Manual pentru universități

Ed. a II-a, revizuită. si suplimentare

2014 G.

Tiraj 1000 de exemplare.

Format 60x90/16 (145x215 mm)

Versiune: broşat

ISBN 978-5-9912-0193-3

BBK 32.882

UDC 621.395

Vulture UMO
Recomandat de UMO pentru educația în domeniul telecomunicațiilor ca ajutor didactic pentru studenții instituțiilor de învățământ superior care studiază la specialitățile „Rețele și sisteme de comutare”, „Sisteme de telecomunicații multicanal”

adnotare

Sunt luați în considerare algoritmi pentru modelarea variabilelor și proceselor aleatoare discrete și continue. Sunt prezentate principiile și algoritmii modelării semnale informative, descrise de procese Markov cu timp discret și continuu Se iau în considerare principiile modelării sistemului. la coadă. Sunt descrise caracteristicile descrierii și utilizării proceselor fractale și multifractale pentru modelarea traficului de telecomunicații. Sunt analizate metode și exemple de modelare sisteme de informare folosind pachete specializate programe de aplicație Matlab, Opnet, Simulator de rețea.

Pentru studenții care studiază la specialitățile „Rețele și sisteme de comutare”, „Sisteme de telecomunicații multicanal”, „Sisteme și tehnologii informaționale”.

Introducere

1 Principii generale modelarea sistemelor
1.1. Concepte generale de modelare și simulare
1.2. Clasificarea modelului
1.3. Structura modelului
1.4. Baza metodologică pentru formalizarea funcționării unui sistem complex
1.5. Modelarea componentelor
1.6. Etapele formării unui model matematic
1.7. Modelare prin simulare
Întrebări de control

2 Principii generale pentru construirea sistemelor și rețelelor de comunicații
2.1. Conceptul de construire a sistemelor și rețelelor de comunicații
2.2. Modele de rețea cu mai multe niveluri
2.2.1. Model pe trei nivele
2.2.2. Arhitectura protocolului TCP/IP
2.2.3. Model de referință OSI
2.3. Structura rețelelor de comunicații
2.3.1. Rețele globale
2.3.2. Rețele locale
2.3.3. Topologii de rețele de calculatoare
2.3.4. Rețele locale Ethernet
2.4. Rețele Frame Relay
2.5. telefonie IP
Întrebări de control

3 Simularea numerelor aleatorii
3.1. Informații generale despre numere aleatoare
3.2. Metode software pentru generarea de numere aleatoare distribuite uniform
3.3. Formarea variabilelor aleatoare cu o lege de distribuție dată
3.3.1. Metoda funcției inverse
3.3.2. Metode aproximative pentru conversia numerelor aleatoare
3.3.3. Metoda de screening (metoda de generare Neumann)
3.4. Metode bazate pe teorema limitei centrale
3.5. Algoritmi pentru modelarea variabilelor aleatoare utilizate în mod obișnuit
3.6. Algoritmi pentru modelarea variabilelor aleatoare corelate
3.7. Generarea de implementări ale vectorilor și funcțiilor aleatorii
3.7.1. Modelarea unui punct aleator n-dimensional cu coordonate independente
3.7.2. Formarea unui vector aleatoriu (în cadrul teoriei corelației)
3.7.3. Formarea implementărilor funcții aleatorii

4 Modelarea distribuțiilor discrete
4.1. distribuția Bernoulli
4.2. Distribuție binomială
4.3. Distribuția Poisson
4.4. Simularea de teste în schema evenimentelor aleatorii
4.4.1. Simularea evenimentelor aleatorii
4.4.2. Simularea evenimentelor opuse
4.4.3. Simularea unei variabile aleatoare discrete
4.4.4. Modelare grup complet evenimente
4.5. Fluxuri de evenimente
4.6. Prelucrarea rezultatelor simulării
4.6.1. Acuratețea și numărul de implementări
4.6.2. Prelucrarea datelor statistice primare
Întrebări de control

5 Algoritmi pentru modelarea semnalelor stocastice și a interferențelor în sistemele de comunicații
5.1. Algoritm de modelare non-staționară procese aleatorii
5.2. Algoritmi pentru modelarea proceselor aleatoare staționare
5.3. Metode de modelare a semnalelor și a zgomotului sub formă de ecuații diferențiale stocastice
5.4. Exemple de modele de procese aleatorii în sisteme de comunicații
5.4.1. Modele ale proceselor informaţionale
5.4.2. Modele de interferență
5.4.3. Caracteristicile principalelor tipuri de interferență
Întrebări de control

6 Procese aleatoare Markov și modelarea lor
6.1. Concepte de bază ale procesului aleator Markov
6.2. Proprietățile de bază ale lanțurilor Markov discrete
6.3. Lanțuri Markov continue
6.3.1. Noțiuni de bază
6.3.2. procese semi-Markov
6.3.3. Procese de moarte și reproducere
6.4. Modele ale proceselor aleatoare Markov cu valori continue bazate pe ecuații diferențiale stocastice
6.5. Modelarea proceselor aleatoare Markov
6.5.1. Modelarea proceselor discrete
6.5.2. Modelarea proceselor scalare cu valori continue
6.5.3. Modelarea proceselor vectoriale cu valori continue
6.5.4. Simularea unui proces gaussian cu densitate spectrală fracțională-rațională
6.5.5. Modelarea secvențelor conectate multiplicate
6.5.6. Modelarea proceselor Markov folosind filtre de modelare
6.5.7. Algoritm pentru modelarea statistică a lanțurilor Markov
Întrebări de control

7 Exemple de modele Markov
7.1. Modele Markov de dialog vocal al abonaților
7.1.1. Stările semnalului vocal
7.1.2. Modele de dialog
7.2. Modele Markov de monolog de vorbire
7.3. Procesul Poisson controlat de Markovian în modelele de vorbire
7.4. Modele Markov de secvențe digitale la ieșirea codecului G.728
7.5. Compactarea surselor statistice a pachetelor de voce ținând cont de modelul Markov al dialogului telefonic
7.6. Model de canal fără fir Markov cu mecanism ARQ/FEC
7.7. Eroare la introducerea în sac
7.8. Calculul caracteristicilor fluxului de erori folosind parametrii modelului
7.8.1. Estimarea parametrilor fluxului de eroare
7.8.2. Evaluarea adecvării modelului fluxului de erori
7.9. Modele de estimare Markov QoS servicii multimedia timp real pe internet
7.9.1. Conceptul de servicii multimedia în timp real
7.9.2. Analiza si modelarea intarzierilor si pierderilor
7.10. Modele de flux de trafic multimedia
Întrebări de control

8 Sisteme de așteptare și modelarea acestora
8.1. Caracteristici generale ale sistemelor de aşteptare
8.2. Structura sistemului de așteptare
8.3. Sisteme de așteptare cu așteptare
8.3.1. Sistem de service M/M/1
8.3.2. Sistem de service M/G/1
8.3.3. Rețele cu un numar mare noduri conectate prin canale de comunicare
8.3.4. Serviciu prioritar
8.3.5. Sistem de service M/M/N/m
8.4. Sisteme de așteptare cu defecțiuni
8.5. Principii generale de modelare a sistemelor de aşteptare
8.5.1. Metoda de testare statistică
8.5.2. Modele bloc ale proceselor de funcționare a sistemelor
8.5.3. Caracteristici de modelare folosind Q-circuite
Întrebări de control

9 Modelarea sistemelor informatice folosind mijloace tehnice standard
9.1. Limbaje de modelare si programare a sistemelor
9.2. Bazele limbajului GPSS
9.2.1. Obiecte dinamice GPSS. Blocuri orientate către tranzacții (instrucțiuni)
9.2.2. Blocuri orientate pe hardware (operatori)
9.2.3. Serviciu omnicanal
9.2.4. Blocuri statistice GPSS
9.2.5. Blocuri de operare GPSS
9.2.6. Alte blocuri GPSS
9.3. Modelarea prin simulare a rețelei ETHERNET în mediul GPSS
Întrebări de control

10 Modelarea sistemelor de transmitere a informaţiei
10.1. Sistem tipic de transmisie a datelor
10.2. Imunitatea la zgomot a transmisiei de semnal discret. Recepție optimă
10.3. Estimarea probabilității de recepție eronată a semnalelor discrete cu parametri complet cunoscuți
10.4. Imunitatea la zgomot a semnalelor discrete cu parametri aleatori
10.5. Imunitatea la zgomot a semnalelor discrete în timpul recepției incoerente
10.6. Imunitatea la zgomot a semnalelor discrete cu parametri semnificativi aleatori
10.7. Algoritmi pentru generarea de semnale discrete
10.8. Algoritm pentru generarea de interferențe
10.9. Algoritm de demodulare a semnalului discret
10.10. Structura complexului de simulare și subrutinele acestuia
10.11. Mediu software Pachetul de modelare vizuală Mathworks Matlab și Simulink
10.11.1. Descriere tehnică și interfață
10.11.2. Pachet de modelare vizuală Simulink
10.11.3. Crearea și mascarea subsistemelor
10.11.4. Pachetul de extensie al casetei de instrumente de comunicații
10.12. Modelarea blocurilor sistemului de transmisie a datelor WiMAX
10.12.1. Simularea transmițătorului
10.12.2. Modelarea canalului de transmisie
10.12.3. Simulare receptor
10.12.4. Implementarea modelului în sistemul Mathlab
10.13. Rezultatele simulării sistemului WiMAX
Întrebări de control

11 Procese autosimilare și aplicarea lor în telecomunicații
11.1. Fundamentele teoriei proceselor fractale
11.2. Procese multifractale
11.3. Estimarea exponentului Hurst
11.4. Analiza multifractala folosind software
11.4.1. Descrierea software-ului
11.4.2. Exemple de evaluare a gradului de autosimilare
11.5. Algoritmi si software pentru analiza multifractala
11.6. Influența autoasemănării traficului asupra caracteristicilor sistemului de servicii
11.7. Metode de modelare a proceselor autosimilare în teletrafic
11.8. Studiul structurii de trafic Ethernet auto-similar
11.9. Controlul supraîncărcării traficului auto-similar
11.10. Mișcare browniană fractală
11.10.1. Algoritm RMD pentru generarea FBD
11.10.2. Algoritm SRA pentru generarea FBD
11.12. Zgomot fractal gaussian
11.12.1. Algoritm FFT pentru sinteza FGN
11.12.2. Evaluarea rezultatelor simulării
Întrebări de control

12 Modelarea unui nod de rețea de telecomunicații
12.1. Elementele de bază ale protocolului Frame Relay
12.2. Proiectarea unui site de rețea Frame Relay
12.3. Rezultatele simulării unui router FR cu codecuri G.728 la intrare
12.4. Impactul auto-asemănării traficului asupra QoS
Întrebări de control

13 Sisteme specializate modelarea prin simulare a rețelelor de calculatoare
13.1. Caracteristici generale ale pachetelor de aplicații specializate pentru modelarea rețelelor
13.2. Principii generale de modelare în mediul OPNET Modeler
13.3. Exemple de aplicație OPNET
13.3.1. Model de evaluare a calității serviciilor
13.3.2. Implementarea modelului de rețea locală
Întrebări de control

14 Modelarea prin simulare folosind simulatorul de rețea Simulatorul de rețea 2
14.1. Istoricul creării și arhitecturii pachetului NS2
14.2. Crearea unui obiect simulator
14.3. Crearea unei topologii de rețea
14.4. Setarea parametrilor generatorului
14.4.1. Pornit/Oprit exponențial
14.4.2. Pareto Pornit/Oprit
14.5. Doi algoritmi principali de așteptare
14.6. Adaptive Routing în NS2
14.6.1. Interfață de programare a aplicației la nivel de utilizator
14.6.2. Arhitectura interioara
14.6.3. Extinderi la alte clase
14.6.4. Defecte
14.6.5. Lista comenzilor utilizate pentru a simula scenarii dinamice în NS2
14.6.6. Exemplu de rutare dinamică în NS2
14.7. Rularea unui program de script în NS2
14.8. Procedura de prelucrare a rezultatelor simulării
14.9. Exemplu de simulare a rețelei fără fir
14.10. Un exemplu de modelare de simulare a calității video streaming folosind pachetul NS 2
14.10.1. Structura complexului software și hardware pentru evaluarea calității streaming video
14.10.2. Module funcționale PAC
14.10.3. Evaluarea calității video

Obiectivele și funcțiile sistemului informațional.

Un IS poate rezolva două grupuri de probleme. Primul grup este asociat cu suportul pur informațional al activității principale (selectarea mesajelor necesare, prelucrarea, stocarea, căutarea și livrarea acestora către subiectul activității principale cu o completitudine, acuratețe și eficiență prestabilită în cea mai acceptabilă formă). A doua grupă de sarcini este asociată cu prelucrarea informațiilor/datelor primite în conformitate cu anumiți algoritmi pentru a pregăti soluții la problemele cu care se confruntă subiectul activității principale. Pentru a rezolva astfel de probleme, IS trebuie să aibă informatie necesara O domeniul subiectului. Pentru a rezolva astfel de probleme, IS-ul trebuie să aibă o anumită inteligență artificială sau naturală. Sistem informatic - un sistem pentru susținerea și automatizarea muncii intelectuale - căutare, administrare, examinări și evaluări sau judecăți ale experților, luare a deciziilor, management, recunoaștere, acumulare de cunoștințe, instruire. Sarcinile primului grup sunt sarcinile de informatizare a societății „în lățime”.

Sarcinile grupei a doua sunt sarcinile de informatizare

societatea „în profunzime”.

Pentru a rezolva sarcinile atribuite, IS trebuie să îndeplinească următoarele funcții:

 selectarea mesajelor din mediul intern și extern necesare implementării activităților de bază;

 introducerea de informaţii în SI;

 stocarea informaţiei în memoria IS, actualizarea acesteia şi menţinerea integrităţii;

 prelucrarea, căutarea și emiterea de informații în conformitate cu cerințele specificate de ODS. Procesarea poate include, de asemenea, pregătirea opțiunilor pentru rezolvarea problemelor aplicațiilor utilizatorului.

Sistemul informațional (SI) este un set interconectat de instrumente, metode și personal utilizat pentru stocarea, procesarea și emiterea de informații în interesul atingerii unui obiectiv stabilit. Înțelegerea modernă a unui sistem informațional presupune utilizarea unui computer personal ca principal mijloc tehnic de prelucrare a informațiilor. IS este un mediu ale cărui elemente constitutive sunt calculatoarele, rețelele de calculatoare, produse software, baze de date, oameni, diverse tipuri de comunicații tehnice și software etc. Deși însăși ideea de sisteme informaționale și unele principii ale organizării lor au apărut cu mult înainte de apariția computerelor, informatizarea a crescut eficiența sistemelor informaționale de zeci și sute de ori și a extins domeniul de aplicare a acestora.

Structura funcțională a sistemului informațional.

Este recomandabil să distingem trei subsisteme funcționale independente în IS.

Subsistemul de selecție a informațiilor. Un sistem informatic poate procesa/prelucra doar informațiile care sunt introduse în el. Calitatea unui sistem informatic este determinată nu numai de capacitatea sa de a găsi și procesa informațiile necesare în propria sa matrice și de a le prezenta utilizatorului, ci și de capacitatea sa de a selecta informații relevante din mediul extern. O astfel de selecție este realizată de un subsistem de selecție a informațiilor, care acumulează date privind nevoile de informații ale utilizatorilor SI (interni și externi), analizează și organizează aceste date, formând un profil de informații IS.

Subsistemul de introducere, prelucrare/prelucrare și stocare a informațiilor transformă informațiile de intrare și solicitările, organizează stocarea și prelucrarea acestora pentru a satisface nevoile de informații ale abonaților IS.

Implementarea funcțiilor acestui subsistem presupune prezența unui aparat de descriere a informațiilor (sisteme de codare, limbaj de descriere a datelor (DDL), etc.), organizarea și întreținerea informațiilor (organizarea logică și fizică, proceduri de menținere și protejare a informațiilor etc.). .), un aparat de procesare și prelucrare a informațiilor (algoritmi, modele etc.).

Subsistemul de pregătire și emitere a informațiilor satisface direct nevoile de informare ale utilizatorilor SI (interni și externi). Pentru a îndeplini această sarcină, subsistemul studiază și analizează nevoile de informații, determină formele și metodele de satisfacere a acestora, compoziția și structura optimă a produselor informaționale de ieșire și organizează procesul de suport și suport informațional.

Realizarea acestor funcții necesită prezența unui aparat de descriere și analiză a nevoilor de informații și exprimarea acestora în limbajul sistemelor informaționale (inclusiv LDL, IPL, limbaj de indexare etc.), precum și a unui aparat de furnizare directă a informațiilor (proceduri de căutare). și emiterea de informații, limbaje de manipulare a datelor etc.). Multe funcții ale subsistemelor IC sunt duplicate sau se suprapun, ceea ce face obiectul optimizării la proiectarea IC-urilor. În acest sens, automatizarea IS este însoțită de o redistribuire a elementelor IS.

Automatizarea implică o reprezentare formalizată (structurare) atât a funcțiilor SI, cât și a informațiilor în sine procesate în SI, ceea ce permite introducerea, procesarea/procesarea, stocarea și preluarea informațiilor folosind un computer. Orice formalizare se caracterizează printr-unul sau altul nivel de adecvare a imaginii create a realității (modelului) realității însăși. Mai mult, adecvarea unui model de realitate este determinată atât de proprietățile realității în sine, cât și de capacitățile aparatului folosit pentru reprezentarea sa formalizată.

Din acest punct de vedere, „nivelul de automatizare” al unui sistem informațional este strâns legat de „gradul de structurare” al informațiilor. Există trei niveluri de structurabilitate a informațiilor: Informație (date) structurată rigid - informație, a cărei reprezentare formalizată prin mijloace moderne de structurare a acesteia (în special, limbaje de descriere a datelor) nu duce la o pierdere a adecvării modelului informațional al cel original

informație. Informația slab structurată este informația, a cărei reprezentare oficială duce la pierderi semnificative în adecvarea modelului informațional al informațiilor originale în sine.

Informațiile nestructurate sunt informații pentru care în prezent nu există mijloace de oficializare cu un nivel de adecvare acceptabil în practică. Mijloacele de prezentare a unor astfel de informații trebuie să aibă abilități semantico-expresive ridicate. Dezvoltarea unor astfel de instrumente este în prezent timpul curge prin crearea de limbaje de descriere a cunoștințelor și FL cu putere semantică mare.

Metodologii de construire a sistemelor informatice.

Industria pentru dezvoltarea sistemelor automate de management al informației a apărut în anii 1950 și 1960 și până la sfârșitul secolului dobândise forme complet dezvoltate.

În prima etapă, principala abordare a proiectării SI a fost metoda „de jos în sus”, când sistemul a fost creat ca un set de aplicații care erau cele mai importante în momentul de față pentru a susține activitățile întreprinderii. Această abordare continuă într-o oarecare măsură și astăzi. În cadrul „automatizării patchwork”, suportul pentru funcțiile individuale este furnizat destul de bine, dar aproape că nu există o strategie pentru dezvoltarea unui sistem de automatizare complex

Următoarea etapă este asociată cu conștientizarea faptului că este nevoie de standarde destul de bune software ah automatizarea activităților diferitelor instituții și întreprinderi. Din întreaga gamă de probleme, dezvoltatorii au identificat cele mai vizibile: automatizarea contabilității analitice și procese tehnologice. Sistemele au început să fie proiectate „de sus în jos”, adică. sub presupunerea că un program trebuie să satisfacă nevoile multor utilizatori.

Însăși ideea de a folosi un program universal impune restricții semnificative asupra capacității dezvoltatorilor de a crea o structură a bazei de date, formulare de ecran și selecta algoritmi de calcul. Cadrul rigid stabilit „de sus” nu face posibilă adaptarea flexibilă a sistemului la specificul activităților unei anumite întreprinderi. Astfel, costurile materiale și de timp pentru implementarea sistemului și ajustarea lui la cerințele clienților de obicei depășesc semnificativ indicatorii planificați.

Conform statisticilor realizate de Standish Group (SGL), din cele 8.380 de proiecte chestionate de SSL în 1994, peste 30% dintre proiecte au eșuat, cu un cost total de peste 80 de miliarde de dolari. În același timp, doar 16% din numărul total de proiecte au fost finalizate la timp, iar depășirile de costuri s-au ridicat la 189% din bugetul planificat.

În același timp, clienții IS au început să propună din ce în ce mai multe cerințe menite să asigure posibilitatea utilizării integrate a datelor corporative în gestionarea și planificarea activităților lor. Astfel, a apărut o nevoie urgentă de a formula o nouă metodologie de construire a sistemelor informaționale.

Conform metodologiei moderne, procesul de creare a unui SI este un proces de construire și transformare secvențială a unui număr de modele coordonate în toate etapele ciclului de viață al SI (LC). În fiecare etapă a ciclului de viață se creează modele specifice acestuia - organizații, cerințe pt

ESTE. proiect IP. cerințe de aplicare etc. De obicei, se disting următoarele etape ale creării unui IS: formarea cerințelor de sistem, proiectare, implementare, testare, punere în funcțiune, operare și întreținere.

Etapa inițială a procesului de creare a SI este modelarea proceselor de afaceri care au loc în organizație și realizarea obiectivelor acesteia. Modelul de organizare, descris în termeni de procese de afaceri și funcții de afaceri, ne permite să formulăm cerințele de bază pentru SI.

Proiectarea IS se bazează pe modelarea domeniului. Pentru a obține un proiect SI adecvat domeniului subiectului sub forma unui sistem de programe de funcționare corect, este necesar să existe o reprezentare holistică, sistemică a modelului, care să reflecte toate aspectele funcționării viitorului sistem informațional. În acest caz, un model de domeniu este înțeles ca un anumit sistem care imită structura sau funcționarea domeniului subiectului studiat și îndeplinește cerința de bază - de a fi adecvat acestui domeniu.

Modelarea preliminară a domeniului subiectului vă permite să reduceți timpul și timpul de lucru de proiectare și să obțineți un proiect mai eficient și de înaltă calitate. Fără modelarea domeniului subiectului, există o probabilitate mare de a face un număr mare de erori în rezolvarea problemelor strategice, ducând la pierderi economice și costuri mari pentru reproiectarea ulterioară a sistemului. Ca rezultat, toate tehnologiile moderne de proiectare IS se bazează pe utilizarea metodologiei de modelare a domeniului.

Următoarele cerințe se aplică modelelor de domenii:

Formalizare care oferă o descriere clară a structurii disciplinei;

Claritate pentru clienți și dezvoltatori pe baza utilizării mijloacelor grafice de afișare a modelului;

Realizabilitate, implicând disponibilitatea mijloacelor de implementare fizică a modelului de domeniu și IS;

Oferirea unei evaluări a eficacității implementării modelului de domeniu pe baza anumitor metode și indicatori calculați.

Modelare funcțională IDEF0: definiții și prevederi de bază.

Programul de informatizare integrată a producției ICAM (ICAM - Integrated Computer Aided Manufacturing) are ca scop creșterea eficienței întreprinderilor industriale prin introducerea pe scară largă a tehnologiilor informatice (informatice). În SUA, această circumstanță a fost realizată la sfârșitul anilor 70, când Forțele Aeriene ale SUA au propus și implementat

Metodologia IDEF (Definiția ICAM) vă permite să studiați structura, parametrii și caracteristicile sistemelor de producție, tehnic și organizatoric-economic (în continuare, unde aceasta nu provoacă neînțelegeri - sisteme). Metodologia generală IDEF constă din trei metodologii specifice de modelare bazate pe reprezentarea grafică a sistemelor:

IDEF0 este folosit pentru a crea un model funcțional care descrie structura și funcțiile unui sistem, precum și fluxurile de informații și obiecte materiale care conectează aceste funcții.

IDEF1 este utilizat pentru a construi un model de informații care afișează structura și conținutul fluxurilor de informații necesare pentru a susține funcțiile sistemului;

IDEF2 vă permite să construiți un model dinamic al comportamentului variabil în timp al funcțiilor, informațiilor și resurselor sistemului.

Până în prezent, metodologiile IDEF0 și IDEF1 (IDEF1X), care au primit statutul de standarde federale în Statele Unite, sunt cele mai răspândite și utilizate. Metodologia IDEF0, ale cărei caracteristici și aplicare sunt descrise în acest document de orientare (GD), se bazează pe o abordare dezvoltată de Douglas T. Ross la începutul anilor '70 și numită SADT (Structured Analysis & Design Technique). Baza abordării și, în consecință, metodologia IDEF0 este limbaj grafic descrieri (modelare) sisteme cu următoarele proprietăți.

Pentru a afișa corect interacțiunile componentelor IS, este important să modelați împreună astfel de componente, mai ales din punct de vedere semnificativ al obiectelor și funcțiilor.

Metodologia structurale analiza de sistem ajută semnificativ la rezolvarea unor astfel de probleme.

Analiza structurală este de obicei numită o metodă de studiere a unui sistem, care începe cu acesta privire de ansamblu, iar apoi detaliază prin achiziție structura ierarhica cu tot mai multe niveluri. Astfel de metode se caracterizează prin: împărțirea în niveluri de abstractizare cu un număr limitat de elemente (de la 3 la 7); context limitat, incluzând doar detaliile esențiale ale fiecărui nivel; utilizarea unor reguli stricte de înregistrare formală; abordare consecventă a rezultatului.

Să definim conceptele cheie ale analizei structurale a activităților unei întreprinderi (organizație).

O operație este o acțiune elementară (indivizibilă) efectuată la un loc de muncă.

O funcție este un set de operații grupate în funcție de o anumită caracteristică.

Un proces de afaceri este un ansamblu conex de funcții, în timpul execuției cărora se consumă anumite resurse și se creează un produs (obiect, serviciu, cercetare științifică).

descoperire, idee) de valoare pentru consumator.

Un subproces este un proces de afaceri care este un element structural al unui proces de afaceri și are valoare pentru consumator.

Un model de afaceri este o descriere grafică structurată a unei rețele de procese și operațiuni asociate cu date, documente, unități organizaționale și alte obiecte care reflectă activitățile existente sau propuse ale unei întreprinderi. Există diverse metodologii pentru modelarea structurală a unui domeniu, dintre care ar trebui evidențiate metodologiile orientate pe funcție și orientate pe obiect.

Descrierea unui sistem care utilizează IDEF0 se numește model funcțional. Modelul funcțional este destinat să descrie procesele de afaceri existente, care utilizează atât limbaje naturale, cât și limbaje grafice. Pentru a transmite informații despre un anumit sistem, sursa limbajului grafic este însăși metodologia IDEF0.

Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame - descrieri unice ale fragmentelor sistemului. În primul rând, se realizează o descriere a sistemului în ansamblu și a interacțiunii sale cu lumea exterioară (diagrama de context), după care se efectuează o descompunere funcțională - sistemul este împărțit în subsisteme și fiecare subsistem este descris separat (diagrame de descompunere) . Apoi fiecare subsistem este împărțit în altele mai mici și așa mai departe până când se atinge nivelul dorit de detaliu.

Mediul instrumentului BPwin.

Modelarea proceselor de afaceri este de obicei realizată folosind instrumente de caz. Astfel de instrumente includ BPwin (tehnologia PLATINUM), Silverrun (tehnologia Silverrun), Oracle Designer (Oracle), Rational Rose (Rational Software), etc. Funcționalitatea instrumentelor pentru modelarea structurală a proceselor de afaceri va fi discutată folosind instrumentul de caz BPwin exemplu.

BPwin acceptă trei metodologii de modelare: modelare funcțională (IDEF0); Descriere procesele de afaceri(IDEF3); Diagrame de flux de date (DFD). BPwin are o interfață de utilizator destul de simplă și intuitivă. Când porniți BPwin, în mod implicit apar bara principală de instrumente, paleta de instrumente (al cărei aspect depinde de notația selectată) și, în partea stângă, Model Explorer.

La crearea unui model nou, apare un dialog în care trebuie să indicați dacă modelul va fi creat din nou sau va fi deschis dintr-un fișier sau din depozitul ModelMart, apoi introduceți numele modelului și selectați metodologia în care modelul este creat. va fi construit.

După cum sa menționat mai sus, BPwin acceptă trei metodologii - IDEF0, IDEF3 și DFD, fiecare dintre acestea rezolvând propriile probleme specifice. În BPwin este posibil să se construiască modele mixte, adică modelul poate conține simultan atât IDEF0, cât și IDEF3 și diagrame DFD. Compoziția paletei de instrumente se schimbă automat când treceți de la o notație la alta.

Un model în BPwin este considerat ca un set de lucrări, fiecare dintre ele funcționând cu un anumit set de date. Lucrarea este descrisă sub formă de dreptunghiuri, datele - sub formă de săgeți. Dacă faceți clic pe orice obiect model cu butonul stâng al mouse-ului, apare un meniu contextual, fiecare articol corespunzător editorului unei proprietăți a obiectului.

În etapele inițiale ale creării unui SI, este necesar să înțelegem cum funcționează organizația care urmează să fie automatizată. Managerul cunoaște bine munca în ansamblu, dar nu este capabil să aprofundeze detaliile muncii fiecărui angajat obișnuit. Un angajat obișnuit știe bine ce se întâmplă la locul său de muncă, dar poate să nu știe cum lucrează colegii săi. Prin urmare, pentru a descrie activitatea unei întreprinderi, este necesar să se construiască un model care să fie adecvat domeniului subiectului și să conțină cunoștințele tuturor participanților la procesele de afaceri ale organizației.

Cel mai convenabil limbaj pentru modelarea proceselor de afaceri este IDEF0, unde sistemul este reprezentat ca un set de joburi sau funcții care interacționează. Această orientare pur funcțională este fundamentală - funcțiile sistemului sunt analizate independent de obiectele cu care operează. Acest lucru vă permite să modelați mai clar logica și interacțiunea proceselor organizației.

Procesul de modelare a unui sistem în IDEF0 începe cu crearea unei diagrame de context - o diagramă a celui mai abstract nivel de descriere a sistemului în ansamblu, care conține o definiție a subiectului modelării, scopul și punctul de vedere al model.

Activitățile se referă la procese, funcții sau sarcini numite care au loc într-o perioadă de timp și au rezultate recunoscute.

Lucrările sunt descrise ca dreptunghiuri. Toate lucrările trebuie denumite și definite. Numele lucrării trebuie exprimat ca un substantiv verbal care denotă o acțiune (de exemplu, „Activități ale companiei”, „Recepția unei comenzi”, etc.). Lucrarea „Activități ale companiei” ar putea avea, de exemplu, următoarea definiție: „Acesta este un model educațional care descrie activitățile unei companii”. La crearea unui model nou (meniul Fișier/Nou), este creată automat o diagramă de context cu o singură lucrare care descrie sistemul în ansamblu.

Săgețile descriu interacțiunea muncii și reprezintă unele informații exprimate prin substantive (de exemplu, „Apelurile clienților”, „Reguli și proceduri”, „Sistem de contabilitate”).

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

Ghid de implementare munca de curs

I.V. Chervenchuk

• Introducere
• 2 . Limbajul de modelare unificatUML
• 4. Dezvoltarea modelului sistem software mijloaceUML
• 5. Probleme legate de implementarea sistemului informatic
• 6. Subiecte de curs
• Bibliografie

Introducere

Lucrarea discută problemele dezvoltării sistemelor informaționale folosind un limbaj unificat Modelare UML, care stă la baza cursurilor la disciplina „Sisteme și procese informaționale. Modelare și management”. Sunt studiate etapele principale ale unui proces rațional unificat de dezvoltare a sistemelor informaționale, sunt oferite exemple și ilustrații. Sunt oferite opțiuni pentru teme pentru cursuri.

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

1. Cerințe generale pentru a finaliza cursurile

Lucrările de curs 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 folosind limbajul unificat de modelare UML cu implementarea sa ulterioară. Ca sarcină tipică, se propune dezvoltarea unui sistem de informații și referințe bazat pe baze de date, dar la cererea elevului, de comun acord cu profesorul, se poate propune ca sarcină dezvoltarea unei aplicații WEB, a unui sistem de testare sau a unui dispozitiv hardware. În același timp, principalul cerință necesară este utilizarea unei abordări orientate pe obiecte și construirea unui model UML.

Un titlu tipic de lucru de curs arată ca „Dezvoltarea unui sistem de informații și referințe _ Nume _ "

Introducere

1. Prezentare generală a conținutului domeniului subiectului. Cerințe de bază ale sistemului

2. Model detaliat al sistemului informatic

2.1 Privire din punctul de vedere al precedentelor

2.2 Vedere din punct de vedere al designului

2.3 Vedere din punct de vedere al implementării

2.4 Vedere proces (dacă este necesar)

2.5 Vedere de implementare (dacă este necesar)

3. Implementarea sistemului informatic

Concluzie

Anexă Listarea unui program sau a unui modul principal

În introducere puteți indica utilizarea tehnologia Informatiei V domenii diverse activități, inclusiv servicii, beneficii contabilitate electronică, probleme de construire a sistemelor informatice specializate etc.

Date instrucțiuni conține recomandări detaliate la secțiunile principale ale notei explicative și exemplele 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 incluse în partea principală a notei explicative, oferindu-le comentarii detaliate și textele programului să fie incluse în anexă.

Viziunea procesului trebuie luată atunci când se dezvoltă sisteme multitasking. Vederea de implementare presupune prezența unui sistem de informații distribuite. Aceste tipuri și secțiunile corespunzătoare ale notei explicative nu sunt obligatorii pentru finalizarea acestei lucrări de curs; utilizarea lor este destinată a fi utilizată atunci când se parcurg numai anumite opțiuni ale lucrării de curs.

Când acoperiți problemele de implementare a sistemului într-o notă, este recomandabil să justificați alegerea mediului de programare și să furnizați un manual de utilizare. Un element obligatoriu este includerea în text a formularelor de ecran (screen shorts) ale programului implementat; se încurajează utilizarea instrumentelor de inginerie inversă.

În concluzie, principalele rezultate ale lucrării sunt rezumate pe scurt: s-a dezvoltat un model UML al sistemului, sistemul este implementat utilizând un astfel de mediu de programare pe care sistemul dezvoltat îl permite, avantajele abordărilor utilizate (bazate pe modelare) la proiectarea sistemului.

modelarea limbajului sistemului informatic

Lucrarea de curs trebuie să conțină 20-30 de pagini de text tipărit cu ilustrații. Trebuie furnizate diagrame ale precedentelor, claselor și interacțiunilor.

2. Limbajul de modelare unificat UML

Dezvoltarea rațională a unui sistem informațional necesită 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 și, în final, să se determine metodele de implementare. Un studiu amănunțit al arhitecturii sistemului informațional dezvoltat î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) fac posibilă realizarea expresivă și destul de ușoară a dezvoltării conceptuale preliminare a unui sistem informațional și, în același timp, însoțesc metodic întregul proces de dezvoltare, inclusiv toate celelalte. ciclu de viață sistemul informatic fiind dezvoltat ca produs software.

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

UML, ca orice altă limbă, constă dintr-un vocabular și reguli care vă permit să combinați cuvintele pe care le conține pentru a crea constructe semnificative. Într-un limbaj 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 este necesar să se dezvolte un număr mare de modele interconectate. Când este aplicat sistemelor software, aceasta înseamnă că este nevoie de un limbaj care poate fi utilizat pentru a descrie vederile arhitecturii unui sistem de-a lungul ciclului său de dezvoltare din mai multe perspective.

UML este un limbaj de vizualizare, iar UML nu este doar un set de simboluri grafice. În spatele fiecăruia dintre ele se află 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 program de instrumente.

UML este un limbaj de specificare. În acest context, specificarea înseamnă construcția unor elemente precise, lipsite de ambiguitate și modele complete. UML vă permite să specificați toate deciziile 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 pe 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; aceleași care sunt mai bine descrise în forma 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. De asemenea, puteți rezolva problema inversă: reconstruiți modelul folosind 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 programele de instrumente asigură consistența între ambele reprezentări.

Pe lângă maparea directă în 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 componente 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ă dezvoltatorilor și managementului o 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 fazele de planificare a proiectului și de control al versiunilor.

Să luăm în considerare dezvoltarea unui model de sistem informațional folosind limbajul UML folosind exemplul dezvoltării unei stații de lucru automatizate pentru secretarul de departament (denumit în continuare stația de lucru a secretarului de departament).

3. Descrierea domeniului subiectului

Conceptul de domeniu al bazei de date este unul dintre Noțiuni de bază informatică și nu are o definiție exactă. 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 considerare a conceptului de domeniu al bazei de date limitează și face vizibil spațiul de regăsire a informațiilor dintr-un IS și permite executarea interogărilor într-un timp finit.

Prin descrierea domeniului subiectului vom înțelege o descriere a mediului în care se află sistemul în curs de dezvoltare, tipurile de utilizatori ai sistemului și vom indica, de asemenea, principalele sarcini a căror soluție este atribuită sistemului.

ÎN descriere preliminară domeniu, sunt introduși termenii de bază (vocabul sistem), se determină tipurile de utilizatori și drepturile acestora și se formulează sarcinile pe care sistemul în curs de dezvoltare trebuie să le rezolve. În acest caz, descrierea ar trebui să folosească mijloacele de limbaj obișnuit și grafica standard de afaceri (desene, diagrame, tabele).

La elaborarea unui dicționar de sistem, este necesar să se determine numele entităților („student”, „profesor”, „disciplină”). În acest caz, înțelegem termenul de entitate ca o componentă a modelului de domeniu, adică ca un obiect deja identificat la nivel conceptual. Obiectele identificate în domeniul subiectului sunt transformate de către analist în entități.

O entitate este rezultatul unei abstractizări a 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 numai funcția de index a 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 atribute).

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 dintr-un domeniu sunt descrise prin declarații despre domeniu. Pe î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 relația de incluziune. Astfel, toate informațiile despre obiectele și entitățile domeniului sunt descrise folosind declarații în limbaj natural.

Puteți specifica conexiuni structurale, pentru a evidenția situații statice și dinamice (introducând astfel un parametru de timp în model), totuși, pentru o elaborare detaliată a modelului, este mai convenabil să se utilizeze instrumente dezvoltate pentru descrierea domeniului subiectului, de exemplu, instrumente de limbaj UML.

Deci, sarcina este de a dezvolta un sistem „Stația de lucru a secretarului departamentului” care să permită înregistrarea automată a datelor despre angajații și studenții departamentului IVT OmSTU, oferind opțiuni flexibile la rezolvarea sarcinilor specifice planificate și neplanificate de procesare a acreditărilor.

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

profesori - profesorii catedrei;

elevi- 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 preda cursuri, pe de altă parte, ei înșiși sunt studenți și au îndrumător;

disciplina- disciplina predata (disciplina, curs).

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

Menținem 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 de evidențe complete și fiabile ale tuturor angajaților și studenților departamentului;

suport informaţional pentru deciziile de management, formarea unui complet şi informaţii de încredere despre proceselor educaționaleși rezultatele activităților departamentului;

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

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

interfață ușor de utilizat;

diferențierea puterilor între utilizatorii obișnuiți și administratori.

ÎN în acest exemplu Rezolvăm o anumită problemă - dezvoltăm un loc de muncă automatizat pentru secretarul departamentului, astfel încât departamentul este luat ca unitate structurală de cel mai înalt nivel pentru noi, ceea ce vom înțelege implicit, adică se presupune că toate elementele ale modelului se referă doar la acest departament, care nu este specificat în mod explicit. Nu vom lua în considerare structurile de nivel superior, cum ar fi o facultate sau o universitate.

4. Dezvoltarea unui model de sistem software folosind UML

UML este un limbaj de specificare și vizualizare ale cărui unități de bază sunt diagramele.

O diagramă în 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. O diagramă este, într-un fel, una dintre proiecțiile sistemului. De obicei, diagramele oferă o vedere condensată a elementelor care alcătuiesc un sistem. Același element poate fi prezent în toate diagramele, sau doar în câteva (cea mai comună opțiune), sau să nu fie prezent în niciuna (foarte rar). În teorie, diagramele pot conține orice combinație de entități și relații. În practică, însă, este folosit relativ o cantitate 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.

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ă corespund vederii statice a sistemului din punct de vedere al proiectării. Diagramele de clasă, care includ clase active, reprezintă o vedere statică a sistemului din perspectiva procesului.

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 de obiecte, precum diagramele de clasă, se referă la o vedere statică a unui sistem dintr-o perspectivă de proiectare sau proces, dar cu ochiul către o implementare reală sau prototip.

O diagramă de cazuri de utilizare reprezintă 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 sistemului.

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 sistemului. În acest caz, 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 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 o secvență de evenimente, 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 atunci când se modelează funcționarea acestuia și reflectă fluxul de control între obiecte.

O diagramă de componente arată organizarea unei colecții de componente și dependențele care există între ele. Diagramele componente se referă la o vedere statică a unui sistem din perspectiva implementării. Ele pot fi legate de diagramele de clase, 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 aflate î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 nod găzduiește 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, de exemplu, diagrame de profil de bază de date, diagrame de aplicație WEB etc.

4.1 Dezvoltarea unei vederi dintr-o perspectivă de caz 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 aceste scopuri. După cum sa discutat, diagramele de cazuri de utilizare identifică cazurile de utilizare și actorii ș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 anumite act e ra (Actor). Un caz de utilizare este folosit pentru a structura entitățile comportamentale ale unui model. Un precedent 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 specifică a comportamentului specificat de un caz de utilizare este furnizată de o clasă, colaborare de clasă sau componentă.

Un actor este un set coerent de roluri pe care utilizatorii de cazuri de utilizare le îndeplinesc atunci când interacționează cu ei. De obicei, un actor reprezintă rolul pe care îl joacă o persoană într-un anumit sistem, dispozitiv hardware sau chiar alt sistem. În sistemul dezvoltat „Postul de lucru al secretarului de departament” actorii sunt administratorul (admin) Și utilizator.

Grafic, un precedent este descris ca o elipsă delimitată de o linie continuă, care conține de obicei doar numele său; actorul are o pictogramă „omuleț”.

Pentru a construi o diagramă precedentă, este necesară identificarea acțiunilor elementare efectuate de sistem și compararea acestora cu precedentele. În același timp, este recomandabil să se acorde nume precedente, astfel încât să indice comportamentul; adesea astfel de nume conțin verbe, de exemplu, „generați un raport”, „găsiți date după criteriu”, etc. Puteți numi cazuri cu substantive care implică anumite acțiuni, de exemplu, „autorizare”, „căutare”, „control”.

Revenind la modelarea postului de lucru al secretarului de departament, să evidențiem precedentele:

Editaredate,

Căutarestudent,

Căutareprofesor,

Emisiunelistăpredatdisciplinelor,

Autorizare.

Elementele unei diagrame 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 utilizate relații de generalizare. Aceste relații au același sens ca în diagrama de clasă.

Mai mult, între precedentele în Limbajul UML sunt definite două dependențe specifice - 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ă este încorporat comportamentul altui caz de utilizare. Un caz de utilizare inclus nu există niciodată independent, 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 adoptând comportamentul celor incluse. Datorită prezenței relațiilor de incluziune, este posibil să se evite mai multe descrieri ale aceluiași flux de evenimente, deoarece comportament 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 include), iar alte cazuri de utilizare includ acele responsabilități în setul lor atunci când este necesar.

Relațiile de incluziune sunt reprezentate 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 inclus.

Relația de extensie este utilizată pentru a modela acele părți ale cazului de utilizare pe care utilizatorul le percepe ca comportament opțional al sistemului. În acest fel puteți separa comportamentul obligatoriu și opțional. Relațiile de extensie sunt, de asemenea, folosite pentru a modela subthread-uri individuale care se execută numai în anumite circumstanțe. În cele din urmă, ele sunt folosite pentru a modela mai multe fire care pot fi declanșate la un moment dat într-un scenariu ca rezultat al interacțiunii explicite cu un actor.

O relație de extensie este reprezentată ca o dependență cu stereotipul „extend”. Punctele de extensie a scenariului de bază sunt enumerate în secțiune suplimentară. Sunt pur și simplu etichete care pot apărea în fluxul de caz de utilizare subiacent.

Exemplu de utilizare această relație Poate exista acces la o bază de date care are o parte operațională și o arhivă. Mai mult, dacă solicitarea este furnizată cu date din partea operațională, se realizează accesul principal (de bază) la date, dar dacă datele din partea operațională nu sunt suficiente, se realizează accesul la datele de arhivă, adică accesul urmează un scenariu avansat.

În cazul nostru, precedentul editaredate include precedente: intraredate, ştergeredate, Schimbaredate.

O diagramă a precedentelor pentru postul de lucru al secretarului de departament este prezentată în Fig. 1.

Orez. 1. Schema precedente pentru postul de lucru al secretarului de departament

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

Atunci când se elaborează o viziune din punct de vedere al precedentelor, 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 lucrului, fluxurile de evenimente ale unui caz de utilizare sunt descrise în forma text. Pe măsură ce cerințele pentru sistem sunt clarificate, va fi mai convenabil să treceți la imagine grafică fluxuri în diagrame 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 descrieți un caz de utilizare ca un flux de evenimente, este important să desemnați ș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ă. Introducerea se finalizează prin apăsarea unei taste introduce. După aceasta, sistemul verifică autentificarea ș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 reia precedentul. Nu există nicio intrare în sistem.

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

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

În mod evident, descrierea unui caz de utilizare cu un flux de evenimente presupune un algoritm care poate fi reprezentat într-o diagramă de activitate (Fig. 2).

Diagrama algoritmului trebuie să conțină un vârf 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, indicată cu romburi) și conexiuni.

Diagrame similare pot fi folosite pentru a 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 de activitate.

4.2 Dezvoltarea unei vederi din punct de vedere al designului

Vederea de proiectare este etapa principală în dezvoltarea conceptuală a modelului. În această etapă sunt introduse abstracții de bază, sunt definite clase și interfețe prin care se implementează soluția problemelor atribuite. Dacă precedentele declară doar comportamentul sistemului, atunci în etapa de dezvoltare a tipului, 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ă, cele dinamice - prin interacțiune și diagrame de stare (automat).

Diagramele de clasă conțin clase, interfețe, colaborări și relațiile 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 definite î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ă ar fi necesar să se indice șeful fiecărei catedre din cadrul unei facultăți, mai bine ar fi 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, este necesar să ne amintim că fiecare clasă trebuie să corespundă unei entități reale sau unei abstractizări conceptuale din domeniul cu care se ocupă utilizatorul sau dezvoltatorul. O clasă bine structurată are următoarele proprietăți:

este o abstractizare clar definită a unui concept din vocabularul unui domeniu al problemei sau al domeniului soluției;

conține un set mic, precis definit de responsabilități și îndeplinește fiecare dintre ele;

menține o separare clară între specificațiile unei abstractizări și implementarea acesteia;

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

Ca parte a dezvoltării modelului postului de lucru al secretarului de departament, vom defini următoarele clase: profesori, elevi, studenți absolvenți, disciplinelor, grupuri. Evident, primele dintre ele au multe atribute comune, așa că haideți să introducem o clasă abstractă Ppersonaj, 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ă cu o relație de generalizare cu clasele profesori, elevi, studenți absolvenți.

Atribut abordare 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 reținut că atributul abordare clasă o persoana este o instanță a clasei T_ ADR, adică se stabilește o relație de dependență între aceste clase (afișat săgeată punctată cu vârful deschis, săgeata este îndreptată de la elementul dependent către elementul independent). În cazul nostru, schimbarea structurii clasei T_ ADR presupune o schimbare de clasă o persoana prin structura atributului corespunzător ( abordare).

Când modelezi o clasă T_ ADR atribut index să-l definim folosind un tip primitiv T_ POSTIDX, definit ca șase cifre numar decimal. Tipurile primitive sunt modelate de stereotip” tip" , intervalul de valori este specificat prin restricții cuprinse între acolade.

In clasa profesor Să evidențiem atributele specifice care se referă numai la profesor: denumirea funcției, 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 prin 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, introducem clase specializate prin enumerare T_Trebuie sa, T_UchSt, T_UchZv, care determină, respectiv, posibile posturi, grade academice, titluri academice prin enumerare. Î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 numărcărți de înregistrări. Atributele specifice sunt definite pentru clasa de absolvenți formăInstruireȘi Datachitanțe. Forma de instruire este determinată de o clasă specială prin enumerare T_FormEducation(normă întreagă, jumătate de normă).

Clasă grup are atribute: Nume, formă Instruire, numărstudio. ( numarul studentilor ). Având în vedere că profesorii de la catedra în cauză pot preda grupe de la alte facultăți, se introduce o clasă suplimentară specialitate, cu atribute număr(specialități), Nume(specialități ), facultate, ale căror tipuri nu sunt specificate în acest model, deși pot fi determinate prin enumerări.

Clasă disciplina are atribute: număr, Nume, ciclu. Atribut ciclu printr-un 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 cantitateore, cantitatesemestre nu poate fi specificat într-o clasă disciplina, întrucât depind de specialitate, mai ales că este imposibil de indicat în clasă specialitate. Aceste atribute se referă la perechea specialitate-disciplină și sunt definite în clasa - asociere Discipline-specialități.

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

Când vizualizați structura clasei, ar trebui să acordați atenție vizibilității atributelor. Toate atributele luate în considerare trebuie să fie accesibile și să aibă vizibilitatea Public (indicată printr-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 sunt destinate să fie descrise), prin urmare, pentru a face diagrama mai ușor de înțeles, este recomandabil să suprimam imaginea operațiilor.

Pe setul introdus de clase, este necesar să se definească în continuare conexiunile. Legăturile dintre generalizare și dependență au fost deja determinate; rămâne de determinat asocierile.

Elevi sunt formate în grupuri, in acest caz asocierea va avea forma de agregare. Agregarea presupune o relație parțială-întreg, denotată linie solida cu un diamant la capăt pe lateralul întregului (în cazul nostru grupuri). Multiplicitatea relației elev-grup este „mulți la unu”. Fiecare grup se referă la un anumit specialități, la rândul lor, mai multe grupe pot corespunde unei anumite specialități, astfel încât asociația grup-specialitate are și un tip de multiplicitate „mulți la unu”.

În acest caz, la fel ca î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ă stabilim asocierea dintre profesoriși a predat disciplinelor după tipul „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 o asociație multi-la-mulți: programă specialităţile conţin 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 acestei discipline pentru această specialitate.

Să introducem în mod similar o asociere între grupuriȘi profesori: profesorii desfășoară cursurile în grup, tipul de multiplicitate a asociațiilor este „mulți la mulți”. Asociere directă între grupuriȘi discipline nu trebuie definit, pentru că această legătură urmăribile prin clasa de legătură specialitate.

Pentru a afișa prezența unui supervizor pentru un student absolvent, este necesar să se introducă o asociere între absolvent și profesor de tip „mulți la unu”; un supervizor poate avea mai mulți absolvenți. Pe această asociere, rolul profesorului poate fi indicat clar: supraveghetor.

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

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

Studenți absolvenți poate preda și cursuri într-o anumită disciplină anumite grupuri: asociații de la mulți la mulți grupuri postuniversitare, studenți postuniversitari. Unii absolvenți s-ar putea să nu predea cursuri, astfel încât tipul de pluralitate de 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ă abstractă suplimentară, de exemplu, predare, care este un descendent al clasei o persoanași o superclasă pentru cursuri profesorȘi absolvent, ceea ce va reduce ușor numărul de conexiuni. (Fig. 4.). În acest caz de la cursuri disciplinaȘi grup asociaţiile vor merge la clasă predare, presupunând o legătură cu clasele profesorȘi absolvent prin moştenire (relaţie de generalizare). La clasa predare atributele pot fi eliminate licitare(0,5 tarif, tarif complet) și deversare.

Diagrama rezultată este destul de complexă și încărcată cu elemente, dar modelarea clasei este departe de a fi finalizată: 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 atributelor auxiliare care definesc tipurile de atribute (Fig. 5).

În fig. 5, alături de principalele clase corespunzătoare elementelor conceptuale ale sistemului, clasa T_ ADR, dezvăluind structura adresei, are și această clasă 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 de afara prin interfețe.

Interfață (Interfața) este un set de operații care definesc serviciul (setul 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. Grafic, interfața este reprezentată ca un cerc cu numele scris sub ea. O interfață există rareori pe cont propriu; este de obicei atașată la clasa sau componenta care o implementează. O interfață presupune întotdeauna existența unui fel de „contract” între partea care declară executarea unei serii de operațiuni și partea care implementează aceste operațiuni.

Să plasăm clasa pe diagramă electronicmasa, care încapsulează toate proprietățile și operațiunile unei foi de calcul care vă permite să editați datele. Nu vom dezvălui structura acestei clase datorită complexității sale mari. Astfel, în instrumentele moderne de dezvoltare a aplicațiilor, utilizatorul folosește clase și șabloane gata făcute, moștenind capacitățile acestora, de exemplu, biblioteca VCL (Delphi) conține clasa TTable, care încapsulează capacitățile unei foi de calcul. Descendenții clasei 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 vom defini interfața editare, adica totul operațiuni posibile editarea datelor (inserarea, ștergerea, modificarea datelor). Se presupune că în clasă electronicmasa aceste posibilități au fost realizate.

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.

Să definim interfețele căutareprofesor, căutaredisciplinelor, atașându-le 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ță sub formă scurtă este reprezentată printr-o linie continuă simplă (ca o asociere).

Interfață căutarestudent afișaj care indică o listă de operațiuni printr-o clasă stereotipată, cu relația de implementare 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 printr-o relație 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 CoderTable(Tabel codificat) care conține parole ( parola) și nume de intrare ( log in) utilizatori administratori. Se presupune că capacitățile clasei de utilitate CoderTable nu permite unui utilizator neautorizat citiți parolele utilizatorului. În această etapă de proiectare, pur și simplu declarăm astfel de capabilități, fără să ne oprim asupra mecanismului de implementare a acestora, ci presupunând că sunt încapsulate într-o clasă CoderTable.

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

Să indicăm dependența dintre interfața de editare a datelor ( editare) și administrator de acces, presupunând că capabilități complete Numai utilizatorii cu drepturi de administrator pot edita datele.

Orez. 6. Diagrama finală de clasă a postului de lucru al secretarului de departament

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

Deci, dezvoltarea unui model orientat pe obiecte a stației de lucru a secretarului de departament folosind diagrame de clasă UML poate fi considerată completă în această etapă. Desigur, este posibil să reveniți la acesta și să revizuiți unele elemente în timpul proiectării sistemului, la ajustarea sarcinilor, la clarificarea detaliilor individuale. Procesul de proiectare a sistemelor informatice este iterativ. Trebuie remarcat faptul că diagrama de clasă dezvoltată conține elemente care implementează în mod explicit sau implicit toate cazurile de utilizare pentru diagrama cazurilor de utilizare. Fiecare caz de utilizare dintr-o diagramă de caz de utilizare trebuie să corespundă fie unei interfețe, 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ă ne uităm la procesul de creație intrare nouă despre elev folosind diagrame succesive.

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

Trebuie remarcat faptul că diagramele de interacțiune implică obiecte, adică instanțe specifice de clase (numele obiectului este întotdeauna subliniat).

Gestionam obiecte: formăintrare, administratorînregistrări, fișa studentului Petrov(Cum exemplu concret dosarele studenților), administratortranzacții. Acest set de obiecte este tipic atunci când se modifică o înregistrare într-un tabel de bază de date.

Formăintrare- element interfața cu utilizatorul, reprezintă forma standard introducerea datelor studentului (nume, prenume, patronim, adresa etc.). În cazul nostru, este o implementare specifică puțin mai mult definită 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 indicaț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 foaie de calcul. Acest set de capabilități este moștenit de clasă elevi din clasa electronicmasa. Pentru obiect Administratorînregistrări clasa a cărei instanță este este menționată în mod explicit - elevi.

Petrov- o intrare specifică despre studentul Petrov, un nou element al tabelului despre studenți. Aici vom indica în mod explicit clasa introdusă recordOstudent. Astfel de obiecte există de obicei temporar pentru a trimite informații relevante către baza de date în timpul tranzacțiilor. După finalizarea tranzacției acest obiect poate fi distrus. Obiectul corespunzător înregistrării poate fi creat din nou dacă este necesară editarea informației.

Administratortranzacții- un obiect care asigură executarea unei operațiuni finalizate pe baza de date, în acest caz crearea unei noi înregistrări despre elevul 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).

În Fig. 7.

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

Folosind diagrama de secvență, definim transmiterea mesajelor între obiecte: creanourecord(difuzat de la obiect la obiect până la capătul lanțului ca mesaj Salvațirecord); deschisformă(la formularul de introducere); introduceF.ȘI DESPRE.,abordare. ( introducerea datelor elevilor), atunci aceste date sunt transmise prin mesaje SalvațiF.ȘI DESPRE.,abordare. Din administratortranzacții un mesaj este trimis pentru colectare informațieOstudent, furnizarea părere cu baza de date și, în final, un mesaj reflectorizant administratortranzacții numit ca SalvațirecordVDB, 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 de la precedentul la mod automat(în Rational Rose apăsând 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 Dezvoltarea unui profil de baze de date relaționale

Dacă pentru implementarea sistemului se folosește un SGBD orientat pe obiecte (OODBMS), 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) ar trebui să fie utilizată ca nucleu informațional al unui sistem 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 a UML care păstrează intact metamodelul UML. Profilul 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 baze de date proiectate și regulile de proiectare a bazelor de date relaționale, la profil au fost adăugate pictograme corespunzătoare (în continuare simple baze de date). O bază de date este descrisă folosind tabele, coloane și relații. Un profil 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 dintr-o bază 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.

Performanţă ( View este un tabel virtual care se comportă din punctul de vedere al utilizatorului exact ca un tabel obișnuit, dar nu există de la sine.

Stocat procedură ( Procedura stocată) este o funcție procedurală independentă executată pe server.

Domenii ( Domeniile 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 informatice î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 curs, adăugată 28.05.2009


Definiția conceptului „sistem”. Istoria dezvoltării și caracteristicile sistemelor informaționale moderne. Principalele etape de dezvoltare a 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 tehnologiei informației. Tipuri de tehnologii informaționale.

lucrare de curs, adaugat 17.06.2003


Conceptul de instrumente CASE ca software care sprijină procesele de creare și întreținere a sistemelor informaționale (IS). Caracteristicile tehnologiei IDEF pentru dezvoltarea IP. Descrierea notației IDEF0. Dezvoltare modele funcționale proces 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 descriere a claselor proces educațional. Implementarea unui sistem informatic dat.

teză, adăugată 17.02.2015


Dezvoltarea sistemelor informatice. Piața modernă software de aplicație 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 formularelor 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 echipamentul centrului de date. Concepte și principii de bază ale modelării. Alegerea unei metode de rezolvare a problemelor. Metoda lui Zeutendijk a direcțiilor admisibile, algoritmul Frank-Wolfe.

lucrare curs, adăugată 18.05.2017


Conceptul de sistem informatic. Etapele dezvoltării sistemelor informaţionale. Procesele din sistemul informatic. Sistem informatic pentru găsirea de nișe de piață și reducerea costurilor de producție. Structura sistemului informatic. Suport tehnic.

Orez. 3.1.1. Clasificarea metodelor de modelare

(naturale sau artificiale, de exemplu, descrierea datelor sau limbaje de modelare), sisteme de alarmă în societate și în lumea animală etc.
Semiotica cuprinde trei secțiuni: sintactica; 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 mesaj.
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ă relația utilizatorului unui sistem de semne cu 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 societate modernăși introducerea metodelor formale în toate sferele activității umane, le evidențiem 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țiuni, vom folosi cunoscuta metodologie de analiză a sistemelor, teoria eficienței și luarea deciziilor.

Mai multe despre subiectul 3. TEHNOLOGIE PENTRU MODELAREA SISTEMELOR INFORMAȚII Metode de modelare a sistemelor:

1. Modele de simulare a sistemelor informaţionale economice Baza metodologică de aplicare a metodei simulării
2. Secțiunea III BAZELE MODELĂRII UNUI SISTEM DE MARKETING DE SERVICII
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 UNUI MODEL DE SISTEM DE MARKETING ÎN MODELAREA SIMULARE
6. Conceptul de modelare a sferei financiare a sistemelor de marketing