Kurssin ensisijaisena materiaalina käytetään Matti Luukkaisen ja Harri Laineen Ohjelmistojen mallintaminen-luentomonistetta, sekä luentokalvoja joita lisätään tänne kurssin edetessä. Luentomoniste löytyy tämän linkin takaa.

Opiskelun tukena voi käyttää esim. seuraavia kirjoja (kurssilla pärjää hyvin myös ilman kirjaa):

• Craig Larman: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Kolmas painos.
• Martin Fowler: UML Distilled: A Brief Guide to the Standard Object Modeling Language. Kolmas painos.

Verkosta löytyy paljon vaihtelevatasoista UML-materiaalia.

• Larmanin kirjan luvut 2, 5 ja 6 löytyvät täältä
• Allen Holub's UML Quick Reference on kompakti tiivistelmä tärkeimpien UML-kaavioiden käytöstä

Luennoilla on puhuttu UML:n lisäksi hieman testaamisesta. Verkosta löytyy paljon materiaalia testaamiseen liittyen, alla muutamia linkkejä.

• Design For Testability
• Introduction to Test Driven Development
• Why you fail with TDD

Luentokalvot

• Yleistä (2.8.): ODP PDF
• Johdanto (2.8.): ODP PDF
• Vaatimusmäärittely ja käyttötapaukset (2.8., 4.8.): ODP PDF
  • Luennolla mainittu Alistair Cockburnin käyttötapausmalli PDF
• Luokka- ja oliokaaviot (4.8.): ODP PDF
• Luokka- ja oliokaaviot jatkuu (4.8. ja 9.8.): ODP PDF
• Yksikkötestaamisesta ja TDD:stä (9.8. ja 11.8.): ODP PDF
• Torstain 11.8. luennolla pariohjelmointina luotu verkkokauppaesimerkki (NetBeans-projekti): ZIP
• Luokka- ja oliokaaviot jatkuu (9.8.  ja 16.8.): ODP PDF
• Olioiden yhteistyön mallintaminen: sekvenssikaavio ja kommunikaatiokaavio (9.8. ja 16.8.): ODP PDF
• Takaisinmallinnus sekvenssikaavioiden avulla, yleistäminen ja erikoistaminen, rajapinnat ja oliosuunnittelun periaatteita (16.8. ja 18.8.): ODP PDF 
• Lisää oliosuunnittelusta ja sananen oliomenetelmistä (18.8.): ODP PDF
• Refaktoroinnista ja arkkitehtuurista (18.8., 23.8. ja 25.8.): ODP PDF
• Ohjelmistojen mallintamisen ja tietokantojen perusteet (23.8.): PDF
• Kertausta ja hieman muuta (25.8.): ODP PDF
   

Laskuharjoitustehtävät

• Harjoitukset osa 1 (tehtävä 5.8. mennessä)
• Harjoitukset osa 2 (tehtävä 12.8. mennessä) - Ratkaisuhahmotelmia
• Harjoitukset osa 3 (tehtävä 19.8. mennessä) - Ratkaisuhahmotelmia
• Harjoitukset osa 4 (tehtävä 26.8. mennessä) - Ratkaisuhahmotelmia
• Harjoitukset osa 5 (tehtävä 2.9. mennessä) - Ratkaisuhahmotelmia "kenraaliharjoituksen" muutamaan tehtävään

Laskuharjoituksissa läpikäydyt kalvot

• Osa 1
• Osa 2 
• Osa 3
• Osa 4
• 16.8.2011 järjestetty erilliskoe

Usein kysyttyjä kysymyksiä, kurssilta kuultua palautetta sekä vastapalautetta

• Olisi mukavaa jos palaute (ja vastapalaute) olisi julkista!
  • Arto: Olisi pitänyt ajatella aiemmin, mainio ajatus!
• "Huh, onpas tässä paljon tekemistä"
  • Arto: Normaalilla kuusi (tai seitsemän) viikkoa kestävällä ohjelmistojen mallintaminen-kurssilla valitellaan samaa :). Nyt kurssi on tarkoitus suorittaa noin neljässä viikossa, luonnollisesti siten että kurssilta ei jätetä sisältöä pois -- avoimessa yliopistossa suoritetut opinnothan hyväksytään normaaleina tietojenkäsittelytieteen opintoina.
    Uskon itse että ainakin käsiteanalyysitehtävät tuntuvat työläiltä, jo pelkästään luettavan tekstin määrän takia -- on aina paljon mukavampaa laittaa sormet heti saveen ja alkaa tekemään. Lisää haastetta kurssille tuo myös se, että kesällä ohjelmointikursseille osallistumisesta (tai ohjelmoinnista yleensäottaen) saattaa olla helposti muutama kuukausi, vaikka käytännössä kurssilla pohditaan ohjelmien rakentumista ja niiden suorituksen kuvaamista. Kuulen mielelläni lisää asioista jotka tuntuvat työläiltä.
    Jos jotkut tehtävät ovat liian vaikean tuntuisia (ei siis työläitä, vaan vaikeita), kuulen siitä myös hyvin mielelläni.
• Seise: Huh, onpas paljon tekemistä laskareissa, kiirettä pitää eikä oikein ehdi käydä kaikkea läpi!
  • Arto: Sori! Koitan saada ensi kurssille 3 tuntia kestävät laskariryhmät -- en juurikaan pystynyt vaikuttamaan tämän kurssin järjestelyihin. Kolmen tunnin laskariryhmissä ehtii treenaamaan mallinnusta myös ryhmässä, joka itsessään on mainio harjoite.
• Testaustehtävät on mukavia!
  • Arto: Kiitti! Testien kirjoittaminen ennen koodin kirjoittamista on myös mainio tapa treenata ohjelman pilkkomista pieniin osiin. Hajoita ja hallitse!
    • ...mutta ohjelmointitaitoni taitavat olla liian huteralla pohjalla -- en siis viitsi lähteä tekemään niitä.
      • Arto: Höh :(. Pyrin löytämään sopivan tasapainon kurssille. Käy vastaamassa kysymykseen "Olisiko kurssin alussa pitänyt olla enemmän ohjelmointitehtäviä?"  tämän linkin takana.
• Seise: Eräs opiskelijoista näytti laskareissa tällaisen työkalun sekvenssikaavioiden piirtämiseen: http://www.websequencediagrams.com/
  • Arto: Asiaa, kerron luennolla (nyt löytyy täältäkin!). Edit: Myös Diagramly (http://www.diagram.ly) ja LucidChart (http://www.lucidchart.com) vaikuttavat mielenkiintoisilta.
• Tehtävänannot olivat hieman epäselviä kolmoslaskareissa, kurssimateriaalia ei löytynyt kurssin web-sivuilta kunnolla.
  • Arto: Pahoittelut! Lisäsin "Luentomoniste löytyy tämän linkin takaa."-tekstin luentomateriaalin mainitsevaan kappaleeseen.
• Kolmoslaskarien tehtävässä kaksi sanamuoto oli hieman epäselvä: "Kuvaa" ja "Kuvaile" ovat eri asioita.
  • Arto: Epäilen että tämä liittyi ainakin osittain tuohon edelliseen kohtaan, eli kurssimateriaalia ei ollut löytynyt. Hain termit wiktionarystä: Kuvaa ja Kuvailla (termiä "Kuvaile" ei löytynyt suoraan), enkä ole ihan varma vieläkään että "Kuvaile" olisi parempi. Tehtävien teko ei ole aina helppoa, tsemppaan! :).
• Testauksesta pitäisi puhua muillakin kursseilla, erityisesti ohjelmointikurssilla. Tuntuu oudolta että ensimmäiset askeleet testaukseen käydään ohjelmistojen mallintaminen-nimisellä kurssilla.
  • Arto: Olen ehdottomasti samaa mieltä, haasteena tässä lienee se, että kukin luennoitsija ja kurssin vastuuhenkilö tekee ohjelmointikurssista hieman omannäköisensä. Tietojenkäsittelytieteen laitoksen henkilökunnan voi hieman kärjistäen jakaa kahteen ryhmään: Algoritmeja ja pieniä ohjelmia painottaviin, ja ohjelmistojen rakenteen ja olioiden yhteistyön ymmärtämistä painottaviin. Algoritmikot yleensä todistavat ohjelmansa aiemmin jo matemaattisesti, eivätkä pidä testausta niin oleellisena.  Heille on myös hyvin yleistä se, että toteutetaan vain joku yksi erillinen asia -- algoritmi, jolloin ns. ison järjestelmän yhtenäinen toiminta ei ole oleellisessa roolissa.  Ohjelmistoja ja järjestelmän rakennetta painottavat taas taitavat ajatella ohjelmiston elinkaarta pidempänä jatkumona, jolloin ylläpidettävyys ja testattavuus on isommassa roolissa. Tällä kurssillakin tutuksi tulleet oliosuunnittelun periaatteet, sekä tietenkin abstraktiot ja testaaminen, ovat hyvin oleellisia.  Luennollakin on nähty että jos yhtä järjestelmän komponenttia muuttaa, voi joku erillinen -- komponenttia välillisesti käyttävä osa -- hajota samalla.  Automaattiset testit (ja järkevä ohjelmiston rakenne ;)) auttavat huomattavasti näiden virheiden huomaamisessa.
• Jos huomattava osa tietojenkäsittelijöistä päätyy jossain vaiheessa elämäänsä toteuttamaan isompia ohjelmistoja, miksi emme tutustuneet näihin asioihin perusohjelmointikursseilla?
  • Arto: kts. yllä.
• Aina puhutaan siitä että tieto ja toiminnallisuus pitäisi erottaa toisistaan, mitä tämä oikeastaan tarkoittaa?
  • Arto: Tiistaina 23.8. tulee aiheesta esimerkki :) -- Edit: Esimerkki ei mennyt ihan putkeen "pienen" demoefektin takia. Tarkoitus oli luoda sovellus, jossa käsitenalyysin tuotoksena saadut tallennettavat oliot kytketään tietokantaan ORM-rajapintaa käyttäen. Luennolla keskusteltiin mm. kerrostetusta arkkitehtuurista, esimerkiksi web-sovellukset rakennetaan usein siten, että käyttöliittymässä tehdyt pyynnöt menevät kontrollikerrokselle, kontrollikerros päättää mille palvelulle pyyntö kuuluu -- ja ohjaa pyynnön oikeaan suuntaan. Palvelut taas tietävät muunmuassa tallennuspalveluista (tietokantarajapinnoista) ja mahdollisista muista palveluista (esimerkiksi kolmannen osapuolen tarjoamat palvelut). Kukin kerros abstrahoi alla olevaa toimintaa, eikä käyttöliittymän tarvitse tietää muuta kuin osoitteet joihin pyynnöt lähetetään. Kontrollikerros taas tietää vain palveluiden rajapinnat -- ja palvelut taas tietävät niiden alla toimivat rajapinnat. Tieto kulkee tallennettavina olioina, ja toiminnallisuus on muunmuassa viestien välitystä ja erilaisia algoritmisia toimintoja. Pienimuotoinen -- ehkä jo hieman vanhentunut -- opas tietokantasovellusten tekemisen aloittamiseen JPA-tallennusrajapinnan avulla avulla löytyy tätä linkkiä klikkaamalla.
• Seise: Voiko rajapintaan liittyä toisia rajapintoja?
  • Arto: Rajapinta voi periä toisen rajapinnan (tai useamman rajapinnan), mutta rajapinnat itsessään eivät sisällä mitään muuta kuin metodimäärittelyt -- eli toiminnallisuuden hyvin abstraktin kuvauksen. Toisaalta, normaaleihin ja abstrakteihin luokkiin voi liittyä joukko rajapintoja, sillä normaalit ja abstraktit luokat voivat sisältää myös rakennemäärittelyjä.
• Seise: Jos rajapinta perii rajapinnan, ei kai siihen tule merkitä osallistumisrajoitteita?
  • Arto: Oikeassa olet, kun luokka (rajapintakin on luokka!) perii toisen luokan, ei osallistumisrajoitteita merkitä. Tämä johtuu siitä että perintään liittyvät rajoitteet ovat aina tiedossa. Lukijalle kysymys: Miksi näin on?