1 din 38

Prezentare pe tema: Modelarea sistemelor informatice

Slide nr. 1

Slide nr. 2

Descriere diapozitiv:

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 studenților a abilităților și interesului lor pentru activități creative, de cercetare în domeniul modelării informaționale; - pregătire pentru intrarea la universitate pentru specialități legate de modelarea informației și tehnologiile informatice: matematică aplicată, modelare, sisteme de calcul etc.

Slide nr. 3

Descriere diapozitiv:

Slide nr. 4

Descriere diapozitiv:

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. Foaie de calcul - Instrumentul 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. Set de instrumente pentru modelarea matematică pe calculator (Excel, MathCad, VBA, Pascal) 2.3. Modelarea optimă a proceselor de planificare 2.4. Aplicații de simulare pe calculator

Slide nr. 5

Descriere diapozitiv:

„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 bazelor metodologiei pentru construirea sistemelor de referință informațională. Elevii dobândesc o înțelegere a etapelor dezvoltării unui sistem informațional: etapa de proiectare și etapa de implementare. Crearea unei baze de date multitabulare are loc în mediul SGBD relațional MS Access. Elevii stăpânesc tehnicile de construire a unei baze 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 grafică vectorială la construirea modelelor structurale ale sistemelor - studiul aprofundat al capacităților MS Access DBMS - utilizarea MS Excel ca mijloc de lucru cu o bază de date - programarea în VBA în mediul Excel pentru dezvoltarea interfeței - când lucrați pe rezumate, se recomandă utilizarea resurselor de pe Internet; pregăti material pentru protecție sub formă de prezentare (Power Point)

Slide nr. 6

Descriere diapozitiv:

Metoda de predare a proiectului Enunțarea problemei: Domeniul de studiu: gimnaziu Scopul proiectului: crearea unui sistem informațional „Procesul educațional” Scopul sistemului informațional: informarea utilizatorilor: Despre corpul elevilor de clase Despre personalul didactic al școlii Despre repartizarea predării sarcina si conducerea clasei Despre progresul elevilor

Slide nr. 7

Descriere diapozitiv:

Slide nr. 8

Descriere diapozitiv:

Slide nr. 9

Descriere diapozitiv:

Slide nr. 10

Descriere diapozitiv:

Slide nr. 11

Descriere diapozitiv:

Slide nr. 12

Descriere diapozitiv:

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 care au A la informatică. Concept de subschemă Folosind o alegere ipotetică a limbajului de interogare ELEVI NUMELE ELEVII NUME ELEVĂ CLASA ELEVI CLASA ELEV = '9? sortați ELEVI.NUMELE crescător

Slide nr. 13

Descriere diapozitiv:

Slide nr. 14

Descriere diapozitiv:

Slide nr. 15

Descriere diapozitiv:

Programare VBA Private Sub CommandButton1_Click () „Descrierea variabilelor Dim i, j, n As Integer Dim Flag As Boolean” Inițializarea datelor Flag = False „Determină numărul de rânduri din lista de școli n = Interval (" A3 "). CurrentRegion .Rânduri. Numărați „Căutați în listă 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 programului pentru procesarea evenimentului „Clic pe butonul CĂUTARE”

Slide nr. 16

Descriere diapozitiv:

„Modelarea matematică pe calculator” Obiectivele studierii secțiunii Stăpânirea modelării ca metodă de cunoaștere a realității înconjurătoare (natura de cercetare științifică a secțiunii) - se arată că modelarea în diferite domenii ale cunoașterii are caracteristici similare, adesea pentru procese diferite este posibil pentru a obține modele foarte asemănătoare; - demonstrează 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 cunoaște lumea înconjurătoare, de a o controla în interesul omului. Dezvoltarea abilităților practice în modelarea computerizată. 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, sunt implementate practic toate etapele modelării, de la formularea problemei până la interpretarea rezultatelor obținute în decursul unui experiment pe calculator. Promovarea orientării profesionale a elevilor. Dezvăluirea aptitudinii studentului pentru activități de cercetare, dezvoltarea potențialului creativ, orientarea către alegerea unei profesii legate de cercetarea științifică. Depășirea disocierii subiectului, integrarea cunoștințelor. Cursul examinează modele din diverse domenii ale științei folosind matematica. Dezvoltarea și profesionalizarea abilităților informatice. Stăpânire software pentru scopuri generale și specializate, sisteme de programare.

Slide nr. 17

Descriere diapozitiv:

Slide nr. 18

Descriere diapozitiv:

Modelarea proceselor de planificare optimă Problema programării lucrării unei staţii de service.Enunţarea problemei Lăsaţi service-ul auto să efectueze două tipuri de service: TO-1 şi TO-2. Mașinile sunt acceptate la începutul zilei de lucru și predate clienților la sfârșit. Datorită spațiului de parcare limitat, 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 prin TO-2, atunci 50. Costul (pentru client) al TO-2 este de două ori mai mare. ridicat ca cel al TO-1. În realitate, unele dintre mașini trec TO-1, iar unele, în aceeași zi, trec TO-2. Este necesar să se întocmească un astfel de plan zilnic de servicii pentru a asigura întreprinderii cele mai mari încasări de numerar.

Slide nr. 19

Descriere diapozitiv:

Modelarea proceselor de planificare optimă Formalizarea și modelarea matematică a problemei Indicatori planificați x - planul zilnic de producție TO-1; y - planul zilnic de producție pentru TO-2. Din formularea problemei rezultă sistemul de inegalități.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 sistemul de constrângeri. Am o problemă de programare liniară

Slide nr. 20

Descriere diapozitiv:

Slide nr. 21

Descriere diapozitiv:

Modelarea proceselor de planificare optimă Metode de rezolvare a problemei programării liniare Metoda Simplex este o metodă universală de rezolvare a problemei programării liniare Tabel Simplex Baza St. x1 ¼ xi ¼ xr xr + 1 ¼ xj ¼ xn x1 b1 1 ¼ 0 ¼ 0 a1, r + 1 ¼ a1j ¼ a1n xi bi 0 1 ¼ 0 ai, r + 1 ¼ ¼ ¼ aij ¼ ain ¼ ¼ ¼ ¼ ain ¼ ¼ xr br 0 0 ¼ 1 ar, r + 1 ¼ arj ¼ Arn f 0 0 0 ¼ 0 gr + 1 ¼ gj ¼ gn

Slide nr. 22

Descriere diapozitiv:

Slide nr. 23

Descriere diapozitiv:

Slide nr. 24

Descriere diapozitiv:

Slide nr. 25

Descriere diapozitiv:

Modelarea proceselor optime de planificare Private Sub CommandButton1_Click () Dim d (5, 9) Ca Variant Dim i, j, r, n, k, m Ca Integer Dim p, q, t Ca șir Dim a, b Ca dublu pentru i = 1 La 5 Pentru j = 1 La 9 d (i, j) = Interval ("a6: i10"). Celule (i, j) .Valoare Următorul j Următorul în = 7: r = 3 "Analiza optimității curentului soluție 't = "următorul" Do While t = "următorul" Program cu metoda Simplex în VBA pentru Excel (fragment)

Slide nr. 28

Descriere diapozitiv:

Slide nr. 29

Descriere diapozitiv:

Modelarea proceselor de planificare optimă 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 construirii fiecăreia dintre secțiunile posibile este cunoscut (prezentat în figură). În realitate, drumul va fi niște linii întrerupte care leagă punctele H și K. Este necesar să găsiți o astfel de linie care să aibă cel mai mic cost. Aceasta este o sarcină de programare dinamică

Descriere diapozitiv:

Slide nr. 33

Descriere diapozitiv:

Simulare pe calculator Se folosește aparatul de statistică matematică Evenimente aleatoare: - interval de timp dintre două tranzacții - timpul de serviciu al tranzacției Funcții de densitate de probabilitate a evenimentelor aleatoare Distribuție uniformă Distribuție normală Gaussiană Distribuție Poisson

Descriere diapozitiv:

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 sisteme; ce este un model de domeniu infologic; ce este o bază de date (DB); clasificarea bazei de date; structura unei baze de date relaționale (RDB); normalizarea bazei de date; ce este un SGBD; cum sunt organizate legăturile într-o bază de date multitabulară; care sunt tipurile de interogări către baza de date; care este structura comenzii de solicitare pentru selectarea și sortarea datelor; ce posibilități de lucru cu baze de date are un procesor de foi de calcul (MS Excel); cum puteți crea și executa o macrocomandă în MS Excel; ce este o aplicație orientată pe obiecte; Bazele programării VBA; conținutul conceptelor „model”, „model informațional”, „model matematic computerizat”;

Slide nr. 36

Descriere diapozitiv:

etapele modelării matematice pe calculator, conținutul acestora; alcătuirea setului de instrumente pentru modelarea matematică pe calculator; capacităț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 metoda modelarii computerizate; enunţ de probleme rezolvate prin metoda programarii liniare; enunţ de probleme rezolvate prin metoda programării dinamice; conceptele de bază ale teoriei probabilității, necesare pentru implementarea modelării simulării: o variabilă aleatoare, legea distribuției unei variabile aleatoare, densitatea probabilității a distribuției, fiabilitatea rezultatului unui studiu statistic; modalități de a obține șiruri de numere aleatoare cu o lege de distribuție dată; enunţ de probleme rezolvate prin metoda modelării prin simulare în teoria stării de aşteptare.

Slide nr. 37

Descriere diapozitiv:

Elevii ar trebui să fie capabili: să proiecteze un sistem simplu de informare și referință; proiectarea unei baze de date multitabulare; navigați în mediul MS Access DBMS; creați o structură de bază de date și umpleți-o cu date; faceți interogări pentru selecție în MS Access folosind designerul de interogări; lucrul cu formulare; face întrebări odată cu primirea 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 handlere de evenimente simple în VBA. să aplice schema unui experiment pe calculator atunci când se rezolvă probleme semnificative în care este nevoie de modelare matematică pe calculator; selectați factorii care influențează comportamentul sistemului studiat, efectuați ierarhizarea acestor factori;

Slide nr. 38

Descriere diapozitiv:

construirea modelelor proceselor studiate; alege software-ul pentru studierea modelelor construite; să analizeze rezultatele obținute și să investigheze modelul matematic pentru diverse seturi de parametri, inclusiv de frontieră sau critici; utilizați modele economice simple de optimizare; construiți cele mai simple modele de sisteme de așteptare și interpretați rezultatele. implementează 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, ilustrați grafic rezultatele modelării; utilizați sistemul MathCAD pentru a rezolva probleme de optimizare liniară și neliniară.

Trimiteți-vă munca bună în baza de cunoștințe este simplu. Utilizați 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.

Postat pe http://www.allbest.ru/

Institutul de Stat de Serviciu din Omsk

Modelarea sistemelor informatice folosind limbajul UML

Instrucțiuni metodice pentru implementarea lucrării de termen

I.V. Chervenchuk

• Introducere
• 2 . Limbajul de modelare unificatUML
• 4. Dezvoltarea unui model de sistem software prin mijloaceUML
• 5. Probleme de implementare a sistemului informatic
• 6. Subiecte de curs
• 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 date exemple și ilustrații. Sunt oferite opțiuni pentru teme pentru cursuri.

Instrucțiunile metodice sunt destinate studenților specialității „Informatică aplicată” și pot fi utilizate în cursuri, pregătirea pentru examen, precum și în procesul de muncă independentă.

1. Cerințe generale pentru implementarea documentului de termen

Lucrarea cursului la disciplina "Sisteme și procese informaționale. Modelare și management" reprezintă etapa finală a studierii acestui curs și este menită să consolideze în practică cunoștințele teoretice de bază ale modelării sistemelor informaționale. Lucrarea constă în dezvoltarea unui model al unui sistem informaţional prin intermediul limbajului unificat de modelare UML cu implementarea sa ulterioară. Ca variantă tipică a temei, 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 oferit ca sarcină. În același timp, principala condiție prealabilă este utilizarea unei abordări orientate pe obiecte și construirea unui model UML.

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

Introducere

1. Privire de ansamblu substanțială a domeniului subiectului. Cerințe de bază ale sistemului

2. Un model detaliat al sistemului informatic

2.1 Vedere din perspectiva cazurilor de utilizare

2.2 Vedere de proiectare

2.3 Vedere de implementare

2.4 Perspectiva procesului (dacă este cazul)

2.5 Vedere din punct de vedere al implementării (dacă este necesar)

3. Implementarea sistemului informatic

Concluzie

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

În introducere, se poate indica utilizarea tehnologiei informației în diverse domenii de activitate, inclusiv 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 unei note explicative, oferindu-le comentarii detaliate. , iar textele programelor ar trebui să fie plasate în aplicație.

Vizualizarea procesului ar trebui să fie dată la proiectarea sistemelor multitasking. Vederea de implementare presupune un sistem de informații distribuit. Aceste tipuri, precum și secțiunile corespunzătoare ale notei explicative, nu sunt obligatorii pentru implementarea acestei lucrări de curs, utilizarea lor fiind asumată la efectuarea doar a anumitor variante ale lucrării de curs.

La evidențierea problemelor de implementare a sistemului într-o notă, este recomandabil să se justifice alegerea unui mediu de programare, 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 este implementat printr-un mediu de programare pe care sistemul dezvoltat îl permite, avantajele abordărilor utilizate (bazate pe modelare) la proiectarea sistemelor.

modelarea limbajului sistemului informatic

Lucrarea cursului trebuie să conțină 20-30 de pagini de text tipărit cu ilustrații. Diagramele de cazuri de utilizare, clase, interacțiuni trebuie furnizate fără greșeală.

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 în curs de dezvoltare, apoi, să se elaboreze un model al sistemului, iar în final, să se determine metodele de implementare. Un studiu profund al arhitecturii sistemului informatic în curs de dezvoltare în fazele inițiale de proiectare, de regulă, dă roade mai târziu, 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) permit în mod expresiv și destul de ușor să se realizeze o dezvoltare conceptuală preliminară a unui sistem informațional și, în același timp, să însoțească metodic întregul proces de dezvoltare, inclusiv întregul ciclu de viață al sistemului informațional dezvoltat ca produs software.

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

UML, ca orice altă limbă, constă dintr-un vocabular și reguli care vă permit să combinați cuvintele incluse în el și să obțineți construcții semnificative. Într-un limbaj de modelare, vocabularul și regulile sunt concentrate pe reprezentarea conceptuală și fizică a sistemelor informaționale. Modelarea este esențială pentru înțelegerea sistemului. Acestea fiind spuse, un singur model nu este niciodată suficient. Dimpotrivă, pentru a înțelege orice sistem non-trivial trebuie dezvoltat un număr mare de modele interconectate. Așa cum este aplicat sistemelor software, aceasta înseamnă că este nevoie de un limbaj cu care să poată descrie din diverse puncte de vedere reprezentările arhitecturii sistemului de-a lungul ciclului său de dezvoltare.

UML este un limbaj de vizualizare, iar UML nu este doar o colecție de simboluri grafice. Fiecare dintre ele are 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 un set de instrumente.

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 tabele de baze de date relaționale sau obiecte persistente de baze de date orientate pe obiecte. Acele concepte care sunt de preferință transmise grafic sunt reprezentate în UML; cele care sunt mai bine descrise sub formă de text sunt exprimate folosind un limbaj de programare.

Această mapare a unui model la un limbaj de programare permite proiectarea directă: generarea de cod dintr-un model 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ă coerența î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 de operare.

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 la care se face referire nu sunt doar părți ale proiectului furnizate; 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 conducerii propria soluție la problema documentării arhitecturii sistemului și a tuturor detaliilor sale, oferă un limbaj pentru formularea cerințelor de sistem și definirea testelor și, în cele din urmă, oferă un mijloc de lucru de modelare în timpul planificării proiectului și controlului versiunilor. fază.

Să luăm în considerare dezvoltarea unui model de sistem informatic prin intermediul limbajului UML folosind exemplul dezvoltării unei stații de lucru automatizate pentru un secretar de departament (denumit în continuare AWP al secretarului de departament).

3. Descrierea domeniului subiectului

Conceptul de domeniu al bazei de date este unul dintre conceptele de bază ale informaticii și nu are o definiție precisă. Utilizarea acestuia în contextul PI presupune existența unei corelații stabile în timp între nume, concepte și anumite realități ale lumii externe, independent de PI în sine și de cercul său de utilizatori. Astfel, introducerea în considerare a conceptului de domeniul bazei de date limitează și face vizibil spațiul de regăsire a informațiilor în IS și face posibilă executarea interogărilor într-un timp finit.

Sub descrierea domeniului subiectului, ne referim la 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 se introduc termenii de bază (vocabul sistem), se determină tipurile de utilizatori și drepturile acestora, se formulează sarcinile pe care sistemul dezvoltat trebuie să le rezolve. În acest caz, descrierea ar trebui să folosească mijloacele de limbaj obișnuit și grafica standard de afaceri (imagini, diagrame, tabele).

La elaborarea unui dicționar de sistem, este necesar să se definească denumirile entităților („student”, „profesor”, „disciplină”). În acest caz, termenul de esență 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 de analist în entități.

Entitatea este rezultatul abstracției unui obiect real. Există două probleme asociate obiectelor: identificarea și descrierea adecvată. Pentru identificare se folosește un nume, care trebuie să fie unic. În acest caz, se presupune că există o respingere a sensului său, care este inerent limbajului natural. Se folosește doar funcția indicativă a numelui. Numele este un mod direct de a identifica un obiect. Metodele indirecte de identificare a obiectelor includ definirea unui obiect prin proprietățile sale (caracteristici sau semne).

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 incluzivă. Astfel, toate informațiile despre obiectele și entitățile domeniului sunt descrise folosind declarații în limbaj natural.

Puteți specifica legături 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 mijloace avansate de descriere a domeniului, de exemplu, mijloace de limbajul UML.

Deci, sarcina este de a dezvolta un sistem „stație de lucru a secretarului departamentului” care să permită contabilitatea automată a datelor privind angajații și studenții departamentului de TIC al OmSTU, să ofere oportunități flexibile pentru rezolvarea sarcinilor specifice planificate și neplanificate de prelucrare. acreditările.

Ca parte a soluționării problemei dezvoltării unui loc de muncă automatizat pentru secretarul departamentului, vom evidenția următoarele entități:

profesori - profesorii catedrei;

studenți- studenți ai universității de această specialitate;

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 consilier științific;

disciplina- disciplina predată (disciplina, cursul).

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

Conducem două tipuri de utilizatori: privat utilizator(mai departe utilizator, și administrator... Se presupune că utilizator poate accesa sistemul cu o solicitare, afișa rapoarte, administratorîn plus, poate modifica 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 în curs de dezvoltare ar trebui să ofere:

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

susținerea informațională a deciziilor de management luate, formarea de informații complete și sigure despre procesele educaționale și rezultatele activităților 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ță prietenoasă cu utilizatorul;

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

În acest exemplu, rezolvăm o anumită problemă - dezvoltăm AWP pentru secretarul departamentului, prin urmare, departamentul este luat ca o unitate structurală de cel mai înalt nivel pentru noi, pe care o vom avea în vedere implicit, adică se presupune că toate elementele modelului se referă numai la acest departament, care nu este specificat în mod explicit... Nu vom lua în considerare structuri de nivel superior, cum ar fi o facultate, o universitate.

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 șabloane, cel mai adesea reprezentată ca un graf conectat cu vârfuri (entități) și margini (relații). Diagramele caracterizează sistemul din diferite puncte de vedere. O diagramă este, într-un fel, una dintre proiecțiile sistemului. De obicei, diagramele oferă o vedere restrânsă a elementelor care alcătuiesc un sistem. Unul și același element poate fi prezent în toate diagramele, sau numai în mai multe (varianta cea mai comună), sau nu poate fi prezent în nici una (foarte rar). În teorie, 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, în UML se disting nouă tipuri de diagrame:

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 ale componentelor;

diagrame de implementare.

Model conceptual UML

O diagramă de clasă arată clase, interfețe, obiecte și colaborări și relațiile lor. La modelarea sistemelor orientate pe obiecte, acest tip de diagramă este folosit cel mai des. Diagramele de clasă reprezintă o vedere statică de proiectare a unui sistem. Diagramele de clase care includ clase active corespund vederii statice a sistemului din perspectiva procesului.

O diagramă de obiecte reprezintă obiectele și relațiile dintre ele. Sunt „fotografii” statice ale instanțelor de entitate prezentate în diagramele de clasă. Diagramele de obiecte, precum diagramele de clasă, se referă la o vedere statică a unui sistem dintr-o perspectivă de proiectare sau proces, dar în vederea unei implementări reale sau simulate.

Diagrama cazurilor de utilizare prezintă cazuri de utilizare și actori (un caz special de clase), precum și relațiile dintre ei. Diagramele de cazuri de utilizare se referă la o vedere statică a unui sistem în termeni de cazuri de utilizare. Ele sunt deosebit de importante atunci când se organizează și se modelează comportamentul unui sistem.

Diagramele secvențe și diagramele 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 sistemului. În acest caz, diagramele de secvență reflectă ordonarea temporală a mesajelor, iar diagramele de cooperare - organizarea structurală a obiectelor care fac schimb de mesaje. Aceste diagrame sunt izomorfe, adică pot fi transformate una în alta.

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 sistemului; ele sunt deosebit de importante atunci când se modelează comportamentul unei interfețe, clase sau cooperări. Ele se concentrează pe comportamentul unui obiect, în funcție de succesiunea evenimentelor, ceea ce este foarte util pentru simularea sistemelor reactive.

O diagramă de activitate este un caz special al unei diagrame de stare; arată tranzițiile fluxului de control de la o activitate la alta în cadrul sistemului. Diagramele de activitate se referă la o vedere dinamică a unui sistem; 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 dintre acestea. Diagramele componente se referă la o vedere statică a unui sistem din punct de vedere al implementării. Ele pot fi legate de diagramele de clasă, deoarece o componentă se mapează de obicei 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 componente deoarece un subansamblu conține de obicei una sau mai multe componente.

Iată 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 unei vederi dintr-o perspectivă de caz de utilizare

Modelarea începe cu definirea obiectivelor principale ale sistemului în curs de dezvoltare și a acțiunilor pe care ar trebui să le realizeze. Diagramele de cazuri de utilizare sunt utilizate în aceste scopuri. După cum sa discutat mai devreme, diagramele de cazuri de utilizare indică cazuri de utilizare și actori și relațiile dintre ei.

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

Un actor este un set coerent de roluri pe care utilizatorii de cazuri de utilizare le joacă atunci când interacționează cu ei. De obicei, un actor reprezintă rolul pe care o persoană, un dispozitiv hardware sau chiar un alt sistem îl joacă într-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ă a cazurilor 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 cazurilor de utilizare 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ă criteriu”, etc. Este posibil să dați nume pentru cazurile de utilizare cu substantive care sugerează unele acțiuni, de exemplu, „autorizare”, „căutare”, „control”.

Revenind la modelarea locului de muncă automatizat al secretarului de departament, să evidențiem precedentele:

Editaredate,

Căutarestudent,

Căutareprofesor,

Emiterelistăpredatdisciplinelor,

Autorizare.

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

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 - o relație de includere și o relație de extensie.

O relație de includere între cazurile de utilizare înseamnă că la un moment dat în cazul de utilizare de bază este încorporat (inclus) comportamentul altui caz de utilizare. Cazul de utilizare inclus nu există niciodată în mod autonom, ci este instanțiat doar ca parte a cazului de utilizare alăturat. Vă puteți gândi la cazul de utilizare de bază ca împrumutând comportamentul include. Datorită prezenței relațiilor de incluziune, este posibil să se evite mai multe descrieri ale aceluiași flux de evenimente, deoarece comportamentul general poate fi descris ca un caz de utilizare independent inclus în cele de bază. O relație de includere este un exemplu de delegare, în care un număr de responsabilități ale sistemului sunt descrise într-un singur loc (în cazul de utilizare inclus), iar restul cazurilor de utilizare, atunci când este necesar, includ aceste responsabilități în setul lor.

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. Acest lucru vă permite să separați comportamentele obligatorii și opționale. 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 simula mai multe fluxuri care pot fi declanșate la un moment dat în scenariu ca rezultat al interacțiunii explicite cu actorul.

Relația de extensie este descrisă ca o dependență cu stereotipul „extend”. Punctele de extensie a scriptului de bază sunt listate într-o secțiune suplimentară. Sunt pur și simplu etichete care pot apărea în fluxul cazului de utilizare subiacent.

Un exemplu de utilizare a acestei relații poate fi accesul la o bază de date cu o parte operațională și o arhivă. În acest caz, dacă solicitarea este furnizată cu date din partea operațională, se realizează accesul principal (de bază) la date, dacă datele din partea operațională nu sunt suficiente, se accesează datele de arhivă, adică accesul este realizat conform scenariului avansat.

În cazul nostru, precedentul editaredate include cazuri de utilizare: intraredate, ştergeredate, schimbareadate.

Diagrama precedentelor AWP a secretarului departamentului este prezentată în Fig. 1.

Orez. 1. Diagrama precedentelor AWP a secretarului departamentului

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

Atunci când proiectați o vedere în termeni de cazuri de utilizare, este adesea necesar să furnizați o descriere extinsă a cazului de utilizare (numai numele este dat în versiunea prescurtată). De obicei, fluxul de evenimente al unui caz de utilizare este descris sub formă de text la început. Pe măsură ce vă rafinați cerințele de sistem, 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 prin intermediul textului nestructurat, text structurat (conținând cuvinte de serviciu: DACĂ,INAINTE DEACESTEAPORPA etc.), un limbaj formal specializat (pseudocod).

Când descriem un caz de utilizare ca 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 îi cere utilizatorului Login-ul și parola. Utilizatorul îl poate introduce de la tastatură. Intrarea se termină cu o apăsare a tastei. introduce. După aceea, sistemul verifică Login-ul și parola introduse și, dacă se potrivesc cu administratorul, confirmă autoritatea administratorului. Aceasta încheie precedentul.

Excepţional curgere evenimente. Clientul poate încheia tranzacția în orice moment apăsând tasta Anulare. Această acțiune începe din nou precedentul. Nu există nicio intrare în sistem.

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

Excepţional curgere evenimente. Dacă clientul a introdus Login și parolă care nu corespund administratorului, i se oferă să intre din nou sau să se autentifice în sistem ca utilizator obișnuit.

Evident, descrierea unui caz de utilizare printr-un flux de evenimente presupune un fel de 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, cu un singur început și un capăt. Diagrama conține vârfuri executabile - activități (indicate prin dreptunghiuri rotunjite), vârfuri condiționate (decizie - selecție, recunoaștere, indicate cu romburi) și legături.

Diagrame similare pot explica execuția altor cazuri de utilizare, completând astfel viziunea sistemului din punct de vedere al cazurilor de utilizare.

Orez. 2. Autorizarea utilizatorului. Diagrama activității.

4.2 Dezvoltarea unei vederi de proiectare

Vederea de proiectare este etapa principală în studiul conceptual al modelului. În această etapă sunt introduse abstracțiile de bază, sunt definite clase și interfețe prin care se implementează soluția sarcinilor. Dacă cazurile de utilizare declară doar comportamentul sistemului, atunci în etapa de dezvoltare a vederii din punct de vedere al designului se determină prin ce mijloace vor fi implementate aceste cazuri de utilizare. 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, cooperări, precum și conexiuni între 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 este necesar să decidem care entități sunt mai convenabile de modelat ca clase și care sunt atributele lor. De exemplu, dacă s-a cerut în cadrul facultății să se indice șef pentru fiecare catedra, ar fi bine să se precizeze administratorScaune fă din acesta un atribut de clasă scaun indicând clasa profesori ( asociere unu-la-unu ), mai degrabă decât introducerea unei clase separate administratorScaune.

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 zonei problemei sau al zonei de soluție;

conţine un set mic, bine definit de responsabilităţi şi îndeplineşte fiecare dintre ele;

menține o separare clară între specificațiile de abstractizare și implementarea acesteia;

de înțeles și simplu, dar în același timp permite extinderea și adaptarea la noi sarcini.

Ca parte a dezvoltării modelului locului de muncă automatizat al secretarului departamentului, vom defini clasele: profesori, studenți, studenți absolvenți, disciplinelor, grup... Evident, primele dintre ele au multe atribute comune, așa că haideți să introducem o clasă abstractă PEerson, care va cuprinde toate proprietățile umane în contextul sistemului în curs de dezvoltare (nume, prenume, adresă etc.). În acest caz o persoana va fi superclasa și va comunica prin relație generică cu clasele 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). Rețineți 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 (indicată printr-o săgeată întreruptă cu vârful deschis, săgeata este îndreptată 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 prin intermediul unui tip primitiv T_ POSTIDX, definit ca un număr zecimal din șase cifre. Tipurile primitive sunt stereotipe" tip" , intervalul de valori este specificat prin constrângerile cuprinse între acolade.

In clasa profesor să evidențiem atributele specifice legate doar de profesor: poziţie, uh. grad(grad academic), uh. rang ( rang academic), deversare(categoria unui singur tarif tarifar). Atribute uh. gradși uh. rang este mai bine să definiți tipurile specializate prin enumerare. Enumerările sunt modelate de o clasă cu stereotipul " enumerare" (enumerare - enumerare), valorile permise sunt scrise ca atribute, etichetele care determină vizibilitatea atributelor sunt suprimate. În exemplul considerat, prin enumerare, introducem clase de specialitate T_Trebuie sa, T_UCHST, T_UchZv, respectiv definirea posibilelor posturi, grade academice, titluri academice prin transferuri. Î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 se introduce un atribut specific camerăcărți de recorduri... Atributele specifice sunt definite pentru clasa postuniversitară formăînvăţareși Datachitanțe... Forma de studiu va fi determinată de o clasă specială printr-o enumerare T_FormObuch(normă întreagă, jumătate de normă).

Clasă grup are atribute: titlu, formă învăţare, numărstud. ( numarul studentilor ). Avand in vedere ca profesorii catedrei in cauza pot preda grupe de la alte facultati, se introduce o clasa suplimentara specialitate, cu atribute cameră(specialitate), titlu(specialitate ), facultate ale căror tipuri nu sunt specificate în acest model, deși pot fi determinate prin enumerări.

Clasă disciplina are atribute: cameră, titlu, ciclu. Atribut ciclu prin intermediul unui tip specializat introdus printr-o enumerare T_Cycles determină cărui ciclu îi aparține disciplina: ciclul 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, deoarece depind de specialitate, cu atât mai mult nu le poți indica în clasă specialitate... Aceste atribute se referă la perechea specialitate-disciplină și sunt definite în clasa - asociație Discipline-specialități.

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

Când redați o structură de clasă, acordați atenție vizibilității atributelor. Toate atributele luate în considerare trebuie să fie disponibile și să aibă vizibilitate Public (notat cu un semn „+” sau o pictogramă fără lacăt). În clasele luate în considerare, ne-am concentrat mai degrabă pe structură decât pe comportament (operațiile nu au fost descrise și nu trebuie descrise), prin urmare, pentru a face diagrama mai ușor de citit, este de dorit să se suprima operațiile.

Pe setul de clase introdus, este necesară redefinirea legăturilor. Legăturile de generalizare și dependențe au fost deja determinate, rămâne de definit asocierile.

Studenți format în grup, in acest caz asocierea va avea forma de agregare. Agregarea presupune o relație parțială-întreg, notată printr-o linie continuă cu un romb la sfârșit din toată latura (în cazul nostru grup). Pluralitatea relațiilor multi-la-unu elev-grup. Fiecare grup se referă la un anume specialitate, la rândul lor, mai multe grupe pot corespunde unei anumite specialități, prin urmare asociația grup-specialitate are și tipul de multiplicitate „mulți 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 ca „mulți-la-mulți”: un profesor poate preda mai multe discipline, unele discipline pot fi predate de mai mulți profesori. Între disciplinelorși specialități se înfiinţează şi asociaţia „mulţi-la-mulţi”: programa de specialităţi conţine multe discipline, majoritatea disciplinelor se regăsesc în planurile de lucru ale mai multor specialităţi. Clasa de asociere este atașată acestei asociații. 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 in grupuriși profesori: Profesorii predau în grupuri, tip asociere multi-la-mulți. Asociere directă între in grupuriși discipline nu trebuie să definiți, deoarece această relație este urmărită prin clasa de liant specialitate.

Pentru a afișa prezența unui supervizor pentru un student absolvent, este necesar să se introducă o asociere între un absolvent și un profesor de tip „multi-la-unu”; un supervizor poate avea mai mulți absolvenți. În această asociere din partea profesorului, puteți indica în mod explicit rolul: supraveghetor.

Orez. 4. Diagrama claselor de AWP a secretarului departamentului (opțiunea 2)

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

Studenți postuniversitari poate preda, de asemenea, discipline specifice unor grupuri specifice: asociații multi-la-mulți grupuri postuniversitare, discipline postuniversitare. Unii absolvenți s-ar putea să nu predea, 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, se poate introduce o clasă suplimentară de abstract, de exemplu, predare care este un descendent al clasei o persoanași o superclasă pentru clase profesorși absolvent, ceea ce va reduce ușor numărul de conexiuni. (fig. 4.). În acest caz, de la clase disciplinași grup asociaţiile vor merge la cursuri predare, presupunând o legătură către clase profesorși absolvent prin moştenire (relaţie de generalizare). La clasa predare poti scoate atributele licitare(0,5 tarif, tarif complet) și deversare.

Diagrama rezultată este destul de complexă și încărcată cu elemente, dar modelarea claselor este departe de a fi completă: unele clase de utilitate și interfețe mai trebuie definite. Pentru a descărca diagrama de clase, vom construi 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).

În fig. 5, alături de principalele clase corespunzătoare elementelor conceptuale ale sistemului, este prezentată și clasa T_ ADR, dezvăluind structura adresei, această clasă este de asemenea importantă, deoarece conține elementele de date necesare pentru 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ța) este o colecție 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țiile operațiunilor (semnăturilor), dar niciodată implementarea acestora. Interfața grafică este reprezentată ca un cerc, sub care este scris numele său. O interfață există rareori pe cont propriu – este de obicei atașată unei clase sau componente de implementare. Interfața presupune întotdeauna existența unui fel de „contract” între partea care declară executarea unui număr de operațiuni și partea care implementează aceste operațiuni.

Plasați clasa pe diagramă electronicmasa, care încapsulează toate proprietățile și operațiunile foii de calcul care vă permite să editați datele. Nu vom dezvălui structura acestei clase datorită 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 o clasă TTable care încapsulează capacitățile unei foi de calcul. Descendenții clasei electronicmasa sunt foi de calcul specifice care conțin date specifice pentru facultate, absolvenți, studenți, grupuri, 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). În acest caz, se presupune că în clasă electronicmasa aceste posibilități sunt implementate.

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

Să definim interfețele Căutareprofesor, Căutaredisciplinelor prin atașarea lor la clasele lor respective cu o relație de implementare. Nu vom dezvălui compoziția operațiilor acestor interfețe (este destul de banală), prin urmare, vom afișa interfețele într-o formă prescurtată (sub formă de cerc). Amintiți-vă că o relație de implementare atașată unei interfețe în formă prescurtată este afișată ca o simplă linie continuă (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ă printr-o săgeată întreruptă 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 ușurința percepției, 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) al utilizatorilor administrator. Se presupune că capacitățile clasei de serviciu CodirTable nu permiteți unui utilizator neautorizat să citească parolele utilizatorului. În această etapă a proiectării, pur și simplu declarăm astfel de capacități, fără a insista asupra mecanismului de implementare a acestora, 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 se realizează autorizarea și gestionarea drepturilor de acces.

Să indicăm 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ă a claselor AWP a secretarului de catedra

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

Deci, în această etapă, dezvoltarea unui model orientat pe obiecte a stației de lucru a secretarului departamentului prin intermediul diagramei de clasă UML poate fi considerată completă. Desigur, este posibil să reveniți la acesta și să revizuiți unele elemente în timpul proiectării sistemului, la ajustarea sarcinilor, la specificarea 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țiuni publice a clasei sau unui set de operații publice (în acest caz, cazul de utilizare este implementat direct de clasa sau setul de clase corespunzătoare).

Să ne uităm la procesul de creare a unei noi înregistrări de elev folosind o diagramă de secvență.

Crearea unei noi înregistrări presupune drepturi de administrator, astfel încât administratorul va fi protagonistul acestei interacțiuni ( admin). Acest element a fost deja introdus în diagrama cazurilor de utilizare, așa că trageți-l în diagrama de secvență din browserul de vizualizare a cazurilor de utilizare.

Trebuie remarcat faptul că obiectele apar în diagramele de interacțiune, adică instanțe concrete de clase (numele unui obiect este întotdeauna subliniat).

Gestionam obiecte: formăintrare, administratorînregistrări, fișa studentului Petrov(ca exemplu concret de fișă 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- un element al interfeței cu utilizatorul, care este o formă tipică pentru introducerea datelor despre un student (nume, prenume, patronimic, adresă etc.). În cazul nostru, este o implementare concretă oarecum extinsă 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 clasa a cărei instanță este este indicată în mod explicit - 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ă înregistrareOstudent... Astfel de obiecte există de obicei temporar pentru a trimite informații 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 creat din nou dacă este necesară editarea informației.

Administratortranzactii- un obiect care asigură executarea unei operațiuni finalizate 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 a accesa bazele de date Paradox, Dbase etc. din aplicațiile Delphi), ADO (folosit pentru a accesa bazele de date MS Access din diverse aplicații).

Diagrama de succesiune pentru introducerea unei noi înregistrări despre un student în AWS al secretarului de departament este prezentată în Fig. 7.

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

În diagrama de secvență, definim transferul de mesaje între obiecte: creanouînregistrare(difuzat de la obiect la obiect până la capătul lanțului ca mesaj salvaînregistrare); deschisformă(la formularul de introducere); a introduceF.ȘI DESPRE.,adresa. ( introducerea datelor elevilor), apoi aceste date sunt difuzate prin mesaje salvaF.ȘI DESPRE.,adresa. Din administratortranzactii trimite mesaj în colectare informațieOstudent furnizarea de feedback la baza de date și, în final, un mesaj reflex administratortranzactii numit ca salvaînregistrarevDB, 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 cazurilor de utilizare.

4.3 Dezvoltarea unui profil de baze de date relaționale

În cazul în care un SGBD orientat pe obiect (OODBMS) este utilizat pentru implementarea sistemului, diagrama obiect construită în secțiunea anterioară este modelul final și un ghid 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 unui sistem informațional, este necesar să se elaboreze o altă diagramă, o diagramă de profil a unei baze de date relaționale.

Profilul UML pentru un proiect de bază de date este o extensie UML care păstrează intact metamodelul UML. Un profil pentru un proiect de bază de date adaugă stereotipuri și valori etichetate anexate acestor stereotipuri, dar nu schimbă metamodelul UML de bază. Pentru a vizualiza elementele de bază de date proiectate și regulile de proiectare pentru baze de date relaționale, pictogramele corespunzătoare au fost adăugate la profil (în continuare simple baze de date). Baza de date este descrisă folosind tabele, coloane și relații. Profilul conține 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 să folosiți 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 ( Cheie primară) - o posibilă cheie aleasă pentru a identifica rândurile de tabel.

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

Reprezentare ( View) este o masă virtuală care se comportă din punctul de vedere al utilizatorului exact ca o masă obișnuită, dar nu există de la sine.

Stocat procedură ( Procedura stocată) este o funcție procedurală independentă executată 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. Dezvoltarea unui fragment din sistemul informatic de resurse educativ-metodice.

lucrare de termen, adăugată 28.05.2009


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

prezentare adaugata la 14.10.2013


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

prezentare adaugata la 04/02/2013


Rolul structurii de management în sistemul informaţional. Exemple de sisteme informatice. Structura si clasificarea sistemelor informatice. Tehnologia de informație. Etapele dezvoltării tehnologiei informației. Tipuri de tehnologie a informației.

lucrare termen adăugat 17.06.2003


Conceptul de instrumente CASE ca instrumente software care sprijină crearea și întreținerea sistemelor informaționale (IS). Caracteristici ale IDEF-tehnologie de dezvoltare IS. Descrierea notației IDEF0. Dezvoltarea modelelor funcționale ale unui proces de afaceri.

prezentare adaugata la 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 educațional. 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 implementării 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 formelor de interfață grafică și baze de date.

teză, adăugată 23.06.2015


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

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.

„Modelare matematică pe calculator” Obiectivele studierii secțiunii. Stăpânirea modelării ca metodă de cunoaștere a realității înconjurătoare (natura de cercetare științifică a secțiunii) - se arată că modelarea în diverse domenii ale cunoașterii are caracteristici asemănătoare, adesea pentru procese diferite fiind posibil să se obțină modele foarte asemănătoare; - demonstrează 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 cunoaște lumea înconjurătoare, de a o controla în interesul omului. Dezvoltarea abilităților practice în modelarea computerizată. 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, sunt implementate practic toate etapele modelării, de la formularea problemei până la interpretarea rezultatelor obținute în decursul unui experiment pe calculator. Promovarea orientării profesionale a elevilor. Dezvăluirea aptitudinii studentului pentru activități de cercetare, dezvoltarea potențialului creativ, orientarea către alegerea unei profesii legate de cercetarea științifică. Depășirea disocierii subiectului, integrarea cunoștințelor. Cursul examinează modele din diverse domenii ale științei folosind matematica. Dezvoltarea și profesionalizarea abilităților informatice. Stăpânire software pentru scopuri generale și specializate, sisteme de programare.

Conceptul de model este 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 mijloacelor disponibile.
În teoria eficienței și informatică, un model al unui obiect (sistem, operație) este un sistem material sau ideal (imaginabil mental) creat și/sau utilizat în rezolvarea unei probleme specifice în scopul obținerii de noi cunoștințe despre obiectul original, adecvate pentru ea din punct de vedere al proprietăților studiate și mai simplă decât originalul în alte privințe.
Clasificarea principalelor metode de modelare (și modelele lor corespunzătoare) este prezentată în Fig. 3.1.1.
În studiul sistemelor informaționale economice (EIS) sunt utilizate toate metodele de modelare, totuși, această secțiune se va concentra pe metodele semiotice (semnale).
Amintiți-vă că semiotica (din grecescul semeion - semn, atribut) este știința proprietăților generale ale sistemelor de semne, adică sisteme de obiecte (semne) concrete sau abstracte, fiecăruia dintre care este asociat un anumit sens. 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 studiază sintaxa sistemelor de semne fără a ține cont de orice interpretări și probleme asociate cu percepția sistemelor de semne ca mijloace 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 examinează atitudinea persoanei care utilizează sistemul de semne față de sistemul de semne însuși, în special - percepția expresiilor semnificative ale sistemului de semne.
Dintre numeroasele modele semiotice, datorită celei mai mari distribuții, mai ales în contextul informatizării societății moderne și al introducerii metodelor formale în toate sferele activității umane, le vom evidenția pe cele matematice care reflectă 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ții, vom folosi cunoscuta metodologie a analizei 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 Fundamentele metodologice ale aplicării metodei simulării
2. Secțiunea III BAZE PENTRU MODELAREA UNUI SISTEM DE MARKETING DE SERVICII
3. CAPITOLUL 1. SISTEME DINAMICE CONTROLATE CA OBIECT DE SIMULARE CALCULATORULUI
4. Fundamentele modelării structurale a sistemului de marketing al serviciilor medicale
5. Secțiunea IV EXEMPLU DE UTILIZARE APLICATĂ A UNUI MODEL DE SISTEM DE MARKETING ÎN MODELAREA IMITĂȚII
6. Conceptul de modelare a sferei financiare a sistemelor de marketing