Ohjelmistotuotannon menetelmät Syksy 2003 Oliopohjainen suunnittelu (Sami Jantunen, LTY/TITE)

Esitys aiheesta: "Ohjelmistotuotannon menetelmät Syksy 2003 Oliopohjainen suunnittelu (Sami Jantunen, LTY/TITE)"— Esityksen transkriptio:

1 Ohjelmistotuotannon menetelmät Syksy 2003 Oliopohjainen suunnittelu (Sami Jantunen, LTY/TITE)

2 Ohjelma UML:n käyttö oliopohjaisessa suunnittelussa: 1. Yleistä Luettavaa Mallintamisesesta UML 2. Luokkakaavio Käyttö kehitystyön eri vaiheissa Kehitysprosessi Notaatio Esimerkkejä 3. Oliokaavio 4. Toiminnallinen mallinnus Vuorovaikutuskaavio vs. sekvenssikaavio

3 Luettavaa The Unified Modeling Language User Guide (Grady Booch, James Rumbaugh, Ivar Jacobson) The Rational Unified Process An Introduction, Second Edition (Philippe Kruchten) UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition ( Martin Fowler )

4 Luettavaa… Rational Unified Process

5 Mallintamisesta Malli on todellisuuden yksinkertaistus Mallinnamme, jotta ymmärrämme paremmin järjestelmän mitä kehitämme Ongelman ratkaisuun tarvitaan yleensä useita eri malleja Mallintaminen voi tapahtua usealla tarkkuustasolla 7±2 sääntö

6 Mistä hyvä malli muodostuu? Hyvän mallin tulee: käyttää standardi notaatiota olla helposti ymmärrettävissä asiakkaille ja käyttäjille auttaa ohjelmiston kehittäjiä ymmärtää järjestelmän piirteitä tarjota mahdollisuus abstraktointiin

7 UML määrittely UML (The Unified Modelling Language) on oliopohjaisen ohjelmiston mallintamiseen käytettävä graafinen kieli. Sitä käytetään: suunnittelutyön apuna suunnittelutyön analysoinnissa ja hyväksynnässä järjestelmän perusdokumentaationa UML ei ole metodologia

8 UML historiaa “The Metdhod Wars” 1980-1990 luvulla Kuvauskieliä oli monia. Notaatiot erilaisia, vaikkakin notaatioiden ilmaisuvoimat samankaltaiset. Rumbaugh (OMT) ja Booch (Booch) päättivät yhdistää voimansa 1994. Jacobson (Use Cases) liittyi joukkoon 1995,  three amigos UML standardointi aloitettiin1997 the Object Management Group (OMG):n toimesta

9 Näkymiä ratkaistavaan ongelmaan

10 Keskeisiä Design-kaavioita Järjestelmän staattinen kuvaus: Luokkakaavio (Class diagram) Oliokaavio (Object diagram) Järjestelmän toiminnallinen kuvaus: Sekvenssikaavio (Sequence diagram) Vuorovaikutuskaavio (Collaboration diagram)

11 Missä mennään? UML:n käyttö oliopohjaisessa suunnittelussa: 1. Yleistä Luettavaa Mallintamiseseta UML 2. Luokkakaavio Käyttö kehitystyön eri vaiheissa Kehitysprosessi Notaatio Esimerkkejä 3. Oliokaavio 4. Toiminnallinen mallinnus Vuorovaikutuskaavio vs. sekvenssikaavio

12 Luokkakaavio (Class diagram) Luokat (tiedon tyyppi) Attribuutit (luokan sisältämä tieto) Operaatiot (luokan tarjoama toiminnallisuus) Assosiaatiot (luokkien väliset yhteydet) Yleistys (luokkien hierarkkisuus) Kuvaa luokat ja niiden väliset suhteet Peruselementit:

13 Luokkakaavion käyttö eri mallinnusvaiheissa Domainmalli (Exploratory domain model): Kehitetään analyysivaiheessa, jotta ymmärrettäisiin järjestelmän toimintaympäristö paremmin Systeemin domainmalli (System domain model): Mallintaa ne toimialaan liittyvät piirteet, mitkä kehitettävä järjestelmä toteuttaa Systeemimalli (System model): Sisältää myös käyttöliittymään ja systeemiarkkitehtuuriin liittyvät luokat

14 Luokkakaavioiden erot ( Systeemin domainmalli vs. systeemimalli) Systeemin domainmallista puuttuu paljon luokkia, joita tarvitaa kokonaisen järjestelmän rakentamisessa Voi jopa sisältää vähemmän kuin puolet tarvittavista luokista Pitäisi kehittää riippumattomaksi spesifisistä käyttöliittymäluokista arkkitehtuuriluokista Täydellinen systeemimalli sisältää Systeemin domainmallin Käyttöliittymäluokat Arkkitehtuuriluokat Utilityluokat

15 Luokkakaavion kehitysprosessi: Suositeltava aktiviteettien järjestys 1. Identifioi kandidaattiluokat 2. Lisää assosiaatiot ja attribuutit 3. Löydä yleistettävät asiat 4. Määrittele luokkien vastuut 5. Määrittele operaatiot 6. Iteroi prosessia kunnes mallista tulee hyväksyttävä Lisää tai poista luokkia, assosiaatioita, attribuutteja, yleistyksiaä, vastuita tai operaatioita Identifioi rajapinnat Sovella design patterneja Ole järjestelmällinen, mutta älä mene liiallisuuksiin

16 Vaihe 1: Identifioi kandidaattiluokat Menetelmä domainmallin luokkien etsimiseen Tarkastele annettua materiaalia (esim. vaatimusmäärittely) Poimi substantiivit Eliminoi substantiivit jotka: Tarkoittavat samaa asiaa Kuvaa instansseja Ovat liian epämääräisiä Ovat kehitettävän järjestelmän kannalta tarpeettomia Kiinnitä huomiota domainmallin luokkiin, jotka kuvaavat erityyppisiä käyttäjiä

17 Vaihe 1: Identifioi kandidaattiluokat Luokkien tunnistamisesta Domainmallia tehdessä yleensä “löydät” luokkia Kun työskentelet käyttöliittymän tai ohjelmistoarkkitehtuurin parissa yleensä “keksit” luokkia Tarve ratkaista tietty suunnitteluongelma (Luokkien keksimistä saattaa tapahtua myös domainmallia tehdessä) Ota uudelleenkäyttö huomioon Frameworks Järjestelmän laajennennukset (System extensions) Samankaltaiset järjestelmät

18 Vaihe 1: Identifioi kandidaattiluokat Notaatio luokkien kuvaukseen Luokka kuvataan yksinkertaisimmillaan laatikkona, missä on luokan nimi sisällä Laatikossa voidaan kuvata myös attribuutit ja operaatiot Operaation täydellinen kuvaus on: operationName(parameterName: parameterType …): returnType

19 Vaihe 2: Lisää assosiaatiot ja attribuutit Prosessi assosiaatioiden ja attribuuttien tunnistukseen Aloita luokista mitkä ovat mielestäsi keskeisimmät ja tärkeimmät Päätä mitä itsestään selvää tietoa kukin luokka sisältää ja mihin muihin luokkiin sillä on assosiaatioita Suunnittele luokat tärkeysjärjestyksessä Vältä suurta assosiaatioiden ja attribuuttien määrää Järjestelmä on yksinkertaisempi jos se manipuloi pienempää tietomäärää

20 Vaihe 2: Lisää assosiaatiot ja attribuutit Ohjeita hyvien assosiaatioiden määrittelyyn Assosiaatio tulisi määritellä jos luokka: omistaa kontrolloi on kytketty liittyy on osa omistaa osina on jäsen, tai omistaa jäseninä muita luokkia mallissasi Muista määritellä olioiden mahdollinen lukumäärä assosiaation kumpaankin päähän Kuvaa assosiaatiot selkeästi

21 Vaihe 2: Lisää assosiaatiot ja attribuutit Notaatio assosiaation suunnan kuvaukseen Assosiaatiot ovat oletusarvoisesti kaksisuuntaisia On mahdollista rajoittaa assosiaatio yksisuuntaiseksi lisäämällä nuoli assosiaation päähän ** NoteDay

22 Vaihe 2: Lisää assosiaatiot ja attribuutit Notaatio assosioitujen luokkien lukumäärän määrittelyyn

23 Vaihe 2: Lisää assosiaatiot ja attribuutit Notaatio assosiaatioiden tarkempaan kuvaukseen

24 Vaihe 2: Lisää assosiaatiot ja attribuutit Assosiaatioiden analysointi ja validointi One-to-one Jokaista yritystä kohden on olemassa vain yksi johtoryhmä Johtoryhmä johtaa vain yhtä yritystä Yrityksellä täytyy aina olla johtoryhmä Johtoryhmä kuuluu aina tiettyyn yritykseen

25 Vaihe 2: Lisää assosiaatiot ja attribuutit Assosiaatioiden analysointi ja validointi Many-to-many Sihteeri voi työskennellä usealle johtajalle Johtajalla voi olla useita sihteerejä Sihteerit voi työskennellä “vuorotteluperiaatteella” (pools) Johtajilla voi olla sihteeriryhmiä Joillakin johtajilla ei ole yhtäkään sihteeriä

26 Vaihe 2: Lisää assosiaatiot ja attribuutit Monimutkaisempi esimerkki Varaus tehdään aina täsmälleen yhdelle matkustajalle Ei varausta jos ei matkustajaa varaus tehdään matkustajakohtaisesti Matkustajalla voi olla useita varauksia Voi olla, että matkustajalla ei ole varausta ollenkaan

27 Vaihe 2: Lisää assosiaatiot ja attribuutit Toiminnat (Actions) vs. assosisaatiot Yleinen virhe on kuvata toiminnat assosiaatioina * LibraryPatron borrow Loan borrowedDate dueDate returnedDate Huono, assosiaatiot ovat oikeastaan toimintoja **** * return CollectionItem * * LibraryPatronCollectionItem * * Parempi: borrow toiminto luo lainainstanssin. Loan ja return operaatio päivittää returnedDate attribuutin

28 Vaihe 2: Lisää assosiaatiot ja attribuutit Aggregaatio (Aggregation) Aggregaatiot ovat erikoistuneita assosiaatioita kuvaamaan luokan koostumista muista luokista Kokonaisuutta kuvaavaa puolta kutsutaan aggregaatiksi (aggregate) Aggregaatio kuvataan assosiaation päässä olevalla timantilla. **** ****** Region VehiclePart Country Vehicle

29 Vaihe 2: Lisää assosiaatiot ja attribuutit Milloin aggregaatiota käytetään? Nyrkkisääntö: Käytä aggregaatiota jos jokin seuraavista toteutuu: Luokat ovat osia aggregaatista Aggregaatti koostuu eri luokista Jos joku kontrolloi aggregaattia, se kontrolloi myös aggregaatin osia

30 Vaihe 2: Lisää assosiaatiot ja attribuutit Aggregaation hierarkia ** * WheelTransmissionEngineFrame DoorBodyPanelChassis Vehicle

31 Kooste on vahva aggregaatio Jos aggregaatti tuhotaan niin kaikki osatkin tuhotaan Kaksi vaihtoehtoista tapaa kuvata postiosoite: Vaihe 2: Lisää assosiaatiot ja attribuutit Kooste (Composition) ***** RoomBuilding

32 Vaihe 2: Lisää assosiaatiot ja attribuutit Assosiaatioluokat (Association classes) Joskus attribuutti joka liittyy kahteen eri luokkaan ei sijoitu hyvin kumpaakaan luokista Kummatkin alla olevista malleista kuvaa samaa asiaa: Registration grade StudentCourseSection ******* Registration grade StudentCourseSection **

33 Vaihe 2: Lisää assosiaatiot ja attribuutit Rekursiivinen assosiaatio (Recursive associations) On mahdollista, että luokalla on assosiaatio itsensä kanssa Course * isMutuallyExclusiveWith * * prerequisite successor *

34 Vaihe 2: Lisää assosiaatiot ja attribuutit Kvalifikaatio ( Qualification)

35 Vaihe 2: Lisää assosiaatiot ja attribuutit Vältä turhia one-to-one assosiaatioita Vältä tätä: Ennemmin näin

36 Vaihe 2: Lisää assosiaatiot ja attribuutit Attribuuttien identifiointi Etsi tietoa, mitä kunkin luokan on pakko ylläpitää Useat substantiiveistä, mitä ei hyväksytty luokiksi ovat potentiaalisia attribuutteja Attribuutin tulisi yleensä sisältää yksinkertainen arvo Esim. merkkijono, numero

37 Vaihe 2: Lisää assosiaatiot ja attribuutit Ohjeita atribuuttien määrittelyyn Vältä duplikaatteja Jos osa luokan attribuuteista muodostaa kiintän ryhmän, muodosta näistä attribuuteista oma luokkansa. **** * Person name addresses Person name street1 municipality1 provOrState1 country1 postalCode1 street2 municipality2 provOrState2 country2 postalCode2 Person name Address street municipality provOrState country postalcode type Monikossa oleva attribuutti on huono Huono. Liian monta attribuuttia. Ei mahdollista lisätä osoitteita Hyvä ratkaisu. Voidaan määritellä erikseen onko kyseessä koti-, työ, … osoite

38 Vaihe 3: Löydä yleistettävät asiat Yleistyksien (Generalization) ja rajapintojen (Interface) määrittely Kaksi tapaa määritellä yleistykset: bottom-up Kokoa samankaltaiset luokat luomalla niille isäluokka top-down Etsi yleiset luokat ensiksi ja peri niistä erityistapaukset Luo rajapinta isäluokan sijasta jos: Luokilla on muutama yhteinen operaatio, mutta ovat muuten hyvin erilaisia Yhdellä tai useammalla luokalla on jo isäluokka Luokasta saattaa jo olla erilaisia toteutuksia

39 Vaihe 3: Löydä yleistettävät asiat Yleistyksen notaatio

40 Vaihe 3: Löydä yleistettävät asiat Rajapinnat (Interfaces) Rajapinta kuvaa olioiden ulospäin näkyvän toiminnallisuuden. Rajapinta muistuttaa luokkaa sillä poikkeuksella, että sillä ei ole omia muuttujia eikä toteutettuja metodeja. «interface» Cashier withdraw deposit Machine ATMEmployee Person Machine ATMEmployee Person Cashier

41 Vaihe 3: Löydä yleistettävät asiat Älä yleistä liikaa! rockbluesclassicaljazzmusic video videoaudio RecordingCategory * subcategory description Recording * hasCategory subcategory :RecordingCategory 9th Symphony :Recording Let it be :Recording The Beatles Beethoven title artist Virheellinen luokkahierarkia. Nämä ovat pikemminkin olioita Parannettu luokka- ja instanssikaavio

42 Vaihe 3: Löydä yleistettävät asiat Vältä tilanteita, missä olio joutuu vaihtamaan luokkaansa

43 Vaihe 4: Määrittele luokkien vastuut Luokkien vastuut Vastuu on jotain, mitä järjestelmän kuuluu tehdä. Kukin toiminnallinen vaatimus pitää pystyä kytkemään yhteen luokista Kaikki luokalle annetut vastuut pitäisi selkeästi liittyä toisiinsa. Pilko luokka jos sille tulee liikaa vastuita. Luokka on todennäköisesti käyttökelvoton jos sille ei ole määritelty yhtään vastuita. Uusi luokka pitää todennäköisesti luoda jos jotain vastuuta ei voi määrittää olemassa olevalle luokalle. Vastuiden määrittely Suorita use case analyysi Etsi verbejä ja substantiivejä, jotka kuvaavat toiminnallisuutta

44 Vaihe 4: Määrittele luokkien vastuut Vastuiden kategorioita Attribuuttien luku ja kirjoitus Uusien instanssien luonti ja alustus Tietokannasta luku ja tietokantaan talletus Instanssien tuhoaminen Assosiaatiolinkkien luonti ja tuhoaminen Kopiointi, konvertointi, muuntaminen, lähettäminen,… Numeerisen tuloksen laskenta Navigointi ja etsintä Muu erikoistunut työ

45 Vaihe 4: Määrittele luokkien vastuut Esimerkki (vastuut) Uuden reittilennon luonti Lennon etsintä Lennon attribuuttien muokkaus Tietyn lennon luonti Matkustajan bookkaus Bookkauksen peruminen * supervisor RegularFlight time flightNumber * ****** PassengerRole ****** ****** ****** SpecificFlight date ****** ****** Person name idNumber 0..2 EmployeeRole jobFunction Booking seatNumber PersonRole Airline

46 Vaihe 5: Määrittele Operaatiot Operaatioiden määrittely Operaatioita tarvitaan kunkin luokan vastuiden toteutukseen Yhtä vastuuta kohden saattaa olla useita operaatioita Keskeisimm ä t vastuita toteuttavista operaatioista julistetaan yleens ä public - määreellä Ne metodit jotka vain auttavat vastuun toteutuksessa pit ä isi julistaa niin privaatiksi kuin mahdollista

47 Luokkamallin täydentäminen tekstuaalisesti Tarkentavat tekstit ja muut kaaviot Upota kaaviosi dokumenttiin Teksti voi kuvat järjestelmään liittyviä näkökulmia valitsemallasi notaatiolla Painota ja tarkenna oleellisia ominaisuuksia ja perustele Viestit: Viesti (Note) kuvataan UML-kaavioon upotettavana pienenä tekstilaatikkona. Toimii samoin kuin kommentointi koodatessa

48 Luokkakaavion protoilu paperilla Kirjoita luokkien nimiä korteille sitä mukaan kun keksit niitä Kun löydät attribuutteja ja vastuita kirjoita ne luokkaan liittyvään korttiin Jos tila loppuu kortista, harkitse luokan pilkkomista: Siirtele kortteja taululla ympäriinsä ja yritä muodostaa niistä luokkamalli Yhdistä kortit assosiaatioita ja yleistystä kuvaavilla viivoilla

49 Esimerkki: Luokkamalli perhesuhteiden kuvaukseen Ongelmat: Henkilöllä on oltava 2 vanhempaa Ei ota kunnolla huomioon avioliittoa

50 Mahdollisia ratkaisuja edelliseen esimerkkiin… Person name placeOfBirth dateOfBirth placeOfDeath dateOfDeath Union placeOfMarriage dateOfMarriage dateOfDivorce parents 0..1 child * **** * partner 0..2 sex Person name placeOfBirth dateOfBirth placeOfDeath dateOfDeath Union placeOfMarriage dateOfMarriage dateOfDivorce parents 0..1 child * *** malePartner *0..1 child ** femalePartner 0..1 WomanMan {partner->forAll(p1,p2 | p1 <> p2 implies p1.sex <> p2.sex)}

51 Missä mennään? UML:n käyttö oliopohjaisessa suunnittelussa: 1. Yleistä Luettavaa Mallintamiseseta UML 2. Luokkakaavio Käyttö kehitystyön eri vaiheissa Kehitysprosessi Notaatio Esimerkkejä 3. Oliokaavio 4. Toiminnallinen mallinnus Vuorovaikutuskaavio vs. sekvenssikaavio

52 Oliokaaviot (Object Diagram) Carla:Employee Ali:Employee Wayne:Employee OOCorp:Company OOCorp's Board: UML inc's Board UML inc:Company Pat:Employee Terry:Employee Peruselementit: Oliot (luokan instanssi) Linkit (assosiaation instanssi) “snapshot” tietyllä hetkellä luokkakaavion mukaisesti instantioiduista olioista

53 Assosiaatiot vs. yleistys oliokaavioissa Assosiaatiot kuvaavat instanssien välisiä ajonaikaisia suhteita. oliokaaviossa luokista johdetut oliot kytketään assosiaation mukaisesti linkeillä Yleistys kuvaa luokkien välistä suhdetta luokkakaaviossa Ne eivät ole näkyvissä oliokaavioissa. Olio käsitetään myös kaikkien isäluokkiensakin instanssiksi

54 Missä mennään? UML:n käyttö oliopohjaisessa suunnittelussa: 1. Yleistä Luettavaa Mallintamiseseta UML 2. Luokkakaavio Käyttö kehitystyön eri vaiheissa Kehitysprosessi Notaatio Esimerkkejä 3. Oliokaavio 4. Toiminnallinen mallinnus Vuorovaikutuskaavio vs. sekvenssikaavio

55 UML Design diagrammeja vuorovaikutuksen kuvaamiseen Kaksi vaihtoehtoista tapaa: Vuorovaikutuskaavio (collaboration diagram) Rakenteellinen painotus Sekvenssikaavio (sequence diagram) Ajallinen painotus

56 Ohjeita toiminnallisuuden kuvaukseen Valitse mitä haluat painottaa (rakenne vs. aika) Näytä vain ne tiedot mitkä auttavat ymmärtämään mallinnettavaa vuorovaikutusta Näytä viesteistä vain ne tiedot mitkä auttavat ymmärtämään mallinnettavaa vuorovaikutusta