Uzdevuma nostādne - datubaze.files.wordpress.com · Web viewUzdevuma nostādne

Aļona Ivaņecka. Klašu modeļa projektēšana ar PowerDesigner. 2008.

Saturs

Uzdevuma nostādne................................................................................................................3

1. Problēmvides apraksts....................................................................................................4

2. Klašu diagrammas veidošana.........................................................................................4

2.1. Klašu projektēšana..................................................................................................6

2.1.1. Klašu atribūtu definēšana...............................................................................7

2.1.2. Domēnu veidošana........................................................................................10

2.2. Asociāciju definēšana...........................................................................................11

2.2.1. Asociācija starp klasēm................................................................................12

2.2.2. Kompozīcija starp klasēm.............................................................................13

2.2.3. Agregācijas starp klasēm..............................................................................15

2.2.4. Vispārināšana starp klasēm (mantošana)......................................................16

2.2.5. Rekursīvā asociācija.....................................................................................18

2.3. Stereotipi un to lietošana......................................................................................18

2.4. Metožu definēšana................................................................................................19

2.4.1. Statiskās metodes..........................................................................................20

2.4.2. Dinamiskās metodes.....................................................................................21

2.5. Klašu diagrammas projektēšanas grafisks rezultāts.............................................25

3. Klašu diagrammas analīze............................................................................................27

4. Secinājumi....................................................................................................................30

Izmantotā literatūra...............................................................................................................31

Uzdevuma nostādne

Izmantojot CASE rīku PowerDesigner, tiek izveidots klašu modelis, kas iekļauj sevī

datu bāzes projektēšanai nepieciešamo informāciju. Lai attēlot klašu diagrammas

dinamisko pusi, tad tiek izveidota sadarbības diagramma, kas parāda kādi lietotāji izmanto

kādas sistēmā nodefinētas funkcijas.

2

1. Problēmvides aprakstsJāizprojektē datu bāze automašīnu nomas servisam. Datu bāze glabās informāciju par

autonomu, tās filiālēm un darbiniekiem, tai piederošajām automašīnām, kā arī par klientiem

un viņu prasībām attiecībā uz automašīnām.

Ir jābūt iespējai veikt automašīnu atlasi pēc klientu prasībām, kā arī pēc ražotājiem,

klientus pēc to lietotāja vārda elektroniskajā sistēmā un autonomas filiāles pēc to

nosaukuma un adreses.

Ērtākai datu bāzes satura apskatei jābūt skatam, kur būtu attēlotas autonomas kopā ar

tās piedāvātajiem automobiļiem un skatam, kurš parādītu visas filiāles un visus to

darbiniekus.

2. Klašu diagrammas veidošanaIzmantojot PowerDesigner DB projektēšanas rīku, ir nepieciešams konstruēt sistēmas

Klāšu diagrammu.

Klašu diagramma parāda modeļa statisko struktūru: būtības, kas eksistē sistēmā, to

iekšējo uzbūvi un attiecības ar citām sistēmas būtībām. Klases diagrammas pamata

elementi ir klases un attiecības starp tām. Klases attēlošanai ir izvēlēta Rambo (James

Rumbaugh) piedāvāta konstrukcija – sadalīts trīs daļās taisnstūris. Augšējā daļā ir parādīts

klases nosaukums. Klases struktūra ir parādīta ar atribūtu (īpašību) kopu. Klases uzvedība

ir parādīta ar metodēm (operācijām). Realizācijas līdzekļi nodrošina to, kā operācijas uzreiz

ir piesaistītas pie klasēm (ievērojot objektu grupēšanu), tā kā secību diagrammas parāda

objektu uzvedību.

1.att. Klašu diagrammas struktūra

3

Projektējot klašu diagrammu ir svarīgi atcerēties par sakarību, ko bieži vien piemin DB

projektēšanā, ka zinot sistēmas konceptuālo modeli, bez problēmās var uzkonstruēt arī

sistēmas klašu diagrammu (skat. 2.att).

2.att. Sakarība starp Sadarbības, Klašu un Konceptuālo modeli

Lai uzsākt Klašu diagrammas projektēšanu, jāsāk ar to, ka jāuztaisa bāzes klašu

modelis. Atverot sistēmu izvēlamies komandas rīku File -> New.

Izveidoju jaunu objektu orientētu modeli, kuru nosaucu par BD_klasu_diagrama_01.

4

2.1. Klašu projektēšanaGalvenā objektu orientācijas filozofija meklēt objektus ar līdzīgiem atribūtiem un

metodēm un apvienot tos klasē. Objekti ar līdzīgu datu struktūru (atribūtiem) un uzvedību

(metodēm) ir apvienoti klasēs.

Objekts (klases eksemplārs) ir veidots piešķirot klases atribūtiem noteiktas vērtības

(objekta inicializācija).

Klases veidošanu sāk, klases modeļa veidošanas rīku paletē izvēloties klases ikonu un

noklikšķinot diagrammas zīmēšanas logā, kā rezultātā tiek izveidota klase, kurai pēc

noklusējuma tiek piešķirts nosaukums Class_1.

Class_1

3.att. Klases diagrammasveidošanas rīku palete

4.att. Klase

Kad klase ir izveidota, nepieciešams, tai piešķirt citu nosaukumu, kā arī definēt

atribūtu un metožu sarakstu. Lai to izdarītu, divas reizes nepieciešams noklikšķināt uz

klases pēc kā atveras klases īpašību (Class properties) logs (skat. 5.att.).

5

5.att. Klases īpašību loga General iedaļa

Īpašību loga General iedaļas saturs:

Name - Klases nosaukums.

Code - Klases atsauces kods.

Comment - Klases informatīvs apraksts.

Stereotype – Klašu grupējums pēc kopīgās pazīmes.

Visibility – Klases pieejamība citām klasēm. “+”public–redzams un sasniedzams

no jebkuras citas klases; “#”protected–redzams un sasniedzams no klases

apakšklasēm; “-”private–nav redzams un sasniedzams ārpus klases; ja redzamību

nenorādīt, pēc noklusēšanas atribūts ir privāts.

Cardinatily - eksemplāru skaits norāda šī tipa atribūtu skaitu, kas ir šīs klases

sastāvā, [0..1] vai [1..*] vai [1..3, 7..10]; ja skaits nav norādīts, pēc noklusēšanas 1.

2.1.1. Klašu atribūtu definēšanaKad klasei dots nosaukums nepieciešams definēt tās atribūtus. Klases atribūti ir datu

vienības, kas piesaistītas klasei. Tā kā klašu modelis manto klases no konceptuālā modeļa,

tad arī atribūti paliek tie paši.

6

Nodefinēt atribūtus var realitātes Īpašību loga Atributes iedaļā (skat. 6.att.).

6.att. Klašu atribūtu logs

Kad atribūti ir nodefinēti, tos var pievienot jebkurai no nākošajām klasēm tās

īpašību logā Atribute iedaļā, noklikšķinot ar pelīti uz ikonas Add Data Item (pievienot

datu vienību – attēlā ikona apvilka ar sarkanu līniju), pēc kā parādās logs ar datu vienību

sarakstu, kur, pieliekot ķeksīti blakus datu vienības nosaukumam, tiek norādīts, ka datu

vienība jāpievieno klases atribūtu sarakstam (skat. 7. att.).

7.att. Datu vienības pievienošana klašu atribūtu sarakstam

7

Atribūta īpašības var definēt klašu īpašību logā, kā arī atribūtu īpašību logā, kas

parādās iezīmējot kādu no izveidoto atribūtu ierakstiem klašu īpašību logā un divas reizes

uzklikšķinot ar pelīti uz šīs iezīmētās rindiņas, pēc kā parādās atribūta īpašību logs (skat.

8.att).

8.att. Atribūta īpašību logs

Katras realitātes atribūtu definīcija ietver sekojošas īpašības:

Generale satur:

Name – realitātes atribūta nosaukums.

Code – atsauces kods realitātes atribūtam.

Comment – informatīvs apraksts par realitātes atribūtu.

Stereotype - Klašu grupējums pēc kopīgās pazīmes.

Visibility - Klases pieejamība citām klasēm. "+"public-redzams un

sasniedzams no jebkuras citas klases; "#"protected-redzams un sasniedzams

no klases apakšklasēm; "-"private-nav redzams un sasniedzams ārpus klases;

ja redzamību nenorādīt, pēc noklusēšanas atribūts ir privāts.

Data type – atribūta datu tips.

Details

Changeability – iespēja mainīt vērtību, konkrētajā laukā.

Primary Identifier – norāda uz to, vai dotais atribūts ir vai nav primārā

atslēga realitātei.

8

Standard Checks – vispārīgi datu ierobežojumi. Proti, šajā atribūta īpašību loga iedaļā

var definēt sekojošas īpašības (skat.8.att.):

Minimum – vismazākā numeriskā pieņemamā vērtība. Tā kā 8. attēlā

parādītajam atribūtam ir Text datu tips, tad šo vērtību nav nepieciešams norādīt

atribūta īpašību Standart Checks iedaļā, tāpat ir arī ar nākošo īpašību –

Maximum.

Maximum – visaugstākā pieņemamā numeriskā vērtība.

Default - vērtība pēc noklusējuma, kas pēc noklusējuma parādīsies fiziskās

tabulas kolonnā. Manā piemērā pēc noklusējuma Namīpašumu dati tabulas

kolonnā Nelikumīga būvniecība pēc noklusējuma parādīsies vērtība - Nav.

Unit – standarta mērs

Format - datu formāts (piemēram, 9999.99). Manā gadījumā norādīts standarta

mēru un datu formātu nav nepieciešams.

Lowercase – norāda, lai visi alfabētiskie simboli būtu mazo burtu formā. Kā

redzams esmu to arī norādījusi, tātad tabulas kolonnā Nelikumīga

būvniecība visas vērtības parādīsies mazo burtu formātā.

Uppercase - norāda, lai visi alfabētiskie simboli būtu lielo burtu formā.

Cannot Modify – aizsargā no izmaiņām, parādās kā nemodificējama

kolonna fiziskā datu tabulā.

List of Values – atļautās vērtības fiziskas datu tabulas kolonnā.

2.1.2. Domēnu veidošanaAr domēnu palīdzību iepriekš var uzdot, kāda tipa datus saturēs mūsu izvēlētie

lauki. Ar šādas metodes palīdzību var novērst dažādu vēlāku kļudu veidošanos.

Lai izveidotu domēnu, no rīku joslas jāizvēlas komanda no rīku joslas Model ->

Domains. Kad tas izdarīts, atvērsies domēnu saraksts (9.att.).

9

9.att. Domēnu saraksta definēšana

Name - ievadītie simboli būs šī domēna pazīmējums. Šis apzīmējums tiks

piedāvāts kā datu tips kādam no tabulas laukiem.

Data Type laukā var izvēlēties domēna datu tipu. Iespējamos datu tipus var

apskatīt uzspiežot uz pogas, kas parādās, kad aktivizēts Data Type lauks.

Length – lauka garuma definēšana.

Precision - iespējams noteikt precizitāti, piemēram, cik cipari var būt aiz

komata.

Savai sistēmai izveidoju piecus domēnus:

1) Adrese, kura drīkst sastāvēt no maksimums 100 simboliem

2) Telefons, kas sastāv no 20 simboliem, jo gadās, ka telefona numuru pierakstot,

nepieciešamas arī zīmes kā „+”.

3) Uzvards noteiks uzvārdu garumu – 20 simboli

4) Vards noteiks vārda garumu – 20 simboli

5) ID, kas ļaus ievadīt tikai veselus skaitļus.

2.2. Asociāciju definēšanaAsociāciju veidošana ir viena no svarīgākajām lietam Klašu modeļa projektēšanā.

Asociācija ir saite starp divām klasēm.

Pastāv vairāki asociāciju veidi:

Agregācija – ir „vesels-daļa” vai „daļa no”

attiecība, kurā objekti, kas ir kaut kā daļas, ir

asociēti ar objektu, kas ir šo daļu konteiners.

10

Kompozīcija – ir agregācijas speciāls gadījums, kas raksturojas ar to, ka

agregāta sastāvdaļas, sauktas arī par komponentēm, ir neatņemamas šī agregāta

daļas, kas “dzīvo un iet bojā” reizē ar pašu agregātu.

Atkarība – ir asociācijas veids, kas nosaka, ka

vienai klasei ir nepieciešama saikne ar ortu

klasi, lai veikt savas funkcijas.

Mantošana – ir asociācija starp superklasi un vienu

vai vairākām tās apakšklasēm, kur apakšklases manto

superklases struktūru (atribūtus un asociācijas) un

uzvedību (operācijas). Mantošanu izmanto, lai

organizētu klašu hierarhiju. Mantošana var būt

organizēta divos virzienos:

o Vispārinājums - vispārinot kopīgos aspektus

eksistējošās klasēs superklasē (bottom-top).Modelī

jāmeklē klases ar līdzīgiem atribūtiem, asociācijām, vai

operācijām. Katram vispārinājumam jādefinē

superklase, kurā jāattēlo vispārināto klašu kopīgas

īpašības.

o Specializācija (sadalīšana) - seko no problēmvides: jāmeklēlietvārdu

frāzes ar dažādiem īpašības vārdiem, tās frāzes nosaka klases, kas var

būt sadalītās apaksklasēs.

Ja ir nepieciešams izveidot saiti starp divām klasēm, nepieciešams izvēlēties

simbolu attiecīgu rīku paletē. PowerDesigner piedāvā patvaļīgti norādīt, kuras divas klases

ir nepieciešams sasaistīt. Novelkot līniju no vienas klases uz otru pārādās asociācija, kuras

iestatījumus ir iespējams mainīt divas reizes uzklikšķinot uz tās.

2.2.1. Asociācija starp klasēmParastā asociācija ir vērojama starp klasēm „Auto modelis” un „Auto komplektācija”.

Tas nozīmē, ka abas starp abām klasēm ir sakarība, bet tā nav strikti noteikta, kā arī tā

nosaka, ka viena klase neiekļauj sevī otru (skat. 10.att.).

11

10.att. Parastās asociācijas piemērs

Asociāciju starp šīm divām klasēm var interpretēt kā gadījumu, kad katram auto

modelim tiek piedāvāta viena vai vairākas iespējamās komplektācijas.

2.2.2. Kompozīcija starp klasēmStarp klasi „Darbs” un „Auto noma” izvēlējos nodefinēt asociāciju, kas ir

kompozīcija. Kompozīcija šajā gadījumā nozīmē, ka klase „Darbs” ir cieši atkarīga no

klases „Auto noma”. Dzīvē to var izskaidrot ļoti vienkārši, ja uzņēmums Auto noma pārstās

pastāvēt, tad arī darbs šajā uzņēmumā nebūs (skat. 11.att.).

12

11. att. Kompozīcijas piemērs

General satur:

o Name – asociācijas nosaukums.

o Code - atsauces nosaukums asociācijai.

o Comment – asociācijas informatīvs apraksts.

o ClassA, ClassB – divas klases, kas savā starpā saistītas ar doto asociāciju.

o Stereotype - klašu grupējums pēc kopīgās pazīmes.

o Type – asociācijas veids.

o Container – norāda, kura klase kalpo par konteineri otras klases objektiem.

Kā redzams 11.attēlā saitei ir dots nosaukums „S2”, kas nozīmē, ka katrā autonomas

filiālē ir daudz darba ierakstu par darba vietām.

13

12.att. Kompozīcijas detalizācija

Sadaļā Details var redzēt kādas kardinalitātes ir piekārtotas katrai no klasēm.

Kardinalitāti raksta pie asociāciju galiem un tā apzīmē iespējamo klašu instanču skaitu, kas

atbilst vienai instancei no asociācijas pretējā gala.

<0..1> - klasē var nulle vai viens eksemplārs;

<1..1> - klasē var eksistēt tikai viens eksemplārs;

<1..*> - klasē var eksistēt viens vai vairāki eksemplāri;

<*> - klasē var eksistēt tikai vairāki eksemplāri;

<0..*> - klasē var eksistēt nulle vai vairāki eksemplāri.

Kopmozīcija ir vērojama arī starp klasēm „Auto noma” un „Klients”, „Darbs” un

„Darbinieks”, „Auto ražotājs” un „Auto modelis”.

2.2.3. Agregācijas starp klasēmStarp klasēm „Auto noma” un „Auto”, „Auto” un „Darba auto info”, „Auto” un

„Auto ražotājs”, „Auto ražotājs” un „Auto” autors ir izvēlējies asociācijas speciālo

gadījumu – agregāciju. Ir ļoti tipiska situācija, kad nepieciešams pateikt, ka kādas klases

objekti satur (“contains”) vai sastāv no (“consists of”) kādas citas klases objektiem. Šim

gadījumam ir paredzēta speciāla priekšdefinēta asociācija, kuru sauc par agregāciju, un

14

kuru grafiski attēlo ar līniju, kuras galā (pie klases - agregāta) tiek zīmēts rombiņš (skat.

13.att).

13.att. Agregācijas piemērs un detalizācijia

2.2.4. Vispārināšana starp klasēm (mantošana)Vispārināšana ir saistību veidošana starp vispārīgiem konceptiem (klasēm) un to

speciāliem gadījumiem (apakšklasēm).

Auto

Vieglais auto Smagais auto

Virsklase

Vispārināšanas attiecība

Apakšklases

Vispārināšanas attiecību, ja to aplūko pretējā virzienā (no virsklases uz apakšklasi),

sauc arī par specializācijas attiecību.

Ja mēs aplūkojam “Auto” klasi, ir iespējams arī cits vispārināšanas (jeb

specializācijas) variants.

15

Volvo Mercedes

Auto

BMW

Vispārināšana (un specializācija) ir galvenais līdzeklis, kuru nepieciešams lietot, kad

ir nepieciešamība apgūt kādu jaunu zināšanu apgabalu - jāsāk ar vispārīgiem jēdzieniem

(virsklasēm), pēc tam šos vispārīgos jēdzienus jāizskaidro sadalot tos sīkākos jēdzienos

(apakšklasēs). Vispārināšanas attiecību dažreiz sauc arī par Inheritances (mantošanas)

attiecību. (skat. 14.att).

14.att. Vispārināšanas piemērs

General

Name (Nosaukums) – mantošanas saites nosaukums.

Code (Kods) - atsauces kods mantošanas saitei.

Comment (Komentārs) – mantošanas saites informatīvs aprakts.

Parent (Realitāte - supertips) – supertipa realitātes nosaukums.

Children – norāda uz to, vai dalījums ir pilns vai nepilns, ja ieliek ķeksīti, tad

dalījums ir pilns, ja nē tad nepilns.

16

Kā redzams 15. attēlā ir definēta mantošanas saite starp klasi „Auto” un apakšklasēm

„Smagie auto” un „Vieglie auto”.

Auto--

Auto numursAuto darba info id

: int: int

Smagie_auto+++

Autonomas idRazotaja idTipa id

: int: int: int

Vieglie_auto+++


: int: int: int

15.att. Vispārināšanas realizācija diagrammā

2.2.5. Rekursīvā asociācijaPar rekursīvu asociāciju sauc ciklisku asociāciju, t.i. asociācija, kas savieno vienu un

to pašu klasi.

Manā gadījumā šāda veida rekursīvā asociācija izveidojās klasei „Darbinieks” (skat.

16.att.). Tas nozīmē, ka vienam vadītājam ir viens vai vairāki padotie.

1..1vada

1..*Darbinieks

-++++--

Darbinieka idDarbinieka vardsDarbinieka uzvardsAdreseTelefonsVaditajsDarba id

: int: java.lang.String: java.lang.String: java.lang.String: java.lang.String: int: int

16.att. Rekursīvās asociācijas piemērs

2.3. Stereotipi un to lietošana Stereotipi ir viens no spēcīgākajiem valodas UML autoru izgudrojumiem. Stereotipi

dod iespēju definēt jaunus elementu tipus balstoties uz esošajiem bāzes tipiem. Klašu

diagrammas gadījumā bāzes tipi ir: klase, asociācija, vispārināšana.

Klasēm par piemēru var definēt stereotipu <<Aktieris>> ar to saprotot klases, kuru

instances ir aktīvi elementi, t.i. elementi, kuri veic kādas darbības. Parasti tie ir cilvēki.

Tipiski klašu piemēri, kuri atbilst stereotipam <<Aktieris>>:

Persona Klients Sekretāre Students Pasniedzējs

17

Formāli stereotipus norāda tā, ka klases simbolā virs klases vārda divkāršajās asajās

iekavās raksta stereotipa vārdu:

Persona<<Aktieris>>

Klients<<Aktieris>>

Sekretāre<<Aktieris>>

Students<<Aktieris>>

Pasniedzējs<<Aktieris>>

Stereotipam var būt piekārtota arī ikona, kas to grafiski raksturo.

Rīks PowerDesigner ir ļoti ierobežots, attiecībā uz stereotipu izveidi. Taču,

piemēram, rīks GRADE paredz iespēju, kas oficiālajā UML nav iekļauta, rīks GRADE

atļauj stereotipam piekārtot arī simbola stilu – ģeometrisko formu, krāsu u.t.t. Piemēram,

mēs varam definēt, ka klases ar stereotipu <<process>> tiks attēlotas kā četrstūri ar

ieapaļiem stūriem sarkanā krāsā. Stereotipus var definēt pats lietotājs pēc saviem ieskatiem.

Stereotipus var lietot kā klasēm, tā arī asociācijām.

Veidojot savas sistēmas klašu diagrammu, kā piemērs tika lietoti divi stereotipi.

Viens apraksta visas klases, kas ir saistītas ar automašīnām, otrs – apraksta klases, kas ir

saistītas ar klientiem (skat. 17.att.).<<Auto>>

Auto_darba_info-++

Auto darba info idAuto pirksanas datumsDarba auto numurs

: int: java.util.Date: int

<<Auto>>Auto

----

Auto numursAuto darba info idRazotaja idAutonomas id

: int: int: int: int

<<Auto>>Auto_tips

-+

Tipa idTipa nosaukums

: int: java.lang.String

<<Klients>>Klients

-++-++--

Klienta numursVardsUzvardsPersonas kodsAdreseTelefonsTransporta apliecibas nrVestures id

: int: java.lang.String: java.lang.String: int: java.lang.String: java.lang.String: java.lang.String: int

<<Klients>>Klienta_vesture

-+

Vestures idApraksts


17.att. Stereotipi klasēm (pa labi klases ar stereotipu „Klients”, pa kreisi klases ar stereotipu „Auto”).

2.4. Metožu definēšanaKatras klases metodes nosaka, kādas funkcijas vai uzdevumus spēj paveikt klase ar

piederošajiem atribūtiem. Metožu attēlošana iekļauj sevī metodes vārdu un tipu.

Tā kā klašu diagramma ir statiskais IS modelis, tad zinot kādas ir klases ir iespējams

nodefinēt tikai SET un GET operācijas. Savukārt, lai noteikt operācijas starp klasēm ir

jārealizē IS dinamiskais modelis. Pie dinamiskiem modeļiem pieder tādas diagrammas kā

18

secību (sequence) un sadarbības (collaboration) diagrammas vai arī ir jābūt lielai pieredzei

projektēšanā, lai nodefinēt dinamiskas metodes nerealizējot dinamiskos modeļus.

2.4.1. Statiskās metodesLai nodefinēt klases statiskās metodes, nepieciešams divas reizes uzklikšķināt uz

vēlamās klases. Atvērsies klases īpašību logs, kurā nepieciešams izvēlāties loga sadaļu

Attributes (skat. 18.att.).

18.att. Metožu definēšanas piemērs

Ja ir zināms, ka būs nepieciešamas gan iegūt gan ievadīt vērtības kādā no klasē

nodefinētajiem atribūtiem, var izmantot pogu Add..-> Set/Get Opperations. Tas ļauj

automātiski izveidot metodes Set un Get iezīmētajam atribūtam (skat. 19.att.). Svarīgi ir

atcerēties, ka definējot metodes, tiek nodrošināta piekļuve šiem atribūtiem gan klases

robežās, gan ārpus tās. Tāpēc ir jāseko līdzi atribūtu „redzamībai”.

Ja ir zināms, ka klasē tiks izmantoti visi tās atribūti, un katram ir nepieciešams

izveidot metodi, tad laba programmēšanas pieredze rāda, ka atribūtiem jābūt statusā

„privat”. Šīs statuss ļauj izmantos atribūtu vērtību klases robežās.

19

19.att. Set/get metodes apskate

Pēc tam, kad visas metodes ir nodefinētas klase izskatās šādi:Auto_noma

-------

Autonomas idAuto numursAutonomas nosaukumsAutonomas adreseAutonomas telefonsKlienta numursDarba id

: int: int: java.lang.String: java.lang.String: java.lang.String: int: int

+++++++++++++++

<<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>>

get auto list (String search critheria)getAutonomasId ()setAutonomasId (int newAutonomas id)getAutoNumurs ()setAutoNumurs (int newAuto numurs)getAutonomasNosaukums ()setAutonomasNosaukums (java.lang.String newAutonomas nosaukums)getAutonomasAdrese ()setAutonomasAdrese (java.lang.String newAutonomas adrese)getAutonomasTelefons ()setAutonomasTelefons (java.lang.String newAutonomas telefons)getKlientaNumurs ()setKlientaNumurs (int newKlienta numurs)getDarbaId ()setDarbaId (int newDarba id)

2.4.2. Dinamiskās metodesKā jau minēju, klašu dinamiskās metodes ir iespējams noskaidrot uzprojektējot

secības vai sadarbības diagrammu.

Secību diagramma satur objektus un ziņojumus starp objektiem un parāda kā ir

organizēta objektu uzvedība konkrēta lietošanas gadījuma realizācijā.

20

20.att. Secību diagrammas konceptuālā shēma

Savukārt, sadarbības diagramma satur objektus, ziņojumus un attiecības starp

objektiem un parāda ne tikai ziņojumu sūtīšanas secību, bet arī strukturālās attiecības starp

objektiem, kas piedalās šajā secībā.

21. att. Sadarbības diagrammas konceptuālā shēma

Taču vislabāk izvirzītā mērķa sasniegšanai der tieši sadarbības diagramma, jo mērķi

ir noteikt dinamiskās metodes un sadarbības starp klasēm, nevis noskaidrot lietošanas

gadījumus. Šajā gadījumā secības diagramma ir garākais ceļš līdz mērķim.

Sadarbības diagrammas elementi:

Objekts – klases eksemplārs. Tā kā sadarbības diagrammā tiek atspoguļotas

attiecības starp klašu objektiem, tad var būt svarīgas lomas, ko objekti spēlē šajās

attiecībās. Objekta nosaukuma pieraksta formāts ir sekojošais: Objekta nosaukums /

Lomas nosaukums : Klases nosaukums. Sintakse ir sekojošā: O/R:C – klases C

objekts O, kas spēlē lomu R, kur

o :C-nezināms (anonīms) klases C objekts

o /R-anonīms objekts, kas spēle lomu R

o /R:C -anonīms klases C objekts, kas spēlē lomu R

o O/R-objekts O, kas spēlē lomu R

o O:C-klases C objekts O

21

o O:-objekts O, kas ir bārenis (pagaidām nav veidota klase, kurai pieder

objekts)

Attiecības – ir iespējams ievietot attiecību nosaukumus.

Ziņojumi -diagrammā ir svarīga ziņojumu numerācija

Lai sākt veidot sadarbības diagrammu, nepieciešams zem objektu orientētas

diagrammas izveidot sadarbības apakš diagrammu. To var izdarīt, ka uz objektu orientētas

diagrammas ikonas piespiež peles kreiso pogu un izvēlās funkciju New -> Collaboration

Diagram.

Lai saprastu kā savā veidā sadarbojas klases un kādas šai sadarbībai būs

nepieciešamas funkcijas, nav nepieciešamības no jauna veidot klases. Iepriekš nodefinētās

klases glabājas tajā pašā vietnē, zem sadaļas „Classes”.

22.att. Objektu orientēta modeļa vietņu struktūra

Tālāk, atliek izvēlēties nepieciešamās klases no saraksta un nodefinēt sadarbību starp

tām. Kā piemēru izvēlējos aprakstīs gadījumu, kad auto nomā griežas tās klients ar

vēlēšanos iznomāt mašīnu (skat. 23.att.).

3: Licence

2: showLicence

1: getCar7: checkHistory

4: checkLicence 10: History:Auto_noma :Klients

Klients

:Klienta_vesture

23.att. Sadarbības diagramma auto iznomāšanas procesam

Tādas šo nelielo daļu no sadarbības diagrammas var aprakstīt kā procesu, kad klients

griežas uz autonomas filiāli ar konkrētu nolūku. Pirms apkalpot klientu, auto nomas

22

darbinieks prasa klientam autovadītāja apliecības dokumentu, pēc kura pārbauda, vai tāds

klients tiešām ir reģistrēts nomas sistēmā. Kad apliecības numurs ir ievadīts klase „Auto

noma” griežas pie klases „Klients” ar lūgumu atrast informāciju par ievadīto apliecības

numuru. Klase „Klients” papildus griežas pie klases „Klienta vēsture”, lai kopā ar

meklēšanas rezultātiem atgriezt arī vēstures ierakstus, par atrasto apliecības numuru.

Pēc tāda paša principa tiem konstruētas sadarbības arī starp pārējām klasēm.

Rezultātu var vērot 24.attēlā.

3: Licence

2: showLicence

1: getCar 16: registerCust

15: returnLicenceHistory

7: checkHistory4: checkLicence

17: createHistory

14: returnHistory

10: History

19: returnSearchCar18: searchCar

21: returnCarBrand

20: searchCarBrand

23: returnCarMod

22: searchCarMod

25: returnCarCompl

24: searchCarCompl

28: returnCarType27: searchCarType

34: returnCarInfo30: searchCarInfo

37: returnJ ob

35: searchJ ob

42: returnEmpl

41: searchEmpl

43: assignEmp

:Auto_noma :Klients

Klients

:Klienta_vesture

:Auto_darba_info

:Auto_razotajs :Auto_modelis

:Auto_komplektacija

:Auto_tips:Auto

:Darbs :Darbinieks

24.att. Sistēmas sadarbības diagramma

Lai pārbaudītu sadarbības diagrammas iespaidu, jāatgriežas pie klašu diagrammas.

Par salīdzinājumu tika paņemta klase „Auto noma” (skat. 25.att.).

23

Auto_noma-------



+++++++++++++++


get auto list (String search critheria)getAutonomasId ()setAutonomasId (int newAutonomas id)getAutoNumurs ()setAutoNumurs (int newAuto numurs)getAutonomasNosaukums ()setAutonomasNosaukums (java.lang.String newAutonomas nosaukums)getAutonomasAdrese ()setAutonomasAdrese (java.lang.String newAutonomas adrese)getAutonomasTelefons ()setAutonomasTelefons (java.lang.String newAutonomas telefons)getKlientaNumurs ()setKlientaNumurs (int newKlienta numurs)getDarbaId ()setDarbaId (int newDarba id)

Auto_noma-------



++++++++++++++++++


get auto list (String search critheria)getAutonomasId ()setAutonomasId (int newAutonomas id)getAutoNumurs ()setAutoNumurs (int newAuto numurs)getAutonomasNosaukums ()setAutonomasNosaukums (java.lang.String newAutonomas nosaukums)getAutonomasAdrese ()setAutonomasAdrese (java.lang.String newAutonomas adrese)getAutonomasTelefons ()setAutonomasTelefons (java.lang.String newAutonomas telefons)getKlientaNumurs ()setKlientaNumurs (int newKlienta numurs)getDarbaId ()setDarbaId (int newDarba id)getCar ()Licence ()returnLicenceHistory ()

25.att. Metožu kopas salīdzinājums(pa kreisi tikai statiskās metodes, pa labi – statiskās un dinamiskās metodes)

Kā redzams, tad pateicoties sadarbības diagrammai ir parādījušās metodes, kas

abstrakti apzīmē sadarbības scenārijus starp klasēm.

Veicot šāda veida abstrakto metožu dalīšanu statiskajās un dinamiskajās metodēs, ir

iespējams datu bāzes līmeņa pietuvoties aplikāciju līmenim.

2.5. Klašu diagrammas projektēšanas grafisks rezultātsKad visi klašu diagrammas definēšanas darbi ir pabeigti, rezultātu var aplūkot

26.attēlā.

24

1..1vada

1..*

1..1 1..*pieder

0..1

1..*

1..1

0..*pieder

1..*pieder 1..1

1..1piedāvā

1..*

1..*pieder

1..1

0..*piereģistrēts

1..1

1..*1..*

paredz

1..*strādā

1..*

0..*pieder 1..1 1..*

strādā

1..*

Auto_noma-------



++++++++++++++++++



<<Auto>>Auto_darba_info

---

Auto darba info idAuto pirksanas datumsDarba auto numurs

: int: java.util.Date: int

+++++++

<<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>>

getAutoDarbaInfoId ()setAutoDarbaInfoId (int newAuto darba info id)getAutoPirksanasDatums ()setAutoPirksanasDatums (java.util.Date newAuto pirksanas datums)getDarbaAutoNumurs ()setDarbaAutoNumurs (int newDarba auto numurs)searchCar ()

Darbs----

Darba filiāleDarba amatsDarba liguma nrDarba id

: java.lang.String: java.lang.String: java.lang.String: int

++++++++++

<<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>>

getDarbaFiliāle ()setDarbaFiliāle (java.lang.String newDarba filiāle)getDarbaAmats ()setDarbaAmats (java.lang.String newDarba amats)getDarbaLigumaNr ()setDarbaLigumaNr (java.lang.String newDarba liguma nr)getDarbaId ()setDarbaId (int newDarba id)searchJ ob ()searchEmpl ()

Darbinieks-------



++++++++++++++++


getDarbiniekaId ()setDarbiniekaId (int newDarbinieka id)getDarbiniekaVards ()setDarbiniekaVards (java.lang.String newDarbinieka vards)getDarbiniekaUzvards ()setDarbiniekaUzvards (java.lang.String newDarbinieka uzvards)getAdrese ()setAdrese (java.lang.String newAdrese)getTelefons ()setTelefons (java.lang.String newTelefons)getVaditajs ()setVaditajs (int newVaditajs)getDarbaId ()setDarbaId (int newDarba id)searchEmpl ()assignEmp ()

<<Klients>>Klients

--------

Klienta numursVardsUzvardsPersonas kodsAdreseTelefonsTransporta apliecibas nrVestures id

: int: java.lang.String: java.lang.String: int: java.lang.String: java.lang.String: java.lang.String: int

++++++++++++++++++++

<<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>>

getKlientaNumurs ()setKlientaNumurs (int newKlienta numurs)getVards ()setVards (java.lang.String newVards)getUzvards ()setUzvards (java.lang.String newUzvards)getPersonasKods ()setPersonasKods (int newPersonas kods)getAdrese ()setAdrese (java.lang.String newAdrese)getTelefons ()setTelefons (java.lang.String newTelefons)getTransportaApliecibasNr ()setTransportaApliecibasNr (java.lang.String newTransporta apliecibas nr)getVesturesId ()setVesturesId (int newVestures id)checkLicence ()checkHistory ()History ()returnHistory ()...

<<Klients>>Klienta_vesture

--

Vestures idApraksts


++++++

<<Getter>><<Setter>><<Getter>><<Setter>>

getVesturesId ()setVesturesId (int newVestures id)getApraksts ()setApraksts (java.lang.String newApraksts)History ()createHistory ()

: int: void: java.lang.String: void: int: int

<<Auto>>Auto

----



+++++++++


getAutoNumurs ()setAutoNumurs (int newAuto numurs)getAutoDarbaInfoId ()setAutoDarbaInfoId (int newAuto darba info id)getRazotajaId ()setRazotajaId (int newRazotaja id)getAutonomasId ()setAutonomasId (int newAutonomas id)searchCarInfo ()

<<Auto>>Auto_tips

--

Tipa idTipa nosaukums


+++++


getTipaId ()setTipaId (int newTipa id)getTipaNosaukums ()setTipaNosaukums (java.lang.String newTipa nosaukums)searchCarType ()

<<Auto>>Auto_razotajs

---

Razotaja idRazotaja nosaukumsModela id

: int: java.lang.String: int

++++++++++

<<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>>

getRazotajaId ()setRazotajaId (int newRazotaja id)getRazotajaNosaukums ()setRazotajaNosaukums (java.lang.String newRazotaja nosaukums)getModelaId ()setModelaId (int newModela id)searchCarMark ()returnCarMod ()searchCar ()searchCarBrand ()

<<Auto>>Auto_modelis

------

Modela idNosaukumsJ audaPaterinsPaatrinajumsKomplektacijas id

: int: java.lang.String: java.lang.String: java.lang.String: java.lang.String: int

+++++++++++++

<<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>>

getModelaId ()setModelaId (int newModela id)getNosaukums ()setNosaukums (java.lang.String newNosaukums)getJ auda ()setJ auda (java.lang.String newJ auda)getPaterins ()setPaterins (java.lang.String newPaterins)getPaatrinajums ()setPaatrinajums (java.lang.String newPaatrinajums)getKomplektacijasId ()setKomplektacijasId (int newKomplektacijas id)searchCarMod ()

<<Auto>>Auto_komplektacija

--

Komplektacijas idKomplektacija


+++++


getKomplektacijasId ()setKomplektacijasId (int newKomplektacijas id)getKomplektacija ()setKomplektacija (java.lang.String newKomplektacija)searchCarCompl ()

Smagie_auto---


: int: int: int

Vieglie_auto---


: int: int: int

Darbs_darbinieks--

Darba_idDarbinieka id

: int: int

++++


getDarbaId ()setDarbaId (int newDarba_id)getDarbiniekaId ()setDarbiniekaId (int newDarbinieka id)

: int: void: int: void

26.att. Sistēmas konceptuālais modelis

3. Klašu diagrammas analīzeIzmantojot CASE rīku PowerDesigner, ir iespēja iegūt klašu diagrammu balstoties uz

izveidoto EER vai fizisko diagrammu. Taču izmantojot automatizētu iebūvēto

PowerDesigner rīku klašu diagrammas iegūšanai, rodas vairākas neatbilstības starp

projektētāja vīziju par klašu diagrammu un programmatūras realizēto diagrammu. Zemāk

redzamajā tabulā ir aprakstītas klašu diagrammas komponentes un to atšķirības projektētāja

un programmatūras izpildē.

Komponente

PowerDesigner (PD) Manuāli PD priekšrocības un trūkumi

Klase (nosaukums, atribūti, metodes)

Auto_noma++++++++

Autonomas idAuto darba info idAuto numursAutonomas nosaukumsAutonomas adreseAutonomas telefonsKlienta numursDarba id

: int: int: int: java.lang.String: java.lang.String: java.lang.String: int: int

Auto_noma-------



++++++++++++++++++



+ Izmantojot PowerDesigner iebūvēto automātisko klašu diagrammas ģenerēšanas rīku, tiek veidota klase, kurai normālā gadījumā ir trīs sadaļas: nosaukums, atribūtu sadaļa un metožu sadaļa.- Visas atribūtu vērtības ir publiskas, kas nav labā programmēšanas prakse.- Metodes jādefinē manuāli, jo ne EERD ne fiziskajā modelī tās nav paredzētas.

Asociācija

1..11..*

Auto_modelis++++++



Auto_komplektacija++



1..1piedāvā

1..*

<<Auto>>Auto_modelis

------



+++++++++++++

<<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>><<Getter>><<Setter>>

getModelaId ()setModelaId (int newModela id)getNosaukums ()setNosaukums (java.lang.String newNosaukums)getJ auda ()setJ auda (java.lang.String newJ auda)getPaterins ()setPaterins (java.lang.String newPaterins)getPaatrinajums ()setPaatrinajums (java.lang.String newPaatrinajums)getKomplektacijasId ()setKomplektacijasId (int newKomplektacijas id)searchCarMod ()

<<Auto>>Auto_komplektacija

--



+++++


getKomplektacijasId ()setKomplektacijasId (int newKomplektacijas id)getKomplektacija ()setKomplektacija (java.lang.String newKomplektacija)searchCarCompl ()

+ Visas asociācijas tiek ģenerētas automātiski. - Asociācijai trūkst lomas (darbības vārds).- Neatšķir asociācijas veidus „agregācija” un kompozīcija. Tas nozīmē, ka programmatūrai nav saprašanas par klašu attiecībām.

Komponente


Asociācija: Agregācija

1..10..*

Auto2+ Auto numurs : int

Auto_noma2++++++++

Autonomas idAuto darba info idAuto numursAutonomas nosaukumsAutonomas adreseAutonomas telefonsKlienta numursDarba id


0..*pieder

1..1

Auto_noma2-------



++++

<<Getter>><<Setter>><<Getter>>

get auto list (String search critheria)getAutonomasId ()setAutonomasId (int newAutonomas id)getAutoNumurs ()...

<<Auto>>Auto2

----



++++


getAutoNumurs ()setAutoNumurs (int newAuto numurs)getAutoDarbaInfoId ()setAutoDarbaInfoId (int newAuto darba info id)...

- Neatšķir asociācijas veidus „agregācija” un „kompozīcija”. Tas nozīmē, ka programmatūrai nav saprašanas par klašu attiecībām. - Agregācijai trūkst lomas (darbības vārds).

Asociācija: Kompozīcija

1..11..*

Darbs2++++



Auto_noma2++++++++

Autonomas idAuto darba info idAuto numursAutonomas nosaukumsAutonomas adreseAutonomas telefonsKlienta numursDarba id...


1..*

1..*paredz

Auto_noma2-------



+++++


get auto list (String search critheria)getAutonomasId ()setAutonomasId (int newAutonomas id)getAutoNumurs ()setAutoNumurs (int newAuto numurs)...

Darbs2----



++++++++


getDarbaFiliāle ()setDarbaFiliāle (java.lang.String newDarba filiāle)getDarbaAmats ()setDarbaAmats (java.lang.String newDarba amats)getDarbaLigumaNr ()setDarbaLigumaNr (java.lang.String newDarba liguma nr)getDarbaId ()setDarbaId (int newDarba id)...

- Neatšķir asociācijas veidus „agregācija” un „kompozīcija”. Tas nozīmē, ka programmatūrai nav saprašanas par klašu attiecībām. - Agregācijai trūkst lomas (darbības vārds).

Asociācija: Vispārināšana

1..1

0..*

1..1

0..*

Vieglie_auto2+++


: int: int: int

Auto2+ Auto numurs : int

Smagie_auto2+++


: int: int: int

<<Auto>>Auto2

----



+++


getAutoNumurs ()setAutoNumurs (int newAuto numurs)getAutoDarbaInfoId ()...

Vieglie_auto2---


: int: int: int

Smagie_auto2---


: int: int: int

- Neatšķir asociācijas veidus „kompozīcija” un „vispārināšana”. Tas nozīmē, ka programmatūrai nav saprašanas par klašu attiecībām.

27

Komponente


Asociācija: Rekursija

0..1

0..1Darbinieks

+++++++

Darbinieka idDar_Darbinieka idDarbinieka vardsDarbinieka uzvardsAdreseTelefonsVaditajs

: int: int: java.lang.String: java.lang.String: java.lang.String: java.lang.String: int

1..1vada

1..*Darbinieks2

-------



+++++

<<Getter>><<Setter>><<Getter>><<Setter>><<Getter>>

getDarbiniekaId ()setDarbiniekaId (int newDarbinieka id)getDarbiniekaVards ()setDarbiniekaVards (java.lang.String newDarbinieka vards)getDarbiniekaUzvards ()...

+ Izvēlēts pareizs asociācijas veids.- Agregācijai trūkst lomas (darbības vārds).- Nepareizas kardinalitātes starp klasēm.

KardinalitāteN:M

1..11..*

1..10..*

Darbs++++



Darbinieks+++++++

Darbinieka idDar_Darbinieka idDarbinieka vardsDarbinieka uzvardsAdreseTelefonsVaditajs

: int: int: java.lang.String: java.lang.String: java.lang.String: java.lang.String: int

Darbs_darbinieks+++

dad_idDarba idDarbinieka id

: int: int: int

1..*strādā

1..*

Darbs2----



+++++

<<Getter>><<Setter>><<Getter>><<Setter>><<Getter>>

getDarbaFiliāle ()setDarbaFiliāle (java.lang.String newDarba filiāle)getDarbaAmats ()setDarbaAmats (java.lang.String newDarba amats)getDarbaLigumaNr ()...

Darbinieks2-------



+ <<Getter>> getDarbiniekaId ()... : int

Darbs_darbinieks2--

Darba_ idDarbinieka id

: int: int

+++


getDarbaId ()setDarbaId (int newDarba_id)getDarbiniekaId ()...

- Nepareizi attēlota N:M kardinalitāte. Programmatūra neievēro klašu diagrammas projektēšanas pamata noteikumus un likumus.+ Pārējās kardinalitātes ir attēlotas pareizi.

28

4. SecinājumiŠī praktiskā darba uzdevums bija saprast PowerDesigner rīka klašu modeļa

projektēšanas metodiku, kā arī noskaidrot atšķirības un būtiskus trūkumus.

Darba gaitā ir izveidojies priekšstats, ka PowerDesigner ir labi saprotama un

vienkārša programmatūra iesācēja un vidēja līmeņa projektēšanas darbiem. Šī

programmatūra ļauj veidot datu bāzu projektējumus ne tikai tādām sistēmām, kas bāzējās

uz Oracle sistēmām, bet arī pavisam vienkāršām un pieejamām sistēmām, tādām kā MS

Access.

Kas attiecas uz klašu modeļa projektēšanu, tad tam ir visas nepieciešamās funkcijas,

lai ar šī rīka palīdzību izstrādāt objektu orientētus modeļus. Darbā ar rīka palīdzību tika

uzprojektēta klašu un sadarbības diagrammas. Starp PowerDesignes iebūvētajām funkcijām

ir arī automātiskas objektu orientēto modeļu veidošanas funkcija. Taču tai ir savi mīnusi.

Vairāk pamanāmie trūkumi ir nekorekta asociāciju veidošana, kas nozīmē, ka

programmatūra „nesaprot” klašu attiecības, kā arī atribūtu vērtības „public” piešķiršana pēc

klašu modeļa ģenerācijas, kas nav laba projektēšanas prakse. Visi ģenerācijas laikā

pamanītie programmatūras PowerDesigner trūkumi ir novēršami manuāli.

Var atzīmēt arī priekšrocību automātiskai klašu veidošanas funkcijai, nav

nepieciešams ievadīti visu klašu atribūtu vērtības ar roku, tās tiek pilnībā pārņemtas no ER

diagrammas.

Atgriežoties pie klašu diagrammas projektēšanas, ir svarīgi atcerēties, ka klasei

vienmēr ir trīs daļas – nosaukuma, atribūtu un metožu daļa. Ja atribūtus var pārmantot no

EER diagrammas, tad metodes ir jādefinē manuāli. Metodes projektētāju pietuvina

aplikāciju līmenim un tās ir iedalāmas divās nosacītās kategorijās – dinamiskās un statiskās

metodes. Statiskās metodes, vai t.s. „Setter” un „Getter”, var noskaidrot katrai klasei

individuāli, savukārt, dinamiskās metodes var noskaidrot zinot savstarpējo klašu sadarbības

procesu. Tieši šīm nolūkam šajā praktiskajā darbā tika izmantota viena no dinamisko

metožu noteikšanas metodēm – sadarbības diagrammas projektēšana. Kā liecina darba

izstrādes laikā iegūtā pieredze, tad lai uzprojektēt šādu diagrammu PowerDesigner

projektēšanas rīkam ir visam nepieciešamās funkcijas.

29

Izmantotā literatūra1. Prof. Jānis Eiduks. Lekciju konspekti studiju priekšmetā „Informācijas sistēmas un

CASE rīki”. – 2008.

2. As. Prof. Oksana Ņikiforova. Lekciju konspekti priekšmetā „Objektu orientētā

projektēšana”. – 2007.

3. Sybase. PowerDesigner . Object Oriented Model. Getting Started -2001.

4. Sybase. PowerDesigner 9 Help faili.

5. http://en.wikipedia.org/wiki/Class_diagram -on-line bibliotēka, klašu modelēšanas

apskats – 12.04.2008

6. http://www.aisintl.com/case/CDM-PDM.html - projektēšanas modeļu apraksts –

12.04.2008.

7. http://www.smartdraw.com/tutorials/software/uml/tutorial_04.htm - klases apraksts,

projektēšanas pamata principi – 12.04.2008.

8. http://www.agilemodeling.com/artifacts/classDiagram.htm - klašu diagrammas

modelēšanas pamatprincipi – 14.04.2008.

9. http://www.sparxsystems.com/resources/uml2_tutorial/uml2_classdiagram.html -

klašu modeļa apraksts – 16.04.2008.

10. http://www.objectmentor.com/resources/articles/umlCollaborationDiagrams.pdf -

sadarbības diagrammas projektēšanas pamācība – 17.04.2008.

11. http://www.netbeans.org/kb/55/uml-collab-diagram.html - sadarbības diagrammas

projektēšanas pamata principi – 12.04.2008.

30

http://www.netbeans.org/kb/55/uml-collab-diagram.html

http://www.objectmentor.com/resources/articles/umlCollaborationDiagrams.pdf

http://www.sparxsystems.com/resources/uml2_tutorial/uml2_classdiagram.html

http://www.agilemodeling.com/artifacts/classDiagram.htm

http://www.smartdraw.com/tutorials/software/uml/tutorial_04.htm

http://www.aisintl.com/case/CDM-PDM.html

http://en.wikipedia.org/wiki/Class_diagram

Documents

Uzdevuma nostādne - datubaze.files.wordpress.com · Web viewUzdevuma nostādne