582101 Ohjelmistotekniikan menetelmt mallintaminen ja UML 1 Mallintaminen

582101 - Ohjelmistotekniikan menetelmät, mallintaminen ja UML 1

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

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

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 4

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 5

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 6

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 7

Esimerkki sanastosta Term Definition 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 instance A particular occurrence of an ad, i. e. each incidence of an ad broadcast, screening or publication. product A 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. [Kurssikirja, s. 206 -207] 8

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 9

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 10

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) 11

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

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ä 13

Olioperustaisuus • Olio toimii mallinnuksen perusyksikkönä eri abstraktiotasoilla – Järjestelmän rajaus, suunnittelu, ohjelmointi, suoritus. . • Järjestelmä koostuu joukosta olioita (object), jotka yhdessä tuottavat järjestelmän palvelut • Olio on kokonaisuus (entity), joka suorittaa omaan tietosisältöönsä perustuvia palveluita • Olio kapseloi omat tietonsa tarjoamiensa palveluiden kautta käytettäviksi • Oliolla on identiteetti (identity), joka pysyy vaikka olion tila (state) tai käyttäytyminen (behavior) muuttuisivat 14

Luokka • Samanrakenteiset oliot kuuluvat samaan luokkaan (class) • Eli ovat ko. luokan ilmentymiä (instance) • Pitäisikö määritellä luokat kirahvi ja leijona ? 15

Luokka ja olio public class Eläin { int eläin. Numero; String laji; Color väri; float paino; public Eläin(int numero, String laji, Color väri, float paino) { …. } public float get. Paino() { … } } Eläin leo. Leijona = new Eläin(…. ); Eläin kira. Kirahvi = new Eläin(…. . ); leo. Leijona. syö(kira. Kirahvi); 16

Unified Modeling Language (UML) • ”… ohjelmistojen, liiketoiminnan ja muiden järjestelmien spesifiointiin, visualisointiin, rakentamiseen ja dokumentointiin tarkoitettu kieli. ” [UML Specification 2003] • Alun perin yhdistelmä vanhemmista oliotekniikoista – OMT (Rumbaugh) + Booch + OOSE (Jacobson) • Kehitetty Rational Softwaren toimesta vuodesta 1996 lähtien • Nykyisin teollisuusstandardi • Useiden CASE-välineiden valinta • Sisältää kymmenkunta kaaviotyyppiä 17

UML: n kaaviotyypit [Wikipedia] 18

Omni. Graffle-työkalun kategoria UML Use Case 19

Omni. Graffle-työkalun kategoria UML General 20

Omni. Graffle-työkalun kategoria UML Sequence 21

UML: n malli- ja kaaviotyypit: rakennemalli • Ohjelman staattinen rakenne • Kaaviotyypit: – Luokkakaavio ja oliokaavio • Järjestelmän tietosisältö ja käytettävissä olevat luokkien tarjoamat palvelut • Käytössä määrittely- ja suunnittelutasolla – Toteutuskaaviot eli komponentti- ja sijoittelukaavio (component diagram, deployment diagram) • Ohjelmiston koostuminen komponenteista ja niiden suoritusaikainen sijoittuminen 22

Esimerkki: Ostoskori 23

UML: n malli- ja kaaviotyypit: käyttäytymismalli • Järjestelmän palvelut ja niiden toteuttaminen • Kaaviotyypit: – Käyttötapauskaavio (use case diagram) • Mitä järjestelmällä tehdään • Tekstuaaliset kuvaukset olennaisia – Vuorovaikutuskaaviot eli sekvenssi- (sequence) ja kommunikointikaavio (communication diagram • Palveluiden toteuttaminen olioiden välisenä yhteistyönä • Sekvenssikaavio korostaa palveluiden käyttämistä aikajärjestyksessä • Kommunikointikaavio korostaa olioiden kytkentöjä 24

Käyttötapaukset • Keskeisin tekniikka järjestelmän ulkoisesti havaittavien ominaisuuksien ja käyttäytymisen mallintamiseen määrittelytasolla UML: ssä • UML määrittelee käyttötapauskaavion, mutta kaaviotekniikkaa olennaisempaa on kunkin käyttötapauksen tekstuaalinen kuvaus • Käyttötapauksia voi kuvata eri tarkkuustasolla, mutta ne eivät muodosta varsinaista hierarkkista rakennetta 25

Käyttötapaus ja käyttäjä • Käyttötapaus (use case) – Looginen tavoitteellinen tehtäväkokonaisuus, jolla on lähtökohta ja lopputulos – Usein järjestelmälle asetettava toiminnallinen vaatimus • Käyttäjä (actor) – Rooli, jota järjestelmään liittyvä taho esittää – Usein ihminen, mutta voi olla myös ulkoinen järjestelmä – Toimii vuorovaikutteisesti järjestelmän kanssa 26

Käyttötapauksen tekstikuvaus • Sisältää tyypillisesti ainakin – Käyttötapaukseen liittyvät käyttäjät – Käyttötapauksen kulku askelittain • Usein myös: – Annettavat syötteet ja saatavat tulosteet / tulokset – Säännöt, vaatimukset, määrät – Suhteet muihin tapauksiin, erikois- ja poikkeustilanteet 27

Käyttötapausesimerkki: ostoskori 28

UML: vuorovaikutuskaaviot: sekvenssikaavio • Keskeisin tekniikka käyttäytymisen mallintamiseen suunnittelutasolla UML: ssä • Visualisoi olioiden välisen viestinvälityksen – Viesti (message) kuvataan nuolena oliosta toiseen – Kaaviossa aika kulkee ylhäältä alas, viestit merkitään aikajärjestykseen – Viesti aktivoi metodin (eli palvelun tai operaation) suorituksen vastaanottavassa oliossa – Aktivaatio (activation) kuvataan suorakaiteena olion elämänviivassa (lifeline) 29

Tärkeimmät sekvenssikaavion elementit • Kutsuja-olio kutsuu Kutsuttava-olion metodia nimeltä metodi. Kutsu() • Paksunnettu pystypalkki kuvaa aktivaatiota • Horisonaaliset viivat kuvaavat viestien kulkua 30

UML: malli- ja kaaviotyypit: tilanmuutosmalli (state change model) • Järjestelmän tilan mahdolliset muutokset – Aktiviteettikaavio (activity diagram) • Kontrollin kulku prosessissa tai olion operaatiossa • Sisältää ehtoja ja haaraumia – Tilakaavio (statechart diagram) • Olion tilamuutokset esitetään tilakoneena • Tapahtumat (event) laukaisevat tilasiirtymiä (state transition) ja • Tuottavat toimintoja (actions) 31