Koncept modelu je kľúčový vo všeobecnej teórii systémov. Modelovanie ako výkonná – a často jediná – výskumná metóda predpokladá nahradenie skutočného objektu iným – materiálnym alebo ideálnym.
Najdôležitejšími požiadavkami na akýkoľvek model je jeho primeranosť k skúmanému objektu v rámci konkrétnej úlohy a realizovateľnosť dostupných prostriedkov.
V teórii efektívnosti a informatike je model objektu (systému, operácie) materiálny alebo ideálny (mentálne predstaviteľný) systém vytvorený a/alebo použitý pri riešení konkrétneho problému s cieľom získať nové poznatky o pôvodnom objekte, adekvátne je z hľadiska študovaných vlastností a v iných ohľadoch jednoduchší ako originál.
Klasifikácia hlavných metód modelovania (a im zodpovedajúcich modelov) je znázornená na obr. 3.1.1.
Pri štúdiu ekonomických informačných systémov (EIS) sa využívajú všetky metódy modelovania, avšak táto časť sa zameria na semiotické (znakové) metódy.
Pripomeňme si, že semiotika (z gréckeho semeion - znak, znak) je veda o všeobecných vlastnostiach znakových systémov, teda systémov konkrétnych alebo abstraktných predmetov (znakov), s každým z nich je spojený určitý význam. Príkladmi takýchto systémov sú akékoľvek jazyky

Ryža. 3.1.1. Klasifikácia metód modelovania

(prirodzené alebo umelé, napr. popis údajov alebo modelovacie jazyky), signalizačné systémy v spoločnosti a vo svete zvierat atď.
Semiotika zahŕňa tri sekcie: syntaktika; sémantika; pragmatika.
Syntaktika študuje syntax znakových systémov bez ohľadu na akékoľvek interpretácie a problémy spojené s vnímaním znakových systémov ako prostriedkov komunikácie a komunikácie.
Sémantika študuje interpretáciu výrokov znakového systému a z hľadiska modelovania objektov zaujíma hlavné miesto v semiotike.
Pragmatika skúma postoj človeka používajúceho znakový systém k samotnému znakovému systému, najmä vnímanie zmysluplných prejavov znakového systému.
Z množstva semiotických modelov z dôvodu najväčšieho rozšírenia, najmä v kontexte informatizácie modernej spoločnosti a zavádzania formálnych metód do všetkých sfér ľudskej činnosti, vyčleníme matematické, ktoré odrážajú reálne systémy využívajúce matematické symboly. Zároveň, berúc do úvahy skutočnosť, že uvažujeme o metódach modelovania vo vzťahu k štúdiu systémov v rôznych operáciách, využijeme známu metodológiu systémovej analýzy, teóriu efektívnosti a rozhodovania.

Viac k téme 3. TECHNOLÓGIA SIMULÁCIE INFORMAČNÝCH SYSTÉMOV Metódy modelovania systémov:

1. Simulačné modely ekonomických informačných systémov Metodické základy aplikácie metódy simulácie
2. Časť III ZÁKLADY PRE MODELOVANIE SYSTÉMU MARKETINGU SLUŽBY
3. KAPITOLA 1. RIADENÉ DYNAMICKÉ SYSTÉMY AKO OBJEKT POČÍTAČOVEJ SIMULÁCIE
4. Základy štrukturálneho modelovania marketingového systému zdravotníckych služieb
5. Časť IV PRÍKLAD APLIKOVANÉHO POUŽITIA MODELU MARKETINGOVÉHO SYSTÉMU V IMITAČNOM MODELOVANÍ
6. Koncept modelovania finančnej sféry marketingových systémov

1 z 38

Prezentácia na tému: Modelovanie informačných systémov

Snímka č.1

Snímka č.2

Popis snímky:

Účelom kurzu je prehĺbenie základných predmetov (informatika, matematika); formovanie kompetencií pre odborné činnosti v oblasti informačného modelovania.Motivácia študentov pri výbere ES. - testovanie schopností a záujmu študentov o tvorivú, výskumnú činnosť v oblasti informačného modelovania; - príprava na vstup na vysokú školu pre odbory súvisiace s informačným modelovaním a počítačovými technológiami: aplikovaná matematika, modelovanie, výpočtové systémy atď.

Snímka č.3

Popis snímky:

Snímka č.4

Popis snímky:

Obsah učebnice Kapitola 1. Modelovanie informačných systémov 1.1. Informačné systémy a systemológia 1.2. Relačný model a databázy (Prístup) 1.3. Tabuľkový kalkulátor – Nástroj na modelovanie informácií 1.4. Programovanie aplikácií (prvky VBA pre Excel) Kapitola 2. Počítačové matematické modelovanie 2.1. Úvod do modelovania 2.2. Sada nástrojov pre počítačové matematické modelovanie (Excel, MathCad, VBA, Pascal) 2.3. Optimálne modelovanie procesov plánovania 2.4. Počítačové simulačné aplikácie

Snímka č.5

Popis snímky:

"Modelovanie a rozvoj informačných systémov" Ciele štúdia sekcie Všeobecný vývoj a formovanie svetonázoru študentov. Hlavnou ideologickou zložkou obsahu tejto časti kurzu je formovanie systematického prístupu k analýze okolitej reality. Osvojenie si základov metodológie budovania informačných referenčných systémov. Študenti pochopia etapy vývoja informačného systému: etapu návrhu a etapu implementácie. Tvorba multitabuľkovej databázy prebieha v prostredí relačnej DBMS MS Access. Študenti ovládajú techniky budovania databázy, aplikácií (dotazy, reporty), prvkov rozhrania (dialógové okná). Rozvoj a profesionalizácia počítačových zručností. Zručnosti získané v základnom kurze sa ďalej rozvíjajú. - práca s vektorovou grafikou pri budovaní štruktúrnych modelov systémov - hĺbkové štúdium možností MS Access DBMS - používanie MS Excel ako prostriedku na prácu s databázou - programovanie vo VBA v prostredí Excel pre vývoj rozhrania - pri práci pri abstraktoch sa odporúča použiť internetové zdroje; pripraviť materiál na ochranu formou prezentácie (Power Point)

Snímka č.6

Popis snímky:

Metóda projektového vyučovania Problematika: Vecný okruh: stredná škola Cieľ projektu: vytvorenie informačného systému "Vzdelávací proces" Účel informačného systému: informovať používateľov: O žiackom zbore tried O pedagogickom zbore školy O rozložení výučby zaťaženie a vedenie triedy O pokroku žiaka

Snímka č.7

Popis snímky:

Snímka č.8

Popis snímky:

Snímka č.9

Popis snímky:

Snímka č.10

Popis snímky:

Snímka č.11

Popis snímky:

Snímka č.12

Popis snímky:

Vývoj aplikácií Aplikácie: dotazy, zostavy Úloha. Je potrebné získať zoznam všetkých dievčat v deviatom ročníku, ktoré majú A z informatiky. Koncept podschémy využívajúci hypotetický výber jazyka dopytovania ŠTUDENTOV PRIEZVISKO ŠTUDENTOV MENO ŠTUDENTOV TRIEDA ŠTUDENTOV TRIEDA = 9? zoradiť ŠTUDENTI. PRIEZVISKO vzostupne

Snímka č.13

Popis snímky:

Snímka č.14

Popis snímky:

Snímka č.15

Popis snímky:

Programovanie VBA Private Sub CommandButton1_Click () "Popis premenných Dim i, j, n As Integer Dim Flag As Boolean" Inicializácia dát Flag = False "Určuje počet riadkov v zozname škôl n = Rozsah (" A3 "). CurrentRegion .Rádky. Počet "Vyhľadajte v zozname číslo školy zadané vo vstupnom poli 'TextBox1" Pre i = 3 až n + 2 If Bunky (i, 1) .Value = Val (UserForm1.TextBox1.Text) Then Flag = True Exit For End If Next Fragment programu na spracovanie udalosti "Kliknite na tlačidlo HĽADAŤ"

Snímka č.16

Popis snímky:

"Počítačové matematické modelovanie" Ciele štúdia sekcie Zvládnutie modelovania ako metódy poznávania okolitej reality (vedecko-výskumný charakter sekcie) - ukazuje sa, že modelovanie v rôznych oblastiach poznania má podobné črty, často pre rôzne procesy je možné získať veľmi podobné modely; - demonštruje výhody a nevýhody počítačového experimentu v porovnaní s celoplošným experimentom; - ukazuje sa, že abstraktný model aj počítač poskytujú možnosť spoznávať okolitý svet, ovládať ho v záujme človeka. Rozvoj praktických zručností v oblasti počítačového modelovania. Uvedená je všeobecná metodika počítačového matematického modelovania. Na príklade množstva modelov z rôznych oblastí vedy a praxe sú realizované prakticky všetky stupne modelovania od formulácie problému až po interpretáciu výsledkov získaných v priebehu počítačového experimentu. Podpora profesijného poradenstva pre študentov. Prejavenie vlohy študenta pre vedeckovýskumnú činnosť, rozvoj tvorivého potenciálu, orientácia na voľbu povolania súvisiaceho s vedeckovýskumnou činnosťou. Prekonávanie predmetovej disociácie, integrácia vedomostí. Kurz skúma modely z rôznych oblastí vedy s využitím matematiky. Rozvoj a profesionalizácia počítačových zručností. Zvládnutie softvéru pre všeobecné a špecializované účely, programovanie systémov.

Snímka č.17

Popis snímky:

Snímka č.18

Popis snímky:

Modelovanie procesov optimálneho plánovania Problém plánovania práce autoservisu Vysvetlenie problému Nechajte autoservis vykonávať dva typy servisu: TO-1 a TO-2. Autá sú prijímané na začiatku pracovného dňa a na konci odovzdané zákazníkom. Vzhľadom na obmedzený počet parkovacích miest nie je možné obslúžiť viac ako 140 áut denne. Pracovný deň trvá 8 hodín. Ak by všetky autá prešli len TO-1, kapacita stanice by umožnila obsluhu 200 áut denne, ak by všetky autá prešli iba TO-2, tak 50. Náklady (pre klienta) TO-2 sú dvojnásobné. vysoké ako TO-1. V skutočnosti niektoré autá prejdú TO-1 a niektoré v ten istý deň TO-2. Je potrebné vypracovať takýto denný plán služieb, aby sa podniku zabezpečili čo najväčšie peňažné príjmy.

Snímka č.19

Popis snímky:

Modelovanie procesov optimálneho plánovania Formalizácia a matematický model problému Plánované ukazovatele x - denný plán výroby TO-1; y - denný plán výroby pre TO-2. Systém nerovníc vyplýva z formulácie úlohy Najväčší zisk dosiahneme pri maximálnej hodnote funkcie Funkcia f (x, y) sa nazýva účelová funkcia a systém nerovností sa nazýva systém obmedzenia. Mám problém s lineárnym programovaním

Snímka č.20

Popis snímky:

Snímka č.21

Popis snímky:

Modelovanie procesov optimálneho plánovania Metódy riešenia úlohy lineárneho programovania Simplexová metóda je univerzálna metóda riešenia úlohy lineárneho programovania Simplexná tabuľka Základ 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

Snímka č.22

Popis snímky:

Snímka č.23

Popis snímky:

Snímka č.24

Popis snímky:

Snímka č.25

Popis snímky:

Modelovanie procesov optimálneho plánovania Private Sub CommandButton1_Click () Dim d (5, 9) As Variant Dim i, j, r, n, k, m As Integer Dim p, q, t As String Dim a, b As Double For i = 1 Do 5 Pre j = 1 Do 9 d (i, j) = Rozsah ("a6: i10"). Bunky (i, j) .Hodnota Ďalej j Ďalej v = 7: r = 3 "Analýza optimality prúdu riešenie 't = "ďalší" Do Kým t = "ďalší" Program Simplexovej metódy vo VBA pre Excel (fragment)

Snímka č.28

Popis snímky:

Snímka č.29

Popis snímky:

Modelovanie procesov optimálneho plánovania Úloha plánovania prác na výstavbe cesty Problémové vyjadrenie Sú dva body - počiatočný H a konečný K; z prvej do druhej je potrebné vybudovať cestu, ktorá pozostáva z kolmice a segmentov. Náklady na výstavbu každej z možných sekcií sú známe (zobrazené na obrázku). V skutočnosti to bude nejaká prerušovaná čiara spájajúca body H a K. Je potrebné nájsť takú čiaru, ktorá má najnižšie náklady. Toto je úloha dynamického programovania

Popis snímky:

Snímka č.33

Popis snímky:

Počítačová simulácia Používa sa aparát matematickej štatistiky Náhodné udalosti: - časový interval medzi dvoma transakciami - čas služby transakcie Funkcie rozdelenia hustoty pravdepodobnosti náhodných udalostí Rovnomerné rozdelenie Gaussovo normálne rozdelenie Poissonovo rozdelenie

Popis snímky:

Plánované vzdelávacie výstupy pre EC. Študenti by mali poznať: účel a zloženie informačných systémov; etapy tvorby počítačového informačného systému; základné koncepty systemológie, existujúce varianty modelov systémov; čo je model infologickej domény; čo je databáza (DB); klasifikácia databázy; štruktúra relačnej databázy (RDB); normalizácia databázy; čo je DBMS; ako sú odkazy usporiadané vo viactabuľkovej databáze; aké sú typy dopytov do databázy; aká je štruktúra príkazu request na výber a triedenie údajov; aké možnosti práce s databázami má tabuľkový procesor (MS Excel); ako môžete vytvoriť a spustiť makro v programe MS Excel; čo je objektovo orientovaná aplikácia; základy programovania vo VBA; obsah pojmov „model“, „informačný model“, „počítačový matematický model“;

Snímka č.36

Popis snímky:

etapy počítačového matematického modelovania, ich obsah; zloženie súboru nástrojov pre počítačové matematické modelovanie; schopnosti tabuľkového procesora Excel pri implementácii matematického modelovania; schopnosti systému MathCAD pri implementácii počítačových matematických modelov; špecifiká počítačového matematického modelovania v ekonomickom plánovaní; príklady zmysluplných úloh z oblasti ekonomického plánovania, riešených metódou počítačového modelovania; výpis úloh riešených metódou lineárneho programovania; výpis úloh riešených metódou dynamického programovania; základné pojmy teórie pravdepodobnosti potrebné na realizáciu simulačného modelovania: náhodná veličina, zákon rozdelenia náhodnej veličiny, hustota rozdelenia pravdepodobnosti, spoľahlivosť výsledku štatistickej štúdie; spôsoby získania postupností náhodných čísel s daným distribučným zákonom; výkaz problémov riešených metódou simulačného modelovania v teórii radenia.

Snímka č.37

Popis snímky:

Študenti by mali byť schopní: navrhnúť jednoduchý informačný a referenčný systém; navrhnúť multitabuľkovú databázu; navigácia v prostredí MS Access DBMS; vytvorte databázovú štruktúru a naplňte ju údajmi; vytvárať dotazy na výber v MS Access pomocou návrhára dotazov; práca s formulármi; vykonať dopyt po prijatí konečných údajov; prijímať správy; organizovať jednotabuľkové databázy (zoznamy) v MS Excel; vyberať a triediť údaje v zoznamoch; filtrovať dáta; vytvárať kontingenčné tabuľky; zaznamenávať makrá pre MS Excel pomocou záznamníka makier; písať jednoduché obslužné programy udalostí vo VBA. aplikovať schému počítačového experimentu pri riešení zmysluplných úloh, kde je potrebné počítačové matematické modelovanie; vybrať faktory, ktoré ovplyvňujú správanie skúmaného systému, vykonať klasifikáciu týchto faktorov;

Snímka č.38

Popis snímky:

vytvárať modely študovaných procesov; vybrať softvér na štúdium vytvorených modelov; analyzovať získané výsledky a skúmať matematický model pre rôzne súbory parametrov, vrátane hraničných alebo kritických; používať jednoduché optimalizačné ekonomické modely; vytvoriť najjednoduchšie modely systémov radenia a interpretovať výsledky. implementovať jednoduché matematické modely na počítači, vytvárať algoritmy a programy v jazyku Visual Basic; využívať možnosti TP Excel na vykonávanie jednoduchých matematických výpočtov a ilustrovať výsledky matematického modelovania pomocou grafov a stĺpcových diagramov; použiť nástroj "Hľadať riešenie" TP Excel na riešenie úloh lineárneho a nelineárneho programovania; používať systém MathCAD na jednoduché matematické výpočty, graficky znázorňovať výsledky modelovania; použiť systém MathCAD na riešenie lineárnych a nelineárnych optimalizačných problémov.

Odoslanie dobrej práce do databázy znalostí je jednoduché. Použite nižšie uvedený formulár

Študenti, postgraduálni študenti, mladí vedci, ktorí pri štúdiu a práci využívajú vedomostnú základňu, vám budú veľmi vďační.

Uverejnené na http://www.allbest.ru/

Štátny inštitút služby v Omsku

Modelovanie informačných systémov pomocou jazyka UML

Metodické pokyny na realizáciu semestrálnej práce

I.V. Červenčuk

• Úvod
• 2 . Jednotný modelovací jazykUML
• 4. Vývoj modelu softvérového systému prostriedkamiUML
• 5. Otázky implementácie informačného systému
• 6. Témy ročníkovej práce
• Bibliografický zoznam

Úvod

Príspevok sa zaoberá vývojom informačných systémov s využitím jednotného modelovacieho jazyka UML, ktorý je základom pre prácu v predmete v disciplíne "Informačné systémy a procesy. Modelovanie a manažment". Rozpracúvajú sa hlavné etapy racionálneho jednotného procesu vývoja informačných systémov, uvádzajú sa príklady a ilustrácie. Možnosti zadania pre prácu v kurze sú uvedené.

Metodické pokyny sú určené pre študentov odboru "Aplikovaná informatika" a môžu byť použité pri cvičení, príprave na skúšku, ako aj v procese samostatnej práce.

1. Všeobecné požiadavky na realizáciu semestrálnej práce

Predmetová práca z disciplíny "Informačné systémy a procesy. Modelovanie a manažment" je záverečným stupňom štúdia tohto predmetu a je určená na praktické upevnenie základných teoretických poznatkov z modelovania informačných systémov. Práca spočíva vo vývoji modelu nejakého informačného systému pomocou jednotného modelovacieho jazyka UML s jeho následnou implementáciou. Ako typický variant zadania sa navrhuje vypracovať informačný a referenčný systém na báze databázy, avšak na požiadanie študenta po dohode s vyučujúcim je možné vytvoriť WEB aplikáciu, testovací systém alebo hardvérové ​​zariadenie. ponúkať ako úlohu. Zároveň je hlavným predpokladom využitie objektovo orientovaného prístupu a konštrukcia UML modelu.

Typický názov semestrálnej práce vyzerá ako „Vývoj informačného a referenčného systému _ titul _ "

Úvod

1. Podstatný prehľad v predmetnej oblasti. Základné systémové požiadavky

2. Podrobný model informačného systému

2.1 Pohľad z pohľadu prípadov použitia

2.2 Dizajnový pohľad

2.3 Implementačný pohľad

2.4 Procesná perspektíva (ak je to vhodné)

2.5 Pohľad z pohľadu nasadenia (ak je to potrebné)

3. Implementácia informačného systému

Záver

Aplikácia Výpis programu alebo hlavného modulu

V úvode možno poukázať na využitie informačných technológií v rôznych oblastiach činnosti vrátane sektora služieb, výhody elektronického účtovníctva, problémy budovania špecializovaných informačných systémov atď.

Tieto usmernenia obsahujú podrobné odporúčania pre hlavné časti vysvetlivky a príklady dizajnu. Je potrebné poznamenať, že hlavným predmetom práce v tomto kurze je vývoj UML modelu informačného systému, preto sa dôrazne odporúča, aby UML diagramy boli uvedené v hlavnej časti vysvetľujúcej poznámky s podrobnými komentármi. a texty programov by mali byť umiestnené v aplikácii.

Procesný pohľad by sa mal poskytnúť pri navrhovaní multitaskingových systémov. Pohľad nasadenia predpokladá distribuovaný informačný systém. Tieto typy a zodpovedajúce časti vysvetliviek nie sú povinné na realizáciu tejto kurzovej práce, ich použitie sa predpokladá pri vykonávaní len určitých variantov kurzovej práce.

Pri zvýraznení problematiky implementácie systému v poznámke je vhodné zdôvodniť výber programovacieho prostredia, poskytnúť používateľskú príručku. Povinným prvkom je zahrnutie obrazoviek (screen-shortov) implementovaného programu do textu, odporúča sa použitie nástrojov reverzného inžinierstva.

V závere sú stručne zhrnuté hlavné výsledky práce: bol vyvinutý UML-model systému, systém je implementovaný s použitím takého a takého programovacieho prostredia, ktoré vyvinutý systém umožňuje, výhody použitých prístupov (založené na o modelovaní) k návrhu systémov.

modelovanie jazyka informačného systému

Práca v kurze by mala obsahovať 20-30 strán tlačeného textu s ilustráciami. Bezpodmienečne musia byť poskytnuté diagramy prípadov použitia, tried, interakcií.

2. Jednotný modelovací jazyk UML

Racionálny rozvoj informačného systému predpokladá hĺbkovú predbežnú analytickú štúdiu. V prvom rade je potrebné načrtnúť okruh úloh, ktoré vyvíjaný systém vykonáva, potom vypracovať model systému a nakoniec určiť spôsoby implementácie. Hlboká štúdia architektúry vyvíjaného informačného systému v počiatočných fázach návrhu sa spravidla vyplatí neskôr, najmä pri vývoji rozsiahlych projektov s dlhodobou podporou.

Nástroje modelovacieho jazyka UML (Unified Model Language, - jednotný programovací jazyk) umožňujú výrazne a pomerne jednoducho uskutočniť predbežný koncepčný vývoj informačného systému a zároveň metodicky sprevádzať celý proces vývoja, vrátane tzv. celý ďalší životný cyklus vyvinutého informačného systému ako softvérového produktu.

UML je objektovo orientovaný jazyk na vizualizáciu, špecifikáciu, konštrukciu a dokumentáciu artefaktov softvérových systémov.

UML, ako každý iný jazyk, pozostáva zo slovnej zásoby a pravidiel, ktoré vám umožňujú kombinovať slová v ňom obsiahnuté a získať zmysluplné konštrukcie. V modelovacom jazyku sa slovná zásoba a pravidlá zameriavajú na koncepčnú a fyzickú reprezentáciu informačných systémov. Modelovanie je nevyhnutné pre pochopenie systému. Ako už bolo povedané, jeden model nikdy nestačí. Naopak, na pochopenie akéhokoľvek netriviálneho systému je potrebné vyvinúť veľké množstvo vzájomne súvisiacich modelov. V prípade softvérových systémov to znamená, že je potrebný jazyk, pomocou ktorého je možné z rôznych uhlov pohľadu popisovať reprezentácie architektúry systému počas jeho vývojového cyklu.

UML je vizualizačný jazyk a UML nie je len zbierka grafických symbolov. Každý z nich má dobre definovanú sémantiku (pozri), takže model napísaný jedným vývojárom môže byť jednoznačne interpretovaný iným vývojárom, alebo dokonca pomocou sady nástrojov.

UML je špecifikačný jazyk. V tomto kontexte špecifikácia znamená zostavenie presných, jednoznačných a úplných modelov. UML umožňuje špecifikáciu všetkých dôležitých rozhodnutí o analýze, návrhu a implementácii, ktoré sa musia urobiť počas vývoja a nasadenia softvérového systému.

UML je dizajnový jazyk. Hoci UML nie je vizuálny programovací jazyk, modely vytvorené pomocou neho možno priamo preložiť do rôznych špecifických programovacích jazykov. Inými slovami, model UML je možné mapovať na jazyky ako Java, C++, Visual Basic a dokonca aj tabuľky relačných databáz alebo perzistentné objektovo orientované databázové objekty. Tie pojmy, ktoré sú prednostne vyjadrené graficky, sú znázornené v UML; tie, ktoré sú lepšie opísané v textovej forme, sú vyjadrené pomocou programovacieho jazyka.

Toto mapovanie modelu do programovacieho jazyka umožňuje priamy návrh: generovanie kódu z modelu UML do špecifického jazyka. Môžete tiež vyriešiť inverzný problém: obnoviť model z existujúcej implementácie. Prirodzene, model a implementácia zahŕňa použitie množstva špecifických entít. Preto reverzné inžinierstvo vyžaduje nástroje aj ľudský zásah. Kombinácia dopredného generovania kódu a spätného inžinierstva vám umožňuje pracovať v grafických aj textových reprezentáciách, pokiaľ nástroje zaisťujú konzistentnosť medzi oboma reprezentáciami.

Okrem priameho mapovania na programovacie jazyky umožňuje UML svojou výraznosťou a jednoznačnosťou priamo spúšťať modely, simulovať správanie systémov a ovládať operačné systémy.

UML je dokumentačný jazyk

Softvérová spoločnosť produkuje okrem spustiteľného kódu aj ďalšie dokumenty vrátane:

Požiadavky na systém;

architektúra;

projekt;

zdroj;

projektové plány;

testy;

prototypy;

verzie atď.

V závislosti od prijatej metodiky vývoja sú niektoré práce vykonávané viac formálne, iné menej. Uvedené dokumenty nie sú len dodanými časťami projektu; sú potrebné pre riadenie, pre vyhodnocovanie výsledku a tiež ako prostriedok komunikácie medzi členmi tímu pri vývoji systému a po jeho nasadení.

UML poskytuje vývojárom a manažmentu vlastné riešenie problému dokumentácie architektúry systému a všetkých jeho detailov, poskytuje jazyk na formulovanie systémových požiadaviek a definovanie testov a nakoniec poskytuje prostriedky na modelovanie práce pri plánovaní projektu a kontrole verzií. fáza.

Uvažujme vývoj modelu informačného systému pomocou jazyka UML na príklade vývoja automatizovaného pracoviska pre tajomníka katedry (ďalej len AWP tajomníka katedry).

3. Popis predmetnej oblasti

Pojem oblasť databázy je jedným zo základných pojmov informatiky a nemá presnú definíciu. Jeho použitie v kontexte IP predpokladá existenciu stabilnej korelácie v čase medzi menami, pojmami a určitými realitami vonkajšieho sveta, nezávisle od samotného IP a jeho okruhu používateľov. Uvedenie do úvahy koncept databázovej domény teda obmedzuje a zviditeľňuje priestor na vyhľadávanie informácií v IS a umožňuje vykonávať dopyty v konečnom čase.

Pod popisom predmetnej oblasti rozumieme popis prostredia vyvíjaného systému, typy používateľov systému, pričom sú uvedené aj hlavné úlohy, ktorých riešenie je systému zadané.

V predbežnom popise predmetnej oblasti sú predstavené základné pojmy (systémový slovník), určené typy používateľov a ich práva, formulované úlohy, ktoré musí vyvíjaný systém riešiť. V tomto prípade má popis využívať prostriedky bežného jazyka a štandardnej obchodnej grafiky (obrázky, diagramy, tabuľky).

Pri vývoji systémového slovníka je potrebné definovať názvy entít („študent“, „učiteľ“, „disciplina“). V tomto prípade pojem esencia chápeme ako komponent doménového modelu, teda ako objekt už identifikovaný na konceptuálnej úrovni. Objekty alokované v predmetnej oblasti sú transformované analytikom na entity.

Entita je výsledkom abstrakcie skutočného objektu. S objektmi sú spojené dva problémy: identifikácia a adekvátny popis. Na identifikáciu sa používa názov, ktorý musí byť jedinečný. V tomto prípade sa predpokladá, že dochádza k odmietnutiu jeho významu, ktorý je vlastný prirodzenému jazyku. Používa sa iba orientačná funkcia názvu. Názov je priamy spôsob identifikácie objektu. Nepriame metódy identifikácie objektu zahŕňajú definíciu objektu prostredníctvom jeho vlastností (charakteristiky alebo znaky).

Objekty sa navzájom ovplyvňujú prostredníctvom svojich vlastností, čo vedie k situáciám. Situácie sú vzťahy, ktoré vyjadrujú vzťahy medzi objektmi. Situácie v predmetnej oblasti sú opísané prostredníctvom výpovedí o predmetnej oblasti. V tejto fáze môžete použiť metódy výrokového počtu a predikátového počtu, teda formálnej, matematickej logiky. Napríklad výrok „Programátor a manažér sú zamestnancami spoločnosti“ popisuje inkluzívny vzťah. Všetky informácie o objektoch a entitách domény sú teda opísané pomocou príkazov v prirodzenom jazyku.

Môžete špecifikovať štrukturálne väzby, zvýrazňovať statické a dynamické situácie (čím sa do modelu zavedie časový parameter), avšak pre detailné štúdium modelu je vhodnejšie použiť pokročilé prostriedky popisu domény, napr. jazyk UML.

Úlohou je teda vyvinúť systém „pracovisko tajomníka katedry“, ktorý by umožňoval automatizované účtovanie údajov o zamestnancoch a študentoch katedry IKT OmSTU, poskytoval flexibilné možnosti riešenia plánovaných i neplánovaných špecifických úloh spracovania. poverenia.

V rámci riešenia problematiky rozvoja automatizovaného pracoviska pre tajomníka katedry vyčleníme nasledovné subjekty:

učitelia - učitelia katedry;

študentov- študenti univerzity tejto špecializácie;

študenti študujú v skupiny, skupina je organizačným (zjednocujúcim) subjektom pre študentov;

postgraduálnych študentov, majú tú zvláštnosť, že na jednej strane môžu sami viesť hodiny, na druhej strane sú sami študentmi a majú vedeckého poradcu;

disciplína- vyučovaná disciplína (predmet, kurz).

Vložené entity majú množstvo atribútov, ktoré si zadefinujeme neskôr.

Vykonávame dva typy používateľov: súkromných užívateľ(ďalej užívateľ a správca... Predpokladá sa, že užívateľ môže pristupovať do systému s požiadavkou, zobrazovať správy, správca navyše môže upravovať údaje. Napríklad asistent tajomníka katedry môže pôsobiť ako používateľ, samotný tajomník alebo zodpovedný učiteľ môže pôsobiť ako správca.

Vzhľadom na zavedené výrazy by mal vyvíjaný systém poskytovať:

organizácia kompletného a spoľahlivého účtovníctva všetkých zamestnancov a študentov katedry;

informačná podpora prijímaných rozhodnutí manažmentu, tvorba úplných a spoľahlivých informácií o vzdelávacích procesoch a výsledkoch činnosti oddelenia;

zníženie mzdových nákladov na prípravu prvotných dokumentov a správ;

odstránenie duplicity pri zadávaní informácií az toho vyplývajúce mechanické chyby;

užívateľsky prívetivé rozhranie;

rozlíšenie právomocí bežných používateľov a správcu.

V tomto príklade riešime konkrétny problém - vypracúvame AWP pre tajomníka katedry, preto je katedra pre nás braná ako štrukturálna jednotka najvyššej úrovne, ktorú budeme mať štandardne na mysli, tzn. predpokladá sa, že všetky prvky modelu sa týkajú iba tohto oddelenia, ktoré nie je výslovne špecifikované ... Nebudeme uvažovať nad štruktúrami vyššej úrovne, ako je fakulta, univerzita.

4. Vývoj modelu softvérového systému pomocou UML

UML je jazyk pre špecifikáciu a vizualizáciu, jeho hlavnými jednotkami sú diagramy.

UML diagram je grafické znázornenie množiny vzorkovníc, najčastejšie zobrazované ako spojený graf s vrcholmi (entitami) a hranami (vzťahmi). Diagramy charakterizujú systém z rôznych uhlov pohľadu. Diagram je v istom zmysle jednou z projekcií systému. Grafy zvyčajne poskytujú zbalený pohľad na prvky, ktoré tvoria systém. Jeden a ten istý prvok môže byť prítomný vo všetkých diagramoch, alebo len vo viacerých (najbežnejší variant), alebo nie je prítomný v žiadnom (veľmi zriedkavo). Teoreticky môžu diagramy obsahovať akúkoľvek kombináciu entít a vzťahov. V praxi sa však používa relatívne malý počet typických kombinácií zodpovedajúcich piatim najbežnejším typom, ktoré tvoria architektúru softvérového systému (pozri nasledujúcu časť). V UML sa teda rozlišuje deväť typov diagramov:

diagramy tried

diagramy objektov;

diagramy prípadov použitia;

sekvenčné diagramy;

diagramy spolupráce;

stavové diagramy;

akčné (činnostné) diagramy;

diagramy komponentov;

diagramy nasadenia.

Koncepčný model UML

Diagram tried zobrazuje triedy, rozhrania, objekty a spolupráce a ich vzťahy. Pri modelovaní objektovo orientovaných systémov sa tento typ diagramu používa najčastejšie. Diagramy tried predstavujú statický pohľad na návrh systému. Diagramy tried, ktoré obsahujú aktívne triedy, zodpovedajú statickému pohľadu na systém z perspektívy procesu.

Diagram objektov predstavuje objekty a vzťahy medzi nimi. Sú to statické „fotografie“ inštancií entít znázornených v diagramoch tried. Objektové diagramy, podobne ako diagramy tried, odkazujú na statický pohľad na systém z perspektívy návrhu alebo procesu, ale s ohľadom na skutočnú alebo falošnú implementáciu.

Diagram prípadov použitia zobrazuje prípady použitia a aktérov (špeciálny prípad tried), ako aj vzťahy medzi nimi. Diagramy prípadov použitia odkazujú na statický pohľad na systém z hľadiska prípadov použitia. Sú obzvlášť dôležité pri organizovaní a modelovaní správania systému.

Sekvenčné diagramy a kooperačné diagramy sú špeciálnymi prípadmi interakčných diagramov. Interakčné diagramy predstavujú vzťahy medzi objektmi; ukazuje najmä správy, ktoré si predmety môžu vymieňať. Interakčné diagramy odkazujú na dynamický pohľad na systém. V tomto prípade sekvenčné diagramy odrážajú časové usporiadanie správ a diagramy spolupráce - štrukturálnu organizáciu objektov, ktoré si vymieňajú správy. Tieto diagramy sú izomorfné, to znamená, že sa môžu navzájom transformovať.

Diagramy stavových diagramov predstavujú automat, ktorý zahŕňa stavy, prechody, udalosti a typy akcií. Stavové diagramy sa vzťahujú na dynamický pohľad na systém; sú obzvlášť dôležité pri modelovaní správania rozhrania, triedy alebo spolupráce. Zameriavajú sa na správanie objektu v závislosti od postupnosti udalostí, čo je veľmi užitočné pri simulácii reaktívnych systémov.

Diagram aktivity je špeciálny prípad stavového diagramu; zobrazuje prechody toku riadenia z jednej činnosti do druhej v rámci systému. Diagramy aktivít odkazujú na dynamický pohľad na systém; sú najdôležitejšie pri modelovaní jeho fungovania a odrážajú tok riadenia medzi objektmi.

Diagram komponentov zobrazuje organizáciu súboru komponentov a závislosti medzi nimi. Diagramy komponentov odkazujú na statický pohľad na systém z hľadiska implementácie. Môžu súvisieť s diagramami tried, pretože komponent sa zvyčajne mapuje do jednej alebo viacerých tried, rozhraní alebo spolupráce.

Diagram nasadenia zobrazuje konfiguráciu procesných uzlov systému a komponentov v nich umiestnených. Diagramy nasadenia odkazujú na statický pohľad na architektúru systému z perspektívy nasadenia. Súvisia s diagramami komponentov, pretože podzostava zvyčajne obsahuje jeden alebo viac komponentov.

Tu je čiastočný zoznam diagramov používaných v UML. Nástroje vám umožňujú generovať aj iné diagramy, ako napríklad diagramy databázových profilov, diagramy webových aplikácií atď.

4.1 Návrh pohľadu z pohľadu prípadu použitia

Modelovanie začína definovaním hlavných cieľov vyvíjaného systému a činností, ktoré by mal vykonávať. Na tieto účely sa používajú diagramy prípadov použitia. Ako už bolo spomenuté vyššie, diagramy prípadov použitia označujú prípady použitia a aktérov a vzťahy medzi nimi.

Precedens (Prípad použitia) je popis postupnosti akcií vykonávaných systémom, ktoré vytvárajú pozorovateľný výsledok, ktorý je významný pre určitý zák e ra (Herec). Prípad použitia sa používa na štruktúrovanie entít správania modelu. Prípad použitia iba deklaruje popis nejakej akcie systému, odpovedá na otázku „čo robiť?“, ale neuvádza akým spôsobom. Konkrétnu implementáciu správania špecifikovaného prípadom použitia poskytuje trieda, spolupráca triedy alebo komponent.

Herec je koherentný súbor rolí, ktoré používatelia prípadu použitia hrajú pri interakcii s nimi. Aktér zvyčajne predstavuje úlohu, ktorú v danom systéme zohráva osoba, hardvérové ​​zariadenie alebo dokonca iný systém. Vo vyvinutom systéme „Pracovisko tajomníka katedry“ sú herci administrátormi (admin) a užívateľ.

Graficky je precedens znázornený ako elipsa ohraničená súvislou čiarou, ktorá zvyčajne obsahuje len jeho meno, herec má ikonu „malý muž“.

Na zostavenie diagramu prípadov použitia je potrebné identifikovať základné akcie vykonávané systémom a porovnať ich s prípadmi použitia. Zároveň je žiaduce uviesť názvy prípadov použitia tak, aby naznačovali správanie, často takéto názvy obsahujú slovesá, napríklad „vygenerovať správu“, „nájsť údaje podľa kritéria“ atď. Je možné pomenovať prípady s podstatnými menami, ktoré naznačujú niektoré akcie, napríklad „autorizácia“, „hľadanie“, „kontrola“.

Vráťme sa k modelovaniu automatizovaného pracoviska tajomníka katedry, dovoľte nám zdôrazniť precedensy:

Úpravaúdajov,

Vyhľadávanieštudent,

Vyhľadávanieučiteľ,

Vydaniezoznamučildisciplín,

Autorizácia.

Prvky diagramu prípadov použitia (prípady použitia a aktéri) musia byť prepojené vzťahmi.

Najbežnejším vzťahom medzi prípadmi použitia, prípadmi použitia a aktérmi je asociácia. V niektorých prípadoch možno použiť zovšeobecňovacie vzťahy. Tieto vzťahy majú rovnaký význam ako v diagrame tried.

Okrem toho sú medzi prípadmi použitia v UML definované dve špecifické závislosti – vzťah zahrnutia a vzťah rozšírenia.

Vzťah zahrnutia medzi prípadmi použitia znamená, že v určitom bode základného prípadu použitia je začlenené (zahrnuté) správanie iného prípadu použitia. Zahrnutý prípad použitia nikdy neexistuje autonómne, ale vytvára sa iba ako súčasť priloženého prípadu použitia. Základný prípad použitia si môžete predstaviť ako vypožičanie správania zahrnutia. Vďaka prítomnosti inklúznych vzťahov je možné vyhnúť sa viacnásobnému opisu toho istého prúdu udalostí, pretože všeobecné správanie možno opísať ako nezávislý prípad použitia zahrnutý v základných. Príkladom delegovania je vzťah zahrnutia, v ktorom je na jednom mieste (v zahrnutom prípade použitia) popísaných niekoľko zodpovedností systému a ostatné prípady použitia, ak je to potrebné, zahrnú tieto zodpovednosti do svojho súboru.

Vzťahy inklúzie sú zobrazené ako závislosti so stereotypom „zahrnúť“. Ak chcete určiť miesto v toku udalostí, kde základný prípad použitia zahŕňa správanie iného, ​​jednoducho napíšte slovo zahrnúť a za ním názov prípadu použitia, ktorý sa má zahrnúť.

Vzťah rozšírenia sa používa na modelovanie častí prípadu použitia, ktoré používateľ vníma ako voliteľné správanie systému. To vám umožňuje oddeliť požadované a voliteľné správanie. Vzťahy rozšírení sa používajú aj na modelovanie jednotlivých podprúdov, ktoré bežia len za určitých okolností. Nakoniec sa používajú na simuláciu viacerých streamov, ktoré môžu byť spustené v určitom bode scenára ako výsledok explicitnej interakcie s hercom.

Extenčný vzťah je znázornený ako závislosť so stereotypom „predlžovať“. Body rozšírenia základného skriptu sú uvedené v ďalšej časti. Sú to jednoducho štítky, ktoré sa môžu objaviť v toku základného prípadu použitia.

Príkladom využitia tohto vzťahu môže byť prístup k databáze s prevádzkovou časťou a archívom. V tomto prípade, ak sú v žiadosti poskytnuté údaje z prevádzkovej časti, vykoná sa hlavný (základný) prístup k údajom, ak údaje z prevádzkovej časti nepostačujú, sprístupní sa archívne údaje, to znamená vykonaná podľa pokročilého scenára.

V našom prípade precedens editovanieúdajov zahŕňa prípady použitia: vstupúdajov, vymazanieúdajov, zmenaúdajov.

Schéma precedensov RP tajomníka katedry je na obr.1.

Ryža. 1. Schéma precedensov RP tajomníka katedry

Precedens Vyhľadávanieštudent zahŕňa vyhľadávanie podľa priezviska a vyhľadávanie podľa výsledkov akademického výkonu.

Pri návrhu pohľadu z hľadiska prípadov použitia je často potrebné poskytnúť rozšírený popis prípadu použitia (v skrátenej verzii je uvedený iba názov). Typicky je tok udalostí prípadu použitia opísaný v textovej forme na začiatku. Keď upravíte svoje systémové požiadavky, bude pohodlnejšie prejsť na grafické znázornenie tokov v diagramoch aktivít a interakcií.

Prúdy udalostí možno opísať pomocou neštruktúrovaného textu, štruktúrovaného textu (obsahujúceho servisné slová: AK,PREDTIEPORKEĎ atď.), špecializovaný formálny jazyk (pseudokód).

Pri popise prípadu použitia ako toku udalostí je dôležité určiť aj hlavné a alternatívne toky správania systému.

Zvážte napríklad popis toku udalostí prípadu použitia autorizáciu.

Základné prúdiť diania. Prípad použitia začína, keď systém požiada používateľa o jeho prihlasovacie meno a heslo. Používateľ ho môže zadať z klávesnice. Zadávanie končí stlačením tlačidla. Zadajte. Potom systém skontroluje zadané prihlasovacie meno a heslo a ak sa zhodujú s administrátorom, potvrdí oprávnenie administrátora. Týmto sa precedens uzatvára.

Výnimočné prúdiť diania. Klient môže transakciu kedykoľvek ukončiť stlačením klávesu Zrušiť. Táto akcia začína precedens odznova. Neexistuje žiadny vstup do systému.

Výnimočné prúdiť diania. Klient môže svoje prihlasovacie meno a heslo kedykoľvek pred stlačením klávesu Enter vymazať.

Výnimočné prúdiť diania. Ak klient zadal prihlasovacie meno a heslo, ktoré nezodpovedajú administrátorovi, je mu ponúknutý opätovný vstup alebo prihlásenie do systému ako bežný používateľ.

Je zrejmé, že popis prípadu použitia prúdom udalostí predpokladá nejaký druh algoritmu, ktorý možno znázorniť v diagrame aktivít (obr. 2).

Diagram algoritmu musí obsahovať začiatočné a koncové vrcholy s iba jedným začiatkom a jedným koncom. Diagram obsahuje spustiteľné vrcholy - aktivity (označené zaoblenými obdĺžnikmi), podmienené vrcholy (rozhodnutie - výber, rozpoznávanie, označené kosoštvorcami) a prepojenia.

Podobné diagramy môžu vysvetliť vykonávanie iných prípadov použitia, čím dopĺňajú pohľad na systém z pohľadu prípadov použitia.

Ryža. 2. Autorizácia používateľa. Diagram aktivity.

4.2 Vypracovanie návrhového pohľadu

Dizajnový pohľad je hlavnou etapou koncepčnej štúdie modelu. V tejto fáze sa zavádzajú základné abstrakcie, definujú sa triedy a rozhrania, cez ktoré sa implementuje riešenie úloh. Ak prípady použitia iba deklarujú správanie systému, tak vo fáze vývoja pohľadu z hľadiska návrhu je určené, akými prostriedkami budú tieto prípady použitia implementované. Statické aspekty tohto typu sa rozvíjajú prostredníctvom diagramov tried, dynamických - prostredníctvom interakcií a stavových diagramov (automat).

Diagramy tried obsahujú triedy, rozhrania, kooperácie, ako aj prepojenia medzi nimi. Vývoj diagramu tried by sa mal začať definíciou tried zodpovedajúcich hlavným entitám systému, ktoré sa spravidla určujú v počiatočných fázach vývoja pri opise predmetnej oblasti. Tu je potrebné rozhodnúť, ktoré entity je vhodnejšie modelovať ako triedy a ktoré ako ich atribúty. Ak by sa napríklad v rámci fakulty vyžadovalo uviesť vedúceho pre každý odbor, bolo by lepšie špecifikovať manažérStoličky urobte z neho atribút triedy stolička označujúci triedu učitelia ( spojenie jeden k jednému ), namiesto zavádzania samostatnej triedy manažérStoličky.

Pri modelovaní treba pamätať na to, že každá trieda musí zodpovedať nejakej skutočnej entite alebo konceptuálnej abstrakcii z oblasti, ktorou sa používateľ alebo vývojár zaoberá. Dobre štruktúrovaná trieda má nasledujúce vlastnosti:

je dobre definovaná abstrakcia nejakého konceptu zo slovnej zásoby problémovej oblasti alebo oblasti riešenia;

obsahuje malý, dobre definovaný súbor povinností a vykonáva každú z nich;

zachováva jasné oddelenie špecifikácií abstrakcie a ich implementácie;

zrozumiteľné a jednoduché, no zároveň umožňuje rozšírenie a prispôsobenie sa novým úlohám.

V rámci vývoja modelu automatizovaného pracoviska tajomníka katedry zadefinujeme triedy: učitelia, študentov, postgraduálnych študentov, disciplín, skupina... Je zrejmé, že prvý z nich má veľa spoločných atribútov, takže predstavme abstraktnú triedu NSEerson, ktorý zapuzdruje všetky vlastnosti súvisiace s človekom v kontexte vyvíjaného systému (priezvisko, meno, adresa atď.). V tomto prípade osoba bude supertriedou a bude komunikovať prostredníctvom všeobecného vzťahu s triedami učitelia, študentov, postgraduálnych študentov.

Atribút adresu má svoju vlastnú štruktúru, na jej vyjadrenie môžete zaviesť ďalšiu triedu, nazvime ju T_ ADR(ako je zvykom v mnohých programovacích systémoch, názvy tried začínajú písmenom T). Všimnite si, že atribút adresu trieda osoba je inštanciou triedy T_ ADR, to znamená, že medzi týmito triedami je vytvorený vzťah závislosti (znázornený prerušovanou šípkou s otvorenou špičkou, šípka smeruje od závislého k nezávislému). V našom prípade zmena štruktúry triedy T_ ADR znamená zmenu triedy osoba cez štruktúru zodpovedajúceho atribútu ( adresu).

Pri modelovaní triedy T_ ADR atribút index nastavené pomocou primitívneho typu T_ POSTIDX, definované ako šesťmiestne desiatkové číslo. Primitívne typy sú stereotypné“ typu" , rozsah hodnôt je špecifikovaný prostredníctvom obmedzení uzavretých v zložených zátvorkách.

V triede učiteľ vyzdvihnime konkrétne atribúty súvisiace len s učiteľom: pozíciu, uch. stupňa(akademický titul), uch. hodnosť ( akademická hodnosť), vypúšťanie(kategória jednotnej tarifnej stupnice). Atribúty uch. stupňa a uch. hodnosť je lepšie definovať špecializované typy prostredníctvom enumerácie. Enumerácie sú modelované triedou so stereotypom " enum" (enumerácia - enumerácia), povolené hodnoty sú zapísané ako atribúty, štítky určujúce viditeľnosť atribútov sú potlačené. V uvažovanom príklade prostredníctvom enumerácie uvádzame špecializované triedy T_Musieť, T_UCHST, T_UchZv, respektíve definovanie možných pozícií, akademických titulov, akademických titulov prostredníctvom prestupov. V tomto prípade, ako aj inde v podobných prípadoch, pri vytváraní tried, ktoré špecifikujú atribúty hlavnej triedy, sa vytvárajú vzťahy závislostí.

Pre triedu študent zavádza sa špecifický atribút miestnosťknihy záznamov... Pre postgraduálnu triedu sú definované špecifické atribúty formuláručenie a dátumpotvrdenky... Formu štúdia určí špeciálna trieda prostredníctvom súpisu T_FormObuch(plný, čiastočný úväzok).

Trieda skupina má atribúty: titul, formulár učenie, číslostud. ( počet študentov ). Vzhľadom na to, že učitelia predmetnej katedry môžu vyučovať skupiny z iných fakúlt, zavádza sa doplnková trieda špecialita, s atribútmi miestnosť(špeciality), titul(špeciality ), fakulty ktorých typy nie sú v tomto modeli špecifikované, hoci ich možno určiť pomocou enumerácií.

Trieda disciplína má atribúty: miestnosť, titul, cyklu. Atribút cyklu prostredníctvom špecializovaného typu zavedeného prostredníctvom enumerácie T_Cycles určuje, do ktorého cyklu disciplína patrí: cyklus humanitných a sociálno-ekonomických disciplín, matematických a prírodovedných disciplín, všeobecných odborných disciplín, špeciálnych disciplín.

Atribúty číslohodiny, číslosemestrov nemožno v triede špecifikovať disciplína, keďže závisia od špecializácie, tým viac ich nemôžete v triede uviesť špecialita... Tieto atribúty sa vzťahujú na dvojicu odbornosť a sú definované v triede – asociácia Disciplíny-špeciality.

Ryža. 3. Triedny rozvrh RP tajomníka katedry (variant 1)

Pri vykresľovaní štruktúry triedy venujte pozornosť viditeľnosti atribútov. Všetky uvažované atribúty musia byť dostupné a musia mať viditeľnosť Verejné (označené znakom „+“ alebo ikonou bez visiaceho zámku). V uvažovaných triedach sme sa zamerali skôr na štruktúru ako na správanie (operácie neboli popísané a ani sa nepredpokladá), preto je pre uľahčenie čítania diagramu žiaduce operácie potlačiť.

Na zavedenej množine tried je potrebné predefinovať prepojenia. Súvislosti zovšeobecnenia a závislostí sú už určené, zostáva definovať asociácie.

Študenti vytvorený v skupina, v tomto prípade bude mať združenie formu agregácie. Agregácia predpokladá vzťah časť-celok, označený plnou čiarou s kosoštvorcom na konci z celej strany (v našom prípade skupina). Pluralita vzťahov medzi študentmi a skupinami. Každý skupina odkazuje na konkrétny špeciality, zas môže určitej špecializácii zodpovedať viacero skupín, preto skupinovo-špecializačné združenie má aj typ mnohosti „mnoho ku jednej“.

V tomto prípade, rovnako ako vo väčšine ostatných, je smer asociácií obojsmerný, preto je lepšie navigáciu potlačiť (zrušte začiarknutie políčka Navigovateľné pri možnosti Úloha detailov)

Definujme asociáciu medzi učitelia a učil disciplín ako „many-to-many“: učiteľ môže učiť viacero odborov, niektoré odbory môže vyučovať viacero učiteľov. Medzi disciplín a špeciality vzniká aj združenie „many-to-many“: učebné osnovy odborov obsahujú veľa odborov, najviac odborov sa nachádza v pracovných plánoch viacerých odborností. Trieda asociácie je pripojená k tejto asociácii. Disciplíny-špeciality s atribútmi označujúcimi kurz, počet semestrov a počet hodín daného odboru v danej špecializácii.

Podobne zavedieme asociáciu medzi v skupinách a učitelia: Učitelia učia v skupinách, typ asociácie multi-to-many. Priama asociácia medzi v skupinách a disciplins nemusíte definovať, pretože tento vzťah sa sleduje cez triedu spojiva špecialita.

Na zobrazenie prítomnosti školiteľa pre postgraduálneho študenta je potrebné zaviesť asociáciu medzi postgraduálnym študentom a učiteľom typu „many-to-one“, jeden školiteľ môže mať viacero postgraduálnych študentov. V tejto asociácii zo strany učiteľa môžete výslovne uviesť úlohu: supervízor.

Ryža. 4. Schéma tried RP tajomníka katedry (možnosť 2)

V každom skupinye existuje vodca skupiny, túto skutočnosť môže zobraziť ďalšie združenie (dajme mu názov prednosta) zo skupiny na študentov s typom násobnosti „jeden k jednému“. V tomto prípade môžete výslovne špecifikovať navigáciu.

Postgraduálni študenti môže tiež vyučovať špecifické disciplíny pre špecifické skupiny: mnoho-k-many združenia postgraduálne skupiny, postgraduálne disciplíny. Niektorí postgraduálni študenti nemusia učiť, takže typ násobnosti na koncoch asociácie bude 0. n.

Konečný diagram tried je znázornený na obr. 3.

Ryža. 5. Zjednodušený diagram tried

Vzhľadom na to, že študenti aj učitelia vyučujú triedy, možno zaviesť ďalšiu abstraktnú triedu, napr. vyučovanie ktorý je potomkom triedy osoba a supertrieda pre triedy učiteľ a postgraduálny študent, čo mierne zníži počet spojení. (obr. 4.). V tomto prípade z tried disciplína a skupina združenia pôjdu do triedy vyučovanie, za predpokladu prepojenia na triedy učiteľ a postgraduálny študent prostredníctvom dedenia (vzťah zovšeobecňovania). Do triedy vyučovanie môžete odstrániť atribúty ponuku(sadzba 0,5, plná sadzba) a vypúšťanie.

Výsledný diagram je pomerne zložitý a nabitý prvkami, ale modelovanie tried nie je ani zďaleka dokončené: ešte je potrebné definovať niektoré pomocné triedy a rozhrania. Aby sme rozložili diagram tried, zostrojíme naň nový pohľad (na samostatnom diagrame), pričom ponecháme obraz hlavných tried a potlačíme zobrazovanie pomocných, ktoré určujú typy atribútov (obr. 5).

Na obr. 5, spolu s hlavnými triedami zodpovedajúcimi koncepčným prvkom systému, je znázornená aj trieda T_ ADR, odhaľujúca štruktúru adresy, je dôležitá aj táto trieda, keďže obsahuje potrebné dátové prvky pre učitelia a postgraduálnych študentov- potomkovia triedy osoba.

Prejdime k definovaniu rozhraní. Triedy interagujú s vonkajším svetom prostredníctvom rozhraní.

Rozhranie (Interface) je súbor operácií, ktoré definujú službu (množinu služieb) poskytovanú triedou alebo komponentom. Rozhranie teda popisuje externe viditeľné správanie prvku. Rozhranie môže reprezentovať správanie triedy alebo komponentu vcelku alebo čiastočne; definuje len špecifikácie operácií (podpisy), ale nikdy nie ich implementáciu. Grafické rozhranie je znázornené ako kruh, pod ktorým je napísané jeho meno. Rozhranie zriedka existuje samo o sebe – zvyčajne je pripojené k implementačnej triede alebo komponentu. Rozhranie vždy predpokladá existenciu akejsi „zmluvy“ medzi stranou, ktorá deklaruje vykonanie množstva operácií, a stranou, ktorá tieto operácie realizuje.

Umiestnite triedu na diagram elektronickétabuľky, ktorý zahŕňa všetky vlastnosti a operácie tabuľky, ktorá vám umožňuje upravovať údaje. Štruktúru tejto triedy pre jej veľkú zložitosť neprezradíme. Takže v moderných nástrojoch na vývoj aplikácií používateľ používa hotové triedy a šablóny, ktoré dedia ich schopnosti, napríklad knižnica VCL (Delphi) obsahuje triedu TTable, ktorá zahŕňa možnosti tabuľky. Potomkovia triedy elektronickétabuľky sú špecifické tabuľky obsahujúce špecifické údaje pre fakultu, postgraduálnych študentov, študentov, skupiny, odbory a špecializácie. Tým, že sa zodpovedajúce triedy stanú potomkami triedy elektronickétabuľky, pre tieto triedy deklarujeme všetky vlastnosti a operácie vlastné tabuľkovým procesorom (registrácia v systéme, vkladanie, mazanie, editácia údajov, triedenie atď.).

Pre triedu elektronickétabuľky a podľa toho pre všetkých jeho potomkov definujeme rozhranie úprava, zahŕňajúce všetky možné operácie úpravy údajov (vkladanie, mazanie, zmena údajov). V tomto prípade sa predpokladá, že v kl elektronickétabuľky tieto možnosti sú implementované.

Použitie vlastnej triedy elektronickétabuľky a dedičnosť sa vyhla definovaniu špeciálnych vlastností a rozhraní na úpravu údajov pre každú tabuľku.

Poďme definovať rozhrania Vyhľadávanieučiteľ, Vyhľadávaniedisciplín ich pripojením k ich príslušným triedam s implementačným vzťahom. Zloženie operácií týchto rozhraní nebudeme prezrádzať (je to celkom triviálne), preto rozhrania zobrazíme v skrátenej forme (vo forme kruhu). Pripomeňme, že implementačný vzťah pripojený k rozhraniu v skrátenej forme je zobrazený ako jednoduchá plná čiara (ako asociácia).

Rozhranie Vyhľadávanieštudent sa zobrazí s označením zoznamu operácií cez stereotypnú triedu, pričom realizačný vzťah je znázornený prerušovanou šípkou s uzavretým hrotom.

Prirodzene sa predpokladá, že zavedené rozhrania sú implementované pomocou tried, ku ktorým sú pripojené implementačným vzťahom, to znamená, že zodpovedajúce triedy obsahujú operácie a metódy, ktoré implementujú deklarované rozhrania. Pre uľahčenie vnímania nie sú tieto mechanizmy vizualizované.

Na správu prístupových práv a autorizácie používateľov uvádzame triedu manažérprístup... Správca prístupu má atribút typu súkromného prístupu tabuľkyhesláčo je inštancia triedy CodirTable(Kódovaná tabuľka) obsahujúca heslá ( heslo) a názvy vstupov ( Prihlásiť sa) správcovských používateľov. Predpokladá sa, že služby triedy schopností CodirTable neumožňujú neoprávnenému používateľovi čítať používateľské heslá. V tejto fáze návrhu tieto schopnosti jednoducho deklarujeme, pričom sa nezaoberáme mechanizmom ich implementácie, ale za predpokladu, že sú zapuzdrené v triede CodirTable.

Trieda manažérprístup obsahuje otvorené transakcie vstupheslo a udeľovanie administrátorských práv, pomocou ktorých sa realizuje autorizácia a správa prístupových práv.

Označme závislosť medzi rozhraním na úpravu údajov ( editovanie) a správcu prístupu za predpokladu, že iba používatelia s právami správcu majú úplné možnosti úpravy údajov.

Ryža. 6. Záverečná schéma tried RP tajomníka katedry

Konečná schéma je znázornená na obr. 6.

Takže v tejto fáze možno považovať vývoj objektovo orientovaného modelu pracovnej stanice tajomníka katedry pomocou diagramu tried UML za ukončený. Prirodzene je možné sa k nemu vrátiť a niektoré prvky revidovať už pri návrhu systému, pri úprave úloh, pri špecifikovaní jednotlivých detailov. Proces navrhovania informačných systémov je iteratívny. Treba poznamenať, že vyvinutý diagram tried obsahuje prvky, ktoré explicitne alebo implicitne implementujú všetky prípady použitia diagramu prípadov použitia. Každý prípad použitia diagramu prípadu použitia musí zodpovedať buď rozhraniu alebo operácii rozhrania (implementácia sa predpokladá v triedach zodpovedajúcich rozhraniu), alebo verejnej operácii triedy alebo množine verejných operácií (v tomto prípade prípad použitia je implementovaný priamo zodpovedajúcou triedou alebo množinou tried).

Pozrime sa na proces vytvárania nového študentského záznamu pomocou sekvenčného diagramu.

Vytvorenie nového záznamu predpokladá administrátorské práva, takže administrátor bude protagonistom tejto interakcie ( admin). Tento prvok už bol zadaný do diagramu prípadov použitia, takže ho presuňte do sekvenčného diagramu z prehliadača zobrazenia prípadov použitia.

Treba si uvedomiť, že objekty sa objavujú v interakčných diagramoch, teda konkrétne inštancie tried (názov objektu je vždy podčiarknutý).

Spravujeme objekty: formulárvstup, manažérzáznamy, študentský záznam Petrov(ako konkrétny príklad študentského záznamu), manažértransakcií... Táto množina objektov je typická pri úprave záznamu v databázovej tabuľke.

Formulárvstup- prvok používateľského rozhrania, ktorý je typickým formulárom na zadávanie údajov o študentovi (priezvisko, meno, priezvisko, adresa atď.). V našom prípade ide o trochu rozšírenú konkrétnu implementáciu štandardného rozhrania editovanie trieda elektronickétabuľky. Keďže sme špeciálne neuviedli rozhranie na úpravu údajov o študentovi na diagrame tried, explicitne špecifikujte triedu pre objekt formulárvstup nebudeme.

manažérzáznamy- objekt, ktorý má štandardnú sadu možností správy údajov pri práci s tabuľkovým procesorom. Táto sada schopností je zdedená triedou študentov z triedy elektronickétabuľky... Pre objekt manažérzáznamy trieda, ktorej je inštanciou, je výslovne uvedená - študentov.

Petrov- špecifický záznam o študentovi Petrovi, nový prvok tabuľky o študentoch. Tu výslovne uvádzame zavedenú triedu nahrávanieOštudent... Takéto objekty zvyčajne existujú dočasne na odosielanie relevantných informácií do databázy počas transakcií. Po ukončení transakcie môže byť tento objekt zničený. Objekt zodpovedajúci záznamu je možné vytvoriť znova, ak je potrebné upraviť informácie.

manažértransakcií- objekt, ktorý zabezpečuje vykonanie dokončenej operácie nad databázou, v tomto prípade vytvorenie nového záznamu o študentovi Petrovi. Tento objekt je tiež zodpovedný za vykonávanie množstva systémových funkcií, ktoré transakciu sprevádzajú. Príkladmi transakčných manažérov sú napríklad BDE (používa sa na prístup k databázam Paradox, Dbase atď. z aplikácií Delphi), ADO (používa sa na prístup k databázam MS Access z rôznych aplikácií).

Sekvenčný diagram pre zadanie nového záznamu o študentovi do AWS tajomníka katedry je na obr. 7.

Ryža. 7. Zadávanie údajov o študentovi. Sekvenčný diagram.

V sekvenčnom diagrame definujeme prenos správ medzi objektmi: vytvoriťNovýnahrávanie(vysielané od objektu k objektu až do konca reťazca ako správa uložiťnahrávanie); otvorenétvar(do vstupného formulára); predstaviťF.A O.,adresu. ( zadávanie údajov študenta), potom sú tieto údaje vysielané prostredníctvom správ uložiťF.A O.,adresu. Od manažértransakcií odoslať správu zbierať informácieOštudent poskytovanie spätnej väzby do databázy a nakoniec reflexná správa manažértransakcií pomenovaný ako uložiťnahrávanievDB, zabezpečuje ukončenie transakcie.

V prípade potreby môže byť táto interakcia reprezentovaná kooperačným diagramom, znázorňujúcim predovšetkým štrukturálny aspekt interakcie (obr. 8). Tento diagram je možné zostaviť z predchádzajúceho v automatickom režime (v Rational Rose stlačením klávesu F5).

Ryža. 8. Zadávanie údajov o študentovi. Schéma spolupráce.

V prípade potreby je možné projekt doplniť o ďalšie interakčné diagramy, ktoré odhaľujú prácu prípadov použitia.

4.3 Vývoj profilu relačnej databázy

V prípade, že je na implementáciu systému použitý objektovo orientovaný DBMS (OODBMS), je objektový diagram zostrojený v predchádzajúcej časti finálnym modelom a priamym návodom na implementáciu informačného systému. V rovnakom prípade, keď sa má ako informačné jadro informačného systému použiť relačná databáza (RDB), je potrebné vypracovať ďalší diagram, profilový diagram relačnej databázy.

Profil UML pre databázový projekt je rozšírenie UML, ktoré zachováva metamodel UML nedotknutý. Profil pre databázový projekt pridáva stereotypy a označené hodnoty pripojené k týmto stereotypom, ale nemení základný metamodel UML. Pre vizualizáciu navrhnutých databázových prvkov a pravidiel návrhu pre relačné databázy boli do profilu (ďalej len databázy) pridané príslušné ikony. Databáza je opísaná pomocou tabuliek, stĺpcov a vzťahov. Profil obsahuje prvky, ktoré rozširujú databázu, ako sú spúšťače, uložené procedúry, obmedzenia, užívateľom definované typy (domény), zobrazenia a iné. Profil ukazuje, ako a kde použiť všetky tieto prvky v modeli. V profile databázy UML sú definované nasledujúce entity:

tabuľky ( Tabuľka) - množina záznamov v databáze pre konkrétny objekt, pozostáva zo stĺpcov.

Stĺpec ( Column) je komponent tabuľky obsahujúci jeden z atribútov tabuľky (pole tabuľky).

Primárny kľúč ( Primárny kľúč) – možný kľúč vybraný na identifikáciu riadkov tabuľky.

Vonkajšie kľúč ( Cudzí kľúč) - jeden alebo viac stĺpcov jednej tabuľky, ktoré sú primárnymi kľúčmi inej tabuľky.

Výkon ( View) je virtuálna tabuľka, ktorá sa z pohľadu používateľa správa presne ako bežná tabuľka, ale sama o sebe neexistuje.

Uložené postup ( Uložená procedúra) je nezávislá procedurálna funkcia vykonávaná na serveri.

domény ( Domény) je platná množina hodnôt pre atribút alebo stĺpec.

Okrem týchto entít je možné zaviesť niektoré ďalšie entity, ktoré odrážajú špecifické aspekty databázového modelu.

Podobné dokumenty

Metodiky rozvoja informačných systémov v domácej a zahraničnej literatúre. Štátne a medzinárodné štandardy v oblasti vývoja softvéru. Vývoj fragmentu výchovno-metodického zdrojového informačného systému.

ročníková práca, pridaná 28.05.2009


Definícia pojmu „systém“. História vývoja a vlastnosti moderných informačných systémov. Hlavné etapy vývoja automatizovaného informačného systému. Používanie domácich a medzinárodných štandardov v oblasti informačných systémov.

prezentácia pridaná dňa 14.10.2013


Hlavná myšlienka metodológie a princípov RAD-vývoja informačných systémov, jej hlavné výhody. Dôvody popularity, vlastnosti aplikácie technológie. Formulácia základných princípov rozvoja. Vývojové prostredia využívajúce princípy RAD.

prezentácia pridaná dňa 04.02.2013


Úloha riadiacej štruktúry v informačnom systéme. Príklady informačných systémov. Štruktúra a klasifikácia informačných systémov. Informačné technológie. Etapy vývoja informačných technológií. Druhy informačných technológií.

semestrálna práca pridaná 17.06.2003


Koncepcia CASE-tools ako softvérových nástrojov, ktoré podporujú tvorbu a údržbu informačných systémov (IS). Vlastnosti IDEF-technológie vývoja IS. Popis notácie IDEF0. Vývoj funkčných modelov podnikového procesu.

prezentácia pridaná dňa 04.07.2013


Podstata jednotného modelovacieho jazyka, jeho konceptuálny model a princíp fungovania, všeobecné pravidlá a mechanizmy. Modelovanie konceptu „kompetencie“. Diagram tried popisujúci vzdelávací proces. Implementácia daného informačného systému.

práca, pridané 17.02.2015


Vývoj informačných systémov. Moderný trh finančného a ekonomického aplikovaného softvéru. Výhody a nevýhody implementácie automatizovaných informačných systémov. Metódy navrhovania automatizovaných informačných systémov.

práca, pridané 22.11.2015


Pojem informačný systém, typy informačných systémov. Analýza nástrojov pre vývoj automatizovaných informačných systémov. Požiadavky na program a softvérový produkt. Vývoj foriem grafického rozhrania a databáz.

práca, pridané 23.06.2015


Riešenie informačnej bezpečnosti. Systémy pre dátové centrá. Čo je hardvér dátového centra. Základné pojmy a princípy modelovania. Výber metódy riešenia problémov. Zoitendijkova metóda prípustných smerov, Frank – Wolfeov algoritmus.

semestrálna práca pridaná 18.05.2017


Koncepcia informačného systému. Etapy vývoja informačných systémov. Procesy v informačnom systéme. Informačný systém na hľadanie trhových medzier, na znižovanie výrobných nákladov. Štruktúra informačného systému. Technická podpora.

MINISTERSTVO ŠKOLSTVA RUSKEJ FEDERÁCIE ŠTÁTNA TECHNICKÁ UNIVERZITA UĽANOVSK V.S. SCHKLEIN MODELOVANIE INFORMAČNÝCH SYSTÉMOV Poznámky z prednášky pre študentov smeru 652100 "Konštrukcia lietadiel" University of Shcheklein V.S. Щ Modelovanie informačných systémov: poznámky z prednášok / V.S. SHCHEKLEIN. - Uljanovsk: UlSTU, 2002 .-- s. Poznámky z prednášok sú výberom materiálu použitého v akademickom roku 1999/2000 pri vyučovaní v disciplíne "Modelovanie informačných systémov". Je určený pre študentov odborov: 130107 „Softvérové ​​spracovanie konštrukčných materiálov“ a 130111 „Projektové riadenie leteckej výroby“. Táto príručka nie je úplná, plánuje sa zahrnúť nový vyvinutý materiál, ktorého výber a návrh sa vykonáva v súlade so schváleným programom disciplíny. 3 OBSAH ÚVOD ………………………………………………… .. JEHO IMPLEMENTÁCIA POMOCOU POČÍTAČA …………………………………………………………………… ………………………………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………………………………… …… 7 3. VŠEOBECNÉ ALGORITMY ŠTATISTICKEJ SIMULÁCIE ako DISTRIBÚCIA. SIMULÁCIA NÁHODNÝCH UDALOSTÍ …………………………………………………………… .. 5. PRÍSTUP K SIMULÁCII SYSTÉMOV …………………… ... 15 6. NASTAVENIE NÁHODNÝCH HODNOT A NÁHODNÉ UDALOSTI V EXCELI ………………………………………………………… ... 21 7. MODELOVANIE OZNAČENÝCH REŤAZÍ ……………………. 23 8. MODELOVANIE SYSTÉMOV HROMADNEJ OBSLUHY. 25 9. Štruktúra informačnej a výpočtovej systematickej TEM ...................................... ...................................... 26 9.1. Koncepcia procesu ………………………. ………………………… .. 28 9.2. Pracovná záťaž ………………………………………………………… 29 10. UKAZOVATELE VÝKONNOSTI INFORMAČNÉHO SYSTÉMU ………………………………………………………… … … …… .. 30 11. ODHAD VÝKONU KOMPONENTOV SYSTÉMU ………………………………………………………………….…. 31 12. HODNOTENIE ČINNOSTI SYSTÉMU VŠEOBECNE ……. 32 13. VPLYV REŽIMU SPRACOVANIA ÚDAJOV …………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………………………………… 36 …………………. 40 REFERENCIE …………………………………………. 46 4 ÚVOD Užitočnosť matematického modelovania pre riešenie praktických problémov vôbec nevyvoláva pochybnosti. Môže sa naskytnúť otázka, prečo je potrebné ovládať modelovanie informačných systémov (a dnes si tieto systémy bez výpočtovej techniky už ani nemožno predstaviť) pre leteckých konštruktérov zameraných na technológiu výroby lietadiel? Moderné technológie sa čoraz viac automatizujú. Moderný výrobca lietadiel, či už je to konštruktér alebo technológ, musí pri svojej práci využívať počítače. Pri riešení technických problémov existuje nebezpečenstvo nedostatočného hodnotenia schopností počítača. To môže viesť buď k odmietnutiu automatizácie jedného alebo druhého fragmentu technologického procesu, alebo k neoprávneným výdavkom na výpočtové vybavenie, ktorého možnosti sú v porovnaní s potrebnými značne nadhodnotené. V tomto prípade môže takzvaný zdravý rozum viesť k závažným chybám v hodnotení. Cieľom disciplíny je vybaviť mladého odborníka aparátom na vyhodnocovanie informačných a výpočtových systémov tak, aby automatizačné prostriedky správne zapasoval do kontúr výroby či riadenia. Okrem toho, modelovaním určitých systémov študenti získavajú nepriame skúsenosti s optimalizáciou systémov a posilňujú zručnosti používania počítača pri riešení odborných problémov. 1. ZÁKLADNÉ KONCEPTY TEÓRIE MODELOVANIA Modelovanie je nahrádzanie jedného objektu druhým s cieľom získať informácie o najdôležitejších vlastnostiach objektu - originálu pomocou objektu - modelu. Model (francúzsky modele z lat. modulas - miera, vzorka): 1) vzorka pre sériovú výrobu produktu; značka produktu; 2) produkt, z ktorého je formulár odstránený (šablóny, vzory, námestia); 3) osoba alebo predmet zobrazený umelcom; 4) zariadenie, ktoré reprodukuje štruktúru alebo činnosť akéhokoľvek iného zariadenia; 5) akýkoľvek obraz objektu, procesu alebo javu použitý ako reprezentant originálu (obraz, diagram, kresba, mapa); 6) matematický aparát opisujúci objekt, proces alebo jav; 7) zariadenie na získanie odtlačku v odlievacej forme. V nasledujúcom texte, pokiaľ nie je uvedené inak, bude model chápaný ako matematický aparát. Všetky modely majú určitú štruktúru (statickú alebo dynamickú, materiálovú alebo ideálnu), ktorá je podobná štruktúre pôvodného objektu. V procese práce model vystupuje ako relatívne samostatný kvázi objekt, čo umožňuje získať počas výskumu určité poznatky o samotnom objekte. Ak sa výsledky takejto štúdie (modelovania) potvrdia a môžu slúžiť ako základ pre prognózovanie v skúmaných objektoch, potom hovoria, že model je adekvátny objektu. V tomto prípade primeranosť modelu závisí od účelu modelovania a prijatých kritérií. Proces modelovania predpokladá prítomnosť: - objektu výskumu; - výskumník so špecifickou úlohou; - model vytvorený na získanie informácií o objekte potrebných na riešenie problému. Vo vzťahu k modelu je výskumník experimentátorom. Treba mať na pamäti, že každý experiment môže mať v určitej oblasti vedy a techniky významný význam len so špeciálnym spracovaním jeho výsledkov. Jedným z najdôležitejších aspektov modelovania systémov je problém cieľa. Akýkoľvek model je zostavený v závislosti od cieľa stanoveného výskumníkom, preto je jedným z hlavných problémov pri modelovaní problém zadania cieľa. Podobnosť procesu prebiehajúceho v modeli so skutočným procesom nie je samoúčelná, ale podmienkou správneho fungovania modelu. Ako cieľ by mala byť stanovená úloha študovať akýkoľvek aspekt fungovania objektu. Ak sú ciele modelovania jasné, potom nastáva ďalší problém, problém zostavenia modelu. Táto konštrukcia sa ukáže ako možná, ak existujú informácie alebo hypotézy týkajúce sa štruktúry, algoritmov a parametrov skúmaného objektu. Treba zdôrazniť úlohu výskumníka v procese budovania modelu, tento proces je tvorivý, založený na vedomostiach, skúsenostiach, heuristike. Formálne metódy, ktoré umožňujú dostatočne presný popis systému alebo procesu, sú neúplné alebo jednoducho chýbajú. Preto je výber tej alebo onej analógie úplne založený na skúsenostiach výskumníka a chyby výskumníka môžu viesť k chybným výsledkom simulácie. Keď je model zostavený, potom za ďalší problém možno považovať problém práce s ním, implementáciu modelu. Tu je hlavnou úlohou minimalizovať čas na získanie konečných výsledkov a zabezpečiť ich spoľahlivosť. Pre správne zostavený model je charakteristické, že odhaľuje len tie zákonitosti, ktoré výskumník potrebuje, a neberie do úvahy vlastnosti systému - originálu, ktoré sú v danom momente nepodstatné. Klasifikácia typov systémového modelovania je znázornená na obr. 1.1. Matematické modelovanie je konštrukcia a použitie matematických modelov na štúdium správania sa systémov (objektov) v rôznych podmienkach, na získanie (výpočet) určitých charakteristík originálu bez vykonávania meraní alebo s ich malým počtom. V rámci matematického modelovania sa vyvinuli dva prístupy: - analytické; - imitácia. 6 Modelovanie systému Deterministické Stochastické Statické Dynamické Diskrétne Diskrétne Spojité Abstraktné Materiály Vizuálne Symbolické Matematické Prírodné fyzikálne Analytické Kombinované. Simulácia Obr. 1.1. Analytický prístup je založený na konštrukcii vzorcových závislostí spájajúcich parametre a prvky systému. Po dlhú dobu bol tento prístup vlastne matematickým prístupom. Pri zvažovaní zložitých systémov sú však prísne matematické závislosti veľmi zložité, na získanie požadovaných hodnôt parametrov je potrebný veľký počet meraní. Analýza charakteristík procesov fungovania komplexných systémov pomocou iba analytických výskumných metód naráža na značné ťažkosti, čo vedie k potrebe výrazne zjednodušiť modely buď vo fáze ich konštrukcie, alebo v procese práce s modelom, čo znižuje spoľahlivosť výsledkov. Simulačný (štatistický) prístup k modelovaniu je založený na použití Čebyševovej limitnej vety v pravdepodobnostnej reprezentácii parametrov systému. Na základe predbežnej štúdie modelovaného systému je celkom jednoduché určiť typy a hodnoty distribučných zákonov pre náhodné hodnoty parametrov. V rámci simulačného prístupu sa využívajú analytické závislosti medzi parametrami prvkov systému, tieto závislosti však majú zovšeobecnený, zjednodušený charakter. Sú oveľa jednoduchšie ako závislosti v analytickom prístupe. 7 Matematické modelovanie systémov vrátane informačných systémov je zamerané na optimalizáciu štruktúry systémov, výber najoptimálnejších režimov fungovania systémov, určenie požadovaných vlastností hardvéru a softvéru. Matematické modelovanie technologických procesov vrátane informačných procesov má za hlavné ciele nájsť optimálne alebo akceptovateľné charakteristiky samotného objektu, nájsť optimálne režimy spracovania, zaškoliť personál a zabezpečiť určité riadiace funkcie. V každom prípade musí modelovanie spĺňať nasledujúce požiadavky: - modely musia byť primerané zodpovedajúcim systémom alebo technologickým úlohám; - musí byť zabezpečená požadovaná presnosť; - pohodlie užívateľa - špecialistu na technológiu alebo spracovanie informácií (manažment) - by malo byť zabezpečené: - zrozumiteľné rozhranie pre riadenie modelovania; - dostatočná rýchlosť práce; - viditeľnosť výsledkov; - prijateľné náklady na vývoj a používanie simulačných nástrojov. 2. PODSTATA METÓDY ŠTATISTICKÝCH TESTOV A JEJ REALIZÁCIE S POMOCOU POČÍTAČA Metóda štatistického modelovania spočíva v reprodukovaní skúmaného procesu pomocou pravdepodobnostného matematického modelu a výpočte charakteristík tohto procesu. Metóda je založená na opakovanom testovaní zostrojeného modelu s následným štatistickým spracovaním získaných údajov za účelom stanovenia charakteristík posudzovaného procesu vo forme štatistických odhadov jeho parametrov. Uvažujme rovnicu: y = f (x, t, ξ), (2.1) kde y je systémový parameter, ktorý sa má určiť, x je fázová premenná, t je čas, ξ je náhodný parameter, ktorého distribučný zákon je nám známy. Ak je funkcia f v podstate nelineárna, potom neexistujú univerzálne metódy riešenia tohto problému a dostatočne rozvinuté regulárne metódy na nájdenie optimálnych riešení je možné aplikovať iba tak, že sa do popredia umiestni viditeľnosť použitia matematiky, zjednodušenia povedú k vážna strata presnosti. Matematický model sa stane neadekvátnym 8 pre skúmaný systém a modelovanie bude len formou klamu. Ak je však možné zostrojiť funkciu y = ϕ (ξ) a generátor náhodných čísel ξ 1, ξ 2, ..., ξ N s daným distribučným zákonom, potom hodnotu y možno vypočítať ako y = ∑ ϕ (ξ i) N, (2.2) kde ϕ (ξ 1) je hodnota i-tej realizácie. Ak f (x, t, ξ) je analytický model procesu transformácie informácie alebo technologického procesu spracovania súčiastky, potom ϕ (ξ) bude štatistický model. Niektoré princípy a techniky konštrukcie štatistických modelov budú diskutované neskôr. Dôležité je, že pri konštrukcii funkcie y = ϕ (ξ) a generátora náhodných čísel ξ 1, ξ 2, ..., ξ N na papieri je v drvivej väčšine prípadov celkom jednoduché ich implementovať na počítač pomocou vhodného softvéru. V tomto prípade budú výsledky obsahovať chybu, ale táto chyba je menšia ako chyby spôsobené predpokladmi v analytickom modeli. Okrem toho možno kvantifikovať chybu spôsobenú aplikáciou štatistického modelu. Táto technika je rozšírená aj na zložitejšie prípady, keď rovnica (2.1) obsahuje nielen náhodné parametre, ale aj náhodné funkcie. Po prijatí N realizácií do počítača nasleduje fáza spracovania štatistiky, ktorá umožňuje vypočítať spolu s matematickým očakávaním (2.2) ďalšie parametre ϕ (ξ), napríklad rozptyl D = 1 N * ∑ xi - 1 N 2 * (∑ xi). Pri metóde štatistických testov je na získanie dostatočne spoľahlivých výsledkov potrebné zabezpečiť veľké množstvo realizácií N, navyše pri zmene aspoň jedného počiatočného parametra úlohy je potrebné vykonať sériu opäť z N testov. Pri zložitých modeloch sa neodôvodnene veľká hodnota N môže stať faktorom, ktorý oneskorí prijatie výsledku. Preto je dôležité správne posúdiť požadovaný počet výsledkov. Interval spoľahlivosti ε, pravdepodobnosť spoľahlivosti α, rozptyl D a počet realizácií N sú vo vzťahu ε = D NФ −1 (α), kde Ф −1 (α) je funkcia inverzná k Laplaceovej funkcii. V praxi môžete použiť pomer N ≤ D ε 2 * 6,76 pre α ≥ 0,99, pričom z dôvodu spoľahlivosti vezmete najväčšiu hodnotu N z pomeru (). Odhad rozptylu D je možné získať vopred pomocou rovnakého štatistického modelu pre počet realizácií n, n<< N . 9 При построении статистических моделей информационных систем ис- пользуется общий и прикладной математический аппарат. В качестве приме- ра можно привести аппарат систем массового обслуживания. Система массо- вого обслуживания (СМО) - система, предназначенная для выполнения пото- ка однотипных требований случайного характера. Статистическое моделиро- вание СМО заключается в многократном воспроизведении исследуемого процесса (технического, социального и т.д.) при помощи вероятностной ма- тематической модели и соответствующей обработке получаемой при этом статистики. Существуют пакеты программ статистического моделирования СМО, однако они требуют определенных усилий для их освоения и не всегда доступны. Поэтому в рамках дисциплины предлагается достаточно простой подход, позволяющий с наименьшими затратами моделировать простые СМО. При этом предполагается, что пользователь ознакомлен с теорией мас- сового обслуживания и имеет навыки работы на компьютере. Следует пом- нить, что массовое обслуживание - важный, но далеко не единственный предмет статистического моделирования. На основе этого метода решаются, например, задачи физики (ядерной, твердого тела, термодинамики), задачи оптимизации маршрутов, моделирования игр и т.п. 3. ОБОБЩЕННЫЕ АЛГОРИТМЫ СТАТИСТИЧЕСКОГО МОДЕЛИРОВАНИЯ Существуют две схемы статистического моделирования: - моделирование по принципу особых состояний; - моделирование по принципу ∧ t . Порядок моделирования по принципу особых состояний заключается в выполнении следующих действий: 1) случайным образом определяется событие с минимальным временем - бо- лее раннее событие; 2) модельному времени присваивается значение времени наступления наибо- лее раннего события; 3) определяется тип наступившего события; 4) в зависимости от типа наступившего события осуществляется выполнение тех или иных блоков математической модели; 5) перечисленные действия повторяются до истечения времени моделирова- ния. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования хо- рошо подходит для систем массового обслуживания в традиционном их опи- сании. Обобщенный алгоритм моделирования по принципу особых состоя- ний представлен схемой на рис. 3.1. 10 н Определение времени наступления очередного события Корректировка текущего модельного времени Опр.типа соб Блок реакции 1 Блок реакции К нет Конец модел Да Рис. к Моделирование по принципу ∧ t осуществляется следующим образом: 1) устанавливаются начальные состояния, в т. ч. t = 0 ; 2) модельному времени дается приращение t = t + ∧t ; 3) на основе вектора текущих состояний элементов модели и нового значения времени рассчитываются новые значения этих состояний; за ∧ t может на- ступить одно событие, несколько событий или же может вообще не проис- ходить событий; пересчет состояния всех элементов системы – более тру- доемкая процедура, нежели любой из блоков реакции модели, построенной по принципу особых состояний; 4) если не превышено граничное время моделирования, предыдущие пункты повторяются. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования применима для более широкого круга систем, нежели моделирование по принципу особых событий, однако есть проблемы с определением ∧ t . Если задать его слишком большим - теряется точность, слишком малым - возрас- тает время моделирования. На основе базовых схем моделирования можно строить комбинирован- ные и диалоговые схемы, в которых моделирование идет под контролем опе-

Pri koncepčnom návrhu IS sa využíva množstvo popisov špecifikácií (požiadavky, podmienky, obmedzenia a pod.), medzi ktorými ústredné miesto zaujímajú modely transformácie, uchovávania a prenosu informácií. Modely získané štúdiom predmetnej oblasti sa v priebehu vývoja IS menia a stávajú sa modelmi navrhovaného IS.

Rozlišujte medzi funkčnými, informačnými, behaviorálnymi a štrukturálnymi modelmi. Funkčný model systému popisuje množinu funkcií vykonávaných systémom. Informačné modely odrážajú dátové štruktúry – ich zloženie a vzťahy. Behaviorálne modely popisujú informačné procesy (dynamiku fungovania), zahŕňajú také kategórie ako stav systému, udalosť, prechod z jedného stavu do druhého, podmienky prechodu, sled udalostí. Štrukturálne modely charakterizujú morfológiu systému (jeho konštrukciu) - skladbu subsystémov, ich vzájomné prepojenia.

Existuje množstvo spôsobov, ako zostaviť a reprezentovať modely, ktoré sa líšia pre rôzne typy modelov. Základom je štrukturálna analýza - metóda štúdia systému, ktorá začína jeho všeobecným prehľadom a potom prechádza do detailov, tvoriac hierarchickú štruktúru s narastajúcim počtom úrovní.

V tomto návode sa budeme zaoberať metodológiou konštrukcie štruktúrno-funkčných a informačných modelov IP a na ich základe navrhnúť relačné databázy, pričom tento proces ilustrujeme konkrétnym vzdelávacím príkladom nasledujúceho obsahu.

V súvislosti s diverzifikáciou aktivít bola od vedenia spoločnosti Bezenchuk and Companions prijatá objednávka na vývoj informačného systému s cieľom zefektívniť riadenie.

Firma sa zaoberá výrobou a predajom nábytku. K dispozícii je katalóg typického nábytku vyrábaného spoločnosťou. Zákazník si môže vybrať nábytok z katalógu a/alebo zadať objednávku podľa vlastného popisu. Po vytvorení objednávky je vyhotovená zmluva. Spoločnosť prijíma starý nábytok od nových zákazníkov nábytku, ktorého náklady sú odpočítané z ceny objednávky. Akceptovaný starý nábytok je daný na predaj alebo je možné ho prenajať. Neprevzatý starý nábytok je po určitom čase odovzdaný do skladu na drevo. Je vedený archív s informáciami o zrealizovaných objednávkach. Klienti, ktorí už predtým so spoločnosťou uzatvorili zmluvy, získavajú pri uzatvorení novej zmluvy zľavu. Materiály a komponenty potrebné na výrobu nábytku získava spoločnosť od dodávateľov.

Funkčné modelovanie IC

Existuje niekoľko rôznych techník a nástrojov na vývoj štrukturálnych a funkčných modelov duševného vlastníctva. Jednou z najpoužívanejších je metóda založená na konštrukcii diagramov toku dát (DFD - Data Flow Diagrams)

Diagram toku údajov

DFD je metóda štrukturálnej analýzy, ktorá používa pojmy „tok údajov“ a „proces“ na opis systému ako súboru funkčných komponentov (procesov) spojených tokom údajov. V súlade so základným princípom štrukturálnej analýzy je popis systému založený na postupnom upresňovaní jeho funkcií, ktoré je zobrazené vo forme hierarchicky usporiadaného súboru grafických obrázkov (diagramov).

Hlavnými prvkami diagramov toku údajov sú: externé entity; procesy; Zariadenia na ukladanie údajov; dátové toky. Každý takýto prvok má štandardné grafické znázornenie.

Externá entita je objekt, ktorý je zdrojom alebo príjemcom informácií, napríklad zákazníci, personál, dodávatelia, zákazníci, sklad. Definícia nejakého objektu alebo systému ako externej entity naznačuje, že je mimo hraníc navrhovaného IS.

Externé entity vo vyššie uvedenom príklade budú predstavovať zákazníkov nábytku, dodávateľov materiálu, sklad a niektoré ďalšie objekty v predmetnej oblasti. Príklady ich grafických obrázkov:

Funkcie navrhovaného IS v modeli DFD by mali byť reprezentované vo forme procesov, ktoré transformujú vstupné dátové toky na výstupné dáta v súlade s určitými algoritmami. Samotné dátové toky sú mechanizmom, ktorý simuluje prenos informácií zo zdroja do prijímača (z jednej časti systému do druhej). Tok údajov v diagrame je znázornený čiarou končiacou šípkou, ktorá označuje smer toku. Každý dátový tok by mal mať názov, ktorý odráža jeho obsah.

Napríklad funkcia IS určená na vytvorenie objednávky nábytku a uzavretie zmluvy na jeho výrobu môže byť v diagrame znázornená procesom „objednávka nábytku“. Tento proces by mal ako vstupné údaje získať informácie o zákazníkovi, ktoré sú potrebné na uzavretie zmluvy a informácie o ním objednanom nábytku (typ, popis, rozmery a pod.). Grafické znázornenie tohto procesu a zodpovedajúcich dátových tokov:

Zariadenie na ukladanie údajov (úložisko) je abstraktné zariadenie na ukladanie informácií, ktoré je možné kedykoľvek vložiť do pamäťového zariadenia a získať pre ďalšie použitie. Informácie do disku môžu pochádzať z externých subjektov a procesov, môžu to byť aj spotrebitelia informácií uložených v jednotke. Grafika pohonu:

Kontextový diagram

Diagram vyššej úrovne hierarchie, ktorý fixuje hlavné procesy alebo subsystémy IS a ich vzťah k externým entitám (vstupy a výstupy systému), sa nazýva kontextový diagram. Typicky sa pri navrhovaní relatívne jednoduchých integrovaných obvodov vytvára jediný kontextový diagram s hviezdicovou topológiou, v strede ktorého je hlavný proces spojený s umývadlami a zdrojmi informácií (používatelia a iné externé systémy). Hoci sa kontextový diagram môže zdať triviálny, jeho nepochybná užitočnosť spočíva v tom, že určuje hranice analyzovaného systému a definuje hlavný účel systému. Toto nastavuje kontext, v ktorom existujú diagramy nižšej úrovne s ich procesmi, tokmi a akumulátormi.

Kontextový diagram pre vyššie uvedený príklad je znázornený na obrázku 4.

Je potrebné poznamenať, že pre vzdelávacie účely je nižšie uvažovaná zjednodušená verzia modelov systému, v ktorej nebudú prezentované dátové toky a procesy súvisiace s finančnou stránkou činnosti spoločnosti. Aj keď, samozrejme, pre každú spoločnosť sú včasné, úplné a spoľahlivé informácie o jej finančnej situácii životne dôležité. V tomto príklade je „finančná zložka“ zjavne prítomná v interakcii spoločnosti so všetkými externými entitami znázornenými v kontextovom diagrame.

Externé entity zastúpené v tomto diagrame vystupujú ako zdroje informácií, ktoré sa ukladajú a spracúvajú v IS podniku a ako spotrebitelia týchto informácií. V tomto modeli sa rozlišujú dva subjekty „klient“, čo sú obrazy skutočných klientov firmy: „zákazník“ a „kupujúci“, keďže existujú výrazné rozdiely v obsahu informácií, ktoré si vymieňajú s IS.

Pre „zákazníka-zákazníka“ je dátový tok „katalóg“ popisom typického nábytku vyrábaného spoločnosťou. Dátový tok „objednávka“ môže obsahovať informácie o objednávaní nábytku vybraného z katalógu a/alebo zákazníkovi popis nábytku, ktorý nie je v katalógu, a prípadne aj informácie o starom nábytku, ktorý zákazník predal firme.

Pre „zákazníka-kupujúceho“ je dátový tok „katalóg starého nábytku“ informáciou o dostupnom starom nábytku získanom od zákazníkov. Stream "výkup/prenájom starého nábytku" je informácia o klientom vybranom starom nábytku, ktorý si želá kúpiť alebo prenajať.

Zároveň sú v praxi možné situácie, keď „zákazník-zákazník“ a „zákazník-zákazník“ bude jedna a tá istá osoba.