- Kerfisgreining með UML

Transcription

1

2 Kuml - Kerfisgreining með UML 2007, Jón Freyr Jóhannsson 5ta útgáfa Hönnun og umbrot: Jón Freyr Jóhannsson Rit þetta má eigi afrita með neinum hætti sem sem ljósmyndun, prentun, ljósritun eða á annan sambærilegan hátt, að hluta eða í heild, án skriflegs leyfis höfundar Útgefandi er Jón Freyr Jóhannsson 2

3 Efnisyfirlit 1 Inngangur Staðlar og tól Fyrirvarar Hvað er kerfisgreining? Verkþættir hugbúnaðargerðar, fasar Samantekt Spurningar Hvað er UML? RUP þróunarferlið Líkanagerð Kostir og gallar UML UML-ritin Samantekt Spurningar Kröfugreining Kröfugreining og kröfulýsing Kröfulýsing Mismunandi tegundir af kröfum Hvernig gerum við? Samantekt Spurningar Notkunarlíkan Táknmál notkunarlíkana - Grunntáknin Hvernig gerum við? Hvað er passlegt?... of stórt?.. eða of lítið? Meira táknmál Samantekt Spurningar og umræður Lýsing notkunarlíkana Innihald lýsinga notkunardæma Ábendingar um gerð notkunardæmalýsinga Form notkunardæmislýsingar Hlutir, klasar og vensl Hlutur Klasi Táknmál - Grunntákn Eigindi Aðgerðir Hvaða upplýsingar veitir klasinn? Hverskonar fyrirbæri verða klasar? Hvernig gerum við? Hvar finnum við klasana? Klasarit Hafa ber í huga Samantekt Spurningar og umræður Nafnorðagreining Dæmi um nafnorðagreiningu Vandamál við Nafnorðagreiningu og aðrar líkar aðferðir Vensl Jón Freyr Jóhannsson 3

4 9.1 Tengsl Alhæfing/erfðir Margfeldisþáttur Meira um vensl Endurkvæm tengsl Nefning vensla Tengslaklasi Samskiptarit Táknmál runurita Hvernig gerum við? Meira táknmál Yfirlit yfir táknmál Hafa ber í huga Samantekt Spurningar og umræður Stöðurit Táknmál stöðurita - Grunntáknin Hvernig gerum við? Hafa ber í huga Meira um stöðurit Verknaðarrit Táknmál verknaðarrita Sundbrautir Hvernig gerum við? Hafa ber í huga Verknaðarrit samantekt Ýmis fróðleikur - bland í poka Málfræði eiginda Málfræði aðgerða Pakkar Flokkar klasa sem kunna þarf skil á Snið Skorður/takmarkanir Afleidd tengsl Lykluð tengsl Yfirskrift í erfðum OCL Ýmis mikilvæg hugtök Heimildaskrá

5 1 Inngangur Þetta rit er ætlað til nota við kennslu í kerfisgreining þar sem miðað er við notkun á UML líkanamálinu. Ritið er gert fyrir rafræna framsetningu, þ.e. að það sé notað með tölvu. Fyrstu útgáfur verða þó miðaðar við að hægt sé að prenta ritið og er það brotið um miðað við útprentun á A4 pappír. Dæmi og verkefni hafa að mestu leyti verið færð yfir á vef kerfisgreiningar. Miðað er við að sá vefur sé notaður meðfram bókinni. Þessi dæmi eru algjör tilbúningur og þó þau styðjist við einhverja raunverulega þætti þá eru þau aðlöguð og breytt til að falla að þörfum kennslunnar. Sum dæmin verða með meira eða minna tilbúnum lausnum, önnur ekki. Tölvulausnir dæma, grunnar til að nota við dæmi og lagfæringar og leiðréttingar á texta er að finna á ru.is/kennarar/jonfreyr/kuml. Þar verður einnig að finna ítarefni og hljóð og myndskrár sem tengjast efninu. Þetta tákn hér á spássíunni til hliðar er notað þar sem vísað er til efnis sem finna má á kuml-vef. 1.1 Staðlar og tól Í þessu riti er miðað við UML útgáfu 2.0. Skýringarmyndir eru flestar unnar í Microsoft Office Visio Professional 2007 með UML sniðmáti. Það sniðmát er ekki í fullu samræmi við UML skilgreiningar en í ritunum hér hefur því verið breytt, ýmist með því að breyta eigindum (properties), handvirkum breytingum á teikniformum eða með því að nota almenn teiknitákn. Aðrar skýringarmyndir eru unnar í Poseidon 1 eða StarUML. Líkön sem finna má á vef eru flest 1 Poseidon sjá gentleware.com

6 Þegar vísað er til UML skilgreiningar þá er átt við skilgreiningu eins og hún kemur fyrir á vef OMG, Fyrirvarar Verkefni sem sett eru fyrir og dæmi sem eru sýnd í þessu riti eru tilbúningur, hafa samsvörun við raunveruleg dæmi en er hagað þannig að henti kennslu. Nefndir einstaklingar og leikendur myndskeiða eru notaðir til að þóknast þörfum námsefnisins en eru ekki endilega að túlka raunveruleika þeirra umhverfis. Allar tilvísanir í verkefnum og dæmum til lifenda og liðinna er skáldskapur einn. Þetta rit er ókeypis til notkunar fyrir þá sem vilja. Öll breyting eða nýting á einstökum hlutum þess er óheimil án samráðs við höfund. Skylt er að geta höfundar við alla notkun þessa. Allur höfundarréttur er áskilinn. Allar ábendingar og fyrirspurnir vel þegnar, hafið samband með netpósti: eða msn netfangið er og má nota það til samskipta á msn en engum pósti er svarað af því netfangi Hafnarfirði, ágúst Njóttu vel, Jón Freyr Jóhannsson, MBA í viðskiptafræði, BSc í tölvunarfræði, aðjúnkt við Háskólann í Reykjavík, 6

7 2 Hvað er kerfisgreining? Hugbúnaðargerð getur verið flókið ferli og krefst oft mikils tíma, mannafla og peninga. Stundum gengur hugbúnaðargerðin vel og stundum síður. Dæmi um mistök við hugbúnaðargerð eru mörg og hafa mistökin oft veruleg áhrif á líf fólks og starf, en ekki síður þá tapast oft mikið fé. Sumt af mistökunum má rekja til þess sem kalla má mannleg mistök, eitthvað sem ekki er unnt að sjá fyrir með góðu móti, annað kann að vera vegna þess að verkefnið var of stórt til að kerfisgerendur réðu við það og enn annað má sjálfsagt rekja til slælegra vinnubragða. Gott er að læra af þeim verkefnum sem vel hafa gengið og reyna að yfirfæra þá þekkingu á gerð nýs hugbúnaðar. Gerð hugbúnaðar felur alltaf í sér einhverjar breytingar á starfsemi, stundum litlar og stundum miklar. CIA fimm árum á eftir í tölvutækni Kvikmyndir sýna njósnara og liðsmenn leyniþjónustu sem tæknivætt fólk og ávallt með fullkomnustu tækin. Raunveruleikinn er allur annar. Niðurstöður nýlegrar leynilegrar rannsóknar hafa leitt í ljós að Bandaríska leyniþjónustan, CIA, er fimm árum á eftir öðrum íbúum veraldar hvað varðar nýtingu tækni, að því er segir í frétt BBC. (af mbl.is ) Stundum felast breytingarnar í nýrri starfsemi sem ekki er nein reynsla af. Mikilvægt er að markmið hugbúnaðarins séu skýr og að það sé fullur skilningur starfsmanna sem hann nota og einnig skilningur þeirra sem kaupa hann. Skilningur þeirra sem að kerfisgerðinni koma er einnig nauðsynlegur og samskipti milli þeirra og síðan notenda og kaupenda mun ráða mestu um hversu vel tekst til. Oft líður langur tími frá því að hugmynd um tölvukerfi kemur þar til fullbúið kerfi er komið í notkun og margt þarf að gera á þeim tíma. Einföld kerfi og einnig þau sem byggja að mestu á tilbúnum einingum, er oft hægt að vinna á skömmum tíma, jafnvel fáum dögum, en algengara er að verkið taki mánuði eða jafnvel ár þegar um stærri verkefni er að ræða. Verkefni eru misumfangsmikil og þeir sem vinna verkefnið mismargir eftir eðli og umfangi verks. Sum verkefni eru unnin af einum einstakling en algengara er að þau séu unnin af hópi einstaklinga. Stærstu verkefni eru unnin af hundruðum og jafnvel þúsundum einstaklinga.

8 Flestir hafa þekkingu sína frá bíómyndum þar sem forritarar eru gerðir líkastir nútíma galdramönnum og geta, með fáeinum slögum á lyklaborðið eða skipunum í hljóðnema, töfrað fram hinar ólíklegustu upplýsingar. Vélmenni og aðrar vélar gæddar mannlegum eiginleikum leysa hin ótrúlegustu verkefni. Þessar ímyndir af möguleikum tölvunnar eru oftast mjög fjarri sanni og allavega ekki á færi okkar sem byrjenda við hugbúnaðargerð! Forritun er mikilvægur þáttur í kerfisgerð en hún er aðeins hluti hugbúnaðargerðar. Kerfisgreining (e. system analysis) er yfirleitt skilgreindur sem fyrsti verkþátturinn í kerfisgerðinni Verkþættir hugbúnaðargerðar, fasar Verkþættirnir við gerð hugbúnaðar eru margir en sá verkþáttur sem flestir vita eitthvað af er forritunin sjálf, það að búa til forrit, en sjálfsagt gera fæstir sér grein fyrir því í hverju það felst. Það er venja að skipta þróunarferli 3 hugbúnaðar í tilgreinda verkþætti, oft talað um fasa, þar sem innan hvers fasa er áherslan á tiltekin viðfangsefni. Þróunarferli sem kallað er RUP (stendur fyrir Rational Unified Process) skiptir ferlinu upp eins og hér er sýnt 4 : 2 Mismunandi skilgreiningar á hugbúnaðarferlinu ráða því hvort skilgreindir eru verkþættir á undan kerfisgreiningu og er þá yfirleitt um að ræða verkþátt sem kallaður er kröfu- eða þarfagreining (e. requirements analysis), hér er gert ráð fyrir að hugtakið kerfisgreining nái til allra verkþátta í upphafi kerfisgerðar 3 Með þróunarferli er átt við það ferli (þann tíma og verkefni) sem spannar allt frá upphafi verks og þar til því er lokið. 4 Þessa mynd er m.a. að finna í hugbúnaðinum Rational Unified Process útgáfu

9 RUP skiptir þróunarferlinu í fjóra meginfasa (e. phases): 1. Upphaf (e. inception) Skilgreinir umfang verks, kröfulýsing og greining. 2. Mótun (e. elaboration) Verkefni skipulagt, gerð grein fyrir innihaldi og högun og líkön gerð. 3. Kerfissmíð (e. construction) Hin eiginlega framleiðsla kerfis, þar með talin forritun. 4. Aðlögun (e. transition) Kerfi sett upp og aðlagað að þörfum notenda. Innan hvers fasa er unnið að margvíslegum verkþáttum eins og fram kemur á mynd og skarast þannig mismunandi verkþættir við meginfasana fjóra. Kerfisgreining eins og fjallað er um hana hér spannar fyrstu tvo fasa RUP, upphaf og mótun. Í kerfisgreiningu felst sá grunnur sem talinn er nauðsynlegur til að vel takist til við kerfisgerð. Í kerfisgreiningu er áhersla lögð á skipuleg vinnubrögð og notkun formlegra aðferða eins og hægt er. Kerfisgreining felst í því að greina með skipulögðum hætti þarfir notenda og skilgreina með formlegum hætti hvernig hægt væri að koma þeim þörfum til skila í nýju kerfi. Þó kerfisgreining sé hluti af hugbúnaðargerð þá er er orðið kerfi notað í víðari skilningi en svo að það eigi einungis við um tölvukerfi. Kerfi er samsafn óháðra hluta eða þátta sem eru tengdir, mynda heild og þjóna einhverjum sameiginlegum tilgangi 5. Mikilvægi þessarar skilgreiningar liggur í því að hið endanlega tölvukerfi er alltaf í einhverju samhengi við aðra þætti, svo sem samskipti við notendur og önnur kerfi. Það vinnuumhverfi sem tölvukerfið verður hluti af, er þannig hluti þess sem við gætum kallað heildarkerfi. Til að vel takist til við gerð tölvukerfis þarf að gæta vel að öllum þessum ytri þáttum og skilja vel samspilið milli þeirra og tölvukerfi, taka tillit til hina ólíku krafna umhverfis. Af þessu má sjá að í kerfisgreiningu reynir á ýmsa þætti sem ekki snúast endilega um tölvur eða forritun. Í kerfisgreiningu reynir á viðtalstækni, samskipti við ólíka aðila, skipulagningu og hæfni í rituðu og töluðu máli og svo mætti áfram telja. Kerfisgreiningarferlinum er oft líkt við byggingarframkvæmdir. Svipað og þegar hús er byggt þá hefur ýmislegt átt sér stað áður en eitthvað fer að rísa úr jörðu. Starf þess sem greinir kerfi er ekki ósvipað starfi arkitekts sem þarf að greina þarfir væntanlegs notanda og/eða kaupanda og kanna hvernig hægt er að mæta þeim: 5 Alter, Steven (1996). bls Jón Freyr Jóhannsson 9

10 Arkitektinn þarf að vita til hvers á að nota bygginguna, kerfisgreinandinn þarf að vita til hvers kerfið er. Arkitektinn þarf að vita hverjir nota bygginguna, kerfisgreinandinn þarf að vita hverjir eru notendur kerfisins. Arkitektinn þarf að vita kröfur til stærðar og umfangs, kerfisgreinandinn þarf að vita stærðir eins og fjölda notenda, gagnamagn, kröfur til svartíma o.s.frv. Arkitektinn skilar ekki tilbúinni byggingu heldur teikningu eða líkani, kerfisgreinandinn skilar ekki tilbúnu kerfi heldur teikningum og ritum og jafnvel líkani (frumgerð). 2.2 Samantekt Þetta rit fjallar um nokkur grunnatriði við kerfisgreiningu og skilgreiningu hugbúnaðarkerfa. Ætlunin er að hjálpa þér við að taka fyrstu skrefin sem arkitekt hugbúnaðarkerfa. Það sem þú lærir hér er að fást við líkönin, lærir að nota hugbúnaðarverkfærin og lærir að nota táknmálið. Það sem þú lærir ekki er hvernig haldið er utan um stór verk og hvernig flókin skjölun fer fram og ekki heldur um það hvernig nota á hugbúnaðarverkfæri kerfisgreiningar þegar margir vinna í sama verkefni og hvernig verkfærin vinna með útgáfustýringu. Software Errors Cost U.S. Economy $59.5 Billion Annually Software bugs, or errors, are so prevalent and so detrimental that they cost the U.S. economy an estimated $59.5 billion annually, or about 0.6 percent of the gross domestic product, according to a newly released study commissioned by the Department of Commerce's National Institute of Standards and Technology (NIST). At the national level, over half of the costs are borne by software users and the remainder by software developers/- vendors. ( htm) 2.3 Spurningar 1. Ef kerfisgerð er líkt við byggingarframkvæmdir gætum við þá ekki lært af því hvernig staðið er að þeim? 2. Eru dæmi um svipuð mistök við byggingarframkvæmdir og finna má í hugbúnaðargerð? 3. Hver heldur þú að sé helsti munur á hugbúnaðargerð og annars konar framkvæmdum t.d. byggingaframkvæmdum? 4. Ef við líkjum gerð stýrikerfis eins og Winows XP við virkjanaframkvæmdir værum við sátt við sams konar öryggisgalla og þar er að finna? 5. Hvaða telur þú að sé mikilvægast að hafa í huga þegar byrjað er á hugbúnaðargerð? 10

11 3 Hvað er UML? UML, Unified Modeling Language, er eins og nafnið gefur til kynna mál, m.a. táknmál, til líkanagerðar. UML er byggt upp af táknmáli sem er bæði á myndrænu formi og einnig með texta og málfræði sem fer eftir föstum skilgreindum reglum. Líkönin sem gerð eru með UML eru notuð til að skilgreina, m.a. á myndrænan hátt, byggja upp og skjalfesta einingar og uppbyggingu hugbúnaðarkerfa. UML má einnig nota til að gera það sama fyrir almenn kerfi sem ekki byggja á tölvum og hugbúnaði. Það er tiltölulega auðvelt að skilja flest líkön UML, misjafnlega þó því sum eru nokkuð tæknileg. Það að hafa myndrænt táknmál gerir allan skilning og vinnu við kerfisgerð einfaldari og aðgengilegri fyrir þá sem þurfa að koma að vinnunni, það á bæði við um fagmenn og samstarfsaðila þeirra og viðskiptavini. UML gerir ráð fyrir að líkönin sé ýmist hægt að nota til að skilgreina svokölluð yfirlitslíkön sem ekki gera grein fyrir smáatriðum og einnig nákvæmari rit og útskýringar við þau. Það er mikilvægt að gera sér grein fyrir því að UML er ekki forritunarmál, verkfæri eða aðferðafræði. UML byggir sem sé ekki á forritunarmálum eins og C++, C#, Java, Visual Basic.NET eða öðru slíku. UML er heldur ekki hugbúnaðarverkfæri, en það eru hins vegar mörg verkfæri, s.s. Rational Rose, Select, StarUML, Poseidon og fleiri slík, sem bjóða þann kost að sýna útfærslu UML líkana í tilteknum forritunarmálum. UML er hins vegar alveg óháð þeim forritunarmálum og það sama má segja um gagnagrunna, þróunarverkfæri og annað slíkt. UML er ekki aðferðafræði. Með aðferðafræði þá er átt við það að segja hvernig eigi að fara í gegnum greiningu og hönnun, hvaða skref eigi að taka og hvaða afurðir/skjöl eða líkön eigi að verða til í hverju skrefi. Dæmi um aðferðafræði er

12 RUP (Rational Unified Process) 6, Scrum 7 og fleiri sem t.d. eru kenndar við Agile 8 aðferðir. 3.1 RUP þróunarferlið Í RUP eru skilgreindir fasar eða meginverkþættir (e. phases) þar sem tiltekin eru helstu verk og viðfangsefni og einnig hvaða afurðir (skjöl, líkön o.s.frv.) eigi að liggja fyrir þegar fasa lýkur. Fasarnir eru í tiltekinni röð en gert er ráð fyrir að farið sé til baka eftir þörfum og er þá talað um ítrun eða sprett (e. iteration) og er ör ítrun eitt af megineinkennum RUP. Í þessu riti er sýnd farin nokkuð hefðbundin leið í gegnum greiningar og hönnunarferli og þá byggt á línulegri leið sem oftast er kölluð fossalíkanið (sjá myndræna framsetningu hér á mynd til hliðar). Þegar talað er um fossalíkanið er vísað til þess að hönnuðir snéru ekki tilbaka til fyrri fasa, þar kemur vísunin til fossa þar sem vatnið fer ekki upp fossinn aftur (þeir sem komu með þetta nafn hafa greinilega ekki séð íslenska fossa í miklu roki!). Þetta er ekki allskostar sanngjörn söguskoðun því þó það væri ekki tilgreint með jafnskýrum hætti og RUP gerir, þá gerðu menn almennt ráð fyrir því að fara 9 til baka í fyrri verkþætti ef endurskoða þurfti greiningu eða hönnun. Þegar unnið er eftir RUP aðferðafræðinni er Mynd 1 Fossalíkanið yfirleitt gert ráð fyrir að hluti kerfis sé útfærður til fulls og síðan er ferlið endurtekið fyrir aðra hluta. Með þessu er gert ráð fyrir að búið sé að fara í gegnum helstu mögulegu vandamál, sem geta m.a. verið tengd notkun á nýrri tækni, óvana starfsmanna, án þess að vera með allt kerfið undir í einu. Þá er það einnig nefnt sem styrkur þessarar nálgunar að notendur/kaupendur fá fyrr að sjá eitthvað sem virkar og hafa þess vegna betra tækifæri til að tjá sig t.d. um það sem betur má fara áður en lengra er haldið. UML byggir á formlegum grunni, málfræði 10, og gefur möguleika á hugbúnaðarstuðningi, m.a. svokallaðra CASE-verkfæra (tölvustudd hugbúnaðargerð). Það að UML byggir ekki á neinni einni aðferðafræði eða hugbúnaði þá er UML-ið útbreitt og þekking á því orðin mikil og mikið til af skrifuðu efni um það, bæði á vef og í hefðbundnu bókarformi Frekari upplýsingar um RUP má finna á www-306.ibm.com/software/awdtools/rup/ og á en.wikipedia.org/wiki/rup 7 Frekari upplýsingar um Scrum má finna á en.wikipedia.org/wiki/scrum_%28development%29 8 Frekari upplýsingar um Agile aðferðir má finna á en.wikipedia.org/wiki/agile_software_development 9 his work is licensed under the Creative Commons Attribution ShareAlike License version 2.5: 10 Málfræði UML er ekki fullkomin að því leyti að hún sé einkvæm, þ.e. suma hluti er hægt að túlka eða setja fram á fleiri en einn veg. Forritunarmál og annað er lýtur strangri málfræði þarf hins vegar að vera einkvæmt svo ekki sé hætta á rangtúlkun.

13 Sumt af táknmáli UML er gamalt, s.s. táknmál stöðu- og verknaðarrita, en hefur verið fært í formlegt horf undir UML. Þeir sem þekkja slíkt táknmál í öðru samhengi ættu að gæta að því að skilgreining þess gæti verið önnur í UML. 3.2 Líkanagerð Líkananagerð eins og sú sem byggir á UML er sérstaklega mikilvæg í gerð stærri hugbúnaðarkerfa. Líkanagerðin nýtist einnig vel í smærri kerfum þó þar séu kostirnir ekki eins áberandi miklir, umfang er þar lítið og yfirsýn fárra starfsmanna oft góð. Líkanagerð eins og með UML gerir kerfin oftast sveigjanleg og skalanleg, þ.e. auðveldara að bæta við nýjum atriðum eða breyta eldri og að fella hugbúnað að auknum kröfum til afkasta eða rýmdar. Þetta er vegna þess að auðveldara hefur verið að sjá fyrir hvernig notkunin mætti vera betri áður en farið er í að smíða viðkomandi kerfi. Líkanagerð er það sem felst í greiningu og hönnun hugbúnaðar áður en byrjað er á forritun. Þetta ferli, áður en að forritun kemur, er oftast skipt upp í nokkur undirferli: þarfagreining, kerfisgreining og kerfishönnun, undir það fellur einnig viðmótshönnun. Nánar verður fjallað um þetta ferli síðar. Í þessari bók er litið á kerfisgreiningu sem allt það sem lýtur að upphafi kerfisgerðar og þar til kemur að endanlegri hönnun. Sumir þættir sem hefðbundið er að ktelja til hönnunar eru teknir hér með. Hugbúnaðarverkfæri eins og þau frá Rational (nokkur mismunandi verkfæri þar, þekktast er Rational Rose), Select og Poseidon að mörgum öðrum ótöldum, gera mögulegt að útbúa forritskóða út frá líkönunum sem skilgreind eru í UML (codegeneration). Sum þeirra bjóða einnig upp á það að taka þegar tilbúin forritskóða og útbúa UML-líkön útfrá honum (reverse-engineering). Þetta gerir það auðvelt að skilgreina viðbætur og lagfæringar út frá líkönum. Í upphafi er UML skilgreint af Grady Booch 11, James Rumbaugh 12 og Ivar Jacobson 13 sem allir störfuðu hjá fyrirtækinu Rational. Oft er vitnað til þeirra þriggja sem the three amigos. Það er ekki alveg ljóst hvort þarna er verið að vitna til bíómyndar með þessu nafni, en líklegri er skýringin að nafnið hafi verið til einföldunar þar sem ekki eru allir jafnsterkir í að muna, bera fram eða stafa nöfnin þeirra! Allir hafa þeir verið virkir í hugbúnaðarfræðum bæði fyrir þann tíma er þeir skilgreindu UML og einnig eftir það. UML er nú á ábyrgð, og skilgreint af, OMG (Object Management Group) 14 sem eru sjálfseignarstofnun (e. non-profit) hagsmunaðila og sérfræðinga á sviði upplýsingatækni sem gera og viðhalda stöðlum fyrir tölvu- og hugbúnaðariðnaðinn og þá sérstaklega staðla sem lúta að samskiptum milli tölvukerfa (hugbúnaðar). Nýjasta útgáfa af UML er útgáfa 2.0 og er miðað við hana í þessu riti, hún var endanlega tilbúin en.wikipedia.org/wiki/booch 12 en.wikipedia.org/wiki/james_rumbaugh 13 en.wikipedia.org/wiki/ivar_jacobson 14 Frekari upplýsingar um OMG er að finna á Jón Freyr Jóhannsson 13

14 Hægt er að fræðast frekar um UML á vefnum, heildarskilgreiningu táknmálsins er að finna á Helstu hugbúnaðarverkfæri sem notuð eru til kerfisgreiningar og hönnunar hér á landi (2007) eru: Rational Rose: www-306.ibm.com/software/rational Select: Einnig einfaldari og ódýrari verkfæri eins og Poseidon: Visio frá Microsoft er einnig notað til líkanagerðar skv. UML en er takmarkaðra en flest þau verkfæri sem sérstaklega eru ætluð greiningar og hönnunar. StarUML - The Open Source UML/MDA Platform staruml.com Önnur verkfæri sem byggja á og nota UML má m.a. finna á: Það er mjög mismunandi hversu vel hin ýmsu verkfæri fylgja útgáfum UML. Það er ekki alltaf tiltekið hvaða útgáfu UML er fylgt þó það séu ekki miklar breytingar sem eru sjáanlegar milli útgáfa. 3.3 Kostir og gallar UML UML er ekki bjargvættur allrar hugbúnaðargerðar, það eru bæði kostir og gallar. Það er ekki ætlunin að rekja það neitt sérstakleag hér nema þá til að nefna það og til þess að þú, lesandi góður, sért gagnrýninn og reynir að átta þig á möguleikunum og takmörkunum. Það sem nefnt er hér á eftir er hluti af því sem nefnt hefur verið í þessu sambandi en er ekki hugsað sem tæmandi listi. Helstu kostir sem taldir hafa verið við UML: Það er staðlað 15, þó ekki fylgi allir þeim stöðlum Það er sveigjanlegt, það getur ráðið við verkefni af ólíkasta toga, stór sem smá. Helsti styrkleiki þess er þó í notkun þess í miðlungs til stórum verkefnum. Notkun UML í skilgreiningu rauntímakerfa hefur verið að vaxa en þá hefur oftast verið notaðar viðbætur (extensions) þar sem grunnskilgreiningar UML hafa ekki nægt. UML er lýsandi, táknmálið er einfalt án þess að það sé um of einfaldað Notkun er útbreidd og þekking er orðin mikil, mikið er til af rituðu efni um UML og notkun þess og því auðvelt að afla sér þekkingar. Nánast öll verkfæri við hugbúnaðargerð gera ráð fyrir eða styðja notkun UML Það er rétt að hafa í huga að margir telja að orðið staðlað sé frátekið fyrir það sem hefur hlotið viðurkenningu alþjóðlegra staðlastofnana og því er þeim í nöp við þessa notkun.

15 Helstu gallar við notkun UML UML er ekki skilgreint þróunarferli eða aðferðafræði. UML var ekki sett fram sem slíkt og í raun sérstaklega tekið fram að svo væri ekki. Það eru til sérstakar aðferðir sem taka til þeirra atriða og sum kerfi/hugbúnaður tekur tillit til slíkra þátta s.s.. í Rational Unified Process og í tengslum við SELECT. Málfræði UML er ekki sterk og getur verið margræð, en á þessu vandamáli er tekið að einhverju leyti í nýrri útgáfu UML (útgáfu 2.0). Lengi var beðið eftir nýrri útgáfu af UML (2.0) sem tæki á helstu annmörkum. Nú er beðið frekari viðbóta. 3.4 UML-ritin Í þessu riti verður mest fjallað um táknmál og notkun (mynd-) ritanna sem UML táknmálið skilgreinir, auk þess sem fjallað verður lítillega um OCL (Object Constraint Language) sem er eins konar hálf-forritunarmál (e. pseudo-code). Þau rit og hugtök sem hér eru nefnd koma líklega flestum lítt kunnuglega fyrir sjónir, en hugtökin verða kynnt betur síðar og ekki ástæða til að hafa áhyggjur af því að ná ekki strax nöfnum eða inntaki þeirra. UML skilgreinir mörg rit, en í þessu riti verður fjallað um 7 þeirra, en þau eru: Klasarit (Class Diagram) Notkunarlíkan (Use Case Diagram), einnig kallað notkunartilviksrit Runurit (Sequence Diagram) Stöðurit (Statechart Diagram) Verknaðarrit (Activity Diagram) Samvirknirit (Collaboration Diagram) Pakkarit (Packages) Þessu til viðbótar er fjallað stuttlega um OCL (Object Constraint Language) sem er hluti af UML. OCL svipar til forritunarmáls eða Pseudo-máls 16 og gerir kleift að setja fram skilgreiningar og útskýra virkni einstakra þátta innan UML-ritanna sem við erum að útfæra. Mörg fleiri atriði tilheyra UML heldur en þau sem eru nefnd í þessu riti. Þau skipta minna máli vegna þeirra hluta sem þetta rit fjallar um, en geta komið við sögu hjá þeim sem vinna meira með UML. 16 Pseudo-mál eru einnig nefnd gervimál, líka sauðakóði (fyrir pseudo-code) 2007 Jón Freyr Jóhannsson 15

16 3.5 Samantekt UML er mál til líkanagerðar. UML er byggt upp af táknmáli sem er bæði á myndrænu formi og einnig með texta og málfræði sem fer eftir föstum skilgreindum reglum. UML er ekki aðferðafræði, ekki forritunarmál og ekki hugbúnaðarverkfæri! Við verðum að velja hvaða verkfæri UML við notum, UML er verkfærakassinn, en okkar er valið! 3.6 Spurningar 1. Hvers vegna notum við líkön við kerfisgerð? 2. Er UML aðferð? 3. Hver er helstu UML líkönin? 16

17 4 Kröfugreining Hvað gerist fyrst í kerfisgreiningu? Hvernig verður hugmynd um tölvukerfi að veruleika? Setning eins og:... ég vil fá nýtt kerfi fyrir nemendabókhald sem getur líka annast skráningu námskeiða og skráð nemendur og námskeið í kennslustofur..., er ágæt byrjun, en gefur takmarkaðar upplýsingar. Til að geta haldið áfram þarf að skoða nánar hvað felst í þessari ósk. Það er viðfangsefni kröfugreiningar. Kröfugreining er skilgreind sem eitt fyrsta verkefni í RUP þróunarferlinu (sbr. mynd). Mynd 2 Myndræn framsetning þróunarferlis skv. RUP

18 Nr Kröfuheiti (og hugsanlega stutt lýsing) Notkunardæmi (nr) Forgangur (A/B/C) Staða (ósamþ/samþ) Kerfisgreining með UML 4.1 Kröfugreining og kröfulýsing Kröfugreining (e. requirements engineering/analysis) snýst um að skilgreina tilgang kerfis og þær kröfur sem til þess eru gerðar. Kröfugreining gengur einnig undir nafninu þarfagreining. Kröfu- eða þarfagreining er oft skilgreind sem sérstakur þáttur í þróunarferli hugbúnaðar. Það er mismunandi hvað hugtakið kröfugreining er látið ná yfir stóran hluta ferlisins oft er það skilgreint sem allt ferlið frá því að hugmynd um kerfi kviknar og þar til komið er að hönnun á tæknilegri útfærslu og forritun, en stundum er það skilgreint sem aðeins fyrsti hluti greiningar. Í þessari umfjöllun hér látum við okkur nægja að horfa mjög þröngt á hugtakið, lítum svo á að þetta sé aðeins upphafshluti kerfisgreiningar þar sem kröfur notenda og kaupenda eru kortlagðar. Við fjöllum hér um afmarkaðan þátt sem er kröfulýsing, einföld lýsing og framsetning á kröfum frá verkkaupa. Niðurstöður úr kröfugreiningu, kröfulýsingin, er síðan notuð við frekari greiningarvinnu. Framsetning á kröfum sem hér verður lýst virkar ágætlega í smærri verkefnum en nauðsynlegt er að hafa í huga að í stórum eða flóknum verkefnum þarf að nota aðrar formlegri aðferðir og þá er einnig þörf skipulagðari vinnubragða en hér eru nefnd. Samhengi kröfulýsingar og annarra þátta kerfisgerðar má lýsa með eftirfarandi mynd: Líkön Notkunardæmi Notkunarlíkönin tryggja að kröfum sé mætt í prófanlegum notkunardæmum Kröfur Prófanir kanna hvaða kröfum er fullnægt. Notendur/kaupendur geta skilið niðurstöður í samhengi við skilgreindar kröfur Prófanir Texti Kröfulisti Prófanalýsingar Samhengið Kröfur - Notkunarlíkön - Prófanir 18

19 Notkunarlíkön eru oftast unnin samhliða kröfulýsingu og hér er oft lagður grunnur að prófanalýsingum. Það er ekki svo að kröfulýsing sé unnin í eitt skipti, í einum rykk. Kröfulýsing og þau verk sem eftir fylgja eru yfirleitt unnin í ítruðu ferli (e. iterative) eða sprettum, sem þýðir að tilteknum (litlum) hlutum kerfisins er fylgt alveg til enda og svo tekið til við aðra hluta. Með þessu vinnst m.a. þekking á umhverfi og viðfangsefni án þessa að of stór hluti verkefnis sé undir í einu. Kröfulýsingin er því í raun í vinnslu meginhluta tímans sem kerfisgerðin stendur. 4.2 Kröfulýsing Kröfulýsingu er oft skipt í tvennt, annars vegar almenna lýsingu í texta og svo skipulagðari framsetning á einstökum kröfum/þörfum, oft sett upp í töfluform Almenn lýsing Dæmigert innihald almennu lýsingarinnar er sem hér segir: Greint frá megintilgangi kerfis. Vísað í önnur tengd kerfi. Hugtök er varða verkefnið eru skilgreind og skammstafanir skýrðar. Forsendur verkefnis tilgreindar. Ef nýtt kerfi á að koma í stað annars þá er greint frá kostum og göllum eldra kerfis. Núverandi aðferðir eru skýrðar þannig að ljóst sé í meginatriðum hvað það er sem notendur-/kaupendur eru ánægðir með og hvað ekki. Tillögur um aðferðir. Ef tillögur hafa komið fram um aðferðir eða lausnir þá eru þær tilgreindar. Hafa ber í huga að það er hlutverk kerfisgreinandans að finna góða heildarlausn og hún gæti verið önnur en upphaflegar hugmyndir. Það getur verið slæmt að loka sig inni í fyrirfram ákveðinni lausnaraðferð. Ef kaupandi hefur hins vegar sett fram ákveðna kröfu um lausn eða ramma hennar þarf að taka tillit til þess. Mörk kerfis eru skilgreind. Í því felst að tilgreint er hvaða þættir eru utan kerfis, hvaða þættir í umhverfi hafa áhrif á kerfið s.s. önnur kerfi. Umhverfi. Fjallað um það umhverfi sem kerfið verður í. Meðal atriða sem hér er fjallað um eru: Kröfur til hugbúnaðar, stýrikerfa, samskiptakröfur við annan hugbúnað. Ef kerfið hefur veflægan hluta gæti verið tilgreint hvaða vefrápara þarf að styðja. Kröfur til vélbúnaðar. Hér gætu verið settar fram kröfur um að kerfið krefjist ekki annars vélbúnaðar en þegar er til staðar eða aðrar slíkar kröfur. Öryggiskröfur, bæði til tölvuumhverfis (vél- og hugbúnaðar) og annarra umhverfisþátta. Kröfur til þjónustu við kerfið og aðstoðar við notendur. Aðrar kröfur þ.m.t. staðlar sem uppfylla þarf Jón Freyr Jóhannsson 19

20 4.2.2 Kröfulisti Greint er frá kröfum til virkni í kröfulista sem yfirleitt er á töfluformi (er á kumlvef): Nr Kröfuheiti (og hugsanlega stutt lýsing) Notkunardæmi (nr) Forgangur (A/B/C) Staða (ósamþ/samþ) Dálkarnir í þessari töflu sem hér er sýnd eru eftirfarandi: Númer til að auðkenna kröfuna. Oftast er notað hlaupandi númer og ekki lögð nein sérstök merking í númerið. Stundum eru bókstafir notaðir til að greina milli mismunandi kröfuflokka t.d. V1, V2 o.s.frv. fyrir virknikröfur, G1, G2 o.s.frv. fyrir kröfur til gagna. Slík flokkun getur vel hentað sumum verkefnum, en oft eru kröfurnar ekki svo þröngt skilgreindar að þær falli bara í einn flokk og því verður þessi flokkun oft tímafrek og tekur dýrmætan tíma frá greiningunni. Önnur leið til að leysa slíka flokkun er að hafa sérstakan dálk fyrir flokk og þá er hægt að tilgreina fleiri en einn flokk. Kröfuheiti og stutt lýsing ef hægt er. Lengri lýsingar ættu að vera annars staðar en í töflunni og geta þá verið í sérstöku skjali eða fylgt eftir töflunni. Notkunardæmi. Tilgreint er hvaða notkunardæmi eiga við kröfuna, hvar hún er útfærð. Þetta atriði er sjaldnast ljóst í upphafi, þetta er fyllt þegar búið er að fara í gegnum meiri greiningu og setja upp notkunarlíkön. Fleira en eitt notkunardæmi getur verið tilgreint hér því krafa getur verið víðtæk. Forgangur. Kröfur geta verið mismikilvægar og forgangur því settur í samræmi við það. Oft er miðað við að kröfur sem eru í hæsta forgangi (t.d. skilgreint sem A-kröfur) séu þær kröfur sem skilyrðislaust þarf að leysa og komi örugglega í fyrstu útgáfu. Í næsta forgangsflokki (t.d. skilgreint sem B-kröfur) séu þær kröfur sem eru mikilvægar en mega bíða næstu útgáfu eða næstu endurskoðunar á forgangsröðun. Einfaldast er að hafa flokkana ekki fleiri en þrjá og í þriðja forgangsflokknum (t.d. skilgreint sem C-kröfur) eru þær kröfur sem ekki eru nauðsynlegar en gæti verið gott að hafa ( nice-to-have ) en ekki ástæða til að leggja neina áherslu á. Nú kann einhver að velta fyrir sér af hverju á yfir höfuð að vera með þessar kröfur sem jafnvel er ekki séð fram á að komi til greina fyrr en eftir langan tíma, ef þá nokkru sinni. Svarið við slíkum vangaveltum er það að það er mikilvægt að gera sér strax grein fyrir því hvert stefnt er með kerfið þannig að strax í upphafi sé gert ráð fyrir því að það sé vel mögulegt að útfæra slíkar kröfur seinna. Það er mun ódýrara að taka slíkar kröfur með í upphafi og gera ráð fyrir þeim í greiningu og hönnun þó þær verði ekki útfærðar á næstunni. Til að tilgreina forgang nánar en með þessari einföldu flokkun má einnig gefa forgangsnúmer en hér munum við ekki nota það. Staða. Hér er t.d. hægt að tilgreina hvort krafa hefur verið samþykkt, í bið eða ósamþykkt. Oftast er í fyrirtækjum um að ræða formleg ferli þar sem skilgreint 20

21 er hvernig kröfur eru samþykktar m.a. af því að krafa getur haft í sér fólgin mikil peningaútlát eða breytingar og slíkt þarf að samþykkja formlega. Í verksamningum eru slíkar samþykktir og ferli þeirra skilgreindar mjög skýrt og nákvæmlega. Dæmi um hluta kröfulista fyrir bókasafnskerfi: Nr Kröfuheiti (og hugsanlega stutt lýsing) 3 Aðfangaskráning: Kerfið skal geta skráð aðföng (innkeyptar bækur) bókasafns þannig að þær séu tilbúnar til útláns 4 Lánþegaskrá: Kerfið skal geta skráð og haldið utanum skráningu lánþega a.m.k. á sama hátt og gert er í núverandi kerfi 7 Staða lánþega: Á hverjum tíma skal alltaf vera hægt að fá fram fyrir hvern lánþega hvaða bækur, eða önnur safnföng, hann hefur í láni og skal þar koma fram skiladagur hvers eintaks og áfallin sekt ef hún er. Hægt skal vera að fara beint í þessar upplýsingar frá öllum skjámyndum/vettvöngum kerfis Upplýsingar um bók: Hægt skal vera að fá fram upplýsingar um bók (eða önnur safnföng) frá öllum skjámyndum/vettvöngum kerfis. Upplýsigar sem þar koma fram er lýst í skjali BókUpp23. Bók skal vera hægt að finna eftir a.m.k. titli og ISBN (leit er notuð ef þarf að finna eftir öðrum leiðum) Útlán: Útlán skal vera hægt að skrá lán á lánþega. Ef staða lánþega er þannig að hann fái ekki lán skal það koma upp í kerfinu (forsendur er að finna í skjalinu StoppLán03 ). Til að skrá lán þarf að skanna inn strikamerki bókar eða slá inn skráningarnúmer við strikamerkið Tölfræði útlána: Hægt skal vera að kalla fram tölfræðiupplýsingar (sbr. skjal Töl12 ) þannig að hægt sé að skoða útlán einstakra titla, höfunda, útgefanda og bókaflokka eftir bæði árum og mánuðum. Tölfræði útlána: Hægt skal vera að kalla fram tölfræðiupplýsingar (sbr kröfu 22) eftir mismunandi dögum (vikudögum) sbr. hugmyndir sem er að finna í skjali Töl13. Notkunardæmi (nr) Forgangur (A/B/C) 12, 13 A Samþ Staða (ósamþ/samþ) 23, 24 A Samþ 26 A Samþ 2, 3,4 A Samþ 8, 9 A Samþ 15, 16, 25 A Samþ 35 C Ósamþ 2007 Jón Freyr Jóhannsson 21

22 4.3 Mismunandi tegundir af kröfum Sumar af þeim kröfum sem við (eða réttara sagt kaupandinn) þurfum að tilgreina eru nokkuð augljósar, það eru þær sýnilegu sem auðvelt er að finna og tilgreina. Vandi okkar liggur hins vegar í því að það eru mjög margar kröfur sem okkur er nauðsynlegt að fá fram en sem eru ekki eins augljósar. Það er ágætt að nýta sér eftirfarandi flokkun og aðgreiningu á kröfum til að eiga auðveldara með að draga þessar síður augljósu kröfur fram í dagsljósið Kröfur til virkni Kröfur til virkni eiga það sameiginlegt að nokkuð auðöveldlega er hægt að prófa hvort slíkum kröfum er mætt. Virknin er prófanleg og hægt að mæla hana. Mikilvægt er að setja mælikvarða og viðmið á þessar kröfur svo auðveldara sé að sannreyna að virknin sé sú sem ætlað var. Dæmi um kröfur til virkni eru: 1. Forsendur (einnig talað um forskilyrði): gert er ráð fyrir að Kröfur til tiltekinnar virkni (e. functional requirements) 3. Takmarkanir með tilliti til upplýsinga og gagna (e. data constraints) a. Notandi getur bara haft eina skrá opna í einu b. Notandi má bara fá 3 bækur c. Aðeins eitt eintak hverrar bókar má vera í láni hjá sama lánþega 4. Upplýsinganotkun a. Forstöðumaður skal geta á hvað tíma sem er séð útistandandi lán sem komin eru yfir skiladag b. Starfsmaður getur stofnað nýjan lánþega c. Starfsmaður getur stofnað nýja færslu fyrir bók 5. Notendaskil og skýrslur a. Starfsmaður skal geta flett upp og haft á skjánum upplýsingar um fleiri en einn lánþega í einu 6. Þegar niðurstöður uppflettingar eru birtar skal einnig birtast hvaða leitarskilyrði voru notuð við leitina/uppflettinguna Kröfur til eiginleika, annarra en virkni Þegar talað er um kröfur til eiginleika, annarra en virkni (e. nonfunctional requirements / system qualities) er oftast er um að ræða kröfur sem tilgreina hversu vel tilteknum kröfum er fullnægt. Skipta má slíkum kröfum í tvo meginflokka: 1. Kröfur sem hægt er að staðfesta við keyrslu kerfis: a. Afköst / frammistaða (e. performance) A.m.k. fjórir starfsmenn skulu geta unnið í kerfinu í einu. Ef breytingar hafa orðið á gögnum skulu upplýsingar á skjám hafa uppfærst innan 5 sek. b. Öryggi (e. security) c. Uppitími / aðgengileiki (e. availability) Kerfið verður að hafa a.m.k. 97% uppitíma á þjónustutíma (opnunartíma bókasafns) og 90% utan þess (vegna vefnotkunar) 2. Kröfur sem ekki er hægt að staðfesta við keyrslu kerfis: 22

23 a. Stækkanleiki/skalanleiki (e. extensibility/scalability) b. Flytjanleiki (e. portability) c. Endurnýtanleiki (e. reusability) 4.4 Hvernig gerum við? Hvaðan fáum við upplýsingar til að setja í kröfulýsingu? Fólk: Sjáum það betur þegar við fjöllum um gerendur í tengslum við notkunarlíkön. Kerfi: Núverandi kerfi og þau kerfi sem nýtt kerfi á að eiga samskipti við. Ýmis skjöl: Markaðsrannsóknir, handbækur, greinar og bækur um efnið eða aðferðirnar sem nota á. Algengt er að nota rit eins og notkunarlíkön og klasarit til að hjálpa við greiningu þarfa. Aðferðir sem við getum einnig beitt við að fá fram kröfur eru: Viðtöl, spurningalistar og kannanir Greining á skjölum og öðrum gögnum Vinnufundir Hlutverkaleikir þar sem reynt er að draga fram hvað gæti gerst við tilteknar aðstæður, sjá nánar í umfjöllun um atburðarás (e. scenarios). Notkun frumgerða (e. prototyping). Frumgerðir eru einföld líkön af hugsanlegu kerfi, oftast er um að ræða skjámyndir án mikillar virkni á bak við þær. Til eru sérstök verkfæri til að vinna frumgerðir. Myndbandsupptökur af því hvernig unnið er við núverandi kerfi. Gátlistar sem farið er eftir, sjá slíka gátlista á kuml-vef HV-spurningar sjá gátlista á vef 4.5 Samantekt Kröfulýsing er eitt af fyrstu verkefnum við kerfisgerð. Kröfulýsing er oft unnin samhliða notkunarlíkönum. Afurðir kröfulýsingar eru oftast almenn lýsing á kerfi ásamt svokölluðum kröfulista. Hafa ber í huga... Gátlisti Jón Freyr Jóhannsson 23

24 4.6 Spurningar 1. Hvernig má setja kröfulýsingu sem hér er lýst í samhengi við það þegar við kaupum hús eða bíl? a. Er líklegt að kröfulýsing fyrir bílakaup sé mismunandi eftir því hvort um er að ræða bílasérfræðing eða venjulegan ökumann sem lítið þekkir nema það sem blasir við frá bílstjórasætinu? b. Hver væri helsti munur á kröfulýsingu húss eftir því hvort hún sé gerð af byggingarmeistara, arkitekt eða venjulegan húsakaupanda? 2. Hvernig getum við best tryggt að við gleymum engu við kröfulýsingu? 3. Hvaða aðferð telur þú best henta þér við að vinna kröfulýsingu? Sjá verkefni á vef 24

25 5 Notkunarlíkan Notkunardæmi 17 (e. use case) eru notuð til að tákna og afmarka tiltekna virkni kerfis. Það er sagt að þau séu safn aðgerða sem kerfið framkvæmir. Með því er átt við að notkunarlíkönin segja til um það hvað kerfið sjálft gerir og hvaða samskipti það á við þá sem standa fyrir utan kerfið, hvort sem það eru einstaklingar eða önnur kerfi. Uppflettikerfi bókasölu Rithöfundur Skoða söluyfirlit minnar bókar Skoða sölulista bóksala Skoða sölutölfræði einstakra bóka Notkunardæmin ásamt gerendum og venslum þeirra á milli eru sett saman í notkunarlíkön (e. use case diagram). Notkunarlíkön eru einnig kölluð notkunartilviksrit. Útgefandi Sækja nýjustu sölutöluskýrslu Sölutöluþjónusta bóksala Helsti tilgangur notkunarlíkana er að hjálpa þróunarhóp (þeim sem vinna við kerfisgerðina) að fá yfirsýn á myndrænan hátt yfir kröfur til virkni kerfisins og þá sérstaklega hvernig samskipti kerfis við notendur eiga að vera. Notkunarlíkön eru einnig mikið notuð til að sýna notendum eða kaupendum kerfa hvernig virkni þeirra og notkun er byggð upp og gefa þeim möguleika á að koma með ábendingar eða leiðréttingar. Góð kerfi byggja á notendamiðaðri greiningu og hönnun. Það má til einföldunar segja að notkunarlíkön sýni kerfi frá sjónarhóli notenda og stuðli þannig að notendamiðaðri greiningu og hönnun. Önnur rit UML eru yfirleitt tæknilegri og miðast frekar við þarfir kerfisgreinenda og kerfissmiða. 17 Notkunardæmi hafa einnig verið kölluð notkunartilvik.

26 Í þessum kafla er farið yfir: Grunntáknmál notkunarlíkana Hvernig notkunarlíkön eru unnin Fjallað um táknmál til viðbótar við grunntáknin Hvernig við lýsum notkunarlíkönum í texta, m.a. með því að skrifa svokallaða atburðarás Hvað ber að hafa í huga og hvað ber að varast 5.1 Táknmál notkunarlíkana - Grunntáknin Táknmál notkunarlíkana er einfalt. Grunntákn eru gerandi (e. actor), notkunardæmi (e. use case) og vensl (e. relation) milli geranda og notkunardæmis Gerandi Gerandi (e. actor) er táknaður með Óla prik kalli. Gerandi er yfirleitt einhver tiltekinn (mennskur) notandi en getur einnig verið annað kerfi, tæki eða slíkt. Eiginlega er um að ræða hlutverk (e. role) frekar en einstakling. Gerandi er notaður til að tákna allt sem stendur fyrir utan kerfið en sem hefur þó einhver samskipti við það. Heiti sem lýsir geranda eða hlutverki hans er sett undir táknið. Heitið höfum við nafnorð í eintölu nema eitthvað sérstakt krefjist annars. Ef við höfum t.d. notendur sem við viljum tákna sem gerendur og þeir væru best flokkaðir og skilgreindir undir þessu sjónarhorni sem Starfsmenn þá köllum við gerandann Starfsmaður af því að í hverju tilviki fyrir sig þá er það ekki hópurinn Starfsmenn sem eru gerendur heldur Starfsmaður. Sum hugbúnaðarverkfæri gefa kost á að lita haus gerandans. Þetta er oft notað til að gera greinarmun á gerendum, s.s. að gera mun á mennskum gerendum og ómennskum (tækjum eða kerfum), en það er rétt að fara sparlega með þennan möguleika, hann skyldi ekki nota til skreytingar Notkunardæmi Notkunardæmi (e. use case) er táknað með liggjandi sporöskju. Gerandi (Actor) Tákn geranda (e. Actor) Heiti notkunardæmis er sett inn í miðja sporöskjuna. Heitið gefur til kynna hvað notkunardæmi felur í sér og venjan er að hafa heitið sem stutta setningu, sagnorð og nafnorð í eintölu (það má vera í fleirtölu ef það á við). Notkunardæmi eru einnig kölluð notkunartilvik. Notkunardæmi (UseCase) Tákn notkunardæmis (e. Use Case) Sum hugbúnaðarverkfæri gefa kost á að velja stærð sporöskjunnar, (t.d. Visio og Rational Rose) önnur láta stærðina ráðast af lengd texta/nafns notkunardæmis 26

27 (t.d. Select og Poseidon). Rational Rose leyfir okkur að ráða stærðinni á notkunardæmistákninu en setja nafnið fyrir neðan en ekki inn í táknið. Stærð sporöskjunnar skiptir auðvitað ekki máli, en misstór tákn geta áreitt fegurðarskyn kerfisgreinandans og einnig er hætta á því að einhverjir mistúlki stærðina sem mikilvægisflokkun Vensl Vensl (e. relation) milli geranda og notkunardæmis eru táknuð með beinu óbrotnu striki milli þeirra. Venslin er án örvaodda, það er ekki verið að gefa til kynna að eitthvað flæði í aðra hvora áttina, einungis það að vensl eru milli gerenda og notkunardæmis. Tákn vensla (e. Relation) Venslin þýða það að gerandinn getur notað eða vakið upp notkunardæmið eða að notkunardæmið skili einhverju til geranda eða geri ráð fyrir honum. Þessi vensl eru það eina sem tengir gerendur og notkunardæmi, önnur vensl sem fjallað er um síðar eiga ekki við milli þessara fyrirbæra. Venslin hafa yfirleitt ekki heiti, önnur vensl t.d. milli klasa hafa oftast heiti, en vensl í notkunarlíkönum geta haft margfaldara sem fjallað er um annars staðar. Margfaldarar eiga hins vegar sjaldnast við í notkunarlíkönum, mörgum þykja þeir flækja ritin og það er óhætt að sleppa þeim. Sum hugbúnaðarverkfæri setja örvaodda á venslin en yfirleitt er til staðar sá valkostur að láta örvaoddana ekki sjást (yfirleitt kallað navigable), venjan er að hafa ekki örvaodda á þessum venslum Einfalt notkunarlíkan Einfalt notkunarlíkan getur samanstaðið af einum geranda, einu notkunardæmi og venslum þar á milli eins og myndin hér til hliðar sýnir. Ritið hér sýnir einfaldlega það að gerandinn Lánþegi bókasafns getur vakið upp notkunardæmið Fá lánaða bók, það segir hins vegar ekki endilega hvort hann fær bókina lánaða því það fer eftir því hvað felst í notkunardæminu! Lánþegi bókasafns Fá lánaða bók Notkunarlíkan sem sýnir vensl Lánþega bókasafn og notkunardæmisins Fá lánað bók 2007 Jón Freyr Jóhannsson 27

28 5.2 Hvernig gerum við? Notkunarlíkön verða ekki til á einhvern einn hátt. Þegar reynslan verður meiri þá verða þau nánast til af sjálfu sér! Það gengur hins vegar ekki sem leiðbeining fyrir þá sem eru að byrja. Það eru hér á eftir nokkrar leiðbeiningar um það hvernig má standa að verki, en hafðu í huga að þetta eru ekki neinar reglur. Auðveldast er að vinna notkunarlíkönin út frá tilbúinni kröfulýsingu. Það er hins vegar ekki alltaf sem þær eru til og stundum eru notkunarlíkönin notuð til að útbúa kröfulýsingu. Gerum samt ráð fyrir að kröfulýsing í einhverju formi sé þegar til og þá gæti verkröðin verið svona: Bankanotandi Leggja inn á reikning <<extend>> 1. Finna þá gerendur sem eru augljósir frá kröfulýsingunni 2. Finna og skilgreina notkunardæmin 3. Finna vensl milli gerenda og notkunardæma 4. Finna vensl milli notkunardæma 5. Vinna lýsingu notkunardæma 6. Endurtaka og bæta ofangreint eftir þörfum Finnum gerendur Reikningseigandi Senda SMS um hreyfingu Notkunarlíkan sem sýnir virkan geranda og óvirkan geranda (þátttakanda) notkunardæma Hvernig förum við nú að því að finna þessi notkunardæmi og gerendur? Við gætum byrjað á því að finna til notendur kerfisins og byrjað að tiltaka þá sem gerendur. Til að finna notendur getum við t.d. leitað í kröfulýsingunni. Þegar við tilgreinum þessa notendur þá gagnast lítið að tilgreina þá sem Gunnu og Jón, við reynum að finna þeim eitthvert samheiti sem byggist yfirleitt á hlutverki notendanna en ekki einstaklingseinkennum þeirra. Í einföldustu dæmum þá gætu gerendur t.d. verið Viðskiptavinur og Starfsmaður. Í bókasafnsdæmi gætu fyrstu hugmyndir um gerendur verið t.d. Lánþegi og Bókasafnsstarfsmaður af því að þessir flokkar einstaklinga hafa stærstu hlutverkin og hlutverkin eru aðgreind, þ.e. Lánþegi gerir ekki það sem Bókasafnsstarfsmaður gerir og öfugt (nema starfsmaðurinn sé í hlutverki Lánþega. Það er alveg hægt að gera ráð fyrir því að fyrstu hugmyndir um gerendur breytist þegar lengra líður á greininguna bæði hvað varðar nefningar gerenda og hvað þeir standa fyrir. Það er engin ástæða til að óttast það þó slíkt breytist þegar á líður, það er eðli greiningarvinnu að líkönin breytast, það að ætla sér að hafa allt rétt í upphafi og eyða miklum tíma í vangaveltur er ekki líklegt til að skila okkur áleiðis. 28

29 Til viðbótar við að leita gerenda í notendum og hlutverkum þeirra, þá getum við leitað gerenda með því að skoða hvort önnur kerfi eða tæki eru notuð. Byrjum að skoða hvað gerendur tákna og hverjir þeir geta verið út frá skilgreiningu á gerendum: Getur verið mennskur, vélbúnaður eða annað kerfi Getur táknað hvað sem er utan kerfisins. Getur verið þjónustuþegi (e. beneficiary) notkunardæmis Skilgreinir hlutverk notenda kerfisins Hægt er að horfa bæði til þeirra sem taka þátt og þeirra sem eru óvirkir þjónustuþegar/þátttakendur, gerandi getur verið virkur þátttakandi í samskiptum við kerfið eða óvirkur viðtakandi upplýsinga Tiltekinn notandi getur verið í hlutverki margra geranda. Þú getur verið í hlutverkunum nemandi, kennari og starfsmaður í skólakerfinu okkar. Í skólakerfi gæti fyrsta hugmynd að gerendum verið á þessa leið: Lektor Nemendabókhald Prófessor Reikningakerfi Nemandi Fyrstu hugmynd um gerendur skólakerfis (bæði mennskir gerendur og kerfi) Það kemur síðan í ljós um leið og þessi fallega mynd hefur verið gerð að þetta er nú ekki besta nálgunin og það vantar inn á hana. Í fyrsta lagi vantar starfsmenn skrifstofu og nemendabókhalds og síðan að það er algjör óþarfi að gera greinarmun á kennurum eftir því hvaða titil þeir hafa. Næsta útgáfa gæti því verið þessi: Kennari Nemendabókhald Skráningarstarfsmaður Reikningakerfi Nemandi Önnur hugmynd um gerendur skólakerfis (bæði mennskir gerendur og kerfi) Nú sjáum við að gerandinn Skráningarstarfsmaður nær til þeirra starfmanna sem hafa með skráningarkerfið að gera, það er allt eins líklegt að breyta þurfi þessu seinna eða skilgreina nýjan geranda sem er bara almennur starfsmaður eða einhver sem getur bara flett upp Jón Freyr Jóhannsson 29

30 Taktu líka eftir að þarna er búið að auðkenna Nemendabókhald og Reikningakerfi með lit í haus Óla-priks. Þetta er ekki skv. UML en það getur verið ágætt að nota liti hóflega til að draga fram sérkenni eins og þarna er gert með því að greina ómennska gerendur, t.d. kerfi, frá öðrum gerendum Finnum notkunardæmin Þegar við leitum að því hver notkunardæmin eru þá höfum nokkrar leiðir. Við finnum þau í kröfulýsingunni þar sem þarfir/kröfur notenda eru skilgreindar. Þar leitum við að því sem gert er þ.e. hvað það er sem kerfið á að framkvæma. Skoðum betur hvernig notkunardæmi eru skilgreind: Gerandi vekur upp notkunardæmi (til að fá fram virkni kerfisins) Notkunardæmi eru röð aðgerða sem skila sjáanlegri niðurstöðu fyrir tiltekinn geranda Notkunardæmi eru heilstætt og merkingarbært flæði atburða, þ.e. ekki bara hluti af einhverju, heldur eitthvað sem getur staðið sjálfstætt. Öll virkni kerfisins samanstendur af öllum notkunardæmum þess (aðgerð er ekki til ef hana er ekki að finna í einhverju notkunardæmi) Það sjónarhorn sem lýst er með notkunardæmum (e. use case view) er það sem sýnilegt er utanaðkomandi notendum. Þeir eru kallaðir gerendur (e. actor). Notkunardæmi er samstæð eining aðgerða sem m.a. lýsir samspili gerenda og kerfisins. Með notkunardæmunum náum við fram hverjir gerendurnir eru og hverjir þeirra eiga í hlut í hverju notkunardæmi fyrir sig. Notkunardæmi sýna ekki hvernig aðgerðir eru útfærðar. Í kröfulýsingu bókasafnskerfis gætum við séð að það þarf að vera hægt að fá bækur lánaðar, skila þeim, panta bækur o.s.frv. Þessi atriði sem hér eru talin upp eru öll ágætis hugmyndir að notkunardæmum. Þau uppfylla m.a. að vera vakin upp af gerendum og þau standa hvert um sig fyrir sjálfstæð og heilstæð ferli sem skilar niðurstöðu. Við getum líka leitað í skilgreiningu á gerendum og þeim hlutverkum sem þeir sinna. Spurningar sem við þurfum að spyrja: Lánþegi Fá lánaða bók Skila bók Panta bók Hvað er það sem hver og einn gerandi Dæmi um notkunardæmi í bókasafnskerfi gerir, framkvæmir, þarfnast? Hefur gerandi aðgang að upplýsingum í kerfinu eða getur hann breytt þeim? Mun gerandi koma til skila inn í okkar kerfi því sem fram fer í öðrum kerfum og breytingum þar? Þarf gerandi að fá að vita af óvæntum breytingum, villum eða öðrum uppákomum í kerfinu? 30

31 Um leið og við kortleggjum og skjalfestum notkunardæmi þá finnum við oft fleiri sem við höfðum ekki gert ráð fyrir og getum bætt þeim við. Til viðbótar við kröfulýsingu getum við líka leitað í atburðarásum ef þær hafa verið skilgreindar. Höfum í huga að nafn á notkunardæmi sem virðist vera einfalt getur falið í sér flókið ferli. Tökum sem dæmi notkunardæmið Fá lánaða bók sem virðist ekki vera flókið notkunardæmi en ef við skoðum það betur þá þarf að athuga hvort lánþeginn er skráður, hvort hann er nokkuð með of margar bækur í láni (eða einhverjar aðrar reglur sem í gildi eru), hvort bókin er frátekin fyrir annan lánþega og hugsanlega eitthvað fleira. Notkunarlíkön geta verið misflókin eftir eðli kerfanna sem þau lýsa, en það er einnig í valdi þess sem gerir ritið að ákveða hversu djúpt á að brjóta niður virknina. Með því er átt við að í stað þess að vera með eitt notkunardæmi sem táknar einhverja tiltekna virkni þá væri hægt að hafa mörg notkunardæmi sem hvert um sig táknar hluta af virkni þess fyrrnefnda. Þegar meta þarf hvað eigi að vera í einu notkunardæmi má hafa það í huga að ef stutt lýsing á tilgangi eða markmiði notkunardæmis rúmast ekki í einni skýrri setningu þá er hugsanlega of mikið fólgið í notkunardæminu. Ef stutta lýsingin hins vegar nær ekki að lýsa heildstæðu flæði (einhverju sem gæti staðið eitt og óstutt) þá er hugsanlega um of lítið notkunardæmi að ræða. Þessi viðmið eru að sjálfsögðu einungis til að gefa hugmyndir um viðmið, reynslan er hér mikilvæg og hún kemur smátt og smátt, verið óhrædd við að prófa ykkur áfram. Notkunardæmi er safn eða röð aðgerða sem oftast eru vaktar upp af geranda og framkvæmdar af kerfi. Stundum er gerandi bara óvirkur þátttakandi notkunardæmis, þ.e. hann fær upplýsingar en vekur ekki sjálfur upp notkunardæmið. Bankanotandi Leggja inn á reikning <<extend>> Dæmi um þetta gæti verið að ég legg inn á bankareikning þinn og þú færð síðan SMS-boð frá bankanum um að lagt hafi verið inn á reikninginn. Bæði ég og þú værum í hlutverki gerenda (Innleggjandi og Reikningseigandi), ég vek upp notkunardæmið en þú ert líka þátttakandi þess. Reikningseigandi Senda SMS um hreyfingu Notkunarlíkan sem sýnir virkan geranda og óvirkan geranda (þátttakanda) notkunardæma Á notkunarlíkaninu má sjá tegund vensla milli notkunardæma sem ekki hafa verið sýnd áður, þau verða útskýrð síðar Jón Freyr Jóhannsson 31

32 5.2.3 Hlutverk, gerendur og einstaklingar Það þarf að gera greinarmun á gerendum (sem hlutverkum) og einstaklingunum sem gegna þeim hlutverkum. Tiltekinn einstaklingur getur verið í hlutverki fleiri en eins geranda í notkunarlíkaninu okkar. Dæmi um það að gerandi er í fleiri en einu hlutverki að sjá á ritinu hér til hliðar. Edda er Deildarstjóri og er þannig að fást við að skrá einhverjar grunnupplýsingar í kerfið eða sækja upplýsingar sem ekki er ætlunin að aðrir geri, en svo er hún einnig í hlutverkinu Sölumaður og þarf þannig að geta sinnt því hlutverki meðfram því að vera deildarstjóri. Edda getur því tilheyrt báðum þessum hlutverkum og þar með gerendum. Þessu til viðbótar gæti allt eins verið að hún væri líka í hlutverkinu Starfsmaður ef það er til og ef það á við. Edda getur verið í hlutverki deildarstjóra og hún getur verið í hlutverki sölumanns Deildarstjóri Sölumaður Hin hliðin er svo augljósari að í tilteknu hlutverki geta verið fleiri en einn einstaklingur. Eins og sjá má á ritinu hér til hliðar þar sem bæði Ásta og Gunnar eru í hlutverkinu Gjaldkeri. Auk þess gætu þau verið í öðrum hlutverkum líka. Gunnar getur verið í hlutverki gjaldkera Ásta getur verið í hlutverki gjaldkera Gjaldkeri 32

33 5.3 Hvað er passlegt?... of stórt?.. eða of lítið? Hvert notkunarlíkan fyrir sig sýnir venjulega nokkur notkunardæmi og einn eða fleiri gerendur. Tiltekið notkunarlíkan getur líka sýnt afmarkaðan hluta kerfis til að útskýra hann betur eða til að óskyld atriði trufli ekki áherslu þess rits. Notkunarlíkanið getur líka sýnt kerfið í heild sinni og það á þá sérstaklega við um einfaldari kerfi. Það er í valdi þess sem gerir ritið hvort og hvernig skipta beri upp ritinu. Actor1 Actor5 UseCase9 UseCase20 UseCase20 Actor3 Actor10 UseCase28 UseCase14 «uses» UseCase20 UseCase34 «uses» UseCase11 UseCase12 Actor12 Actor4 Þegar skiptingin er ákveðin ættum við að hafa í huga að: mikil uppskipting (mörg rit) getur flækt málið og minnkað yfirsýn sem ritin gefa (sjá mörg einföld rit hér til hliðar), of fá rit (lítil uppskipting) getur gert ritið of flókið, flókin rit (lítið skipt upp) eru ekki eins góð til útskýringar, sérstaklega ekki fyrir notendur sem hafa ekki sömu reynslu af framsetningunni og reyndir kerfisgerendur (sjá flókið rit hér til hliðar). Skipting notkunarlíkana ræðst oft af því hvernig skipta má upp virkni kerfis, t.d. notendahluti, stjórnendahluti, skráningarhluti, söluhluti, útlánahluti, eftirlitshluti o.s.frv. UseCase21 UseCase20 «uses» «uses» «extends» Þegar við lítum á notkunarlíkan kerfis (hvort «uses» «extends» UseCase21 UseCase21 UseCase12 sem þau eru eitt eða fleiri) þá sjáum við í heild UseCase16 UseCase32 virkni kerfisins og þá í leiðinni má segja að við «uses» UseCase13 UseCase21 UseCase15 «uses» sjáum einnig hvað kerfið gerir EKKI. Það er «uses» Actor6 «uses» UseCase33 «uses» gert ráð fyrir því að öll notkunardæmin sem UseCase30 UseCase23 UseCase25 sýnd eru á ritunum feli í sér ALLA virkni UseCase31 UseCase29 kerfisins. Actor9 Actor8 Það má því segja að ef ekki er að finna notkunardæmi sem felur í sér tiltekna virkni þá er hún ekki til staðar í kerfinu. Það er mikilvægt að kerfisgerendur geri sér grein fyrir þessu og sérstaklega er mikilvægt að notendur og kaupendur geri sér grein fyrir því einnig þannig að ekki sé verið að gera ráð fyrir einhverju sem ekki hefur verið skilgreint. Tiltekið notkunardæmi getur komið fyrir í fleiri en einu riti innan sama kerfis ef það er til að það sé skýrara, en það er þá með sömu skilgreiningu hvar sem það kemur fyrir. Það sama á við um gerendur, en þar er oftar um að ræða að þeir tengist nýjum notkunardæmum. Actor6 Actor1 Actor8 Actor5 UseCase26 UseCase20 «extends» UseCase24 UseCase20 UseCase9 «uses» UseCase32 «uses» UseCase33 «uses» «uses» UseCase20 UseCase27 UseCase14 «uses» UseCase28 UseCase20 Actor3 UseCase10 «uses» UseCase20 «uses» «extends» UseCase22 «uses» «uses» Actor9 UseCase35 «extends» Actor10 UseCase21 UseCase18 UseCase16 UseCase21 UseCase19 UseCase34 «uses» UseCase11 «uses» Actor12 Actor11 Actor11 UseCase17 Actor Jón Freyr Jóhannsson 33

34 5.4 Meira táknmál Einföldustu notkunarlíkönum nægir það táknmál sem þegar hefur verið nefnt, eins og á notkunarlíkaninu hér til hliðar af uppflettikerfi í bóksölu, en oftast þurfum við meira. Það getur verið skynsamlegt og hentugt að notkunardæmin geta verið þannig að þau noti hvort annað þannig að betur komi fram hvernig flóknara samspil á sér stað. Þá getur líka verið gott að sýna hvernig ein tegund gerenda getur gert það sama og önnur (sjáum það betur hér á eftir). Uppflettikerfi bókasölu Rithöfundur Útgefandi Skoða söluyfirlit minnar bókar Skoða sölulista bóksala Skoða sölutölfræði einstakra bóka Sækja nýjustu sölutöluskýrslu Sölutöluþjónusta bóksala Erfðir / alhæfing Við höfum þegar skoðað það hvernig einstaklingar geta verið í fleiru en einu hlutverki og þannig tilheyrt fleiri en einum gerendahópi. Á svipaðan hátt er það svo að gerandi getur tilheyrt hópi annarra gerenda. Dæmi um þetta er gerandinn Deildarstjóri sem hefur sérstakt hlutverk, en jafnframt getur hann gert allt sem gerandinn Starfsmaður getur gert. Táknmál UML gefur okkur kost á því að tákna slíkt samhengi á þann hátt að gerandinn Deildarstjóri erfi það sem gerandinn Starfsmaður getur gert. Hinn möguleikinn til að notað þetta táknmál innan notkunarlíkana er þegar tiltekið notkunardæmi getur gert allt sem annað notkunardæmi gerir (og svo eitthvað til viðbótar). Tákn erfða/alhæfingar (e. Generalisation) Korthafi Erfðir, einnig kallaðar alhæfingarvensl, (e. generalisation) eru táknaðar með óbrotnu striki og lokuðum ófylltum oddi sem bendir til þess sem erft er frá. Á hinum endanum er sá sem erfir og sá bætir við virkni/getu þess sem erft er frá. Erfðir eru vensl milli tveggja gerenda, venslin geta einnig verið milli tveggja notkunardæma. Milli gerenda geta verið alhæfingavensl, stundum kölluð erfðir (e. generalisation). Ekki er gert ráð fyrir neinum öðrum venslum milli gerenda en þessara. Alhæfingavensl er einnig hægt að nota milli notkunardæma en það er frekar sjaldan notað þar sem það flækir frekar ritin fyrir Gullkorthafi Dæmi um erfðir/ alhæfingu milli gerenda notendum. Sjá mynd af notkunarlíkani um millifærslur af reikningum hér á eftir. Alhæfingarvensl eru einnig notuð í tengslum við klasa (sjá nánar síðar). 34

35 Dæmi um erfðir: Millifæra Stimpla sig inn Starfsmaður Reikningseigandi Millifæra á erlendan reikning Dæmi um erfðir milli notkunardæma Millifæra á erlendan reikning erfir allar aðgerðir/möguleika notkunardæmisins Millifæra Staðfesta tímaskráningu Deildarstjóri Notkunarlíkan sem sýnir erfðir/alhæfingu milli gerenda Deildarstjóri getur gert það sem Starfsmaður getur gert, en ekki öfugt Endurnýting, að innifela, «include» Þegar við höfum möguleika á að endurnýta eða samnýta sameiginlega virkni notkunardæma eða þegar við notum tilbúnar einingar fyrir hluta notkunardæmis, þá notum við sérstakt táknmál til að sýna það. Innifelur (e. include) er táknað með brotinni línu og opnum oddi sem bendir á það notkunardæmi sem er innifalið í hinu. Við línuna er skráð «include». Endurnýting, innifelur, sýnir: vensl við notkunardæmi sem er sameiginlegt fleirum en einu notkunardæmum eða sem ástæða er til að taka sérstaklega fram til skýringar. að innifalið notkunardæmi er alltaf tekið með í framkvæmd megintilviks Meginnotkunardæmi <<include>> <<include>> Tákn <<innifelur>> (e. <<include>>) Innifalið notkunardæmi Notkunarlíkan sem sýnir hvernig eitt notkunardæmi innifelur annað 2007 Jón Freyr Jóhannsson 35

36 Í bókasafnskerfi gætum við verið með notkunarlíkan eins og hér fyrir neðan. Við segjum að notkunardæmið Fá lánaða bók innifeli notkunardæmið Kanna pantanir og eigum þá við að alltaf þegar notkunardæmið Fá lánaða bók er vakið þá er einnig vakið notkunardæmið Kanna pantanir. Til að vita hvernig og hvenær nákvæmlega það er gert verðum við að skoða betur lýsingu notkunardæmis (sem verður fjallað um hér síðar). Við segjum á sama hátt að notkunardæmið Framlengja lán innifeli Kanna pantanir. Fá lánaða bók <<include>> Kanna pantanir Lánþegi Framlengja lán <<include>> Dæmi um innifalið / endurnýtt notkunardæmi Endurnýting á táknmáli eins hér hefur verið lýst hefur marga kosti, en það þarf líka að hafa í huga mögulega ókosti. Á þessu stigi ert þú kannski ekki í stakk búin(n) til að meta þessa kosti og ókosti, en síðar gerir þú þér betur grein fyrir þeim. Kostir endurnýtingar («include»): Heppilegt að geta sýnt hvar (tilbúnar) einingar geta verið notaðar. Það getur haft áhrif á áætlanagerð. Komið í veg fyrir að skrá þurfi sömu upplýsingar oftar en einu sinni því þá þarf ekki að skrá þá lýsingu notkunardæmis aftur. Gerir lýsingu notkunardæmis styttri og auðskiljanlegri. Gefur meiri möguleika til að sjá hvar endurnýting er möguleg. Mikilvægar upplýsingar fyrir verkefnastjórnun. Hættur og ókostir við endurnýtingu («include»): Líkön verða hugsanlega of flókin fyrir þá sem ekki hafa nægilega þekkingu á UML-táknmálinu. Viðhald líkana getur verið erfiðara (en það getur líka orðið einfaldara með þessari aðferð). Þegar verið er að leita að möguleikum á endurnýtingu er hætta á því að sveigjanleika hlutbundinna aðferða verði ýtt til hliðar, en við skulum ekki hafa áhyggjur af því á þessu stigi. 36

37 5.4.3 Sértilvik, að sértaka «extend» Kerfisgreining með UML Sértilvik er ekki ósvipuð endurnýtingunni, en sértilvik er það þegar við höfum möguleika á að endurnýta eða samnýta sameiginlega virkni notkunardæma eða þegar við notum tilbúnar einingar fyrir hluta notkunardæmis en ólíkt endurnýtingu þá er sértilvikið stundum en ekki alltaf vakið. Við ákveðin skilyrði er farið í sértilvikið en annars ekki. Sértilvik (e. extend) er táknað með brotinni línu og opnum oddi sem bendir á meginnotkunardæmi, það sem vekur hitt upp. Við línuna er skráð «extend». Hið rétta táknmál er að hafa brotna línu, sum hugbúnaðarverkfæri hafa hana heila. <<extend>> Tákn <<sértekur>> (e. <<extend>>) Athugið sérstaklega stefnu örvarinnar, hún bendir á meginnotkunardæmið. Meginnotkunardæmi <<extend>> Sértilvik Notkunarlíkan sem sýnir hvernig meginnotkunardæmi getur falið í sér sértilvik undir tilteknum kringumstæðum (sem skilgreindar eru í meginnotkunardæminu) Þegar notkunardæmi samanstendur af tveimur eða fleirum mjög ólíkum atburðarrásum (t.d. mismunandi niðurstaða eftir aðstæðum) þá notkum við sértilvik. Við skjalfestingu sértilvika þurfum við að sýna: í hvaða tilvikum þessi sértilvik eiga við hvar þessi skilyrði er prófuð og hvar þessi hegðun kann að breytast, sjá sértilviksstað (e. extension point) hér strax á eftir. Við getum litið þannig á að sértilvik sé sett inn í aðaltilvikið, geti komið þar undir sérstökum skilyrðum. Bankanotandi Leggja inn á reikning <<extend>> Senda SMS um hreyfingu Reikningseigandi Notkunarlíkan sem sýnir virkan geranda og óvirkan geranda (þátttakanda) notkunardæma 2007 Jón Freyr Jóhannsson 37

38 5.4.4 Sértilviksstaður Sértilvik eru notuð þegar tiltekin skilyrði koma upp í notkunardæmi. Til að skýra betur hverskonar skilyrði er um að ræða getum við sett svokallaðan sértilviksstað (e. extention point) í tákn notkunardæmis. Sértilviksstaður (e. extention point) er táknaður með láréttri óbrotinni línu sem sett er undir heiti notkunardæmis. Fyrir neðan línuna er settur stuttur texti sem lýsir skilyrði sem vekur sértilvik (sjá textann Hér er skilgreining á skilyrðum sértilviks inni í notkunardæmisbólunni). Notkunardæmi Hér er skilgreining á skilyrðum sértilviks Táknmál fyrir skilgreiningu sértekningar (e. Extension points) Dæmi um skilyrði sértilviks er að sjá hér á myndinni. Athugaðu að: Sértilviksstaður segir til um það af hverju «extend» er notað. Þessu er oft sleppt, oftast er það ljóst af samhengi hvað átt er við Það flækir ritin stundum að hafa alla skilgreinda sértilviksstaði táknaða á þennan hátt Lánþegi Fá lánaða bók Of margar bækur að láni Hafna láni <<extend>> Dæmi um notkunardæmi sem hefur skilgreinda sértekningu (e. Extension points) Slíkar skilgreiningar geta verið fleiri en ein í hverju notkunardæmi 38

39 5.5 Samantekt Kerfisgreining með UML Helstu verk við gerð notkunarlíkana: Finnum gerendur. Finnum notkunardæmin. Finnum venslin milli notkunardæma (ef þau eru). Ritum lýsingar notkunardæma og gerenda þar sem þörf er (sjá í sérkafla). Notkun atburðarásir (e. scenarios) til að hjálpa okkur. Hafa ber í huga... Gátlistar og dæmi Ef vafi er: Notið gerendur þegar það virðist helst henta, verið óhrædd að skilgreina þá frekar fleiri en færri í upphafi. Veljið að hafa sem gerendur þau fyrirbæri sem skýra viðfangsefnið helst. Hafið notkunardæmin frekar fleiri en færri í upphafi, það er auðvelt að sameina og fækka seinna. Sýnið alltaf samskipti við ytri kerfi þegar: önnur kerfi / tæki hafa frumkvæði að samskiptum. tæki eða kerfi fær upplýsingar með samskiptunum. Notkunardæmi gegna mikilvægu hlutverki í: Þarfagreiningu og þá í samskiptum við notendur og kaupendur (sbr. umfjöllun um kröfulýsingu). Prófun kerfis Helstu kostir notkunarlíkana eru að: Táknmál er einfalt og auðskiljanlegt. Þau gefa góða yfirsýn. Notkunardæmi henta vel til samskipta milli hönnuða, notenda og sérfræðinga, tryggir að notendur vilji nota kerfið. Þau sýna heildarvirkni kerfis. Þau skilgreina góðan grunn fyrir prófanir á virkni útfrá sjónarhóli kaupenda/- notenda. Gerir mögulegt að skilgreina alla gerendur, öll skil og samskipti og allar aðgerðir kerfisins. Tryggir að farið hefur verið yfir allar þarfir, allar þarfir eiga að vera leysanlegar með þeim notkunardæmum sem við skilgreinum. Gerir greinendum og hönnuðum mögulegt að skilja þarfirnar. Hjálpar við að finna hvort við þurfum að halda áfram að greina ferli, nær notkunardæmi að gera það sem skilgreindar þarfir krefjast? Helstu gallar notkunarlíkana eru að: Það er undir þeim sem ritið gerir að ákveða hve djúpt eða grunnt ritið er og því getur verið mikill munur á ritum vegna sama kerfis eftir því hver gerir þau. Helsta gagnrýni á notkunarlíkön er að: Þau byggja á runu-hugsun og beinu flæði, sem var líklegra til árangurs í eldri sequential hugsuninni, en hentar ekki eins vel í atburðadrifinni hlutbundinni högun (e. event driven object-oriented architecture) Jón Freyr Jóhannsson 39

40 5.6 Spurningar og umræður 1. Ekki alltaf ljóst hvort um er að ræða gerendur eða ekki: er lyklaborð gerandi? strikalesari? búðarkassi? 2. Segjum sem svo að þú sért að skoða hugsanlegt kerfi fyrir sjúklingamóttöku á læknastofu. Kerfið er ætlað til tímabókana eingöngu: er sjúklingur gerandi? er móttökuritari gerandi? er læknir gerandi? 3. Ég er að greina fyrir þig kerfi fyrir bóksölu á netinu og ég segi þér að notkunarlíkanið sé ofureinfalt, það er einn gerandi sem er kaupandinn og svo er eitt notkunardæmi sem er að kaupa bók. Það er erfitt að mótmæla þessum einföldu rökum. Hvað finnst þér? Ivar Jacobsen (Jacobson, 2003) setur fram þá lauslegu viðmiðun að notkunardæmi verði að gefa mælanlegt aukið virði (hvernig sem það ætti nú að vera mælt) fyrir tiltekinn geranda. Hann setur einnig fram þá þumalputtareglu að í stóru kerfi fyrir [one business process] ætti notkunarlíkan ekki að innihalda fleiri en 20 notkunardæmi. Við verðum samt að passa okkur á því að taka þetta ekki of alvarlega. Það er ekki þannig að við eigum að fjölga eða fækka notkunardæmunum til að ná þessari tölu, þetta er einungis gróf viðmiðun. 40

41 6 Lýsing notkunarlíkana Notkunarlíkön hafa einfalt táknmál, en það er meira á bak við þau en bara þessi tákn. Ólíkt flestum öðrum ritum UML þá gera flestir ráð fyrir nokkuð miklum texta bakvið notkunarlíkön. Sumir tala reyndar um að maður skrifi notkunardæmi en ekki teikni! maður skrifar notkunardæmi en ekki teiknar! UML skilgreinir ekki sérstaklega textalýsingu sem vani er að hafa með notkunardæmum og gerendum. UML gerir ráð fyrir að notuð séu önnur rit, eins og runurit, stöðurit eða verknaðarrit, til að lýsa útfærslu, en vandinn við það er að á frumstigi greiningar er ekki komin nein mynd á útfærslu kerfis og á þeim tíma er greinandi upptekinn af því að ná því niður hvaða þarfir eru og hvernig leysa megi úr þeim. Venja er að nota almenna lýsingu í orðum til að skilgreina hvernig hvert notkunardæmi er hugsað og tökum við mið af því hér. Þá er einnig gert ráð fyrir að gerendum sé lýst á svipaðan en þó mun einfaldari hátt. Formið á þessum lýsingum er ekki staðlað á neinn hátt en venja hefur skapast um meginhluta innihalds þeirra og verður miðað við það hér. Lýsingin hefur m.a. þann tilgang að gefa skýra mynd af bæði því sem gerist og því sem ekki á að gerast. Það er ekki ætlast til þess að þessu sé lýst mjög tæknilega og alls ekki að fara nákvæmlega í það hvernig eitthvað á að birtast á skjánum, slíkt bíður seinni tíma. Notkunardæmi, og lýsing á þeim, eru að mestu til að eiga samskipti við notendur og kaupendur og þeim á ekki að þvæla í of tæknilega umfjöllun. Lýsingin ætti að vera með orðalagi notenda og kaupenda (það eru þeir sem við erum að tala við með ritinu) og vera á mannamáli til að fyrirbyggja misskilning. Þar sem notkunarlíkön eru okkar helsta leið til samskipta við notendur til að fá fram kröfur og til að tryggja að ekkert vanti eða sé of, þá er mikilvægt að við flækjum ekki málið með of mikilli tækni eða málskrúði. Lýsing ætti einnig að vera skrifuð með það í huga að hún er oft notuð sem grunnur prófanalýsinga.

42 6.1 Innihald lýsinga notkunardæma Lýsing notkunardæmis getur falið í sér eftirfarandi atriði: Heiti notkunardæmis Um er að ræða sama nafn og kemur fram á ritinu. Númer Gott er að geta vísað til notkunardæma með númerum frekar en nöfnum og einnig er þægilegra að leita milli rita og lýsinga ef notuð eru númer. Númerin þurfa þá að vera líka á notkunardæmunum á ritunum. Stutt lýsing á tilgangi eða markmiði notkunardæmis. Forskilyrði (e. pre-condition) skilgreinir hvað þarf að vera til staðar þegar notkunardæmi hefst. Oftast er um að ræða einhverskonar stöðu á tilteknum atriðum. Dæmi: Höfuðskjalaskrá skal vera opin, Notandi hefur uppfærsluaðgang, Kerfi RB þarf að vera í sambandi o.s.frv. Flæði (e. flow of control). Hvað stýrir því hvernig tilteknar aðgerðir eru framkvæmdar Lýsing á flæði Bæði getur verið um að ræða svokallað meginflæðið (e. base flow) og fráviksflæði/hliðarflæði (e. alternative flow). Meginflæðið er það sem venjulegast gerist (ef ekkert er óvanalegt eða sérstakt). Fráviksflæði (hliðarflæði) eru frekar undantekningar eða eitthvað sem gerist við sérstök skilyrði, eins og hvað gerist ef þú hefur gert þrjár misheppnaðar tilraunir til að slá inn leyniorðið þitt eða PIN-númer í hraðbanka. Eftirskilyrði (e. post-condition) skilgreinir hvaða staða er þegar notkunardæmi hefur lokið (eðlilega). Dæmi: Bók hefur verið skráð í útleigu á lánþega, Höfuðskjalalisti er uppfærður, Notendi hefur verið gerður óvirkur, Gagnagrunni hefur verið lokað fyrir uppfærslu o.s.frv. Gerendur Hvaða gerendur koma við sögu. Auk þess getur verið rétt að tiltaka: Höfund. Dagsetningu síðustu breytingar. Númer á kröfu í kröfulýsingu sem notkunardæmið leysir að hluta eða öllu. 42

43 6.2 Ábendingar um gerð notkunardæmalýsinga Við ritun lýsinga notkunardæma er gott að hafa nokkur atriði í huga: Skjalfestið eins fullkomlega og eðlilegt er (notið 3ju persónu). Of mikil nákvæmni er ekki endilega af hinu góða, aðalatriðin þurfa að koma fram. Varasamt er að fara of nákvæmlega í að lýsa (væntanlegum) útfærslum, ekki fara að rita notandi ýtir þá á OK hnapp í neðra hægra horni glugga, frekar eitthvað eins og notandi getur staðfest samþykki sitt áður en lengra er haldið. Notkunardæmi þarf að skilgreina skýrt flæði og röð aðgerða og þá þarf að tiltaka eftirfarandi: hvaða aðgerðir tilheyra notkunardæminu, hvernig notkunardæmi byrjar og hvernig því líkur, hvenær og hvernig notkunardæmi vinnur með geranda, hvort og hvaða upplýsingar flæða milli notkunardæmis og geranda. Varist óljóst orðalag, t.d. o.fl., osfrv., upplýsingar, gögn Notkunardæmi eiga að vera þannig skrifuð að notandi/verkkaupi skilji þau! 6.3 Form notkunardæmislýsingar Þægilegast er að vera með fast form fyrir þessar lýsingar og hér er dæmi um eitt slíkt: 2007 Jón Freyr Jóhannsson 43

44 Dæmi um lýsingu þar sem búið er að setja inn fyrstu drög lýsingar (yfirleitt verða þær nákvæmari eftir því sem líður á greiningarferlið): Lýsing notkunardæmis Númer notkunardæmis ND-8 Heiti notkunardæmis Tilgangur notkunardæmis Forskilyrði Lýsing meginflæðis Útlán bóka Gera kleift að lána út bækur skv. reglum safns sniðmát með kuml Búið er að skanna (eða slá inn) númer lánþega og skráningarmynd með einkennum lánþega er komin upp Miðað er við að skráningarmynd sé uppi. Til að skrá lán þarf að skanna inn strikamerki bókar (með strikalesara) eða slá inn skráningarnúmer, sem er við strikamerkið, í skráningarnúmersreitinn á skráningarmyndinni. Einungis þarf að skrá skráningarnúmer eintaks bókar sem er lánað (sjá athugasemdir *) Lýsing undirflæðis Ef staða lánþega er þannig að hann fái ekki lán skal það koma upp í kerfinu (forsendur er að finna í skjalinu StoppLán03 ). Ekki er hægt að skrá frekari útlán fyrr en staða lánþega breytist. Staða getur breyst með því að bókum er skilað eða ef heimildum lánþega er breytt (sjá kröfu 27, notkunardæmi 29). Ef hvorki er hægt að lesa inn strikamerki eða númer bókar er athugað með að finna annað eintak til útláns. Ef ekki finnst annað eintak er hægt að fletta upp bókum eftir titli og athugað hvort viðkomandi er síðasta eintak inni á skrá og þá fæst númer eintaks bókar. Ef vafi leikur á skráningu er hægt að velja að gefa safngrip nýtt númer (sjá kröfu 65, notkunardæmi 37). Eftirskilyrði Gerendur Annað - athugasemdir Aðgerð lokið með skráðu útláni eða hætt við aðgerð Starfsmaður bókasafns * Ekki er heimilt að skanna inn annað eintak bókar en það sem lána á því hvert um sig er einkvæmt númerað. Útlán annarra safnfanga eru til tekin í ND-9 Höfundur Jón Freyr Jóhannsson Dagsetning síðustu breytingar Vísun í kröfulýsingu Krafa Lýsing gerenda Lýsing gerenda er yfirleitt öllu einfaldari en lýsing notkunardæma. Helst er skráð hvaða hlutverki gerandi gegnir, hvaða hagsmuni hefur hann, hvaða hæfni má gera ráð fyrir, hvaða einstaklingar séu líklega í hópi geranda, þ.e. með þetta hlutverk. Ýmsar aðferðir í viðmótshönnun gera skýrari og greinarbetri kröfur til skilgreiningar gerenda og hlutverka. Við skulum halda okkur við einfaldari framsetningu nú og miðum við að skrá einungis: Heiti geranda. Númer til að aðgreina og auðvelda leit og uppflettingar Hverjir það séu sem falla í þann flokk (ef það er ekki augljóst). Hvaða hæfni eða bakgrunn þeir hafa (ef það á við). 44

45 7 Hlutir, klasar og vensl Þegar unnið er með notkunarlíkön er verið að skoða hvað er gert í kerfinu. Nú þurfum við að halda áfram og skoða hvað er unnið með í kerfinu. Til þess að greina það notum við svokölluð klasarit sem lýsa samhengi hluta sem kerfið á að vinna með. Í kaflanum verður farið yfir skilgreiningar á hlutum, klösum, tilvikum, venslum og fleiru sem því tengist. Nánar verður fjallað um klasa og klasarit í síðari köflum. 7.1 Hlutur Hlutur (e. object) er minnsta eining sem við vinnum með sem hefur einhverja markverða hegðun og eiginleika. Við búum til okkar kerfi úr hlutum sem falla eiga saman á tiltekinn hátt. Tökum sem samlíkingu húsbyggingu. Þegar við byggjum hús þá notum við timbur, nagla, sand og sement og það væru hugsanlega minnstu einingarnar okkar sem máli skipta. Við byggingu húss úr slíkum hlutum þá er ekki nóg að hafa þessa hluti, við verðum einnig að hafa einhverja hugmynd um það hvernig við eigum að láta þessa hluti passa saman og teikningu af því sem byggja á. Á sama hátt höfum við líkön við hugbúnaðargerðina sem segja til um samhengi hlutanna, s.s. hlutalíkön (reyndar kallast þau klasalíkön). Þegar við skilgreinum líkönin okkar við húsbyggingu, þá tölum við ekki um stakar spýtur og sandkorn heldur segjum við frekar að við ætlum að nota timbur, 1x4, 120 metra og svo tiltekið magn af steypu. Það er ekki alltaf samræmi í því hvernig hugtökin hlutur og klasi eru notuð. Mismunandi forritunarmál geta haft nokkuð mismunandi skilgreiningu á notkun orðanna og höfundar bóka gera það einnig. Í þessari kennslubók notumst við skilgreiningu UML á þessum hugtökum, en þrátt fyrir að margir bókahöfundar og hugbúnaðarframleiðendur vísi til þess að þeir noti skilgreiningu UML þá fara menn oft mismunandi leiðir í túlkun sinni á þeim og verður að taka tillit til þess. Tegundarheitið timbur er það sem við myndum kalla klasa, timbrið getur verið með mismunandi eiginleika, mismunandi breidd og þykkt og hefur lengd, það væru

46 þá eiginleikar hluta (einstakar spýtur) sem tilheyrðu þessum klasa (sem gæti heitið Timbur). Stöku spýturnar (eða borðin) er hlutir en samheitið timbur er klasinn sem lýsir hlutunum. Ef við hugsum okkur kerfi sem snýst um það að skrá viðskiptamenn og pantanir þeirra, hlutirnir okkar væru viðskiptamennirnir og pantanir. Klasann sem lýsir viðskiptamönnum getum við kallað Viðskiptamaður og klasinn sem lýsir pöntunum almennt köllum við Pöntun. Eiginleikar viðskiptamanna væru t.d. nafn viðskiptamann, kennitala o.s.frv., pantanir hefðu eiginleika eins og pantananúmer, dagsetningu, afhendingartíma o.s.frv. Byrjum að skoða hvað klasar eru. 7.2 Klasi Klasi (e. class) lýsir hlutum og hegðun þeirra, þ.e.a.s. hvað þeir geta gert, hverju þeir geta brugðist við, hvaða upplýsingar þeir veita o.s.frv. Klasi (Class) Tákn klasa, einfaldasta framsetning (e. Class) Klasi er lýsing á mengi hluta sem hafa sömu: Eigindi (e. attributes), sem lýsa eiginleikum hlutanna sem byggja á klasanum. Aðgerðir (e. operations), sem hægt er að beita á klasann. Aðgerðirnar skilgreina þá þjónustu sem klasinn veitir, hvað hann getur framkvæmt, hverju hann getur svarað. Vensl (e. relationship), sem segja til um það hvaða samskipti klasinn á við aðra klasa t.d. með því að kalla á aðgerðir þeirra eða þá að klasinn svari þeim (fjöllum um þau síðar). Merkingarfræði eða orðaforða (e. vocabulary), þ.e. hægt er að tala um hluti klasans á sama hátt og þeir eru af sömu tegund. Um klasa má m.a. segja: A class is the stencil from which the objects are created (instantiated). Each object has the same structure and behavior as the class from which it is instantiated 18 Hlutir af sama klasa hafa sömu skil við umhverfið (bregðast á sama hátt við svipuðum áreitum eða aðgerðum) Sömu aðgerðir vinna á alla þá hluti sem tilheyra sama klasa. Ef aðgerðin StórAðgerð vinnur á hlutinn StórKassi sem er af klasanum Kassi, þá vinnur aðgerðin StórAðgerð einnig á hlutinn MeðalKassi ef hann er líka af klasanum Kassi. Tilgreindu nemendurnir (hlutirnir) Jón og Gunna tilheyra sama klasa (nemendur) 18 Page-Jones: Fundamentals of Object-Oriented Design in UML 46

47 7.3 Táknmál - Grunntákn Klasi (e. class) er táknaður með rétthyrningi sem getur haft þrjú hólf en stundum eru þau ekki öll sýnd. Oft er klasinn einungis táknaður með kassa með nafni klasans í. Hólfin þrjú eru: Heiti klasans Venja er að nefna klasa þannig að þeir heiti nafnorði í eintölu sem byrji á stórum staf. Skynsamlegt er að vinna eftir einhverjum nafnastaðli t.d. nafnastaðla sem notaðir eru í forritun. Önnur atriði er tengjast klasanum í heild eru stundum skráð í þetta hólf en við fjöllum um það síðar. eigindi aðgerð() Klasi Tákn klasa með hólfum fyrir eigindi og aðgerðir Klasi (Class) Tákn klasa, einfaldasta framsetning (e. Class) Eigindi klasans Eigindin er talin upp, eitt í hverri línu, sjá betur hér á eftir. Aðgerðir Aðgerðir eru taldar upp, ein í hverri línu, sjá betur hér á eftir. Hægt er að sleppa neðri hólfunum tveimur eða hafa þau tóm, en röð hólfana er alltaf sú sama, fyrst eigindi og síðan aðgerðir. 7.4 Eigindi Uppbygging klasans sést á eigindunum (e. attributes), þ.e. hvað hefur klasinn að geyma. Eigindin eru talin upp og er hvert og eitt í sérlínu. Oft eru heiti eiginda með litlum upphafsstaf. Skynsamlegt er að vinna eftir einhverjum reglum um heiti eiginda t.d. nafnastaðli sem notaðir eru fyrir breytur í forritun. Hægt er að tilgreina nánar hvernig eigindin eru með því að tilgreina tag (e. type) þeirra, upphafsgildi og fleiri atriði. Bók titill höfundur útgefandi útgáfuár ISBN Tákn klasa með eigindum Eigindið titill í Bók (hér fyrir ofan) gæti t.d. verið af taginu String og væri þá táknað: titill : String Upphafsgildi (eða sjálfgefið gildi er hægt að skilgreina á svipaðan hátt. Segjum svo að algengast sé að útgefandi sé AddisonWesley og við vildum hafa það sem upphafsgildi (þ.e. það gildi sem sett er í upphafi ef ekki er annað tekið fram) þá gætum við táknað það á þennan hátt: útgefandi : String = AddisonWesley 2007 Jón Freyr Jóhannsson 47

48 Skoðum nú fleiri dæmi um eigindi klasa. Klasinn Nemandi í nemendaskrárkerfi gæti haft eigindin: Nafn Kennitala Deild Skráningardagur o.s.frv. Nemandi nafn kenntala deild skráningardagur... Klasinn Viðskiptamaður gæti haft eigindin: Nafn Heimilisfang Sími Netfang o.s.frv. Viðskiptamaður nafn heimilisfang sími netfang... Klasinn Timbur sem nefndur var í inngangi kaflans gæti t.d. haft eigindin: Timburgerð (vísað til flokkunarkerfis eða bara texti) Lengd (mælt í m) Breidd (mælt í mm) Þykkt (mælt í mm) Áferð (heflað/óheflað) o.s.frv. Timbur timburgerð lengd breidd þykkt áferð... Eigindi - dæmi með tagi eiginda: Námskeið einkenni námskeiðs : string heiti námskeiðs : string Pöntun pöntunarnúmer : string dagsetning pöntunar : Date upphæð pöntunar : Upphæð Dæmi um eigindi með skilgreindu tagi 48

49 7.5 Aðgerðir Aðgerð (e. operations/methods) er það sem klasi getur gert, aðgerð er veitt þjónusta klasa, það sem hlutir af þessum klasa geta. Aðgerð er sameiginleg öllum hlutum sama klasa, allir eru þeir færir um að framkvæma þessar aðgerðir. Þegar hlutur sendir skeyti/boð til annars hlutar þá er hann að krefjast aðgerðar þess hlutar. Aðgerðir er hægt að skilgreina með tagi (e. type) eins og hægt að gera með eigindin. Tagið segir til um hverrar gerðar svarið er þ.e. skilagildið sem aðgerðin gefur. Bók lána út() skila inn() er bók inni?() panta bók() Tákn klasa með aðgerðum Nemandi nafn kenntala deild skráningardagur... skrá() skrifa feril() LÍN skilagrein() skrá í námsleyfi() skrá úr námsleyfi() útskrifa() Ferhyrningur -lengd : decimal -breidd : decimal ummál() : decimal +flatarmál() : decimal Dæmi um aðgerðir Bíll +nýskrá() +umskrá() +afskrá() 7.6 Hvaða upplýsingar veitir klasinn? Þegar við tölum um hvaða upplýsingar hlutir veita þá er átt við að við getum spurt hlutinn um eiginleika (eigindi). Til að svara slíkum spurningum þá notum við aðgerðir. Í hlutbundinni aðferðafræði er gert ráð fyrir því að eigindi hluta séu hulin utanaðkomandi og einungis sé hægt að nálgast þau með því að nýta sé aðgerðir klasans sem hlutur tilheyrir. Köttur -kyn -nafn +segja nafn() +segja kyn() Skotti : Köttur kyn = högni nafn = "Skotti" Ef kötturinn minn væri hlutur þá gæti ég séð að hann er svartur og að hann er högni, en þar sem ég vil bara skilgreina hann sem Dæmi um klasa og hlut sem byggir á honum hlut þá gæti ég spurt hlutinn t.d. um lit og kyn vegna þess að þessi hlutur, Skotti sem er af klasanum Köttur, hefur skilgreinda eiginleika sem eru nauðsynlegir hlutnum til að virka í sínu umhverfi Jón Freyr Jóhannsson 49

50 7.7 Hverskonar fyrirbæri verða klasar? Áþreifanleg fyrirbæri eru oft táknuð sem klasar, athuga þarf samt að þetta er eingöngu ef við ætlum að vinna með eða geyma upplýsingar um viðkomandi fyrirbæri, ekki ef viðkomandi er einungis gerandi: Bók, hestur, bíll, hús, land o.s.frv. Óáþreifanleg fyrirbæri sem verða klasar: Námskeið, pöntun, námsárangur, viðtal, fyrirtæki o.s.frv. Hlutverk (e. roles): Lánþegi, stúdent, kennari, sjúklingur, ökumaður, eigandi o.s.frv. Stundum verða atburðir klasar. Þetta á t.d. við þegar atburðir hafa eigindi sem við þurfum að varðveita eða eru áhugaverð. Yfirleitt má segja að atburðir tengist frekar aðgerðum einstakra klasa þannig að þetta er undantekning frekar en hitt og byggist á því að atburður búi yfir áhugaverðum eigindum. Dæmi um slíka klasa: lán, bókaður viðtalstími, bílferð, sýning o.s.frv. Athugið að rugla ekki saman klösum og gerendum. Gerendur eru í tilteknu hlutverki og tákna t.d. raunverulega einstaklinga, klasinn nemandi táknar hins vegar upplýsingar um nemandann Munur á klasa og hlut Hvað er hlutur? Hlutur hefur nafn (auðkenni/einkenni) Hlutur þarf ekki að vísa til raunlægs hlutar, pöntun er t.d. ekki raunlægur hlutur, bókað viðtal ekki heldur Hlutur er í tilteknu ástandi, er í tiltekinni stöðu. Bókin kuml getur t.d. verið í því ástandi að vera í útláni og hluturinn Árni af klasa Nemandi getur verið í ástandinu virkur. Hlutur (Object) Tákn hluts, einfaldasta framsetning (e. Object) Hlutur tilheyrir klasa. Tiltekinn hlutur er af einhverri gerð, þ.e.a.s. tilheyrir einhverjum klasa sem lýsir almennum atriðum þeirra hluta sem tilheyra klasanum. Við tölum um tilvik (e. instance) af klasanum þegar við tölum um tiltekinn hlut. Njála er tilvik af klasanum Bók. Í því felst að hún er hlutur, klasar eru ekki tilvik. Við getum því talað almennt um klasa, almennt um hluti (og átt þá við ótilgreinda hluti) og svo tölum við um hluti sem eru (sértekin tiltekin) tilvik af klasa. Njála : Bók titill = Njála höfundur = óþekktur útgefandi útgáfuár ISBN Tiltekinn hlutur Auðkenni hluta, einkvæm aðgreining 50

51 Mismunandi hlutir sama klasa geta haft mismunandi nöfn eða einkenni (e. identity). Hlutir af klasanum Bók geta t.d. verið Njála, Íslandsklukkan, Harry Potter og pottormarnir o.s.frv. Hvert nafn eða einkenni getur bara átt við einn tiltekinn hlut. Hluturinn Njála sem tilheyrir/er af klasanum Bók á einungis við þennan eina tiltekna hlut, þessa tilteknu bók. Skilgreining stöðu (e. state) hluta Staða hluta er ákvörðuð af innihaldi (gildum) eigindanna (breytanna) Klasinn -eigindi1 : string = "Nei" -eigindi2 : int = 28 Hlutur : Klasinn eigindi1 : string = "Nei" eigindi2 : int = 28 Klasi og hlutur (tilvik klasa) sem sýna eigindi með upphafsgildum Stöðuheldni Hlutur getur haft minni, eigindin geyma upplýsingar, en það hefur klasinn ekki. Klasinn er bara einskonar sniðmát (e. template) fyrir það hvernig hlutir hans eru. Þessi eiginleika að geyma upplýsingar (að hafa minni ) er það sem átt er við með stöðuheldni. Hlutur hefur stöðuheldni, klasi hefur það ekki því hann geymir ekki annað en hvernig hlutirnir eru uppbyggðir. 7.8 Hvernig gerum við? Hvernig finnum við og skilgreinum klasa? Það er ólíklegt að tveir greinendur komist að sömu niðurstöðu í sama verkefni þegar þeir greina klasa. Klasa-uppgötvunin - hvernig finnum við þá? Nokkrar aðferðir eru til en í þessari bók verður aðeins fjallað um þá fyrstu sem hér er nefnd.. Nafnorðagreining eða textagreining (e. noun identification), sjá kafla um nafnorðagreiningu. Mynstur (e. patterns). Mikið er til af bókum sem fjalla skilgreina almenn og sértæk klasalíkön til að nota 19. Use case driven aðferðir sem byggja á notendamiðaðri greiningu, unnið út frá notkunardæmum og notkunarlíkönum. CRC (Class ResponsibilityCollaboration). Frekari upplýsingar um þessa aðferð má finna á Netinu Hvar finnum við klasana? Kröfulýsing gefur okkur nokkra mynd af klösum sem þarf. Nafnorð í lýsingu eru tiltekin og metin eftir tiltekinni aðferð (sjá Nafnorðagreining ). Sumt sem hægt er að lesa milli línanna að sé til staðar þó það sé ekki nefnt beint. Dregin eru upp meginatriði kerfis og það hjálpar til við flokkun klasa. Í klasasöfnum núverandi kerfis má finna klasa eða upplýsingar um þá, gagnagrunnar núverandi kerfis og/eða kerfa sem vinna eiga með nýju kerfi. Þar má oft 19 en.wikipedia.org/wiki/design_pattern_%28computer_science%29 20 en.wikipedia.org/wiki/class-responsibility-collaboration_card 2007 Jón Freyr Jóhannsson 51

52 finna þau gögn sem þegar eru notuð. Þá má einnig leita í klasasöfnum hugbúnaðargerðarmanna, þ.e. lausnir sem til eru fyrir. Viðtöl við notendur og kaupendur er oftast besta leiðin til að finna meginklasa kerfis. Leitum eftir sértækum hugtökum sem notuð eru (e. jargon) sem fela í sér mikilvæg atriði. Leitum eftir upplýsingum um utanaðkomandi atriði eða gögn sem notuð eru af kerfinu. Við tölum um að finna klasa en ekki hluti. Víða í ritum um þessi fræði er talað um að finna hluti, en þar sem við höfum mestan áhuga á tegundum hluta, þ.e. klösum, en ekki einstökum hlutum og tilvikum þá skulum við halda okkur við að finna klasa. Af öðrum leiðum til að finna klasana má nefna: Notendahandbækur eldri kerfa og aðrar vinnuhandbækur eða gæðahandbækur. Viðtöl við kerfisgreinendur sem fengist hafa við svipuð viðfangsefni. Leitum á Internetinu og í bókum um þekktar lausnir t.d. mynstur (e. pattern) Klasarit Klasarit (e. class diagram) greina frá tilveru klasanna og hver vensl þeirra eru og hvaða tilgangi þeir þjóna innan kerfis Tilgangur klasarita er að draga upp mynd (líkan) sem sýnir samhengi klasa í kerfinu okkar. Klasarit lýsa hvernig hlutir/fyrirbæri (fólk, hlutir, gögn eða önnur fyrirbæri) tengjast hvert öðru. Klasarit lýsa ekki flæði eða hreyfingu heldur einungis hvernig samhengi þeirra er eða getur verið. UML táknin í klasaritum eru: Klasarnir og uppbygging þeirra og hegðun Vensl (e. relations), þar með talin safnvensl og alhæfingar (erfðir) Margfaldarar (e. multiplicity) Nöfn vensla (e. role names) Við höfum þegar skoðað klasa í þessum kafla en við þurfum einnig að takast á við hin hugtökin og táknin Hafa ber í huga... Ólíkt notkunarlíkönum þá eru klasaritin tæknileg í þeim skilningi að meiri nákvæmni er þörf og eiginleikar táknmálsins eru fjölbreyttari. Hér á eftir fara nokkrar ábendingar sem rétt er að hafa í huga við gerð klasarita. Fleiri atriði munu 52

53 síðan vera nefnd í síðari köflum ritsins þegar meira verður fjallað um klasarit og ennþá fleiri eiginleika og möguleika þeirra Skilgreining klasa Klasar á klasariti Hver klasi hefur nafn (hugsanlega númer eða annan kóða ef það er venja) Nafnorð í eintölu Ábending vegna enskrar venju: Oft eru nöfn klasa sem innihalda fleiri en eitt orð þannig að þeim er slegið saman og hvert orð með upphafsstaf (dæmi PostalAddress) Skiljanlegt (merkingarbært) Stutt nafn (minna en 30 stafir) Eigindi klasa skilgreind Fyrst koma þau eigindi sem skipta mestu máli vegna stöðu (e. state) klasa Ábending: notið lágstafi og undirstrik til að tengja orð, einnig má nota nafnareglur sem settar hafa verið fyrir breytuheiti í forritum Aðgerðir (e.operations/methods): Bíðum aðeins með það á þessum frumstigum, nema það augljósasta Góðir siðir og vinnureglur Sýnið bara þá eiginleika klasa sem eru mikilvægir í því samhengi sem verið er að sýna í hvert sinn Skipuleggið lista eiginda með því að flokka þau eftir eðli eða tegund. Sýnið tengda klasa á sömu mynd (myndir geta orðið margar og flóknar) Nafn klasa/hluts/geranda er nafnorð í nefnifalli eintölu Nöfn klasa byrjar með stórum staf Nöfn hluta/tilvika byrjar með litlum staf Nefning vensla sagnorð Nefning vensla er með litlum staf Nöfn aðgerða/eiginda með litlum upphafsstaf Á yfirlitsklasariti er bara nafnahluti klasa Á mörgum klasaritum er því sleppt að sýna tvö neðstu hólfin (fyrir eigindin og aðgerðirnar). Þetta á t.d. við um yfirlitsklasarit þar sem markmiðið er að sýna heildarmyndina en ekki smáatriðin og þar væru eigindin og aðgerðirnar bara til að flækja málið í flestum tilvikum. Það er ekki alltaf sem öll eigindin og aðgerðirnar sem klasinn býr yfir eru sýnd. Markmið hvers rits er að sýna þau atriði sem nauðsynleg eru í hverju samhengi fyrir sig. Sjáanleg atriði klasa geta því verið mismunandi á mismunandi klasaritum án þess þó að það sé einhver mótsögn í því eða villa. Athuga þarf að hér er verið að tala um það hvaða atriði sjást á tilteknu riti, en klasinn getur verið skilgreindur á öðrum ritum eða vegna annarra vensla en þeirra sem sjást á tilteknu riti Jón Freyr Jóhannsson 53

54 7.12 Samantekt Klasarit samanstanda af: Klösum Venslum Margföldurum Nefningum vensla Klasar innihalda: Eigindi Aðgerðir Vensl eru margvísleg, t.d.: Tengsl Alhæfing/erfðir Safnvensl Einföld Samsetning Endurkvæm vensl Tengslaklasi útfærir bæði vensl og klasa. Við tölum um tilvik klasa, tilteknir (nefndir) hlutir eru tilvik klasa. Nafnorðagreiningu má nota til að finna klasa 7.13 Spurningar og umræður Hvaða vandamál telur þú helst vera við notkun nafnorðagreiningar? Hvað kosti hefur nafnorðagreining? Eru klasarit hentug til að sýna notendum? Ef við nýtum okkur táknmál margfaldara og tiltökum nákvæmlega tölur um vensl eins og við fáum hugsanlega uppgefið hjá notendum/kaupendum, er einhver hætta á því að það verði of takmarkandi við útfærslu t.d. ef mörk eru háð reglum sem breytast oft? 54

55 8 Nafnorðagreining Ein algengasta aðferð sem notuð er við að finna líklega klasa er kölluð nafnorðagreining (e. noun identification technique). Reyndir kerfisgreinendur treysta oft orðið meira á reynslu og þekkja tiltekin mynstur verkefna sem hjálpar þeim að finna klasana. Við skulum hins vegar halda okkur hér við nafnorðagreininguna. Nafnorðagreining notar skýra og nákvæma lýsingu á þörfum kerfis: getur verið kröfulisti eða kröfugreining (kallað mismunandi nöfnum og er stundum á mismunandi formi) getur verið lýsing notkunardæmis (e. use case descriptions) Við finnum það í textanum sem skiptir máli, þ.e. markverða hluti: markverðir hlutir = hlutir = nafnorð Nafnorð í lýsingu verkefnis koma til greina sem klasar. Slíka kandídata má flokka í þrennt. Nafnorð sem koma málinu ekki við og má sleppa strax. Nafnorð sem skipta máli, eru viðeigandi, (e. relevant) og fara strax á listann okkar yfir klasa. Óljósir (e. fuzzy), þá þarf að skoða betur. Til að þessi greiningaraðferð virki fullkomlega þurfum við að gefa okkur að lýsing verkefnis sé rétt og nægjanlega ítarleg, annars er hætt við að í þessari greiningu yfirsjáist okkur klasar. Það er hins vegar mjög hæpið að slík lýsing sé nægilega ítarleg. Það hefur samt sýnt sig að nafnorðagreining sem byggir á takmarkaðri lýsingu er betri leið en flestar aðrar til að finna klasa á fljótlegan hátt.

56 Þegar við erum komin með lista yfir hugsanlega klasa þá athugum við hvað við geturm skorið niður, hvaða hugmyndir við getum örugglega losað okkur við. Losum okkur við þær hugmyndir að klösum sem ekki eiga við: tvíteknir (e.redundant) - er þegar kominn fram (hugsanlega undir öðru nafni). óljós merking (e. vague) - ekki ljóst hvað orðið þýðir eða stendur fyrir. yfir-orð (e. meta-language) - orð sem tilheyra aðferðum/táknmáli eða því hvernig við flokkum atriði málfarslega (dæmi: kerfi). utan marka kerfis - lýsir einhverju sem varðar kerfið en er utan marka sem við skilgreinum. er eigindi eða aðgerð - það getur verið mismunandi eftir tilgangi kerfa hvað telst vera klasi og hvað eigindi. Hvar erum við nú með klasana? Fyrsti listi okkar yfir klasa er bara fyrsta ágiskun. Við endurskoðum listann eftir því sem við lærum meira um kerfið. Gerð klasarita er ítrað (e. iterative) ferli, þ.e. við smám saman gerum ritið betra. 8.1 Dæmi um nafnorðagreiningu Tökum dæmi af bókasafnskerfi. Til er stutt lýsing á kerfinu sem við notum til greiningar. Lýsing kerfis Bækur og tímarit Á bókasafninu eru bækur og tímarit. Fleiri en eitt eintak hverrar bókar getur verið til. Sumar bækur eru einungis lánaðar í skammtímaláni. Allar aðrar bækur geta bókasafnsmeðlimir fengið lánaðar í allt að 3 vikur. Bókasafnsmeðlimir geta verið með allt að 6 bækur að láni á hverjum tíma, en starfsmenn geta haft allt að 12 stykki á hverjum tíma. Aðeins starfsmenn geta fengið lánuð tímarit. Útlán Kerfið verður að halda utan um hvenær bækur og tímarit eru lánuð út og þeim skilað, byggt á þeim reglum sem að ofan er lýst. 56

57 Strikum nú undir öll nafnorð Bækur og tímarit Á bókasafninu eru bækur og tímarit. Fleiri en eitt eintak hverrar bókar getur verið til. Sumar bækur eru einungis lánaðar í skammtímaláni. Allar aðrar bækur geta bókasafnsmeðlimir fengið lánaðar í allt að 3 vikur. Bókasafnsmeðlimir geta verið með allt að 6 bækur að láni á hverjum tíma, en starfsmenn geta haft allt að 12 stykki á hverjum tíma. Aðeins starfsmenn geta fengið lánuð tímarit. Útlán Kerfið verður að halda utan um hvenær bækur og tímarit eru lánuð út og þeim skilað, byggt á þeim reglum sem að ofan er lýst. Veljum það sem við höfum með: Nafnorð bókasafn bækur tímarit eintak bókar skammtímalán bókasafnsmeðlimir vikur tími starfsmenn stykki útlán kerfið reglur Athugasemd/afgreiðsla er í vafa hvort eigi að hafa með, set þetta sem vafaatriði. (strangt tiltekið ætti bókasafn ekki að vera með þar sem hægt er að líta á það bókasafnið sé kerfið í heild, en ef við gerðum ráð fyrir því að í kerfinu væri hægt að skilgreina fleiri en eitt bókasafn þá ættum við að hafa þetta með) með, er hlutur með með sleppum sem klasa, þetta er atburður, aðgerð eða einkenni með, er hlutur burtu, er einkenni, ástand, tímalengd burtu, er einkenni, ástand, tímalengd með burtu, er einkenni, ástand, fjöldi burtu, er atburður, aðgerð eða einkenni líklega má sleppa, er Yfir-orð (sjá forsendur fyrir að velja bókasafn sem hlut, set sem vafaatriði sem þarf að skoða betur burtu, en hafa í huga að safna þarf upplýsingum um hinar mörgu reglur og koma því að þar sem við á, t.d. þegar við skilgreinum stöðurit eða verknaðarrit Hvernig lítur þetta þá út þegar búið er að flokka möguleikana í þrennt? Hlutir Vafaatriði Sleppt bók tímarit eintak bókasafnsmeðlimur starfsmaður bókasafn kerfi skammtímalán vika stykki tími regla Við skulum gefa okkur að það hafi verið tekin ákvörðun um að hafa bókasafn með en sleppa kerfi Jón Freyr Jóhannsson 57

58 Hvað gerum við svo við listann? Lagfærum listann: breytum fleirtölu í eintölu Bækur Bók Skoðum nöfn klasanna eiga að vera lýsandi fyrir klasann ekki nota skammstafanir láta passa við nafnareglur (ef það á við og við höfum slíkar) Bók Lánþegi Bókasafn Tímarit Eintak Starfsmaður Klasa-kandidatar bókasafnskerfis Hvað gerum við í óvissu? Ef það er vafi hvort nafnorð fer inn sem klasi eða ekki: hafa á listanum? henda burtu? ef við höfum það með gæti það skapað rugling ef við sleppum því þá gætum við verið að tapa upplýsingum sumir hafa tvo lista það sem er örugglega inni og það sem er kannski inni. ágætis hugmynd að hafa vafa-lista. 8.2 Vandamál við Nafnorðagreiningu og aðrar líkar aðferðir Hugsanlegir ekki-klasar Það er ekki ástæða til að ætlast til of mikils þegar aðferðir eins og nafnorðagreining er notuð. Það eru líkur á því að ekki finnist besta lausn á klasaritum og sjálfsagt vantar einhverja klasa og líkur á því að einhverjum klösum sé ofaukið. Klasagreining byggir ekki síst á reynslu og innsæi þeirra sem vinna greininguna, auk slatta af heppni! Það er því ekki til nein ein endanleg uppskrift til að finna klasana ekki frekar en það sé til aðferð til að gera uppgötvanir eða að finna upp nýja hluti, en leiðbeiningar, eins og nafnorðagreiningin, eru til og þær hjálpa okkur af stað. Mikilvægasta aðferðin sem við getum notað er sú að byggja á því sem aðrir hafa gert (stundum talað um að stela!). Fæst hugbúnaðarverkefni eru alveg ný í þeim skilningi að aldrei hafi verið fengist við viðfangsefnið eða eitthvað því líkt. Mikið er til af ritum og greinum um lausnir á tilteknum viðfangsefnum eða flokkum viðfangsefna. (sjá síðar um mynstur). Helstu vandamál sem finna má við nafnorðagreiningu felast í því sem ofaukið er og því sem vantar. Dæmi: Hurð lyftunnar lokast áður en hún fer á næstu hæð Klasakandídatar hér eru Hurð, Lyfta og Hæð og óreyndum greinanda þætti það líklega ágætt. Það er hins vegar líklegra til árangurs og meira í samræmi við hlutbundna högun að líta á Lyftu sem klasa og lokahurð(), opnahurð(), faraniður(int) og faraupp(int) sem aðgerðir Lyftu og hugsanlega staða Hurðar sem eigindi (sem gæfi okkur hvort hurð er opin eða lokuð). 58

59 Nú er rétt að taka það fram að hugsanlegt er að Hurð og Hæð væru klasar, kerfið gæti verið þannig að megináherslan væri á þessa klasa. Það er því rétt að útiloka ekkert, dæmið er einungis til að benda á það að nafnorðagreiningin ein og sér gefur ekki endilega eina rétta og endanlega niðurstöðu. Ein leið til að finna klasa sem ekki eiga að vera á klasariti felast í því að spyrja: Hvert er hlutverk klasans?. Ef svarið er eitthvað í þessa veru klasinn prentar niðurstöðuna, klasinn þáttar inntakið eða annað sem hljómar eins og klasinn gerir... þá er líklegt að ekki sé um að ræða (góðan) klasa. Klasar eiga ekki sem aðalhlutverk að gera eitthvað, þeir veita þjónustu vegna hluta. Ef um slíka gera - klasa er að ræða þá er liklegra að þar sé um að ræða þjónustu (hugsanlega aðgerð) annars klasa, en ekki sjálfstæðan klasa. Fáar aðgerðir Klasi með eina aðgerð (eða að minnsta kosti fáar) er athugunarverður. Það eru að sjálfsögðu dæmi um góða klasa með einni eða fáum aðgerðum, en það er rétt að athuga hvort það gæti verið um að ræða einfalda aðgerð sem eigi frekar heima í öðrum klasa. Klasar sem ekki gera ráð fyrir að breyta eða uppfæra eigindi Rétt er að athuga vel hvort slíkir klasar séu eðlilegir (þeir geta auðvitað verið það). Oft hefur gleymst að gera ráð fyrir sjálfsögðum aðgerðum sem felast í því að stofna, breyta eða eyða tilvikum klasans (hlutum). Einsleitnipróf Er klasinn að geyma samsvarandi upplýsingar og framkvæma sambærilegar aðgerðir í öllum tilvikum. Klasinn Skírteini væri gagnslaus ef hann væri til að sjá um ökuskírteini, lyfjaskírteini, haffærniskírteini skipa o.s.frv. Hvert og eitt af þessum skírteinategundum hafa mismunandi upplýsingar/eigindi og mismunandi aðgerðir. Meira-en-bara-nafn-próf Ef klasi hefur engin eigindi önnur en það sem flest í nafninu þá er líklega ekki um klasa að ræða heldur eigindi í öðrum klasa. Dæmi um þetta gæti verið kennitala eða heimilisfang. Það gæti hins vegar verið um að ræða í slíkum tilvikum tag-klasa (e. type class) en það er önnur saga. EÐA prófið Ef lýsing á klasanum felur í sér orðið eða í einhverjum mikilvægum skilningi er líklegt að þú sért ekki með klasa heldur eitthvert samansafn af fyrirbærum sem einhvernveginn hafa ratað saman í klasahugmynd Jón Freyr Jóhannsson 59

60 60

61 9 Vensl Klasarnir einir og sjálfir segja okkur ákveðna sögu, þ.e. hvaða aðgerðum er hægt að beita á þá og hvaða eigindi þeir hafa. Ekki síður mikilvæg eru venslin (e. relationships) á milli klasanna. Á klasaritum sýnum við bæði klasa og vensl (klasarit hér til hliðar 21 ) Venslin segja okkur til um það hvernir klasar tengjast, hvaða klasar geta átt samskipti við hvaða aðra klasa, hvaða klasar byggja á öðrum klösum o.s.frv. Í UML eru skilgreindar nokkrar gerðir vensla milli klasa: Vensl Ákvæði (e. dependency ) Tengsl (e. assocoation ) Helstu gerðir vensla milli klasa í UML Lýsing Yfirleitt skammtímavensl. Venslin eru oftast rofin fljótt en hluturinn sem vakinn var með venslunum getur lifað áfram. Yfirleitt langtímavensl a.m.k. miðað við ákvæði (e. dependency ). Sá hlutur sem stýrir/er ráðandi/vekur upp venslin notar venslaða hlutinn til að vekja upp aðgerðir hans (e. methods eða operations ). Venslaðir hlutir geta lifað sjálfstætt. Safnvensl (e. aggregation ) Samsetning (e. composition ) Alhæfing/erfðir (e. generalisation/inheritance ) Raungerð (e. realisation ) Langtímavensl milli hluta. Þeir hlutir sem venslaðir eru ráðandi hlut í venslunum geta lifað sjálfstætt Hlutir eru hluti af stærri heild, geta verið venslaðir við fleiri en einn ráðandi hlut. Langtímavensl milli hluta. Þeir hlutir sem venslaðir eru ráðandi hlut í venslunum geta ekki lifað sjálfstætt Hlutir eru hluti af stærri heild, geta ekki verið venslaðir við fleiri en einn ráðandi Sá hlut. sem erfir fær alla eiginleika þess sem hann erfir frá, allar aðgerðir og eigindi ásamt öðru sem klasann varðar. Þegar klasi/pakki vekur upp klasa þannig að hann raungerir hann, býr hann til" lætur hann verða til" 21 developers.sun.com/jsenterprise/learning/tutorials/jse8/uml_class_diagram.html

62 9.1 Tengsl Við segjum að klasi A og klasi B séu tengdir, hafi tengsl (e. association), ef: hlutur af klasa A sendir skeyti/boð til hlutar af klasa B hlutur af klasa A býr til hlut af klasa B hlutur af klasa A hefur eigindi sem eru hlutir af klasa B eða safn hluta af klasa B hlutur af klasa A fær skeyti/boð þar sem hlutur af klasa B kemur fyrir tengsl eru í báðar áttir nema annað sé tekið fram, þ.e. ef A er venslaður B þá er B venslaður A. Tengsl (e. association) milli klasa eru táknuð með beinu óbrotnu striki milli þeirra. Tengsl geta verið vísuð (e. navigable eða directed), þ.e. vísa í aðra áttina og þá er átt við að sá klasi sem er við örvaoddslausa endann venslist hinum en ekki öfugt. Við gerum yfirleitt ráð fyrir að tengsl séu óvísuð þ.e. venslist í báðar áttir og eru venslin þá táknuð með einu striki án örva. Tákn tengsla (e. association) Tákn vísaðra vensla (e. Directed Relation) A B Námskeið -sækir -hefur Nemandi Bók Lánþegi Námskeið -sækir -hefur Nemandi Klasar A og B eru tengdir Klasar Bók og Lánþegi eru tengdir Jafngilt táknmál 62

63 Dæmi um klasarit í bókasafnskerfi Bókasafn Kerfisgreining með UML Lánþegi Bók Útlán Tímarit Eintak Dæmi um klasarit bókasafnskerfis, með tengslum Dæmi um klasarit með tengslum Pöntun -númer_pöntunarngar : int -dags_pöntunar : Date -verð : int -hefur * -er í * Sending -eink_sendingar : string -dags_sendingar : Date -flutningsaðili : string +setja_i_flutning() Dæmi um klasa með tengslum (tákn og texti á venslum, nefningar og margfaldarar, verða útskýrð síðar) Dæmi um vísuð vensl Vildarkort Viðskiptavinur -er handhafi -er skráð á Dæmi um margfaldara þegar venslin eru vísuð (e. navigable) Í þessu tilviki þarf klasinn viðskiptavinur ekki að vita af/þekkja vildarkortið, kortið þekkir hins vegar á hvern það er skráð. Margfaldarar þurfa ekki að vera frá klasanum viðskiptavin en það er leyfilegt og í þessu tilviki er það gert til nánari skýringar á einhverri viðskiptareglu 2007 Jón Freyr Jóhannsson 63

64 9.2 Alhæfing/erfðir Í notkunarlíkönum var möguleiki að skilgreina svokölluð alhæfingarvensl eða erfðir (e. generalisation). Slík vensl er einnig hægt að nota í klasaritum á milli klasa. Alhæfingu er einnig hægt að nota milli gerenda sem fjallað var um fyrr. Sá sem erfir fær alla eiginleika þess sem hann erfir frá. Þegar um er að ræða klasaerfðir (það geta verið erfðir milli annarra fyrirbæra) þá erfast allar aðgerðir og eigindi ásamt öðru sem klasann varðar. Erfðir (einnig kallað Alhæfing), (e. generalisation) eru táknaðar með óbrotnu striki og lokuðum ófylltum oddi sem bendir til þess sem erft er frá. Á hinum endanum er sá sem erfir og sá bætir við virkni/getu þess sem erft er frá. Tákn erfða/alhæfingar (e. Generalisation) Eftirfarandi skilgreiningar segja til um það hvernig þessi vensl virka í klasaritum. Alhæfing eru vensl milli foreldris (yfirklasa, e. super-class) og barns (undirklasa, e. sub-class) - oft er talað um að þetta séu af sömu gerð vensl, undirklasi er af sömu gerð og yfirklasi. Undirklasi getur komið í stað yfirklasa en ekki öfugt. Undirklasinn erfir eigindi og aðgerðir yfirklasans og þarf þá ekki að taka þau fram í undirklasanum. Klasi getur haft engan, einn eða fleiri yfirklasa. Klasi sem hefur enga yfirklasa en einn eða fleiri undirklasa er kallaður grunnklasi (e. root class, base class). Klasi með einn yfirklasa telst hafa einfaldar erfðir (e. single inheritance). Klasi með marga yfirklasa telst hafa fjölerfðir (e. multiple inheritance) Yfirklasinn spendýr í dæminu hér við hliðina lýsir sameiginlegum þáttum sem allir undirklasarnir erfa. Við þekkjum það úr ýmsum flokkunarkerfum s.s. úr dýrafræðinni hvernig þetta virkar. Erfðir/alhæfingarvensl eru einstaklega merkileg fyrirbæri og geta einfaldað vinnu við kerfisgerð. Spendýr Maður Hestur Hreindýr Dæmi um alhæfingu / erfðir (e. generalisation / inheritance) Það er hins vegar auðvelt að gera hlutina rangt og flækja þá óþarflega auk þess sem það er ekki alltaf svo að forritunarmál ráði við erfðirnar svo vel sé. Það er því viturlegra að fara sparlega með þennan eiginleika þar til þú hefur nokkra reynslu. 64

65 Dæmi um erfðir: Bankareikningar Farartæki Bankareikningur Debetreikningur Kreditreikningur Gjaldeyrisreikningur Dæmi um alhæfingu / erfðir Farartæki Bifreið Hjól Skip Dæmi um alhæfingu / erfðir (e. generalisation / inheritance) Sumir hafa gengið svo langt að telja að erfðir og notkun þeirra geti haft afgerandi áhrif á viðhald hugbúnaðar og þar með aukið framleiðni í hugbúnaðargerð, en lítil framleiðni í hugbúnaðargerð miðað við aðrar iðnog tæknigreinar er áhyggjuefni margra. Eiginleikar hluta (þ.e. gagnagrindur og aðgerðir) geta erfst á milli þeirra. Erfðirnar opna möguleika á að skrifa almenna þætti aðgerða ofarlega í erfðatrénu en sértæk afbrigði neðantil. (...) Þannig hafa t.d. ávísanareikningar og sparisjóðsreikningar í banka ýmislegt sameiginlegt svo sem innlagningaraðgerðina og hún getur þá legið í eitt skipti fyrir öll ofarlega í erfðatrénu en vaxtareikningar lægju hins vegar neðarlega í hvorri erfðagreininni fyrir sig. Sértækar breytingar eru mun auðveldari með þessari aðferðafræði og viðhald hugbúnaðar þar með. Oddur Benediktsson, Nýir straumar í hugbúnaðargerð, Tölvumál, febrúar 1991 Fleiri dæmi um erfðir Dæmi um fjölerfðir Einstaklingur -fæðingardagur -nafn +aldur() : int Einstaklingur -fæðingardagur -nafn +aldur() : int Starfsmaður -ráðningardagur -laun -lífeyrissjóður -stéttarfélag -starfsheiti -orlof tekið +orlofsréttur() : int Kennari Nemandi Rannsóknanemandi Dæmi um erfðir þar sem starfsmaður erfir eiginleika einstaklings Leiðbeinandi Dæmi um fjölerfðir 2007 Jón Freyr Jóhannsson 65

66 9.3 Margfeldisþáttur Eiginleikar vensla eru margskonar, þau eru ekki bara strik, þráður eða rör milli klasa. Einn af eiginleikum vensla er margfeldisþáttur þeirra (e. multiplicity). Margfeldisþáttur vensla segir til um fjöldi tilvika klasa sem tengdur er EINU tilviki annars klasa. Við getum sagt sem svo að ef við erum með klasann Námskeið tengdan klasanum Nemandi og gerðum ráð fyrir að allt að 30 nemendur gætu verið á tilteknu námskeiði þá væri margfeldisþátturinn táknaður með Margfeldisþáttur er skilgreindur fyrir hvorn enda tengsla. Við erum búin að segja að allt að 30 nemendur geti tengst einu námskeiði, því til viðbótar skulum við gefa okkur að hver nemandi geti tengst allt að 5 námskeiðum. Margfeldisþátturinn vegna þeirra tengsla er þá Námskeið Margfeldisþáttur Nemandi Ef við lesum úr myndinni þá segjum við að Námskeið getur tengst 0 til 30 tilvikum af Nemanda og Nemandi getur tengst 0 til 5 tilvikum af Námskeiði. Takið eftir að margfaldarinn er þeim megin sem tilvikin eru sem margfeldið segir til um. Margfeldisþáttur tengsla er sýndur við enda þeirra og taflan hér til hliðar sýnir hvernig margfaldari getur verið. Margfaldari er almennt táknaður með: [neðri mörk].. [efri mörk] Margfaldarar - dæmi: Kennari -Nafn_kennara -Starfsm_nr -er kennt af * -kennir 1..* Námskeið -einkenni_námskeiðs -heiti_námskeiðs -einingar Dæmi um margfaldara, hér er gefið til kynna að hver kennari verði a.m.k. að kenna eitt námskeið Ef venslin eru bara í aðra áttina þ.e. eru vísuð þá er margfaldarinn yfirleitt aðeins hafður örvaoddsmegin því það er leiðin sem segir til um hvaða klasi þekkir/veit af hinum. Sá klasi sem örvaoddurinn vísar á veit ekki af hinum. Læsing -gengur að 1..* Lykill Dæmi um margfaldara þegar venslin eru vísuð (e. navigable) 66

67 9.4 Meira um vensl Kerfisgreining með UML Mikilvægar tegundir vensla eru tengsl og erfðir sem við höfum þegar nefnt. Til viðbótar við að sýna slík vensl getum við viljað sýna nánar hvernig venslin eru, sérstaklega ef þeim eru settar einhver sérstakar skorðu. Ein tegund vensla sem sýna slíkt eru safnvensl (e. aggregation). Þessi vensl eru sterkari vensl milli klasa en venjuleg. Sagt er að annar klasinn standi fyrir heild sem hinn er partur af, sjáum þetta betur með dæmum hér á eftir. Safnvenslin eru tvenns konar, einföld safnvensl (e. aggregation) og samsetning (e. composition) Safnvensl (einföld) Einföld safnvensl (e. aggregation) eru táknuð með óbrotnu striki með opinn ófylltan tígul á öðrum endanum. Venslin geta haft margfaldara. Tákn einfaldra safnvensla (e. aggregation) Námsbraut Námskeið 1 * Einföld safnvensl (e. aggregation) Safnvenslin hér til hliðar segja okkur að Námskeið geti samanstaðið af tilvikum af Nemanda, Bók og Kennara. Safnvenslin segja með þessu ákveðna sögu, en setja þó engin skilyrði fyrir þessari samsetningu, þ.e. námskeið þarf ekki að hafa þessar samsetningar en getur haft þær. Þessi vensl eru því veik að því leyti að þau segja okkur lítið annað en venjuleg tengsl segja. Námskeið Dæmi um einföld safnvensl (e. aggregation) Bók. Nemandi Kennari Helstu ástæður þess að nota þessi vensl eru þær að það gefur ákveðnar upplýsingar til þeirra sem nota eiga líkönin til útfærslu og sumir kjósa því þessa leið til skjalfestingar. Kassi 0..1 * Bjórflaska Dæmi um safnvensl, einföld 2007 Jón Freyr Jóhannsson 67

68 9.4.2 Samsetning Samsetning (e. composition) eru táknuð með óbrotnu striki með fylltan tígul á öðrum endanum. Venslin geta haft margfaldara. Samsetning táknar sterkari vensl milli klasa en einföld safnvensl, það verða að vera tiltekinn skilyrði til staðar í samsetningu, en í safnvenslum geta þau verið til staðar. Tákn samsetningar (e. composition) Samsetningin hér á myndinni segir okkur það að Hönd samanstandi af 1 til 5 Fingrum (kann að Hönd Fingur hljóma íhaldssamt en við skulum gefa okkur þessar stífu Samsetning (e. composition) forsendur!). Samsetningin segir okkur líka að Fingur geti ekki verið til án Handar, það er það sem í samsetningunni felst. Margfaldarar samsetningar eru þannig að þeir eru alltaf 1 eða 0..1 þeim megin sem tígullinn er. Dæmi um safnvensl: Bók Kafli Undirkafli 1 * 1 * Dæmi um safnvensl, samsetningu 9.5 Endurkvæm tengsl Endurkvæm tengsl (e. recursive) eru ekki sérstök gerð tengsla, það sem gerir þau hins vegar sérstök er að þau tengjast sama klasa í báða enda. Klasi getur haft tengsl við sjálfan sig og það þýðir annað af tvennu: Hlutur hefur tengsl við annað tilvik hlutar af sama klasa Hlutur getur haft tengsl við sjálfan sig Endurkvæmu tengslin á myndinni hér til hliðar segja mér að Einstaklingur geti verið venslaður öðrum Einstaklingi (með hjónabandi í þessu tilviki). Þessi tengsl sem myndin sýnir eru íhaldssöm að því leyti að ekki er gert ráð fyrir hjónabandi nema aðila af gagnstæðu kyni og hvorki er gert ráð fyrir fjölveri né fjölkvæni! kvæntur 0..1 Einstaklingur gift Endurkvæm tengsl (e. recursive) er hluti af Námskeið 0..1 Dæmi um endurkvæm vensl Námskeið getur verið hluti af öðru námskeiði 68

69 9.6 Nefning vensla Kerfisgreining með UML Eins og sést hefur á ritunum í dæmunum að framan eru nöfn tengd við venslin á mörgum stöðum. Þessi nöfn segja til um hlutverk (e. role) viðkomandi vensla. Eins og nefnt var í skilgreiningu á tengslum þá virka tengslin í báðar áttir og er því eðlilegt að hlutverkin séu bæði nefnd (í báðar áttirnar). Klasaritið á myndinni segir okkur eftirfarandi: Hver Kennari kennir 0 eða fleiri Námskeið Hvert Námskeið er kennt af 1 eða fleirum Kennurum Hvert Námskeið er sótt af 0 eða fleirum Nemendum Hver Nemandi er skráður í 1 til 5 Námskeið Kennari er kennt af 1..* kennir 0..* Námskeið Við getum einnig ályktað sem svo út frá ritinu: Nemandi verður að vera skráður í a.m.k. 1 Námskeið Kennari þarf ekki nauðsynlega að kenna neitt Námskeið Námskeið hefur alltaf a.m.k. 1 kennara Námskeið þarf ekki að vera sótt af neinum Nemanda er skráður í 1..5 Nefningar vensla er sótt af 0..* Nemandi Nú kann okkur að þykja þessi skilyrði óeðlileg, en það skiptir ekki máli í þessu samhengi, þetta er það sem ritið segir okkur. Staðsetning nefninganna er þannig að við getum lesið þannig að við nefnum fyrst fyrri klasann svo nefninguna sem er nær hinum klasanum og svo nefnum við seinni klasann. Dæmi Nemandi sækir Námskeið. Kennari -Nafn_kennara -Starfsm_nr Kennari kennir eitt eða fleiri námskeið -er kennt af * -kennir 1..* Námskeið -einkenni_námskeiðs -heiti_námskeiðs -einingar Dæmi um hvernig lesa skal úr nefningum og margföldurum Nefningarnar hjálpa okkur til að lesa rétt úr ritunum og koma í veg fyrir misskilning eins og þann að halda að venslin séu annars eðlis en þau í raun eru Jón Freyr Jóhannsson 69

70 9.7 Tengslaklasi Tengslaklasi (e. association class). Stundum eru tengslin jafnmikilvæg og klasarnir sjálfir og hafa eiginleika sem við viljum taka sérstaklega fram. Eiginleikarnir geta verið eigindi eða aðgerðir. Klasi A Tengslaklasi Klasi B Tengslaklasinn tengist venslunum með brotnu striki. Tákn tengslaklasa (e. association class) Nefningar og margfaldarar geta verið til staðar og eru þá á venslunum sem táknuð eru með óbrotna strikinu. Námskeið -nafn námskeiðs -einingar -lýsing 1..* * Nemandi -nafn -deild -dags innritunar Mat -önn -matsþáttur -árangur -athugasemdir Dæmi um tengslaklasa Fyrirtæki * 1..* Einstaklingur Ráðning starf starfsheiti laun dags ráðningar... Dæmi um tengslaklasa 70

71 Táknmál sem jafngildir því að nota tengslaklasa hefur Námsefni Námskeið -nafn námskeiðs -einingar -lýsing -verð tilheyrir 1..* kennir 1..* 0..* er kennt af Kennari er skráður í 1..* 1..* hefur * Þátttakandi -nafn -vinnustaður Námskeiðsskráning -tími námskeiðs -greitt Dæmi um tengslaklasa hefur Námsefni Námskeið -nafn námskeiðs -einingar -lýsing -verð tilheyrir 1..* kennir 1..* 0..* er kennt af Kennari 1 tilheyrir 1..* 0..* hefur Námskeiðsskráning -nafn námskeiðs -nafn þátttakanda -tími námskeiðs -greitt hefur 1..* er vegna 1 Þátttakandi -nafn -vinnustaður Jafngilt táknmál (í stað tengslaklasa milli Námskeiðs og Þátttakanda) 2007 Jón Freyr Jóhannsson 71

72 72

73 10 Samskiptarit Samskiptarit (e. interaction diagrams) lýsa því hvernig hlutir (e. objects) vinna saman. Oft eru samvirknirit notuð til að lýsa heilum notkunardæmum (e. use case) eða hlutum þeirra. Það má því segja að Notkunarlíkön Klasarit samskiptarit tengi Eintak Bók -titill : string(idl) -titill : string -ISBN þannig saman -höfundur : string -ISBN +lána() -útgefandi +skila() -útgáfuár notkunarlíkön og +fjöldiinni() +stofna() +eyða() Lánþegi klasarit. -nafn : string -númer Lýsing notkunardæma er, eins og áður hefur verið farið yfir, almennt orðuð eða réttara sagt, ekki tæknilega orðuð. Í þeim er ekki fjallað um það hvaða klasar og hlutir eru notaðir og ekki heldur hvernig. X v Samskiptarit x() y() z() :A w Samhengið Notkunarlíkön - Klasarit - Samskiptarit :B Sjónarhorni notkunarlíkana er ætlað að gefa notendum og kaupendum möguleika að skilja hvað kerfinu er ætlað að gera og hvernig það gengur fyrir sig. Samskiptarit eru hins vegar, öfugt við notkunarlíkön, tæknileg í þeim skilningi að þau lýsa nákvæmlega 22 hvað er að gerast og oft er hægt að vinna forrit beint eftir þeim. 22 Kerfisgreinandi hefur val um það hve ítarlega hann notar táknmál ritanna, en þau gefa möguleika á að vera mjög tæknileg

74 Samskiptarit er ætluð kerfisgreinendum og þeim sem hanna og forrita kerfin. Með samskiptaritum er verið að kanna möguleika til útfærslu og þau gera kleift að skjalfesta í smáatriðum hvernig samskipti hluta fara fram og oftast er framsetning þeirra tengd forritunarútfærslu, s.s. með tag-skilgreiningum (e. type) og færibreytum (e. parameters). Meginnotkun samskiptarita er til að lýsa því hvernig kerfi útfærir: notkunardæmi (e. use case) eða hluta þeirra, atburðarás (e. scenario), samskipti milli hluta (e. objects), meðhöndlun skeyta (e. messages), tímaröð aðgerða (e. operations eða methods), og fleira í þeim dúr. UML skilgreinir tvær tegundir samskiptarita: Runurit (e. sequence diagrams) þar sem áherslan er á í hvaða röð samskiptin fara fram. Samvirknirit (e. collaboration diagram) sem sýna fyrirkomulag og tengingar milli hluta (e. objects). Runurit og samvirknirit sýna (nokkurn veginn) það sama og skiptast menn í tvo flokka eftir því hvort þeim líkar betur, en almennt má segja að sé áhugi á því að skoða útfærslu einhvers þannig að fram komi í hvað röð aðgerðir eru framkvæmdar þá noti menn runurit, en sé áhuginn á því að skoða samhengi hluta óháð tímaröð noti menn samvirknirit. Hér munum við eingöngu fjalla um runurit. Ástæða þessa að velja að sýna runurit frekar en samvirknirit er sú að runurit gefa betri möguleika á að sýna nákvæma útfærslu og henta vel til að brúa bilið yfir í forritun. Hafa þarf í huga þegar runurit er unnið að nú erum við að fást við hluti en ekki klasa. Klasarnir eru sniðmátið fyrir hlutina en hér erum við að tala um tilvik klasans þ.e. hlutinn. Í þessum kafla er farið yfir: Táknmál runurrita (grunntáknin) Hvernig runurit eru unnin Fjallað um táknmál til viðbótar við grunntáknin Hvað ber að hafa í huga og hvað ber að varast 74

75 Tími Kerfisgreining með UML 10.1 Táknmál runurita Runurit (e. sequence diagrams) sýnir hvernig hlutir (e. objects) kerfis hafa samskipti hver við annan innan kerfisins. Einnig er hægt að vísa til hluta eða þátta (e. components) utan kerfis. Áherslan í runuritum er á tímaröð aðgerða, skeyta eða boða milli hluta Framsetning runurita Táknmál runurita er flóknara en klasarita og notkunarlíkana. Mismunandi tilvik Eitt meginatriði skilur á milli runurita og hinna: röð og staðsetning skiptir nú höfuðmáli. hlutur : Klasi hlutur2 : Klasi2 Röðun og staðsetning felst í því að runuritin eru lesin frá vinstri til hægri 23 og síðan niður 24. aðgerð Engin sérstök merking er Runurit lögð í það hvað langur tími Víddir og grunnatriði líður þegar neðar dregur á ritið, þ.e. það er ekki kvarðaður eða mældur tími 25. Í sinni einföldustu mynd sýna runurit samkipti geranda við kerfið, en oft eru þau notuð til að sýna samkipti tiltekinna klasa við aðra klasa. Yfirleitt erum við ekki í tilteknu runuriti að hugsa um kerfið í heild sinni heldur frekar afmarkaðan hluta þess sem við viljum greina og skýra betur. Grunntákn sem notuð eru á runuritum eru gerendur og hlutir. Þeir eru táknaðir á sama hátt og venja er (athugaðu um hluti að hér erum við ekki lengur að fást við klasana), Hlutur táknaður sem einfaldur ferhyrningur og gerandi sem Óla-prik kall. Tákn fyrir líflínu, ýmis skeyti og aðgerðir fylla síðan myndina. 23 Það er ekki fullkomlega rétt að þau séu aðeins lesin frá vinstri til hægri því það fer eftir því hvernig örvar á skeytum og aðgerðum snúa í hvaða átt er lesið. Vaninn er hins vegar sá að reyna að koma því þannig við að ritið sé hægt að lesa til hægri þar sem það er skýrara og það er þægilegri lesröð. Engin eiginleg merking er lögð í lárétta staðsetningu. 24 Það er leyfilegt skv. UML að breyta tímaröðun þannig að unnið sé upp í stað niður. 25 Hægt er að hafa slíkan kvarða og það er oft notað við útfærslu á rauntímakerfum (e. real-time application) Jón Freyr Jóhannsson 75

76 Dæmi um einfalt runurit Gerandi Gerandi (e. actor) er notaður til að tákna allt sem stendur fyrir utan kerfið en sem hefur þó einhver samskipti við það. Þegar runuriti er notað til að lýsa virkni notkunardæmis er gerandi (táknið) hafður sem virki hluturinn sem vekur aðgerðina, sá sem setur allt af stað! Táknið sem við notum er táknið eins og við notuðum í notkunarlíkönum. Að öðru leyti er táknið, virknin, meðhöndlað eins og um tilvik eða hlut hafi verið að ræða Ekki er alltaf um það að ræða að það sé gerandi sem vekur runuritið og í stað geranda getur verið tilvik eða hlutur sem vekur upp runurit. Tákn geranda er undantekningarlítið haft lengst til vinstri á ritinu 26. Gerandi sem virkur þáttur runurits Ef hugbúnaðarverkfærið sem þú vinnur með býður ekki þann möguleika að sýna gerandatáknið þá skilgreinum við hlut (klasa) sem hefur heiti gerandans og skilgreinum þá þann klasa af sniðinu 27 «actor», þetta tákn er jafngilt hefðbundnu gerandatákni, en er hins vegar ekki eins lýsandi. 26 Ef margir gerendur koma við sögu og einhver þeirra jafnvel ómennskur gerandi er það þekkt að þeir séu staðsettir hægra megin. 27 Sjá síðar um snið,«stereotype» 76

77 Hlutur/tilvik Hlutur (e. object), eða tilvik (e. instance), er táknaður með rétthyrningi. Inni í rétthyrningnum er heiti hlutar og oftast er einnig haft nafn klasans sem hluturinn tilheyrir og á milli er tvípunktur. Á runuriti erum við að vinna með það sem við köllum tilvik klasa, þ.e. einhvern tiltekin hlut. Hlutur eða tilvik er sett í röð efst á ritið 28 ef það er til í upphafi runurits. Kerfisgreining með UML Tilvik á runuriti hafa líflínu (e. lifeline, sjá hér á eftir) sem táknuð er með brotalínu lóðrétt niður af tilviki. Á runuritið setjum við þau tilvik sem koma við sögu í því sem fengist er við að lýsa með þessu tiltekna riti, þ.e. einungis þau tilvik sem koma við sögu, ýmist með því að vera virk tilvik sem kalla á einhverja aðgerð eða senda skeyti eða þá með því að vera þiggjendur Líflína Líflína (e. lifeline) sýnir að tilvik er til, hægt er að vísa til hans og vinna með hann. Líflína er táknuð með brotalínu lóðrétt niður af tilviki. Tilvik geta haft takmarkaðan líftíma þ.e. þau geta verið búin til og þeim eytt og líflínan sýnir hvort þau eru lífs eða liðin innan þess sjónarhorns sem runuritið lýsir. Ef tilvik er búið til að því eytt innan runurits þá sýnir líflínan tímabilið frá því að það verður til og þar til því er eytt. Tilvik sem er til staðar eftir að því sem runurit lýsir lýkur er sýnt með líflínu þannig að líflínan ná lengra niður en síðustu samskipti (köll, aðgerðir). Líflína getur kvíslast, greinst í sundur, t.d. þegar um einhverja skilyrðisbundna virkni er að ræða. hlutur Hlutur á runuriti með líflínu 28 Athugaðu þó að þegar nýtt tilvik er gert þá er staðsetningin önnur, sjá síðar. 29 Við sumar aðstæður getur verið skýrara að tiltaka sömu í sömu röð í mörgum runuritum og þá getur verið rétt að sýna hluti sem í raun koma ekki við sögu í þessa tiltekna rit, en meginviðmiðunin er að hafa eingöngu hlutina sem koma við sögu í þessu riti 2007 Jón Freyr Jóhannsson 77

78 Virkur hluti líflínu Virkur hluti líflínu (e. focus of control) sýnir, eins og nafnið gefur til kynna, þann hluta lífs tilviks sem það er virkt (er í gangi). Virkur hluti líflínu, sá hluti tímans sem tilvik er virkt, er táknaður með ferhyrningi (kassa) á líflínu tilviks. Tilvik getur verið virkt eða óvirkt innan runurits, ef það er óvirkt þá er það t.d. vegna þess að það hefur lokið sínu hlutverki tímabundið eða endanlega. Skv. UML er sá tími virkur sem tilvik bíður svars við kalli sem það hefur vakið Tilviki eytt innan runurits Ef tilviki er eytt í samskiptum sem sýnd eru á runuriti þá er það táknað með stórum krossi á líflínu tilviks og þar endar þá líflínan. hlutur Oftast er tilviki eytt á þann hátt að aðgerð eða skeyti er notað og er þá sniðið «destroy» oft haft á aðgerð eða skeyti. Hlutur á runuriti sem eyðist (e. destroy) Tilviki búið til innan runurits Ef tilviki er búið til í samskiptum sem sýnd eru á runuriti þá er það táknað þannig að tákn tilviks (tákn hluts, rétthyrningur) er staðsett við enda skeytis/aðgerðar, en ekki efst á riti eins og annars væri. Oftast er tilviki búið til með aðgerð eða skeyti og er þá sniðið «create» oft haft á aðgerð eða skeyti. 78

79 Aðgerð eða kall Aðgerð eða kall (e. operation/call) frá einum hlut til annars er táknað með óbrotnu striki með fylltum örvaoddi þeim megin sem hluturinn er sem kallað er í. Aðgerðin sem beitt er á hlutinn er aðgerð sem tilheyri þeim hlut sem tekur við (hún er þá skilgreind í aðgerðahluta klasa hans). aðgerð / kall / skeyti Aðgerð / kall (sem skilar e-u) (e. operation / call) Nafn aðgerðar og form (t.d. færibreytur) eru tilgreind við strikið Svar Svar (e. return) er táknað með brotnu striki með opnum örvaoddi þeim megin sem viðtakandi svars er. Skv. UML er ekki nauðsynlegt að tilgreina svar á runuriti (þó það sé skilgreint sem mögulegt og að aðgerðin skili í raun og veru svari). Það er gengið út frá að þegar virknihluta þess hlutar sem kallað er á lýkur, skili hann því sem skilgreint er af aðgerðinni eða kallinu. svar Svar (e. return) Nafn svars og form (t.d. skilagildi) er hægt að tilgreina við strikið. Oftast er ekki haft neitt nafn við svarið Skeyti Skeyti (e. operation/message/call) sem sent er frá einum hlut til annars er táknað með óbrotnu striki með opnum örvaoddi þeim megin sem hluturinn er sem fær skeytið. Skeyti er frábrugðið aðgerð/kalli þannig að virkni hlutar sem sendi skeytið heldur áfram eins og ekkert hafi í skorist og annað hvort ætlast ekki til svars eða bíður ekki eftir því. Nafn skeytis og form (t.d. færibreytur) eru tilgreind við strikið. skeyti Aðgerð / skeyti (sem ekki skilar e-u) (e. operation / message / call) 2007 Jón Freyr Jóhannsson 79

80 Dæmi um runurit Hlutur kallar á hlut með aðgerð hluturb hefur aðgerð() skilgreinda í sínum klasa. hlutura kallar á hlutb með þeirri aðgerð. Svar hefur verið skilgreint í aðgerð() og það er sýnt hvernig það skilar sér (ekki þörf að sýna það). hlutura aðgerð() hluturb Hlutur á runuriti kallar á annan hlut (með aðgerð) og fær svar Hlutur sendi hlut skeyti hluturb hefur skeyti() skilgreint í sínum klasa (getur tekið við því). hlutura sendir skeyti() á hlutb. Skeyti krefst ekki svars (skv. skilgreiningu á skeyti). hlutura skeyti() hluturb Hlutur á runuriti sendir skeyti Einfalt runurit Dæmi um einfalt runurit getur verið eins og hér að neðan þar sem lýst er einfaldri atburðarás (e. scenario) úr bókasafnskerfi. Runuritið sýnir það hvað gerist þegar lánþegi á bókasafni vill fá lánað bók. fá lánað eintak(eintak) lánþegia : Lánþegi eintakx : Eintak bókar bók1 : Bók í lagi að fá lánað() (þetta er sama rit og var sýnt framar í kaflanum) fær lánað() eintak lánað() Dæmi um runurit (athugið að það er ekki að öllu leyti rétt miðað við ætlaða virkni kerfis) 80

81 10.2 Hvernig gerum við? Kerfisgreining með UML Fyrstu drög eru gróf en svo aukum við smám saman nákvæmnina. Byrjum á því að tiltaka þá klasa sem við vitum að eru örugglega til staðar. Við tiltökum auðvitað ekki klasana sjálfa því nú erum við að vinna með hluti/tilvik.. Það er ekki alltaf ljóst í upphafi hvort við höfum ennþá fundið alla klasana sem málið varðar, vinnan felst að hluta í því að skoða hverjir það eru og hvernig þeir koma við sögu. Efst í vinstra horn rits setjum við gerandann 30 eða tilvik ef það er ekki gerandi sem vekur runuritið. Tilvikin setjum við svo í röð efst. Reynum nú að sjá fyrir í hvaða röð aðgerðir eru. Byrjum á að skoða hvaða aðgerð það er sem byrjað er á frá geranda séð (eða tilvikinu lengst til vinstri). Tengjum aðgerðina eða kallið við þann hlut sem við á. Tökum síðan atburðarásina þannig eitt skref af öðru. Athugaðu að þetta kemur ekki alltaf allt í einu eða í endanlega réttri röð, en þá getum við alltaf lagfært á tiltölulega einfaldan hátt, hvort sem við gerum þetta á pappír, töflu eða með hugbúnaði. Gott er að hafa í huga að hægt er að skipta hlutum á runuriti í fjóra flokka með tillit til lífshlaups þeirra: Hlutir sem eru til í gegnum öll samskiptin Hlutir sem búnir eru til í samskiptum (táknað með: skorður {new}, snið «create») Hlutir sem eytt er í samskiptunum (táknað með: skorður {destroyed}, snið «destroy») Hlutir sem búnir eru til og eytt í samskiptum 30 Sum verkfæri bjóða ekki upp á tákn fyrir geranda hér, en þá verðum við að notast við það að skilgreina klasa með nafni geranda og skilgreina hann með sniðinu (e. stereotype) «actor» til að greina gerandann frá raunverulegum klösum 2007 Jón Freyr Jóhannsson 81

82 10.3 Meira táknmál Endurkvæmt kall Endurkvæmt kall (e. recursion) er ekki annað en venjulegt kall, það sem gerir það sérstakt er að hlutur er að beita á sig eigin skilgreindri aðgerð. Endurkvæmt kall Endurkvæmt kall / aðgerð Þegar hlutur kallar á endurkvæman hátt verður til nýr virknihluti sem leggst ofaná og til hliðar við þann virknihluta sem fyrir er (getur staflast áfram ef um djúpa endurkvæmni er að ræða) hlutur Endurkvæmt kall (e. recursion) Endurkvæmt kall Hlutur á runuriti með endurkvæmu kalli (e. recursion) Tímasetningar/tímatakmarkanir Tilgreining tímatakmarkana og/-eða tímasetninga skiptir mestu máli í rauntímakerfum. Hægt er að tilgreina hvenær tiltekinn atburður á að gerast eða hve hratt tiltekinn atburður á að gerast. Getum einnig tilgreint merkingar (e. labels) á örvar ritanna til að tiltaka hvenær skeyti er sent, t.d. A og C. fá lánað eintak(eintak) Tiltökum skorður á ritinu, t.d. {C - A < 5 sekúndur}. Það segir að tími aðgerðir frá A til C sé ekki lengri en 5 sekúndur. A C {C-A < 5 sec} lánþegia : Lánþegi eintakx : Eintak bókar bók1 : Bók fær lánað() eintak lánað() Dæmi um runurit með skorðum / tímatakmörkunum 82

83 10.4 Yfirlit yfir táknmál hlutur2 : KlasiB hlutur4 : KlasiD aðg1() hlutur1 : KlasiA [x>0] búatil() [x=<0] kalla á() hlutur3 : KlasiC gera eitthvað() gera annað() endurkvæmt() Runurit - Yfirlit táknmáls 2007 Jón Freyr Jóhannsson 83

84 Helsta táknmál runurita með skýringum Þessir hlutir eru til fyrir fyrstu aðgerð og verða til áfram eftir þá síðustu Þessi hlutur er búinn til af aðgerðinni hlutur2 : KlasiB hlutur4 : KlasiD aðg1 Aðgerðir geta haft skilyrðisbundna virkni hlutur1 : KlasiA [x>0] búatil [x=<0] kalla á Þessi hlutur er búinn til af aðgerðinni hlutur3 : KlasiC Mismunandi stýring (e.branch of control) gera eitthvað() gera annað() Aðgerð / kall Svar Aðgerðir með skilyrðisbundna virkni "rennur" saman Endurkvæm aðgerð (e. recursive), hlutur kallar á sig (eða annað tilvik) Endurkvæmni gerir nýja líflínu (fyrir það tilvik) endurkvæmt() Líflína endar, hlut er eytt (e. destroy) Líflína heldur áfram - hlutur er áfram til Runurit - Yfirlit táknmáls 84

85 Lögun runurita Kerfisgreining með UML Oft má sjá ýmislegt út úr lögun runurita. Hér eru dæmi um tvenns konar helstu lögun. hlutur1 hlutur2 hlutur3 hlutur4 hlutur5 Dæmi um tiltekna lögun runurits Liggjandi píramídinn segir okkur hvernig uppbygging á kallferlinu er, farið er djúpt og síðan er svari skilað í gegnum öll lögin hlutur1 hlutur2 hlutur3 hlutur4 hlutur5 Dæmi um tiltekna lögun runurits Ójafna greiðan segir okkur hvernig uppbygging á kallferlinu er, hvert kall fer frá grunnstöðu og skilað er svari þangað og síðan farið aftur frá þeirri stöðu 2007 Jón Freyr Jóhannsson 85

86 10.5 Hafa ber í huga... Hér koma nokkrar ábendingar um það sem hafa ber í huga og hvað ber að varast. Þetta eru ekki nein heilög sannindi, einungis ábendingar. Reyndu að setja ritið þannig upp að það sé í eðlilegri lesröð eins og sagt var frá í upphafi kaflans, lesa frá vinstri til hægri og niður. Ef hugbúnaðinn sem þú notar gefur kost á því notfærðu þér þá að sækja nöfn og skilgreiningar á þegar skilgreindum gerendum, klösum, hlutum, aðgerðum og öllu slíku þannig að samhengi sé milli rita og skilgreininga. Sum hugbúnaðarkerfi krefjast þess að þú gerir slíkt. Ef hugbúnaður styður þetta ekki skaltu gæta þess að hafa fullt samhengi milli nafngifta milli rita. Settu skýringar inn á ritin þar sem þú telur þörf nánari útskýringa. Runurit geta orðið bæði löng og breið. Þú verður að meta það hvort þú vilt skipta þeim upp í fleiri smærri. Mörgum þykir þeir missa yfirsýn yfir rununa ef henni er skipt, öfugt við að klasarit og notkunarlíkön er oft einfaldara að vinna með þegar þeim er skipt. Runurit eru tæknileg í eðli sínu. Ekki hræðast að setja inn tæknilegar útskýringar, skorður, færibreytur o.s.frv Samantekt Samskiptaritin eru mjög mikilvægur þáttur í því að gera kerfin tölvutæk eða auðforritanleg út frá greiningunni. Sumir segja að samskiptarit séu hluti af starfslíkani (e. functional model/diagram) Samvirknirit og runurit sýna það sama og má breyta hvoru um sig í hitt, en notkun þeirra er háð því í hvaða tilgangi við ætlum að nota þau Það er ekki nauðsynlegt að útbúa samskiptarit, stundum erum samskiptin sjálfsögð. Við búum því til samskiptarit þegar það er gagnlegt Spurningar og umræður 1. Ekki alltaf ljóst hvort þörf er á runuritum. Skoðaðu verkefnin sem þú hefur þegar unnið og reyndu að leggja mat á það hver af notkunardæmunum sem þú hefur gert væri eðlilegt að útfæra með runuriti. 86

87 11 Stöðurit Stöðurit (e. state diagrams) eru notuð til að lýsa atferli/hegðun (e. behavior) eininga sem hafa breytanleika (e. dynamic behavior). Með breytanleika er átt við að einingarnar geta haft mismunandi stöðu frá einum tíma til annars, þ.e. þær breytast. Stundum er talað um að verið sé að lýsa líftíma (e. life history, entity life history) eininga. Oftast lýsa stöðurit breytingum hluta eða tilvika (e. object/instance) 31. Ekki er öllum hlutum lýst með stöðuritum, einungis þeim sem hafa slíka markverða eða áhugaverða hegðun. Hlutum með flókið lífsferli er oftast lýst með stöðuritum til að öðlast skilning á þeim og hvernig þeir bregðast við kveikja() áreitum 32. Hægt er að segja að staða bregðist við utanaðkomandi áreitum sem við köllum hér atburði (e. event). Atburðir kalla á stöðuskipti (e. transition) þ.e. færslu frá einni stöðu í aðra. Stöðurit er rit sem lýsir stöðuvél (e. state machine) sem ekki verður fjallað um hér. Slökkt slökkva() Í hillu Kveikt lána() skila() Einföld dæmi um stöðurit Í útláni setjast() Standandi standaupp() Sitjandi 31 Stöðurit geta einnig lýst hegðun notkunardæma, gerenda, kerfa eða aðgerða. 32 Við gætum t.d. lýst öllum forritum með stöðuritum (en væri yfirleitt nokkuð flókið stöðurit!)

88 Samhengi stöðurita við önnur rit UML eru sýnd hér á myndinni: Skrá nýjan viðskiptamann Pöntun Farmur Sölumaður Skrá nýja pöntun Viðskiptamaður pöntun viðskiptamaður skrá nýja pöntun staðfesta greiðsluhæfi Sölumaður Vara skráð í pöntun Farmur tilbúinn Stöðurit - Samhengi við önnur rit 88

89 11.1 Táknmál stöðurita - Grunntáknin Staða Staða (e. state) er táknuð með rétthyrningi með ávöl horn. Heiti sem lýsir stöðunni er sett inn í rétthyrninginn. Hægt er að greina frá innri virkni stöðu (e. internal actions eða activities) og er þá heiti í sérstökum reit efst í rétthyrningnum og virknin tilgreind í reitnum fyrir neðan. Stöður geta verið einfaldar (e. simple state), samsettar (e. composite state) og samhliða/samskeiða/samtíða (e. concurrent state). Staða (e. state) Staða (e. state) Tákn stöðu (e. state) Innri virkni stöðu Þegar greint er frá innri virkni tiltekinnar stöðu þá er það gert þannig: [heiti-virkni] / [skilgreining-virkni] [Heiti-virkni] tiltekur þær aðstæður sem kalla á virknina það getur verði atburður (e. event) [Skilgreining-virkni] tilgreinir eigindi eða tilvísanir sem viðeigandi eru Nafn stöðu entry / upphafsaðgerð do / aðgerð A do /... on event-1 / aðgerð exit / lokaaðgerð Innri virkni stöðu Frátekin heiti virkni Nokkrar tegundir af virkni hafa frátekin heiti, en þar fyrir utan getum við skilgreint virkni eins og þurfa þykir, athugaðu þó að of mikið frjálsræði í slíkum skilgreiningum verður oft til að flækja málin. entry skilgreinir hvað gerist þegar komið er í stöðuna. exit skilgreinir hvað gerist þegar staða er yfirgefin. do skilgreinir hvað gert er meðan staðan er virk eða þar til önnur skilyrði taka yfir. include tilgreinir ef undirstöðuvél (e. submachine) á að vera innifalin. Slá inn leyniorð entry / taka af birtingu innsláttar on keypress-enter / ath leyniorð on keypress / móttaka staf on help / birta hjálp. exit / setja á birtingu innsláttar Dæmi um innri virkni stöðu 2007 Jón Freyr Jóhannsson 89

90 Stöðuskipti Stöðuskipti (e. transition) eru táknuð með óbrotnu striki með opnum örvaoddi við þá stöðu sem farið er í. Atburðir (e. event) sem valda stöðuskiptum eru oftast tilgreindir við strikið. Skilyrði stöðuskipta geta einnig verið sett fram á Boolean-hátt 33 og eru kölluð verðir (vörður í kk, et) (e. guard). Vörður er tilgreindur innan hornklofa, ef atburður er tiltekinn á stöðuskiptum þá kemur vörður þar á eftir. Stöðuskipti geta vísað aftur í sömu stöðu (eins og endurkvæmni í klasaritum). atburður (e. event) Tákn stöðuskipta (e. transition) [ef x > 0 og kyn = karl ] skila() Vörður (e. guard) á stöðuskiptum Bók ólánshæf skila() lána()[síðasta eintak] Bók lánshæf Einfalt dæmi um stöðurit með vörðum (e. guards) lána()[ekki síðasta eintak] Upphafs og lokastöður Tvær sérstakar stöður eru skilgreindar í UML stöðuritum: Upphafsstaða (e. initial state) er táknuð með fylltum hring og frá honum liggja stöðuskipti. Lokastaða (e. final state) er táknuð með fylltum hring með einföldum hring utanum (frá honum liggja stöðuskipti). Ekki er nauðsynlegt að tilgreina upphafsstöðu eða lokastöðu. Tákn upphafsstöðu (e. initial state) tákni stöðuskipta er ofaukið Þessar tvær stöður eru hvorugar nauðsynlegar í stöðuritum og hafa takmarkaða merkingu, oft kallaðar gervistöður. Stöðuvél, stöðuritið, byrjar í upphafsstöðu ef hún er til staðar. Fleiri en ein stöðuskipti geta legið frá upphafsstöðu og þá með Tákn lokastöðu (e. final state) tákni stöðuskipta er ofaukið einhverjum vörðum (skilyrðum fyrir þeim tilteknu stöðuskiptum). Hlutur er aldrei í stöðunni upphafsstaða, hún er eingöngu til að sýna hvernig farið er í fyrstu raunverulegu stöðu. Lokastaða er á sama hátt ekki eiginleg staða, ef komið er í lokastöðu þá er ferlinu sem lýst er lokið og hlutur/tilvik því aldrei í lokastöðu. 33 Boolean segð hefur einungis tvö möguleg gildi, SATT eða ÓSATT (true eða false) og verða stöðuskiptin virk ef segðin er sönn (true), en óvirk, ekki notuð, ef segðin er ósönn (false) 90

91 Það er ekki nauðsynlegt að hafa lokastöðu, en þær geta líka verið margar hver um sig háð mismunandi skilyrðum. Það kann að hljóma undarlega að ekki sé nauðsynlegt að hafa lokastöðu en í mörgum aðstæðum er það fullkomlega eðlilegt því stöðurnar sem í ritum eru skilgreina alla möguleika og ferlinu lýkur aldrei beint Ógreiddur innborgun fullnaðargreiðsla innborgun Greiddur að hluta fullnaðargreiðsla Fullgreiddur Upphafsstaða og lokastaða eru stundum kallaðar gervistöður (e. pseudo-state) þar sem þær eru ekki eiginlegar stöður, þ.e. hlutir eru ekki í þeim stöðum. Einfalt dæmi um stöðurit 2007 Jón Freyr Jóhannsson 91

92 11.2 Hvernig gerum við? Hlutirnir sem eðlilegt er að lýsa með stöðuriti eru oftast nokkuð augljósir. Dæmi um slíka eru Pöntun sem getur verið óstaðfest, staðfest, greidd eða afgreidd, Nemandi sem getur verið ósamþykktur, í námi, í námshléi, útskrifaður o.s.frv. Leitaðu eftir eigindum sem hafa staða sem heiti eða hluta heitis, athugaðu t.d. hvort tími (aldur) hefur áhrif á virkni eða hegðun hlutar. Byrjaðu á því að teikna inn stöðurnar sjálfar og gefa þeim góð heiti, heiti sem lýsa vel stöðunni. Þegar stöðurnar eru komnar skaltu skoða það hvað það er sem vekur stöðuskiptin, þ.e. við hvaða kringumstæður eða áreiti breytist staða úr einni í aðra. Settu stöðuskiptin milli staðanna og gefðu stöðuskiptunum heiti sem lýsir því hvað það er sem vekur stöðuskiptin. Hér er oft rétt að tiltaka skilyrði (skorður eða verði). Athugaðu að sama (eða svipað) áreiti getur vakið mismunandi stöðuskipti eftir kringumstæðum og þá þarf að gera grein fyrir þeim. Athugaðu hvort rétt sé að tiltaka upphafsstöðu. Ef þú sérð ekki ekki þörf á því athugaðu þá vel hvort það sé augljóst í hvaða stöðu er byrjað. Athugaðu hvort rétt sé að tiltaka lokastöðu. Það er yfirleitt skýrara að hafa þær þegar um slíkt er að ræða, það gerir ritið auðveldara í lestri Hafa ber í huga... Hér koma nokkrar ábendingar um það sem hafa ber í huga og hvað ber að varast. Þetta eru ekki nein heilög sannindi, einungis ábendingar. Ekki eyða tíma í að gera stöðurit fyrir hluti sem lítið breytast. Það getur verið full ástæða til að gera stöðurit vegna hluta sem einungis hafa tvær stöður. Slíkt á við ef stöðuskiptin eru flókin og/eða skipta miklu máli í útfærslu og túlkun. Reyndu ef hægt er að hafa ritið í þægilegri lesröð, þ.e. upphafsstaða efst til vinstri og lokastaða neðst til hægri. Gættu vel að heitum á stöðum og stöðuskiptum, athugaðu sérstaklega hvort einhver hætta sé á misskilningi á nafngiftum. Eru einhver svarthol? Svarthol eru stöður þar sem mörg stöðuskipti liggja að en engin frá. Slíkt er ekki nema um eiginlega lokastöðu sé að ræða. Eru einhver kraftaverk? Kraftaverk eru stöður þar sem engin stöðuskipti liggja að, en ein eða fleiri frá. Slíkt er ekki nema um eiginlega upphafsstöðu sé að ræða. Gættu þessa að innri virkni stöðu (t.d. entry, exit, do) eigi við um öll stöðuskipti sem liggja að/frá stöðu. Notaðu endurkvæm (e. recursive) stöðuskipti (þar sem stöðuskipti liggja aftur í sömu stöðu) bara þegar þú vilt endurtaka innri virkni eins og entry, exit eða do 92

93 11.4 Meira um stöðurit Kerfisgreining með UML Stöðurit eru notuð til að líkja eftir flóknum fyrirbærum og eru aðferðirnar við að gera þau nokkuð margar og að sumu leyti flóknar. Hérna eru tiltekin nokkur af þeim táknum og aðferðum sem notaðar eru við útfærslu ritanna. Það verður ekki farið djúpt í útskýringar á þeim Undirstöður/yfirstöður Undirstöður (e. substate) er stöðuvél innan í stöðu. Tiltekin staða getur verið með flókna innri virkni eða virkni sem þú vilt geta valið hvort þú sýnir eða ekki. Slíkum stöðum má lýsa með undirstöðum. Yfirstaða (e. superstate) er sú staða sem hefur undirstöður Jón Freyr Jóhannsson 93

94 Samsíða/samskeiða/samhliða ferli Samsíða/samskeiða/samhliða ferli (e. concurrent state) tákna að farið er í tvær eða fleiri undirstöður samtímis og vinna þær allar í einu óháðar hinum. Ferlin eru aðskilin með brotnu striki. Dæmi um skilyrt stöðuskipti í samskeiða ferli: 94

95 Samsett staða Kerfisgreining með UML Samsett staða (e. composite state) er staða sem er samsett úr tveimur eða fleirum samsíða/samskeiða undirstöðum eða undirstöðuvélum, hún getur líka verið samsett úr tveimur eða fleirum óháðum (þ.e. ekki samsíða/samskeiða) stöðum. Talað er um að svæði (e. region) sem þá undirstöðu sem samsetningin nær til Undirstöður geta haft sjálfstæða upphafsstöðu og/eða lokastöður. Stöðuskipti í samsetta stöðu jafngildir stöðuskiptum í upphafsstöðu undirstöðu. Ef um er að ræða samsíða/samskeiða undirstöður þá er jafngildir þetta stöðuskiptum í upphafsstöðu þeirra allra Stöðuskipti í lokastöðu undirstöðu jafngilda því að verknaði lýkur Hægt er að fara beint í tiltekna stöðu undirstöðunnar óháð upphafsstöðu hennar Dæmi um samsetta stöðu: Observer Overhead Projector Active above Armed below Triggered cancel On Desk Light Off On Floor Light On 2007 Jón Freyr Jóhannsson 95

96 Sögustaða Sögustaða (e. history state) er táknuð með hring með bókstafnum H inni í. Sögustaðan vísar til þess svæðis (e. region) sem táknið er staðsett í. Ef komið er í sögustöðuna þá er farið í þá stöðu innan svæðisins (í samsettu stöðunni) sem síðast var komið úr. Sögustaða getur haft mörg stöðuskipti til sín og ein ómerkt stöðuskipti frá sér sem vísa þá til default fyrri stöðu (e. previous state) ef ekki hefur verið farið á þetta svæði áður. Allar upphafsaðgerði (e. entry actions) eru framkvæmdar. Sögustaða vísar til stöðu (hugsanlega samsettrar) sem er á sama svæði (e. region eða level) og sögustöðutáknið er. Hægt er að tákna að farið sé dýpra, þ.e. í lægri undirstöðu, hvar sem er í undirstöðum með því að hafa stjörnu á eftir H-inu í sögustöðutákninu. Á sama svæði mega bæði vera djúpar og grunnar sögustöður. Dæmi um stöðurit með sögustöðum: H Tákn sögustöðu (e. history state) H* Tákn djúprar sögustöðu (e. deep history state) 96

97 Samhæfingarstaða Samhæfingarstaða (e. synch state) er táknuð með hring með stjörnu inni í. Samhæfingartáknið er staðsett á línu sem skilur samsíða undirstöður. Samhæfingarstaða er t.d. notuð til að samhæfa tímasetningar verknaða / staða í samsíða-/samskeiða undirstöðuvélum. * Tákn samhæfingar (e. synch state) Undirstaða - stubbar Stöðuskipti inn í undirstöðu má tákna með stubbum og þar má gefa slóðir (e. path) á enn dýpri undirstöður Jón Freyr Jóhannsson 97

98 Falin undirstaða (samsett) Til einföldunar getum við sleppt að sýna sjálfar undirstöðurnar og einungis sýnt yfirstöðuna. Þá notum við sérstakt táknmál til að sýna að staðan er samsett, þ.e. til eru undirstöður. Ekki er skilyrði í UML að sýna þetta tákn Tákn sem sett er í stöðu til að sýna að hún er samsett staða Samsett staða (e. composite state) Tákn samsettrar stöðu (e. composite state) Samsett staða (e. composite state) Jafngildir Tákn samsettrar stöðu í VISIO 98

99 Samsett stöðuskipti Kerfisgreining með UML Samsett stöðuskipti (e. compound transition) einfalda annars flókna framsetningu. Samsett stöðuskipti með [else] verði (e. guard): 2007 Jón Freyr Jóhannsson 99

100 100

101 12 Verknaðarrit Verknaðarrit (e. activity diagrams) eru sérstakt tilbrigði eða afbrigði af stöðuritum. Á verknaðarritum tákna stöðurnar framkvæmd tiltekinna aðgerða eða virkni og stöðuskipti verða síðan við að aðgerðum eða virkni lýkur. Þ.e.a.s. staðan er virk meðan tiltekin aðgerð eða virkni er framkvæmd. Tilgangur verknaðarrita er að sýna flæði sem verður vegna innri virkni aðgerða, notkunardæma eða virkni klasa. Samhengi verknaðarrita við önnur rit UML er það sama og stöðurita: Sölumaður Skrá nýjan viðskiptamann Skrá nýja pöntun Pöntun Viðskiptamaður Farmur pöntun viðskiptamaður skrá nýja pöntun staðfesta greiðsluhæfi Sölumaður Vara skráð í pöntun Farmur tilbúinn Stöðurit - Samhengi við önnur rit

102 12.1 Táknmál verknaðarrita Táknmál verknaðarrita byggir á sömu táknum og tákn á stöðuritum en auk þess eru fleiri tákn og auk þess hafa sum táknin lítilsháttar aðra merkingu en á stöðuritunum Verknaður/verknaðarstaða Staða, sem í þessu samhengi við köllum líka verknað (e. activity) eða verknaðarstöðu (e. activity state) Staða (e. state) Staða (e. state) Tákn stöðu (e. state) Upphafs- og lokastaða Sama tákn og merking og á stöðuritum Stöðuskipti Sama tákn og á stöðuritum. Nú er hins vegar ekki atburður sem ræður stöðuskiptum heldur það að verknaði er lokið og þess vegna haldið áfram Ákvörðun Ákvörðun (e. decisions) er táknuð með tígli þar sem ein ör eða fleiri (stöðuskipti) koma inn í tígulinn (oftast ein) og síðan tvær eða fleiri örvar (stöðuskipti) sem fara úr honum. Oft er talað um ákvarðanatökutígul þegar vísað er til svona Allar einkunnir reiknaðar? [nei] Tákn lokastöðu (e. final state) tákni stöðuskipta er ofaukið Tákn upphafsstöðu (e. initial state) tákni stöðuskipta er ofaukið Tákn stöðuskipta (e. transition) Tákn ákvörðunar (e. decision) á verknaðarriti ákvörðunar. Spurningin sem ákvörðunin byggir á er oft sett við tígulinn. [já] Ákvörðun er skilgreind Tákn ákvörðunar með spurningu ákvörðunar af vörðum (e. guards) sem tilgreindir eru á örvum/-stöðuskiptum sem fara úr tíglinum. Sleppa má að skilgreina vörð við ein stöðuskiptin og tekur hún þá til allra annara möguleika en skilgreindir eru á hinum stöðuskiptunum (eins og else í if- eða case-setningu, eða eins og default annarsstaðar) [x<0] Tákn ákvörðunar með vörðum [x=>0] 102

103 Samstillingarstrik Samstillingarstrik (e. synchronization bar) er táknað með breiðu striki sem gengur þvert á stefnu stöðuskipta. Samstillingarstrik eru notuð til að samhæfa virknina t.d. með því að tryggja að ekki sé haldið áfram fyrr en fleiri en ein verknaðarstaða hefur lokið virkni og getum þannig sýnt betur forsendur viðkomandi ferlis. Kerfisgreining með UML Samstillingarstrik sýna: ef fleiri en ein stöðuskipti koma að samstillingarstriki (sameining) þá verður ekki haldið áfram frá samstillingarstrikinu fyrr en öll eru komin. ef fleiri en ein stöðuskipti liggja frá samstillingarstriki (gaffall) þá virkjast þau öll á sama tíma og starfa samskeiða eða samsíða (e. concurrent). Samstillingarstrik geta verið flóknari. Við getum sett saman gaffal og sameiningu eins og okkur sýnist en hafa þarf í huga skýrleika rits og tilgang 2007 Jón Freyr Jóhannsson 103

104 12.2 Sundbrautir Sundbrautir eru notaðar til sýna á skýran hátt skipulag aðgerða eða verknaðar þannig að fram komi hver (gerandi eða jafnvel klasi) ber ábyrgð eða hefur með tiltekna þætti aðgerðar eða verknaðar að gera Sundbrautir (e. swimlanes) eru táknaðar með lóðréttu óbrotnu striki Sundbrautir hafa enga merkingarbæra þýðingu, þær eru eingöngu hugsaðar til frekari skýringar Dæmi um sundbrautir: 104

105 12.3 Hvernig gerum við? Kerfisgreining með UML Við gerð verknaðarrita getum við haft til hliðsjónar leiðbeiningar um gerð stöðurita og haft einnig í huga eftirfarandi: Verknaðarstöður má finna út frá lýsingum notkunardæma Verknaðarstöður ætti að gefa heiti út frá sjónarhóli kerfis (eða kerfisgeranda) en ekki frá sjónarhóli geranda Verknaður er eitthvað sem tekur tíma Aðgerð (stöðuskipti á stöðuriti) tekur svo skjótan tíma (frá okkur séð) að litið er á hann sem engan tíma UML notar sama táknið til að tákna stöðu á stöðuriti og verknaðarstöðu - við verðum að hafa það í huga að þetta eru samt gjörólík fyrirbæri með tilliti til tíma og innihalds 12.4 Hafa ber í huga... Hér koma nokkrar ábendingar um það sem hafa ber í huga og hvað ber að varast. Þetta eru ekki nein heilög sannindi, einungis ábendingar. Alltaf skal hafa upphafs og lokastöðu á verknaðarritum. Reyndu ef hægt er að hafa ritið í þægilegri lesröð, þ.e. upphafsstaða efst til vinstri og lokastaða neðst til hægri. Eru einhver svarthol? Svarthol eru stöður þar sem mörg stöðuskipti liggja að en engin frá. Slíkt er ekki nema um eiginlega lokastöðu sé að ræða. Eru einhver kraftaverk? Kraftaverk eru stöður þar sem engin stöðuskipti liggja að, en ein eða fleiri frá. Slíkt er aldrei nema um eiginlega upphafsstöðu sé að ræða Verknaðarrit samantekt Verknaðarrit: Geta á myndrænan hátt sýnt flæði atburða í notkunardæmi Geta verið notið til að dýpka skilning á vinnuferli áður en tekið er til við gerð notkunarlíkana (væri þá notað á kröfulýsingarstiginu) Sýna skref sem framkvæmd eru í útreikningum eða úrvinnslu Hvert skref er sú staða að gera eitthvað Þessi skref eru kölluð verknaðarstöður (e. activity states) Lýsir hvaða skref eru unnin í runu (röð) og hver þeirra er hægt að vinna samhliða/samskeiða Stöðuskipti eru hér til að lýsa flæði stjórnunar (e. flow of control) frá einni verknaðarstöðu til annarar Lýsingar notkunardæma eru oft skrifaðar fyrir utanaðkomandi gerendur sem ekki hafa mikla þekkingu á innri virkni kerfisins, verknaðarrit miðast við sjónarhorn kerfisgerandans sem þekkir virknina betur 2007 Jón Freyr Jóhannsson 105

106 106

107 13 Ýmis fróðleikur - bland í poka Hér í þessum kafla er fjallað (mjög) stuttlega um nokkur atriði sem tengjast klösum og klasaritum. Umfjöllunin er stuttaraleg þar sem margt af því sem hér er nefnt er þess eðlis að útfærsluleiðir (forritunarmál, gagnagrunnar o.fl.) ráða miklu um notkun þessara möguleika UML 13.1 Málfræði eiginda Þegar við skilgreinum eigindi klasa getum við verið mjög nákvæm í skilgreiningum á þeim. Skilgreining á málfræði eiginda (e. attribute) líkist skilgreiningu á færibreytum (e. parameter) í forritum. Fform skilgreiningar er eins og skilgreiningar í forritunarmálum): sýnileiki nafn [vídd] : tag = upphafsgildi {eiginleikar} dæmi: -einingar[1..100]:string = NULL Sýnileiki (má sleppa): + public, sýnilegur utan klasa - private, sýnilegur innan klasa # protected, sýnilegur innan klasa og til undirklasa Vídd (má sleppa): [neðri mörk..efri mörk]: Skilgreinir stærð töflu eða fylkja, dæmi: Tafla[1..10] Ef ekkert er tilgreint er sjálfgefið [1..1] Tag og upphafsgildi er háð skilgreiningu viðkomandi forritunarmáls (má sleppa) Eiginleikar (má sleppa): Nánari lýsing á eigindi, t.d. gæti fasti verið skilgreindur með {frozen}

108 13.2 Málfræði aðgerða Þegar við skilgreinum aðgerðir klasa getum við verið mjög nákvæm í skilgreiningum á þeim. Skilgreining á málfræði aðgerða (e. operation) líkist skilgreiningu á færibreytum (e. parameter) í forritum. Form skilgreiningar er eins og skilgreiningar í forritunarmálum): sýnileiki nafn (breytulisti) : skilagildi {eiginleikar} dæmi: +normalisera(fylki) : boolean Sýnileiki (má sleppa): + public, sýnilegur utan klasa - private, sýnilegur innan klasa # protected, sýnilegur innan klasa og til undirklasa Nafn heiti aðgerðar Breytulisti (má sleppa): breytur aðgreindar með kommu. Skilgreining breytu er: tegund nafn : tag = sjálfgefið gildi tegund er in, out eða inout (in er sjálfgefið) Skilagildi háð skilgreiningu viðkomandi forritunarmáls (má sleppa). Eiginleikar (má sleppa): {query} gæti t.d. sýnt okkur að viðkomandi aðgerð er einungis fyrirspurn, þ.e. hún breytir engu 108

109 13.3 Pakkar Pakki (e. package) er hugtak yfir það þegar nokkrir klasar og vensl þeirra eru dregnir saman í eitt (til einföldunar). Það geta verið mörg klasarit innan sama kerfis og hvert klasarit er mynd af hluta (eða öllum) af pökkum og klösum. Pakki er táknaður með skjalavasatákni (e. folder) og er nafn pakkans á tákninu miðju. Yfirlitsklasarit (e. main class diagram) er notað til að sýna samhengi allra klasaritanna (t.d. með því að nota pakkahugtakið). Hver pakki hefur sitt eigið klasarit. Dæmi um yfirlitsklasarit eða pakkarit eins og þau eru stundum kölluð þegar eingöngu er um að ræða pakka á ritinu. Um venslin milli pakka má lesa betur í skjölun um UML á Námsmat Nemendabókhald Stundatöflur Dæmi um pakkarit 2007 Jón Freyr Jóhannsson 109

110 13.4 Flokkar klasa sem kunna þarf skil á Nokkur hugtök eru notuð til að greina á milli meginflokka klasa: Greint er á milli eftirfarandi tveggja flokka klasa (þeir eru alltaf af annarri hvorri gerðinni): Hugrænn klasi (e. abstract class) er klasi sem hefur engin tilvik, lýsir skipan (e. structure) hluta. Hlutrænn klasi (e. concrete class) er klasi sem hefur tilvik. Hluti klasa eru augljósir út af viðfangsefnum kerfa (kjarnaklasar) en aðrir eru nauðsynlegir til útfærslu: Kjarnaklasar (e. application domain classes/ business classes...) sem við finnum út frá kerfislýsingum og fleiru slíku og þá hugsanlega með nafnorðagreiningu, stundum kallaðir greiningarklasar. Hlutir sem eru til, sem við getum tengt viðfangsefninu. Dæmi: Bók, Bíll, Reikningur, Banki. Klasar sem við skilgreinum og hönnum til þess að kerfið virki að öðru leyti, að hægt sé að framkvæma það sem þarf. Stundum kallaðir hönnunar og/eða útfærsluklasar. Dæmi: Tengi-/skilaklasar (e. interface classes), umsýsla um söfn og lista. Hönnunarklasa, skipun eins og í UNDO hluta ritvinnslukerfis og SöguListi í vefsjá (e. webbrowser). Þessir klasar koma til vegna (hönnunar) útfærslu sem nauðsynleg er til að framkvæma það sem greining hefur komið fram með, en hefur ekki á greiningarstigi verið útfært til fullnustu. Útfærsluklasar. TengdurListi, Fylki, Biðröð eða annað sem t.d. flokkast undir gagnaskipan eða aðrar leiðir til geymslu og meðhöndlunar upplýsinga kerfis en hafa ekki beint með viðfangsefni kerfisins að gera. Í upphafi, við greiningu, þá erum við mest að velta fyrir okkur kjarnaklösum, greiningarklösum. Af öðrum flokkum klasa má nefna template -klasa og parameter -klasa. 110

111 13.5 Snið Kerfisgreining með UML Snið (e. stereotype) er skilgreining sem er aðferð UML til að skýra betur frá einhverju, bæta við grunnskilgreiningar, gefa nánari flokkun eða eðli til kynna. Oftast erum við ekki að nota þessari skilgreiningu en í ákveðnum tilvikum hjálpar hún. Snið eru táknuð þannig að heiti sniðsins er umlukið táknunum «og» Á klasaritum getur t.d. verið um að ræða snið af gerðinni: «interface» «type» notað til að skilgreina t.d. tag «implementation class» útfærir «type» «utility» safn víðværra (e. global) eiginda og aðferða eigin skilgreind snið «stereotypes» Snið geta komið við sögu víða. Táknmál sniðs í klasa er t.d.: Í efsta reit klasa, nafnareitnum geta verið eftirfarandi upplýsingar: Snið (e. stereotype) skilgreint innan Nafn þarf alltaf að vera til staðar Skilyrði/skorður (e. constraints) (sjá næsta kafla) Í hlut/tilviki gæti einnig verið notað snið: «instance» «instance of» «snið» Klasinn {skorður} Dæmi um táknmál Dæmi um táknmál: «type» Upphæð {fastir 6 aukastafir} «actor» = Kennari Kennari Dæmi um klasa með skilgreindu sniði og skorðum Kennari Dæmi um táknmál. Tvö fyrri táknin eru jafngild, tákna gerandann (e. actor) kennara, það þriðja táknar klasann kennara 2007 Jón Freyr Jóhannsson 111

112 13.6 Skorður/takmarkanir Skorður (e. constraints) eru skilyrði sem við setjum réttri útfærslu á hönnun. Skorður eru táknaðar með oddasviga utan um skorðurnar { }. Skorður má nota á margvíslegan hátt, en varast skal ofnotkun því slíkt getur flækt framsetningu líkana og takmarka oft útfærslu. Við getum sett tengslum ákveðnar skorður: Bók Eintak {XOR} Tímarit Dæmi um skorður: Annað hvort / XOR Skorður geta einnig komið við sögu í klösum á þennan hátt (sjá til hliðar): Campaign <<PK>> campaign_code : String campaign_title : String date_start : Date date_close : Date date_drawn : Date num_tickets : Integer / num_tickets_sold : Integer computeticketssold() : Integer computeticketsleft() : Integer computeduration() : Integer computedaysleft(today : Date) : Integer CampaignTicket ticket_number : String ticket_value : Currency ticket_status : String * {each ticket_number is only unique within its containing campaign} 112

113 Fleiri dæmi um skorður created Event description : String created_dt : Date due_dt : Date completed_dt : Date priority : Byte 0..* {Employee.created!= Employee.due} 0..* 1 due 1 0..* 0..1 Employee <<PK>> employee_id : String family_name : String first_name : String middle_name : String completed {author = Les, status = 2nd iteration} 1..1 Task description : String created_dt : Date value : Currency 0..* <<constraint>> Employee who created a task must also create - in a single transaction - the first event for that task. created Event 1..* description : String created_dt : Date due_dt : Date completed_dt : Date priority : Byte 0..* {Employee.created!= Employee.due} 0..* 1 due 1 0..* Employee <<PK>> employee_id : String family_name : String first_name : String middle_name : String completed 2007 Jón Freyr Jóhannsson 113

114 13.7 Afleidd tengsl Afleidd tengsl (e. derived association). Þegar klasarit eru unnin er oft spurning um það hvort sýna eigi tiltekin tengsl eða hvort leiða megi þau af öðrum tengslum. Við getum sýnt afleidd tengsl þegar einn klasi tengist öðrum, en ekki beint heldur gegnum aðra, en til nánari skýringar viljum við sýna þessi tengsl. Tengslin eru því alls ekki eins og önnur tengsl heldur lesa-má-þetta-eftir-öðrum-leiðum -tengsl! Afleidd tengsl eru sýnd þannig að þau hafa nafn og fyrir framan það er skástrik /. Dæmi: /er kennari, /er afi eða amma Dæmi um afleidd tengsl: Customer customer_name : String customer_address : String phone_number : String _address : String * /CustInv 0..* Invoice invoice_number : String invoice_date : Date invoice_total : Currency Order order_number : String order_date : Date ship_address : String order_total : Currency order_status : String salesperson_name : String

115 13.8 Lykluð tengsl Margfeldisþáttur er ekki alltaf gegnsær, það er ekki alltaf ljóst hvernig hann er samsettur. Við getum stundum notað lykluð tengsl (e. qualified association) til að útskýra betur. Sýning -heiti sýningar Sýning -heiti sýningar Kerfisgreining með UML Lykluð tengsl eru táknuð þannig að kassilaga tákn er á endanum á Lykluð vensl geta einfaldað/útskýrt margfaldara venslunum sem verið er að skýra og inn í hann er skrifað hvaða eigindi eru sem lyklar þ.e.a.s. hvað það er sem ræður tengslunum þannig að þau verði einkvæm. dags sæti 1 * 1..* 0..1 Miði Miði Fleiri dæmi um lykluð tengsl: Banki reikningsnr Einstaklingur * 0..1 Flug -flugnúmer brottför sætisnúmer 1..* 0..1 Farþegi Dæmi um lykluð vensl 13.9 Yfirskrift í erfðum Klasi erfir eigindi og aðgerðir yfirklasa, en getur einnig endurskilgreint (yfirskrifað) aðgerðir eða eigindi. Þetta er t.d. gert þegar unnið er með annars konar tög í undirklasa heldur en í yfirklasa eða þegar reikni- eða úrvinnsluaðferð er önnur í undirklasanum en yfirklasanum. Tónleikar +getdags() +printmiðaupplýsingar() +computemiðareftir() VIP-Tónleikar +printmiðaupplýsingar() +computemiðareftir() Dæmi um erfðir þar sem aðgerðir eru yfirskrifaðar t.d. vegna mismunandi virkni eða ólíkra taga 2007 Jón Freyr Jóhannsson 115

116 13.10 OCL OCL (e. object constraint language) er formlegt mál (e. formal language), þ.e. það á sér skilgreiningu sem sett er fram með formlegum hætti eins og um forritunarmál gildir almennt (sjá á en.wikipedia.org/wiki/object_constraint_language). OCL var skilgreint í upphafi af IBM og byggði á verkefni sem heitir Syntropy (sjá á en.wikipedia.org/wiki/syntropy). Það hefur helstu einfalda virkja (e. constructs) sem forritunarmál hafa og skilgreinir helstu gagnatög og einnig mengi og lista (e. sets, lists bags o.s.frv.). OCL setning samanstendur oftast af: Samhengi (e. context) sem unnið er með. Oftast er um að ræða tilvik klasa (þ.e. hlut) en getur einnig átt við vensl, skeyti o.fl. Eiginleikar (e. properties) þess sem unnið er með (sbr. samhengi hér að ofan). Eiginleikar geta vísað til eiginda, vensla eða fyrirspurna/niðurstaðna úrvinnslu OCL aðgerð (e. operation) sem beitt er á eiginleikana. Aðgerðirnar geta t.d. verið reikniaðgerðir (+,-,/, *), samanburðaraðgerðir (and, or, xor) en einnig aðrar aðgerðir. Aðgerðir geta einnig innihaldið önnur frátekin orð/lykilorð (e. keyword) OCL hefur nokkur frátekin orð (eins og í forritunarmáli). Frátekin orð (e. keywords) eru: and, attr, context,, def, else, endif, endpackage, if, implies, in, inv, let, not, oper, or, package, post, pre, then, xor OCL-segð (e. expression) er í skrifuð í samhengi við tilvik af tilgreindu/- skilgreindu tagi. Í OCL-segð er frátekna orðið self notað til að vísa í tilvikið sem á við í þessu samhengi, þetta er samsvarandi venju í mörgum forritunarmálum. Skorður er hægt að skrifa í OCL: {self.noofstudents > 50 implies (not (self.room = 231A))}. táknar að ef nemendur í námskeiði eru fleiri en 50 sé ekki hægt að nota stofu 231A (sem einungis rúmar 50 nemendur). Meira um OCL má finna á 116