1 od 38

Prezentacija na temu: Modeliranje informacijskih sustava

Slajd br. 1

Slajd br. 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 odabiru EK. - ispitivanje sposobnosti i interesa učenika za kreativne, istraživačke aktivnosti u području informacijskog modeliranja; - priprema za upis na sveučilište za specijalnosti vezane uz informacijsko modeliranje i računalne tehnologije: primijenjena matematika, modeliranje, računalni sustavi itd.

Slajd br. 3

Opis slajda:

Slajd br. 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 – 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 procesa optimalnog planiranja 2.4. Računalne simulacijske aplikacije

Slajd br. 5

Opis slajda:

"Modeliranje i razvoj informacijskih sustava" Ciljevi prouč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 u razvoju informacijskog sustava: fazi projektiranja i fazi implementacije. Stvaranje multitabularne baze podataka odvija se u MS Access relacijskom DBMS okruženju. Studenti ovladavaju tehnikama izgradnje baze podataka, aplikacija (upita, izvješća), elemenata sučelja (dijaloški okviri). Razvoj i profesionalizacija rada na računalu. Vještine stečene u 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 okruženju Excel za razvoj sučelja - pri radu kod sažetaka preporuča se korištenje internetskih resursa; pripremiti materijal za zaštitu u obliku prezentacije (Power Point)

Slajd br. 6

Opis slajda:

Projektna nastavna metoda Prikaz problema: Predmetno područje: srednja škola Cilj projekta: izrada informacijskog sustava "Odgojno-obrazovni proces" Svrha informacijskog sustava: informirati korisnike: O učeničkom sastavu odjeljenja O nastavnom osoblju škole O rasporedu nastave opterećenje i vođenje 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šća Zadatak. Potrebno je pribaviti popis svih djevojčica devetog razreda koje imaju A iz informatike. Koncept podsheme Korištenje hipotetičkog izbora jezika upita PREZIME STUDENTI IME STUDENTA RAZRED STUDENTA RAZRED = '9? poredaj 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 redaka na popisu škola n = Raspon (" A3 "). Trenutna regija .Redci. Broji "Traži na popisu broj škole naveden u polju za unos 'TextBox1" Za i = 3 do n + 2 Ako ćelije (i, 1) .Vrijednost = Val (UserForm1.TextBox1.Text) Tada Zastava = True Exit For End If Sljedeći fragment programa za obradu događaja "Kliknite na gumb SEARCH"

Slajd br. 16

Opis slajda:

"Računalno matematičko modeliranje" Ciljevi proučavanja sekcije 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 je za različite procese moguće dobiti vrlo slične modele; - pokazuje prednosti i nedostatke računalnog pokusa u usporedbi s pokusom punog opsega; - pokazuje se da i apstraktni model i računalo pružaju mogućnost spoznavanja okolnog svijeta, 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 provode se praktički sve faze modeliranja, od formulacije problema do interpretacije rezultata dobivenih tijekom računalnog eksperimenta. Promicanje profesionalnog usmjeravanja učenika. Razotkrivanje studentskih sklonosti za istraživačku djelatnost, razvoj kreativnih potencijala, usmjerenost na izbor zanimanja vezanog za znanstveno-istraživački rad. Prevladavanje predmetne disocijacije, integracija znanja. Kolegij ispituje modele iz različitih područja znanosti korištenjem matematike. Razvoj i profesionalizacija rada na računalu. Ovladavanje softverom opće i specijalizirane namjene, programskim sustavima.

Slajd br. 17

Opis slajda:

Slajd br. 18

Opis slajda:

Modeliranje procesa optimalnog planiranja Problem rasporeda rada servisa Postavka problema Neka autoservis obavlja dvije vrste servisa: TO-1 i TO-2. Automobili se primaju na početku radnog dana, a na kraju predaju kupcima. Zbog ograničenog parkirnog mjesta, 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 dvostruko veći kao što je 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 poduzeću osigurala najveća novčana primanja.

Slajd br. 19

Opis slajda:

Modeliranje procesa optimalnog planiranja Formalizacija i matematički model problema Planirani pokazatelji x - dnevni plan proizvodnje TO-1; y - dnevni plan proizvodnje za 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 br. 21

Opis slajda:

Modeliranje procesa optimalnog planiranja Metode rješavanja problema linearnog programiranja Simpleksna metoda je univerzalna metoda za rješavanje problema linearnog programiranja Simpleksna tablica 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_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ći" Do Dok t = "sljedeći" program Simplex metode u VBA za Excel (fragment)

Slajd br. 28

Opis slajda:

Slajd broj 29

Opis slajda:

Modeliranje procesa optimalnog planiranja Zadatak planiranja radova na izgradnji ceste Postavljanje problema Postoje dvije točke - početna H i konačna K; od prve do druge potrebno je izgraditi cestu, koja se sastoji od vertikale i segmenata. Trošak izgradnje svake od mogućih dionica je poznat (prikazano na slici). U stvarnosti, cesta će biti neka izlomljena linija koja spaja točke H i K. Potrebno je pronaći takvu liniju koja ima najnižu cijenu. Ovo je zadatak 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 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 veze organizirane u višetabelarnoj bazi podataka; koje su vrste upita bazi podataka; kakva je struktura naredbe zahtjeva za odabir i sortiranje podataka; kakve mogućnosti za rad s bazama podataka ima procesor proračunskih tablica (MS Excel); kako možete stvoriti i izvršiti makronaredbu u MS Excelu; što je objektno orijentirana aplikacija; Osnove VBA programiranja; 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 Excel procesora proračunskih tablica 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 metodom računalnog modeliranja; prikaz problema riješenih metodom linearnog programiranja; prikaz problema riješenih 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; načini dobivanja nizova slučajnih brojeva s zadanim zakonom raspodjele; prikaz problema riješenih metodom simulacijskog modeliranja u teoriji čekanja.

Slajd broj 37

Opis slajda:

Studenti bi trebali biti sposobni: osmisliti jednostavan informacijski i referentni sustav; dizajnirati multitabularnu bazu podataka; navigirati okruženjem MS Access DBMS; stvoriti strukturu baze podataka i ispuniti je podacima; izraditi upite za odabir u MS Accessu pomoću dizajnera upita; rad s obrascima; postavljati upite uz primitak 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 rukovaoce događajima u VBA. primijeniti shemu računalnog eksperimenta pri rješavanju smislenih problema gdje postoji potreba za računalnim matematičkim modeliranjem; odabrati čimbenike koji utječu na ponašanje proučavanog sustava, izvršiti rangiranje tih čimbenika;

Slajd broj 38

Opis slajda:

graditi modele proučavanih procesa; odabrati softver 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 obavljanje jednostavnih matematičkih proračuna, grafički ilustrirati rezultate modeliranja; koristiti MathCAD sustav za rješavanje problema linearne i nelinearne optimizacije.

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.

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

Državni institut za usluge Omsk

Modeliranje informacijskih sustava korištenjem UML jezika

Metodičke upute za izvođenje seminarskog rada

I.V. Chervenchuk

• Uvod
• 2 . Jedinstveni jezik modeliranjaUML
• 4. Razvoj modela softverskog sustava sredstvimaUML
• 5. Pitanja implementacije informacijskog sustava
• 6. Teme kolegija
• 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 su opcije za zadaće za nastavu.

Metodičke upute namijenjene su studentima specijalnosti "Primijenjena informatika" i mogu se koristiti u nastavi, pripremi za ispit, kao iu procesu samostalnog rada.

1. Opći uvjeti za izvođenje seminarskog rada

Nastavni rad iz discipline "Informacijski sustavi i procesi. Modeliranje i upravljanje" završna je faza izučavanja 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 pomoću jedinstvenog modelarskog jezika UML s njegovom naknadnom implementacijom. Kao tipična varijanta zadatka, predlaže se izrada informacijsko-referentnog sustava na bazi baze podataka, ali se na zahtjev studenta, u dogovoru s nastavnikom, može izraditi WEB aplikacija, testni sustav ili hardverski uređaj. ponuditi kao zadatak. Istodobno, glavni preduvjet je korištenje objektno orijentiranog pristupa i izgradnja UML modela.

Tipičan naziv seminarskog rada izgleda kao "Razvoj informacijsko-referentnog sustava _ titula _ "

Uvod

1. Sadržajni pregled predmetnog područja. Osnovni zahtjevi sustava

2. Detaljan model informacijskog sustava

2.1 Pogled iz perspektive slučajeva korištenja

2.2 Pogled dizajna

2.3 Pogled na implementaciju

2.4 Perspektiva procesa (ako je primjenjivo)

2.5 Pogled sa stajališta implementacije (ako je potrebno)

3. Implementacija informacijskog sustava

Zaključak

Primjena Popis programa ili glavnog modula

U uvodu se može ukazati na korištenje informacijske tehnologije 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 snažno preporučuje da se UML-dijagrami navedu u glavnom dijelu objašnjenja, uz detaljne komentare. , a tekstove programa treba staviti u aplikaciju.

Prilikom projektiranja 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 izvođenje ovog kolegija, njihova se uporaba pretpostavlja pri izvođenju samo određenih varijanti nastavnog rada.

Prilikom isticanja problema implementacije sustava u bilješci, preporučljivo je obrazložiti izbor programskog okruženja, 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.

U zaključku se ukratko sumiraju 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 (temeljenih o modeliranju) do projektiranja sustava.

modeliranje jezika informacijskog sustava

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

2. Unified Modeling Language UML

Racionalni razvoj informacijskog sustava pretpostavlja duboku preliminarnu analitičku studiju. Prije svega, potrebno je ocrtati raspon zadataka koje obavlja sustav koji se razvija, zatim razviti model sustava i na kraju odrediti metode implementacije. Duboko proučavanje arhitekture informacijskog sustava koji se razvija u početnim fazama projektiranja, u pravilu se kasnije isplati, posebno kada se razvijaju projekti velikih razmjera uz dugoročnu podršku.

Alati jezika za modeliranje UML (Unified Model Language, - unificirani programski jezik) omogućuju ekspresivno i prilično jednostavno izvođenje preliminarnog konceptualnog razvoja informacijskog sustava, a istovremeno metodički prate cijeli proces razvoja, uključujući i cjelokupni daljnji životni ciklus razvijenog informacijskog sustava kao softverskog proizvoda.

UML je objektno orijentirani jezik za vizualizaciju, specificiranje, konstruiranje i dokumentiranje artefakata softverskih sustava.

UML, kao i svaki drugi jezik, sastoji se od rječnika i pravila koja vam omogućuju kombiniranje riječi uključenih u njega i dobivanje smislenih konstrukcija. U jeziku modeliranja, vokabular i pravila usredotočeni su na konceptualni i fizički prikaz informacijskih sustava. Modeliranje je bitno za razumijevanje sustava. Uz to, jedan model nikada nije dovoljan. Naprotiv, za razumijevanje bilo kojeg netrivijalnog sustava potrebno je razviti veliki broj međusobno povezanih modela. Primijenjeno na softverske sustave, to znači da je potreban jezik kojim je moguće s različitih stajališta opisati prikaze arhitekture sustava kroz njegov razvojni ciklus.

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

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 njime 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 tablice relacijskih baza 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 su bolje opisani u tekstualnom obliku izražavaju se pomoću programskog jezika.

Ovo 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 u programske jezike, UML, zbog svoje izražajnosti i jednoznačnosti, omogućuje izravno izvršavanje modela, simulaciju ponašanja sustava i upravljanje operativnim sustavima.

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 izrade, neki se radovi izvode formalnije, drugi manje. Dokumenti na koje se pozivaju nisu samo isporučeni 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 pruža programeru i menadžmentu vlastiti način rješavanja problema dokumentiranja arhitekture sustava i svih njezinih detalja, pruža jezik za formuliranje zahtjeva sustava i definiranje testova, te konačno pruža sredstvo za modeliranje rada tijekom planiranja projekta i verzije. kontrolna faza.

Razmotrimo razvoj modela informacijskog sustava pomoću UML jezika na primjeru razvoja automatizirane radne stanice za tajnika odjela (u daljnjem tekstu AWP 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 IP-a pretpostavlja postojanje stabilne korelacije tijekom vremena između naziva, pojmova i određenih stvarnosti vanjskog svijeta, neovisno o samom IP-u i njegovom krugu korisnika. Dakle, uvođenje u razmatranje koncepta domene baze podataka ograničava i čini prostor za pronalaženje informacija vidljivim u IS-u te omogućuje izvršavanje upita u konačnom vremenu.

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

U preliminarnom opisu predmetnog područja uvode se osnovni pojmovi (rječnik sustava), utvrđuju se vrste korisnika i njihova prava, formuliraju se zadaci koje razvijeni sustav mora riješiti. U ovom slučaju, opis bi trebao koristiti sredstva običnog jezika i standardne poslovne grafike (slike, dijagrami, tablice).

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

Entitet je rezultat apstrakcije stvarnog objekta. Dva su problema povezana s 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 izravan način identificiranja objekta. Neizravne metode identifikacije objekta uključuju definiranje objekta kroz njegova svojstva (obilježja 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 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 inkluzivan odnos. Dakle, sve informacije o objektima i entitetima domene opisane su pomoću izraza na prirodnom jeziku.

Možete odrediti 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, prikladnije je koristiti napredna sredstva za opisivanje domene, na primjer, sredstva za UML jeziku.

Dakle, zadatak je razviti sustav "radne stanice tajnika katedre" koji bi omogućio automatizirano obračunavanje podataka o zaposlenicima i studentima odsjeka za IKT OmSTU, pružio fleksibilne mogućnosti za rješavanje planiranih i neplaniranih specifičnih zadataka obrade. vjerodajnice.

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

učitelji - nastavnici odjela;

studentima- studenti sveučilišta ove specijalnosti;

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

Diplomirani studenti, imaju posebnost da, s jedne strane, sami mogu voditi nastavu, s druge strane, i sami su studenti i imaju znanstvenog savjetnika;

disciplina- disciplina koja se podučava (predmet, kolegij).

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

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

Uzimajući u obzir uvedene pojmove, sustav koji se razvija trebao bi osigurati:

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

informatička potpora donošenim upravljačkim odlukama, formiranje cjelovitih i pouzdanih informacija o obrazovnim procesima i rezultatima rada odjela;

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

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

korisničko sučelje;

razlikovanje ovlasti običnih korisnika i administratora.

U ovom primjeru rješavamo određeni problem - razvijamo AWP za tajnika odjela, stoga se odjel uzima kao strukturna jedinica najviše razine za nas, što ćemo po defaultu imati na umu, tj. pretpostavlja se da se svi elementi modela odnose samo na ovaj odjel, koji nije eksplicitno specificiran... Nećemo razmatrati strukture više razine, kao što su fakultet, sveučilište.

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

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 s vrhovima (entitetima) i bridovima (relacijama). Dijagrami karakteriziraju sustav s različitih stajališta. Dijagram je u određenom smislu jedna od projekcija sustava. U pravilu, grafikoni pružaju sažeti prikaz elemenata koji čine sustav. Jedan te isti element može biti prisutan na svim dijagramima, ili samo u nekoliko (najčešća varijanta), ili nije prisutan ni u 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 sustava (vidi sljedeći odjeljak). Dakle, u UML-u se razlikuje devet vrsta dijagrama:

dijagrami razreda

dijagrami objekata;

dijagrami slučajeva upotrebe;

dijagrami slijeda;

dijagrami suradnje;

dijagrami stanja;

dijagrami djelovanja (aktivnosti);

dijagrami komponenti;

dijagrami raspoređivanja.

UML konceptualni model

Dijagram klasa prikazuje klase, sučelja, objekte i suradnje te njihove odnose. Kod modeliranja objektno orijentiranih sustava najčešće se koristi ova vrsta dijagrama. Dijagrami klasa predstavljaju statički pogled dizajna sustava. Dijagrami klasa koji uključuju aktivne klase odgovaraju statičkom pogledu na sustav iz perspektive procesa.

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

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

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

Dijagrami dijagrama stanja 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 simuliranje reaktivnih sustava.

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

Dijagram komponenti prikazuje organizaciju skupa komponenti i ovisnosti između njih. Dijagrami komponenti odnose se na statički pogled na sustav s gledišta implementacije. Mogu se povezati s dijagramima klasa, budući da se komponenta obično preslikava 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 podsklop obično sadrži jednu ili više komponenti.

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

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

Glumac je koherentan skup uloga koje korisnici koriste u interakciji s njima. Glumac obično predstavlja ulogu koju osoba, hardverski uređaj ili čak drugi sustav igra 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".

Da bi se izgradio dijagram slučajeva korištenja, potrebno je identificirati elementarne radnje koje sustav izvodi i usporediti ih sa slučajevima korištenja. Pritom je poželjno navesti nazive slučajeva upotrebe tako da ukazuju na ponašanje, često takvi nazivi sadrže glagole, na primjer, "generirati izvješće", "pronaći podatke po kriteriju" itd. Moguće je davati nazive za upotrebu padeža s imenicama koje sugeriraju neke radnje, na primjer, "autorizacija", "pretraga", "kontrola".

Vraćajući se na modeliranje automatiziranog radnog mjesta tajnika odjela, istaknimo presedane:

Uređivanjepodaci,

tražistudent,

tražiučitelj, nastavnik, profesor,

Izdavanjepopispodučavaodiscipline,

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.

Osim toga, definirane su dvije specifične ovisnosti između slučajeva korištenja 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. Možete zamisliti osnovni slučaj upotrebe kao posuđivanje 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će ponašanje može opisati kao neovisni slučaj uporabe uključen u osnovne. Odnos uključivanja je primjer delegiranja, u kojem se na jednom mjestu opisuje niz odgovornosti sustava (u uključenom slučaju upotrebe), a ostali slučajevi korištenja, kada je potrebno, uključuju te odgovornosti u svoj skup.

Odnosi uključivanja prikazani su kao ovisnosti 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 nakon čega slijedi naziv slučaja upotrebe koji želite uključiti.

Relacija proširenja koristi se za modeliranje dijelova slučaja upotrebe koje korisnik percipira kao neobavezno ponašanje sustava. To vam omogućuje da odvojite potrebna i neobavezna ponašanja. 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 simulaciju višestrukih tokova koji se mogu pokrenuti u nekom trenutku u scenariju kao rezultat eksplicitne interakcije s glumcem.

Odnos proširenja prikazan je kao ovisnost sa stereotipom "proširiti". Točke proširenja osnovne skripte navedene su u dodatnom odjeljku. To su jednostavno oznake koje se mogu pojaviti u tijeku temeljnog slučaja upotrebe.

Primjer korištenja ovog odnosa može biti pristup bazi podataka s operativnim dijelom i arhivom. U tom slučaju, ako se zahtjevu dostavljaju podaci iz operativnog dijela, vrši se glavni (osnovni) pristup podacima, ako podaci iz operativnog dijela nisu dovoljni, pristupa se arhivskim podacima, odnosno pristup izvedeno prema naprednom scenariju.

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

Dijagram presedana AWP-a tajnika odjela prikazan je na slici 1.

Riža. 1. Dijagram presedana AWP-a tajnika odjela

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

Prilikom oblikovanja pogleda u smislu slučajeva korištenja, često je potrebno dati prošireni opis slučaja upotrebe (samo je naziv dan u skraćenoj verziji). Tipično, tijek događaja slučaja upotrebe opisan je u tekstualnom obliku na početku. Kako precizirate svoje zahtjeve sustava, bit će prikladnije 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: AKO,PRIJEONIPORPOZDRAV itd.), specijalizirani formalni jezik (pseudokod).

Kada opisujete slučaj upotrebe kao tijek događaja, važno je također odrediti 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 njegovu prijavu i lozinku. Korisnik ga može unijeti s tipkovnice. Unos završava pritiskom na tipku. Unesi. Nakon toga sustav provjerava unesene Login i lozinku, te ako odgovaraju administratoru potvrđuje ovlaštenje administratora. Ovim se završava presedan.

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

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

Iznimna teći događaji. Ukoliko je klijent unio Login i lozinku koji ne odgovaraju administratoru, nudi mu se ponovni ulazak ili prijava u sustav kao običan korisnik.

Očito, 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), uvjetne vrhove (odluka - odabir, prepoznavanje, označene rombovima) i poveznice.

Slični dijagrami mogu objasniti izvođenje drugih slučajeva korištenja, čime se nadopunjuje pogled na sustav sa stajališta slučajeva korištenja.

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

4.2 Razvijanje pogleda dizajna

Pogled dizajna je glavna faza u idejnoj studiji modela. U ovoj fazi uvode se glavne apstrakcije, definiraju klase i sučelja putem kojih se implementira rješavanje zadataka. Ako slučajevi korištenja samo deklariraju ponašanje sustava, tada se u fazi razvoja pogleda s gledišta dizajna određuje na koji način će se ti slučajevi korištenja 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 veze između njih. 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 je potrebno odlučiti koje je entitete pogodnije modelirati kao klase, a koje kao njihove atribute. Primjerice, ako bi se unutar fakulteta zahtijevalo navođenje voditelja za svaki odjel, bilo bi bolje navesti menadžerStolice neka bude atribut klase stolica koji označava klasu učitelji ( udruga jedan na jedan ), umjesto uvođenja zasebnog razreda menadžerStolice.

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

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

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

razumljivo i jednostavno, ali u isto vrijeme omogućuje proširenje i prilagodbu novim zadacima.

U sklopu izrade modela automatiziranog radnog mjesta tajnika odjela definirat ćemo nastavu: učitelji, studentima, Diplomirani studenti, discipline, skupina... Očito, prvi od njih ima mnogo zajedničkih atributa, pa uvedimo apstraktnu klasu PEerson, koji će obuhvatiti sva svojstva povezana s ljudima u kontekstu sustava koji se razvija (prezime, ime, adresa itd.). U ovom slučaju osoba bit će nadklasa i komunicirati generičkim odnosom 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). Imajte na umu da atribut adresa razreda osoba je instanca klase T_ ADR, odnosno uspostavlja se odnos ovisnosti između ovih klasa (prikazano isprekidanom strelicom s otvorenim vrhom, strelica je usmjerena od ovisnog prema nezavisnom). 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 pomoću primitivnog tipa T_ POSTIDX, definiran kao šesteroznamenkasti decimalni broj. Primitivni tipovi su stereotipizirani" tip" , raspon vrijednosti je specificiran kroz ograničenja zatvorena u vitičaste zagrade.

U klasi učitelj, nastavnik, profesor istaknimo specifične atribute vezane samo za učitelja: položaj, uh. stupanj(akademska titula), uh. rang ( akademsko zvanje), pražnjenje(kategorija jedinstvene tarifne ljestvice). Atributi uh. stupanj i uh. rang bolje je definirati specijalizirane tipove putem nabrajanja. Nabrajanja su modelirana od strane klase sa stereotipom " enum" (enumeracija - nabrajanje), dopuštene vrijednosti se zapisuju kao atributi, oznake koje određuju vidljivost atributa su potisnute. U razmatranom primjeru kroz nabrajanje uvodimo specijalizirane razrede T_Mora, T_UCHST, T_UchZv, odnosno definiranje mogućih pozicija, akademskih stupnjeva, akademskih titula putem premještaja. 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 uvodi se specifičan atribut sobaknjige rekorda... Za poslijediplomski razred definirani su posebni atributi oblikučenje i datumpriznanice... Oblik studija odredit će poseban razred nabrajanjem T_FormObuch(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 predavati grupe s drugih fakulteta, uvodi se dopunski razred specijalitet, s atributima soba(specijalitet), titula(specijalitet ), fakultetčiji tipovi nisu specificirani u ovom modelu, iako se mogu odrediti putem nabrajanja.

Razred disciplina ima atribute: soba, titula, ciklus. Atribut ciklus pomoću specijalizirane vrste uvedene kroz nabrajanje T_ciklusi utvrđ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, više ih ne možete naznačiti u razredu specijalitet... Ovi atributi se odnose na par specijalnost-disciplina i definirani su u razredu - asocijaciji Discipline-specijalnosti.

Riža. 3. Dijagram razreda AWP-a tajnika odjela (opcija 1)

Prilikom renderiranja strukture klase obratite 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 smjele opisivati), stoga je, radi lakšeg čitanja dijagrama, poželjno potisnuti operacije.

Na uvedenom skupu klasa potrebno je redefinirati poveznice. Veze generalizacije i ovisnosti su već određene, ostaje da se definiraju asocijacije.

Studenti formirana u skupina, u ovom slučaju asocijacija će biti u obliku združivanja. Agregacija pretpostavlja odnos dio-cjelina, označen punom linijom s rombom na kraju s cijele strane (u našem slučaju skupina). Mnoštvo odnosa više-na-jedan student-grupa. Svaki skupina odnosi se na određenu specijalitet, pak, određenoj specijalnosti može odgovarati nekoliko skupina, stoga i grupno-specijalistička udruga ima tip višestrukosti "mnogo prema jednom".

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

Definirajmo povezanost između učitelji i podučavao discipline kao "mnogo-na-više": učitelj može predavati nekoliko disciplina, neke discipline može predavati više učitelja. Između discipline i specijaliteti osniva se i udruga "mnogi-na-mnogi": nastavni plan i program specijalnosti sadrži mnoge discipline, većina disciplina nalazi se u planovima rada nekoliko specijalnosti. Razred asocijacija je pridružen ovoj udruzi. 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 u grupama i učitelji: Učitelji podučavaju u grupama, tipa više prema više. Izravna povezanost između u grupama i disciplins ne trebate definirati, budući da se ovaj odnos prati kroz klasu veziva specijalitet.

Za prikaz prisutnosti mentora za studenta diplomskog studija potrebno je uvesti asocijaciju između diplomiranog studenta i nastavnika tipa "mnogo prema jednom", jedan mentor može imati više diplomiranih studenata. Na ovoj asocijaciji od strane učitelja možete eksplicitno naznačiti ulogu: nadglednik.

Riža. 4. Dijagram nastave AWP-a tajnika odjela (opcija 2)

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

Studenti poslijediplomskog studija također može podučavati određene discipline određenim skupinama: udrugama mnogo prema mnogo poslijediplomske grupe, poslijediplomske discipline. Neki diplomirani studenti možda neće predavati, 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 izvode i studenti diplomskog studija i nastavnici, može se uvesti i dodatni apstraktni sat, npr. nastava koji je potomak klase osoba i superklasa za razrede učitelj, nastavnik, profesor i postdiplomac, što će malo smanjiti broj priključaka. (slika 4.). U ovom slučaju, iz razreda disciplina i skupina udruge će ići na nastavu nastava, uz pretpostavku poveznice s klasama učitelj, nastavnik, profesor i postdiplomac putem nasljeđivanja (odnos generalizacije). U razred nastava možete izvaditi atribute ponuda(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 dovršetka: još je potrebno definirati neke uslužne klase i sučelja. Kako bismo rasteretili dijagram klasa, izgradit ćemo novi pogled na njega (na zasebnom dijagramu), ostavljajući sliku glavnih klasa i potiskivajući prikaz pomoćnih koji određuju vrste atributa (slika 5.).

Na sl. 5, uz glavne klase koje odgovaraju konceptualnim elementima sustava, prikazana je i klasa T_ ADR, otkrivajući strukturu adrese, ova klasa je također važna, budući da 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; samo definira specifikacije operacija (signature), ali nikada njihovu provedbu. 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 komponenti. Sučelje uvijek pretpostavlja postojanje neke vrste "ugovora" između strane koja deklarira izvršenje niza operacija i strane koja te operacije provodi.

Postavite razred na dijagram elektroničkistol, koji sadrži sva svojstva i operacije proračunske tablice koja vam omogućuje uređivanje podataka. Nećemo otkrivati ​​strukturu ove klase zbog njene velike složenosti. Dakle, u modernim alatima za razvoj aplikacija korisnik koristi gotove klase i predloške, nasljeđujući njihove sposobnosti, na primjer, VCL biblioteka (Delphi) sadrži klasu TTable koja sadrži mogućnosti proračunske tablice. Potomci klase elektroničkistol su posebne proračunske tablice koje sadrže specifične podatke za nastavnike, diplomske studente, studente, grupe, discipline i specijalnosti. Pretvaranjem odgovarajućih klasa kao potomaka 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). U ovom slučaju pretpostavlja se da u razredu elektroničkistol te su mogućnosti implementirane.

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

Definirajmo sučelja tražiučitelj, nastavnik, profesor, tražidiscipline pridružujući ih odgovarajućim klasama implementacijskim odnosom. Sastav operacija ovih sučelja nećemo otkrivati ​​(prilično je trivijalan), stoga ćemo sučelja prikazati u skraćenom obliku (u obliku kruga). Podsjetimo da se implementacijski odnos pridružen sučelju u skraćenom obliku prikazuje kao jednostavna puna crta (kao asocijacija).

Sučelje tražistudent prikazat će se s naznakom popisa operacija kroz stereotipnu klasu, dok je implementacijski odnos prikazan isprekidanom strelicom 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. Radi lakše percepcije, ti mehanizmi nisu vizualizirani.

Za upravljanje pravima pristupa i autorizacijom korisnika uvodimo klasu menadžerpristup... Upravitelj pristupa ima atribut privatne vrste pristupa stollozinke koji je instanca klase CodirTable(Kodirana tablica) koja sadrži lozinke ( zaporka) i nazive unosa ( prijaviti se) administratorskih korisnika. Pretpostavlja se da su sposobnosti klase usluge CodirTable ne dopuštajte neovlaštenom korisniku čitanje korisničkih lozinki. 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 ostvaruje autorizacija i upravljanje pravima pristupa.

Naznačimo 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 dijagram nastave AWP-a tajnika odjela

Konačni dijagram prikazan je na sl. 6.

Dakle, u ovoj se fazi razvoj objektno orijentiranog modela radne stanice tajnika odjela pomoću UML dijagrama klasa može smatrati dovršenim. Naravno, moguće je vratiti se na njega i revidirati neke elemente tijekom projektiranja sustava, pri podešavanju zadataka, prilikom specificiranja pojedinačnih detalja. Proces projektiranja informacijskog 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 javnoj operaciji klase, ili skupu javnih operacija (u ovom slučaju, slučaj korištenja implementira izravno odgovarajuća klasa ili skup klasa).

Pogledajmo proces stvaranja novog zapisa učenika pomoću dijagrama sekvence.

Izrada novog zapisa pretpostavlja administratorska prava, tako da će administrator biti protagonist ove interakcije ( admin). Ovaj je element već unesen u dijagram slučaja upotrebe, pa ga povucite na dijagram slijeda iz preglednika za prikaz slučaja upotrebe.

Treba napomenuti da se objekti pojavljuju u dijagramima interakcije, odnosno konkretnim instancama 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 koji je tipična forma za unos podataka o učeniku (prezime, ime, prezime, adresa i sl.). U našem slučaju radi se o nešto proširenoj 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 klasa čija je instanca eksplicitno je naznačena - studentima.

Petrov- specifičan zapis o učeniku Petrovu, novi element tablice o studentima. Ovdje izričito označavamo uvedenu klasu snimanjeOstudent... Takvi objekti obično postoje privremeno za slanje relevantnih informacija 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 podatke.

Menadžertransakcije- objekt koji osigurava izvršenje dovršene operacije nad bazom podataka, u ovom slučaju stvaranje novog zapisa o učeniku Petrovu. Ovaj objekt je također odgovoran za izvođenje 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 za unos novog zapisa o studentu u AWS tajnika odjela prikazan je na sl. 7.

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

U dijagramu sekvence definiramo prijenos poruka između objekata: stvoritinovisnimanje(emituje se od objekta do objekta do kraja lanca kao poruka uštedjetisnimanje); otvorenaoblik(u obrazac za unos); uvestiF.I O.,adresa. ( unos podataka učenika), tada se ti podaci emitiraju porukama uštedjetiF.I O.,adresa. Iz menadžertransakcije poslati poruku prikupiti informacijaOstudent pružanje povratne informacije bazi podataka i konačno refleksivnu poruku menadžertransakcije imenovan kao uštedjetisnimanjevDB, 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 slučajeva korištenja.

4.3 Razvijanje profila relacijske baze podataka

U slučaju da se za implementaciju sustava koristi objektno orijentirani DBMS (OODBMS), objektni dijagram konstruiran 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 proširenje koje održava UML metamodel netaknutim. Profil za projekt baze podataka dodaje stereotipe i označene vrijednosti dodane tim stereotipima, ali ne mijenja temeljni UML metamodel. Za vizualizaciju dizajniranih elemenata baze podataka i pravila dizajna za relacijske baze podataka, u profil su dodane odgovarajuće ikone (u daljnjem tekstu jednostavno baze podataka). Baza podataka je opisana pomoću tablica, stupaca i relacija. Profil sadrži 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 koristiti sve te elemente u modelu. Sljedeći entiteti definirani su na UML profilu baze podataka:

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č) - 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 ( View) je virtualna tablica koja se s korisničke točke gledišta ponaša baš kao obična tablica, ali ne postoji sama za sebe.

Pohranjeno postupak ( Pohranjena procedura) je neovisna proceduralna funkcija koja se izvršava 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čkih resursa.

seminarski rad, dodan 28.05.2009


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

prezentacija dodana 14.10.2013


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

prezentacija dodana 02.04.2013


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

seminarski rad dodan 17.06.2003


Koncept CASE-alata kao softverskih alata koji podržavaju stvaranje i održavanje informacijskih sustava (IS). Značajke IDEF-tehnologije razvoja IS-a. Opis IDEF0 notacije. Razvoj funkcionalnih modela poslovnog procesa.

prezentacija dodana 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 obrazovni proces. Implementacija zadanog informacijskog sustava.

rad, dodan 17.02.2015


Razvoj informacijskih sustava. Suvremeno tržište financijskog i ekonomskog primijenjenog softvera. Prednosti i nedostaci implementacije 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 oblika grafičkog sučelja i baza podataka.

rad, dodan 23.06.2015


Rješenje za informacijsku sigurnost. Sustavi za podatkovne centre. Što je hardver podatkovnog centra. Osnovni pojmovi i principi modeliranja. Izbor metode za rješavanje problema. Zoitendijkova metoda dopuštenih pravaca, Frank – Wolfe 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.

"Računalno matematičko modeliranje" Ciljevi proučavanja odjeljka. Ovladavanje modeliranjem kao metodom spoznavanja okolne stvarnosti (znanstvenoistraživačka priroda sekcije) - pokazuje se da modeliranje u različitim područjima znanja ima slične značajke, često je za različite procese moguće dobiti vrlo slične modele; - pokazuje prednosti i nedostatke računalnog pokusa u usporedbi s pokusom punog opsega; - pokazuje se da i apstraktni model i računalo pružaju mogućnost spoznavanja okolnog svijeta, 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 provode se praktički sve faze modeliranja, od formulacije problema do interpretacije rezultata dobivenih tijekom računalnog eksperimenta. Promicanje profesionalnog usmjeravanja učenika. Razotkrivanje studentskih sklonosti za istraživačku djelatnost, razvoj kreativnih potencijala, usmjerenost na izbor zanimanja vezanog za znanstveno-istraživački rad. Prevladavanje predmetne disocijacije, integracija znanja. Kolegij ispituje modele iz različitih područja znanosti korištenjem matematike. Razvoj i profesionalizacija rada na računalu. Ovladavanje softverom opće i specijalizirane namjene, programskim sustavima.

Koncept modela ključan je 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 izvedivost raspoloživih sredstava.
U teoriji učinkovitosti i informatici, model objekta (sustava, operacije) je materijalni ili idealni (mentalno zamisliv) sustav koji je stvoren i/ili korišten u rješavanju određenog problema kako bi se dobila nova saznanja o izvornom objektu, adekvatna za ona je u pogledu proučavanih svojstava i jednostavnija od originala u ostalim aspektima.
Klasifikacija glavnih metoda modeliranja (i njihovih odgovarajućih modela) prikazana je na Sl. 3.1.1.
U proučavanju ekonomskih informacijskih sustava (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, značajka) znanost o općim svojstvima znakovnih sustava, odnosno sustava konkretnih ili apstraktnih objekata (znakova), sa svakim od kojih je povezano određeno značenje. 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 proučava sintaksu znakovnih sustava bez obzira na bilo kakva tumačenja i probleme povezane s percepcijom znakovnih sustava kao sredstava komunikacije i komunikacije.
Semantika proučava interpretaciju iskaza znakovnog sustava i, sa stajališta modeliranja objekata, zauzima glavno mjesto u semiotici.
Pragmatika ispituje odnos osobe koja koristi znakovni sustav prema samom znakovnom sustavu, posebice - percepciju smislenih izraza znakovnog sustava.
Od brojnih semiotičkih modela, zbog najveće rasprostranjenosti, posebice u kontekstu informatizacije suvremenog društva i uvođenja formalnih metoda u sve sfere ljudskog djelovanja, izdvojit ćemo one matematičke koji odražavaju stvarne sustave pomoću matematičkih simbola. Istovremeno, 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, teorijom 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 primjene metode simulacije
2. Odjeljak III OSNOVE ZA MODELIRANJE SUSTAVA MARKETINGA USLUGA
3. POGLAVLJE 1. UPRAVLJANI DINAMIČKI SUSTAVI KAO OBJEKAT RAČUNALNE SIMULACIJE
4. Osnove strukturnog modeliranja marketinškog sustava medicinskih usluga
5. Odjeljak IV. PRIMJER PRIMIJENJENE UPOTREBE MODELA MARKETINŠKOG SUSTAVA U IMITACIONOM MODELIRANJU
6. Koncept modeliranja financijske sfere marketinških sustava