MINISTARSTVO OBRAZOVANJA RUJSKE FEDERACIJE ULJANOVSKI DRŽAVNI TEHNIČKI UNIVERZITET V.S. SCHKLEIN MODELIRANJE INFORMACIONIH SISTEMA Bilješke sa predavanja za studente smjera 652100 "Konstrukcija aviona" Univerzitet u Shcheklein V.S. Ŝ Modeliranje informacionih sistema: bilješke s predavanja / V.S. SHCHEKLEIN. - Uljanovsk: UlSTU, 2002.-- str. Bilješke sa predavanja su izbor materijala korištenog u školskoj 1999/2000. godini pri izvođenju nastave iz discipline "Modeliranje informacionih sistema". Namijenjen je studentima smjerova: 130107 "Softverska obrada građevinskog materijala" i 130111 "Projektno upravljanje proizvodnjom aviona". Ovaj priručnik nije potpun, planirano je da se uključi novi razvijeni materijal, čiji se odabir i dizajn vrši u skladu sa odobrenim programom discipline. 3 SADRŽAJ UVOD ………………………………………………………… .. NJEGOVA IMPLEMENTACIJA POMOĆU RAČUNARA …………… 7 3. GENERALIZOVANI ALGORITMI STATISTIČKOG MODELIRANJA …………………………… ……………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………… …………………… 9 DISTRIBUCIJA. SIMULACIJA SLUČAJNIH DOGAĐAJA …………………………………………………… .. 5. PRISTUP SIMULACIJI SISTEMA …………………… ... 15 6. POSTAVLJANJE SLUČAJNIH VRIJEDNOSTI I SLUČAJNI DOGAĐAJI U EXCEL-u ...................... 23 8. MODELIRANJE SISTEMA MASOVNIH USLUGA. 25 9. Struktura informacionog i računarskog sistematskog TEM-a ........................................ ................................................. 26 9.1. Koncept procesa …………………………………………………………… .. 28 9.2. Obim posla …………………………………………………… 29 10. POKAZATELJI PERFORMANSE INFORMACIONOG SISTEMA ………………………………………………………… ……… .. 30 11. PROCJENA PERFORMANSE KOMPONENTI SISTEMA ……………………………………………………………………….…. 31 12. PROCJENA PERFORMANSE SISTEMA OPĆENITO ……. 32 13. UTICAJ NAČINA OBRADE PODATAKA ……………………………… .. 35 14. KARAKTERISTIKE POUZDANOSTI …………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………… .. … ……………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………… ………………………………………………………………………………………………… ” ……………. 40 LITERATURA ………………………………………………. 46 4 UVOD Korisnost matematičkog modeliranja za rješavanje praktičnih problema uopće ne izaziva sumnju. Može se postaviti pitanje zašto je potrebno ovladavanje modeliranjem informacionih sistema (a sada se ovi sistemi ne mogu zamisliti bez kompjuterske tehnologije) za konstruktore aviona fokusirane na tehnologiju proizvodnje aviona? Moderna tehnologija postaje sve više automatizirana. Savremeni proizvođač aviona, bilo da je dizajner ili tehnolog, u svom radu mora koristiti kompjutere. Postoji opasnost od neadekvatne procene mogućnosti računara pri rešavanju inženjerskih problema. To može dovesti ili do odbijanja automatizacije jednog ili drugog fragmenta tehnološkog procesa, ili do neopravdanih troškova za računarsku opremu, čije su mogućnosti znatno precijenjene u odnosu na potrebne. U tom slučaju takozvani zdrav razum može dovesti do ozbiljnih grešaka u procjeni. Cilj discipline je opremiti mladog specijalistu aparatom za procjenu informacionih i računarskih sistema kako bi mogao pravilno uklopiti sredstva automatizacije u konture proizvodnje ili upravljanja. Osim toga, modeliranjem određenih sistema studenti stiču indirektno iskustvo u optimizaciji sistema i jačaju vještine korištenja računara u rješavanju profesionalnih problema. 1. OSNOVNI POJMOVI TEORIJE MODELIRANJA Modeliranje je zamjena jednog objekta drugim radi dobijanja informacija o najvažnijim svojstvima objekta – originala uz pomoć objekta – modela. Model (francuski modele od lat. modulas - mjera, uzorak): 1) uzorak za masovnu proizvodnju proizvoda; brend proizvoda; 2) proizvod sa kojeg se uklanja obrazac (šabloni, šare, plasice); 3) lice ili predmet koji je umetnik prikazao; 4) uređaj koji reprodukuje strukturu ili radnju nekog drugog uređaja; 5) bilo koju sliku predmeta, procesa ili pojave koja se koristi kao predstavnik originala (slika, dijagram, crtež, mapa); 6) matematički aparat koji opisuje predmet, proces ili pojavu; 7) uređaj za dobijanje otiska u kalupu za livenje. U nastavku, osim ako nije drugačije navedeno, model će se shvatiti kao matematički aparat. Svi modeli imaju određenu strukturu (statičku ili dinamičku, materijalnu ili idealnu), koja je slična strukturi originalnog objekta. U procesu rada model se ponaša kao relativno nezavisan kvazi-objekt, što omogućava da se tokom istraživanja dobije određena saznanja o samom objektu. Ako se rezultati takve studije (modeliranja) potvrde i mogu poslužiti kao osnova za predviđanje u objektima koji se proučavaju, onda kažu da je model adekvatan objektu. U ovom slučaju, adekvatnost modela zavisi od svrhe modeliranja i usvojenih kriterijuma. Proces modeliranja pretpostavlja prisustvo: - predmeta istraživanja; - istraživač sa određenim zadatkom; - model kreiran za dobijanje informacija o objektu neophodne za rešavanje problema. U odnosu na model, istraživač je eksperimentator. Treba imati na umu da svaki eksperiment može imati značajan značaj u određenom području nauke i tehnologije samo uz posebnu obradu njegovih rezultata. Jedan od najvažnijih aspekata modeliranja sistema je problem cilja. Svaki model se gradi u zavisnosti od cilja koji istraživač postavlja, stoga je jedan od glavnih problema u modeliranju problem zadatka cilja. Sličnost procesa koji se odvija u modelu sa stvarnim procesom nije sama sebi svrha, već uslov za ispravno funkcionisanje modela. Kao cilj treba postaviti zadatak proučavanja bilo kojeg aspekta funkcionisanja objekta. Ako su ciljevi modeliranja jasni, onda se javlja sljedeći problem, problem izgradnje modela. Ova konstrukcija se ispostavlja mogućom ako postoje informacije ili se iznesu hipoteze u vezi sa strukturom, algoritmima i parametrima istraživanog objekta. Treba istaći ulogu istraživača u procesu izgradnje modela, ovaj proces je kreativan, zasnovan na znanju, iskustvu, heuristici. Formalne metode koje omogućavaju dovoljno tačan opis sistema ili procesa su nekompletne ili jednostavno odsutne. Stoga je izbor ove ili one analogije u potpunosti zasnovan na iskustvu istraživača, a greške istraživača mogu dovesti do pogrešnih rezultata simulacije. Kada je model izgrađen, onda se sljedeći problem može smatrati problemom rada s njim, implementacijom modela. Ovdje su glavni zadaci minimizirati vrijeme za postizanje konačnih rezultata i osigurati njihovu pouzdanost. Za pravilno konstruisan model karakteristično je da otkriva samo one zakonitosti koje su potrebne istraživaču, a ne uzima u obzir svojstva sistema – originala, koja su u datom trenutku beznačajna. Klasifikacija tipova modeliranja sistema prikazana je na Sl. 1.1. Matematičko modeliranje je konstrukcija i upotreba matematičkih modela za proučavanje ponašanja sistema (objekata) u različitim uslovima, za dobijanje (izračunavanje) određenih karakteristika originala bez uzimanja merenja ili sa malim brojem njih. U okviru matematičkog modeliranja razvila su se dva pristupa: - analitički; - imitacija. 6 Modeliranje sistema Deterministički Stohastički Statički Dinamički Diskretni Diskretni Kontinuirani Apstraktni Materijal Vizuelni Simbolični Matematički Prirodni Fizički Analitički Kombinovani. Simulacija Sl. 1.1. Analitički pristup zasniva se na konstrukciji formulacijskih zavisnosti koje povezuju parametre i elemente sistema. Dugo je ovaj pristup bio zapravo matematički pristup. Međutim, kada se razmatraju složeni sistemi, stroge matematičke zavisnosti su veoma složene; potreban je veliki broj merenja da bi se dobile tražene vrednosti parametara. Analiza karakteristika procesa funkcionisanja složenih sistema korišćenjem samo analitičkih metoda istraživanja nailazi na značajne poteškoće, što dovodi do potrebe da se modeli značajno pojednostave bilo u fazi njihove konstrukcije, bilo u procesu rada sa modelom, čime se smanjuje pouzdanost rezultata. Simulacijski (statistički) pristup modeliranju zasniva se na korišćenju Čebiševljeve granične teoreme u probabilističkom prikazu parametara sistema. Na osnovu preliminarne studije modeliranog sistema, prilično je jednostavno odrediti vrste i vrijednosti zakona raspodjele za slučajne vrijednosti parametara. U okviru simulacionog pristupa koriste se analitičke zavisnosti između parametara elemenata sistema, međutim, ove zavisnosti su generalizovanije, pojednostavljene prirode. Oni su mnogo jednostavniji od zavisnosti u analitičkom pristupu. 7 Matematičko modeliranje sistema, uključujući informacione sisteme, ima za cilj optimizaciju strukture sistema, izbor najoptimalnijih načina funkcionisanja sistema, određivanje potrebnih karakteristika hardvera i softvera. Matematičko modeliranje tehnoloških procesa, uključujući i informacijske procese, ima za glavne ciljeve pronalaženje optimalnih ili prihvatljivih karakteristika samog objekta, pronalaženje optimalnih načina obrade, obuku kadrova i obezbjeđivanje određenih upravljačkih funkcija. U svakom slučaju, modeliranje mora ispunjavati sljedeće zahtjeve: - modeli moraju biti adekvatni odgovarajućim sistemima ili tehnološkim zadacima; - mora se osigurati potrebna tačnost; - treba osigurati pogodnost korisnika - stručnjaka za tehnologiju ili obradu (upravljanje) informacija: - razumljiv interfejs za upravljanje modeliranjem; - dovoljna brzina rada; - vidljivost rezultata; - prihvatljivi troškovi razvoja i upotrebe alata za simulaciju. 2. SUŠTINA METODE STATISTIČKIH TESTOVA I NJEGOVA IMPLEMENTACIJA UZ POMOĆ RAČUNARA Metoda statističkog modeliranja sastoji se u reprodukciji procesa koji se proučava korišćenjem verovatnosnog matematičkog modela i izračunavanju karakteristika ovog procesa. Metoda se zasniva na ponovljenom testiranju konstruisanog modela sa naknadnom statističkom obradom dobijenih podataka u cilju određivanja karakteristika procesa koji se razmatra u vidu statističkih procena njegovih parametara. Razmotrimo jednačinu: y = f (x, t, ξ), (2.1) gdje je y sistemski parametar koji treba odrediti, x je fazna varijabla, t je vrijeme, ξ je slučajni parametar, čiji je zakon distribucije nama poznato. Ako je funkcija f u suštini nelinearna, onda ne postoje univerzalne metode rješenja za rješavanje ovog problema, a dovoljno potpuno razvijene regularne metode za pronalaženje optimalnih rješenja mogu se primijeniti samo stavljanjem vidljivosti upotrebe matematike u prvi plan; pojednostavljenja će dovesti do ozbiljan gubitak tačnosti. Matematički model će postati neadekvatan 8 sistemu koji se proučava, a modeliranje će biti samo oblik zablude. Međutim, ako je moguće konstruisati funkciju y = ϕ (ξ) i generator slučajnih brojeva ξ 1, ξ 2, ..., ξ N sa datim zakonom raspodjele, tada se vrijednost y može izračunati kao y = ∑ ϕ (ξ i) N, (2.2) gdje je ϕ (ξ 1) vrijednost i-te realizacije. Ako je f (x, t, ξ) analitički model procesa transformacije informacija ili tehnološkog procesa obrade dijela, onda će ϕ (ξ) biti statistički model. O nekim principima i tehnikama za konstruisanje statističkih modela biće reči kasnije. Važno je da pri konstruisanju funkcije y = ϕ (ξ) i generatora slučajnih brojeva ξ 1, ξ 2, ..., ξ N na papiru, u ogromnoj većini slučajeva ih je prilično lako implementirati na računar koristeći odgovarajući softver. U ovom slučaju, rezultati će sadržavati grešku, ali je ta greška manja od grešaka zbog pretpostavki u analitičkom modelu. Osim toga, greška zbog primjene statističkog modela može se kvantifikovati. Ova tehnika je proširena na složenije slučajeve, kada jednačina (2.1) sadrži ne samo slučajne parametre, već i slučajne funkcije. Nakon dobijanja N realizacija na računaru, slijedi faza obrade statistike koja omogućava izračunavanje, uz matematičko očekivanje (2.2), i drugih parametara ϕ (ξ), na primjer, varijanse D = 1 N * ∑ xi - 1 N 2 * (∑ xi). U metodi statističkih testova, da bi se dobili dovoljno pouzdani rezultati, potrebno je obezbijediti veliki broj realizacija N, osim toga, uz promjenu barem jednog početnog parametra zadatka, potrebno je izvršiti niz od N testova ponovo. Kod složenih modela, neopravdano velika vrijednost N može postati faktor koji odlaže prijem rezultata. Stoga je važno pravilno procijeniti potreban broj rezultata. Interval povjerenja ε, vjerovatnoća povjerenja α, varijansa D i broj realizacija N povezani su relacijom ε = D NF −1 (α), gdje je F −1 (α) funkcija inverzna Laplaceovoj funkciji. U praksi možete koristiti omjer N ≤ D ε 2 * 6,76 za α ≥ 0,99, uzimajući, radi pouzdanosti, najveću vrijednost N iz omjera (). Procjena varijanse D može se dobiti unaprijed koristeći isti statistički model za broj realizacija n, n<< N . 9 При построении статистических моделей информационных систем ис- пользуется общий и прикладной математический аппарат. В качестве приме- ра можно привести аппарат систем массового обслуживания. Система массо- вого обслуживания (СМО) - система, предназначенная для выполнения пото- ка однотипных требований случайного характера. Статистическое моделиро- вание СМО заключается в многократном воспроизведении исследуемого процесса (технического, социального и т.д.) при помощи вероятностной ма- тематической модели и соответствующей обработке получаемой при этом статистики. Существуют пакеты программ статистического моделирования СМО, однако они требуют определенных усилий для их освоения и не всегда доступны. Поэтому в рамках дисциплины предлагается достаточно простой подход, позволяющий с наименьшими затратами моделировать простые СМО. При этом предполагается, что пользователь ознакомлен с теорией мас- сового обслуживания и имеет навыки работы на компьютере. Следует пом- нить, что массовое обслуживание - важный, но далеко не единственный предмет статистического моделирования. На основе этого метода решаются, например, задачи физики (ядерной, твердого тела, термодинамики), задачи оптимизации маршрутов, моделирования игр и т.п. 3. ОБОБЩЕННЫЕ АЛГОРИТМЫ СТАТИСТИЧЕСКОГО МОДЕЛИРОВАНИЯ Существуют две схемы статистического моделирования: - моделирование по принципу особых состояний; - моделирование по принципу ∧ t . Порядок моделирования по принципу особых состояний заключается в выполнении следующих действий: 1) случайным образом определяется событие с минимальным временем - бо- лее раннее событие; 2) модельному времени присваивается значение времени наступления наибо- лее раннего события; 3) определяется тип наступившего события; 4) в зависимости от типа наступившего события осуществляется выполнение тех или иных блоков математической модели; 5) перечисленные действия повторяются до истечения времени моделирова- ния. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования хо- рошо подходит для систем массового обслуживания в традиционном их опи- сании. Обобщенный алгоритм моделирования по принципу особых состоя- ний представлен схемой на рис. 3.1. 10 н Определение времени наступления очередного события Корректировка текущего модельного времени Опр.типа соб Блок реакции 1 Блок реакции К нет Конец модел Да Рис. к Моделирование по принципу ∧ t осуществляется следующим образом: 1) устанавливаются начальные состояния, в т. ч. t = 0 ; 2) модельному времени дается приращение t = t + ∧t ; 3) на основе вектора текущих состояний элементов модели и нового значения времени рассчитываются новые значения этих состояний; за ∧ t может на- ступить одно событие, несколько событий или же может вообще не проис- ходить событий; пересчет состояния всех элементов системы – более тру- доемкая процедура, нежели любой из блоков реакции модели, построенной по принципу особых состояний; 4) если не превышено граничное время моделирования, предыдущие пункты повторяются. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования применима для более широкого круга систем, нежели моделирование по принципу особых событий, однако есть проблемы с определением ∧ t . Если задать его слишком большим - теряется точность, слишком малым - возрас- тает время моделирования. На основе базовых схем моделирования можно строить комбинирован- ные и диалоговые схемы, в которых моделирование идет под контролем опе-

1 od 38

Prezentacija na temu: Modeliranje informacionih sistema

Slajd br. 1

Slajd br. 2

Opis slajda:

Svrha kursa je produbljivanje osnovnih predmeta (informatika, matematika); formiranje kompetencija za profesionalne aktivnosti u oblasti informacionog modeliranja Motivacija studenata pri izboru EK. - ispitivanje sposobnosti i interesovanja učenika za kreativne, istraživačke aktivnosti u oblasti informacionog modeliranja; - priprema za upis na univerzitet za specijalnosti vezane za informaciono modeliranje i računarske tehnologije: primijenjena matematika, modeliranje, računarski sistemi itd.

Slajd br. 3

Opis slajda:

Slajd br. 4

Opis slajda:

Sadržaj udžbenika Poglavlje 1. Modeliranje informacionih sistema 1.1. Informacioni sistemi i sistemologija 1.2. Relacioni model i baze podataka (Pristup) 1.3. Tabela - Alat za informaciono modeliranje 1.4. Aplikacijsko programiranje (VBA elementi za Excel) Poglavlje 2. Računarsko matematičko modeliranje 2.1. Uvod u modeliranje 2.2. Alati za kompjutersko matematičko modeliranje (Excel, MathCad, VBA, Pascal) 2.3. Modeliranje procesa optimalnog planiranja 2.4. Aplikacije za kompjuterske simulacije

Slajd br. 5

Opis slajda:

"Modeliranje i razvoj informacionih sistema" Ciljevi izučavanja sekcije Opšti razvoj i formiranje pogleda na svet učenika. Glavna ideološka komponenta sadržaja ovog dijela predmeta je formiranje sistematskog pristupa analizi okolne stvarnosti. Ovladavanje osnovama metodologije za izgradnju informacionih referentnih sistema. Studenti stječu razumijevanje faza u razvoju informacionog sistema: faza projektovanja i faza implementacije. Kreiranje multitabularne baze podataka odvija se u MS Access relacionom DBMS okruženju. Studenti ovladavaju tehnikama izgradnje baze podataka, aplikacija (upiti, izvještaji), elementi interfejsa (dijaloški okviri). Razvoj i profesionalizacija rada na računaru. Vještine stečene u osnovnom kursu se dalje razvijaju. - rad sa vektorskom grafikom pri izgradnji strukturnih modela sistema - dubinsko proučavanje mogućnosti MS Access DBMS - korišćenje MS Excel-a kao sredstva za rad sa bazom podataka - programiranje u VBA u Excel okruženju za razvoj interfejsa - pri radu za sažetke se preporučuje korištenje internetskih izvora; pripremiti materijal za zaštitu u vidu prezentacije (Power Point)

Slajd br. 6

Opis slajda:

Projektna metoda nastave Prikaz problema: Predmetna oblast: srednja škola Svrha projekta: izrada informacionog sistema "Obrazovni proces" Svrha informacionog sistema: informisanje korisnika: O učeničkom sastavu odeljenja O nastavnom osoblju škole O raspodeli nastavnog opterećenja i vođenja razreda O napretku učenika

Slajd br. 7

Opis slajda:

Slajd br. 8

Opis slajda:

Slajd br. 9

Opis slajda:

Slajd br. 10

Opis slajda:

Slajd br. 11

Opis slajda:

Slajd br. 12

Opis slajda:

Razvoj aplikacija Aplikacije: upiti, izvještaji Zadatak. Potrebno je pribaviti spisak svih djevojčica devetog razreda koje imaju A iz informatike. Koncept podšeme korištenjem hipotetičkog izbora jezika upita PREZIME STUDENTI IME STUDENTA RAZRED STUDENTA RAZRED = '9? sortiraj STUDENTS.PREZIME uzlazno

Slajd br. 13

Opis slajda:

Slajd br. 14

Opis slajda:

Slajd br. 15

Opis slajda:

VBA programiranje Private Sub CommandButton1_Click () "Opis varijabli Dim i, j, n As Integer Dim Flag As Boolean" Oznaka inicijalizacije podataka = False "Određuje broj redova na listi škola n = Opseg (" A3 "). CurrentRegion .Redovi. Broji "Traži na listi broj škole naveden u polju za unos 'TextBox1" Za i = 3 do n + 2 Ako ćelije (i, 1) .Vrijednost = Val (UserForm1.TextBox1.Text) Tada Flag = True Exit For End If Sljedeći fragment programa za obradu događaja "Kliknite na dugme SEARCH"

Slajd br. 16

Opis slajda:

"Kompjutersko matematičko modeliranje" Ciljevi izučavanja sekcije Ovladavanje modeliranjem kao metodom spoznavanja okolne stvarnosti (naučnoistraž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 vrlo slične modele; - demonstrira prednosti i nedostatke kompjuterskog eksperimenta u odnosu na eksperiment u punoj veličini; - pokazuje se da i apstraktni model i kompjuter pružaju mogućnost spoznaje okolnog svijeta, upravljanja njime u interesu čovjeka. Razvoj praktičnih vještina kompjuterskog modeliranja. Daje se opšta metodologija kompjuterskog matematičkog modeliranja. Na primjeru niza modela iz različitih oblasti nauke i prakse implementirane su praktično sve faze modeliranja, od formulacije problema do interpretacije rezultata dobijenih u toku kompjuterskog eksperimenta. Promoviranje profesionalnog usmjeravanja učenika. Razotkrivanje studentskih sklonosti za istraživačku aktivnost, razvoj kreativnog potencijala, orijentaciju na izbor zanimanja vezanog za naučnoistraživački rad. Prevazilaženje predmetne disocijacije, integracija znanja. Predmet ispituje modele iz različitih oblasti nauke koristeći matematiku. Razvoj i profesionalizacija rada na računaru. Ovladavanje softverom opšte i specijalizovane namene, sistemima za programiranje.

Slajd br. 17

Opis slajda:

Slajd br. 18

Opis slajda:

Modeliranje procesa optimalnog planiranja Problem planiranja rada servisa Postavljanje problema Neka autoservis obavlja dvije vrste servisa: TO-1 i TO-2. Automobili se primaju na početku radnog dana i na kraju predaju kupcima. Zbog ograničenog parkinga, dnevno se može servisirati najviše 140 automobila. Radni dan traje 8 sati. Kada bi svi automobili prošli samo TO-1, tada bi kapacitet stanice omogućio servisiranje 200 automobila dnevno, ako bi svi automobili prošli samo TO-2, onda 50. Trošak (za klijenta) TO-2 je duplo veći. visok kao TO-1. U stvarnosti, neki od automobila prolaze TO-1, a neki istog dana prolaze TO-2. Potrebno je izraditi takav dnevni plan usluga kako bi se preduzeću obezbijedili najveći novčani prihodi.

Slajd br. 19

Opis slajda:

Modeliranje procesa optimalnog planiranja Formalizacija i matematički model problema Planirani indikatori x - dnevni plan proizvodnje TO-1; y - dnevni plan proizvodnje za TO-2. Sistem nejednakosti proizilazi iz formulacije problema.Najveći profit će se postići pri maksimalnoj vrijednosti funkcije.Funkcija f(x,y) se naziva funkcija cilja, a sistem nejednakosti sistem ograničenja. Imam problem linearnog programiranja

Slajd br. 20

Opis slajda:

Slajd br. 21

Opis slajda:

Modeliranje procesa optimalnog planiranja Metode rješavanja problema linearnog programiranja Simpleks metoda je univerzalna metoda za rješavanje problema linearnog programiranja Simpleks tabela Osnova St. x1 ¼ xi ¼ xr xr + 1 ¼ xj ¼ xn x1 b1 1 ¼ 0 ¼ 0 a1, r + 1 ¼ a1j ¼ a1n xi bi 0 1 ¼ 0 ai, r + 1 ¼ aij ¼ ain ¼ ¼ ¼ ¼ ¼ ¼ xr br 0 0 ¼ 1 ar, r + 1 ¼ arj ¼ Arn f 0 0 0 ¼ 0 gr + 1 ¼ gj ¼ gn

Slajd br. 22

Opis slajda:

Slajd br. 23

Opis slajda:

Slajd br. 24

Opis slajda:

Slajd br. 25

Opis slajda:

Modeliranje optimalnih procesa planiranja Private Sub CommandButton1_Klik () Dim d (5, 9) Kao varijanta Dim i, j, r, n, k, m kao cijeli broj Dim p, q, t Kao niz Dim a, b kao dvostruko za i = 1 Do 5 Za j = 1 Do 9 d (i, j) = Raspon ("a6: i10"). Ćelije (i, j) .Vrijednost Next j Next in = 7: r = 3 "Analiza optimalnosti struje rješenje 't = "sljedeće" Uradi Dok t = "sljedeće" Simplex metodski program u VBA za Excel (fragment)

Slajd br. 28

Opis slajda:

Slajd br. 29

Opis slajda:

Modeliranje procesa optimalnog planiranja Zadatak planiranja radova na izgradnji puta Prikaz problema Postoje dvije tačke - početna H i konačna K; od prvog do drugog potrebno je izgraditi saobraćajnicu, koja se sastoji od vertikale i segmenata. Cijena izgradnje svake od mogućih dionica je poznata (prikazana na slici). U stvarnosti, put će biti neka isprekidana linija koja povezuje tačke H i K. Potrebno je pronaći takvu liniju koja ima najmanju cijenu. Ovo je zadatak dinamičkog programiranja

Opis slajda:

Slajd br. 33

Opis slajda:

Računarska simulacija Koristi se aparat matematičke statistike Slučajni događaji: - vremenski interval između dvije transakcije - vrijeme usluge transakcije Funkcije distribucije gustine vjerovatnoće slučajnih događaja Ujednačena distribucija Gausova normalna distribucija Poissonova distribucija

Opis slajda:

Planirani ishodi učenja za EC. Studenti treba da znaju: svrhu i sastav informacionih sistema; faze stvaranja kompjuterskog informacionog sistema; osnovni koncepti sistemologije, postojeće varijante modela sistema; šta je model infološke domene; šta je baza podataka (DB); klasifikacija baze podataka; struktura relacione baze podataka (RDB); normalizacija baze podataka; šta je DBMS; kako su veze organizovane u višetabelarnoj bazi podataka; koji su tipovi upita bazi podataka; kakva je struktura naredbe zahtjeva za odabir i sortiranje podataka; kakve mogućnosti za rad sa bazama podataka ima procesor tabela (MS Excel); kako možete kreirati i izvršiti makro u MS Excelu; šta je objektno orijentisana aplikacija; Osnove VBA programiranja; sadržaj pojmova "model", "informacioni model", "računarski matematički model";

Slajd br. 36

Opis slajda:

faze kompjuterskog matematičkog modeliranja, njihov sadržaj; sastav alata za kompjutersko matematičko modeliranje; mogućnosti procesora Excel tabela u implementaciji matematičkog modeliranja; mogućnosti MathCAD sistema u implementaciji kompjuterskih matematičkih modela; specifičnosti kompjuterskog matematičkog modeliranja u ekonomskom planiranju; primjeri smislenih zadataka iz oblasti ekonomskog planiranja, riješeni metodom kompjuterskog modeliranja; prikaz problema riješenih metodom linearnog programiranja; prikaz problema riješenih metodom dinamičkog programiranja; osnovni koncepti teorije vjerovatnoće, neophodni za implementaciju simulacionog modeliranja: slučajna varijabla, zakon raspodjele slučajne varijable, gustina vjerovatnoće distribucije, pouzdanost rezultata statističkog istraživanja; načini dobijanja nizova slučajnih brojeva sa datim zakonom raspodjele; prikaz problema riješenih metodom simulacijskog modeliranja u teoriji čekanja.

Slajd br. 37

Opis slajda:

Studenti treba da budu u stanju da: dizajniraju jednostavan informacioni i referentni sistem; dizajnirati multitabularnu bazu podataka; navigacija kroz MS Access DBMS okruženje; kreirajte strukturu baze podataka i popunite je podacima; napraviti upite za odabir u MS Accessu koristeći dizajner upita; rad sa obrascima; vršiti upite uz prijem konačnih podataka; primati izvještaje; organizovati jednotabelarne baze podataka (liste) u MS Excel-u; birati i sortirati podatke na listama; filter podataka; kreirati pivot tabele; snimajte makroe za MS Excel koristeći snimač makroa; napišite jednostavne obrađivače događaja u VBA. primijeniti shemu kompjuterskog eksperimenta pri rješavanju smislenih problema gdje postoji potreba za kompjuterskim matematičkim modeliranjem; odabrati faktore koji utiču na ponašanje sistema koji se proučava, izvršiti rangiranje ovih faktora;

Slajd br. 38

Opis slajda:

izgraditi modele proučavanih procesa; odabrati softver za proučavanje konstruisanih modela; analizirati dobijene rezultate i istražiti matematički model za različite skupove parametara, uključujući granične ili kritične; koristiti jednostavne optimizacijske ekonomske modele; izgraditi najjednostavnije modele sistema čekanja i interpretirati rezultate. implementirati jednostavne matematičke modele na računaru, kreirajući algoritme i programe na jeziku Visual Basic; koristiti mogućnosti TP Excel-a za obavljanje jednostavnih matematičkih proračuna i ilustriranje rezultata matematičkog modeliranja pomoću grafikona i trakastih dijagrama; koristiti alat "Traži rješenje" TP Excel za rješavanje problema linearnog i nelinearnog programiranja; koristiti MathCAD sistem za obavljanje jednostavnih matematičkih proračuna, grafički ilustrovati rezultate modeliranja; koristiti MathCAD sistem za rješavanje problema linearne i nelinearne optimizacije.

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 izvodljivost raspoloživih sredstava.
U teoriji efikasnosti i informatici, model objekta (sistema, operacije) je materijalni ili idealan (mentalno zamisliv) sistem koji je kreiran i/ili korišten u rješavanju određenog problema kako bi se došlo do novih saznanja o originalnom objektu, adekvatnih za ona je u pogledu proučavanih svojstava i jednostavnija od originala u drugim aspektima.
Klasifikacija glavnih metoda modeliranja (i njihovih odgovarajućih modela) prikazana je na Sl. 3.1.1.
U proučavanju ekonomskih informacionih sistema (EIS) koriste se sve metode modeliranja, međutim, ovaj dio će se fokusirati na semiotičke (znakovne) metode.
Podsjetimo da je semiotika (od grčkog semeion - znak, karakteristika) nauka o općim svojstvima znakovnih sistema, odnosno sistema konkretnih ili apstraktnih objekata (znakova), sa svakim od kojih je povezano određeno značenje. 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 proučava sintaksu znakovnih sistema bez obzira na bilo kakva tumačenja i probleme povezane sa percepcijom znakovnih sistema kao sredstava komunikacije i komunikacije.
Semantika proučava interpretaciju iskaza znakovnog sistema i, sa stanovišta modeliranja objekata, zauzima glavno mjesto u semiotici.
Pragmatika ispituje odnos osobe koja koristi znakovni sistem prema samom znakovnom sistemu, posebno - percepciju smislenih izraza znakovnog sistema.
Od brojnih semiotičkih modela, zbog najveće rasprostranjenosti, posebno u kontekstu informatizacije savremenog društva i uvođenja formalnih metoda u sve sfere ljudskog djelovanja, izdvojićemo one matematičke koji odražavaju realne sisteme korištenjem 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, teoriju 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 primjene metode simulacije
2. Odjeljak III OSNOVE ZA MODELIRANJE SISTEMA MARKETINGA 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 MARKETING SISTEMA U IMITACIONOM MODELIRANJU
6. Koncept modeliranja finansijske sfere marketing sistema

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.

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

Omsk državni institut za usluge

Modeliranje informacionih sistema korišćenjem UML jezika

Metodičko uputstvo za izvođenje seminarskog rada

I.V. Chervenchuk

• Uvod
• 2 . Unified Modeling LanguageUML
• 4. Razvoj modela softverskog sistema putem sredstavaUML
• 5. Pitanja implementacije informacionog sistema
• 6. Teme nastave
• Bibliografska lista

Uvod

Rad se bavi razvojem informacionih sistema korišćenjem objedinjenog jezika za modeliranje 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 su opcije za zadatke za nastavni rad.

Metodička uputstva su namenjena studentima specijalnosti „Primenjena informatika“ i mogu se koristiti u nastavi, pripremi za ispit, kao iu procesu samostalnog rada.

1. Opšti uslovi za izvođenje seminarskog rada

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 pomoću jedinstvenog jezika modeliranja UML sa njegovom naknadnom implementacijom. Kao tipična varijanta zadatka, predlaže se izrada informaciono-referentnog sistema na bazi baze podataka, ali se na zahtev studenta, u dogovoru sa nastavnikom, može izraditi WEB aplikacija, sistem za testiranje ili hardverski uređaj. ponuditi kao zadatak. Istovremeno, glavni preduvjet je korištenje objektno orijentisanog pristupa i konstrukcija UML modela.

Tipičan naziv seminarskog rada izgleda kao "Razvoj informaciono-referentnog sistema _ naslov _ "

Uvod

1. Sadržajni pregled predmetne oblasti. Osnovni sistemski zahtjevi

2. Detaljan model informacionog sistema

2.1 Pogled iz perspektive slučajeva upotrebe

2.2 Prikaz dizajna

2.3 Pogled na implementaciju

2.4 Perspektiva procesa (ako je primjenjivo)

2.5 Pogled sa stanovišta postavljanja (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 delu objašnjenja, sa detaljnim komentarima. , a tekstove programa treba staviti u aplikaciju.

Pogled na proces treba dati kada se dizajniraju multitasking sistemi. 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 varijante nastavnog rada.

Prilikom isticanja problema implementacije sistema u bilješci, preporučljivo je opravdati izbor programskog okruženja, 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 se ukratko sumiraju glavni rezultati rada: razvijen je UML-model sistema, sistem je implementiran korišćenjem takvog i takvog programskog okruženja koje razvijeni sistem dozvoljava, prednosti korišćenih pristupa (zasnovanih na o modeliranju) do projektovanja sistema.

modeliranje jezika informacionog sistema

Nastavni rad treba da sadrži 20-30 stranica štampanog teksta sa ilustracijama. Dijagrami slučajeva upotrebe, klasa, interakcija moraju biti obezbeđeni bez greške.

2. Unified Modeling Language UML

Racionalni razvoj informacionog sistema pretpostavlja duboku preliminarnu analitičku studiju. Prije svega, potrebno je ocrtati opseg zadataka koje obavlja sistem koji se razvija, zatim razviti model sistema i na kraju odrediti metode implementacije. Duboko proučavanje arhitekture informacionog sistema koji se razvija u početnim fazama projektovanja, po pravilu se kasnije isplati, posebno kada se razvijaju veliki projekti uz dugoročnu podršku.

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

UML je objektno orijentisani jezik za vizualizaciju, specificiranje, konstruisanje i dokumentovanje artefakata softverskih sistema.

UML, kao i svaki drugi jezik, sastoji se od vokabulara i pravila koja vam omogućavaju da kombinujete reči uključene u njega 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. Uz to, 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 kojim je moguće opisati sa različitih tačaka gledišta reprezentacije arhitekture sistema tokom njegovog razvojnog ciklusa.

UML je jezik vizualizacije, a UML nije samo kolekcija grafičkih simbola. Svaki od njih ima dobro definisanu semantiku (vidi) Dakle, model koji je napisao jedan programer može se nedvosmisleno interpretirati od strane drugog, ili čak pomoću kompleta alata.

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 preslikati na jezike kao što su Java, C++, Visual Basic, pa čak i tablice relacijske baze podataka ili trajni objektno orijentirani objekti baze podataka. Oni koncepti koji su poželjno preneti grafički su predstavljeni u UML-u; oni koji su bolje opisani u tekstualnom obliku izražavaju se pomoću programskog jezika.

Ovo mapiranje modela u programski jezik omogućava direktan dizajn: generisanje 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 osiguravaju 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 operativnih 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.

U zavisnosti od usvojene razvojne metodologije, neki radovi se izvode formalnije, drugi manje. Dokumenti o kojima se govori nisu samo isporučeni 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 obezbeđuje programeru i menadžmentu sopstveni način rešavanja problema dokumentovanja arhitekture sistema i svih njenih detalja, obezbeđuje jezik za formulisanje sistemskih zahteva i definisanje testova, i konačno obezbeđuje sredstvo za modeliranje rada tokom planiranja projekta i verzije. kontrolna faza.

Razmotrimo razvoj modela informacionog sistema pomoću UML jezika na primeru razvoja automatizovane radne stanice za sekretara odeljenja (u daljem tekstu AWP sekretara odeljenja).

3. Opis predmetne oblasti

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

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

U preliminarnom opisu predmetne oblasti uvode se osnovni pojmovi (rečnik sistema), utvrđuju se tipovi korisnika i njihova prava, formulišu zadaci koje razvijeni sistem mora da reši. U ovom slučaju, opis treba koristiti sredstva uobičajenog jezika i standardne poslovne grafike (slike, dijagrami, tabele).

Prilikom izrade sistemskog rječnika potrebno je definirati nazive entiteta ("učenik", "nastavnik", "disciplina"). U ovom slučaju, pojam suštine shvatamo kao komponentu modela domene, odnosno kao objekat koji je već identifikovan na konceptualnom nivou. Objekte dodijeljene u predmetnoj oblasti analitičar transformira u entitete.

Entitet je rezultat apstrakcije realnog objekta. Postoje dva problema povezana sa objektima: identifikacija i adekvatan opis. Za identifikaciju se koristi ime koje mora biti jedinstveno. U ovom slučaju, pretpostavlja se da postoji odbacivanje njegovog značenja, koje je svojstveno prirodnom jeziku. Koristi se samo indikativna funkcija imena. Ime je direktan način identifikacije objekta. Indirektne metode identifikacije objekta uključuju definiciju objekta kroz njegova svojstva (karakteristike ili znakove).

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 inkluzivni odnos. Dakle, sve informacije o objektima i entitetima domene su opisane pomoću izraza na prirodnom jeziku.

Možete specificirati strukturne veze, 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 napredna sredstva za opisivanje domene, na primjer, sredstva za UML jezik.

Dakle, zadatak je da se razvije sistem „radna stanica sekretara katedre“ koja bi omogućila automatizovano obračunavanje podataka o zaposlenima i studentima odseka IKT OmSTU, pružila fleksibilne mogućnosti za rešavanje planiranih i neplaniranih konkretnih zadataka obrade. vjerodajnice.

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

nastavnici - nastavnici katedre;

studenti- studenti univerziteta ove specijalnosti;

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

diplomirani studenti, imaju posebnost da, s jedne strane, sami mogu izvoditi nastavu, s druge strane, i sami su studenti i imaju naučnog savjetnika;

disciplina- disciplina koja se predaje (predmet, predmet).

Umetnuti entiteti imaju niz atributa, koje ćemo kasnije definirati.

Vodimo dvije vrste korisnika: privatne korisnik(dalje korisnik, i administrator... Pretpostavlja se da korisnik može pristupiti sistemu sa zahtjevom, prikazati izvještaje, administrator dodatno može 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 termine, sistem koji se razvija treba da obezbedi:

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

informatička podrška donošenih rukovodnih odluka, formiranje potpunih i pouzdanih informacija o obrazovnim procesima i rezultatima rada odjela;

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

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

korisničko sučelje;

razlikovanje ovlasti običnih korisnika i administratora.

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

4. Razvoj modela softverskog sistema koristeći UML

UML je jezik za specifikaciju i vizualizaciju, njegove glavne jedinice su dijagrami.

UML dijagram je grafički prikaz skupa šablona, ​​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, na neki način, jedna od projekcija sistema. Tipično, grafikoni pružaju sažeti prikaz elemenata koji čine sistem. Jedan te isti element može biti prisutan na svim dijagramima, ili samo u nekoliko (najčešća varijanta), ili nije prisutan ni na jednom (vrlo rijetko). U teoriji, 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, u UML-u se razlikuje devet tipova dijagrama:

dijagrami klasa

dijagrami objekata;

dijagrami slučajeva upotrebe;

dijagrami sekvence;

dijagrami saradnje;

dijagrami stanja;

dijagrami akcije (aktivnosti);

dijagrami komponenti;

dijagrami raspoređivanja.

UML konceptualni model

Dijagram klasa prikazuje klase, interfejse, objekte i kolaboracije i njihove odnose. Prilikom modeliranja objektno orijentiranih sistema najčešće se koristi ova vrsta dijagrama. Dijagrami klasa predstavljaju statički pogled na dizajn sistema. Dijagrami klasa koji uključuju aktivne klase odgovaraju statičkom pogledu na sistem iz perspektive 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 iz perspektive dizajna ili procesa, ali sa pogledom na stvarnu ili lažnu implementaciju.

Dijagram slučaja upotrebe prikazuje slučajeve upotrebe i aktere (poseban slučaj klasa), kao 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 pri organizaciji i modeliranju ponašanja sistema.

Dijagrami sekvenci i dijagrami 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. U ovom slučaju, dijagrami sekvence odražavaju vremenski poredak poruka, a dijagrami saradnje - strukturnu organizaciju objekata koji razmjenjuju poruke. Ovi dijagrami su izomorfni, odnosno mogu se transformisati jedan u drugi.

Dijagrami dijagrama stanja predstavljaju automat koji uključuje stanja, tranzicije, 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 simulaciju reaktivnih sistema.

Dijagram aktivnosti je poseban slučaj dijagrama stanja; pokazuje 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 između njih. Dijagrami komponenti odnose se na statički pogled na sistem sa stanovišta implementacije. Oni se mogu povezati sa dijagramima klasa, budući da se komponenta obično mapira 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 podsklop obično sadrži jednu ili više komponenti.

Ovdje 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 iz perspektive slučaja upotrebe

Modeliranje počinje definisanjem glavnih ciljeva sistema koji se razvija i radnji koje treba da izvrši. U ove svrhe se koriste dijagrami slučajeva upotrebe. Kao što je ranije objašnjeno, dijagrami slučajeva upotrebe ukazuju na slučajeve upotrebe i aktere 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 određeni Act e ra (glumac). Slučaj upotrebe se koristi za strukturiranje entiteta ponašanja modela. Slučaj upotrebe samo deklarira opis neke radnje sistema, odgovarajući na pitanje "šta učiniti?", ali ne ukazuje na koji način. Konkretnu implementaciju ponašanja specificiranog slučajem upotrebe osigurava klasa, saradnja klasa ili komponenta.

Glumac je koherentan skup uloga koje korisnici koriste u interakciji s njima. Tipično, akter predstavlja ulogu koju osoba, hardverski uređaj ili čak drugi sistem igra 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 slučajeva upotrebe tako da ukazuju na ponašanje, često takvi nazivi sadrže glagole, na primjer, "generirati izvještaj", "pronaći podatke po kriteriju" itd. Moguće je davati nazive za upotrebu padeža uz imenice koje sugeriraju neke radnje, na primjer, "autorizacija", "pretraga", "kontrola".

Vraćajući se na modeliranje automatizovanog radnog mesta sekretara odeljenja, da istaknemo presedane:

Uređivanjepodaci,

Tražistudent,

Tražinastavnik,

Izdavanjelistaučiodiscipline,

Autorizacija.

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

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

Pored toga, definisane su dve specifične zavisnosti između slučajeva upotrebe u UML-u — odnos uključivanja i odnos 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 priloženog slučaja upotrebe. O osnovnom slučaju upotrebe možete razmišljati kao o posuđivanju ponašanja uključivanja. Zbog prisutnosti relacija uključivanja, moguće je izbjeći višestruke opise istog toka događaja, budući da se općenito ponašanje može opisati kao nezavisan slučaj upotrebe uključen u osnovne. Odnos uključivanja je primjer delegiranja, u kojem je određeni broj odgovornosti sistema opisan na jednom mjestu (u uključenom slučaju upotrebe), a ostali slučajevi upotrebe, kada je potrebno, uključuju ove odgovornosti u svoj skup.

Odnosi uključivanja su prikazani kao zavisnosti sa stereotipom "uključiti". 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.

Relacija proširenja se koristi za modeliranje dijelova slučaja upotrebe koje korisnik percipira kao opciono ponašanje sistema. Ovo vam omogućava da odvojite obavezna i opciona ponašanja. 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 simulaciju višestrukih tokova koji se mogu pokrenuti u nekom trenutku u scenariju kao rezultat eksplicitne interakcije s akterom.

Odnos proširenja je prikazan kao zavisnost sa stereotipom "proširiti". Tačke proširenja osnovne skripte navedene su u dodatnom 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 s operativnim dijelom i arhivom. U ovom slučaju, ako se zahtjevu dostavljaju podaci operativnog dijela, vrši se glavni (osnovni) pristup podacima, ako podaci operativnog dijela nisu dovoljni, vrši se pristup arhivskim podacima, tj. , pristup ide prema naprednom scenariju.

U našem slučaju, presedan uređivanjepodaci uključuje slučajeve upotrebe: unospodaci, brisanjepodaci, promjenapodaci.

Dijagram presedana AWP sekretara odjeljenja prikazan je na slici 1.

Rice. 1. Dijagram presedana AWP sekretara odjeljenja

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

Prilikom dizajniranja pogleda u smislu slučajeva upotrebe, često je potrebno dati prošireni opis slučaja upotrebe (samo je naziv dat u skraćenoj verziji). Obično je tok događaja u slučaju upotrebe opisan u tekstualnom obliku na početku. Kako precizirate svoje sistemske zahtjeve, bit će zgodnije prijeći na grafički prikaz tokova u dijagramima aktivnosti i interakcije.

Tokovi događaja mogu se opisati pomoću nestrukturiranog teksta, strukturiranog teksta (koji sadrži uslužne riječi: IF,PRIJETHOSEPORWHILE itd.), specijalizovani formalni jezik (pseudokod).

Kada opisujete slučaj upotrebe kao 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 njegovu prijavu i lozinku. Korisnik ga može unijeti sa tastature. Unos se završava pritiskom na taster. Enter. Nakon toga, sistem provjerava unesene Login i lozinku, te ako odgovaraju administratoru potvrđuje ovlaštenje administratora. Ovim se završava presedan.

Izuzetno protok događaji. Klijent može u svakom trenutku prekinuti transakciju pritiskom na tipku Otkaži. Ova akcija ponovo pokreće presedan. Nema ulaska u sistem.

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

Izuzetno protok događaji. Ukoliko je klijent unio Login i lozinku koji ne odgovaraju administratoru, nudi mu se da ponovo uđe ili se prijavi na sistem kao običan korisnik.

Očigledno, opis slučaja upotrebe nizom događaja pretpostavlja neku vrstu algoritma koji se može predstaviti u dijagramu aktivnosti (slika 2).

Dijagram algoritma mora sadržavati početni i krajnji vrh, sa samo jednim početkom i jednim krajem. Dijagram sadrži izvršne vrhove - aktivnosti (označene zaobljenim pravokutnicima), uslovne vrhove (odluka - odabir, prepoznavanje, označene rombovima) i veze.

Slični dijagrami mogu objasniti izvršenje drugih slučajeva upotrebe, na taj način dopunjujući pogled na sistem sa stanovišta slučajeva upotrebe.

Rice. 2. Autorizacija korisnika. Dijagram aktivnosti.

4.2 Razvijanje pogleda dizajna

Pogled dizajna je glavna faza u konceptualnoj studiji modela. U ovoj fazi uvode se osnovne apstrakcije, definišu klase i interfejsi preko kojih se realizuje rešavanje zadataka. Ako slučajevi upotrebe 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 slučajevi korišćenja 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, saradnje, kao i veze 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 je potrebno 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 odsjek, bilo bi bolje precizirati menadžerStolice neka bude atribut klase stolica koji označava klasu nastavnici ( asocijacija jedan na jedan ), umjesto uvođenja posebne klase menadžerStolice.

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 definirana apstrakcija nekog koncepta iz rječnika problematičnog područja ili područja rješenja;

sadrži mali, dobro definisan skup odgovornosti i izvršava svaku od njih;

održava jasno razdvajanje između specifikacija apstrakcije i njene implementacije;

razumljivo i jednostavno, ali istovremeno omogućava proširenje i prilagođavanje novim zadacima.

U okviru izrade modela automatizovanog radnog mesta sekretara departmana definisaćemo časove: nastavnici, studenti, diplomirani studenti, discipline, grupa... Očigledno, prvi od njih ima mnogo zajedničkih atributa, pa hajde da uvedemo apstraktnu klasu NSEerson, koji će obuhvatiti sva svojstva vezana za ljude u kontekstu sistema koji se razvija (prezime, ime, adresa, itd.). U ovom slučaju osobaće biti superklasa i komunicirati generičkim 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). Imajte na umu da atribut adresa klasa osoba je instanca klase T_ ADR, odnosno uspostavlja se odnos zavisnosti između ovih klasa (prikazano isprekidanom strelicom sa otvorenim vrhom, strelica je usmerena 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 postavljen pomoću primitivnog tipa T_ POSTIDX, definisan kao šesterocifreni decimalni broj. Primitivni tipovi su stereotipni" tip" , raspon vrijednosti je specificiran kroz ograničenja zatvorena u vitičaste zagrade.

U razredu nastavnik hajde da istaknemo specifične atribute koji se odnose samo na nastavnika: pozicija, uch. stepen(fakultetska diploma), uch. rang ( akademsko zvanje), pražnjenje(kategorija jedinstvene tarifne skale). Atributi uch. stepen i uch. rang bolje je definirati specijalizovane tipove putem nabrajanja. Nabrajanja su modelirana od strane klase sa stereotipom " enum" (enumeracija - nabrajanje), dozvoljene vrijednosti se pišu kao atributi, oznake koje određuju vidljivost atributa su potisnute. U ovom primjeru kroz nabrajanje uvodimo specijalizirane klase T_Mora, T_UCHST, T_UchZv, odnosno definisanje mogućih pozicija, akademskih stepena, akademskih titula kroz premeštaj. 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 uvodi se specifičan atribut sobaknjige rekorda... Specifični atributi su definisani za postdiplomsku klasu obrazacučenje i datumpriznanice... Oblik studiranja će odrediti poseban razred putem nabrajanja T_FormObuch(puno radno vrijeme, nepuno radno vrijeme).

Klasa grupa ima atribute: naslov, obrazac učenje, brojstud. ( broj studenata ). S obzirom da nastavnici predmetnog odsjeka mogu predavati grupe sa drugih fakulteta, uvodi se dopunska nastava specijalnost, sa atributima soba(specijaliteti), naslov(specijaliteti ), fakultetčiji tipovi nisu specificirani u ovom modelu, iako se mogu odrediti putem nabrajanja.

Klasa disciplina ima atribute: soba, naslov, ciklus. Atribut ciklus pomoću specijalizovanog tipa koji se uvodi kroz nabrajanje T_Cycles utvrđ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, više ih ne možete naznačiti u razredu specijalnost... Ovi atributi se odnose na par specijalnost-disciplina i definisani su u klasi – asocijaciji Discipline-specijalnosti.

Rice. 3. Dijagram razreda AWP sekretara odjeljenja (opcija 1)

Kada prikazujete strukturu klase, obratite pažnju na vidljivost atributa. Svi razmatrani atributi moraju biti dostupni i javno vidljivi (označeni 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 dijagram bio lakši za čitanje, poželjno potisnuti operacije.

Na uvedenom skupu klasa potrebno je redefinirati veze. Veze generalizacije i zavisnosti su već određene, ostaje da se definišu asocijacije.

Studenti formirana u grupa, u ovom slučaju asocijacija će imati oblik agregacije. Agregacija pretpostavlja odnos dio-cjelina, označen punom linijom s rombom na kraju sa cijele strane (u našem slučaju grupa). Mnoštvo odnosa više-na-jedan student-grupa. Svaki grupa odnosi se na određeno specijaliteti, zauzvrat, nekoliko grupa može odgovarati određenoj specijalnosti, stoga udruženje grupno-specijalitet također ima tip višestrukosti "mnogo prema jednom".

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 kao "mnogo-prema-više": nastavnik može predavati nekoliko disciplina, neke discipline može predavati nekoliko nastavnika. Između discipline i specijaliteti osniva se i udruženje „mnogo-na-mnogi“: nastavni plan i program specijalnosti sadrži mnoge discipline, 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 u grupama i nastavnici: Nastavnici podučavaju u grupama, tip udruženja više prema više. Direktna povezanost između u grupama i disciplins ne morate definirati, jer se ovaj odnos prati kroz klasu povezivača specijalnost.

Da bi se prikazalo prisustvo supervizora za diplomiranog studenta, potrebno je uvesti asocijaciju između postdiplomca i nastavnika tipa „više-na-jedan“, jedan supervizor može imati više diplomiranih studenata. Na ovoj asocijaciji od strane nastavnika možete eksplicitno naznačiti ulogu: supervizor.

Rice. 4. Šema časova AWP sekretara odeljenja (opcija 2)

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

Studenti postdiplomskih studija također može podučavati određene discipline određenim grupama: asocijacijama mnogo prema mnogo postdiplomske grupe, postdiplomske discipline. Neki diplomirani studenti možda neće predavati, 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že se uvesti dodatni apstraktni čas, npr. podučavanje koji je potomak klase osoba i superklasa za klase nastavnik i diplomirani student, što će neznatno smanjiti broj priključaka. (sl. 4.). U ovom slučaju, iz časova disciplina i grupa udruženja će ići na časove podučavanje, pretpostavljajući vezu sa klasama nastavnik i diplomirani student putem nasljeđivanja (generalizacijski odnos). U razred podučavanje možete izvaditi atribute bid(0,5 stopa, puna stopa) 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 tek treba definirati. Da bismo rasteretili dijagram klasa, konstruisaćemo novi pogled na njega (na posebnom dijagramu), ostavljajući sliku glavnih klasa i potiskivajući prikaz pomoćnih koji određuju tipove atributa (slika 5).

Na sl. 5, pored glavnih klasa koje odgovaraju konceptualnim elementima sistema, prikazana je i klasa T_ ADR, otkrivajući strukturu adrese, ova klasa je takođe važna, jer sadrži potrebne elemente podataka za nastavnici i diplomirani studenti- potomci klase osoba.

Idemo dalje 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; samo definiše specifikacije operacija (potpise), ali nikada njihovu implementaciju. Grafički interfejs je prikazan u obliku kruga, ispod kojeg je napisano njegovo ime. Interfejs retko postoji samostalno — obično je vezan za implementacionu klasu ili komponentu. Interfejs uvijek pretpostavlja postojanje neke vrste "ugovora" između strane koja deklarira izvršenje određenog broja operacija i strane koja te operacije implementira.

Stavite klasu na dijagram elektronskisto, koji obuhvata sva svojstva i operacije proračunske tablice koja vam omogućava da uređujete podatke. Nećemo otkrivati ​​strukturu ove klase 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 TTable klasu koja obuhvata mogućnosti proračunske tablice. Potomci klase elektronskisto su specifične tabele koje sadrže specifične podatke za fakultet, postdiplomske studente, studente, grupe, discipline i specijalnosti. Pravljenjem 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). U ovom slučaju se pretpostavlja da u klasi elektronskisto ove mogućnosti su implementirane.

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

Hajde da definišemo interfejse Tražinastavnik, Tražidiscipline pridružujući ih njihovim odgovarajućim klasama sa odnosom implementacije. Nećemo otkrivati ​​sastav operacija ovih interfejsa (prilično je trivijalan), stoga ćemo interfejse prikazati u skraćenom obliku (u obliku kruga). Podsjetimo da se implementacijski odnos pridružen interfejsu u skraćenom obliku prikazuje kao jednostavna puna linija (kao asocijacija).

Interfejs Tražistudentće biti prikazan sa indikacijom liste operacija kroz stereotipnu klasu, dok je relacija implementacije prikazana isprekidanom strelicom 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. Radi lakše percepcije, ovi mehanizmi nisu vizualizirani.

Za upravljanje pravima pristupa i autorizacijom korisnika uvodimo klasu menadžerpristup... Upravitelj pristupa ima atribut privatnog tipa pristupa stolozinke koja je instanca klase CodirTable(Kodirana tabela) koja sadrži lozinke ( lozinka) i imena unosa ( Ulogovati se) administratorskih korisnika. Pretpostavlja se da je klasa usluga sposobnosti CodirTable ne dozvolite neovlaštenom korisniku da čita 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 dodjeljivanje administratorskih prava, pomoću kojih se ostvaruje autorizacija i upravljanje pravima pristupa.

Hajde da ukažemo na 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šni dijagram časova APZ sekretara odjeljenja

Konačni dijagram je prikazan na sl. 6.

Dakle, u ovoj fazi, razvoj objektno orijentisanog modela radne stanice sekretara odjela pomoću UML dijagrama klasa može se smatrati završenim. Naravno, moguće je vratiti se na njega i revidirati neke elemente tokom projektovanja sistema, prilikom prilagođavanja zadataka, prilikom specificiranja 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 javnoj operaciji klase, ili skupu javnih operacija (u ovom slučaju, slučaj upotrebe se implementira direktno od strane odgovarajuće klase ili skupa klasa).

Pogledajmo proces kreiranja novog zapisa učenika koristeći dijagram sekvence.

Kreiranje novog zapisa pretpostavlja administratorska prava, tako da će administrator biti protagonista ove interakcije ( admin). Ovaj element je već unesen u dijagram slučaja upotrebe, pa ga prevucite na dijagram sekvence iz pretraživača prikaza slučaja upotrebe.

Treba napomenuti da se objekti pojavljuju u dijagramima interakcije, odnosno konkretnim instancama klasa (ime objekta je uvijek podvučeno).

Upravljamo objektima: obrazacunos, 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, koji je tipična forma za unos podataka o učeniku (prezime, ime, patronim, adresa i sl.). U našem slučaju, radi se o nešto proširenoj konkretnoj implementaciji 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 obrazacunos 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 je naznačena klasa čija je instanca - studenti.

Petrov- poseban zapis o učeniku Petrovu, novi element tabele o studentima. Ovdje eksplicitno ukazujemo na uvedenu klasu snimanjeOstudent... Takvi objekti obično postoje privremeno da šalju relevantne informacije bazi 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 završene 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 sekvence za unos novog zapisa o studentu u AWS sekretara odjeljenja prikazan je na sl. 7.

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

U dijagramu sekvence definiramo prijenos poruka između objekata: stvoritinovosnimanje(emituje se od objekta do objekta do kraja lanca kao poruka spasitisnimanje); otvorenoblik(u obrazac za unos); uvestiF.I O.,adresa. ( unos podataka učenika), onda se ti podaci emituju porukama spasitiF.I O.,adresa. Od menadžertransakcije poslati poruku prikupiti informacijeOstudent pružanje povratne informacije bazi podataka i konačno refleksivnu poruku menadžertransakcije imenovan kao spasitisnimanjevDB, 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 slučajeva upotrebe.

4.3 Razvijanje profila relacijske baze podataka

U slučaju da se za implementaciju sistema koristi objektno orijentisani DBMS (OODBMS), objektni dijagram konstruisan 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 projekat baze podataka je UML ekstenzija koja održava UML metamodel netaknutim. Profil za projekt baze podataka dodaje stereotipe i označene vrijednosti pridružene ovim stereotipima, ali ne mijenja osnovni UML metamodel. Za vizualizaciju dizajniranih elemenata baze podataka i pravila dizajna za relacijske baze podataka, odgovarajuće ikone su dodate profilu (u daljem tekstu jednostavno baze podataka). Baza podataka je opisana pomoću tabela, kolona i relacija. Profil sadrži 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 koristiti sve ove elemente u modelu. Na UML profilu 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č) - 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.

Performanse ( View) je virtuelna tabela koja se ponaša iz korisničke tačke gledišta potpuno kao obična tabela, ali ne postoji sama za sebe.

Pohranjeno procedura ( Pohranjena procedura) je nezavisna proceduralna funkcija koja se izvršava 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 obrazovno-metodičkog informacionog sistema.

seminarski rad, dodan 28.05.2009


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

prezentacija dodata 14.10.2013


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

prezentacija dodata 04.02.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 kreiranje i održavanje informacionih sistema (IS). Osobine IDEF-tehnologije razvoja IS-a. Opis IDEF0 notacije. Razvoj funkcionalnih modela poslovnog procesa.

prezentacija dodata 04.07.2013


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

teze, dodato 17.02.2015


Razvoj informacionih sistema. Savremeno tržište finansijskog i ekonomskog primijenjenog softvera. Prednosti i nedostaci implementacije 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 oblika grafičkog interfejsa i baza podataka.

disertacije, dodato 23.06.2015


Rješenje za sigurnost informacija. Sistemi za data centre. Šta je hardver data centra? Osnovni koncepti i principi modeliranja. Izbor metode za rješavanje problema. Zoitendijkova metoda dopuštenih pravaca, Frank – Wolfe 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.

U idejnom rješenju IS-a koristi se niz opisa specifikacija (zahtjeva, uvjeta, ograničenja, itd.), među kojima centralno mjesto zauzimaju modeli transformacije, skladištenja i prijenosa informacija. Modeli dobijeni proučavanjem predmetne oblasti menjaju se tokom razvoja IS i postaju modeli projektovanog IS.

Razlikovati funkcionalne, informativne, bihevioralne i strukturalne modele. Funkcionalni model sistema opisuje skup funkcija koje sistem obavlja. Informacijski modeli odražavaju strukture podataka – njihov sastav i odnose. Modeli ponašanja opisuju informacijske procese (dinamiku funkcionisanja), uključuju kategorije kao što su stanje sistema, događaj, prijelaz iz jednog stanja u drugo, uvjeti tranzicije, slijed događaja. Strukturni modeli karakterišu morfologiju sistema (njegovu konstrukciju) - sastav podsistema, njihove međusobne veze.

Postoji nekoliko načina za izgradnju i predstavljanje modela, koji su različiti za različite tipove modela. Osnova je strukturna analiza – metoda proučavanja sistema, koja počinje sa njegovim opštim pregledom, a zatim prelazi u detalje, formirajući hijerarhijsku strukturu sa sve većim brojem nivoa.

U ovom tutorijalu ćemo razmotriti metodologiju za konstruisanje strukturno-funkcionalnih i informacionih modela IP-a i projektovanje relacione baze podataka na osnovu njih, ilustrujući ovaj proces konkretnim edukativnim primerom sledećeg sadržaja.

U vezi sa diverzifikacijom aktivnosti, od rukovodstva Bezenčuka i pratilaca je primljen nalog za razvoj informacionog sistema u cilju poboljšanja efikasnosti upravljanja.

Preduzeće se bavi proizvodnjom i prodajom nameštaja. Postoji katalog tipičnog namještaja koji proizvodi kompanija. Kupac može odabrati namještaj iz kataloga i/ili naručiti prema vlastitom opisu. Nakon formiranja narudžbe sastavlja se ugovor. Kompanija preuzima stari namještaj od novih kupaca namještaja, čija se cijena odbija od cijene narudžbe. Prihvaćeni stari namještaj se prodaje ili se može iznajmiti. Nakon određenog vremena, stari namještaj koji nije tražen se predaje u skladište na drva. Čuva se arhiva sa podacima o izvršenim narudžbama. Klijenti koji su ranije sklopili ugovore sa kompanijom ostvaruju popust pri sklapanju novog ugovora. Kompanija nabavlja materijale i komponente neophodne za proizvodnju namještaja od dobavljača.

Funkcionalno IC modeliranje

Postoji nekoliko različitih tehnika i alata za razvoj strukturnih i funkcionalnih modela IP. Jedna od najčešće korišćenih je metoda zasnovana na konstrukciji dijagrama toka podataka (DFD - Data Flow Diagrams)

Dijagram toka podataka

DFD je metoda strukturalne analize koja koristi koncepte „tok podataka“ i „proces“ da opiše sistem kao skup funkcionalnih komponenti (procesa) povezanih tokovima podataka. U skladu sa osnovnim principom strukturne analize, opis sistema se zasniva na sekvencijalnim detaljima njegovih funkcija, koje se prikazuju u obliku hijerarhijski organizovanog skupa grafičkih slika (dijagrama).

Glavni elementi dijagrama toka podataka su: eksterni entiteti; procesi; Uređaji za pohranu podataka; tokovi podataka. Svaki takav element ima standardni grafički prikaz.

Eksterni entitet je objekt koji je izvor ili primatelj informacija, na primjer, kupci, osoblje, dobavljači, kupci, skladište. Definicija nekog objekta ili sistema kao eksternog entiteta ukazuje na to da je izvan granica projektovanog IS-a.

Eksterni entiteti u gornjem primjeru će predstavljati kupce namještaja, dobavljače materijala, skladište i neke druge objekte u predmetnoj oblasti. Primjeri njihovih grafičkih slika:

Funkcije projektovanog IS-a u DFD modelu treba da budu predstavljene u obliku procesa koji transformišu ulazne tokove podataka u izlazne podatke u skladu sa određenim algoritmima. Sami tokovi podataka su mehanizam koji simulira prijenos informacija od izvora do prijemnika (od jednog dijela sistema u drugi). Tok podataka na dijagramu je predstavljen linijom koja se završava strelicom koja pokazuje smjer toka. Svaki tok podataka treba imati ime koje odražava njegov sadržaj.

Na primjer, IS funkcija dizajnirana da formira narudžbu namještaja i zaključi ugovor za njegovu proizvodnju može se na dijagramu prikazati procesom "naručivanje namještaja". Ovaj proces, kao ulazni podatak, treba da dobije informaciju o kupcu, koja je neophodna za sklapanje ugovora i podatke o nameštaju koji je naručio (vrsta, opis, dimenzije itd.). Grafički prikaz ovog procesa i odgovarajućih tokova podataka:

Uređaj za pohranu podataka (skladištenje) je apstraktni uređaj za pohranjivanje informacija koji se u bilo kojem trenutku može staviti u uređaj za pohranu i preuzeti za dalju upotrebu. Informacije na pogon mogu doći od vanjskih entiteta i procesa, oni također mogu biti potrošači informacija pohranjenih u pogonu. grafika pogona:

Dijagram konteksta

Dijagram gornjeg nivoa hijerarhije koji fiksira glavne procese ili podsisteme IS-a i njihov odnos sa eksternim entitetima (ulazima i izlazima sistema) naziva se kontekst dijagram. Tipično, pri projektovanju relativno jednostavnih IC-a, gradi se jedinstven dijagram konteksta sa topologijom zvijezde, u čijem središtu je glavni proces povezan sa ponorima i izvorima informacija (korisnicima i drugim vanjskim sistemima). Iako se kontekstni dijagram može činiti trivijalnim, njegova nesumnjiva korisnost leži u činjenici da postavlja granice analiziranog sistema i definiše glavnu svrhu sistema. Ovo postavlja kontekst u kojem postoje dijagrami nižeg nivoa sa njihovim procesima, tokovima i akumulatorima.

Kontekst dijagram za gornji primjer prikazan je na slici 4.

Treba napomenuti da je u obrazovne svrhe u nastavku razmatrana pojednostavljena verzija modela sistema u kojoj neće biti prikazani tokovi podataka i procesi koji se odnose na finansijsku stranu aktivnosti kompanije. Iako je, naravno, za svaku kompaniju od vitalnog značaja pravovremena, potpuna i pouzdana informacija o njenom finansijskom stanju. U ovom primjeru, "finansijska komponenta" je očigledno prisutna u interakciji kompanije sa svim eksternim entitetima predstavljenim u kontekstualnom dijagramu.

Eksterni entiteti predstavljeni u ovom dijagramu djeluju kao izvori informacija koje se pohranjuju i obrađuju u IS-u kompanije i kao potrošači ovih informacija. U ovom modelu izdvajaju se dva entiteta „klijent“ koji su slike stvarnih klijenata firme: „kupac“ i „kupac“, budući da postoje značajne razlike u sadržaju informacija koje razmenjuju sa IS-om.

Za "kupac-kupac" tok podataka "katalog" je opis tipičnog namještaja koji proizvodi kompanija. Tok podataka "narudžbe" može uključivati ​​informacije o naručivanju namještaja odabranog iz kataloga i/ili opis namještaja koji nije u katalogu od strane kupca, a moguće i informacije o starom namještaju koji je kupac prodao firmi.

Za “kupac-kupac”, tok podataka “katalog starog namještaja” je informacija o dostupnom starom namještaju primljenom od kupaca. Stream "kupovina/iznajmljivanje starog namještaja" je informacija o starom namještaju po izboru klijenta, koji želi kupiti ili iznajmiti.

Istovremeno, u praksi su moguće situacije kada će "kupac-kupac" i "kupac-kupac" biti jedna te ista osoba.