1 582104 – Ohjelmistojen mallintaminen, mallintaminen ja UML.

Esitys aiheesta: "1 582104 – Ohjelmistojen mallintaminen, mallintaminen ja UML."— Esityksen transkriptio:

1 1 582104 – Ohjelmistojen mallintaminen, mallintaminen ja UML

2 Mallintaminen ja UML (Ch 2.) Ohjelmistojen mallintamisesta ja kuvaamisesta Strukturoitu mallinnus –Tietovuo- ja ER-kaaviot Oliomallinnus ja UML –Luokkakaaviot –Käyttötapauskaaviot –Sekvenssikaaviot 2

3 Mallintamisesta ja kuvaamisesta Ohjelmistotuotannossa on kyse mallintamisesta –Toisaalta ohjelmiston käsittelemää liiketoimintaa –Toisaalta ohjelmiston sisäistä rakennetta –Näiden tulisi vastata toisiaan Tietojärjestelmän kehittäminen on yhteistyötä –Ohjelmiston kehittäjien ja muiden sidosryhmien ymmärrettävä toisiaan –Projektiin tulevan uuden henkilön pystyttävä muodostamaan yleiskuva järjestelmästä Tämän vuoksi muodostamme järjestelmän mallin ja siihen perustuvia kuvauksia eri tarpeisiin 3

4 Mallit ja abstraktiot Malli: abstraktio jostain kohteesta Abstrahointi: asian ilmaiseminen tavalla, joka tuo esiin tietystä näkökulmasta katsottuna oleellisen ja kätkee tarpeettomat yksityiskohdat –abstraktio on abstrahoinnin tulos, siis tietystä näkökulmasta katsottuna oleellisia asioita sisältävä kuvaus kohteesta Ohjelmiston malli: abstraktio ohjelmistosta (näkemys, kuvaus) 4

5 Mallinnuskielet Mallintamiseen tarvitaan kieli Voidaan käyttää luonnollista kieltä (suomea) Suosittua on käyttää visuaalista kieltä (UML) –Vaatimusmäärittely- ja suunnitteluvaiheessa –Kaavio itsessään on vain harvoin riittävä, lisäksi tarvitaan sanallista selostusta 5

6 Formaalit menetelmät Formaalit menetelmät (Z, B method, Alloy) –Perustuvat matematiikkaan, logiikkaan –Ideana mahdollistaa automaattinen päättely, mallin ominaisuuksien todistaminen –Käytössä joillakin erityisalueilla, kuten protokollien tai mikropiirien suunnitteleminen –Suosiota vähentää tarvittavan koulutuksen määrä Myös itse ohjelma on malli, jota voidaan lisäksi koneellisesti suorittaa 6

7 Ohjelma itsessään on malli Tietojenkäsittelytehtävän suorituksen malli ohjelmointikielen käsittein esitettynä Suoritettava malli: ohjelman sisältää kaiken suorituksen kannalta tarpeellisen tiedon Ohjelmakoodiin (=mallin esitys) voi sisältyä myös suorituksen kannalta tarpeetonta informaatiota, kommentteja –Kuvaavat (mallintavat) ohjelmaa tai sen suoritusta –Ollakseen hyödyllisiä tulisi olla korkeammalla abstraktiotasolla kuin ohjelmakoodi 7

8 Kommentit ohjelmakoodissa Esim. i=1; // i saa arvon 1 – hyödytön kommentti, sama abstraktiotaso Parempi: // muunnetaan eurohinnat dollareiksi for (int i=0; i<euros.length; i++) { dollars[i] = ExchangeRate*euros[i]; } 8

9 Kommenttien käyttäminen mallintamiseen Ohjelmakommenttien tarjoamat abstraktiot ohjelmasta eivät perustu mihinkään yhtenäiseen käsitteistöön, vaan ovat ohjelmoijan vapaasti muodostettavissa –eritasoisia –taso ei mitenkään näy –esitetään luonnollisella kielellä, dokumentointijärjestelmä (esim. JavaDoc) voi asettaa jotain syntaktisia ehtoja 9

10 Abstraktion tasot Tietojenkäsittelytieteessä puhutaan usein abstraktiotasoista (levels of abstraction) –eri tasoilla on oma kiinnitetty käsitteistönsä, johon kyseisen tason mallit perustuvat –sama kohde mallinnetaan kullakin tasolla eri käsittein –'ylempi' taso suhteellisesti abstraktimpi ja 'alempi' konkreettisempi 10

11 Ohjelman annotaatiot Ohjelman annotaatiot ovat kommenttien kaltaisia, mutta formaalimmin määriteltyjä Esim @Identity int id; Määrittelee, että kenttä id toimii olion identiteettinä –Identiteetin käsite puolestaan määritellään annotaatiota hyödyntävässä paikassa Annotaatiot toimivat usein samalla tai samankaltaisella abstraktion tasolla (separation of concerns) 11

12 Käsitteistö Abstraktiotasoon liittyvä käsitteistö muodostaa perustan tason mukaisen abstraktion muodostamiselle. Käsitteistö on suunnittelun ja ajattelun apuväline Ohjelmat ovat keinotekoisia kuten myös niiden mallinnuksessa käytettävät käsitteet. Uusia käsitejärjestelmiä syntyy jatkuvasti. Ei voida yleisesti osoittaa, että jokin kattava käsitteistö olisi toista parempi –joitain puutteita käsitejärjestelmissä toki on osoitettavissa. 12

13 Luonnollisen kielen käyttäminen mallinnuksessa Esimerkki: sanaston (glossary) laatiminen Kielenkäytössä esiintyy synonyymejä ja homonyymejä –Synonyymi – kaksi eri sanaa tarkoittavat samaa –Homonyymi – kaksi samaa sanaa erilaisin tarkoituksin Kohdealueen asiantuntija pystyy helposti ymmärtämään asiayhteydestä tarkoitetun asian Tietojärjestelmän toteuttaja on vain harvoin kohdealueen asiantuntija 13

14 Sanaston laatiminen Luettelo organisaation toiminnan kannalta keskeisistä käsitteistä ja niiden määritelmistä Voidaan esittää vaihtelevin abstraktiotasoin –Koko organisaatiolle –Kullekin osa-alueelle erikseen tarkemmin Auttaa muiden mallien laatimisessa –Luokkamallin olioluokkien löytäminen Olennaista käsitteistön selkeys ja ristiriidattomuus 14

15 Esimerkki sanastosta [Kurssikirja, s. 206-207] 15 TermDefinition and Explanations ad advertisement A unique piece of creative that may be broadcast, screened, published or otherwise exposed any number of times. Each ad exposure by a media outlet is known in the AEM system as an ad instance. advertisement ad instanceA particular occurrence of an ad, i.e. each incidence of an ad broadcast, screening or publication. productA merchandise or service that may be advertised. Products may be categorized (i.e. a product can belong to a category of products). Categories are classifications of products as envisaged by AEM. The AEM system supports a hierarchical grouping of categories with an unlimited number of levels in the hierarchy. Products may only be categorized at the lowest level of the category hierarchy.

16 Abstraktiotasot ja näkökulmat Ohjelmistot muodostuvat ajan myötä laajoiksi, sisältävät runsaasti yksityiskohtia Yksityiskohdat ovat tärkeitä, mutta häiritsevät kokonaisuuden hahmottamista Kehittäjillä ja muilla sidosryhmillä erilaisia tarpeita eri tilanteissa ja ohjelmistoprosessin eri vaiheissa 16

17 Abstraktiotasot ja näkökulmat Tarvitaan kuvauksia eri abstraktiotasoilla –järjestelmän rajaus  –järjestelmän yleisarkkitehtuuri  –osajärjestelmien yksityiskohtaiset kuvaukset  –ohjelmakoodi.. ja eri näkökulmista –Kruchtenin 4+1-malli jakaa näkökulmiin Looginen näkökulma Prosessinäkökulma Toteutusnäkymä Fyysinen näkymä.. Jotka yhdessä muodostavat käyttötapaukset 17

18 Strukturoitu mallinnus Strukturoidun mallinnuksen taustalla on strukturoitu (eli rakenteinen) ohjelmointi Rakenteisessa ohjelmoinnissa silmukat ja if-lauseet toteutetaan kielen antamina kontrollirakenteina –Go to-komentoa ei suvaita [E. Dijkstra (March 1968). Go To Statement Considered Harmful. Comm. of the ACM 11 (3): 147–148] Ohjelma jaetaan top-down –menetelmällä osiin Ilmentää monoliittista, proseduraalista perusluonnetta Keskeiset visuaaliset kuvaustekniikat –Tietovuokaaviot (data flow diagram, DFD) –Käsitekaaviot (entity-relationship diagram, ER) –Rakennekaaviot (structure chart) 18

19 Tietovuokaaviot Data flow diagrams, DFD Historiallisesti käytetyin kuvaustekniikka Järjestelmän toiminnallinen ositus Epäyhteensopivuus oliomallinnuksen kanssa aiheuttanut suosion hiipumisen 19

20 Yhteys- eli sidosryhmäkaavio Rajaa järjestelmän suhteessa toimintaympäristöön Kaavioelementit –Yksi koko järjestelmää kuvaava prosessisymboli –Joukko ulkoisia tahoja (edustavat mm. järjestelmän sidosryhmiä ja muita, ulkoisia tietojärjestelmiä) –Joukko tietovuosymboleita em. välillä 20