1. UML asist. V.Giedrimas

2. Planas • Reikalavimo samprata ir savybės • Reikalavimų inžinerijos samprata • Bendrieji reikalavimų inžinerijos principai • Reikalavimų formulavimo būdai • Reikalavimų rūšys

3. UML (Unified Modeling Language) • Universali modeliavimo kalba • Rumbaugh joined Booch at Rational in 1994; in 1995, Rational added Jacobsen to their team. In 1996, work on the UML was begun. • 1997m. firma Rational pasiūlė UML 1.0 pripažinti OMG standardu

4. UML naudojimo sritys • Dalykinės srities analizė • Modeliuojami dalykines srities procesai • Projektavimas • Realizavimas • Kai kurie UML įrankiai geba iš pateikto diagramų rinkinio generuoti būsimosios programos fragmentus

5. Užduočių (Užduočių diagramas) Klasių (Class Diagrams) Bendradarbiavimo (Collaboration Diagrams) Sekos (Sequence Diagrams) Veiklos (Activity Diagrams) Būsenų (State Diagrams) Paketų (Package Diagrams) Komponentų (Component Diagrams) Išdėstymo (Deployment Diagrams) UML diagramų tipai

6. Užduotys • Aprašo vartotojų ir išorinių sistemų (vadinamų aktoriais) sąveiką • Užduotys turi būti diskrečiosir išmatuojamos • Pagal apimtį gali būti • Detalios užduotys • “Pastorinti tekstą” • Stambesnės užduotys • “Sudaryti knygos turinį”

7. Užduočių diagrama

8. Užduočių diagrama • Kiti pavadinimai: • Use-case diagrama • Panaudos diagrama • Panaudoijmo atvejų diagrama

9. Užduočių diagramos paskirtis • Analizės procese parodoma, kokios užduotys yra atliekamos dalykinėje srityje • Projektavimo procese parodoma, kokias užduotis turėtų atlikti programų sistema

10. Užduotis

11. Ryšiai tarp užduočių:Praplėtimas

12. Ryšiai tarp užduočių:Smulkesnės užduotys

13. Ryšiai tarp užduočių:Apibendrinimas

14. Aktorius • Aktorius pabrėžia vaidmenį, o ne vardą ar pareigas • Aktoriumi gali būti ne tik žmogus bet ir išorinė sistema, pvz.: bankas, ATM stotelė

15. Komentarai

16. Užduočių diagrama

17. Užduočių diagrama

18. Užduočių diagrama

19. Užduočių diagrama

20. Veiklos diagrama

21. Veiklos diagrama • Veiklos diagrama papildo užduočių diagramą • Veiklos diagrama parodo, kokia tvarka gali būti atliekamosužduotys nurodydama jų “smulkesnes” dalis - veiksmus

22. Veiklos diagrama

23. Veiklos diagrama • Veiklos diagramose gali būti vaizduojamas ir veiksmų rezultatasbei veiksmams atlikti reikaligas argumentas (“medžiaga”)

24. Šakojimasis • Naudojamas alternatyvoms parodyti. • Sąlygos sakinio (IF) programavimo kalbose analogas

25. Lygiagretūs veiksmai • Naudojama keliems vienu metu vykdomiems veiksmams parodyti.

26. Klasių diagrama

27. Klasių diagrama • Analizės procese aprašo dalykinės srities esybes • Projektavimo procese aprašo dalykinės srities esybes arba klases

28. Esybė = daiktas, gyva būtybė, reiškinys ir pan.

29. Klasė +Laukas1 : SomeType - Laukas2 : SomeType #Laukas3 : SomeType +Metodas1() +Metodas 2() Apribojimai. Klasė • Klasė • Vardas (būtinas!) • Laukai • Metodai • Apribojimai • Klasės elementų matomumo laipsnis: • + public • -private • #protected

30. Paprastas ryšys Pavadinimas Vaidmenys

31. Refleksyvus ryšys • Naudojamas kai klasės objektai turi ryšį (dažniausiai priklausomybės) su savimi

32. Klasė_1 Klasė_2 Navigacijos ryšys • Naudojamas, siekiant parodyti, kadjei egzituoja bent vienas klasės A egzempliorius, tai būtinai turi egzistuoti ir klasės B egzempliorius • Pvz.: Sąskaita ir Sąskaitos eilutė

33. Agregacijos ryšys • Ryšys “Dalis-visuma” • Dalis, paimta atskirai, neturi prasmės • Dalis gali būti kelių stambesnių klasių dalimi

34. Agregacijos ryšys

35. Kompozicijosryšys • Ryšys “Dalis-visuma” • Dalis, paimta atskirai, turi prasmę • Dalis gali būti tik vienos “stambesnės” klasės dalimi

36. Kompozicijosryšys • Composite • Each component can belong to just one whole. • same as the symbol for an aggregation except the diamond is filled.

37. Agregacijos ir kompozicijosryšiai

38. Vidinė klasė • UML 2 standarto naujovė • Žymėjimai naudojami rečiau

39. Apibendrinimo ryšys • Analizės procese parodo apibendrinimus • Projektavimo procese aprašo paveldėjimo ryšius tarp klasių

40. Apibendrinimo ryšys

41. Apibendrinimo ryšys

42. Priklausomybės ryšys • Sakoma, kad klasė A prikauso nuo klasės B tada, kai paeitus klasę B, būtina (arba bent jau gali prireikti) pakeisti ir klasę A. • Pavyzdžiai: • vienoje klasėje, kviečiamas kitos metodas. • viena klasė, naudoja kitos egzempliorių, kaip argumentą: public static void main( String []args )

43. Priklausomybės ryšys • Klasių tarpusavio priklausomybė – svarbi objektinės paradigmos problema. • Klasių priklausomybė apsunkina (arba net daro neįmanomą) velesnį programų sistemų modernizavimą • Šiai problemai spręsti, komponentinė paradigma turi sprendimą – interfeisus.

44. Klasė_1 Klasė_1 Priklausomybės ryšys

45. Interfeisas • Interfeisas programavime = pareigybinė instrukcija firmoje • Darbuotojas firmoje dirba taip, kaip nurodyta pareigybinėje instrukcijoje. • Realizuojanti interfeisą klasė “elgiasi” taip, kaip aprašyta interfeise.

46. Interfeisas • Interfeisas programavime = pareigybinė instrukcija firmoje • Darbuotojas firmoje dirba taip, kaip nurodyta pareigybinėje instrukcijoje. • Realizuojanti interfeisą klasė “elgiasi” taip, kaip aprašyta interfeise.

47. Interfeisas • Aprašomas panašiai, kaip ir klasė, tačiau • Metodai neturi realizacijos, tik pavadinimus! • Interfeise, gali nebūti aprašyti ir laukai <<interface>> Interf02 +Laukas1 : SomeType - Laukas2 : SomeType #Laukas3 : SomeType +Metodas1() +Metodas 2()

48. Interfeiso realizacija

49. Priklausomybė nuo interfeiso

50. Ryšio kardinalumas • Parodo kiek klasės objektų yra susiję su kitos klasės objektais. • Galimi žymėjimai • konkretus (pvz.: 1) • intervalas (pvz.: n..m) • “Daug” reiškianti žvaigždutė (pvz.: *) • Mišrūs (pvz.: 0..*)