Modelare orientată pe obiecte bazată pe UML

Manualul conține: un scurt rezumat al limbajului UML - acea parte a acestuia care poate fi folosită ca bază pentru un limbaj pentru modelarea sistemelor dinamice complexe; 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.
Tehnologia tradițională de proiectare a sistemelor complexe, care nu implică modelarea preliminară pe computer, include următoarele etape principale: formularea cerințelor pentru un viitor sistem, dezvoltarea documentației de proiectare pe baza acestora, crearea 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știi de sistem sau automat folosind tehnologia computerizată, este deja o soluție de proiectare, nu rămâne decât să construim un model fizic conform acestei specificații, care va fi sistemul care se proiectează. Din păcate, nu este. Crearea unui sistem real care să îndeplinească specificațiile 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ă „manual”, slab 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 este posibilă generarea automată de software încorporat și specificații funcționale, iar aceste condiții sunt încă foarte departe de realitățile actuale.

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
Polimorfismul
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
Polimorfismul
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 instrumentele moderne de 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 unui sistem tehnic complex
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
Mai jos puteți cumpăra această carte la cel mai bun preț cu reducere cu livrare în toată Rusia.

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.

Majoritatea metodelor 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”, când fiecare bloc funcțional poate fi descompus în mai multe subfuncții etc., realizând astfel modul 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ă referirea la module software similare prin nume comune ( polimorfism) și reutilizați codul programului atunci când modificați software-ul. 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 adaptative procesele de afaceri(gestionarea fluxului de lucru, implementarea de interogări dinamice în depozitele de informații) - modele orientate pe obiecte. Cu toate acestea, în cadrul aceluiași IS, diferite clase de probleme pot necesita diferite tipuri de modele care descriu aceeași zonă cu probleme. În acest caz, combinate modele de domenii.

În tehnologia OOP, relația dintre date și algoritm este mai regulată: în primul rând, o clasă (conceptul de bază al acestei tehnologii) combină datele (variabilă structurată) și metode (funcții). În al doilea rând, modelul de interacțiune dintre funcții și date este fundamental diferit. O metodă (funcție) apelată pe un obiect, de obicei, nu apelează direct o altă funcție. În primul rând, el trebuie să aibă acces la un alt obiect (creează, obține un pointer, folosește un obiect intern în cel curent etc.), după care poate apela deja una dintre metodele cunoscute pe acesta. Astfel, structura programului este determinată de interacțiunea obiectelor din diferite clase între ele. De regulă, există o ierarhie a claselor, iar tehnologia OOP poate fi altfel numită programare „de la clasă la clasă”.

Orice programare se realizează conform unuia dintre cele patru principii:

principiul modularității

principiul „de la general la specific”

· principiul pas-cu-pas

· principiul de structurare

Programare modulară. Principiul modularității este formulat ca o cerință pentru dezvoltarea unui program sub forma unui set de module (funcții). În acest caz, împărțirea în module nu ar trebui să fie de natură mecanică, ci să se bazeze pe logica programului:

1. dimensiunea modulului trebuie să fie limitată;

2. modulul trebuie să efectueze o acţiune logic integrală şi completă;

3. modulul trebuie să fie universal, adică ori de câte ori este posibil, parametrizat: toate caracteristicile modificabile ale acțiunii care se execută trebuie transmise prin parametri;

4. Este indicat să treceți parametrii de intrare și rezultatul modulului nu prin variabile globale, ci prin parametri formali și rezultatul funcției.

O altă unitate, dar deja fizică a programului, este un fișier text care conține o serie de funcții și definiții ale tipurilor de date și variabilelor. Programarea modulară la nivel de fișier este capacitatea de a împărți textul complet al unui program în mai multe fișiere. Principiul modularității se aplică nu numai programelor, ci și datelor: orice set de parametri care caracterizează un obiect logic sau fizic trebuie reprezentat în program sub forma unei singure structuri de date (variabilă structurată).

Realizarea principiului modularității este biblioteca de funcții standard. De obicei, oferă un set complet de acțiuni parametrizate folosind structuri de date comune. Bibliotecile sunt programe similare, traduse independent și plasate în catalogul bibliotecii.

Programare de sus în jos. Proiectarea programului de sus în jos este aceea că dezvoltarea pornește de la o formulare generală informală a unei acțiuni de program în limbaj natural, „de la general la specific”: până la înlocuirea acesteia cu una dintre cele trei constructe formale ale limbajului de programare:

· succesiune simplă de acțiuni;

· constructe de selecție sau declarații if;

· construcţii de repetiţie sau ciclu.

În notația algoritmului, aceasta corespunde unei mișcări de la o structură externă (cuprinzătoare) la una internă (imbricată). Aceste modele pot conține, de asemenea, descrieri informale ale acțiunilor din părțile lor, adică designul de sus în jos este de natură pas cu pas. Să notăm principalele proprietăți ale acestei abordări:

· iniţial programul este formulat sub forma unei acţiuni informale în limbaj natural;

· se determină inițial parametrii de intrare și rezultatul acțiunii;

· pasul următor de detaliere nu modifică structura programului obținut în pașii anteriori;

· dacă în timpul procesului de proiectare se obțin acțiuni identice în diferite ramuri, atunci aceasta înseamnă că este necesară proiectarea acestei acțiuni ca o funcție separată;

· structurile de date necesare sunt proiectate concomitent cu detalierea programului.

Programare pas cu pas. Designul de sus în jos este de natură incrementală, deoarece implică înlocuirea unei formulări verbale de fiecare dată cu un singur construct lingvistic. Dar în procesul de dezvoltare a unui program, pot exista și alți pași legați de specificarea formulării verbale în sine în altele mai detaliate.

Faptul că acest principiu este evidențiat separat indică necesitatea de a preveni tentația de a detalia programul imediat de la început până la sfârșit și de a dezvolta capacitatea de a evidenția și de a concentra atenția asupra detaliilor principale, mai degrabă decât minore, ale algoritmului.

În general, proiectarea programului pas cu pas de sus în jos nu garantează un program „corect”, dar vă permite să reveniți la unul dintre pașii superioare de detaliu atunci când este detectat un blocaj.

Programare structurată. Cu rafinarea programului pas cu pas de sus în jos, structurile de date și variabilele necesare funcționării apar pe măsură ce trecem de la definițiile informale la constructele limbajului, adică procesele de detaliere a algoritmului și a datelor decurg în paralel. Cu toate acestea, acest lucru se aplică în primul rând variabilelor locale individuale și parametrilor interni. Din cel mai general punct de vedere, obiectul (în cazul nostru, datele) este întotdeauna primar în raport cu acțiunile efectuate cu el (în cazul nostru, algoritmul). Prin urmare, de fapt, modul în care un program organizează datele are un impact mai semnificativ asupra structurii algoritmului său decât orice altceva, iar procesul de proiectare a structurilor de date ar trebui să precedă procesul de proiectare a unui algoritm pentru procesarea acestora.

Programarea structurată este modulară, de sus în jos, proiectarea pas cu pas a algoritmului și a structurilor de date.

Abordarea orientată pe obiect a programarii include 3 componente principale:

· analiza orientată pe obiecte (OOA),

· proiectare orientată pe obiecte (OOD),

· programare orientată pe obiecte (OOP).

În orice disciplină de inginerie, designul se referă de obicei la o abordare unificată prin care căutăm modalități de a rezolva o problemă specifică, asigurându-ne că sarcina este îndeplinită. În contextul proiectării inginerești, scopul de proiectare este definit ca crearea unui sistem care

· satisface specificatii functionale date (eventual informale);

· în concordanță cu limitările impuse de echipament;

· satisface cerințele explicite și implicite de performanță și consum de resurse;

· satisface criteriile explicite și implicite de proiectare a produsului;

· satisface cerințele pentru procesul de dezvoltare în sine, cum ar fi durata și costul, precum și utilizarea unor instrumente suplimentare.

Proiectarea presupune luarea în considerare a cerințelor conflictuale. Produsele sale sunt modele care ne permit să înțelegem structura viitorului sistem, să echilibrăm cerințele și să conturăm o schemă de implementare.

Programul este un model numeric al sistemului în curs de proiectare (Fig. 1.3.1.)

Orez. 1.3.1.

Importanța construirii unui model. Modelarea este larg răspândită în toate disciplinele de inginerie, în mare parte pentru că implementează principiile de descompunere, abstractizare și ierarhie. Fiecare model descrie o anumită parte a sistemului luat în considerare, iar noi, la rândul nostru, construim noi modele pe baza celor vechi, în care suntem mai mult sau mai puțin încrezători. Modelele ne permit să ne controlăm eșecurile. Evaluăm comportamentul fiecărui model în situații normale și neobișnuite și apoi facem ajustările corespunzătoare dacă nu suntem mulțumiți de ceva.

Elemente de proiectare software. Este clar că nu există o metodă universală care să ghideze un inginer software de la cerințele unui sistem software complex până la implementarea acestora. Proiectarea unui sistem software complex nu înseamnă a urma orbește un set de rețete. Mai degrabă, este un proces gradual și iterativ. Și totuși, utilizarea unei metodologii de proiectare aduce o anumită organizare în procesul de dezvoltare. Inginerii de software au dezvoltat zeci de tehnici diferite, pe care le putem clasifica în trei categorii. În ciuda diferențelor lor, aceste metode au ceva în comun. În special, acestea sunt unite de următoarele:

· simboluri - limbaj de descriere a fiecărui model;

· proces - reguli de proiectare a unui model;

· instrumente - instrumente care accelerează procesul de creare a modelelor, și în care legile de funcționare a modelelor sunt deja întruchipate. Instrumentele ajută la identificarea erorilor în timpul procesului de dezvoltare.

O metodă bună de proiectare se bazează pe o bază teoretică solidă, permițând în același timp programatorului un anumit grad de libertate de exprimare.

Modele orientate pe obiecte. Cel mai util este să creați modele care să se concentreze pe obiectele găsite în domeniul însuși, formând ceea ce se numește o descompunere orientată pe obiecte.

Analiza și proiectarea orientate pe obiecte este o metodă care duce logic la descompunerea orientată pe obiecte. Folosind design orientat pe obiecte, sunt create programe care sunt flexibile și scrise într-o manieră rentabilă. Împărțind cu înțelepciune spațiul de stat, câștigăm mai multă încredere în corectitudinea programului nostru. Ca rezultat, reducem riscul atunci când dezvoltăm sisteme software complexe.

Deoarece construcția modelelor este extrem de importantă atunci când se proiectează sisteme complexe, proiectarea orientată pe obiecte oferă o selecție bogată de modele (prezentată în Fig. 1.3.2). Modelele de proiectare orientată pe obiecte reflectă ierarhia atât a claselor, cât și a obiectelor de sistem. Aceste modele acoperă întreaga gamă de decizii critice de proiectare care trebuie luate în considerare atunci când proiectăm un sistem complex și, astfel, ne inspiră să creăm modele care prezintă toate cele cinci atribute ale sistemelor complexe bine proiectate.

Orez. 1.3.2

OOP este o ideologie de programare bazată pe combinarea datelor și a procedurilor care pot lucra cu aceste date în mod colectiv, numite clase.

Esența OOP este utilizarea unui model de obiect familiar în viața de zi cu zi. Fiecare obiect are propriile sale proprietăți și puteți efectua acțiuni specifice acestuia. O clasă este un tip de obiect. Clasa descrie și implementează aceleași proprietăți și acțiuni. Un obiect, după înțelegerea noastră, va fi o variabilă, al cărei tip va fi un fel de clasă. Vom numi câmpurile unei clase proprietățile sale, iar metodele sale acțiunile care pot fi efectuate cu o instanță a acestei clase (obiect).

Ca exemplu de implementare a unei clase, să ne uităm la implementarea conceptului de carte folosind o clasă pentru a defini o reprezentare a cărții TBook și un set de funcții pentru lucrul cu variabile de acest tip:

PagesCount: întreg;

funcția CompareWithBook(OtherBook: TBook): întreg;

procedura ShowTitle;

constructor Create(NewTitle, New

Abilitățile cognitive umane sunt limitate; le putem depăși granițele folosind descompunerea, abstracția și ierarhiile.

Sistemele complexe pot fi studiate concentrându-se fie pe obiecte, fie pe procese; Există motive întemeiate pentru a folosi descompunerea orientată pe obiecte, în care lumea este privită ca o colecție ordonată de obiecte care, în procesul de interacțiune între ele, determină comportamentul sistemului.

Analiza și proiectarea orientate pe obiect este o metodă care utilizează descompunerea obiectelor; Abordarea orientată pe obiect are propria sa notație și oferă un set bogat de modele logice și fizice cu ajutorul cărora ne putem face o idee despre diferitele aspecte ale sistemului luat în considerare.

În prezent, conceptul de orientat pe obiecte modelare . Acest concept a fost rezultatul dezvoltării conceptualȘi ontologice modelare

Modelare conceptuală. Procesul al cărui scop este să identifice, să analizeze și să descrie entitățile domeniului tematici relevante pentru obiectivele sale, relațiile dintre ele, constrângerile pe care trebuie să le satisfacă, precum și comportamentul lor (în sensul modificărilor stării lor în timp). ), se numește modelare conceptuală. În esență, modelarea conceptuală reprezintă structura cunostintelor despre domeniul de subiect al sistemului, care sunt o condiție prealabilă necesară pentru calificare proiecta astfel de sisteme.

Modelare bazată pe ontologie. Conceptul de modelare conceptuală a fost clarificat și extins folosind conceptul ontologii. Ontologie este o specificație structurală a unui domeniu, o reprezentare formalizată a acestuia care include un vocabular (sau nume) de indicatori către termeni de domeniu și expresii logice care descriu modul în care se raportează între ei. O schimbare a terminologiei a dus la apariția unor concepte precum modelare ontologicăȘi inginerie ontologică.

Inginerie ontologică este procesul de proiectare și dezvoltare a ontologiilor. Este nucleul conceptului de „managementul cunoștințelor” și tehnologie ingineria cunostintelor, acoperind o gamă largă de metode – de la extragerea cunoştinţelor până la structurarea şi formalizarea acesteia.

Ingineria ontologică a apărut la mijlocul anilor 90 în marile corporații, unde problemele de prelucrare a informațiilor au devenit deosebit de acute și critice. A devenit evident că principalul blocaj în tehnologiile de guvernanță corporativă este prelucrarea cunoștințelor acumulate de specialiștii companiei, deoarece cunoștințele sunt cele care oferă un avantaj față de concurenți. Așa a apărut termenul „Knowledge Management” sau „Knowledge Management” (KM). KM este interpretat ca un set de procese care gestionează crearea, distribuția, procesarea și utilizarea informațiilor în cadrul unei întreprinderi.

Modelare orientată pe obiecte. Modelarea ontologică a stat și la baza metodologiilor modelare orientată pe obiecte(OOM), care se concentrează în primul rând pe creare mari si complexe sisteme, dezvoltarea lor colectivă, sprijinul activ ulterior în timpul funcționării și modificările periodice. OOM include:

· analiza orientată pe obiecte (OOA),

proiectare orientată pe obiecte (Object-Oriented Design, OOD),

· programare orientată pe obiecte (Object-Oriented Programming, OOP).

Metodologia OOA este o metodologie de analiză entitati real (sau ideal) din lume bazată pe concepte de clasă (as tip obiecte) și obiect (ca copie clasă). Obiectele și relațiile lor reprezentate în diagramele de clasă clasifică această metodologie ca modelare ontologică.

Pentru a implementa modele OO, un orientat pe obiecte limbaj de modelare unificat(Limbajul de modelare unificat, UML). Este folosit pentru a specifica, vizualiza și documenta componente ale sistemelor de informații orientate pe obiecte (software) în timpul dezvoltării.

Pentru a modela astfel de sisteme, UML oferă peste o duzină de tipuri de diagrame care modelează structura și funcționarea („comportamentul”) sistemelor obiect din diferite puncte de vedere. Modelarea începe cu analiza și modelarea domeniului sistemului software și dezvoltarea cerințelor utilizatorilor săi. Lista dezvoltată de cerințe este reprezentată de diagrame UML Use-Case. Structura sistemului este apoi modelată sub formă de diagrame de „structură”:

Diagrama de clasă,

Diagrama componentelor software (Componenta) și

Diagrama de implementare a componentelor software pe o platformă software și hardware (Deployment Diagram).

Proprietățile dinamice ale sistemului sunt modelate printr-un set de diagrame de tipuri „comportamentale” care definesc

Algoritmi pentru interacțiunea obiectelor software (diagrame secvențiale și de colaborare),

Comportamentul obiectelor discrete (diagramele Statechart),

Procese care au loc în sistemul obiect (Diagrame de activitate.

Ca exemplu în Fig. 36 prezintă cerințele utilizatorilor pentru o librărie electronică (sub formă de diagrame de caz de utilizare ale sistemului Rational Rose).

Fig 36. Diagramele de utilizare ale proiectului Rose eBookShop

Orez. 37. Diagrama claselor domeniului eBookShop Rose

Orez. 38. Model static complet al proiectului eBookShop Rose (sub forma unei diagrame de clasă UML)

Acest model se bazează pe modelul domeniului librăriei prezentat în Fig. 37. Un model static complet al unei librării electronice care satisface toate cerințele utilizatorilor este prezentat în Fig. 38.

Tehnicile de modelare orientate pe obiecte au revoluționat arhitectura sistemelor informaționale moderne. Pentru a înlocui arhitectura tradițională prelucrarea algoritmică a datelor a venit arhitectură bazată pe modele (obiect).(Model-Driven Architecture, MDA).

UML (Unified Modeling Language) este un limbaj de descriere grafică pentru modelarea obiectelor în domeniul dezvoltării 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 instrumentele de 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 codul să fie scris, astfel încât proiectarea să fie documentată. Folosind modelul, puteți corecta deficiențele fără costuri.

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 face o distincție între conceptele de clasă și instanță. O clasă descrie caracteristicile generale ale unui anumit tip de actor, iar o instanță descrie 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ă. Actorii aparținând unor clase diferite pot 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 natură materială și informațională (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 de familie, 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, concurenti)

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 sistemului analizat (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) computaționale (programare liniară, analiză 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.