Informacijos sistemos

1. Informacijos sistemos samprata, paskirtis, pavyzdžiai, tipai.IS tikslas-užtikrinti efektyvų inf-jos panaudojimą organizacijoje, aprūpinti ją tikslia ir pilna inf-a, užtikrinančia įmonės reikmes priimant valdymo sprendimus. Galima išskirti kelis IS tipus, priklausomai nuo jų įtakos (teikiamos pagalbos), įmonės funkcionavimo:Duomenų apdorojimo sistema (DAS). DAS-tai informacijos sistema, apdorojanti didelius inf-os kiekius, atspindinčius elementarius organizacijoje vykstančius procesus.Informacinė valdymo sistema (IVS). IVS-išplėsta DAS. Jos tikslas ne tik registruoti ir kaupti inf-ją, bet ir aprūpinti reikiama inf-a vadybininkus bei kitus tam tikrų procesų valdymą užtikrinančius asmenis. Ši inf-a dažniausiai būna labiau struktūrizuota, apibendrinta, pateikiama abstraktesnėje formoje. Pvz.: elementari pagamintos produkcijos apskaita (DAS). Gaminys Kiekis Atsilikimas nuo gamyb. užd. (darbo dienomis) Jei DAS atlieka elementarią atlyginimų apskaitą, tai IVS pateikia statistinę inf-ą apie vidutinį atlyginimo per laikotarpį, kvalifikacijos kėlimo rezultatus ir pan. IVS turi pateikti inf-ą apie organizacijos veiklos vystymosi tendencijos nukrypimus nuo siekiamų tikslų.Sprendimų priėmimo sistema (SPS). SPS-tai išplėsta IVS. Ji turi išvystytas analizės ir sprendimų priėmimo priemones. Pvz.: SPS gali turėti optimizavimo priemones priimant tam tikrus sprendimus, tačiau ir visais atvejais galutinį sprendimą priima žmogus.2. Informacijos sistema, kaip tam tikros organizacijos (darbinės sistemos) dalis.Žmonės registruojantys, apdorojantys ir naudojantys inf-ą.Inf-a apie darbą, kurį vykdo žmonės ir tam tikra technologija.Formatuoti duomenys, tekstai, vaizdai, garsai.Informacinė įranga, algoritminė įranga.3. Tikslai, veiksmai ir objektai: trys probleminės srities tyrimo aspektai. Reikalavimai veiksmų, tikslų ir objektų modeliavimo priemonės.Tiriant probleminę sritį tikslų aspektu tenka atsakyti į klausimus: kokie organizacjos egzistavimo tikslai? Ko siekia organizacijos žmonės? Kokios organizacijos veiksmų vykdymo garantijos (perspektyvos)? Analizuodami organizaciją tikslų aspektu, nustatome probleminės srities gyvavimo tikslus, atskleidžiame konfliktus tarp jų bei aplinkybes, galinčias sutrukdyti pasiekti tikslus. Pvz.: pakviesti optimalų plenarinių pranešėjų skaičių;įtraukti į konferencijos programą tik geriausius pranešėjus;konferencijoje turi dalyvauti ne mažiau kaip 100 moksleivių.Analizuodami organizaciją veiksmų aspektu, užduodami tokie klausimai: kokie veiksmai vykdomi organizacijoje? Kokie žmonės (padaliniai) kokius veiksmus atlieka? Kokie veikmų tarpusavio ryšiai? Šios analizės metu identifikuojami organizacijos veikėjai, jų veiksmai bei atsakomybės struktūra. Pvz.: išsiųsti kvietimus atrinktiems pranešėjams; sudaryti konferencijos dienotvarkę; registruoti pageidavimus viešbučiams.Analizuojant organizaciją objektų pjūvyje, atsakome į klausimus: kokie objektai, reiškiniai, sąvokos egzistuoja organizacijoje ir jos aplinkoje? Kokiomis savybėmis objektai pasižymi? Kokie objektų tarpusavio ryšiai? Kaip objektai atsiranda, kinta, išnyksta? Kokie įvykiai įtakoja objektus? Analizuojant objektus tiriamas jų elgesys ir kitimas laike. Be to, nustatomos taisyklės, ribojančios objektų būsenas bei jų elgesį. Pvz.: straipsniai, pranešėjai, sekcijos ir pan. (objektai);pavėluotai atsiųsti straipsniai atmetami;straipsnio peržiūrėti negali asmuo, dirbantis ten pat kaip ir autorius.Tikslai nusako objektų pageidaujamas būsenas, tuo pačiu, kokie objektai yra reikalingi kokios jų savybės (pageidaujamos) ir kaip jie turi sąveikauti tarpusavyje. Veiksmai įtakoja objektų būsenas, be to, jie turi būti įvykdyti taip, kad patenkinti tikslus. Kuriant IS būtina sudaryti organizacijos modelį, atspindintį ją 3 aspektais. Jis turi patenkinti tokius reikalavimus:Turi būti paprastai ir suprantamai aprašyti, kad projektuotojas ir vartotojas galėtų juo naudotis kaip tarpusavio bendravimo pagrindu.Modelis turi būti detalizuotas ir nedviprasmiškas, kad būtų pagrindu kitiems IS projektavimo etapams.Veiksmams modeliuoti yra nemažai priemonių: duomenų srautų diagrama, būsenų kaitos diagrama. Tikslų modeliavimui tokiu priemonių nėra. Tėra tik nauji, dar neištirti metodai. Objektų modeliavimui seniausi priemonė-ER modelis; tačiau ER modelis daugiau išreiškia statistinius probleminės srities aspektus ir tik nesudėtingos taisyklės, nusakančios objektams keliamus reikalavimus. Šį trukūmą pašalina objektiškai orientuoti metodai, atspindintys tiek statinius, tiek dinaminius probleminės srities aspektus.

4. Tradicinio infornacijos sistemų kūrimo proceso sudėtis.5. Reikalavimų nustatymo etapo turinys ir specifika (bendra charakteristika).Tai mažiausiai apibrėžtas ir struktūrizuotas etapas. Priežastys:Labiausiai priklausantis nuo konkrečios probleminės srities; (mažiausiai techniškas).Reikalavimai iš prigimties nėra apibrėžiami, naudojant griežtus metodus.6. Problemos apibrėžimas reikalavimų nustatymo metu.Pagrindžiamos sistemos kūrimo priežastys. Tradiciškai tai gali būti pateikta techniniame pasiųlyme (sistemos kūrimo pagrindime). Šis dokumentas neturi griežtos formos. Jame apibrėžiama sistemos paskirtis ir jos kūrimo tikslai. Kuriant sistemą galima siekti bent vieno tikslo: išspęsti problemą, įvykdyti nurodymą, išplėsti tam tikros veiklos galimybes. Jie vėliau detalizuojami. Sistemos kūrimą pagrindžiantys fatoriai:inf-os apdorojimo galimybių išplėtimas (padidinti inf-os apdorojimo greitį, paieškos galimybes);komunikavimo galimybių išplėtimas (organizacijos vidaus ir išorės ryšių patobulinimas, padidinant pranešimų perdavimo greitį; tikslumą, kompiuterizuojant dokumento perdavimą);valdymo patobulinimas (valdymo tikslumas, pilnumas, savalaikiškumas);kainų (pinigų) valdymas;konkurentabilumo padidinimas.Techninį pasiūlymą rengia labiausiai patyrę IS kūrimo ir analizės specialistai. Procesas trunka keletą dienų. Pateikiama ataskaita, susidedanti iš:spręstino uždavinio apibrėžimas;siūlomas sprendimas, kuriame paaiškinama IS pagalba ir numatoma nauda ją sukūrus;reikalingi resursai; (fiksavimo, laiko).7. Sistemos kūrimo galimybių analizė ir jos atlikimo aspektai.Jo metu įvertinamos realizavimo galimybės techninio pasiųlymo išanalizuojant uždavinį ir parenkant optimalų sprendimą. Gali būti keli alternatyvūs sprendimai ir nefunkciniai reikalavimai sistemos kūrimo galimumas pagrindžiamas šiais aspektais:sistemos atitikimas organizacijos funkcionalumo tikslams (reikia, kad atliktų organizacijai reikiamas (trūkstamas) f-jas);ekonominis kūrimo galimumas (įvertinamos finansinės išlaidos ir numatoma nauda. Pinigais įvertinami nefunkciniai reikalavimai);techninis kūrimo galimumas (įvertinama, ar sisteos kūrimo idėja suderinama su egzistuojama technologija. Kai kurie sprendimai reikalauja papildomos techninės įrangos. Analizuojami nefunkciniai reikalavimai);kūrimo galimumo įvertinimas organizaciniu aspektu (tai įvertina organizacijos darbuotojų pasiruošimą ir nusiteikimą eksploatuoti IS. Tai gali būti sąlygota, kai sprendimas kurti sistemą priimamas aukščiausiu lygiu, o sistemos techniniame (kūrimo) metu nedalyvauja tiesiogiai sistemos vartotojai (apie nepasitenkinimą)).Projekto sekmės faktoriai:Projekto palaikymas iš vadovybės pusės.Betarpiškas tiesioginių sistemos vartotojų dalyvavimas kuriant sistemą.8. Sistemos kūrimo galimybių analizės rezultatai ir jų panaudojimas projekto planavimui.Sistemos kūrimo galimybių analizės rezultatai. Šis etapas sudėtingas todėl, kad dauguma klausimų negali būti tiksliai atsakyti dėl nepakankamo probleminės srities žinojimo. Vienas iš faktorių, lemiančių IS kūrimo sekmę yra IS projektuotojų komandos pasiruošimas darbui. Jis nėra analizuojamas pakankamai. Šio etapo metu tyrimas atliekamas apytiksliai ir greitai, atmetant pasiūlymus, neatitinkančius organizacijos vystymosi strategijos, techniniu požiūriu neįmanomus, duodama nauda nepateikiant išlaidų, bei vartotojui nesant pasiruošiusiam (nusiteikusiam) naudoti šios sistemos. Šį etapą vykdo sistemos analitikai, diskutuojantys su vartotojais bei analizuojantys dokumentaciją. Jei paruošia ataskaitą, kurioje pateikiama:bendri funkciniai reikalavimai;svarbiausi nefunkciniai reikalavimai (pvz.: saugumas);Ataskaitoje turi būti apžvelgti visi 4 IS kūrimo galimumo aspektai. Taip pat gali būti priimtas vienas iš sistemos kūrimo variantų:Sistema kūriama savo jėgomis.Sistema užsakoma kitoje organizacijoje.Perkamas jau sukurtas paketas.Sistemos kūrimu gali būti išskirti keli etapai: sukūriamas pilotinis projektas, kuris paskui išplėčiamas, išvystant funkcines galimybes.Projekto planavimas. Atlikus sistemos kūrimo galimumo analizę, galima sudaryti IS kūrimo planą. Jis apima finansavimo poreikius laiko ir projektuotojų poreikius. Projekto planas yra hierarchijos struktūros, kuriame sistemos kūrimoetapai detalizuojami, numatant jų turinį ir atliekamus darbus, gaunamus rezultatus, reikalavimus kokybei ir būdus (taškus).9. Reikalavimų įgijimo paskirtis ir metodai. Reikalavimų įgyjimas. Patvirtinus sistemos kūrimo galimumą, toliau detalizuojami vartotojo poreikiai. Nustatomi naudojant:
Stebėjimą. Jo metu stebimas tam tikro probleminės srities aktoriaus elgesys darbo metu ir jo darbo aplinka. Stebint jo vietą nustatoma:jo funkcijos ir vieta sistemoje;pagrindiniai naudojami inf-os šaltiniai, pateikiami rezultatai ir inf-os pobūdis.Stebint aktoriaus darbo apliką nustatomi jo poreikia inf-ai bei galimybės išplėsti jo veiklą, pagerinant darbo aplinkos inf-nę infrastruktūrą. Šis metodas naudojamas tuomet, kai kitų poreikių šaltiniai duoda prieštaringus rezultatus arba kitų šaltinių nėra. Stebėjimas gali būti atliekamas betarpiškai, dalyvaujant ar jam nedalyvaujant.esamo sistemos dokumentacijos (inf-os srautų) analizę. Ji atliekama tiriant esamoje sistemoje naudojamus duomenis : kiekybinio ir kokybinio tipo. Kiekybiniai-ataskaitų formos, pirminiai dokumentai, veiklos instrukcijos ir t.t. Kokybiniai (jie leičia organizacijos veiklos kultūrą)-reklama, skelbimų lentos pranešimai, atmintinės. Papildomai galima nustatyti: pvz.: organizacija, turinti daug dokumentų, pasirašytų vadovaujančio personalo ir reglamentuojanti veiklos taisykles yra daugiau centralizuota negu organizacijos, kuriose paplitę pranešimai skelbimų lentoje ar kiti laisvo pobūdžio dokumentai. Tai leid-ia nuspręsti ar kuriamos IS ataskaitos apie organizacinę veiklą reikia orientuoti vadovams ar daugiau žemesniam personalui.kūriamosios sistemos dokumentacijos analizę. Tai pastabos apie vartotojo poreikius ir apribojimus kuriamai sistemai, pateiktos ankstesniu naujosios sistemos kūrimo etapo metu. Tai daugiausia bendri reikalavimai, pateikti organizacijų strateginiame plane, problemos apibrėžimo ataskaitoje bei sistemos kūrimo galimumo pagrindime.interviu ir anketavimą. Dažniausiai naudojamas poreikių įgyjimo metodas-interviu. Jis leidžia vartotojui savarankiškai ir betarpiškai pareikšti pageidavimus sistemai. Interviu reikia pasiruošti. Išskiriami žingsniai:susipažinti su bazine informacija;pagrįsti interviu tikslus;pasirinkti tinkamą probleminės srities specialistą;sudaryti interviu struktūrą;numatyti klausimų tipus ir sudėtį.Interviu struktūra:piramidės tipo D. Pradedamas nuo specifinių klausimų išplėčiant interviu kontekstą ir baigiant apibendrinančiomis išvadomis. Naudojama vėlesniuose analizės etapuose.piltuvėlio tipo Ñ. Pradedamas nuo bendrų klausimų ir einama link detalių. Naudojama analizės pradžioje, laisvesnio pobūdžio, leidžia atskleisti daugiau detalių.deimanto tipo à. Pradedamas specialiais klausimais, išplėčiamas jų kontekste ir baigiama vėl. spec. klausimais. smėlinio laikrodžio tipo.Anketavimas. Vartotojas apklausiamas raštu. Naudojama kai reikia inf-os iš daugelio probleminės srities atstovų. Ypač tai pasiteisina, kai yra daug tokiu pat sistemos vartotojų ir reikia apibendrinti jų nuomonę arba norime atlikti paruošiamąjį darbą prieš apklausą interviu būdu. Sunkumai: vartotojui sunkiau atsakyti į atviro pobūdžio klausimus;anketavimas užtrunka ilgiau negu interviu.Anketoje gali būti praleisti svarbūs aspektai, kurie interviu metu išaiškėja.Anketą reikia sudaryti, išplatinti ir atlikti analizę.Interviu geresnis dėl betarpiškumo, leidžia atskeisti prieštaravimus ir konfliktus ankščiau pateiktoje medžiagoje, tačiau jo metu viską reikia ne tik užregistruoti, bet ir suprasti. Poreikių įgyjimo metu nustatoma didesnė dalis vartotojo reikmių, tačiau vėlaiu jie turi būti datalizuojami ir patvirtinami.Reikalavimų analizė. Jos metu neformalūs reikalalvimai transformuojami sudarant struktūrizuotą jų aprašymą (reikalavimų specifikaciją). Nauda:analitikui lengviau suprasti (surasti) prieštaravimus ir trūkstamą inf-ą;sistemiškas reikalavimų atvaizdavimas leidžia pateikti juos vartotojo patikrinimui ir patvirtinimui. Reikalavimų specifikamui sudaryti naudojami įvairūs modeliai:Struktūrinė analizė.Objektinė analizė.10. Reikalavimų nustatymo etapo sunkumai.Reikalavimų nustatymo etapo sunkumai. Produktyvumo (našumo) sunkumai. Kyla dėl prielaidos, kad reikalavimai-tai objektyvus faktų rinkinys, jie gerai žinomi nuo IS kūrimo pradžios, jie nekinta. Kita prielaida, kad projektavimo resursai gali būti įvertinti iš anksto, pakankamai tiksliai. Poreikiai kinta dėl šių priežasčių:Vartotojai keičia savo nuomonę dėl:įsigilinimo į problemą, informinių technologijų galimybes, plečiant sistemos galimybes;vartotojų tarpusavio prieštaravimų, ypač projektavimo pradžioje, didelio suinteresuotų probleminės srities specialistų skaičiaus; vyraujanti nuomonė gali pasikeisti likvidavus prieštaravimus.
Išorės faktoriai gali įtakoti pokyčius (organizaci. gali pakeisti veiklos pobūdį, atsirasti modeernistinė įranga, pasikeisti įstatymais).Diegimas neįvedus pakeitimų gali būti neįmanomas (jo metu gali paaiškėti, kad tam tikri nefunkciniai reikalavimai netenkinami, pvz.: sistemos realizacijos greitis. Tuomet gali tekti grįžti į reiklavimų nustatymo fazę).Komplikuotas ir nepakankamas projekto valdymas (sudėtinga įvertinti projektavimui reikalingus resursus: projektavimo kaina, programinės ir techninės įrangos įsigyjimo kaina, projektuotojų kiekį ir kvalifikaviją, projektavimo trukmę). Projekto valdymas remiasi personalo patirtimi ir intuicija. Užsakovai siekia trumpinti projektavimo trukmę ir mažinti kainą. Dėl to dažnai resursų įvertinimas yra optimistinis. Poreikių nustatymas yra reliatyvus procesas ir tai padidina projekto kainą.Kokybės sunkumai. Analizės metodai neįvertina specifinių žinių apie probleminę sritį, kurios reikalingos nustatyti poreikius.Analizės metodai remiasi netinkamais metodais ir priemonėmis inf-os poreikiams specifikuoti. Dažnai pasikliaunama vien tik analitikų intuicija. Kuo didesnė sistema, tuo daugiau šansų, kad poreikių specifikacijoje bus daug klaidų, ypač naudojant vientik intuityvų metodą.11. Reikalavimų nustatymo etapo sunkumų sprendimo būdai.Sunkumų sprendimo būdai. (1b) Grupiniai pasitarimai. Jų metu, suinteresuotieji vartotojai sukviečiami į pasitarimus, kuriuose prieštaravimai detalizuojami ir išsprendžiami. Gali būti: pasitarimų idėja, pasitarimų kaskados.(1a) Pasitarimas ir prototipo sudarymas. Šie metodai leidžia patvirtinti vartotojui poreikių analizės rezultatus. Tai leidžia ne tik aptikti analiės metu atliktas klaidas, bet ir užtikrinti alternatyvią poreikių nustatymo technologiją.(5) Algebrinė inžinerija. Šis metodas naudoja CASE priemones, kad iš egzistuojančios sistemos specifikacijos programų ir duomenų struktūrų pavidalu būtų sudaryta sistemos projektinė dokumentacija (ORACLE).(6) Šiuolaikinių analizės panaudojimas poreikiams nustatyti. Galima naudoti techninį dokumentavimą.(4) Projekto valdymo patobulinimas. Planavimo technologijos panaudojimas, tvarkos įvedimas, CASE priemonių panaudojimas (PROJECT, PRINCEN).Išvados (reikalavimų nustatymo skyriaus). Poreikių įgyjimas-iteratyvus procesas. Pagrindinis sunkumas-poreikių analizės fazė neturi pilnai išvystytų metodų, neprieštaringai ri pilani poreikių specifikacijai sudaryti. Dėl to sudėtinga aptikti poreikių nepilnumą ir prieštaringumą pirmosiose analizės fazėse. Pirmoji fazė yra lemiama IS kūrime, kadangi klaidos, paliktos ir atliktos šios fazės metu, išsiplečia sekančių fazių metu.12. Analizės etapo tikslai, turinys ir specifika.Analizes etapo tikslai, turinys ir specifika. Jo tikslas detalizuotų reikalavimų IS specifikacija ir išreikšti ją naudojant tikslesnias specifikavimo priemones. Jo metu sudaromas tikslus kūriamos sistemos modelis:Jis turi tikti tiek vartotojo ir analitiko komunikavimui, tiek analizės specialistų tarpusavio darbui.Gali būti naudojamas kaip bazė kuriant detalų sistemos projektą ir jį programiškai realizuojant.Dauguma šiuolaikinių analizės metodų remiasi konceptualiu modeliavimu. Konceptualų modelį sudaro:Struktūros modelis.Procesų modelis.Taisymo modelis.Senesniuose projektavimo metoduose daugiausia buvo skiriama dėmesio struktūros modeliui. Vėliau- struktūra pradėjo atlikti karkaso vaidmenį kitų sudėtinių dalių atžvilgiu. Analizės metodai remiasi tiek statiniu, tiek dinaminiu probleminės srities aspektų tyrimu. Dinaminio aspekto pagrindas-procesų ir organizacijos veiklos analizė, o statinio-struktūriniai probleminės srities objektai, kurie atlieka tam tikrus veiksmus arba yra kitų procesu rezultatas ar veiklos terpė. Be to, objektų būsenos turi tam tikrus apribojimus (taisykles). Porcesai skirstomi:Keitimo (modifikavimo) procesus, kurie keičia objekto būsenas ir privalo tenkinti tam tikras sąlygas, nes kitaip objektai gali įgyti nepageidaujamas būsenas. Paklausimo (informavimo, ataskaitų pateikimo) procesus, informuojačius apie objekto būsenas.13. ER-modelis. Esybės samprata, jų išskyrimas ir pasitaikančios klaidos.Esybių ryšių modelis (ER).

ER modelio vieta-projektavimo procese. Pagrindas daugelio CASE priemonių. ER-entity relation. Autorius: Chen 1976 m. 3 pagrindinės modelio dalys: 1. Esybė; 2. Ryšys; 3. Atributas. ER modeliavimas apima organizacijai svarbių dalykų (esybių) identifikavimą, jų savybių (atributų) bei tarpusavio ryšių aprašymą. Tai atliekama tik modeliuojamos veiklos kontekste. ER modeliavimo tikslas-sudaryti tikslų organizacijos informacinį modelį (poreikių), kuris atliktų naujai kuriamos arba tobulinamos sistemos kakraso vaidmenį.

Esybės samprata. Esybė atitinka realių probleminės srities objektų aibę arba klasę. Objektai, pasižymintys panašiomis savybėmis, sudaro objektų klasę, kuriai suteikiamas vardas. Pvz.: visi įmonės dirbantys yra darbuotojų aibės elementai ir sudaro klasę DARBUOTOJAS. ER modelyje tai atitiks esybę. Papildomos ryšių savybės:1. Tas pačias esybes gali sieti daugiau negu 1 ryšys.

Ryšiams reikia suteikti unikalų pavadinimą (jei tarp dviejų esybių yra keletas ryšių). Tarp skirtingų esybių ryšio pavadinimas gali ir kartotis. Pavadinimas turi atitikti prasmę iš probleminės srities.2. Tas pats ryšys turi ir invertuotą pavadinimą, nusakantį priešingą ryšio kryptį.

Dažniausiai nurodomas tik vienas pavadinimas. Ryšio semantika-išsiaiškinti tikslinga išvardinti tam tikrą ryšio egzempliorių poaibį (ryšio paplitimo diagramą):E1 E2 Jonaitis Petraitis Jonaitis Batai Kojinės Kaklaraištis To reikia ryšio kardinalumui įvertinti. Galima patikslinti kardinalumą. Čia paaiškėja ar ryšys yra būtinas, ar ne. Paplitimo diagrama neįeina į ER modelį. Ji reikalinga tik išsiaiškinimui.Kaidos, išskiriant esybes. Esybėmis negali būti vaizduojami kuriamą inf-os sistemą sudarantys objektai (failai, programa). Tai tik kuriamos inf-os sistemos dalių vidinio atvaizdavimo elementai.Esybėmis neatvaizduojami kuriamos inf-os sistemos išorinio atvaizdavimo elementai (ataskaitos, meniu ir pan.).14. Ryšio samprata ER modelyje.Ryšio samprata. Ryšys atvaizduoja dviejų esybių (arba vienos ir tos pačios esybės pačios su savimi) egzempliorių tarpusavio sąryšį (priklausomybę). Pvz.: pirkėjas perka prekę.

Ryšys egzistuoja tarp esybių egzempliorių (tam tikrų). ER modelyje atvaizduojamas ryšys tarp esybių. Ne visos esybės turi ryšius ir netgi jei turi, ne visur reikia atvaizduoti. Atvaizduojami tik tie, kurie apima mus dominantį kontekstą. Ryšių žymėjimas. Ryšiai žymimi lanku, jungiančiu esybes. Ryšio komponentę sudaro tokios pagrindinės sudėtinės dalys:Esybės, kurias sieja ryšys ir ryšio pavadinimas.Ryšio kardinalumas (matiškumas).Ryšio būtinumas.Galimi 2 ryšio atvejai:Ryšys sieja dviejų skirtingų esybių egzempliorius.Ryšys sieja tos pačios esybės skirtingus egzempliorius. (Pvz.: suvenyrą sudaro knyga ir pakabukas).Kardinalumą galima ir užrašyti: M:1, 1:M, 1:1, M:N.Ryšių būtinumo žymėjimo iliustracija. Yra būtini, privalomi ir neprivalomi ryšiai. Ryšys gali būti, gali ir nebūti.]-alternatyva: arba pilnametis asmuo, arba vaikas.15. Ryšių kardinalumas ER-modelyje. Ryšių kardinalumo tipai ir jo nustatymas.Ryšių kardinalumas. Jeigu esybes sieja tam tikras ryšys, tai galima priimti, kad jis iš pradžių neturi apribojimų. Pvz.: kiekvienas pirkėjas perka kiekvieną prekę ir kiekviena prekė yra perkama kiekvieno pirkėjo.Priešingu atveju: nei vienas A egzempliorius neturi ryšio nei su vienu B esybės egzemplioriumi. Dažniausiai ryšys atspindi esybių egzempliorių tam tikrą Dekartinės sandaugos poaibį. Tiriant ryšių kardinalumą reikia analizuoti ar ryšiai yra funkciniai, ar ne. Tarp esybių A ir B egzistuoja funkcinis ryšys, kai bet kuris esybės A egzempliorius tam tikru laiko momentu gali būti susietas su ne daugiau kaip 1 esybės B egzemplioriumi. Priešingu atveju, jei gali būti daugiau nei 1 ryšys, tai bus nefunkcinis ryšys. B-A-funkcinis (B su A); A-B-nefunkcinis:Priklausomai nuo to ar ryšys funkcinis ar ne, išskiriami ryšių kardinalumo atvejai (tipai):1:1-ryšys abiem kryptim yra funkcinis.1:M, N:1-ryšys funkcinis tik viena kryptimi.M:N-ryšys yra nefunkcinis abiem kryptimis.1:1, 1:M, N:1-hierarchinių struktūrų pagrindas.M:N-modeliuoja tinklines struktūras.Ryšių kardinalumo vaizdavimas diagramose.¾ -vienas su vienu. -vienas su daug. -daug su daug.Konkretus objektų aibės elementas (“darbuotojas Jonaitis”) vadinamas esybės egzemplioriu. Jie ER modelyje tiesiogiai neatvaizduojami. Modeliuojant esybes išreiškiamas tik tas faktas, kad egzistuoja tam tikra objektų klase, nenurodant jos sudėties (ji kinta laike). ER diagramose esybės žymimos stačiakampiais, skrituliais arba ovalais. Viduje įrašomas esybės vardas.

Ryšių kardinalumo nustatymas.Funkcionalumo nustatymas. Nustatant funkcionalumą būtina parinkti tokią ryšio interpretaciją, kuri būtų teisinga esybės egzempliorių atžvilgiu visais laiko momentais. Pvz.: tam tikrame laiko intervale pirkėjai gali įsigyti tik po vieną prekę (susidaro funkcinis ryšys), tačiau per ilgesnį laiką ši taisyklė nepasitvirtina.Nustatant kardinalumo požymį (1:M, N:1, M:N), termino “daug” (M:N) nereikia sutapatinti su terminu “visi”.Ryšio simetriškumo (1:1, M:N) arba asimetriškumo (1:M, N:1) nustatymas.Fiksuoto kardinalumo užregistravimas (kai vienos esybės egzempliorius tam tikru laiko momentu siejasi su fiksuoto kardinalumo egzemplioriumi).16. ER-modelio atributo samprata. Esybės-atributo ryšiai, jų kardinalumas ir žymėjimas.Atributai. Atributas aprašo esybę (identifikuoja, klasifikuoja, matuoja, nusako būseną). Atributas nagrinėjamas tos esybės aspektu. Pvz.: prekė turi prekės kodą, tipą, kainą. Atributo egzempliorius vadinamas atributo reikšme. Pvz.: prekės kaina 100 Lt.Dalis atributų reikšmių yra stabilios, kitos-pakankamai dinamiškos.Esybės ir atributo ryšiai. Šie ryšiai taip pat gali būti charakterizuojami ryšio pavadinimu ir kordinalumu. Ryšio pavadinimas dažniausiai nerodomas. Kardinalumai:1:1-šiuo atveju atributas vadinamas esybės identifikatoriumi. 1 atributo egzempliorius nusako vienintelį esybės egzempliorių ir atvirkščiai. Pvz.: prekė turi prekės kodą ir prekės kodas nusako vienintelį prekės egzempliorių. Galima pastebėti, kad vienareikšmiškam esybių indentifikavimui pakanka, kad ryšys tarp A ir E būtų n:1. Sudarant ER modelį, identifikatorius turi būti parenkamas kruopščiai (ar jis tikrai unikalus).N:1-registruojamas kai esybės egzempliorius turi vienintelę atributo reikšmę, tačiau ta pati atributo reikšmė gali nusakyti kelis esybės egzempliorius. Pvz.:

1:M-fiksuojamas, kai kiekvienas esybės egzm-ius gali turėti daug atributo reikšmių, kurių kiekviena nusako vienintelį esybės egzm-rių. Pvz.:

N:M-pvz.: prekė gali turėti kelias kainas, o tą pačią kainą gali turėti kelios skirtingos prekės.Esybės atributo ryšio žymėjimas.17. Atributų išskyrimo šaltiniai.Dokumentų formos (grafų pavadinimai yra svarbūs). Skirtingose formose tas pats atributas gali turėti skirtingus pavadinimus.Egzistuojančios inf-os sistemos (kompiuteriniai failai, ekrano formos, DB loginė schema). Pavojus: atkartoti seną sistemą, neįvertinant naujų poreikių.Analizuojant dokumentų formas, ataskaitas, susidūriama su išvestiniais atributais, tai reiškia, kad tokia atributo reikšmė gali būti išvesta iš kitų atributo reikšmių. Pvz.: suma gali būti išvedama iš atributų: kiekis ir kaina. Išvestinių atributų reikšmės dažniausiai nesaugomos. Bet yra išimčių:Tam tikrą apibendrintą inf-ą reikia saugoti ilgiau. Tada prie esybių juos parodome.Kai tam tikros veiklos f-jos dažnai naudojasi tam tikrais išvestiniais duomenimis.18. Atributų būtinumo ir unikalumo samprata bei žymėjimas. Esybę identifikuojančių atributų išskyrimas.Atributo reikšmių būtinumo ir unikalumo žymėjimas. Dalis atributų gali būti privalomi (esybės ryšys su atributu privalomas), o kiti gali ne visada įgyti reikšmes. Pvz.: išėjimo iš darbo data personalo apskaitos duomenų bazei. Gali būti neprivalomas ir namų tel. nr. Atributas gali turėti reikšmę tam tikru metu. Pvz.:

Atributo-unikalaus esybės identifikatoriaus išskyrimas. Atributas-esybės identifikatorius, gali būti arba atskiras atributas, keli atributai, ryšys, keli ryšiai arba atributų ir ryšių kombinacija. Šiuo atveju (važtaraščių) identifikatorius bus atributas+ryšys. Gali būti, kad turime kelis unikalius ID. 1 pastaba: esybės atributų reikšmės turi priklausyti nuo viso unikalaus identifikatoriaus, o ne nuo jo dalies. Tai yra ER modelio 2-a normalinė forma. 2 pastaba: atributai privalo priklausyti nuo unikalaus ID. Tai 3-ios normalinės formos požymis. Nepriklausančius atributus reikia pašalinti iš esybės ir dažniausiai tai yra trūkstamos esybės arba trūkstamo ryšio požymis. Pvz.: esybėje DARBUOTOJAS netinka atributas kiekis.

19. Esybių išskyrimas, įvertinant atributų reikšmių kartojimąsį.Esybių formavimas, įvertinant atributų reikšmių kartojimąsį. Esybė komkrečiu momentu gali turėti vienintelę atributo reikšmę. Jeigu taip nėra, tai matyt reikia sukurti naują esybę, kuri su pirmąja turės ryšį M:1. Pvz.:

Pašalinant atributo reikšmių kartojimąsį ER diagramoje pereiname prie pirmos normalinės formos reikalavimų tenkinimo. Atributas tampa esybe, jeigu jis turi atskirą prasmę, yra svarbus ir turi savo savybes (atributus) bei ryšius su kitomis esybėmis.20. Egzempliorių, sinonimų, homonimų ir rolių įtaka, išskiriant esybes.Kalbant apie esybes, dažnai naudojamasi konkrečių jos egzempliorių pavadinimas. Pvz.: vietoj to, kad būtų kalbama bendrai apie zooparko gyvūnus, kalbama apie tigrą, mešką ar kt. maišomos esybės su egzemplioriais.Dažnai pasitaiko sinonimų, pvz.: produktai ir žaliavos, patiekalas ir gaminys.Tas pats žodis, priklausomai nuo konteksto, gali turėti kelias skirtingas reikšmes, pvz.: konferencijos programa (dienotvarkė) apėmė programų (PĮ) sudarimo klausimus. Šiuo atveju gali padėti egzempliorių išvardinimas.Dažnai tam tikri objektai įvardinami remiantis jų paskirtimi (atliekama role). Ypač tai būdinga asmenims arba organizacijoms. Asmens rolės: vedėjas, treneris, sekretorė, žaidėjas… Šios rolės atspindi užimamas pareigas, profesiją, atliekamą f-ją ar vaidmenis ir rolės gali būti atvaizduotos atskiru atributu, o ne būtinai esybe.

21. Neslankūs ryšiai.Neslankūs ryšiai. Dalis ryšių, juos nustačius, negali būti transformuoti keičiant ryšio komponentę sudarantį esybės egzempliorių kitu esybės egzemplioriumi. Šiuo atveju turime neslankų ryšį ir jos gali būti pažymėtos ER modelyje rombu. Pvz.: vaiko santykis su tėvais-vaikas visada turi konkrečius tėvus ir jie nesikeičia.

Paplitimo diagrama:E1 E2 Jonaitis … Nanamira … lietuvis lenkas japonas …

22. Esybių apibendrinimo hierarchija ir žymėjimas.Apibendrinimo hierarchija. Esybė A modeliuoja esybes egzempliorių aibę A={a1, a2, …, an}. Šie egzemplioriai (jų dalis) gali sudaryti kitos esybės, pvz.: B egzempliorių aibę. Tada BÌA:

Pvz.: turime esybę VADYBININKAS, kuri yra esybės DARBUOTOJAI poaibis:

Galimas atvejis, kad kai kurie esybių egzempliorių poaibiai persidengia.Tokie ryšiai sudaro esybių apibendrinimo hierarchiją. Aukštesnio lygio esybė yra bendresnė ir kartais vadinama APIBENDRINANČIA. Žemesnio lygio esybė vadinama apibensrinančios esybės specialiu atveju (specializacija). Bendresnės esybės vadinamos supertipais, o specializuotos-subtipais. Pvz.: vadybininkas yra subtipas esybės DARBUOTOJAS atžvilgiu, tačiau jis gali būti ir supertipas pvz.: esybės VADYB. atžvilgiu. Savybės, būdingos visiems esybių poaibiams, saugomos tik prie juos apibūdinančios superesybės. Tačiau tie poaibiai, subtipai gali turėti ir savo savybių.Apibendrinimo hierarchijos žymėjimas diagramose:

Rodyklė rodo į supertipą.Naudojami laukai, jungiantys apibendrinamas esybes.

23. Esybių poaibių išskyrimas ir jų sudarymo būdai.Esybių poaibius skiriančios savybės. Galimi tokie poaibių atsiradimo keliai:Grupavimas. Esybių egzempliorių poaibės gali būti sugrupuotos tam tikro atributo bendros reikšmės pagrindu, pvz.: pagal atributą SPECIALYBĖ gali būti išskirta VADYBININKAS, INŽINIERIUS.Ypatinga savybė arba ryšys. Tam tikras esybės egzempliorių poaibis gali būti išskirtas, remiantis jo ypatingo ryšio su kitais probleminės srities objektais arba papildomų atributų atžvilgiu.

24. N-mačių santykių modeliavimas ER diagramose.N-mačiai santykiai (ryšiai). Kol kas nagrinėjome tik binarinius ryšius tarp esybių. Analizuojant probleminę sritį, susiduriama su didesnio matiškumo santykiais, pvz.: turime 3 esybes-tiekėjas, žaliava ir projektas.

Įvedame apribojimą, kad tiekėjas tiekia tik tam tikrų rūšių žaliavas tam tikriems projektams.t1 z1 p2t2 z2 p1 Reikia įvesti papildomą esybę:

25. Taisyklės sąvoka. Taisyklių modelio paskirtis. Taisyklės apibrėžimas.Taisyklių modelis. Taisyklės sąvoka organizacijoje turi daug interpretacijų. Pvz.:Taisyklės, nusakančios rūkymo patalpose tvarką;

Taisyklės, nurodančios gamybinių ataskaitų pateikimo dažnumą.Taisyklė, apribojanti į darbą priimtų darbuotojų amžių.Nagrinėsime taisykles, kurios įtakoja arba riboja tam tikrus probleminės srities struktūrinės dalies objektus, kurie atvaizduojami ER modelyje. Tačiau taisyklę galima įsivaizduoti plačiau, negu vien tik struktūrinės komponentės apribojimą. Struktūrinė specifikacijos komponentė apima tik tą specifikacijos dalį, kuri susijusi su esybėmis, ryšiais tarp jų ir atributais, tačiau šalia to vartotojo reikalavimuose gausu taisyklių, kurias irgi reikia užregistruoti. Tuo tikslu sudaromas taisyklių modelis, kuriame taisyklės kaupiamos deklaratyvioje formoje (neprocedūrinėje). Istoriškai taisyklių sąvoka kilusi iš DB pilnumo apribojimo ir vėliau ji buvo išvystyta konceptualaus modeliavimo srityje. Viena iš priežasčių dėl ko reikia modeliuoti taisykles yra ta, kad struktūrinė probleminės srities specifikacija atspindi objektų aibes (klases), o ne atskirus egzepliorius. Joje negalima aprašyti jokių apribojimų, susijusių su atskirais objektų egzeplioriais, o ne su aibe. Dažniausiai taisyklės būna pateiktos natūralia kalba. Sudarant taisyklių modelį, taisyklės išreškiamos tikslesne forma, t.y. sudarant griežtesnę specifikaciją. Be to, specifikuojant taisykles, remiamasi struktūrinės komponentės sąvokomis.Taisyklės apibrėžimas. Taisyklę galima apibrėžti remiantis tokiais teiginiais:Taisyklės-t.y. teiginiai apie probleminės srities būsenas, t.y. jos nusako galimas sistemos būsenas. Kartais taisyklės nusako ir ko negalima daryti.²Sistema² čia suprantama, kaip esybių, atributų ir ryšių egzeplioriai, apibrėžti struktūrinėje probleminės srities specifikacijoje. Pvz.: jeigu struktūrinė komponentė susideda iš esybių: PIRKĖJAS, PREKĖ, RYŠYS TARP PIRK./PREKĖS. Tuomet ²sistema² gali būti sudaryta iš tokių egzepliorių:Pirkėjas – P1 P2 P3Prekė- S1 S2 S3Ryšys P/P- P1S1 P2S2 P3S1Sistemos būsena tam tikru laiko momentu nusakoma šiomis komponentėmis:objektų egzepliorių (P1, P2, P3);objektų savybių aibe, pvz.: pirkėjo egzepliorių skaičius arba vidutinis prekės egzepliorių skičius, tenkinantis tam tikram pirkėjui.Taisyklėmis gali būti taiginiai, nusakantys apribojimus:struktūrinės komponentės objektams. Pvz.: kiekvienas pirkėjas turi būti susietas su bent viena preke;tam tikriems objektų egzeplioriams. Pvz.: prekę S2 gali pirkti tik pirkėjas P1;nustatomos tam tikros objektų savybės arba netgi egzepliorių aibės savybės. Pvz.: max prekių skaičius negali viršyti 1000 vnt.Tradicinio taisyklių modeliavimo sunkumai. Taisyklės tradiciškai išreiškiamos procedūrinėje formoje, o jų išraiškos yra žemame abstrakcijos lygyje (labai detalios). Pvz.: taisyklė, kuri apriboja pirkjų egzempliorių aibę iki 1000:KIEKIS (pirkėjai)£1000IF KIEKIS (pirkėjai)<1000 THENĮvesti naują pirkėjąWRITE ELSE(*Išvesti pranešimą*) (“Pirkėjų skaičius viršytas”)ENDIFProcedūriniame variante pateikti 3 specifikacijos elementai:Pati taisyklė sąlyginėje išraiškos dalyje KIEKIS (pirkėjai)<1000.Atliekami veiksnai: Įvesti naują pirkėją.Atsisakymas atlikti veiksmus, kai taisyklė netenkinama.Ši išraiškos forma paini ir sudėtinga, todėl vartotojui sunkiai suprantama. Žemas abstraktumo lygus. Taikomosiose programose naudojamos taisyklių išraiškos nusako ne pačią taisyklę, bet veiksmus kaip ji turi būti tikrinama, vykdoma.Nustatyti įrašą; KIEKIS=0 DO WHILE NOT EOFKIEKIS=KIEKIS+1ENDDOIš šio pavyzdžio aišku, kad taisyklės prasmė (semantika) atsiskleidžia konkretaus taisyklės realizavimo detalėmis.26. Taisyklių modeliavimo sunkumai.Taisyklių modeliavimo sunkumų suvestinė. Taisyklių specifikaciją sunku skaityti ir suprasti:taisyklės išreiškiamos murodant veiksmus, pranešimus apie klaidas, jų vykdymo sąlygas;galimos įvairiausios tos pačios taisyklės procedūrinės išraiškos formos;taisyklės išreiškiamos detaliame taikymo abstrakcijos lygyje;taisyklės išskaidytos po visą specifikaciją ir nėra pateiktos vienoje vietoje.
Sudėtinga taisykles patikrinti ir patvirtinti (verifikuoti ir validuoti), nes jos yra išbarstytos ir išreikštos procedūrinėje formoje. Be to, sunku patikrinti jų neprieštaringumą, priėmimą ir kartu patenkinti vartotojus, kad jas patvirtintų.Beveik kiekvienoje taikomojoje programoje gali pasitaikyti taisyklių, kurios suteikia prieštaravimų tarp atskirų programinių modulių.Pagrindinė taisyklių procedūrinės išraiškos formos priežastis yra ta, kad jos betarpiškai apriboja galimas strktūrines komponentės būsenas, taigi reglamentuoja veiksmų ir pakitimų rūšis, kurie leidžia keisti objektų būsenas. Sistemos programinio realizavimo metu patogiau taisykles turėti įmontuotas į progamas, o ne saugoti jas atskiroje taisyklių bazėje. Dėl tos priežasties procedūrinė išraiškos forma tebenaudojama, specifikuojant taisykles.27. Šiuolaikiniai taisyklių modeliavimo principai. Taisyklių struktūros analizė ir jų pavyzdžiai.Šiuolaikiniai taisyklių modeliavimo principai. Šie metodai leidžia bent dalinai išvengti minėtų sunkumų, panaudojant šias priemones:Deklaratyviai, o ne procedūriškai išreiškiant daugumą taisyklių.Išreiškia taisykles konceptualiame abstrakcijos lygyje, panaudojant struktūrinės komponentės sąvokas.Atvaizduoti taisykles atskirai nuo kitų specifikacijos dalių (komponenčių) baziniame taisyklių modelyje.Taisyklių struktūra.

Reikšmės: K-kardinalumas; A-aibė; F-funkcija; T-tvarka; A-atributas; E-esybė; E-E-ryšiai tarp esybių; E-A-esybė-atributas. Lentelės eilutėse aprašyti atskiros struktūrinės specifikacijos objektai. Stulpeliuose išvardinti atskiri apribojimų tipai.Atributo kardinalumo taisyklė (1.1). Apriboja tam tikro atributo reikšmių skaičių, pvz.: galimų medžiagos kodų skaičiaus apribotas 1000. KARDINALUMAS (medžiagos kodas)<=1000.Atributo reikšmių aibės apribojimas (1.2). Apriboja atributo įgyjamas reikšmes, pvz.: jei kainos atributas apribotas nuo 50 iki 200, tai galima užrašyti: DIAPAZONAS (kaina)=[50..200]Atributo reikšmės suformavimo f-ja (1.3) nusako, kaip atributo reikšmę gauti iš kitų reikšmių, pvz.: atskaitymai į SODRĄ sudaro 1% sumos. ATSKAITYMAI SODRAI=ATLYGINIMAS*0,01.Dalyvavimo ryšyje taisyklė (3.21). Apriboja dalybaujančių ryšyje egzepliorių aibę. Ryšyje gali dalyvauti arba visi esybės egzeplioriai, arba jų dalis. Pvz.: žaliava-Tiekėjas, gali dalyvauti visi esybės žaliava egzeplioriai. Žaliava: Tiekėjas=Žaliava. Su apribojimu: Interesantas: Konkursas=Interesantas (Amžius<35).Dalis taisyklių gali būti sėkmingai modeliuojamos, naudojant objektinį modeliavimo modelį.28. Proceso sąvoka, specifikavimo komponentės ir rezultatai.Procesų atvaizdavimas. Proceso sąvoka, specifikavimo komponentės ir rezultatai. Procesai-tam tikri organizacijoje vykdomi veiksmai: sąskaitos išrašymas, dešrų gamyba. Proceso sąvokai yra ekvivalentiškos f-jos arba veiksmo sąvokos. Specifikuojant procesus, išskiriamos komponentės:Aukšto lygio procesų dekomponavimas į detalesnio lygio specifikaciją.Susietų procesų grupių identifikavimas, nurodant juos inicijuojančius realaus pasaulio įvykius.Procesų valdymo struktūros užregistravimas šiais aspektais:eiliškumas (procesų vyksmo tvarka);atrinkimas (procesų vyksmo sąlygos);iteratyvumas (ar procesas vyksta 1 ar daugiau kartų).Proceso įėjimų ir išėjimų nustatymas.Pagrindiniai procesų specifikavimo etapų rezultati: 1. Procesų dekompozicijos diagrama (f-jų hierarchijos diagrama). 2. Duomenų srautų diagrama. 3. Būsenų kaitos diagrama. 4. Srautų struktūrograma.5. Struktūrizuota natūrali kalba. 6.Veiksmų diagramos. 7. Sprendimų medis. 8. Sprendimų lentelė. 9. Esybių gyvavimo istorija.29. Procesų dekomponavimas ir dekomponavimo diagrama.Procesų dekomponavimas. Procesų dekompozicijos diagrama (FHD). Sudaryta iš stačiakampių ir briaunų, jungiančių stačiakampius. Stačiakampis-tam tikro detalumo lygio procesas. Briaunos-procesų tarpusavio hierarchijos priklausomybės. Diagramoje vieno lygio porcesai gali būti sutvarkyti, atspindint tarpusavio eiliškumą.

Naudojami esybių vardai turi būti suderinti su ER diagrama. Proceso dekompozicijos diagramoje galima parodyti įvykius, kurie tradiciškai atvaizduojami duomenų srautų diagramoje.30. Duomenų srautų diagrama.Procesų modeliavimas. Duomenų srautų diagrama (DSD). Procesų tarpusavio sąryšiams atvaizduoti naudojama duomenų srautų diagrama (atvaizdavimas per duomenis). PDD-procesų dekompozicijos diagrama ir ER diagrama } apjungia ir papidomai nurodo inf-os srautus. DSD susideda iš: Proceso (inf. apdorojimo).Įvykis, inicijuojantis procesą Þ.Duomenų srautas ®.Duomenų šaltinis (vartotojas) ar imtuvas (siuntėjas arba gavėjas)  .Duomenų saugykla.DSD sudarymo taisyklės:Kiekvienas procesas turi turėti unikalų vardą ir kartais jam suteikiamas numeris (gali būti hierarchinio pobūdžio).

Visi procesai privalo turėti įėjimą ir išėjima. Jie jungia procesą ar kitus diagramos elementus.Duomenų srautas privalo turėti vardą. Procesus sukeliantys įvykiai, kurie neįeina betarpiškai į sistemą žymimi trumpomis strėlėmis su užrašytu įvykio vardu ir pateikami šalia atitinkamo proceso.Išorinės esybės atvaizduojamos stačiakampiu. Jos naudojamos parodyti išorinius inf-os šaltinius arba gavėjus.Duomenų saugyklos tarnauja kaip buferis, kuriame duomenys saugomi procesui atlikus tam tikrus veiksmus. Kiekviena saugykla privalo turėti unikalų vardą. Duomenų saugyklą inf-os srautas betarpiškai negali jungti.DSD gali būti naudojama materialiems inf-os srautams atvaizduoti.

31. Būsenų kaitos diagrama.Būsenų kaitos diagrama. Skirta sistemos būsenų kitimo sąlygoms parodyti. Vartotojas įveda tam tikras komandas, o kompiuteris duoda atsakymą. BKD susideda iš 3-jų dalių:Būsenos, atvaizduojamos stačiakampiu su įrašytu būsenos pavadinimu.Būsenos kaitos žymėjimo, vaizdavimo lanku, jungiančiu išeities būseną su galine būsena.Sąlygos-veiksmo žymėjimo, pateikiamo šalia atitinkamo lanko.

Pirmiausia sistema pereina į gamybos pradžios būseną iš kurios, įvykus tam tikram įvykiui ir jį patikrinus, galima pereiti į tam tikrą būseną. Tuščias stačiakampis nurodo, kad sistema, priklausomai nuo įvykio gali pereiti į įvairias būsenas. Jei įvyksta žinomas įvykis, joks procesas neįnicijuojamas.