1. Kokie yra svarbiausieji inžinerijos ir amato skirtumai?(3) Programų sistemų inžinerija – teorinis pramoninio programavimo pagrindas. Tai inžinerinė disciplina, įgalinanti kurti programų sistemas, tenkinančias iš anksto nustatytus apribojimus. Kaip ir kiekviena inžinerinė disciplina, ji skiriasi nuo amato tuo, kad nusako, kokia tvarka, kuo remiantis ir kokius sprendimus reikia priimti projektuojant ir konstruojant programų sistemas.Amatas: 1)Gaminio kokybę lemia amatininko talentas, patirtis ir sąžiningumas. 2) Kurdamas gaminį, amatininkas sprendimus priima intuityviai. Jis paprastai nežino, kokia tvarka, kuo remiantis ir kokie sprendimai buvo priimti. 3) Amato mokomasi dirbant su patyrusiu meistru, žiūrint kaip jis dirba, vykdant jo užduotis, gaunant patarimus ir pamokymus (pameistrių institutas).Inžinerija: 1) Gaminio kokybė ir kiti ribojimai nustatomi, remiantis ekonominio tikslingumo kriterijais. Jie fiksuojami reikalavimų specifikacija ir sandoriu (kontraktu). 2) Kokia tvarka, kuo remiantis ir kokius sprendimus reikia priimti nustato atitinkama inžinerinė disciplina. 3) Inžinerinę discipliną galima aprašyti, todėl ją galima studijuoti skaitant atitinkamą literatūrą. Tačiau vien teorinių žinių inžinieriui nepakanka. Jam reikia taip pat ir praktinių įgūdžių, kuriuos galima įgyti tik kartu su “patyrusio meistru” atliekant praktines užduotis.Dirbant amatininkiškais metodais, produkto kokybė dažniausiai yra užsakovo norų ir realių produktą kuriančio kolektyvo galimybių kompromiso rezultatas. Taikant inžinerinius metodus(produktą gaminant pramoniniu būdu), kokybė planuojama, atsižvelgiant į ekonominio tikslingumo kriterijus.Baigdami pastebėsime, kad programų sistemų inžinerija – tai naujo tipo inžinerinė disciplina, atsiradusi jungiant technikos, matematikos ir socialinių mokslų pasiekimus.2. Kas vadinama „programavimo krize“? Kokios yra jos apraiškos? Trumpai jas apibūdinkite. (5) Programavimo krizė – tai aklavietė, kurioje atsiduria programavimas dėl tam tikrų priežasčių: uždavinių algoritmizavimo, naujų kompiuterių resursų, galimybių išnaudojimo.Programavimo krizė pasireiškia trim pagrindiniais aspektais: 1) augančiomis sąnaudomis programų sistemoms kurti ir prižiūrėti; 2) nuolatiniu planuotų terminų žlugdymu; 3) naudotojų reiškiamu nepasitenkinimu gaunamos programinės įrangos kokybe.1)Programinės įrangos tiražavimo, diegimo, modernizavimo bei priežiūros sąnaudos pradeda gerokai viršyti kūrimo sąnaudas. Valstybės mastu tai didžiulės sumos, didėjančios kartu su skaičiavimo technikos naudojimo sferos plėtote. Priežasčių, lemiančių tokią padėtį, yra daug. Svarbiausios – standartizacijos stoka, žemas programavimo darbų automatizavimo laipsnis, nekokybiška projektinė dokumentacija ir netinkamas projekto vykdymas.2)Programinis projektas nebaigiamas laiku: vėluoja eksploatavimo dokumentacija; daug laiko praeina nuo sistemos sukūrimo iki jos įdiegimo. Būna ir taip, kad sistema pasensta anksčiau negu ji baigiama. Šiuos trūkumus taip pat lemia blogas planavimas, žemas darbo našumas, naudojamų technologijų neefektyvumas ir netikę darbo organizavimo būdai.3)Sistemos yra visai ne tokios, kokiomis naudotojai jas įsivaizduoja. Jei sistema ir daro beveik tą, ką turi daryti, tačiau dirba visai ne taip, kaip tikimasi. Pvz.: automatizuojant vieną ar kitą veiklos sritį, ji dažniausiai iškelia naudotojams nelauktų problemų, tokių kaip, duomenų paruošimas ir analizė, mažas patikimumas, sąveikos sudėtingumas, modernizavimo sunkumai ir kt.3. Kokie yra svarbiausi pramoninio programavimo ypatumai? Trumpai apibūdinkite juos. (5) Kuriant sistemas pramoniniu būdu, turi būti užtikrinta, kad sistemos bus pateikiamos naudotojams laiku, nebus viršijamas skirtas biudžetas, bus garantuota sukurtos sistemos kokybė ir tenkinama daug kitų reikalavimų. Be to, šiam tikslui naudojamos priemonės turi būti pritaikytos kolektyvinio pobūdžio darbui. Taip pat reikia atsižvelgti į tai, kad kolektyvuose, kuriančiuose programų sistemas, tenka bendradarbiauti skirtingo profilio specialistams.Programuotojų darbo našumas: Programavimo automatizavimo priemonės (transliatoriai, redaktoriai ir pan.) pradėtos kurti dar šeštajame dešimtmetyje, tačiau jos palengvino tik programų rašymą, o tai tik penktadalis ar net dešimtadalis visos darbų apimties. Programavimo metodika, technologija bei darbų organizavimas pradėti tobulinti aštunto dešimtmečio pradžioje, bet tai leido amatininkiškus darbo metodus pakeisti tik manufaktūriniais, bet ne pramoniniais. Projektavimo, dokumentavimo ir daugelį kitų darbų rimtai pradėti automatizuoti tik aštuntojo dešimtmečio pabaigoje. Sukaupta instrumentinių priemonių kūrimo patirtis pirma kartą buvo apibendrinta viename iš JAV gynybos ministerijos projektų. Jame, be plačiai žinomos programavimo kalbos ADA ir jos transliatorių, į bendrą sistemą buvo sujungta dar virš šimto įvairių instrumentinių priemonių. Instrumentinių sistemų srityje Pentagonas ir NASA tebepirmauja po šiai dienai. Masiškai automatizavimo priemones buvo pradėta naudoti tik devintojo dešimtmečio viduryje, kuomet masiškai pradėta naudoti personalinius kompiuterius.Serijinė gamyba: Taikomųjų programų paketai: Pereiti prie programų serijinio gamybos būdo įgalino taikomųjų programų paketai. Paketų koncepcija buvo suformuluota apie 1966 metus, tačiau iki reikiamo lygmens buvo ištobulinta tik atsiradus personaliniams kompiuteriams ir susiformavus pakankamai didelei rinkai.. Užsakymas ir rinka: Tiražuoti daugeliu egzempliorių tikslinga tik sistemas, tenkinančias didelės naudotojų klasės poreikius. Todėl tenka atsisakyti pagal individualius užsakymus atliekamo unikalių sistemų kūrimo ir persiorientuoti į abstraktaus, statistinio naudotojo poreikius. Tokių poreikių nustatymas reikalauja gilaus rinkos tyrimo. Šitaip suformuluoti programų sistemos reikalavimus žymiai sudėtingiau negu dirbant su konkrečiu užsakovu. Dirbant rinkai negalima išsiversti ir be kokybės planavimo.Serijinės gamybos privalumai: Tiražavimo išlaidos yra daug mažesnės negu naujos sistemos kūrimo, tad serijinė gamyba atpigina programinės įrangos kainą. Be to, tai teigiamai veikia standartizacijos procesus, nes kai kurios sistemos paplinta taip plačiai, kad susiklosto vadinamieji de facto standartai, kurie palaipsniui perauga į de jure standartus.
Kolektyvinis gamybos pobūdis: Dideles programų sistemas kuria dideli kolektyvai. Grupinis darbas nuo individualaus visų pirma skirias tuo, kad tuo pat metu yra vykdomi keli projektai ir kolektyvo nariams tenka specializuotis atskirų užduočių vykdymui (projektavimas, programavimas, testavimas ir kt.). Užduotys perduodamos iš rankų į rankas, todėl kyla standartizavimo, planavimo, kontrolės ir kitos projekto valdymo problemos.Kokybės planavimas ir valdymas: Dirbant pramoninio programavimo metodais kokybė planuojama atsižvelgiant į ekonominio tikslingumo kriterijus. Leistiną klaidų skaičių, programų patikimumą, naudojimo patogumą ir kitus kokybės parametrus nustato standartai, reikalavimų specifikacija, kontraktas bei kiti dokumentai. Tačiau reikia išmokti kokybę ne tik planuoti, bet ir kontroliuoti. Taigi, reikia išmokti ją matuoti. Deja kol kas tą mokama daryti tik iš dalies.Standartai: Kolektyvinis gamybos pobūdis ir darbų automatizavimas neįmanomi be standartizacijos ir kuriamų produktų nuasmeninimo. Be standartizacijos neįmanomas ir programų tiražavimas dideliu mastu . Sistemos ir atskirų jos modulių struktūrą, realizavimo metodus ir apipavidalinimą turi lemti pasirinkti standartai, o ne atskirų programuotojų kvalifikacija ar skonis. Šiandien jau turime gana aukštą standartizacijos lygį. Pradeda dominuoti vadinamosios atvirosios sistemos, sukurti šimtai tarptautinių standartų. Tačiau Lietuvoje jie vis dar yra nepakankamai žinomi ir taikomi praktikoje.Projektų valdymas: Kuriant programų sistemas, prognozuoti darbų apimtį, vertinti gaminio užbaigtumo laipsnį ir organizuoti pastovų darbų ritmą gerokai sunkiau, negu, tarkime, gamyboje, nes programuotojo darbas – tai visų pirma projektuotojo, konstruktoriaus darbas, todėl nustatyti normatyvus bei planuoti lėšas yra sudėtinga. Tačiau konstruktorių biuruose sukaupta panaši (techninių sistemų projektavimo patirtis) ir devintajame dešimtmetyje ją pradėta taikyti programų sistemų kūrimo projektams valdyti. Pasiūlyta keletas programų kūrimo projektų valdymo būdų, paremtų tinklinio planavimo ir valdymo metodais. Dažniausiai jie naudojami didelėse firmose, nes smulkūs kolektyvai yra nepajėgūs sukurti atitinkamą infrastruktūrą. Jiems tai per brangu.Ypatumai: 1) aukštas darbų automatizavimo lygis, 2)serijinė gamyba, 3) kolektyvinis gamybos pobūdis, 4) kokybės planavimas ir valdymas, 5) produkto nuasmeninimas, 6) planingas gamybos pobūdis, 7) griežti teoriniai pagrindai.4. Kokius komponentus reikia sukurti, kuriant programų sistemą? Ką reikia padaryti, kad sukurtų komponentų rinkinys taptų sistema? (1) Programų sistema – tai integruota programų, failų, duomenų bazių ir žinių bazių visuma, skirta tam tikros klasės uždaviniams spręsti arba tam tikriems įrenginiams ar procesams valdyti. Būtina bet kokios programų sistemos sudėtinė dalis – jos naudojimo instrukcijos.5. Kas svarbiau: klaida programoje ar jos naudojimo instrukcijoje? (1) Programų sistemos naudotojui nėra jokio skirtumo ar padaryta klaida pačiose programose, ar programų sistemos dokumentacijoje. Abiem atvejais rezultatas yra tas pats: arba programų sistema apskritai neveikia, arba ji veikia ne taip, kaip numatyta jos reikalavimų specifikacijoje.6. Kokiais aspektais galima nagrinėti programų sistemą, ją kuriant? (1) Kuriant programų sistemas, jas būtina nagrinėti dviem skirtingais požiūriais: išoriniu ir vidiniu. Pirmuoju atveju nagrinėjamos jos vykdomos funkcijos, elgsena ir kitos iš išorės stebimos savybės. Tai – sistemos naudotojų požiūris į sistemą. Antruoju atveju nagrinėjama jos architektūra. Tai – sistemos kūrėjų (projektuotojų, programuotojų ir pan.) požiūris į sistemą.7. Kas nusako išorinę programų sistemos elgseną? Kas nusako vidinę programų sistemos elgseną? (1) Išorinę programų sistemos elgseną nusako jos elgesys pastebimas iš išorės. Vidinę programų sistemos elgseną nusako programų sistemos architektūra.Išorinis aspektas: Nagrinėjamos tos programų sistemos savybės, kurias galima stebėti iš jos išorės: funkcijos, elgsena, interfeisas, patikimumas ir pan. Šitaip į sistemą žiūri jos užsakovai, reikalavimų specifikaciją rengiantys analitikai, naudotojai ir ją aptarnaujantis bei prižiūrintis personalas. Aprašant sistemos išorinį aspektą, ji aprašoma kaip vadinamoji juodoji dėžė.Vidinis aspektas: Nagrinėjamos tos programų sistemos savybės, kurias galima stebėti tik iš jos vidaus: architektūra, architektūros įgyvendinimo būdas, sistemos veikimas ir pan. Šitaip į sistemą žiūri jos projektuotojai, programuotojai ir kiti ją kuriantys asmenys. Aprašant sistemos vidinį aspektą, ji aprašoma kaip vadinamoji perregimoji dėžė. Perregimosios dėžės aprašai (eskizinis projektas, detalusis projektas ir kt.) sudaro programų sistemos projektinę dokumentaciją.8. Kas vadinama programų sistemos architektūra? Koks santykis sieja programų sistemos architektūrą ir jos eskizinį projektą? Kas vadinama eskiziniu programų sistemos projektavimu? Kas vadinama detaliu programų sistemos projektavimu? (1) Programų sistemos architektūra vadinamas jos sudėtinių dalių (konstrukcinių elementų) sujungimo būdas. Programų sistemos architektūros aprašas nusako sistemos konstrukcinius elementus, jų vykdomas funkcijas, sąveikos būdus ir juos siejantį konstrukcijos santykį. Sistemos architektūros aprašas yra vadinamas jos eskiziniu projektu.Eskiziniu projektavimu vadinamas kuriamosios programų sistemos funkcinės, modulinės, duomenų ir interfeiso architektūros projektavimo procesas. Dokumentas, kuriame aprašomi eskizinio projektavimo metu priimti projektiniai sprendimai, pateikiami tų sprendimų motyvacija ir eskizinio projektavimo rezultatai, vadinamas programų sistemos eskiziniu projektu.Detaliuoju programų sistemos projektavimu yra vadinamas architektūrinių programų sistemos komponentų vidinės struktūros ir logikos (veikimo algoritmų) projektavimas. Dokumentas, kuriame aprašomi projektiniai sprendimai, priimti detalaus projektavimo metu, pateikiami tų sprendimų motyvacija ir detaliojo projektavimo rezultatai, vadinamas detaliuoju programų sistemos projektu.9. Kas vadinama programų sistemos dalykine ir kas problemine sritimi? (1) Programų sistemos taikymo sritis vadinama dalykine sritimi. Šiuolaikines programų sistemos dažniausiai taip kuriamos, kad jomis galėtų be tarpininku naudotis dalykines srities specialistai. Tokios sistemos vadinamos specialios arba dalykines paskirties sistemomis. Dalykines paskirties sistemos turi sudaryti naudotojams sąlygas formuluoti užduotis vartojant įprastus jų profesines veiklos terminus, nutylint neesmines detales ir galbūt remiantis negriežtoms ir nevienareikšmėmis formuluotėmis. Tokius reikalavimus tenkinančios programų sistemos vadinamos intelektualizuotomis. Jų architektūra būna labai sudėtinga ir be PSI metodų tokias sistemas sukurti praktiškai neįmanoma.Programų sistemos taikymo sritis – dalykinė sritis.Programų sistemos problemine sritimi(angl. Problem domain) vadinama jos sprendžiamų uždavinių visuma.10. Kas vadinama programų sistemų inžinerija? (1) Mokslinis aspektas: Kaip inžinerijos mokslo šaka, programų sistemų inžinerija nagrinėja, kaip apskritai reikia spręsti įvairias programų sistemų kūrimo, aptarnavimo bei priežiūros problemas ir kokių priemonių (instrumentų) tam reikia.Praktinis aspektas: Kaip praktinės inžinerijos šaka, programų sistemų inžinerija naudojama konkrečioms programų sistemoms kurti, aptarnauti bei prižiūrėti.Programų sistemų inžinerijos apibrėžtis: Programų sistemų inžinerija vadinama sistemų inžinerijos šaka, nagrinėjanti pramoninio programų sistemų kūrimo priemones (metodus, instrumentus, kalbas, procedūras) bei veiksmingus jų naudojimo būdus.Programų sistemų inžinerija – tai naujo tipo inžinerinė disciplina, atsiradusi jungiant technikos, matematikos ir socialinių mokslų pasiekimus. Programų sistemų inžinerija – teorinis pramoninio programavimo pagrindas.11. Kokios yra programų sistemų inžinerijos pagrindinės dalys?(1) Pagrindinės programų sistemos inžinerijos dalys yra šios: 1) reikalavimų inžinerija, 2) programų inžinerija, 3) interfeiso inžinerija, 4) duomenų bazių inžinerija, 5) žinių inžinerija, 6) programų sistemų architektūra, 7) programų sistemų kūrimo projektų valdymas, 8) programų sistemų kokybės vertinimas ir valdymas, 9) instrumentinių sistemų teorija, 10) programų sistemų diegimas ir priežiūra.12. Ką nagrinėja reikalavimų inžinerija? Kokios yra jos pagrindinės dalys? (1) Reikalavimų inžinerija nagrinėja, kaip turi būti rengiami ir pateikiami funkciniai, kokybės ir kiti kuriamos sistemos reikalavimai. Pagrindinės reikalavimų inžinerijos dalys yra dalykinės srities sisteminė analizė, koncepcinis modeliavimas ir reikalavimų analizė.Pastebėsime, kad sisteminė analizė ir sistemų analizė yra skirtingi dalykai ir jų nevalia painioti. Pirmuoju atveju kalbama apie analizės metodą, o antruoju – apie jos objektą.Dalykinės srities sisteminė analizė yra specifinė bendrosios sisteminės analizės rūšis. Bendroji sisteminė analizė nagrinėja, kaip taikyti sisteminį požiūrį analizuojant bet kokios prigimties reiškinius. Tai labai bendra mokslo šaka. Dalykinės srities sisteminė analizė nagrinėja metodus, instrumentus bei kitas priemones dalykinės srities analizei atlikti. Šias priemones įvaldęs specialistas vadinamas sisteminiu analitiku.Dalykinės srities sisteminė analizė atliekama siekiant ištirti dalykinės srities specialistų poreikius ir suformuluoti kuriamos sistemos reikalavimus. Analizės rezultatai fiksuojami vadinamojoje reikalavimų specifikacijoje. Reikalavimų specifikacija vadinamas dokumentas, kuriame išsamiai aprašoma, kokioms užduotims vykdyti yra skirta kuriamoji sistema ir kokios turi būti kitos jos pageidaujamos savybės.Koncepcinis modeliavimas nagrinėja dalykinės srities koncepcinio modeliavimo metodus ir priemones. Dalykinės srities koncepcinis modelis sudaromas rengiant specifikaciją. Modeliams aprašyti naudojamos specialiai tam tikslui skirtos kalbos, vadinamos koncepcinio modeliavimo kalbomis. Dalykinės srities koncepciniai modeliai naudojami sisteminiams analitikams, užsakovams ir sistemos projektuotojams tarpusavyje aptariant kompiuterizuojamos dalykinės srities ypatumus ir yra konstruojami taip, kad juos pagal tam tikras taisykles būtų galima transformuoti į kuriamų sistemų koncepcinius modelius. Būtent tuo koncepciniai modeliai, nagrinėjami reikalavimų inžinerijoje, skiriasi nuo koncepcinių modelių, nagrinėjamų dirbtinio intelekto teorijoje.Norint transformuoti dalykinės srities koncepcinį modelį į kuriamos programų sistemos koncepcinį modelį ir parengti tos sistemos specifikaciją, reikia išnagrinėti tos sistemos reikalavimus. Tai – reikalavimų analizės objektas. Kartais reikalavimų analizė dar yra vadinama sistemos analize.13. Kas tai yra sistemų analizė? Ką ji nagrinėja? Koks pagrindinis sistemų analizės tikslas? (1) Sistemų analizė – tai sistemos skaidymo į sudėtines dalis procesas, vykdomas siekiant suvokti analizuojamosios sistemos savybes.Analizės samprata universali. Tačiau kiekviena sistemų klasė paprastai turi tam tikrų tik jai būdingų ypatumų, todėl jos analizės metodai taip pat yra specifiniai. Programų sistemų inžinerijoje nagrinėjami dalykinių sričių ir programų sistemų analizės metodai.Dalykinės srities sisteminė analizė yra specifinė bendrosios sisteminės analizės rūšis. Bendroji sisteminė analizė nagrinėja, kaip taikyti sisteminį požiūrį analizuojant bet kokios prigimties reiškinius. Tai labai bendra mokslo šaka. Dalykinės srities sisteminė analizė nagrinėja metodus, instrumentus bei kitas priemones dalykinės srities analizei atlikti. Šias priemones įvaldęs specialistas vadinamas sisteminiu analitiku.Dalykinės srities sisteminė analizė atliekama siekiant ištirti dalykinės srities specialistų poreikius ir suformuluoti kuriamos sistemos reikalavimus. Analizės rezultatai fiksuojami vadinamojoje reikalavimų specifikacijoje. Reikalavimų specifikacija vadinamas dokumentas, kuriame išsamiai aprašoma, kokioms užduotims vykdyti yra skirta kuriamoji sistema ir kokios turi būti kitos jos pageidaujamos savybės.Pastebėsime, kad sisteminė analizė ir sistemų analizė yra skirtingi dalykai ir jų nevalia painioti. Pirmuoju atveju kalbama apie analizės metodą, o antruoju – apie jos objektą.Apie sisteminę analizę trumpai (plačiau 12 klausime): dalykinės srities sisteminė analizė nagrinėja metodus, instrumentus dalykinės srities analizei atlikti. Dalykinės srities sisteminė analizė atliekama, siekiant ištirti dalykinės srities specialistų poreikius ir suformuluoti kuriamos programų sistemos reikalavimus.14. Kaip vadinamas dokumentas, aprašantis kuriamos programų sistemos paskirtį ir jos pageidaujamas savybes? (1) Reikalavimų specifikacija.Ikiprojektiniai tyrimai atliekami dalykinės srities analizės metu. Priklausomai nuo to, kokie dokumentavimo standartai yra naudojami, jų rezultatai gali būti pateikti viename ar keliuose dokumentuose. Lietuvoje ikiprojektinių tyrimų rezultatai dažniausiai yra aprašomi specialiai tam skirtuose dokumento, vadinamo technine užduotimi sistemai sukurti, skyriuose.15. Kuo skiriasi koncepciniai modeliai, nagrinėjami programų sistemų inžinerijoje, nuo koncepcinių modelių, nagrinėjamų dirbtinio intelekto teorijoje? Kam programų sistemų inžinerijoje naudojamas koncepcinis modeliavimas? (1) Koncepcinis modeliavimas nagrinėja dalykinės srities koncepcinio modeliavimo metodus ir priemones. Dalykinės srities koncepcinis modelis sudaromas rengiant specifikaciją. Modeliams aprašyti naudojamos specialiai tam tikslui skirtos kalbos, vadinamos koncepcinio modeliavimo kalbomis. Dalykinės srities koncepciniai modeliai naudojami sisteminiams analitikams, užsakovams ir sistemos projektuotojams tarpusavyje aptariant kompiuterizuojamos dalykinės srities ypatumus ir yra konstruojami taip, kad juos pagal tam tikras taisykles būtų galima transformuoti į kuriamų sistemų koncepcinius modelius. Būtent tuo koncepciniai modeliai, nagrinėjami reikalavimų inžinerijoje, skiriasi nuo koncepcinių modelių, nagrinėjamų dirbtinio intelekto teorijoje.Pagrindinė reikalavimų verifikavimo ir vertinimo problema tai analitikų, užsakovų, naudotojų, dalykinės srities ekspertų ir projektuotojų tarpusavio bendravimas. Gana dažnai užsakovai, naudotojai ir dalykinės srities ekspertai nesupranta šio proceso svarbos ir nenori jame dalyvauti. Be to, labai sunku parengti konkretų, formalų ir kartu visiems suinteresuotiems asmenims lengvai suprantamą dokumentą.Koncepcinis modeliavimas – pirmasis programų sistemos reikalavimų formalizavimo žingsnis. Pagal tradiciją koncepcinis modeliavimas priskiriamas dalykinės srities analizės stadijai, nors jį būtų galima laikyti ir pirmuoju projektavimo stadijos etapu. Taip esti dėl to, kad koncepcinis modelis kartais yra konstruojamas reikalavimams verifikuoti ir vertinti. Vadinasi, griežtos ribos tarp atskirų programų sistemos gyvavimo ciklo stadijų nėra. Kiekvienu konkrečiu atveju jos turi būti konstruojamos iš bazinių technologinių procesų savaip, atsižvelgiant į konkrečius vykdomo projekto ypatumus. Koncepcinis modeliavimas ir yra vienas iš tų bazinių technologinių procesų.16. Kas vadinama programų inžinerija? Kuo programų inžinerija skiriasi nuo programų sistemų inžinerijos? (1) Programų inžinerija nagrinėja programų projektavimo ir konstravimo problemas, instrumentus bei priemones.Svarbiausios projektavimo problemos yra geriausio kuriamos programos reikalavimų įgyvendinimo būdo parinkimas ir dokumentavimas kokia nors specialiai tam skirta programų projektavimo kalba. Svarbiausios programų konstravimo problemos yra tinkamos programavimo kalbos parinkimas, modulių teksto struktūrizavimas ir apipavidalinimas.Programos projektavimas – tai kuriamos programos specifikacijos įgyvendinimo būdo parinkimas ir to būdo modeliavimas specialiai tam skirta kalba (programų projektavimo kalba). Programos įgyvendinimo būdas modeliuojamas specifikuojant jos išorinius ir vidinius interfeisus, valdymo mechanizmus bei kitus programos konstrukcinius elementus. Programos konstravimas – tai jos specifikacijos įgyvendinimas projektavimo metu parinktu būdu. Konstruojant programą, koduojami ir jungiami į vieną visumą jos moduliai. Svarbiausios programų konstravimo problemos yra tinkamos programavimo kalbos parinkimas, modulių teksto struktūrizavimas ir apipavidalinimas bei konstruojamos programos konfigūracijos valdymas.Pagrindiniai objektai, sukuriami procesais, naudojamais kuriant programų sistemas, yra šie: 1) ikiprojektinių tyrimų rezultatai (poreikių specifikacijos, tikslų specifikacijos ir pan.), 2) techniniai sistemos aprašai (specifikacijos, projektinė dokumentacija, kodas, naudojimo instrukcijos ir pan.), 3) sistemos mazgai (moduliai, failai, bazės, posistemės ir pan.), 4) sistemos distributyvinės versijos, 5) funkcionuojančios sistemos, 6) pagalbinė medžiaga (planai, užduotys, ataskaitos, testai, testavimo užduotys, testavimo rezultatai ir pan.).Programų sistemų inžinerija nagrinėja šių objektų struktūrą, jų apipavidalinimo standartus ir kitus panašaus pobūdžio klausimus. Programų inžinerija yra programų sistemos inžinerijos dalis.17. Kokius klausimus nagrinėja duomenų inžinerija? Kokius klausimus nagrinėja žinių inžinerija? (1) Duomenų inžinerija nagrinėja duomenų bazių bei failų sistemų projektavimo problemas. Ši programų sistemų inžinerijos šaka taip pat nagrinėja metodus, instrumentus ir kitas priemones, skirtas duomenų bazėms projektuoti bei konstruoti. Pagrindinės duomenų bazių bei failų sistemų projektavimo problemos yra našumo, patikimumo bei darnos įgyvendinimas ir perteklinių duomenų eliminavimas.Žinių inžinerija nagrinėja žinių bazių projektavimo problemas. Ši programų sistemų inžinerijos šaka taip pat nagrinėja metodus, instrumentus ir kitas priemones, skirtas žinių bazėms projektuoti bei konstruoti. Pagrindinės problemos yra panašios į duomenų inžinerijos problemas. Specifinė problema – kaip išgauti iš ekspertų žinias ir jas panaudoti, apdoroti.18. Kas vadinama projekto valdymu? Kas sudaro kokybės valdymo esmę? (1) Terminas “projektas” programų sistemų inžinerijoje vartojamas dviem prasmėm: pirmoji – tai dokumento, aprašančio projektavimo rezultatus, pavadinimas, antroji -programų sistemos kūrimo proceso pavadinimas. Kai kalbama apie projektų valdymą, omeny turima antroji termino prasmė. Projektų, skirtų programų sistemoms kurti, valdymo metodai ir priemonės yra panašūs į kitų inžinerinių projektų valdymo metodus bei priemones. Pagrindinis jų tikslas – taip struktūrizuoti sistemos kūrimo procesą, kad jis būtų suskaidytas į lengvai kontroliuojamas ir valdomas dalis. Siekiama, kad bet kuriuo laiko momentu būtų galima įvertinti tai, kas jau yra padaryta, nustatyti, ar neatsiliekama nuo numatytų terminų ir ar nėra sunaudota daugiau lėšų, negu buvo numatyta. Pažymėtina, kad kokybės ir konfigūracijos valdymas taip pat yra sudėtinės projekto valdymo dalys.Kokybės valdymo esmę sudaro kokybės standartų parinkimas, tų standartų diegimas ir jų vykdymo kontrolė. Einamoji kuriamosios programų sistemos versija ir jos kūrimo procesas turi būti nuolat kontroliuojami, visi nukrypimai nuo pasirinktųjų standartų turi būti fiksuojami ir nedelsiant šalinami. Kokybei matuoti reikalingos atitinkamos metrikos, matavimo priemonės ir metodai. Svarbiausias programų sistemos kokybės aspektas yra jos patikimumas, t.y. geba veikti nustatytą laiko periodą, nenukrypstant nuo specifikacijoje pateiktų reikalavimų. Pagrindinis programų sistemų kokybės matavimo metodas yra jos testavimas. Taikant inžinerinius metodus(produktą gaminant pramoniniu būdu), kokybė planuojama, atsižvelgiant į ekonominio tikslingumo kriterijus. Deja, kokybę matuoti mokama tik iš dalies, nes programų sistemų inžinerijai – vos kelios dešimtys metų.19. Ką nagrinėja instrumentinių sistemų teorija? (1) Instrumentinių sistemų teorija nagrinėja, kokie instrumentai reikalingi programų sistemų inžinieriams, kaip tokius instrumentus sukurti ir kaip juos jungti į įvairias instrumentines sistemas (programavimo aplinkas, CASE (Computer Aided Software Engineering) sistemas ir kt.).Norint palengvinti programų sistemų kūrimą, tikslinga įvairius kompiuterinius instrumentus (dokumentatorius, projektavimo bazių tvarkymo priemones, kompiliatorius, testavimo priemones ir pan.), naudojamus programoms projektuoti, konstruoti, testuoti bei kitiems darbams atlikti, jungti į vieną instrumentinę sistemą. Instrumentai dažniausiai jungiami pasirinktojo programų sistemos gyvavimo ciklo arba pasirinktojo projektavimo metodo nusakomu būdu. Svarbus tokių sistemų komponentas yra automatinio programavimo sistemos, kartais dar vadinamos programų generatoriais. Automatinio programavimo sistemos yra skirtos kuriamoms programoms generuoti. Programos tokiose sistemose yra generuojamos žingsnis po žingsnio transformuojant kuriamosios sistemos specifikaciją į atitinkamų programų tekstus. Dažniausiai programos yra surenkamos iš anksčiau parengtų modulių arba kitų konstrukcinių elementų. Todėl toks programų konstravimo būdas dar yra vadinamas struktūrine sinteze arba surenkamuoju programavimu. Transformacijos parenkamos taip, kad būtų išsaugotas transformuojamojo objekto korektiškumas. Tai reiškia, kad iš teisingos specifikacijos visuomet bus sugeneruota teisinga programa. Generatorių darbą paprastai valdo projektuotojas. Jei reikia, jis gali patikslinti specifikacijas ir parengti geriausiai tinkančius jų įgyvendinimo būdus.20. Kokie darbai vykdomi, vykdant programų sistemos priežiūrą? Kas vadinama programų sistemos parengimu darbui, aptarnavimu, modernizavimu ir demontavimu? (1) Diegimas ir priežiūra – programų sistemos inžinerijos šaka, nagrinėjanti programų sistemos diegimo ir priežiūros problemas. Programų sistemos prižiūra turi būti vykdoma taip, kad sistema nuolat būtų tinkama naudotis. Kadangi dalykinė sritis dažniausiai nuolat kinta, tai nuolat turi būti keičiama ir eksploatuojama programinė įranga. Todėl naudojamos programinės įrangos modernizavimas yra būtina programų sistemų inžinerijos priežiūros dalis. Priežiūros metu programinė įranga pritaikoma pakitusiems jos naudotojų ir eksploatavimo tarnybų poreikiams, naujai techninei įrangai ir pan. Priežiūros metu taip pat yra tikrinamas programinės įrangos funkcionalumas, šalinami trikiai, keičiama konfigūracija, restruktūrizuojamos duomenų bazės, tvarkomi archyvai ir atliekami kiti panašaus pobūdžio darbai. Tam reikalingi specialūs metodai, instrumentai bei kitos priemonės.Tam, kad sistema būtų parengta darbui, reikia ją instaliuoti, patikrinti kaip ji veikia, suformuoti reikiamas duomenų bazes ir atlikti kitus darbus. Sistemos parengimo darbui procesą nagrinėja programų sistemų inžinerijos šaka, vadinama sistemų diegimu ir priežiūra. Ji taip pat nagrinėja ir sistemos aptarnavimo, modernizavimo bei demontavimo procesus. Šie procesai apibrėžiami šitaip:Sistemos parengimas darbui – tai sistemos veikimui reikalingų resursų akumuliavimo ir jos adaptavimo konkrečiai darbo vietai procesas. Sistemos aptarnavimas – tai specifikacijoje numatytos sistemos elgsenos palaikymo procesas. Sistemos modernizavimas – tai veikiančios sistemos vidinės arba išorinės elgsenos modifikavimo procesas. Sistemos demontavimas – tai laipsniškas vienos veikiančios sistemos funkcijų perdavimo kitai veikiančiai sistemai procesas. Perduodant senos sistemos funkcijas naujai sistemai, kuria ji yra keičiama, senoji sistema palaipsniui demontuojama.21. Kas programų sistemų inžinerijoje vadinama baziniu procesu? Kokie baziniai procesai naudojami programų sistemų inžinerijoje? (1) Baziniais procesais programų sistemų inžinerijoje yra vadinami tokie procesai, be kurių negali būti sukurtos ir panaudotos programų sistemos.Skiriami šie baziniai procesai: 1) analizė, 2) specifikavimas, 3) projektavimas, 4) programavimas, 5) surinkimas, 6) parengimas darbui, 7) aptarnavimas, 8) modernizavimas, 9) demontavimas.22. Kas programų sistemų inžinerijoje vadinama pagalbiniu procesu? Kokie pagalbiniai procesai naudojami programų sistemų inžinerijoje?(1) Pagalbiniais procesais programų sistemų inžinerijoje yra vadinami procesai, skirti bazinių procesų vykdymui palengvinti ir padedantys užtikrinti jų sėkmę.Pagrindiniai pagalbiniai procesai yra šie: 1) testavimas, 2) verifikavimas, 3) vertinimas, 4) dokumentavimas, 5) konfigūracijos valdymas, 6) peržiūra, 7) inspektavimas, 8) problemų sprendimas.23. Kas programų sistemų inžinerijoje vadinama organizaciniu procesu? Kokie organizaciniai procesai naudojami programų sistemų inžinerijoje? (1) Organizaciniais procesais programų sistemų inžinerijoje yra vadinami procesai, skirti organizacinėms struktūroms, kuriančioms programų sistemas, sukurti ir palaikyti.Pagrindiniai organizaciniai procesai yra šie: 1) valdymas, 2) infrastruktūros kūrimas ir palaikymas, 3) procesų vykdymas, 4) apmokymas.Čia šiaip sau: Pagrindinis programų sistemų inžinerijos nagrinėjimų objektas yra baziniai procesai. Nors pagalbiniai ir organizaciniai procesai programų sistemų inžinerijoje irgi yra svarbūs, jie traktuotini kaip kitų mokslo šakų detalaus nagrinėjimo objektas. Programų sistemų inžinerija nagrinėja tik tose mokslo šakose gautų rezultatų panaudojimo specifiką. Kai kuriais atvejais, pavyzdžiui, testavimo, ši specifika gali būti labai svarbi. Kitais gi atvejais, pavyzdžiui, valdymo, ji yra gana nereikšminga.24. Kas vadinama programų sistemos specifikavimu? Kokie yra programų sistemos specifikavimo būdai? (1) Sistemos specifikavimas – tai iš išorės stebimos sistemos elgsenos modeliavimo procesas.Šios apibrėžtys tinka bet kokioms sistemoms, tačiau kiekviena konkreti sistemų klasė dažniausiai turi ir savitų, tik jai būdingų ypatumų. Todėl kiekvienos sistemų klasės analizės ir specifikavimo metodai taip pat yra specifiniai. Programų sistemų inžinerija nagrinėja dalykinių sričių ir programų sistemų analizės bei specifikavimo procesų ypatumus. Programų sistemos gali būti specifikuojamos natūraliosiomis arba specialiai tam skirtomis formaliosiomis kalbomis. Kai kurioms formalioms kalboms yra sudaryti jų interpretatoriai. Tada sakoma, kad mes turime vykdomą specifikaciją. Kartais programų sistemoms specifikuoti yra naudojami jų prototipai arba maketai.25. Kas vadinama programų sistemos projektavimu? Kas tai yra programavimas? (1) Sistemos projektavimas – tai geriausio sistemos specifikacijos įgyvendinimo būdo parinkimo ir to būdo modeliavimo procesas.Ši apibrėžtis visiškai tinka ir programų sistemoms. Būsimos sistemos modelis yra aprašomas specialiai tam skirtomis kalbomis, vadinamomis projektavimo kalbomis. Tai dar vadinama projektinių sprendimų dokumentavimu. Kartais sistemos įgyvendinimo būdui modeliuoti naudojami veikiantys maketai.Programų konstravimas yra suprantamas kaip priimtų projektinių sprendimų aprašymas pasirinktąja programavimo kalba. Programų konstravimą įprasta vadinti programavimu arba kodavimu.Programavimas – tai pasirinktojo procesoriaus vykdomų instrukcijų rinkinio, užtikrinančio specifikacijoje numatytą to procesoriaus veiką, realizuojamą sistemos projekte numatytu būdu, sudarymo procesas.Programų sistemos konstravimo sąvoka yra platesnė negu programavimo. Konstruojant sistemą, yra ne tik sudaromos programos, bet ir kuriamos duomenų bei žinių bazės. Be to, visi konstrukciniai elementai dar turi būti integruoti į vieną visumą taip, kaip tai yra numatyta sistemos architektūroje. Visa tai apima sistemos surinkimo procesas.26. Kas vadinama programų sistemos surinkimu? (1) Sistemos surinkimas – tai sistemos sudėtinių dalių (programų, duomenų bazių ir kitų konstrukcinių elementų) jungimo procesas. Kartais jis dar yra vadinamas sistemos integravimu.Reikia pažymėti, kad kai kuriais atvejais sistema gali būti renkama iš gatavų konstrukcinių elementų, pavyzdžiui, programų paketų. Tokiais atvejais programavimo procesas yra apskritai nereikalingas.Su sistemos surinkimu glaudžiai siejasi konfigūracijos valdymo procesas.27. Kas vadinama programų sistemos konfigūracijos valdymu? (1) Konfigūracijos valdymas – tai procesas, kuriuo siekiama, kad bet kuriuo laiko momentu sistemoje būtų visos jos sudėtinės dalys ir kad tos dalys būtų tarpusavyje suderintos.Pagrindinis konfigūracijos valdymo tikslas sukontroliuoti “kas kur yra”. Tuo tikslu kiekvienas “kas” traktuojamas kaip komponentas ir jam priskiriamas unikalus vardas. Steigiamos komponentų saugyklos ir pradedama jų apskaita.Antrasis tikslas – įvertinti, kokiu mastu yra išbaigtas konkretus gaminys. Tam išskiriamos gaminio gyvavimo stadijos (išbaigtumo būsenos) ir kiekvienai jų rengiami gaminio konfigūracijų aprašai. Kiekviena tokia būsena taip pat turi turėti unikalų vardą.Kadangi komponentai gali kisti, konfigūracijos valdymas turi padėti nepainioti panašių komponentų, t.y. valdyti pokyčius.Šiaip sau: Programų sistemų testavimo, verifikavimo ir vertinimo procesus nagrinėja programų sistemų inžinerijos šaka, vadinama programų sistemų kokybės vertinimu ir valdymu. Su kokybės valdymu glaudžiai yra susiję taip pat ir peržiūros, inspektavimo bei problemų sprendimo procesai.28. Kas vadinama programų sistemos testavimu? Kas vadinama programų sistemos verifikavimu? (1) Sistemos testavimas – tai empirinis sistemos atitikimo jos specifikacijai tikrinimo procesas.Verifikavimas – tai sistemos kūrimo žingsnio korektiškumo tikrinimo procesas.29. Kuo skiriasi programų sistemos vertinimas, peržiūra ir inspektavimas? (1) Sistemos vertinimas – tai procesas, kuriuo siekiama nustatyti, ar sistema, jos projektas arba specifikacija tenkina realius jos naudotojų poreikius.Sistemos peržiūra – tai procesas, kuriuo siekiama patikrinti, ar sistemos kūrimas vyksta pagal numatytą planą, ar gauti visi plane numatyti rezultatai ir, jei to nėra, išsiaiškinti nukrypimų nuo planuotos darbų eigos priežastis.Sistemos inspektavimas – tai procesas, kuriuo siekiama patikrinti, ar kuriant sistemą nenukrypstama nuo numatytų standartų bei specifikacijomis, sutartimis ar kitais dokumentais numatytų reikalavimų.30. Kokie objektai yra kuriami programų sistemos kūrimo eigoje? (1) Pagrindiniai objektai, sukuriami procesais, naudojamais kuriant programų sistemas, yra šie: 1)ikiprojektinių tyrimų rezultatai (poreikių specifikacijos, tikslų specifikacijos ir pan.), 2) techniniai sistemos aprašai (specifikacijos, projektinė dokumentacija, kodas, naudojimo instrukcijos ir pan.), 3) sistemos mazgai (moduliai, failai, bazės, posistemės ir pan.), 4) sistemos distributyvinės versijos, 5) funkcionuojančios sistemos, 6) pagalbinė medžiaga (planai, užduotys, ataskaitos, testai, testavimo užduotys, testavimo rezultatai ir pan.). Programų sistemų inžinerija nagrinėja šių objektų struktūrą, jų apipavidalinimo standartus ir kitus panašaus pobūdžio klausimus.31. Kokios prielaidos yra daromos, taikant programų inžinerijos procesus? (1) Nagrinėjant aukščiau aptartus inžinerinius procesus ir jais kuriamus objektus, programų sistemų inžinerijoje, kaip ir kitose inžinerijos šakose, daromos tam tikros prielaidos apie tai, kaip šie procesai vyksta praktikoje. Tokios prielaidos yra būtinos, nes, neatsižvelgiant į jas, procesai yra idealizuojami ir nebegali būti efektyviai taikomi praktinėje veikloje. Trumpai aptarsime šias prielaidas.1 prielaida: Neįmanoma pašalinti atotrūkio tarp sistemos specifikacijų ir realių naudotojų poreikių.Taip yra dėl dviejų pagrindinių priežasčių. Pirmoji priežastis – tai, kad joks analitikas negali nustatyti visų naudotojų poreikių, nes dažniausiai visų savo poreikių nesuvokia ir patys naudotojai. Antroji priežastis – tai, kad naudotojų poreikiai nuolat kinta. Poreikių pokyčius sąlygoja realaus gyvenimo pokyčiai. Todėl programų sistemų inžinerijoje visuose nagrinėjamuose procesuose stengiamasi atsižvelgti į tai, kad nė viena specifikacija nėra adekvati realiems naudotojų poreikiams.2 prielaida: Neįmanoma išvengti klaidų nė viename iš techninių sistemos aprašų.Atsižvelgiant į šią prielaidą, yra numatomos klaidų paieškos ir šalinimo procedūros bei priemonės.3 prielaida: Neįmanoma visiškai sumodeliuoti sistemos elgsenos trikių metu.4 prielaida: Įmanoma surinkti tik nedidelę dalį duomenų, reikalingų tam, kad būtų galima adekvačiai įvertinti visus programų sistemų inžinerijoje naudojamų procesų eigoje sukuriamus objektus.32. Kuo skiriasi programų sistemų inžinerijos principai ir jos paradigmos? (1) Kaip ir kitose inžinerinėse disciplinose, programų sistemų inžinerijoje yra vadovaujamasi tam tikrais principais ir tam tikromis paradigmomis.Principais programų sistemų inžinerijoje yra vadinamos pačios bendriausios metodinės programų sistemų kūrimo prielaidos.Paradigma programų sistemų inžinerijoje vadinama teorinių ir metodinių prielaidų visuma, nusakanti tam tikrą požiūrį į tai, kaip turi būti kuriama programų sistema.Pastebėsime, kad pagrindiniai principai naudojami visose arba daugelyje paradigmų. Tačiau skirtingose paradigmose jie naudojami skirtingiems tikslams.Šiaip sau: Kaip ir kitose inžinerinėse disciplinose, programų sistemų inžinerijoje yra vadovaujamasi tam tikrais principais ir tam tikromis paradigmomis.Principais programų sistemų inžinerijoje yra vadinamos pačios bendriausios metodinės programų sistemų kūrimo prielaidos.Paradigma programų sistemų inžinerijoje vadinama teorinių ir metodinių prielaidų visuma, nusakanti tam tikrą požiūrį į tai, kaip turi būti kuriama programų sistema.Pastebėsime, kad pagrindiniai principai naudojami visose arba daugelyje paradigmų. Tačiau skirtingose paradigmose jie naudojami skirtingiems tikslams.33. Kokios yra pagrindinės programų sistemų inžinerijos paradigmos? (1) Skiriamos šios pagrindinės programų sistemų inžinerijos paradigmos: 1) sistemų kūrimo iš apačios aukštyn paradigma, 2) sistemų kūrimo iš viršaus žemyn paradigma, 3) riešuto paradigma, 4) formalizuoto sistemų kūrimo paradigma, 5) evoliucinio sistemų kūrimo paradigma, 6) karkaso paradigma.34. Kokia yra sistemų kūrimo iš apačios aukštin(buttom-up development) paradigma? (1) Tai viena iš populiariausių programų sistemų kūrimo paradigmų. Taikant šią paradigmą, pirmiausia parenkama viena ar kita kompiuterinė technologija, o po to sprendžiama, kaip šios technologijos priemonėmis reikia kurti norimą sistemą. Sistemų kūrimo iš apačios aukštyn paradigmos populiarumas yra natūralus, nes naudojama technologija visuomet lemia tai, kokio pobūdžio programų sistemas galima sukurti. Rinkoje pasirodantys naujo tipo produktai dažniausiai yra naujų technologinių pasiekimų pasekmė. Kūrimo iš apačios aukštyn paradigma gana gerai tinka nedidelėms programų sistemoms kurti. Projektuojant didesnius arba sudėtingesnius produktus, šia paradigma naudotis nepatariama, nes dėl iš anksto daromų technologinių prielaidų dažniausiai arba iškraipoma naudotojų turima būsimosios sistemos vizija, arba galutinėje jos versijoje tenka naudoti papildomas priemones, transformuojančias žemo (technologinio) lygmens interfeisus į pavidalą, atitinkantį naudotojų viziją. Pirmuoju atveju sudėtingesnis tampa naudotojų darbas, antruoju – projekto įgyvendinimas.35. Kokia yra sistemų kūrimo iš viršaus žemyn(top-down development) paradigma? (1) Taikant šią paradigmą, pirmiausiai yra projektuojami išoriniai programų sistemos interfeisai ir nustatomi iš išorės stebimos sistemos elgsenos vertinimo kriterijai, o tik po to formuluojami reikalavimai kompiuterinės technologijos, garantuojančios suprojektuotų interfeisų veikimą ir norimą sistemos elgseną. Kuriant sistemą tokiu būdu, galima apsisaugoti nuo naudotojų vizijos iškraipymų, gaunamų dėl technologinių prielaidų. Tačiau ši vizija vis vien gali būti iškraipyta, nes, kaip jau buvo minėta anksčiau, sisteminiai analitikai dažniausiai iki galo naudotojų poreikius bei reikalavimus suvokia ne iš karto ir dėl to juos iškraipo. Šiaip sau: Dažniausiai paradigmos „iš apačios aukštyn“ ir „iš viršaus žemyn“ yra taikomos abi iškart.36. Kokia yra riešuto(bootstrap development) paradigma? (1) Riešuto paradigma dažniausiai naudojama kuriant operacines sistemas, programavimo sistemas ir kitą sisteminę programinę įrangą. Taikant šią paradigmą, programų sistema pradedama kurti nuo vadinamojo branduolio. Branduolys – tai programų rinkinys, realizuojantis bazines sistemos funkcijas. Jis traktuojamas kaip virtuali mašina, kurios kalba programuojamos papildomos funkcijos, praplečiančios šią kalbą. Taip yra sukuriamas branduolį supantis kevalas, kuris laikomas nauja virtualia mašina, naudojama naujam kevalui kurti. Procesas tęsiamas tol, kol sistema įgyja tas savybes, kurios yra nurodytos jos specifikacijoje. Kalbant apie tokį sistemos kūrimo būdą, sakoma, kad sistema “išvyniojama” iš branduolio.37. Kokia yra formalizuoto sistemų kūrimo paradigma? (1) Šios paradigmos esmę sudaro matematinės logikos ir kitų formalių metodų taikymas programų sistemoms kurti. Paradigma siūlo formalizuoti kuriamosios sistemos specifikaciją ir tą specifikaciją formaliai transformuoti į reikiamų programų kodą. Tai gali daryti žmogus arba speciali programa. Pirmuoju atveju kalbama apie įrodomąjį programavimą, antruoju – apie programų sintezę. Programų sintezės uždavinys kol kas yra išspręstas tik iš dalies. Kol kas sukurti tik jau minėtos struktūrinės sintezės metodai. Be to, tie metodai dažniausia yra pritaikyti kokiai nors konkrečiai dalykinei sričiai.38. Kokia yra evoliucinio sistemų kūrimo paradigma? (1) Pagrindinė šios paradigmos idėja yra laipsniško sistemos konstravimo idėja. Kaip ir naudojant riešuto paradigmą, pirmiausia yra kuriamas būsimosios sistemos branduolys. Tačiau šiuo atveju branduolys yra traktuojamas ne kaip virtuali mašina, naudojama sistemos funkcijoms plėsti, o kaip būsimos sistemos prototipas, įgyvendinantis pagrindines taikomojo pobūdžio funkcijas. Branduolys atiduodamas naudotojams ir toliau yra keičiamas bei plečiamas, atsižvelgiant į jų pastabas bei pageidavimus. Šitaip bandoma išvengti galimų naudotojų turimos sistemos vizijos iškraipymų. Taikant šią paradigmą programų sistemos konstravimas vyksta visą jos kūrimo laiką. Atskiros sistemos dalys sukonstruojamos jau pačioje jos kūrimo pradžioje.39. Kokia yra karkaso paradigma? (1) Ši paradigma grindžiama vadinamųjų mišriųjų skaičiavimų teorija. Taikant šią paradigmą, pirmiausiai yra kuriama apibendrinta (parametrizuota) programų sistemos versija, vadinama karkasu. Karkasas taip kuriamas, kad jis tiktų visoms dalykinėms sritims, turinčioms panašią loginę struktūrą. Turint konkrečios sistemos specifikaciją, karkasas yra konkretizuojamas, pritaikomas konkrečiam atvejui. Toks sistemų kūrimo būdas kartais dar yra vadinamas parametriniu programavimu.40. Kokie yra pagrindiniai programų sistemų inžinerijos principai? (1) Didžioji dauguma programų sistemų inžinerijos principų – tai konkretizuoti atitinkami sistemų inžinerijos principai. Taikant šiuos principus konkrečiuose programų sistemų inžinerijos procesuose, jie dažniausiai dar kartą konkretizuojami atsižvelgiant į nagrinėjamo proceso ypatumus. Pagrindiniai programų sistemų inžinerijos principai yra šie: 1) dekompozicijos principas, 2) abstrakcijos principas, 3) nuoseklių patikslinimų principas (abstrakcijos principo konkretizacija), 4) struktūrizavimo principas, 5) juodosios dėžės principas, 6) informacijos maskavimo principas (viena iš juodosios dėžės konkretizacijų), 7) unifikavimo principas, 8) sistemų atvirumo principas, 9) konceptualizavimo principas, 10) metaforizavimo principas, 11) interfeiso komfortiškumo principas, 12) sistemos reaktyvumo principas.41. Ką teigia dekompozicijos principas? (1) Dekompozicijos principas: Visus sudėtingus programų sistemų inžinerijoje vykdomų procesų objektus (užduotis, procesus, struktūras ir kt.) reikia skaidyti į kiek galima paprastesnes sudėtines dalis (modulius) ir vykdomąjį procesą taikyti kiekvienam moduliui atskirai. Nagrinėjamojo proceso požiūriu visi moduliai turi būti vieno lygmens. Jie taip pat turi būti nepriklausomi, t.y. tokie, kad, atlikus norimus veiksmus su kiekvienu iš jų atskirai ir sujungus tokiu būdu gautus rezultatus į vieną visumą, būtų gautas pageidaujamas galutinis rezultatas. Procesas turi būti kartojamas tol, kol objektas nėra suskaidytas į primityvus, t.y. lengvai suvokiamas ir neskaidžias dalis. Dalys vadinamos neskaidžiomis, jei jų negalima išskaidyti į sudėtines dalis nepažeidžiant savarankiškumo reikalavimo.Taikant dekompozicijos principą, supaprastinami analizės, projektavimo, konstravimo, testavimo ir kai kurie kiti procesai. Principas taikomas funkcijoms, programoms, duomenų struktūroms ir kitiems objektams skaidyti. Tada kalbama apie funkcinę dekompoziciją, duomenų dekompoziciją, programų moduliarizavimą ir pan. Geras programų sistemų projektavimas – tai geba skaidyti sistemą į modulius ir organizuoti tų modulių sąveiką.42. Ką teigia abstrakcijos principas? (1) Abstrakcijos principas: Programų sistemos inžinerijos procesai turi būti iteraciniai. Tai reiškia, kad kiekvienam objektui procesas turi būti taikomas kelis kartus. Be to, kiekvieno proceso taikymo metu objektas turi būti nagrinėjamas skirtingu detalumu, t.y. kiekvienos anksčiau vykdomos iteracijos metu yra ignoruojama daugiau nagrinėjamojo objekto detalių, jis yra labiau apibendrinamas negu vėliau vykdomų iteracijų metu. Iteracijos vadinamos abstrakcijos lygmenimis.Abstrakcijos lygmenų panaudojimas leidžia paskirstyti dėmesį ir taip supaprastinti projektavimą, konstravimą bei kai kuriuos kitus procesus. Aukštesni abstrakcijos lygmenys yra labiau apibendrinti negu žemesni. Juose sutapatinami kai kurie objektai, kurie žemesniuose abstrakcijos lygmenyse turi būti skiriami. Taigi kiekvieną abstrakcijos lygmenį galima detalizuoti daugeliu skirtingų būdų. Tai reiškia, kad kiekvienas abstrakcijos lygmuo aprašo visą šeimą žemesnių lygmenų. Todėl, norint optimizuoti taikomojo proceso rezultatus, pakanka optimizuoti perėjimus iš vieno abstrakcijos lygmens į kitą. Taip pat supaprastėja ir taikomojo proceso rezultatų modifikavimas, nes dažniausiai pakanka modifikuoti tik kai kuriuos apatinius abstrakcijos lygmenis.Abstrakcijos principas turi daug skirtingų konkretizacijų. Kalbama apie procedūrinę abstrakciją, duomenų abstrakciją, valdymo struktūrų abstrakciją, virtualiųjų mašinų hierarchijas ir pan. Jis naudojamas įvairiose paradigmose. Pavyzdžiui, taikant sistemų kūrimo iš viršaus žemyn paradigmą, pirmojoje iteracijoje projektuojama dalykinės srities terminais. Dėmesys sutelkiamas sistemos funkcijų aprašymui, konkretūs jos realizavimo būdai abstrahuojami. Paskutiniojoje iteracijoje projektuojama programavimo kalbos, duomenų struktūrų ir kompiuterio resursų terminais. Čia pagrindinis dėmesys skiriamas sistemos realizavimui ir abstrahuojamos taikymų srities sąvokos bei vaizdiniai. Kitos iteracijos užima tarpinę padėtį, jų skaičių lemia projektuojamos programų sistemos sudėtingumas ir pasirinktas projektavimo metodas.43. Ką teigia nuoseklių patikslinimų principas? (1) Konkrečioms programoms (moduliams) projektuoti taikoma abstrakcijų principo konkretizacija vadinama nuoseklių patikslinimų principu.Nuoseklių patikslinimu principas: Projektuojant konkrečią programą, pirmiausiai reikia suformuluoti jos sprendžiamą uždavinį. Uždavinio formuluotė turi būti traktuojama kaip projektuojamosios programos specifikacija. Po to specifikacija yra detalizuojama. Tam nagrinėjami galimi jos tikslinimo būdai ir iš jų, taikant našumo ar kitus kriterijus, yra išrenkamas geriausias. Taip gaunama nauja, patikslinta programos specifikacija. Procesas kartojamas ir baigiamas tuomet, kai gaunamas kodas kokia nors programavimo kalba.Nuoseklių tikslinimų principas yra esminė sistemų kūrimo iš viršaus žemyn paradigmos dalis. Jis grindžiamas prielaida, kad galima pateikti tikslią ir nekintamą sprendžiamojo uždavinio formuluotę. Deja, tai įmanoma padaryti tik kai kuriais atvejais.44. Ką teigia struktūrizavimo principas? (1) Struktūrizavimo principas: Programų sistemų inžinerijos procesų eigoje kuriami objektai turi būti konstruojami iš tipizuotų, patikimų elementų, kurių savybės yra gerai žinomos ir patikrintos.Struktūrizavimo principą išgarsino vadinamasis “struktūrinis programavimas”. Iš pradžių šis principas buvo suabsoliutintas ir mėgintas pateikti kaip panacėja. Tai, be abejo, netiesa, nors struktūrinio programavimo metodų nauda neabejotina. Beje, plačiai paplitusi nuomonė, kad kaip tipines būtina naudoti vadinamąsias D struktūras, taip pat klaidinga. D struktūros parinktos remiantis programos analogija teoremos įrodymui ir pasižymi daugeliu gerų savybių, bet nėra vienintelės galimos.Programų sistemų inžinerijoje struktūrizuojamos ne tik programos, bet ir duomenys, sistemos, procesai bei kiti objektai.45. Ką teigia juodos dėžės principas? Kas tai yra informacijos maskavimas?(1) Juodosios dėžės principas: Objektai turi būti taip konstruojami, kad jais butų galima manipuliuoti, nežinant jų veikimo principų. Tam, kad būtų galima pasinaudoti objektu, turi pakakti žinių apie tai, kaip jo elgesį keičia išorinis poveikis.Juodosios dėžės principą programų sistemų inžinerija perėmė iš kibernetikos. Joje juodąja dėže vadinama sistema, kuria galima naudotis nežinant tos sistemos veikimo principų. Gerai sukonstruota programų sistema naudotojui turi būti juodoji dėžė. Ja turi būti ir kiekvienas sistemos modulis. Kad programų sistema taptų juodąja dėže, reikia parinkti atitinkamą architektūrą, parengti gerą jos naudojimo instrukciją, atlikti išsamią įvesties duomenų kontrolę ir apsaugoti sistemą nuo galimų naudotojo klaidų poveikio. Be to, juodosios dėžės principas bus pažeistas, jei pranešimai naudotojui bus formuluojami vidinių sistemos konstrukcijų, o ne dalykinės srities terminais. Sistemos ir naudotojo dialogas turi vykti naudotojui įprastais terminais, sistema turi suprasti jį ir būti jo suprasta. Daugeliu atveju šį tikslą pavyksta pasiekti naudojant abstrakcijos ir konceptualizavimo principus.Pažymėsime, kad juodosios dėžės principas programų sistemų inžinerijoje taikomas daugeliui objektų ir todėl turi keletą konkretizacijų. Svarbiausia iš jų – informacijos maskavimo principas. Jis formuluojamas šitaip:Informacijos maskavimo principas: Modulių vidinės duomenų struktūros ir procedūros turi buti nematomos išoriniams naudotojams. Iš išorės prieinamos duomenų struktūros turi būti inkapsuliuotos, t.y. naudotojui turi būti pateiktas procedūrų, skirtų manipuliuoti tomis struktūromis, rinkinys. Šių duomenų struktūrų vaizdavimo būdas naudotojams turi būti nežinomas.Informacijos maskavimo principas yra svarbus tuo, kad jis leidžia keisti vidinę programų sistemų modulių konstrukciją be jokio poveikio tų modulių naudojimui. Tai labai supaprastina programų sistemų modernizavimą. Be to, taikant šį principą, padidinamas modulių patikimumas, nes duomenų struktūros yra apsaugomos nuo pažeidimų.46. Ką teigia unifikavimo principas? (1) Unifikavimo principas: Programų sistema turi būti taip projektuojama ir konstruojama, kad ji būtų vienalytė. Visos sistemos dalys turi būti suprojektuotos ir sukonstruotos vienodai. Tam turi būti numatyti atitinkami standartai.Unifikavimo principas palengvina programų sistemų modernizavimą, sudaro prielaidas jas nuasmeninti, t.y. “atplėšti” nuo autorių. Unifikuotą sistemą gali suvokti ir keisti ne tik jos kūrėjai, bet ir kiti ją kuriant naudotus standartus įsisavinę asmenys.47. Koks yra sistemų atvirumo principas? (1) Su unifikavimo ir juodosios dėžės principais labai glaudžiai siejasi sistemų atvirumo principas. Jis formuluojamas taip:Sistemų atvirumo principas: Programų sistemos turi būti atviros, t.y. jos turi būti konstruojamos iš komponentų, turinčių standartizuotus sąveikos su išorine aplinka interfeisus. Bet kuris sistemos komponentas gali būti keičiamas kitu, turinčiu tą pačią išorinę bet galbūt kitos vidinės elgsenos komponentu.Tai vienas iš svarbiausių programų sistemų inžinerijos principų. Jis sudaro prielaidas sistemoms plėsti, integruoti tarpusavyje bei perkelti iš vienos aparatūrinės-operacinės aplinkos į kitą.Atvirąja, arba atviros architektūros sistema, vadinama tokia programų sistema, kurios visi išoriniai interfeisai yra suprojektuoti pagal tarptautinius atvirųjų sistemų standartus.Atvirųjų sistemų standartų yra gana daug. Pagrindinės naudojamų standartų rūšys parodytos paveiksle. Interfeiso reikalavimuose būtina nurodyti, kokiems konkretiems standartams turi atitikti kiekvienas išorinis kuriamos programų sistemos interfeisas.48. Ką teigia konceptualizavimo principas? (1) Konceptualizavimo principas: Programų sistemos turi būti taip projektuojamos ir konstruojamos, kad dalykinės srities konceptai turėtų sistemoje tiesioginius atitikmenis. Sistemos dalių sąveika turi tiksliai atspindėti probleminės srities konceptų ryšius. Tai reiškia, kad programų sistema turi būti kuriama remiantis atitinkamos dalykinės srities koncepciniu modeliu.Taikant šį principą, programų sistema dažniausiai yra konstruojama kaip specialių struktūrų, vadinamų objektais, hierarchija. Šiuo atveju objektais yra vadinami duomenų struktūrų ir su šiomis struktūromis dirbti skirtų procedūrų paketai. Jie konstruojami pagal juodosios dėžės ir duomenų maskavimo principus. Objektai modeliuoja dalykinės srities sąvokas ir todėl juos patogu naudoti dialogui dalykinės srities terminais realizuoti.49. Ką teigia metaforizacijos principas? (1) Metaforizavimo principas: Programų sistemos sąveikos su naudotoju interfeisas turi būti konstruojamas kaip dalykinės srities metafora, atspindinti naudotojų vaizdinius, tradicijas bei įpročius.Taikomas kartu su konceptualizavimo principu, metaforizacijos principas sudaro visas prielaidas sukonstruoti interfeisą, modeliuojantį naudotojų požiūrį į dalykinę sritį ir sprendžiamus uždavinius. Kad sistema suprastų, ko nori naudotojas, reikia aprašyti jo vaizdinius, sukonstruoti kompiuterinę dalykinės srities metaforą ir susieti ją su koncepciniu tos sistemos modeliu. Sukonstravus vykusią metaforą, pavyksta naudotojo darbą su sistema priartinti prie jam įprasto darbo stiliaus. Jis gali įsivaizduoti sistemą kaip savo darbo stalą, paštą, kalkuliatorių ar kitą jam gerai žinomą objektą.Metaforoms konstruoti naudojami užduočių analizės metodai. Analizuojant užduotis, nagrinėjamas veiklos, kurią sistema automatizuoja, pobūdis, o ne objektas, į kurį ši veikla nukreipta. Kokias funkcijas turi realizuoti sistema čia ne tiek svarbu. Svarbiausia, koks sistemos darbo režimas tinkamiausias naudotojams. Vienaip nori sistema naudotis inžinierius, kitaip – medikas, dar kitaip – buhalteris. Būtina atsižvelgti ne tik į darbo pobūdį, bet ir į naudotojų įgūdžius, tradicijas bei mąstymo būdą. Programų sistemų inžinerijos metodų tam nepakanka, todėl tenka naudotis atitinkamais psichologijos bei pedagogikos metodais.50. Ką teigia interfeiso komfortiškumo principas? (1) Su metaforizacijos ir konceptualizavimo principais artimai susietas ir svarbus naudotojo interfeiso konstravimo principas, vadinamas interfeiso komfortiškumo principu. Jis formuluojamas šitaip:Interfeiso komfortiškumo principas: Programų sistemos sąveikos su naudotoju interfeisas turi būti komfortiškas, t.y. darbas su sistema turi kuo mažiau varginti naudotoją, būti malonus ir nesukelti psichologinio diskomforto būsenos. Interfeisas turi būti lengvai individualizuojamas, t.y. pritaikomas prie konkretaus naudotojo pomėgių. Visų vieno tipo naudotojų naudojamų sistemų interfeisai turi būti panašūs.Šį principą realizuoti padeda ergonomikos metodai. Svarbus yra ir meninis interfeiso apipavidalinimas, medžiagos pateikimo būdas ir pan. Taigi tenka naudotis ir techninės estetikos, psichologijos bei pedagogikos metodais.Šiaip sau: Sistemos reaktyvumo principas. Programų sistema neturi būti pasyvi, ji turi reaguoti į dalykinėje srityje susidarančias situacijas ir daryti kryptingą poreikį norimai tų situacijų eigai formuoti. Šis principas yra perimtas iš dirbtinio intelekto teorijos ir nėra bendrasis principas.51. Kokia yra dalykinės srities struktūra ir kaip ji kinta laike? Ką vadiname esybėmis ir ką jų egzemplioriais? kokios esti esybių ir jų egzempliorių charakteristikos? ką vadiname esybių egzempliorių būsenomis? kaip vyksta būsenų pokyčiai?(5) Esybės – realaus pasaulio objektų klasės, jas galima apibūdinti bendriniais daiktavardžiais. Egzempliorius – konkrečios esybės realizacija. Charakteristikos: aprašomosios (fizinės, chronologinės, nefizinės,etc.) – nusako esybės arba egzempliorių vidines savybes; organizacinės – nusako esybės egzemplioriaus ryšius su kitais tos pačios ar kitos esybės egzemplioriais; Esybės egzemplioriaus būsena – vienareikšmiškai nusakoma egzemplioriaus apraiška. Būsena nusakoma reikšme (aprašomųjų ir organizacinių charakteristikų reikšmių visuma) ir toje būsenoje leistinomis elgesio savybėmis.Būsenos kinta laikui bėgant – jas keičia procesai, inicijuoti tam tikrų įvykių.52. Ką vadiname modeliu? Kokios esti modelių rūšys?(5) Modelis – aiškiai nusakytą tikslinę paskirtį turintis supaprastintas sistemos, proceso, reiškinio ar kito originalo analogas, tapatus originalui modeliavimo tikslų atžvilgiu. Rūšys: struktūrinis – atspindi tik struktūrines originalo savybes imitacinis – imituoja originalo elgseną kompleksinis – struktūrinis + imitacinisPagal realizavimo būdą: fizinis – materialus originalo analogas abstraktus – teisingų tvirtinimų ir teiginių apie originalo savybes bei charakteristikas rinkinys, interpretuojamas pakankamai vienareikšmiškai. Lingvistinis modelis – originalo aprašas natūraliąja kalba arba spec. pokalbiu modeliavimo tikslams.53. Iš kokių dalių sudarytas informacinio modeliavimo formalizmas? Apibūdinkite jas. (5) Objektinio modeliavimo formalizmu vadinamas šešetas:F = Cls – klasių vardų aibė. Ji sudaryta iš leksinių (Cls1) ir neleksinių objektų klasių vardų poaibių (Cls2). CnstB – bendrųjų konstantų aibė. Ji sudaryta iš Cls1 klasių objektų. Atr – atributų vardų aibė. Kiekvienas atributas turi tipą iš Cls ir gali būti Cls2 klasės objektų arba visos klasės atributas. Tą nusako signatūros. Op – operacijų (metodų) aibė. Kiekvienas metodas yra vienos ir tik vienos Cls2 klasės arba klasės objektų metodas. Gali turėti parametrus ir rezultatą tipo iš Cls. Tą nusako signatūros. Trm – leistini termai. Kiekvienas termas yra vienos Cls2 klasės tipo. Frm – leistinos formulės. Paaiškinimai C++ pavyzdžiu: Cls–tipai (Cls1–baziniai tipai (char, int), Cls2–klasės (class)), CnstB–bazinių tipų reikšmių aibės (‘a’,’b’,0,1,2,…), Atr – klasių atributai, Op – klasių metodai, Trm– objektai.54. Kas tai yra informacinio modeliavimo formalizmo domenai? Kaip jie konstruojami? Pateikite (skirtingų nei knygoje) pavyzdžių.(5) Domenas = Domenų konstruktoriai yra: Dekarto sandauga d:data d: {metai x mėnuo x diena }sąrašų konstruktorius m:mėnuo m: {“sausis”, .. “gruodis” }aibių konstruktorius v:asmens_vardas v: {vardas:(1,3)}algebrinis konstruktorius x:tiekėjasx:{juridinis_asmuo U fizinis_asmuo}domeno ribojimas m: metai WWII (m:metai) & (m >= 1939) & (m < 1946)).55. Kas tai yra informacinio modeliavimo formalizmo klasės? Kaip aprašomos jų signatūros? Pateikite pavyzdžių (5)56. Apibūdinkite informacinio modeliavimo formalizmo klasių ir poklasių ryšių pobūdį. Kas tai yra klasifikacija? kokios jos esti? Pateikite (skirtingų nei knygoje) pavyzdžių.(5) Ryšys IS-A. Klasės klasifikacija – (x, y)::k, k1,..kn – yra k potipiai, x iš {t, d}, y iš {g, n}, t žymi totaliąją klasifikaciją, d – dalinę, g – griežtąją, n – negriežtąją. Klasifikacija gali būti totali arba dalinė ir griežta arba negriežta. (t,g) :: Asmuo; (t,g) :: Asmuo57. Ką informacinio modeliavimo formalizmuose vadiname ryšiais? Kaip aprašomos ryšių signatūros? Pateikite pavyzdžių. (5) Ryšiai naudojami DS esybių organizacinėms charakteristikoms modeliuoti. Ryšių signatūros konstruojamos naudojant predikatines konstantas. Ryšio r signatūra vadinamas reiškinys: r[fr1 => k1: (ν1, μ1); … ; fkn => kn: (νn, μn); <φ r1 => d1; … ; φ rm => dm> | γ k1; …; γ ks], čia k – objektinės molekulės, f – tų molekulių vaidmenų ryšyje r vardai, φ – ryšio generuojamų sąryšių atributų vardai, d – tų atributų reikšmių domenų vardai,.58. Kokius darnos reikalavimus galima aprašyti klasių kardinalumais ryšių atžvilgiu?