Modelarea orientată pe obiect a sistemelor informaționale. Abordare orientată pe obiect a modelării sistemelor. Tipuri de analiză a TA

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 Programarea procedurală nu poate face față nici complexității tot mai mari a programelor și dezvoltării lor, nici nevoii de îmbunătățire a fiabilității acestora. Î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 aspect 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 conceptul general este specificat într-un fel, reducându-și astfel volumul și crescându-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 la cel mai de jos nivel se obține un concept, a cărui concretizare 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), care este un limbaj de modelare vizuală de uz general, care este conceput pentru specificarea, vizualizarea, proiectarea și documentarea componentelor software, procesele de afaceri și alte sisteme. Acest limbaj poate fi folosit pentru a construi modele conceptuale, logice și grafice sisteme 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 aceeași limbă este o specificație grafică pentru reprezentare vizuala semantica limbajului.

În limbajul UML, toate ideile despre modelul unui sistem complex sunt înregistrate sub formă de structuri 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. În același timp, o diagramă de caz de utilizare reprezintă cel mai general model conceptual al unui 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 componente fizice 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 de observat că timpul, ca atribut cel mai important al oricărui 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ă la construirea diagramelor finale (diagrame componente și diagrame de implementare), este necesar să se indice în mod explicit specificații hardware, de exemplu, cum ar fi numărul de stații de lucru (AWS), frecvența ceasului procesoare, viteza de transmisie a rețelei, capacitatea de stocare etc. Este clar că indicatorii umflaț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 obiectele modelului de simulare. Cele mai importante diagrame care conțin informațiile necesare în în acest caz, sunt diagrama de caz de utilizare și diagrama 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 chiar în sens general un obiect este o entitate, de obicei extrasă dintr-un vocabular de domeniu sau soluție, iar o clasă este o descriere a unui set de obiecte de același tip. 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”.

Cea mai evidentă formalizare a abordării sistemelor pentru studiul sistemelor complexe se realizează pe baza conceptului „ un obiect” ca element de bază al sistemului. Vom numi abordarea obiectului abordarea sistemelor, formalizat pe baza conceptului de obiect. Tehnologii construite pe baza abordarea obiectului, vom suna tehnologii orientate pe obiecte(OOT).

Modelare orientată pe obiecte(OOM) oferă un număr de avantaje semnificative:

1. Utilizarea unei abordări bazate pe obiect crește semnificativ nivelul de unificare a dezvoltării și adecvarea pentru reutilizare a modelelor deja create și dovedite.

2. Utilizarea OOM duce la construirea de sisteme bazate pe descrieri intermediare stabile, ceea ce simplifică procesul de efectuare a modificărilor. Acest lucru permite sistemului să se dezvolte treptat și nu duce la reproiectarea sa completă chiar și în cazul unor modificări semnificative ale cerințelor inițiale.

3. Modelele orientate pe obiecte sunt adesea mai compacte. Aceasta înseamnă nu numai o reducere a volumului de cod al programului, ci și o reducere a costului proiectului datorită utilizării dezvoltărilor anterioare, ceea ce are ca rezultat un câștig în cost și timp.

4. Un model de obiect reduce riscul dezvoltării sistemelor complexe prin pași de proiectare clar definiți și un proces integrat de creare a modelului care se extinde pe întreaga perioadă de dezvoltare, mai degrabă decât să devină un eveniment unic.

5. Modelul obiect vă permite să utilizați pe deplin capacitățile expresive ale limbajelor de programare moderne orientate pe obiecte.

Compararea definițiilor obiectelor din literatură a fost dezvăluită Puncte importante OOM:

Analiza obiectelor dezvăluie comportamentul și structura obiectelor;

Ambiguitatea în reprezentare se rezolvă prin atribuirea termenului conceptelor "Clasă", iar pentru obiecte fizice specifice termenul "un obiect".

Astfel, OOM implică suport pentru clase și instanțe de obiecte (statice și dinamice), încapsulare, moștenire și polimorfism. Conceptele de clasă și instanță sunt susținute fie explicit, fie implicit de aproape toate limbajele de simulare. În caz contrar, este destul de dificil să modelezi sisteme cu multe blocuri similare și imposibil să modelezi sisteme cu o structură dinamică.

Mai mult concepte complexe MOO sunt moștenirea și polimorfismul. Moştenire vă permite să transferați elemente ale descrierii unei clase existente în descrierea unei clase noi cu adăugarea altora noi. Polimorfismînseamnă posibilitatea de a utiliza o instanță a oricăreia dintre clasele sale derivate în loc de o instanță a unui bloc al unei clase de bază.

Un alt principiu al OOM este principiul modularitatea, care presupune împărțirea sistemului în părți numite module, fiecare dintre ele conținând grupuri de clase. Prezența unor biblioteci extinse de clase este un avantaj serios al unui anumit sistem de modelare de simulare. În acest caz, modelul poate fi construit mecanic din instanțe de clase standard cu setările lor parametrice. Pe baza bibliotecilor de clasă dezvoltate, se creează o bancă de blocuri pentru construcție modele de simulare diverse domenii.

Forma de reprezentare a obiectului cel mai bun modîndeplinește sarcinile de modelare de simulare, deoarece vă permite să potriviți în mod unic fiecare obiect, fenomen sau proces lumea reala iar relaţiile lor au un analog informaţional corespunzător.

În prezent, standardul recunoscut pentru modelarea sistemelor complexe este limbajul unificat de modelare UML ( Limbajul de modelare unificat). Limbajul UML a fost dezvoltat de companie Software raționalși partenerii săi. Este succesorul limbajelor de modelare bazate pe analiza obiectelor și metodele de proiectare ale lui Booch. OOSE Jacobson, OMT Rambo şi colab.

Modelele vizuale oferă o reprezentare clară a soluțiilor arhitecturale selectate și vă permit să înțelegeți sistemul studiat sau dezvoltat în întregime. Complexitatea sistemelor și proiectelor continuă să crească și, prin urmare, relevanța creării complexelor de modelare folosind tehnologia de modelare vizuală este în creștere.

Unul dintre puținele instrumente MI care utilizează diagrame de structură UML ca bază este AnyLogic, care este folosit în principal pentru a studia dinamica sisteme continue, prin utilizarea hărților de stare „hibride” și a obiectelor active UML-RT create special pentru reprezentare sisteme dinamiceîn timp real. Sistem Model Vision Studio este o versiune simplificată (de laborator) a sistemului AnyLogic.

Mihail Vasiliev, Igor Khomkov, Serghei Shapovalenko

În aproape toate etapele ciclului de viață al sistemelor 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 IP să rămână conditii de lucruî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 unui sistem informațional corporativ î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. Cel mai des sunt utilizate prototipuri pe bancă și construirea modelelor computerizate ale circuitelor integrate.

Î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ă pentru prezentarea grafică a rezultatelor în sistemul OPNET.) Să ne oprim asupra unuia dintre aceste sisteme și asupra abordării implementate în acesta în mai multe detaliu.

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.

Etapa finală a procesului de descompunere este determinată de cel mai scăzut nivel de abstractizare aplicat î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 computerul NS7000, echipat cu mai multe plăci de rețeași efectuarea de rutare software poate fi considerată 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ă, împărțind sistemul studiat în funcție de principiile sale active, adică procesele care au loc în el în într-o anumită ordine, și orientat pe obiecte, care vă permite să împărțiți sistemul studiat în clase de abstracțiuni 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 nu sunt acest moment sunt nesemnificative sau distrag atenţia”*1. Deci, într-o situație, când descrieți un computer, este suficient să îl definiți ca sursă de trafic, fără a intra într-o descriere detaliată a arhitecturii; în 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ță viata reala. 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 încă unul. clasa suplimentara, ale căror obiecte pot fi situate și 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 sau receptori de trafic și sunt, de asemenea, folosite pentru a modela sisteme software complexe care țin 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, au fost introduse o serie de proprietăți suplimentare, cum ar fi prezența și parametrii magistralei interne, care vă permite să simulați trecerea internă a traficului între porturile de intrare și de ieșire. a 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)

Obiecte din această clasă care vă permit să creați reprezentări abstracte pentru rețele globale, moștenește și 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 vă permit să descrieți cel mai flexibil volumul de lucru al rețelei și comportamentul surselor de trafic în cadrul modelului. 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 gazdă, dar în contextul interacțiunii cu subsistemul disc pentru 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 complex distribuit sisteme softwareși impactul acestora asupra infrastructurii de rețea existente.

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ă modelăm o rețea locală care folosește o metodă de acces aleatoriu cu detectarea transportatorului și detectarea coliziunilor (CSMA/CD, o clasă de conexiuni cu acces multiplu), totuși, standardul stratului de legătură propus de producătorul de echipamente de rețea este oarecum diferit de IEEE 802.3 „nativ”. 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.

Acest lucru arată că parametrizarea oferă oportunități ample de extindere a bibliotecii de bază de obiecte, permițând dezvoltatorului modelului să ia decizii mai flexibile.

Puteți extinde setul de bază de clase prin 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ă unui dezvoltator i se dă sarcina de a construi 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 descriere standard Busul COMNET III este descris de doi parametri: debitului si frecventa. 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 autobuzul ca un dispozitiv separat - o 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.

Diferența fundamentală dintre abordarea funcțională și cea a obiectelor constă în modul în care sistemul este descompus. Abordarea orientată pe obiect folosește descompunerea obiectelor, unde structura statică este descrisă în termeni obiecte și conexiuniîntre ele, iar comportamentul sistemului este descris în termeni mesagerieîntre obiecte. Scopul metodologiei este de a construi un model de afaceri al organizației, permițând trecerea de la model cazuri de utilizare la un model care definește obiectele individuale implicate în implementarea funcțiilor de business.

Baza conceptuală este modelul obiect, care este construit ținând cont de următoarele principii:

• abstractizare;
• încapsulare;
• modularitatea;
• ierarhie;
• tastare;
• paralelism;
• durabilitate.

Noțiuni de bază abordare orientată pe obiecte sunt obiect și clasă.

Obiect - un obiect sau fenomen care are un comportament clar definit și are o stare, comportament și personalitate. Structura și comportamentul obiectelor similare determină clasa lor comună. O clasă este un set de obiecte legate de o structură și comportament comun. Următorul grup de concepte importante ale abordării obiectului sunt moștenirea și polimorfismul. Concept polimorfism poate fi interpretat ca abilitatea unei clase de a aparține mai multor tipuri. Moştenireînseamnă construirea de noi clase bazate pe cele existente, cu posibilitatea de a adăuga sau de a suprascrie date și metode.

O calitate importantă a abordării bazate pe obiecte este consistența modelelor de activitate ale organizației și a modelelor sistemului informațional proiectat de la etapa formării cerințelor până la etapa de implementare. Folosind modele de obiecte, se poate urmări maparea entităților reale din domeniul de subiect modelat (organizație) în obiecte și clase ale sistemului informațional.

Majoritate metode existente abordare orientată pe obiecte include limbaj de modelareși o descriere a procesului de modelare. Proces este o descriere a pașilor care trebuie urmați la dezvoltarea unui proiect. La fel de limbaj de modelare abordarea obiect folosește un unificat limbaj de modelare UML, care conține un set standard de diagrame pentru modelare.

O diagramă este o reprezentare grafică a unui set de elemente. Cel mai adesea, este descris ca un graf conectat cu vârfuri (entități) și muchii (relații) și reprezintă o anumită proiecție a sistemului.

Abordare orientată pe obiecte are urmatoarele avantaje:

• Descompunerea obiectelor face posibilă crearea unor modele mai mici prin utilizarea mecanismelor comune care asigură economiile necesare în mijloace expresive. Utilizarea abordării bazate pe obiect crește semnificativ nivelul de unificare și reutilizare a dezvoltării, ceea ce duce la crearea unui mediu de dezvoltare și la trecerea la crearea modelului de asamblare.
• Descompunerea obiectelor vă permite să evitați crearea de modele complexe, deoarece presupune o cale evolutivă de dezvoltare a modelului bazată pe subsisteme relativ mici.
• Modelul obiect este natural deoarece este axat pe percepția umană asupra lumii.

Spre dezavantaje abordare orientată pe obiecte includ costuri mari de pornire. Această abordare nu oferă beneficii imediate. Efectul utilizării sale se simte după dezvoltarea a două sau trei proiecte și acumularea de componente reutilizabile. Diagramele care reflectă specificul abordării obiectului sunt mai puțin clare.

Compararea metodelor existente

ÎN modele funcționale(DFD- diagrame de flux de date, diagrame SADT) principalele componente structurale sunt funcții (operații, acțiuni, lucrări), care sunt interconectate în diagrame fluxuri de obiecte.

Avantaj incontestabil modele funcționale este implementarea abordare structurală la proiectarea IC bazată pe principiul „de sus în jos”, unde fiecare bloc funcţional pot fi descompuse în multe subfuncții etc., realizând astfel un modular Design IC. Pentru modele funcționale caracterizat prin rigoare procedurală a descompunerii IS și claritatea prezentării.

La abordare funcțională Modelele de date obiect sub formă de diagrame ER „obiect – proprietate – relație” sunt dezvoltate separat. Pentru a verifica corectitudinea modelării domeniului subiectului, se stabilesc relații unu-la-unu între modelele funcționale și obiectele.

Principalul dezavantaj modele funcționale este că procesele și datele există separat unele de altele - pe lângă descompunerea funcțională, există o structură de date care se află în fundal. În plus, condițiile pentru efectuarea proceselor de prelucrare a informațiilor, care se pot schimba dinamic, nu sunt clare.

Dezavantaje enumerate modele funcționale filmat în modele orientate pe obiecte, în care componenta principală de formare a structurii este o clasă de obiecte cu un set de funcții care pot accesa atributele acestei clase.

Clasele de obiecte sunt caracterizate printr-o ierarhie de generalizare care permite moştenire nu numai atributele (proprietățile) obiectelor dintr-o clasă superioară de obiecte la o clasă inferioară, ci și funcțiile (metode).

În cazul moștenirii funcțiilor, puteți face abstracție de la implementarea specifică a procedurilor ( tipuri de date abstracte), care diferă pentru anumite subclase de situații. Acest lucru face posibilă contactul similar module software De nume comune (polimorfism) și implementați reutilizare codul programului la modificarea software-ului. Astfel, adaptabilitatea sistemelor orientate pe obiecte la schimbări în domeniul subiectului comparativ cu abordare funcțională mult mai înalt.

Cu o abordare orientată pe obiecte, principiul se schimbă și el Design IC. Mai întâi se identifică clase de obiecte, iar apoi, în funcție de posibilele stări ale obiectelor (ciclul de viață al obiectelor), se determină metode de procesare (proceduri funcționale), care asigură cea mai bună implementare a comportamentului dinamic al sistemului informațional.

Pentru abordare orientată pe obiecte au fost dezvoltate metode grafice de modelare a domeniului subiectului, generalizate în limbajul unificat de modelare UML. Cu toate acestea, în ceea ce privește claritatea prezentării modelului către utilizatorul client, modelele orientate pe obiecte sunt în mod clar inferioare modelelor funcționale.

Atunci când alegeți o metodologie pentru modelarea unui domeniu, gradul de dinamism al acesteia este de obicei folosit ca criteriu. Pentru sarcini mai reglementate, modelele funcționale sunt mai potrivite, pentru cele mai adaptive procesele de afaceri(gestionarea fluxului de lucru, implementare interogări dinamice la depozitele de informaţii) - modele orientate pe obiecte. Cu toate acestea, în cadrul aceluiași IS, pot necesita diferite clase de sarcini tipuri diferite modele care descriu aceeași zonă cu probleme. În acest caz, combinate modele de domenii.