1 / 32

Programu sistemu in inerija

5 paskaita. 2. Paskaitos planas. Ivadas i kursa14 dalis. Ka apima PS in

oshin
Download Presentation

Programu sistemu in inerija

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. 5 paskaita 1 Programu sistemu ininerija Prof. Albertas Caplinskas 2005

    2. 5 paskaita 2 Iki 84(59)Iki 84(59)

    3. 5 paskaita 3 Paskaitos planas Ivadas i kursa 14 dalis. Ka apima PS ininerija Disciplinos turinys PS ininerijos procesai: basiniai procesai, pagalbiniai procesai, organizaciniai procesai. Artifaktai. Idealizacijos

    4. 5 paskaita 4 Paskaitos planas Ivadas i kursa 15 dalis. PS ininerijos principai ir paradigmos Svarbiausi PS ininerijos principai: turiniu atskyrimas, dekompozicija, juodosios dees principas, abstrakcija, unifikavimo principas, strukturizavimo principas,sistemu atvirumo principas, konceptualizavimo principas, interfeiso komfortikumo principas, reaktyvumo principas Svarbiausios PS ininerijos paradigmos: kurimo i viraus emyn, kurimo i apacios auktyn, rieuto, prototipu, pletiniu, ekstremalaus programavimo, daugkartinio panaudojamumo, PS eimu ininerijos, formalaus kurimo

    5. 5 paskaita 5 Kurso ivadas 14 dalis. Ka apima PS ininerija?

    6. 5 paskaita 6 Ka apima PS ininerija? Terminija Terminas programu ininerija (software engineering) buvo ivestas 1968 m. vykusioje pirmojoje NATO konferencijoje PS ininerijos klausimais Nuo pat pradios is terminas turejo dvi skirtingas prasmes Siauroji prasme: disciplinuotas principu, metodu ir irankiu naudojimas analizuojant kompiuteriniu programu, ju eksploatavimo proceduru ir ju dokumentacijos reikalavimus, visa tai projektuojant, realizuojant, eksploatuojant ir prieiurint (McDermid, 1985) Placioji prasme: disciplina, usiimanti PS kurimo technikomis (Ramamoorthy at all, 1984)

    7. 5 paskaita 7 Ka apima PS ininerija? Terminija ios apibretys yra visikai skirtingos pirmojoje kalbama apie kompiuterines programas antrojoje kalbama apie programu sistemas, turint omenyje, kad programu sistemas sudaro ivairus skirtingos prigimties komponentai (failai, duomenu bazes, interfeisai, protokolai ir kt.) ir programos yra tik vienas i komponentu. Siekdami atskirti ias prasmes, R.H. Thayer ir W.W. Royce ivede termina PS ininerija (software systems engineering) ir apibree ia disciplina, kaip disciplina, harmoningai derinancia tarpusavyje bendrosios sistemu ininerijos ir programu ininerijos elementus. PS ininerija usiima sudetingomis sistemomis, kuriose pagrindinis vaidmuo PI (software intensive systems).

    8. 5 paskaita 8 Ka apima PS ininerija? Terminija iame kurse PS ininerija yra apibreiama itaip: 1. PS ininerija, kaip praktine veiklos sritis, yra sistemu ininerijos aka, usiimanti pramoniniu PS kurimu. 2. PS ininerija, kaip moksline disciplina, yra inineriniu mokslu aka, nagrinejanti pramoniniu PS kurimo principus, metodus, technikas, irankius bei proceduras ir efektyvu viso to panaudojima PS pramoneje.

    9. 5 paskaita 9 Sudetines PS ininerijos dalys

    10. 5 paskaita 10 Sudetines PS ininerijos dalys

    11. 5 paskaita 11 Disciplinos turinys Teoriniai pagrindai savokos, principai paradigmos, modeliai, modeliavimo formalizmai, modeliavimo kalbos

    12. 5 paskaita 12 Disciplinos turinys Inineriniai pagrindai tipiniai projektavimo sprendimai (design patterns), karkasai (frameworks), komponentai, irankiai, technologijos

    13. 5 paskaita 13 Disciplinos turinys PS architekturos architekturiniai stiliai, architekturu savybes (reikalavimai), modelines (reference) architekturos imones sistemos architekturos (enterprise architectures), programi eimu architekturos, Programi sistemu architekturos jungimo mechanizmai (glue mechanisms) igyvendinimo budai

    14. 5 paskaita 14 Disciplinos turinys Projekto valdymas Projekto valdymo proceso komponentai (subprocesai) projekto iniciavimas, projekto planavimas, projekto vykdymas, projekto kontrole, projekto ubaigimas PS gyvavimo ciklo modeliai ir PS kurimo procesai Dalykines sritys projekto integravimas, terminu valdymas, kokybes valdymas, mogikuju itekliu valdymas, komunikavimo procesu valdymas, rizikos veiksniu valdymas, pirkimu valdymas Apskritai, kokybes valdymas yra projekto valdymo dalis. Bet, del io klausimo svarbos, mes nagrinejame kokybes valdyma kaip savarankika PSI aka..

    15. 5 paskaita 15 Disciplinos turinys Kokybes valdymas Kokybes valdymas tai savarankika PS ininerijos aka, nagrinejanti kokybes standartus, kokybes atributus, kokybes planavima, kokybes kontrole (vertinima (evaluation), matavima, testavima ir pan.), kokybes utikrinimo proceduras, kokybes ivertinima (assessment).

    16. 5 paskaita 16 Disciplinos turinys Konfiguracijos valdymas Konfiguracijos valdymas, kaip moksline disciplina, nagrineja kaip utikrinti, kad einamoji kuriamo produkto (ir jo komponentu) konfiguracija bet kuriuo laiko momentu butu inoma ir dokumentuota ir kad visi jos keitimai butu kontroliuojami ir trasuojami, t.y.: pateikiamo produkto komponentu (iskaitant ju versijas) nustatymo ir identifikavimo (ivardinimo) metodus, tu komponentu atmainu (release) ir ju pokyciu kontroles visose gyvavimo ciklo stadijose metodus, einamosios produkto komponentu bukles ir reikalavimu ja keisti dokumentavimo metodus, produkto komponentu isamumo ir korektikumo tikrinimo proceduras.

    17. 5 paskaita 17 Disciplinos turinys Reikalavimu ininerija reikalavimu nustatymas, reikalavimu dokumentavimas, reikalavimu prieiura, reikalavimu modeliavimas, reikalavimu analize ir vertinimas, reikalavimu lokalizavimas, reikalavimu operacionalizavimas ir nuleidimas emyn.

    18. 5 paskaita 18 Disciplinos turinys Programu ininerija programu specifikavimas, programu projektavimas programu moduliarizavimas, programu kodavimas ir kodo dokumentavimas, programu testavimas ir derinimas

    19. 5 paskaita 19 Disciplinos turinys Duomenu ininerija Duomenu ininerija, kaip moksline disciplina, nagrineja, kaip PS projektuoti, realizuoti, tvarkyti, priiureti ir naudoti duomenu strukturas ir pacius duomenis, t.y.: duomenu baziu projektavima; metaduomenis ir ju vaizdavimo bei apdorojimo metodus; kalbas duomenims, prieigai prie ju ir manipuliavimu jais aprayti; prieigos prie duomenu, ju apsaugos ir darnos (integrity) kontroles strategijasir mechanizmus.

    20. 5 paskaita 20 Disciplinos turinys Interfeisu ininerija Pagrindinis ios disciplinos nagrinejimu objektas yra vartotojo interfeisu (bet nagrinejami ir kitokie interfeisai) specifikavimas, projektavimas ir realizavimas. Vienas i pagrindiniu tikslu yra didinti vartotojo darbo nauma. Nors mes priskiriame ia disciplina PS ininerijai, ji taip pat yra priskiriama mogaus ir kompiuteriu saveika nagrinejanciai mokslo akai. Interfeisu ininerija nagrineja interfeisu architekturas, tipinius interfeisu projektavimo sprendimus (design patterns), interfeisu standartus, irankius interfeisams kurti, interfeisu prototipu kurimo technikas.

    21. 5 paskaita 21 Disciplinos turinys Web ininerija Web ininerijos nagrinejimu objektas yra Web sistemu specifikavimas, projektavimas, realizavimas, aptarnavimas ir prieiura. Ji nagrineja: informacijos architekturas, informacines erdves strukturizavimo ir dekomponavimo i hipermedia puslapius technikas, hipermedia puslapiu dekomponavimo i smulkesnius daugkartinio panaudojimo objektus technikas, vizualizavimo technikas, Web sistemu kurimo irankius. http://www.rspa.com/reflib/WebEngineering.html http://webster.fh-hagenberg.at/staff/kurschl/ (cia yra kursas kurio viso nepavyko nukopijuoti)http://www.rspa.com/reflib/WebEngineering.html http://webster.fh-hagenberg.at/staff/kurschl/ (cia yra kursas kurio viso nepavyko nukopijuoti)

    22. 5 paskaita 22 Disciplinos turinys Kokybes ininerija Kokybes ininerija nagrineja ininerines veiklas, naudojamas utikrinti reikalaujama kuriamo produkto kokybe, t.y.: patikimumo (reliability) ininerija, saugos (safety) ininerija, apsaugos (security) ininerija, naumo (performance) ininerija, panaudojamumo (usability) ininerija, priiurimumo (maintainability) ininerija.

    23. 5 paskaita 23 Disciplinos turinys Patikimumo ininerija i disciplina numato, kokios vadybines ir ininerines proceduros turi buti naudojamos projekte, siekiant utikrinti pakankama demesi visoms projekto detalems, vienaip ar kitaip darancioms itaka kuriamos PS patikimumui. Ji nagrineja: patikimumo modelius, patikimumo reikalavimus ir standartus, patikimumo matavimo ir vertinimo metodus, patikimuma utikrinancio projektavimo budus (designing for reliability), patikimumo testavimo metodus ir proceduras, testu patikimumui testuoti projektavimo metodus. http://www.enre.umd.edu/ http://media.wiley.com/product_data/excerpt/39/04708446/0470844639.pdfhttp://www.enre.umd.edu/ http://media.wiley.com/product_data/excerpt/39/04708446/0470844639.pdf

    24. 5 paskaita 24 Disciplinos turinys Saugos ininerija Sauga (safety): garantijos, kad sistema nesukels katastrofiku pasekmiu nei vartotojams, nei aplinkai. PS sauga yra speciali PS patikimumo ruis Saugos ininerija numato, kokios vadybines ir ininerines proceduros turi buti naudojamos projekte, siekiant utikrinti, kad kritines PS (daniausiai, imontuotos PS) veiktu saugiai net ir tuomet, kuomet kurios nors ju dalys sutrinka. Robyn R. Lutz. Software Engineering for Safety: A Roadmap http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/finallutz.pdf Robyn R. Lutz. Software Engineering for Safety: A Roadmap http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/finallutz.pdf Safety engineering http://en.wikipedia.org/wiki/Safety_engineering Software Reliability and Safety (skaidres) http://engr.smu.edu/~tian/class/8317.05f/ov1.pdf Robyn R. Lutz. Software Engineering for Safety: A Roadmap http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/finallutz.pdf Robyn R. Lutz. Software Engineering for Safety: A Roadmap http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/finallutz.pdf Safety engineering http://en.wikipedia.org/wiki/Safety_engineering Software Reliability and Safety (skaidres) http://engr.smu.edu/~tian/class/8317.05f/ov1.pdf

    25. 5 paskaita 25 Disciplinos turinys Saugos ininerija Saugos ininerija nagrineja: sistemos sauga paeidianciu rizikos veiksniu (hazards) analizes metodus, sistemos saugos rizikos veiksniais vadinamos sistemos busenos, galincios sukelti nelaimingus atsitikimus. saugiai naudojamo ir saugaus programinio produkto ribojimu nustatymo metodus, saugos reikalavimu specifikavimo ir analizes metodus, sauga utikrinancio projektavimo (design for safety) metodus, saugos poiuriu kritiniu sistemu testavimo ir vertinimo metodus, saugos standartus ir PS saugos sertifikavimo metodus, veikianciu PS saugos monitoringo metodus. Robyn R. Lutz. Software Engineering for Safety: A Roadmap http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/finallutz.pdf Robyn R. Lutz. Software Engineering for Safety: A Roadmap http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/finallutz.pdf

    26. 5 paskaita 26 Disciplinos turinys System Software Safety http://www.faa.gov/library/manuals/aviation/risk_management/ss_handbook/media/Chap10_1200.PDFSystem Software Safety http://www.faa.gov/library/manuals/aviation/risk_management/ss_handbook/media/Chap10_1200.PDF

    27. 5 paskaita 27 Disciplinos turinys System Software Safety http://www.faa.gov/library/manuals/aviation/risk_management/ss_handbook/media/Chap10_1200.PDFSystem Software Safety http://www.faa.gov/library/manuals/aviation/risk_management/ss_handbook/media/Chap10_1200.PDF

    28. 5 paskaita 28 Disciplinos turinys Apsaugos ininerija PS apsaugos reikalavimai, juos paeidianciu gresmiu nustatymas ir paeidimu pasekmiu likvidavimo strategijos, projektavimo ir programavimo metodai, padedantys ivengti samoningu ir atsitiktiniu PS apsaugos paeidimu, saugus PS iskleidimo (deployment) metodai, PS apsauga eksploatavimo metu.

    29. 5 paskaita 29 Disciplinos turinys

    30. 5 paskaita 30 Disciplinos turinys Naumo ininerija Naumo (performance) ininerija kaip visose gyvavimo ciklo stadijose planuoti ir igyvendinti reikalaujama PS nauma, t.y.: naumo modelius, naumo reikalavimus ir standartus, naumo matavimo ir vertinimo metodus, nauma utikrinancio projektavimo budus (performance-oriented design) Connie U. Smith, Lloyd G. Williams: Performance Solutions - A Practical Guide to Creating Responsive, Scalable Software, Addison-Wesley, 2002 http://cs.gmu.edu/~menasce/perfbyd/Connie U. Smith, Lloyd G. Williams: Performance Solutions - A Practical Guide to Creating Responsive, Scalable Software, Addison-Wesley, 2002 http://cs.gmu.edu/~menasce/perfbyd/

    31. 5 paskaita 31 Disciplinos turinys http://www.sce.carleton.ca/wosp98/w98slides.htmlhttp://www.sce.carleton.ca/wosp98/w98slides.html

    32. 5 paskaita 32 Disciplinos turinys Panaudojamumo ininerija Panaudojamumo (usability) ininerija, atsivelgdama i mogaus ir kompiuterio saveikos ypatumus, nagrineja kaip suprojektuoti tokia PI, kuri priimtu demesin mogaus psichofiziologines savybes ir kuria mogui butu patogu ir lengva naudotis. I esmes, tai yra ergonomikos aka. Ji glaudiai siejasi ir su interfeisu ininerija. Disciplina nagrineja: panaudojamumo lygmenis, panaudojamumo standartus, panaudojamumo gerinimo budus, metodus, technikas ir tam skirtas veiklas, panaudojamumo matavimo ir vertinimo metodus.

    33. 5 paskaita 33 Disciplinos turinys Priiurimumo ininerija i disciplina nagrineja, kaip, kuriant PS, palengvinti tu sistemu prieiura ir sumainti ju prieiuros katus, t.y.: priiurimumo (maintanability) standartus, priiurimumo gerinimo budus, metodus, technikas ir tam skirtas veiklas, lenviau priiurimu sistemu projektavimo metodus (design for maintainability), priiurimumo vertinimo ir matavimo metodus. http://www.waveland.com/Titles/Ebeling.htm http://www.cdf.utoronto.ca/~csc408h/winter/lectures/Week1-Intro.pdfhttp://www.waveland.com/Titles/Ebeling.htm http://www.cdf.utoronto.ca/~csc408h/winter/lectures/Week1-Intro.pdf

    34. 5 paskaita 34 Disciplinos turinys PI prieiura PI prieiura - tai disciplina, usiimanti programiniu produktu atnaujinimo ir techninio palaikymo problemomis,iskaitant sistemu kelimo i platformos i platforma problemas. i disciplina nagrineja: PI prieiuros modelius, PI prieiuros procesus, PI prieiuros kategorijas, PI prieiuros standartus http://www.waveland.com/Titles/Ebeling.htm http://www.cdf.utoronto.ca/~csc408h/winter/lectures/Week1-Intro.pdfhttp://www.waveland.com/Titles/Ebeling.htm http://www.cdf.utoronto.ca/~csc408h/winter/lectures/Week1-Intro.pdf

    35. 5 paskaita 35 Disciplinos turinys Instrumentiniu sistemu teorija Instrumentiniu sistemu teorija nagrineja programiniu irankiu kurimo metodus, t.y.: programavimo ir PS kurimo aplinku architekturas, irankiu realizavimo ir integravimo metodus, repozitorijus, irankiu saveikos standartus. http://www.waveland.com/Titles/Ebeling.htm http://www.cdf.utoronto.ca/~csc408h/winter/lectures/Week1-Intro.pdfhttp://www.waveland.com/Titles/Ebeling.htm http://www.cdf.utoronto.ca/~csc408h/winter/lectures/Week1-Intro.pdf

    36. 5 paskaita 36 Procesai ir artifaktai

    37. 5 paskaita 37 Disciplinos turinys Norint suvokti bet kuria ininerine disciplina, reikia inoti kokiais procesais joje yra gaunami norimi rezultatai, kokius artefaktus (mogaus ranku kurinius) ji kuria.

    38. 5 paskaita 38 Disciplinos turinys PS ininerijoje naudojami triju tipu procesai: baziniai (pirminiai) procesai procesai, neimanoma nei sukurti jokia PS sistema, nei ja pasinaudoti pagalbiniai procesai pagalbiniai procesai veikia baziniu procesu sudetyje ir padeda utikrinti ju kokybe bei sekme, bet, i principo, be iu procesu galima apseiti organizaciniai procesai tai procesai, kuriais kuriamos, aptarnaujamos ir palaikomos organizacines strukturos, skirtos PS kurti

    39. 5 paskaita 39 Disciplinos turinys Baziniai procesai analize: ko nors esamo (proceso, veiklos, sistemos ir kt.) modeliavimas, atliekamas tikslu tai perprasti, specifikavimas: ko nors, kas bus kuriamas, modeliavimas jo i iores stebimu savybiu terminais, atliekamas tikslu suformuluoti to daikto projektavimo ir realizavimo tikslus ir ribojimus, projektavimas: ko nors, kas bus kuriamas, modeliavimas jo vidiniu savybiu terminais, atliekamas tikslu kuo geriau igyvendinti specifikacijos reikalavimus, projektavimas apima geriausio specifikacijos igyvendinimo budo parinkima ir to budo modeliavima

    40. 5 paskaita 40 Disciplinos turinys Baziniai procesai realizavimas: ko nors, kas yra kuriama, specifikuota to dalyko elgsena projektuotojo numatytu budu igyvendinanciu daliu konstravimas programavimas yra vienas i realizavimo subprocesu; jis suprantamas kaip projektavimo sprendimu uraymas pasirinktajam procesoriui suprantamu instrukciju seka; surinkimas (integravimas): ko nors, kas yra kuriama, daliu jungimas i viena visuma, diegimas (preparation for operation): kam nors veikti reikalingu resursu akumuliavimas, to daikto pateiktis, instaliavimas ir pritaikymas konkreciai darbo vietai,

    41. 5 paskaita 41 Disciplinos turinys Baziniai procesai aptarnavimas (operation): specifikacija numatytos kieno nors elgsenos palaikymo procesas, prieiura (maintenance): ko nors, kas jau yra sukurta ir naudojama, vidiniu ar i iores stebimu savybiu keitimo procesas, atliekamas nepaeidiant to daikto vientisumo ir jo savybiu darnos, demontavimas (retirement): ko nors sukurto ir naudojamo laipsnikas naudojimo nutraukimas PS atveju tai laipsnikas vienos veikiancios sistemos funkciju perdavimo kitai veikianciai sistemai procesas.

    42. 5 paskaita 42 Disciplinos turinys Pagalbiniai procesai testavimas: empirinis tikrinimas, ar kas nors tenkina reikalavimus, kuriuos tas daiktas privalo tenkinti, verifikavimas: ko nors, kas yra kuriamas, eilinio atlikto kurimo ingsnio (pvz., operacijos) korektikumo tikrinimo procesas, vertinimas (validation): procesas, kuriuo siekiama nustatyti, ar kas nors tenkina realius to daikto vartotoju poreikius,

    43. 5 paskaita 43 Disciplinos turinys Pagalbiniai procesai dokumentavimas: informacijos, sukauptos ka nors kuriant, fiksavimo procesas, konfiguracijos valdymas: procesas, kuriuo siekiama, kad kas nors, kas yra kuriamas ir nuolat keiciamas, bet kuriuo laiku momentu turetu visas savo sudetines dalis, privalomas tam laiko momentui, ir kad tos dalys tarpusavyje butu suderintos,

    44. 5 paskaita 44 Disciplinos turinys Pagalbiniai procesai periura (reviewing): procesas, kuriuo siekiama patikrinti, ar ko nors, kas yra kuriamas, kurimas vyksta pagal numatyta plana, ar gauti visi plane numatyti rezultatai ir, jei to nera, nustatyti nukrypimu nuo planuotos darbu eigos prieastis, inspektavimas (auditing): procesas, kuriuo siekiama patikrinti, ar ka nors kuriant nenukrypstama nuo sandoriu, standartais ar kitais privalomais dokumentais nustatytu kokybes reikalavimu, problemu sprendimas (problem resolution): procesas, kuriuo siekiama ianalizuoti problemas (iskaitant nukrypimus nuo planuotos darbu eigos), nustatytas atliekant periura, inspektavima ar kitus procesus, tu problemu prigimti bei prieastis, ir tas problemas paalinti.

    45. 5 paskaita 45 Disciplinos turinys Organizaciniai procesai valdymas: kitu procesu iniciavimas, planavimas, vykdymas, kontrole, vertinimas ir ubaigimas, infrastrukturos kurimas ir palaikymas: kitiems procesams vykdyti reikalingu salygu sudarymo procesas, procesu tobulinimas: kitu procesu matavimo, kontroles vertinimo ir gerinimo procesas, apmokymas (training): procesas, kuriuo siekiama, kad kitus procesus vykdantys asmenys igytu tam reikalingas inias bei igudius.

    46. 5 paskaita 46 Disciplinos turinys Artefaktai PS ininerijos procesais kuriamos eios artefaktu grupes: preliminariniai dokumentai: tikslu specifikacijos, poreikiu specifikacijos, verslo modeliai ir t.t.; techniniai sistemos apraai: reikalavimu specifikacijos, projektines specifikacijos, kodas, vartotojo dokumentacija; sistemos mazgai: posistemiai, moduliai, duomenu bazes ir t.t.; sistemos ruoiniai (distributive versions): tai, i ko generuojamos veikiancios sistemos; galutiniai programiniai produktai: veikiancios sistemos; pagalbine mediaga: planai, uduociu apraai, ataskaitos ir t.t.

    47. 5 paskaita 47 Disciplinos turinys Idealizacijos PS ininerijoje, kaip ir kitose mokslinese disciplinose, daromos tam tikros idealizuotos (neatitinkancios tikroves) prielaidos, apie tai, kaip PS ininerijos procesai vyksta praktikoje: galima ialdyti sistemos reikalavimus, galima sukurti neturincius klaidu artefaktus, galima sumodeliuoti sistemos elgsena trykiu metu, imanoma surinkti pakankamai duomenu artefaktams vertinti.

    48. 5 paskaita 48 Kurso ivadas 15 dalis. Principai ir paradigmos

    49. 5 paskaita 49 Principai ir paradigmos Baziniai PS ininerijos principai turiniu atskyrimo (concern separation) principas, dekompozicijos principas, juodosios dees (black box) principas, abstrakcijos principas, unifikavimo (uniformity) principas, strukturizavimo principas, sistemu atvirumo principas, interfeisu komfortikumo principas, metaforizavimo principas, reaktyvumo (agency) principas.

    50. 5 paskaita 50 Principai ir paradigmos

    51. 5 paskaita 51 Principai ir paradigmos Turiniu atskyrimo principas Taisykle: PS turi buti taip projektuojamos ir konstruojamos, kad dalykines srities konceptai turetu sistemoje tiesioginius atitikmenis. Sistemos daliu saveika turi tiksliai atspindeti tu konceptu ryius tai reikia, kad PS turi buti kuriama remiantis atitinkamos dalykines srities (verslo) koncepciniu modeliu, i taisykle i tiesu yra dalinis turiniu atskyrimo principo atvejis, ji yra dar vadinama konceptualizavimo principu, bendruoju atveju turiniu atskyrimo principo formuluote yra gerokai bendresne.

    52. 5 paskaita 52 Principai ir paradigmos Turiniu atskyrimo principas Konceptualizavimo principa pasiule Edward Yourdan ir Larry L. Constantine knygoje Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design (1979) vadovaujantis iuo principu, yra enkliai sumainamos pastangos, reikalingos PS realizuoti, priiureti ir perdaryti.

    53. 5 paskaita 53 Principai ir paradigmos Turiniu atskyrimo principas PS realizavimo katai yra maesni tuomet, kai sprendiamos problemos dalys yra aikiai atskirtos viena nuo kitos, aprepiamos, sprendiamos nepriklausomai viena nuo kitos. PS prieiura supaprasteja tuomet, kuomet tos sistemos dalys atitinka sprendiamos problemos dalis, yra aprepiamos, gali buti keiciamos nepriklausomai viena nuo kitos.

    54. 5 paskaita 54 Principai ir paradigmos Turiniu atskyrimo principas Sistemos reininerija supaprasteja, kuomet sistemos struktura atitinka sprendiamos problemos struktura, sistemos dalis galima keisti nepriklausomai viena nuo kitos.

    55. 5 paskaita 55 Principai ir paradigmos Dekompozicijos principas Dekompozicija tai procesas, kuriuo dideles problemos suskaidomos i maesnes, lengviau aprepiamas dalines problemas. Motyvacija: dideles problemas yra daug sunkiau spresti negu maas. Daug lengviau parayti dvi 500 eiluciu programas negu viena 1000 eiluciu programa.

    56. 5 paskaita 56 Principai ir paradigmos Dekompozicijos principas

    57. 5 paskaita 57 Principai ir paradigmos Dekompozicijos principas Taisykle Visus sudetingus PS ininerijos procesais kuriamus objektus reikia skaidyti i kiek galima paprastesnes sudetines dali (modulius) ir procesa, kuriuo kuriamas objektas, taikyti kiekvienam moduliui atskirai. Toks skaidymas vadinamas dekomponavimu. Nagrinejamo proceso poiuriu visi moduliai turi buti vieno lygmens. Jie taip pat turi buti nepriklausomi, t.y. tokie, kad, atlikus norimus veiksmus su kiekvienu i ju atskirai ir sujungus tokiu budu gautus rezultatus i viena visuma, butu gautas pageidaujamas galutinis rezultatas. Procesas turi buti kartojamas tol, kol objektas nera suskaidytas i primityvys, t.y. lengvai suvokiamas ir neskaidias dalis Dalys vadinamos neskaidiomis, jei ju negalima toliau skaidyti, nepaeidiant ju savarankikumo Programuojant C kalba, sistema dekomponuojama i funkcijas ir abstrakcius duomenu tipus. Programuojant C++ arba Java kalba, sistema dekomponuojama i klases.

    58. 5 paskaita 58 Principai ir paradigmos Dekompozicijos principas Kad dekompozicija butu efektyvi, problemos dalys turi buti kiek galima labiau nepriklausomos (turiniu atskyrimo principas) Tai nereikia, kad dalys turi apskritai nepriklausyti viena nuo kitos. Reikia tiktai ivengti nebutinu vienos dalies priklausomybiu nuo kitos dalies detaliu. Tai ypac svarbu grupiniuose projektuose, kur skirtingomis problemos dalimis usiimineja skirtingi mones. Kiekvienas programuotojas turi susitelkti i ta problemos dali, kuria jis usiimineja, nesirupindamas kitu daliu sprendimu.

    59. 5 paskaita 59 Principai ir paradigmos Dekompozicijos principas Geras projektavimas tai gebejimas skaidyti sistema i modulius ir organizuoti tu moduliu saveika! Tai reikia, kad projektuotojas turi gebeti taip suskaidyti problema i dalines problemas, kad kiekviena daline problema butu galima spresti atskiru moduliu.

    60. 5 paskaita 60 Principai ir paradigmos Dekompozicijos principas Norint pritaikyti dekompozicijos principa, butina atsakyti i iuos klausimus: Kaip skaidyti problema? Kokie problemos aspektai turi buti realizuoti vienoje sistemos dalyje, o kokie - skirtingose? Kaip sieti sistemos dalis tarpusavyje ir kaip nuspresti, kurios dalys turi buti susietos viena su kita, o kurios ne? Kokia dalis vadinama maa? Kada baigti sistemos dekomponavimo procesa?

    61. 5 paskaita 61 Principai ir paradigmos Dekompozicijos principas Atsakymai Stipriai perpintos problemos dalys turi buti realizuojamos vienoje sistemos dalyje Perpinti turiniai negali buti atskirti vienas nuo kito! Nesusijusios problemos dalys turi buti realizuojamos skirtingose sistemos dalyse Ten, kur tai imanoma, turinius butina atskirti!

    62. 5 paskaita 62 Principai ir paradigmos Dekompozicijos principas Atsakymai Mes siekiame taip organizuoti sistema, kad nei viena sistemos dalis nebutu didesne, negu butina atitinkamai problemos daliai ispresti. Sistema butina taip organizuoti, kad tarp jos dalys nebutu siejamos tokiais ryiais, kurie neatitinka problemos dalis siejanciu ryiu.

    63. 5 paskaita 63 Principai ir paradigmos Dekompozicijos principas Kompiuterines programos yra sudarytos i operatoriu programos tekste operatoriai eina vienas po kito tam tikra seka toks operatoriu sutvarkymas vadinamas leksiniu sutvarkymu poiuris, kad programa yra grietai sutvarkyta operatoriu seka, vadinamas klasikine arba algoritmine programos traktuote, taigi, operatorius galima traktuoti kaip programos komponentus, o ju sutvarkyma - kaip programos strukturizavimo ryi.

    64. 5 paskaita 64 Principai ir paradigmos Dekompozicijos principas Idemiai analizuojant bet kurios programavimo kalbos operatorius, nesunku pastebeti, kad kai kurie i ju yra skirti agreguoti (apjungti) kitus programos operatorius i didesnius vienetus (agregatus) tokie operatoriai vadinami operatoriniais skliaustais daugelyje programavimo kalbu kaip operatoriniai skliaustai yra vartojami operatoriai Begin ir End.

    65. 5 paskaita 65 Principai ir paradigmos Dekompozicijos principas Vienas i operatoriniu skliaustu ivedimo tikslu yra siekis apibreti vardu galiojimo sriti (vardai tai nuorodos i kokius nors objektus, kuriais manipuliuoja programa) Agregatas taip pat gali tureti su juo susieta varda, naudojant kuri operatoriniais skliaustais apskliaustu operatoriu visuma galima manipuliuoti kaip vienu objektu tiek agregato viduje, tiek ir jo ioreje esanciuose operatoriuose galima, panaudojant agregato varda, daryti nuorodas i ta agregata

    66. 5 paskaita 66 Principai ir paradigmos Dekompozicijos principas . Function F() Begin Define X Use X End Call F() .

    67. 5 paskaita 67 Principai ir paradigmos Dekompozicijos principas Bet kuri programa tai grietai apibreta, sutvarkyta operatoriu ir ju agregatu seka, apibreianti, apraanti arba kaip nors kitaip nusakanti, kaip reikia vykdyti kokia nors konkrecia uduoti programos tekste operatoriai agreguojami, apjungiant juos i grupes, vadinamas leksiniais agregatais pradinio teksto moduliais vadinami turintys vardus leksiniai agregatai Monolitine vadinama nemoduliarizuota programa, t.y. tokia programa, kuri nera suskaidyta i modulius, kurioje visi operatoriai yra glaudiai perpinti vienas su kitu Dirbtinis gatavos programos suskaidymas i modulius programos sudetingumo niekaip nesumaina, nes yra paeidiamas turiniu atskyrimo principas. PS nuo pat pradiu turi buti projektuojama vadovaujantis turiniu atskyrimo ir dekompozicijos principais.

    68. 5 paskaita 68 Principai ir paradigmos Dekompozicijos principas Reziume Kuriant dideles PS, reikia: jas dekomponuoti i komponentus, specifikuoti kiekvieno interfeiso elgsena ir jo interfeisa, kiekviena komponenta kurti ir testuoti atskirai; komponentus sujungti i bendra sistema tiktai po to, kai jie visi yra baigti testuoti.

    69. 5 paskaita 69 Principai ir paradigmos Dekompozicijos principas Reziume Privalumai: Programuotojas usiimineja vieno komponento detaliu projektavimu. Nuoalyje lieka deimtys kitu komponentu su imtais savo detaliu, apie kurias jam nereikia galvoti projektuojant ir programuojant savaji komponenta. Tai kitu programuotoju rupestis.

    70. 5 paskaita 70 Principai ir paradigmos Juodosios dees (black box) principas Juodosios dees savoka pasiskolinta i kibernetikos Juodoji dee tai tokia sistema (arba komponentas), apie kuria yra inoma: jos ieiga, jos ieiga, kaip ieiga priklauso nuo ieigos, bet nieko neinoma apie tai, kas vyksta jos viduje dee yra juoda, nes negalima pamatyti, kas dedasi jos viduje

    71. 5 paskaita 71 Principai ir paradigmos Juodosios dees principas Juodosios dees principas yra vienas i galingiausiu ininerijos principu. Juodoji dee tai tokia sistema, kuria galima naudotis, nieko neinant apie jos realizavimo buda!

    72. 5 paskaita 72 Principai ir paradigmos Juodosios dees principas Didioji dalis sistemu, kuriomis mes naudojames kasdieniniame gyvenime, yra juodosios dees paprastam vairuotojui automobilis yra juodoji dee, transformuojanti degalus bei ieiga, pateikiama naudojantis vairu, greiciu dee ir stabdiais, i judejima norimu greiciu norima kryptimi; radijas, televizorius, mikrobangine krosnele, skalbimo maina visa tai yra juodosios dees.

    73. 5 paskaita 73 Principai ir paradigmos Juodosios dees principas Dekompozicija grindiama skaldyk ir valdyk strategija. Ji igalina dirbti su kiekviena sistemos dalimi savarankikai. Dekomponuojant, siekiama problema suskaidyti i nepriklausomas subproblemas. Juodosios dees principas naturaliai iplecia ta tiksla Kiekviena juodaja dee galima realizuoti nepriklausomai nuo kitu.

    74. 5 paskaita 74 Principai ir paradigmos Juodosios dees principas Programikai realizuotu juoduju deiu charakteristikas galima suskirstyti i dvi grupes: statines, dinamines. PS yra juodoji dee tokiu mastu, kokiu jos elgsena galima nusakyti ieigos (pradiniu duomenu), ieigos (rezultatu) ir jas siejancio ryio terminais.

    75. 5 paskaita 75 Principai ir paradigmos Juodosios dees principas Juodoji dee yra paprasciausia i visu galimu abstrakciju, pasinaudojant kuria galima aprayti sistemos veikima, nieko nepasakant apie jos realizavima. Juodaja dee galima specifikuoti nurodant tik jos paskirti, pavyzdiui, A noriu, kad nurodyta forma butu upildoma duomenimis i nurodyto failo". Visos detales kaip tai bus realizuojama paslepiamos juodosios dees viduje.

    76. 5 paskaita 76 Principai ir paradigmos Juodosios dees principas Juodosios dees principas igalina paprastai ir isamiai specifikuoti modulius, nurodant pradinius duomenis ir ju altinius (i kur imti) bei rezultatus ir ju talpyklas (kur padeti)

    77. 5 paskaita 77 Principai ir paradigmos

    78. 5 paskaita 78 Principai ir paradigmos

    79. 5 paskaita 79 Principai ir paradigmos Juodosios dees principas Kadangi juodosiomis deemis gali naudotis neinant ir nesuprantant ju realizacijos, projektuojant sistema jomis galima naudotis kaip koncepcinio lygmens tos sistemos komponentais.

    80. 5 paskaita 80 Principai ir paradigmos Juodosios dees principas Taisykle: Jei, projektuojant sistema, prisireikia kokios nors funkcijos ar galimybes, apibrekite ja kaip juodaja dee ir toliau naudokites ta dee, kol kas nesirupindami apie tai, kaip ji bus realizuota Daniausiai, kiekviena juodaja dee galima realizuoti, pasinaudojant kitomis juodosiomis deemis. emiausiojo lygmens juodosios dees turi buti realizuotos tiesiogiai, t.y. paraant ju koda.

    81. 5 paskaita 81 Principai ir paradigmos Juodosios dees principas Konstruokite PS taip, kaip jus konstruotumete, pavyzdiui, automobili: nuspreskite, kokiu komponentu jums prireiks, specifikuokite kiekviena komponenta kaip juodaja dee, nusipirkite arba sukurkite komponentus, tenkinancias tas specifikacijas prie jungdami i sistema, atlikite isamu kiekvieno komponento testavima, tobulindami sistema, komponentus keiskite kitais, geresniais komponentais, tenkinanciais tas pacias specifikacijas.

    82. 5 paskaita 82 Principai ir paradigmos Juodosios dees principas iurint i iores, juodosios dees yra labai paprastos, todel jas nesunku kombinuoti viena su kita. Taciau, tai teisinga tik tuo atveju, jei juodaja dee nusakoma abstrakcija yra prasminga Turi buti apibretas aikus ieigos ir ieigos ryys. Daniausiai, ta padaryti nera paprasta, nes reikia atmesti daugybe realizacinio pobudio detaliu, kurios neturi nieko bendro su abstrakcija (t.y. reikia atskirti turinius). Ieigai turi priklausyti tik tai, ko tikrai reikia ieigai gauti.

    83. 5 paskaita 83 Principai ir paradigmos Juodosios dees principas Pagrindinis testas yra toks: ar paprasta nusakyti juodosios dees paskirti? Funkcinems deems, klausiama, ar galima aprayt juodosios dees paskirti veiksmaodiu (dees pavadinimas), o jos ieigos ir ieigos parametrus daiktavardiais. Objektines dees atveju, turi buti paprastai nusakoma, kas ivyks su objektu, gavus bet kuri juodosios dees apdorojama praneima. Kvieciantysis modulis kvieciamaji moduli visuomet turi traktuoti kaip juodaja dee!

    84. 5 paskaita 84 Principai ir paradigmos Juodosios dees principas Informacijos maskavimo (information hiding) principas yra dalinis juodosios dees principo atvejis Jis formuluojamas taip: moduliu (funkciju, objektu) realizavimo detales (duomenu strukturos, vidines proceduros) turi buti pasleptos, nematomos ioriniam vartotojui, inkapsuliuotos modulio viduje. Tai galinga programavimo technika, be kita ko, padedanti ymiai sumainti programos sudetinguma.. Vienas i pagrindiniu informacijos maskavimo mechanizmu yra duomenu strukturu inkapsuliacija. WebopediaWebopedia

    85. 5 paskaita 85 Principai ir paradigmos Abstrakcijos principas Stengiantis dorotis su sudetingumo, PS yra projektuojamos (o kartais ir realizuojamos) sluoksniais Pavyzdiui, gali pasitaikyti, kad projektuojant PS susiduriama su kokiais nors tos sistemos aspektais, kuriu negalima vienareikmikai priskirti nei duomenu strukturoms, nei algoritmams. Idealiu atveju, butu gerai, kad, projektuodamas koda, programuotojas galetu nuo tu aspektu atsiriboti, nekreipti i juos demesio.

    86. 5 paskaita 86 Principai ir paradigmos Abstrakcijos principas Abstrakcija gaunama ignoruojant neesmines detales, paliekant tiktai esminius ko nors aspektus detales ignoruojamos tam, kad butu galima mastyti stambiu planu, sutelkti demesi i esminius dalykus abstrakcija tai mastymo procesas, naudojamas apibendrinti atskirus, dalinius atvejus

    87. 5 paskaita 87 Principai ir paradigmos Abstrakcijos principas Abstrahavimasis tai apibendrinimo procesas. Jo metu iekoma panaumu tarp daiktu. Abstrakcijos gaunamos jungiant panaius daiktus i grupes.

    88. 5 paskaita 88 Principai ir paradigmos Abstrakcijos principas Pavyzdiui, abstrakcija apmoketos saskaitos yra naudinga tiems, kas nori kalbetis, nevartodami terminu saskaitos iraymas, pinigu gavimas, apmoketos paslaugos, banko pavedimas ir pan. Terminai saskaitos iraymas, pinigu gavimas, apmoketos paslaugos, banko pavedimas yra emesnio lygmens abstrakcijos.

    89. 5 paskaita 89 Principai ir paradigmos Abstrakcijos principas Abstrakcijos lygmuo tai sudetingumo, kuriuo mes nagrinejame sistema, lygmuo. Kuo auktesnis abstrakcijos lygmuo, tuo maiau jame lieka detaliu. Kuo emesnis abstrakcijos lygmuo, tuo jis yra detalesnis. Aukciausias abstrakcijos lygmuo yra pati sistema. Vienetu emesni lygmeni sudaro sistemos komponentai, pati emiausia lygmeni programu kodas ir duomenys .

    90. 5 paskaita 90 Principai ir paradigmos Abstrakcijos principas Taisykle: Kiekviena PS ininerijos procesa bet kuriam juo kuriamam objektui taikyk iteratyviai, kiekvienoje iteracijoje nagrinedamas objekta vis didesniu detalumu ir ignoruodamas tas detales, kurios nera svarbios to nagrinejimo lygmens (t.y. einamosios iteracijos) tikslu poiuriu.

    91. 5 paskaita 91 Principai ir paradigmos Abstrakcijos principas Bet kuri sistema turi keleta abstrakcijos lygmenu Programu sistemose abstrakcijos lygmenys daniausiai yra tapatinami su moduliu lygmenimis (t.y. jie ilieka veikiancioje sistemoje) Taciau kartais abstrakcijos lygmenys esti tik projektineje dokumentacijoje (t.y. veikiancioje sistemoje ju nebelieka).

    92. 5 paskaita 92 Principai ir paradigmos

    93. 5 paskaita 93 Principai ir paradigmos Abstrakcijos principas Nuosekliu tikslinimu (stepwise refinement) principas yra specialus abstrakcijos principo atvejas Nuoseklus patikslinimai - tai paingsninis procesas, taikant kuri yra imama programos (modulio) funkcija ir dekomponuojama i subfunkcijas. Tesiant i procesa, galu gale yra gaunami reikiamos programos (modulio) kodo operatoriai. Tai iteratyvusis procesas, kurio kiekvienoje iteracijoje tyrime vis detalesni ir detalesni programos teksta. Dekomponuodami i vis smulkesnes ir smulkesnes subfunkcijas, mes vis tikslau ir tiksliau uraome sprendiamos problemos sprendimo algoritma, t.y. ingsnis po ingsnio atliekame nuoseklius algoritmo tikslinimus.

    94. 5 paskaita 94 Principai ir paradigmos Nuosekliu tikslinimu principas Pavyzdys Patikslinti Tikrinti ar neturi skolu: Skaityti iraa apie kita skaitytoja IF jei kokia nors knyga negrainta laiku Apdoroti skola Patikslinti Apdoroti skola: IF turi skolu = 0 Print praneima apie bauda ELSE IF turi skolu = 1 Print saskaita apmoketi u prarastas knygas ELSE apriboti naudojimasi skaitytojo bilietu ..

    95. 5 paskaita 95 Principai ir paradigmos Nuosekliu tikslinimu principas Dideles ir sudetingos programos gali tureti daug tikslinimo lygmenu Pradiniai patikslinimai yra labai bendri ir ne dayg ka skiriasi nuo specifikacijos, velesni yra vis labiau ir labiau panaus i galutin: programos koda Tarpiniuose lygmenyse operatoriai atitinka tam tikrus programus gabalus, bet tie gabalai dar yra nepakankamai detalizuoti, kad juos jau butu galima urayti kokia nors programavimo kalba. emiausiojo lygmens operatoriai yra transformuojami i kokios nors programavimo kalbos operatorius (arba ju sekas).

    96. 5 paskaita 96 Principai ir paradigmos Nuosekliu tikslinimu principas Taisykle: Pradek problemos nagrinejimu ir pasiulyk bendra problemos atakos plana, t.y. pacia bendriausia problemos sprendimo algoritma algoritmas turi buti sudarytas vadovaujantis funkciniu poiuriu, t.y. ireiktas uduociu, kurias atlikus bus gautas norimas rezultatas, terminais

    97. 5 paskaita 97 Principai ir paradigmos Nuosekliu tikslinimu principas Taisykle (tesinys): Po to, ingsnis po ingsnio, tikslink pasiulyta algoritma, dekomponuodamas uduotis i pouduotis Tikslinimas tesiamas tol, kol galu gale pouduotys yra ireikiamos pasirinktaja programavimo kalba Tikslinimo procesas susideda i 2 daliu: Analizes: kiekviename ingsnyje problemos sprendimo budas analizuojamas vis didesniu ir didesniu detalumu; Sintezes: lygiagreciai su analizes procesu ingsnis po ingsnio konstruojamas problemos sprendimo algoritmas.

    98. 5 paskaita 98 Principai ir paradigmos Nuosekliu tikslinimu principas Nuoseklius tikslinimus galima traktuoti kaip savoku hierarchijos konstravima Problemos sprendimas apraomas vartojant daugeliu budu realizuojamos problemines kalbos savokas. ingsnis po ingsnio tos savokos yra ireikiamos per paprastesnes ir galu gale yra pereinama prie kokios nors universaliosios programavimo kalbos savoku. Galima sakyti, kad itaip mes pasirinkome tam tikra problemines kalbos realizavimo buda ir realizavome ta kalba pasirinktosios programavimo kalbos priemonemis

    99. 5 paskaita 99 Principai ir paradigmos Abstrakcijos principas Kiti specialus abstrakcijos principo taikymo atvejai yra procedurine abstrakcija: moduliai suvokiami kaip proceduros, duomenu abstrakcija: sudetingos duomenu strukturos, valdymo abstrakcija: aukto lygmens programavimo kalbu valdymo strukturos, virtualiosios mainos: programikai realizuoti kompiuteriai, emuliuojami jusu realaus kompiuterio.

    100. 5 paskaita 100 Principai ir paradigmos Procedurine abstrakcija

    101. 5 paskaita 101 Principai ir paradigmos Procedurine abstrakcija Funkcija viena i svarbiausiu skaiciavimo moksliniu ideju Funkcija inkapsuliuoja koki nors algoritma. Tuo algoritmu programoje galima pasinaudoti ikvieciant funkcija (darant nuoroda i jos varda) ir pateikiant reikalingus pradinius duomenis (funkcines dees ieiga).

    102. 5 paskaita 102 Principai ir paradigmos Procedurine abstrakcija Procedurines abstrakcijos privalumai maskuojamos algoritmines detales, palengveja programos teksto skaitomumas, programuojant, sudaroma galimybe galvoti apie bendra algoritmo schema, atidedant jo realizavimo detales velesniam laikui, sukuriami daugkartinio panaudojimo komponentai (funkciju bibliotekos), kuriais galima pasinaudoti ir kitose programose, sudaroma galimybe tobulinti funkcijos realizacija, nedarant jokiu kitu pakeitimu programoje, vardai lokalizuojami funkcijos viduje, projektuoptojui suteikiama galimybe projektuoti funkciniu (leksiniu) agregatu terminais, palengveja PS eimu projektavimas.

    103. 5 paskaita 103 Principai ir paradigmos Procedurine abstrakcija Taisykle: Apibrek formalius parametrus, parayk atitinkama algoritma realizuojancios proceduros kuna. Suteik procedurai varda. Paslepk algoritmines detales nuo vartotojo, leisdamas jam kviesti procedura pagal varda.

    104. 5 paskaita 104 Principai ir paradigmos Duomenu abstrakcija Duomenu abstrakcija grindiama turiniu atskyrimo principu: grietai vienos nuo kitu yra atskiriamos abstrakciosios duomenu tipo savybes ir konkrecios to tipo realizavimo detales. Abstrakciosios savybes yra tos, kurias privalu inoti tam, kas tuo duomenu tipu nori pasinaudoti (duomenu tipo interfeisas). Realizavimo detaliu besinaudojanciajam inoti nereikia, jos gali buti keiciamos, pavyzdiui, norint padidinti programos darbo nauma. Tokie pakeitimai tampa lokalus, nedaro jokio poveikio likusiai programos daliai, nes jie nekeicia abstrakcios duomenu tipo elgsenos.

    105. 5 paskaita 105 Principai ir paradigmos

    106. 5 paskaita 106 Principai ir paradigmos Duomenu abstrakcija Duomenu abstrakcija duoda galimybe agreguoti duomenis ir dirbti tu agregatu terminais duomenu agregatas gali buti vel traktuojamas kaip primityvus objektas ir agreguojamas kartu su kitais objektais, itaip kuriant auktesnio lygmens duomenu agregatus.

    107. 5 paskaita 107 Principai ir paradigmos Duomenu abstrakcija Procedurinemis ir duomenu abstrakcijomis grindiamas objektinis projektavimas. Cia leidiama i viena visuma agreguoti funkcinius ir duomenu agregatus. itaip kuriamos objektines juodosios dees (objektai), realizuojancios vartotojo apibretus probleminio pobudio duomenu tipus.

    108. 5 paskaita 108 Principai ir paradigmos Duomenu abstrakcija Objektinio programavimo teorijoje, abstrakcija suprantama kaip galimybe apibreti objektus, representuojancius abstrakcius aktorius, galincius atlikti tam tikra darba, praneti apie savo busena, ta busena keisti, komunikuoti" su kitais tos pacios PS objektais.

    109. 5 paskaita 109 Principai ir paradigmos Duomenu abstrakcija Terminas inkapsuliacija objektiniame programavime reikia informacijos maskavima (t.y. objekto busenos detaliu nuslepima nuo vartotojo), bet, ipletus ankstyvosiose programavimo kalbose tureta duomenu tipo samprata, grieciau susiejus elgsena su duomenimis ir standartizavus skirtingu duomenu tipu saveikos budus, gautos abstrakcijos uuomazgos.

    110. 5 paskaita 110 Principai ir paradigmos Duomenu abstrakcija Ipletus abstrakcija operacijoms ir leidiant dinamikai keisti ju argumentu tipus, pereinama prie polimorfizmo. Pleciant abstrakcija prieinga kryptimi, i tipu ar i klasiu vidu, gauname delegavima ir paveldejima. Kol kas terminija cia nera standartizuota ir skirtingose objektinese kalbose terminai polimorfizmas, paveldejimas ir delegavimas gali buti suprantami iek tiek skirtingai.

    111. 5 paskaita 111 Principai ir paradigmos Duomenu abstrakcija Abstraktieji duomenu tipai (ADT) tai matematines duomenu ir ant tu duomenu apibretu operaciju specifikacijos. Jie yra abstraktus ta prasme, kad demesys sutelkiamas i operacijas, ignoruojant ju realizavimo detales. Realizuojant programoje, ADT pateikia interfeisus, maskuojancius ju realizavima.

    112. 5 paskaita 112 Principai ir paradigmos Duomenu abstrakcija Tipiniai ADT pavyzdiai Eilute Saraas Stekas (deklas) Eile Kompleksinis skaicius

    113. 5 paskaita 113 Principai ir paradigmos Duomenu abstrakcija Yra, nors ir gana subtilus, skirtumas tarp abstraktaus duomenu tipo ir jam realizuoti naudojamos duomenu strukturosThere is a distinction, although sometimes subtle, between the abstract data type and the data structure used in its implementation. Pavyzdiui, ADT Saraas galima realizuoti masyvu arba susiejant sarao elementus nuorodomis. ATD Saraas turi tiksliai apibretas operacijas (prideti elementa, imesti elementa ir t.t.), o nuorodomis susieti sarao elementai (saraine duomenu struktura) yra viena i duomenu strukturu, panaudojant kuria galima gana paprastai tas operacijas realizuoti. Kadangi ATD Saraas labai danai yra itaip realizuojamas, tai pradedama tuos dalykus painioti ir pradedama saraines duomenu strukturas vadinti saraais. Taciau tai yra skirtingi dalykai.

    114. 5 paskaita 114 Principai ir paradigmos Duomenu abstrakcija Reziume Duomenu strukturos konstruojamos remiantis sandorio principais (isipareigojama nekeisti interfeiso) Su duomenu strukturomis yra susijamos jomis manipuliuoti skirtos proceduros Paprastai rekursyviosios proceduros slepia rekursyviasias duomenu strukturas Konstruodamas duomenu abstrakcijas: Galvok apie efektyvia duomenu organizacija. Galvok apie tai, kaip ta organizacija paslepsi po duomenimis manipuliuojanciomis proceduromis. Paslepk, vadovaudamasis sandorio principu, abstrakcijos realizavimo detales.

    115. 5 paskaita 115 Principai ir paradigmos Valdymo abstrakcija Maininese kalbose valdymo strukturos yra labai primityvios ir konkrecios. FORTRAN, BASIC ir kitos ankstyvosios programavimo kalbos, i esmes, megdiojo maininiu kalbu valdymo strukturas. Neturint abstraktesniu valdymo strukturu, programose daroma daug klaidu ir negalima adekvaciai aprayti programos operatorius siejancius loginius ryius.

    116. 5 paskaita 116 Principai ir paradigmos Paprastas Basic kodo fragmentas: 160 IF I>= J GOTO 164 161 LET I = I+ 3 162 PRINT I 163 GOTO 160 164 LET K=5 Tas pats fragmentas Java kalba: while (i<j) { i = i+3; System.out.println( i ); } k = 5;

    117. 5 paskaita 117 Principai ir paradigmos akojimo strukturos if-then if-then-else switch Ciklai while do-while for .. Valdymo perdavimas goto exit return break continue call ..

    118. 5 paskaita 118 Principai ir paradigmos Virtualieji irenginiai Virtualieji irenginiai tai abstrakcijos, nuslepiancios nuo programu realiu irenginiu (spausdintuvu, disku ir kt.) veikimo detales. Virtualieji irenginiai realizuojami programikai programos, realizuojancios virtualiuosius irenginius, vadinamos programinemis irenginiu jungtimis (drivers). Duomenu baziu valdymo sistemos ir kai kuri kita PI taip pat gali buti traktuojami analogikai kaip irenginiai, t.y. ju realizacines detales taip pat galima paslepti, sukuriant atitinkamas programines jungtis (drivers).

    119. 5 paskaita 119 Principai ir paradigmos Virtualioji maina Virtualioji maina tai abstrakcija, realizuojama panaudojant "realia" TI ir "realia" operacine sistema. Operacine sistema (Windows, Linux ir kt.) taip pat yra virtualioji maina. Virtualios mainos yra kuriamos panaudojant realia aparatura (procesorius, atminti, periferinius irenginius, tinklu iranga), kiekviena i ju veikia nepriklausomai nuo kitu tame paciame kompiuteryje veikianciu kitu virtualiuju mainu. I karto gali veikti kelios tos pacios mainos kopijos. Virtualiosios mainos leidia programoms ignoruoti TI ypatumus ir vykdyti tas programas skirtingose platformose, jei jos emulioja ta pacia virtualia maina. Be to, itaip viename realiame kompiuteryje gali egzistuoti skirtingos, tarpusavyje nesuderinamos, programavimo ar skaiciavimo aplinkos.

    120. 5 paskaita 120 Principai ir paradigmos Virtualioji maina Virtualioji maina realizuojama programikai, itaip paprastai realizuojamas apatinis PS abstrakcijos lygmuo. Virtualioji maina realizuojama panaudojant kitas abstrakcijas (procedurine, duomenu, valdymo, irenginio). Ji nuslepia nuo PS konkrecios platformos detales. Keliant PS i kita platforma, pakanka perrayti tik jos virtualiaja maina. Auktesni lygmenys nekinta, nes nekinta abstrakciosios mainos interfeisai (jos API).

    121. 5 paskaita 121 Principai ir paradigmos Virtualioji maina Pavyzdiai: Assemblerio maina C++ maina Buhalteriniu skaiciavimu maina

    122. 5 paskaita 122 Principai ir paradigmos Virtualioji maina Reziume Virtualioji maina yra programikai sukuriama fikcija. Ji gali buti kuriama panaudojant ne tik realia, bet ir kita abstrakcia maina. Virtualioji maina vykdo jai paraytas programas panaiai kaip ir realus kompiuteris. Taigi, programa neino, kad ja vykdo virtuali maina ir tuo nesidomi. Pakol virtuali maina reaguoja i programos veiksmus kaip reali maina (ilieka juodaja dee), ja galima traktuoti kaip realu kompiuteri.. Virtualiosios mainos ir realaus kompiuterio interfeisa galima traktuoti kaip API. i netradicini API sudaro pertraukimai, kreipiniai i BIOS ir I/O prieigas (ports). Jei Windows gali kokiu nors budu tobulai emuliuoti toki API, programa veikianti Windows mainoje elgsis taip, tarsi ja vykdytu realus kompiuteris.

    123. 5 paskaita 123 Principai ir paradigmos Unifikavimo (uniformity) principas Unifikavimas tai nebutinu skirtumu (nevienodum.) paalinimas. Tai taip pat svarbus PS ininerijos principas. Jis sako, kad PS turi buti taip projektuojama ir konstruojama, kad ji butu vienalite. Tam turi buti numatyti atitinkami standartai. Taisykle: Taikyk visiems tos pacios ruies artefaktams (moduliams, komponentams, dokumentams ir t.t.) vienus ir tuos pacius standartus.

    124. 5 paskaita 124 Principai ir paradigmos Unifikavimo principas Beasmenis (egoless) programavimas yra specialus unifikavimo principo taikymo atvejas mogikasis faktorius diktuoja tam tikras kodo raymo taisykles Pramonines PS kuria grupes, su tuo paciu kodu skirtingais laiko momentais dirba skirtingi mones; Grupes nariai turi skaityti vieni kitu koda, ji vertinti; Visa tai reikia, kad kodavimo negalima palikti asmeninei kiekvieno programuotojo nuoiurai. Kodas turi buti nuasmenintas, raomas vadovaujantis vidiniais firmos standartais.

    125. 5 paskaita 125 Principai ir paradigmos Strukturizavimo principas Taisykle: Visus artefaktus konstruok i tipizuotu, patikimu elementu, kuriu savybes yra gerai inomos ir patikrintos. Pavyzdys: D-strukturos Irodyta, kad bet kuriai loginio pobudio problemos sprendimui aprayti pakanka iu valdymo abstrakciju: sekos, akojimosi ir ciklo ia teorema irode matematikai Bohm ir Jacopini (1966)

    126. 5 paskaita 126 Principai ir paradigmos Sistemu atvirumo principas Taisykle: Konstruok sistemas tik i komponentu, tenkinanciu atviruju sistemu standartus is principas riboja juoduju deiu naudojima tam tikra iu deiu (atviruju sistemu) klase Atviruju sistemu privalumai bet kurio komponento realizacija galima keisti (nekeiciant jo kontraktinius isipareigojimus apraancios specifikacijos); vienoje sistemoje galima kombinuoti skirtingu gamintoju gaminamus komponentus.

    127. 5 paskaita 127 Principai ir paradigmos Interfeiso komfortikumo principas Visi PS vartotojo interfeisai turi buti komfortiki, t.y. jie turi buti pritaikyti konkretiems vartotojams (user-friendly), adaptyvus, lengvai panaudojami (easy to use) kuo maiau varginti vartotojus ir nesukelti jiems psichologinio diskomforto Sakoma, kad interfeisas yra pritaikytas konkretiems vartotojams (user-friendly), jei jis taip suprojektuotas, kad yra intuityviai suprantamas vidutiniam vartotojui ir aikina pats save (self-explanatory). Sakoma, kad interfeisas yra lengvai panaudojamas (easy to use), jei juo naudojantis i vartotojo nereikalaujama jokiu bereikalingu veiksmu.

    128. 5 paskaita 128 Principai ir paradigmos Metaforizavimo principas Bendruoju atveju Metafora odio reikmes perkelimas nuo vieno dalyko i kita, siekiant antraji apibudinti. Metafora kartais vadinama pasleptu palyginimu, tai lyginimas be jungiamuju odeliu, nurodanciu gretinimo motyvus. Pvz.: laivo nosis, dienos senatve, gyvenimo saulelydis

    129. 5 paskaita 129 Principai ir paradigmos Metaforizavimo principas PS kontekste Metafora tai vieno objekto idejos nusakymas kito, gerai inomo objekto terminais Metafora vieno objekto esme nusakoma tapatinant ja su tam tikromis kito objekto savybemis. Taisykle: Konstruok vartotojo interfeisa kaip dalykines srities metafora, sudaryta atsivelgiant i vartotoju mentaliteta, tradicija ir patirti.

    130. 5 paskaita 130 Principai ir paradigmos Metaforizavimo principas Metaforos yra tam tikros abstrakcijos. Jos naudojamos kaip priemone susieti tokius techninius ir sudetingus dalykus kaip PI su vartotojo kasdieninio pasaulio realijomis Panaudojant metaforas, yra konceptualizuojami ir vizualizuojami dalykines srities objektai ir su jais atliekami veiksmai Pavyzdys Saraas gali buti panaudotas kaip metafora masyvui aprayti. Tai i karto sukelia vartotojui mintis, kad jis gali su tuo objektu atlikti tam tikrus veiksmus (irayti i saraa, ibraukti i jo). Saraas gali buti vizualizuotas kaip vartotojui iprastas popierinis saraas.

    131. 5 paskaita 131 Principai ir paradigmos Metaforizavimo principas Metaforos ypac naudingos, jei dalis ar visi vartotojo interfeise vaizduojamu objektu vartotojams yra nauji ir neiprasti (pavyzdiui, tokie dalykai, kaip failas, serveris) Gera metafora padeda vartotojui susieti jam neinomus objektus su inomais Geru metaforu pavyzdiai: Darbo stalo metafora (pvz., MS Windows), istaigos metafora (pvz., MS Office), e-pato metafora (pvz., Pegasus Mail), kompiuteriniu lenteliu metafora (pvz., MS Excel), lenteles metafora (reliacinese DB), formos metafora.

    132. 5 paskaita 132 Principai ir paradigmos Metaforizavimo principas Naudojant istaigos metafora, vartotojams neiprasti kompiuteriniai objektai (failas, failu katalogas, OS funkcija, API ir pan.) PS interfeise metaforizuojami, panaudojant jiems iprastus kancialerinius objektus (dokumentas, pieinys, aplankas, ir kt.) Panaiai, e-pato metaforoje naudojami su tradiciniu patu sietini objektai ir veiksmai (laiku deute, laikas, isiusti, atsakyti ir pan.)

    133. 5 paskaita 133 Principai ir paradigmos Metaforizavimo principas Kartais projektuotojai teigia, kad ju suprojektuotame interfeise apskritai nera metaforu. Taciau itaip buti negali. Kokia nors metafora visuomet panaudojama. Kitas dalykas, ar projektuotojas ja parinko samoningai, ar ne ir ar ji yra tinkamai parinkta. Problema ne tame, kad reikia naudoti metaforas, bet tame, kad jas reikia parinkti tinkamai ir kruopciai suprojektuoti!

    134. 5 paskaita 134 Principai ir paradigmos Metaforizavimo principas Rekomendacijos Isitikink, kad metafora atitinka vartotoju prielaidas Jei vartotojas kompiuterio ekrane mato, pavyzdiui, forma, jis i karto daro tam tikras prielaidas apie matomo daikto funkcionaluma ir apie tai, kaip tuo daiktu naudotis Vizualiai metafora nebutinai visuomet turi buti tiksli Pavyzdiui, kontorose naudojamuose languoto poperiaus lapuose nei eilutes, nei stulpeliai jokiu ymiu neturi. Realizuojant languoto popieriaus lapo metafora MS Excel tokios ymes sudetos ir tai teisinga, nes taip yra patogiau.

    135. 5 paskaita 135 Principai ir paradigmos Metaforizavimo principas Rekomendacijos Kuo metafora paprastesne, tuo ji geresne. Metaforu iekok kasdienineje vartotojo darbo aplinkoje Iekok ju, nagrinedamas kaip vartotojas vykdo uduotis ir kokiais objektais (irkles, klijai, kalkuliatorius, stalinis kalendorius ir kt.) jis naudojasi tai darydamas. Paprayk vartotoju ivertinti tavo parinktas metaforas!

    136. 5 paskaita 136 Principai ir paradigmos Metaforizavimo principas Rekomendacijos Daniausiai prisireikia daugiau nei vienos metaforos pavyzdiui, rengdamas ataskaita, vartotojas gali naudotis languoto popieriaus lapu kokiems nors tarpiniams skaiciavimams atlikti Metafora apimk ne tik vaizda, bet ir fukcionaluma Isami metafora apima ne tik objekta, bet ir su juo atliekamus veiksmus. Suvok, kokia metafora naudojiesi, projektuodamas interfeisa Projektuotojas privalo samoningai parinkti metafora ir ja suvokti iki smulkiausiu detaliu. Vartotojui tai nebutina. Jis gali sekmingai (ir efektyviai) naudotis interfeisu, apskritai nesuvokdamas, kad tas interfeisas yra metaforizuotas.

    137. 5 paskaita 137 Principai ir paradigmos Metaforizavimo principas Rekomendacijos Nepersistenk, besistengdamas vizualizuoti visus objektus Nevisuomet pieinys yra pranaesnis u teksta. Kartais pats geriausias budas pavaizduoti objekta yra ji aprayti odiais pavyzdiui, paprasciausias darbuotoju saraas geriau aprao padalini, negu pieinys, kuriame parodyti savo darbo vietose dirbantys tie patys darbuotojai

    138. 5 paskaita 138 Principai ir paradigmos Metaforizavimo principas Rekomendacijos Nepersistenk, besistengdamas pavaizduoti pieinyje visas realaus objekto detales Pakanka, kad metafora vartotojui primintu realaus pasaulio objekta ir jis ta objekta atpaintu pavyzdiui, e-pato programoje pakanka, kad gaunamu laiku deute tik primintu realia laiku deute. Negaik laiko, projektuodamas metaforos detales!

    139. 5 paskaita 139 Principai ir paradigmos Metaforizavimo principas Rekomendacijos Labai svarbu prisiminti, kad vartotojas nori matyti kaip skirtingus tuos objektus, kurie yra skiriami vykdant jo atliekamas uduotis, o ne tuos, kurie skirtingai realizuojami sistemoje! pavyzdiui, vartotojo poiuriu ataskaita ir atmintine gali buti visikai skirtingi objektai, nors PS ir vienas ir kitas gali buti realizuotas kaip tekstinis failas Metaforos konstruojamos analizuojant vartotojo uduotis ir jo vartojama terminija, o ne klasifikuojant PS objektus!

    140. 5 paskaita 140 Principai ir paradigmos Reaktyvumo (agency) principas Agentinis ryys sukuriamas tuomet, kuomet viena esybe igalioja kita esybe veikti jos vardu (pvz., verslo transakcijose) Taisykle: PS turi buti projektuojama kaip tikslingai veikiantis agentas. Tai reikia, kad sistema privalo nuolat analizuoti dalykines srities reikalu bukle ir tikslingai (arba bent jau i anksto numatytu budu) reaguoti i visas susidariusias nenormalias situacijas.

    141. 5 paskaita 141 Principai ir paradigmos Reaktyvumo principas Agentas suvokiamas kaip esybe, kuri, pasinaudodama savo sensoriais, geba stebeti savo aplinka ir kuri, panaudodama turimus efektorius, gali daryti tai aplinkai koki nors poveiki. Russel and Norvigs Autonominis agentas tai sistema, kuri yra situatizuota aplinkoje, yra tos aplinkos dalis, suvokia ta aplinka ir joje veikia. Franklin

    142. 5 paskaita 142 Principai ir paradigmos Reaktyvumo principas Agento juodosios dees modelis autonomine arba pusiau autonomine PS, vykdanti uduotis sudetingoje, dinamikai kintancioje aplinkoje. Ji apraoma funkcija f, kurios ieiga sudaro percepcijos (pojuciai) ir gaunami praneimai, o ieiga apraoma jos atliekamu veiksmu ir siunciamu praneimu terminais. I iores tiesiogiai atvaizdavimo f niekas nekontroliuoja. Mller, 1996

    143. 5 paskaita 143 Principai ir paradigmos

    144. 5 paskaita 144 Principai ir paradigmos Reaktyvumo principas Mes domemis sekmingai veikianciais rationaliais agentais (agentais veikianciais teisingai) ka reikia, kad racionalus agentas veikia sekmingai? agento sekme nusako jo efektyvumo matas problemos skirtingi sekmes kriterijai agentas gali veikti racionaliai, bet buti nenaudingas, nes neturi reikiamos informacijos

    145. 5 paskaita 145 Principai ir paradigmos

    146. 5 paskaita 146 Principai ir paradigmos Reaktyvumo principas Tikra reaktyvioji PS yra sistema, demonstruojanti refleksyvia (salyga-veiksmas) elgsena Pavyzdys e-pato sistema Pegasus Mail nuolat tikrina vartotojo pato deute ir rodo kiek joje yra neskaitytu inuciu.

    147. 5 paskaita 147 Principai ir paradigmos

    148. 5 paskaita 148 Principai ir paradigmos

    149. 5 paskaita 149 Principai ir paradigmos

    150. 5 paskaita 150 Principai ir paradigmos Reaktyvumo principas Reaktyviojoje sistemoje i anksto numatyta, kaip sistema turi reaguoti (kokiu veiksmu imtis) i kiekviena potencialiai galima situacija Sistemoje nera modeliuojama nei jos aplinka, nei PS, su kuriomis ji komunikuoja, todel reaktyvioji sistema negali prognozuoti savo veiksmu pasekmiu. Todel ji neturi ir galimybiu planuoti, koki veiksma geriau butu atlikti. Reaktyvioji sistema neatlieka jokiu iankstiniu samprotavimu. Ji paprasciausiai reaguoja i susidarancias situacijas i anksto numatytu budu.

    151. 5 paskaita 151 Principai ir paradigmos Reaktyvumo principas Proaktyvioji PS - tai sistema, kuri realizuoja savo tikslinga elgsena perimdama iniciatyva Proaktyvioji sistema neleidia susidaryti nepageidaujamoms situacijoms, i anksto imdamasi atitinkamu priemoniu. Planuojanti PS - tai proaktyvioji sistema, kuri proaktyviaja elgsena realizuoja panaudodama tikslu ir priemoniu samprotavimo metoda (means-end reasoning)

    152. 5 paskaita 152 Principai ir paradigmos

    153. 5 paskaita 153 Principai ir paradigmos

    154. 5 paskaita 154 Principai ir paradigmos

    155. 5 paskaita 155 Principai ir paradigmos

    156. 5 paskaita 156 Principai ir paradigmos Reaktyvumo principas Racionalius, tikslingus veiksmus atliekantis agentas turi naudotis ireiktiniu budu uduotu simboliniu modeliu, modeliuojanciu dalykine sriti (aplinka), jo gebamus atlikti veiksmus, tikslus, kuriu jam privalu siekti; nagrinedamas potencialias galimybes (alternatyvius tikslus), sprendia ka jam daryti ir isipareigoja siekti pasirinktuju tikslu; panaudodamas tikslu ir priemoniu samprotavimo metoda (means-end reasoning), sudarineja savo veiksmu planus (leistinu veiksmu grandines), kaip pasiekti pasirinktus tikslus ir galbut tuos planus optimizuoja arba naumo, arba laukiamos naudos poiuriu.

    157. 5 paskaita 157 Principai ir paradigmos

    158. 5 paskaita 158 Principai ir paradigmos

    159. 5 paskaita 159 Principai ir paradigmos

    160. 5 paskaita 160 Principai ir paradigmos Reaktyvumo principas Abstrakcijos lygmenys Objekto abstrakcija inkapsuliuoja duomenis ir algoritmus, kontroliuoja savo busena, kviecia kitu objektu metodus. Proceso (aktyvaus objekto) abstrakcija turi savo nuosava valdymo gija, gali demonstruoti tam tikra elgsena, kurios neicijavo joks kitas procesas.

    161. 5 paskaita 161 Principai ir paradigmos Reaktyvumo principas Abstrakcijos lygmenys Agento abstrakcija kontroliuoja savo elgsena, uprao kitus agentus atlikti jam reikalingus veiksmus, gali reaguoti i susidariusias situacijas i anksto numatytu budu, neleisti joms susidaryti arba reaguoti i jas vadovaujantis tikslingumo principu.

    162. 5 paskaita 162 Principai ir paradigmos Reaktyvumo principas PS kiekvienas modulis ir kiekviena moduliu grupe vykdo tam tikra fiksuota uduoti. Tai reikia, kad reguliavimo buda galima aprayti tiksliomis statinemis taisyklemis. Taigi, su reaktyviuoju agentu visuomet yra susiejama arba modulis arba moduliu grupe ir jam pavedama kontroliuoti to modulio (moduliu grupes) rezultatus. Kadangi reaktyviajam agentui reikia specifines su modulio kontekstu siejamos informacijos, tai jis veikia panaiai kaip valdymo ciklas.

    163. 5 paskaita 163 Principai ir paradigmos Reaktyvumo principas Tikslingas agentas gali analizuoti sudetingas situacijas, bet, bendruoju atveju, jis nepajegos tai daryti realaus laiko reimu, nes turi atlikti didelius ir sudetingus skaiciavimus. Paprastai, reaktyvu agenta valdo ir jo generuojama informacija apdoroja koks nors tikslingas agentas (valdantysis agentas).

    164. 5 paskaita 164 Principai ir paradigmos Reaktyvumo principas Projektavimas, nenaudojant reaktyvumo principo projektuotojas i anksto numato visas situacijas ir sistemos reakcijas i jas. Projektavimas, naudojant reaktyvumo principo projektuotojas projektuoja tokia sistema, kuri pati sprendia, ka reikia padaryti, kad arteti prie numatytu tikslu.

    165. 5 paskaita 165 Principai ir paradigmos Reaktyvumo principas Agentine PS ininerija (APSI) tai nauja PS kurimo paradigma, susiformavusi objektines PS ininerijos (OPSI) pagrindu. APSI akcentuoja PS autonomikuma, tarpusavio saveika, intelektualikuma ir proaktyvuma.

    166. 5 paskaita 166 Principai ir paradigmos

    167. 5 paskaita 167 Principai ir paradigmos PS ininerijos paradigmos PS ininerijos paradigmos tai skirtingi poiuriai i tai, kaip turi buti kuriama PS I principo, PS galima sukurti pasinaudojant bet kuria paradigma. Kuria paradigma rinktis, priklauso ir nuo vykdytoju igudiu, ir nuo kuriamos PS pobudio, ir nuo sandorio su usakovu pobudio ir nuo kitu konkretaus projekto ypatumu. Bet kuri i PSI paradigmu uduoda tiktai tam tikra principine PS kurimo schema

    168. 5 paskaita 168 Principai ir paradigmos PS ininerijos paradigmos Nei viena PSI paradigma neduoda projektuotojui jokiu atsakymu i jokius konkrecius klausimus. Ji yra tik kelrode vaigde, primenanti projektuotojui, kokius projektavimo sprendimus jis turi priimti.

    169. 5 paskaita 169 Principai ir paradigmos Populiariausios PS ininerijos paradigmos Paradigma i viraus emyn (top-down approach) Paradigma i apacios auktyn (bottom-up approach) Rieuto paradigma (bootstrap approach) Iteracine paradigma (prototyping) Evoliucinio kurimo paradigma (incremental development) Programu eimu paradigma (domain/application engineering) Komponentine paradigma (reuse-based development) Sintezes paradigma (formal development)

    170. 5 paskaita 170 Principai ir paradigmos Paradigma i viraus emyn (top-down) Taikant ia paradigma sistemos kurimas pradedamas jos vartotojo interfeisu projektavimu be to, nustatomi i iores stebimos sistemos elgsenos vertinimo kriterijai; kitaip tariant, PS traktuojama kaip juodoji dee; po to ingsnis po ingsnio judama emyn, kiekviename ingsnyje visu pirma nustatant, ka tame ingsnyje nagrinejami komponentai darys ir kokius interfeisus jie tures, ir tik po to pradedant galvoti, kaip reikia realizuoti ju elgsena (funkcijas) t.y. komponentai traktuojami kaip juodosios dees

    171. 5 paskaita 171 Principai ir paradigmos Paradigma i viraus emyn (top-down) Taikant ia paradigma projektavimas baigiamas nulipus iki kompiuterines platformos lygmens ir suformulavus kompiuterines technologijos reikalavimus, garantuojancius suprojektuotu interfeisu veikima ir norima sistemos elgsena. Taigi, vadovaujantis ia paradigma, galima apsisaugoti nuo vartotoju turimos PS vizijos ikraipymu, danai atsirandanciu kuriant sistemas kitais budais. Taciau, ir vadovaujantis ia paradigma, vartotoju vizija gali buti ikreipta, jei, kaip tai neretai atsitinka, analitikai iki galo neperpras vartotoju poreikiu.

    172. 5 paskaita 172 Principai ir paradigmos Paradigma i viraus emyn I viraus emyn paradigmoje intensyviai naudojami abstrakcijos ir dekompozicijos principai kiekvienas abstrakcijos lygmuo yra dekomponuojamas i komponentus (juodasias dees), kurie tikslinami emesniuose abstrakcijos lygmenyse Paradigma pritaikyta projektuotojams, gebantiems projektuoti komponentus, tenkinancius i anksto uduotas specifikacijas.

    173. 5 paskaita 173 Principai ir paradigmos Paradigma i viraus emyn Projektavimo sprendimai priimami vadovaujantis funkciniais kriterijais problema dekomponuojama i komponentus (modulius, duomenu strukturas ar kt.), komponentai realizuojami panaudojant emesnio lygmens (patikslintus) komponentus, kurie vis labiau ir labiau atspindi tikslines kompiuterines platformos ypatumus.

    174. 5 paskaita 174 Principai ir paradigmos

    175. 5 paskaita 175 Principai ir paradigmos Paradigma i apacios auktyn Taikant ia paradigma sistemos kurimas pradedamas nuo kompiuterines platformos kompiuterine platforma uduoda rinkini grietai apibretu savoku, per kurias galima ireikti sudetingesnes ivariu dalykiniu ir probleminiu sriciu savokas; po to konstruojamos vis abstraktesnes ir abstraktesnes savokos, kuriomis galu gale pavyksta aprayti PS sprendiama problema taigi, yra parenkama kompiuterine technologija, o po to sprendiama kaip ios technologijos priemonemis kurti reikiama PS.

    176. 5 paskaita 176 Principai ir paradigmos Paradigma i apacios auktyn Tai viena i populiariausiu PS kurimo paradigmu ios paradigmos populiarumas yra naturalus, nes naudojama technologija visuomet lemia tai, kokias PS yra imanoma sukurti; rinkoje pasirodantys naujo pobudio programiniai produktai daniausiai esti nauju kompiuteriniu technologiju pasirodymo pasekme. i paradigma neblogai tinka nedidelems PS kurti projektuojant sudetingesnes PS, del i anksto daromu technologiniu prielaidu daniausiai yra ikraipoma vartotoju turima PS vizija, nes suprojektuojami tokie sistemos interfeisai, kuriuos patogu realizuoti turimomis technologinemis priemonemis, o ne tokie, kurie butu patogus vartotojui.

    177. 5 paskaita 177 Principai ir paradigmos Paradigma i apacios auktyn Projektavimo i apacios auktyn paradigma grindiama intensyviu abstrakcijos principo ir konkatenacijos operacijos naudojimu kiekviename abstrakcijos lygmenyje, panaudojant konkatenacijos operacija, emesnio lygmens komponentai kombinuojami i sudetingesnius komponentus.

    178. 5 paskaita 178 Principai ir paradigmos Paradigma i apacios auktyn Projektavimas pradedamas nusakant bendrais bruoais sistemos programine realizacija t.y. nusprendiant, kokios proceduros ir duomenu strukturos galetu buti naudingos, konstruojant reikiama PS. Toliau ingsnis po ingsnio vyksta konkatenacijos procesas vietoje to, kad leistis nuo udavinio prie programavimo kalbos, kaip tai daroma taikant i viraus emyn paradigma, nuo programavimo kalbos yra kilama prie udavinio, vienas po kito konstruojant abstrakcijos lygmenis (juos galima traktuoti kaip programavimo kalbas) vis labiau ir labiau pritaikytus sprendiamam udaviniui aprayti.

    179. 5 paskaita 179 Principai ir paradigmos Paradigma i apacios auktyn Procesas ubaigiamas, suprojektavus probleminio pobudio komponentus panaudojus kuriuos galima igyvendinti uduociu formulavimo kalba (vartotojo interfeisus) Paradigma pritaikyta projektuotojams, kurie linke visu pirma ivertinti komponento, kuri jie rengiasi projektuoti, technologini tinkamuma (nauma ir pan.) kuriamai programu sistemai.

    180. 5 paskaita 180 Principai ir paradigmos Paradigma i apacios auktyn Projektavimo sprendimai priimami vadovaujantis technologiniais kriterijais komponentai kombinuojami, norint gauti auktesnio lygmens komponentus, kurie, manoma, yra tinkamesni vartotojo interfeisams igyvendinti, nes yra labiau probleminio (ne technologinio) pobudio.

    181. 5 paskaita 181 Principai ir paradigmos Paradigma i apacios auktyn Rekomenduojama vadovautis i apacios auktyn paradigma, kuomet norima sukurti PS sprendiancia bendresne problema negu problema, kuria sprendia kokia nors jau esama PS. Kaip jau mineta, svarbiausias paradigmos trukumas yra tas, kad apatiniuose abstrakcijos lygmenyse priimti technologiniai sprendimai paveikia visa PS, iskaitant vartotojo interfeisus vadovaujantis i viraus emyn paradigma, pradedama ne nuo technologiniu sprendimu, jie atidedami velesniam laikui.

    182. 5 paskaita 182 Principai ir paradigmos

    183. 5 paskaita 183 Principai ir paradigmos

    184. 5 paskaita 184 Principai ir paradigmos

    185. 5 paskaita 185 Principai ir paradigmos Rieuto paradigma PS kuriama kaip specializuota virtualioji maina, turinti visas duomenu strukturas ir komandas, pritaikytas reikiamai problemai spresti, o taip pat ta problema sprendiancia programa Virtualiajai mainai vykdant ia programa, yra ivykdoma reikiama uduotis. Po to, ingsnis po ingsnio konstruojamos naujos, emesnio lygmens virtualiosios mainos, skirtos auktesnio lygmens mainoms igyvendinti Kiekviena tokia maina patikslina (realizuoja) auktesnio lygmens virtualiosios mainos komandas ir duomenu strukturas.

    186. 5 paskaita 186 Principai ir paradigmos Rieuto paradigma Procesas baigiamas tada, kada visos auktesnio lygmens mainos komandos ir duomenu strukturos yra realizuotos kokia nors programavimo kalba I esmes, tai specialus paradigmos i viraus emyn atvejas Kiekvienas abstrakcijos lygmuo cia projektuojamas kaip virtualioji maina. Pagrindine ideja yra palaipsniui pertvarkyti probleminio pobudio virtualiaja maina i kompiuterines platformos lygmens maina.

    187. 5 paskaita 187 Principai ir paradigmos Rieuto paradigma Rieuto paradigma galima traktuoti ir kaip specialu paradigmos i apacios auktyn atveja iuo atveju PS pradedama kurti nuo vadinamojo branduolio, t.y. virtualiosios mainos, realizuojancios bazines sistemos funkcijas; ios mainos kalba programuojamos papildomos funkcijos, t.y. kuriama nauja virtualioji maina, kuri tarsi kevalas padengia branduoli; procesas tesiamas tol, kol sukuriama sistema, tenkinanti turima reikalavimu specifikacija.

    188. 5 paskaita 188 Principai ir paradigmos

    189. 5 paskaita 189 Principai ir paradigmos Iteracine paradigma Vadovaujantis ia paradigma kuriamas ir testuojamas busimosios PS prototipas (funkciniu ar kitais poiuriais neibaigta PS); prototipas perdirbamas i labiau ibaigta varianta (nauja prototipa); procesas tesiamas kol galu gale sukuriama ibaigta PS, tenkinanti reikalavimu specifikacija.

    190. 5 paskaita 190 Principai ir paradigmos

    191. 5 paskaita 191 Principai ir paradigmos

    192. 5 paskaita 192 Principai ir paradigmos

    193. 5 paskaita 193 Principai ir paradigmos Evoliucinio kurimo paradigma Sistema yra kuriama kaip usakovui vienas po kito pateikiamu papildiniu (increments) seka suprojektavus visos sistemos architektura, kuriami ir pateikiami usakovui tos sistemos branduolys (svarbiausios funkcijos) ir jo papildiniai; kiekvienam papildiniui rengiama jo reikalavimu specifikacija ir jo projektine dokumentacija; kol kuriamas naujas papildinys, vartotojai dirba su einamaja PS versija ir irykina jos trukumus.

    194. 5 paskaita 194 Principai ir paradigmos

    195. 5 paskaita 195 Principai ir paradigmos

    196. 5 paskaita 196 Principai ir paradigmos Ekstremalus programavimas (extreme programming) Specialus (iuo metu labai populiarus) evoliucines paradigmos atvejas, numatantis, kad kuriami ir usakovui pateikiami labai mai papildiniai grindiamas nuolatiniu kodo tobulinimu, tiesioginiu vartotojo dalyvavimu PS kurimo procese ir programavimu poromis; priskiriamas prie agiliuju metodu termino ekstremalus del neigiamu asosiaciju pradedama atsisakyti.

    197. 5 paskaita 197 Principai ir paradigmos Ekstremalus programavimas Programavimas poromis: prie ekrano sedi dviese ir kartu rao programa; itaip vienas kita tikrina ir ivengia daugelio klaidu; be to, kiekviena programa ino maiausiai du mones ir, jei vienam kas nors atsitiko, kitas gali ta programa keisti ir taisyti.

    198. 5 paskaita 198 Principai ir paradigmos Evoliucinio kurimo paradigma Evoliucine paradigma yra panai i iteracine, taciau yra sukuriama geriau strukturizuota PS ir jos kurimo procesa yra lengviau valdyti PS funkcionalumas pateikiamas usakovui anksciau (nors ir dalimis); pradiniai papildiniai vaidina prototipu vaidmeni, nes padeda patikslinti velesniu papildiniu reikalavimus; sumaeja projekto lugimo rizika; galima geriau ibandyti (daugiau testavimo) svarbiausias sistemos funkcijas.

    199. 5 paskaita 199 Principai ir paradigmos Komponentine paradigma Sistema renkama i turimu komponentu grindiama daugkartiniu rinkoje parduodamu komponentu panaudojimu; didele svarba igyja komponentu integravimo metodai; labai svarbu, kiek reikia pastangu komponentui perprasti.

    200. 5 paskaita 200 Principai ir paradigmos Komponentine paradigma PS kurimas pradedamas komponentu analize ir ju reikalavimu keitimu. Daniausiai i komponentu surenkama tiktai tam tikra kuriamos PS dalis, todel komponentine paradigma turi buti kombinuojama su kitomis paradigmomis.

    201. 5 paskaita 201 Principai ir paradigmos

    202. 5 paskaita 202 Principai ir paradigmos Programu eimu ininerija Programu eima apibreiama, apebreiant tam tikroje dalykineje srityje jos sprendiamu udaviniu (problemu) klase Tai specialus komponentines paradigmos atvejas, numatantis sprendiamu problemu klases nustatyma, ia problemu klase sprendianciu sistemu apibendrintos architekturos projektavima, programu eimos ruoinio (reikalavimai, projektine dokumentacija, kodas, vartotojo dokumentacija) kurima, konkreciu sistemu generavima i to ruoinio.

    203. 5 paskaita 203 Principai ir paradigmos

    204. 5 paskaita 204 Principai ir paradigmos Programu eimu ininerija Kadangi eimai priklausancios programos turi daug bendru savybiu, prasminga jas apjungti, kad butu galima pakartotinai panaudoti ne tik koda, bet ir reikalavimus, architektura bei vartotojo dokumentacijos komponentus. Vadovaujantis ia paradigma, sistemos kurimo procesas skyla i dvi dalis: bendrybiu paieka ir realizavimas (eimos ininerija; domain engineering) ir konkreciu PS kurimas (sistemos ininerija; application engineering).

    205. 5 paskaita 205 Principai ir paradigmos Programu eimu ininerija Bendrybes (commonality) tai savybes, kurias turi visos tai eimai priklausancios PS bendrybes tai ir yra tai, kas gali buti daug kartu panaudota pakartotinai (kiekvienai tai eimai priklausanciai sistemai); tuo paciu bendrybes nustato eimos ribas, nes per jas nusakoma tai eimai priklausanciu sistemu aibe.

    206. 5 paskaita 206 Principai ir paradigmos

    207. 5 paskaita 207 Principai ir paradigmos Programu eimu ininerija eimos ininerija: Tam tikrai kokios nors dalykines srities problemu klasei kuriamas programu eimos ruoinys. Sistemos ininerija: I ruoinio sukuriama konkreti tam tikrai dalykinei sriciai skirta PS.

    208. 5 paskaita 208 Principai ir paradigmos

    209. 5 paskaita 209 Principai ir paradigmos Karkaso paradigma Tai specialus programu sistemu eimos paradigmos atvejas. dirbant pagal ia paradigma, ruoinys yra kuriamas kaip objektinis ar kitoks PS sistemos architekturinis karkasas (apibendrinta parametrizuota PS); konkreti PS sistema yra kuriama konkretizuojant karkasa (suteikiant parametrams konkrecias reikmes) ir upildant ji konkreciu funkcionalumu; itaip, pavyzdiui, kuriamos vadinamosios verslo procesu valdymo sistemos (ERP paketai).

    210. 5 paskaita 210 Principai ir paradigmos Karkaso paradigma Architekturinis karkasas yra tam tikri PS griauciai realizuojamos duomenu strukturos, moduliu interfeisai, ju saveika ir kiti konstrukciniai PS ypatumai; taciau pats karkasas nera upildytas jokiu konkreciu funkcionalumu t.y. jame paciu moduliu realizacijos nera.

    211. 5 paskaita 211 Principai ir paradigmos Karkaso paradigma Objektinis karkasas kuriamas kaip tarpusavyje susietu abstrakciuju klasiu rinkinys abstrakciosios klases naudojamos paveldejimo hierarchijoms konstruoti; jos neturi realizaciju, jose apibretos tik virtualios operacijos; t.y. karkase klasiu realizacijos nera.

    212. 5 paskaita 212 Principai ir paradigmos Karkaso paradigma Objektiniai karkasai i esmes skiriasi nuo klasiu biblioteku bibliotekos tirauoja programu koda, karkasai realizuoja ir tirauoja PS eimai budingas architekturines bendrybes (tipinius projektavimo sprendimus); naudojant klasiu biblioteka valdymo srautas teka i viena puse: i klasiu biblioteka naudojancios programis i bibliotekos klases; naudojant objektini karkasa, valdymo srautas yra abipusis, nes, viena vertus, programos klases paveldi abstrakciuju karkaso klasiu ypatumus, o, kita vertus, virtualiosios operacijos, panaudojant dinaminio susiejimo mechanizma (dynamic binding), susiejamos su jas realizuojanciu kodu programos vykdymo metu.

    213. 5 paskaita 213 Principai ir paradigmos

    214. 5 paskaita 214 Principai ir paradigmos Karkaso paradigma Norint karkaso pagrindu sukurti konkrecia PS eimos sistema reikia sukurti karkaso klasemis numatyta funkcionaluma realizuojanti koda (karkaso upilda) paprastai kartu su karkasu yra tirauojamas ir standartinis upildas (arba bent jau jo dalis); realizuojant konkrecia PS, standartinis upildas gali buti visas arba i dalies pakeistas nestandartine, tai konkreciai sistemai budinga realizacija.

    215. 5 paskaita 215 Principai ir paradigmos Sintezes paradigma Dirbant pagal ia paradigma, formali (matematine) sistemos specifikacija pagal formalias taisykles (automatikai) transformuojama i veikiancia PS transformavimas atliekamas per kelis tarpinius ingsnius; transformacijos neinea klaidu, todel kodas visuomet atitinka sistemos specifikacija; todel atpuola butinybe testuoti itaip gauta koda.

    216. 5 paskaita 216 Principai ir paradigmos

    217. 5 paskaita 217 Principai ir paradigmos Sintezes paradigma Problemos reikalingi specialus igudiai ir aukta kvalifikacija; sudetinga formaliai specifikuoti kai kuriuos sistemos aspektus, pavyzdiui, vartotojo interfeisa; darant sistemos pakeitimus, prireikia sukurti naujas transformacijas ir irodyti ju teisinguma; kaip taisykle, nepavyksta keisti itaip kuriamu sistemu masta (does not scale). Taikymu sritis Kritines sistemos.

    218. 5 paskaita 218 Klausimai?

    219. 5 paskaita 219 Klausimai Dvi skirtingos termino programu ininerija prasmes. (1) Sudetines PS ininerijos dalys. (4) Ka apima teoriniai PS ininerijos pagrindai? Trumpai juos apibudinkite. (3) Ka apima inineriniai PS ininerijos pagrindai? Trumpai juos apibudinkite.(3) Ka nagrineja disciplina PS architekturos? (3) Ka nagrineja disciplina PS projektu valdymas? (3) Ka nagrineja disciplina PS konfiguracijos valdymas? (3) Ka nagrineja disciplina PS reikalavimu ininerija? (3) Ka nagrineja programu ininerija?(3)

    220. 5 paskaita 220 Klausimai Ka nagrineja duomenu ininerija? (3) Ka nagrineja interfeisu ininerija? (3) Ka nagrineja Web ininerija?( 3) Ka nagrineja kokybes ininerija? (3) Ka nagrineja patikimumo ininerija? (3) Ka nagrineja naumo ininerija? (3) Ka nagrineja apsaugos ininerija? (3) Ka nagrineja saugos ininerija? (3) Ka nagrineja panaudojamumo ininerija?(3) Ka nagrineja disciplina PS prieiura?(3)

    221. 5 paskaita 221 Klausimai Ka nagrineja instrumentiniu sistemu teorija?(3) I kokias grupes yra skirstomi PS ininerijos procesai? Trumpai apibudinkite kiekviena i ju. (2) Kokie PS ininerijos procesai yra vadinami baziniais procesais? Trumpai apibudinkite kiekviena i ju. (3) Kokie PS ininerijos procesai yra vadinami pagalbiniais procesais? Trumpai apibudinkite kiekviena i ju. (3) Kokie PS ininerijos procesai yra vadinami organizaciniais procesais? Trumpai apibudinkite kiekviena i ju. (3) Kokios artifaktu grupes yra kuriamos PS ininerijos procesais? Trumpai apibudinkite kiekviena i ju. (3) Kokios idealizuotos prielaidos daromos PS ininerijoje? (3) Kokius PS ininerijos principus inote? (1).

    222. 5 paskaita 222 Klausimai Paaikinkite kas tai yra turiniu atskyrimo principas. (3) Paaikinkite kas tai yra dekompozicijos principas. (3) Paaikinkite kas tai yra juodosios dees principas. (3) Paaikinkite kas tai yra abstrakcijos principas. (3) Paaikinkite kas tai yra paingsniniu patikslinimu principas. (3) Kas tai yra procedurine abstrakcija? (3) Kas tai yra duomenu abstrakcija? (3) Kas tai yra valdymo abstrakcija? (3) Kas tai yra virtualioji maina? (3) Paaikinkite kas tai yra unifikavimo principas. (3) Paaikinkite kas tai yra strukturizavimo principas. (2) Paaikinkite kas tai yra sistemu atvirumo principas. (2)

    223. 5 paskaita 223 Klausimai Paaikinkite kas tai yra interfeisu komfortikumo principas. (2) Paaikinkite kas tai yra metaforizavimo principas. (3) Paaikinkite kas tai yra reaktyvumo principas. (6) Ivardinkite populiariausias PS ininerijos paradigmas. (1). Paaikinkite i viraus emyn paradigma. (2) Paaikinkite i apacios auktyn paradigma. (2) Palyginkite i viraus emyn ir i apacios auktyn paradigmas. (2) Paaikinkite rieuto paradigma. (2) Paaikinkite iteracine paradigma. (2) Paaikinkite evoliucine paradigma. (2) Kas tai yra ekstremalusis programavimas? (2) Paaikinkite komponentine paradigma. (2)

    224. 5 paskaita 224 Klausimai Paaikinkite programu eimu paradigma. (3) Paaikinkite karkaso paradigma. (3) Paaikinkite sintezes paradigma. (2)

More Related