Objektinis projektavimas

1. Objektinis projektavimas Sistemų projektavimas, naudojant savarankiškus objektus ir objektų klases

2. Tikslai • Išaiškinti kaip programinės įrangos projektavimas gali būti pristatytas kaip sąveikaujančių objektų rinkinys, kurie kontroliuoja savo stovį ir operacijas • Aprašyti veiksmus objektinio projektavimo procese • Pristatyti įvairius modelius, kurie apibūdina objektinį projektavimą • Parodyti kaip UML gali būti panaudota šių modelių atvaizdavimui

3. Nagrinėjamos temos • Objektai ir objektų klasės • Objektinio projektavimo procesas • Projektavimo vystymas

4. Objektinio projektavimo charakteristikos • Objektai yra realaus pasaulio arba sistemos būsenų abstrakcijos ir valdo patys save • Objektai yra nepriklausomi ir apjungia būvio ir atvaizdavimo informaciją • Sistemos funkcionalumas išreiškiamas objekto servisais • Bendros duomenų sritys yra eliminuotos. Objektai bendrauja perduodami pranešimus • Objektai gali būti paskirstyti ir gali būti vykdomi nuosekliai arba lygiagrečiai

5. Sąveikaujantys objektai

6. Objektinio projektavimo privalumai • Paprastesnis palaikymas. Objektai gali būti suprantami kaip atskiros esybės • Objektai yra atitinkami pakartotinio panaudojimo komponentai • Kai kurių sistemų objektams gali būti priskiriamos realaus pasaulio esybės

7. Objektinis kūrimas • Objektinė analizė, projektavimas ir programavimas yra susiję bet skirtingi • Objektinė analizė rūpinasi taikomosios programos objektinio modelio srities vystymu • Objektinis projektavimas rūpinasi objektiniais sistemos modeliais reikalavimų realizavimui • Objektinis programavimas rūpinasi objektinio projektavimo realizavimu, naudojant objektinę programavimo kalbą tokią kaip Java arba C++

8. Nagrinėjamos temos • Objektai ir objektų klasės • Objektinio projektavimo procesas • Projektavimo vystymas

9. Objektai ir objektų klasės • Objektai yra programinės įrangos sistemų dalys, kurios atstovauja realaus pasaulio daiktus arba sistemos esybes • Objektų klasės yra objektų šablonai. Jie gali būti panaudojami objektų kūrimui • Objektų klasės gali paveldėti kitų objektų klasių savybes ir metodus

10. Objektai Objektas yra esybė, kuri turi būseną ir apibrėžtą aibę operacijų, kurios veikia jo būseną. Būvis yra pristatomas kaip objekto savybių rinkinys. Su objektu susietos operacijos teikia servisus kitiems objektams, kurie jų reikalauja kai reikalingas koks nors apskaičiavimas. Objektai yra kuriami pagal objektų klasių apibrėžimą. Objekto klasės apibrėžimas naudojamas kaip objekto šablonas. Joje yra nurodytos visos savybės bei servisai kurie turėtų būti susieti su šios klasės objektu

11. Unifikuota modeliavimo kalba (UML) • Keletas skirtingų objektinio projektavimo žymėjimų buvo pasiūlyti 1980’ais ir 1990’ais • UML (Unified Modeling Language ) yra šių žymėjimų suvienijimas • UML apibudina įvairių modelių žymėjimus, kurie gali būti pateikti per objektinę analizę ir projektavimą • Dabar tai de facto standartas objektiniam modeliavimui

12. Darbuotojo objekto klasė (UML)

13. Objektų bendravimas • Koncepciškai objektai bendrauja perduodami pranešimus • Pranešimai • Serviso pavadinimas, kurio reikalauja kviečiantis objektas • Informacijos kopijos, kurių reikia serviso įvykdymui, ir rezultato turėtojo vardas • Praktiškai, pranešimai dažnai yra sužadinami kviečiant procedūrą • Pavadinimas = procedūros pavadinimas • Informacija = parametrų sąrašas

14. Pranešimų pavyzdžiai // Iškviesti metodą susietą su buferio objektu, // kuris gražina sekančią reikšmę buferyje v = circularBuffer.Get () ; //Iškviesti metodą susietą su termostato objektu, // nustato temperatūrą, kuri turi būti palaikoma thermostat.setTemp (20) ;

15. Apibendrinimas ir paveldimumas • Objektai yra nariai klasių, kurios apibrėžia atributų tipus ir operacijas • Klasės gali būti sutvarkytos klasės hierarchijoje, kur viena klasė (superklasė) yra vienos ar kelių kitų klasių (poklasių) apibendrinimas • Poklasė paveldi atributus ir operacijas iš savo superklasės ir gali būti papildyta naujais metodais ir atributais • Apibendrinimas UML’e yra realizuotas kaip paveldimumas OO programavimo kalbose

16. Apibendrinimo hierarchija

17. Paveldimumo privalumai • Tai abstrakcijos mechanizmas, kuris gali būti panaudotas įvairių esybių klasifikavimui • Tai yra pakartotinio panaudojimo mechanizmas tiek projektavimo, tiek programavimo lygyje • Paveldimumo grafas yra organizacinių žinių apie sritis ir sistemas šaltinis

18. Paveldėjimo problemos • Objektinės klasės nėra savarankiškos ( self-contained ) ir savyje turinčios visą objekto kodą. Jas sunku suprasti nesiremiant jų superklasėmis • Projektuotojai turi tendenciją pakartotinai pasinaudoti analizės metu sukurtu paveldimumo grafiku. Tai gali iššaukti reikšmingą efektyvumo praradimą • Paveldimumo grafai analizei , projektavimui ir realizavimui turi skirtingas funkcijas ir turi būti palaikomi atskirai

19. Paveldimumas ir objektinis projektavimas • Yra įvairių požiūrių sprendžiant klausimą ar paveldimumas yra fundamentalus objektiniam projektavime • Požiūris 1. Paveldimumo hierarchijos identifikavimas arba tinklas yra fundamentali OOD dalis. Akivaizdžiai tai gali būti realizuota naudojant OOPL • Požiūris 2. Paveldimumas yra naudinga realizacijos koncepcija, kuri leidžia atributų ir operacijų apibrėžimų pakartotinį panaudojimą. Identifikuojant paveldimumą projektavimo stadijoje suformuojami realizacijai nebūtini apribojimai • Paveldimumas įveda sudėtingumą ir tai yra nepageidaujama, ypač kritinėse sistemose

20. UML asociacijos • Objektai ir objektų klasės santykiauja su kitais objektais ir objektų klasėmis • UML’e apibendrinti ryšiai yra parodyti asocijacijomis • Asociacijos gali turėti pastabas, kurios aprašo asociaciją • Asociacijos yra bendros bet gali iš anksto skelbti, kad objekto atributas yra asocijuotas objektas, arba kad metodas remiasi asocijuotu objektu

21. Asociacijų modelis

22. Lygiagretūs (concurent -dėl sistemos resursų konkuruojantys) objektai • Objektų prigimtis kaip savarankiškų esybių daro juos tinkamus lygiagrečiai realizacijai • Objektų komunikavimo pranešimų siuntimo modelis gali būti realizuotas tiesiogiai jei objektai yra vykdomi paskirstytoje sistemoje ant atskirų procesorių

23. Serveriai ir aktyvūs objektai • Serveriai • Šis objektas yra realizuotas kaip lygiagretus procesas (serveris) su įėjimo taškais, atitinkančiais objekto operacijas. Jei nėra į jį kreipinių, objektas pats save sustabdo ir laukia tolimesnių serviso reikalavimų • Aktyvūs objektai • Objektai yra realizuoti kaip lygiagretūs procesai ir vidinė objekto būsena gali būti pakeista paties objekto ir ne taip lengvai per išorinius kreipinius

24. Aktyvus “transponder” objektas • Aktyvūs objektai gali turėti savo atributus, kurie gali būti modifikuojami operacijų,bet taip pat juos galima atnaujinti autonomiškai naudojant vidines operacijas • Transponder ( trans(mitter)+ (res) ponder) objektas transliuoja lėktuvo buvimo vietą. Buvimo vieta gali būti atnaujinama naudojantis palydovine paieškos sistema. Objektas periodiškai atnaujina buvimo vietą trikampio metodu iš palydovų

25. An active transponder object

26. Gijos Javoje • Gijos (Threads ) Javoje yra paprasčiausios konstrukcijos naudojamos realizuojant besivaržančius dėl sistemos resursų objektus • Gijos turi turėti metodą, kuris vadinasi run() ir kuris yra įvykdomas, vykdant Java run-time sistemą • Aktyvūs objektai dažniausiai turi begalinį ciklą, todėl jie visada vykdo skaičiavimus

27. Nagrinėjamos temos • Objektai ir objektų klasės • Objektinio projektavimo procesas • Projektavimo vystymas

28. Objektinio projektavimo procesas • 1. Apibrėžti kontekstą ir būdus kaip naudojama sistema • 2. Suprojektuoti sistemos architektūrą • 3. Identifikuoti principinius sistemos objektus • 4. Sukurti projekto modelius • 5. Specifikuoti objektų sąsajas

29. Meteorologinės sistemos aprašymas Meteorologinių duomenų rinkimo sistema turės reguliariai generuoti meteorologinius žemėlapius naudodama surinktus duomenis iš nuotolinių, nepasiekiamų stočių ir kitų duomenų šaltinių, tokių kaip oro stebėtojai, balionai ir satelitai. Meteorologinės stotys persiunčia savo duomenis į kompiuterį gavusios iš jo užklausą. Srities kompiuteris atestuoja surinktus duomenis ir integruoja juos su duomenimis iš kitų šaltinių. Susumuoti duomenys yra archyvuojami, ir naudojantis tuo archyvu ir skaitmeniniu žemėlapiu duomenų baze yra kuriami lokaliniai metereorologiniai žemėlapiai. Žemėlapiai gali būti spausdinami panaudojimui specialiu spausdintuvu, arba gali būti vaizduojami įvairiais formatais.

30. Meteorologinės stoties aprašymas Meteorologinė stotis yra paketas programinės įrangos kontroliuojamų įtaisų, kurie renka duomenis, vykdo apdorojimą ir siunčia duomenis tolesniam apdorojimui. Įtaisai gali būti oro ir žemės termometrai, vėjo greičio matuokliai, vėjarodžiai, barometrai ir lietaus matavimo. Duomenys yra renkami kas 5 minutes. Kai komanda yra išleidžiama vykdymui, stotis apdoroja ir apibendrina surinktus duomenis. Jie yra persiunčiami į žemėlapių kompiuterį, kai iš jo gaunama užklausa.

31. Layered architecture Duomenų vaizdavimo sluoksnis, kai objektai skirti ruošti ir pateikti duomenis vartotojui suprantama forma. Duomenų archyvavimo sluoksnis, kai objektai skirti saugoti duomenis vėlesniam apdorojimui. Duomenų apdorojimo sluoksnis, kai objektai skirti tikrinti ir integruoti surinktus duomenis. Duomenų surinkimo sluoksnis, kai objektai yra skirti užprašymui duomenų iš nutolusių šaltinių.

32. 1. Sistemos kontekstas ir naudojami modeliai • Suprasti ryšius tarp projektuojamos PĮ ir jos išorinės aplinkos. • Sistemos kontekstas • Statinis modelis, kuris aprašo kitas aplinkos sistemas. Naudokite posistemių modelį pavaizduoti kitoms sistemoms. Kita skaidrė vaizduos sistemas, kurios yra aplink Meteorologinės stoties sistemą. • Sistemos naudojimo modelis • Dinaminis modelis, kuris aprašo kaip sistema sąveikauja su jos aplinka. Naudokite panaudojimo atvejus ( angl. Use cases ), kad parodyti sąveikas.

33. Meteorologinės stoties posistemės

34. Meteorologinės stoties naudojimo-atvejai

35. Naudojimo-atvejų aprašymas

36. 2. Architektūrinis projektavimas • Kai sistemos ir jos aplinkos sąveika yra išsiaiškinama, jūs naudojate šią informaciją projektuojant sistemos architektūrą. • Sluoksniuota architektūra yra tinkama Meteorologinės stoties sistemai. • Sąsajos lygis komunikacijų valdymui • Duomenų rinkimo lygis – įtaisų valdymui • Įtaisų lygis duomenų rinkimui • Architektūriniame modelyje negali būti daugiau kaip 7 esybės.

37. Meteorologinės stoties sistemos architektūra

38. 3. Objektų identifikavimas • Objektų ir jų klasių identifikavimas yra sunkiausia objektinio projektavimo dalis • Nėra stebuklingos formulės kaip identifikuoti objektus. Tai priklauso nuo žinių, patirties ir žinių pobūdžio sisteminiam projektuotojui, • Objektų identifikavimas yra iteratyvus procesas. Mažai šansų, kad jums tai pasiseks iš karto.

39. Identifikavimo metodai • Naudokite gramatinį metodą paremtą natūralia kalba sistemos aprašymui ( Hood metodas ) • Identifikuokite materialius dalykus programos aplinkoje • Naudokite elgesio metodą ir identifikuokite objektus remiantis kas kokiuose veiksmuose dalyvauja. • Naudokite scenarijais pagrįstą analizę. Objektai, atributai ir metodai kiekviename scenarijuje turi būti identifikuojami.

40. Meteorologinės stoties objektų klasės • Žemės termometras, anemometras, barometras • Programos srities objektai, kurie yra “hardware” objektai, susiję su sistemos įtaisais. • Meteorologinė stotis • Pagrindinė sąsaja jos aplinkos. Ji turi įtakos sąveikoms identifikuotoms use-case modelyje. • Oro duomenys • Kapsuliuoja (Encapsulates ) apibendrintus duomenis iš įtaisų.

41. Meteorologinės stoties objektų klasės

42. Tolimesni objektai ir objektų tobulinimas • Naudokite srities žinias kad identifikuoti daugiau objektų ir operacijų • Meteorologinės stotys turi turėti unikalų identifikatorių • Meteorologinės stotys yra nutolusios, taigi įtaisų klaidos turi būti pranešamos automatiškai. Dėl to atributai ir operacijos savęs patikrinimui turi būti realizuotos. • Aktyvūs ir pasyvūs objektai • Šiuo atveju, objektai yra pasyvūs ir renka duomenis gavę užklausą, o ne automatiškai. Tai suteikia lankstumo kontroliuojant apdorojimo laiką

43. 4. Projektavimo modeliai • Projektavimo modeliai parodo objektus ir jų klases ir ryšius tarp šių esybių • Statiniai modeliai aprašo statinę sistemos struktūrą objektų klasių ir ryšių terminais. • Dinaminiai modeliai aprašo dinamines sąveikas tarp objektų.

44. Projektavimo modelių pavyzdžiai • Posistemių modeliai parodo loginį objektų grupavimą į suderintas (coherent) posistemes. • Sekos modeliai parodo objektų sąveikavimo sekas. • Būsenų mechanizmų modeliai parodo atskirų objektų būsenų pasikeitimą atsakant į tam tikrus įvykius, • Kiti modeliai tokie kaip panaudojimo-atvejų (use case), agregavimo, apibendrinimų (generalisation) ir kt.

45. Posistemių modeliai • Parodo kaip projektas yra organizuojamas į logiškai susijusias grupes. • Pagal UML tai yra parodoma naudojant paketus -kapsuliavimo konstrukcija. Tai yra loginis modelis. Pagrindinis objektų organizavimo būdas gali būti skirtingas.

46. Meteorologinės stoties posistemės

47. Sekos modeliai • Sekos modeliai parodo objektų sąveikavimo sekas • Objektai yra lygiuojami horizontaliai viršuje • Laikas vaizduojamas vertikaliai ir modeliai skaitomi iš viršaus į apačią • Sąveikos vaizduojamos rodyklėmis, skirtingi rodyklių tipai vaizduoja skirtingas sąveikas • Plonas keturkampis ant objekto gyvenimo linijos, parodo laiką kai objektas kontroliuojamas sistemos.

48. Duomenų rinkimo seka

49. Būsenų diagramos • Parodo kaip objektai atsako į skirtingas serviso užklausas ir būsenų perėjimus prie šių užklausų • Jeigu objekto būsena yra ShutDown, tai jis atsako Startup() žinute • Jeigu laukianti būsena – tai objektas laukia žinučių • Jeigu calibrate(), tai sistema pereina į tikrinimo režimą • Rinkimo būsena, kai clock signalas yra gaunamas.

50. Meteorologinės stoties būsenų diagrama