Modelare orientată pe obiecte: Maxim Kidruk. Bazele matematice ale graficii vectoriale. Crearea unei diagrame de clasă

Mihail Vasiliev, Igor Khomkov, Serghei Shapovalenko

Aproape în toate etapele ciclu de viață Sisteme informatice (IS) - atât proiectarea, când sunt stabilite principalele caracteristici ale sistemului, cât și întreținerea și gestionarea unui IS deja construit - apar multe întrebări care sunt de o importanță capitală. O sa această arhitectură IP pentru a satisface nevoile tot mai mari? Ce blocaje necesită cea mai mare atenție? Ce investiții sunt necesare pentru ca PI să rămână în stare de funcționare într-un an?.. trei ani?.. cinci ani? Care este eficacitatea IP-ului utilizat?

Răspunsul la toate aceste întrebări nu este deloc ușor. Este și mai greu să le răspunzi corect. Analiza corporativă Sistem informaticîn orice stadiu al existenţei sale este o chestiune complexă.

Putem spune că complexitatea sistemelor informaționale corporative nu este întâmplătoare, ci mai degrabă o proprietate necesară. Este determinată de o serie de motive, printre care se numără următoarele:

Complexitatea problemei care se rezolvă;

Complexitatea dezvoltării SI;

Dificultatea de a asigura parametri precum adecvarea, scalabilitatea, fiabilitatea, eficiență economică si siguranta;

Dificultate în descrierea subsistemelor IS individuale.

Evaluările obiective pot fi furnizate prin utilizarea tehnologiilor de modelare. Construirea unui model, analizarea acestuia și obținerea de răspunsuri la întrebările „ce se va întâmpla dacă...?” ne permit să prezicem comportamentul SI în diverse situații. Prototiparea și construcția în bancă sunt cele mai des folosite modele de calculator ESTE.

În prezent, există trei lideri pe piața instrumentelor de modelare a sistemelor informaționale. Acestea sunt companiile americane MIL3 (sistem de modelare OPNET), Make Systems (sistemul NetMaker XA) și CACI Products Company (sistemul COMNET). În fig. 1 prezintă fereastra principală a sistemului OPNET. (În PC Week/RE, Nr. 34/98, p. 36, Fig. 2 prezintă o fereastră reprezentare grafică rezultă în sistemul OPNET.) Să ne oprim mai detaliat asupra unuia dintre aceste sisteme și asupra abordării implementate în acesta.

Tehnologia de modelare IC folosind COMNET III

Modul evident de modelare a sistemelor complexe este de a le descompune conform principiului străvechi al lui Divide et impera (Împărțire și cuceri - latină). Reprezentarea ierarhică a IS complex ca un set de subsisteme interconectate este cheia pentru descoperirea situației. Subsistemele obținute ca urmare a unei astfel de descompunere pot fi, la rândul lor, împărțite în subsisteme ale următorului nivel al ierarhiei și așa mai departe la infinit. Este capacitatea de a descompune sisteme complexe care ne permite să le creăm modelele. Totuși, pe această cale este extrem de important să te poți opri la timp.

Se determină etapa finală a procesului de descompunere Cel mai mic nivel abstracții utilizate în fiecare model specific. Fragmentarea excesiv de detaliată poate duce la un rezultat care este exact opusul a ceea ce era așteptat: în loc să simplificați sistemul modelat, puteți ajunge la complexitatea acestuia, în ceea ce se numește „nu puteți vedea pădurea pentru copaci”. Astfel, alegerea nivelului corect de abstractizare este esențială pentru modelarea de succes.

Următorul pas pentru a facilita modelarea sistemelor complexe este descoperirea și izolarea abstracțiilor comune. Să presupunem că am descompus deja SI modelat și am obținut o anumită ierarhie a entităților. De exemplu, Router Cisco 7500 și NS7000, care are mai multe plăci de rețea și efectuează rutarea software, pot fi considerate atât ca două obiecte complet diferite, cât și ca două obiecte aparținând aceleiași clase de routere. Descompunerea sistemului folosind metafora clasei în combinație cu un nivel de abstractizare selectat corect vă permite să simplificați radical construcția unui model IS.

Orez. 1. Fereastra principală a sistemului OPNET

De obicei, sunt luate în considerare două tipuri principale de descompunere: algoritmică, care împarte sistemul studiat în funcție de principiile sale active, adică procesele care au loc într-o anumită ordine, și orientată pe obiecte, care face posibilă împărțirea sistemului în studiază în clase de abstracții similare. Ambele tipuri de descompunere și-au găsit drumul în COMNET III.

Abordarea construirii modelelor în COMNET III poate fi prezentată ca secvență standard pași:

Descrierea topologiei IC și determinarea parametrilor echipamentului;

Descrierea surselor de trafic și comportamentul acestora, descrierea încărcării rețelei;

Definirea scenariului de simulare.

Determinarea topologiei IS și a conexiunilor dintre sursele de trafic și nodurile de topologie este un domeniu ideal pentru aplicarea descompunere orientată pe obiecte. Descompunerea algoritmică este necesară pentru a descrie comportamentul surselor de trafic și modificările încărcării rețelei în timp.

După cum sa menționat deja, condițiile de limită pentru descompunerea IS depind de nivelul necesar de abstractizare. Abstracția permite dezvoltatorului să creeze un proiect IP sau administrator de sistem care o însoțește, pentru a separa cele mai semnificative trăsături ale comportamentului ei de modul exact în care sunt implementate. „O abstractizare bună este una care subliniază detaliile care sunt esențiale pentru luare în considerare și utilizare și le omite pe cele care în prezent nu sunt importante sau distrag atenția”*1. Deci, într-o situație, atunci când descrieți un computer, este suficient să îl definiți ca sursă de trafic, fără a intra în descriere detaliata arhitectura, in alta poate fi necesar considerație detaliată caracteristici precum, de exemplu, numărul de procesoare și parametrii subsistemului de disc.

*1. Shaw M. Tehnici de abstractizare în limbaje de programare moderne. - Software IEEE, oct. 1984, v. 1(4), p.10.

Sistemul COMNET aplică pe deplin metoda de descompunere orientată pe obiecte, care poate reduce semnificativ timpul de modelare și poate face procesul său intuitiv și clar corelat cu sistemul real. Modelul este creat din obiecte, un fel de „blocuri de construcție”, familiare utilizatorului din experiența de viață reală. Sistemul COMNET vine cu o bibliotecă mare de astfel de obiecte - modele reale echipamente de rețeași metodele de acces la mediu. Să aruncăm o privire mai atentă asupra modelului obiect COMNET (Fig. 2).

Orez. 2. Biblioteca clasei COMNET III de bază

Obiectele din acest sistem pot fi împărțite în două clase: cele utilizate, în primul rând, pentru a descrie topologia și, în al doilea rând, pentru a descrie caracteristicile de trafic și încărcare ale rețelei. Ecranul de bază COMNET III cu un set de clase de bibliotecă este prezentat în Fig. 3.

Orez. 3. Ecranul principal al sistemului COMNET

Descrierea topologiei în COMNET III

Astfel de concepte de topologie de bază în sistemul COMNET III precum noduri, conexiuni, arcuri au fost descrise în PC Week/RE, Nr. 34/98, p. 34.

Pe lângă noduri, conexiuni și arcuri pentru descrierea topologiilor ierarhice și modelarea domeniilor rutabile independente, sistemul COMNET include o altă clasă suplimentară, ale cărei obiecte pot fi, de asemenea, localizate la vârfurile graficului - o subrețea.

Utilizarea mecanismelor de moștenire, inclusiv a celor multiple, extinde gama de clase utilizate.

Clasa nod este moștenită de patru clase noi.

Clasa „Computer și Nod de comunicații” (C&C Nod, Computer and Communications Node)

Aceste obiecte pot servi ca surse de trafic sau chiuvete și sunt, de asemenea, folosite pentru modelarea complexului sisteme software, ținând cont de sarcina procesorului și a subsistemelor de disc. Nodurile IC descrise folosind C&C Node pot fi, de asemenea, utilizate pentru modelarea routerelor software.

Clasa Computer Group Node

Obiectul poate fi folosit doar pentru modelare sisteme informatice, deoarece funcționalitatea lor include doar o sursă și un receptor de trafic. De regulă, este folosit pentru a descrie grupuri de computere care au un comportament identic.

Clasa Router Node

Obiectele de acest tip sunt folosite pentru modelarea routerelor hardware. La fel ca C&C Node, Router Node poate acționa atât ca sursă, cât și ca receptor de trafic și poate rula aplicații care utilizează resursele hardware ale nodului (procesoare, subsisteme de discuri). Pentru o descriere mai detaliată a implementării hardware a obiectelor simulate, un număr de proprietăți suplimentare, cum ar fi prezența și parametrii magistralei interne, care vă permite să simulați fluxul intern de trafic între porturile de intrare și de ieșire ale obiectului.

Switch Node class

Obiectele de tip Switch Node, care au capacitatea de a ruta, sunt folosite pentru a modela comutatoarele care petrec o cantitate neglijabilă de timp transmitend trafic între porturile interne. Cu toate acestea, aceste obiecte, spre deosebire de cele trei anterioare, nu pot fi folosite nici ca sursă, nici ca receptor de trafic.

Obiectele claselor C&C Node, Computer Group Node și Router nod pentru modelarea sistemelor software complexe includ un depozit de comenzi care utilizează proprietățile obiectului deja menționate, cum ar fi caracteristicile subsistemului de disc. La o bibliotecă de obiecte actualizată constant diverse clase COMNET include o gamă largă de modele de dispozitive hardware reale.

Obiectul link moștenește două obiecte noi.

Clasa „Legătură punct la punct”

Această clasă este folosită pentru a descrie canalele dintre două noduri. Exemple de astfel de conexiuni includ linii închiriate care conectează routerele în rețele de zonă extinsă sau conexiuni în rețele cu comutare de circuite.

Clasa „Link multiacces”

Câmpul de aplicare pentru această clasă îl reprezintă situațiile în care mai multe noduri au acces la același mediu de transmisie a datelor. La rândul său, acest obiect este moștenit de o serie de obiecte noi care descriu fapte specifice implementării metodei de acces mediu, cum ar fi Detectarea purtătorului, trecerea de simboluri, SONET etc. (vezi Fig. 2).

Până acum am luat în considerare cazurile în care un obiect părinte este moștenit de un singur obiect copil. Cu toate acestea, abordarea orientată pe obiect permite, de asemenea, situații mai complexe cu moștenire multiplă. Această formă de moștenire este aplicabilă și în sistemul COMNET. Aici, moștenirea multiplă este folosită pentru a crea obiecte din clase atât de importante precum Transit Network și WAN Cloud.

Ambele clase sunt descendenții a două clase părinte - Subnet și Link. Forma de moștenire este prezentată în fig. 2. Să luăm în considerare această opțiune mai detaliat.

Clasa de subrețea

O clasă extrem de importantă. Folosit pentru a crea topologii ierarhice IC, vă permite să descrieți corect subrețele cu diferiți algoritmi de rutare, independent de algoritmul utilizat pe coloana vertebrală. În plus, subrețelele sunt folosite pentru a ascunde detaliile excesive atunci când modelați circuite integrate complexe. În COMNET, acestea sunt folosite pentru a descrie sisteme cu adâncime de imbricare arbitrară. Conexiunile dintre topologia internă a subrețelei și topologia backbone se realizează folosind puncte de acces, al căror număr poate fi arbitrar (vezi Fig. 3).

Clasa „Transit Net”

Un copil de subrețele și conexiuni este un obiect care combină proprietățile obiectelor părinte. O rețea de tranzit poate fi considerată atât o conexiune, cât și o subrețea în același timp. Ca o conexiune, transmite pachetele din bufferul de ieșire al unui nod către bufferul de intrare al altuia. Sub forma unei subrețea, rețeaua de tranzit creează în limitele sale o zonă cu propriul algoritm de rutare.

Clasa „Cloud” (WAN Cloud)

Obiectele acestei clase, care vă permit să creați reprezentări abstracte pentru rețele globale, moștenesc, de asemenea, proprietățile obiectelor părinte - Subnet și Link. Din perspectiva topologiei, obiectul WAN Cloud funcționează ca un obiect de conexiune, pictograma sa conectându-se direct la noduri. În ceea ce privește structura sa internă, cloud-ul constă dintr-un set de circuite virtuale și legături de acces, un tip de conexiune punct la punct pentru modelarea rețelelor globale.

Descrierea traficului și a încărcării rețelei în COMNET III

După cum am spus deja, modelul IS în COMNET include două părți: o descriere a topologiei sistemului și o descriere a surselor de trafic și a încărcării rețelei. Ne-am uitat la gama de bază de obiecte asociate cu topologia. Acum să ne întoarcem la obiectele care descriu traficul.

COMNET oferă o gamă largă de instrumente pentru descrierea traficului.

Clasa de mesaje

Obiectele care aparțin acestei clase vă permit să trimiteți un singur mesaj fie către un obiect destinatar, fie către mai multe obiecte. Redirecționarea unor astfel de mesaje este tratată ca o secvență de datagrame, unde fiecare pachet este direcționat independent de celelalte.

Clasa „Răspuns”

Obiectele acestei clase pot fi folosite numai pentru a trimite mesaje de răspuns. Ele sunt controlate de sosirea mesajelor create de obiecte din clasele Message sau Response. Destinatarul mesajelor clasei Response va fi întotdeauna un obiect al clasei Node la care este conectată sursa mesajelor de control (a clasei Response sau Message).

Clasa „Apel”

Obiectele clasei Call sunt utilizate pentru a crea modele de rețele cu comutare de circuite. Sursa apelului este descrisă de un set de parametri precum legea distribuției, durata și, ținând cont de clasa de rutare, cerințele de lățime de bandă.

Clasa de sesiune

Aceste obiecte sunt folosite pentru a modela sesiuni care includ seturi de mesaje sau mesaje direcționate prin conexiuni virtuale. O sesiune este inițiată prin trimiterea unui pachet de configurare a sesiunii și primirea unui pachet de confirmare. Ulterior, un număr arbitrar de mesaje poate fi trimis în cadrul sesiunii, descris și în obiectul clasei Session. Astfel de mesaje sunt direcționate fie ca datagrame, fie ca conexiuni virtuale, în funcție de algoritmul de rutare de pe coloana vertebrală sau subrețeaua care conține obiectul.

De asemenea, rețineți că COMNET III folosește așa-numitele fișiere de trafic externe, care pot fi obținute folosind diverse analizoare de trafic.

De un interes deosebit sunt obiectele clasei „Aplicație”, care este rezultatul moștenirii multiple a claselor Message, Response, Call și Session (vezi Fig. 2). Obiectele sale permit cea mai flexibilă descriere în cadrul modelului volumul de muncă rețelele și comportamentul surselor de trafic. Mai mult, atunci când le folosesc, aproape orice tip de sistem software poate fi simulat cu ușurință, inclusiv cele distribuite, cum ar fi DBMS, sisteme poştale etc.

Aplicația reală descrisă de obiectele acestei clase include trei componente. În primul rând, aceștia sunt parametrii nodului la care este conectat obiectul clasei Application. Folosind acești parametri, setați caracteristicile și cantitatea procesoarele necesareși subsisteme de discuri. În al doilea rând, acestea sunt așa-numitele depozite de comenzi care folosesc caracteristicile nodurilor menționate mai sus. Și în al treilea rând, acesta este obiectul Aplicație în sine, care controlează secvența de execuție a acestor comenzi.

Depozitul de comenzi al nodului și, prin urmare, obiectul clasei Application, poate conține următoarele comenzi:

Transport Message (transmite mesaj). Această comandă este rezultatul unui obiect moștenit de clasa Application de la un obiect părinte al clasei Message.

Configurarea este rezultatul moștenirii clasei Session.

Answer Message este un moștenitor al clasei Response.

Filter Message (filtrare mesaje). Această comandă vă permite să întrerupeți toate operațiunile descrise în obiectul Clasa Aplicație până când este primit un mesaj care îndeplinește condițiile de filtrare.

Proces. Această comandă simulează procesarea care provoacă încărcarea procesorului.

Citește și scrie (citește și scrie). Aceste două comenzi vă permit, de asemenea, să simulați ocuparea procesorului nodului, dar în contextul interacțiunii cu subsistem disc citirea și scrierea fișierelor.

Astfel, folosind clasele Aplicație, Mesaj, Răspuns, Sesiune și Apel, este posibil să se simuleze atât în ​​mod flexibil încărcarea curentă a rețelei, cât și descriere detaliata comportamentul sistemelor software incluse în IS. Este extrem de important ca aceste clase să vă permită să modelați sisteme software distribuite complexe și impactul acestora asupra existente infrastructura retelei retelelor.

Obiecte COMNET III: Abstracția parametrică

Când vorbim despre setul de bază al claselor COMNET III, este extrem de important să menționăm aplicabilitatea așa-numitei abstractizări parametrice la acestea. Această abordare vă permite să creați noi obiecte - instanțe ale unei clase cu proprietăți diferite. Soluțiile tehnologice importante, cum ar fi, de exemplu, Gigabit Ethernet, pot fi modelate foarte simplu prin modificarea parametrilor abstracției în cauză - proprietățile clasei selectate.

Să ne uităm la un exemplu. Să presupunem că simulăm retea locala, care utilizează o metodă de acces aleatoriu cu detectarea purtătorului și detectarea coliziunilor la substratul MAC (CSMA/CD, o clasă de conexiuni cu acces multiplu), cu toate acestea, standardul stratului de legătură propus de producătorul de echipamente de rețea este oarecum diferit de cel „nativ” IEEE 802.3. Situație similară atunci când utilizați un produs care nu implementează o abordare orientată pe obiecte, ar putea cauza unele inexactități. Dezvoltatorul ar fi obligat să folosească standardul oferit de producătorul produsului, cel mai probabil clasic 802.3. În fig. Figura 4 prezintă fereastra interfeței COMNET III, cu ajutorul căreia utilizatorul poate edita parametrii acestui standard - numărul de retransmisii în cazul detectării coliziunii, lungimea antetului cadrului etc. Cu alte cuvinte, utilizatorul însuși realizează parametrizarea a obiectului.

Orez. 4. Parametrizarea conexiunii 10BaseT conform standardului IEEE 802.3

Deci, decidem asupra corespondenței dintre standardul de referință și standardul producătorului. Acțiunile noastre ulterioare se reduc la completarea bibliotecii de obiecte de clasă CSMA/CD cu un nou standard definit de utilizator. Pentru a face acest lucru, trebuie doar să adăugați noi parametri. Putem face același lucru cu nodurile hardware, sursele de trafic, parametrii WAN Cloud etc.

Din aceasta putem observa că parametrizarea dă oportunități ample pentru a extinde biblioteca de bază de obiecte, permițând dezvoltatorului de modele să ia decizii mai flexibile.

Extinde set de bază cursurile sunt posibile cu utilizare ulterioară mecanism de moștenire.

Mod intermodel copy-paste

Să presupunem că construim un model mare care are o descriere topologică foarte complexă. Aici putem merge în două moduri: combinăm întreaga topologie a sistemului într-un singur fișier sau construim mai multe fragmente și ulterior le combinăm. A doua opțiune este mai convenabilă pentru dezvoltator din mai multe motive. Aceasta include ușurința de depanare a fiecărui fragment individual, vizibilitate bună și, în cele din urmă, fiabilitate mai mare.

Pe viitor, întreaga problemă este să transferăm obiecte de la un model la altul. Pentru a rezolva acest lucru, este convenabil să folosiți modul COMNET III Intermodel copy-paste (copierea și lipirea unui model extern), care asigură transferul de la model la model al obiectelor nou create cu toate proprietățile, cu excepția celor care sunt locale modelului sursă. .

Să dăm un exemplu. Să presupunem că transferăm un fragment de rețea care are o anumită încărcare de la un model la altul. Traficul este descris de obiecte din clasa Message. O proprietate a unor astfel de obiecte care este locală modelului sursă este destinația acestuia. Proprietățile rămase vor fi transferate fără modificări de la obiectele care moștenesc clasele Nod (C&C nod, Computer group, Router, Switch), Link etc., nelegate de modelul sursă.

Procedura de parametrizare în acest caz este foarte simplă. În special, pentru un mesaj puteți specifica direcția acestuia în conformitate cu lista de nume din noul model, care este atașată automat obiectului.

Utilizarea metodei descrise deschide posibilități largi de construire a oricăror modele dintr-un set flexibil și extensibil de obiecte - blocuri de construcție, permițându-vă să reduceți semnificativ costurile de modelare.

Construcție modulară noduri

Să luăm în considerare procedura de creare a unui obiect al unei clase noi bazate pe moștenirea multiplă.

Să presupunem că un dezvoltator are sarcina de a construi un model detaliat dispozitiv hardware(de exemplu, un router, dintre care mai multe module de interfață sunt conectate printr-o magistrală de interfață). Scopul construirii modelului este de a determina întârzierea pe magistrala de interfață. În descrierea standard a COMNET III, magistrala este descrisă de doi parametri: lățimea de bandă și frecvența. Este clar că o astfel de descriere nu este suficientă pentru noi. Cu toate acestea, avem la dispoziție un obiect care ne permite să descriem anvelopa ca dispozitiv separat, - conexiune. În general, acest lucru nu este în totalitate soluție standard, dar după efectuarea parametrizării necesare a obiectului clasei Link, vom obține un model al magistralei ca dispozitiv complet funcțional care implementează, de exemplu, funcția de arbitrare. Arată în Fig. 5, obiectul MPRouter este modelat exact în acest fel. Autobuzul de interfață funcționează folosind algoritmul Token Bus.

Orez. 5. Parametrizarea sursei de trafic în timpul transferului

fragment de model la alt model (Sursa sesiunii)

Trebuie spus că dezvoltatorul nu ar trebui să abuzeze de astfel de tehnici, deoarece, după cum sa menționat deja, o descriere prea precisă a fiecărui obiect în unele situații poate avea efectul opus, care se exprimă în reducerea fiabilității modelului în ansamblu. Această tehnică este aplicabilă în cazurile în care este necesară o descriere detaliată a caracteristicilor obiectelor.

Abilitatea de a seta stări ale obiectelor

Orice obiect din COMNET poate fi în mai multe stări. De exemplu, pentru obiectele din clasele Link și Node, stările posibile sunt sus, jos, eșec (pornit, oprit, eroare). De asemenea, puteți simula tranzițiile între aceste stări și puteți analiza efectul tranziției asupra circuitului integrat simulat (Fig. 6).

Orez. 6. Determinarea parametrilor stării curente a obiectului (Node Properties)

Acest lucru oferă dezvoltatorului o oportunitate largă de a crea scenarii dinamice precum „ce se întâmplă dacă...?” și astfel crește semnificativ flexibilitatea modelului creat.

Așadar, am analizat principalele instrumente și cele mai comune tehnici de construire a modelelor în COMNET III. Autorii plănuiesc să dedice alte articole modelării diverse solutii, utilizat pe scară largă în circuitele integrate moderne.

Tutorialul contine: rezumat Limbajul UML - acea parte a acestuia care poate fi folosită ca bază pentru un limbaj de modelare complex sisteme dinamice; descrierea și capacitățile noului limbaj de modelare propus de autori bazat pe automate hibride, care este o extensie a UML; prezentare istorică și exemple de abordări diferite pentru proiectarea instrumentelor de modelare; analiza orientată pe obiect a sistemelor dinamice complexe. Cartea este a doua dintre cele trei cărți reunite sub titlul general Modeling of Systems.

Necesitatea unui limbaj de descriere a modelului unificat.
Tehnologie tradițională pentru proiectarea sistemelor complexe care nu necesită prealabil modelare pe calculator, cuprinde următoarele etape principale: formularea cerinţelor pentru viitorul sistem, elaborarea documentației de proiectare pe baza acestora, realizarea unui prototip, testarea acestuia pentru conformitatea cu cerințele și întreținerea desenului industrial.

Într-un caz ideal, o specificație funcțională completă, dezvoltată de analiști de sistem sau automat folosind tehnologia computerizată, este deja o soluție de proiectare; tot ce rămâne este să construim un model fizic conform acestei specificații, care va fi sistemul proiectat. Din păcate, nu este. Creare sistem real, corespunzătoare specificațiilor funcționale dezvoltate, necesită soluții de inginerie creative, neformalizate și muncă manuală.

Chiar și „partea soft” aparent complet formalizată a sistemelor tehnice moderne - software-ul încorporat - este cel mai adesea executată pe computere încorporate speciale sau microprocesoare cu canale speciale de schimb, sisteme de operare speciale și alte caracteristici care necesită o reglare fină „manuală” a software-ului dezvoltat. . Fără această etapă de „manual”, prost formalizată, este dificil să se asigure cerințele speciale pentru funcționarea fiabilă a sistemului la anumite temperaturi, vibrații, suprasarcini, niveluri de radiație, restricții de volum și greutate. Capitolul 5 discută condițiile în care generare automată software încorporat, dar specificații funcționale, iar aceste condiții sunt încă foarte departe de realitățile de astăzi.

Cuprins
Cuprins
Prefaţă
Capitolul 1. Abordarea orientată pe obiecte a modelării
Necesitatea unui limbaj de descriere a modelului unificat
Clase, instanțe și sisteme cu mai multe componente
Utilizarea UML în etapa inițială de proiectare
Diagrame de clasă
Atribute
Comportament
Operații și metode
Clase abstracte și concrete. Interfețe
Clase și relații
Asociere
Generalizare
Agregare
Moştenire
Polimorfism
Comportament. Diagrame de stări
Clasificatori structurați
Componente
Evenimente și semnale
Pachete
Model
Capitolul 2. Modelarea orientată obiect a sistemelor dinamice complexe bazate pe formalismul automatului hibrid
Clasa activă și obiect dinamic activ
Pachete si model
Utilizarea obiectelor pasive
Variabile
Tipuri de date
Tipuri scalare
Tip real
Tipuri întregi
tip boolean
Tipuri de enumerare
Tipuri de caractere
Tipuri obișnuite
Vectori
Matrici
Matrice
Liste
Tip combinat (înregistrare)
Tipuri definite în mod explicit
Semnale
Turnare de tip automat
Sistem de ecuații
Harta comportamentului
state
Tranziții
Schema structurala
Obiecte
Conexiuni
Structuri regulate
Moștenirea de clasă
Adăugarea de noi elemente de descriere
Suprascrierea elementelor moștenite
Polimorfism
Clase parametrizate
Capitolul 3. Modelarea sistemelor hibride și abordarea orientată pe obiecte în diverse pachete
Modelarea sistemelor hibride în instrumente pentru calculatoare mainframe
limba SLAM II
limbajul NEDIS
Modele hibride în instrumente moderne modelare
Modelarea sistemelor hibride în pachetul Simulink („modelare în bloc”)
Modelarea sistemelor hibride în limbajul Modelica (" modelare fizică")
Direcție hibridă
Limbaje de modelare orientate pe obiecte
Simula-67 și NEDIS
ObjectMath
Omola
Modelica
Instrumente de modelare a blocurilor
Analiza limbajelor OOM existente în legătură cu modelarea sistemelor dinamice complexe
Capitolul 4. Modele multi-obiect
Capitolul 5. Modelare orientată pe obiecte și analiză orientată pe obiecte
Sistem tehnic complex
Analiza orientată pe obiect în dezvoltarea sistemelor tehnice complexe
Modelare orientată pe obiecte la etapele ulterioare de dezvoltare și întreținere a complexului sistem tehnic
Modelul analitic de sistem ca bază a tehnologiei de proiectare „end-to-end”.
Literatură
Citiri suplimentare pentru capitolul 1
Citiri suplimentare pentru capitolul 2
Citiri suplimentare pentru capitolul 3
Citiri suplimentare pentru capitolul 4
Citiri suplimentare pentru capitolul 5
Index de subiect.

Descărcați cartea electronică gratuit într-un format convenabil, vizionați și citiți:
Descarcă cartea Modelarea sistemelor, abordare orientată pe obiecte, Kolesov Yu., Senichenkov Yu., 2012 - fileskachat.com, descărcare rapidă și gratuită.

Descărcați pdf
Puteți cumpăra această carte mai jos cel mai bun preț la reducere cu livrare în toată Rusia.

Concept modelare orientată pe obiecte(OOM) este cu siguranță legat de programare orientată pe obiecte(OOP). Această abordare a dezvoltării software, care a apărut la mijlocul anilor 1980, a avut ca scop inițial rezolvarea problemelor care decurg din creșterea și complexitatea inevitabile a programelor, precum și sarcinile de prelucrare și manipulare a datelor. În acel moment a devenit evident că metode tradiționale programare procedurală Nu suntem capabili să facem față complexității tot mai mari a programelor și dezvoltării lor și nici nevoii de a le îmbunătăți fiabilitatea. În același timp, sarcinile computaționale și computațional-algoritmice, în special în domeniul suportului pentru afaceri, au început treptat să treacă în plan secund, iar sarcinile de prelucrare și manipulare a datelor au început să ocupe primul loc.

Conceptele fundamentale ale POO sunt conceptele de clasă și obiect. În același timp, sub clasă se înțelege o oarecare abstractizare a totalității obiecte cine are set general proprietăți și au același comportament. Fiecare obiect în acest caz este considerat ca o instanță a clasei corespunzătoare. Obiectele care nu au exact aceleași proprietăți sau comportament nu pot fi, prin definiție, clasificate în aceeași clasă. Deși definiția de mai sus a unei clase poate fi rafinată luând în considerare alte concepte OOP, este generală și suficientă pentru efectuarea OOM.

O caracteristică importantă a claselor este posibilitatea organizării lor sub forma unei structuri ierarhice, care în aparență seamănă cu o schemă de clasificare a conceptelor de logică formală. În acest sens, trebuie menționat că fiecare concept din logică are o sferă și un conținut. Sfera de aplicare a unui concept se referă la toate celelalte concepte imaginabile pentru care conceptul original poate servi ca categorie sau parte definitorie. Conținutul unui concept este totalitatea tuturor semnelor și atributelor sale care disting acest concept de la toți ceilalți. În logica formală, legea relației inverse este cunoscută: dacă conținutul conceptului A este conținut în conținutul conceptului B, atunci sfera conceptului B este cuprinsă în sfera conceptului A.

Ierarhia conceptelor este construită după cum urmează. Conceptul sau categoria cea mai generală este considerată conceptul care are cel mai mare volum și, în consecință, cel mai mic conținut. Acesta este cel mai înalt nivel de abstractizare pentru o anumită ierarhie. Apoi concept general este specificat într-un fel, reducându-și astfel volumul și mărindu-i conținutul. Apare un concept mai puțin general, care în diagrama ierarhică va fi situat la un nivel sub conceptul inițial. Acest proces de concretizare a conceptelor poate fi continuat până când nivel inferior nu se va obține un concept a cărui specificare ulterioară este imposibilă sau impracticabilă.

Evident, dacă luăm un anumit model drept cel mai abstract concept pentru a atinge obiectivele OOM, atunci schema conceptuală a modelării orientate pe obiect poate fi reprezentată așa cum se arată în Fig. 4.5.

În prezent, limbajul care implementează abordări orientate pe obiect (inclusiv modelarea proceselor de afaceri) este limbajul UML (Limbaj de modelare unificat), este un limbaj de modelare vizuală de uz general, care este conceput pentru specificarea, vizualizarea, proiectarea și documentarea componentelor software, proceselor de afaceri și a altor sisteme. Acest limbaj poate fi folosit pentru a construi modele conceptuale, logice și grafice ale sistemelor complexe în diverse scopuri.

Descrierea formală a disciplinei folosind UML se bazează pe structura ierarhică a reprezentărilor modelului (vezi Fig. 4.5), constând din patru niveluri: 1) meta-metamodel; 2) megamodele; 3) modele; 4) obiecte.

Orez. 4.5.

Nivelul meta-metamodel formează baza inițială pentru toate vederile metamodelului. Scopul său principal este de a defini un limbaj pentru specificarea metamodelului. Meta-metamodelul definește limbajul formal însuși nivel inalt abstractizare și este descrierea sa cea mai compactă. În acest caz, un meta-metamodel poate specifica mai multe metamodele, realizând astfel potențiala flexibilitate de a include concepte suplimentare.

Un metamodel este o instanță sau o instanțiere a unui meta-metamodel. Sarcina principală a acestui strat este de a defini limbajul pentru specificarea modelului. Acest nivel este mai constructiv decât precedentul, deoarece are o semantică mai dezvoltată a conceptelor de bază.

Un model în contextul limbajului UML este o instanță a unui metamodel în sensul că orice model specific al unui sistem trebuie să folosească doar conceptele metamodelului, specificându-le în raport cu o situație dată. Acesta este un nivel pentru descrierea informațiilor despre un anumit domeniu. Cu toate acestea, dacă conceptele de limbaj UML sunt folosite pentru a construi un model, atunci este necesară coerența completă a conceptelor la nivel de model cu conceptele de limbaj la nivel de metamodel. Concretizarea conceptelor model are loc la nivelul obiectelor.

Din cel mai general punct de vedere, UML constă din două părți care interacționează: semantica limbajului și notația. Semantică definit pentru două tipuri de modele: modele structurale și modele comportamentale. Modelele structurale, cunoscute și sub denumirea de modele statice, descriu structura entităților sau componentelor (elementelor) unui sistem, inclusiv atributele și relațiile acestora. Modelele de comportament, numite uneori modele dinamice, descriu comportamentul sau funcționarea obiectelor sistemului, interacțiunea dintre ele, precum și procesul de schimbare a stărilor elementelor individuale și a sistemului în ansamblu. Trebuie remarcat că UML a fost creat în primul rând pentru a afișa aspectul comportamental al sistemelor. Notaţie a aceluiași limbaj este o specificație grafică pentru reprezentarea vizuală a semanticii limbajului.

În limbajul UML, toate reprezentările modelului sistem complex sunt înregistrate sub formă de desene grafice speciale - diagrame. Definit în termeni UML următoarele tipuri diagrame (Fig. 4.6):

• diagrama cazului de utilizare ( Diagrama de caz de utilizare);
• diagrama de clasa ( Diagrama de clasă);
• diagrame de comportament ( Diagrame de comportament);
• diagrame de implementare ( Diagrame de implementare).

Orez. 4.6.

Fiecare dintre aceste diagrame detaliază și concretizează o viziune diferită a unui model de sistem complex în termeni UML. Cu toate acestea, diagrama cazurilor de utilizare reprezintă cea mai generală model conceptual sistem complex, care este punctul de plecare pentru construirea altor diagrame. O diagramă de clasă este în esență un model logic care reflectă aspectele statice ale proiectării structurale a unui sistem.

Un rol deosebit îl au diagramele de comportament, concepute pentru a reflecta aspectele dinamice ale funcționării unui sistem complex. Acest tip de diagramă include:

• diagrama de stare ( Diagrama de stat);
• diagrama de activitate (Diagrama activității);
• diagrame de interacțiune (Diagrame de interacțiune):
• - Diagrama secvenței (Diagrama secvenței);
• - diagrama de cooperare (Diagrama de colaborare).

În cele din urmă, diagramele de implementare servesc pentru a reprezenta componentele fizice ale unui sistem complex. Acestea includ:

• diagrama componentelor (Diagrama componentelor);
• diagrama de implementare (Diagrama de implementare).

În literatura modernă, toate diagramele și obiectele enumerate la nivelul metamodelului sunt luate în considerare în detaliu.

Din punctul de vedere al modelării proceselor de afaceri, modelarea vizuală în IJML poate fi reprezentată ca un anumit proces de coborâre nivel cu nivel de la modelul conceptual cel mai general și abstract al sistemului sursă la cel logic și apoi la modelul fizic. a sistemului software corespunzător. Pentru a atinge aceste obiective, un model este mai întâi construit sub forma unei așa-numite diagrame de caz de utilizare (Utilizați diagrama de caz), care descrie scopul funcțional al sistemului sau, cu alte cuvinte, ceea ce va face sistemul în timpul funcționării sale. O diagramă de caz de utilizare este reprezentarea conceptuală inițială sau modelul conceptual al unui sistem în timpul procesului de proiectare și dezvoltare.

Dezvoltarea unei diagrame de caz de utilizare are următoarele obiective:

• determinați limitele generale și contextul domeniului subiectului modelat în etapele inițiale ale proiectării sistemului;
• formula Cerințe generale la comportamentul funcțional al sistemului proiectat;
• dezvoltarea unui model conceptual inițial al sistemului pentru detalierea ulterioară a acestuia sub forma unor modele logice și fizice;
• pregăti documentația inițială pentru interacțiunea dezvoltatorilor de sisteme cu clienții și utilizatorii săi.

Esența acestei diagrame este următoarea: sistemul proiectat este reprezentat ca un set de entități sau actori care interacționează cu sistemul folosind așa-numitele cazuri de utilizare. în care actor sau un actor este orice entitate care interacționează cu sistemul din exterior. Ar putea fi o persoană dispozitiv tehnic, program sau orice alt sistem care este capabil să servească drept sursă de influență asupra sistemului simulat, așa cum este determinat de dezvoltatorul însuși. La randul lui, utilizare caz servește pentru a descrie serviciile pe care sistemul le oferă actorului. Cu alte cuvinte, fiecare caz de utilizare definește un anumit set de acțiuni efectuate de sistem în timpul unui dialog cu actorul. Cu toate acestea, nu se spune nimic despre modul în care va fi implementată interacțiunea actorilor cu sistemul.

Obiectele principale ale diagramei cazurilor de utilizare sunt rezumate în tabel. 4.1.

Obiecte de diagramă de caz de utilizare UML de bază

Tabelul 4.1

Sfârșitul mesei. 4.1

	Desemnare	Scop
Relații într-o diagramă de caz de utilizare
relație de asociere		Asociația specifică trăsăturile semantice ale interacțiunii actorilor și cazurile de utilizare în model grafic sisteme
extinde relația		O relație de extensie definește relația dintre instanțele unui anumit caz de utilizare și un caz de utilizare mai general, ale cărui proprietăți sunt determinate pe baza modului în care aceste instanțe sunt combinate împreună.
Relația de generalizare relație de generalizare		O relație de generalizare este folosită pentru a indica faptul că un caz de utilizare A poate fi generalizat la cazul de utilizare B. În acest caz, opțiunea A va fi o specializare a opțiunii B
Relația de incluziune (include relația)		O relație de includere între două cazuri de utilizare indică faptul că un anumit comportament pentru un caz de utilizare este inclus ca o componentă constitutivă în secvența de comportamente a celuilalt caz de utilizare.

Un exemplu de diagramă de caz de utilizare este prezentat în Fig. 4.7.

Orez. 4.7.

Din perspectiva modelării prin simulare, diagramele de cazuri de utilizare și diagramele de comportament sunt de cel mai mare interes. Aceste diagrame sunt concepute pentru a descrie funcționalitatea (activitatea, mișcarea) componentelor sistemului. În plus, totalitatea acestor diagrame determină complet nivelul conceptual de descriere a unui sistem complex (model conceptual). În acest sens, este necesar să luăm în considerare aceste diagrame mai detaliat. Ca exemplu, să luăm departamentul de vânzări și marketing al unei anumite companii ca un sistem complex. Scopul principal al modelării acestui sistem este de a automatiza activitatea departamentului, adică. în crearea şi implementarea unui sistem informaţional de management al vânzărilor. Se presupune că nu există o automatizare a activităților de producție în departament.

Fără a intra într-o descriere a semanticii limbajului UML (este bine acoperită în literatura de specialitate), vom prezenta doar rezultatele analizei orientate pe obiecte prezentate în Fig. 4,8-4,12.

Este ușor să vezi că timpul este ca atributul cel mai important orice model comportamental este prezent în diagramele de mai sus doar indirect. Aceasta înseamnă că atunci când se analizează comportamentul (sau modificările stărilor), sunt posibile doar evaluări calitative precum „nu mai devreme de...”, „numai după...”, etc. Cu toate acestea, atunci când se analizează, de exemplu, o diagramă de stare (vezi Fig. 4.9), apar în mod firesc următoarele întrebări: „Cât de des ajung comenzile?”, „Cât timp durează procesarea?”, „Care este raportul dintre numărul de stații de lucru automatizate (AWS) și numărul de manageri?”, „Care ar trebui să fie performanța serverului?” etc. Este evident că este pur și simplu imposibil de a obține răspunsuri la aceste întrebări din diagramele date fără utilizarea modelării prin simulare.

Orez. 4.8.

Orez. 4.9.

Orez. 4.10.

Orez. 4.11.

Orez. 4.12.

În același timp, observăm că atunci când construim diagramele finale (diagramele componentelor și diagramele de implementare), este necesar să se indice în mod explicit caracteristicile tehnice ale hardware-ului, de exemplu, cum ar fi numărul de stații de lucru (AWS), viteza procesorului. , viteza de transmisie a rețelei, capacitatea de stocare etc. Este clar că indicatorii supraestimați pot duce la costuri nejustificate, iar cei subestimați pot duce la scăderea eficienței întregului sistem. Prin urmare, justificarea valorilor solicitate ale tuturor indicatorilor tehnici este posibilă numai pe baza rezultatelor modelării simulării.

Obiectele diagramei UML care modelează comportamentul sistemului pot fi asociate cu obiecte model de simulare. Cele mai importante diagrame care poartă informatie necesara, în acest caz, sunt o diagramă de caz de utilizare și o diagramă de stare. Relația dintre obiectele acestor diagrame și obiectele modelului de simulare este prezentată în tabel. 4.2.

Tabelul 4.2

Relația dintre obiectele diagramei UML și obiectele modelului de simulare

	Obiect Statechart	Obiect model de simulare

Utilizați obiectul diagramă de caz	Obiect Statechart	Obiect model de simulare

Analiza tabelului 4.2 arată că, în ciuda expresivității suficiente a limbajului UML pentru construirea unui model de simulare vizuală, instrumentele sale sunt în mod clar insuficiente. Obiectele abstracte date ale modelului de simulare constituie un model conceptual al funcționării departamentului de vânzări și marketing.

Există mai multe abordări ale modelării în dezvoltarea de software. Cele mai importante dintre ele sunt algoritmice (structurale) și orientate pe obiecte.

Metoda structurată reprezintă abordarea tradițională a creării de software. Blocul de bază este o procedură sau o funcție, iar atenția este acordată în primul rând problemelor de transfer al controlului și descompunerea algoritmilor mari în alții mai mici.

Cea mai modernă abordare a dezvoltării software este orientată pe obiecte. Aici blocul de bază este un obiect sau o clasă. În sensul cel mai general, un obiect este o entitate, de obicei extrasă din vocabularul unui domeniu sau soluție, iar o clasă este o descriere a unui set de obiecte similare. Fiecare obiect are o identitate (poate fi numit sau diferit diferit de alte obiecte), o stare (de obicei există unele date asociate cu obiectul) și un comportament (puteți face ceva cu el sau el însuși poate face ceva cu alte obiecte) .

Ca exemplu, luați în considerare o arhitectură de sistem de facturare pe trei niveluri, constând dintr-o interfață de utilizator, middleware și o bază de date. Interfața conține obiecte specifice - butoane, meniuri și casete de dialog. Baza de date este formata si din obiecte specifice, si anume tabele reprezentand entitati de domeniu: clienti, produse si comenzi. Middleware include obiecte precum tranzacții și reguli de afaceri, precum și reprezentări mai abstracte ale entităților de domeniu (clienți, produse și comenzi).

Dacă acceptați o viziune a lumii orientată pe obiecte, trebuie să răspundeți la o serie de întrebări. Ce structură ar trebui să aibă o arhitectură bună orientată pe obiecte? Ce artefacte ar trebui create în timpul proiectului? Cine ar trebui să le creeze? Și în sfârșit, cum să evaluăm rezultatul?

Vizualizarea, specificarea, construcția și documentarea sistemelor orientate pe obiecte este scopul limbajului UML.

Limbajele de modelare orientate pe obiecte au apărut de la mijlocul anilor '70 până la sfârșitul anilor '80, când cercetătorii, confruntați cu nevoia de a ține cont de noile capabilități ale limbajelor de programare orientate pe obiecte și de cerințele aplicațiilor din ce în ce mai complexe, au fost forțați pentru a începe dezvoltarea diferitelor abordări alternative ale analizei și proiectării.

Tehnologia de dezvoltare a sistemelor software, care se bazează pe paradigma reprezentării lumii înconjurătoare sub formă de obiecte care sunt instanțe ale claselor corespunzătoare, se numește analiză și proiectare orientate pe obiecte (OOAP) - OOA&D (Object-Oriented Analysis/ Proiecta). În cadrul acestei tehnologii, limbajul UML este un mijloc de reprezentare grafică a rezultatelor modelării nu numai a software-ului, ci și a unor clase mai largi de sisteme și aplicații de afaceri, folosind concepte orientate pe obiecte. În același timp, relația dintre conceptele de bază pentru modelele de nivel conceptual și fizic este asigurată în mod explicit și se realizează scalabilitatea modelului, ceea ce este deosebit de important pentru sistemele complexe cu scop multifuncțional.

Înșiși dezvoltatorii de limbaj îl definesc ca „un limbaj de modelare vizuală de uz general conceput pentru specificarea, vizualizarea, proiectarea și documentarea componentelor software, proceselor de afaceri și a altor sisteme”.

UML (English Unified Modeling Language - limbaj unificat de modelare) - limbaj descriere grafică pentru modelarea obiectelor în dezvoltarea de software. UML este un limbaj general, un standard deschis care folosește notația grafică pentru a crea un model abstract al unui sistem, numit model UML. UML a fost creat pentru a defini, vizualiza, proiecta și documenta în primul rând sisteme software. UML nu este un limbaj de programare, dar generarea de cod este posibilă pe baza modelelor UML. (wiki)

Dezvoltare rapidă în anii 1980.

Principal nu o procedură sau o funcție, dar un obiect.

Pentru diferite limbi, au fost create biblioteci de clase de obiecte standard care pot efectua acțiuni.

Au apărut fonduri programare vizuală(RAD), unde programatorul creează un program cu mouse-ul, iar codul programului este generat automat. Atenția programatorilor a trecut de la scrierea codului la etapele anterioare - analiza domeniului și proiectarea programului.

Au apărut metode de analiză orientată pe obiect și proiectare OOA/OOD. Acestea permit proiectarea sistemelor înainte ca codificarea să fie scrisă, astfel încât proiectarea să fie documentată. Folosind modelul, puteți corecta deficiențele fără niciun cost.

2 tipuri de diagrame:

1) Modele structurale

2) modele de comportament

Ulterior, UML a început să fie folosit nu atât pentru proiectarea IS, ci pentru analiza și reproiectarea sistemelor de alimentare cu energie.

Modelarea afacerilor folosind UML presupune construirea a două modele:

1) modelul precedent (întrebarea 16)

2) model obiect (analiza modelului structural, descris de structura externă a afacerii etc.) (întrebarea 17).

Model de afaceri precedent

La fel ca și pentru precedente și pentru actori, se disting conceptele de clasă și instanță. Clasa – descrie Caracteristici generale a unui anumit tip de actor, iar o instanță este caracteristicile unui anumit actor. O diagramă de caz de utilizare afișează de obicei clase de cazuri de utilizare și clase de actori. În plus, locația lor poate fi arbitrară. Actori aparținând diferite clase poate avea caracteristici comune sau obligații comune față de afacere. Este posibil să se introducă o clasă generalizată de actori care combină caracteristicile comune ale mai multor clase mai specifice. De exemplu, pentru clasele cumpărători de mobilă și cumpărători de computere, poate fi introdus un cumpărător de clasă comună. În acest caz, se stabilește o relație de generalizare între tipul generalizat de actori și unul mai specific.

Se stabilește o relație de comunicare între precedente și actori. Acestea modelează fluxurile de informații și materiale, de ex. schimb de precedente cu subiecte de mediu de natura materiala si informativa (date, documente, materii prime etc.).

Se întocmește o specificație pentru fiecare element al modelului. Specificația actorului specifică numele, stereotipul, descrierea și o listă de subdiagrame și documente asociate cu cazul de utilizare. Cel mai important document pentru descrierea cazurilor de utilizare este un document numit flux de evenimente. Acesta descrie un scenariu pentru implementarea cazurilor de utilizare ca o secvență de pași ai procesului.

Fiecare pas sau eveniment al unui caz de utilizare reprezintă o acțiune care transferă cazul de utilizare într-o stare nouă. La rândul său, noua stare a cazului de utilizare este un stimulent pentru a efectua următorul pas sau eveniment. Astfel, un precedent este considerat ca o succesiune de stări și evenimente.

Model de obiect de afaceri.

Un model de caz ilustrează funcțiile unei afaceri. Cu toate acestea, pentru a înțelege pe deplin afacerea, este nevoie de un model care să arate de către cine și cu ce ajutor sunt implementate precedentele. Modelul obiect dezvăluie structura internă a unei afaceri: ce tipuri de resurse sunt utilizate și cum interacționează acestea. Acest model se mai numește și modelul de analiză a afacerii. Conceptul principal al acestui model este conceptul de obiect.

Obiectele modelului de afaceri reprezintă persoanele implicate în executarea proceselor și diferitele tipuri de entități care sunt procesate sau create de afacere. Participanții la procese sunt numiți obiecte active, entități - pasive. Obiectele similare sunt grupate în clase, fiecare obiect specific fiind considerat ca o instanță a unei anumite clase. De exemplu, obiectele corespunzătoare anumitor angajați pot fi combinate în clasa „angajați”. Proprietatea unui obiect este descrisă folosind caracteristici numite atribute, iar compoziția atributelor este aceeași pentru întreaga clasă. Clasa „angajat” poate avea atribute: nume, vechime etc. Diferite obiecte vor avea valori diferite (care se pot schimba în timp). Comportamentul este reprezentat de un set de operații pe care le poate efectua un obiect. Exemplu de operațiuni de clasă „angajați”: acceptați o comandă, executați un acord, acceptați plata etc.

Tipuri de analiză a TA.

Există diferite clasificări ale tipurilor de analiză. Clasificarea în funcție de obiectul analizei ne permite să distingem:

1. Analiza mediului

~ Analiza macromediului (politic, economic, tehnologic)

~ Analiza micromediului (clienti, furnizori, competitori)

2. Analiza afacerii (Produse, Echipamente, Personal).

Analiza macromediului include analiza politicii fiscale, legislația muncii, studiul sistemului politic al regiunii, analiza celor mai recente realizări în producție etc.

Cele mai importante domenii ale analizei micromediului sunt studiul cerințelor clienților, analiza furnizorilor și partenerilor și analiza poziției competitive a companiei. În procesul de analiză a afacerii, se efectuează analiza proceselor de afaceri, tehnologiile de implementare a acestora, analiza produselor fabricate, analiza și evaluarea personalului.

Clasificări în conformitate cu stările analizate ale sistemului (actual, trecut, viitor) - vă permite să evidențiați analiza comparativă, retrospectivă și prognostică.

Clasificarea prin metode de analiză - ne permite să distingem două grupe principale:

· cantitativ (bazat pe măsurarea obiectivă și prelucrarea ulterioară a parametrilor cantitativi)

1) statistic (corelație, regresie, cluster)

2) economic (analiza factorilor deterministă, echilibru)

3) calculatoare ( programare liniară, analiza de sensibilitate etc.)

· analiză calitativă (pe baza opiniilor, judecăților subiective și evaluărilor experților). În acest caz, de regulă, se folosesc metode informale sau slab formalizate, precum: Metode de evaluare a exporturilor, metoda DELPHI, analiza morfologică, metoda scenariilor și metoda de construire a arborelui de decizie.