UML-kuvauskielten käyttö ohjelmistojen vaatimusmäärittelyissä

Save this PDF as:
 WORD  PNG  TXT  JPG

Koko: px
Aloita esitys sivulta:

Download "UML-kuvauskielten käyttö ohjelmistojen vaatimusmäärittelyissä"

Transkriptio

1 UML-kuvauskielten käyttö ohjelmistojen vaatimusmäärittelyissä Hannu A Heikkinen Helsinki HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 ii Sisältö 1 Johdanto 1 2 Ohjelmistojen vaatimusmäärittely 1 3 UML 2.0 vaatimusmäärittelyissä UML:n historia Muutoksia UML 1 versioista 2 versioon vaatimusmäärittelyn näkökulmasta Näkymät ja kaaviotyypit Käyttötapauskaavio Käyttötapauskaavio ja ei-toiminnalliset vaatimukset Aktiviteettikaaviot UML vaatimusten analysoinnissa 11 5 UML ja toiminnalliset vaatimukset 11 6 UML ja ei-toiminnalliset vaatimukset 11 7 Yhteenveto 11 Lähteet 12

3 1 1 Johdanto UML-kuvauskielten perhe on ollut oliopohjaisen ohjelmistotuotannon kulmakivi. Kieliä on käytetty lähinnä oliopohjaisessa suunnittelussa, mutta niitä on mahdollista käyttää myös muissa oliopohjaisen ohjelmistotuotannon työvaiheissa. Vaatimusmäärittely on merkittävä vaihe suunnitelmallisessa ohjelmistoprosessissa. Mitä aikaisemmin virhe havaitaan ohjelmiston määrittelyssä sitä edullisempaa sen korjaaminen on. Tämän vuoksi vaatimusmäärittelyn menetelmien kehittäminen on erityisen kannattavaa. Opinnäytteen tavoitteena on perehtyä UML-kuvauskielen käyttöön vaatimusmäärittelyn menetelmänä kirjallisuudessa esitettyjen tulosten avulla ja selvittää mitä UML:n avulla kannattaa ja on mahdollista toteuttaa vaatimusmäärittelyssä. 2 Ohjelmistojen vaatimusmäärittely * * * 3 UML 2.0 vaatimusmäärittelyissä UML (Unified Modeling Language) on kieli, jolla voidaan visualisoida ohjelmistojen toimintaa, sisältöjä ja ohjelmistoa suorittavaa järjestelmää [Obj07]. UML on yleiskäyttöinen kieli, joka tarkoittaa sitä, että sitä voidaan käyttää kaikilla olemassa olevilla toteutusympäristöillä ja sovellusalueilla sekä sovellustyypeillä. Toteutusympäristöllä tarkoitetaan alustan ja ohjelmointikielen yhdistelmää, kuten J2EE tai.net. Sovellusalueilla tarkoitetaan sitä olosuhdeympäristöä, jossa ohjelmistoa käytetään kuten terveydenhoito, talous, tietoliikenne. Sovellustyypillä tarkoitetaan ohjelmiston lajia, joita ovat informaatiojärjestelmä, hallintajärjestelmä, muunnosjärjestelmä, kytkentäjärjestelmä ja työkaluohjelmisto [BRA02]. UML-kaavioita käsiteltäessä MOF (Meta-Object Facility) eli UML-kielen metamalli toimii säännöstönä kaavioiden piirtämiselle. XMI (XML Metadata Interchange) on XML:ään perustuva formaatti UMLkielen metadatan siirtämiseen. UML on standardin kaltainen tapa kuvata toteutettavaa järjestelmää oliopohjaisessa ohjelmistotuotannossa [Lan02]. UML:n yleiskäyttöisyys ja laaja hyväksyntä pitävät sen

4 2 toistaiseksi suosittuna, joskaan ei ainoana visualisointiin soveltuvana tapana. Tämä tutkielman kappale keskittyy UML:n ominaisuuksiin, joita käytetään ohjelmistojen vaatimusmäärittelyssä. Erityisesti tarkastellaan UML:n 2 version uusia ominaisuuksia. 3.1 UML:n historia UML:n kehitys alkoi vuonna 1994, jolloin Grady Booch ja James Rumbaugh aloittivat työn yhdistääkseen aikaisemmin omilla tahoillaan kehittelemiänsä oliomallinnustekniikoita. Vuonna 1995 Ivar Jacobson toi mukaan oman menetelmänsä. Menetelmien yhdistäminen oli järkevää kolmesta syystä. Menetelmät olivat jo kehittymässä samaan suuntaan, käsitteiden yhdenmukaistaminen toisi vakautta ja helpottaisi ohjelmistoprojektien yhteensovittamista. Menetelmien yhdessä kehittäminen toi ratkaisuja ongelmiin, joita ei aikaisemmin kyetty ratkaisemaan yksin. Vuonna 1996 OMG (Object Management Group) julkaisi ehdotuksen UML 1.0 versioksi, jonka pohjalta UML on kehittynyt lukuisten yhteisöjen panoksen tukemana [DJA01]. UML:n versioista tällä hetkellä 2.0:n ominaisuudet ovat saaneet riittävän työkaluohjelmistojen tuen. UML:n tämän hetkinen virallinen versio on 2.1.1, joka julkaistiin elokuussa Kehitystyö versiota varten on käynnissä. 3.2 Muutoksia UML 1 versioista 2 versioon vaatimusmäärittelyn näkökulmasta. UML 2.0 versiossa tuli mahdolliseksi asettaa kaavio sisältämään toinen toisiaan. Periaatteessa mikä tahansa UML:n kaaviokomponentti voi toimia säiliönä (classifier) toiselle kaaviolle. UML:ää käyttävät työkaluohjelmistot kykenevät, metamalliin perustuen, tarjoamaan toiminnallisuuden, jossa kaaviot ovat linkitetty toisiinsa sisäkkäisesti [OMG08]. Tämä tarjoaa vaatimusmäärittelylle käytännöllisen tavan yhdistää käyttötapauskaavioihin muita UML:n kaavioita ja antaa käyttötapauskaaviolle mahdollisuuden sisältyä toiseen komponenttiin. Vaatimusmäärittelyn kannalta esimerkiksi kaavioon kuvattu käyttötapaus voi linkittää itseensä aktiviteettikaavioina kuvattuja liiketoimintaan liittyviä logiikoita. Käyttötapauskaaviossa teknisenä muutoksena on suhteiden kuvauksessa käytettyjen nimien muutos [EPL04]. Merkinnät "uses" ja "extends" ovat muutettu merkinnöiksi "include" ja "extend". Täysin uusi suhteen tyyppi on "generalize". Muutokset näissä suhdemerkinnöissä on herättänyt kritiikkiä. Merkintöjen monitulkintaisuus

5 3 on aiheuttanut epätietoisuutta järjestelmien kehittäjille [AlI04]. Aktiviteettikaaviolla kuvataan ohjelmiston dynaamista toimintaa. UML 2 mukana aktiviteettikaavioon on tullut uusia mallinnuselementtejä. Näitä ovat aktiviteetin aloitus- ja jälkiehtoa kuvaavat merkit (Pin) ja kutsun välittämistä kuvaavien lähetys ja vastaanotto komponentit. 3.3 Näkymät ja kaaviotyypit Ohjelmiston määrittely ei onnistu yhdellä kaaviolla eikä useankaan UML:ssä käytetyn kaavion esittäminen sellaisenaan toisi kuvaukseen riittävää kattavuutta. Kruchtenin 1995 esittelemä "4+1-malli" esittelee tietojärjestelmien kehitykseen näkökulmapohjaisen lähestymistavan [Kru95]. 4+1-mallissa on alun perin esitelty oma UML:stä poikkeava notaatio, mutta periaate on sama. Mallissa painotetaan tarkastelemaan kehitettävää järjestelmää eri näkökulmista, jotta projektia kuvataan kaikkien sidosryhmien kannalta. 4+1-mallin näkökulmat ovat looginen-, prosessi-, fyysinen- ja kehitysnäkökulma. Lisäksi 4+1-mallissa on skenaarionäkökulma. Skenaarionäkökulmassa kuvataan järjestelmää käytännön käyttötapausesimerkkien kautta. UML:n kehittäjät ottivat 4+1- mallin UML:ään. Näkökulma asettaa UML-kaavion tarkastelulle lähtökohdan ja helpottaa siten sen tulkintaa. Näkökulmia ovat käyttötapausnäkymä (use-case view), looginen näkymä (logical view), toteutusnäkymä (implementation view), prosessinäkymä (process view) ja käyttöönottonäkymä (deployment view) [EPL04]. UML:n käyttö ei edellytä näiden näkymien huomioon ottamista ja kaaviot toimivat sellaisenaan halutulla tavalla kehitettävänä olevan järjestelmän kuvaamisessa. Toisaalta kehitettävän järjestelmän tarkastelu eri näkökulmista helpottaa määrittelyä. Jos järjestelmän olennainen tehtävä on automatisoida yrityksessä suoritettavia työvaiheita, on järkevää miettiä asioita työnkulun näkökulmasta. Tuotanto- tai liiketoimintavaiheen kuvaaminen aktiviteettikaaviolla prosessin alusta loppuun luo tilanteesta kokonaiskuvan, johon muita vaatimusmäärittelyjä voidaan verrata. UML-kielen versiossa 2.0 on määritelty 13 erilaista kaaviotyyppiä [OMG08]. Kaavioita on kolmea eri tyyppiä. Staattista rakennetta, käyttäytymistä, ja vuorovaikutusta kuvaavia kaavioita. Staattista rakennetta kuvaavia kaavioita ovat luokkakaavio (Class diagram), oliokaavio (Object diagram), komponenttikaavio (Component diagram), rakennekaavio (Composite Structure diagram), pakkauskaavio (Package diagram) ja

6 4 sijoituskaavio (Deployment diagram). Käyttäytymistä kuvaavia kaavioita ovat käyttötapauskaavio (Use Case diagram), aktiviteettikaavio (Activity diagram) ja tilakaavio (State machine diagram). Vuorovaikutusta kuvaavia kaavioita ovat sekvenssikaavio (Sequence diagram), kommunikaatiokaavio (Communication diagram), ajoituskaavio (Timing diagram) ja vuorovaikutuskaavio (Interaction diagram). Kaaviot voidaan luokitella rakennetta ja käyttäytymistä kuvaaviin kaavioihin. Kuvassa 1 on kuvattu UMLkaavioiden luokittelu. UML-kaavioita ei sellaisenaan sovelleta mihinkään tiettyyn ohjelmiston määrittelyn tai suunnittelun vaiheeseen. UML-kaavioiden käytön ratkaisee se, minkä tyyppisestä ohjelmistosta on kyse. Minkälainen lähestymistapa valitaan ohjelmiston vaatimusmäärittelyyn. Lähestytäänkö tehtäväaluetta liiketoimintaprosessien kautta vai asetetaanko ohjelmistolle tiettyjä perustavoitteita, joita sen tulee täyttää. Minkälaista Kuva 1: UML-kaavioiden luokittelu [ViG06] prosessimallia aiotaan kehityksen aikana käyttää. Tukevatko käytetyt työkaluohjelmistot prosessin mukaista työskentelyä ja löytyykö työkaluohjelmistoista tuki käytetyille kaavioille. Nämä ja monet muut asiat vaikuttavat siihen, mitä ja miten yhdisteltyinä UMLkaavioita käytetään. Yksi tyypillinen yhdistelmä esiintyy RUP-prosessimallissa (Rational Unified Process), jota pidetään yleisesti käyttötapauksiin perustuvaksi ja arkkitehtuuriorientoituneeksi tavaksi toteuttaa oliopohjaisia ohjelmistoja. Käyttötapauk-

7 5 set määrittelevät ohjelmiston kehityksen sekä asiakkaalle, että ohjelmiston suunnittelijoille. RUP-prosessin mukainen ohjelmiston määrittely kuvataan UML-kielen käyttötapauskaaviolla [Ree02]. RUP:n ja muidenkin vakiintuneiden prosessimallien tueksi on olemassa työkaluohjelmistoja, joissa käytetään kuvauskielenä UML:ää. 3.4 Käyttötapauskaavio Käyttötapauskaavio on UML:n paljon käytetty perustyökalu vaatimusmäärittelyssä. Käyttötapaukset ovat yleinen tapa määritellä ohjelmiston toiminnallisia vaatimuksia. Käyttötapauksilla annetaan korkean tason kuva siitä, miten järjestelmä toimii suhteessa sen käyttäjään. Toiminnalliset vaatimukset kuvataan käyttötapauskaaviossa helpoilla symboleilla, jolloin se on hyvin helposti ymmärrettävä myös ohjelmistotekniikkaan perehtymättömälle henkilölle [EPL04]. Kognitio-psykologisessa tutkimuksessa, jossa verrattiin luokkakaavioiden ja käyttötapauskaavioiden käyttämistä, todettiin käyttötapauskaavioiden olevan hyvä kommunikaatiotyökalu. Luokkakaavio soveltuu myös vaatimusten kuvaamiseen, mutta on tekniikaltaan monimutkaisempi. Luokkakaavion tuoma näkökulma määriteltävään järjestelmään poikkeaa käyttötapauskaavion näkökulmasta, joten sen avulla vaatimukset kuvautuvat eri tavalla [SiL04]. Käyttötapauskaavion Symboleja ovat toimija (Actor), käyttötapaus (Use Case), yhdysviiva (Connector) [Lan02]. Kuvassa (Kuva 2) on esitetty symbolit tilanteessa, jossa toimijat ja käyttötapaukset on säiliöity kuvan vasemmalla puolella pakkauksiin. Tässä tapauksessa UML:n kaaviotyyppi pakkaus toimii säiliönä käyttötapauskomponenteille. Kuvan oikealla puolella on käyttötapauskaavio, jossa käytetään pakkausten komponentteja. Käyttötapauskaaviossa toimija-symboli (actor) esittää järjestelmän ulkoista toimijaa. Toimija voi olla todellinen käyttäjä tai järjestelmän ulkopuolinen toinen järjestelmä, joka käyttää kuvatun järjestelmän tarjoamia palveluja. Toimijasta on piirretty suhdeviiva, jonka nuoli osoittaa käyttötapausta. Nuoli kertoo näiden välillä olevan vuorovaikutussuhteen. Ovaali-kuvio käsittää järjestelmässä olevan toiminnallisuuden. Kaavioon liittyy aina erillinen dokumentti, joka kuvaa kunkin käyttötapauksen seikkaperäisesti. Käyttötapaus voi olla esimerkiksi "Lipun varaus". Kuvan oikeaan alakulmaan on kuvattu järjestelmän ulkopuolinen automaattinen järjestelmä, jossa on käytetty UML:n laajentamismahdollisuutta stereotyypillä. Stereotyyppi kertoo, että kyseessä on toimija. Vaikka käyttötapauskaavioiden hyödyllisyyttä on kyseenalaistettu, on niistä

8 6 edelleen apua vaatimusten määrittelyssä. Yhden käyttötapauksen sijoittaminen yhteen käyttötapauskomponenttiin, jota käytetään tekstin, toimijoiden ja muiden kaavioiden sitojana on selkeästi hyödyllinen mallintamiskeino. Kuva 2: Käyttötapausten kuvaus käyttötapauskaaviolla 3.5 Käyttötapauskaavio ja ei-toiminnalliset vaatimukset Ei-toiminnalliset vaatimukset ovat järjestelmän toimintaan ja -laatuun liittyviä ehtoja, kuten riittävä suorituskyky, vasteaika, palvelun laatu, saatavuus. Ohjelmiston vaatimusmäärittelyssä nämä ehdot kirjataan ylös vaatimuksia, mutta niiden seuraaminen osana ohjelmistonkehitysprosessia on hankalaa. Usein kriittisimmän virheet ohjelmistossa liittyvät sen ei-toiminnallisiin vaatimuksiin. Nämä ovat tyypillisesti hankalimpia vikoja korjata. 4+1-mallissa ei-toiminnalliset vaatimuksia kuvataan prosessi-näkökulmassa [Kru95]. Myös UML:n prosessinäkökulma on tarkoitettu ei-toiminnallisten vaatimusten kuvaamiseen. Ongelmana tässä on kuitenkin se, että vaatimukset eivät tule huomatuksi

9 7 kehitysprosessin aikana tätä kautta. Ratkaisuksi ongelmaan on ehdotettu ei-toiminnallisten vaatimusten liittämistä osaksi käyttötapausten mallintamista kontrollitapausten avulla [ZoP07]. Ei-toiminnallisten vaatimusten nostaminen 4+1-malliin keskelle skenaario-näkökulmaan pakottaa ottamaan järjestelmän suunnittelussa huomioon käyttötapausten lisäksi siihen liittyvän ei-toiminnallisen vaatimuksen (kuva 3). Kuva 3: 4+2 malli [ZoP07] Kontrollitapaus (control case) on ei-toiminnallinen vaatimus. Kontrollitapauksena kuvattu ei-toiminnallinen vaatimus voidaan liittää käyttötapauskaaviossa käyttötapaukseen. Kontrollitapauksien suunnittelu aloitetaan tunnistamalla ei-toiminnallisiin vaatimuksiin vaikuttavat olosuhdetekijät (operating conditions). Näitä ovat esimerkiksi tietoliikenneyhteyden katkeaminen, järjestelmän kuormittuminen, sähkökatkos. Kontrollitapauksiin kuvataan myös riskit ja seuraukset sidosryhmille. Kontrollitapaukset luokitellaan pääkategorioihin kuten, luotettavuus, saatavuus, eheys, skaalautuvuus ja tietoturva. Kontrollitapaus siis kuvaa sen laatuvaatimuksen, jonka järjestelmän täytyy täyttää ettei siihen liittyvä riski toteudu. Suorituskykyyn liittyvä kontrollitapaus esimerkkinä kuvassa 4.

10 8 Kuva 4: Kontrollitapaus esimerkki [ZoP07] Kontrollitapauksen liittäminen käyttötapauskaavioon tapahtuu hyödyntämällä UML:n stereotyypitystä. Stereotyypityksellä voidaan laajentaa UML:n omaa ilmaisuvoimaa. Kontrollitapauksia varten on esitetty yksinkertainen notaatio (kuva 5). Notaatiossa olosuhdetekijää kuvaa oma symboli, joka liitetään suhdeviivalla käyttötapaukseen. Suhdeviivaa tarkennetaan stereotyypillä "<<operating under>>". Näin käyttötapaukseen liitetään aina yksi tai useampia olosuhdetekijöitä. Olosuhdetekijään liitetään suhdeviivalla yksi kontrollitapaus stereotyypillä "<<controlled by>>". Kuva 5: Notaatio kontrollitapauksen liittämiseksi käyttötapauskaavioon [ZoP07] 3.6 Aktiviteettikaaviot Aktiviteettikaaviolla voidaan mallintaa organisaatioiden olemassa olevia työnkulkuja sekä mallintaa jonkin tietyn olioksi mallinnettavan asian sisäinen toiminta. Aktiviteettikaavio on kuvaustavaltaan tilakaavion kaltainen verkko, mutta sitä käytetään eri tarkoitukseen. Aktiviteettikaavioilla kuvataan ohjelmiston vaatimusmäärittelyssä toi-

11 9 mintojen kulkua ja niiden tuloksia. Riippuen UML-kielen käyttötavasta, aktiviteettikaaviolla voidaan vaatimusmäärittelyssä kuvata tehtäväalueen korkean tason käyttäytymistä tai kuvata tarkasti jonkin tietyn toiminnon vaiheita. Korkean tason kuvauksen yhteydessä kaaviosta käytetään englannin kielellä nimitystä "activity diagram" ja toiminnon kuvauksen yhteydessä "activity chart". Kuvassa (kuva 6) on esitetty yksinkertainen esimerkki aktiviteettikaaviosta, jossa kuvataan perunoiden keittämistä. Kuvassa huomionarvoista ovat ehtosolmut. Perunoiden kypsentäminen vaatii prosessin aloittamisen alkusolmusta eli veden kiehuttamisen ja syötteenä raakoja perunoita. Näiden esiehtojen täytyttyä siirrytään saman tien perunoiden keittoon, joka vaatii kiehuvaa vettä ja perunoita. Lopputuotteena saadaan kypsiä perunoita. Kuva 6: Aktiviteettikaavio Järjestelmän käyttäytymistä kuvaavissa aktiviteettikaavioissa (diagrams) toimintoja voidaan osioida liiketoimintaan liittyvien toimijoiden mukaisesti. Kahteen eri osioon voidaan jakaa palvelun tuottava osa ja palvelua tarjoava osa kuvattavasta ohjelmiston osasta. Osiot kuvataan "uima-altaan ratoihin" (Swimlanes) assosioiduilla pystyviivoilla, joiden välillä aktiviteetteihin liittyvät suhteet on kuvattu viivoilla. Kuvassa (kuva 7) on yksinkertaisella kirjan syntyprosessia kuvaavalla esimerkillä kuvattu liiketoimintaprosessin kuvaamista ja sen osioimista. Osiot mahdollistavat aktiviteettikaavion jakamisen korkean tason käsitteisiin. Osioituun kaavioon voi sisällyttää muitakin aktiviteettikaa-

12 vioiden symboleja. Esimerkissä on käytetty tilakaavioista tuttuja alku- ja loppusolmun symboleja. 10 Kuva 7: Aktiviteettikaavio, jossa liiketoimintaprosessit on osioitu Käyttötapauksia voidaan tarkentaa aktiviteettikaavioilla. Tapaustutkimuksessa, jossa tutkittiin käyttöliittymäsuunnitelman tarkentamista aktiviteettikaavioilla, todettiin aktiviteettikaavioiden auttavan käyttötapausten toiminnallisessa määrittelyssä [AlI04]. Tutkimuksessa johdettiin käyttötapausten suhdemäärittelyn perusteella käyttöliittymän toiminnallista määrittelyä varten aktiviteettikaaviot. Aktiviteettikaaviot tarkensivat käyttötapauskaavion kuvausta vaatimusmäärittelyn kannalta silloin, kun tilasiirtymässä kuvattiin oli ehdollisuutta. Tapaustutkimuksessa aktiviteettikaavioihin oli otettu mukaan käyttöliittymän toteuttavat ohjelmistokomponentit tilasiirtymiin liitettyinä stereotyyppeinä.

13 11 4 UML vaatimusten analysoinnissa * * * 5 UML ja toiminnalliset vaatimukset * * * 6 UML ja ei-toiminnalliset vaatimukset * * * 7 Yhteenveto UML-kuvauskielen kaaviotyypeistä erityisesti käyttötapauskaavio on vaatimusmäärittelyn työkalu. Olennaista on kuvata ohjelmistoa monesta eri näkökulmasta, että kaikki ohjelmistoon liittyvät seikat tulevat huomioitua. UML:n tarjoamat kaaviot ovat hyvä visualisoinnin työkalu. UML yhdistettynä hyvään prosessimalliin, jolle löytyy työkalutuki, edesauttaa ohjelmiston vaatimusmäärittelyn toteutumista kaikissa seuraavissa ohjelmistoprosessin vaiheissa. UML:n laajentaminen ja jatkokehitys tarjoaa tulevaisuudessa lisää välineitä entistä laadukkaampien ohjelmistojen tuotantoon.

14 12 Lähteet [AlI04] [Bra02] [DJA01] [EPL04] [Kru95] [Lan02] [Obj07] Almendros-Jiménez J. M., Iribarne L., Describing Use Cases with Activity Charts, LNCS Springer, Vol. 3511, 2005, sivut Bray, Ian K., An Introduction to Requirements Engineering, Addison Wesley Braun D., Sivils J., Shapiro A., Versteegh J. Kennesaw State University, [ ] Eriksson, H., Penker M., Lyons, B., Fado D. UML 2 Toolkit. Wiley Publishing Inc., Kruhten P., The 4+1 View Model of Architecture, IEEE Software JNL, Vol. 12, 1995, sivut Lanman J. Using UML Use Case and Activity Diagrams to Describe Software Requirements. Department of Computer and Mathematics Embry- Riddle Aeronautical University, 25 February Object Management Group,Unified Modeling Language: Infrastructure, version 2.1.1, February 2007 [OMG08] OMG - Object Management Group, Introduction to OMG's Unified Modeling Language. [ ] [Ree02] [SiL04] [ViG06] Reed P., From Developing Applications with Java and UML, Addison-Wesley, 2002, [ ] Siau K., Lee L., Are use case and class diagrams complementary in requirements analysis? An experimental study on use case and class diagrams inuml, Springer, Requirements Engineering, vol. 9, sivut Viljamaa J., Gustafsson J., Ohjelmistotekniikan menetelmät, luentokalvot. [ ]

15 13 [ZoP07] Zou J., Pavlovski C. J., Control case approach to record and model nonfunctional requirements, Springer Information Systems and E-Business Management Journal, Vol. 6, No. 1., 2008.

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

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

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

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

Ohjelmistojen mallintaminen, mallintaminen ja UML

Ohjelmistojen mallintaminen, mallintaminen ja UML 582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti

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

Määrittely- ja suunnittelumenetelmät

Määrittely- ja suunnittelumenetelmät Menetelmädokumentti Määrittely- ja suunnittelumenetelmät Versio Päiväys Tekijä Kuvaus 0.01 5.12.01 Pekka Koskinen Alustava sisällysluettelo 0.1 7.12.01 Pekka Koskinen Ensimmäinen luonnos 1.0 11.12.01 Pekka

Lisätiedot

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 582101 - Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 1 Vaatimukset ja käyttötapaukset Vaiheittainen mallintaminen ja abstraktiotasot Järjestelmän rajaaminen sidosryhmäkaaviolla

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

Ohjelmistojen mallintaminen kertausta Harri Laine 1

Ohjelmistojen mallintaminen kertausta Harri Laine 1 kertausta 5.12.2008 Harri Laine 1 Ohjelmiston elinkaari, elinkaarimallit Yleinen puitemalli (reference model) - abstrakti kokonaiskuva ei etenemiskontrollia, ei yksityiskohtia Ohjelmistoprosessimallit

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

UML- mallinnus: Tilakaavio

UML- mallinnus: Tilakaavio UML- mallinnus: Tilakaavio Karkea kuvaus UML- kaavioiden käytöstä ohjelmistonkehityksen eri vaiheissa ja tehtävissä. Mallinnus tilakaavioilla Tilakaaviolla kuvataan yhden luokan olioiden tilan muuttumista

Lisätiedot

TIE = JOTU. VH5 - MagicDraw

TIE = JOTU. VH5 - MagicDraw TIE-02300 = JOTU VH5 - MagicDraw TIE-02300 2 VH5 kaavionpiirtelyharjoitus Tässä harjoituksessa opetellaan tunnistamaan ja piirtämään tavallisimpia ja käytetyimpiä ohjelmistotuotannon kaavioita: käyttötapauskaavio

Lisätiedot

UML metamallina. Seminaariesitelmä Minna Majuri HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

UML metamallina. Seminaariesitelmä Minna Majuri HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Seminaariesitelmä 26.9.2000 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Sisällys 1 Johdanto 1 2 UML:n perusteet 2 2.1 Kaaviot 2 2.1.1 Yleiskäsitteet ja käyttötapauskaavio 2 2.1.2 Luokkakaavio 3

Lisätiedot

Ohjelmistotekniikan menetelmät, mallintaminen ja UML

Ohjelmistotekniikan menetelmät, mallintaminen ja UML 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

Lisätiedot

Malliperustainen ohjelmistokehitys - MDE Pasi Lehtimäki

Malliperustainen ohjelmistokehitys - MDE Pasi Lehtimäki Malliperustainen ohjelmistokehitys - MDE 25.9.2007 Pasi Lehtimäki MDE Miksi MDE? Mitä on MDE? MDA, mallit, mallimuunnokset Ohjelmistoja Eclipse, MetaCase Mitä jatkossa? Akronyymiviidakko MDE, MDA, MDD,

Lisätiedot

Ohjelmistojen mallintaminen, kesä 2009

Ohjelmistojen mallintaminen, kesä 2009 582104 Ohjelmistojen mallintaminen, kesä 2009 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin

Lisätiedot

Kaaviotekniikoista (erityisesti UML) (ajan riittäessä pikkasen projekteista)

Kaaviotekniikoista (erityisesti UML) (ajan riittäessä pikkasen projekteista) Kaaviotekniikoista (erityisesti UML) (ajan riittäessä pikkasen projekteista) Kari Systä 05.10.2015 9/30/2013 Jotu2013/KSY 1 Ajankohtaista kurssista Keskiviikon viimeinen viikkoharjoitus saatetaan lopettaa

Lisätiedot

UML-MALLINNUSKIELI JA SEN HYÖDYNTÄMINEN OHJELMISTOKEHITYKSESSÄ

UML-MALLINNUSKIELI JA SEN HYÖDYNTÄMINEN OHJELMISTOKEHITYKSESSÄ Juha Rautiainen UML-MALLINNUSKIELI JA SEN HYÖDYNTÄMINEN OHJELMISTOKEHITYKSESSÄ Tietotekniikan kandidaatintutkielma 20.3.2011 Jyväskylän yliopisto Tietotekniikan laitos Tekijä: Juha Rautiainen Yhteystiedot:

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

Ohjelmistotekniikan menetelmät, kesä 2008

Ohjelmistotekniikan menetelmät, kesä 2008 582101 - Ohjelmistotekniikan menetelmät, kesä 2008 1 Ohjelmistotekniikan menetelmät Methods for Software Engineering Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön

Lisätiedot

Ohjelmistojen suunnittelu

Ohjelmistojen suunnittelu Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer

Lisätiedot

Mallinnus UML-yleiskatsaus

Mallinnus UML-yleiskatsaus 2 Mallinnus UML-yleiskatsaus Tule maalle - näe mullin malli. Tämän osan sisältö Mallinnus ohjelmistoprojekteissa Mallinnuskielet UML-yleiskatsaus Oliopohjainen ajattelu UML-kaaviot rakennetta kuvaavat

Lisätiedot

Ohjelmistotekniikka - Luento 2

Ohjelmistotekniikka - Luento 2 Ohjelmistotekniikka - Luento 2 Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento 2: Prosessimallit

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

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 2, pe 5.11.

Ohjelmistojen mallintaminen. Luento 2, pe 5.11. Ohjelmistojen mallintaminen Luento 2, pe 5.11. Kertausta Ohjelmistotuotantoprosessin vaiheet: Vaatimusanalyysi- ja määrittely Mitä halutaan? Suunnittelu Miten tehdään? Toteutus Ohjelmointi Testaus Varmistetaan

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

UML OHJELMISTOPROSESSIEN TUKENA

UML OHJELMISTOPROSESSIEN TUKENA UML OHJELMISTOPROSESSIEN TUKENA Kimmo Kampman 11.5.2001 Joensuun yliopisto Tietojenkäsittelytiede Pro gradu -tutkielma TIIVISTELMÄ Ohjelmistojen teko muuttuu jatkuvasti vaativammaksi. Ohjelmiston mallintamisen

Lisätiedot

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita.

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Arkkitehtuuriin vaikuttavat ympäristötekijät Jo kehittämisen alkuvaiheessa on tarpeellista hahmotella arkkitehtuurin perusratkaisu. Lähtökohdat

Lisätiedot

5. Järjestelmämallit. Mallinnus

5. Järjestelmämallit. Mallinnus 5. Järjestelmämallit Käyttäjävaatimukset pitää kirjoittaa luonnollisella kielellä. Niitä lukevat myös asiakkaat ja loppukäyttäjät. Järjestelmävaatimukset kannattaa kirjoittaa jollain rakenteisella kuvaustavalla.

Lisätiedot

Käyttötapausten mallintaminen

Käyttötapausten mallintaminen Käyttötapausten mallintaminen Vaatimukset ja testauslähtöisyys, swd4tn001 Anne Valsta 1.3.2011 (ent. 11.2.2011) Sisällysluettelo 1 Käyttötapaukset ohjelmiston vaatimusten määrityksessä... 2 1.1 Käyttötapauskartta...

Lisätiedot

käyttötapaukset mod. testaus

käyttötapaukset mod. testaus käyttötapaukset Jari Ojasti Nokia email : jari.ojasti@nokia.com puh : 040 5926 312 Kartta hyväksyntä määrittely suunnittelu suunnittelu mod. testaus integrointi sys. testaus Ylläpito koodaus (toteutus)

Lisätiedot

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento

Lisätiedot

Analyysi on tulkkaamista

Analyysi on tulkkaamista Analyysi on tulkkaamista Petri: Pitää osata menetelmiä, arkkitehtuureja, suunnittelumalleja, eli miten [ohjelmistoja] ylipäänsä kehitetään. Pitää olla viestintätaitoja. Perttu: Pitää ymmärtää miten projekti

Lisätiedot

Testaaminen ohjelmiston kehitysprosessin aikana

Testaaminen ohjelmiston kehitysprosessin aikana Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/

Lisätiedot

UML-mallinnus ja prosessien kuvaaminen Microsoft Visiolla (versio 2003 professional) Jouni Huotari 11.1.2005

UML-mallinnus ja prosessien kuvaaminen Microsoft Visiolla (versio 2003 professional) Jouni Huotari 11.1.2005 UML-mallinnus ja prosessien kuvaaminen Microsoft Visiolla (versio 2003 professional) Jouni Huotari 11.1.2005 Tutustumiskierros Vision UML-kaavioihin Avaa ChampionzoneUML.vsd-tiedosto Tutustu malliin eli

Lisätiedot

Mallinnus. 5. Järjestelmämallit. Abstraktiot. Mallinnuksen etuja. Arkkitehtuurimalli. Yhteysmallit. Ohjelmistotuotanto, järjestelmämallit Kevät 2005

Mallinnus. 5. Järjestelmämallit. Abstraktiot. Mallinnuksen etuja. Arkkitehtuurimalli. Yhteysmallit. Ohjelmistotuotanto, järjestelmämallit Kevät 2005 5. Järjestelmämallit Käyttäjävaatimukset pitää kirjoittaa luonnollisella kielellä. Niitä lukevat myös asiakkaat ja loppukäyttäjät. Järjestelmävaatimukset kannattaa kirjoittaa jollain rakenteisella kuvaustavalla.

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

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.

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

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

VH5, JOTU, MagicDraw:n käyttö

VH5, JOTU, MagicDraw:n käyttö VH5, JOTU, MagicDraw:n käyttö 1. Käynnistä MagicDraw (versio 18.2) 2. Valitse Manage Projects-kohdasta Create New Project toiminto. Oletusarvona on UML Project, saa olla. Täytä nimi (Name) ja tallennuspaikka

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

Ohjelmistotuotanto, kuvaustekniikat Syksy Kuvaustekniikat. Miksi kuvaustekniikoita? Abstraktiotasot. Abstrahointi UML

Ohjelmistotuotanto, kuvaustekniikat Syksy Kuvaustekniikat. Miksi kuvaustekniikoita? Abstraktiotasot. Abstrahointi UML 5. Kuvaustekniikat Miksi kuvaustekniikoita? Tämä luku perustuu Sommervillen lisäksi seuraaviin kirjoihin: Martin Fowler, UML Distilled - Second Edition. Addison-Wesley, 2000. Roger S. Pressman, Software

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

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

UML-MALLINNUS MICROSOFT VISIOLLA JOUNI HUOTARI 11.1.2005 14.2.2010

UML-MALLINNUS MICROSOFT VISIOLLA JOUNI HUOTARI 11.1.2005 14.2.2010 UML-MALLINNUS MICROSOFT VISIOLLA JOUNI HUOTARI 11.1.2005 14.2.2010 TUTUSTUMISKIERROS VISION UML-KAAVIOIHIN Avaa ChampionzoneUML.vsd-tiedosto Tutustu malliin eli eri sivuilla oleviin kaavioihin (napsautus

Lisätiedot

Olioperustaisuus (object oriented)

Olioperustaisuus (object oriented) DO NOT PRINT THIS DOCUMENT Olioperustainen ohjelmistokehitys Olioperustaisuus (object oriented) järjestelmä (system) muodostuu joukosta olioita (object), jotka yhteistyössä toimien tuottavat järjestelmän

Lisätiedot

Ohjelmistojen mallintaminen, kesä 2010

Ohjelmistojen mallintaminen, kesä 2010 582104 Ohjelmistojen mallintaminen, kesä 2010 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin

Lisätiedot

3a. Projektin hallinta (lisäys lukuun 3)

3a. Projektin hallinta (lisäys lukuun 3) 3a. Projektin hallinta (lisäys lukuun 3) Tehokas projektin hallinta keskittyy kolmeen osaalueeseen: henkilökuntaan, tehtävään ja prosessiin. Henkilökunta: on yrityksen tärkein voimavara, oikea henkilö

Lisätiedot

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright

Lisätiedot

Visual Case 2. Miika Kasnio (C9767) 23.4.2008

Visual Case 2. Miika Kasnio (C9767) 23.4.2008 Visual Case 2 Miika Kasnio (C9767) 23.4.2008 Työn tarkasti: Jouni Huotari 24.4.2008 1 SISÄLTÖ 1. TYÖN LÄHTÖKOHDAT... 2 2. PERUSTIEDOT... 2 3. ASENTAMINEN... 2 4. OMINAISUUDET... 3 4.1. UML-kaaviot... 4

Lisätiedot

Kaaviotekniikoista (erityisesti UML)

Kaaviotekniikoista (erityisesti UML) Kaaviotekniikoista (erityisesti UML) Kari Systä 20.10.2014 20.10.2014 Jotu2014/KSY 1 Tiedotettavaa Jos ette ole varanneet välinäyttöä, varatkaa heti (keskiviikkona dedis) Dokumentit IDLEeen (sähköposti

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

Johdatus sovellussuunnitteluun, s2000, osa3 Helsingin yliopisto;/tktl. Harri Laine 1. Järjestelmän palvelujen määrittely

Johdatus sovellussuunnitteluun, s2000, osa3 Helsingin yliopisto;/tktl. Harri Laine 1. Järjestelmän palvelujen määrittely Tietojärjestelmät tarjoavat tietoa sekä käyttäjille että epäsuorasti muille tahoille Tahoja, jotka ovat järjestelmän ulkopuolella, mutta kuitenkin palvelujen kautta kytkeytyneitä järjestelmään kutsutaan

Lisätiedot

Vaatimusten keräys ja hallinta

Vaatimusten keräys ja hallinta Vaatimusten keräys ja hallinta Inka Vilpola 19.4.2006 Sisältö Vaihe ISO 13407 -prosessissa Vaatimusten lajit (teoria) Vaatimukset hyvälle vaatimukselle Vaatimusten hallinta Vaatimusten kerääminen Vaatimusten

Lisätiedot

Käyttäjien tunnistaminen on ensimmäinen tehtävä järjestelmän palveluja määriteltäessä. Käyttäjien löytämiseksi voidaan esittää kysymykset:

Käyttäjien tunnistaminen on ensimmäinen tehtävä järjestelmän palveluja määriteltäessä. Käyttäjien löytämiseksi voidaan esittää kysymykset: 1 Käyttötapausmalli Ohjelmisto tarjoaa käyttäjilleen palveluita, jotka perustuvat järjestelmän tietosisältöön. Ohjelmiston toiminta voidaan kuvata määrittelemällä millaisia palveluita ohjelmisto tarjoaa.

Lisätiedot

Ohjelmistojen mallintaminen, mallinnustekniikat käytännössä

Ohjelmistojen mallintaminen, mallinnustekniikat käytännössä 582104 Ohjelmistojen mallintaminen, mallinnustekniikat käytännössä 1 Sisältö Oliomenetelmien taustaa Kirjastojärjestelmän käyttötapaukset Kirjastojärjestelmän luokkamalli 2 Oliosuuntautunut suunnittelumenetelmä

Lisätiedot

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 EDELLISELLÄ KERRALLA TAPAHTUNUTTA Täydellinen testaus on mahdotonta. Testataan, koska virheiden löytyminen ajoissa

Lisätiedot

Joskus yleistäminen voi tapahtua monen ominaisuuden pohjalta. Myös tällöin voi tulla moniperintätilanteita.

Joskus yleistäminen voi tapahtua monen ominaisuuden pohjalta. Myös tällöin voi tulla moniperintätilanteita. Moniperintä 2 Joskus yleistäminen voi tapahtua monen ominaisuuden pohjalta. Myös tällöin voi tulla moniperintätilanteita. Oliomallinnus TITE.2040 Hannu K. Niinimäki 1 Delegointi 1 Moniperinnän toteuttaminen

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:

Lisätiedot

Johdatus sovellussuunnitteluun, s2001, osa 3 Helsingin yliopisto / TKTL. Harri Laine / Inkeri Verkamo 1. Järjestelmän palvelujen määrittely

Johdatus sovellussuunnitteluun, s2001, osa 3 Helsingin yliopisto / TKTL. Harri Laine / Inkeri Verkamo 1. Järjestelmän palvelujen määrittely Tietojärjestelmät tarjoavat tietoa sekä käyttäjille että epäsuorasti muille tahoille. Tahoja, jotka ovat järjestelmän ulkopuolella, mutta kuitenkin palvelujen kautta kytkeytyneitä järjestelmään, kutsutaan

Lisätiedot

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

Ohjelmistotekniikan menetelmät Luokkamallit ohjelmiston mallintamisessa Harri Laine 1

Ohjelmistotekniikan menetelmät Luokkamallit ohjelmiston mallintamisessa Harri Laine 1 Ohjelmistotekniikan menetelmät Luokkamallit ohjelmiston mallintamisessa 14.11.2008 Harri Laine 1 Oliot ohjelmiston mallinnuksessa käyttötapaus käyttää Käyttämämme oliokeskeinen perusmalli ohjelmistojen

Lisätiedot

Ohjelmistojen mallintaminen, mallintaminen ja UML

Ohjelmistojen mallintaminen, mallintaminen ja UML 582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML (Ch 2.) Ohjelmistojen mallintamisesta ja kuvaamisesta Strukturoitu mallinnus Tietovuo- ja ER-kaaviot Oliomallinnus ja UML

Lisätiedot

Kertaus: yleistys-erikoistus ja perintä

Kertaus: yleistys-erikoistus ja perintä Kertaus: yleistys-erikoistus ja perintä Nauta, Lehmä ja Kuttu ovat Kotieläimiä, Kotieläimet Eläimiä Kotieläimillä (siis myös Naudoilla, Lehmillä ja Kutuilla) on Omistaja Kuttu ja Lehmä toteuttavat rajapinnan

Lisätiedot

AVOIMEN LÄHDEKOODIN UML-MALLINNUSVÄLINEIDEN VERTAILU PIENTEN OHJELMISTOPROJEKTIEN TARPEISIIN

AVOIMEN LÄHDEKOODIN UML-MALLINNUSVÄLINEIDEN VERTAILU PIENTEN OHJELMISTOPROJEKTIEN TARPEISIIN Juha Rautiainen AVOIMEN LÄHDEKOODIN UML-MALLINNUSVÄLINEIDEN VERTAILU PIENTEN OHJELMISTOPROJEKTIEN TARPEISIIN Tietotekniikan pro gradu -tutkielma, 15.1.2014 Jyväskylän yliopisto Tietotekniikan laitos Tekijä:

Lisätiedot

Ohjelmistojen mallintaminen

Ohjelmistojen mallintaminen Luentomoniste kurssille Ohjelmistojen mallintaminen Matti Luukkainen ja Harri Laine Tietojenkäsittelytieteen laitos Helsingin Yliopisto 31. lokakuuta 2010 Esipuhe Käsissäsi on Ohjelmistojen mallintaminen

Lisätiedot

Ohjelmistojen mallintaminen Olioperustainen ohjelmistomalli Harri Laine 1

Ohjelmistojen mallintaminen Olioperustainen ohjelmistomalli Harri Laine 1 Ohjelmistojen mallintaminen Olioperustainen ohjelmistomalli 4.11.2008 Harri Laine 1 Olioperustainen ohjelmistokehitys Olioperustaisuus (object oriented software development) järjestelmä (system) on olio

Lisätiedot

Lomalista-sovelluksen määrittely

Lomalista-sovelluksen määrittely Thomas Gustafsson, Henrik Heikkilä Lomalista-sovelluksen määrittely Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikka Dokumentti 14.10.2013 Tiivistelmä Tekijä(t) Otsikko Sivumäärä Aika Thomas

Lisätiedot

sovellussuunnitteluun

sovellussuunnitteluun DO NOT PRINT THIS DOCUMENT Johdatus sovellussuunnitteluun Yleiskuva olioperustaisesta tietojärjestelmän ja erityisesti ohjelmiston kehittämisprosessista sekä siinä käytettävistä kuvaustekniikoista Pääperiaatteet

Lisätiedot

Johdatus sovellussuunnitteluun. Johdatus sovellussuunnitteluun

Johdatus sovellussuunnitteluun. Johdatus sovellussuunnitteluun Johdatus sovellussuunnitteluun Yleiskuva olioperustaisesta tietojärjestelmän ja erityisesti ohjelmiston kehittämisprosessista sekä siinä käytettävistä kuvaustekniikoista Pääperiaatteet käyttöliittymien

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 2 Ohjelmistoarkkitehtuurien kuvaus 2.1 Arkkitehtuurin kuvaukseen liittyvät käsitteet 2.2 Arkkitehtuurikuvaukset eri tasoilla 2.3 Arkkitehtuurinäkökulmat ja kuvaustyypit 2.4 Arkkitehtuuriviipaleiden kuvaus

Lisätiedot

Ohjelmistojen mallintaminen Ohjelmiston suunnittelu Model driven development Harri Laine 1

Ohjelmistojen mallintaminen Ohjelmiston suunnittelu Model driven development Harri Laine 1 Ohjelmistojen mallintaminen Ohjelmiston suunnittelu Model driven development 2.12.2008 Harri Laine 1 Jacobson jakaa ohjelmiston oliot kolmeen tyyppiin liittymäolioiksi (interface objects, boundary objects)

Lisätiedot

Johdatus sovellussuunnitteluun

Johdatus sovellussuunnitteluun D Harri Laine Johdatus sovellussuunnitteluun luentomoniste osa 1 Helsingin yliopisto Tietojenkäsittelytieteen laitos syksy 2000 Sisältö: 1 JÄRJESTELMÄN KEHITTÄMISEN VAIHEET... 1 1.1 PERUSKÄSITTEITÄ...

Lisätiedot

Luento 3 Tietokannan tietosisällön suunnittelu

Luento 3 Tietokannan tietosisällön suunnittelu HAAGA-HELIA / Heti-09 1 (17) Luento 3 Tietokannan tietosisällön suunnittelu Tietojärjestelmän suunnitteluprosessi... 2 Tietokannan suunnittelun tavoitteet... 3 Tietokannan suunnitteluprosessi... 4 Käsitteellinen

Lisätiedot

UML työvälineenä ja tutkimuskohteena

UML työvälineenä ja tutkimuskohteena UML työvälineenä ja tutkimuskohteena Kai Koskimies, Johannes Koskinen, Mika Maunumaa, Jari Peltonen, Petri Selonen, Mika Siikarla & Tarja Systä Tampereen teknillinen yliopisto Ohjelmistotekniikan laitos

Lisätiedot

GroupDesk Toiminnallinen määrittely

GroupDesk Toiminnallinen määrittely GroupDesk Toiminnallinen määrittely Tilanne: Paikallinen oppilaitos, kuvitteellinen WAMK, tarvitsee ryhmätyöhön soveltuvan sähköisen asioiden hallintajärjestelmän ja ryhmätyöohjelmiston, jonka ajatuksena

Lisätiedot

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

UML -mallinnus TILAKAAVIO

UML -mallinnus TILAKAAVIO UML -mallinnus TILAKAAVIO SISÄLLYS 3. Tilakaavio 3.1 Tilakaavion alku- ja lopputilat 3.2 Tilan nimi, muuttujat ja toiminnot 3.3 Tilasiirtymä 3.4 Tilasiirtymän vai tilan toiminnot 3.5 Tilasiirtymän tapahtumat

Lisätiedot

Tällä harjoituskerralla on tarkoituksena harjoitella käyttötapaus-, luokka- ja tapahtumasekvenssikaavioiden luontia.

Tällä harjoituskerralla on tarkoituksena harjoitella käyttötapaus-, luokka- ja tapahtumasekvenssikaavioiden luontia. MagicDraw-pikaohje Tällä harjoituskerralla on tarkoituksena harjoitella käyttötapaus-, luokka- ja tapahtumasekvenssikaavioiden luontia. Alkuvalmistelut Windows (sali TC205) 1) Kirjaudu sisään TTY:n intra-tunnuksella.

Lisätiedot

Määrittelyvaihe. Projektinhallinta

Määrittelyvaihe. Projektinhallinta Määrittelyvaihe Projektinhallinta testaus määrittely suunnittelu ohjelmointi käyttöönotto, testaus tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta Määrittely Määrittely, eli kansanomaisesti

Lisätiedot

Yhteenveto. Menettelytavat

Yhteenveto. Menettelytavat Yhteenveto Ohjelmistotuotanto: Luotettavien ja tehokkaiden ohjelmistojärjestelmien tuottamista noudattaen hyviksi havaittuja menettelytapoja. Menettelytavat Prosessimalli (vesiputous/spiraali/kasvattava)

Lisätiedot

MagicDraw-pikaohje (VH5)

MagicDraw-pikaohje (VH5) MagicDraw-pikaohje (VH5) Tällä harjoituskerralla on tarkoituksena harjoitella käyttötapaus-, luokka- ja tapahtumasekvenssikaavioiden luontia. Alkuvalmistelut Linux-työasemaluokka: käynnistä MagicDraw jollakin

Lisätiedot

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton 2015 syksy 2. vsk IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton Sisältö 1. Johdanto luontimalleihin 2. Proxy 3. Factory Method 4. Prototype 5. Singleton Suunnittelumallit Proxy et.

Lisätiedot

Dynaaminen analyysi II

Dynaaminen analyysi II Dynaaminen analyysi II Luento 7 Antti-Pekka Tuovinen 9 April 2013 1 Tavoitteet Black-box testitapausten suunnittelutekniikat II Tilamallien käyttö Syys-seurausverkot ja päätöstaulut Käyttötapaukset Yhteenveto

Lisätiedot

Suorituskyky ja ohjelmistokehitys Suorituskykymallit

Suorituskyky ja ohjelmistokehitys Suorituskykymallit Suorituskyky ja ohjelmistokehitys Suorituskykymallit Luento 2 58153003 Ohjelmistojen suorituskyky 1 SUORITUSKYKYISTEN OHJELMISTOJEN KEHITTÄMINEN 58153003 Ohjelmistojen suorituskyky 2 Helsingin Yliopisto

Lisätiedot

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

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

Käyttäjätarinat perinteisessä hankkeessa. Sisältö ja käytännöt

Käyttäjätarinat perinteisessä hankkeessa. Sisältö ja käytännöt Käyttäjätarinat perinteisessä hankkeessa Sisältö ja käytännöt Helsingin kaupunki 21/03/17 Käyttäjätarinat perinteisessä hankkeessa Mikä on käyttäjätarina Käyttäjätarina perinteisessä hankkeessa Käyttäjätarinan

Lisätiedot

Ohjelmistojen mallintaminen

Ohjelmistojen mallintaminen Luentomoniste kurssille Ohjelmistojen mallintaminen Matti Luukkainen ja Harri Laine Tietojenkäsittelytieteen laitos Helsingin Yliopisto 25. toukokuuta 2010 Esipuhe Käsissäsi on Ohjelmistojen mallintaminen

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

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 elinkaaret - tilakaavio. 21.11.2008 Harri Laine 1

Ohjelmistojen mallintaminen olioiden elinkaaret - tilakaavio. 21.11.2008 Harri Laine 1 Ohjelmistojen mallintaminen olioiden elinkaaret - tilakaavio 21.11.2008 Harri Laine 1 Joidenkin järjestelmien sisältömallissa on erotettavissa luokkia, joiden ilmentymien käyttäytymisen kuvaaminen, kirjaus

Lisätiedot

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1 Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon 31.10.2008 Harri Laine 1 Ohjelmisto Tietokoneohjelma (computer program) toimintaohje, jonka mukaan toimien tietokone suorittaa jonkin tietojenkäsittelytehtävän

Lisätiedot

Kurssin aihepiiri: ohjelmistotuotannon alkeita

Kurssin aihepiiri: ohjelmistotuotannon alkeita Kurssin aihepiiri: ohjelmistotuotannon alkeita [wikipedia]: Ohjelmistotuotanto on yhteisnimitys niille työnteon ja työnjohdon menetelmille, joita käytetään, kun tuotetaan tietokoneohjelmia sekä monista

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

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti

Lisätiedot