MINISTARSTVO OBRAZOVANJA RUSKE FEDERACIJE ULJANOVSKO DRŽAVNO TEHNIČKO SVEUČILIŠTE ono sveučilišta Shcheklein V.S. Ŝ Modeliranje informacijskih sustava: bilješke s predavanja / V.S. SCHEKLEIN. - Uljanovsk: UlGTU, 2002. - str. Bilješke s predavanja su izbor materijala korištenog u školskoj 1999./2000. godini pri izvođenju nastave iz discipline "Modeliranje informacijskih sustava". Namijenjeno studentima smjerova: 130107 “Programska obrada konstrukcijskih materijala” i 130111 “Projektno upravljanje zrakoplovnom proizvodnjom”. Ovaj priručnik nije potpun, planira se uključiti novi razvijeni materijal, čiji se odabir i dizajn vrši u skladu s odobrenim programom discipline. 3 SADRŽAJ UVOD …………………………………………………………………………………… 4 1. OSNOVNI POJMOVI TEORIJE MODELIRANJA ………... 4 NJENA IMPLEMENTACIJA UZ POMOĆ RAČUNALO …………… 7 3. GENERALIZIRANI ALGORITMI STATISTIČKOG MODELIRANJA ……………………………………………………………………… 9 4. SIMULACIJA SLUČAJNIH VARIJABLI S A DATI ZAKON DISTRIBUCIJE. SIMULACIJA SLUČAJNIH DOGAĐAJA …………………………………………………………………….. 5. PRISTUP SIMULACIJI SUSTAVA ……………………………………………………… ………………………………………………………………………………………………………………………………………………….. 15 6. POSTAVLJANJE NASLUČAJNIH VRIJEDNOSTI I SLUČAJNIH DOGAĐAJA U EXCELU ………………………………………………………… 21 7. MODELIRANJE MARKOVSKIH LANCA ……………………. 23 8. MODELIRANJE SUSTAVA REDOVANJA. 25 9. STRUKTURA INFORMACIJSKIH I RAČUNALNIH SUSTAVA……………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………… 26 9.1. Koncept procesa …………………………………………………………………….. 28 9.2. Opterećenje posla …………………………………………………………………… 29 10. POKAZATELJI UČINKA INFORMACIJSKIH SUSTAVA ……………………………………………………… ………….. 30 11. OCJENA PERFORMANSE KOMPONENTI SUSTAVA ……………………………………………………………………….….…. 31 12. OCJENA OPĆINE PERFORMANSE SUSTAVA ……. 32 13. UTJECAJ NAČINA OBRADE PODATAKA …………………….. 35 14. KARAKTERISTIKE POUZDANOSTI ……………………………… 36 15. KONSTRUKCIJA MATEMATIČKOG MODELA INFORMACIJSKOG SUSTAVA …… ………………………………………………………. 40 LITERATURA ………………………………………………. 46 4 UVOD Nedvojbena je korisnost matematičkog modeliranja za rješavanje praktičnih problema. Može se postaviti pitanje zašto je potrebno ovladati modeliranjem informacijskih sustava (a sada se ti sustavi ne mogu zamisliti bez računalne tehnologije) za proizvođače zrakoplova usmjerenih na tehnologiju proizvodnje zrakoplova? Moderna tehnologija postaje sve više automatizirana. Suvremeni graditelj zrakoplova, bilo da je dizajner ili tehnolog, u svom radu mora koristiti računala. Postoji opasnost od neadekvatne procjene sposobnosti računala pri rješavanju inženjerskih problema. To može dovesti ili do odbijanja automatizacije jednog ili drugog fragmenta tehnološkog procesa, ili do neopravdanih troškova računalne opreme, čije su mogućnosti uvelike precijenjene u odnosu na potrebne. U tom slučaju takozvani zdrav razum može dovesti do ozbiljnih pogrešaka u procjeni. Svrha discipline je opremiti mladog stručnjaka aparatom za ocjenjivanje informacijskih i računalnih sustava kako bi mogao kompetentno uklopiti alate za automatizaciju u konture proizvodnje ili upravljanja. Osim toga, modeliranjem određenih sustava studenti stječu neizravno iskustvo u optimizaciji sustava i učvršćuju vještine korištenja računala u rješavanju stručnih problema. 1. TEMELJNI POJMOVI TEORIJE MODELIRANJA Modeliranje je zamjena jednog objekta drugim kako bi se uz pomoć objekta - modela dobila informacija o najvažnijim svojstvima predmeta - originala. Model (franc. modele od lat. modulas - mjera, uzorak): 1) uzorak za masovnu proizvodnju proizvoda; marka proizvoda; 2) proizvod s kojeg je uklonjen obrazac (šabloni, uzorci, trgovi); 3) osobu ili predmet koji je umjetnik prikazao; 4) naprava koja reproducira strukturu ili djelovanje nekog drugog uređaja; 5) bilo koju sliku predmeta, procesa ili pojave koja se koristi kao predstavnik originala (slika, dijagram, crtež, karta); 6) matematički aparat koji opisuje predmet, proces ili pojavu; 7) naprava za dobivanje otiska u kalupu. U nastavku, osim ako nije drugačije navedeno, model će se shvaćati kao matematički aparat. Sve modele karakterizira prisutnost neke strukture (statičke ili dinamičke, materijalne ili idealne), koja je slična strukturi objekta – izvornika. U procesu rada model djeluje kao relativno neovisan kvazi-objekt, što omogućuje stjecanje određenog znanja o samom objektu tijekom proučavanja. Ako su rezultati takvog istraživanja (modeliranja) potvrđeni i mogu poslužiti kao osnova za predviđanje u objektima koji se proučavaju, onda se kaže da je model adekvatan objektu. U ovom slučaju adekvatnost modela ovisi o svrsi modeliranja i prihvaćenim kriterijima. Proces modeliranja pretpostavlja prisutnost: - predmeta proučavanja; - istraživač s određenim zadatkom; - model stvoren za dobivanje informacija o objektu potrebne za rješavanje problema. U odnosu na model, istraživač je eksperimentator. Treba imati na umu da svaki eksperiment može biti od značajne važnosti u određenom području znanosti i tehnologije samo ako se njegovi rezultati posebno obrađuju. Jedan od najvažnijih aspekata modeliranja sustava je problem cilja. Svaki model se gradi ovisno o cilju koji mu istraživač postavlja, pa je jedan od glavnih problema u modeliranju problem namjene. Sličnost procesa koji se odvija u modelu sa stvarnim procesom nije sama sebi svrha, već uvjet za ispravno funkcioniranje modela. Kao cilj treba postaviti zadatak proučavanja bilo kojeg aspekta funkcioniranja objekta. Ako su ciljevi modeliranja jasni, onda se javlja sljedeći problem, problem izgradnje modela. Ova konstrukcija je moguća ako postoje informacije ili se iznesu hipoteze o strukturi, algoritmima i parametrima objekta koji se proučava. Treba istaknuti ulogu istraživača u procesu izgradnje modela, koji je kreativan, zasnovan na znanju, iskustvu i heuristici. Formalne metode koje omogućuju dovoljno točan opis sustava ili procesa su nepotpune ili jednostavno odsutne. Stoga se izbor ove ili one analogije u potpunosti temelji na postojećem iskustvu istraživača, a pogreške istraživača mogu dovesti do pogrešnih rezultata modeliranja. Kada je model izgrađen, sljedećim se problemom može smatrati problem rada s njim, implementacija modela. Ovdje su glavni zadaci minimiziranje vremena za dobivanje konačnih rezultata i osiguranje njihove pouzdanosti. Za ispravno konstruiran model karakteristično je da otkriva samo one zakonitosti koje su istraživaču potrebne, a ne razmatra svojstva sustava – originala, koja u ovom trenutku nisu bitna. Klasifikacija tipova modeliranja sustava prikazana je na sl. 1.1. Matematičko modeliranje je izgradnja i korištenje matematičkih modela za proučavanje ponašanja sustava (objekata) u različitim uvjetima, za dobivanje (izračunavanje) određenih karakteristika originala bez mjerenja ili s malim brojem njih. U okviru matematičkog modeliranja razvila su se dva pristupa: - analitički; - imitacija. 6 Sustavi modeliranja Deterministički Stohastički Statički Dinamički Diskretni Diskretni Kontinuirani Kontinuirani Apstraktni Materijal Vizualni Simbolični Matematički Prirodni Fizički Analitički Kombinirano. Simulacija Sl. 1.1. Analitički pristup temelji se na konstrukciji ovisnosti formula koje povezuju parametre i elemente sustava. Takav je pristup dugo vremena bio ispravan matematički pristup. Međutim, kada se razmatraju složeni sustavi, stroge matematičke ovisnosti su vrlo složene, a za dobivanje traženih vrijednosti parametara potreban je veliki broj mjerenja. Analiza karakteristika procesa funkcioniranja složenih sustava primjenom samo analitičkih metoda istraživanja nailazi na značajne poteškoće, što dovodi do potrebe značajnog pojednostavljenja modela bilo u fazi njihove izgradnje ili u procesu rada s modelom, što smanjuje pouzdanost rezultata. Simulacijski (statistički) pristup u modeliranju temelji se na korištenju Čebiševljevog graničnog teorema u probabilističkom prikazu parametara sustava. Na temelju preliminarnog proučavanja sustava koji se modelira, vrlo jednostavno se određuju vrste i vrijednosti zakona raspodjele slučajnih varijabli parametara. U sklopu simulacijskog pristupa koriste se analitičke ovisnosti između parametara elemenata sustava, međutim, te su ovisnosti generaliziranije, pojednostavljene. One su puno jednostavnije od ovisnosti u okviru analitičkog pristupa. 7 Matematičko modeliranje sustava, uključujući informacijske sustave, usmjereno je na optimizaciju strukture sustava, odabir najoptimalnijih načina funkcioniranja sustava, određivanje potrebnih karakteristika hardvera i softvera. Matematičko modeliranje tehnoloških procesa, uključujući i informacijske, ima za glavne ciljeve pronalaženje optimalnih ili prihvatljivih karakteristika samog objekta, pronalaženje optimalnih načina obrade, osposobljavanje osoblja i osiguravanje određenih upravljačkih funkcija. U svakom slučaju, modeliranje treba ispunjavati sljedeće zahtjeve: - modeli trebaju biti primjereni odgovarajućim sustavima ili tehnološkim zadacima; - mora se osigurati potrebna točnost; - treba osigurati pogodnost korisnika - stručnjaka za tehnologiju ili obradu informacija (upravljanje): - razumljivo sučelje za upravljanje simulacijom; - dovoljna brzina rada; - vidljivost rezultata; - prihvatljivi trošak razvoja i korištenja alata za modeliranje. 2. BIT METODE STATISTIČKOG ISPITIVANJA I NJENA IMPLEMENTACIJA UZ POMOĆ RAČUNALA Metoda statističkog modeliranja sastoji se u reprodukciji proučavanog procesa pomoću vjerojatnosnog matematičkog modela i izračunavanju karakteristika tog procesa. Metoda se temelji na ponovljenom testiranju izgrađenog modela uz naknadnu statističku obradu dobivenih podataka kako bi se odredile karakteristike procesa koji se razmatra u obliku statističkih procjena njegovih parametara. Razmotrimo jednadžbu: y = f (x, t, ξ) , (2.1) gdje je y parametar sustava koji treba odrediti, x je fazna varijabla, t je vrijeme, ξ je slučajni parametar čiji je zakon distribucije nama poznat. Ako je funkcija f u biti nelinearna, onda ne postoje univerzalne metode rješenja za rješavanje ovog problema, a dovoljno dobro razvijene regularne metode za pronalaženje optimalnih rješenja mogu se primijeniti samo stavljanjem vidljivosti korištenja matematike u prvi plan, pojednostavljenja će dovesti do ozbiljnog gubitka točnosti. Matematički model postat će neadekvatan sustavu koji se proučava, a modeliranje će biti samo oblik zablude. Međutim, ako je moguće konstruirati funkciju y = ϕ (ξ) i generator slučajnih brojeva ξ 1 , ξ 2 , ... , ξ N s danim zakonom distribucije, 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 pretvorbe informacija ili tehnološkog procesa obrade dijela, tada će ϕ (ξ) biti statistički model. O nekim principima i tehnikama za konstruiranje statističkih modela bit će riječi kasnije. Važno je da ih je pri konstruiranju funkcije y = ϕ (ξ) i generatora slučajnih brojeva ξ 1 , ξ 2 , ... , ξ N na papiru u većini slučajeva prilično jednostavno implementirati na računalu unutar okvir odgovarajućeg softvera. U ovom slučaju rezultati će sadržavati pogrešku, ali je ta pogreška manja od pogrešaka zbog pretpostavki u analitičkom modelu. Osim toga, pogreška zbog primjene statističkog modela može se kvantificirati. Ova tehnika se također može proširiti na kompliciranije slučajeve, kada jednadžba (2.1) sadrži ne samo slučajne parametre, već i slučajne funkcije. Nakon primanja N realizacija na računalu, slijedi faza obrade statistike koja omogućuje izračunavanje, uz matematičko očekivanje (2.2), i drugih parametara ϕ (ξ) , na primjer, varijance D = 1 N * ∑ xi − 1 N 2* (∑ xi) . U metodi statističkog testiranja, da bi se dobili dovoljno pouzdani rezultati, potrebno je osigurati veliki broj implementacija N , osim toga, uz promjenu barem jednog početnog parametra problema, potrebno je izvesti niz ponovno od N testova. Kod složenih modela, nerazumno velika vrijednost N može postati faktor koji odgađa primanje rezultata. Stoga je važno ispravno procijeniti potreban broj rezultata. Interval povjerenja ε , vjerojatnost povjerenja α , varijanca D i broj realizacija N povezani su relacijom ε = D NF −1 (α) , gdje je F −1 (α) inverzna funkcija Laplaceove funkcije. 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 varijance D može se prethodno dobiti koristeći isti statistički model s brojem 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 informacijskih sustava

slajd broj 1

slajd broj 2

Opis slajda:

Svrha kolegija je produbljivanje temeljnih predmeta (informatika, matematika); formiranje kompetencija za stručnu djelatnost u području informacijskog modeliranja Motivacija učenika pri izboru EK. - provjeravanje od strane studenata svojih sposobnosti i interesa za kreativne, istraživačke aktivnosti u području informacijskog modeliranja; - priprema za upis na sveučilište za specijalnosti vezane za informacijsko modeliranje i računalne tehnologije: primijenjena matematika, modeliranje, računalni sustavi itd.

slajd broj 3

Opis slajda:

slajd broj 4

Opis slajda:

Sadržaj udžbenika Poglavlje 1. Modeliranje informacijskih sustava 1.1. Informacijski sustavi i sistemologija 1.2. Relacijski model i baze podataka (Pristup) 1.3. Proračunska tablica je alat za informacijsko modeliranje 1.4. Aplikacijsko programiranje (VBA elementi za Excel) Poglavlje 2. Računalno matematičko modeliranje 2.1. Uvod u modeliranje 2.2. Alati za računalno matematičko modeliranje (Excel, MathCad, VBA, Pascal) 2.3. Modeliranje optimalnih procesa planiranja 2.4. Računalne simulacijske aplikacije

slajd broj 5

Opis slajda:

"Modeliranje i razvoj informacijskih sustava" Ciljevi izučavanja odjeljka Opći razvoj i oblikovanje svjetonazora učenika. Glavna ideološka komponenta sadržaja ovog dijela kolegija je formiranje sustavnog pristupa analizi okolne stvarnosti. Ovladavanje osnovama metodologije izgradnje informacijskih referentnih sustava. Studenti stječu razumijevanje o fazama razvoja informacijskog sustava: fazi projektiranja i fazi implementacije. Kreiranje baze podataka s više tablica odvija se u MS Access relacijskom DBMS okruženju. Studenti uče kako izgraditi bazu podataka, aplikacije (upiti, izvješća), elemente sučelja (dijaloški okviri). Razvoj i profesionalizacija rada na računalu. Vještine stečene na osnovnom tečaju dalje se razvijaju. - rad s vektorskom grafikom pri izgradnji strukturnih modela sustava - dubinsko proučavanje mogućnosti MS Access DBMS - korištenje MS Excela kao sredstva za rad s bazom podataka - programiranje u VBA u Excelu za razvoj sučelja - pri radu na sažetaka, preporuča se korištenje internetskih resursa; pripremiti materijal za zaštitu u obliku prezentacije (Power Point)

slajd broj 6

Opis slajda:

Projektna nastavna metoda Prikaz problema: Predmetno područje: srednja škola Cilj projekta: izrada informacijskog sustava "Obrazovni proces" Svrha informacijskog sustava: informirati korisnike: O učeničkom sastavu razredne nastave škola O raspodjeli nastavnog opterećenja i vođenju razreda O napredovanju učenika

slajd broj 7

Opis slajda:

slajd broj 8

Opis slajda:

slajd broj 9

Opis slajda:

slajd broj 10

Opis slajda:

slajd broj 11

Opis slajda:

slajd broj 12

Opis slajda:

Razvoj aplikacija Aplikacije: upiti, izvješća Zadatak. Potrebno je pribaviti popis svih djevojčica iz devetog razreda, čije su godišnje ocjene iz informatike petice. Koncept podsheme Korištenje hipotetičkog jezika upita.odabir STUDENTS.PREZIME, STUDENTS.PRVI, STUDENTS.CLASS za STUDENTS.CLASS='9?'i STUDENTS.SEX='g' i GROWTH.SUBJECT='informatika' i GROWTH.GOD =5 poredaj UČENIKI.PREZIME uzlaznim redoslijedom

slajd broj 13

Opis slajda:

slajd broj 14

Opis slajda:

slajd broj 15

Opis slajda:

VBA aplikacijsko programiranje Private Sub CommandButton1_Click() "Deklaracija varijable Dim i, j, n As Integer Dim Flag kao Boolean "Zastava inicijalizacije podataka = False "Broj redaka na popisu škola određuje se n = Raspon("A3"). CurrentRegion.Rows. Count "Traži na popisu broj škole naveden u 'TextBox1 polju za unos" Za i = 3 do n+2 If Cells(i, 1).Value = Val(UserForm1.TextBox1.Text) Tada Oznaka = True Exit For End If Sljedeći fragment rukovatelja događaja "Kliknite na gumb SEARCH"

slajd broj 16

Opis slajda:

"Računalno matematičko modeliranje" Zadaci proučavanja rubrike Ovladavanje modeliranjem kao metodom spoznavanja okolne stvarnosti (istraživačka priroda sekcije) - pokazuje se da modeliranje u različitim područjima znanja ima slične značajke, često se mogu dobiti vrlo bliski modeli. za razne procese; - prikazane su prednosti i nedostaci računalnog pokusa u usporedbi s pokusom punog opsega; - pokazuje se da i apstraktni model i računalo pružaju mogućnost upoznavanja svijeta oko sebe, upravljanja njime u interesu čovjeka. Razvoj praktičnih vještina računalnog modeliranja. Dana je opća metodologija računalnog matematičkog modeliranja. Na primjeru niza modela iz različitih područja znanosti i prakse praktički se provode sve faze modeliranja od formulacije problema do interpretacije rezultata dobivenih tijekom računalnog eksperimenta. Promicanje profesionalnog usmjeravanja učenika. Utvrđivanje sklonosti studenata istraživačkoj djelatnosti, razvoj kreativnih potencijala, usmjerenost na izbor zanimanja vezanog uz znanstveno-istraživački rad. Prevazilaženje predmetne nejedinstva, integracija znanja. U sklopu kolegija matematikom se proučavaju modeli iz različitih područja znanosti. Razvoj i profesionalizacija rada na računalu. Ovladavanje softverom opće i specijalizirane namjene, programskim sustavima.

slajd broj 17

Opis slajda:

slajd broj 18

Opis slajda:

Modeliranje optimalnih procesa planiranja Zadatak 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 izdaju se kupcima na kraju. 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. Cijena (za klijenta) TO-2 je dvostruko veća od TO-2 -1. U stvarnosti neki automobili prolaze TO-1, a neki istog dana TO-2. Potrebno je izraditi takav dnevni plan održavanja kako bi se poduzeću osigurala najveća novčana primanja.

slajd broj 19

Opis slajda:

Modeliranje optimalnih procesa planiranja Formalizacija i matematički model problema Planirani pokazatelji x - dnevni plan proizvodnje TO-1; y je dnevni plan proizvodnje TO-2. Iz formulacije problema proizlazi sustav nejednakosti.Najveća dobit će se postići pri maksimalnoj vrijednosti funkcije Funkcija f(x, y) naziva se funkcija cilja, a sustav nejednakosti sustavom ograničenja. . Imam problem linearnog programiranja

slajd broj 20

Opis slajda:

slajd broj 21

Opis slajda:

Modeliranje optimalnih procesa planiranja Metode rješavanja problema linearnog programiranja Simpleksna metoda - univerzalni način rješavanja problema linearnog programiranja Simpleksna tablica Osnova St. član. 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 broj 22

Opis slajda:

slajd broj 23

Opis slajda:

slajd broj 24

Opis slajda:

slajd broj 25

Opis slajda:

Modeliranje procesa optimalnog rasporeda Privatna podnaredbaButton1_Click() 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" Do Dok t = "sljedeće" Simplex Method Program u VBA za Excel (fragment)

slajd broj 28

Opis slajda:

slajd broj 29

Opis slajda:

Modeliranje optimalnih procesa planiranja Zadatak planiranja radova na izgradnji ceste Postavljanje problema Dvije su točke - početna H i konačna K; od prve do druge potrebno je izgraditi cestu, koja se sastoji od vertikale i segmenata. Poznata je cijena izgradnje svakog od mogućih segmenata (prikazano na slici). U stvarnosti, cesta će biti neka izlomljena crta koja spaja točke H i K. Potrebno je pronaći takvu liniju koja ima najmanju cijenu. Ovo je problem dinamičkog programiranja

Opis slajda:

slajd broj 33

Opis slajda:

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

Opis slajda:

Planirani ishodi učenja za EC. Studenti trebaju poznavati: svrhu i sastav informacijskih sustava; faze izrade računalnog informacijskog sustava; osnovni koncepti sistemologije, postojeće varijante modela sustava; što je model infološke domene; što je baza podataka (DB); klasifikacija baze podataka; struktura relacijske baze podataka (RDB); normalizacija baze podataka; što je DBMS; kako su odnosi organizirani u bazi podataka s više tablica; koje vrste upita baze podataka postoje; kakva je struktura naredbe upita za dohvaćanje i sortiranje podataka; Koje su mogućnosti za rad s bazama podataka ima procesor proračunskih tablica (MS Excel); kako stvoriti i izvršiti makronaredbu u MS Excelu; što je objektno orijentirana aplikacija; osnove programiranja u VBA; sadržaj pojmova "model", "informacijski model", "računalni matematički model";

slajd broj 36

Opis slajda:

faze računalnog matematičkog modeliranja, njihov sadržaj; sastav alata za računalno matematičko modeliranje; mogućnosti procesora proračunskih tablica Excel u provedbi matematičkog modeliranja; mogućnosti MathCAD sustava u implementaciji računalnih matematičkih modela; specifičnosti računalnog matematičkog modeliranja u gospodarskom planiranju; primjeri smislenih zadataka iz područja ekonomskog planiranja, riješeni računalnim simulacijama; formuliranje problema riješenih metodom linearnog programiranja; formuliranje problema rješavanih metodom dinamičkog programiranja; osnovni pojmovi teorije vjerojatnosti potrebni za provedbu simulacijskog modeliranja: slučajna varijabla, zakon raspodjele slučajne varijable, gustoća vjerojatnosti distribucije, pouzdanost rezultata statističkog istraživanja; metode za dobivanje nizova slučajnih brojeva sa zadanim zakonom raspodjele; formulacija problema riješenih simulacijom u teoriji čekanja.

slajd broj 37

Opis slajda:

Studenti bi trebali biti sposobni: osmisliti jednostavan informacijski i referentni sustav; dizajnirati bazu podataka s više tablica; navigirati u okruženju MS Access DBMS; stvoriti strukturu baze podataka i ispuniti je podacima; izvršiti odabir upita u MS Accessu pomoću dizajnera upita; rad s obrascima izvršavati zahtjeve uz dobivanje konačnih podataka; primati izvješća; organizirati baze podataka (liste) s jednom tablicom u MS Excelu; birati i sortirati podatke na popisima; filtriranje podataka; izraditi zaokretne tablice; snimanje makronaredbi za MS Excel pomoću snimača makronaredbi; napisati jednostavne programe za rukovanje događajima u VBA. primijeniti shemu računalnog eksperimenta u rješavanju smislenih problema gdje postoji potreba za računalnim matematičkim modeliranjem; odabrati čimbenike koji utječu na ponašanje sustava koji se proučava, izvršiti rangiranje tih čimbenika;

slajd broj 38

Opis slajda:

graditi modele procesa koji se proučavaju; odabrati softverske alate za proučavanje konstruiranih modela; analizirati dobivene 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 sustava čekanja i interpretirati rezultate. implementirati jednostavne matematičke modele na računalu, stvarajući algoritme i programe na jeziku Visual Basic; koristiti mogućnosti TP Excela za provođenje jednostavnih matematičkih izračuna i ilustriranje rezultata matematičkog modeliranja grafikonima i stupčastim dijagramima; koristiti alat "Traži rješenje" TP Excel za rješavanje problema linearnog i nelinearnog programiranja; koristiti MathCAD sustav za provođenje jednostavnih matematičkih izračuna, grafičku ilustraciju rezultata simulacije; koristiti MathCAD sustav za rješavanje problema linearne i nelinearne optimizacije.

Koncept modela je ključan u općoj teoriji sustava. Modeliranje kao moćna - a često i jedina - istraživačka metoda podrazumijeva zamjenu stvarnog predmeta drugim - materijalnim ili idealnim.
Najvažniji zahtjevi za svaki model su njegova primjerenost predmetu koji se proučava u okviru određenog zadatka i njegova izvedivost dostupnim sredstvima.
U teoriji učinkovitosti i informatici model objekta (sustava, operacije) je materijalni ili idealni (mentalno reprezentabilni) sustav koji je stvoren i/ili korišten u rješavanju određenog problema kako bi se dobilo novo znanje o izvornom objektu, njemu adekvatno u smislu 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 informacijskih sustava (EIS) koriste se sve metode modeliranja, međutim, u ovom dijelu glavna će se pozornost posvetiti semiotičkim (znakovnim) metodama.
Podsjetimo da je semiotika (od grčkog semeion - znak, znak) znanost o općim svojstvima znakovnih sustava, tj. sustava konkretnih ili apstraktnih objekata (znakova), od kojih je svaki povezan s određenom vrijednošću. Primjeri takvih sustava su bilo koji jezici

Riža. 3.1.1. Klasifikacija metoda modeliranja

(prirodni ili umjetni, na primjer, jezici opisa podataka ili modeliranja), signalni sustavi u društvu i životinjskom svijetu itd.
Semiotika uključuje tri odjeljka: sintaktiku; semantika; pragmatike.
Sintaktika istražuje sintaksu znakovnih sustava bez obzira na bilo kakva tumačenja i probleme povezane s percepcijom znakovnih sustava kao sredstva komunikacije i komunikacije.
Semantika proučava interpretaciju iskaza znakovnog sustava i, sa stajališta modeliranja objekata, zauzima glavno mjesto u semiotici.
Pragmatika istražuje odnos korisnika znakovnog sustava prema samom znakovnom sustavu, posebice percepciju smislenih izraza znakovnog sustava.
Od brojnih semiotičkih modela, zbog najveće rasprostranjenosti, posebice u uvjetima informatizacije suvremenog društva i uvođenja formalnih metoda u sve sfere ljudskog djelovanja, izdvajamo matematičke koji realne sustave prikazuju pomoću matematičkih simbola. Istodobno, uzimajući u obzir činjenicu da razmatramo metode modeliranja u odnosu na proučavanje sustava u različitim operacijama, koristit ćemo se dobro poznatom metodologijom analize sustava, teorije učinkovitosti i odlučivanja.

Više o temi 3. TEHNOLOGIJA SIMULACIJE INFORMACIJSKIH SUSTAVA Metode modeliranja sustava:

1. Simulacijski modeli ekonomskih informacijskih sustava Metodološke osnove za primjenu simulacijske metode
2. Odjeljak III. OSNOVE MODELIRANJA SUSTAVA MARKETINŠKIH USLUGA
3. POGLAVLJE 1. UPRAVLJANI DINAMIČKI SUSTAVI KAO OBJEKT RAČUNALNE SIMULACIJE
4. Osnove strukturnog modeliranja marketinškog sustava medicinskih usluga
5. Odjeljak IV. PRIMJER PRIMIJENJENE UPOTREBE MODELA MARKETINŠKOG SUSTAVA U SIMULACIJSKOM MODELIRANJU
6. Koncept modeliranja financijske sfere marketinških sustava

Pošaljite svoj dobar rad u bazu znanja je jednostavno. Upotrijebite obrazac u nastavku

Studenti, diplomski studenti, mladi znanstvenici koji koriste bazu znanja u svom studiju i radu bit će vam jako zahvalni.

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

Institut državne službe Omsk

Modeliranje informacijskih sustava korištenjem UML jezika

Smjernice za izvođenje nastavnog rada

I.V. Chervenchuk

• Uvod
• 2 . Jedinstveni jezik modeliranjaUML
• 4. Razvoj modela softverskog sustava pomoćuUML
• 5. Pitanja implementacije informacijskog sustava
• 6. Teme seminarskih radova
• Bibliografski popis

Uvod

Rad se bavi razvojem informacijskih sustava korištenjem unificiranog jezika modeliranja UML, koji je temelj za nastavni rad iz discipline "Informacijski sustavi i procesi. Modeliranje i upravljanje". Razrađuju se glavne faze racionalnog jedinstvenog procesa razvoja informacijskih sustava, daju se primjeri i ilustracije. Dane opcije za zadatke za nastavu.

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 uvjeti za nastavni rad

Nastavni rad iz discipline "Informacijski sustavi i procesi. Modeliranje i upravljanje" završna je faza studija ovog kolegija i osmišljen je kako bi se u praksi konsolidirali temeljna teorijska znanja o modeliranju informacijskih sustava. Rad se sastoji u razvoju modela nekog informacijskog sustava korištenjem jedinstvenog jezika modeliranja UML s njegovom naknadnom implementacijom. Kao tipična opcija za zadatak, predlaže se izrada informacijsko-referentnog sustava na bazi baze podataka, no na zahtjev studenta, u dogovoru s nastavnikom, može se izraditi WEB aplikacija, testni sustav ili hardverski uređaj. biti predložen kao zadatak. U ovom slučaju, glavni nužni zahtjev je korištenje objektno orijentiranog pristupa i izgradnja UML modela.

Tipičan naslov seminarskog rada izgleda kao "Razvoj informacijskog i referentnog sustava _ titula _ "

Uvod

1. Smisaoni pregled predmetnog područja. Osnovni zahtjevi sustava

2. Detaljni model informacijskog sustava

2.1 Pogled u smislu slučajeva korištenja

2.2 Pogled dizajna

2.3 Pogled na implementaciju

2.4 Pogled procesa (ako je potrebno)

2.5 Prikaz implementacije (ako je potrebno)

3. Implementacija informacijskog sustava

Zaključak

Primjena Popis programa ili glavnog modula

U uvodu se može istaknuti korištenje informacijskih tehnologija u različitim područjima djelovanja, uključujući uslužni sektor, prednosti elektroničkog računovodstva, probleme izgradnje specijaliziranih informacijskih sustava itd.

Ove smjernice sadrže detaljne preporuke za glavne odjeljke objašnjenja i primjere dizajna. Treba napomenuti da je glavni predmet ovog kolegija razvoj UML modela informacijskog sustava, stoga se preporuča da se UML dijagrami navedu u glavnom dijelu objašnjenja, dajući im detaljne komentare i programski tekstovi trebaju biti uključeni u aplikaciju.

Prilikom razvoja multitasking sustava potrebno je dati prikaz procesa. Prikaz implementacije pretpostavlja distribuirani informacijski sustav. Ove vrste, kao i pripadajući odjeljci objašnjenja, nisu obvezni za provedbu ovog nastavnog rada, njihova se uporaba pretpostavlja kada se izvode samo određene opcije za nastavni rad.

Kada se u bilješci obrađuju problemi implementacije sustava, poželjno je obrazložiti izbor programskog okruženja i dati korisnički priručnik. Obvezni element je uključivanje zaslonskih formi (screen-shorts) implementiranog programa u tekst, potiče se korištenje alata obrnutog inženjeringa.

Zaključno, ukratko su sažeti glavni rezultati rada: razvijen je UML model sustava, sustav je implementiran korištenjem takvog i takvog programskog okruženja koje razvijeni sustav dopušta, prednosti korištenih pristupa (na temelju modeliranje) do projektiranja sustava.

modeliranje jezika informacijskog sustava

Nastavni rad treba sadržavati 20-30 stranica tiskanog teksta s ilustracijama. Dijagrami presedana, klasa, interakcija moraju se dati bez greške.

2. Unified Modeling Language UML

Racionalni razvoj informacijskog sustava podrazumijeva duboku preliminarnu analitičku studiju. Prije svega, potrebno je ocrtati raspon zadataka koje obavlja razvijeni sustav, zatim razviti model sustava i na kraju odrediti načine implementacije. Duboko proučavanje arhitekture informacijskog sustava koji se razvija u početnim fazama projektiranja, u pravilu se kasnije isplati, osobito pri razvoju velikih projekata uz dugoročnu podršku.

Alati jezika za modeliranje UML (Unified Model Language, - unificirani programski jezik) omogućuju eksplicitnu i vrlo laku izradu preliminarnog konceptualnog razvoja informacijskog sustava, a istovremeno metodički prate cijeli razvojni proces, uključujući cijeli daljnji životni ciklus informacijskog sustava koji se razvija kao softverski proizvod.

UML je jezik za vizualizaciju, specificiranje, konstruiranje i dokumentiranje artefakata softverskih sustava koji se temelji na objektno orijentiranom pristupu.

UML, kao i svaki drugi jezik, sastoji se od rječnika i pravila koja vam omogućuju kombiniranje riječi u njemu i dobivanje smislenih konstrukcija. U jeziku modeliranja, vokabular i pravila usmjereni su na konceptualni i fizički prikaz informacijskih sustava. Modeliranje je neophodno za razumijevanje sustava. Međutim, jedan model nikada nije dovoljan. Naprotiv, da bismo razumjeli bilo koji netrivijalni sustav, potrebno je razviti veliki broj međusobno povezanih modela. Kada se primjenjuje na softverske sustave, to znači da je potreban jezik koji se može koristiti za opisivanje prikaza arhitekture sustava s različitih stajališta tijekom 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 točnih, nedvosmislenih i cjelovitih modela. UML omogućuje specifikaciju svih značajnih odluka o analizi, dizajnu i implementaciji koje se moraju donijeti tijekom razvoja i implementacije softverskog sustava.

UML je jezik dizajna. Iako UML nije vizualni programski jezik, modeli stvoreni s njim mogu se izravno 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 na relacijske tablice baze podataka ili trajne objektno orijentirane objekte baze podataka. Oni koncepti koji su po mogućnosti grafički prikazani predstavljeni su 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ćuje izravan 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 korištenje niza specifičnih entiteta. Stoga, obrnuti inženjering zahtijeva i alate i ljudsku intervenciju. Kombinacija unaprijednog generiranja koda i obrnutog inženjeringa omogućuje vam rad u grafičkim i tekstualnim prikazima, sve dok alati osiguravaju dosljednost između oba prikaza.

Osim izravnog preslikavanja na programske jezike, UML, zbog svoje izražajnosti i jednoznačnosti, omogućuje izravno izvršavanje modela, simulaciju ponašanja sustava i kontrolu postojećih sustava.

UML je dokumentacijski jezik

Softverska tvrtka proizvodi i druge dokumente osim izvršnog koda, uključujući:

Zahtjevi sustava;

arhitektura;

projekt;

izvor;

projektni planovi;

testovi;

prototipovi;

verzije itd.

Ovisno o usvojenoj metodologiji razvoja, neki se radovi izvode formalnije, drugi manje. Referentni dokumenti nisu samo isporučivi dijelovi projekta; nužni su za upravljanje, za evaluaciju rezultata, a također i kao sredstvo komunikacije između članova tima tijekom razvoja sustava i nakon njegove implementacije.

UML nudi programeru i menadžmentu vlastito rješenje za problem dokumentiranja arhitekture sustava i svih njegovih detalja, nudi jezik za formuliranje zahtjeva sustava i definiranje testova i, na kraju, pruža alate za modeliranje rada u fazi planiranja projekta i verzije. kontrolirati.

Razmotrite razvoj modela informacijskog sustava korištenjem UML jezika na primjeru razvoja automatiziranog radnog mjesta tajnika odjela (u daljnjem tekstu: radna stanica tajnika odjela).

3. Opis predmetnog područja

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

Pod opisom predmetnog područja razumjet ćemo opis okruženja sustava koji se razvija, tipove korisnika sustava, uz navođenje glavnih zadataka čije je rješavanje dodijeljeno sustavu.

U preliminarnom opisu predmetnog područja uvode se glavni pojmovi (rječnik sustava), definiraju se vrste korisnika i njihova prava te formuliraju zadaci koje razvijeni sustav treba riješiti. Pritom se pri opisu treba koristiti sredstvima zajedničkog jezika i standardne poslovne grafike (slike, dijagrami, tablice).

Prilikom izrade sustavnog rječnika potrebno je definirati nazive entiteta ("učenik", "nastavnik", "disciplina"). Istodobno, pojam entiteta shvaćamo kao komponentu modela domene, odnosno kao objekt koji je već identificiran na konceptualnoj razini. Objekte dodijeljene predmetnom području analitičar pretvara u entitete.

Entitet je rezultat apstrahiranja stvarnog objekta. Postoje dva problema s objektima: identifikacija i adekvatan opis. Za identifikaciju koristite ime koje mora biti jedinstveno. Istodobno, pretpostavlja se da postoji odbacivanje njegovog značenja, koje je svojstveno prirodnom jeziku. Koristi se samo funkcija pokazivača naziva. Ime je izravan način identificiranja objekta. Neizravni načini identifikacije objekta uključuju definiranje objekta kroz njegova svojstva (karakteristike ili značajke).

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

Možete odrediti 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, prikladnije je koristiti napredne alate za opisivanje predmetnog područja, na primjer, UML jezični alati.

Dakle, zadatak je razviti sustav „Radna stanica tajnika katedre“ koji bi omogućio automatizirano obračunavanje podataka o zaposlenicima i studentima odjela IKT OmSTU, omogućio fleksibilnost u rješavanju planiranih i neplaniranih specifičnih zadataka obrade računovodstvenih podataka.

U sklopu rješavanja problema razvoja automatiziranog radnog mjesta tajnika odjela izdvajamo sljedeće subjekte:

učitelji - nastavnici odjela;

studentima- studenti sveučilišta dane specijalnosti;

studenti studiraju u grupe, skupina je organizacijska (objedinjujuća) cjelina za studente;

Diplomirani studenti, imaju osobitost da, s jedne strane, sami mogu voditi nastavu, s druge strane, sami su studenti i imaju mentora;

disciplina- poučavana disciplina (predmet, kolegij).

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

Upravljamo s dvije vrste korisnika: običnim korisnik(unaprijediti korisnik, i administrator. Pretpostavlja se da korisnik može pristupiti sustavu sa zahtjevom, prikazati izvješća, administrator može dodatno modificirati podatke. Primjerice, pomoćnik tajnika odjela može biti korisnik, sam tajnik ili odgovorni nastavnik može biti administrator.

Uzimajući u obzir uvedene termine, razvijeni sustav treba osigurati:

organizacija cjelovitog i pouzdanog računovodstva svih zaposlenika i studenata odjela;

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

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

otklanjanje dupliciranja prilikom unosa informacija i nastalih mehaničkih pogrešaka;

praktično korisničko sučelje;

razlikovanje ovlasti običnih korisnika i administratora.

U ovom primjeru rješavamo konkretan problem - razvijamo radnu stanicu za tajnika odjela, pa nam je odjel, koji ćemo po defaultu imati na umu, uzet kao strukturna jedinica najviše razine, tj. je, pretpostavlja se da se svi elementi modela odnose samo na ovaj odjel, što nije eksplicitno navedeno. Strukture više razine, kao što su fakultet, sveučilište, nećemo razmatrati.

4. Razvoj modela softverskog sustava korištenjem UML-a

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

UML dijagram je grafički prikaz skupa elemenata koji se najčešće prikazuje kao povezani graf s vrhovima (entitetima) i bridovima (relacijama). Dijagrami karakteriziraju sustav s različitih stajališta. Dijagram je u izvjesnom smislu jedna od projekcija sustava. U pravilu, dijagrami daju sažeti prikaz elemenata koji čine sustav. 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 sustava (vidi sljedeći odjeljak). Dakle, postoji devet vrsta dijagrama u UML-u:

dijagrami razreda

dijagrami objekata;

dijagrami slučajeva upotrebe;

dijagrami slijeda;

dijagrami suradnje;

dijagrami stanja;

dijagrami djelovanja (aktivnosti);

dijagrami komponenti;

dijagrami raspoređivanja.

Konceptualni UML model

Dijagram klasa prikazuje klase, sučelja, objekte i suradnje, kao i njihove odnose. Kod modeliranja objektno orijentiranih sustava najčešće se koristi ova vrsta dijagrama. Dijagrami klasa odgovaraju statičkom pogledu na sustav s gledišta dizajna. Dijagrami klasa koji uključuju aktivne klase odgovaraju statičkom pogledu na sustav u smislu procesa.

Dijagram objekata predstavlja objekte i odnose među njima. Oni su statične "fotografije" instanci entiteta prikazanih na dijagramima klasa. Dijagrami objekata, poput dijagrama klasa, odnose se na statički pogled na sustav u smislu dizajna ili procesa, ali imajući na umu stvarnu ili lažnu implementaciju.

Dijagram slučaja korištenja prikazuje slučajeve upotrebe i aktere (poseban slučaj klasa) i odnose između njih. Dijagrami slučajeva korištenja odnose se na statički prikaz sustava u smislu slučajeva korištenja. Posebno su važni u organizaciji i modeliranju ponašanja sustava.

Dijagrami slijeda i suradnje posebni su slučajevi interakcijskih dijagrama. Interakcioni dijagrami predstavljaju odnose između objekata; pokazuje, posebice, poruke koje objekti mogu razmjenjivati. Dijagrami interakcije odnose se na dinamički prikaz sustava. Istodobno, dijagrami sekvence odražavaju vremenski poredak poruka, a dijagrami suradnje odražavaju strukturnu organizaciju objekata koji razmjenjuju poruke. Ovi dijagrami su izomorfni, odnosno mogu se transformirati jedan u drugi.

Dijagrami stanja (Statechart dijagrami) predstavljaju automat koji uključuje stanja, prijelaze, događaje i vrste akcija. Dijagrami stanja odnose se na dinamički pogled na sustav; posebno su važni pri modeliranju ponašanja sučelja, klase ili suradnje. Usredotočuju se na ponašanje objekta ovisno o slijedu događaja, što je vrlo korisno za modeliranje reaktivnih sustava.

Dijagram aktivnosti je poseban slučaj dijagrama stanja; predstavlja prijelaze tijeka kontrole s jedne aktivnosti na drugu unutar sustava. Dijagrami aktivnosti odnose se na dinamički prikaz sustava; najvažniji su u modeliranju njegova funkcioniranja i odražavaju tijek kontrole između objekata.

Dijagram komponenti prikazuje organizaciju skupa komponenti i ovisnosti koje postoje između njih. Dijagrami komponenti odnose se na statički pogled na sustav sa stajališta implementacije. Mogu se povezati s dijagramima klasa, budući da je komponenta obično mapirana na jednu ili više klasa, sučelja ili suradnje.

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

Ovo je djelomični popis dijagrama koji se koriste u UML-u. Alati vam omogućuju generiranje i drugih dijagrama, kao što su dijagrami profila baze podataka, dijagrami web aplikacija i tako dalje.

4.1 Dizajniranje pogleda u smislu slučajeva korištenja

Modeliranje započinje definiranjem glavnih zadataka sustava koji se razvija i radnji koje mora izvršiti. U tu svrhu koriste se dijagrami slučajeva korištenja. 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 slijeda radnji koje izvodi sustav, a koji proizvodi vidljivi rezultat koji je značajan za neki određeni Djeluj e ra (Glumac). Slučaj korištenja koristi se za strukturiranje entiteta ponašanja modela. Presedan samo deklarira opis neke radnje sustava, odgovarajući na pitanje "što učiniti?", ali ne navodi na koji način. Konkretnu implementaciju ponašanja određenog slučajem upotrebe osigurava klasa, suradnja klase ili komponenta.

Glumac je povezani skup uloga koje korisnici slučajeva korištenja obavljaju u interakciji s njima. U pravilu, glumac predstavlja ulogu koju igra osoba, hardverski uređaj ili čak drugi sustav u danom sustavu. U razvijenom sustavu "Radna stanica tajnika odjela" akteri su administratori (admin) i korisnik.

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

Kako bi se izgradio dijagram slučajeva korištenja, potrebno je identificirati elementarne radnje koje sustav izvodi i usporediti ih s slučajevima korištenja. Istodobno, poželjno je navesti imena presedana tako da ukazuju na ponašanje, često takvi nazivi sadrže glagole, na primjer, "generirati izvješće", "pronaći podatke po kriteriju" itd. Možete imenovati slučajeve upotrebe s imenicama koje sugeriraju neku radnju, na primjer, "autorizacija", "pretraga", "kontrola".

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

Uređivanjepodaci,

tražistudent,

tražiučitelj, nastavnik, profesor,

izručenjepopispodučavaodiscipline,

Autorizacija.

Elementi dijagrama slučajeva upotrebe (slučajevi korištenja 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 mogu se koristiti generalizacijski odnosi. Ovi odnosi imaju isto značenje kao u dijagramu klasa.

Osim toga, definirane su dvije specifične ovisnosti između slučajeva korištenja 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 ograđenog slučaja upotrebe. Možete zamisliti osnovni slučaj upotrebe kao posuđivanje ponašanja uključenih. Zbog prisutnosti inkluzijskih odnosa moguće je izbjeći višestruke opise istog toka događaja, budući da se opće ponašanje može opisati kao neovisni presedan uključen u osnovne. Odnos uključivanja je primjer delegiranja, u kojem je skup odgovornosti sustava 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 prikazani su kao ovisnosti 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 nakon čega slijedi naziv slučaja upotrebe koji želite uključiti.

Odnos proširenja koristi se za modeliranje dijelova slučaja upotrebe koje korisnik doživljava kao izborno ponašanje sustava. Na taj način možete odvojiti obavezno i ​​neobavezno ponašanje. Odnosi proširenja također se 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 prikazan je kao ovisnost sa stereotipom "proširi". Točke proširenja osnovnog scenarija navedene su u opcionalnom odjeljku. To su jednostavno oznake koje se mogu pojaviti u streamu osnovnih slučajeva upotrebe.

Primjer korištenja ovog odnosa može biti pristup bazi podataka koja ima operativni dio i arhivu. U tom 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. je, pristup ide prema proširenom scenariju.

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

Dijagram presedana radne stanice tajnika odjela prikazan je na sl.1.

Riža. 1. Dijagram presedana radne stanice tajnika odjela

Presedan tražistudent uključuje pretraživanje po prezimenu i pretraživanje prema rezultatima akademske uspješnosti.

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

Tokovi događaja mogu se opisati korištenjem nestrukturiranog teksta, strukturiranog teksta (koji sadrži funkcijske riječi: AKO,PRIJEONIPORPOZDRAV itd.), specijalizirani formalni jezik (pseudokod).

Kada se presedan opisuje tijekom događaja, važno je također označiti glavne i alternativne tokove ponašanja sustava.

Na primjer, razmotrite opis toka događaja slučaja upotrebe ovlaštenje.

Osnovni, temeljni teći događaji. Slučaj korištenja počinje kada sustav od korisnika zatraži svoje ime za prijavu (Login) i lozinku (Password). Korisnik ga može unijeti s tipkovnice. Završite unos pritiskom na tipku Unesi. Nakon toga sustav provjerava unesene Login i lozinku, te ako odgovaraju administratoru potvrđuje ovlaštenje administratora. Tu presedan završava.

Iznimna teći događaji. Klijent može prekinuti transakciju u bilo kojem trenutku pritiskom na tipku Otkazati. Ova radnja ponovno pokreće slučaj upotrebe. Nema ulaska u sustav.

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

Iznimna teći događaji. Ako je klijent unio Login i lozinku koji ne odgovaraju administratoru, od njega se traži da ponovno uđe ili se prijavi kao obični korisnik.

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

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

Slični dijagrami također mogu objasniti izvođenje drugih slučajeva korištenja, čime se nadopunjuje pogled na sustav u smislu slučajeva korištenja.

Riža. 2. Autorizacija korisnika. Dijagram aktivnosti.

4.2 Pogled na dizajn sa stajališta dizajna

Pogled dizajna glavni je korak u konceptualizaciji modela. U ovoj fazi uvode se glavne apstrakcije, definiraju klase i sučelja putem kojih se implementira rješavanje zadataka. Ako presedani samo deklariraju ponašanje sustava, tada se u fazi razvoja pogleda, sa stajališ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, sučelja, suradnje, kao i odnose među njima. Razvoj dijagrama klasa trebao bi započeti s definiranjem klasa koje odgovaraju glavnim entitetima sustava, a koji se u pravilu određuju u početnim fazama razvoja pri opisivanju predmetnog područja. Ovdje biste trebali odlučiti koje je entitete prikladnije modelirati kao klase, a koje kao njihove atribute. Na primjer, ako je unutar fakulteta potrebno odrediti voditelja za svaki odjel, bilo bi bolje navesti entitet menadžerodjela neka bude atribut klase odjelu koji označava klasu učitelji ( udruga jedan na jedan ), umjesto uvođenja zasebnog razreda menadžerodjela.

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

je dobro definirana apstrakcija nekog koncepta iz vokabulara domene problema ili domene rješenja;

sadrži mali, dobro definiran 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ćuje proširenje i prilagodbu novim zadacima.

U sklopu izrade AWP modela tajnika odjela definiramo razrede: učitelji, studentima, Diplomirani studenti, discipline, grupe. Očito, prvi od njih ima mnogo zajedničkih atributa, pa uvodimo apstraktnu klasu Person, koji će obuhvatiti sva svojstva vezana uz osobu u kontekstu sustava koji se razvija (prezime, ime, adresa itd.). U ovom slučaju osoba bit će nadklasa i biti povezana relacijom generalizacije s klasama učitelji, studentima, Diplomirani studenti.

Atribut adresa ima vlastitu strukturu, da biste je odrazili možete uvesti dodatnu klasu, nazovimo je T_ ADR(kao što je uobičajeno u mnogim programskim sustavima, nazivi klasa počinju slovom T). Treba napomenuti da atribut adresa razreda osoba je instanca klase T_ ADR, odnosno uspostavlja se odnos ovisnosti između ovih klasa (prikazano kao točkasta strelica s otvorenim vrhom, strelica pokazuje od ovisnog prema neovisnom). U našem slučaju, promjena strukture klase T_ ADR podrazumijeva promjenu klase osoba kroz strukturu odgovarajućeg atributa ( adresa).

Prilikom modeliranja razreda T_ ADR atribut indeks postavljen primitivnim tipom T_ POSTIDX, definiran kao šesteroznamenkasti decimalni broj. Primitivni tipovi su modelirani stereotipom " tip" , raspon vrijednosti je specificiran kroz ograničenja zatvorena u vitičaste zagrade.

U klasi učitelj, nastavnik, profesor Istaknimo specifične atribute koji se odnose samo na učitelja: položaj, uh. stupanj(akademska titula), uh. rang ( akademska titula) pražnjenje(kategorija jedinstvene tarifne ljestvice). Atributi uh. stupanj i uh. rang bolje je definirati specijalizirane tipove putem enuma. Enume su modelirane od strane klase sa stereotipom " enum" (enumeracija - nabrajanje), valjane vrijednosti se zapisuju kao atributi, oznake koje određuju vidljivost atributa su potisnute. U primjeru koji se razmatra kroz nabrajanje uvodimo specijalizirane razrede T_Mora, T_UchSt, T_UchSv, definirajući, odnosno moguća radna mjesta, akademske stupnjeve, akademska zvanja putem nabrajanja. U ovom slučaju, kao i drugdje u sličnim slučajevima, prilikom kreiranja klasa koje specificiraju atribute glavne klase, uspostavljaju se odnosi ovisnosti.

Za razred student upisuje se određeni atribut sobađačke knjige. Za poslijediplomski razred definirani su posebni atributi oblikučenje i datumpriznanice. Oblik izobrazbe utvrđuje poseban razred nabrajanjem T_FormEducation(puno radno vrijeme, nepuno radno vrijeme).

Razred skupina ima atribute: titula, oblik učenje, brojklinac. ( broj studenata ). S obzirom na to da nastavnici predmetnog odjela mogu izvoditi nastavu sa grupama s drugih fakulteta, uvodi se dopunska nastava specijalitet, s atributima soba(specijalitet), titula(specijalitet ), fakultet, čiji tipovi nisu navedeni u ovom modelu, iako se mogu definirati putem nabrajanja.

Razred disciplina ima atribute: soba, titula, ciklus. Atribut ciklus pomoću specijaliziranog tipa uveden putem nabrajanja T_ciklusi određuje kojem ciklusu disciplina pripada: ciklusu humanitarnih i društveno-ekonomskih disciplina, matematičkim i prirodoslovnim disciplinama, općim stručnim disciplinama, posebnim disciplinama.

Atributi brojsati, brojsemestra ne može se specificirati u klasi disciplina, budući da ovise o specijalnosti, tim više ih ne možete specificirati u razredu specijalitet. Ovi atributi se odnose na par specijalnosti-disciplina i definirani su u razredu - asocijacijama Discipline-specijalnosti.

Riža. 3. Dijagram razreda radne stanice tajnika odjela (opcija 1)

Prilikom vizualizacije strukture klasa treba obratiti pozornost na vidljivost atributa. Svi razmatrani atributi moraju biti dostupni i javno vidljivi (označeno znakom "+" ili ikonom bez lokota). U razmatranim razredima fokusirali smo se na strukturu, a ne na ponašanje (operacije nisu opisane i ne bi se trebale opisivati), stoga je, radi lakše percepcije dijagrama, poželjno potisnuti prikaz operacija.

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

studentima formirana u grupe, u ovom slučaju asocijacija će izgledati kao agregacija. Agregacija podrazumijeva odnos dio-cjelina, označen punom linijom s rombom na kraju sa strane cjeline (u našem slučaju grupe). Mnoštvo odnosa student-grupa je više na jedan. Svaki skupina odnosi se na određeno specijalitet, pak, nekoliko skupina može odgovarati određenoj specijalnosti, tako da asocijacija grupnih specijaliteta 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 učitelji i podučavao discipline prema tipu "više prema mnogo": nastavnik može voditi nekoliko disciplina, neke discipline može predavati više nastavnika. Između discipline i specijaliteti osniva se i udruga "mnogo-na-mnogo": nastavni plan i program specijalnosti sadrži mnoge discipline, većina disciplina nalazi se u planovima rada nekoliko specijalnosti. Ovoj asocijaciji je pridružen razred asocijacija. Discipline-specijalnosti s atributima koji označavaju kolegij, broj semestara i broj sati određene discipline u određenoj specijalnosti.

Slično, uvodimo asocijaciju između grupe i učitelji: učitelji provode nastavu u grupama, tip asocijacije višestrukosti je više-prema-mnogima. izravna povezanost između grupe i disciplins ne treba definirati, budući da se ovaj odnos prati kroz klasu povezivanja specijalitet.

Kako bi se kod diplomiranog studenta prikazala prisutnost mentora, potrebno je uvesti asocijaciju između diplomiranog studenta i nastavnika po tipu „mnogo prema jednom“, jedan mentor može imati više diplomiranih studenata. Na ovoj asocijaciji, sa strane učitelja, možete eksplicitno naznačiti ulogu: nadglednik.

Riža. 4. Dijagram razreda radne stanice tajnika odjela (opcija 2)

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

doktorandi također može voditi nastavu u određenoj disciplini s određenim skupinama: udrugama mnogo prema mnogo poslijediplomske grupe, diplomirani studenti-discipline. Neki diplomirani studenti možda neće predavati nastavu, pa će tip višestrukosti na krajevima asocijacije biti 0. n.

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

Riža. 5. Pojednostavljeni dijagram klasa

S obzirom da nastavu predaju i studenti diplomskog studija i nastavnici, možete uvesti dodatni apstraktni sat, npr. nastava, koji je potomak klase osoba i superklasa za nastavu učitelj, nastavnik, profesor i postdiplomac, što će donekle smanjiti broj veza. (slika 4.). U ovom slučaju, iz razreda disciplina i skupina udruge će ići na nastavu nastava, uz pretpostavku povezanosti s razredima učitelj, nastavnik, profesor i postdiplomac putem nasljeđivanja (odnos generalizacije). U razred nastava atributi se mogu ukloniti ponuda(0,5 ulog, puni ulog) i pražnjenje.

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

Na sl. 5, zajedno s glavnim klasama koje odgovaraju konceptualnim elementima sustava, također prikazuje klasu T_ ADR, otkrivajući strukturu adrese, ova klasa je također važna jer sadrži potrebne elemente podataka za učitelji i Diplomirani studenti- potomci klase osoba.

Prijeđimo na definiranje sučelja. Klase komuniciraju s vanjskim svijetom putem sučelja.

Sučelje (Sučelje) je skup operacija koje definiraju uslugu (skup usluga) koju pruža klasa ili komponenta. Dakle, sučelje opisuje vanjsko vidljivo ponašanje elementa. Sučelje može predstavljati ponašanje klase ili komponente u cijelosti ili djelomično; definira samo specifikacije operacija (signature), a ne njihove implementacije. Grafičko sučelje prikazano je kao krug, ispod kojeg je napisano njegovo ime. Sučelje rijetko postoji samostalno - obično je pripojeno implementacijskoj klasi ili bean-u. Sučelje uvijek pretpostavlja postojanje nekog "ugovora" između strane koja deklarira izvršenje određenog broja operacija i strane koja provodi te operacije.

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

Za razred elektroničkistol, i, sukladno tome, za sve njegove potomke definiramo sučelje uređivanje,što podrazumijeva sve moguće operacije uređivanja podataka (umetanje, brisanje, promjena podataka). Pretpostavlja se da u razredu elektroničkistol ove značajke su implementirane.

Korištenje posebne klase elektroničkistol a nasljeđivanjem je izbjegnuto definiranje posebnih svojstava i sučelja za uređivanje podataka za svaku proračunsku tablicu.

Definirajte sučelja tražiučitelj, nastavnik, profesor, tražidiscipline, pridružujući ih odgovarajućim klasama s implementacijskim odnosima. Sastav operacija ovih sučelja nećemo otkrivati ​​(prilično je trivijalan), pa ćemo sučelja prikazati u skraćenom obliku (u obliku kruga). Podsjetimo da je relacija implementacije povezana sa sučeljem u kratkom obliku prikazana kao jednostavna puna linija (kao asocijacija).

Sučelje tražistudentće se prikazati s naznakom popisa operacija kroz stereotipnu klasu, dok je implementacijski odnos prikazan kao točkasta strelica sa zatvorenim vrhom.

Naravno, pretpostavlja se da se uvedena sučelja implementiraju pomoću klasa kojima su vezana implementacijskom relacijom, odnosno odgovarajuće klase sadrže operacije i metode koje implementiraju deklarirana sučelja. Da bi se olakšala percepcija, ti se mehanizmi ne vizualiziraju.

Za upravljanje pravima pristupa i autorizacijom korisnika uvodimo klasu menadžerpristup. Upravitelj pristupa ima atribut privatne vrste pristupa stollozinke, što je instanca klase CodirTable(kodirana tablica) koja sadrži lozinke ( zaporka) i nazive unosa ( prijaviti 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 sposobnosti, ne zadržavajući se na mehanizmu za njihovu implementaciju, već pod pretpostavkom da su inkapsulirane u klasi CodirTable.

Razred menadžerpristup sadrži otvorene transakcije ulaznizaporka i dodjeljivanje administratorskih prava, pomoću kojih se provodi autorizacija i upravljanje pravima pristupa.

Označite ovisnost između sučelja za uređivanje podataka ( uređivanje) i upravitelj pristupa, pod pretpostavkom da samo korisnici s administratorskim pravima imaju pune mogućnosti uređivanja podataka.

Riža. 6. Završni razredni dijagram radnog mjesta tajnika odjela

Konačni dijagram prikazan je na sl. 6.

Dakle, razvoj objektno orijentiranog modela radne stanice tajnika odjela pomoću UML dijagrama klasa u ovoj se fazi može smatrati dovršenim. Naravno, moguće je vratiti se i revidirati neke elemente tijekom projektiranja sustava, pri podešavanju zadataka, pri razjašnjavanju pojedinih detalja. Proces projektiranja informacijskih sustava je iterativan. Treba napomenuti da razvijeni dijagram klasa sadrži elemente koji eksplicitno ili implicitno implementiraju sve slučajeve korištenja dijagrama slučajeva. Svaki slučaj upotrebe dijagrama slučaja upotrebe mora odgovarati ili sučelju, ili operaciji sučelja (pretpostavlja se da je implementacija u klasama koje odgovaraju sučelju), ili operaciji javne klase, ili skupu javnih operacija (u ovom slučaju, slučaj korištenja implementira izravno odgovarajuća klasa ili skup klasa).

Razmotrimo postupak stvaranja novog zapisa o učeniku pomoću dijagrama sekvence.

Stvaranje novog zapisa zahtijeva administratorska prava, tako da će administrator biti akter ove interakcije ( admin). Ovaj element je već unesen u dijagram slučaja upotrebe, pa ga povucimo na dijagram slijeda iz preglednika prikaza slučajeva upotrebe.

Treba napomenuti da dijagrami interakcije predstavljaju objekte, odnosno specifične instance klasa (ime objekta uvijek je podvučeno).

Upravljamo objektima: oblikulazni, menadžerzapisima, evidencija učenika Petrov(kao konkretan primjer studentske evidencije), menadžertransakcije. Ovaj skup objekata tipičan je kada se mijenja zapis u tablici baze podataka.

Oblikulazni- element korisničkog sučelja, tipičan je oblik za unos podataka o učeniku (prezime, ime, patronim, adresa i sl.). U našem slučaju radi se o malo unaprijed definiranoj konkretnoj implementaciji standardnog sučelja uređivanje razreda elektroničkistol. Budući da nismo posebno uveli sučelje za uređivanje podataka učenika na dijagramu razreda, stoga eksplicitno navedite klasu za objekt oblikulazni nećemo.

Menadžerzapisima- objekt koji ima standardni skup mogućnosti upravljanja podacima pri radu s proračunskom tablicom. Ovaj skup sposobnosti nasljeđuje klasa studentima iz razreda elektroničkistol. Za objekt Menadžerzapisima eksplicitno specificira klasu čija je instanca - studentima.

Petrov- specifičan zapis o učeniku Petrovu, novi element tablice o studentima. Ovdje izričito označavamo uvedenu klasu ulazakOstudent. Takvi objekti obično postoje privremeno kako bi slali relevantne informacije u bazu podataka tijekom transakcija. Nakon završetka transakcije, ovaj objekt se može uništiti. Objekt koji odgovara zapisu može se ponovno kreirati ako je potrebno urediti informacije.

Menadžertransakcije- objekt koji osigurava izvođenje kompletne operacije nad bazom podataka, u ovom slučaju stvaranje novog zapisa o učeniku Petrovu. Ovaj objekt je također odgovoran za obavljanje niza funkcija sustava koje prate transakciju. Primjeri upravitelja transakcija su, na primjer, BDE (koristi se za pristup bazama podataka Paradox, Dbase itd. iz Delphi aplikacija), ADO (koristi se za pristup bazama podataka MS Accessa iz raznih aplikacija).

Dijagram slijeda unosa novog zapisa o učeniku u radnom mjestu tajnika odjela prikazan je na sl. 7.

Riža. 7. Unos podataka učenika. Dijagram slijeda.

Na dijagramu sekvence definiramo prijenos poruka između objekata: stvoritinoviulazak(emitiranje od objekta do objekta do kraja lanca kao poruka uštedjetiulazak); otvorenaoblik(u obrazac za unos); UnesiF.I O.,adresa. ( unos podataka za studenta), tada se ti podaci emitiraju porukama uštedjetiF.I O.,adresa. Iz menadžertransakciješalje se poruka za preuzimanje informacijaOstudent, pružajući povratnu informaciju bazi podataka i konačno refleksivnu poruku menadžertransakcije imenovan kao uštedjetiulazakvDB, osigurava završetak transakcije.

Po želji, ova interakcija se može prikazati dijagramom suradnje, koji ilustrira prije svega strukturni aspekt interakcije (slika 8). Ovaj dijagram se može izgraditi od prethodnog u automatskom načinu rada (u Rational Rose, pritiskom na tipku F5).

Riža. 8. Unos podataka učenika. Dijagram suradnje.

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

4.3 Dizajniranje profila relacijske baze podataka

U slučaju da se za implementaciju sustava koristi objektno orijentirani DBMS (OODBMS), objektni dijagram izgrađen u prethodnom odjeljku je konačni model i izravni vodič za implementaciju informacijskog sustava. U istom slučaju, kada se relacijska baza podataka (RDB) treba koristiti kao informacijska jezgra informacijskog sustava, potrebno je razviti još jedan dijagram, dijagram profila relacijske 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 temeljni UML metamodel. Kako bi se vizualizirali elementi dizajna baze podataka i pravila za projektiranje relacijskih baza podataka, odgovarajuće ikone se dodaju profilu (u daljnjem tekstu jednostavno baze podataka). Baza podataka je opisana pomoću tablica, stupaca i relacija. Profil ima elemente koji proširuju bazu podataka, kao što su okidači, pohranjene procedure, ograničenja, korisnički definirane vrste (domene), pogledi i drugi. Profil pokazuje kako i gdje se svi ti elementi koriste u modelu. Na profilu UML baze podataka definirani su sljedeći entiteti:

stol ( Tablica) - skup zapisa u bazi podataka za određeni objekt, sastoji se od stupaca.

Stupac ( Stupac) je komponenta tablice koja sadrži jedan od atributa tablice (polje tablice).

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

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

Zastupanje ( Pogled) - virtualna tablica koja se s korisničke točke gledišta ponaša na isti način kao obična tablica, ali ne postoji sama za sebe.

Pohranjeno postupak ( Pohranjena procedura je neovisna proceduralna funkcija koja se izvodi na poslužitelju.

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

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

Slični dokumenti

Metodologije razvoja informacijskih sustava u domaćoj i stranoj literaturi. Državni i međunarodni standardi u području razvoja softvera. Izrada fragmenta informacijskog sustava "Obrazovno-metodički resurs".

seminarski rad, dodan 28.05.2009


Definicija pojma "sustav". Povijest razvoja i značajke suvremenih informacijskih sustava. Glavne faze u razvoju automatiziranog informacijskog sustava. Korištenje domaćih i međunarodnih standarda u području informacijskih sustava.

prezentacija, dodano 14.10.2013


Glavna ideja metodologije i principa RAD-razvoja informacijskih sustava, njegove glavne prednosti. Razlozi popularnosti, značajke primjene tehnologije. Formuliranje glavnih načela razvoja. Razvojna okruženja koja koriste RAD principe.

prezentacija, dodano 02.04.2013


Uloga upravljačke strukture u informacijskom sustavu. Primjeri informacijskih sustava. Struktura i klasifikacija informacijskih sustava. Informacijska tehnologija. Faze razvoja informacijskih tehnologija. Vrste informacijskih tehnologija.

seminarski rad, dodan 17.06.2003


Koncept CASE-alata kao softverskih alata koji podržavaju procese stvaranja i održavanja informacijskih sustava (IS). Značajke IDEF-tehnologija za razvoj IS-a. Opis IDEF0 notacije. Razvoj funkcionalnih modela poslovnih procesa.

prezentacija, dodano 07.04.2013


Bit jedinstvenog jezika modeliranja, njegov konceptualni model i princip rada, opća pravila i mehanizmi. Modeliranje koncepta "kompetencije". Dijagram razreda koji opisuje proces učenja. Implementacija zadanog informacijskog sustava.

rad, dodan 17.02.2015


Razvoj informacijskih sustava. Suvremeno tržište financijskog i ekonomskog primijenjenog softvera. Prednosti i nedostaci uvođenja automatiziranih informacijskih sustava. Metode projektiranja automatiziranih informacijskih sustava.

rad, dodan 22.11.2015


Pojam informacijskog sustava, vrste informacijskih sustava. Analiza alata za razvoj automatiziranih informacijskih sustava. Zahtjevi za program i softverski proizvod. Razvoj GUI obrazaca i baza podataka.

rad, dodan 23.06.2015


Rješenje za informacijsku sigurnost. Sustavi za podatkovne centre. Što je oprema podatkovnog centra. Osnovni pojmovi i principi modeliranja. Odabir metode rješavanja problema. Metoda dopuštenog smjera Seutendijk, Frank–Wulf algoritam.

seminarski rad, dodan 18.05.2017


Koncept informacijskog sustava. Faze razvoja informacijskih sustava. Procesi u informacijskom sustavu. Informacijski sustav za pronalaženje tržišnih niša, za smanjenje troškova proizvodnje. Struktura informacijskog sustava. Tehnička podrška.

U idejnom rješenju IS-a koristi se niz opisa specifikacija (zahtjeva, uvjeta, ograničenja i sl.), među kojima središnje mjesto zauzimaju modeli transformacije, pohrane i prijenosa informacija. Modeli dobiveni tijekom proučavanja predmetnog područja, u procesu razvoja IS-a, mijenjaju se i postaju modeli projektiranog IS-a.

Postoje funkcionalni, informacijski, bihevioralni i strukturni modeli. Funkcionalni model sustava opisuje skup funkcija koje sustav obavlja. Informacijski modeli odražavaju strukture podataka – njihov sastav i odnose. Modeli ponašanja opisuju informacijske procese (dinamiku funkcioniranja), uključuju kategorije kao što su stanje sustava, događaj, prijelaz iz jednog stanja u drugo, prijelazni uvjeti, slijed događaja. Strukturni modeli karakteriziraju morfologiju sustava (njegovu konstrukciju) - sastav podsustava, njihove međusobne odnose.

Postoji niz načina za izgradnju i predstavljanje modela, različiti za različite vrste modela. Osnova je strukturna analiza – metoda proučavanja sustava, koja počinje s njegovim općim pregledom, a zatim ide u detalje, tvoreći hijerarhijsku strukturu sa sve većim brojem razina.

U ovom priručniku razmotrit ćemo metodologiju za konstrukciju strukturno-funkcionalnih i informacijskih modela IS-a te na temelju njih osmisliti relacijske baze podataka, ilustrirajući ovaj proces konkretnim primjerom obuke sljedećeg sadržaja.

U svezi s diverzifikacijom aktivnosti, od uprave Bezenchuk and Companions zaprimljena je narudžba za razvoj informacijskog sustava u cilju poboljšanja učinkovitosti upravljanja.

Tvrtka se bavi proizvodnjom i prodajom namještaja. Postoji katalog tipičnog namještaja koji proizvodi tvrtka. Kupac može odabrati namještaj iz kataloga i/ili naručiti prema vlastitom opisu. Nakon formiranja narudžbe sastavlja se ugovor. Tvrtka prihvaća stari namještaj od kupaca novog namještaja čiji se trošak odbija od cijene narudžbe. Prihvaćeni stari namještaj se prodaje ili se može iznajmiti. Nakon određenog vremena, nepotraženi stari namještaj iznajmljuje se u skladište drva. Održava se arhiva s podacima o izvršenim narudžbama. Klijenti koji su prethodno sklopili ugovore s tvrtkom ostvaruju popust pri sklapanju novog ugovora. Tvrtka nabavlja materijale i komponente potrebne za proizvodnju namještaja od dobavljača.

Funkcionalno modeliranje IC-a

Postoji nekoliko različitih metoda i alata za razvoj strukturnih i funkcionalnih modela IS-a. Jedna od najraširenijih je metoda koja se temelji na konstrukciji dijagrama toka podataka (DFD - Data Flow Diagrams)

Dijagram toka podataka

DFD je metoda strukturne analize koja operira s konceptima "protoka podataka" i "procesa" kako bi opisala sustav kao skup funkcionalnih komponenti (procesa) povezanih tokovima podataka. Sukladno temeljnom principu strukturne analize, opis sustava temelji se na dosljednom detaljiziranju njegovih funkcija, koje se prikazuje kao hijerarhijski organizirani skup grafičkih slika (dijagrama).

Glavni elementi dijagrama toka podataka su: vanjski entiteti; procesi; uređaji za pohranu podataka; tokovi podataka. Svaki takav element ima standardnu ​​grafičku sliku.

Vanjski entitet je objekt koji je izvor ili primatelj informacija, na primjer, kupci, osoblje, dobavljači, kupci, skladište. Definicija nekog objekta ili sustava kao vanjskog entiteta ukazuje na to da se nalazi izvan granica projiciranog IS-a.

Vanjski entiteti u gornjem primjeru bili bi kupci namještaja, dobavljači materijala, skladište i neki drugi objekti domene. Primjeri njihovih grafičkih slika:

Funkcije projektiranog IS-a u DFD modelu treba prikazati kao procese koji pretvaraju ulazne tokove podataka u izlazne u skladu s određenim algoritmima. Sami tokovi podataka su mehanizam koji simulira prijenos informacija od nekog izvora do primatelja (iz jednog dijela sustava u drugi). Tijek podataka u dijagramu predstavljen je linijom koja završava strelicom koja pokazuje smjer toka. Svaki tok podataka mora imati naziv koji odražava njegov sadržaj.

Na primjer, funkcija IS namijenjena formiranju narudžbe namještaja i sklapanju ugovora za njegovu proizvodnju može se na dijagramu prikazati postupkom "narudžbe namještaja". Ovaj proces bi trebao dobiti kao ulazne podatke o kupcu, potrebne za sklapanje ugovora i podatke o namještaju koji je naručio (vrsta, opis, dimenzije itd.). Grafički prikaz ovog procesa i povezanih tokova podataka:

Podatkovni pogon (pohrana) je apstraktni uređaj za pohranjivanje informacija koji se u bilo kojem trenutku može staviti u pogon i dohvatiti za daljnju upotrebu. Informacije u pogonu mogu dolaziti od vanjskih entiteta i procesa, oni također mogu biti potrošači informacija pohranjenih u pogonu. Pogon grafika:

Dijagram konteksta

Dijagram najviše razine hijerarhije, koji fiksira glavne procese ili podsustave IS-a i njihove veze s vanjskim entitetima (ulazima i izlazima sustava), naziva se kontekstni dijagram. Obično se pri projektiranju relativno jednostavnih IS-ova gradi jedan kontekstni dijagram s topologijom zvijezde, u čijem je središtu glavni proces povezan s prijamnicima i izvorima informacija (korisnicima i drugim vanjskim sustavima). Iako se kontekstni dijagram može činiti trivijalnim, njegova nedvojbena korisnost leži u činjenici da utvrđuje granice analiziranog sustava i određuje glavnu svrhu sustava. Ovo postavlja kontekst u kojem postoje dijagrami niže razine sa svojim procesima, tokovima i pogonima.

Kontekstni dijagram za gore opisani primjer prikazan je na slici 4.

Valja napomenuti da je u obrazovne svrhe u nastavku razmatrana pojednostavljena verzija modela sustava u kojoj neće biti prikazani tokovi podataka i procesi vezani uz financijsku stranu poslovanja tvrtke. Iako je, naravno, za svaku tvrtku od vitalnog značaja pravovremena, potpuna i pouzdana informacija o njezinom financijskom stanju. U ovom primjeru, "financijska komponenta" očito je prisutna u interakciji tvrtke sa svim vanjskim entitetima predstavljenim u kontekstualnom dijagramu.

Vanjski entiteti prikazani u ovom dijagramu djeluju kao izvori informacija koje se pohranjuju i obrađuju u IS-u tvrtke, te kao potrošači tih informacija. U ovom modelu identificiraju se dva entiteta “klijent” koji su slike stvarnih klijenata tvrtke: “kupac” i “kupac”, budući da postoje značajne razlike u sadržaju informacija koje razmjenjuju s IS-om.

Za "klijent-kupac", "katalog" toka podataka je opis tipičnog namještaja koji proizvodi tvrtka. 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 te također moguće informacije o starom namještaju koji je kupac prodao tvrtki.

Za “kupac-kupac” tok podataka “katalog starog namještaja” je informacija o dostupnom starom namještaju primljenom od kupaca. Tijek "kupnja/najam starog namještaja" je informacija o starom namještaju koji je odabrao klijent, a koji želi kupiti ili iznajmiti.

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