Pošaljite svoj dobar rad u bazu znanja je jednostavno. Koristite obrazac ispod

Studenti, postdiplomci, mladi naučnici koji koriste bazu znanja u svom studiranju i radu biće vam veoma zahvalni.

Hostirano na http://www.allbest.ru/

Institut državne službe Omsk

Modeliranje informacionih sistema korišćenjem UML jezika

Smjernice za realizaciju nastavnog rada

I.V. Chervenchuk

• Uvod
• 2 . Unified Modeling LanguageUML
• 4. Razvoj modela softverskog sistema pomoćuUML
• 5. Pitanja implementacije informacionog sistema
• 6. Teme seminarskih radova
• Bibliografska lista

Uvod

Rad se bavi razvojem informacionih sistema korišćenjem objedinjenog jezika modeliranja UML, koji je osnova za nastavni rad iz discipline "Informacioni sistemi i procesi. Modeliranje i upravljanje". Razrađuju se glavne faze racionalnog jedinstvenog procesa razvoja informacionih sistema, daju se primjeri i ilustracije. Date opcije za zadatke za kurs.

Smjernice su namijenjene studentima specijalnosti "Primijenjena informatika" i mogu se koristiti u nastavnom radu, pripremama za ispit, kao iu procesu samostalnog rada.

1. Opći zahtjevi za nastavni rad

Nastavni rad iz discipline "Informacioni sistemi i procesi. Modeliranje i upravljanje" je završna faza izučavanja ovog predmeta i osmišljen je da u praksi konsoliduje osnovna teorijska znanja o modeliranju informacionih sistema. Rad se sastoji u razvoju modela nekog informacionog sistema korišćenjem jedinstvenog jezika modeliranja UML sa njegovom naknadnom implementacijom. Kao tipična opcija za zadatak, predlaže se izrada informacijsko-referentnog sistema na bazi baze podataka, ali se na zahtjev studenta, u dogovoru sa nastavnikom, može izraditi WEB aplikacija, sistem za testiranje ili hardverski uređaj. biti predložen kao zadatak. U ovom slučaju, glavni neophodan zahtjev je korištenje objektno orijentisanog pristupa i konstrukcija UML modela.

Tipičan naslov seminarskog rada izgleda kao "Razvoj informacionog i referentnog sistema _ naslov _ "

Uvod

1. Smisaoni pregled predmetne oblasti. Osnovni sistemski zahtjevi

2. Detaljan model informacionog sistema

2.1 Pogled u smislu slučajeva upotrebe

2.2 Prikaz dizajna

2.3 Pogled na implementaciju

2.4 Pogled procesa (ako je potrebno)

2.5 Prikaz implementacije (ako je potrebno)

3. Implementacija informacionog sistema

Zaključak

Aplikacija Listing programa ili glavnog modula

U uvodu se može ukazati na upotrebu informacionih tehnologija u različitim oblastima delatnosti, uključujući uslužni sektor, prednosti elektronskog računovodstva, probleme izgradnje specijalizovanih informacionih sistema itd.

Ove smjernice sadrže detaljne preporuke za glavne dijelove objašnjenja i primjere dizajna. Treba napomenuti da je glavni predmet ovog kursa razvoj UML modela informacionog sistema, stoga se snažno preporučuje da se UML dijagrami daju u glavnom dijelu objašnjenja, uz detaljne komentare i tekstovi programa trebaju biti uključeni u aplikaciju.

Prilikom razvoja multitasking sistema treba dati pogled na proces. Prikaz implementacije pretpostavlja distribuirani informacioni sistem. Ove vrste, kao i odgovarajući odjeljci objašnjenja, nisu obavezni za realizaciju ovog nastavnog rada, njihova upotreba se pretpostavlja kada se izvode samo određene opcije za nastavni rad.

Kada se u bilješci pokriju problemi implementacije sistema, poželjno je opravdati izbor programskog okruženja i dati korisnički priručnik. Obavezni element je uključivanje ekranskih formi (screen-shortova) implementiranog programa u tekst, podstiče se upotreba alata obrnutog inženjeringa.

U zaključku, glavni rezultati rada su ukratko sumirani: razvijen je UML model sistema, sistem je implementiran korišćenjem takvog i takvog programskog okruženja koje razvijeni sistem dozvoljava, prednosti korišćenih pristupa (na osnovu modeliranje) do dizajna sistema.

modeliranje jezika informacionog sistema

Nastavni rad treba da sadrži 20-30 stranica štampanog teksta sa ilustracijama. Dijagrami presedana, klasa, interakcija moraju se dati bez greške.

2. Unified Modeling Language UML

Racionalni razvoj informacionog sistema podrazumeva duboku preliminarnu analitičku studiju. Prije svega, potrebno je ocrtati obim zadataka koje obavlja razvijeni sistem, zatim izraditi model sistema i na kraju odrediti načine implementacije. Duboko proučavanje arhitekture razvijenog informacionog sistema u početnim fazama projektovanja po pravilu se kasnije isplati, posebno kada se razvijaju projekti velikih razmera uz dugoročnu podršku.

Alati jezika za modeliranje UML (Unified Model Language, - unificirani programski jezik) omogućavaju da se ekspresno i prilično lako izvrši preliminarni konceptualni razvoj informacionog sistema, a istovremeno metodički prati čitav proces razvoja, uključujući i čitav dalji razvoj. životni ciklus informacionog sistema koji se razvija kao softverski proizvod.

UML je jezik za vizualizaciju, specificiranje, konstruisanje i dokumentovanje artefakata softverskih sistema zasnovanih na objektno orijentisanom pristupu.

UML, kao i svaki drugi jezik, sastoji se od vokabulara i pravila koja vam omogućavaju da kombinujete riječi u njemu i dobijete smislene konstrukcije. U jeziku modeliranja, vokabular i pravila su fokusirani na konceptualnu i fizičku reprezentaciju informacionih sistema. Modeliranje je neophodno za razumevanje sistema. Međutim, jedan model nikada nije dovoljan. Naprotiv, da bismo razumjeli bilo koji netrivijalni sistem, potrebno je razviti veliki broj međusobno povezanih modela. Kada se primeni na softverske sisteme, to znači da je potreban jezik koji se može koristiti za opisivanje reprezentacija arhitekture sistema sa različitih tačaka gledišta tokom njegovog razvojnog ciklusa.

UML je jezik vizualizacije, a UML nije samo skup grafičkih simbola. Iza svakog od njih postoji dobro definirana semantika (vidi ) Dakle, model koji je napisao jedan programer može se nedvosmisleno tumačiti drugim ili čak alatom.

UML je jezik specifikacije. U ovom kontekstu, specifikacija znači izgradnju tačnih, nedvosmislenih i kompletnih modela. UML omogućava specifikaciju svih značajnih odluka o analizi, dizajnu i implementaciji koje se moraju donijeti tokom razvoja i implementacije softverskog sistema.

UML je jezik dizajna. Iako UML nije vizuelni programski jezik, modeli kreirani s njim mogu se direktno prevesti u različite specifične programske jezike. Drugim riječima, UML model se može mapirati na jezike kao što su Java, C++, Visual Basic, pa čak i na relacijske tablice baze podataka ili trajne objektno orijentirane objekte baze podataka. Oni koncepti koji su poželjno preneti grafički su predstavljeni u UML-u; oni koji se najbolje opisuju u tekstualnom obliku izražavaju se pomoću programskog jezika.

Takvo preslikavanje modela u programski jezik omogućava direktan dizajn: generiranje koda iz UML modela u određeni jezik. Također možete riješiti inverzni problem: vratiti model iz postojeće implementacije. Naravno, model i implementacija uključuje upotrebu određenog broja specifičnih entiteta. Stoga, obrnuti inženjering zahtijeva i alate i ljudsku intervenciju. Kombinacija naprednog generisanja koda i obrnutog inženjeringa omogućava vam da radite u grafičkim i tekstualnim prikazima, sve dok alati obezbeđuju konzistentnost između oba prikaza.

Pored direktnog mapiranja u programske jezike, UML, zbog svoje ekspresivnosti i jednoznačnosti, omogućava direktno izvršavanje modela, simulaciju ponašanja sistema i kontrolu postojećih sistema.

UML je jezik dokumentacije

Softverska kompanija proizvodi i druge dokumente pored izvršnog koda, uključujući:

Zahtjevi sustava;

arhitektura;

projekat;

izvor;

projektni planovi;

testovi;

prototipovi;

verzije itd.

Ovisno o usvojenoj metodologiji razvoja, neki radovi se izvode formalnije, drugi manje. Referentni dokumenti nisu samo isporučivi dijelovi projekta; neophodni su za upravljanje, za evaluaciju rezultata, ali i kao sredstvo komunikacije između članova tima tokom razvoja sistema i nakon njegovog postavljanja.

UML nudi programeru i menadžmentu sopstveno rešenje za problem dokumentovanja arhitekture sistema i svih njenih detalja, nudi jezik za formulisanje sistemskih zahteva i definisanje testova i, na kraju, pruža alate za modeliranje rada u fazi planiranja i verzije projekta. kontrolu.

Razmotrite razvoj modela informacionog sistema korišćenjem UML jezika na primeru razvoja automatizovanog radnog mesta sekretara odeljenja (u daljem tekstu: radna stanica sekretara odeljenja).

3. Opis predmetne oblasti

Pojam predmetne oblasti baze podataka jedan je od osnovnih pojmova informatike i nema preciznu definiciju. Njegova upotreba u kontekstu IS-a pretpostavlja postojanje vremenski stabilne korelacije između imena, pojmova i određenih realnosti vanjskog svijeta, neovisno o samom IS-u i njegovom krugu korisnika. Dakle, uvod u razmatranje koncepta predmetne oblasti baze podataka ograničava i čini vidljivim prostor za pronalaženje informacija u IS-u i omogućava izvršavanje upita u konačnom vremenu.

Pod opisom predmetne oblasti razumećemo opis okruženja sistema koji se razvija, tipove korisnika sistema, uz navođenje glavnih zadataka čije je rešavanje dodeljeno sistemu.

U preliminarnom opisu predmetne oblasti uvode se glavni pojmovi (rečnik sistema), definišu se tipovi korisnika i njihova prava i formulišu zadaci koje razvijeni sistem treba da reši. Istovremeno, pri opisivanju treba koristiti sredstva zajedničkog jezika i standardne poslovne grafike (slike, dijagrami, tabele).

Prilikom izrade sistemskog rječnika potrebno je definirati nazive entiteta ("učenik", "nastavnik", "disciplina"). Istovremeno, pojam entiteta mi shvatamo kao komponentu modela domene, odnosno kao objekat koji je već identifikovan na konceptualnom nivou. Objekte dodijeljene u predmetnom području analitičar pretvara u entitete.

Entitet je rezultat apstrahovanja stvarnog objekta. Postoje dva problema sa objektima: identifikacija i adekvatan opis. Za identifikaciju koristite ime koje mora biti jedinstveno. Istovremeno, pretpostavlja se da postoji odbacivanje njegovog značenja, koje je svojstveno prirodnom jeziku. Koristi se samo funkcija pokazivača imena. Ime je direktan način identifikacije objekta. Indirektne metode identifikacije objekta uključuju definiciju objekta kroz njegova svojstva (karakteristike ili karakteristike).

Objekti međusobno djeluju kroz svoja svojstva, što dovodi do situacija. Situacije su odnosi koji izražavaju odnose između objekata. Situacije u predmetnoj oblasti opisuju se iskazima o predmetnoj oblasti. U ovoj fazi možete koristiti metode propozicionog računa i predikatskog računa, odnosno formalne, matematičke logike. Na primjer, izjava "Programer i menadžer su zaposleni u kompaniji" opisuje odnos uključivanja. Tako se sve informacije o objektima i entitetima predmetnog područja opisuju pomoću iskaza na prirodnom jeziku.

Možete specificirati strukturne odnose, istaknuti statičke i dinamičke situacije (na taj način uvodeći parametar vremena u model), međutim, za detaljno proučavanje modela, pogodnije je koristiti napredne alate za opisivanje predmetne oblasti, na primjer, UML jezički alati.

Dakle, zadatak je da se razvije sistem „Radna stanica sekretara katedre“ koji bi omogućio automatizovano obračunavanje podataka o zaposlenima i studentima odseka IKT OmSTU, obezbedio fleksibilnost u rešavanju planiranih i neplaniranih konkretnih zadataka obrade računovodstvenih podataka.

U sklopu rješavanja problema razvoja automatizovanog radnog mjesta sekretara odjeljenja izdvajamo sljedeće subjekte:

nastavnici - nastavnici katedre;

studenti- studenti date specijalnosti;

studenti studiraju u grupe, grupa je organizaciona (objedinjujuća) cjelina za studente;

diplomirani studenti, imaju posebnost da, s jedne strane, sami mogu voditi nastavu, s druge strane, sami su studenti i imaju supervizora;

disciplina- predavana disciplina (predmet, predmet).

Održavani entiteti imaju niz atributa koje ćemo kasnije definirati.

Upravljamo sa dvije vrste korisnika: obični korisnik(dalje korisnik, i administrator. Pretpostavlja se da korisnik može pristupiti sistemu sa zahtjevom, prikazati izvještaje, administrator može dodatno modificirati podatke. Na primjer, pomoćnik sekretara katedre može biti korisnik, sam sekretar ili odgovorni nastavnik može biti administrator.

Uzimajući u obzir uvedene uslove, razvijeni sistem treba da obezbedi:

organizovanje potpunog i pouzdanog računovodstva svih zaposlenih i studenata odsjeka;

informatička podrška donošenju upravljačkih odluka, formiranje potpunih i pouzdanih informacija o obrazovnim procesima i rezultatima odjela;

smanjenje troškova rada za izradu primarnih dokumenata i izvještaja;

otklanjanje dupliranja prilikom unosa informacija i nastalih mehaničkih grešaka;

praktično korisničko sučelje;

razlikovanje ovlasti običnih korisnika i administratora.

U ovom primeru rešavamo konkretan problem - razvijamo radnu stanicu za sekretara odeljenja, pa se odeljenje, koje ćemo podrazumevano imati u vidu, uzima kao strukturna jedinica najvišeg nivoa za nas, tj. je, pretpostavlja se da se svi elementi modela odnose samo na ovaj odjel, koji nije eksplicitno specificiran. Strukture višeg nivoa, kao što su fakultet, univerzitet, nećemo razmatrati.

4. Razvoj modela softverskog sistema koristeći UML

UML je jezik specifikacije i vizualizacije, njegove glavne jedinice su dijagrami.

UML dijagram je grafički prikaz skupa elemenata, najčešće prikazanih kao povezani graf sa vrhovima (entitetima) i ivicama (relacijama). Dijagrami karakterišu sistem sa različitih tačaka gledišta. Dijagram je, u određenom smislu, jedna od projekcija sistema. Po pravilu, dijagrami daju sažeti prikaz elemenata koji čine sistem. Isti element može biti prisutan na svim dijagramima, ili samo u nekoliko (najčešći), ili nije prisutan ni na jednom (vrlo rijetko). Teoretski, dijagrami mogu sadržavati bilo koju kombinaciju entiteta i odnosa. U praksi se, međutim, koristi relativno mali broj tipičnih kombinacija, koje odgovaraju pet najčešćih tipova koji čine arhitekturu softverskog sistema (pogledajte sljedeći odjeljak). Dakle, postoji devet tipova dijagrama u UML-u:

dijagrami klasa

dijagrami objekata;

dijagrami slučajeva upotrebe;

dijagrami sekvence;

dijagrami saradnje;

dijagrami stanja;

dijagrami akcije (aktivnosti);

dijagrami komponenti;

dijagrami raspoređivanja.

Konceptualni UML model

Dijagram klasa prikazuje klase, interfejse, objekte i kolaboracije, kao i njihove odnose. Prilikom modeliranja objektno orijentiranih sistema najčešće se koristi ova vrsta dijagrama. Dijagrami klasa odgovaraju statičkom pogledu na sistem sa stanovišta dizajna. Dijagrami klasa koji uključuju aktivne klase odgovaraju statičkom pogledu sistema u smislu procesa.

Dijagram objekata predstavlja objekte i odnose između njih. Oni su statične "fotografije" instanci entiteta prikazanih na dijagramima klasa. Dijagrami objekata, poput dijagrama klasa, odnose se na statički pogled na sistem u smislu dizajna ili procesa, ali sa stvarnom ili lažnom implementacijom na umu.

Dijagram slučaja upotrebe prikazuje slučajeve upotrebe i aktere (poseban slučaj klasa) i odnose između njih. Dijagrami slučajeva upotrebe odnose se na statički pogled na sistem u smislu slučajeva upotrebe. Oni su posebno važni u organizaciji i modeliranju ponašanja sistema.

Dijagrami sekvenci i saradnje su posebni slučajevi interakcijskih dijagrama. Dijagrami interakcije predstavljaju odnose između objekata; pokazuje, posebno, poruke koje objekti mogu razmjenjivati. Dijagrami interakcije odnose se na dinamički pogled na sistem. Istovremeno, dijagrami sekvence odražavaju vremenski poredak poruka, a dijagrami saradnje odražavaju strukturnu organizaciju objekata koji razmjenjuju poruke. Ovi dijagrami su izomorfni, odnosno mogu se transformisati jedan u drugi.

Dijagrami stanja (Statechart dijagrami) predstavljaju automat koji uključuje stanja, prelaze, događaje i vrste akcija. Dijagrami stanja odnose se na dinamički pogled na sistem; oni su posebno važni pri modeliranju ponašanja interfejsa, klase ili saradnje. Oni se fokusiraju na ponašanje objekta ovisno o slijedu događaja, što je vrlo korisno za modeliranje reaktivnih sistema.

Dijagram aktivnosti je poseban slučaj dijagrama stanja; on predstavlja prelaze toka kontrole sa jedne aktivnosti na drugu unutar sistema. Dijagrami aktivnosti odnose se na dinamički pogled na sistem; oni su najvažniji u modeliranju njegovog funkcionisanja i odražavaju tok kontrole između objekata.

Dijagram komponenti pokazuje organizaciju skupa komponenti i zavisnosti koje postoje između njih. Dijagrami komponenti odnose se na statički pogled na sistem sa stanovišta implementacije. Oni se mogu povezati sa dijagramima klasa, pošto je komponenta obično mapirana na jednu ili više klasa, interfejsa ili kolaboracija.

Dijagram implementacije prikazuje konfiguraciju procesnih čvorova sistema i komponenti smještenih u njima. Dijagrami implementacije odnose se na statički pogled na arhitekturu sistema iz perspektive implementacije. Oni su povezani sa dijagramima komponenti jer čvor obično ima jednu ili više komponenti.

Ovo je djelomična lista dijagrama koji se koriste u UML-u. Alati vam omogućavaju da generišete i druge dijagrame, kao što su dijagrami profila baze podataka, dijagrami web aplikacija i tako dalje.

4.1 Dizajniranje pogleda u smislu slučajeva upotrebe

Modeliranje počinje definicijom glavnih zadataka sistema koji se razvija i radnji koje on mora izvršiti. U tu svrhu se koriste dijagrami slučajeva upotrebe. Kao što je već spomenuto, dijagrami slučajeva upotrebe pokazuju slučajeve upotrebe i aktere, kao i odnose između njih.

Presedan (Slučaj upotrebe) je opis niza radnji koje izvodi sistem koji proizvodi vidljivi rezultat koji je značajan za neki određeni Act e ra (glumac). Slučaj upotrebe se koristi za strukturiranje entiteta ponašanja modela. Presedan samo deklariše opis neke radnje sistema, odgovarajući na pitanje "šta da se radi?", ali ne precizira kojim sredstvima. Konkretnu implementaciju ponašanja specificiranog slučajem upotrebe obezbjeđuje klasa, kolaboracija klase ili komponenta.

Glumac je povezani skup uloga koje korisnici slučajeva korištenja obavljaju dok su u interakciji s njima. Tipično, glumac predstavlja ulogu koju igra osoba, hardverski uređaj ili čak drugi sistem u datom sistemu. U razvijenom sistemu „Radna stanica sekretara odeljenja“ akteri su administratori (admin) i korisnik.

Grafički, presedan je prikazan kao elipsa omeđena kontinuiranom linijom, koja obično sadrži samo ime, glumac ima ikonu "malog čovjeka".

Da bi se napravio dijagram slučaja upotrebe, potrebno je identifikovati elementarne radnje koje sistem izvodi i uporediti ih sa slučajevima upotrebe. Istovremeno, poželjno je dati nazive presedana tako da ukazuju na ponašanje, često takvi nazivi sadrže glagole, na primjer, "generirati izvještaj", "pronaći podatke po kriteriju" itd. Možete imenovati slučajeve upotrebe imenicama koje sugeriraju neku radnju, na primjer, "autorizacija", "pretraga", "kontrola".

Vraćajući se na modeliranje radne stanice sekretara odjela, ističemo presedane:

Uređivanjepodaci,

Tražistudent,

Tražinastavnik,

izručenjelistaučiodiscipline,

Autorizacija.

Elementi dijagrama slučajeva upotrebe (slučajevi upotrebe i akteri) moraju biti povezani.

Najčešći odnos između slučajeva upotrebe, slučajeva upotrebe i aktera je povezivanje. U nekim slučajevima se mogu koristiti relacije generalizacije. Ovi odnosi imaju isto značenje kao u dijagramu klasa.

Osim toga, dvije specifične zavisnosti su definirane između slučajeva upotrebe u UML-u - relacija uključivanja i relacija proširenja.

Odnos uključivanja između slučajeva upotrebe znači da je u nekom trenutku osnovnog slučaja upotrebe uključeno (uključeno) ponašanje drugog slučaja upotrebe. Uključeni slučaj upotrebe nikada ne postoji autonomno, već se instancira samo kao dio zatvorenog slučaja upotrebe. Možete zamisliti osnovni slučaj upotrebe kao posuđivanje ponašanja uključenih. Zbog prisustva inkluzijskih relacija moguće je izbjeći višestruke opise istog toka događaja, jer se općenito ponašanje može opisati kao nezavisni presedan uključen u osnovne. Odnos uključivanja je primjer delegiranja, u kojem je skup sistemskih odgovornosti opisan na jednom mjestu (u uključenom slučaju upotrebe), a drugi slučajevi upotrebe uključuju te odgovornosti u svoj skup prema potrebi.

Odnosi uključivanja su prikazani kao zavisnosti sa stereotipom "uključi". Da biste naveli mjesto u toku događaja gdje osnovni slučaj upotrebe uključuje ponašanje drugog, jednostavno napišete riječ uključi praćenu imenom slučaja upotrebe koji želite uključiti.

Odnos proširenja se koristi za modeliranje dijelova slučaja upotrebe koje korisnik percipira kao opciono ponašanje sistema. Na ovaj način možete odvojiti obavezno i ​​opciono ponašanje. Odnosi proširenja se također koriste za modeliranje pojedinačnih podtokova koji se pokreću samo pod određenim okolnostima. Konačno, koriste se za modeliranje više niti koje se mogu pokrenuti u nekom trenutku u skripti kao rezultat eksplicitne interakcije s akterom.

Odnos proširenja je prikazan kao zavisnost sa stereotipom "proširi". Točke proširenja osnovnog scenarija su navedene u opcionom odjeljku. To su jednostavno oznake koje se mogu pojaviti u toku osnovnog slučaja upotrebe.

Primjer korištenja ovog odnosa može biti pristup bazi podataka koja ima operativni dio i arhivu. U ovom slučaju, ako se zahtjevu dostavljaju podaci operativnog dijela, vrši se glavni (osnovni) pristup podacima, a ako podaci operativnog dijela nisu dovoljni, vrši se pristup arhivskim podacima, tj. pristup ide prema proširenom scenariju.

U našem slučaju, presedan uređivanjepodaci uključuje presedane: unospodaci, odstranjivanjepodaci, promjenapodaci.

Dijagram presedana radne stanice sekretara odjeljenja prikazan je na sl.1.

Rice. 1. Dijagram presedana radne stanice sekretara odjeljenja

Presedan Tražistudent uključuje pretraživanje po prezimenu i pretraživanje prema rezultatima akademskog uspjeha.

Prilikom razvijanja pogleda u smislu slučajeva upotrebe, često je potrebno dati prošireni opis slučaja upotrebe (u skraćenoj verziji navodi se samo njegov naziv). U pravilu, na početku rada, tok događaja slučaja upotrebe opisuje se u tekstualnom obliku. Kako zahtjevi za sistem postanu precizniji, bit će zgodnije prijeći na grafički prikaz tokova u dijagramima aktivnosti i interakcije.

Tokovi događaja mogu se opisati korištenjem nestrukturiranog teksta, strukturiranog teksta (sadrži funkcionalne riječi: IF,PRIJETHOSEPORBYE itd.), specijalizovani formalni jezik (pseudokod).

Kada se presedan opisuje kroz tok događaja, važno je naznačiti i glavne i alternativne tokove ponašanja sistema.

Na primjer, razmotrite opis toka događaja slučaja upotrebe autorizacija.

Basic protok događaji. Slučaj upotrebe počinje kada sistem od korisnika zatraži njihovo korisničko ime (Login) i lozinku (Lozinka). Korisnik ga može unijeti sa tastature. Završite unos pritiskom na tipku Enter. Nakon toga, sistem provjerava unesene Login i lozinku, i ako odgovaraju administratoru, potvrđuje ovlaštenje administratora. Tu se presedan završava.

Izuzetno protok događaji. Klijent može u svakom trenutku prekinuti transakciju pritiskom na tipku Otkaži. Ova radnja ponovo pokreće slučaj upotrebe. Nema ulaska u sistem.

Izuzetno protok događaji. Klijent može u bilo koje vrijeme prije pritiska na tipku Enter obrisati svoju prijavu i lozinku.

Izuzetno protok događaji. Ako je klijent unio Login i lozinku koje ne odgovaraju administratoru, od njega se traži da ponovo uđe ili se prijavi kao običan korisnik.

Očigledno, opis presedana nizom događaja uključuje neki algoritam koji se može predstaviti u dijagramu aktivnosti (slika 2).

Dijagram algoritma mora sadržavati početni i krajnji vrh i samo jedan početak i jedan kraj. Dijagram sadrži izvršne vrhove - aktivnosti (označene zaobljenim pravokutnicima), uslovne vrhove (odluka - izbor, prepoznavanje, označene rombovima) i veze.

Slični dijagrami takođe mogu objasniti izvršenje drugih slučajeva upotrebe, na taj način dopunjujući pogled na sistem u smislu slučajeva upotrebe.

Rice. 2. Autorizacija korisnika. Dijagram aktivnosti.

4.2 Pogled na dizajn sa stanovišta dizajna

Pogled dizajna je glavni korak u konceptualizaciji modela. U ovoj fazi se uvode glavne apstrakcije, definišu klase i interfejsi preko kojih se implementira rešavanje zadataka. Ako presedani samo deklarišu ponašanje sistema, tada se u fazi razvoja pogleda, sa stanovišta dizajna, određuje na koji način će se ti presedani implementirati. Statički aspekti ovog tipa razvijaju se kroz dijagrame klasa, dinamički - kroz interakciju i dijagrame stanja (automat).

Dijagrami klasa sadrže klase, interfejse, kolaboracije, kao i odnose između njih. Razvoj dijagrama klasa treba započeti određivanjem klasa koje odgovaraju glavnim entitetima sistema, a koje se po pravilu određuju u početnim fazama razvoja pri opisivanju predmetne oblasti. Ovdje biste trebali odlučiti koje je entitete pogodnije modelirati kao klase, a koje kao njihove atribute. Na primjer, ako bi se unutar fakulteta zahtijevalo da se navede šef za svaki odjel, bilo bi bolje navesti entitet menadžerodjeljenja neka bude atribut klase odjelu koji označava klasu nastavnici ( asocijacija jedan na jedan ), umjesto uvođenja posebne klase menadžerodjeljenja.

Prilikom modeliranja, mora se imati na umu da svaka klasa mora odgovarati nekom stvarnom entitetu ili konceptualnoj apstrakciji iz oblasti kojom se korisnik ili programer bavi. Dobro strukturirana klasa ima sljedeća svojstva:

je dobro definisana apstrakcija nekog koncepta iz rečnika domena problema ili domena rešenja;

sadrži mali, dobro definisan skup dužnosti i obavlja svaku od njih;

održava jasno razdvajanje specifikacija apstrakcije i njihove implementacije;

jasno i jednostavno, ali u isto vrijeme omogućava proširenje i prilagođavanje novim zadacima.

U okviru izrade AWP modela sekretara odeljenja definišemo klase: nastavnici, studenti, diplomirani studenti, discipline, grupe. Očigledno, prvi od njih ima mnogo zajedničkih atributa, pa uvodimo apstraktnu klasu Person, koji će obuhvatiti sva svojstva koja se odnose na osobu u kontekstu sistema koji se razvija (prezime, ime, adresa, itd.). U ovom slučaju osobaće biti superklasa i biti povezana generalizacijskim odnosom sa klasama nastavnici, studenti, diplomirani studenti.

Atribut adresa ima sopstvenu strukturu, da biste je odrazili, možete uvesti dodatnu klasu, nazovimo je T_ ADR(kao što je uobičajeno u mnogim sistemima programiranja, imena klasa počinju slovom T). Treba napomenuti da atribut adresa klasa osoba je instanca klase T_ ADR, odnosno uspostavlja se odnos zavisnosti između ovih klasa (prikazano kao isprekidana strelica sa otvorenim vrhom, strelica pokazuje od zavisnog ka nezavisnom). U našem slučaju, promjena strukture klase T_ ADR podrazumeva promenu klase osoba kroz strukturu odgovarajućeg atributa ( adresa).

Prilikom modeliranja klase T_ ADR atribut index postavljeno primitivnim tipom T_ POSTIDX, definisan kao šesterocifreni decimalni broj. Primitivni tipovi su modelirani po stereotipu " tip" , raspon vrijednosti je specificiran kroz ograničenja zatvorena u vitičaste zagrade.

U razredu nastavnik Istaknimo specifične atribute koji se odnose samo na nastavnika: pozicija, uch. stepen(fakultetska diploma), uch. rang ( akademska titula) pražnjenje(kategorija jedinstvene tarifne skale). Atributi uch. stepen i uch. rang bolje je definirati specijalizovane tipove preko enuma. Enume su modelirane klasom sa stereotipom " enum" (enumeracija - nabrajanje), važeće vrijednosti se zapisuju kao atributi, oznake koje određuju vidljivost atributa su potisnute. U primjeru koji se razmatra, kroz nabrajanje uvodimo specijalizovane klase T_Mora, T_UchSt, T_UchSv, definisanje, odnosno mogućih pozicija, akademskih stepena, akademskih titula kroz nabrajanje. U ovom slučaju, kao i drugdje u sličnim slučajevima, prilikom kreiranja klasa koje specificiraju atribute glavne klase, uspostavljaju se odnosi zavisnosti.

Za razred student unosi se određeni atribut sobađačke knjige. Specifični atributi su definisani za postdiplomsku klasu formuučenje i datumpriznanice. Oblik obuke određuje poseban razred kroz nabrajanje T_FormEducation(puno radno vrijeme, nepuno radno vrijeme).

Klasa grupa ima atribute: naslov, obrazac učenje, brojstud. ( broj studenata ). S obzirom na to da nastavnici predmetne katedre mogu izvoditi nastavu sa grupama sa drugih fakulteta, uvodi se dopunska nastava specijalnost, sa atributima soba(specijalnost), naslov(specijalnost ), fakultet, čiji tipovi nisu specificirani u ovom modelu, iako se mogu definirati putem nabrajanja.

Klasa disciplina ima atribute: soba, naslov, ciklus. Atribut ciklus pomoću specijalizovanog tipa koji se uvodi putem nabrajanja T_ciklusi određuje kojem ciklusu disciplina pripada: ciklusu humanitarnih i društveno-ekonomskih disciplina, matematičkim i prirodno-naučnim disciplinama, opštim stručnim disciplinama, specijalnim disciplinama.

Atributi brojsati, brojsemestri ne može se specificirati u klasi disciplina, pošto zavise od specijalnosti, tim više ih ne možete specificirati u razredu specijalnost. Ovi atributi se odnose na par specijalnost-disciplina i definisani su u klasi – asocijacije Discipline-specijalnosti.

Rice. 3. Dijagram klase radne stanice sekretara odjeljenja (opcija 1)

Prilikom vizualizacije strukture klasa treba obratiti pažnju na vidljivost atributa. Svi razmatrani atributi moraju biti dostupni i javno vidljivi (označeno znakom "+" ili ikonom bez katanca). U razmatranim klasama fokusirali smo se na strukturu, a ne na ponašanje (operacije nisu opisane i ne bi trebalo da budu opisane), stoga je, da bi se olakšala percepcija dijagrama, poželjno potisnuti predstavljanje operacija.

Na uvedenom skupu klasa potrebno je redefinirati veze. Generalizacijski odnosi i zavisnosti su već definirani, ostaje da se definiraju asocijacije.

studenti formirana u grupe, u ovom slučaju asocijacija će izgledati kao agregacija. Agregacija podrazumeva odnos deo-celina, označen punom linijom sa rombom na kraju sa strane celine (u našem slučaju grupe). Mnoštvo odnosa student-grupa je više na jedan. Svaki grupa odnosi se na određeno specijalnost, zauzvrat, nekoliko grupa može odgovarati određenoj specijalnosti, tako da asocijacija grupnih specijalnosti također ima tip višestrukosti više prema jedan.

U ovom slučaju, kao iu većini drugih, smjer asocijacija je dvosmjeran, pa je bolje potisnuti navigaciju (poništite polje Navigable u opciji Detail Role)

Definirajmo povezanost između nastavnici i predavao discipline prema tipu "mnogo-na-više": nastavnik može voditi nekoliko disciplina, neke discipline može predavati više nastavnika. Između discipline i specijaliteti osniva se i udruženje „mnogo-prema mnogima“: nastavni plan i program specijalnosti sadrži mnogo disciplina, većina disciplina se nalazi u planovima rada nekoliko specijalnosti. Klasa asocijacija je pridružena ovoj asocijaciji. Discipline-specijalnosti sa atributima koji označavaju predmet, broj semestara i broj sati date discipline u datoj specijalnosti.

Slično, uvodimo asocijaciju između grupe i nastavnici: nastavnici izvode nastavu u grupama, tip asocijacije višestrukosti je više-prema-mnogo. direktna povezanost između grupe i disciplins ne treba definirati, jer se ovaj odnos prati kroz klasu povezivanja specijalnost.

Da bi se kod diplomiranog studenta prikazalo prisustvo supervizora, potrebno je uvesti asocijaciju između postdiplomca i nastavnika po tipu „mnogo prema jednom“, jedan supervizor može imati više diplomiranih studenata. Na ovoj asocijaciji, sa strane nastavnika, možete eksplicitno naznačiti ulogu: supervizor.

Rice. 4. Dijagram klase radne stanice sekretara odjeljenja (opcija 2)

U svakom grupee postoji čelnik grupe, ovu činjenicu može prikazati dodatna asocijacija (dajmo joj ime starešina) od grupe do učenika sa tipom višestrukosti jedan na jedan. U ovom slučaju, možete eksplicitno odrediti navigaciju.

studenti doktorskih studija također može voditi nastavu u određenoj disciplini sa određenim grupama: asocijacijama mnogo prema mnogo postdiplomske grupe, diplomirani studenti-discipline. Neki diplomirani studenti možda neće predavati nastavu, tako da će tip višestrukosti na krajevima asocijacije biti 0. n.

Konačni dijagram klasa prikazan je na sl. 3.

Rice. 5. Pojednostavljeni dijagram klasa

S obzirom da nastavu predaju i diplomirani studenti i nastavnici, možete uvesti dodatni apstraktni čas, npr. podučavanje, koji je potomak klase osoba i superklasa za klase nastavnik i diplomirani student, što će donekle smanjiti broj veza. (Sl. 4.). U ovom slučaju, iz časova disciplina i grupa udruženja će ići na časove podučavanje, pretpostavljajući povezanost s klasama nastavnik i diplomirani student putem nasljeđivanja (generalizacijski odnos). U razred podučavanje atributi se mogu ukloniti bid(0,5 opklada, puna opklada) i pražnjenje.

Rezultirajući dijagram je prilično složen i opterećen elementima, ali modeliranje klasa je daleko od završenog: neke uslužne klase i sučelja još uvijek treba definirati. Da bismo rasteretili dijagram klasa, napravimo novi pogled na njega (na posebnom dijagramu) ostavljajući sliku glavnih klasa i potiskujući prikaz pomoćnih koji određuju tipove atributa (slika 5).

Na sl. 5, zajedno sa glavnim klasama koje odgovaraju konceptualnim elementima sistema, takođe prikazuje klasu T_ ADR, otkrivajući strukturu adrese, ova klasa je također važna jer sadrži potrebne elemente podataka za nastavnici i diplomirani studenti- potomci klase osoba.

Pređimo na definiranje interfejsa. Klase komuniciraju sa vanjskim svijetom putem interfejsa.

Interfejs (Interfejs) je skup operacija koje definiraju uslugu (skup usluga) koju pruža klasa ili komponenta. Dakle, interfejs opisuje spoljašnje vidljivo ponašanje elementa. Interfejs može predstavljati ponašanje klase ili komponente u celini ili delimično; definiše samo specifikacije operacija (signature), a ne njihove implementacije. Grafičko sučelje je prikazano kao krug, ispod kojeg je napisano njegovo ime. Interfejs retko postoji samostalno - obično je vezan za implementacionu klasu ili bean. Interfejs uvijek pretpostavlja postojanje nekog "ugovora" između strane koja deklarira izvršenje određenog broja operacija i strane koja implementira te operacije.

Stavite klasu na dijagram elektronskisto, koji obuhvata sva svojstva i operacije tabele koja omogućava uređivanje podataka. Struktura ove klase neće biti otkrivena zbog njene velike složenosti. Dakle, u modernim alatima za razvoj aplikacija, korisnik koristi gotove klase i šablone, nasljeđujući njihove mogućnosti, na primjer, VCL biblioteka (Delphi) sadrži klasu TTable, koja inkapsulira mogućnosti proračunske tablice. Klasni potomci elektronskisto su posebne tabele koje sadrže specifične podatke o nastavnicima, diplomiranim studentima, studentima, grupama, disciplinama i specijalnostima. Pravljenje odgovarajućih klasa potomcima klase elektronskisto, za ove klase deklariramo sva svojstva i operacije svojstvene tabelama (registracija u sistemu, umetanje, brisanje, uređivanje podataka, sortiranje, itd.).

Za razred elektronskisto, i, shodno tome, za sve njegove potomke definišemo interfejs uređivanje, podrazumijevaju sve moguće operacije uređivanja podataka (umetanje, brisanje, promjena podataka). Pretpostavlja se da u razredu elektronskisto ove karakteristike su implementirane.

Korištenje posebne klase elektronskisto a nasljeđivanjem je izbjegnuto definisanje posebnih svojstava i interfejsa za uređivanje podataka za svaku tabelu.

Definirajte interfejse Tražinastavnik, Tražidiscipline, pridružujući ih odgovarajućim klasama sa implementacijskim odnosima. Nećemo otkrivati ​​sastav operacija ovih interfejsa (prilično je trivijalan), pa ćemo interfejse prikazati u skraćenom obliku (u obliku kruga). Podsjetimo da je relacija implementacije povezana sa interfejsom u kratkom obliku prikazana kao jednostavna puna linija (kao asocijacija).

Interfejs Tražistudentće biti prikazan sa indikacijom liste operacija kroz stereotipnu klasu, dok je relacija implementacije prikazana kao isprekidana strelica sa zatvorenim vrhom.

Naravno, pretpostavlja se da su uvedeni interfejsi implementirani pomoću klasa kojima su vezani implementacijskim odnosom, odnosno da odgovarajuće klase sadrže operacije i metode koje implementiraju deklarisane interfejse. Da bi se olakšala percepcija, ovi mehanizmi se ne vizualiziraju.

Za upravljanje pravima pristupa i autorizacijom korisnika uvodimo klasu menadžerpristup. Upravitelj pristupa ima atribut privatnog tipa pristupa stolozinke, što je instanca klase CodirTable(kodirana tabela) koja sadrži lozinke ( lozinka) i imena unosa ( Ulogovati se) administratorski korisnici. Pretpostavlja se da su sposobnosti klase korisnosti CodirTable spriječiti neovlaštene korisnike da čitaju korisničke lozinke. U ovoj fazi dizajna jednostavno deklariramo takve mogućnosti, ne zadržavajući se na mehanizmu za njihovu implementaciju, već pod pretpostavkom da su inkapsulirane u klasi CodirTable.

Klasa menadžerpristup sadrži otvorene transakcije unoslozinka i dodeljivanje administratorskih prava, pomoću kojih se sprovodi autorizacija i upravljanje pravima pristupa.

Označite zavisnost između interfejsa za uređivanje podataka ( uređivanje) i menadžer pristupa, pod pretpostavkom da samo korisnici sa administratorskim pravima imaju pune mogućnosti uređivanja podataka.

Rice. 6. Završna klasna šema radne stanice sekretara odjeljenja

Konačni dijagram je prikazan na sl. 6.

Dakle, razvoj objektno orijentisanog modela radne stanice sekretara odeljenja koristeći UML dijagram klasa u ovoj fazi može se smatrati završenim. Naravno, moguće je vratiti se i revidirati neke elemente u toku projektovanja sistema, pri podešavanju zadataka, prilikom razjašnjavanja pojedinačnih detalja. Proces projektovanja informacionih sistema je iterativan. Treba napomenuti da razvijeni dijagram klasa sadrži elemente koji eksplicitno ili implicitno implementiraju sve slučajeve upotrebe dijagrama slučajeva. Svaki slučaj upotrebe dijagrama slučaja upotrebe mora odgovarati ili interfejsu, ili operaciji interfejsa (pretpostavlja se da je implementacija u klasama koje odgovaraju interfejsu), ili operaciji javne klase, ili skupu javnih operacija (u ovom slučaju, slučaj upotrebe se implementira direktno od strane odgovarajuće klase ili skupa klasa).

Razmotrimo proces kreiranja novog zapisa o učeniku koristeći dijagrame sekvence.

Za kreiranje novog zapisa potrebna su administratorska prava, tako da će akter u ovoj interakciji biti administrator ( admin). Ovaj element je već unesen u dijagram slučaja upotrebe, pa hajde da ga prevučemo na dijagram sekvence iz pretraživača prikaza slučajeva upotrebe.

Treba napomenuti da se objekti, odnosno specifične instance klasa pojavljuju na dijagramima interakcije (ime objekta je uvijek podvučeno).

Upravljamo objektima: formuunos, menadžerevidencije, studentska evidencija Petrov(kao konkretan primjer studentske evidencije), menadžertransakcije. Ovaj skup objekata je tipičan kada se modificira zapis u tablici baze podataka.

Formaunos- element korisničkog interfejsa, tipična je forma za unos podataka o studentu (prezime, ime, patronim, adresa i sl.). U našem slučaju, to je malo unaprijed definirana konkretna implementacija standardnog interfejsa uređivanje klasa elektronskisto. Pošto nismo posebno uveli sučelje za uređivanje podataka učenika na dijagramu razreda, stoga eksplicitno navedite klasu za objekat formuunos nećemo.

Menadžerevidencije- objekat koji ima standardni skup mogućnosti upravljanja podacima pri radu sa tabelom. Ovaj skup mogućnosti nasljeđuje klasa studenti iz razreda elektronskisto. Za objekt Menadžerevidencije eksplicitno specificira klasu čija je instanca - studenti.

Petrov- poseban zapis o učeniku Petrovu, novi element tabele o studentima. Ovdje eksplicitno ukazujemo na uvedenu klasu ulazakOstudent. Takvi objekti obično postoje privremeno da pošalju relevantne informacije u bazu podataka tokom transakcija. Nakon završetka transakcije, ovaj objekat se može uništiti. Objekt koji odgovara zapisu može se ponovo kreirati ako je potrebno urediti informacije.

Menadžertransakcije- objekat koji obezbeđuje izvršenje kompletne operacije nad bazom podataka, u ovom slučaju kreiranje novog zapisa o učeniku Petrovu. Ovaj objekt je također odgovoran za izvođenje niza sistemskih funkcija koje prate transakciju. Primeri menadžera transakcija su, na primer, BDE (koristi se za pristup Paradox, Dbase itd. bazama podataka iz Delphi aplikacija), ADO (koristi se za pristup bazama podataka MS Access iz različitih aplikacija).

Dijagram redosleda unosa novog zapisa o studentu u radnoj stanici sekretara odeljenja prikazan je na sl. 7.

Rice. 7. Unošenje podataka učenika. Dijagram sekvence.

Na dijagramu sekvence definiramo prijenos poruka između objekata: stvoritinovoulazak(emituje se od objekta do objekta do kraja lanca kao poruka spasitiulazak); otvorenformu(u obrazac za unos); enterF.I O.,adresa. ( unos podataka za studenta), onda se ti podaci emituju porukama spasitiF.I O.,adresa. Od menadžertransakciješalje se poruka za preuzimanje informacijeOstudent, pružajući povratnu informaciju bazi podataka i konačno refleksivnu poruku menadžertransakcije imenovan kao spasitiulazakvDB, osigurava završetak transakcije.

Po želji, ova interakcija se može predstaviti dijagramom saradnje, koji ilustruje, pre svega, strukturni aspekt interakcije (slika 8). Ovaj dijagram se može napraviti od prethodnog u automatskom načinu rada (u Rational Rose, pritiskom na tipku F5).

Rice. 8. Unošenje podataka učenika. Dijagram saradnje.

Ako je potrebno, projekat se može dopuniti drugim dijagramima interakcije koji otkrivaju rad presedana.

4.3 Dizajniranje profila relacijske baze podataka

U slučaju da se za implementaciju sistema koristi objektno orijentisani DBMS (OODBMS), objektni dijagram izgrađen u prethodnom odeljku je konačni model i direktno uputstvo za implementaciju informacionog sistema. U istom slučaju, kada se relaciona baza podataka (RDB) treba koristiti kao informaciono jezgro informacionog sistema, potrebno je razviti još jedan dijagram, dijagram profila relacione baze podataka.

UML profil za projekt baze podataka je UML ekstenzija koja održava UML metamodel nepromijenjenim. Profil za projekt baze podataka dodaje stereotipe i označene vrijednosti pridružene tim stereotipima, ali ne mijenja osnovni UML metamodel. Kako bi se vizualizirali elementi dizajna baze podataka i pravila za dizajniranje relacijskih baza podataka, odgovarajuće ikone se dodaju profilu (u daljem tekstu jednostavno baze podataka). Baza podataka je opisana pomoću tabela, kolona i relacija. Profil ima elemente koji proširuju bazu podataka, kao što su okidači, pohranjene procedure, ograničenja, korisnički definirani tipovi (domene), pogledi i drugi. Profil pokazuje kako i gdje se svi ovi elementi koriste u modelu. Na profilu UML baze podataka definirani su sljedeći entiteti:

sto ( Tabela) - skup zapisa u bazi podataka za određeni objekat, sastoji se od kolona.

Kolona ( Kolona) je komponenta tabele koja sadrži jedan od atributa tabele (polje tabele).

Primarno ključ ( Primarni ključ) je mogući ključ odabran za identifikaciju redova tablice.

Eksterni ključ ( Strani ključ - jedan ili više stupaca jedne tabele koji su primarni ključevi druge tabele.

Zastupanje ( Pogled) - virtuelna tabela koja se ponaša sa stanovišta korisnika na isti način kao obična tabela, ali ne postoji sama za sebe.

Pohranjeno procedura ( Pohranjena procedura je nezavisna proceduralna funkcija koja se izvodi na serveru.

Domains ( Domains) je važeći skup vrijednosti za atribut ili kolonu.

Pored ovih entiteta, mogu se uvesti i neki dodatni entiteti koji odražavaju specifične aspekte modela baze podataka.

Slični dokumenti

Metodologije razvoja informacionih sistema u domaćoj i stranoj literaturi. Državni i međunarodni standardi u oblasti razvoja softvera. Izrada fragmenta informacionog sistema "Obrazovno-metodološki resurs".

seminarski rad, dodan 28.05.2009


Definicija pojma "sistem". Istorijat razvoja i karakteristike savremenih informacionih sistema. Glavne faze u razvoju automatizovanog informacionog sistema. Upotreba domaćih i međunarodnih standarda u oblasti informacionih sistema.

prezentacija, dodano 14.10.2013


Glavna ideja metodologije i principa RAD-razvoja informacionih sistema, njegove glavne prednosti. Razlozi popularnosti, karakteristike primjene tehnologije. Formulisanje glavnih principa razvoja. Razvojna okruženja koja koriste RAD principe.

prezentacija, dodano 02.04.2013


Uloga upravljačke strukture u informacionom sistemu. Primjeri informacionih sistema. Struktura i klasifikacija informacionih sistema. informacione tehnologije. Faze razvoja informacionih tehnologija. Vrste informacionih tehnologija.

seminarski rad, dodan 17.06.2003


Koncept CASE-alata kao softverskih alata koji podržavaju procese kreiranja i održavanja informacionih sistema (IS). Karakteristike IDEF-tehnologija za razvoj IS. Opis IDEF0 notacije. Razvoj funkcionalnih modela poslovnih procesa.

prezentacija, dodano 07.04.2013


Suština jedinstvenog jezika modeliranja, njegov konceptualni model i princip rada, opšta pravila i mehanizmi. Modeliranje koncepta "kompetencije". Dijagram razreda koji opisuje proces učenja. Implementacija datog informacionog sistema.

teze, dodato 17.02.2015


Razvoj informacionih sistema. Savremeno tržište finansijskog i ekonomskog primenjenog softvera. Prednosti i nedostaci uvođenja automatizovanih informacionih sistema. Metode projektovanja automatizovanih informacionih sistema.

rad, dodato 22.11.2015


Pojam informacionog sistema, vrste informacionih sistema. Analiza alata za razvoj automatizovanih informacionih sistema. Zahtjevi za program i softverski proizvod. Razvoj GUI obrazaca i baza podataka.

disertacije, dodato 23.06.2015


Rješenje za sigurnost informacija. Sistemi za data centre. Šta je oprema data centra? Osnovni koncepti i principi modeliranja. Odabir metode za rješavanje problema. Metoda dopuštenog smjera Seutendijk, Frank–Wulf algoritam.

seminarski rad, dodan 18.05.2017


Koncept informacionog sistema. Faze razvoja informacionih sistema. Procesi u informacionom sistemu. Informacioni sistem za pronalaženje tržišnih niša, za smanjenje troškova proizvodnje. Struktura informacionog sistema. Tehnička podrška.

Koncept modela je ključan u općoj teoriji sistema. Modeliranje kao moćna – a često i jedina – istraživačka metoda podrazumijeva zamjenu stvarnog objekta drugim – materijalnim ili idealnim.
Najvažniji zahtjevi za svaki model su njegova adekvatnost predmetu koji se proučava u okviru određenog zadatka i njegova izvodljivost raspoloživim sredstvima.
U teoriji efikasnosti i informatici model objekta (sistema, operacije) je materijalni ili idealni (mentalno reprezentabilni) sistem koji je kreiran i/ili korišten u rješavanju određenog problema kako bi se steklo novo znanje o originalnom objektu, njemu adekvatno u pogledu proučavanih svojstava i jednostavniji od originala u drugim aspektima .
Klasifikacija glavnih metoda modeliranja (i modela koji im odgovaraju) prikazana je na sl. 3.1.1.
U proučavanju ekonomskih informacionih sistema (EIS) koriste se sve metode modeliranja, međutim, u ovom odeljku glavna pažnja će biti posvećena semiotičkim (znakovnim) metodama.
Podsjetimo da je semiotika (od grčkog semeion - znak, znak) nauka o općim svojstvima znakovnih sistema, odnosno sistema konkretnih ili apstraktnih objekata (znakova), od kojih je svaki povezan s određenom vrijednošću. Primjeri takvih sistema su bilo koji jezici

Rice. 3.1.1. Klasifikacija metoda modeliranja

(prirodni ili vještački, na primjer, jezici opisa podataka ili modeliranja), sistemi signalizacije u društvu i životinjskom svijetu, itd.
Semiotika uključuje tri sekcije: sintaktiku; semantika; pragmatika.
Sintaksa istražuje sintaksu znakovnih sistema bez obzira na bilo kakve interpretacije i probleme povezane sa percepcijom znakovnih sistema kao sredstva komunikacije i komunikacije.
Semantika proučava interpretaciju iskaza znakovnog sistema i, sa stanovišta modeliranja objekata, zauzima glavno mjesto u semiotici.
Pragmatika istražuje odnos korisnika znakovnog sistema prema samom znakovnom sistemu, posebno percepciju smislenih izraza znakovnog sistema.
Od brojnih semiotičkih modela, zbog najveće rasprostranjenosti, posebno u uslovima informatizacije savremenog društva i uvođenja formalnih metoda u sve sfere ljudske delatnosti, izdvajamo matematičke koji realne sisteme prikazuju pomoću matematičkih simbola. Istovremeno, uzimajući u obzir činjenicu da razmatramo metode modeliranja u odnosu na proučavanje sistema u različitim operacijama, koristićemo dobro poznatu metodologiju analize sistema, teorije efikasnosti i donošenja odluka.

Više o temi 3. TEHNOLOGIJA SIMULACIJE INFORMACIJSKIH SISTEMA Metode modeliranja sistema:

1. Simulacijski modeli ekonomskih informacionih sistema Metodološke osnove za primjenu simulacijske metode
2. Odjeljak III OSNOVE MODELIRANJA SISTEMA MARKETINŠKIH USLUGA
3. POGLAVLJE 1. UPRAVLJANI DINAMIČKI SISTEMI KAO OBJEKAT RAČUNARSKE SIMULACIJE
4. Osnove strukturalnog modeliranja marketinškog sistema medicinskih usluga
5. Odjeljak IV PRIMJER PRIMIJENJENE UPOTREBE MODELA MARKETINŠKOG SISTEMA U SIMULACIJSKOM MODELIRANJU
6. Koncept modeliranja finansijske sfere marketing sistema

Zadaci i funkcije informacionog sistema.

IS može riješiti dvije grupe problema. Prva grupa se odnosi na isključivo informatičku podršku glavne djelatnosti (odabir potrebnih poruka, njihova obrada, pohranjivanje, pretraživanje i izdavanje subjektu glavne djelatnosti sa unaprijed određenom potpunošću, tačnošću i efikasnošću u najprikladnijem obliku) . Druga grupa zadataka odnosi se na obradu primljenih informacija/podataka u skladu sa određenim algoritmima u cilju pripreme rješenja za probleme sa kojima se suočava predmet osnovne djelatnosti. Da bi riješio takve probleme, IS mora imati potrebne informacije o predmetnoj oblasti. Da bi riješio takve probleme, IS mora imati određenu umjetnu ili prirodnu inteligenciju. Informacioni sistem - sistem za podršku i automatizaciju intelektualnog rada - pretraga, administracija, ispitivanja i stručne procene ili prosuđivanja, donošenje odluka, upravljanje, prepoznavanje, akumulacija znanja, obuka. Zadaci prve grupe su zadaci informatizacije društva "u širinu".

Zadaci druge grupe - zadaci informatizacije

društvo "dublje".

Da bi riješio postavljene zadatke, IS bi trebao obavljati sljedeće funkcije:

 odabir poruka iz internog i eksternog okruženja neophodnih za realizaciju osnovne aktivnosti;

 unos informacija u IS;

 skladištenje informacija u memoriji IS, njeno ažuriranje i održavanje integriteta;

 obradu, pretraživanje i izdavanje informacija u skladu sa zahtjevima koje postavlja SOD. Obrada može uključivati ​​pripremu opcija za rješavanje problema korisničkih aplikacija.

Informacioni sistem (IS) - međusobno povezani skup alata, metoda i osoblja koji se koriste za skladištenje, obradu i izdavanje informacija u cilju postizanja cilja. Savremeno shvatanje informacionog sistema podrazumeva korišćenje personalnog računara kao glavnog tehničkog sredstva za obradu informacija. IS je okruženje čiji su sastavni elementi računari, računarske mreže, softverski proizvodi, baze podataka, ljudi, razne vrste tehničkih i softverskih komunikacija itd. Iako su sama ideja IS-a i neki principi njihove organizacije nastali mnogo prije pojave kompjutera, kompjuterizacija je povećala efikasnost IS-a za desetine i stotine puta i proširila obim njihove primjene.

Funkcionalna struktura informacionog sistema.

U IS-u je svrsishodno izdvojiti tri nezavisna funkcionalna podsistema.

Podsistem za odabir informacija. Informacijski sistem može obraditi/obraditi samo one informacije koje su u njega unesene. Kvalitet rada IS-a određuje ne samo njegova sposobnost da pronađe i obradi potrebne informacije u svom nizu i da ih korisniku, već i sposobnost odabira relevantnih informacija iz vanjskog okruženja. Ovakvu selekciju vrši podsistem za selekciju informacija, koji akumulira podatke o informacijskim potrebama korisnika IS (internih i eksternih), analizira i raspoređuje te podatke, formirajući informacioni profil IS.

Podsistem za unos, obradu/obradu i skladištenje informacija konvertuje ulazne informacije i zahteve, organizuje njihovo skladištenje i obradu u cilju zadovoljavanja informacionih potreba pretplatnika IS-a.

Implementacija funkcija ovog podsistema podrazumijeva postojanje aparata za opisivanje informacija (sistemi kodiranja, jezik za opis podataka (DDL) itd.), organizovanje i održavanje informacija (logička i fizička organizacija, procedure za održavanje i zaštitu informacija, itd.). itd.), aparat za obradu i obradu informacija (algoritmi, modeli itd.).

Podsistem za pripremu i izdavanje informacija direktno realizuje zadovoljenje informacionih potreba korisnika IS (internih i eksternih). Za ostvarivanje ovog zadatka, podsistem vrši proučavanje i analizu informacionih potreba, utvrđuje oblike i metode njihovog zadovoljenja, optimalan sastav i strukturu izlaznih informacionih proizvoda i organizuje proces informacione podrške i održavanja.

Za obavljanje ovih funkcija potrebno je postojanje uređaja za opisivanje i analizu potreba za informacijama i njihovo izražavanje u IS jeziku (uključujući DDL, IEL, jezik za indeksiranje itd.), kao i uređaja za direktnu informacijsku podršku (procedure pretraživanja i izdavanje informacija, jezika za manipulaciju podacima itd.). Mnoge funkcije podsistema IS se dupliraju ili ukrštaju, što je predmet optimizacije u dizajnu IS. U tom smislu, automatizaciju IS-a prati preraspodjela elemenata IS-a.

Automatizacija uključuje formalizirano predstavljanje (strukturiranje) kako funkcija IS-a, tako i samih informacija koje se obrađuju u IS-u, što vam omogućava unos, obradu/obradu, pohranjivanje i pretraživanje informacija pomoću računala. Svaka formalizacija karakterizira jedan ili drugi nivo adekvatnosti stvorene slike stvarnosti (modela) same stvarnosti. Štaviše, adekvatnost modela stvarnosti određena je i svojstvima same stvarnosti i mogućnostima aparata koji se koristi za njenu formalizovanu reprezentaciju.

Sa ove tačke gledišta, "nivo automatizacije" IS-a usko je povezan sa "stepenom strukturiranosti" informacija. Postoje tri nivoa strukturiranosti informacija: Rigidno strukturirana informacija (podaci) - informacija, čija formalizirana reprezentacija savremenim sredstvima njenog strukturiranja (posebno jezicima za opis podataka) ne dovodi do gubitka adekvatnosti informacionog modela. sama originalna informacija.

informacije. Slabo strukturirana informacija je informacija čija formalizirana reprezentacija dovodi do značajnih gubitaka u adekvatnosti informacijskog modela same izvorne informacije.

Nestrukturirana informacija je informacija za koju trenutno ne postoje načini njenog formalizovanog predstavljanja sa prihvatljivim nivoom adekvatnosti u praksi. Sredstva za predstavljanje takvih informacija treba da imaju visoke semantičke i ekspresivne sposobnosti. Razvoj takvih alata trenutno ide na liniji stvaranja jezika za opis znanja i IEL-a velike semantičke snage.

Metodologije za izgradnju informacionih sistema.

Industrija razvoja automatizovanih sistema za upravljanje informacijama nastala je 1950-ih i 1960-ih godina i do kraja veka dobila je potpuno zaokružene forme.

U prvoj fazi, glavni pristup u projektovanju IS-a bio je metod „odozdo prema gore“, kada je sistem kreiran kao skup aplikacija koje su u ovom trenutku najvažnije za podršku aktivnostima preduzeća. Ovaj pristup se donekle nastavlja i danas. U okviru „patchwork automatizacije“ podrška za pojedinačne funkcije je dosta dobro obezbeđena, ali gotovo da ne postoji strategija za razvoj integrisanog sistema automatizacije.

Sledeća faza je povezana sa spoznajom da postoji potreba za prilično standardnim softverskim alatima za automatizaciju aktivnosti različitih institucija i preduzeća. Od čitavog niza problema, programeri su identifikovali najuočljivije: automatizaciju računovodstvenih analitičkih računovodstvenih i tehnoloških procesa. Sistemi su počeli da se projektuju "odozgo prema dole", tj. pod pretpostavkom da jedan program treba da zadovolji potrebe velikog broja korisnika.

Sama ideja korištenja univerzalnog programa nameće značajna ograničenja sposobnosti programera da formiraju strukturu baze podataka, ekranske forme i biraju algoritme za proračun. Kruti okvir postavljen "odozgo" ne omogućava fleksibilno prilagođavanje sistema specifičnostima delatnosti određenog preduzeća, pa su materijalni i vremenski troškovi implementacije sistema i finog prilagođavanja zahtevima kupac obično značajno premašuje planirane brojke.

Prema statistici koju je prikupila Standish Group (SSL), od 8.380 projekata ispitanih u SSL-u 1994. godine, više od 30% projekata bilo je neuspješno, ukupne vrijednosti preko 80 milijardi dolara. Istovremeno, samo 16% od ukupnog broja projekata je završeno na vrijeme, a prekoračenje troškova iznosilo je 189% planiranog budžeta.

Istovremeno, korisnici IS-a su počeli da postavljaju sve više zahteva koji imaju za cilj omogućavanje integrisane upotrebe korporativnih podataka u upravljanju i planiranju njihovih aktivnosti. Stoga je postojala hitna potreba za formiranjem nove metodologije za izgradnju informacionih sistema.

Prema savremenoj metodologiji, proces kreiranja IS je proces izgradnje i uzastopne transformacije većeg broja konzistentnih modela u svim fazama životnog ciklusa (LC) IS. U svakoj fazi životnog ciklusa za njega se kreiraju specifični modeli - organizacije, zahtjevi za

IS. IS projekat. zahtjevi za prijavu, itd. Obično se razlikuju sljedeće faze kreiranja IS-a: formiranje sistemskih zahtjeva, projektovanje, implementacija, testiranje, puštanje u rad, rad i održavanje.

Početna faza procesa kreiranja IS-a je modeliranje poslovnih procesa koji se odvijaju u organizaciji i ostvaruju njene ciljeve. Model organizacije, opisan u smislu poslovnih procesa poslovnih funkcija, omogućava nam da formulišemo osnovne zahtjeve za IS.

Dizajn IS-a se zasniva na modeliranju domena. Da bi se dobio IP projekat adekvatan predmetnoj oblasti u vidu sistema ispravno funkcionisanih programa, neophodan je holistički, sistemski prikaz modela, koji odražava sve aspekte funkcionisanja budućeg informacionog sistema. Istovremeno, pod modelom domena se podrazumijeva neki sistem koji imitira strukturu ili funkcionisanje predmetnog domena koji se proučava i ispunjava osnovni uslov - da bude adekvatan ovom domenu.

Preliminarno modeliranje predmetnog područja omogućava vam da smanjite vrijeme i vrijeme projektiranja i dobijete efikasniji i kvalitetniji projekt. Bez domenskog modeliranja, postoji velika vjerovatnoća da se napravi veliki broj grešaka u rješavanju strateških pitanja, što dovodi do ekonomskih gubitaka i visokih troškova naknadnog redizajniranja sistema. Kao rezultat toga, sve moderne tehnologije dizajna IS-a su zasnovane na korištenju metodologije domenskog modeliranja.

Modelima domena nameću se sljedeći zahtjevi:

Formalizacija koja daje nedvosmislen opis strukture predmetne oblasti;

Jasnoća za kupce i programere zasnovana na upotrebi grafičkih sredstava za prikaz modela;

Realizabilnost, što podrazumeva dostupnost sredstava fizičke implementacije modela domena i IS;

Davanje procjene efikasnosti implementacije modela domena na osnovu određenih metoda i izračunatih indikatora.

Funkcionalno modeliranje IDEF0: osnovne definicije i odredbe.

Program integrisane kompjuterizacije proizvodnje ICAM (ICAM - Integrated Computer Aided Manufacturing) ima za cilj povećanje efikasnosti industrijskih preduzeća kroz široko uvođenje računarskih (informacionih) tehnologija. U Sjedinjenim Državama je ova okolnost prepoznata još kasnih 70-ih, kada je američko ratno zrakoplovstvo predložilo i implementiralo

IDEF metodologija (ICAM definicija) omogućava vam da istražite strukturu, parametre i karakteristike proizvodno-tehničkih i organizaciono-ekonomskih sistema (u daljem tekstu, gdje ne izaziva nesporazum - sistemi). Opća IDEF metodologija se sastoji od tri posebne metodologije modeliranja zasnovane na grafičkom predstavljanju sistema:

IDEF0 se koristi za kreiranje funkcionalnog modela koji prikazuje strukturu i funkcije sistema, kao i tokove informacija i materijalnih objekata koji povezuju ove funkcije.

IDEF1 se koristi za izgradnju informacionog modela koji prikazuje strukturu i sadržaj tokova informacija neophodnih za podršku funkcijama sistema;

IDEF2 vam omogućava da izgradite dinamički model vremenski promjenjivog ponašanja sistemskih funkcija, informacija i resursa.

Do danas su najrasprostranjenije i korišćene metodologije IDEF0 i IDEF1 (IDEF1X), koje su dobile status federalnih standarda u Sjedinjenim Državama. IDEF0 metodologija, čije su karakteristike i metode primjene opisane u ovom Vodiču (GD), zasnovana je na pristupu koji je razvio Douglas T. Ross ranih 70-ih i nazvan SADT (Structured Analysis & Design Technique – metoda za konstrukcijska analiza i projektovanje). Osnova pristupa i kao rezultat IDEF0 metodologije je grafički jezik za opisivanje (simulacija) sistema, koji ima sljedeća svojstva.

Da bi se pravilno prikazale interakcije komponenti IS-a, važno je izvršiti zajedničko modeliranje takvih komponenti, posebno sa stanovišta sadržaja objekata i funkcija.

Metodologija analize strukturnih sistema uvelike pomaže u rješavanju ovakvih problema.

Strukturna analiza se obično naziva metodom proučavanja sistema, koja počinje njegovim opštim pregledom, a zatim detaljima, dobijajući hijerarhijsku strukturu sa sve većim brojem nivoa. Takve metode karakterizira: podjela na nivoe apstrakcije sa ograničenim brojem elemenata (od 3 do 7); ograničen kontekst, uključujući samo bitne detalje svakog nivoa; korištenje strogih formalnih pravila snimanja; uzastopni pristup rezultatu.

Hajde da definišemo ključne koncepte strukturne analize delatnosti preduzeća (organizacije).

Operacija je elementarna (nedjeljiva) radnja koja se izvodi na jednom radnom mjestu.

Funkcija - skup operacija grupisanih prema određenom atributu.

Poslovni proces je povezan skup funkcija tokom kojih se troše određeni resursi i stvara proizvod (predmet, usluga, naučni proizvod).

otkriće, ideja) koja je od vrijednosti za potrošača.

Podproces je poslovni proces koji je strukturni element nekog poslovnog procesa i od vrijednosti je za potrošača.

Poslovni model je grafički strukturirani opis mreže procesa i operacija povezanih sa podacima, dokumentima, organizacionim jedinicama i drugim objektima koji odražavaju postojeće ili predložene aktivnosti preduzeća. Postoje različite metodologije za strukturno modeliranje predmetne oblasti, među kojima je potrebno izdvojiti funkcionalno orijentisane i objektno orijentisane metodologije.

Opisivanje sistema pomoću IDEF0 naziva se funkcionalni model. Funkcionalni model je namijenjen za opisivanje postojećih poslovnih procesa koji koriste i prirodne i grafičke jezike. Za prenošenje informacija o određenom sistemu, izvor grafičkog jezika je sama IDEF0 metodologija.

IDEF0 metodologija propisuje izgradnju hijerarhijskog sistema dijagrama – pojedinačnih opisa fragmenata sistema. Prvo se vrši opis sistema u celini i njegove interakcije sa spoljnim svetom (kontekst dijagram), nakon čega se vrši funkcionalna dekompozicija - sistem se deli na podsisteme i svaki podsistem se opisuje posebno (dekompozicioni dijagrami) . Zatim se svaki podsistem razlaže na manje, i tako sve dok se ne postigne potreban stepen detalja.

BPwin alatno okruženje.

Modeliranje poslovnih procesa se obično radi pomoću alata za slučajeve. Ovi alati uključuju BPwin (PLATINUM tehnologija), Silverrun (Silverrun tehnologija), Oracle Designer (Oracle), Rational Rose (Rational Software) itd. Funkcionalnost alata za modeliranje strukturnih poslovnih procesa će biti razmotrena korištenjem alata za slučaj BPwin kao primjera.

BPwin podržava tri metodologije modeliranja: funkcionalno modeliranje (IDEF0); opis poslovnih procesa (IDEF3); dijagrami toka podataka (DFD). BPwin ima prilično jednostavan i intuitivan korisnički interfejs. Kada pokrenete BPwin, podrazumevano se pojavljuje glavna traka sa alatkama, paleta alata (čiji izgled zavisi od izabrane notacije) i, sa leve strane, navigator modela - Model Explorer).

Prilikom kreiranja novog modela pojavljuje se dijalog u kojem treba odrediti da li će se model ponovo kreirati ili će se otvoriti iz datoteke ili iz ModelMart spremišta, zatim upisati naziv modela i odabrati metodologiju u kojoj će model će biti izgrađen.

Kao što je gore spomenuto, BPwin podržava tri metodologije - IDEF0, IDEF3 i DFD, od kojih svaka rješava svoje specifične probleme. U BPwin-u je moguće izgraditi mješovite modele, tj. model može sadržavati i IDEF0, IDEF3 i DFD dijagrame u isto vrijeme. Sastav palete alata se automatski mijenja prilikom prelaska s jedne notacije na drugu.

Model u BPwin-u se posmatra kao kolekcija aktivnosti, od kojih svaka radi na nekom skupu podataka. Rad je prikazan kao pravougaonik, podaci kao strelice. Ako lijevom tipkom miša kliknete na bilo koji objekt modela, pojavljuje se kontekstni meni čija svaka stavka odgovara uređivaču nekog svojstva objekta.

U početnim fazama kreiranja IS-a potrebno je razumjeti kako funkcionira organizacija koja će se automatizirati. Menadžer generalno dobro poznaje posao, ali nije u stanju da ulazi u detalje rada svakog običnog zaposlenog. Običan zaposlenik dobro zna šta se dešava na njegovom radnom mestu, ali možda ne zna kako rade njegove kolege. Stoga je za opisivanje poslovanja preduzeća potrebno izgraditi model koji će biti adekvatan predmetnoj oblasti i sadržavati znanja svih učesnika u poslovnim procesima organizacije.

Najpogodniji jezik za modeliranje poslovnih procesa je IDEF0, gdje je sistem predstavljen kao skup aktivnosti ili funkcija u interakciji. Takva čisto funkcionalna orijentacija je fundamentalna - funkcije sistema se analiziraju nezavisno od objekata na kojima rade. Ovo vam omogućava da jasnije modelirate logiku i interakciju procesa organizacije.

Proces modeliranja sistema u IDEF0 počinje kreiranjem kontekstnog dijagrama - dijagrama najapstraktnijeg nivoa opisivanja sistema kao celine, koji sadrži definiciju predmeta modeliranja, svrhe i tačke gledišta na model.

Aktivnosti se odnose na imenovane procese, funkcije ili zadatke koji se odvijaju tokom određenog vremenskog perioda i imaju prepoznatljive rezultate.

Stavke su prikazane kao pravokutnici. Svi radovi moraju biti imenovani i identifikovani. Naziv posla mora biti izražen kao glagolska imenica koja označava radnju (na primjer, "Aktivnost kompanije", "Primanje naloga" itd.). Rad "Aktivnosti kompanije" može imati, na primjer, sljedeću definiciju: "Ovo je model tutorijala koji opisuje aktivnosti kompanije." Prilikom kreiranja novog modela (File/New meni), kontekstni dijagram se automatski kreira sa jednim poslom koji prikazuje sistem kao cjelinu.

Strelice (Strelica) opisuju interakciju posla i predstavljaju neke informacije izražene imenicama (na primjer, "Pozivi korisnika", "Pravila i procedure", "Računovodstveni sistem".)

"Kompjutersko matematičko modeliranje" Problemi izučavanja sekcije. Ovladavanje modeliranjem kao metodom spoznavanja okolne stvarnosti (istraživačka priroda sekcije) - pokazuje se da modeliranje u različitim oblastima znanja ima slične karakteristike, često je za različite procese moguće dobiti veoma bliske modele; - prikazane su prednosti i nedostaci kompjuterskog eksperimenta u odnosu na eksperiment u punoj veličini; - pokazano je da i apstraktni model i kompjuter pružaju priliku da se uči o svijetu oko sebe, upravlja njime u interesu čovjeka. Razvoj praktičnih vještina kompjuterskog modeliranja. Daje se opšta metodologija kompjuterskog matematičkog modeliranja. Na primjeru većeg broja modela iz različitih oblasti nauke i prakse, praktično su implementirane sve faze modeliranja od formulacije problema do interpretacije rezultata dobijenih u toku kompjuterskog eksperimenta. Promoviranje profesionalnog usmjeravanja učenika. Identifikacija studentskih sklonosti istraživačkim aktivnostima, razvoj kreativnih potencijala, orijentacija na izbor zanimanja vezanog za naučnoistraživački rad. Prevazilaženje predmetne nejedinstva, integracija znanja. U okviru kursa matematikom se proučavaju modeli iz različitih oblasti nauke. Razvoj i profesionalizacija rada na računaru. Ovladavanje softverom opšte i specijalizovane namene, sistemima programiranja.

Udžbenik za univerzitete

2. izdanje, revidirano. i dodatne

2014 G.

Tiraž 1000 primjeraka.

Format 60x90/16 (145x215 mm)

Verzija: meki povez

ISBN 978-5-9912-0193-3

BBC 32.882

UDC 621.395

Vulture UMO
Preporučeno od strane UMO za obrazovanje u oblasti telekomunikacija kao nastavno sredstvo za studente visokoškolskih ustanova koji studiraju na specijalnostima „Mreže i komutacioni sistemi“, „Višekanalni telekomunikacioni sistemi“

anotacija

Razmatraju se algoritmi za modeliranje diskretnih i kontinuiranih slučajnih varijabli i procesa. Prikazani su principi i algoritmi za modeliranje informacionih signala opisanih Markovljevim procesima sa diskretnim i kontinuiranim vremenom i razmotreni su principi modeliranja sistema redova čekanja. Opisane su karakteristike opisa i upotrebe fraktalnih i multifraktalnih procesa za modeliranje telekomunikacijskog prometa. Analiziraju se metode i primjeri modeliranja informacionih sistema korišćenjem specijalizovanih softverskih paketa Matlab, Opnet, Mrežni simulator.

Za studente koji studiraju na specijalnostima "Mreže i komutacioni sistemi", "Višekanalni telekomunikacioni sistemi", "Informacioni sistemi i tehnologije".

Uvod

1 Opći principi modeliranja sistema
1.1. Opći koncepti modela i simulacije
1.2. Klasifikacija modela
1.3. Struktura modela
1.4. Metodološke osnove za formalizaciju funkcionisanja složenog sistema
1.5. Modeliranje komponenti
1.6. Faze formiranja matematičkog modela
1.7. Simulacija
Kontrolna pitanja

2 Opći principi izgradnje komunikacionih sistema i mreža
2.1. Koncept izgradnje komunikacionih sistema i mreža
2.2. Slojeviti mrežni modeli
2.2.1. Model na tri nivoa
2.2.2. Arhitektura TCP/IP protokola
2.2.3. OSI referentni model
2.3. Struktura komunikacionih mreža
2.3.1. globalne mreže
2.3.2. Lokalne mreže
2.3.3. Topologije računarske mreže
2.3.4. Ethernet LANs
2.4. Frame relay mreže
2.5. IP telefonija
Kontrolna pitanja

3 Modeliranje slučajnih brojeva
3.1. Opće informacije o slučajnim brojevima
3.2. Programske metode za generiranje ravnomjerno raspoređenih slučajnih brojeva
3.3. Formiranje slučajnih varijabli sa datim zakonom raspodjele
3.3.1. Metoda inverzne funkcije
3.3.2. Približne metode za pretvaranje slučajnih brojeva
3.3.3. Metoda skrininga (metoda Neumannove generacije)
3.4. Metode zasnovane na središnjoj graničnoj teoremi
3.5. Algoritmi za modeliranje najčešće korištenih slučajnih varijabli
3.6. Algoritmi za modeliranje koreliranih slučajnih varijabli
3.7. Formiranje implementacija slučajnih vektora i funkcija
3.7.1. Simulacija n-dimenzionalne slučajne tačke sa nezavisnim koordinatama
3.7.2. Formiranje slučajnog vektora (u okviru teorije korelacije)
3.7.3. Formiranje implementacija slučajnih funkcija

4 Modeliranje diskretnih distribucija
4.1. Bernoullijeva distribucija
4.2. Binomna distribucija
4.3. Poissonova distribucija
4.4. Simulacija testova u shemi slučajnih događaja
4.4.1. Simulacija slučajnih događaja
4.4.2. Simulacija suprotnih događaja
4.4.3. Modeliranje diskretne slučajne varijable
4.4.4. Simulacija kompletne grupe događaja
4.5. Tokovi događaja
4.6. Obrada rezultata simulacije
4.6.1. Tačnost i broj realizacija
4.6.2. Primarna statistička obrada podataka
Kontrolna pitanja

5 Algoritmi za modeliranje stohastičkih signala i interferencije u komunikacijskim sistemima
5.1. Algoritam za modeliranje nestacionarnih slučajnih procesa
5.2. Algoritmi za modeliranje stacionarnih slučajnih procesa
5.3. Metode modeliranja signala i šuma u obliku stohastičkih diferencijalnih jednačina
5.4. Primjeri modela slučajnih procesa u komunikacijskim sistemima
5.4.1. Modeli informacionog procesa
5.4.2. Modeli interferencije
5.4.3. Karakteristike glavnih vrsta smetnji
Kontrolna pitanja

6 Markovljevi stohastički procesi i njihovo modeliranje
6.1. Osnovni koncepti Markovljevog stohastičkog procesa
6.2. Osnovna svojstva diskretnih Markovljevih lanaca
6.3. Neprekidni Markovi lanci
6.3.1. Osnovni koncepti
6.3.2. Polu-Markovljevi procesi
6.3.3. Procesi smrti i reprodukcije
6.4. Modeli kontinualnih Markovljevih slučajnih procesa zasnovani na stohastičkim diferencijalnim jednadžbama
6.5. Modeliranje Markovljevih stohastičkih procesa
6.5.1. Modeliranje diskretnih procesa
6.5.2. Modeliranje skalarnih kontinuiranih procesa
6.5.3. Modeliranje kontinuiranih vektorskih procesa
6.5.4. Modeliranje Gausovog procesa s frakcionom racionalnom spektralnom gustinom
6.5.5. Modeliranje višestruko povezanih sekvenci
6.5.6. Modeliranje Markovljevih procesa sa filterima za oblikovanje
6.5.7. Algoritam za statističko modeliranje Markovljevih lanaca
Kontrolna pitanja

7 Primjeri Markovljevih modela
7.1. Markovi modeli govornog dijaloga pretplatnika
7.1.1. Govorna stanja
7.1.2. Dialogue Models
7.2. Markovi modeli govornog monologa
7.3. Poissonov proces vođen Markovljevim procesom u govornim modelima
7.4. Markovi modeli digitalnih sekvenci na izlazu G.728 kodeka
7.5. Statističko multipleksiranje izvora govornih paketa, uzimajući u obzir Markovljev model telefonskog dijaloga
7.6. Markov model bežičnog kanala sa ARQ/FEC mehanizmom
7.7. Greška u pakovanju
7.8. Proračun karakteristika toka grešaka na osnovu parametara modela
7.8.1. Procjena parametara toka greške
7.8.2. Procjena adekvatnosti modela toka grešaka
7.9. Markovi modeli za procjenu QoS multimedijalnih usluga u realnom vremenu na Internetu
7.9.1. Koncept multimedijalnih usluga u realnom vremenu
7.9.2. Analiza i modeliranje kašnjenja i gubitaka
7.10. Modeli multimedijalnih saobraćajnih tokova
Kontrolna pitanja

8 Sistemi čekanja i njihovo modeliranje
8.1. Opće karakteristike sistema čekanja
8.2. Struktura sistema čekanja
8.3. Sistemi čekanja
8.3.1. Servisni sistem M/M/1
8.3.2. Servisni sistem M/G/1
8.3.3. Mreže sa velikim brojem čvorova povezanih komunikacijskim kanalima
8.3.4. Prioritetna usluga
8.3.5. Servisni sistem M/M/N/m
8.4. Sistemi čekanja sa kvarovima
8.5. Opšti principi za modeliranje sistema čekanja
8.5.1. Metoda statističkog ispitivanja
8.5.2. Blok modeli procesa funkcionisanja sistema
8.5.3. Osobine modeliranja korištenjem Q-šema
Kontrolna pitanja

9 Modeliranje informacionih sistema korišćenjem standardnih tehničkih sredstava
9.1. Modeliranje sistema i programski jezici
9.2. Razumijevanje jezika GPSS
9.2.1. Dinamički GPSS objekti. Blokovi orijentirani na transakcije (izvodi)
9.2.2. Hardverski orijentirani blokovi (izjave)
9.2.3. Omnichannel Service
9.2.4. GPSS statistički blokovi
9.2.5. GPSS operativne jedinice
9.2.6. Ostale GPSS jedinice
9.3. Simulacijsko modeliranje ETHERNET mreže u GPSS okruženju
Kontrolna pitanja

10 Modeliranje sistema za prenos informacija
10.1. Tipičan sistem za prenos podataka
10.2. Otpornost na šum prijenosa diskretnih signala. Optimalan prijem
10.3. Procjena vjerovatnoće pogrešnog prijema diskretnih signala sa potpuno poznatim parametrima
10.4. Otpornost na šum diskretnih signala sa slučajnim parametrima
10.5. Otpornost na šum diskretnih signala sa nekoherentnim prijemom
10.6. Otpornost na šum diskretnih signala sa nasumičnim bitnim parametrima
10.7. Algoritmi za generiranje diskretnih signala
10.8. Algoritam generiranja smetnji
10.9. Algoritam za demodulaciju diskretnog signala
10.10. Struktura simulacionog kompleksa i njegove potprograme
10.11. Mathworks Matlab softversko okruženje i Simulink paket za vizuelno modeliranje
10.11.1. Tehnički opis i interfejs
10.11.2. Simulink paket vizualne simulacije
10.11.3. Kreiranje i maskiranje podsistema
10.11.4. Communications Toolbox Extension Pack
10.12. Simulacija blokova sistema za prenos podataka WiMAX standarda
10.12.1. Simulacija predajnika
10.12.2. Modeliranje kanala prijenosa
10.12.3. Simulacija prijemnika
10.12.4. Implementacija modela u Mathlabu
10.13. Rezultati simulacije WiMAX sistema
Kontrolna pitanja

11 Samoslični procesi i njihova primjena u telekomunikacijama
11.1. Osnove teorije fraktalnih procesa
11.2. Multifraktalni procesi
11.3. Procjena Hurstovog eksponenta
11.4. Multifraktalna analiza pomoću softvera
11.4.1. Opis softvera
11.4.2. Primjeri procjene stepena samosličnosti
11.5. Algoritmi i softver za multifraktalnu analizu
11.6. Uticaj samosličnosti saobraćaja na karakteristike uslužnog sistema
11.7. Metode modeliranja samosličnih procesa u TV saobraćaju
11.8. Istraživanje samoslične strukture Ethernet saobraćaja
11.9. Upravljanje zagušenjima sličnog saobraćaja
11.10. fraktalno braunovo kretanje
11.10.1. Algoritam generiranja RMD FBD
11.10.2. SRA-algoritam za generiranje FBD-a
11.12. Fraktalni Gausov šum
11.12.1. Algoritam FGN sinteze
11.12.2. Evaluacija rezultata simulacije
Kontrolna pitanja

12 Modeliranje čvora telekomunikacijske mreže
12.1. Osnove protokola Frame Relay
12.2. Dizajn mrežnog čvora Frame Relay
12.3. Rezultati simulacije FR rutera sa G.728 kodecima na ulazu
12.4. Utjecaj samosličnosti saobraćaja na QoS
Kontrolna pitanja

13 Specijalizovani sistemi za simulaciono modeliranje računarskih mreža
13.1. Opšte karakteristike specijalizovanih paketa primenjenih programa za mrežno modeliranje
13.2. Opšti principi modeliranja u okruženju OPNET Modeler
13.3. Primjeri OPNET aplikacija
13.3.1. Model za procjenu kvaliteta usluge
13.3.2. Implementacija modela lokalne mreže
Kontrolna pitanja

14 Simulacija sa mrežnim simulatorom 2
14.1. Istorija nastanka i arhitektura NS2 paketa
14.2. Kreiranje objekta simulatora
14.3. Kreirajte topologiju mreže
14.4. Postavljanje parametara generatora
14.4.1. Eksponencijalno uključeno/isključeno
14.4.2. Pareto On/Off
14.5. Dva glavna algoritma čekanja
14.6. Adaptivno rutiranje u NS2
14.6.1. Interfejs za programiranje aplikacije na nivou korisnika
14.6.2. Interna arhitektura
14.6.3. Proširenja za druge klase
14.6.4. Nedostaci
14.6.5. Lista naredbi koje se koriste za simulaciju dinamičkih scenarija u NS2
14.6.6. Primjer dinamičkog rutiranja u NS2
14.7. Pokretanje skriptnog programa u NS2
14.8. Procedura za obradu rezultata simulacije
14.9. Primjer simulacije bežične mreže
14.10. Primjer simulacije kvaliteta striming video prijenosa korištenjem NS 2 paketa
14.10.1. Struktura softversko-hardverskog kompleksa za procjenu kvaliteta streaming videa
14.10.2. Funkcionalni moduli PAK
14.10.3. Ocjena kvalitete videa