MINISTERUL EDUCAȚIEI AL UNIVERSITĂȚII TEHNICE DE STAT ULYANOVSK V.S. SCHEKLEIN MODELAREA SISTEMELOR INFORMAȚIONALE Note de curs pentru studenții direcției 652100 „Inginerie aeronautică” Ulyanovsk 2002 2 UDC 621.9.06-5229 din universitatea VS. Щ Modelarea sistemelor informaţionale: note de curs / V.S. SCHEKLEIN. - Ulianovsk: UlGTU, 2002. - p. Notele de curs sunt o selecție a materialelor utilizate în anul universitar 1999/2000 la desfășurarea orelor la disciplina „Modelarea sistemelor informaționale”. Destinat studenților specializărilor: 130107 „Program de prelucrare a materialelor structurale” și 130111 „Managementul proiectelor producției aviatice”. Acest manual nu este complet, este planificat să includă material nou dezvoltat, a cărui selecție și proiectare se efectuează în conformitate cu programul aprobat al disciplinei. 3 CUPRINS INTRODUCERE …………………………………………………………………… 4 1. CONCEPTE DE BAZĂ ALE TEORIEI MODELARII ………... 4 IMPLEMENTAREA SA CU AJUTORUL UN CALCULATOR …………… 7 3. ALGORITMI GENERALIZATI DE MODELARE STATISTICĂ ………………………………………………………………… 9 4. SIMULAREA VARIABILELOR ALEATORII CU UN DAT DISTRIBUȚII DE LEGEA. SIMULAREA EVENIMENTELOR ALEATOARE ……………………………………………………….. 5. ABORDAREA MODELAREA SISTEMULUI …………... 15 6. ATRIBUIREA ALEATORII VALORI ȘI EVENIMENTE ALEATOARE ÎN EXCEL ………………………………………………………... 21 7. MODELAREA LANȚURILOR MARKOV ……………………. 23 8. MODELAREA SISTEMELOR DE COZI. 25 9. Structura sistemelor informatice și de calcul ........................................ ......................................... 26 9.1. Conceptul de proces …………………………………………………………….. 28 9.2. Volumul de muncă ……………………………………………………… 29 10. INDICATORI DE PERFORMANȚĂ A SISTEMELOR DE INFORMAȚII …………………………………………………… …… ……….. 30 11. EVALUAREA PERFORMANȚEI COMPONENTELOR SISTEMULUI ………………………………………………………………………….….…. 31 12. EVALUAREA PERFORMANȚEI GENERALE A SISTEMULUI ……. 32 13. INFLUENȚA MODULUI DE PRELUCRARE A DATELOR ………….. 35 14. CARACTERISTICI DE FIABILITATE ………………………………… 36 15. CONSTRUIREA UNUI MODEL MATEMATIC AL SISTEMULUI INFORMAȚIONAL … …………………………………. 40 REFERINȚE ……………………………………. 46 4 INTRODUCERE Utilitatea modelării matematice pentru rezolvarea problemelor practice este dincolo de orice îndoială. Poate apărea întrebarea, de ce este necesară stăpânirea modelării sistemelor informaționale (și acum aceste sisteme nu pot fi imaginate fără tehnologia computerizată) pentru producătorii de avioane axați pe tehnologia de producție a aeronavelor? Tehnologia modernă devine din ce în ce mai automatizată. Un constructor modern de avioane, fie că este proiectant sau tehnolog, trebuie să folosească computere în munca sa. Există pericolul unei evaluări inadecvate a capacităților unui computer atunci când se rezolvă probleme de inginerie. Aceasta poate duce fie la refuzul automatizării unuia sau altul fragment al procesului tehnologic, fie la cheltuieli nejustificate pentru echipamente informatice, ale căror capacități sunt mult supraevaluate față de cele necesare. În acest caz, așa-numitul bun simț poate duce la grave erori de evaluare. Scopul disciplinei este de a dota un tânăr specialist cu un aparat de evaluare a sistemelor informatice și de calcul, astfel încât să poată integra cu competență instrumentele de automatizare în contururile producției sau managementului. În plus, prin modelarea anumitor sisteme, studenții dobândesc experiență indirectă în optimizarea sistemelor și consolidează abilitățile de utilizare a computerului în rezolvarea problemelor profesionale. 1. CONCEPTE DE BAZĂ ALE TEORIEI MODELĂRII Modelarea este înlocuirea unui obiect cu altul pentru a obține informații despre cele mai importante proprietăți ale obiectului - originalul cu ajutorul obiectului - model. Model (franceză modele din latină modulas - măsură, eșantion): 1) o probă pentru producția în masă a unui produs; marca produsului; 2) produsul din care se îndepărtează forma (şabloane, modele, pieţe); 3) persoana sau obiectul reprezentat de artist; 4) un dispozitiv care reproduce structura sau acțiunea unui alt dispozitiv; 5) orice imagine a unui obiect, proces sau fenomen folosit ca reprezentativ al originalului (imagine, diagramă, desen, hartă); 6) aparat matematic care descrie un obiect, un proces sau un fenomen; 7) un dispozitiv pentru obținerea unei amprente într-o matriță. În cele ce urmează, dacă nu se specifică altfel, un model va fi înțeles ca un aparat matematic. Toate modelele se caracterizează prin prezența unei structuri (statice sau dinamice, materiale sau ideale), care este similară cu structura obiectului - originalul. În procesul de lucru, modelul acționează ca un cvasi-obiect relativ independent, ceea ce face posibilă obținerea unor cunoștințe despre obiectul însuși în timpul studiului. Dacă rezultatele unui astfel de studiu (modelare) sunt confirmate și pot servi drept bază pentru prognoza în obiectele studiate, atunci se spune că modelul este adecvat obiectului. În acest caz, adecvarea modelului depinde de scopul modelării și de criteriile acceptate. Procesul de modelare presupune prezenţa: - obiectului de studiu; - un cercetător cu o sarcină specifică; - un model creat pentru a obține informații despre obiectul necesare pentru rezolvarea problemei. În raport cu modelul, cercetătorul este un experimentator. Trebuie avut în vedere faptul că orice experiment poate avea o importanță semnificativă într-un anumit domeniu al științei și tehnologiei numai dacă rezultatele sale sunt procesate special. Unul dintre cele mai importante aspecte ale modelării sistemelor este problema obiectivului. Orice model este construit în funcție de scopul pe care cercetătorul și-l stabilește, așa că una dintre principalele probleme în modelare este problema scopului urmărit. Asemănarea procesului care are loc în model cu procesul real nu este un scop în sine, ci o condiție pentru funcționarea corectă a modelului. Ca scop, ar trebui stabilită sarcina de a studia orice aspect al funcționării obiectului. Dacă obiectivele modelării sunt clare, atunci apare următoarea problemă, problema construirii modelelor. Această construcție este posibilă dacă sunt disponibile informații sau sunt formulate ipoteze privind structura, algoritmii și parametrii obiectului studiat. Trebuie subliniat rolul cercetătorului în procesul de construire a unui model; acest proces este creativ, bazat pe cunoștințe, experiență și euristică. Metodele formale care permit o descriere suficient de precisă a unui sistem sau proces sunt incomplete sau pur și simplu absente. Prin urmare, alegerea acestei sau acelea analogii se bazează complet pe experiența existentă a cercetătorului, iar greșelile cercetătorului pot duce la rezultate eronate de modelare. Când modelul este construit, următoarea problemă poate fi considerată problema lucrului cu acesta, implementarea modelului. Aici, principalele sarcini sunt minimizarea timpului de obținere a rezultatelor finale și asigurarea fiabilității acestora. Pentru un model construit corect, este caracteristic că dezvăluie doar acele regularități de care are nevoie cercetătorul și nu ia în considerare proprietățile sistemului - originalul, care nu sunt esențiale în acest moment. Clasificarea tipurilor de modelare a sistemului este prezentată în fig. 1.1. Modelarea matematică este construcția și utilizarea modelelor matematice pentru a studia comportamentul sistemelor (obiectelor) în diferite condiții, pentru a obține (calcula) anumite caracteristici ale originalului fără măsurători sau cu un număr mic al acestora. În cadrul modelării matematice s-au dezvoltat două abordări: - analitice; - imitație. 6 Sisteme de modelare Determinist Stochastic Static Dinamic Discret Discret Continu Continuu Abstract Material Vizual Simbolic Matematic Natural Fizic Analitic Combinat. Simulare Fig. 1.1. Abordarea analitică se bazează pe construirea de dependențe de formule care leagă parametrii și elementele sistemului. O astfel de abordare a fost multă vreme abordarea matematică adecvată. Cu toate acestea, atunci când se iau în considerare sisteme complexe, dependențele matematice stricte sunt foarte complexe și sunt necesare un număr mare de măsurători pentru a obține valorile parametrilor necesare. Analiza caracteristicilor proceselor de funcționare a sistemelor complexe folosind doar metode de cercetare analitică întâmpină dificultăți semnificative, conducând la necesitatea unei simplificări semnificative a modelelor fie în stadiul construcției lor, fie în procesul de lucru cu modelul, care reduce fiabilitatea rezultatelor. Abordarea de simulare (statistică) în modelare se bazează pe utilizarea teoremei limitei Chebyshev în reprezentarea probabilistică a parametrilor sistemului. Pe baza unui studiu preliminar al sistemului simulat, se determină destul de simplu tipurile și valorile legilor de distribuție a variabilelor aleatoare ale parametrilor. Ca parte a abordării simulării, sunt utilizate dependențe analitice între parametrii elementelor sistemului, însă aceste dependențe sunt mai generalizate, simplificate. Ele sunt mult mai simple decât dependențele în cadrul abordării analitice. 7 Modelarea matematică a sistemelor, inclusiv a sistemelor informaționale, vizează optimizarea structurii sistemelor, alegerea celor mai optime moduri de funcționare a sistemelor, determinarea caracteristicilor necesare hardware și software. Modelarea matematică a proceselor tehnologice, inclusiv a celor informaționale, are ca obiectiv principal găsirea caracteristicilor optime sau acceptabile ale obiectului însuși, găsirea modurilor optime de procesare, instruirea personalului și asigurarea anumitor funcții de control. În orice caz, modelarea trebuie să îndeplinească următoarele cerințe: - modelele să fie adecvate sistemelor sau sarcinilor tehnologice corespunzătoare; - trebuie asigurată precizia necesară; - comoditatea utilizatorului - ar trebui asigurată un specialist în tehnologie sau prelucrare (management) a informațiilor: - o interfață de management de simulare ușor de înțeles; - viteza suficienta de lucru; - vizibilitatea rezultatelor; - cost acceptabil de dezvoltare și utilizare a instrumentelor de modelare. 2. ESENȚA METODEI DE TESTARE STATISTICĂ ȘI IMPLEMENTAREA EI CU AJUTORUL UNUI CALCULATOR Metoda modelării statistice constă în reproducerea procesului studiat folosind un model matematic probabilistic și calcularea caracteristicilor acestui proces. Metoda se bazează pe testarea repetată a modelului construit cu prelucrarea statistică ulterioară a datelor obținute pentru a determina caracteristicile procesului luat în considerare sub forma unor estimări statistice ale parametrilor acestuia. Luați în considerare ecuația: y \u003d f (x, t, ξ) , (2.1) unde y este un parametru de sistem care trebuie determinat, x este o variabilă de fază, t este timpul, ξ este un parametru aleatoriu a cărui lege de distribuție este cunoscut de noi. Dacă funcția f este esențial neliniară, atunci nu există metode universale de rezolvare pentru rezolvarea acestei probleme, iar metodele obișnuite suficient de bine dezvoltate pentru găsirea soluțiilor optime pot fi aplicate doar punând vizibilitatea utilizării matematicii în prim-plan, simplificările vor duce la o pierdere serioasă de precizie. Modelul matematic va deveni inadecvat pentru sistemul studiat, iar modelarea va fi doar o formă de iluzie. Totuși, dacă este posibil să se construiască o funcție y = ϕ (ξ) și un generator de numere aleatoare ξ 1 , ξ 2 , ... , ξ N cu o lege de distribuție dată, atunci valoarea lui y poate fi calculată ca y = ∑ ϕ (ξ i) N , (2.2) unde ϕ (ξ 1) este valoarea i --a realizare. Dacă f (x, t , ξ) este un model analitic al procesului de conversie a informațiilor sau al procesului tehnologic de prelucrare a unei piese, atunci ϕ (ξ) va fi un model statistic. Unele principii și tehnici de construire a modelelor statistice vor fi discutate mai târziu. Este important ca atunci când construim funcția y = ϕ (ξ) și generatorul de numere aleatoare ξ 1 , ξ 2 , ... , ξ N pe hârtie, în majoritatea cazurilor este destul de ușor să le implementezi pe un computer în cadrul cadrul software-ului corespunzător. În acest caz, rezultatele vor conține o eroare, dar această eroare este mai mică decât erorile din cauza ipotezelor din modelul analitic. În plus, eroarea datorată aplicării modelului statistic poate fi cuantificată. Această tehnică poate fi extinsă și la cazuri mai complicate, când ecuația (2.1) conține nu numai parametri aleatori, ci și funcții aleatorii. După primirea N realizări pe calculator, urmează etapa de prelucrare statistică, care permite calcularea, alături de așteptarea matematică (2.2), a altor parametri ϕ (ξ) , de exemplu, varianța D = 1 N * ∑ xi − 1 N 2* (∑ xi) . În metoda de testare statistică, pentru a obține rezultate suficient de fiabile, este necesar să se prevadă un număr mare de implementări N , în plus, cu modificarea a cel puțin unui parametru inițial al problemei, este necesar să se efectueze o serie din N teste din nou. Cu modele complexe, o valoare nerezonabil de mare a lui N poate deveni un factor care întârzie primirea rezultatului. Prin urmare, este important să estimați corect numărul necesar de rezultate. Intervalul de încredere ε , probabilitatea de încredere α , varianța D și numărul realizărilor N sunt legate prin relația ε = D NФ −1 (α) , unde Ф −1 (α) este funcția inversă a funcției Laplace. În practică, puteți utiliza raportul N ≤ D ε 2 * 6,76 pentru α ≥ 0,99, luând, de dragul fiabilității, cea mai mare valoare a lui N din raportul (). O estimare a varianței D poate fi obținută anterior folosind același model statistic cu numărul de realizări n , n<< N . 9 При построении статистических моделей информационных систем ис- пользуется общий и прикладной математический аппарат. В качестве приме- ра можно привести аппарат систем массового обслуживания. Система массо- вого обслуживания (СМО) - система, предназначенная для выполнения пото- ка однотипных требований случайного характера. Статистическое моделиро- вание СМО заключается в многократном воспроизведении исследуемого процесса (технического, социального и т.д.) при помощи вероятностной ма- тематической модели и соответствующей обработке получаемой при этом статистики. Существуют пакеты программ статистического моделирования СМО, однако они требуют определенных усилий для их освоения и не всегда доступны. Поэтому в рамках дисциплины предлагается достаточно простой подход, позволяющий с наименьшими затратами моделировать простые СМО. При этом предполагается, что пользователь ознакомлен с теорией мас- сового обслуживания и имеет навыки работы на компьютере. Следует пом- нить, что массовое обслуживание - важный, но далеко не единственный предмет статистического моделирования. На основе этого метода решаются, например, задачи физики (ядерной, твердого тела, термодинамики), задачи оптимизации маршрутов, моделирования игр и т.п. 3. ОБОБЩЕННЫЕ АЛГОРИТМЫ СТАТИСТИЧЕСКОГО МОДЕЛИРОВАНИЯ Существуют две схемы статистического моделирования: - моделирование по принципу особых состояний; - моделирование по принципу ∧ t . Порядок моделирования по принципу особых состояний заключается в выполнении следующих действий: 1) случайным образом определяется событие с минимальным временем - бо- лее раннее событие; 2) модельному времени присваивается значение времени наступления наибо- лее раннего события; 3) определяется тип наступившего события; 4) в зависимости от типа наступившего события осуществляется выполнение тех или иных блоков математической модели; 5) перечисленные действия повторяются до истечения времени моделирова- ния. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования хо- рошо подходит для систем массового обслуживания в традиционном их опи- сании. Обобщенный алгоритм моделирования по принципу особых состоя- ний представлен схемой на рис. 3.1. 10 н Определение времени наступления очередного события Корректировка текущего модельного времени Опр.типа соб Блок реакции 1 Блок реакции К нет Конец модел Да Рис. к Моделирование по принципу ∧ t осуществляется следующим образом: 1) устанавливаются начальные состояния, в т. ч. t = 0 ; 2) модельному времени дается приращение t = t + ∧t ; 3) на основе вектора текущих состояний элементов модели и нового значения времени рассчитываются новые значения этих состояний; за ∧ t может на- ступить одно событие, несколько событий или же может вообще не проис- ходить событий; пересчет состояния всех элементов системы – более тру- доемкая процедура, нежели любой из блоков реакции модели, построенной по принципу особых состояний; 4) если не превышено граничное время моделирования, предыдущие пункты повторяются. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования применима для более широкого круга систем, нежели моделирование по принципу особых событий, однако есть проблемы с определением ∧ t . Если задать его слишком большим - теряется точность, слишком малым - возрас- тает время моделирования. На основе базовых схем моделирования можно строить комбинирован- ные и диалоговые схемы, в которых моделирование идет под контролем опе-

1 din 38

Prezentare pe tema: Modelarea sistemelor informatice

diapozitivul numărul 1

diapozitivul numărul 2

Descrierea diapozitivului:

Scopul cursului este aprofundarea disciplinelor de bază (informatica, matematică); formarea competenţelor pentru activităţi profesionale în domeniul modelării informaţionale Motivarea elevilor la alegerea unui CE. - testarea de către studenți a abilităților și interesului acestora pentru activități creative, de cercetare în domeniul modelării informaționale; - pregătirea pentru intrarea la universitate pentru specialități legate de modelarea informației și tehnologia computerelor: matematică aplicată, modelare, sisteme informatice etc.

diapozitivul numărul 3

Descrierea diapozitivului:

diapozitivul numărul 4

Descrierea diapozitivului:

Conţinutul manualului Capitolul 1. Modelarea sistemelor informaţionale 1.1. Sisteme informaționale și sistemologie 1.2. Model relațional și baze de date (Acces) 1.3. Foaia de calcul este un instrument de modelare a informațiilor 1.4. Programarea aplicaţiilor (elementele VBA pentru Excel) Capitolul 2. Modelare matematică pe calculator 2.1. Introducere în modelare 2.2. Instrumente de modelare matematică pe calculator (Excel, MathCad, VBA, Pascal) 2.3. Modelarea proceselor optime de planificare 2.4. Aplicații de simulare pe calculator

diapozitivul numărul 5

Descrierea diapozitivului:

„Modelarea şi dezvoltarea sistemelor informaţionale” Obiectivele studiului secţiunii Dezvoltarea generală şi formarea viziunii despre lume a elevilor. Principala componentă ideologică a conținutului acestei secțiuni a cursului este formarea unei abordări sistematice a analizei realității înconjurătoare. Stăpânirea elementelor de bază ale metodologiei de construire a sistemelor de referință informațională. Elevii obțin o înțelegere a etapelor dezvoltării sistemului informațional: etapa de proiectare și etapa de implementare. Crearea unei baze de date cu mai multe tabele are loc în mediul SGBD relațional MS Access. Elevii învață cum să construiască o bază de date, aplicații (interogări, rapoarte), elemente de interfață (casete de dialog). Dezvoltarea și profesionalizarea abilităților informatice. Abilitățile dobândite la cursul de bază sunt dezvoltate în continuare. - lucrul cu grafica vectoriala la construirea de modele structurale ale sistemelor - studiul aprofundat al capacitatilor MS Access DBMS - folosirea MS Excel ca mijloc de lucru cu o baza de date - programarea in VBA in Excel pentru dezvoltarea unei interfete - cand lucreaza la rezumate, se recomandă utilizarea resurselor de pe Internet; pregăti material pentru protecție sub formă de prezentare (Power Point)

diapozitivul numărul 6

Descrierea diapozitivului:

Metoda de predare pe bază de proiect Enunțarea problemei: Domeniul de studiu: gimnaziu Scopul proiectului: crearea sistemului informațional „Procesul educațional” Scopul sistemului informațional: informarea utilizatorilor: Despre componența elevilor a claselor Despre personalul didactic al școlii Despre repartizarea sarcinii didactice și managementul clasei Despre progresul elevilor

diapozitivul numărul 7

Descrierea diapozitivului:

diapozitivul numărul 8

Descrierea diapozitivului:

diapozitivul numărul 9

Descrierea diapozitivului:

diapozitivul numărul 10

Descrierea diapozitivului:

diapozitivul numărul 11

Descrierea diapozitivului:

diapozitivul numărul 12

Descrierea diapozitivului:

Dezvoltare aplicație Aplicații: interogări, rapoarte Sarcină. Este necesar să obțineți o listă cu toate fetele din clasa a IX-a, ale căror note anuale la informatică sunt cinci. Conceptul de subschemă Folosind un limbaj de interogare ipotetic.alegerea STUDENTS.SURNAME, STUDENTS.FIRST, STUDENTS.CLASS pentru STUDENTS.CLASS='9?' și STUDENTS.SEX='g' și GROWTH.SUBJECT='informatica' și GROWTH.YEAR =5 sortați PUPILS.SURNAME în ordine crescătoare

diapozitivul numărul 13

Descrierea diapozitivului:

diapozitivul numărul 14

Descrierea diapozitivului:

diapozitivul numărul 15

Descrierea diapozitivului:

Programare aplicație VBA Private Sub CommandButton1_Click() „Declarația variabilei Dim i, j, n As Integer Dim Flag Ca Boolean „Inițializarea datelor Flag = False „Numărul de rânduri din lista de școli este determinat n = Range(„A3”). CurrentRegion.Rows. Count „Căutați în lista numărul școlii specificat în câmpul de introducere „TextBox1” Pentru i = 3 To n+2 If Cells(i, 1).Value = Val(UserForm1.TextBox1.Text) Then Flag = True Exit For End If Next Fragment al handlerului de evenimente „Faceți clic pe butonul CĂUTARE”

diapozitivul numărul 16

Descrierea diapozitivului:

„Modelarea matematică pe calculator” Sarcinile de studiu a secțiunii Stăpânirea modelării ca metodă de cunoaștere a realității înconjurătoare (natura de cercetare a secțiunii) - se arată că modelarea în diverse domenii ale cunoașterii are caracteristici similare, de multe ori pot fi obținute modele foarte apropiate pentru diverse procese; - sunt demonstrate avantajele și dezavantajele unui experiment pe calculator în comparație cu un experiment la scară largă; - se arată că atât modelul abstract, cât și computerul oferă o oportunitate de a afla despre lumea din jur, de a o gestiona în interesul omului. Dezvoltarea abilităților practice de modelare pe calculator. Este dată metodologia generală a modelării matematice pe calculator. Pe exemplul unui număr de modele din diverse domenii ale științei și practicii, toate etapele modelării sunt practic implementate de la formularea problemei până la interpretarea rezultatelor obținute în cursul unui experiment pe calculator. Promovarea orientării profesionale a elevilor. Identificarea înclinației studentului pentru activități de cercetare, dezvoltarea potențialului creativ, orientarea către alegerea unei profesii legate de cercetarea științifică. Depășirea dezunității subiectului, integrarea cunoștințelor. În cadrul cursului, modelele din diverse domenii ale științei sunt studiate folosind matematica. Dezvoltarea și profesionalizarea abilităților informatice. Stăpânirea software-ului de uz general și specializat, sisteme de programare.

diapozitivul numărul 17

Descrierea diapozitivului:

diapozitivul numărul 18

Descrierea diapozitivului:

Modelarea proceselor optime de planificare Problema planificării funcţionării unei staţii de benzină Enunţarea problemei Lasă o staţie de service auto să efectueze două tipuri de servicii: TO-1 şi TO-2. Mașinile sunt acceptate la începutul zilei de lucru și eliberate clienților la sfârșit. Datorită zonei limitate de parcare, în total nu pot fi deservite mai mult de 140 de mașini pe zi. Ziua de lucru durează 8 ore. Dacă toate mașinile trec doar TO-1, atunci capacitatea stației ar permite întreținerea a 200 de mașini pe zi, dacă toate mașinile trec doar TO-2, atunci 50. Costul (pentru client) al TO-2 este de două ori mai mare decât TO-2. -1. În realitate, unele mașini trec TO-1, iar altele, în aceeași zi, TO-2. Este necesar să se întocmească un astfel de plan zilnic de întreținere pentru a asigura întreprinderii cele mai mari încasări de numerar.

diapozitivul numărul 19

Descrierea diapozitivului:

Modelarea proceselor optime de planificare Formalizarea și modelarea matematică a problemei Indicatori planificați x - planul zilnic de producție TO-1; y este planul zilnic pentru producerea TO-2. Sistemul de inegalități rezultă din enunțul problemei.Cel mai mare profit se va realiza la valoarea maximă a funcției Funcția f(x, y) se numește funcție obiectiv, iar sistemul de inegalități se numește sistem de restricții. . Am o problemă de programare liniară

diapozitivul numărul 20

Descrierea diapozitivului:

diapozitivul numărul 21

Descrierea diapozitivului:

Modelarea proceselor optime de planificare Metode de rezolvare a unei probleme de programare liniară Metoda Simplex - o modalitate universală de rezolvare a unei probleme de programare liniară Tabel Simplex Baza St. membru. 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

diapozitivul numărul 22

Descrierea diapozitivului:

diapozitivul numărul 23

Descrierea diapozitivului:

diapozitivul numărul 24

Descrierea diapozitivului:

diapozitivul numărul 25

Descrierea diapozitivului:

Modelare Procese optime de programare Sub CommandButton1_Click() Dim d(5, 9) Ca variantă Dim i, j, r, n, k, m Ca întreg Dim p, q, t Ca șir Dim a, b Ca dublu pentru i = 1 To 5 For j = 1 To 9 d(i, j) = Range("a6:i10").Cells(i, j).Value Next j Next in = 7: r = 3 " Analiza optimitatii curentului soluție' t = „următorul” Do While t = „următorul” Program Metoda Simplex în VBA pentru Excel (fragment)

diapozitivul numărul 28

Descrierea diapozitivului:

diapozitivul numărul 29

Descrierea diapozitivului:

Modelarea proceselor optime de planificare Sarcina de planificare a lucrărilor de construcție a drumului Enunțarea problemei Există două puncte - H inițial și K final; de la primul la al doilea este necesar să se construiască un drum, care este format din verticală și segmente. Costul construcției fiecăruia dintre segmentele posibile este cunoscut (prezentat în figură). În realitate, drumul va fi o linie întreruptă care leagă punctele H și K. Este necesar să se găsească o astfel de linie care să aibă cel mai mic cost. Aceasta este o problemă de programare dinamică

Descrierea diapozitivului:

diapozitivul numărul 33

Descrierea diapozitivului:

Simulare pe calculator Se utilizează un aparat de statistică matematică Evenimente aleatoare: - intervalul de timp dintre două tranzacții - timpul de deservire a tranzacției Funcții de distribuție a densității de probabilitate a evenimentelor aleatoare Distribuție uniformă Distribuție normală Gaussiană Distribuție Poisson

Descrierea diapozitivului:

Rezultatele învățării planificate pentru EC. Elevii trebuie să cunoască: scopul și compoziția sistemelor informaționale; etapele creării unui sistem informatic informatic; concepte de bază de sistemologie, varietăți existente de modele de sistem; ce este un model de domeniu infologic; ce este o bază de date (DB); clasificarea bazei de date; structura bazei de date relaționale (RDB); normalizarea bazei de date; ce este un SGBD; cum sunt organizate relațiile într-o bază de date cu mai multe tabele; ce tipuri de interogări de baze de date există; care este structura comenzii de interogare pentru preluarea și sortarea datelor; Care sunt posibilitățile de lucru cu bazele de date are un procesor de foi de calcul (MS Excel); cum să creați și să executați o macrocomandă în MS Excel; ce este o aplicație orientată pe obiecte; elementele de bază ale programării în VBA; conținutul conceptelor „model”, „model informațional”, „model matematic computerizat”;

diapozitivul numărul 36

Descrierea diapozitivului:

etapele modelării matematice pe calculator, conținutul acestora; compoziție de instrumente pentru modelare matematică pe calculator; capabilitățile procesorului de foi de calcul Excel în implementarea modelării matematice; capacitățile sistemului MathCAD în implementarea modelelor matematice computerizate; specificul modelării matematice pe calculator în planificarea economică; exemple de sarcini semnificative din domeniul planificarii economice, rezolvate prin simulare pe calculator; formularea de probleme rezolvate prin metoda programarii liniare; formularea problemelor rezolvate prin metoda programarii dinamice; conceptele de bază ale teoriei probabilităților necesare implementării modelării simulării: o variabilă aleatoare, legea distribuției unei variabile aleatoare, densitatea probabilității a distribuției, fiabilitatea rezultatului unui studiu statistic; metode de obținere a unor secvențe de numere aleatoare cu o lege de distribuție dată; formularea problemelor rezolvate prin simulare în teoria cozilor.

diapozitivul numărul 37

Descrierea diapozitivului:

Elevii ar trebui să fie capabili: să proiecteze un sistem simplu de informare și referință; proiectarea unei baze de date cu mai multe tabele; navigați în mediul MS Access DBMS; creați o structură de bază de date și umpleți-o cu date; pentru a efectua interogări selectate în MS Access utilizând designerul de interogări; lucra cu forme de a efectua cereri cu obținerea datelor finale; primi rapoarte; organizați baze de date cu un singur tabel (liste) în MS Excel; selectați și sortați datele în liste; date de filtrare; creați tabele pivot; înregistrați macrocomenzi pentru MS Excel folosind un înregistrator de macrocomenzi; scrieți programe simple de gestionare a evenimentelor în VBA. să aplice schema unui experiment pe calculator în rezolvarea unor probleme semnificative unde este nevoie de modelare matematică pe calculator; selectați factorii care influențează comportamentul sistemului studiat, efectuați ierarhizarea acestor factori;

diapozitivul numărul 38

Descrierea diapozitivului:

construirea modelelor proceselor studiate; alege instrumente software pentru studiul modelelor construite; analizați rezultatele obținute și explorați modelul matematic pentru diverse seturi de parametri, inclusiv cei de limită sau critici; utilizați modele economice simple de optimizare; construiți cele mai simple modele de sisteme de așteptare și interpretați rezultatele. să implementeze modele matematice simple pe un computer, creând algoritmi și programe în limbajul Visual Basic; să folosească capacitățile TP Excel pentru a efectua calcule matematice simple și pentru a ilustra rezultatele modelării matematice cu grafice și diagrame cu bare; utilizați instrumentul „Căutare soluție” TP Excel pentru a rezolva probleme de programare liniară și neliniară; utilizați sistemul MathCAD pentru a efectua calcule matematice simple, ilustrarea grafică a rezultatelor simulării; utilizați sistemul MathCAD pentru a rezolva probleme de optimizare liniară și neliniară.

Conceptul de model este unul cheie în teoria generală a sistemelor. Modelarea ca metodă de cercetare puternică – și adesea singura – implică înlocuirea unui obiect real cu altul – material sau ideal.
Cele mai importante cerințe pentru orice model sunt adecvarea acestuia la obiectul studiat în cadrul unei sarcini specifice și fezabilitatea acestuia prin mijloacele disponibile.
În teoria eficienței și informatică, un model al unui obiect (sistem, operație) este un sistem material sau ideal (reprezentabil mental) creat și/sau utilizat în rezolvarea unei probleme specifice în scopul obținerii de noi cunoștințe despre obiectul original, adecvate acestuia. din punct de vedere al proprietăţilor studiate şi mai simplu decât originalul sub alte aspecte .
Clasificarea principalelor metode de modelare (și a modelelor corespunzătoare acestora) este prezentată în fig. 3.1.1.
În studiul sistemelor informaționale economice (EIS) sunt utilizate toate metodele de modelare, totuși, în această secțiune, atenția principală va fi acordată metodelor semiotice (semnului).
Amintiți-vă că semiotica (din greacă semeion - semn, semn) este știința proprietăților generale ale sistemelor de semne, adică sisteme de obiecte concrete sau abstracte (semne), fiecare dintre acestea fiind asociat cu o anumită valoare. Exemple de astfel de sisteme sunt orice limbă

Orez. 3.1.1. Clasificarea metodelor de modelare

(naturale sau artificiale, de exemplu, descrierea datelor sau limbaje de modelare), sisteme de semnalizare în societate și în lumea animală etc.
Semiotica cuprinde trei secțiuni: sintactică; semantică; pragmatică.
Sintactica explorează sintaxa sistemelor de semne fără a ține cont de interpretările și problemele asociate cu percepția sistemelor de semne ca mijloc de comunicare și comunicare.
Semantica studiază interpretarea enunţurilor unui sistem de semne şi, din punctul de vedere al modelării obiectelor, ocupă locul principal în semiotică.
Pragmatica explorează atitudinea utilizatorului sistemului de semne față de sistemul de semne însuși, în special, percepția expresiilor semnificative ale sistemului de semne.
Dintre numeroasele modele semiotice, datorita celei mai mari distributii, mai ales in conditiile informatizarii societatii moderne si introducerii metodelor formale in toate sferele activitatii umane, le remarcam pe cele matematice care afiseaza sisteme reale folosind simboluri matematice. Totodată, ținând cont de faptul că avem în vedere metode de modelare în raport cu studiul sistemelor în diverse operațiuni, vom folosi cunoscuta metodologie de analiză a sistemelor, teoria eficienței și luarea deciziilor.

Mai multe despre subiectul 3. TEHNOLOGIA SIMULĂRII SISTEMELOR INFORMAȚIONALE Metode de modelare a sistemelor:

1. Modele de simulare a sistemelor informaţionale economice Fundamente metodologice pentru aplicarea metodei simulării
2. Sectiunea III BAZE DE MODELARE A SISTEMULUI DE SERVICII DE MARKETING
3. CAPITOLUL 1. SISTEME DINAMICE CONTROLATE CA OBIECTUL SIMULĂRII PE CALCULATOR
4. Fundamentele modelării structurale a sistemului de marketing al serviciilor medicale
5. Secțiunea IV EXEMPLU DE UTILIZARE APLICATĂ A MODELULUI DE SISTEM DE MARKETING ÎN MODELAREA SIMULARE
6. Conceptul de modelare a sferei financiare a sistemelor de marketing

Trimiteți-vă munca bună în baza de cunoștințe este simplu. Foloseste formularul de mai jos

Studenții, studenții absolvenți, tinerii oameni de știință care folosesc baza de cunoștințe în studiile și munca lor vă vor fi foarte recunoscători.

Găzduit la http://www.allbest.ru/

Institutul Serviciului de Stat din Omsk

Modelarea sistemelor informatice folosind limbajul UML

Orientări pentru implementarea lucrărilor de curs

I.V. Chervenchuk

• Introducere
• 2 . Limbajul de modelare unificatUML
• 4. Dezvoltarea unui model de sistem software prin intermediulUML
• 5. Probleme de implementare a sistemului informatic
• 6. Teme ale lucrărilor trimestriale
• Lista bibliografică

Introducere

Lucrarea tratează dezvoltarea sistemelor informaționale folosind limbajul unificat de modelare UML, care stă la baza lucrărilor de curs la disciplina „Sisteme și procese informaționale. Modelare și management”. Se elaborează etapele principale ale unui proces rațional unificat de dezvoltare a sistemelor informaționale, sunt oferite exemple și ilustrații. Opțiuni oferite pentru teme pentru cursuri.

Orientările sunt destinate studenților specialității „Informatică aplicată” și pot fi utilizate în cadrul lucrărilor de curs, pregătirea pentru examen, precum și în procesul de muncă independentă.

1. Cerințe generale pentru activitatea de curs

Lucrarea cursului la disciplina "Sisteme și procese informaționale. Modelare și management" reprezintă etapa finală a studiului acestui curs și este menită să consolideze în practică cunoștințele teoretice de bază privind modelarea sistemelor informaționale. Lucrarea constă în dezvoltarea unui model al unui sistem informaţional folosind limbajul unificat de modelare UML cu implementarea sa ulterioară. Ca opțiune tipică pentru sarcină, se propune elaborarea unui sistem de informare și referință bazat pe o bază de date, dar la solicitarea elevului, de comun acord cu profesorul, se poate dezvolta o aplicație WEB, sistem de testare sau dispozitiv hardware. fi propus ca sarcină. În acest caz, principala cerință necesară este utilizarea unei abordări orientate pe obiecte și construirea unui model UML.

Un titlu tipic de lucrare a termenului arată ca „Dezvoltarea unui sistem de informare și referință _ titlu _ "

Introducere

1. O privire de ansamblu semnificativă a domeniului subiectului. Cerințe de bază ale sistemului

2. Model detaliat al sistemului informatic

2.1 Vedeți în termeni de cazuri de utilizare

2.2 Vedere de proiectare

2.3 Vedere de implementare

2.4 Vedere proces (dacă este necesar)

2.5 Vedere de implementare (dacă este necesar)

3. Implementarea sistemului informatic

Concluzie

Lista de aplicații a unui program sau a unui modul principal

În introducere se poate evidenția utilizarea tehnologiilor informaționale în diverse domenii de activitate, inclusiv în sectorul serviciilor, avantajele contabilității electronice, problemele construirii sistemelor informatice specializate etc.

Aceste ghiduri conțin recomandări detaliate pentru secțiunile principale ale notei explicative și exemple de proiectare. Trebuie remarcat faptul că subiectul principal al acestui curs este dezvoltarea unui model UML al unui sistem informațional, de aceea se recomandă insistent ca diagramele UML să fie prezentate în partea principală a notei explicative, oferindu-le comentarii detaliate și textele programului trebuie incluse în aplicație.

Vizualizarea procesului ar trebui oferită atunci când se dezvoltă sisteme multitasking. Vederea de implementare presupune un sistem de informații distribuit. Aceste tipuri și secțiunile corespunzătoare ale notei explicative nu sunt obligatorii pentru implementarea acestei lucrări de curs, utilizarea lor este presupusă atunci când se efectuează numai anumite opțiuni pentru lucrarea de curs.

Când se acoperă problemele de implementare a sistemului într-o notă, este de dorit să se justifice alegerea unui mediu de programare și să se furnizeze un manual de utilizare. Un element obligatoriu este includerea în text a formularelor de ecran (screen-short-uri) ale programului implementat, se încurajează utilizarea instrumentelor de inginerie inversă.

În concluzie, principalele rezultate ale lucrării sunt rezumate pe scurt: a fost dezvoltat un model UML al sistemului, sistemul a fost implementat folosind un mediu de programare pe care sistemul dezvoltat îl permite, avantajele abordărilor utilizate (pe baza modelare) la proiectarea sistemului.

modelarea limbajului sistemului informatic

Cursul ar trebui să conțină 20-30 de pagini de text tipărit cu ilustrații. Diagramele precedentelor, claselor, interacțiunilor trebuie date fără greș.

2. Limbajul de modelare unificat UML

Dezvoltarea rațională a unui sistem informațional presupune un studiu analitic preliminar profund. În primul rând, este necesar să se contureze gama de sarcini îndeplinite de sistemul dezvoltat, apoi să se elaboreze un model al sistemului și, în final, să se determine modalitățile de implementare. Studiul profund al arhitecturii sistemului informatic dezvoltat în etapele inițiale de proiectare, de regulă, se plătește ulterior, mai ales atunci când se dezvoltă proiecte de anvergură cu suport pe termen lung.

Instrumentele limbajului de modelare UML (Unified Model Language, - un limbaj de programare unificat) fac posibilă realizarea expresă și destul de ușoară a unei dezvoltări conceptuale preliminare a unui sistem informațional și, în același timp, însoțirea metodică a întregului proces de dezvoltare, inclusiv a întregului ulterioară ciclul de viață al sistemului informațional fiind dezvoltat ca produs software.

UML este un limbaj pentru vizualizarea, specificarea, construirea și documentarea artefactelor sistemelor software bazate pe o abordare orientată pe obiecte.

UML, ca orice altă limbă, constă dintr-un vocabular și reguli care vă permit să combinați cuvintele din el și să obțineți constructe semnificative. În limbajul de modelare, vocabularul și regulile sunt concentrate pe reprezentarea conceptuală și fizică a sistemelor informaționale. Modelarea este necesară pentru a înțelege sistemul. Cu toate acestea, un singur model nu este niciodată suficient. Dimpotrivă, pentru a înțelege orice sistem non-trivial, trebuie să dezvoltăm un număr mare de modele interdependente. Când se aplică sistemelor software, aceasta înseamnă că este nevoie de un limbaj care să poată fi utilizat pentru a descrie reprezentările arhitecturii unui sistem din diferite puncte de vedere de-a lungul ciclului său de dezvoltare.

UML este un limbaj de vizualizare, iar UML nu este doar un set de simboluri grafice. În spatele fiecăruia dintre ele există o semantică bine definită (vezi ) Astfel, un model scris de un dezvoltator poate fi interpretat fără ambiguitate de către altul sau chiar de către un instrument.

UML este un limbaj de specificare. În acest context, specificarea înseamnă construirea de modele precise, lipsite de ambiguitate și complete. UML permite specificarea tuturor deciziilor semnificative de analiză, proiectare și implementare care trebuie luate în timpul dezvoltării și implementării unui sistem software.

UML este un limbaj de design. Deși UML nu este un limbaj de programare vizual, modelele create cu acesta pot fi traduse direct în diferite limbaje de programare specifice. Cu alte cuvinte, modelul UML poate fi mapat la limbaje precum Java, C++, Visual Basic și chiar la tabele de baze de date relaționale sau la obiecte persistente de baze de date orientate pe obiecte. Acele concepte care sunt de preferință transmise grafic sunt reprezentate în UML; cele care sunt cel mai bine descrise în formă textuală sunt exprimate folosind un limbaj de programare.

O astfel de mapare a modelului la limbajul de programare permite proiectarea directă: generarea de cod din modelul UML într-un limbaj specific. Puteți rezolva și problema inversă: restaurați modelul din implementarea existentă. Desigur, modelul și implementarea implică utilizarea unui număr de entități specifice. Prin urmare, ingineria inversă necesită atât instrumente, cât și intervenție umană. Combinația dintre generarea de cod înainte și inginerie inversă vă permite să lucrați atât în ​​reprezentări grafice, cât și textuale, atâta timp cât instrumentele asigură consistență între ambele reprezentări.

Pe lângă maparea directă către limbaje de programare, UML, datorită expresivității și lipsei de ambiguitate, vă permite să executați direct modele, să simulați comportamentul sistemelor și să controlați sistemele existente.

UML este un limbaj de documentare

O companie de software produce și alte documente în plus față de codul executabil, inclusiv:

Cerințe de sistem;

arhitectură;

proiect;

sursă;

planuri de proiect;

teste;

prototipuri;

versiuni etc.

În funcție de metodologia de dezvoltare adoptată, unele lucrări sunt realizate mai formal, altele mai puțin. Documentele de referință nu sunt doar părți livrabile ale proiectului; sunt necesare pentru management, pentru evaluarea rezultatului, dar și ca mijloc de comunicare între membrii echipei în timpul dezvoltării sistemului și după implementarea acestuia.

UML oferă dezvoltatorului și managementului propria soluție la problema documentării arhitecturii sistemului și a tuturor detaliilor acesteia, oferă un limbaj pentru formularea cerințelor de sistem și definirea testelor și, în final, oferă instrumente pentru modelarea lucrărilor în etapa de planificare și versiune a proiectului. Control.

Luați în considerare dezvoltarea unui model de sistem informațional folosind limbajul UML pe exemplul dezvoltării unui loc de muncă automatizat al secretarului departamentului (denumit în continuare stația de lucru a secretarului departamentului).

3. Descrierea domeniului subiectului

Conceptul de domeniu al unei baze de date este unul dintre conceptele de bază ale informaticii și nu are o definiție precisă. Utilizarea lui în contextul SI presupune existența unei corelații stabile în timp între nume, concepte și anumite realități ale lumii exterioare, independent de SI însuși și de cercul său de utilizatori. Astfel, introducerea în luarea în considerare a conceptului de tematică a bazei de date limitează și face vizibil spațiul de regăsire a informațiilor din IS și vă permite să executați interogări într-un timp finit.

Prin descrierea domeniului subiectului vom înțelege descrierea mediului în care este dezvoltat sistemul, tipurile de utilizatori ai sistemului, indicând, de asemenea, principalele sarcini a căror soluție este atribuită sistemului.

În descrierea preliminară a domeniului subiectului sunt introduși termenii principali (dicționarul sistemului), se definesc tipurile de utilizatori și drepturile acestora și se formulează sarcinile pe care sistemul dezvoltat ar trebui să le rezolve. În același timp, atunci când descrie, se presupune că trebuie să folosească mijloacele unui limbaj comun și grafică standard de afaceri (figuri, diagrame, tabele).

La elaborarea unui dicționar de sistem, este necesar să se definească denumirile entităților („student”, „profesor”, „disciplină”). În același timp, termenul de entitate este înțeles de noi ca o componentă a modelului de domeniu, adică ca un obiect deja identificat la nivel conceptual. Obiectele alocate în domeniul subiectului sunt transformate în entități de către analist.

O entitate este rezultatul abstracției unui obiect real. Există două probleme cu obiectele: identificarea și descrierea adecvată. Pentru identificare folosiți numele, care trebuie să fie unic. În același timp, se presupune că există o respingere a sensului său, care este inerent limbajului natural. Este utilizată numai funcția de indicator al numelui. Un nume este o modalitate directă de a identifica un obiect. Metodele indirecte de identificare a unui obiect includ definirea unui obiect prin proprietățile sale (caracteristici sau caracteristici).

Obiectele interacționează între ele prin proprietățile lor, ceea ce dă naștere unor situații. Situațiile sunt relații care exprimă relații între obiecte. Situațiile din domeniul subiectului sunt descrise prin intermediul afirmațiilor despre domeniul subiectului. În această etapă, puteți utiliza metodele calculului propozițional și al predicatelor, adică logica formală, matematică. De exemplu, afirmația „Programatorul și managerul sunt angajați ai companiei” descrie o relație de incluziune. Astfel, toate informațiile despre obiectele și entitățile din domeniul subiectului sunt descrise folosind declarații în limbaj natural.

Puteți specifica relații structurale, evidenția situații statice și dinamice (introducând astfel un parametru de timp în model), cu toate acestea, pentru un studiu detaliat al modelului, este mai convenabil să folosiți instrumente avansate pentru descrierea domeniului subiectului, de exemplu, UML instrumente lingvistice.

Deci, sarcina este de a dezvolta un sistem „Stația de lucru a secretarului departamentului” care să permită contabilizarea automată a datelor privind angajații și studenții departamentului TIC OmSTU, să ofere flexibilitate în rezolvarea sarcinilor specifice planificate și neplanificate de prelucrare a datelor contabile.

Ca parte a soluționării problemei dezvoltării unui loc de muncă automatizat al secretarului de departament, evidențiem următoarele entități:

profesori - profesorii catedrei;

studenți- studenți ai specialității date;

elevii studiază în grupuri, grup este o entitate organizatoare (unificatoare) pentru studenți;

studenți absolvenți, au particularitatea că, pe de o parte, ei înșiși pot conduce cursurile, pe de altă parte, ei înșiși sunt studenți și au un supraveghetor;

disciplina- disciplina predată (disciplină, curs).

Entitățile menținute au o serie de atribute pe care le vom defini mai târziu.

Gestionăm două tipuri de utilizatori: obișnuiți utilizator(mai departe utilizator, și administrator. Se presupune că utilizator poate accesa sistemul cu o solicitare, afișa rapoarte, administrator poate modifica suplimentar datele. De exemplu, secretarul asistent al catedrei poate acționa ca utilizator, secretarul însuși sau profesorul responsabil, poate acționa ca administrator.

Ținând cont de termenii introduși, sistemul dezvoltat ar trebui să ofere:

organizarea unei contabilități complete și de încredere a tuturor angajaților și studenților departamentului;

suport informațional pentru deciziile de management, formarea de informații complete și de încredere despre procesele educaționale și rezultatele departamentului;

reducerea costurilor cu forța de muncă pentru întocmirea documentelor și rapoartelor primare;

eliminarea duplicării la introducerea informațiilor și a erorilor mecanice rezultate;

interfață de utilizator convenabilă;

diferențierea puterilor utilizatorilor obișnuiți și ale administratorului.

În acest exemplu, rezolvăm o anumită problemă - dezvoltăm o stație de lucru pentru secretarul departamentului, astfel încât departamentul, pe care îl vom avea în vedere implicit, este luat ca unitate structurală de cel mai înalt nivel pentru noi, că adică, se presupune că toate elementele modelului se aplică numai acestui departament, ceea ce nu este specificat în mod explicit. Structurile de nivel superior, cum ar fi o facultate, o universitate, nu vor fi luate în considerare de noi.

4. Dezvoltarea unui model de sistem software folosind UML

UML este un limbaj de specificare și vizualizare, unitățile sale principale sunt diagramele.

O diagramă UML este o reprezentare grafică a unui set de elemente, cel mai adesea reprezentată ca un graf conectat cu vârfuri (entități) și muchii (relații). Diagramele caracterizează sistemul din diferite puncte de vedere. Diagrama este, într-un fel, una dintre proiecțiile sistemului. De regulă, diagramele oferă o vedere restrânsă a elementelor care alcătuiesc sistemul. Același element poate fi prezent în toate diagramele, sau doar în câteva (cele mai frecvente), sau nu în niciuna (foarte rar). Teoretic, diagramele pot conține orice combinație de entități și relații. În practică, însă, se utilizează un număr relativ mic de combinații tipice, corespunzătoare celor mai comune cinci tipuri care alcătuiesc arhitectura unui sistem software (vezi secțiunea următoare). Astfel, există nouă tipuri de diagrame în UML:

diagrame de clasă

diagrame de obiecte;

diagrame de cazuri de utilizare;

diagrame de secvențe;

diagrame de cooperare;

diagrame de stare;

diagrame de acțiune (activitate);

diagrame componente;

diagrame de implementare.

Modelul UML conceptual

O diagramă de clasă arată clase, interfețe, obiecte și colaborări, precum și relațiile lor. La modelarea sistemelor orientate pe obiecte, acest tip de diagramă este folosit cel mai des. Diagramele de clasă corespund vederii statice a sistemului din punct de vedere al proiectării. Diagramele de clase care includ clase active corespund vederii statice a sistemului din punct de vedere al proceselor.

O diagramă de obiecte reprezintă obiectele și relațiile dintre ele. Sunt „fotografii” statice ale instanțelor de entități prezentate în diagramele de clasă. Diagramele obiect, precum diagramele de clasă, se referă la vederea statică a unui sistem în termeni de proiectare sau procese, dar având în vedere o implementare reală sau simulată.

O diagramă de cazuri de utilizare prezintă cazuri de utilizare și actori (un caz special de clase) și relațiile dintre ei. Diagramele de cazuri de utilizare se referă la vizualizarea statică a unui sistem în termeni de cazuri de utilizare. Ele sunt deosebit de importante în organizarea și modelarea comportamentului unui sistem.

Diagramele de succesiune și de cooperare sunt cazuri speciale de diagrame de interacțiune. Diagramele de interacțiune reprezintă relații între obiecte; arată, în special, mesajele pe care obiectele le pot schimba. Diagramele de interacțiune se referă la vizualizarea dinamică a unui sistem. În același timp, diagramele de secvență reflectă ordonarea temporală a mesajelor, iar diagramele de cooperare reflectă organizarea structurală a obiectelor care fac schimb de mesaje. Aceste diagrame sunt izomorfe, adică pot fi transformate una în alta.

Diagramele de stări (diagramele Statechart) reprezintă un automat care include stări, tranziții, evenimente și tipuri de acțiuni. Diagramele de stare se referă la vederea dinamică a unui sistem; ele sunt deosebit de importante atunci când se modelează comportamentul unei interfețe, clase sau colaborări. Acestea se concentrează pe comportamentul unui obiect în funcție de succesiunea evenimentelor, ceea ce este foarte util pentru modelarea sistemelor reactive.

O diagramă de activitate este un caz special al unei diagrame de stare; reprezintă tranziţiile fluxului de control de la o activitate la alta în cadrul sistemului. Diagramele de activitate se referă la vizualizarea dinamică a sistemului; ele sunt cele mai importante în modelarea funcționării acestuia și reflectă fluxul de control între obiecte.

Diagrama componentelor arată organizarea unui set de componente și dependențele care există între ele. Diagramele componente se referă la vederea statică a unui sistem din punct de vedere al implementării. Ele pot fi legate de diagramele de clasă, deoarece o componentă este de obicei mapată la una sau mai multe clase, interfețe sau colaborări.

Diagrama de implementare arată configurația nodurilor de procesare ale sistemului și componentele plasate în acestea. Diagramele de implementare se referă la o vedere statică a arhitecturii unui sistem din perspectiva implementării. Ele sunt legate de diagramele de componente deoarece un nod găzduiește de obicei una sau mai multe componente.

Aceasta este o listă parțială a diagramelor utilizate în UML. Instrumentele vă permit să generați și alte diagrame, cum ar fi diagramele profilului bazei de date, diagramele aplicațiilor web și așa mai departe.

4.1 Proiectarea vederii în termeni de cazuri de utilizare

Modelarea începe cu definirea sarcinilor principale ale sistemului în curs de dezvoltare și a acțiunilor pe care acesta trebuie să le realizeze. Diagramele de cazuri de utilizare sunt utilizate în acest scop. După cum sa menționat deja, diagramele de cazuri de utilizare indică cazuri de utilizare și actori, precum și relațiile dintre ei.

Precedent (cazul de utilizare) este o descriere a secvenței de acțiuni efectuate de sistem, care produce un rezultat observabil care este semnificativ pentru o anumită act e ra (Actor). Cazul de utilizare este folosit pentru a structura entitățile comportamentale ale modelului. Precedentul declară doar o descriere a unei acțiuni a sistemului, răspunzând la întrebarea „ce să faci?”, dar nu precizează prin ce mijloace. Implementarea concretă a comportamentului specificat de un caz de utilizare este asigurată de o clasă, o colaborare de clasă sau o componentă.

Un actor este un set conectat de roluri pe care le îndeplinesc utilizatorii cazurilor de utilizare în timp ce interacționează cu ei. De obicei, un actor reprezintă un rol jucat de o persoană, un dispozitiv hardware sau chiar un alt sistem dintr-un sistem dat. În sistemul dezvoltat „Postul de lucru al secretarului departamentului” actorii sunt administratorul (admin) și utilizator.

Grafic, un precedent este înfățișat ca o elipsă delimitată de o linie continuă, conținând de obicei doar numele său, actorul are o pictogramă „omuleț”.

Pentru a construi o diagramă de cazuri de utilizare, este necesar să se identifice acțiunile elementare efectuate de sistem și să le compare cu cazurile de utilizare. În același timp, este de dorit să se dea denumirile precedentelor astfel încât acestea să indice comportamentul, adesea astfel de nume conțin verbe, de exemplu, „generați un raport”, „găsiți date după un criteriu”, etc. Puteți numi cazuri de utilizare cu substantive care sugerează o acțiune, de exemplu, „autorizare”, „căutare”, „control”.

Revenind la modelarea postului de lucru al secretarului de catedra, evidentiam precedentele:

Editaredate,

Căutarestudent,

Căutareprofesor,

extrădarelistăpredatdisciplinelor,

Autorizare.

Elementele diagramei de cazuri de utilizare (cazuri de utilizare și actori) trebuie să fie legate.

Cea mai comună relație între cazuri de utilizare, cazuri de utilizare și actori este asocierea. În unele cazuri pot fi folosite relații de generalizare. Aceste relații au același sens ca în diagrama de clase.

În plus, două dependențe specifice sunt definite între cazurile de utilizare în UML - relația de includere și relația de extensie.

O relație de includere între cazurile de utilizare înseamnă că la un moment dat în cazul de utilizare de bază, comportamentul altui caz de utilizare este încorporat (inclus). Un caz de utilizare inclus nu există niciodată în mod autonom, ci este instanțiat doar ca parte a unui caz de utilizare anexat. Vă puteți gândi la cazul de bază de utilizare ca împrumutând comportamentul celor incluse. Datorită prezenței relațiilor de incluziune, este posibilă evitarea descrierilor multiple ale aceluiași flux de evenimente, deoarece comportamentul general poate fi descris ca un precedent independent inclus în cele de bază. O relație de includere este un exemplu de delegare, în care un set de responsabilități de sistem sunt descrise într-un singur loc (într-un caz de utilizare inclus), iar alte cazuri de utilizare includ acele responsabilități în setul lor, după cum este necesar.

Relațiile de incluziune sunt descrise ca dependențe cu stereotipul „include”. Pentru a specifica un loc în fluxul de evenimente în care un caz de utilizare de bază include comportamentul altuia, pur și simplu scrieți cuvântul include urmat de numele cazului de utilizare de inclus.

O relație de extensie este utilizată pentru a modela părți ale unui caz de utilizare pe care utilizatorul le percepe ca comportament opțional al sistemului. În acest fel, puteți separa comportamentul obligatoriu și cel opțional. Relațiile de extensie sunt, de asemenea, folosite pentru a modela subfluxuri individuale care rulează numai în anumite circumstanțe. În cele din urmă, ele sunt folosite pentru a modela mai multe fire de execuție care pot fi declanșate la un moment dat într-un script ca urmare a interacțiunii explicite cu un actor.

O relație de extensie este descrisă ca o dependență cu stereotipul „extindere”. Punctele de extindere a scenariului de bază sunt listate în secțiunea opțională. Sunt pur și simplu etichete care pot apărea în fluxul de caz de utilizare de bază.

Un exemplu de utilizare a acestei relații poate fi accesul la o bază de date care are o parte operațională și o arhivă. În acest caz, dacă solicitarea este furnizată cu datele părții operaționale, se realizează accesul principal (de bază) la date, dar dacă datele părții operaționale nu sunt suficiente, se realizează accesul la datele de arhivă, că este, accesul merge conform scenariului extins.

În cazul nostru, precedentul editaredate include precedente: intraredate, îndepărtaredate, schimbareadate.

Diagrama precedentelor postului de lucru al secretarului departamentului este prezentată în Fig.1.

Orez. 1. Schema precedente ale postului de lucru al secretarului de catedra

Precedent Căutarestudent presupune căutarea după nume de familie și căutarea după rezultatele performanței academice.

Atunci când se dezvoltă o vedere în termeni de cazuri de utilizare, este adesea necesar să se furnizeze o descriere extinsă a cazului de utilizare (în versiunea prescurtată, este indicat doar numele acestuia). De regulă, la începutul lucrării, fluxul de evenimente al unui caz de utilizare este descris în formă textuală. Pe măsură ce cerințele pentru sistem devin mai precise, va fi mai convenabil să treceți la o reprezentare grafică a fluxurilor în diagramele de activitate și interacțiune.

Fluxurile de evenimente pot fi descrise folosind text nestructurat, text structurat (conținând cuvinte funcționale: DACĂ,INAINTE DEACESTEAPORPA etc.), un limbaj formal specializat (pseudocod).

Când descriem un precedent printr-un flux de evenimente, este important să desemnăm și fluxurile principale și alternative ale comportamentului sistemului.

De exemplu, luați în considerare descrierea fluxului de evenimente a cazului de utilizare autorizare.

De bază curgere evenimente. Cazul de utilizare începe atunci când sistemul solicită utilizatorului numele de autentificare (Login) și parola (Parola). Utilizatorul îl poate introduce de la tastatură. Terminați introducerea apăsând tasta introduce. După aceea, sistemul verifică Login-ul și parola introduse, iar dacă acestea corespund administratorului, confirmă autoritatea administratorului. Aici se termină precedentul.

Excepţional curgere evenimente. Clientul poate încheia tranzacția în orice moment apăsând tasta Anulare. Această acțiune repornește cazul de utilizare. Nu există nicio intrare în sistem.

Excepţional curgere evenimente. Clientul poate, în orice moment înainte de a apăsa tasta Enter, să-și șteargă Login-ul și parola.

Excepţional curgere evenimente. Dacă clientul a introdus Login și parolă care nu corespund administratorului, i se solicită să reintroducă sau să se autentifice ca utilizator obișnuit.

Evident, descrierea unui precedent printr-un flux de evenimente implică un algoritm care poate fi reprezentat într-o diagramă de activitate (Fig. 2).

Diagrama algoritmului trebuie să conțină vârfurile de început și de sfârșit și doar un început și un capăt. Diagrama conține vârfuri executabile - activități (notate prin dreptunghiuri rotunjite), vârfuri condiționate (decizie - alegere, recunoaștere, indicate cu romburi) și conexiuni.

Diagramele similare pot explica și execuția altor cazuri de utilizare, completând astfel viziunea sistemului în ceea ce privește cazurile de utilizare.

Orez. 2. Autorizarea utilizatorului. Diagrama de activitate.

4.2 Vizualizarea designului din punct de vedere al designului

Vizualizarea designului este pasul principal în conceptualizarea unui model. În această etapă sunt introduse principalele abstracții, sunt definite clase și interfețe prin care se implementează soluția sarcinilor. Dacă precedentele declară doar comportamentul sistemului, atunci în stadiul dezvoltării vederii, din punct de vedere al proiectării, se determină prin ce mijloace vor fi implementate aceste precedente. Aspectele statice de acest tip sunt dezvoltate prin diagrame de clasă, dinamice - prin interacțiune și diagrame de stare (automat).

Diagramele de clasă conțin clase, interfețe, colaborări, precum și relații dintre ele. Dezvoltarea unei diagrame de clasă ar trebui să înceapă cu definirea claselor corespunzătoare principalelor entități ale sistemului, care, de regulă, sunt determinate în etapele inițiale de dezvoltare atunci când se descrie domeniul de studiu. Aici ar trebui să decideți ce entități sunt mai convenabile de modelat ca clase și care ca atribute. De exemplu, dacă s-ar cere în cadrul facultății să se precizeze un șef pentru fiecare catedra, ar fi bine să se precizeze entitatea administratordepartamente fă din acesta un atribut de clasă departament indicând clasa profesori ( asociere unu-la-unu ), mai degrabă decât introducerea unei clase separate administratordepartamente.

La modelare, trebuie amintit că fiecare clasă trebuie să corespundă unei entități reale sau unei abstractizări conceptuale din zona cu care se ocupă utilizatorul sau dezvoltatorul. O clasă bine structurată are următoarele proprietăți:

este o abstractizare bine definită a unui concept din vocabularul domeniului problemei sau domeniul soluției;

conține un set mic, bine definit de sarcini și îndeplinește fiecare dintre ele;

menține o separare clară a specificațiilor de abstractizare și implementarea acesteia;

clar si simplu, dar in acelasi timp permite extinderea si adaptarea la noi sarcini.

Ca parte a dezvoltării modelului AWP al secretarului departamentului, definim clasele: profesori, studenți, studenți absolvenți, disciplinelor, grupuri. Evident, primele dintre ele au multe atribute comune, așa că introducem o clasă abstractă Person, care va cuprinde toate proprietățile legate de o persoană în contextul sistemului în curs de dezvoltare (nume, prenume, adresă etc.). În acest caz o persoana va fi o superclasă și va fi asociată printr-o relație de generalizare cu clase profesori, studenți, studenți absolvenți.

Atribut adresa are propria sa structură, pentru a o reflecta puteți introduce o clasă suplimentară, să o numim T_ ADR(după cum este obișnuit în multe sisteme de programare, numele claselor încep cu litera T). Trebuie remarcat faptul că atributul adresa clasă o persoana este o instanță a clasei T_ ADR, adică se stabilește o relație de dependență între aceste clase (afișată ca o săgeată punctată cu vârful deschis, săgeata indicând de la dependent la independent). În cazul nostru, schimbarea structurii clasei T_ ADR presupune o schimbare de clasă o persoana prin structura atributului corespunzător ( adresa).

Când modelezi o clasă T_ ADR atribut index stabilite după tipul primitiv T_ POSTIDX, definit ca un număr zecimal din șase cifre. Tipurile primitive sunt modelate de stereotipul " tip" , intervalul de valori este specificat prin restricțiile cuprinse între acolade.

In clasa profesor Să evidențiem atributele specifice care se aplică numai profesorului: poziţie, uh. grad(grad academic), uh. rang ( titlu academic) deversare(categoria baremului tarifar unificat). Atribute uh. gradși uh. rang este mai bine să definiți tipurile specializate printr-o enumerare. Enumerările sunt modelate de o clasă cu stereotipul " enumerare" (enumerare - enumerare), valorile valide sunt scrise ca atribute, etichetele care determină vizibilitatea atributelor sunt suprimate. În exemplul luat în considerare, prin enumerare, introducem clase de specialitate T_Trebuie sa, T_UchSt, T_UchSv, definind, respectiv, posibile posturi, grade academice, titluri academice prin enumerari. În acest caz, ca și în alte cazuri similare, la crearea unor clase care specifică atributele clasei principale, se stabilesc relații de dependență.

Pentru clasă student este introdus un anumit atribut camerăcărțile elevului. Atributele specifice sunt definite pentru clasa postuniversitară formăînvăţareși Datachitanțe. Forma de pregătire este determinată de o clasă specială prin enumerare T_FormEducation(normă întreagă, jumătate de normă).

Clasă grup are atribute: titlu, formă învăţare, numărstud. ( numarul studentilor ). Având în vedere că cadrele didactice ale catedrei în cauză pot desfășura cursuri cu grupe din alte facultăți, se introduce o clasă suplimentară specialitate, cu atribute cameră(specialitate), titlu(specialitate ), facultate, ale căror tipuri nu sunt specificate în acest model, deși pot fi definite prin enumerări.

Clasă disciplina are atribute: cameră, titlu, ciclu. Atribut ciclu prin intermediul unui tip specializat introdus printr-o enumerare T_cicluri determină cărui ciclu aparține disciplina: ciclului disciplinelor umanitare și socio-economice, disciplinelor matematice și științelor naturii, disciplinelor profesionale generale, disciplinelor speciale.

Atribute numărore, numărsemestre nu poate fi specificat în clasă disciplina, cu cat depind de specialitate, cu atat mai mult nu le poti preciza in clasa specialitate. Aceste atribute se referă la o pereche de specialitate-disciplină și sunt definite în clasa - asociații Discipline-specialități.

Orez. 3. Diagrama de clasă a postului de lucru al secretarului departamentului (opțiunea 1)

Când vizualizați structura claselor, ar trebui să acordați atenție vizibilității atributelor. Toate atributele luate în considerare trebuie să fie accesibile și să aibă vizibilitate Public (notate cu un semn „+” sau o pictogramă fără lacăt). În clasele luate în considerare, ne-am concentrat pe structură, nu pe comportament (operațiile nu au fost descrise și nu ar trebui să fie descrise), prin urmare, pentru a facilita percepția diagramei, este de dorit să se suprima reprezentarea operațiilor.

Pe setul de clase introdus, este necesară redefinirea legăturilor. Relațiile de generalizare și dependențele au fost deja definite, rămâne de definit asocierile.

studenți format în grupuri, în acest caz asociația va arăta ca o agregare. Agregarea implică o relație parte-intreg, notată printr-o linie continuă cu un romb la capăt din partea întregului (în cazul nostru grupuri). Multiplicitatea relației elev-grup este multi-la-unu. Fiecare grup se referă la un anumit specialitate, la rândul lor, mai multe grupuri pot corespunde unei anumite specialități, astfel încât asociația grup-specialitate are și un tip de multiplicitate multi-la-unu.

În acest caz, ca și în majoritatea celorlalte, direcția asocierilor este bidirecțională, deci este mai bine să suprimați navigarea (debifați câmpul Navigabil al opțiunii Rol de detaliu)

Să definim o asociere între profesoriși a predat disciplinelor după tipul „mulți-la-mulți”: un profesor poate conduce mai multe discipline, unele discipline pot fi predate de mai mulți profesori. Între disciplinelorși specialități se înființează și o asociație multi-to-multi: programa de specialități conține multe discipline, majoritatea disciplinelor se regăsesc în planurile de lucru ale mai multor specialități. O clasă de asociere este atașată acestei asocieri. Discipline-specialități cu atribute care indică cursul, numărul de semestre și numărul de ore ale unei anumite discipline într-o anumită specialitate.

În mod similar, introducem o asociere între grupuriși profesori: profesorii desfășoară cursurile în grupuri, tipul de asociere a multiplicității este multi-la-mulți. asociere directă între grupuriși discipline nu trebuie definită, deoarece această relație este urmărită prin clasa de legătură specialitate.

Pentru a afișa prezența unui conducător la un student absolvent este necesar să se introducă o asociere între absolvent și profesor după tipul „mulți la unu”, un conducător putând avea mai mulți absolvenți. Pe această asociere, din partea profesorului, puteți indica în mod explicit rolul: supraveghetor.

Orez. 4. Diagrama de clasă a postului de lucru al secretarului departamentului (opțiunea 2)

În fiecare grupurie există un șef al grupului, acest fapt poate fi afișat de o asociație suplimentară (să-i dăm un nume şef) de la o grupă la elevi cu tip de multiplicitate unu-la-unu. În acest caz, puteți specifica în mod explicit navigarea.

doctoranzi poate conduce și cursuri într-o anumită disciplină cu anumite grupuri: asociații multi-la-mulți grupuri postuniversitare, absolvenţi-discipline. Unii absolvenți s-ar putea să nu predea cursuri, astfel încât tipul de multiplicitate la capetele asociației va fi 0. n.

Diagrama de clasă finală este prezentată în fig. 3.

Orez. 5. Diagrama de clasă simplificată

Având în vedere că atât studenții absolvenți, cât și profesorii predau cursuri, puteți introduce o clasă suplimentară abstractă, de exemplu, predare, care este un descendent al clasei o persoanași superclasă pentru cursuri profesorși absolvent, ceea ce va reduce oarecum numărul de conexiuni. (Fig. 4.). În acest caz, de la cursuri disciplinași grup asociaţiile vor merge la cursuri predare, presupunând asocierea cu clasele profesorși absolvent prin moştenire (relaţie de generalizare). La clasa predare atributele pot fi eliminate licitare(0,5 pariu, pariu complet) și deversare.

Diagrama rezultată este destul de complexă și încărcată cu elemente, dar modelarea clasei este departe de a fi completă: unele clase de utilitate și interfețe trebuie încă definite. Pentru a descărca diagrama de clase, să construim o nouă vedere a acesteia (pe o diagramă separată) lăsând imaginea claselor principale și suprimând afișarea celor auxiliare care determină tipurile de atribute (Fig. 5).

Pe fig. 5, alături de principalele clase corespunzătoare elementelor conceptuale ale sistemului, arată și clasa T_ ADR, dezvăluind structura adresei, această clasă este importantă și pentru că conține elementele de date necesare pt profesoriși studenți absolvenți- descendenții clasei o persoana.

Să trecem la definirea interfețelor. Clasele interacționează cu lumea exterioară prin interfețe.

Interfață (Interfață) este un set de operațiuni care definesc un serviciu (set de servicii) furnizat de o clasă sau componentă. Astfel, o interfață descrie comportamentul vizibil extern al unui element. O interfață poate reprezenta comportamentul unei clase sau componente în totalitate sau în parte; definește doar specificații ale operațiunilor (semnăturilor), niciodată implementările acestora. Interfața grafică este reprezentată ca un cerc, sub care este scris numele său. O interfață rareori există singură - este de obicei atașată la o clasă de implementare sau un bean. O interfață presupune întotdeauna existența unui „contract” între partea care declară executarea unui număr de operațiuni și partea care implementează aceste operațiuni.

Pune o clasă pe diagramă electronicmasa, care încapsulează toate proprietățile și operațiunile unei foi de calcul care permite editarea datelor. Structura acestei clase nu va fi dezvăluită din cauza complexității sale mari. Deci, în instrumentele moderne de dezvoltare a aplicațiilor, utilizatorul folosește clase și șabloane gata făcute, moștenind capacitățile lor, de exemplu, biblioteca VCL (Delphi) conține clasa TTable, care încapsulează capacitățile unei foi de calcul. Descendenții de clasă electronicmasa sunt foi de calcul specifice care conțin date specifice despre profesori, absolvenți, studenți, grupe, discipline și specialități. Făcând clasele corespunzătoare descendenți ai clasei electronicmasa, declarăm pentru aceste clase toate proprietățile și operațiile inerente foilor de calcul (înregistrare în sistem, inserare, ștergere, editare de date, sortare etc.).

Pentru clasă electronicmasa, și, în consecință, pentru toți descendenții săi, definim interfața editare, implicând toate operațiunile posibile de editare a datelor (inserare, ștergere, modificare a datelor). Se presupune că în clasă electronicmasa aceste caracteristici au fost implementate.

Folosind o clasă specială electronicmasa iar moștenirea a evitat definirea de proprietăți speciale și interfețe de editare a datelor pentru fiecare foaie de calcul.

Definiți interfețele Căutareprofesor, Căutaredisciplinelor, prin atașarea acestora la clasele corespunzătoare cu relații de implementare. Nu vom dezvălui compoziția operațiunilor acestor interfețe (este destul de banală), așa că vom afișa interfețele într-o formă prescurtată (sub formă de cerc). Amintiți-vă că o relație de implementare atașată la o interfață în formă scurtă este afișată ca o linie continuă simplă (ca o asociere).

Interfață Căutarestudent va fi afișată cu o indicație a listei de operațiuni printr-o clasă stereotipată, în timp ce relația de implementare este afișată ca o săgeată punctată cu vârful închis.

Desigur, se presupune că interfețele introduse sunt implementate prin intermediul claselor la care sunt atașate prin relația de implementare, adică clasele corespunzătoare conțin operații și metode care implementează interfețele declarate. Pentru a facilita percepția, aceste mecanisme nu sunt vizualizate.

Pentru a gestiona drepturile de acces și autorizarea utilizatorului, introducem clasa administratoracces. Managerul de acces are un atribut de tip de acces privat masaparolele, care este o instanță a clasei CodirTable(tabel codificat) care conține parole ( parola) și nume de intrare ( Autentificare) utilizatori administratori. Se presupune că capacitățile clasei de utilitate CodirTableîmpiedică utilizatorii neautorizați să citească parolele utilizatorului. În această etapă de proiectare, pur și simplu declarăm astfel de capacități, fără a insista asupra mecanismului pentru implementarea lor, ci presupunând că sunt încapsulate într-o clasă CodirTable.

Clasă administratoracces conţine tranzacţii deschise intrareparolași acordarea de drepturi de administrator, prin intermediul cărora sunt implementate autorizarea și gestionarea drepturilor de acces.

Indicați dependența dintre interfața de editare a datelor ( editare) și un manager de acces, presupunând că numai utilizatorii cu drepturi de administrator au capabilități complete de editare a datelor.

Orez. 6. Schema finală de clasă a postului de lucru al secretarului catedrei

Diagrama finală este prezentată în fig. 6.

Deci, dezvoltarea unui model orientat pe obiecte a stației de lucru a secretarului de departament folosind diagrama de clasă UML în această etapă poate fi considerată completă. Desigur, este posibil să reveniți la acesta și să revizuiți unele elemente în cursul proiectării sistemului, la ajustarea sarcinilor, la clarificarea detaliilor individuale. Procesul de proiectare a sistemelor informatice este iterativ. Trebuie remarcat faptul că diagrama de clase dezvoltată conține elemente care implementează în mod explicit sau implicit toate cazurile de utilizare ale diagramei de cazuri de utilizare. Fiecare caz de utilizare al unei diagrame de caz de utilizare trebuie să corespundă fie unei interfețe, fie unei operații de interfață (implementarea este presupusă în clasele corespunzătoare interfeței), fie unei operații de clasă publică, fie unui set de operații publice (în acest caz, cazul de utilizare este implementat direct de clasa sau setul de clase corespunzătoare).

Să luăm în considerare procesul de creare a unei noi înregistrări despre un elev folosind diagrame de secvență.

Crearea unei noi înregistrări necesită drepturi de administrator, astfel încât actorul din această interacțiune va fi administratorul ( admin). Acest element a fost deja introdus în Diagrama de caz de utilizare, așa că haideți să-l glisăm pe Diagrama de secvență din Browserul de vizualizare a cazurilor de utilizare.

Trebuie remarcat faptul că obiectele, adică instanțele specifice ale claselor, apar pe diagramele de interacțiune (numele obiectului este întotdeauna subliniat).

Gestionam obiecte: formăintrare, administratorînregistrări, fișa studentului Petrov(ca exemplu specific de dosar de student), administratortranzactii. Acest set de obiecte este tipic atunci când se modifică o înregistrare într-un tabel de bază de date.

Formăintrare- elementul de interfață cu utilizatorul, este o formă tipică de introducere a datelor despre un student (nume, prenume, patronimic, adresă etc.). În cazul nostru, este o implementare concretă ușor predefinită a interfeței standard editare clasă electronicmasa. Deoarece nu am introdus în mod specific interfața pentru editarea datelor elevilor pe diagrama de clasă, prin urmare, specificați în mod explicit clasa pentru obiect formăintrare nu vom.

Administratorînregistrări- un obiect care are un set standard de capabilități de gestionare a datelor atunci când lucrează cu o foaie de calcul. Acest set de capabilități este moștenit de clasă studenți din clasa electronicmasa. Pentru obiect Administratorînregistrări specifică în mod explicit clasa a cărei instanță este - studenți.

Petrov- o înregistrare specifică despre studentul Petrov, un nou element al tabelului despre studenți. Aici indicăm în mod explicit clasa introdusă intrareOstudent. Astfel de obiecte există de obicei temporar pentru a trimite informațiile relevante către baza de date în timpul tranzacțiilor. După încheierea tranzacției, acest obiect poate fi distrus. Obiectul corespunzător înregistrării poate fi recreat dacă informația trebuie editată.

Administratortranzactii- un obiect care prevede executarea unei operațiuni complete pe baza de date, în acest caz, crearea unei noi înregistrări despre studentul Petrov. Acest obiect este, de asemenea, responsabil pentru realizarea unui număr de funcții de sistem care însoțesc tranzacția. Exemple de manageri de tranzacții sunt, de exemplu, BDE (folosit pentru accesarea bazelor de date Paradox, Dbase etc. din aplicațiile Delphi), ADO (folosit pentru accesarea bazelor de date MS Access din diverse aplicații).

Schema secvenței de introducere a unei noi înregistrări despre un student în stația de lucru a secretarei catedrei este prezentată în fig. 7.

Orez. 7. Introducerea datelor studentului. Diagrama secvenței.

Pe diagrama de secvență, definim transferul de mesaje între obiecte: creanouintrare(difuzat de la obiect la obiect până la capătul lanțului ca mesaj salvaintrare); deschisformă(la formularul de introducere); introduceF.ȘI DESPRE.,adresa. ( introducerea datelor pentru un student), atunci aceste date sunt difuzate prin mesaje salvaF.ȘI DESPRE.,adresa. Din administratortranzactii se trimite un mesaj pentru colectare informațieOstudent, oferind feedback bazei de date și, în final, un mesaj reflectorizant administratortranzactii numit ca salvaintrarevDB, asigură încheierea tranzacției.

Dacă se dorește, această interacțiune poate fi reprezentată printr-o diagramă de cooperare, ilustrând, în primul rând, aspectul structural al interacțiunii (Fig. 8). Această diagramă poate fi construită din cea anterioară în modul automat (în Rational Rose, prin apăsarea tastei F5).

Orez. 8. Introducerea datelor studentului. Diagrama de cooperare.

Dacă este necesar, proiectul poate fi completat cu alte diagrame de interacțiune care dezvăluie munca precedentelor.

4.3 Proiectarea unui profil de bază de date relațională

În cazul în care un SGBD orientat pe obiecte (OODBMS) este utilizat pentru implementarea sistemului, diagrama obiect construită în secțiunea anterioară este modelul final și ghidul direct pentru implementarea sistemului informațional. În același caz, atunci când o bază de date relațională (RDB) se presupune a fi utilizată ca nucleu informațional al sistemului informațional, este necesar să se elaboreze o altă diagramă, o diagramă de profil al bazei de date relaționale.

Profilul UML pentru un proiect de bază de date este o extensie UML care păstrează metamodelul UML neschimbat. Un profil pentru un proiect de bază de date adaugă stereotipuri și valori etichetate atașate acestor stereotipuri, dar nu schimbă metamodelul UML de bază. Pentru a vizualiza elementele de proiectare ale bazei de date și regulile de proiectare a bazelor de date relaționale, la profil se adaugă pictogramele corespunzătoare (în continuare simple baze de date). Baza de date este descrisă folosind tabele, coloane și relații. Un profil are elemente care extind baza de date, cum ar fi declanșatoare, proceduri stocate, constrângeri, tipuri (domenii) definite de utilizator, vizualizări și altele. Profilul arată cum și unde sunt utilizate toate aceste elemente în model. Următoarele entități sunt definite în profilul bazei de date UML:

masa ( Tabel) - un set de înregistrări din baza de date pentru un anumit obiect, format din coloane.

Coloană ( Coloană) este o componentă a tabelului care conține unul dintre atributele tabelului (câmpul tabelului).

Primar cheie ( Cheia primară) este o posibilă cheie aleasă pentru a identifica rândurile de tabel.

Extern cheie ( Cheie externă - una sau mai multe coloane ale unui tabel care sunt cheile primare ale altui tabel.

Reprezentare ( View) - o masă virtuală care se comportă din punctul de vedere al utilizatorului în același mod ca o masă obișnuită, dar nu există de la sine.

Stocat procedură ( O procedură stocată este o funcție procedurală independentă care rulează pe server.

Domenii ( Domenii) este un set valid de valori pentru un atribut sau coloană.

Pe lângă aceste entități, pot fi introduse unele entități suplimentare care reflectă aspecte specifice ale modelului bazei de date.

Documente similare

Metodologii de dezvoltare a sistemelor informaţionale în literatura internă şi străină. Standarde de stat și internaționale în domeniul dezvoltării software. Elaborarea unui fragment din sistemul informatic „Resursa educațională și metodologică”.

lucrare de termen, adăugată 28.05.2009


Definiția conceptului „sistem”. Istoria dezvoltării și caracteristicile sistemelor informaționale moderne. Principalele etape în dezvoltarea unui sistem informatic automatizat. Utilizarea standardelor interne și internaționale în domeniul sistemelor informaționale.

prezentare, adaugat 14.10.2013


Ideea principală a metodologiei și principiilor RAD-dezvoltarea sistemelor informaționale, principalele sale avantaje. Motive pentru popularitate, caracteristici ale aplicării tehnologiei. Formularea principiilor de bază ale dezvoltării. Medii de dezvoltare folosind principiile RAD.

prezentare, adaugat 04.02.2013


Rolul structurii de conducere în sistemul informaţional. Exemple de sisteme informatice. Structura si clasificarea sistemelor informatice. Tehnologia de informație. Etapele dezvoltării tehnologiilor informaţionale. Tipuri de tehnologii informaționale.

lucrare de termen, adăugată 17.06.2003


Conceptul de instrumente CASE ca instrumente software care sprijină procesele de creare și întreținere a sistemelor informaționale (IS). Caracteristici ale tehnologiilor IDEF pentru dezvoltarea SI. Descrierea notației IDEF0. Dezvoltarea modelelor funcționale de procese de afaceri.

prezentare, adaugat 04.07.2013


Esența limbajului de modelare unificat, modelul său conceptual și principiul de funcționare, regulile și mecanismele generale. Modelarea conceptului de „competență”. Diagrama de clasă care descrie procesul de învățare. Implementarea unui sistem informatic dat.

teză, adăugată 17.02.2015


Dezvoltarea sistemelor informatice. Piața modernă a software-ului aplicat financiar și economic. Avantajele și dezavantajele introducerii sistemelor informatice automatizate. Metode de proiectare a sistemelor informatice automatizate.

teză, adăugată 22.11.2015


Conceptul de sistem informatic, tipuri de sisteme informatice. Analiza instrumentelor pentru dezvoltarea sistemelor informatice automatizate. Cerințe pentru program și produsul software. Dezvoltarea de formulare GUI și baze de date.

teză, adăugată 23.06.2015


Soluție de securitate a informațiilor. Sisteme pentru centre de date. Ce este echipamentul centrului de date. Concepte și principii de bază ale modelării. Alegerea unei metode de rezolvare a problemelor. Metoda direcției admisibile Seutendijk, algoritmul Frank–Wulf.

lucrare de termen, adăugată 18.05.2017


Conceptul de sistem informatic. Etapele dezvoltării sistemelor informaţionale. Procesele din sistemul informatic. Sistem informatic pentru gasirea niselor de piata, pentru reducerea costurilor de productie. Structura sistemului informatic. Suport tehnic.

În proiectarea conceptuală a SI sunt utilizate o serie de descrieri ale specificațiilor (cerințe, condiții, restricții etc.), printre care modele de transformare, stocare și transmitere a informațiilor ocupă un loc central. Modelele obținute în timpul studierii disciplinei, în procesul de elaborare a unui SI, se schimbă și devin modele ale SI proiectate.

Există modele funcționale, informaționale, comportamentale și structurale. Modelul funcțional al sistemului descrie setul de funcții îndeplinite de sistem. Modelele informaționale reflectă structurile de date - compoziția și relațiile lor. Modelele comportamentale descriu procesele informaționale (dinamica de funcționare), ele includ categorii precum starea sistemului, un eveniment, o tranziție de la o stare la alta, condiții de tranziție, o succesiune de evenimente. Modelele structurale caracterizează morfologia sistemului (construcția acestuia) - compoziția subsistemelor, interrelațiile lor.

Există o serie de moduri de a construi și de a reprezenta modele, diferite pentru diferite tipuri de modele. Baza este analiza structurală - o metodă de studiu a sistemului, care începe cu privirea generală a acestuia și apoi intră în detaliu, formând o structură ierarhică cu un număr tot mai mare de niveluri.

În acest manual, vom lua în considerare metodologia de construire a modelelor structural-funcționale și informaționale ale SI și proiectarea unei baze de date relaționale pe baza acestora, ilustrând acest proces cu un exemplu de instruire specific din următorul conținut.

În legătură cu diversificarea activităților, s-a primit o comandă de la conducerea Bezenchuk și Companions pentru dezvoltarea unui sistem informațional în vederea îmbunătățirii eficienței managementului.

Firma se ocupă de producția și vânzarea de mobilă. Există un catalog de mobilier tipic produs de companie. Clientul poate alege mobilier din catalog și/sau plasa o comandă conform propriei descrieri. După formarea comenzii se întocmește un contract. Compania acceptă mobilier vechi de la clienți de mobilier nou, al cărui cost se scade din prețul comenzii. Mobilierul vechi acceptat este scos la vanzare sau poate fi inchiriat. După o anumită perioadă de timp, mobilierul vechi nerevendicat este închiriat unui depozit de lemne. Se păstrează o arhivă cu informații despre comenzile finalizate. Clienții care au încheiat anterior contracte cu compania primesc o reducere la încheierea unui nou contract. Firma achizitioneaza materiale si componente necesare fabricarii mobilierului de la furnizori.

Modelarea funcțională a IC

Există mai multe metode și instrumente diferite pentru dezvoltarea modelelor structurale și funcționale ale IS. Una dintre cele mai răspândite este metoda bazată pe construcția de diagrame de flux de date (DFD - Data Flow Diagrams)

Diagrama fluxului de date

DFD este o metodă de analiză structurală care operează cu conceptele de „flux de date” și „proces” pentru a descrie sistemul ca un set de componente funcționale (procese) conectate prin fluxuri de date. În conformitate cu principiul de bază al analizei structurale, descrierea sistemului se bazează pe detalierea secvențială a funcțiilor sale, care este afișată ca un set organizat ierarhic de imagini grafice (diagrame).

Elementele principale ale diagramelor de flux de date sunt: ​​entități externe; procese; dispozitive de stocare a datelor; fluxuri de date. Fiecare astfel de element are o imagine grafică standard.

O entitate externă este un obiect care este o sursă sau un receptor de informații, de exemplu, clienți, personal, furnizori, clienți, depozit. Definiția unui obiect sau a unui sistem ca entitate externă indică faptul că acesta se află în afara granițelor SI proiectate.

Entitățile externe din exemplul de mai sus ar fi clienții de mobilă, furnizorii de materiale, un depozit și alte obiecte de domeniu. Exemple de imagini grafice ale acestora:

Funcțiile IS proiectate în modelul DFD ar trebui să fie prezentate ca procese care convertesc fluxurile de date de intrare în cele de ieșire în conformitate cu anumiți algoritmi. Fluxurile de date în sine sunt un mecanism care simulează transferul de informații de la o sursă la un receptor (de la o parte a sistemului la alta). Fluxul de date din diagramă este reprezentat de o linie care se termină cu o săgeată care arată direcția fluxului. Fiecare flux de date trebuie să aibă un nume care să reflecte conținutul său.

De exemplu, funcția IS destinată formării unei comenzi de mobilier și încheierii unui acord pentru fabricarea acesteia poate fi reprezentată în diagramă prin procesul „comandă de mobilier”. Acest proces ar trebui să primească ca intrare date despre client, necesare încheierii contractului și informații despre mobilierul comandat de acesta (tip, descriere, dimensiuni etc.). Reprezentare grafică a acestui proces și a fluxurilor de date aferente:

O unitate de date (stocare) este un dispozitiv abstract pentru stocarea informațiilor care pot fi plasate într-o unitate în orice moment și preluate pentru utilizare ulterioară. Informațiile din unitate pot proveni de la entități și procese externe, pot fi, de asemenea, consumatori de informații stocate în unitate. Grafica drive:

Diagrama de context

Diagrama nivelului superior al ierarhiei, care fixează principalele procese sau subsisteme ale SI și conexiunile acestora cu entitățile externe (intrări și ieșiri ale sistemului), se numește diagramă de context. De obicei, atunci când se proiectează IS-uri relativ simple, se construiește o singură diagramă de context cu topologie în stea, în centrul căreia se află principalul proces conectat la receptori și surse de informații (utilizatori și alte sisteme externe). Deși diagrama de context poate părea banală, utilitatea ei neîndoielnică constă în faptul că stabilește limitele sistemului analizat și determină scopul principal al sistemului. Aceasta stabilește contextul în care există diagramele de nivel inferior cu procesele, fluxurile și unitățile lor.

Diagrama de context pentru exemplul descris mai sus este prezentată în Figura 4.

De remarcat că, în scop educațional, este considerată mai jos o versiune simplificată a modelelor de sistem, în care nu vor fi prezentate fluxurile și procesele de date legate de latura financiară a activităților companiei. Deși, desigur, pentru orice companie, informațiile oportune, complete și de încredere despre situația sa financiară sunt vitale. În acest exemplu, „componenta financiară” este evident prezentă în interacțiunea companiei cu toate entitățile externe reprezentate în diagrama de context.

Entitățile externe prezentate în această diagramă acționează ca surse de informații care sunt stocate și procesate în SI-ul companiei și ca consumatori ai acestor informații. În acest model sunt identificate două entități „client”, care sunt imagini ale clienților reali ai companiei: „client” și „cumpărător”, deoarece există diferențe semnificative în conținutul informațiilor pe care le schimbă cu IS.

Pentru „client-client”, fluxul de date „catalog” este o descriere a mobilierului tipic produs de firmă. Fluxul de date „comandă” poate include informații despre comandarea mobilierului selectat din catalog și/sau o descriere de către client a mobilierului care nu se află în catalog și, de asemenea, eventual informații despre mobilierul vechi vândut de client către companie.

Pentru „client-cumpărător”, fluxul de date „catalog de mobilă veche” este informații despre mobila veche disponibilă primită de la clienți. Fluxul „cumpărare/închiriere de mobilier vechi” reprezintă informații despre mobila veche selectată de client, pe care acesta dorește să o cumpere sau să închirieze.

În același timp, în practică, sunt posibile situații în care „client-client” și „client-cumpărător” vor fi aceeași persoană.