Zadaci i funkcije informacijskog sustava.

IS može riješiti dvije skupine problema. Prva skupina odnosi se na isključivo informacijsku potporu glavne djelatnosti (odabir potrebnih poruka, njihova obrada, pohrana, pretraživanje i izdavanje subjektu glavne djelatnosti s unaprijed određenom potpunošću, točnošću i učinkovitošću u najprikladnijem obliku) . Druga skupina zadataka odnosi se na obradu primljenih informacija/podataka u skladu s određenim algoritmima radi pripreme rješenja za probleme s kojima se susreće predmet osnovne djelatnosti. Za rješavanje takvih problema IS mora imati potrebne informacije o predmetnom području. Da bi riješio takve probleme, IS mora imati određenu umjetnu ili prirodnu inteligenciju. Informacijski sustav - sustav za podršku i automatizaciju intelektualnog rada - pretraživanje, administracija, ispitivanja i stručne ocjene ili prosudbe, odlučivanje, upravljanje, prepoznavanje, akumulacija znanja, usavršavanje. Zadaci prve skupine su zadaci informatizacije društva "u širinu".

Zadaci druge skupine - zadaci informatizacije

društvo "dublje".

Za rješavanje postavljenih zadataka IS bi trebao obavljati sljedeće funkcije:

 odabir poruka iz unutarnjeg i vanjskog okruženja potrebnih za provedbu glavne djelatnosti;

 unos informacija u IS;

 pohranjivanje informacija u memoriju IS-a, njihovo ažuriranje i održavanje integriteta;

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

Informacijski sustav (IS) - međusobno povezani skup alata, metoda i osoblja koji se koriste za pohranu, obradu i izdavanje informacija u svrhu postizanja cilja. Suvremeno shvaćanje informacijskog sustava podrazumijeva korištenje osobnog računala kao glavnog tehničkog sredstva za obradu informacija. IS je okruženje čiji su sastavni elementi računala, računalne mreže, softverski proizvodi, baze podataka, ljudi, razne vrste tehničkih i softverskih komunikacija itd. Iako je sama ideja IS-a i nekih principa njihove organizacije nastala mnogo prije pojave računala, informatizacija je povećala učinkovitost IS-a za desetke i stotine puta i proširila opseg njihove primjene.

Funkcionalna struktura informacijskog sustava.

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

Podsustav odabira informacija. Informacijski sustav može obraditi/obraditi samo informacije koje su u njega unesene. Kvalitetu rada IS-a određuje ne samo njegova sposobnost da pronađe i obradi potrebne informacije u vlastitom nizu i da ih korisniku, već i sposobnost odabira relevantnih informacija iz vanjskog okruženja. Takvu selekciju provodi podsustav odabira informacija koji akumulira podatke o informacijskim potrebama korisnika IS-a (internih i eksternih), analizira i raspoređuje te podatke, formirajući informacijski profil IS-a.

Podsustav za unos, obradu/obradu i pohranu informacija pretvara ulazne informacije i zahtjeve, organizira njihovu pohranu i obradu kako bi se zadovoljile informacijske potrebe pretplatnika IS-a.

Implementacija funkcija ovog podsustava podrazumijeva postojanje aparata za opisivanje informacija (sustavi kodiranja, jezik opisa podataka (DDL) itd.), organiziranje i održavanje informacija (logička i fizička organizacija, postupci za održavanje i zaštitu informacija, itd.). itd.), aparat za obradu i obradu informacija (algoritmi, modeli itd.).

Podsustav za pripremu i izdavanje informacija izravno provodi zadovoljenje informacijskih potreba korisnika IS-a (internih i eksternih). Za ostvarenje ovog zadatka podsustav provodi proučavanje i analizu informacijskih potreba, utvrđuje oblike i metode njihovog zadovoljenja, optimalan sastav i strukturu izlaznih informacijskih proizvoda te organizira proces informacijske podrške i održavanja.

Za izvođenje ovih funkcija potrebna je prisutnost uređaja za opisivanje i analizu informacijskih potreba i njihovog izražavanja u IS jeziku (uključujući DDL, IEL, jezik indeksiranja itd.), kao i uređaja za izravnu informacijsku podršku (postupci pretraživanja i izdavanje informacija, jezika za manipuliranje podacima itd.). Mnoge funkcije IS podsustava su duplicirane ili presijecane, što je predmet optimizacije u dizajnu IS-a. U tom smislu, automatizaciju IS-a prati preraspodjela elemenata IS-a.

Automatizacija uključuje formalizirani prikaz (strukturiranje) kako funkcija IS-a, tako i samih informacija obrađenih u IS-u, što vam omogućuje unos, obradu/obradu, pohranu i pretraživanje informacija pomoću računala. Svaka formalizacija karakterizira jedna ili ona razina adekvatnosti stvorene slike stvarnosti (modela) same stvarnosti. Štoviše, primjerenost modela stvarnosti određena je i svojstvima same stvarnosti i sposobnostima aparata koji se koristi za njezino formalizirano predstavljanje.

S ove točke gledišta, "razina automatizacije" IS-a usko je povezana sa "stupanjom strukturiranosti" informacija. Postoje tri razine strukturiranosti informacija: Rigidno strukturirana informacija (podaci) - informacija čija formalizirana reprezentacija suvremenim sredstvima njenog strukturiranja (posebno jezicima opisa podataka) ne dovodi do gubitka adekvatnosti informacijskog modela. sama izvorna informacija.

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

Nestrukturirane informacije su informacije za koje trenutno ne postoje načini za njihovo formalizirano predstavljanje s prihvatljivom razinom primjerenosti u praksi. Sredstva prezentiranja takvih informacija trebaju imati visoke semantičke i izražajne sposobnosti. Razvoj takvih alata trenutno ide na liniji stvaranja jezika za opis znanja i IEL-a velike semantičke snage.

Metodologije izgradnje informacijskih sustava.

Industrija razvoja automatiziranih sustava za upravljanje informacijama nastala je 1950-ih i 1960-ih godina i do kraja stoljeća dobila potpuno dovršene oblike.

U prvoj fazi, glavni pristup u dizajnu IS-a bila je metoda "odozdo prema gore", kada je sustav kreiran kao skup aplikacija koje su u ovom trenutku najvažnije za podršku aktivnostima poduzeća. Ovaj pristup se donekle nastavlja i danas. U okviru “patchwork automatizacije” podrška za pojedine funkcije je dosta dobro osigurana, ali gotovo da ne postoji strategija razvoja integriranog sustava automatizacije.

Sljedeća faza povezana je s spoznajom da postoji potreba za prilično standardnim softverskim alatima za automatizaciju aktivnosti različitih institucija i poduzeća. Od cijelog niza problema, programeri su identificirali najuočljivije: automatizaciju računovodstvenih analitičkih računovodstvenih i tehnoloških procesa. Sustavi su se počeli projektirati "odozgo prema dolje", t.j. uz pretpostavku da jedan program treba zadovoljiti potrebe velikog broja korisnika.

Sama ideja korištenja univerzalnog programa nameće značajna ograničenja sposobnosti programera da formiraju strukturu baze podataka, zaslonske obrasce i odaberu algoritme za izračun. Kruti okvir postavljen "odozgo" ne omogućuje fleksibilnu prilagodbu sustava specifičnostima djelatnosti pojedinog poduzeća, pa se materijalni i vremenski troškovi implementacije sustava i finog prilagođavanja zahtjevima kupac obično značajno premašuje planirane brojke.

Prema statistikama koje je prikupila Standish Group (SSL), od 8.380 projekata ispitanih u SSL-u 1994. godine, više od 30% projekata bilo je neuspješno, ukupne vrijednosti preko 80 milijardi dolara. Pritom je samo 16% od ukupnog broja projekata završeno na vrijeme, a prekoračenja troškova iznosila su 189% planiranog proračuna.

Istodobno, korisnici IS-a počeli su postavljati sve više zahtjeva usmjerenih na omogućavanje integrirane upotrebe korporativnih podataka u upravljanju i planiranju njihovih aktivnosti. Stoga je postojala hitna potreba za formiranjem nove metodologije za izgradnju informacijskih sustava.

Prema suvremenoj metodologiji, proces stvaranja IS-a je proces izgradnje i uzastopne transformacije niza konzistentnih modela u svim fazama životnog ciklusa (LC) IS-a. U svakoj fazi životnog ciklusa za njega se stvaraju specifični modeli - organizacije, zahtjevi za

JE. IS projekt. zahtjevi za prijavu itd. Obično se razlikuju sljedeće faze stvaranja IS-a: formiranje zahtjeva sustava, projektiranje, implementacija, testiranje, puštanje u rad, rad i održavanje.

Početna faza procesa stvaranja IS-a je modeliranje poslovnih procesa koji se odvijaju u organizaciji i ostvaruju njezine ciljeve. Organizacijski model, opisan u smislu poslovnih procesa poslovnih funkcija, omogućuje nam da formuliramo osnovne zahtjeve za IS.

Dizajn IS-a temelji se na modeliranju domene. Za dobivanje IP projekta primjerenog predmetnom području u obliku sustava ispravno funkcionirajućih programa, potrebno je imati holistički, sustavni prikaz modela koji odražava sve aspekte funkcioniranja budućeg informacijskog sustava. Pritom se pod modelom domene podrazumijeva neki sustav koji oponaša strukturu ili funkcioniranje predmetne domene koja se proučava te ispunjava glavni uvjet – da bude adekvatan ovoj domeni.

Preliminarno modeliranje predmetnog područja omogućuje vam da smanjite vrijeme i vrijeme projektiranja i dobijete učinkovitiji i kvalitetniji projekt. Bez modeliranja domene velika je vjerojatnost velikog broja pogrešaka u rješavanju strateških pitanja, što dovodi do ekonomskih gubitaka i visokih troškova naknadnog redizajniranja sustava. Kao rezultat toga, sve moderne tehnologije dizajna IS-a temelje se na korištenju metodologije domenskog modeliranja.

Modelima domene nameću se sljedeći zahtjevi:

Formalizacija koja daje nedvosmislen opis strukture predmetnog područja;

Jasnoća za kupce i programere temeljena na korištenju grafičkih sredstava za prikaz modela;

Realizabilnost, što podrazumijeva dostupnost sredstava fizičke implementacije modela domene i IS-a;

Davanje procjene učinkovitosti implementacije modela domene na temelju određenih metoda i izračunatih pokazatelja.

Funkcionalno modeliranje IDEF0: osnovne definicije i odredbe.

Program integrirane informatizacije proizvodnje ICAM (ICAM - Integrated Computer Aided Manufacturing) usmjeren je na povećanje učinkovitosti industrijskih poduzeća kroz široko uvođenje računalnih (informacijskih) tehnologija. U Sjedinjenim Državama ta je okolnost prepoznata još kasnih 70-ih, kada je američko ratno zrakoplovstvo predložilo i implementiralo

IDEF metodologija (ICAM Definicija) omogućuje istraživanje strukture, parametara i karakteristika proizvodno-tehničkih i organizacijsko-ekonomskih sustava (u daljnjem tekstu, gdje ne uzrokuje nesporazum - sustavi). Opća IDEF metodologija sastoji se od tri posebne metodologije modeliranja temeljene na grafičkom prikazu sustava:

IDEF0 se koristi za stvaranje funkcionalnog modela koji prikazuje strukturu i funkcije sustava, kao i tokove informacija i materijalnih objekata koji povezuju te funkcije.

IDEF1 se koristi za izgradnju informacijskog modela koji prikazuje strukturu i sadržaj tokova informacija potrebnih za podršku funkcijama sustava;

IDEF2 vam omogućuje izgradnju dinamičkog modela vremenski promjenjivog ponašanja funkcija sustava, informacija i resursa.

Do danas su najraširenije i korištene metodologije IDEF0 i IDEF1 (IDEF1X), koje su dobile status federalnih standarda u Sjedinjenim Državama. Metodologija IDEF0, čije su značajke i metode primjene opisane u ovom Vodiču (GD), temelji se na pristupu koji je razvio Douglas T. Ross ranih 70-ih i nazvan SADT (Structured Analysis & Design Technique – metoda za konstrukcijska analiza i projektiranje). Osnova pristupa i kao rezultat IDEF0 metodologije je grafički jezik za opisivanje (simulacijskih) sustava koji ima sljedeća svojstva.

Za ispravan prikaz interakcija komponenti IS-a važno je provesti zajedničko modeliranje takvih komponenti, posebno sa sadržajnog stajališta objekata i funkcija.

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

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

Definirajmo ključne pojmove strukturne analize djelatnosti poduzeća (organizacije).

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

Funkcija - skup operacija grupiranih prema određenom atributu.

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

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

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

Poslovni model je grafički strukturirani opis mreže procesa i operacija povezanih s podacima, dokumentima, organizacijskim jedinicama i drugim objektima koji odražavaju postojeće ili predložene aktivnosti poduzeća. Postoje različite metodologije za strukturno modeliranje predmetnog područja, među kojima je potrebno izdvojiti funkcionalno orijentirane i objektno orijentirane metodologije.

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

Metodologija IDEF0 propisuje izgradnju hijerarhijskog sustava dijagrama – pojedinačnih opisa fragmenata sustava. Prvo se provodi opis sustava u cjelini i njegove interakcije s vanjskim svijetom (kontekst dijagram), nakon čega se provodi funkcionalna dekompozicija - sustav se dijeli na podsustave i svaki podsustav se opisuje zasebno (dekompozicijski dijagrami) . Zatim se svaki podsustav razlaže na manje, i tako sve dok se ne postigne potreban stupanj detalja.

BPwin alatno okruženje.

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

BPwin podržava tri metodologije modeliranja: funkcionalno modeliranje (IDEF0); opis poslovnih procesa (IDEF3); dijagrami toka podataka (DFD). BPwin ima prilično jednostavno i intuitivno korisničko sučelje. Kada pokrenete BPwin, prema zadanim postavkama pojavljuje se glavna alatna traka, paleta alata (čiji izgled ovisi o odabranoj notaciji) i, s lijeve strane, navigator modela - Model Explorer).

Prilikom izrade novog modela pojavljuje se dijaloški okvir u kojem trebate odrediti hoće li se model ponovno kreirati ili će se otvoriti iz datoteke ili iz ModelMart repozitorija, zatim upisati naziv modela i odabrati metodologiju u kojoj se model će biti izgrađen.

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

Model se u BPwinu promatra kao skup aktivnosti, od kojih svaka djeluje na nekom skupu podataka. Rad je prikazan kao pravokutnici, podaci kao strelice. Ako lijevom tipkom miša kliknete na bilo koji objekt modela, pojavljuje se kontekstni izbornik čija svaka stavka odgovara uređivaču nekog svojstva objekta.

U početnim fazama stvaranja IS-a potrebno je razumjeti kako funkcionira organizacija koja će se automatizirati. Menadžer općenito dobro poznaje posao, ali nije u stanju proniknuti u detalje rada svakog običnog zaposlenika. Običan zaposlenik dobro zna što se događa na njegovom radnom mjestu, ali možda ne zna kako rade njegove kolege. Stoga je za opisivanje rada poduzeća potrebno izgraditi model koji će biti adekvatan predmetnom području i sadržavati znanja svih sudionika u poslovnim procesima organizacije.

Najprikladniji jezik za modeliranje poslovnih procesa je IDEF0, gdje je sustav predstavljen kao skup interakcijskih aktivnosti ili funkcija. Takva čisto funkcionalna orijentacija je temeljna – funkcije sustava analiziraju se neovisno o objektima na kojima rade. To vam omogućuje jasnije modeliranje logike i interakcije procesa organizacije.

Proces modeliranja sustava u IDEF0 počinje izradom kontekstnog dijagrama - dijagrama najapstraktnije razine opisivanja sustava kao cjeline, koji sadrži definiciju predmeta modeliranja, svrhe i gledišta na model.

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

Stavke su prikazane kao pravokutnici. Svi radovi moraju biti imenovani i identificirani. Naziv posla mora biti glagolska imenica koja označava radnju (na primjer, "Aktivnosti tvrtke", "Primanje narudžbe" itd.). Djelo "Aktivnosti poduzeća" moglo bi imati, na primjer, sljedeću definiciju: "Ovo je model tutoriala koji opisuje aktivnosti poduzeća." Prilikom izrade novog modela (izbornik Datoteka/Novi), automatski se kreira kontekstni dijagram s jednim poslom koji prikazuje sustav kao cjelinu.

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

"Računalno matematičko modeliranje" Problemi proučavanja odjeljka. Ovladavanje modeliranjem kao metodom spoznaje okolne stvarnosti (istraživačka priroda odjeljka) - pokazuje se da modeliranje u različitim područjima znanja ima slične značajke, često je moguće dobiti vrlo slične modele za različite 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.

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 "Odgojno-obrazovni proces" Svrha informacijskog sustava: informirati korisnike: O učeničkom sastavu odjeljenja O nastavnom osoblju škole O raspodjeli nastavnog opterećenja i vođenju razreda O napretku 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 "Potražite 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 Problem planiranja rada servisa Izjava 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. Sustav nejednakosti proizlazi iz stavaka problema.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.
Sintaksa 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 uporaba se 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 ekspresivno i prilično jednostavno izradu preliminarnog konceptualnog razvoja informacijskog sustava, a ujedno, metodički prate cijeli proces razvoja, 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 tablice relacijske 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 su bolje opisani 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. Neizravne metode 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 za IKT OmSTU, omogućio fleksibilnost u rješavanju planiranih i neplaniranih specifičnih zadataka obrade vjerodajnica.

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 slijeda 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, promijenitipodaci.

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,PRIJEONIPORDO 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 razredu 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 Datum odpriznanice. 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 smjele opisivati), stoga je, da bi se olakšala percepcija 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 i u 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-mnogih: 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, uz glavne klase 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 komponenti. 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čkastol, koji obuhvata 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čkastol 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čkastol, 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čkastol, 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čkastol ove značajke su implementirane.

Korištenje posebne klase elektroničkastol 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 upotrebe implementira izravno odgovarajuća klasa ili skup klasa).

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

Stvaranje novog zapisa zahtijeva administratorska prava, tako da će akter u ovoj interakciji biti administrator ( 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čkastol. 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čkastol. 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 ulazakokostudent. 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 omogućuje 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 informacijaokostudent, pružajući povratnu informaciju bazi podataka i konačno refleksivnu poruku menadžertransakcije imenovan kao uštedjetiulazakuDB, 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.