Konspektai

Išsami programų sistemų inžinerijos teorija

9.0   (3 atsiliepimai)
Išsami programų sistemų inžinerijos teorija 1 puslapis
Išsami programų sistemų inžinerijos teorija 2 puslapis
Išsami programų sistemų inžinerijos teorija 3 puslapis
Išsami programų sistemų inžinerijos teorija 4 puslapis
Išsami programų sistemų inžinerijos teorija 5 puslapis
Išsami programų sistemų inžinerijos teorija 6 puslapis
Išsami programų sistemų inžinerijos teorija 7 puslapis
Išsami programų sistemų inžinerijos teorija 8 puslapis
Išsami programų sistemų inžinerijos teorija 9 puslapis
Išsami programų sistemų inžinerijos teorija 10 puslapis
Išsami programų sistemų inžinerijos teorija 11 puslapis
Išsami programų sistemų inžinerijos teorija 12 puslapis
Išsami programų sistemų inžinerijos teorija 13 puslapis
Išsami programų sistemų inžinerijos teorija 14 puslapis
Išsami programų sistemų inžinerijos teorija 15 puslapis
Išsami programų sistemų inžinerijos teorija 16 puslapis
Išsami programų sistemų inžinerijos teorija 17 puslapis
Išsami programų sistemų inžinerijos teorija 18 puslapis
Išsami programų sistemų inžinerijos teorija 19 puslapis
Išsami programų sistemų inžinerijos teorija 20 puslapis
www.nemoku.lt
www.nemoku.lt
Aukščiau pateiktos peržiūros nuotraukos yra sumažintos kokybės. Norėdami matyti visą darbą, spustelkite peržiūrėti darbą.
Ištrauka

 1. Programų sistemų gyvavimo ciklo samprata, gyvavimo ciklo modeliai. 2. Reikalavimų programų sistemai analizė, reikalavimų rūšys, formulavimas, specifikavimas ir vertinimas. 3. Programų sistemų projektavimas, tipinio projektinio sprendimo (projektavimo šablono) sąvoka. 4. Programų sistemų realizavimas. Pagrindiniai testavimo metodai. 5. UML kalba, užduočių (use-case) diagramos, klasių diagramos, sekų diagramos, komponentų diagramos, išdėstymo (deployment) diagramos. 6. Objektiškai orientuoto projektavimo principai. Pagrindiniai objektiškai orientuoti mechanizmai ir jų taikymas. 7. Projektų valdymo kompetencijos sritys, svarbiausios sąvokos ir metodai. 1 balas 1. Kokiu tikslu programų sistemų inžinerijoje įvesta programų sistemos gyvavimo ciklo modelio sąvoka?(1) 2. Kas vadinama programų sistemos gyvavimo ciklu ir kas programų sistemos gyvavimo ciklo modeliu?(1) 3. Kas tai yra projekto palaikymo sistema?(1) 4. Kokia programų sistemų inžinerijos paradigma grindžiamas klasikinis gyvavimo ciklo modelis?(1) 5. Kokias stadijas numato klasikinis gyvavimo ciklo modelis?(1) 6. Kokie yra programų sistemos specifikavimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) 7. Kokiais aspektais nagrinėjama programų sistema techninėje užduotyje?(1) 8. Kas daroma programų sistemos specifikavimo stadijoje klasikiniame gyvavimo ciklo modelyje?(1) 9. Kokie yra programų sistemos projektavimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) 10. Kokie yra pagrindiniai programų sistemos projektavimo žingsniai klasikiniame gyvavimo ciklo modelyje?(1) 11. Kokie yra programavimo ir programų derinimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) 12. Kas daroma programavimo ir programų derinimo stadijoje klasikiniame gyvavimo ciklo modelyje?(1) 13. Kokie yra programų sistemos integravimo ir aprobavimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) 14.Kas daroma programų sistemos integravimo ir aprobavimo stadijoje klasikiniame gyvavimo ciklo modelyje?(1) 15. Kokie yra programų sistemos diegimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) 16. Kas daroma programų sistemos diegimo stadijoje klasikiniame gyvavimo ciklo modelyje?(1) 17. Kokie yra programų sistemos naudojimo ir priežiūros stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) 18. Kas daroma programų sistemos naudojimo ir priežiūros stadijoje klasikiniame gyvavimo ciklo modelyje?(1) 19. Kokie yra kontroliniai taškai klasikiniame gyvavimo ciklo modelyje?(1) 20. Kokie yra klasikinio gyvavimo ciklo modelio trūkumai?(1) 21. Kam skirtas pagrindinis dėmesys spiraliniame programų sistemos gyvavimo ciklo modelyje?(1) 22. Kokios stadijos yra spiraliniame programų sistemos gyvavimo ciklo modelyje?(1) 23. Kas programų sistemų inžinerijoje vadinama reikalavimu? reikalavimų specifikacija?(1) 24. Kas vadinama programų sistemos reikalavimų lokalizavimu?(1) 25. Koks reikalavimas vadinamas abstrakčiu?(1) 26. Koks reikalavimas vadinamas įgyvendinamu?(1) 27. Koks reikalavimas vadinamas integruojamu?(1) 28. Koks reikalavimas vadinamas išsamiu?(1) 29. Koks reikalavimas vadinamas lokakizuojamu?(1) 30. Koks reikalavimas vadinamas trasuojamu?(1) 31. Koks reikalavimas vadinamas suprantamu?(1) 32. Koks reikalavimas vadinamas glaustu?(1) 33. Koks reikalavimas vadinamas unikaliu?(1) 34. Koks reikalavimas vadinamas verifikuojamu?(1) 35. Kas vadinama programų sistemos reikalavimų nuleidimu žemyn?(1) 36. Kokie sistemos funkcinio komponento reikalavimai vadinami išvestiniais?(1) 37. Kas tai yra reikalavimų ryšio matrica?(1) 38. Kokie turi būti gerai suformuluoti programų sistemos reikalavimai?(1) 39. Kas tai yra anotuoti reikalavimai?(1) 40. Kas yra reikalavimo statusas?(1) 41. Kas yra reikalavimo kritiškumas?(1) 42. Kuo skiriasi programų sistemos reikalavimai ir projekto reikalavimai?(1) 43. Į kokias grupes skirstomi projekto reikalavimai?(1) 44. Ką apibūdina technologiniai projekto reikalavimai?(1) 45. Ką apibūdina projekto kokybės valdymo reikalavimai?(1) 46. Ką apibūdina projekto konfigūracijos valdymo reikalavimai?(1) 47. Ką apibūdina projekto kokybės valdymo reikalavimai?(1) 48. Ką apibūdina projekto finansavimo reikalavimai?(1) 49. Ką apibūdina projekto rezultatų ir jų pateikimo reikalavimai?(1) 50. Ką apibūdina projekto rezultatų aprobavimo reikalavimai?(1) 51. Ką apibūdina projekto garantijų reikalavimai?(1) 52. Į kokias grupes skirstomi programų sistemos reikalavimai?(1) 53. Kas įvyksta pažeidus funkcinius sistemos reikalavimus?(1) 54. Į kokias pagrindines grupes skirstomi nefunkciniai sistemos reikalavimai?(1) 55. Kokie yra dalykinės srities analizės rezultatai? Trumpai apibūdinkite juos. (1) 56. Kas programų sistemų inžinerijoje vadinama reikalavimų įgyvendinimo delsa?(1) 57. Kas programų sistemų inžinerijoje vadinama programų sistemos ilgaamžiškumu?(1) 58. Kas programų sistemų inžinerijoje vadinama atotrūkiu tarp užsakovo poreikių ir sistemos galimybių?(1) 59. Kas programų sistemų inžinerijoje vadinama sistemos adaptyvumu?(1) 2 balai 60. Kokios yra interfeiso reikalavimų grupės? trumpai apibūdinkite jas?(2) 61. Kokios yra sistemos veikimo reikalavimų grupės? trumpai apibūdinkite jas?(2) 62. Kokios yra iš ekonominių apribojimų išplaukiančių reikalavimų grupės? trumpai apibūdinkite jas?(2) 63. Kokie reikalavimai išplaukia iš politinių apribojimų? trumpai apibūdinkite juos?(2) 64. Kokie reikalavimai išplaukia iš teisinių apribojimų? trumpai apibūdinkite juos?(2) 65. Kas tai yra dalykinės srities analizė? Pagal kokią schemą ji vyksta?(2) 66. Ką reikia padaryti, planuojant sisteminės analizės procesą?(2) 67. Kaip yra atliekami reikalavimų specifikacijos verifikavimas ir vertinimas? Kokią specifikaciją vadiname korektiška? pagrįsta? įgyvendinama?(2) 68. Dalykinės srities koncepcinio modelio pertvarkymas į programų sistemos koncepcinę architektūrą (2) 69. Kas vadinama koncepciniu programų sistemos projektavimu? Kokie uždaviniai yra sprendžiami koncepcinio projektavimo metu? Kaip traktuojamas konceptualizacijos principas koncepcinio projektavimo metu? (2) 70. Racionalumo principas. Subjektyviosios ir objektyviosios projektavimo proceso iracionalumo priežastys. (2) 71. Kodėl, nepaisant objektyvių priežasčių, pažeidžiančių projektavimo proceso racionalumą, projektavimo metodikų studijos yra prasmingos? (2) 72. Projektavimo metodo ir projektavimo metodikos skirtumai (2) 73. Tipiniai projektavimo metodikų komponentai (2) 74. Išvardinkite populiariausius programų sistemų architektūros stilius. (2) 3 balai 75. Kaip praplėstas klasikinis gyvavymo ciklo modelis struktūriniame modelyje? (3) 76. Kaip praplėstas klasikinis gyvavymo ciklo modelis evoliuciniame modelyje? (3) 77. Projektavimo metodikos samprata. (3) 78. Koncepcinio projektavimo samprata. Koncepcinio projektavimo tikslai (3) 79. UML: realizavimo diagramos (3) 80. Projektavimo paradigmos. Redukcionizmo ir ekspansionizmo esmė (3) 81. Projektinių sprendimų priėmimo strategijos (3) 82. Projektuotojų tipai. Trumpai apibūdinkite juos. (3) 83. Kuo skiriasi projektavimo strategijos, projektavimo procedūros ir projektavimo euristikos? (3) 84. Kokiais svarbiausias atributais aprašoma programų sistemos architektūra? (3) 85. Kas vadinama programų sistemos architektūros stiliumi? (3) 86. Kas vadinama konstrukcijos patikslinimu? (3) 87. Kas vadinama konstrukcijos plėtiniu? (3) 88. Modulių sankiba per skaliarinius duomenis. Pateikite pavyzdžių. (3) 89. Modulių sankiba per skaliarinius valdančiuosius duomenis. Pateikite pavyzdžių. (3) 90. Netiesioginė modulių sankiba per skaliarinius valdančiuosius duomenis. Pateikite pavyzdžių. (3) 91. Modulių sankiba per struktūrinius duomenis. Pateikite pavyzdžių. (3) 92. Modulių sankiba per struktūrinius valdančiuosius duomenis. Pateikite pavyzdžių. (3) 93. Netiesioginė modulių sankiba per struktūrinius valdančiuosius duomenis. Pateikite pavyzdžių. (3) 94. Modulių sankiba per operacinę aplinką. Pateikite pavyzdžių. (3) 95. Nelokalioji modulių sankiba. Pateikite pavyzdžių. (3) 96. Globalioji modulių sankiba. Pateikite pavyzdžių. (3) 97. Tranzityvioji modulių sankiba. Pateikite pavyzdžių. (3) 98. Atsitiktinis modulio rišlumas. (3) 99. Loginis modulio rišlumas. (3) 100. Modulio rišlumas pagal laiko momentą. (3) 101. Procedūrinis modulio rišlumas. (3) 102. Komunikacinis modulio rišlumas. (3) 103. Nuoseklusis modulio rišlumas. (3) 104. Funkcinis modulio rišlumas. (3) 105. Kokie pradiniai duomenys yra reikalingi objektinei projektavimo metodikai? (3) 106. Kaip pasiskirsto resursų poreikis pagal programų sistemos gyvavimo ciklo stadijas? (3) 4 balai 107. Objektinio projektavimo metodikos komponentai: architektūros stilius, PSI paradigma, pradiniai duomenys (4) 108. Koudo ir Jodano strategija (4) 109. UML: paketai, plėtros mechanizmai (4) 110. UML: ansamblių diagramos (4) 111. Projektavimas kaip alternatyvų analizė. Kodėl nepavyksta projektavimui pritaikyti analitinių optimizavimo metodų? Dekompozicijos ir abstrakcijos principų vaidmuo projektavime. (4) 112. Valdymo srautų stiliaus architektūros, jų ypatumai ir stiliaus atmainos. (4) 113. Kas vadinama projektiniu sprendimu? Kokie projektiniai sprendimai vadinami tipiniais? Kas vadinama tipinėmis konstrukcijomis? (4) 114. Kuo skiriasi tipinių konstrukcijų katalogai, tipinių konstrukcijų bibliotekos ir tipinių konstrukcijų kalbos? (4) 115. Kas vadinama architektūriniu karkasu? Kokias architektūrinių karkasų rūšis žinote? Trumpai apibūdinkite jas. (4) 116. Kuo svarbus tinkamas sistemos suskaidymas į modulius? (4) 117. Kas vadinama modulių sankiba? Kodėl modulių sankiba yra nepageidautina? (4) 118. Kas vadinama tarpmoduliniu ryšiu? Kada tarpmodulinis ryšys tampa pataloginiu? (4) 119. Nuo ko priklauso modulių sankibos stiprumas? (4) 120. Modulių sankibos kategorijos. (4) 121. Kas vadinama modulio rišlumo? Per kokias modulio savybes yra nusakomas jo rišlumas? (4) 122. Programų sistemos funkcinės dekompozicijos samprata. Funkciniai agregatai ir funkciniai primityvai. Projektavimo bazė. (4) 123. Kuo skiriasi funkcinė ir dalykinė programų sistemos dekompozicija? Kas vadinama funkciniais moduliais? Kas vadinama dalykiniais moduliais? (4) 124. Reikalavimų lokalizavimas. Reikalavimų lokalizavimo matrica. (4) 125. Reikalavimų nuleidimas žemyn. Išvestiniai ir papildomi reikalavimai. (4) 126. Reikalavimų trasavimas. Reikalavimų trasų aprašymas matrica. (4) 127. Svarbiausieji programų sistemų komponavimo mechanizmai. Tiltų ir vartų skirtumai. (4) 128. Svarbiausios objektinio projektavimo problemos (4) 129. Kokius svarbiausius projektinius sprendimus tenka priimti projektuojant objektiškai (4) 130. Klasių protokolų projektavimas objektiniame projektavime (4) 131. Objektinio projektavimo euristikos. (4) 132. Projektinių sprendimų vertinimo kriterijai objektiniame projektavime (4) 5 balai 133. Kokie informacijos rinkimo metodai naudojami sisteminėje analizėje? Trumpai apibūdinkite juos.(5) 134. Kaip atliekami dalykinės analizės metu surinktų faktų klasifikavimas ir apibendrinimas? Kas vadinama nuostata? perspektyva? požiūriu? Kas vadinama požiūrių integravimu? Kaip jis atliekamas?(5) 135. Kas tai yra reikalavimų specifikacija? Kokios yra pageidautinos reikalavimų specifikacijų savybės?(5) 136. Kokie yra reikalavimų verifikavimo ir vertinimo metodai? Trumpai apibūdinkite juos?(5) 137. Projektavimo metodikų vertinimo problemos. Song ir Osterweil pasiūlymų esmė. (5) 138. Kaip galima aprašyti konkretaus programų sistemos kūrimo projekto ypatumus, renkantis tinkamiausią projektavimo metodiką ?(5) 139. Imperatyviosios architektūros (5) 140. Reaktyviosios architektūros. (5) 141. Primityviosios konstrukcijos ir jų konkretizacija. Pateikite pavyzdžių. (5) 142. Aukštesnės eilės (neprimityviosios) konstrukcijos ir jų konkretizacija (5) 143. Objektinių architektūrinių karkasų ypatumai. Abstrakčiosios klasės. Standartinė karkaso realizacija. (5) 144. Programinio komponento samprata, Kuo komponentai skiriasi nuo tradicinių modulių? (5) 6 balai 145. Duomenų srautų stiliaus architektūros, jų ypatumai, privalumai ir trūkumai bei atmainos (6) 146. Programų sistemos specifinės dalykinės architektūros samprata (6) 147. Programų sistemos bendrosios dalykinės architektūros samprata (6) 148. Programų sistemų šeimos (organizacijos informacinės sistemos) bendrosios architektūros samprata (6) 149. Sistemos skaidymo į posistemius strategijos objektiniame projektavime (6) 7 balai 150. Kaip pasinaudoti tipine konstrukcija? Pateikite pavyzdžių. (7) 151. Klasių bibliotekų ir bjektinių architektūrinių karkasų skirtumai. (7) 152. Programų sistemų ir programų sistemų šeimų kūrimo procesų skirtumai (7) 153. Išvardinkite svarbiausius programų sistemų šeimos (organizacijos informacinės sistemos) bendrosios architektūros sluoksnius. Trumpai apibūdinkite juos. (7) 154. Bendroji modulio samprata. Charakteristikos, apibūdinančios modulio tipą. Modulių panaudojimo būdai, aktyvavimo mechanizmai ir vykdymo būdai (7) 155. Koudo ir Jodano projektavimo strategija (7) 1 balas 1. Kokiu tikslu programų sistemų inžinerijoje įvesta programų sistemos gyvavimo ciklo modelio sąvoka?(1)Programų sistemos gyvavimo ciklo modelio sąvoka buvo įvesta siekiant palengvinti programų sistemų kūrimo projektų planavimą ir valdymą. Programų sistemos kūrimas – ilgas, sudėtingas ir brangus procesas. Jis gali trukti keletą metų. Norint planuoti tokio projekto baigimo terminus ir sąmatinę vertę, reikia numatyti, kokius ir kokio sudėtingumo darbus teks vykdyti. Svarbi ir tų darbų vykdymo eilės tvarka. Nežinat jos, negalima planuoti kaip bus naudojami resursai. Norint veiksmingai valdyti jau vykdomą projektą, taip pat reikia žinoti, kokie darbai ir kokia eilės tvarka turi būti vykdomi. Be to, būtina sugebėti bet kuriuo momentu įvertinti esamą projekto būklę, nustatyti, kokie darbai jau atlikti, kokie dar tik pradedami, įpusėti, baigiami ir t.t. Prielaida: planuoti ir valdyti projektus yra neįmanoma jų nesuskaidžius į pakankamai mažas, matuojamas, kontroliuojamas ir lengvai valdomas dalis, vadinamas darbais. Tam naudojamas dekompozicijos principas. Pageidautina, kad projekto skaidymo būdas nebūtų unikalus, t.y. pageidautina jį tipizuoti. Kitaip kiekvieną projektą tektų skaidyti, planuoti ir valdyti savaip. Tipizuoti programų sistemų kūrimo projektų suskaidymo į darbus būdai yra vadinami programų sistemų gyvavimo ciklo modeliais. 2. Kas vadinama programų sistemos gyvavimo ciklu ir kas programų sistemos gyvavimo ciklo modeliu?(1) Programų sistemos gyvavimo ciklu vadinamas laikotarpis nuo tos sistemos sumanymo iki jos demontavimo momento. Modeliuojant programų sistemos gyvavimo ciklą, visų pirma nustatoma, kokias kokybiškai skirtingas ir prasmingas būsenas gali įgyti sistema tame cikle. Išskirtosios būsenos sutvarkomos eilės tvarka ir kiekvienai viena po kitos einančių būsenų porai parenkami technologiniai procesai, reikalingi vėlesnei sistemos būsenai iš ankstesnės formuoti. Programų sistemos gyvavimo ciklo modelis - tai tos sistemos gyvavimo ciklo eigoje vykdomų procesų, veikų, užduočių ir technologinių operacijų visuma, sutvarkyta laiko atžvilgiu. Modelis numato vykdomų procesų kontrolės taškus ir nustato, kokie tarpiniai ir galutiniai produktai turi būti sukurti gyvavimo ciklo eigoje. Gyvavimo ciklo modelis apibūdina programų sistemos kūrimo technologinius procesus. Modelio paskirtis: nustatyti stadijų vykdymo eiliškumą ir perėjimo iš vienos stadijos į kitą kriterijus, padėti gauti atsakymus į klausimus, kada baigti šiuo metu atliekamus darbus ir kokius darbus reiks daryti po to. 3. Kas tai yra projekto palaikymo sistema?(1) Projekto palaikymo sistema = Techninė įranga + Projekto valdymo metodai + Instrumentinės priemonės + PSI paradigma. Viduje organizacinė struktūra. 4. Kokia programų sistemų inžinerijos paradigma grindžiamas klasikinis gyvavimo ciklo modelis?(1) Klasikinis gyvavimo ciklo modelis grindžiamas programų sistemų kūrimo iš viršaus žemyn paradigma. Jame numatyti tokie abstrakcijos lygmenys, kaip sistemos specifikacija, eskizinis projektas, detalusis projektas ir kodas. Tačiau sistemos konstravimas yra grindžiamas programų sistemų kūrimo iš apačios aukštyn paradigma. Modelyje yra numatyta, kad iš pradžių sistemos sudėtinės dalys testuojamos ir tikrinamos kiekviena atskirai, po to jos integruojamos ir tik po to testuojama visa sistema. 5. Kokias stadijas numato klasikinis gyvavimo ciklo modelis?(1) Modelis numato septynias stadijas: 1) sistemos specifikavimas, 2) eskizinis sistemos projektavimas, 3) detalusis sistemos projektavimas, 4) programavimas ir programų derinimas, 5) sistemos surinkimas ir aprobavimas, 6) sistemos diegimas (tiražavimas), 7) sistemos naudojimas ir priežiūra. 6. Kokie yra programų sistemos specifikavimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) Pagrindiniai sistemos specifikavimo stadijos tikslai yra šie: 1) ištirti būsimų sistemos naudotojų poreikius, 2) nustatyti tikslus, kurių siekiama kuriant sistemą, 3) transformuoti tikslus į programų sistemos reikalavimus, 4) išanalizuoti galimus sistemos įsigijimo variantus ir pasirinkti genausiąjį iš jų, 5) nustatyti finansinius ir kitus projekto apribojimus, 6) organizuoti konkursą, 7) inicijuoti tolimesnius projekto darbus. 7. Kokiais aspektais nagrinėjama programų sistema techninėje užduotyje?(1) Techninė užduotis nusako: 1) kodėl yra kuriama programų sistema (operacinė sistemos naudojimo koncepcija), 2) kam ir kokia nauda bus sukūrus sistemą (operacinė sistemos naudojimo koncepcija), 3) kokie darbai turi būti atlikti ir kas turi būti padaryta tų darbų metu (darbo užduotis), 4) kokias funkcijas turi vykdyti sukurtoji sistema ir kokiomis kitomis ypatybėmis ji turi pasižymėti (programų sistemos reikalavimai), 5) kaip turi būti dokumentuojami atlikti darbai ir jų rezultatai (darbo užduotis), 6) kokiais terminais ir kokie darbai turi būti atlikti (projekto reikalavimai), 7) kaip turi būti kontroliuojama darbų eiga ir kokia atsiskaitymo už atliktus darbus tvarka (projekto reikalavimai). 8. Kas daroma programų sistemos specifikavimo stadijoje klasikiniame gyvavimo ciklo modelyje?(1) Stadijos pradžioje analizuojama dalykinė sritis, nustatomi naudotojų poreikiai ir priimamas sprendimas įsigyti sistemą. Priėmus tokį sprendimą, formuluojami sistemos kūrimo tikslai bei reikalavimai, kuriuos ji turi tenkinti ir atliekama tų tikslų įgyvendinamumo analizė techniniu, ekonominiu bei juridiniu požiūriais. Po to sprendžiama, kokiu būdu sistema bus įsigyjama. Ji gali būti perkama, užsakoma sukurti arba kuriama savo pačių jėgomis. Galimas yra ir mišrus sistemos įsigyjimo būdas, t.y. vienos sistemos dalys gali būti perkamos, kitos - užsakomos, dar kitos - kuriamos savo jėgomis. 9. Kokie yra programų sistemos projektavimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) Projektuojant programų sistemą, yra siekiama šių pagrindinių tikslų: 1) nustatyti visas kuriamosios programų sistemos vykdomas funkcijas ir jų tarpusavio sąryšius, 2) nustatyti iš kokių sudėtinių dalių turi būti sudaryta kuriamoji sistema ir pasiūlyti tas dalis jungiantį konstrukcijos santykį, 3) pasiūlyti kuriamosios programų sistemos ir kiekvienos sudėtinės dalies veikimo principus, 4) nustatyti, kokie duomenys bus apdorojami su kuriama programų sistema ir pasiūlyti, kaip tie duomenys turi būti gaunami, organizuojami ir saugomi, 5) pasiūlyti kuriamosios programų sistemos išorinius interfeisus ir jų realizavimo būdus, 6) nustatyti, kokioje operacinėje aplinkoje veiks kuriamoji programų sistema, 7) pasiūlyti kuriamosios programų sistemos darbo kompiuteriniame tinkle principus. Visi pateikti pasiūlymai turi būti ekonomiškai ir techniškai pagrįsti. Juos reikia fiksuoti raštiškai. 10. Kokie yra pagrindiniai programų sistemos projektavimo žingsniai klasikiniame gyvavimo ciklo modelyje?(1) Programų sistemų projektavimo žingsniai ir jų vykdymo tvarka priklauso nuo pasirinkto projektavimo metodo. Nepaisant to, galima išskirti šiuos pagrindinius projektavimo žingsnius, bendrus daugumai projektavimo metodų: 1) funkcinės architektūros projektavimas, 2) modulinės architektūros projektavimas, 3) duomenų architektūros projektavimas, 4) išorinių interfeisų projektavimas. 5) programų projektavimas. Projektuojant intelektualizuotas programų sistemas, papildomai tenka projektuoti žinių bazes. Be to, kartu su sistema yra projektuojami jos eksploatavimo dokumentai, testai, demonstraciniai pavyzdžiai ir pan. 11. Kokie yra programavimo ir programų derinimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) Šioje stadijoje programuojami, derinami ir autonomiškai testuojami kuriamosios programų sistemos moduliai. Autonominio testavimo rezultatai protokoluojami. Taip pat yra rašomos sistemos naudojimo instrukcijos ir kiti jos eksploatavimo dokumentai. Dokumentacijos sudėtis ir jos apipavidalinimo reikalavimai nurodomi techninėje užduotyje. 12. Kas daroma programavimo ir programų derinimo stadijoje klasikiniame gyvavimo ciklo modelyje?(1) Programuojami, derinami ir autonimiškai testuojami kuriamos PS moduliai. Testavimo rezultati protokoluojami. Rašomos naudijimo instrukcijos. Kuriamos duomenų bazės. 13. Kokie yra programų sistemos integravimo ir aprobavimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) Pagrindiniai integravimo ir aprobavimo stadijos tikslai yra šie: 1) sujungti visus sistemos komponentus į vieną visumą ir patikrinti to sujungimo korektiškumą, 2) patikrinti, ar visi techninės užduoties reikalavimai yra įgyvendinti, ir pašalinti sistemoje esančius techninės užduoties reikalavimų pažeidimus, 3) parengti sistemą tiražavimo ir diegimo darbams. 14. Kas daroma programų sistemos integravimo ir aprobavimo stadijoje klasikiniame gyvavimo ciklo modelyje?(1) Bazės, moduliai jungiami vienas su kitu. Sujungus atliekamas struktūrinis testavimas, siekiama įsitikinti, kad PS kūrimo darbai baigti. Kad patikrinti sistemos veikimą atliekami priėmimo bandymai. 15. Kokie yra programų sistemos diegimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) Įdiegti sistemą, apmokyti būsimus naudotojus, sukaupti būtinus pradinius duomenis. 16. Kas daroma programų sistemos diegimo stadijoje klasikiniame gyvavimo ciklo modelyje?(1) Vyksta sistemos diegimas. Sistema instaliuojama kompiuteriuose, apmokomi naudotojai, kaupiami pradiniai duomenys. 17. Kokie yra programų sistemos naudojimo ir priežiūros stadijos tikslai klasikiniame gyvavimo ciklo modelyje?(1) Išspręsti konkrečius uždavinius, aptarnauti, tobulinti, administruoti DB, periodiškai testuoti. Jei reikia sukirti naują verisiją. 18. Kas daroma programų sistemos naudojimo ir priežiūros stadijoje klasikiniame gyvavimo ciklo modelyje?(1) Sistema naudojama konkretiems uždaviniams spręsti, vykdomas aptarnavimas, ji tobulinama. Atliekamas DB administravimas, periodinis kontrolinis testavimas, etc. Pasenus kuriama nauja versija. 19. Kokie yra kontroliniai taškai klasikiniame gyvavimo ciklo modelyje?(1) Techninės Užduoties tvirtinimas, TU inspektavimas, eskizinio projketo inspektavimas, darbo rezultatų peržiūra, inspektavimas ir vertinimas, bandymų rezultatų peržiųra ir vertinimas, galutinės sistemos konfigūracijos peržiūra. 20. Kokie yra klasikinio gyvavimo ciklo modelio trūkumai?(1) Klasikinis gyvavimo ciklo modelis naudojamas gana plačiai. Tačiau paaiškėjo, kad jį naudoti tikslinga ne visuose projektuose ir kad jis turi keletą esminių trūkumų. Pagrindiniai klasikinio gyvavimo ciklo modelio trūkumai yra šie: 1) nenumatyta lygiagretaus stadijų vykdymo galimybė, 2) remiamasi daugeliu atvejų nerealia prielaida, kad galima iš karto suformuluoti visus sistemos reikalvimus ir juos tiksliai specifikuoti, 3) programų sistema konstruojama iš apačios aukštyn, 4) skirtingose klasikinio gyvavimo ciklo modelio stadijose yra naudojamos skirtingos kalbos, pereinant iš vienos stadijos į kitą, aprašus tenka rankiniu būdu transliuoti iš vienos kalbos į kitą. 5) naudojant nepakankamai formalias kalbas, pradinėse stadijose neįmanoma reikiamu laipsniu patikrinti gautų rezultatų korektiškumą, todėl pagrindiniai sistemos tikrinimai ir vertinimai nustumiami į ciklo pabaigą ir daugelis padarytų klaidų randama per vėlai. 6) Kritikuotinas ir naudojamų kalbų pobūdis, nes jos yra sintaksinio pobūdžio, t.y. tokios, kuriose pagrindinis dėmesys skiriamas formai (kaip sakoma), o ne turiniui (kas sakoma) Programavimo kalbų teorijoje tokios kalbos vadinamos sintaksiškai orientuotomis kalbomis. Norint formalizuoti tekstų, parašytų sintaksiškai orientuotomis kalbomis, prasmę, reikia sukonstruoti kalbos sintaksinių struktūrų semantinio interpretavimo taisykles. Kadangi klasikiniame gyvavimo ciklo modelyje naudojamų kalbų sintaksė yra skirtinga, tai joms interpretuoti tenka naudoti skirtingus semantinius metodus. 21. Kam skirtas pagrindinis dėmesys spiraliniame programų sistemos gyvavimo ciklo modelyje?(1) Pagrindinis dėmesys skiriamas ne tam, kaip specifikuoti ar maketuoti kuriamąją sistemą, o tam, kaip nustatyti sistemos kūrimo proceso rizikos veiksnius ir kaip juos šalinti. 22. Kokios stadijos yra spiraliniame programų sistemos gyvavimo ciklo modelyje?(1) Kiekvienam projektui projektuojamas konkretus, geriausiai jam tinkantis spiralinis gyvavimo ciklo modelis. Projektavimo metu nustatomas konkretus to projekto stadijų skaičius. Spiraliniame gyvavimo ciklo modelyje visų stadijų struktūra vienoda. Pagrindinės stadijos:alternatyvų vertinimas, rizikos faktorių analizė ir eliminavimas; sistemos kūrimo tikslų, alternatyvų ir apribojimų formulavimas; Produkto kūrimas, tikrinimas ir vertinimas. 23. Kas programų sistemų inžinerijoje vadinama reikalavimu? reikalavimų specifikacija?(1) Objekto (proceso) reikalavimu vadinama specifikacija, sutartimi su užsakovu, standartu arba kokiu nors kitu juridinę galią turinčiu ir įpareigojančiu dokumentu numatyta to objekto (proceso) savybė. 24. Kas vadinama programų sistemos reikalavimų lokalizavimu?(1) Tai reikalavimų skaidymas į grupes ir tų grupių susiejimas su funkciniais sistemos komponentais. 25. Koks reikalavimas vadinamas abstrakčiu?(1) Tai reikalavimas, kuris specifikuoja operacinę(stebimą iš išorės) objekto(proceso) savybę. 26. Koks reikalavimas vadinamas įgyvendinamu?(1) Jei žinomas juridiniu, ekonomniu ir kt. požiūriais priimtimas technologinis procesas, kurio inovacinius slesčių pašalinimas yra priimtinas, ir kurį tai kant galima sukruti objektą(procesą), tenkinantį specifikuotą savybę. 27. Koks reikalavimas vadinamas integruojamu?(1) Jei jį sujungus su kitais reikalavimais gaunamas suderintas rinkinys. 28. Koks reikalavimas vadinamas išsamiu?(1) Turintis prasmę ne tik tuomet, kai nagrinėjamas su kitais reikalavimais, bet ir atskirai. 29. Koks reikalavimas vadinamas lokakizuojamu?(1) Jį galima susieti bent su vienu objekto(proceso) komponentu. 30. Koks reikalavimas vadinamas trasuojamu?(1) Jei jis veinareikšmiškai įvardijamas ir turi nuorodą į šaltinį. 31. Koks reikalavimas vadinamas suprantamu?(1) Vienareikšmis reikalavimas. 32. Koks reikalavimas vadinamas glaustu?(1) Jei aprašoma tik specifikuojama objekto(proceso) savybė ir nėra aiškinami motyvai. 33. Koks reikalavimas vadinamas unikaliu?(1) Jame nesikartoja kituose reikalavmuose pateikta informacija. 34. Koks reikalavimas vadinamas verifikuojamu?(1) Egzistuoja baigtinis procesas, kurį taikant galima nustayti ar reikalavimas įgyvendintas. 35. Kas vadinama programų sistemos reikalavimų nuleidimu žemyn?(1) Funkcinių komponentų reikalavim išvedimo iš lokalizuotų funkcinio komponento reikalavimų, į kurio sudėtį tie komponentai įeina, reikalavimų ir išvestinių reikalavimų papildymo procesas. 36. Kokie sistemos funkcinio komponento reikalavimai vadinami išvestiniais?(1) Tai tokie reikalavimai, kurie išplaukia iš aukštesnio lygmens funkcinio agregato lokalizuojamų reikalavimų. 37. Kas tai yra reikalavimų ryšio matrica?(1) Joje nurodoma reikalavimas, iš kokių reikalavimų jis išvestas, kokiame funkciniame komponente lokalizuotas, reikalavimo aprobavimo būdas, aprobavimo rezultatai. 38. Kokie turi būti gerai suformuluoti programų sistemos reikalavimai?(1) Gerai suformuluotas reikalavimas turi būti abstraktus, įgyvendinamas, lokalizuojamas, išsamus, integruojamas, suprantamas, unikalus, glaustas, verifikuojamas, trasuojamas. Be to, reikalavimas turi būti formuluojamas vartojant to funkcinės architektūros lygmens, kuriame jis yra lokalizuojamas, terminus. 39. Kas tai yra anotuoti reikalavimai?(1) Nurodytas jo statusas, kritiškumas ir galiojimo laikas. 40. Kas yra reikalavimo statusas?(1) Ne visi ps reikalavimai yra vienodai svarbūs. Yra trys reikalavimų statuso grupės: Privalomi, jų neįgyvendinus nebus įgyvendintas sistemos naudojimo siekis, Pageidavimai, jų įgyvendinimas padės sistemos naudojimo siekį realizuoti, Papildomi, už papildomą mokestį praplečiamas sistemos naudojimo siekis. 41. Kas yra reikalavimo kritiškumas?(1) Reikalavimo kritiškumas – kokios bus jo pažeidimo pasekmės. 42. Kuo skiriasi programų sistemos reikalavimai ir projekto reikalavimai?(1) PS reikalavimai nurodo, kokia sistema turi būti sukurta, projketo reikalavimai nurodo, kaip ji turi būti sukurta. 43. Į kokias grupes skirstomi projekto reikalavimai?(1) Technologiniai, kokybės, valdymo, konfig. valdymo, vykdymo terminų, vykdymo kontrolės, finansavimo, projekto rezultatų ir jų pateikimo, projeketo rezultatų aprobavimo, garantijų, ginčų sprendimo tvarkos, ypatingieji. 44. Ką apibūdina technologiniai projekto reikalavimai?(1) Jie skirstomi į projektavimo(jais nustatomi projektavimo metodai, technologija bei priemonės, projektavimo rezultatų dokumentavimo būdai); realizavimo(jais nustatoma, kokias programavimo kalbas naudoti, kokią instrumentinę prg. Įrangą naudoti ps realizuoti, kokią kompiuterinę platformą ir konkrečią jos konfigųraciją programoms derinti ir testuoti, struktūrizavimo metodus, programų tekstų formatavimas); parengimo darbui: kaip instaliuoti sukurtas programas, kaip kurti ir pildyti DB, kaip atlikti kitus pareng. darbus. 45. Ką apibūdina projekto kokybės valdymo reikalavimai?(1) Kokybės valdymo reikalavimais nustatoma, kaip planuoti ir kontroliuoti kuriamosios programų sistemos kokybę ir kaip šalinti pastebėtus nuokrypius nuo kokybės plano. 46. Ką apibūdina projekto konfigūracijos valdymo reikalavimai?(1) Konfigūracijos valdymo reikalavimais nustatomi konfigūracijos valdymo metodai, naudojami kuriamosios programų sistemos konfigūracijai valdyti. 47. Ką apibūdina projekto valdymo reikalavimai?(1) Valdymo terminų reikalavimais nustatomi projekto stadijos, etapai ir jų baigimo terminai. valdymo kontrolės reikalavimais nustatomi projekto kontrolės taškai ir tuose taškuose naudojamas kontrolės procedūros. Kontrolės taškais dažniausiai numatomi tie laiko momentai, kuriuose planuojama gauti kokius nors išbaigtus rezultatus. Kontrolės taškuose tikrinama, ar yra gauti visi reikiami rezultatai ir ar jie yra korektiški. Galima atlikti ir rezultatų vertinimą. Rezultatams vertinti naudojamos inspektavimo, audito ir peržiūros procedūros. 48. Ką apibūdina projekto finansavimo reikalavimai?(1) Finansavimo reikalavimais nustatoma projekto kaina, finansavimo būdas ir jo finansavimo tvarka. 49. Ką apibūdina projekto rezultatų ir jų pateikimo reikalavimai?(1) Nurodoma, kokie galutiniai ir tarpiniai rezultatai (programos, DB, failai, testai, etc.) turi būti pateikiami projekto vykdymo metu ir jų pateikimo būdas. 50. Ką apibūdina projekto rezultatų aprobavimo reikalavimai?(1) Projekto rezultatų aprobavimo reikalavimais nustatomi projekto rezultatų vertinimo kriterijai ir darbų priėmimo tvarka. Jais numatoma, kas turi parengti bandymų programą ir metodiką, kur bus vykdomi baigiamieji programų sistemos bandymai, kas sudarys priėmimo komisiją, koks bus oficialus tų bandymų statusas ir kaip įsipareigoja elgtis šalys, jei bandymai bus nesėkmingi. 51. Ką apibūdina projekto garantijų reikalavimai?(1) Garantijų reikalavimais nustatomi: 1) garantinio laikotarpio pradžia ir trukmė, 2) garantiniai tiekėjo įsipareigojimai (nemokamas klaidų šalinimas, konsultacijos, techninė parama ir pan.), 3) užsakovo atsakomybė už neteisėtas pretenzijas (defektus dėl užsakovo kaltės, bereikalingą tiekėjo atstovų iškvietimą ir pan.), 4) užsakovo ir tiekėjo įsipareigojimai saugoti intelektualinės ir pramoninės nuosavybės teises, neskleisti gaunamos informacijos ir vartoti ją tik tam tikslui, kuriam ji yra skirta. Kartais dar yra nustatomos tiekėjo finansinės garantijos laikytis prisiimtų įsipareigojimų. Ginčų sprendimo reikalavimais nustatoma galimų tiekėjo ir užsakovo ginčų sprendimo tvarka. Ypatingaisiais reikalavimais nustatoma, kaip turi elgtis šalys ypatingų aplinkybių (karas, stichinės nelaimės, streikai ir pan.) atveju. 52. Į kokias grupes skirstomi programų sistemos reikalavimai?(1) Programų sistemos reikalavimų rūšys: 1) funkciniai reikalavimai, 2) nefunkciniai reikalavimai Funkciniai reikalavimai: 1) Funkciniais programų sistemos reikalavimais nusakoma, ką ta sistema turi gebėti daryti. 2) Jais specifikuojamos pagrindinės ir pagalbinės kuriamosios sistemos funkcijos. 3) Pagrindinėmis vadinamos funkcijos skirtos kuriamosios sistemos siekiui realizuoti. 4) Pagalbinės funkcijos išplaukia iš technologinių reikalavimų. Jomis naudojamasi aptarnaujant ir prižiūrint sistemą. Pavyzdžiai: programų sistemos darbo protokolavimas, duomenų archyvavimas, statistikos apie sistemos darbą kaupimas ir pan. Formuluojant funkcinius reikalavimus, kiekvienai funkcijai yra nurodomi: 1) pradiniai duomenys, 2) atliekami veiksmai, 3) rezultatai. Be to, reikia nurodyti funkcijų vykdymo tvarką ir jų vykdymo technologinius apribojimus, pavyzdžiui, funkcijas, kurias draudžiama vykdyti vieno darbo seanso metu. Nefunkciniais programų sistemos reikalavimais vadinami reikalavimai, ribojantys aibę potencialiai galimų projektinių sprendimų apie funkcinių reikalavimų įgyvendinimo būdą. 53. Kas įvyksta pažeidus funkcinius sistemos reikalavimus?(1) Pažeidus funkcinius reikalavimus, programų sistema tampa nekorektiška. Sistema, procesas arba bet koks kitas objektas vadinama korektišku, jei jo savybės sutampa su duoto etalono savybėmis. Etalonas gali būti nurodytas ir netiesiogiai, kaip daugiau ar mažiau formalizuotas etalo­ninių reikalavimų rinkinys. Programų sistemos korektiškumas nusakomas jos atitikimo specifikacijoje suformuluotiems reikalavi­mams laipsniu. Programų sistemos korektiškumas - statinė savybė. Pagrindinės programų sistemų nekorektiškumo priežastys - tai projektavimo ir kodavimo klaidos. 54. Į kokias pagrindines grupes skirstomi nefunkciniai sistemos reikalavimai?(1) Nefunkcinių reikalavimų rūšys: 1) interfeiso reikalavimai, 2) veikimo reikalavimai, 3) iš ekonominių apribojimų išplaukiantys reikalavimai, 4) iš politinių apribojimų išplaukiantys reikalavimai, 5) iš teisinių apribojimų išplaukiantys reikalavimai. 55. Kokie yra dalykinės srities analizės rezultatai? Trumpai apibūdinkite juos. (1) 56. Kas programų sistemų inžinerijoje vadinama reikalavimų įgyvendinimo delsa?(1) Reikalavimų įgyvendinimo delsa vadinamas laikotarpis nuo programų sistemos reikalavimų formulavimo pradžios iki užsakovo poreikių, buvusių tuo metu, įgyvendinimo momento 57. Kas programų sistemų inžinerijoje vadinama programų sistemos ilgaamžiškumu?(1) Sistemos gyvavimu (ilgaamžiškumu) vadinamas laikotarpis nuo sistemos įdiegimo iki jos demontavimo mo­mento. 58. Kas programų sistemų inžinerijoje vadinama atotrūkiu tarp užsakovo poreikių ir sistemos galimybių?(1) Atotrūkiu vadinamas dydis, nusakantis skirtumą tarp užsakovo poreikių ir sistemos galimybių. 59. Kas programų sistemų inžinerijoje vadinama sistemos adaptyvumu?(1) Kampas, kurį sudaro programos sistemos galimybių grafikas su laiko ašimi, yra vadinamas sistemos adaptyvumu. 2 balai 60. Kokios yra interfeiso reikalavimų grupės? trumpai apibūdinkite jas?(2) Interfeiso reikalavimais vadinami tokie nefunkciniai programų sistemos reikalavimai, kuriuos pažeidus sistema nebegali funkcionuoti toje aplinkoje, kurioje ją buvo numatyta naudoti, pavyzdžiui, jos nebegalima vykdyti turimoje kompiuterinėje platformoje arba nebegalima suformuluoti tų užduočių, kurias ta sistema turi vykdyti. Kitaip tariant, pažeidus interfeiso reikalavimus, sistema gali vykdyti visas numatytas funkcijas, bet kai kuriomis iš tų funkcijų pasinaudoti tampa neįmanoma. Rūšys:1) semantiniai (prasminiai) reikalavimai, 2) sintaksiniai (struktūriniai) reikalavimai, 3) pragmatiniai (tikslinės paskirties) reikalavimai, 4) protokolo (sąveikos būdo) reikalavimai. Semantiniais interfeiso reikalavimais nusakomi sistemai per jos interfeisus pateikiamos informacijos pobūdis ir tos informacijos interpretacija. Sintaksiniais interfeiso reikalavimais nusakomi informacijos pateikimo forma ir jos struktūrinių elementų vaizdavimas. Pragmatiniais interfeiso reikalavimais nusakoma tikslinė interfeiso paskirtis. Protokolo reikalavimais aprašomi darbo su sistema taisyklės ir susitarimai. Kitaip tariant, jais nurodoma, kaip per interfeisus sistemai perduoti informaciją. 61. Kokios yra sistemos veikimo reikalavimų grupės? trumpai apibūdinkite jas?(2) Sistemos veikimo reikalavimų rūšys: tikslumo reikalavimai, patikimumo reikalavimai, robastiškumo reikalavimai, našumo reikalavimai. Tikslumo reikalavimai skirstomi į duomenų vaizdavimo tikslumo, skaičiavimo tikslumo. Programų sistemos realizuojamu duomenų vaizdavimo tikslumu vadinama sistemos skiriamoji geba, t.y. geba skirti jos apdorojamus objektus vienas nuo kito. Programų sistemos skaičiavimų tikslumu vadinamas jos gaunamų rezultatų nesutapimo su tais rezultatais, kuriuos ji turi gauti, laipsnis. Programų sistemos patikimumo samprata yra gana sudėtinga ir šiuo metu dar nėra pakankamai suvokta. Ji išreiškiama remiantis sistemos funkcionalumo, trykio, funkcionalumo praradimo ir funkcionalumo atkūrimo sąvokomis. Programų sistemos funkcionalumu vadinama tos sistemos geba vykdyti specifikacijoje numatytas funkcijas. Programų sistemos trykiu vadinamas vidinis įvykis, pažeidžiantis jos funkcionalumą. Vidiniais vadinami įvykiai, sąlygoti pačios sistemos atliekamų veiksmų. Programų sistemos funkcionalumo praradimu vadinamas gebos vykdyti specifikacijoje numatytas funkcijas praradimas. Programų sistemos funkcionalumo atkūrimu yra vadinami veiksmai, kuriuos reikia atlikti tam, kad būtų atkurta sistemos geba vykdyti jos specifikacijoje numatytas funkcijas. Programų sistemos patikimumu vadinama jos trykių poveikio operacinių tikslų realizavimui dydis. Programų sistemos robastiškumu vadinama jos geba automatiškai atkurti savo funkcionalumą. Prarastą dėl trykių arba išorinių poveikių, ir atnaujinti savo veikimą. PS vadinama našia (veiksminga), jei ji naudoja tik tiek resursų, kiek jų reikia specifikacija numatytoms funkcijoms korektiškai vykdyti. 62. Kokios yra iš ekonominių apribojimų išplaukiančių reikalavimų grupės? trumpai apibūdinkite jas?(2) Iš ekonominių ribojimų išplaukiančių reikalavimų grupės: diegimo reikalavimai, aptarnavimo reikalavimai, modernizavimo reikalavimai, komponentų tiražuojamumo reikalavimai. PS diegimo reikalavimais siekiama minimizuoti išlaidas, reikalingas naudotojams ir aptarnau­jančiam personalui apmokyti bei sistemą darbui parengti. Aptarnavimo procedūrų automatizavimo reikalavimai formuluojami kaip funkciniai reikalavimai. Jais nurodoma, kokios priemonės turi būti numatytos kuriamojoje PS: archyvams aptarnauti, gedimams lokalizuoti, komplektiškumui ir komponentų funkcionalumui (veikimo korektiškumui) tikrinti. Modernizavimo reikalavimai yra šie: pritaikomumo reikalavimai, universalumo reikalavimai, perkeliamumo reikalavimai, lankstumo reikalavimai, adaptyvumo reikalavimai, praplečiamumo reikalavimai. PS komponentas vadinamas tiražuojamu, jei juo galima naudotis ne tik tuomet, kai jis yra sistemos sudėtyje, bet ir savarankiškai. 63. Kokie reikalavimai išplaukia iš politinių apribojimų? trumpai apibūdinkite juos?(2) Dauguma politinio pobūdžio reikalavimų yra speci­finiai, būdingi konkrečiai organizacijai. Vienintelis universalus reikalavimas yra PS apsauga nuo neteisėto naudojimo. Teisėtu PS naudojimu vadinamas sistemos naudojimas pagal jos paskirtį, atliekamas asmens, turinčio tam oficialius įgaliojimus. PS apsaugos mechanizmu vadinamos priemonės skirtos tos sistemos saugumui gresiančioms grėsmėms nustatyti ir pašalinti. Mechanizmo veiksmingumas nusakomas tikimybe, kad bus nustatyta ir pašalinta bet kokia potencialiai galima grėsmė. Apsaugos reikalavimais nustatoma, koks turi būti kuriamos sistemos apsaugos mechanizmo veiksmingumas, ir galbūt specifikuojami to mechanizmo komponentai. 64. Kokie reikalavimai išplaukia iš teisinių apribojimų? trumpai apibūdinkite juos?(2) Teisiniai ribojimai (įstatymai, vyriausybės nutarimai, organizacijų statutai ir kiti normatyviniai dokumentai) nustato: kurios funkcijos gali būti kompiuterizuotos, kokie duomenis gali būti renkami bei kaupiami. Formuluojant funkcinius PS reikalavimus, būtina atsižvelgti į konstitucinį įstatymų leidžiamosios, vykdomosios ir teisminės valdžių atskyrimo principą. Reikia atsižvelgti ir į tai, kad PS nepažeistų konkurencijos įstatymo. Ypač tai aktualu sistemoms, kurios keičiasi informacija apie rinką arba ją platina. Projektuojant tokias sistemas, reikia užtikrinti, kad nebūtų atskleistos komercinės paslaptys, informacija apie vieną varžovą nebūtų prieinama kitam varžovui. Ar PS nepažeis teisinio organizacijos statuso Ar PS išspausdinti dokumentai bus pripažįstami teisiškai Ar nepažeis telekomunikacijos įstatymų, etc. 65. Kas tai yra dalykinės srities analizė? Pagal kokią schemą ji vyksta?(2) Programų sistemos reikalavimų formulavimo būdai priklauso nuo to, ar ta sistema yra kokios nors kitos, platesnės sistemos komponentu, ar savarankiška sistema. Pirmuoju atveju programų sistemos reikalavimai yra išskiriami iš sistemos reikalavimų, antruoju - formuluojami apibendrinant dalykinės srities analizės rezultatus. Programų sistemos dalykinės srities analize vadinamas informacijos apie dalykinę sritį rinkimo, agregavimo, apibendrinimo ir suvokimo procesas. Analizuojant dalykinę sritį, nagrinėjami joje vykstantys procesai. Analizuojamų procesų pobūdis priklauso nuo kuriamosios sistemos pobūdžio. Pavyzdžiui, kuriant informacinę įstaigos sistemą, analizuojamas tos įstaigos padalinių darbas, o kuriant technologinių procesų valdymo sistemas, analizuojami kompiuterizuojami technologiniai procesai. Analizės metu siekiama: 1) išsiaiškinti užsakovų pageidavimus, 2) operacinius būsimų sistemos naudotojų poreikius, 3) suformuluoti kuriamosios sistemos reikalavimus, 4) sukaupti dalykinės srities specialistų naudojamų žinių bazę. Siekiama nustatyti, kokias užduotis tikslinga kompiuterizuoti ir išsiaiškinti kaip tas užduotis atlieka dalykinės srities specialistai. 66. Ką reikia padaryti, planuojant sisteminės analizės procesą?(2) Planuojant dalykinės srities sisteminės analizės procesą, reikia: 1) nustatyti analizės ribas, sudaryti apklausiamų asmenų ir studijuojamų dokumentų sąrašus (analizės objektas), 2) sudaryti užduočių sąrašą (analizės tikslai), 3) numatyti vykdytojus, skirti jiems darbo vietą, reikalingas darbo priemones ir lėšas (analizės resursus), 4) nustatyti užduočių vykdymo tvarką ir terminus (analizės planas). 67. Kaip yra atliekami reikalavimų specifikacijos verifikavimas ir vertinimas? Kokią specifikaciją vadiname korektiška? pagrįsta? įgyvendinama?(2) Sudarius reikalavimus, reikia įsitikinti jų korektiškumu ir pagrįstumu, išanalizuoti jų įgyvendinimo galimybes. Specifikacija korektiška, jei ji konceptuali, suvokiama, konkreti, tiksli, darni, išsami, trasuojama ir tenkima užduotyje numatytus dokumentavimo standartus. Specifikacija pagrįsta, jei ji yra adekvati operaciniams užsakovų ir būsimųjų PS naudotojų poreikiams. Specifikacija įgyvendinama, jei visi reikalavimai įgyvendinami. 68. Dalykinės srities koncepcinio modelio pertvarkymas į programų sistemos koncepcinę architektūrą (2) PS koncepcinė architektūra pradedama projektuoti pertvarkant dalykinės srities koncepcinį modelį į porgramų sistemos koncepcinį modelį. Pirmiausia dalykinės srities koncepcinis modelis išreiškiamas kuriamos programų sistemo struktūriniais primityvai, po to pertvarkomas į programų sistemos bendrąją dalykinė architektūraą, veliau suprojektuoja to sistemos specifinė dalykinė architektūra. 69. Kas vadinama koncepciniu programų sistemos projektavimu? Kokie uždaviniai yra sprendžiami koncepcinio projektavimo metu? Kaip traktuojamas konceptualizacijos principas koncepcinio projektavimo metu? (2) 70. Racionalumo principas. Subjektyviosios ir objektyviosios projektavimo proceso iracionalumo priežastys. (2) Racionalumo principas: Racionalumo principas reikalauja, kad kiekvienas projektinis sprendimas būtų gerai argumentuotas ir artintų prie siekiamo tikslo - geriausio programų sistemos įgyvendinimo būdo parinkimo. Stebint realų projektavimo procesą, dažnai susidaro įspūdis, kad šis procesas yra visiškai iracionalus. Kyla natūralus klausimas, kodėl šitaip yra. Subjektyvios proceso iracionalumo priežastys: a)Projektuotojams stinga žinių ir laiko išsamiai apsvarstyti ir motyvuoti priimamus sprendimus. b)Projektuotojai dažnai vadovaujasi vien savo intuicija bei sveika nuovoka, negali paaiškinti, kodėl priėmė tokį, o ne kitokį sprendimą. Objektyvios proceso iracionalumo priežastys: a)programų sistemos specifikacijos atotrūkio nuo nuo realių poreikių pašalinti neįmanoma, todėl sistemos projektavimo ir konstravimo metu specifikacija yra nuolat tikslinama bei keičiama. b)pakeitus specifikaciją, racionalūs projektiniai sprendimai gali tapti neracionaliais. Kaskart reikia peržiūrėti visus priimtus sprendimus ir galbūt kai kuriuos pakeisti. Tai padaryti yra neįmanoma. c)net ir tuomet, kai projektavimo metu programų sistemos specifikacija nekinta, visų duomenų, reikalingų racionaliems projektiniams sprendimams priimti, surinkti galimybių nėra. Daugelis pakankamai svarbių sistemos veikimo detalių paaiškėja tik pradėjus konstruoti programas. d)sunku iki galo susisteminti ir prasmingai panaudoti net ir tuos duomenis, kuriuos galima surinkti. Jų būna tiek daug, kad visus išanalizuoti bei įvertinti pritrūksta laiko. e)formaliu būdu transformuoti specifikaciją į racionaliai pagrįstą ir neturintį klaidų kuriamos programų sistemos projektą yra visiškai nerealu. 71. Kodėl, nepaisant objektyvių priežasčių, pažeidžiančių projektavimo proceso racionalumą, projektavimo metodikų studijos yra prasmingos? (2) Formalaus ir racionalaus projektavimo metodai nėra beverčiai. Juos reikia traktuoti kaip idealizuotas projektavimo schemas, kurių tiesiogiai panaudoti negalima, bet kuriomis vadovautis vis vien yra tikslinga. Idealizuotos programų sistemų projektavimo schemos naudingos dėl šių priežasčių: a)be projektavimo metodo sunku susiorientuoti nuo ko pradėti darbą, kuo vadovautis, ką daryti b)kiekvienas projektavimo metodas apibendrina tam tikrą kolektyvinę patirtį, todėl vadovaujantis nors ir idealizuota, bet teoriškai pagrįsta projektavimo schema, gaunamas racionalesnis projektas nei remiantis vien asmenine patirtimi c)projektavimo metodas padeda standartizuoti, suvienodinti projektavimo procedūras, dėl to lengviau bendrauti projektuotojams, vertinti darbų spartą, įtraukti į darbą naujus žmones ir kt. 72. Projektavimo metodo ir projektavimo metodikos skirtumai (2) Projektavimo metodas: Projektavimo metodu programų sistemų inžinerijoje vadinamas sistemingas procesas, veikimo būdas ar technika, naudojami programų sistemai projektuoti. Projektavimo metodika: Projektavimo metodika vadinama darni vienas kitą papildančių projektavimo metodų ir jų taikymo taisyklių visuma. Projektavimo metodika - tai konstruktyvūs racionalaus programų sistemos projektavimo principai, išreikšti tokia forma, kad juos būtų galima kuo lengviau suvokti, išmokti ir perteikti kitiems asmenims. 73. Tipiniai projektavimo metodikų komponentai (2) projektavimo strategijos, projektavimo procedūros, projektavimo euristikos, projektavimo kalba, projektavimo duomenų bazės, projektavimo paketai, tipiniai projektiniai sprendimai, tipinės konstrukcijos ir architektūriniai karkasai, projektavimo rezultatų kokybės matai. 74. Išvardinkite populiariausius programų sistemų architektūros stilius. (2) -valdymo srautų architektūros (control flow systems), -duomenų srautų architektūros (dataflow systems), -objektinės architektūros (object systems), -įvykiais valdomos architektūros (event-based systems), -sluoksninės architektūros (layered systems), -lentelėmis valdomos architektūros (table driven systems), -saugyklos architektūros (repositories), -pandemoniumo architektūros (pandemonium). 3 balai 75. Kaip praplėstas klasikinis gyvavymo ciklo modelis struktūriniame modelyje? (3) Struktūrizuotas programų sistemos gyvavimo ciklo modelis grindžiamas vadinamąja struktūrine programų sistemų kūrimo metodika. Sudėtinės struktūrinės metodikos dalys yra struktūrinė analizė, struktūrinis projektavimas, struktūrinis programavimas ir struktūrinis testavimas. Struktūrinė metodika reglamentuoja visus pagrindinius programų sistemos kūrimo procesus. Viena iš pagrindinių jos idėjų yra brėžinio arba, autorių žodžiais tariant, "popierinio" kuriamojo objekto modelio idėja [127]. Brėžiniai nuo seno yra naudojami statomiems pastatams, konstruojamoms mašinoms ir kitiems inžineriniams objektams modeliuoti. Struktūrinėje metodologijoje pirmą kartą pabandyta brėžinio idėją nuosekliai pritaikyti programų sistemoms. Iki to laiko, naudojant blokines schemas ir kitus panašius būdus, buvo modeliuojami tik atskiri kuriamųjų sistemų aspektai. Dažniausiai būdavo modeliuojami valdymo srautai. Struktūrinėje metodikoje pateiktas suderintų kalbų rinkinys, kurį naudojant galima modeliuoti visus kuriamosios sistemos aspektus. Struktūrinė metodika turi ir kitų privalumų. Vienas iš jų - projektinių sprendimų vertinimo kriterijai. Naudojant šiuos kriterijus, galima tiksliau įvertinti sisteminio analitiko, projektuotojo ir programuotojo darbo rezultatus. Dar vienas metodikos privalumas - galimybė vienu metu vykdyti keletą skirtingų veikų. Šia metodika pagrįstame programų sistemų gyvavimo ciklo modelyje numatyta, kad kai kurios veikos gali būti pradėtos nebaigus prieš tai vykdytų veikų ir kad kai kurios veikos dėl pakitusios situacijos ar dėl padarytų klaidų gali būti pakartotos. 76. Kaip praplėstas klasikinis gyvavymo ciklo modelis evoliuciniame modelyje? (3) Evoliucinis programų sistemos gyvavimo ciklo modelis grindžiamas evoliucinio sistemų kūrimo paradigma. Pagrindinė idėja - veikiančių kuriamosios sistemos maketų naudojimas jos dinaminėms savybėms modeliuoti. Maketu vadinamas veikiantis programų sistemos modelis, naudojamas sistemos reikalavimams patikslinti arba jos prognozuojamai elgsenai tirti. Modelis gali būti nepilnas funkciniu požiūriu, bet pri­valo adekvačiai modeliuoti ttiriamus sistemos aspektus. Motyvacija: 1) Sistemos reikalavi­mai negalima suformuluoti iš karto. Jie formuluojami visą sistemos kūrimo laikotarpį. Be to, programų sistema yra dinaminė sistema ir vien statiniais reikalavimais jos elg­senos pilnai aprašyti neįmanoma. 2) Maketas imituoja ir statines, ir dinamines sistemos savybes, todėl su juo eksperimentuojant galima tikslinti visus sistemos reikalavimus. Jį daug lengviau sukonstruoti, modifikuoti ir plėsti negu realią sistemą, nes pakanka sumodeliuoti naudo­tojo interfeisą ir imituoti sistemos dinamiką. 3) Maketus tikslinga naudoti ir projektuo­jant sistemos architektūrą (imituojama sistemos komponentų elgsena ir modeliuojami jų interfeisai) ir šitaip patikrinti di­namines būsimos sistemos modulinės architektūros charakteristikas. Stadijos perkloja viena kitą, iš dalies vykdomos lygiagrečiai. Išsiskiria dvi stadijų, kuriose naudojamas maketavimas, grupės. Poreikių analizė ir reikalavimų formulavimas grupuojami su naudotojo interfeiso maketavimu, sistemos projektavimas, konstravimas ir aprobavimas - su sistemos modulinės architektūros ir jos kom­ponentų maketavimu. 77. Projektavimo metodikos samprata. (3) Į struktūrinio projektavimo metodiką galima žiūrėti kaip į sprendimų priėmimo metodą, nustatantį: 1) kokius projektinius sprendimus reikia priimti, projektuojant programų sistemos modulinę architektūrą, 2) kokia tvarka tuos sprendimus reikia priimti, 3) kuo vadovaujantis juos priimti, Metodika grindžiama konceptualizavimo principu. 78. Koncepcinio projektavimo samprata. Koncepcinio projektavimo tikslai (3) Koncepciniais vadinami tokie PS projektiniai reikalavimai, kuriais neribojant sistemos įgyvendinimo būdų ir kompiuterinių platformų, kuriose ji veiks, nusakomi kūriamosios PS organizavimo bendrieji principai, ribojimai ir realizavimo strategija. Pagrindinis tikslas yra parengti koncepcinę specifikaciją – dokumentą, kuriame formuluojami koncepcinio lygmens projetiniai reikalavimai, kuriais vadovaujantis būtų sukurta PS, tenkinati užsakovo lūkesčius ir būtų lengvai eksploatuojama, tobulinama ir plėtojama. 79. UML: realizavimo diagramos (3) Realizavimo diagramos skirtos detalaus projektavimo rezultatams, pavyzdžiui, programų pradinio kodo struktūrai ar programų vykdymo struktūrai, aprašyti. Yra dvi realizavimo diagramų rūšys:komponentų diagramos (angl. "component diagrams"), skirtos programų kodo struktūrai aprašyti,konfigūracijos diagramos (angl. "deployment diagrams"), skirtos programas vykdančios kompiuterinės sistemos konfigūracijai aprašyti.Komponentų diagramose parodomos programinės įrangos komponentų (pradinio kodo, dvejetainio kodo, vykdomojo kodo ir pan.; "komponentas" čia vartojamas ne kaip terminas, o tiesiog kaip žodis) priklausomybės. Kai kurie komponentai egzistuoja tik kompiliavimo metu, kai kurie - tik sukompiliuotų programų redagavimo metu, kai kurie - tik programų vykdymo metu, o kai kurie - keliose fazėse. Komponentų diagramoms sudaryti naudojamos dvi pagrindinės konstrukcijos: komponentas ir komponentų priklausomybė. Galima taip pat parodyti komponentų agregavimą ir pavaizduoti jų interfeisus bei jungtis (pavyzdžiui, call jungtis) Realizavimo diagramos Komponentams vaizduoti numatytas specialus grafinis ženklas. Komponentų priklausomybės vaizduojamos punktyrinėmis strėlėmis. Prie strėlės nurodoma priklausomybės rūšis. Kadangi rūšys priklauso nuo konkrečios programavimo sistemos ypatumų, jos nestandartizuotos. Konfigūracijos diagramomis aprašomi programų vykdyme dalyvaujantys techninės ir programinės įrangos komponentai, procesai bei objektai. Kompiuterinio tinklo mazgai vaizduojami "dėžutėmis". Jų viduje parodomi komponentai ir objektai. Komponentų viduje gali būti parodyti žemesnio lygmens komponentai ir objektai. Koks komponentas kokiame kompiuterių tinklo mazge veikia galima taip pat parodyti «supports» rūšies priklausomybe. Komponentų migravimas iš vieno mazgo į kitą parodomas «becomes» rūšies priklausomybe. Komponentų struktūrą taip pat galima aprašyti ne tik pavaizduojant vienus komponentus kitų komponentų viduje, bet ir agregavimo ryšiais. "Dėžutėmis" vaizduojami ne tik kompiuterių tinklo mazgai, bet ir visi kiti fiziniai objektai, pavyzdžiui, programų sistemos vykdyme dalyvaujantys žmonės. Galima pavaizduoti ne tik konkretų objektą, bet ir jų klasę. 80. Projektavimo paradigmos. Redukcionizmo ir ekspansionizmo esmė (3) Projektavimo paradigmos Projektavimo teorija skiria dvi projektavimo paradigmas - redukcionizmą ir ekspansionizmą. Redukcionizmo šalininkai teigia, kad sistemą galima suskaidyti į pakankamai paprastas, tarpusavyje nepriklausomas dalis, suprojektuoti kiekvieną dalį atskirai ir, sujungus dalių projektus į vieną visumą, gauti visos sistemos projektą. Ekspansionizmo šalininkai mano, kad visų pirma reikia projektuoti sistemos dalis jungiantį konstrukcijos santykį ir tų dalių sąveiką. Tik suprojektavus sistemą kaip visumą, galima leistis žemyn ir projektuoti jos atskiras dalis, traktuojant jas kaip naujas žemesnio lygmens sistemas. Galų gale gaunami baziniai elementai, kurių jau nebereikia projektuoti, nes jie arba jau yra sukurti, arba yra tokie paprasti, kad ir nėra prasmės, ir nebeįmanoma juos toliau skaidyti. Redukcionizmas ir ekspansionizmas - tai konkrečios analitinio ir sintetinio požiūrių apraiškos arba, bendriau, konkrečios induktyviojo ir deduktyviojo samprotavimo būdų apraiškos. Naudojant indukciją, einama nuo atskirybių prie bendrybių, šios konstruojamos apibendrinant konkrečias jų apraiškas. Naudojant dedukciją, atvirkščiai, konkretybės yra gaunamos iš bendrybių vadovaujantis tam tikromis iš anksto žinomomis taisyklėmis. Programų sistemų inžinerijoje šie požiūriai konkretizuojami sistemų kūrimo iš apačios aukštyn ir sistemų kūrimo iš viršaus žemyn paradigmomis. Redukcionizmas ir ekspansionizmas neturi būti priešpastatomi vienas kitam. Gerame projektavimo metode jie derinami tarpusavyje, vienas kitą papildo. "Visuma yra daugiau nei atskirų dalių suma. Dalis yra daugiau nei visumos atplaiša" - teigia dar Aristotelio suformuluotas kompozicijos dėsnis. Izoliuotas atskirų sistemos posistemių tobulinimas, neatsižvelgiant į tų posistemių vaidmenį sistemoje, - dažna projektavimo klaida. Šitaip "tobulinant" sistemą, ji gali tapti dar prastesnė 81. Projektinių sprendimų priėmimo strategijos (3) Strategijų tipai Projektuojant programų sistemą, tenka priimti daug ir įvairių projektinių sprendimų. Inžinerinė veikla nuo amato skiriasi tuo, kad inžinierius vadovaujasi kokia nors projektavimo metodika, išreikštiniu būdu nustatančia, kokius projektinius sprendimus ir kokia tvarka reikia priimti. Tačiau projektinius sprendimus taip pat galima priimti įvairiai. Žinomos kelios projektinių sprendimų priėmimo strategijos. Svarbiausios iš jų yra: tradicinė, sisteminė. Tradicinė strategija Tradicinė projektavimo strategija numato šitokią projektinio sprendimo priėmimo tvarką: surinkti problemą apibūdinančius duomenis, suformuluoti sprendžiamą problemą išreikštiniu būdu, suformuluoti perspektyvius problemos sprendimo variantus, parinkti vieną iš variantų, jį detalizuoti. Naudojant šią strategiją, pagrindinis dėmesys skiriamas duomenims rinkti, sisteminti ir analizuoti. Stengiamasi atmesti aiškiai nepe­rspektyvius priimamo projektinio sprendimo variantus ir sumažinti detaliai analizuojamų alternatyvų skaičių. Problema formuluojama remiantis surinktais duomenimis ir ignoruojant jos kontekstą. Tai pagrindinis šios strategijos trūkumas, nes, neįvertinus priimamo sprendimo svarbos visai sistemai, galima prarasti daug laiko antraeilėms problemoms spręsti ir per mažai laiko skirti esminiams sprendimams priimti. Sisteminė strategija Sisteminė projektavimo strategija numato šitokią projektinio sprendimo priėmimo tvarką: sudaryti projektavimo tikslų hierarchiją, nustatyti, kokios problemos trukdo įgyvendinti kiekvieną iš tikslų, pasirinkti vieną iš problemų, ją suformuluoti, nustatyti, kokia tikslo, siekiamo sprendžiant tą problemą, svarba projektui ir kokia problemos sprendimo svarba siekiamo tikslo požiūriu, suformuluoti perspektyvius problemos sprendimo variantus, parinkti vieną iš variantų, jį detalizuoti. Pagrindinis dėmesys skiriamas projektavimo tikslams analizuoti. Tai leidžia projektuotojui geriau suvokti jo priimamų sprendimų svarbą, negaišti laiko antraeilėms problemoms spręsti ir daugiau dėmesio skirti esminiams sprendimams priimti. 82. Projektuotojų tipai. Trumpai apibūdinkite juos. (3) 83. Kuo skiriasi projektavimo strategijos, projektavimo procedūros ir projektavimo euristikos? (3) Sistemos skaidymo į procesus strategija, architektūros stiliaus parinkimo strategija ir klasių protokolų projektavimo strategija Skaidymo į procesus strategija naudojama atliekant PS koncepcinį projektavimą. Tikslas – nustatyti kurie objektai turi būti aktyvūs vienu metu ir kurie negali. Jei programa buvo suskaidyta į posistemius, tai strategiją galima naudoti, kad nustatyti kurie posistemiai turi veikti lygiegrečiai arba pseudolygiagrečiai. Strategiją sudaro 2 projektavimo procedūros: lygiagrečių valdymo srautų projektavmas ir jų realizavimo būdo nustatymas. Architektūros stilių parinkti siūloma analizuojant tarp posistemių tekančius duomenų srautus. Jei posistemius jungiantys srautai yra „žvaigždės“ pavidalo, patartina sistemą realizuoti kaip valdymo srautų stiliaus arch. Klasių protokokus siūloma projektuoti vadovaujantis 5 projektavimo euristikomis: 1) numatyti tik tokias operacijas, kurias galima apibūdinti vienu žodžiu; 2) su kiekvienu metodu susieti 1 ir tik 1 operaciją; 3) jei kelios klasės vykdo tuos pačius kontraktinius įsipareigojimus, jos turi paveldėti tam reikalingus resursus iš tos pačios bendresnės klasės; 4) protokolai turi būti pakankamai bendri, pritaikyti kuo didesniam klientų skaičiui; 5) leisti nutylėti kuo daugiau parametrų. Struktūrinio projektavimo metodikos komponenetai: architektūros stilius Vienareikšmiškai pasakyti, kokio architektūros stiliaus programų sistemas galima projektuoti, naudojant struktūrinio projektavimo metodus, yra gana sunku. Struktūrinio projektavimo metodika nevienalytė ir skirtingi jos komponentai turi skirtingas galimybes. Šiuo požiūriu svarbiausi komponenetai yra projektavimo kalba ir projektavimo strategijos. Naudojant struktūrinio projektavimo metodiką, modulinė architektūra, duomenų architektūra ir interfeiso architektūra aprašomos sirtingomis projektvimo kalbomis. Modulinėms architektūroms aprašyti sukurta spec. grafinė kalba – struktūrogramų kalba. Kaip aprašyti duomenų ir iterfeisų architektūras, metodika nereglamentuoja. Struktūrogramų kalba galima aprašyti gan platų modulių bei modilinių jungčių spektrą, ji gerai pritaikyta hierarchinėms architektūroms aprašyti, bet ji neturi spec. priemonių objektams, sluoksniams ar duomenų srautams aprašyti. Taip pat negalima išsamiai specifimuoti modulių interfeisų. Klasikinės struktūrinio projektavimo metodikos strategijos pritaikytos hierarchinėms architektūroms, tiksliau reaktyviosioms ir transformuojančioms konstrukcijoms projektuoti. Bendruoju atveju reaktyvioji konstrukcija atlieka šiuos veiksmus: 1) įveda transakciją, 2) analizuoja transakciją ir ją atpažįsta, 3) maršrutizuoja transakciją, 4) ją apdoroja ir arba keičia duomenis kokioje nors duombazėje, arba pateikia transakcijos apdorojimo rezultatus kokiam nors išoriniam agentui. Esminis reaktyviosios konstrucijos privalumas, kad joje sintaksinis apdorojimas griežtai atskirtas nuo semantinio. Konstrukcija turi duomenų įvesties šaką, kurioje abstrahuojamasi nuo transakcijos duomenų pateikties pavidalo. Prasminis apdorojimas atliekamas nepriklausomai nuo to, kaip duomenys buvo pateikti. Projektuojant konkrečią programų sistemą, dažniausiai vienos jos dalys yra projektuojamos kaip transformuojančios, kitos – kaip reaktyviosios konstrucijos. 84. Kokiais svarbiausias atributais aprašoma programų sistemos architektūra? (3) Visiško konsensuso kaip traktuoti architektūrą kol kas nėra. Manoma, kad visiško konsensuso pasiekti apskritai nepavyks ir kad jis netgi būtų nepageidautinas. Vienok šiuo metu visuotinai pritarta nuomonei, kad architektūrà galima traktuoti dvejopai: arba kaip pirmosiomis projektavimo stadijose (during high-level design) vykstantį procesą, arba kaip tuo procesu kuriamą artifaktą. Abiem atvejais architektūra apibūdinama šiais atributais: skaičiuojamieji (funkciniai), duomenų ir kiti konstrukciniai elementai. konstrukcinius elementus jungiančios jungtys (duomenø ir valdymo srautai, funkcijų kvietimas, reikalavimai atlikti operacijas ir pan.) ribojimai (komponentø sąveikos protokolai, matomu-mas, sinchronizacija ir kt.) topologinë struktûra ("forma") suformuota jungiant konstrukcinius elementus jungtimis 85. Kas vadinama programų sistemos architektūros stiliumi? (3) PS architektūros stiliumi vad. ketvertas archST = , kur  - leistini PS dalių tipai (struktūriniai primityvai),  – leistini sistemos jungčių tipai (primityvieji konstruktoriai), w – leistini konstrukcijos santykiai (aukštesnės eilės konstruktoriai),  – sistemos veikimo semantiką nusakantys ribojimai. Architekturos stilius, kaip metodikos vertinimos aspektas, leidžia nustatyti, kokios architektūros PS galima suprojektuoti vertinamos metodikos priemonėmis. Konkrecios PS stilius paprastai būna mišrus. Dažniausiai naudojamos stilių hierarhijos. Geriausiai išnagrinėti stiliai yra valdymo srautų (atliekant užduotis, operacijos vykdomos viena po kitos valdymo srauto nustatyta tvarka), duomenų srautų (atliekant užduotis, operacijų vykdymo tvarką nustato duomenų srautai ir operacijos vykdomos tuomet, kai srautu ateina joms įvykdyti reikalingi duomenys), objektinio (jei: 1: sistema sukonstruota iš objektais vadinamų struktūrinių primityvų, teikiančių jų interfeisų specifikacijomis nustatytas paslaugas, interfeisais slepiančių juos projektuojant ir konstruojant priimtus sprendimus ir palaikančių savo vidinę darną. 2: sistemai konstruoti naudotos vienintelės jungtys – reikalavimai atlikti operacijas), įvykiais valdomo (jei: 1: sistema sukonstruota iš struktūrinių primityvų, vykdomų įvykus tam tikram iš anksto numatytam įvykių rinkiniui ir pranešančių, kokie įvykiai įvyksta vykdant juos pačius. 2: sistemai konstruoti naudotos vienintelės jungtys – įvykių ir struktūrinių primityvų sasajos), sluoksninio, lentelėmis valdomo, saugyklos, pandemoniumo. 86. Kas vadinama konstrukcijos patikslinimu? (3) Konstrukcijos visada siejamos su architektūros stiliumi. Taip vadinamos tame stiliuje leistinų struktūrinių primityvų kompozicijos, sudarytos panaudojus ne tik primityviuosius, bet ir aukštesnės eilės konstruktorius. Dažnai naudojamos konstrukcijos vad. tipinėmis. Tipinės konstr. katalogizuojamos ir naud. specifinėms dalykinėms arch. ir konkrečių PS architektūroms projekuoti. Konkrečiai PS tipinės konstr. taikomos atliekant su jomis 3 oper. – tas konstr. konkretizuojant, tikslinant ir plečiant. 87. Kas vadinama konstrukcijos plėtiniu? (3) Primityviaja architektūros stiliaus ArchST =

Daugiau informacijos...

Šį darbą sudaro 17932 žodžiai, tikrai rasi tai, ko ieškai!

★ Klientai rekomenduoja


Šį rašto darbą rekomenduoja mūsų klientai. Ką tai reiškia?

Mūsų svetainėje pateikiama dešimtys tūkstančių skirtingų rašto darbų, kuriuos įkėlė daugybė moksleivių ir studentų su skirtingais gabumais. Būtent šis rašto darbas yra patikrintas specialistų ir rekomenduojamas kitų klientų, kurie po atsisiuntimo įvertino šį mokslo darbą teigiamai. Todėl galite būti tikri, kad šis pasirinkimas geriausias!

Detali informacija
Darbo tipas
Lygis
Universitetinis
Failo tipas
Word failas (.doc)
Apimtis
43 psl., (17932 ž.)
Darbo duomenys
  • Programų konspektas
  • 43 psl., (17932 ž.)
  • Word failas 858 KB
  • Lygis: Universitetinis
www.nemoku.lt Atsisiųsti šį konspektą
Privalumai
Pakeitimo garantija Darbo pakeitimo garantija

Atsisiuntei rašto darbą ir neradai jame reikalingos informacijos? Pakeisime jį kitu nemokamai.

Sutaupyk 25% pirkdamas daugiau Gauk 25% nuolaidą

Pirkdamas daugiau nei vieną darbą, nuo sekančių darbų gausi 25% nuolaidą.

Greitas aptarnavimas Greitas aptarnavimas

Išsirink norimus rašto darbus ir gauk juos akimirksniu po sėkmingo apmokėjimo!

Atsiliepimai
www.nemoku.lt
Dainius Studentas
Naudojuosi nuo pirmo kurso ir visad randu tai, ko reikia. O ypač smagu, kad įdėjęs darbą gaunu bet kurį nemokamai. Geras puslapis.
www.nemoku.lt
Aurimas Studentas
Puiki svetainė, refleksija pilnai pateisino visus lūkesčius.
www.nemoku.lt
Greta Moksleivė
Pirkau rašto darbą, viskas gerai.
www.nemoku.lt
Skaistė Studentė
Užmačiau šią svetainę kursiokės kompiuteryje. :D Ką galiu pasakyti, iš kitur ir nebesisiunčiu, kai čia yra viskas ko reikia.
Palaukite! Šį darbą galite atsisiųsti visiškai NEMOKAMAI! Įkelkite bet kokį savo turimą mokslo darbą ir už kiekvieną įkeltą darbą būsite apdovanoti - gausite dovanų kodus, skirtus nemokamai parsisiųsti jums reikalingus rašto darbus.
Vilkti dokumentus čia:

.doc, .docx, .pdf, .ppt, .pptx, .odt