Luku 9: Arkkitehtuurisuunnittelu. Luku 10: Komponenttitason suunnittelu. arkkitehtuurigenret, tyylit ja mallit Kerrosarkkitehtuuri

Koko: px
Aloita esitys sivulta:

Download "Luku 9: Arkkitehtuurisuunnittelu. Luku 10: Komponenttitason suunnittelu. arkkitehtuurigenret, tyylit ja mallit Kerrosarkkitehtuuri"

Transkriptio

1 Ohjelmistotekniikka: Luento 5 Jouni Lappalainen Luku 8: Suunnittelutekniikat suunnittelun käsitteet suunnittelumalli (design model) arkkitehtuuri, rajapinnat, komponenttitaso, sijoitustaso Luku 9: Arkkitehtuurisuunnittelu arkkitehtuurigenret, tyylit ja mallit Kerrosarkkitehtuuri Luku 10: Komponenttitason suunnittelu komponentin määrittely luokkapohjaisten komponenttien suunnittelu 1

2 Soveltuvat lait ja pohdiskelun aiheita 1. Vain piilossa olevaa voidaan muuttaa riskittä / no 8, Parnas Suunnittelumallien käyttö johtaa nopeampaan ja parempaan ylläpitoon / hyp_no 4, Gamma Oliosuuntautuneita ohjelmia on vaikea ylläpitää / hyp_no 16, Wilde

3 Soveltuvat lait ja pohdiskelun aiheita Conway:n laki (L16) esittää, että järjestelmän rakenne heijastaa sitä rakentavan organisaation rakennetta Mitä tämä mielestänne tarkoittaa ja löytyykö siihen esimerkkejä? Esitä kaksi sovellusesimerkkiä seuraaville arkkitehtuurityylille.» Kerrosarkkitehtuuri» Tietovuoarkkitehtuuri» Asiakas/palvelin arkkitehtuuri» Tietovarastopohjainen arkkitehtuuri Garlan et al. esittelee kolme perustekniikkaa arkkitehtonisen yhteensopimattomuuden käsittelemiselle (hoitamiselle). Mitä ne ovat ja mihin periaatteisiin ne nojautuvat? 3

4 Suunnittelutekniikat Skenaariopohjaiset elementit Käyttötapaukset Käyttötapauskaaviot Aktiviteettikaaviot Uimaratakaaviot Luokkapohjaiset elementit Luokkakaaviot Analyysipakkaukset CRC mallit Yhteistyökaaviot Analyysimalli Vuosuuntautuneet elementit Tietovuokaaviot Ohjausvuokaaviot Käsittelykertomukset Käyttäytymiselementit Tilakaaviot Sekvenssikaaviot Komponenttitason suunnittelu Rajapintasuunnittelu Arkkitehtuurisuunnittelu Tieto / Luokkarakennesuunnittelu Suunnittelumalli 4

5 Hyvän suunnitelman tunnusmerkit Suunnitelman tulisi kuvata arkkitehtuuri, joka noudattaa tunnettuja arkkitehtuureja (esim. suunnittelumallit) koostuu komponenteista, jotka noudattavat hyviä periaatteita (esim. modulaarisuus) voidaan toteuttaa evolutionaarisesti olla modulaarinen kuvata erikseen tieto, arkkitehtuuri, rajapinnat ja komponentit johtaa tietorakenteisiin, jotka ovat sopivia toteutettaville luokille johtaa komponenetteihin, jotka esittävät itsenäisiä toiminnallisia kokonaisuuksia johtaa rajapintoihin, jotka poistavat liitäntöjen mutkikkuutta olla kuvattu helposti ymmärrettävällä esitystavalla 5

6 Suunnitelman laatuattribuutit HP:n FURPS Functionality (Toiminnallisuus) generality, security Usability (Käytettävyys) overall aesthetics Reliability (Luotettavuus) failure rate, MTTF Performance (Suorituskyky) response time, throughput Supportability (Tuettavuus) extensibility adaptability serviceability ISO 9126 Toiminnallisuus (Functionality) suitability, accuracy, interoperability, security Luotettavuus (Reliability) maturity, fault tolerance, recoverability Käytettävyys (Usability) understandability, learnability, operability, attractiveness Tehokkuus (Efficiency) time behaviour, resource utilisation Ylläpidettävyys (Maintainability) analysability, changeability, stability, testability Siirrettävyys (Portability) adaptability, installability, co-existence, replaceability 6

7 Suunnittelun peruskäsitteet Abstraktio keino hallita mutkikkuutta esim. avata ovi, ovi Arkkitehtuuri rakenne, jolla voidaan lisätä järjestelmän käsitteellistä yhdenmukaisuutta Suunnittelumallit mahdollistavat kokeiltujen ratkaisujen käytön suunnittelussa Ositus (separation of concerns) vaikean ongelman ratkaisu on helpompaa, kun sen jakaa osiin Modulaarisuus tekee ohjelmasta hallittavan työkustannukset moduulin määrä kokonaiskustannukset integrointikustannukset kustannukset/ moduuli 7

8 Suunnittelun peruskäsitteet Tiedon kätkentä moduulien välinen kommunikointi tapahtuu hallitusti rajapintaa käyttäen, moduulin sisältöä ei näytetä Toiminnallinen riippumattomuus saavutetaan korkean koheesion ja alhaisen kytkennän avulla Askeleittain tarkentaminen esimerkki top-down suunnittelustrategiasta abstraktio ja tarkentaminen ovat toisiaan täydentäviä Piirteet (aspects) liittyy osittamiseen ja asetettuihin vaatimuksiin esim. jos kaksi vaatimusta leikkaavat jonkin piirteen osalta, tämä piirre kannattaa toteuttaa omana moduulina Refaktorointi yksinkertaistaa suunnitelmaa tai koodia muuttamatta itse toimintaa ja käyttäytymistä (tutkitaan käyttämättömät elementit, päällekkäisyys, tehottomat tai tarpeettomat algoritmit, huonot tietorakenteet) Suunnittelutason luokat suunnittelija luo tyypillisesti viidentyyppisiä luokkia rajapintaluokat, liiketoiminta-alueen luokat, prosessiluokat, talletusluokat, järjestelmäluokat 8

9 Refaktorointi - hyödyt parantaa ohjelman rakennetta muuten koodi rappeutuu helpottaa koodin ylläpitoa kahdentuneet (duplikoidut) osat poistetaan koodista saadaan luettavampaa korostetaan ymmärrettävyyttä, vähentää datariippuvuutta ohjelmisto saadaan ymmärrettävämmäksi ohjelman toiminta tulee selvemmäksi ohjelmasta löydetään helpommin virheet kun koodi on selkeämpää auttaa ohjelmistojen jatkokehitystä kun koodi ei rappeudu 9

10 Refaktorointi - pahat hajut Kahdentunut koodi Pitkä metodi Suuri luokka Pitkä parametrilista Erisuuntaiset muutokset Haulikkoleikkaus Ominaisuuskateus Tietorykelmä Primitiivipakkomielle Case-rakenteet Rinnakkaiset periytymishierarkiat Laiska luokka Spekuloiva yleistäminen Väliaikainen instanssimuuttuja Viestiketjut Välittäjä Sopimaton läheisyys Vaihtoehtoiset luokat erilaisilla rajapinnoilla Keskeneräinen kirjastoluokka Dataluokka Kielletty perintö Kommentit 10

11 Milloin suunnittelutason luokka on hyvä? Täydellinen ja riittävä attribuutit ja operaatiot ovat luokan toiminnan kannalta odotettuja ja välttämättömiä Yksinkertainen operaatiot toteuttavat vain isäntäluokan tarvitseman palvelun Korkea koheesio luokalla on vain pieni, fokusoitu joukko vastuita (hyvin määritelty ja selkeä tehtävä) Alhainen kytkentä mittaa luokkien välisiä sidonnaisuuksia vaikka luokkien välinen yhteistyö on normaalia, se tulisi pitää minimissä alhainen kytkentä takaa, että muutokset luokkaan eivät aiheuta muutoksia useisiin muihin luokkiin 11

12 Analyysitasosta suunnittelutasolle Pohjapiirros tyyppi ulkomitat lisääkamera() lisääseinä() lisääikkuna() tuhoaelementti() pirrä() 1 * Kamera tyyppi kameraid paikka valittuzoom SeinäElementti * Elementti alkukoordinaatti loppukoordinaatti poimityyppi() piirrä() Ikkuna 12

13 Suunnittelumalli (design model) Suunnittelumalli koostuu viidenlaisista peruselementeistä Tietosuunnittelun elementit (1) sovellustasolla tietosuunnittelu kohdistuu tiedostoihin ja tietokantoihin komponenttitasolla tarkastelee paikallisia tietorakenteita Arkkitehtuurisuunnittelun elementit (2) arkkitehtuurimalliin käytetään (1) sovellusalueen tietoja, (2) analyysimallin tietoja ja (3) soveltuvia arkkitehtuurikaavoja (patterns) Rajapintasuunnittelun elementit (3); kolmenlaisia käyttöliittymät esteettiset, ergonomiset ja tekniset elementit ulkoiset rajapinnat mitä tietoa järjestelmä saa ja mitä se lähettää ulospäin, miten virheen tarkastus ja turvallisuus on hoidettu sisäiset rajapinnat luokkien välinen kommunikointi ja yhteistyö 13

14 Suunnittelumalli.. Komponenttitason suunnittelun elementit (4) esitellään ohjelmistokomponentin yksityiskohdat; tietorakenteet paikallisille tieto-olioille, algoritmit tiedon käsittelemiseksi komponentin yksityiskohdat voidaan kuvata eri kaavioilla aktiviteettikaavio käsittelylogiikan kuvaamiseen proseduurit voidaan kuvata pseudokoodilla, aktiviteettikaavioilla tai vuokaavioilla 14

15 Suunnittelumalli.. Komponenttitason suunnittelun elementit (4) esimerkki komponenttikaaviosta Osa SafeHome järjestelmää Tunnistimen hallinta Tunnistin liittyvät komponentit kannattaa ryhmitellä omiksi kokonaisuuksiksi joka voidaan UML:ssa kuvata pakkauksena 15

16 Suunnittelumalli.. Sijoitustason suunnittelun elementit (5) esitellään miten ohjelmiston toiminnallisuus ja osajärjestelmät sovitetaan yhteen fyysisen tietokoneympäristön kanssa UML kuvaus sijoituskaaviosta (deployment diagram) SafeHome tuottessa on kolme yhdessä toimivaa laskentaympäristöä kotona oleva PC ohjauspaneeli toimittajan palvelin (mahdollistaa Internet yhteyden järjestelmään) Control Panel Tunnistin Security PC Security Home Management External Access Tunnistin Surveillance Communication Comp. Server Tunnistin Homeowner Access 16

17 9. Arkkitehtuurisuunnittelu Arkkitehtuuri The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. Bass, Clements, Kazman 2003 Ottaa kantaa keskeisiin ohjelmiston ratkaisuihin, jotka voivat koskea paitsi yleistä jakamista osiin myös osien kommunikointitapaa, prosesseja ja niiden välistä kommunikointia, tiedon saantitapoja ja pysyvyyden toteuttamista, toiminnallisuuden sijoittelua eri järjestelmän osiin, hajautetun järjestelmän fyysistä rakennetta, järjestelmän kykyä käsitellä suuria tieto- ja käyttäjämääriä, tehokkuutta, varautumista tulevaisuuden tarpeisiin, uudelleenkäytettävyyttä jne. Koskimies, Mikkonen

18 Arkkitehtuurisuunnittelu Arkkitehtuuri on kuvaus, joka mahdollistaa suunnitelmien tehokkuuden analysoinnin (kiinnitettyihin vaatimuksiin nähden) arkkitehtuurivaihtoehtojen arvioinnin (tasolla, jossa muutokset ovat vielä kohtuullisen helppoja) ohjelmiston rakentamiseen liittyvien riskien vähentämisen Ero arkkitehtuurin ja ohjelmiston alemman tason rakenteen kuvausten välillä on häilyvä arkkitehtuuri sisältää ne ominaisuudet, jotka eivät muutu ohjelmiston evoluution aikana / Koskimies

19 Näkökulmia arkkitehtuuriin / 4+1 malli (Kruchten, 1995) + 1 (Koskimies, Mikkonen 2005) Looginen näkymä Skenaarionäkymä (Scenario view) kuvaa, kuinka järjestelmä on vuorovaikutuksessa sen ulkopuolella olevien käyttäjien ja muiden järjestelmien kanssa tietyssä käyttöskenaariossa Looginen näkymä (Logical view) kuvaa, miten toiminnallisuus on jaettu järjestelmän eri osien kesken ja mitä velvollisuuksia kullakin komponentilla on -> miten skenaarionäkymän esittämä toiminnallisuus saadaan aikaan Prosessinäkymä (Process view) Kehitysnäkymä Prosessinäkymä Skenaarionäkymä kuvaa, miten järjestelmän toiminta on jaettu loogisiin prosesseihin ja miten prosessit kommunikoivat voidaan arvioida järjestelmän suorituskykyä ja skaalautuvuutta Fyysinen näkymä 19

20 Näkökulmia arkkitehtuuriin / 4+1 malli (Kruchten, 1995) + 1 (Koskimies, Mikkonen 2005) Kehitysnäkymä (Development view) kuvaa, miten järjestelmä on jaettu osiin, jotka voidaan toteuttaa erillisinä yksikköinä olennainen suurten ohjelmistojen tapauksessa Fyysinen näkymä (Physical view) Looginen näkymä Kehitysnäkymä Prosessinäkymä Skenaarionäkymä kuvaa, millaisista fyysisistä prosessointiyksiköistä järjestelmä koostuu, miten nämä ovat yhteydessä toisiinsa ja mitä fyysisiä ohjelmistoartifakteja (esim. komponentteja, tietokantoja) kuhunkin prosessointiyksikköön sijoitetaan Muuntelunäkymä (Variability view) kuvaa, millaista muuntelua järjestelmä tukee kuvaa järjestelmän variaatiopisteet (joissa muuntelu tapahtuu), niiden edellyttämät vaatimukset muunnelmille ja niiden käytön muunnelmien toteuttamiseksi (laajennusrajapinta) olennainen tuoterunkojen tapauksessa Fyysinen näkymä 20

21 Arkkitehtuurityylit putket prosessointiyksikkö prosessointiyksikkö sovellusohjelma sovellusohjelma prosessointiyksikkö prosessointiyksikkö prosessointiyksikkö tietovarasto sovellusohjelma prosessointiyksikkö prosessointiyksikkö prosessointiyksikkö sovellusohjelma sovellusohjelma Tietovarastopohjainen arkkitehtuuri prosessointiyksikkö Tietovuoarkkitehtuuri Jouni Lappalainen & Ilkka Tervonen 21

22 Arkkitehtuurityylit Pääohjelma Luokka_C Luokka_A Valvova aliohjelma Valvova aliohjelma Luokka_B... Luokka_B... Sovellus aliohjelma Sovellus aliohjelma Sovellus aliohjelma Sovellus aliohjelma Luokka_D Sovellus aliohjelma Pääohjelma/aliohjelma arkkitehtuuri Olioperustainen arkkitehtuuri Jouni Lappalainen & Ilkka Tervonen 22

23 Arkkitehtuurityylit Selain Selain HTML JavaScript Visual Basic Sovellus- palvelin Sovellus- ohjelmat (Java, C++,...) Tietokanta- palvelin Tietokanta- kyselyt (SQL,...) Palveluun rekisteröityminen Selain Kerrosarkkitehtuuri Asiakas-palvelin arkkitehtuuri (client-server) etsi Palvelua pyytävä sido julkaise Palvelun tuottaminen Palvelukeskeinen arkkitehtuuri (SOA) Palvelu 23

24 Kerrosarkkitehtuuri Selain Selain Selain HTML JavaScript Visual Basic Sovellus- palvelin Sovellus- ohjelmat (Java, C++,...) Tietokanta- palvelin Tietokanta- kyselyt (SQL,...) 24

25 Kerrosarkkitehtuurin etuja Kerroksittaisuus helpottaa ylläpitoa Kerroksen sisältöä voi muuttaa vapaasti jos sen palvelurajapinta eli muille kerroksille näkyvät osat säilyvät muuttumattomina Sama pätee tietysti mihin tahansa komponenttiin Sovelluslogiikan riippumattomuus käyttöliittymästä helpottaa ohjelman siirtämistä uusille alustoille, esim. toimimaan www-selaimen kautta Alimpien kerroksien palveluja, kuten lokiin kirjoitusta tai tallennuspalvelukerrosta voidaan ehkä uusiokäyttää myös muissa sovelluksissa Ylemmät kerrokset voivat toimia korkeammalla abstraktiotasolla Esim. hyvin tehty tallennuspalvelukerros kätkee tietokannan käsittelyn muilta kerroksilta: sovelluslogiikan tasolla voidaan ajatella kaikki olioina Kaikkien ohjelmoijien ei tarvitse ymmärtää kaikkia detaljeja, osa voi keskittyä tietokantaan, osa käyttöliittymiin, osa sovelluslogiikkaan (Luukkainen & Laine, 2010)" 25

26 Lisää kerrosarkkitehtuureista Myös kerrosten sisällä ohjelman loogisesti toisiinsa liittyvät komponentit kannattaa ryhmitellä omiksi kokonaisuuksiksi joka voidaan UML:ssa kuvata pakkauksena Pakkaus voi sisältää muita (ali)pakkauksia Pakkaus omistaa sisältönsä pakkauksen poistaminen poistaa myös sen sisällön esim. luokka kuuluu yleensä vain yhteen pakkaukseen Pakkaus voi viitata (import) muihin pakkauksiin merkitään riippuvuutena pakkausten välillä tällöin pakkauksen elementit (esim. luokat) voivat viitata kohdepakkaukseen tai sen elementteihin 26

27 Pakkausnotaatioita (Pohjalainen P., 2009)" 27

28 Kerrosten väliset riippuvuudet Ylemmät kerrokset riippuvat alemmista Alempien kerrosten oltava (julkisilta osiltaan) vakaita muutos rajapintaan heijastuu ylempään Toisaalta alemman kerroksen voidaan vaihtaa julkisilta osiltaan samanlaiseen (mutta sisäiseltä toteutukseltaan erilaiseen), koska se on riippumaton ylemmästa (Pohjalainen P., 2009)" 28

29 (Pohjalainen P., 2009)" 29

30 Miten hyötyä kerroksellisuudesta Pelkkä kerroksittaisuus ei tee ohjelman arkkitehtuurista automaattisesti hyvää. Alla tilanne, missä kerroksen n+1 kolmella alipaketilla on kullakin paljon riippuvuuksia kerroksen n sisäisiin komponenttiin Esim. muutos kerroksen n luokkaan 1 aiheuttaa nyt muutoksen hyvin moneen ylemmän kerroksen pakkaukseen (Luukkainen & Laine, 2010)" 30

31 Miten hyötyä kerroksellisuudesta Kerrosten välille kannattaa määritellä selkeä rajapinta Yksi tapa toteuttaa rajapinta on luoda kerroksen sisälle erillinen rajapintaolio, jonka kautta ulkoiset yhteydet tapahtuvat Tätä periaatetta sanotaan fasaadiksi (engl. facade pattern) Alla luotu rajapintaolio kerrokselle n. Kommunikointi kerroksen kanssa tapahtuu rajapintaolion kautta ylemmän kerroksen riippuvuudet kohdistuvat rajapintaolioon muutos esim. luokkaan 1 ei vaikuta kerroksen n+1 komponentteihin ainoat muutokset on tehtävä rajapintaolion sisäiseen toteutukseen (Luukkainen & Laine, 2010)" 31

32 Käyttöliittymän ja sovelluslogiikan erottaminen Kerrosarkkitehtuurin ylimpänä kerroksena on yleensä käyttöliittymä Yleensä pidetään järkevänä, että ohjelman sovelluslogiikka on täysin erotettu käyttöliittymästä Asia tietysti riippuu myös sovelluksen luonteesta ja oletetusta käyttöajasta Sovelluslogiikan erottaminen lisää koodin määrää, joten jos kyseessä kertakäyttösovellus, ei ylimääräinen vaiva ehkä kannata (Luukkainen & Laine, 2010)" 32

33 Arkkitehtuurin arviointi ATAM (An Architecture Trade-Off Analysis Model) koostuu neljästä osiosta esittely, analyysi, testaus ja raportointi Analyysivaiheessa tunnistetaan olennaiset arkkitehtuuriratkaisut, jotka tukevat tiettyjä laatuominaisuuksia laaditaan laatupuu ja liitetään laatuominaisuuksiin skenaarioita ja arvioidaan niiden tärkeys onnistumisen kannalta ja kuinka vaikea skenaario on toteuttaa (riski) tärkeimpiin skenaarioihin liitetään niitä tukevat arkkitehtuuriratkaisut tunnistetaan riskit, turvalliset ratkaisut, herkkyyskohdat (kriittinen jonkin laatuominaisuuden kannalta) ja tasapainokohdat (vaikuttaa useampaan laatuominaisuuteen, +/-) Koskimies & Mikkonen: Ohjelmistoarkkitehtuurit 33

34 tärkeys H vaikeus M Laatupuu 34

35 ATAM analyysin käsitteet /Kazman et al

36 Mikä on komponentti? OMG Unified Modeling Language Specification [OMG01] määrittelee komponentin a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. oliopuolella: komponentti koostuu joukosta yhteistyössä toimivia luokkia perinteisesti: ohjelmiston osa, joka sisältää toimintalogiikan kuvauksen, sen tarvitsemat sisäiset tietorakenteet ja rajapinnan, jonka kautta se voidaan käynnistää ja jonka kautta tietoa siirretään yleisesti: itsenäinen ohjelmayksikkö, joka tarjoaa palveluja rajapinnan kautta 36

37 Komponentit ovat ohjelmistoarkkitehtuurissa käsiteltäviä pienimpiä yksiköitä: raja arkkitehtuurisuunnittelun ja yksityiskohtaisen suunnittelun välillä. Suuri komponentti voi kuitenkin koostua useista pienemmistä komponenteista, jolloin komponentilla on oma sisäinen arkkitehtuurinsa esim. Eclipsen kaltainen ohjelmointiympäristö ja siihen integroidut työkalut Komponentin sisäisen rakenteen ei pitäisi näkyä ulospäin eikä toiminnan riippua käyttöympäristöstä (muuten kuin vaadittujen rajapintojen kautta) 37

38 Komponentti muodostaa toiminnallisen kokonaisuuden, joka tarjoaa joukon loogisesti toisiinsa liittyviä palveluja palvelut käyttävät samoja tietorakenteita palveluja käytetään tyypillisesti samassa yhteydessä Toiminnallisuus on peruste komponentin olemassaololle. Komponenteilla hallitaan järjestelmän muunneltavuutta: eristetään järjestelmän osat, jotka halutaan helposti päivitettäviksi Komponenttityyppejä: esim. plugin-komponentit ja COTS (Commercial Off-The-Shelf )-komponentit 38

39 Komponentti on työnjaon perusyksikkö kaikissa kehitystyön vaiheissa esim. suunnittelu, toteutus, testaus, konfiguraation hallinta, ylläpito Yksi komponentti yhden henkilön vastuulle. Työryhmä kehittää toisiinsa liittyviä komponentteja (esim. tiettyä alijärjestelmää). Järjestelmää kehittävän organisaation rakenne alkaa muistuttaa järjestelmän rakennetta (tai päinvastoin: vrt. Conway:n laki) 39

40 Komponentin ominaispiirteet Riippuvuudet komponentti voi riippua palveluista, joita se olettaa saavansa muilta komponenteilta vaadittujen rajapintojen kautta Käyttöönotto komponentti voidaan ottaa käyttöön lähdekoodisena (käännösaikana) tai käännettynä binäärimuodossa (linkkausaikana) Koko komponentin tulisi olla yhden henkilön hallittavissa Standardointi esimerkkinä Sunin EJB-komponenttistandardi» Koskimies, Mikkonen

41 Komponenttien välinen vuorovaikutus Rajapinta kertoo, miten palvelu otetaan käyttöön palvelun nimi, parametrit ja niiden tyypit ja mahdollisen tuloksen tyyppi = kutsumuoto (signature) palvelun merkitys kuvataan tulo- ja jättöehtojen (pre/post condition) avulla» Koskimies, Mikkonen 2005 PowerSource tarjottu rajapinta Car PowerSource Car vaadittu rajapinta Engine PowerSource Engine 41

42 Esimerkki komponenttimallista: osa yliopistojärjestelmästä UML Superstructure Specification, v2.4 42

43 Komponentin räätälöinti Komponentin uudelleenkäytettävyys edellyttää komponentin soveltumista erilaisiin yhteyksiin. Komponentin voitava muunnella tarjoamaansa palvelua tarpeen mukaan. Komponentin suunnittelussa huomioitava varianssin hallinta (samaan tapaan kuin tuoterungoissa tai sovelluskehyksissä). 43

44 Komponentin räätälöinti periytymisen avulla Määritellään halutut operaatiot aliluokassa uudelleen dynaamisen sidonnan ansiosta suoritusaikana tulee kutsutuksi olion dynaamisen tyypin mukainen operaatio Huono puoli: periytyminen rikkoo kapseloinnin -> semanttinen särkyvän yliluokan ongelma (semantic fragile base class problem) 44

45 Särkyvän yliluokan ongelma Kirjastokomponentti Comp Räätälöity komponentti Custom Muutos alkuperäiseen komponenttiin voi tehdä räätälöidystä komponentista toimimattoman 45

46 Luokkapohjaisten komponenttien suunnittelu (oliosuunnittelun periaatteet) The Open-Closed Principle (OCP). A module [component] should be open for extension but closed for modification. muutokset eivät saa aiheuttaa muutoksia useisiin paikkoihin esim. abstrakteihin rajapintoihin perustuvissa malleissa uuden rajapinnan toteuttavan aliluokan lisääminen ei saisi aiheuttaa muutoksia mallin muissa luokissa <<interface>> Sensor read() enable() disable() test() Window sensor Smoke sensor Motion detector Detector Heat sensor CO2 sensor 46

47 The Liskov Substitution Principle (LSP). Subclasses should be substitutable for their base classes. Ohjelman toiminta säilyy samana, jos luokan T toiminnallisuus korvataan luokalla S, joka on T:n aliluokka Lapsiluokan tulee olla sijoitettavissa kantaluokkiensa tilalle. Ongelma on, että tätä periaatetta ei voi varmistaa tarkastelemalla vain luokkaa itseään, vaan pitää myös tietää miten sitä käytetään. Kuvan vasemmassa osassa oleva rakenne ei noudata korvausperiaatetta, koska lainatililtä ei voi veloittaa. Tilanne on ratkaistu määrittelemällä tileille uusi, yhteinen yliluokka, jonka rajapintaa on rajoitettu (veloitusmetodi poistettu), josta lainatili ja shekkitili on peritty. ChequeAccount accountname balance credit() debit() MortgageAccount interestrate calculateinterest() - debit() Restructuring to satisfy LSP MortgageAccount interestrate calculateinterest() Account accountname balance credit() ChequeAccount debit() 47

48 Oliosuunnittelun periaatteet Dependency Inversion Principle (DIP). Depend on abstractions. Do not depend on concretions. Korkeamman tason modulit eivät saa riippua alemman tason moduleista. Molempien tulisi riippua abstraktioista. Abstraktioiden ei tulisi riippua yksityiskohdista, vaan päinvastoin. The Interface Segregation Principle (ISP). Many client-specific interfaces are better than one general purpose interface. Lihava palvelinrajapinta tulisi erottaa erillisiksi asiakaskohtaisiksi rajapinnoiksi. Rajapinta kuuluu asiakkaalle, eikä palvelimelle. Source: Martin, R., Design Principles and Design Patterns, downloaded from

49 Oliosuunnittelun periaatteet The Release Reuse Equivalency Principle (REP). The granule of reuse is the granule of release. Paketoinnissa käytetään samaa rakeisuutta kuin uudelleenkäytettävyydessä. The Common Closure Principle (CCP). Classes that change together belong together. Luokat joihin kohdistuu samanlaisia muutospaineita kuuluvat yhteen (laitetaan samaan pakettiin). The Common Reuse Principle (CRP). Classes that aren t reused together should not be grouped together. Jos luokkia ei ole uudelleenkäytetty yhdessä, ei niitä myöskään pitäisi käsitellä yhtenä ryhmänä (laittaa samaan pakettiin). Source: Martin, R., Design Principles and Design Patterns, downloaded from

50 Koheesio Perinteisesti: yhden tarkoituksen moduuli OO näkökulma: koheesio tarkoittaa, että komponentti tai luokka kapseloi vain sellaiset attribuutit ja operaatiot, jotka liittyvät läheisesti toisiinsa ja itse luokkaan tai komponenttiin Koheesion tasot (lueteltu koheesion korkeusjärjestyksessä) Toiminnallinen Peräkkäinen toisen osan tuloste on toisen osa syöte Kommunikationaalinen saman datan käsittelyyn liittyvät operaatiot samassa luokassa Proseduraalinen tarkastetaan lupa käyttää tiedostoa ja sitten avataan se Ajallinen virheen sattuessa tietyt operaatiot suoritetaan (suljetaan avoimet tiedostot, kirjataan virhelokiin ja ilmoitetaan käyttäjälle) Looginen samankaltaiseen tehtävään liittyvät, esim I/O käsittelyyn Satunnainen 50

51 Kytkentä Perinteisesti: kytkennän aste komponenttien välillä pyritään alhaiseen kytkentään OO näkökulma: kytkennän aste luokkien välillä Kytkennän tasot (korkeasta matalaan) Sisältökytkentä (haetaan toisen moduulin paikallista dataa) Yleinen kytkentä (globaalin muuttujan käyttö) Ulkoinen kytkentä (kaksi moduulia jakavat ulkopuolisen määrittelemän tietoformaatin, protokollan tai laiterajapinnan) Ohjauskytkentä (operaation A herättää operaation B) Leimakytkentä (moduulit jakavat tietorakennekoosteen ja käyttävät vain osaa siitä) Datakytkentä (tietoa siirretään argumenttien avulla) Viestikytkentä (moduulit eivät ole riippuvia toisistaan, käyttävät julkista rajapintaa viestien vaihdolle) 51

52 Soveltuvat lait ja pohdiskelun aiheita 1. Vain piilossa olevaa voidaan muuttaa riskittä / no 8, Parnas 1972 Parnas jatkoi perinteisen pieni moduuli&selkeä rajapinta suunnitteluperiaatteen kehittelyä. Jako moduuleihin tulisi tehdä niin, että ne ovat pitkälti riippumattomia toisistaan. Silloin moduli olisi helpommin vaihdettavissa. Tällöin yhden moduulin toteutus ei ole riippuvainen muiden moduulien toteutuksesta. Eli, toteutus voidaan piilottaa ja sitä voidaan muuttaa, kunhan moduulin muille tarjoama palvelu säilyy samana. 52

53 Soveltuvat lait ja pohdiskelun aiheita 2. Suunnittelumallien käyttö johtaa nopeampaan ja parempaan ylläpitoon / hyp_no 4, Gamma 1995 väitetään, että suunnittelumallien käyttö (1) parantaa ohjelmoijien tuottavuutta ja ohjelman laatua, (2) parantaa noviisien taitoja (tekevät parempia ratkaisuja), (3) parantaa suunnittelijoiden kommunikointia, (4) rohkaisee hyvien suunnitteluideoiden vaihtoa ja (5) parantaa ohjelmien ylläpitoa 3. Oliosuuntautuneita ohjelmia on vaikea ylläpitää / hyp_no 16, Wilde 1993 luokan operaatioilla on yhteyksiä toisiin luokkiin. Toiminnan ymmärtäminen vaatii monien luokkien tutkimista. jo kolmitasoinen luokkahierarkia kasvattaa ylläpitoajan ja virheiden määrän suuremmaksi kuin ilman hierarkiaa 53

54 Soveltuvat lait ja pohdiskelun aiheita Conway:n laki (L16) esittää, että järjestelmän rakenne heijastaa sitä rakentavan organisaation rakennetta Mitä tämä mielestänne tarkoittaa ja löytyykö siihen esimerkkejä? Esitä kaksi sovellusesimerkkiä seuraaville arkkitehtuurityylille.» Kerrosarkkitehtuuri» Tietovuoarkkitehtuuri» Asiakas/palvelin arkkitehtuuri» Tietovarastopohjainen arkkitehtuuri Garlan et al. esittelee kolme perustekniikkaa arkkitehtonisen yhteensopimattomuuden käsittelemiselle (hoitamiselle). Mitä ne ovat ja mihin periaatteisiin ne nojautuvat? Aiheeseen liittyvää luettavaa: Garlan D., Allen R. and Ockerbloom J., Architectural Mismatch: Why Reuse Is Still So Hard, IEEE Software, vol 26, no 4, 2009, pp

Ohjelmistotekniikka: Luento 6

Ohjelmistotekniikka: Luento 6 Ohjelmistotekniikka: Luento 6 Jouni Lappalainen Luku 8: Suunnittelutekniikat suunnittelun käsitteet suunnittelumalli (design model) arkkitehtuuri, rajapinnat, komponenttitaso, sijoitustaso Luku 9: Arkkitehtuurisuunnittelu

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

Sytyke ry:n laivaseminaari Software Technology Transfer Pekka Forselius

Sytyke ry:n laivaseminaari Software Technology Transfer Pekka Forselius Sytyke ry:n laivaseminaari 3.-5.9.2002 Testaus ja Laatu Ohjelmiston laadun ja laatuvaatimusten mittaaminen Sytyke ry:n laivaseminaari 3.-5.9.2002 Hyvä laatu? Testaaminen? Ohjelmiston hyvällä laadulla tarkoitamme

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

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

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

Ohjelmistoarkkitehtuurit kevät

Ohjelmistoarkkitehtuurit kevät Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti?

Lisätiedot

Komponentit ja rajapinnat

Komponentit ja rajapinnat Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti?

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

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

Ohjelmistojen mallintaminen Ohjelmistoarkkitehtuuri Harri Laine 1

Ohjelmistojen mallintaminen Ohjelmistoarkkitehtuuri Harri Laine 1 Ohjelmistojen mallintaminen Ohjelmistoarkkitehtuuri 25.11.2008 Harri Laine 1 Buschmann et al: Software architecture is a description of the subsystems and components of a software system and relations

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

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

9. Ohjelmistoarkkitehtuurien arviointi

9. Ohjelmistoarkkitehtuurien arviointi 9. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 Mitä on ohjelmistoarkkitehtuurin

Lisätiedot

Ohjelmistoarkkitehtuurit kevät

Ohjelmistoarkkitehtuurit kevät Ohjelmistoarkkitehtuurit Kevät 2011-2012 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 9. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto

Lisätiedot

Ohjelmistoarkkitehtuurit

Ohjelmistoarkkitehtuurit Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto

Lisätiedot

Ohjelmistoarkkitehtuurien arviointi

Ohjelmistoarkkitehtuurien arviointi Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto

Lisätiedot

Kevät Ohjelmistoarkkitehtuurit 2014

Kevät Ohjelmistoarkkitehtuurit 2014 Ohjelmistoarkkitehtuurit Kevät 2014 http://www.cs.tut.fi/~ohar/ 1 Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto 2 Mitä on ohjelmistoarkkitehtuurin

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

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

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

6. Arkkitehtuurityylit

6. Arkkitehtuurityylit 6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit - Kerrosarkkitehtuurit - Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit - Asiakas-palvelin arkkitehtuurit - Viestinvälitysarkkitehtuurit

Lisätiedot

Laatukustannukset. Laadun hallinta. Laadun kustannuksista

Laatukustannukset. Laadun hallinta. Laadun kustannuksista Laatukustannukset Laadun hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 13.2.2007 US National Institute of Standards and Technology: Riittämättömän testauksen kustannusten arvioitiin olevan 59 Mrd dollaria

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

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

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

Lisätiedot

2 Ohjelmistoarkkitehtuurien kuvaus

2 Ohjelmistoarkkitehtuurien kuvaus 2 Ohjelmistoarkkitehtuurien kuvaus 2.1 Arkkitehtuurikuvauksen merkityksestä 2.2 Arkkitehtuurin kuvaukseen liittyvät käsitteet 2.3 Arkkitehtuurikuvaukset eri tasoilla 2.4 Arkkitehtuurinäkymät ja kuvaustyypit

Lisätiedot

Ohjelmistojen mallintaminen

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

Lisätiedot

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

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

Ohjelmistoarkkitehtuurit 2016. Kevät 2016 -käytäntöjä

Ohjelmistoarkkitehtuurit 2016. Kevät 2016 -käytäntöjä Ohjelmistoarkkitehtuurit Kevät 2016 -käytäntöjä Samuel Lahtinen http://www.cs.tut.fi/~ohar/ 13.1.2016 1 Tervetuloa Tampereen teknillinen yliopisto, Oulun yliopisto, Turun yliopisto 13.1.2016 2 Tiedonvälitys

Lisätiedot

Laadun hallinta. Laatukustannukset. Laadun kustannuksista. Sami Kollanus TJTA330 Ohjelmistotuotanto

Laadun hallinta. Laatukustannukset. Laadun kustannuksista. Sami Kollanus TJTA330 Ohjelmistotuotanto Laadun hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 5.4. Laatukustannukset US National Institute of Standards and Technology: Riittämättömän testauksen kustannusten arvioitiin olevan 59 Mrd dollaria

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

UML - unified modeling language

UML - unified modeling language UML - unified modeling language Lähtökohtana: Booch, Rumbaugh, Jacobsson Tavoitteena Unified Method - syntyykö? Kehittäjänä: Rational Inc. Standardointi: Object Management Group (OMG) - vaiheessa Lähteet:

Lisätiedot

TIE-20200 Ohjelmistojen suunnittelu

TIE-20200 Ohjelmistojen suunnittelu TIE-20200 Ohjelmistojen suunnittelu Luento 7: SOLID ja olioiden rakentelumalleja TIE-20200 Samuel Lahtinen 1 Ajankohtaista Harjoitustyössä suunnittelusessioiden ajanvaraus auki Viikkoharjoituksissa tehtaaseen/rakennuttajiin

Lisätiedot

Kevät 2016 Arkkitehtuurin arviointi, ATAM. Ohjelmistoarkkitehtuurit 2016

Kevät 2016 Arkkitehtuurin arviointi, ATAM.  Ohjelmistoarkkitehtuurit 2016 Ohjelmistoarkkitehtuurit Kevät 2016 Arkkitehtuurin arviointi, ATAM http://www.cs.tut.fi/~ohar/ 1 Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto

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

1 Johdanto. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1

1 Johdanto. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri

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

Ohjelmistoarkkitehtuurit. Syksy 2007

Ohjelmistoarkkitehtuurit. Syksy 2007 Ohjelmistoarkkitehtuurit Syksy 2007 Kai Koskimies 1 Tervetuloa Tampereen yliopisto, Teknillinen korkeakoulu, Turun yliopisto 2 Kurssin tavoitteet Arkkitehtuuritason peruskäsitteiden ymmärtäminen Arkkitehtuurien

Lisätiedot

Tietorakenteet ja algoritmit

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

Lisätiedot

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

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

Pakkauksen kokoaminen

Pakkauksen kokoaminen 13. Pakkaukset 13.1 Sisällys Pakkauksen kokoaminen (package). Pakkaukset ja hakemistorakenne. Pakkauksen luokkien käyttö muissa pakkauksissa (import). Pakkaukset ja näkyvyys. 13.2 Pakkauksen kokoaminen

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

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

Ohjelmistoarkkitehtuurit Komponentit Kevät 2016

Ohjelmistoarkkitehtuurit Komponentit Kevät 2016 Ohjelmistoarkkitehtuurit Komponentit Kevät 2016 Samuel Lahtinen http://www.cs.tut.fi/~ohar/ 1 Komponentit ja rajapinnat Komponenttien idea: ohjelmistotuotannon rationalisointi Mikä on ohjelmistokomponentti?

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

Teknologia-arkkitehtuurit. Valinta ja mallinnus

Teknologia-arkkitehtuurit. Valinta ja mallinnus Teknologia-arkkitehtuurit Valinta ja mallinnus ENTERPRISE ARCHITECTURE - A FRAMEWORK TM DATA What FUNCTION How NETWORK Where PEOPLE Who When MOTIVATION Why T IM E SCOPE (CONTEXTUAL) List of Things Important

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

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

Ohjelmistoarkkitehtuurit Kevät käytäntöjä

Ohjelmistoarkkitehtuurit Kevät käytäntöjä Ohjelmistoarkkitehtuurit Kevät 2014 -käytäntöjä Samuel Lahtinen http://www.cs.tut.fi/~ohar/ 8.1.2014 1 Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto

Lisätiedot

Ohjelmistoarkkitehtuurit kevät

Ohjelmistoarkkitehtuurit kevät Ohjelmistoarkkitehtuurit Kevät 2011-2012 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit

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

7.4 Variability management

7.4 Variability management 7.4 Variability management time... space software product-line should support variability in space (different products) support variability in time (maintenance, evolution) 1 Product variation Product

Lisätiedot

TIE Ohjelmistojen suunnittelu

TIE Ohjelmistojen suunnittelu TIE-20200 Ohjelmistojen suunnittelu Luento 10: olioiden rakentelumalleja ja SOLID TIE-20200 Samuel Lahtinen 1 Ajankohtaista Harjoitustyössä välinäyttöjen ajanvaraus auki Viikkoharjoitukset ohi Ohjelmassa

Lisätiedot

Toiminnot eli käyttäytyminen. Tieto eli rakenteelliset ominaisuudet

Toiminnot eli käyttäytyminen. Tieto eli rakenteelliset ominaisuudet Toiminnot eli käyttäytyminen Tieto eli rakenteelliset ominaisuudet Olio (ks. määritelmä): rajattavissa ja yksilöitävissä oleva asia tai käsite, joka on merkityksellinen käsillä olevan tarkastelun kannalta

Lisätiedot

Ohjelmistotuotanto, s

Ohjelmistotuotanto, s Ohjelmistotuotanto : asiakaslähtöisten vaatimusten muuntaminen teknisiä mahdollisuuksia tehokkaasti hyödyntäväksi ratkaisuksi luova prosessi Pääkohteet: ohjelmiston yleisrakenne ja toimintaperiaatteet

Lisätiedot

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu

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

Lisätiedot

POLKU LUOKKAKAAVIOISTA TAULUJEN TOTEUTUKSEEN

POLKU LUOKKAKAAVIOISTA TAULUJEN TOTEUTUKSEEN POLKU LUOKKAKAAVIOISTA TAULUJEN TOTEUTUKSEEN KIRJAN HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI DOCENDO (2003, 2005) LUKU 7 JOUNI HUOTARI & ARI HOVI IIO30100 TIETOKANTOJEN SUUNNITTELU

Lisätiedot

TIES530 TIES530. Moniprosessorijärjestelmät. Moniprosessorijärjestelmät. Miksi moniprosessorijärjestelmä?

TIES530 TIES530. Moniprosessorijärjestelmät. Moniprosessorijärjestelmät. Miksi moniprosessorijärjestelmä? Miksi moniprosessorijärjestelmä? Laskentaa voidaan hajauttaa useammille prosessoreille nopeuden, modulaarisuuden ja luotettavuuden vaatimuksesta tai hajauttaminen voi helpottaa ohjelmointia. Voi olla järkevää

Lisätiedot

1 Johdanto. Pieni motivointikalvo. 1.1 Mikä on ohjelmistoarkkitehtuuri?

1 Johdanto. Pieni motivointikalvo. 1.1 Mikä on ohjelmistoarkkitehtuuri? 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri

Lisätiedot

1.3 Lohkorakenne muodostetaan käyttämällä a) puolipistettä b) aaltosulkeita c) BEGIN ja END lausekkeita d) sisennystä

1.3 Lohkorakenne muodostetaan käyttämällä a) puolipistettä b) aaltosulkeita c) BEGIN ja END lausekkeita d) sisennystä OULUN YLIOPISTO Tietojenkäsittelytieteiden laitos Johdatus ohjelmointiin 811122P (5 op.) 12.12.2005 Ohjelmointikieli on Java. Tentissä saa olla materiaali mukana. Tenttitulokset julkaistaan aikaisintaan

Lisätiedot

Ohjelmistoarkkitehtuurit

Ohjelmistoarkkitehtuurit Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit

Lisätiedot

Ohjelmistoarkkitehtuurit Johannes Koskinen. Osittavat arkkitehtuurityylit

Ohjelmistoarkkitehtuurit Johannes Koskinen.  Osittavat arkkitehtuurityylit Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit

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

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

Huonon suunnittelun oireita. Hajuja ja sääntöjä. Hyvän suunnittelun periaatteet. Paha haju

Huonon suunnittelun oireita. Hajuja ja sääntöjä. Hyvän suunnittelun periaatteet. Paha haju Hajuja ja sääntöjä OA2005 Huonon suunnittelun oireita Kankeus suunnitelmaa on vaikea muokata. Hauraus suunnitelma on helppo rikkoa. Liikkumattomuus suunnitelmaa on hankala uudelleenkäyttää. Viskositeetti

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

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

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

Lisätiedot

Ohjelmistoarkkitehtuurit, syksy 2012 4.9.2010

Ohjelmistoarkkitehtuurit, syksy 2012 4.9.2010 Ohjelmistotutkimuksen painopisteitä Ohjelmistoarkkitehtuurit Johdanto ja peruskäsitteitä 2000 1995 1990 1985 1980 1970 Tuoteperhearkkitehtuurit, MDA, väliohjelmistot, aspektit CASE-välineet: uudelleenkäyttö,

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

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Confuse 25.11.2001 Tila Versio: 1.0 Vaihe: T1 Jakelu: Julkinen Luontipäivä: 15.11.2001 Antti Haapakoski Muutettu viimeksi: 25.11.2001 Antti Haapakoski Sisältö 1 Yleistä 1 2 Mallinnuksesta

Lisätiedot

Olioiden yhteistyön mallintaminen

Olioiden yhteistyön mallintaminen Olioiden yhteistyön mallintaminen Luokkakaaviosta käy hyvin esille ohjelman rakenne minkälaisia luokkia on olemassa miten luokat liittyvät toisiinsa Entä ohjelman toiminta? Luokkakaaviossa voi olla metodien

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

SOA SIG SOA Tuotetoimittajan näkökulma

SOA SIG SOA Tuotetoimittajan näkökulma SOA SIG SOA Tuotetoimittajan näkökulma 12.11.2007 Kimmo Kaskikallio IT Architect Sisältö IBM SOA Palveluiden elinkaarimalli IBM Tuotteet elinkaarimallin tukena Palvelukeskeinen arkkitehtuuri (SOA) Eri

Lisätiedot

Johdatus rakenteisiin dokumentteihin

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

Lisätiedot

1.3Lohkorakenne muodostetaan käyttämällä a) puolipistettä b) aaltosulkeita c) BEGIN ja END lausekkeita d) sisennystä

1.3Lohkorakenne muodostetaan käyttämällä a) puolipistettä b) aaltosulkeita c) BEGIN ja END lausekkeita d) sisennystä OULUN YLIOPISTO Tietojenkäsittelytieteiden laitos Johdatus ohjelmointiin 81122P (4 ov.) 30.5.2005 Ohjelmointikieli on Java. Tentissä saa olla materiaali mukana. Tenttitulokset julkaistaan aikaisintaan

Lisätiedot

Sovellusarkkitehtuurit

Sovellusarkkitehtuurit HELIA TiKo-05 1 (9) Sovellusarkkitehtuurit ODBC (Open Database Connectivity)... 2 JDBC (Java Database Connectivity)... 5 Middleware... 6 Middleware luokittelu... 7 Tietokanta -middleware... 8 Tapahtumamonitorit

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

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

Käyttötapausanalyysi ja testaus tsoft

Kä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ätiedot

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

TIETOKANNAN SUUNNITTELU

TIETOKANNAN SUUNNITTELU TIETOKANNAN SUUNNITTELU HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI DOCENDO (2003, 2005) LUKU 2 JOUNI HUOTARI & ARI HOVI TIETOJEN MALLINNUS TIETOJEN MALLINNUKSESTA TIETOKANTAAN Käsiteanalyysin

Lisätiedot

Ohjelmistojen mallintaminen Olioiden yhteistyö. 18.11.2008 Harri Laine 1

Ohjelmistojen mallintaminen Olioiden yhteistyö. 18.11.2008 Harri Laine 1 Ohjelmistojen mallintaminen Olioiden yhteistyö 18.11.2008 Harri Laine 1 Olioiden yhteistyö Oliokeskeisen ohjelmistonäkemyksen mukaan ohjelmiston palvelut tuotetaan olioiden yhteistyön tuloksena. Ohjelmisto

Lisätiedot

Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista

Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista 582101 - Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista 1 Ohjelmistotuotannon työkaluuista Projektinhallintatyökalut (ei käsitellä tällä kurssilla) CASE- ja mallinnustyökalut (esim. Poseidon)

Lisätiedot

Esimerkki: Auton toiminnan monitorointijärjestelmä

Esimerkki: Auton toiminnan monitorointijärjestelmä Esimerkki: Auton toiminnan monitorointijärjestelmä A car control system needs to be extended with a subsystem that collects various kinds of data during the running of the car, to be used for monitoring

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

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

LUKU 5: SUUNNITTELU. Suunnitteluun liittyviä käsitteitä:

LUKU 5: SUUNNITTELU. Suunnitteluun liittyviä käsitteitä: LUKU 5: SUUNNITTELU Suunnitteluun liittyviä käsitteitä: abstrahointi (abstraction) epäolennaisten yksityiskohtien häivyttäminen, informaation piilottaminen (information hiding) rakenteen osan (moduulin)

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

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

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

Lisätiedot

Tilakaaviot, sekvenssikaaviot (Haikala, Märijärvi ss , )

Tilakaaviot, sekvenssikaaviot (Haikala, Märijärvi ss , ) Tilakaaviot, sekvenssikaaviot (Haikala, Märijärvi ss. 121-133, 135 141) Jari Ojasti Nokia email : jari.ojasti@nokia.com puh : 040 5926 312 Sisältö Sekvenssikaaviot ja tilakaaviot osana UML:ia Sekvenssikaaviot

Lisätiedot

Vesisika. metsiemme työmyyrä. http://www.billybear4kids.com/animal/whose-toes/capybara.jpg

Vesisika. metsiemme työmyyrä. http://www.billybear4kids.com/animal/whose-toes/capybara.jpg Vesisika metsiemme työmyyrä http://www.billybear4kids.com/animal/whose-toes/capybara.jpg Faktat Vesisika tykkää vedestä ja näyttää (ja kuulemma maistuu) hieman sialta. Käyttää myös nickiä kapybara. kapiÿva

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

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

Harjoitus 7: NCSS - Tilastollinen analyysi

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

Lisätiedot

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

Ohjelmistoarkkitehtuurit Kevät 2014

Ohjelmistoarkkitehtuurit Kevät 2014 Ohjelmistoarkkitehtuurit Kevät 2014 Samuel Lahtinen (Johannes Koskinen) http://www.cs.tut.fi/~ohar/ 1 Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit

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

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