Tema 5. Bazele Modelării Sistemelor Informaționale [PDF]

Zitiervorschau

Capitolul II. Metode de modelare și analiză a spațiului funcțional

Tema 5. Bazele Modelării Sistemelor Informaționale Toate modelele sunt greșite, dar unele modele sunt mai greșite Proiectul unui sistem informațional reprezintă planul de lucru în realizarea sistemului şi care are la bază un model, care reduce sistemul informatic la elementele de bază a acestuia asigurînd controlul pe parcursul realizării proiectului. Acest model permite monitorizarea şi coordonarea participanţilor în realizarea proiectului prin analiza şi verificarea executării proiectului precum şi elaborarea documentaţiei proiectului. Modelarea este una dintre cele mai importante tehnici de concepere a sistemelor informatice. Modelarea se focusează pe impactul schimbărilor. 5.1. Noțiuni generale 5.1.1. Noțiuni de modelare

Sub modelare se înțelege: - cartografierea oricărei situații, a prcesului sau a managementului; Definiție - Modelarea - este o metodă de cercetare științifică a fenomenelor proceselor, obiectelor, dispozitivelor sau sistemelor (obiecte de cercetare), bazată pe construcția și studiul modelelor pentru a obține noi cunoștințe, a îmbunătăți caracteristicile obiectelor de cercetare sau a le gestiona. Definiție - Model de antrepriză - este o reprezentare computațională a structurii, activităților, proceselor, informațiilor, resurselor, comportamentului oamenilor, obiectivelor și constrângerilor unei afaceri, guvern sau alte unități social -economice. Scopurile modelării: - Reprezentarea Vizuală a unui system, - Specificarea structurii sistemului şi/sau a comportării, - Oferirea unui model de referință care să ajute la construcţia unui sistem informațional și nu numai, - Documentarea deciziilor luate. Modelul de referință reprezintă aprobarea unei viziuni foarte atractive – care promite o calitate mai mare a sistemelor informaționale la costuri mai mici. Această viziune este însoțită de două afirmații pivot: - pe de o parte, modelele de referință sunt destinate să ofere descrieri adecvate ale unui domeniu de aplicație. - pe de altă parte, modelele de referință au ca scop furnizarea de planuri pentru o proiectare distinctă a sistemelor informaționale și a setărilor organizaționale aferente. Modelele de referință sunt modele conceptuale.

Un model conceptual este o abstractizare care subliniază termenii sau conceptele de bază, care caracterizează un domeniu de aplicație, neglijând în același timp aspecte tehnice legate de implementarea sistemelor software corespunzătoare. Modelele conceptuale sunt considerate – descrieri a unei antreprize generale/felie de realitate care corespund direct și firesc propriilor conceptualizări ale obiectului acestor descrieri. Totuși, descrierea realității este doar o fațetă a unui model conceptual. De obicei, un model conceptual este o (re) construire a descrierii unui domeniu care include și elemente prescriptive. Aceasta este din două motive: - În primul rând, de multe ori nu va avea sens să lăsați un domeniu așa cum este, dacă se dorește încurajarea introducerii unor sisteme software eficiente. În schimb, de obicei, va fi necesară reorganizarea tiparelor de acțiune, cum ar fi procesele de afaceri. - În al doilea rând, dezvoltarea software-ului trebuie să țină seama de limitările limbajelor la nivel de implementare. Pentru a susține o transformare perfectă a modelelor conceptuale în documente la nivel de implementare, nu este recomandabil să neglijăm complet conceptele utilizate la nivel de implementare. Există un consens larg potrivit căruia modelarea conceptuală este esențială pentru profesioniști la dezvoltarea sistemelor informatice. Dar numai dacă modelele conceptuale sunt de înaltă calitate ei înșiși, vor încuraja implementarea de software de înaltă calitate. Prin urmare, evaluarea calității unui model conceptual este un subiect important în crearea unui sistem informațional. Cu privire la proiectarea sistemelor de informaționale, au existat mai multe încercări de ghidare a evaluării calității modelului. În evaluarea calității modelului este necesar utilizarea unei abordări cu mai multe criterii pentru conceptualizarea noțiunii de calitate și sunt sugerate șase criterii de evaluare: -

simplitate, înțelegere, flexibilitate, completitate, integrare, implementabilitate

Principiile modelării La modelare trebuie de ținut cont cel puțin de următoarele principii: - modelul determină soluţia finală, - modelarea pe mai multe niveluri de detaliere, - reflectarea realității - modelul bun are o corespondență cel mai apropiată de realitate, - modelare din mai multe puncte de vedere - pentru a avea o corespondență mai apropiată de realitate nu e suficient un singur model Metoda modelării are următoarele funcții: - funcţia descriptivă, fiind capabilă să descrie riguros unele fenomene în scopul unei mai bune înţelegeri a desfăşurării lor. - funcţia operativă, deoarece aplicarea metodei deschide noi căi de cercetare, permiţând elaborarea unor noi tehnici experimentale. - funcția predictivă, permiţând în multe cazuri imaginarea evoluţiei ulterioare a sistemului. 5.1.1. Noțiuni de model

Modelele sunt un instrument fundamental în dezvoltarea sistemelor computerizate de orice fel: scopul lor esențial este de a susține înțelegerea și raționamentul uman în dezvoltare. Modelul - este un obiect sau imagine materială mentală sau condițională (ipoteză, idee, abstractizare, imagine, descriere, diagramă, formulă, desen, plan, hartă, diagramă de flux, note etc.) care simplifică proprietățile cele mai esențiale ale obiectului de cercetare. Orice model este întotdeauna mai simplu decât un obiect real și afișează doar o parte din cele mai semnificative caracteristici, elemente de bază și relații – deci nu este perfect. Din acest motiv, pentru un obiect de studiu trebuie să avem mai multe modele din diferite viziuni. Tipul modelului depinde de obiectivul ales de modelator. Modelul este - o copie redusă a unui obiect și poate servi drept model de referință- modelul este creat pentru studii mai aprofundate și analize mai detaliate, deoarece modelul reflectă structura și interrelațiile uniui obiect. - modelul permite o analiză detaliată pe niveluri și componente a unui sistem sau a unui obiect complex. 5.1.2. Clasificarea modelelor.

Modelele pot fi clasificate după: - metoda de realizare; - domeniul de utilizare (educațional, experimental, științific și tehnic, jocuri, imitații); - ramura cunoașterii (fizice, chimice, geografice, istorice, sociologice, economice, matematice); - conform metodei de prezentare a modelului (fig.5.1.) (materială și informativă). Materiale - altfel   poate fi numit subiect. Ele percep proprietățile geometrice și fizice ale originalului și au întotdeauna o întruchipare reală Informaționale - Ele se bazează numai pe informații. Un model informațional este o colecție de informații care caracterizează proprietățile și condițiile unui obiect, proces, fenomen, precum și relația acestuia cu lumea exterioară. Verbale - model de informație sub formă mentală sau colocvială. Semantice - model construit prin semne adică, mijloace a unui limbaj formal. Computerizatr - un model construit cu mijloace software. NeComputerizatr – cu alte mijloce și tehnici.

Fig.5.1. Clasificare conform metodei de prezentare a modelului La etapa de proiectare se construiesc modele care redau aspecte structurale și aspecte comportamentale cum ar fi: - arhitectura sistemului, - distribuția proceselor în sistem, - sincronizarea proceselor, - identificarea cerințelor pe subsisteme, - Identificarea stărilor și tranzițiile între stări. - modele ce descriu realizarea fizică a sistemului, componente echipamente și componente program. În procesul de elaborare a sistemelor informaționale sunt evidențiate cel puțin patru tipuri de modele (fig.5.2.a,b.) ce corespund punctelor de viziune a specialiștilor organizației Conform acestor viziuni sunt create modele: - Modelul organizațional - Modelul funcțional - Modelul proceselor - Modelul datelor

Modelul organizațional Modelul organizațional

Modelul datelor

Modelul proceselor

Modelul funcțional Modelul datelor

Modelul proceselor

Modelul funcțional

a

b Fig.5.2. Patru tipuri de modele

Concepte de bază în modelare Sub modelare se înțelege: - cartografierea oricărei situații, a prcesului sau a managementului; Modelarea este - o metodă de cercetare științifică a fenomenelor, proceselor, obiectelor, dispozitivelor sau sistemelor (obiecte de cercetare), bazată pe construcția și studiul modelelor pentru a obține noi cunoștințe, a îmbunătăți caracteristicile obiectelor de cercetare sau a le gestiona. Metoda modelării îndeplineşte câteva funcţii: - funcţia descriptivă, fiind capabilă să descrie riguros unele fenomene în scopul unei mai bune înţelegeri a desfăşurării lor. - funcţia operativă, deoarece aplicarea metodei deschide noi căi de cercetare, permiţând elaborarea unor noi tehnici experimentale. - Funcția cu caracter predictiv, permiţând în multe cazuri imaginarea evoluţiei ulterioare a sistemului. În funcție de natura sistemului, unele modele pot avea diferite grade de importanță. De exemplu, pentru unele sisteme, aspectele structurale și funcționale sunt mai importante, iar pentru altele, aspectele temporare. Când construim un model, suntem ghidați de anumite metode. O metodă oferă o abordare de repetare care vă permite să obțineți rezultate fiabile de mai multe ori. • În toate domeniile de cunoaștințe, sunt utilizate metode mai mult sau mai puțin complexe și mai mult sau mai puțin formalizate. De exemplu: - bucătarii folosesc rețete de bucătărie, - Muzicienii respectă regulile compoziției. - constructorii respectă cerințele arhitecturale ... Modelele sunt constituite din elemente de modelare, care sunt concepte de bază a metodei pentru reprezentarea sistemelor sau fenomenelor. Elementele de modelare sunt de obicei simboluri grafice, adică un limbaj de modelare. Metoda definește regulile de aplicare care descriu coordonarea diferitelor puncte de vedere, lansarea acțiunilor, simplificarea sarcinilor și separarea responabilităților. Principalele obiective ale modelării sistemelor informatice sunt: - reprezentarea vizuală ca mijloc de a facilita comunicarea și înțelegerea; - perfecționarea prin construirea de modele precise, lipsite de ambiguitate și complete; - documentarea cerințelor, deciziile de proiectare și modalitățile de realizare a acestora. Sunt utilizate diferite principii pentru modelarea și proiectarea sistemelor care demonstrează caracteristicile dorite ale ciclului de viață, cum ar fi: - flexibilitate, - receptivitate, - scalabilitate, - mentenabilitate,

-

ușurință de utilizare, integrare, performanță și implicarea factorului uman în activitățile de dezvoltare a ciclului de viață Clasificare modele după domeniul de utilizare

Modele Școlarizare

Jocuri

Experimentale

De imitare

Cercetare Fig.5.3. Clasificare modele după domeniul de utilizare Școlarizare - vizual   manuale, simulatoare  Jocuri - economic, sport, jocuri de afaceri Experementale - copii (mașină într-un tunel de vânt) De imitare - nu  pur și simplu reflectă realitatea, dar o imită. Această metodă de modelare se numește încercare și eroare Cercetare - modelarea funcțională, modelarea proceselor stand pentru verificarea echipamentelor Un model este o imagine simplificată, aproximativă, care reflectă proprietățile cele mai semnificative (din punct de vedere al obiectivului de modelare) ale originalului. - Corespondența modelului cu originalul este denumită adecvarea modelului. - Adecvarea include cerințele de exhaustivitate și acuratețe (corectitudine). Cerințele trebuie îndeplinite în măsura în care este suficient pentru atingerea obiectivului. - Pentru același obiect, se pot construi multiple modele diferite care identifică obiective diferite după cum este redat mai jos: - Modelele cognitive (explicative) reflectă obiectele existente. - Modelele de reglementare (pragmatice) reflectă obiectele care trebuie puse în aplicare. - Modelele statice nu iau în considerare factorul ”timpul”. - Modelele dinamice reflectă schimbările unui obiect care au loc în timp. - Modelele materiale sunt construite din obiecte reale. - Modelele abstracte sunt modele ideale realizate prin gândire, conștiință. - Modelele declarative reflectă proprietățile, structurile, condițiile obiectelor. - Modelele procedurale reflectă cunoștințe procedurale, operaționale. - Modele deterministe reflectă procesele și fenomenele care nu sunt supuse aleatoriei. - Modele Stochastic - reflectă procesele aleatorii descrise de caracteristicile probabilistice și legile statistice. - Modele formalizate pot să nu aibă o interpretare semantică. - Modele semantice se păstrează semantica obiectului modelat. Această varietate de modele necesită metode și limbaje adecvate pentru elaborarea unui model.

5.1.1. Limbaje pentru Descrierea modelului

Calitatea unui model conceptual depinde de caracterul adecvat al limbajului de modelare utilizat Prin urmare, implicit trebuie să ținem cont și de calitatea limbajelor de modelare. Limbajele pot fi diferențiate în trei categorii: - abordări care se concentrează pe cerințele formale, - abordări care se concentrează pe aspecte pragmatice privind utilizarea unui limbaj specifi de modelare și - abordări care utilizează ontologii. În Ingineria Software, scopul pe care trebuie să-l servească un limbaj de modelare este limitat în principal la aspectele formale: Acesta ar trebui să ofere o bază adecvată pentru implementarea produselor software corect și fiabil. Prin urmare, proprietățile formale precum completitudinea, simplitatea și corectitudinea au o importanță deosebită pentru evaluarea limbajului. În plus, analiza limbajelor de modelare în informatică este uneori legată de puterea lor expresivă, de exemplu. - Limbaj analitic, - Limbaj grafic - Limbaj numeric, - Limbaj logic, - Limbaj teoretic, - Limbaj lingvistic, În studiul nostru o să ne oprim mai detaliat la lombaje grafice de modelare Limbaje grafice. - Cu aceste limbaje sunt create Modele grafice: diagrame, scheme, grafice, desene - vizual. - La modelarea grafică se utilizează un sistem de Notare - un sistem de simboluri (semne) și regulile de utilizare a acestora, adoptate într-o metodologie specifică. Cerințe față de notificări: -   simplitate - un semn simplu este de preferat celui complex; -   vizibilitate - cel puțin o asemănare îndepărtată cu originalul; -   individualitate - o diferență suficientă față de alte desemnări; -   unambiguity - este imposibil să desemnați obiecte diferite cu un singur simbol; -   certitudine - reguli clare de utilizare a modelului; -   tradiții ținând cont de tradițiile consacrate. 5.2. Metode de modelare a sistemului informațional a antreprizei Proiectul unui sistem informațional reprezintă planul de lucru în realizarea sistemului şi care are la bază un model, care reduce sistemul informatic la elementele de bază a acestuia asigurînd controlul pe parcursul realizării proiectului. Mmodelare permite monitorizarea şi coordonarea participanţilor în realizarea proiectului prin analiza şi verificarea executării proiectului precum şi elaborarea documentaţiei proiectului. Alegerea instrumentelor de modelare influenţează esenţial maniera de abordare a problemelor şi soluţionarea lor de către sistemul informațional. Dacă alegerea instrumentelor de modelare este reuşită atunci aceasta duce la cele mai bune soluţii ale sistemului informațional,

În caz că alegerea instrumentelor de modelare este nereușită atunci poate duce la eronarea sau abaterea atenţiei dezvoltatorilor de sisteme informaționale de la cerinţele fundamentale ale sistemului. Cele mai reuşite instrumente de modelare sunt acelea care oferă proiectantului sistemului informatițional posbilitatea de a alege nivelul de detaliere la care se ajunge în realizarea sistemelor, subsistemelor, sarcinilor în dependenţă de ceea ce urmăreşte proectantul 5.2.1. Metode orientate pe obiect În metodele obiect orentate principalul element structural este obiectul. În sisteme informaționale, un obiect este o structură care combină date și proceduri. În modelul de afaceri, obiectele sunt participanți la procesul de afaceri (obiecte active) și obiecte pasive (materiale, documente) peste care obiectele active efectuează acțiuni. Principalele concepte care stau la baza modelării orientate pe obiecte sunt: 1. Abstractizarea este una dintre căile fundamentale prin care oamenii ajung să înţeleagă şi să cuprindă complexitatea. Ea scoate în evidenţă toate detaliile semnificative pentru perspectiva din care este analizat un obiect, suprimând sau estompând toate celelalte caracteristici ale obiectului. Obiectele şi nu algoritmii sunt blocurile logice fundamentale: - fiecare obiect este o instanţă a unei clase. clasa este o descriere a unei mulţimi de obiecte caracterizate prin structură şi comportament similare; clasele sunt legate între ele prin relaţii de moştenire. 2. Încapsularea este conceptul complementar abstractizării. Încapsularea este procesul de compartimentare a elementelor care formează structura şi comportamentul unei abstracţiuni; încapsularea serveşte la separarea interfeţei „contractuale” de implementarea acesteia. Din definiţia de mai sus rezultă că un obiect este format din două părţi distincte: - interfaţa (protocolul); - implementarea interfeţei. Abstractizarea defineşte interfaţa obiectului, iar încapsularea defineşte reprezentarea (structura) obiectului împreună cu implementarea interfeţei. 3. Modularizarea constă în divizarea sistemului într-un număr de subunităţi care pot fi elaborate separat, dar care sunt interconectate între ele. Gradul de interconectare trebuie să fie cât mai mic, pentru ca modificările aduse unui subsistem să afecteze cât mai puţine alte subsisteme. Pe de altă parte, clasele care compun un subsistem trebuie să aibă legături strânse între ele pentru a justifica gruparea lor. 4) Ierarhizarea reprezintă o ordonare a abstracţiunilor. Cele mai importante ierarhii în paradigma obiectuală sunt: - ierarhia de clase (relaţie de tip is a); - ierarhia de obiecte (relaţie de tip part of). Moştenirea defineşte o relaţie între clase în care o clasă foloseşte structuri şi comportamente definite în una sau mai multe clase (după caz vorbim de moştenire simplă sau multiplă).

Metode orientate pe obiect

Fig.5.4. Metode orientate pe obiect -

Printre metodele orientate obiect putem menționa: Booch’93 G. Bucha, OMT J. Rumbach OOSE A. Jacobson UML (Unified Modeling Language) - bazat pe Booch’93, OMT, OOSE

Fiecare dintre aceste metode este axată pe susținerea etapelor individuale al metodei Analiză și Proectare Obiect Orientată (OOAP). De exemplu, metoda OOSE conținea instrumente pentru prezentarea cazurilor de utilizare care sunt esențiale în faza de analiză a cerințelor din procesul de proiectare a aplicației de afaceri. Metoda OMT-2 este cea mai potrivită pentru analiza proceselor de prelucrare a datelor în sistemele informaționale. Metoda Booch'93 este utilizată pe scară largă la etapele de proiectare și dezvoltare a diferitelor sisteme software. Principalul element structural este obiectul. În proectare, un obiect este o structură care combină date și proceduri. În modelul de afaceri, obiectele sunt participanți la procesul de afaceri (obiecte active) și obiecte pasive (materiale, documente) peste care obiectele active efectuează acțiuni. 5.2.1.1. Limbajul standadizat UML - Limbajul standardizat UML (Unified Modeling Language) a apărut din necesitatea unei standardizări a tipologiei, semanticii şi a reprezentării rezultatelor. - În prezent, UML este un standard de modelare recunoscut de catre OMG (Object Management Group), standardizarea fiind realizată în noiembrie 1997, iar până în prezent realizându-se o perfecţionare continuă a acestuia. - UML poate fi definit ca fiind un limbaj de vizualizare, specificare, construire si documentare a modelelor. - Valoarea lui constă în faptul că este un standard deschis, realizează întreg ciclul de dezvoltare al software-ului, acoperă multe tipuri de aplicaţii şi poate fi implementat de multe produse de tip CASE.

Diagrame UML Diagrame structurale Diagrama de clase Diagrama de obiecte

Diagrama de profile

Diagrama de pachete

Diagrame comportamentale Diagrama cazuri de utilizare

Diagrama de structură compusă

Diagrama de activități

Diagrama de componente

Diagrama de stare

Diagrame de interațiuni Diagrama de tipm

Diagrama de comunicare

Diagrama de secvențe Diagrama acțiuni de ansamblu

Diagrama de desfășurare

Fig.5.5. tipuri de diagrame UML Diagrame de structură Diagramele de structură reprezintă structura, sunt utilizate pe scară largă în documentarea arhitecturii software a sistemelor software. - Diagrama clasei: descrie structura unui sistem arătând clasele sistemului, atributele acestora și relațiile dintre clase. - Diagrama componentelor: descrie modul în care un sistem software este împărțit în componente și arată dependențele dintre aceste componente. - Diagrama structurii copmpsit: descrie structura internă a unui clasificator și colaborările pe care această structură le face posibilă. - Diagrama de implementare: descrie hardware-ul utilizat în implementările sistemului și mediile de execuție și artefactele implementate pe hardware. - Diagrama obiectului: prezintă o vedere completă sau parțială a structurii unui sistem modelat la un moment dat. - Diagrama (Schema) pachetului: descrie modul în care un sistem este împărțit în grupări logice, arătând dependențele dintre aceste grupări: - Diagrama de profil: - funcționează la nivel de metamodel pentru a afișa stereotipuri ca clase cu stereotipul și profiluri sub formă de pachete cu stereotipul . Diagrame de comportament Diagramele de comportament ilustrează comportamentul unui sistem, sunt utilizate pe scară largă pentru a descrie funcționalitatea sistemelor software. - Diagrama de activități: descrie fluxurile de lucru pas cu pas operaționale și operaționale ale componentelor dintr-un sistem. - Diagrama cazului de utilizare: descrie funcționalitatea furnizată de un sistem în termeni de actori, obiectivele lor reprezentate ca cazuri de utilizare și orice dependență dintre aceste cazuri de utilizare. - Diagrama de stare a obiectului: descrie stările și tranzițiile de stare ale sistemului. Diagrame de interacțiune

Diagramele de interacțiune, un subset de diagrame de comportament, subliniază fluxul de control și de date dintre componentele din sistemul modelat: - Diagrama de secvență: arată modul în care obiectele comunică între ele în termeni de secvență de mesaje. Indică, de asemenea, planurile de viață ale obiectelor în raport cu aceste mesaje. - Diagrama (Schema) de comunicare: arată interacțiunile dintre obiecte sau părți în termeni de mesaje secvențiate. - Diagrama de ansamblu a interacțiunii: oferă o imagine de ansamblu în care nodurile reprezintă diagrame de comunicare. - Diagrame de sincronizare: un tip specific de diagrama de interacțiune în care accentul se pune pe constrângerile de sincronizare. 5.2.2. Modelare prin Metode imitaționale Metode de modelare imitațională ( prin simulare) - Simularea este o metodă care vă permite să construiți modele care descriu procesele așa cum ar fi în realitate. Un astfel de model poate „Perpetuat” în timp atât pentru un test, cât și pentru un set dat din el. - Simularea este o metodă de cercetare în care sistemul în studiu este înlocuit de un model care descrie sistemul real cu o precizie suficientă și se efectuează experimente cu acesta pentru a obține informații despre acest sistem. Experimentarea cu un model se numește imitație sau simulare, imitația este înțelegerea esenței unui fenomen fără a apela la experimente pe un obiect real. - Simularea este un caz special al modelării matematice. Există o clasă de obiecte pentru care, din diferite motive, nu au fost dezvoltate modele analitice sau nu au fost dezvoltate metode de soluționare a modelului rezultat. În aceasta caz, modelul matematic este înlocuit cu un model de imitație sau de simulare. Un model de simulare este o descriere logică și matematică a unui obiect care poate fi utilizat pentru a experimenta pe un computer pentru a analiza, proiecta, și evalua funcționarea unui obiect. O experimentarea la calculator a unui model are două componente: - componenta analitică și - componenta imitativ. Principala sarcină la simularea obiectului este analiza structurală și dinamică a proprietăților modelelor și dezvoltarea procedurilor de operare cu acestea. Schema tehnologică de modelare include: - studiul domeniului și determinarea obiectivelor de modelare; - studiul analitic al modelului, construcția unui model matematic; - dezvoltarea unui algoritm de modelare, - construcția unui model la calculator, studiul simulării; - analiza rezultatelor.

Medote imitaționale Имитационные методы

GPSS

Colored Petri Nets

SIMAN AnyLogic MATLAB &Simulink SimScale Simul8 COMSOL Multiphysics Arena

Fig.5.6. limbaje ce se utilizează la modelare imitațională Acestă metodă vă permit să simulați pe un computer (folosind programe speciale) funcționarea unui sistem real (în timp comprimat sau în mod pas cu pas). Cele mai recente și remarcate limbaje ce se utilizează la modelarea imitațională sunt: - GPSS (General Purpose Simulating System) - Limbajul specializat de modelare; - Aplicație software ANYLOGIC 7 - Platforma de simulare SimScale - Platforma Simul 8 - Pachetul COMSOL Multiphysics - Rețele Petri și Rețele Petri Colorate (CPN, Rețele Petri Colorate); Generalități despre simulare In accepțiunea actuala a informaticii, simularea cuprinde o serie de aplicații care realizează imitarea comportamentului unor păți ale lumii reale (simularea stochastica), luând în considerare și comportamentul aleator al acesteia. Definiție- Simularea este o tehnică de realizare a experimentelor cu calculatorul, care implică utilizarea unor modele matematice și logice care descriu comportarea unui sistem real (sau a unor componente ale sale) de-alungul unor perioade mari de timp. Modelul de simulare (MS) de fapt este un algoritm al relațiilor componetelor din sistem. Potenţialele simulării Potenţialele simulării sunt foarte vaste. În figura de mai jos sunt reprezentate diferite domenii reglementate de simulare. Mai întâi de toate, simularea poate acoperi toate fluxurile întreprinderii, deoarece este capabilă de a reprezenta: fluxurile fizice, cele mai utilizate, şi de asemenea, fluxul de informaţii şi fluxul decizional asociat cu aceste fluxuri fizice. Simularea este capabilă de a reproduce pe computer, comportamentul dinamic şi stocastic al unei maşini, atelier, linie de producţie, întreprindere şi astfel, evoluţia stării sistemului în funcţie de informaţiile survenite şi de deciziile luate. Pe de altă parte, simulare poate reprezenta aceste fluxuri în diferite niveluri ierarhice.

Fig.5.7. potențialele simulării Modelul de simulare se construiește în baza unui model matematic și se finalizează intr-un algoritm. În cele ce urmează vom prezenta schema generală a unui model de simulare, pornind de la descrierea principalelor elemente ale unui model matematic. Model matematic. - Prin definiție, un model este un analog ce reprezinta o parte a lumii reale intr-un mod ușor de perceput de catre noi. Modelul ne reprezintă uneori realitatea prin scheme, figuri geometrice sau alte obiecte ce ne sunt familiare și pe care le intelegem ușor Modelul matematic ne reprezintă realitatea folosind elemente sau abstracțiuni matematice. Elementele constitutive ale unui model matematic sunt urmatoarele: a) Variabile (V ) și Parametri (P ) care pot fi de intrare (V I, PI), dacă pot fi percepute (măsurate sau ințelese șor), sau de ieșire (V E, PE), dacă dimpotrivă, masurarea sau perceperea lor este dificilă. Variabilele și parametri pot lua valori numerice sau logice. Deosebirea dintre variabile și parametri constă în aceea că parametrii nu își schimbă valorile pe perioade mari de timp, în timp ce variabilele își schimbă valorile chiar pe intervale mici de timp. Scopul modelului este de a exprima variabilele și parametri de ieșire în funcție de variabilele și parametri de întrare, cu eventuala satisfacere a unor condiții de performanță de către sistem (de ex. Condiții de optim) b) Relațiile funcționale constituie o altă categorie de elemente ale unui model matematic. Ele sunt de forma: Fi(V I, PI, V E, PE) = 0 (adică implicite) și pot fi la randul lor de două tipuri: - ecuații, care sunt satisfăcute numai de anumite valori ale variabilelor sau parametrilor, și ; - identități, care sunt satisfăcute de orice valori ale variabilelor și parametrilor; ele exprimă condiții de echilibru sau legi de conservare.

Ecuațiile si identitățile pot fi: relații algebrice sau transcendente, diferențiale sau integrale, detrministe sau stochastice, etc. c) Caracteristicile operative - constituie o altă categorie de elemente ce compun un model matematic și ele pot fi: - ipoteze de lucru (referitoare la relațiile funcționale); - ipoteze statistice (referitoare la valorile de intrare (VI) -aleatoare). d) Tehnica de rezolvare este un alt element constitutiv al unui model matematic. Ea este o tehnică matematică ce realizează separarea elementelor de ieșire în funcție de elementele de intrare, adică: (V, P )E = fj(VI, PI) Cu alte cuvinte, tehnica de rezolvare a modelului exprimă sub forma explicită variabilele și parametri de ieșire în funcție de variabilele și parametri de intrare. Construcța unui Model de Simulare utilizează două concepte de bază: - ceasul simularii și - agenda simulării Ceasul simulării - Ceasul asigură eșalonarea corectă în timp a evenimentelor create de model și uneori ajută la implementarea condiției de terminare a simulării.

Fig.5.8. Tipuri ale ceasului simulării a) ceas cu creștere variabilă; b) ceas cu creștere constantă;

Ceasul simulării este de două tipuri: a) ceas cu creștere variabilă; b) ceas cu creștere constantă; Variața ceasului. a) Cazul ceasului cu creștere variabilă. Ti = valorile ceasului. b) Cazul ceasului cu creștere constantă c. Agenda simulării. Agenda se compune din elementele memorate de modelul de simulare. Variabilele modelului iau diverse valori pe parcursul simulării; de aici rezulta că pe parcursul simulării apar multe evenimente. Evenimentele sunt de diverse tipuri; unele variabile descriu și stări ale sistemului (sau ale unor componente ale acestuia). Evenimentele sunt creiate sau generate la momente de timp ulterioare valorii ceasului. De aceea agenda se compune din două părți:

agenda evenimentelor curente - AEC și agenda evenimentelor viitoare - AEV. Deci agenda A = AEC ⊕ AEV , unde: AEC = agenda evenimentelor curente (care au timpul de apariție egal cu valoarea ceasului); iar AEV = agenda evenimentelor viitoare (care au timpul de apariție ulterior valorii curente a ceasului). -

Algoritmul simulării prelucrează deci numai evenimentele din AEC; Prelucrarea unui eveniment inseamnă fie determinarea apariției unui nou eveniment (ce se memorează în AEV ) sau modificarea unei stări (fie distrugerea unui eveniment “ștergerea” lui din agendă). Prelucrările evenimentelor țin seama și de stările sistemului la acel moment. Algoritmul simulării gestionează/actualizează agenda prin interacțiunea acesteia cu ceasul;

Fig.5.9. Schema logică globală a unui algoritm de simulare bazat pe ceas cu creștere variabilă Etapele realizării unui experiment de simulare sunt: 1. Formularea problemei, care constă în a preciza intrebările la care trebuie să răspunda modelul și a preciza domeniul lumii reale ce trebuie analizat; 2. Realizarea unor experimente preliminare, in această etapă se stabilesc, pe baza observațiilor sau datelor culese din lumea reală, sau existente, referitoare la aceasta (istorice), variabilele și parametri și care din acestea sunt de intrare sau de ieșire. 3. Prelucrarea (interpretarea) primară a datelor preliminare, la eceastă etapă se disting variabilele aleatoare, se estimează parametri și se testează ipoteze statistice. (Statistica matematică joacă un rol important în simulare). 4. Formularea unui model matematic preliminar, incomplet; in această etapă se precizează relațiile funcționale, ipoteze de lucru (care să concorde cu datele existente, colectate) și se indentifica ce relații nu pot fi exprimate matematic și care sunt dificultățile ce ar trebui inlăturate pentru a răspunde la intrebările formulate. 5. Evaluarea modelului (etapă de decizie!); se urmărește să se evalueze complexitatea modelului, dacă el poate răspunde in timp real și complet la intrebări. Aici se fac simplificări sau completări ale modelului matematic propus. 6. Construcția modelului de simulare (sub formă de algoritm detaliat); modelul se construiește conform celor precizate anterior urmărindu-se ca el sa fie general. La construcția algoritmului simulării se va utiliza un limbaj spializat de simulare (în cazul nostru GPSS) 7. Validarea modelului este o etapă importantă. In afară de validarea formală (testare sintactică și logic-formală a programului), trebuie să se decidă dacă modelul rezolv corect problema formulată. Acest lucru se realizează prin compararea rezultatelor simulării fie cu rezultate practice cunoscute, fie prin compararea cu soluția obținută cu ajutorul unui model matematic. 8. Planificarea experiențelor de simulare. Din cele relatate anterior cunoaștem că simularea este un experiment realizat cu calculatorul pe baza unui model ce descrie sistemul real. Orice experiment trebuie să se desfășoare pe baza unui plan experimental. Pentru planificarea experimentelor de simulare se folosesc metode ale statisticii matematice (așa zisele experimental design). 9. Prelucrarea și interpretarea experiențlor de simulare o etapă la fel de importantă ca și cele precedente. Programul de simulare rulat pe calculator produce de regulă valori de selecțe asupra variabilelor de ieșire, Scopul unei simulări este: de a găsi o rezolvarea a unei probleme într-o lume virtuală lipsită de riscuri, unde putem face greșeli, putem să dăm timpul înapoi și să o luăm de la început. Rezultatele obținute pot fi rafinate prin varierea parametrilor, în scopul găsirii soluțiilor ideale. Utilitatea simulării. Orice sistem complex, se proiectează pe baza simulării. Alegerea parametrilor de proiectare se realizează (ca intr-un joc!) pe baza unor experiențe bazate pe modelul de simulare. Aceste experiențe sunt mult mai puțin costisitoare decât cele reale. Când experiențele reale sunt costisitoare este intotdeauna recomandabil ca experiențele să se realizeze prin simulare.

Exemple de utilizare: - Înainte de a construi un baraj, mai intâi simulăm comportarea lui pentru a alege cea mai buna variantă de proiectare și construcție. - Când se proiectează politici complexe de dezvoltare economico-socială. - Când se proectează sistemele de producție complexe, - Când se proectează politicile de dezvoltare regională, - proiecte macroeconomice, evoluța mediului ambiant, etc). Modelele pe care le construim nu vor rezolva direct nicio problemă, ci vor furniza informații despre cum sistemul funcționează și apoi modul în care va funcționa cu schimbarea a unor parametri selectați. Alegerea tipului de modelare Procesul modelării cuprinde următoarele etape: - cunoașterea detaliată a realității (procesului) care se modelează, - construirea propriu-zisă a modelului logic-matematic, - rularea modelului si evaluarea soluției, - implementarea modelului logic-matematic si optimizarea soluției. În acest scop se vor lua în considerare atât rezultatele care se doresc a fi obținute cât și ceea ce se cunoaște despre procesul/fenomenul real. Acuratețea rezultatelor unei simulări depinde în mod funamental de felul în care s-a modelat procesul –daca acesta respectă comportamentul real al procesului, dar și de datele de intrare. Se pot obține rezultate teoretice excepționale de optimizare a unor procese, care însă nu vor putea fi niciodată realizate în practică deoarece acele valori ale parametrilor nu vor fi întâlnite niciodată în realitate. 5.2.2.1. Limbajul specializat de modelare GPSS (General Purpose Simulation System) Generalități despre limbajul GPSS - Limbajul specializat de modelare GPSS (General Purpose Simulation System) este un limbaj special care este utilizat în principal pentru a simula sisteme discrete. După cum cunoaștem Limbajele de simulare sunt in acelaș timp limbaje de programare și limbaje de modelare; ele implementează elementele esențiale ale simulării: - manipularea ceasului și gestionarea memoriei. Utilizatorul are numai grija descrierii evenimentelor și a prelucrării lor. Programele in limbaj de simulare sunt mai scurte dar și mai puțin flexibile. Sunt limitate in privința prelucrării și interpretării experimentelor de simulare. Entitățile limbajului GPSS. Limbajul GPSS se compune din 16 tipuri de entități (elemente de abstractizare). La fiecare entitate se asociază un numar de proprietăți sau atribute in majoritatea lor adresabile intern (de către GPSS), dar unele suntadresabile si de către utilizator; Atributele sunt: standard numerice (numere) sau standard logice (valori logice); Entitățile de bază: 1) Blocuri (entități care descriu activități); 2) Tranzactți (elemente circulante);ele sunt creiate (printr-un bloc special GENERATE) și circulă prin model (sistem!), ca urmare a acțiunii altor blocuri. Blocurile au asociate caracteristici

numerice sau logice și posed˘ a argumente necesare descrierii activit˘ at ¸ilor. Tranzact ¸iile posedă un număr de parametri standard dar și parametri introduși de utilizator. Prin programul de simulare utilizatorul poate accesa parametrii tranzacțiilor. Entități de echipament: 3) Stații de serviciu sau facilități; (ele corespund subsistemelor cu o componentă care tratează de regulă o singură tranzacție!); 4) Multistații de serviciu sau depozite; acestea tratează de regulă mai multe tranzacții (de ex. liftul, autobuzul, pot transporta mai multi clienti considerati ca tranzactii, etc!); 5) Comutatorii logici sunt variabile logice care permit utilizatorului să realizeze ramificarea după dorință a fluxului de execuție în programul de simulare. Entități de calcul ce permit efectuarea (limitat!) a unor calcule: 6) Variabile aritmetice; permit evaluarea unor expresii aritmetice, iar rezultatul este memorat de o variabilă aritmetică; 7) Variabile booleene; permit evaluarea unor expresii booleene, iar rezultatul este memorat de o variabilă booleeană; 8) Funcții descrise prin tabele sau prin segmente de dreaptă (liniare pe porțiuni); 9) Funcții analitice descrise prin expresii mai complicate; (ele există numai in SIMUB i au rolul de a facilita simularea diverselor variabile aleatoare prin metoda inversa); Entități statistice, permit colectarea unor statistici sau estimații privind VE sau PE; printre acestea se remarcă: 10) Cozile care sunt entităti statistice ce memorează tranzacțiile intârziate în sistem; 11) Tabele de frecvențe care descriu histograme ale VE; 12) Tabele de frecvența bidimensionale, sau tabele de contingență; (acestea sunt disponibile numai in SIMUB); Entități de referință care memorează anumite informații pe care le dorește utilizatorul și anume: 13) Cuvinte de salvare care memorează valori ce corespund câte unui cuvânt de memorie al calculatorului; 14) Matrice de cuvinte de salvare care memorează matrici; Entități de tip lanț,care sunt de două tipuri: 15) Lanțuri ale utilizatorilor în care se pot depune sau scoate tranzații după dorința utilizatorului; Există și lanțuri ale sistemului, manipulate intern de către GPSS, care nu pot fi accesate de utilizator. 16) Grupuri care separă tranzacții (cu anume scopuri de prelucrare dorite de utilizator, sau cu anumite proprietăți) 5.2.2.2. Aplicația ANYLOGIC 7 AnyLogic este o aplicație software multimetodă,- care permite realizarea de modele prin 3 metode, SD, ABM sau DES, dar și prin combinarea acestora în același model. - Simularea Dinamica a sistemelor – SD

- Modelarea bazată pe agenți (ABM) - Simularea evenimentelor distincte (DES) AnyLogic folosește Java ceea ce îi oferă posibilitatea de a crea applet-uri Java, care pot fi deschise în orice browser obișnuit ceea ce facilitează împărtășirea și plasarea modelelor AnyLogic pe pagini web. Prin prisma simulării dinamice (SD)

Prin prisma simularii evenimentelor dscrete (DES)

Prin prisma simulării bazată pe agenți (ABM)

Fig.5.10. Trei metode de modelare -

Entitățile, resursele și agenții sunt același obiect. Entitățile pot avea un comportament individual, separat față de cel al proceselor. Agenții pot fi integrați sau pot fi scoși din organigramele procesului fără a fi necesară o codificare. Dinamica sistemului poate fi realizată liber în impreună și/sau în afara entităților și agenților.

Spațiului unificat de marcare a elementelor - Spațiu 3D consolidat pentru tot felul de obiecte: agenți, entități, unități de resurse, pietoni, mașini etc. - Oamenii, vehiculele, paleții, clădirile, echipamentele pot interacționa în același spațiu 3D. - Un nou set de elemente de marcare a spațiului cu care ușor se Definesc pereții, zonele, căile, nodurile etc. - Sunt disponibile forme specifice de marcare pentru transportoare, depozite, căi de acces și întrerupătoare. - Noile tehnici de rutare a rețelei permit modelarea eficientă a structurilor foarte mari, cum ar fi centrele de distribuție în care este modelat fiecare raft. U O bibliotecă nouă pentru modelarea proceselor - Definire grafică a parametrilor, variabilele interne, animația și statisticile entităților. - Resursele pot avea propriul lor subproces.

- O entitate poate solicita mai multe seturi alternative de resurse sau poate solicita o anumită unitate de resurse. - Susține prioritățile sarcinii, întreruperi, preemineri, eșecuri, pauze și schimbări. Pe lângă fluxul tradițional de entitate „push”, sunt de asemenea suportate fluxurile „pull”, ceea

Sp

ce este deosebit de util în aplicațiile de fabricație. nified Aplicația ANYLOGIC 7 este utilizată pe larg la: - planificarea traficului, simularea modificărilor, completărilor sau scăderilor la o rețea rutieră; - sincronizare și secvențiere a semafoarelor pentru a optimiza sistemul la scară largă; - analiza fluxului, inclusiv generarea de statistici pentru congestii și blocaje de trafic; - integrarea obiectelor și clădirilor publice în rețelele rutiere, evaluarea impactului asupra traficului 5.2.2.3. Platforma de simulare SimScale SimScale este o platformă de simulare de inginerie 3D bazată pe cloud care permite oricui din echipa de dezvoltare a produsului să simuleze comportamentul fizic al produselor sale într-un browser web standard. Misiunea SimScale este de a ajuta inginerii, oamenii de știință și întreprinderile din întreaga lume să își dezvolte produsele mai bine, mai rapid și mai ieftin, oferindu-le acces la o tehnologie de simulare puternică și o putere de calcul nelimitată - la cerere, colaborativă și bazată pe un model de prețuri flexibil. SimScale este un serviciu complet bazat pe cloud. Toate lucrările se desfășoară prin intermediul browserului dvs. web la alegere. Primul pas în utilizarea instrumentelor oferite este să vă aduceți geometria obiectului în mediul SimScale. La fel ca în cazul tuturor cloud, înseamnă că îl încărcați prin Internet pe serverele companiei. Discretizarea. Odată ce geometria dvs. este încărcată, următoarea etapă este Discretizarea. Procesul de Discretizare are loc în cloud și aveți posibilitatea de a defini numărul de nuclee utilizate pentru a face acest lucru. Desigur, acest proces nu leagă stația de lucru și poate fi făcut de pe orice computer cu conexiune la Internet. Puteți monitoriza progresul pe web sau să așteptați e-mailul de notificare care va fi trimis odată ce procesul va fi finalizat. De asemenea, veți fi informat dacă procesul a eșuat din orice motiv. Pre-procesare și configurare După terminarea procesului de Discretizarea, următorul pas este să comutați în fila Designer de simulare. Acest lucru vă permite să începeți să descrieți studiul, alocând condiții de limitare, materiale și alte variabile de studiu. Următorul pas este să comutați la tabelul de Proiectare simulare. Acest lucru vă permite să începeți să descrieți studiul, alocând condiții de limitare, materiale și alte variabile ale obiectului de studiu. După ce configurarea este completă, atunci trimiteți lucrarea pentru a calcula. Din nou, sistemul vă oferă controlul asupra numărului de procesoare utilizate pentru a vă calcula rezultatele. 5.2.2.4. Platforma de simulare Simul 8

SIMUL 8-Planner este un pachet software care combină simularea și planificare cu instrumente de planificare. Dacă analistul (proiectantul) poate defini și verbaliza un proces și regulile care îl guvernează, sistemul poate fi simulat folosind SIMUL8. SIMUL8 folosește un generator de numere pseudo aleatoriu multiplicativ-congruențial modificat. Există 30.000 de seturi de fluxuri de numere aleatorii disponibile în SIMUL8. Din 2006, SIMUL8 acceptă înlocuirea generatorului propriu cu orice codificat într-o bibliotecă de legături dinamice. Programare în acest software de simulare obiectul simulat implică cele cinci elemente fundamentale: punct de intrare a lucrării, coș de depozitare, centru de lucru, lucru complet și resursă. Obiectele de simulare de bază: Întrare de Lucru, - Work Entry - Coș de Depozitare, - Storage Bin, - Centru de Lucru, - Work Center - Ieșire de Lucru - Work Exit - Resurse – Resource Work Item - Element de lucru Elementele de lucru sunt părțile „în mișcare” ale unui model de simulare. Acestea sunt utilizate pentru a simula „fluxul” de articole prin procesul simulat. Ele pot reprezenta: asamblări, subansambluri, echipamente de transport, oameni, hârtie sau orice alt lucru procesat prin simulare. Proprietățile Elementelor de Lucru: - Etichete (atribute) - Imaginea articolului de lucru - Dimensiuni - Avansat - mai multe tipuri de Elemente de Lucru Work Entry Point - Punctul de intrare în lucru Punctele de intrare în lucru sunt obiecte care creează sau generează elemente de lucru în modelul de simulare. Acestea sunt de obicei punctul de plecare al unui proces sau subproces în care obiectele în mișcare intră în simulare. Utilizatorii pot specifica rata la care sosesc aici articolele de lucru. Punctele de intrare în lucru sunt obiecte active, pe măsură ce împing munca în model. Proprietăți: - Nume - Timpuri inter-sosire - timpul dintre Elementele de Lucru care intră în sistem - Rezultate - rezultate despre obiect - Prelucrare - numărul de Elemente de lucru intrate la fiecare interval de timp - Calea de ieșire - formele prin care lucrarea părăsește obiectul - Acțiuni etichetei etichetă - valorile etichetelor Elementului de Lucru s-au schimbat aici - Grafică - schimbă aspectul obiectului Utilizări comune: - Punctul de sosire a comenzii

- Punctul de pornire a procesului, rezultatul la ieșire din proces - Apeluri telefonice primite - Ușa prin care ajung persoane / pacienți Storage Bin - Loc de depozitare Un loc de stocare este un spațiu în care Elementele de Lucru fac „coada”. loc de stocare acționează ca buffere / cozi între pașii dintr-un proces sau ca zone de stocare pentru inventar sau lucrări în proces. Proprietăți: - Nume spațiului - Capacitatea spațiului - limitează numărul de Elemente de Lucru care se pot stoca în acest spațiu - Perioada de valabilitate - numărul de unități de timp până la expirare pentru Elementele de lucru - Timp minim de așteptare - Timpul minim în care Elementele de lucru trebuie să staționeze în Depozit - Rezultate - rezultate despre obiect - Pornire - Start-Up - conținutul inițial al spațiului de stocare la începutul modelului Conținut - afișează conținutul curent al spațiului de stocare - Grafică - schimbarea aspectul coșului de stocare Work Center - Centru de lucru Centrele de lucru sunt locul în care sunt prelucrate Elementele de lucru. De obicei, este nevoie de ceva timp pentru a îndeplini sarcina și uneori, aceasta necesită una sau mai multe resurse. • Proprietăți: Nume - Timing - timp pentru procesarea Elementelor de lucru setate printr-o distribuție - Rezultate - rezultate despre obiect - Resurse - setul cerut de resurse pentru a efectua sarcina - Eficiență - specifica defecțiuni, reparații - Routing In - modul în care Elementele de lucru intră în centrul de lucru - Routing Out – modalitățile prin care Elementul de lucru părăsește obiectul - Acțiuni pentru etichetă - valorile etichetelor Elementului de lucru s-au schimbat aici - Prioritate - modul în care acest centru de lucru concurează față de alte resurse - Replicare - o modalitate simplă de a copia centrul de lucru - Cuprins - afișează conținutul curent al Centrului de lucru - Grafică - schimbarea aspectului și animația Centrului de lucru Work Exit Point - Punctul de ieșire din lucru Punctele de ieșire de lucru oferă un mijloc pentru ca Elementele de lucru să părăsească modelul de simulare. SIMUL8 înregistrează în general aceste statistici ale procesului de lucru și rezumate ale Elementului de lucru. Proprietăți - Numele puctului de ieșire - Rezultate - rezultate despre obiect - Grafică - schimbarea aspectului obiectului

- Oprire Model la limită - oprește modelul la atingerea numărului specificat Resource - Resursă Resursele sunt elemente din modelul pe care centrele de lucru pot fi setate să le solicite înainte ca Elementele de lucru să poată fi procesate. Astfel, ele reprezintă fie personal, fie unelte speciale. Centrele de lucru care au o cerință de resurse nu pot începe lucrarea până când sunt disponibile atât un element de lucru cât și resursa specificată. Resursele pot fi, de asemenea, „împărțite” între mai multe centre de lucru, favorizând centrele de lucru cu setarea de prioritate maximă. Proprietăți - Numele Resursei - Număr disponibil - specificați numărul acestui tip de resursă disponibil - Shift Dependent – transferarea resurselor disponibile să urmeze modelele de schimbare - Pool Resource - „Pool” unul sau mai multe tipuri de resurse - Rezultate - rezultate despre obiect - Traversare - timpul de călătorie pentru mișcările resurselor între obiecte - Grafică - schimbă aspectul și comportamentul vizual al obiectului

Fig.5.11. Simularea unei clnici 5.2.2.5. Pachetul COMSOL Multiphysics Pachetul COMSOL Multiphysics® este un instrument puternic care vă permite să simulați procesele fizice ale unui dispozitiv din diferite domenii ale științei și tehnologiei, inclusiv sarcini conexe: - inginerie electrică și electrodinamică, - hidrodinamică și transfer de căldură, - mecanică și acustică, - chimie și electrochimie. Capabilitățile unice de modelare oferite de COMSOL Multiphysics® permit inginerilor să creeze soluții inovatoare, să optimizeze performanța, să reducă timpul și costurile de dezvoltare pentru produsul final.

Modelarea multiphysics oferă rezultate exacte Adesea, cheia pentru simulări de succes în inginerie este dezvoltarea de modele validate experimental care înlocuiesc experimente și prototipuri și oferă o înțelegere mai profundă a designului sau procesului studiat. Ca utilizator al COMSOL Multiphysics®, sunteți liberi de restricții în general asociate cu software-ul de simulare și aveți un control complet asupra tuturor aspectelor modelului dumneavoastră. Puteți fi, de asemenea, creativ (într-un mod imposibil sau mult mai greu cu abordări tradiționale), datorită capacității de a cupla un număr de fenomene fizice împreună și de a introduce descrieri fizice definite de utilizator, cu ecuații și expresii asociate, direct în interfața grafică a utilizatorului (GUI). Adesea, cheia pentru simulări cu succes în inginerie este dezvoltarea modelelor validate experimental care înlocuiesc experimente și prototipuri și oferă o înțelegere mai profundă a designului sau procesului studiat. 5.2.2.6. Modelarea și simularea discrete în mediul ARENA Modelul de simulare în sistemul Arena este un grafic (figura 12 ), ale cărui noduri sunt module. Modulele sunt interconectate folosind conexiuni prin care tranzacțiile sunt mutate între modulele 2. Pentru a crea un model în limbajul Arena este suficient să: 1) specificați tranzacțiile, resursele și alte obiecte; 2) selectați modulele necesare; 3) legarea modulelor folosind conexiuni; 4) setați parametrii fiecăruia dintre module; 5) stabiliți caracteristicile modelului în ansamblu.

Fig.5.12. Graficul de simulare proces Modelele din sistemul Arena sunt orientate spre proces, graful modelului arată calea unei tranzacții individuale. O tranzacție este creată, așteaptă în linie, captează resurse, procesează, eliberează resurse și este distrusă. Alte tranzacții pot rula în paralel, în acest caz sistemul își asumă sarcina de control al procesului. Concepte de bază utilizate la construcția modelelor în sistemul Arena. Aceste concepte includ: - tranzact (entitate - obiect dinamic al modelului de simulare); - resursă; - atribut; - variabilă;

- coada; - program - blocuri - modul. 5.2.2.7. Reţele Petri şi modelarea sistemelor concurente. Aceasta este o metodă formală (matematică) folosită pentru modelarea şi verificarea sistemelor (concurente/distribuite). Petri Nets şi conceptele acestora au fost extinse, dezvoltate şi aplicate într-o varietate de domenii: - automatizări pentru birou; - sarcini de lucru, fluxuri; - producţia flexibilă; - limbaje de programare; - protocoale şi reţele; - structuri hardware; - sistemele în timp real; - evaluarea performanţei; - operaţiuni de cercetare; - sisteme integrate; - sisteme de apărare; - telecomunicaţii; - Internet; - comerţ electronic şi comerţ; - reţele feroviare; - sisteme biologice. Concurența într-un sistem Este proprietatea unui "sistem" în care mai multe "entităţi" acţionează şi interacţionează în acelaşi timp. Acest fenomen deseori se manifestă în multe aplicaţii: • ştiinţa informaticii (de exemplu: calculul paralel); •   fluxuri de activităţi; •   sisteme de fabricaţie... Domenii de aplicabilitate:  protocoale de comunicare, reţele;  sisteme software şi hardware;  algoritmi distribuiţi;  protocoale de securitate;  biologie, chimie, medicină;  economie (fluxuri de lucru). Baza matematică a teoriei rețelelor Petri este teoria seturilor. Un set este o mulțime în care o singură instanță poate apărea în mulțime de mai multe ori (în teoria clasică a seturilor, un element fie nu este inclus în set, fie este inclus o singură dată). Un set poate fi numit și multiset sau tuple (comandat multiset). Funcția numărului de instanțe este notată #. Notarea # (x, B) înseamnă că elementul x apare în mulțimea B multiple ori,

unde 0 ≤ B ≥∞. Situația în care 0 ≤ B ≥1 corespunde teoriei claselor de seturi. Definiție 1. O rețea Petri se numește colecția de mulțimi N = {P, T, I, O} unde: P - este un set finit ale cărui elemente sunt numite poziții; T - este un set finit ale cărui elemente se numesc tranziții, Mulţimile P şi T sunt disjuncte P ∩ T = ∅; I este setul de funcții de intrare, I: T → P O este setul de funcții de ieșire, O: T → P T – set de elemente de rețea care nu sunt goale, numite tranziții Tranziții: reprezintă acțiuni sau evenimente din sistemul modelat P – set de elemente de rețea care nu sunt goale, numite locuri; Locațiile input (pentru o tranziție): parametri, variabile, tipuri de resurse necesare producerii unei acțiuni, precondiții pentru producerea unui eveniment

T – set de elemente de rețea care nu sunt goale, numite tranziții Tranziții: reprezintă acțiuni sau evenimente din sistemul modelat

Definiție 2 O rețea Petri este un 4-uplu N = (P, T, F, W) astfel încât : 1. P - mulțime de locații, 2. T - mulțime de tranziții, P ∩ T = ∅; 3. F ⊆ (P × T) ∪ (T × P) relația de flux; 4. W:(P × T)∪ (T × P)→ N funcția pondere, (W (x, y) = 0 dacă (x,y) ∈ F).

P = {p1, p2, p3, p4} T = {t1, t2, t3} F = {(p1, t1), (p2, t1), (t1, p3), (p3, t3), (t3, p1), (t3, p4), (t2, p2)} W (p1, t1) = 1, W (p2, t1) = 2, W (t1, p3) = 1 W (t1, p3) = 1, W (p3, t3) = 1, W (t3, p4) = 1, W (t3, p1) = 1, W (t2, p2) = 1

Marcarea unei rețele Petri Definiție 3 (Marcare, rețele marcate) O marcare a lui N este o funcție M : P → N. Fie N = (P, T, F, W) o rețea Petri și M0 : P → N. Atunci (N, M0) se numește rețea Petri marcată. M = (1, 0, 0, 0) Distribuția punctelor în locațiile unei rețele = marcarea rețelei (starea sistemului modelat)

Funcționarea rețelei Petri este descrisă formal folosind o multitudine de secvențe de acționare și o multitudine de marcaje realizabile în rețea. Aceste concepte sunt definite prin regulile de declanșare a tranzițiilor de rețea. O rețea Petri este definită ca un graf bipartit. Toate vârfurile grafului aparțin uneia dintre cele două clase - poziții și tranziții. -

-

Punctele din locații (marcarea): pot modela resurse sau valori ale parametrilor/variabilelor reprezentate de locația respectivă Ponderea unui arc input (al unei tranziții): căte resurse de un anumit tip sunt necesare producerii acțiunii (valoarea minimă pe care trebuie să o aibă o variabilă pentru că o acțiune să se producă) Ponderea unui arc output (al unei tranziții): numărul de resurse de un anumit tip rezultate prin producerea acțiunii

Acțiunile din rețea sunt reflectate prin tranziții declanșate. Declanșarea tranziției t înseamnă eliminarea unei etichete din fiecare locațir pi dacă există o conexiune de la pi la t și adăugarea unei etichete la fiecare locație pj dacă există o conexiune de la t la pj.

În această rețea Petri avem P={p1; p2 }; T={ t1 }; I(t1 )={ p1 }; O(t1 )= {p2 }; =(1;0).

Rețeau Petri după declanșarea

Reiesă că , graful tranziției t1 din exemplul precedent Petri are două tipuri de =(0;1). noduri: - Un cerc care

reprezintă locația; - Un dreptunghi (sau bandă) care reprezintă tranziția. Arcurile direcționale (săgețile) conectează locațiile și tranzițiile, unele dintre ele fiind direcționate de la locații la tranziții, altele de la tranziții la locații.

Un arc direcționat de la locația pi la tranziția tj definește locația ca o intrare în tranziție. Intrări multiple în tranziție sunt indicate prin arce multiple de la punctele de intrare la tranziții. - Locația de ieșire este indicată de arcul de la tranziția la locație, mai multe ieșiri sunt indicate de multe arcuri. -

Unul dintre conceptele originale ale teoriei rețelelor Petri este conceptul de jetoane (cip). Jetoanele sunt reprezentate de puncte situate în interiorul locațiilor. - fiecare locație a rețelei este asociată cu un număr natural care indică numărul de jetoane în această locație. Acest număr se numește marcaj de locație, iar totalitatea acestor numere pentru toate locațiile rețelei se numește marcaj de rețea. De remarcat, că locația poate să nu conțină jetoane, adică are marcaj zero. Cu alte cuvinte Markajul este distribuția jetoanelor (cipurilor) în locațiile rețelei Petri. Conceptul de jetoane este un concept fundamental în teoria rețelelor Petri (precum locația și tranziția). Jetoanele sunt alocate locațiilor rețelei Petri și pot fi considerate că aparțin acestora. Numărul și localizare a cipurilor se pot modifica în timpul funcționării rețelei Petri. Cipurile utilizate indică funcționarea rețelei Petri.

Un alt concept original al unei rețele Petri este „declanșarea” tranzițiilor. Numim locație de intrare ale unei anumite tranziții - acele locații din care provin arcurile care intră în această tranziție.   Ca urmare, numim locație de ieșire locațiile care includ arcurile emanate de această tranziție. Tranziția este declanșată prin eliminarea cipurilor din fiecare locație de intrare și plasarea lor în fiecare locație de ieșire. Mai mult, numărul de cipuri eliminate dintr-o anumită locație sau plasate într-o locație specifică este egal cu numărul de arcuri care leagă tranziția declanșată cu această locație particulară. De exemplu, tranziția T1 din figură la declanșare ia de la locația P1 un cip și crește numărul de jetoane în locația P3 cu unul. Tranziția T2 elimină un cip din locația P1 și pune două jetoane (prin două arcuri) în locația P2.

Evenimente şi condiţii Evenimentele sunt acţiuni care au loc în sistem. Apariţia evenimentelor este controlată de starea sistemului. Starea sistemului poate fi descrisă ca o mulţime de condiţii. O condiţie este un predicat sau descriere logică a stării sistemului. Astfel, o condiţie poate fi: fie adevărată, fie falsă. Deoarece evenimentele sunt acţiuni, ele se pot produce. Pentru ca un eveniment să se producă (să fie declanșat), s-ar putea să fie necesar ca anumite condiţii să fie adevărate. Acestea se numesc precondiţiile evenimentului. Apariţia evenimentului poate determina ca precondiţiile să nu mai fie adevărate, şi poate stabili ca alte condiţii, numite postcondiţii, să devină adevărate O rețea Petri este desenată ca un graf bipartit, direcționat, și ponderat. ● Un graf bipartit este un graf cu două seturi distincte de noduri astfel că nu există margini între nodurile din același set. ● În cazul transformărilor, acestea două seturi sunt definite ca locuri și tranziții. De regulă, locurile sunt reprezentate ca cercuri, iartranziția ca fie bare sau fie cutii dreptunghiulare. ● Marginile dintre noduri sunt reprezentate ca arce.

O rețea Petri are stări desemnate ca marcaje. Fiecare marcaj corespunde unui număr întreg k nonnegativ atribuit fiecărui loc p. - Aceast loc "marcat„ corespunde cu jetoane k, care sunt reprezentate pe graf, de regulă ca cercuri negre mici în fiecare loc. - În mod normal, nu există nicio limită pentru numărul de jetoane care poate marca un anumit loc.

Fig 5.13. Reprezentarea marcajului Un arc, fie de la o locație la o tranziție sau de la o tranziție la o locație, are o pondere k. ● Un arc cu pondere k este funcțional la fel ca în cazul în care există k arcuri cu ponderea 1. O locație cu un arc de la sine la o tranziție este o locație de intrare și o locație cu un arc de la o tranziție la ea însăși este o locație de ieșire. 1. O tranziție t este activată dacă fiecare locație de intrare p este marcat de t cu cel puțin w ((p, t)) jetoane unde w ((p, t)) este ponderea arcului de la p spre t. 2. Consumarea de către o tranziție activată t elimină jetoanele w ((p, t)) de la fiecare ieșire p spre intrare t și adaugă w ((t, p ')) jetoane pentru fiecare locație de ieșire de la tranziția t spre locația p '.

Nu este obligatoriu ca o tranziție să aibă atât intrare, cât și ieșire. O tranziție fără intrare (fig. A) este menționată ca o tranziție sursă. O tranziție sursă este întotdeauna activată. O tranziția fără ieșire (fig. B) se numește tranziție chiuvetă.

Exemplu rețea Petri Descrierea matematică P = {p1, p2, p3} T = {t1, t2, t3} F = {(p1, t1), (t1, p2), (t1, p3), (p3, t3), (t3, p1), (p2, t2)} W (p1, t1) = 1, W (t1, p2) = 1, W (t1, p3) = 1, W (p3, t3) = 1,

Terminologie uzuală - Dacă o poziţie p este atât poziţie de intrare, cât şi de ieşire pentru o tranziţie t, atunci p şi t formează o buclă autonomă (eng. self-loop). - O reţea Petri care nu conţine bucle autonome se numeşte rețea pură (eng. pure). - O buclă autonomă poate fi întotdeauna transformată într-o buclă neautonomă prin adăugarea simultan a unei poziţii şi a unei tranziţii formale (eng. dummy). - Orice reţea impură poate fi transformată într-o reţea pură. - O reţea Petri se numeşte ordinară (eng. ordinary) dacă toate arcele sale au pondere unitară.

-

Dacă într-o reţea Petri există cel puţin un arc a cărui pondere este mai mare decât 1, atunci se spune că ea este reţea generalizată.

Mulţime predecesoară și mulţime succesoară Fie F mulţimea tuturor arcelor unei reţele Petri N. Se numesc mulţime predecessor (eng. pre-set) şi mulţime succesor (eng. post-set) a tranziţiei t (fig. 39a) două mulţimi de poziţii definite prin: •t ={ p | (p, t) ∈ F} = mulţimea tuturor poziţiilor de intrare ale lui t; şi, respectiv, prin: t• = { p | (t, p) ∈ F} = mulţimea tuturor poziţiilor de ieşire ale lui t. Se numesc mulţime predecesor şi mulţime succesor a poziţiei p (fig. 41b) două mulţimi de tranziţii definite prin: • p ={ t | (t, p) ∈F} = mulţimea tuturor tranziţiilor de intrare ale lui p; şi, respectiv, prin: p• ={ t | (t, p) ∈F}= mulţimea tuturor tranziţiilor de ieşire ale lui p.

Fig. 5.14. mulțimi predcesoare și succesoare, ilustrare. Aplicarea Rețelelor Petri Exemplul 1: Specificaţii de proiectare pentru structurile de conducere - Un proces cu funcţionarea pilotată de evenimente discrete este constituit dintr-o mulţime de resurse care sunt utilizate pentru a efectua o succesiune de operaţii. - Procesul are drept intrare un număr de clienţi (la general desemnând entităţi a căror natură fizică depin de specificul procesului). - Realizarea fiecărei operaţii necesită alocarea uneia sau mai multor resurse care sunt eliberate (consummate) după încheierea operaţiei respective. - Fiecare operaţie realizată de process reprezintă un anumit tip de serviciu prestat unui client. - În urma parcurgerii secvenţiale a întregii succesiuni de operaţii, un client este servit complet şi poate părăsi procesul. Deci, ieşirea procesului constă în numărul de clienţi serviţi complet. În cazul general, diferiţi clienţi pot necesita diferite operaţii în diferite succesiuni. În practici uzuale, numărul de succesiuni diferite de operaţii este de ordinul unităţilor ((linii de servire diferite)).

Problematica conducerii unui astfel de proces constă în a asigura îndeplinirea următoarelor patru condiţii de funcţionare: - condiția (C1) corectitudinea succesiunii de operaţii pentru toţi clienţii; - condiția C2) corectitudinea alocării şi eliberării resurselor necesare de fiecare operaţie în parte; - condiția (C3) prestarea unui anumit tip de serviciu de îndată ce resursele necesare pentru operaţia respectivă sunt disponibile (adică, maximizarea numărului de clienţi aflaţi în curs de servire, în etape diferite); - condiția (C4) repetabilitatea prestării serviciilor fără blocaje circulare datorate utilizării partajate a unora dintre resurse.

Fig. 5.15. Bloc schema structurii de conducere. O structură de conducere (proces + controler), reprezentată prin schema bloc din fig. , ce asigură satisfacerea condiţiilor de funcţionare (C1) – (C4) exploatează numai proprietăţi de tip logic (independente de durata operaţiilor) şi, drept consecinţă, descrierea acestei structuri poate fi abordată prin formalismul reţelelor Petri netemporizate.

Fig. 5.16. Sistem de producție Exemplu 2. Sistem de producție:

sistemul (SP) produce piese (P) utilizând componente (C), furnizate de către alt sistem (SC). Dacă SP este ”idle” (nu este implicat deja in producția unei piese) și există disponibile 2 componente C, va produce piesa P (”consumˆand” cele 2 componente) si va trece intr-o nouă stare (SP a produs o piesă); După ce SP a produs piesa P, va depozita piesa într-un buffer și este pregătit pentru producerea unei noi piese (”idle”); SP2 poate furniza în orice moment câte o componentă C; Aplicarea Modelării cu rețele Petri Rețelele Petri sunt utilizate pentru: > modelarea concurrentelor > Sincronizarea proceselor De menționat că în calitatede Tokeni pot fi: > Resursele disponibile > locuri de muncă pentru transformare > fluxul de control > condiții de sincronizare ... Exemple modelare Petri Net 1. Starea unei mașini: Acest exemplu este oarecum trivial, o rețea petri pură, obișnuită, cu marcare inițială a unui token de stare în "start„ reprezintă o stare a mașinii. Rețeaua Petri în figura reprezintă starea unei mașini de bomboane care acceptă numai monede de 5 cenți(nikel) monede de 10 cenți (dimes), nu dă rest și vinde bomboane de 15 și 20 de cenți. Rețineți că tranzițiile sunt nedeterministe în timp, acest lucru nu înseamnă că nu poate fi modelat o mașină deterministă.

Fig. 5.17

2. Modelare procese paralele Să luăm cazul simplu în care avem un program care face un singur lucru, apoi se ramifică în două fire, fiecare dintre ele executând o sarcină independentă, apoi continuă într-un singur fir după ce ambele procese

Fig. 5.18. modelare procese paralele. 3. Modelare Flux de date O rețea Petri poate fi utilizată pentru a modela fluxul de date printr-un calcul. Prin atribuirea de nume locurilor care reprezintă valoare, putem modela cu ușurință un calcul, în care un token dintr-un loc marchează că datele pe care le reprezintă sunt disponibile pentru utilizare. Modelul reprezintă fluxul de date pentru calcul: x = (a + b) / (a-b). Rețineți că petri net nu conține nici un mecanism pentru a efectua efectiv calculele așa cum este descris.

Fig. 5.19.

-

Tipuri rețele Petri Petri Net temporizate; Petri Net Stochastice; Petri Net Functionale; Inhibitor Petri Net; Hierarchical Network; Petri Net Color; WF petri Networks.

Reţele Petri Temporale Apare deseori necesitatea descrierii aspectelor temporale ale sistemelor cum ar fi duratele unor operații. O durată este asociată cu fiecare tranziţie. Studiul sau descrierea paralelismului fără a lua în considerare duratele operaţiilor sunt deseori incomplete. Aspectul temporal poate fi utilizat la rafinarea unor operaţii, prin eliminarea unor condiţionări funcţionale inutile. Asocierea timpului la activităţile care trebuie să fie executate poate servi la planificarea lor. Prin urmare, timpul serveşte la descrierea duratelor unor activităţi, sau a întârzierii lor, la declararea cerinţelor temporale şi, în final, la verificarea respectării constrângerilor temporale. Ipoteza că tranziţiile se execută instantaneu nu poate fi acceptată în următoarele situaţii: - planificarea sarcinilor; - descrierea constrângerilor temporale;

- determinarea precedentelor; - determinarea timpului minim şi/sau maxim al unei secvenţe; - determinarea timpului probabil al unei secvenţe.

În asemenea cazuri apare necesitatea diferenţierii sarcinilor în sarcini reactive de timp real (legate de interacţiunea dintre sistem şi mediu) şi sarcini de raţionare. Introducerea aspectelor temporale se justifică mai ales la sistemele care sunt ciclice sau repetitive. Cea mai simplă variantă pentru includerea timpului se bazează pe asocierea unor atribute temporale cu nodurile reţelei. Aceasta se poate realiza condiţionând fie întârzierea jetoanelor în locaţii, pentru un anumit interval de timp, înainte de execuţia tranziţiilor, fie introducând o întârziere între momentul în care tranziţiile sunt admisibile şi momentul în care ele se execută (întârzierea tranziţiilor). Se introduce noțiunea de locaţie temporizată prin ataşarea unei valori . Ce reprezintă durata dintre momentul de timp când un jeton este introdus în locaţie şi momentul când el poate fi extras pentru execuţia unei tranziţii de ieșire. Dacă un jeton este introdus într-o locaţie temporizată, el nu prăseşte locaţia (pentru execuţia tranziţiilor de ieşire) până când nu a expirat intervalul de timp asociat locaţiei respective. Definiția 1. O reţea Petri (determinista) cu locaţii temporizate este de forma (N, Ө), unde N = (P, T, pre, post), iar Ө este o funcţie care asociază un număr real nenegativ fiecărei locaţii a reţelei, este minimul timpului de staţionare a unui jeton în . Un jeton dintr-o reţea Petri cu locaţii temporizate poate avea două stări: gata şi în aşteptare. Când un jeton este introdus într-o locaţie, el intră în aşteptare, devenind gata după un interval unităţi de timp. Jetoanele în aşteptare nu pot permite execuţia unei tranziţii, situaţia fiind asemănătoare celei în care ele nu există încă acolo. Domenii şi aplicaţii: - sisteme a căror corectitudine funcţională depinde de satisfacerea unor proprietăţi (restricţii) temporale; – sisteme critice (aviaţie, militare); – circuite asincrone de mare viteză; – sisteme de fabricaţie; controlul proceselor industriale (ex. chimice); – protocoale de comunicaţie; – în proiectare: sisteme electronice de larg consum (protocoale multimedia, controlul automobilelor); – protocoale de sincronizare a bazei de timp (sisteme distribuite, protocoale de securitate). Coloured Petri Nets - (CPN) reprezintă o extensie compatibilă cu conceptul de reţele Petri; - CPN păstrează proprietăţile utile ale reţelelor Petri şi în acelaşi timp extinde

formalismul iniţial pentru a permite distincţia dintre cipuri;  - CPN permit cipurilor să aibă o valoare de date ataşată acestora. Această valoare de date ataşată se numeşte culoarea cipului.  Deşi culoarea poate fi de tip complex arbitrar, locurile din CPN conţin, de regulă, cipuri de un singur tip. Acest tip este numit set de culori al locului. CPN (Reţele Petri Colorate):

- CPN este limbajul dezvoltat de Kurt Jensen şi alţii; - CPN acceptă extensiile în timp, culoare şi ierarhie; - CPN se bazează pe standardul ML; - CPN este suportat de Design / CPN şi CPN Tools. În 2010, sprijinul şi dezvoltarea în continuare a instrumentelor CPN s-au mutat de la Universitatea Aarhus (Danemarca) în TU / e. Versiunea 3 a fost prima versiune lansată de TU / e. Pentru mai multe informaţii: http://cpntools.org Valori şi tipuri. Sintaxa este necesară pentru a tasta locaţiile şi a da valori (culori) pentru jetoane. Preluat din Standard ML Contur: - tipuri de bază: int, string, bool, (real) şi unitate; - constructori tip: cu, produs, înregistrare, listă; - definirea constantelor. Tipuri de bază: - întregi (int), de exemplu, 5, 34234, ~32423; - reale (real), de exemplu, 34.34, ~23.0, 7e3; - şiruri de caractere (string), ex., "Hallo", "28-02-2018" ; - booleans (bool): adevărat sau fals. Unit: tip cu o singură valoare (): - ~ 32423 înseamnă -32423; - ~ 23,0 înseamnă -23; - 7e ~ 3 înseamnă 7000,0; - 4e ~ 2 înseamnă 0,04 - unitatea este utilizată pentru a reprezenta jetoanele negre (adică necolorate). Realele sunt suportate în ML, dar nu pot fi folosite ca set de culori, deoarece egalitatea este nedefinită şi prin urmare legăturile nu pot fi calculate. Operatori de bază: - pentru minusul unar; + şi - pentru reali şi întregi; * (multiplicare) pentru reali şi întregi; / (diviziune) pentru reale. Div şi mod pentru numere întregi (28 div 10 = 2, 28 mod 10 =8) =,>, =, = (mai mare decât), 1 orelse 2> 3) duce la adevărat - dacă "X" = "X" atunci 3 alte 4 rezultate în 3 Declaraţii Setări de culoare Un set de culori este un tip care este definit folosind un set de culori: • declaraţia de culoare ... = ..., 1 de exemplu,

- culoarea I = int; - culoarea S = şir; - culoarea B = bool; - culoare U = unitate. Odată declarată, poate fi utilizată pentru a mapa locaţii. Tipurile nou definite precum I, S, B, U pot fi utilizate în alte setări de culoare. Proprietăţi Petri Nets - Limitarea. Numărul de etichete din orice poziţie din reţea nu poate depăşi o anumită valoare a lui k. O poziţie este delimitată dacă numărul de marcatori în ea nu poate să depăşească întregul k. - Securitatea. Poziţia reţelei Petri este sigură dacă numărul de markere nu depăşeşte 1. Reţeaua Petri este sigură în cazul în care fiecare poziţie este în siguranţă. - Persistenţa. Anumiţi markeri reprezintă resurse, astfel de markeri nu pot fi niciodată creaţi şi distruşi, adică numărul total de markeri trebuie să fie constant. - Activitatea. Posibilitatea oricărei tranziţii când este declanşată funcţionarea obiectului simulat. - Oportunitatea. Abilitatea de a muta reţeaua dintr-o stare în alta. - Acoperirea. Capacitatea de a atinge starea în care dorim să ajungem. Un exemplu real de reţea colorată (figura 5.38). Aceasta este o versiune uşor simplificată a unei reţele preluate dintr - o lucrare introducând reţele Petri colorate, scrise de un grup care implementează un instrument de proiectare şi analiză CPN:

Fig.5.38. Exemplu real de reţea colorată

Acesta descrie un protocol de comunicare foarte simplu care funcţionează după cum urmează: 1. Există un singur expeditor şi un singur receptor. 2. Atât expeditorul, cât şi receptorul au un număr secvenţial comun, care se utilizează pentru a indica faptul că sincronizează unul cu celălalt şi că nu s-au pierdut date. 3. Expeditorul trimite un pachet de date către receptor.

4. Dacă numărul de pachet primit de receptor este corect, atunci receptorul semnalează

expeditorului că este pregătit pentru următorul pachet. 5. Dacă numărul de pachet primit de receptor nu este corect, atunci acesta semnalează expeditorului cu numărul pachetului pe care îl aşteaptă. 6. Expeditorul poate retrimite un pachet de cel mult trei ori. În această reţea, locurile verzi şi tranziţiile sunt pe expeditor; roz este receptorul; iar cu galben este reţeaua. Locurile umbrite sunt locurile care indică punctul în care chiple sunt transferate între entităţi. CPN Tools. CPN Tools cuprinde două componente principale, un editor grafic şi o componentă simulator de backend. Editorul grafic este scris în limbajul, BETA , iar backend Simulator este scris în Standard ML varianta SML / NJ. Instrumentul dispune de verificarea sintaxei incrementale şi generarea de coduri, care au loc în timp ce se construieşte o reţea. Un simulator rapid manipulează în mod eficient plasele neimpozitate şi temporizate. Spaţiile de stare complete şi parţiale pot fi generate şi analizate, iar un raport de spaţiu standard de stare conţine informaţii cum ar fi proprietăţile de limitare şi proprietăţile de viaţă. 5.2.3. Modelare prin Metode integrate Metodele de modelare integrate combină diferite tipuri de modele - analiză structurală, orientată pe obiecte, simulare etc. Ideea de bază a modelării întreprinderii, conform lui Ulrich Frank , este „de a oferi opinii diferite asupra unei întreprinderi, oferind astfel un mediu pentru a promova dialogurile între diferiți actori – atât în mediul academic, cât și în practică. În acest scop, acestea includ abstracții potrivite pentru planificarea strategică, (re) design-ul organizării și ingineria software-ului. Opiniile ar trebui să se completeze reciproc și să promoveze o mai bună înțelegere a sistemelor complexe prin abstractizări sistematice. Opiniile ar trebui să fie generice, în sensul că acestea pot fi aplicate oricărei întreprinderi. În același timp, acestea ar trebui să ofere abstracții care să ajute la proiectarea sistemelor informatice care sunt bine integrate în strategia pe termen lung a companiei și în organizarea acesteia. Prin urmare, ”modelele de întreprinderi pot fi considerate infrastructuri conceptuale care susțin un nivel ridicat de integrare.” Modelarea întreprinderilor este procesul de construire a modelelor întregii sau a unei părți de întreprindere cu: - modele de proces, - modele de date, - modele de resurse și / sau noi ontologii etc. Se bazează pe cunoștințele despre întreprindere, modelele anterioare și / sau modelele de referință, precum și ontologiile de domeniu folosind limbaje de reprezentare a modelului. O întreprindere, în general, este o unitate de organizare sau activități socialeconomică. Aceste activități sunt necesare pentru dezvoltarea și furnizarea de produse și / sau servicii unui client. O întreprindere include o serie de funcții și operațiuni cum ar fi achiziția, producția, marketingul, finanțarea, ingineria, cercetarea și dezvoltarea. Întreprinderea de interes sunt

acele funcții și operații corporative necesare pentru fabricarea variantelor actuale și potențial viitoare ale unui produs.

Fig. 5.20. integrare model de procese și model de date Modelarea procesului de afaceri abordează probleme importante: Cum se potrivesc toate? Va funcționa? De ce avem nevoie? Cum o facem? Cine o poate face? Cât de important este? Unde merge? Cine este supraîncărcat? Cum am făcut? Modelează Interrelațiile între procese Simulează realități alternative Oferă cerințe de resurse Externalizează regulile și fluxul Definește rolurile Definește prioritățile Rutare inteligentă a Traseelor Balansare Cozi Oferă statistici ale fluxului de lucru

Fig.5.21. Obiectivele managementului proceselor de afaceri Printre Metodele de modelare integrate pot fi menționate: • ARIS (Architecture of Integrated Information System) vă permite să reflectați într-un singur model integrat: structuri organizaționale, funcții, date, procese. Utilizează multe tipuri de modele. • G2 - o metodologie pentru crearea sistemelor inteligente dinamice vă permite să simulați procese folosind cunoștințe de specialitate. • BRM (Business Rules Management) - o metodologie pentru gestionarea regulilor de afaceri.

Metode integrate

Fig. 5.21. Modelare cu unele metode integrate 5.2.3.1. Metoda ARIS ARIS înseamnă arhitectura sistemelor informatice integrate. Este un concept cadru folosit pentru a descrie companiile și sistemele de aplicații pentru afaceri. Conceptul ARIS și tipurile de model ARIS pot ajuta la reprezentarea structurii de afaceri a unei companii, aplicații software și/sau proceduri. Această metodă oferă posibilitatea în mod cuprinzător de a reflecta documentația, structura organizatorică și procedurală a companiei și/sau a persoanei fizice și zone ale acestor entități. • ARIS este o colecție de instrumente pentru dezvoltarea și optimizarea proceselor de afaceri. Este vizată mai degrabă dezvoltarea unei soluții IT, decât documentarea și înțelegerea afacerii, ceea ce va duce la implementarea a noi procese de afaceri în modelele tradiționale de antrepriză.

Arhitectura ARIS distinge patru viziuni: Organizare, Funcțională, Informațională și Control. Utilizează un sistem de modelare grafică susținut de software care modelează mișcarea sarcinilor și a datelor. ARIS se concentrează pe faza de analiză și definire a cerințelor în timpul proiectării sistemelor informaționale manageriale, nu pe executarea proceselor de afaceri. ARIS oferă un cadru metodologic generic și bine documentat. Este strâns asociat cu SAP către care poate exporta direct modele pentru încorporarea în sistemele SAP. • Software-ul este complex și are un traseu de învățare relativ lungă. Pe scurt despre SAP Systems Applications and Products in Data Processing. Software-ul SAP ERP are mai multe module principale, care sunt separate în module funcționale și module tehnice, fiecare având submodule. Modulele funcționale ale SAP includ: - Managementul capitalului uman (SAP HCM) - Planificarea producției (SAP PP) - Managementul materialelor (SAP MM) - Sistem de proiect (PS SAP) - Vânzări și distribuție (SAP SD) - Întreținerea fabricației (SAP PM) - Finanțe și control (SAP FICO) - Managementul calității (SAP QM) În ARIS, procesele de afaceri sunt descrise prin diagramele lanțului de proces. Modelarea se face folosind un set de instrumente în loc de limbaj. Mai multe sub-instrumente sunt disponibile, fiecare afișat în propria fereastră. Informațiile captate de setul de instrumente ARIS sunt stocate într-o bază de date după ERM (Entity-Relationship-Model).

Fig. 5.22. Modelul cadru ARIS ARIS se concentrează pe faza de analiză și definire a cerințelor în timpul proiectării sistemelor informaționale manageriale, nu pe executarea proceselor de afaceri. Arhitectura sistemelor informatice integrate (ARIS) se bazează pe un concept de integrare derivat dintr-o viziune holistică a proceselor de afaceri. Primul pas în crearea arhitecturii este dezvoltarea unui model de proces de afaceri care să conțină toate caracteristicile de bază pentru descrierea proceselor de afaceri. Rezultatul este un model extrem de complex, care este descompus în puncte de vedere individuale, astfel încât complexitatea acestuia se reduce. Datorită acestei decompoziții, este posibilă descrierea conținutului viziunilor individuale prin metode speciale adecvate pentru o perspectivă specifică, fără a fi necesar să acorde atenție numeroaselor interrelații a vizualizărilor. Relațiile dintre puncte de vedere sunt încorporate într-o etapă finală și combinate pentru a forma o imagine de ansamblu a lanțurilor de proces fără nicio redundanță. O a doua abordare care reduce complexitatea este o diferențiere prin descrieri. În urma conceptului ciclului de viață, diferitele metode de descriere a sistemelor informaționale sunt clasificate în funcție de proximitatea lor cu tehnologia informației. Aceasta asigură o descriere consecventă, de la problemele de gestionare a afacerilor până la implementarea tehnică. Astfel, conceptul ARIS este un cadru pentru dezvoltarea și optimizarea sistemelor informatice integrate și pentru descrierea implementării acestora. Deoarece accentul se pune pe nivelul tehnic descriptiv, conceptul ARIS servește ca model pentru crearea, analiza și evaluarea lanțurilor proceselor de gestionare a afacerilor. Puncte de vedere ARIS Viziunea produs / serviciu descrie relațiile dintre produse / servicii. Viziunea funcției conține descrierea funcției, o enumerare a subfuncțiilor individuale care fac parte din contextul general și relațiile care există între funcții. Viziunea organizației subsumează utilizatorii și unitățile organizaționale, precum și relațiile și structurile acestora.

Vizunea resurselor oferă condiții generale pentru descrierea altor componente care sunt orientate mai direct către gestionarea afacerilor. Din acest motiv, componentele celorlalte puncte de vedere sunt descrise în ceea ce privește apropierea lor de resursele tehnologiei informației. Astfel, resursele sunt tratate la specificațiile de proiectare și la implementarea celorlalte puncte de vedere. Modelul ciclului de viață care este definit ca urmare a abordării descriptive la nivel înlocuiește vizualizarea resurselor ca un obiect independent de considerare. Viziunea de control este oferită ca o vedere suplimentară pentru descrierea relațiilor dintre viziuni. Combinarea acestor relații într-o perspectivă separată permite înregistrarea sistematică și fără redundanță a tuturor relațiilor. Viziunea controlului este o componentă esențială a ARIS care o distinge de alte abordări de arhitectură. Dscrierea problemelor de gestionare a afacerilor. Obiectele individuale sau zonele de interes sunt modelate în arhitectura ARIS (viziuni și niveluri) pe baza situației inițiale de afaceri, cum ar fi de exemplu, problema de gestionare a afacerii. Descrierea menționează punctele slabe pe care sistemele informaționale utilizate în prezent le au în ceea ce privește sprijinul pe care îl oferă pentru procesele de afaceri existente și include, de asemenea, conținutul principal al conceptului țintă pentru sistemul care urmează să fie dezvoltat. La rândul său, conceptul țintă reflectă obiectivele urmărite prin utilizarea noilor sisteme informaționale. Utilizarea modelului pentru descrierea problemei de gestionare a afacerii trebuie să aibă capacitatea de a înregistra cât mai multe fapte posibil din datele, funcțiile și opiniile organizației, inclusiv interrelațiile acestora. Dgrama lanțului de procese O diagramă a lanțului de proces reprezintă un lanț de proces închis. Toate viziunile unui proces de afaceri (viziunea organizațională, viziune datelor, viziunea funcțiilor, viziunea resurselor) sunt exprimate cu relațiile lor într-o formă coerentă. Cele două coloane din stânga reprezintă secvența operațională cronologic-logică a procesului de afaceri analizat. Funcțiile individuale ale procedurii sunt enumerate în a doua coloană și sunt legate de evenimentele prin care sunt declanșate și pe care le generează. Conexiunile dintre funcții și evenimente definesc exact ce evenimente declanșează funcțiile și care evenimente sunt generate de funcții și reglează astfel fluxul de control între funcții.

Fig. 5.23. Semantica platformei ARIS 5.2.3.2. Platforma G2. Mediu grafic pentru crearea aplicațiilor inteligente. Platforma G2 este un mediu orientat pe obiecte pentru dezvoltarea și întreținerea aplicațiilor în timp real care utilizează baze de date. Gensym G2 oferă un mediu grafic pentru crearea aplicațiilor inteligente care monitorizează, diagnostică și gestionează evenimente dinamice în medii în rețea și simulate. Mediul G2 folosește un limbaj natural structurat, pentru a crea reguli, modele și proceduri. Sistemul expert G2 este baza tuturor aplicațiilor Gensym. Programele includ G2, un adaptor video care permite utilizarea unui mediu de programare vizuală pentru a crea aplicații inteligente de control. Capacitățile instrumentului G2 propus sunt următoarele: Tehnologie orientată spre obiecte: · Comunicări între obiecte; · Relații între obiecte; · Ierarhia obiectelor. Prezentarea cunoștințelor: · Reguli (generale și specifice); · Proceduri; · Modele dinamice. Mecanismul de motivare: · Din date; · Din obiectiv; · Scanare; · Meta-raționament (evenimente, concentrându-se pe clase de obiecte sau reguli); · Implementarea simultană a regulilor și / sau a procedurilor. · Definirea grafică a obiectelor. · Clonarea obiectelor și a grupurilor lor. · Interfețe grafice pentru diverse categorii de utilizatori.

· Dezvoltare de aplicații cooperatiste multi-utilizatori. · Aplicație distribuită. G2 este platforma lideră a companiei Gensym pentru dezvoltarea și implementarea aplicațiilor expert. Aplicațiile G2 măresc semnificativ productivitatea prin: - Monitorizare continuă, asigurând identificarea potențialelor probleme înainte ca acestea să poată avea un impact negativ asupra activității; - Transformarea datelor de lucru complexe în informații semnificative, prin analizarea acestora folosind modele și algoritmi bazate pe baze de cunoștințe; - Diagnosticarea cauzelor principale în identificarea problemelor în aplicații care sunt critice în timp și recomandă acțiuni adecvate; - Menținerea condițiilor optime de lucru și coordonarea acțiunilor și schimbul de informații în procesele complexe de lucru. Proectare

Prognoză

Cunsltare

Cunoștințe

Optimizare

Automatizare

Platforma regulilor G2 Proectare și modelare

Baze de date

Sist. Inf. Procese tehnologoce

Identificare - reacții

Sisteme de rețea

Practici și politici

Fig. 5.24. platform G2 G2 creează un mediu cuprinzător pentru dezvoltarea rapidă și livrarea soluțiilor expert. Fără îndoială, o creștere a productivității dezvoltării soluțiilor de până la 10 ori în comparație cu performanțele obținute prin abordările tradiționale de programare. Platforma G2 se distinge prin: - Stabilitate și fiabilitate dovedită pentru lucrul cu aplicații critice mari; - Arhitectură în timp real pentru operațiuni care sunt strict reglementate în timp; - Proiectare grafică orientată pe obiecte pentru prezentarea intuitivă a aplicațiilor; Reguli și proceduri personalizabile care reduc semnificativ efortul de dezvoltare; - Reguli, proceduri și expresii ale limbajului natural care fac ca aplicațiile să fie mai inteligibile și mai ușor de întreținut;

- Modelare și simulare dinamică încorporată pentru prototipare rapidă, teste preliminare înainte de a merge online, compararea lucrărilor efective și prezise și analiza ”ce-dacă”; - Conectivitate deschisă pentru comunicare bidirecțională performantă cu diferite sisteme, utilizând standarde industriale pentru compatibilitate; - Posibilitatea procesării distribuite a datelor și a muncii pe sistemul „client - server” pentru a crește scalabilitatea sistemului; și - Multi-sistem, ce oferă posibilitatea de a lucra în mai multe platforme. - Un set de medii de instrumentale, grupate după orientarea pe probleme, acoperă toate etapele procesului de producție și este următorul: - Managementul inteligent al producției - Asistent de diagnostic G2 (GDA), Controlul statistic al proceselor (SPC). - Planificare operațională - G2 Scheduling Toolkit (GST), Dynamic Scheduling Packadge (DSP); - Dezvoltarea și modelarea proceselor de producție - G2, ReThink. - Managementul operațiunilor și rețelei corporative - Expert Fault. 5.2.3.3. Sistemul de gestionare a regulilor de afaceri (BRMS) Sistemul de gestionare a regulilor de afaceri (BRMS - Business Rules Management) este o platformă tehnologică construită pentru a implementa, administra și executa logica de afaceri și a proceselor de luare decizie. BRMS sunt, de obicei, cu coduri reduse și ușor de utilizat, care le permit non-inginerilor să gestioneze procesele de luare decizie care anterior cereau eforturi tehnice extinse. Adesea constau într-un mediu de dezvoltare (unde se gestionează regulile) și un motor de decizie (care execută decizii). - BRMS - - este utilizat pentru a dezvolta, stoca, edita și executa reguli de afaceri. - Regulile de afaceri sunt enunțuri logice care definesc comportamentul și funcționarea unei afaceri. De exemplu, „dacă un utilizator își anulează abonamentul, trimitei un e-mail.” Aceste reguli pot fi scrise în documente de proces sau încorporate în aplicații. Deoarece nu este necesară codarea, implementarea este rapidă - munca care dura luni întregi pentru a fi pusă în aplicare și testare poate fi finalizată în câteva zile - iar procesele de luare decizie sunt transparente și ușor de înțeles, întrucât sunt scrise în limba naturală și nu într-un limbaj de programare. Un BRMS acționează ca un depozit central pentru regulile de afaceri. Posesorii de decizii și angajații IT pot colabora pentru elaborarea versiunii și editarea regulilor într-un mediu unic. Un BRMS ajută companiile să automatizeze sarcinile, să îmbunătățească coerența și să reducă schimbările ce sunt generate de schimbare a politicilor companiei. Ce fel de logică de afaceri poți pune într-un BRMS? • Cel puțin, un BRMS vă permite să creați reguli sub forma „dacă are loc acest lucru, atunci se întîmplă asta”. • Unele BRMS duc acest lucru mult mai departe, permițându-vă să construiți procese extrem de coplicate fără a scrie careva cod. Acest lucru revoluționează modul în care întreprinderile pot automatiza luarea deciziilor, deoarece acum este posibil ca „oamenii

de afaceri” să implementeze și să desfășoare logica (sau, cel puțin, să o citească și să o înțeleagă!). (Vezi DigiFi’s BRMS). • BRMS conține de obicei numeroase instrumente pentru gestionarea și măsurarea impactului regulilor de afaceri. • Un BRMS include cel puțin: - Logica decizională externalizată din codul principal al aplicației - Instrumente pentru gestionarea logicii decizionale - Un API expus care invocă motorul regulilor de afaceri

Serviciul decizional

Deposit de reguli

Server de reguli Motor de reguli

mediu de dezvoltare integrat

cerere de gestionare a regulilor

Aplicație externă extragerea regulilor dinamice

Reguli dinamice Versiune

Sursa de date

Acces

Fig. 5.25. Arhitectura BRMS Depozitul de reguli Un depozit de reguli de afaceri este un sistem în care compania folosește pentru a documenta, actualiza și păstra urmărirea necesităților și regulilor de afaceri cu privire la proiectele dvs. Având un depozit central la stocarea acestor reguli va permite dezvoltatorilor și proprietarilor de afaceri accesul la reguli și orice întrebări privind proiectele de afaceri. Serviciul decizional Serviciu de decizie este o componentă software care acționează ca o logică de afaceri (cutie neagră) De obicei, aceasta este o componentă a unui serviciu care încapsulează logica de afaceri necesară pentru a lua decizii de afaceri și care este numit de aplicații care nu conțin înșiși această logică. Într-o astfel de arhitectură, aceasta comunicarea utilizează de obicei servicii web. •

5.2.4. Metode structurale

Metoda structurală se bazează pe descompunerea sistemului în subsisteme tot mai detaliate.

Principii la abordarea structurală: - „Divizare și gestionare” - divizarea problemelor complexe în ma multeși mai mici sarcini, ușor de înțeles și de rezolvat; - ”Ordonare ierarhică” - organizarea componentelor unei probleme în structuri de arbori ierarhici.

Metode structurale

fig.5.26. Metode structurale

-

-

-

Două abordări în metode structurale: modelarea structural - funcțională și modelarea structurii datelor Cele mai utilizate metodologii: IDEF0 - modelarea funcțională bazată pe metoda SADT; IDEF3 - modelarea fluxurilor (prceselor) de lucru; IDEF5: Captura şi descrierea ontologiei; IDEF9: Descoperirea constrângerilor de afaceri. DFD - modelarea fluxurilor de date; IDEF1X - modelarea datelor bazată pe metoda entități – relații (ERD);

5.2.4.1. Conceptul Standardelor IDEF (IDEF0, IDEF1X, IDEF3, DFD, IDEF5, IDEF9)

In funcție de natura sistemului, unele modele pot fi mai importante decat altele. De exemplu, pentru unele sisteme sunt mai importante aspectele structurale și funcționale, pentru altele aspecte temporale. Construirea modelelor este ghidată de metode. O metoda definește o abordare reproductibilă care permite obținerea de rezultate fiabile în mod repetat. Toate domeniile cunoașterii utilizează metode mai mult sau mai puțin sofisticate și mai mult sau mai puțin formalizate. De exemplu, bucatarii utilizează rețete de bucătărie, muzicienii urmează reguli de compoziție. Constructorii respectă arhitectura... Modelele sunt alcatuite din elemente de modelare care constituie concepte fundamentale pentru reprezentarea sistemelor sau a fenomenelor.

Elementele de modelare deobicei sunt notații grafice. Ele constituie limbajul de modelare. E de menționat că față de limbajul de modelare, o metodă definește reguli de aplicare care descriu coordonarea diferitelor puncte de vedere, inlanțuirea acțiunilor, ordonarea sarcinilor și repartizarea responsabilităților. Principalele scopuri ale modelării sistemelor informatice sunt:  vizualizarea, ca mijloc de ușurare a comunicării și ințelegerii;  specificarea, prin construirea de modele precise, neambigue și complete;  documentarea cerințelor, a soluțiilor de proiect și a modului de realizare. Diverse metode sunt aplicate pentru modelare și proiectare sisteme care prezintă caracteristici ale ciclului de viaţă dorite cum ar fi: flexibilitate, receptivitate, scalabilitate, mentenabilitate, usurinta de utilizare, integrare, performanţă şi pentru angajarea echipelor de oameni în activităţi critice de dezvoltare a ciclului de viaţă al sistemului. Un limbaj de modelare este orice limbaj artificial, care poate fi folosit pentru a exprima informaţii sau cunoştinţe sau sisteme într-o structură care este definită de un set consistent de reguli. Regulile sunt folosite pentru a interpreta rostul componentelor în structura. IDEF (Integration DEfinition Functions) este o familie de limbaje de modelare în domeniul sistemelor şi ingineriei software. Acestea acoperă o gamă largă de utilizări, de la modelarea funcţională la date, simulare, analiza / proiectarea obiect-orientata şi achiziţia de cunoştinţe. Aceste "limbaje de definiţie" au fost elaborate în conformitate cu finanţarea de la US Air Force şi, deşi încă cel mai frecvent folosite de acestea, precum şi alte agenţii militare şi Departamentul de Aparare (DoD), acuma sunt și în domeniul public. a) Noţiuni generale ale Conceptului IDEF În etapa de proiectare se construiesc modele care redau arhitectura sistemului, alocarea cerinţelor pe subsisteme, distribuţia proceselor în sistem, sincronizarea lor, stările şi tranziţiile între stări. Alte modele descriu realizarea fizică a sistemului, echipamentele din componenţa sa şi repartiţia componentelor program. Fiecare vedere asupra unui sistem poate avea aspecte structurale şi aspecte comportamentale. În funcţie de natura sistemului, unele modele pot fi mai importante decât altele. De exemplu, pentru unele sisteme sunt mai importante aspectele structurale şi funcţionale, pentru altele aspectele temporale. Construirea modelelor este ghidată de metode. O metodă defineşte o abordare reproductibilă care permite obţinerea de rezultate fiabile în mod repetat. Toate domeniile cunoaşterii utilizează metode mai mult sau mai puţin sofisticate şi mai mult sau mai puţin formalizate. De exemplu, bucătarii utilizează reţete de bucătărie, arhitecţii construiesc planuri, muzicienii urmează reguli de compoziţie. Modelele sunt alcătuite din elemente de modelare care constituie concepte fundamentale pentru reprezentarea sistemelor sau a fenomenelor. Elementele de modelare sunt adesea notaţii grafice. Ele constituie limbajul de modelare. E de menţionat că faţă de limbajul de modelare, o metodă defineşte reguli de aplicare care descriu coordonarea diferitelor puncte de vedere, înlănţuirea acţiunilor, ordonarea sarcinilor şi repartizarea responsabilităţilor. Principalele scopuri ale modelării sistemelor informatice sunt: -vizualizarea, ca mijloc de facilitare a comunicării şi înţelegerii;

-specificarea, prin construirea de modele precise, neambigue şi complete; -documentarea cerinţelor, a soluţiilor de proiectare şi a modului de realizare; -aplicarea diverselor metode pentru modelarea şi proiectarea sistemelor care au caracteristici ale ciclului de viaţă dorite cum ar fi: flexibilitate, receptivitate, scalabilitate, mentenabilitate, ușurinţa în utilizare, integrare, performanţă şi pentru angajarea echipelor de oameni în activităţi critice de dezvoltare a ciclului de viaţă al sistemului; - un limbaj de modelare este orice limbaj artificial, care poate fi folosit pentru a exprima informaţii sau cunoştinţe sau sisteme într-o structură ce este definită de un set consistent de reguli. Regulile sunt folosite pentru a interpreta rostul componentelor în structură; - IDEF (IntegrationDEFinition) este o familie de limbaje de modelare în domeniul sistemelor şi ingineriei software. Acestea acoperă o gamă largă de utilizări, de la modelarea funcţională la date, simulare, analiza / proiectarea obiect-orientată şi achiziţia de cunoştinţe. Aceste "limbaje de definiţie" au fost elaborate în conformitate cu finanţarea de la US Air Force şi, deşi încă cel mai frecvent folosite de acestea, precum şi alte agenţii militare ca şi Departamentul de Apărare (DoD), sunt aplicate şi în domeniul public: -IDEF0: Modelarea funcţională; -IDEF1: Modelarea informaţiei; -IDEF1X: Modelarea datelor; -DFD: Modelarea fluxurilor de date -IDEF3: Captura descriere şi modelare procese; -IDEF5: Captura şi descrierea ontologiei; -IDEF9: Descoperirea constrângerilor de afaceri. IDEF0: Modelarea funcţională - metoda modelării funcţionale IDEF0 este destinată să modeleze deciziile, acţiunile şi activităţile unei organizaţii sau unui sistem. IDEF0 - metodologie pentru simularea funcţională. IDEF0 este sistemul de studiu la un set de funcţii interdependente (blocuri de funcţii). De regulă, instrumentul de modelare IDEF0 este primul pas în analiza şi studiul oricărui sistem. IDEF1: Modelarea informaţiei - metodologie privind modelarea fluxurilor informaţionale în cadrul companiei sau a sistemului. Permite a fi afişată şi analizată structura fluxurilor informaţionale şi relaţiile lor. IDEF1X: Modelarea datelor - IDEF1X (IDEF1 extinsă) - metodologie de construcţie a structurilor relaţionale. IDEF1X se referă la tipul de metodologii Esenţa relaţiei (ER - entitaterelaţie) şi este utilizată pentru modelarea bazelor de date relaţionale relevante pentru acest sistem. DFD: Modelarea logică a fluxurilor de date IDEF3: Captura descriere şi modelare procese - metodologie privind documentarea proceselor care au loc în sistem. Cu IDEF3 se descriu scenariile şi secvenţele de operaţii pentru fiecare proces. IDEF3 este direct legată de metodologia IDEF0 - fiecare funcţie (unitate funcţională) poate fi reprezentată prin intermediul IDEF3 ca un proces separat. IDEF5: Captură descriere ontologie IDEF5 - metodologie ontologică privind cercetarea sistemelor complexe. Cu ajutorul unui dicţionar de termeni şi norme permite a descrie şi a formaliza sistemul ontologic. IDEF5 sau Integrated Definition este o metodă de inginerie software pentru a dezvolta şi a menţine ontologii utilizabile, exacte. În domeniul ontologiilor informatice sunt utilizate pentru a captura concepte şi obiecte într-un domeniu specific, împreună cu relaţiile şi semnificaţiile asociate. În plus, captarea ontologiei contribuie la coordonarea

proiectelor prin standardizarea terminologiei şi creează oportunităţi pentru reutilizarea informaţiilor. Metoda de capturare a ontologiei lDEF5 a fost dezvoltată pentru a construi fiabil ontologii într-un mod care reflectă strâns înţelegerea umană a domeniului specific. În metoda IDEF5, o ontologie este construită prin captarea conţinutului anumitor afirmaţii despre obiectele din lumea reală, proprietăţile şi relaţiile lor care reprezintă acel conţinut într-o formă intuitivă şi naturală. Metoda IDEF5 are trei componente principale: un limbaj grafic pentru a sprijini analiza ontologiei conceptuale, un limbaj text structurat pentru caracterizarea ontologiei detaliate, precum şi o procedură sistematică, care oferă liniile directoare pentru a captura ontologia eficient. IDEF9: Descoperirea constrângerilor de afaceri IDEF9 sau Integrated Definition pentru descoperirea constrângerilor în mediul de afaceri este conceput pentru a ajuta la descoperirea şi analiza constrângerilor într-un sistem de afaceri. Motivaţia principală pentru stimularea dezvoltării IDEF9 a fost recunoaşterea faptului că o colecţie de constrângeri care fabrică un sistem de întreprindere este, în general, slab definită. Cunoaşterea constrângerilor ce există şi a modului în care interacţionează aceste constrângeri este incompletă, disjunctă, distribuită şi de multe ori complet necunoscută. Această situaţie nu este neapărat alarmantă. La fel, ca şi organismele vii, nu trebuie să fie conştienţi de constrângerile genetice sau autonome care guvernează anumite comportamente, organizaţiile pot (şi cele mai multe o fac) să funcţioneze bine fără a cunoaşte explicit care sunt structurile sistemului. Cu toate acestea, în cazul în care există dorinţa de a modifica afacerile într-un mod previzibil, cunoaşterea acestor constrângeri este la fel de critică ca şi cunoştinţele de genetică pentru ingineria genetică. a) Noțiune de Domeniu Conform DEX noțiunea de domeniu are mai multe definiții. Îsă pe noi ne interesează definițiile 5.  ”Cuprinsul unei științe, al unei arte” și 6. ”Sferă de activitate”.  Domeniu ca ”Cuprinsul unei științe, al unei arte” sau ca ”Sferă de activitate”.  Domeniul este caracterizat de un set denumit și definit prin mai multe valori și atribute pe care îl reprezintă. Domeniul este definit separat de entități și puncte de vedere, în scopul de a permite reutilizarea și standardizarea lor în întreaga antrepriză. Un domeniu este considerat o clasă pentru care există o structură fixă și eventual un set infinit de cazuri. Domeniile ca clase imuabile ale căror valori nu se modifică în timp. Fiecare instanță în domeniu are o valoare unică într-o reprezentare - adică, unic în acest domeniu. De exemplu, Codul de Țară ar fi considerat un domeniu în care setul de valori admisibile pentru domeniu ar satisface definiţia unui cod de stat (adică unicul identificator al unei stări) şi abrevierile de două litere ale statelor. Fiecare instanţă domeniu are o valoare unică într-o reprezentare - adică, unică în acest domeniu figura 5.27 (a,b):

Fig.5.27, a). Semantica domeniului

- Structură ierarhică - fiecare activitate este nod în arbore - fiecare nod este etichetat și indicată: Activitatea părinte Poziția în arbore

Fig.5.27, b). Semantica domeniului

Eexistă două tipuri de domenii: domeniul de bază şi domeniul tastat (tip); Unui domeniu de bază îi poate fi atribuit un tip de date care poate fi unul dintre următoarele: caracter, numeric sau boolean. Pot fi utilizate şi alte tipuri de date, cum ar fi data, ora, binar etc.; domeniului de bază de regulă i se atribuie: 1) o regulă de domeniu; 2) normele de domeniu. Normele de domeniu sunt folosite pentru a furniza valori acceptabile ale unui domeniu. Cele două reguli de domeniu sunt comune pentru lista de valori, precum şi pentru regulile de intervale. Domeniile tip sunt subtipuri ale domeniului de bază sau alte domenii tipizate, care pot constrânge în continuare valorile pentru domeniu. Un domeniu tip există, în cazul în care acesta este de tipul de date şi respectă regulile de domeniu din domeniul său superior. În acest fel, o ierarhie de domenii poate fi definită cu reguli de domeniu din ce în ce mai stricte, mergând în jos

pe ierarhie. O ierarhie de domeniu este o ierarhie generalizată figura. Trebuie de reţinut că domeniile tip nu se exlud reciproc. Exemple domenii: 1. domeniul AGRICULTURA: - Cultura plantelor - cereale care cuprinde:  grâul, secara, triticale, orzul, ovăzul, porumbul, sorgul, meiul, orezul și hrișca plante industriale – Principalele plante tehnice cultivate de om sunt: floareasoarelui, rapiță, sfeclă  de  zahăr,  in,  cânepă,  hamei,  tutun și soia. Plante leguminoase – al căror fruct este o păstaie – fasole, linte, năut, mazăre, soia, caju, arahide,... Legumele – cartoful, castravetele, varza, conopida, dovlecelul, pepenele galben, pepenele verde, gulia, prazul, leușteanul, tomate, ardeiul, mărarul, vânăta, ceapa, usturoiul,... Fructe - .......... 1. Domeniul educație

Fig.5.28. Decompoziţie domeniului Învățământ Contextul funțional al acestui domeniu: CODUL EDUCAȚIEI AL REPUBLICII MOLDOA, COD Nr. 152  din  17.07.20 CADRUL NAŢIONAL AL CALIFICĂRILOR Învăţămînt Superior 2. Domeniului – Frecvențe

Fig.5.29. Decompozoția domeniului frecvențe. Contextul funțional al acestui domeniu:

Legea Nr. 241 din 15.11.2007 Comunicații electronice Regulamentului privind monitorizarea frecvenţelor radio şi evaluarea parametrilor tehnici de emisie ai staţiilor de radiocomunicaţii de utilizare  neguvernamentală a) Contextul funcțional/organizațional al domeniului Standardului ISO 9001:2015 ( managementul calității) pune accentul pe contextul organizațional și funcțional al unei organizații. - Intenția de bază este ca organizațiile să obțină un nivel cât mai ridicat de înțelegere referitor la domeniul de activitate al acestora, - precum și asupra celor mai importante probleme care pot afecta sistemul de management aplicat, fie în sens pozitiv, fie negativ, - având în vedere factorii cheie interni și externi care au impact asupra organizației și, implicit, asupra proiectării sistemului de management.  Capitol 4.1 din acest standard – ”Înţelegerea organizaţiei şi contextul acesteia” impune organizaţiei să ia în considerare o gamă largă de potențiali factori care pot avea un impact asupra sistemului de management. Pentru aceasta se aplică diferite metode de a identifica acești potențiali factori Există mai multe metode și abordări practice care pot fi utilizate pentru a obţine aceste informaţii. O Metodă utilă pentru identificarea aspectelor externe provenite din diverse domenii analiza PEST (fig.30)

Fig.5.30. Analiza PEST a domeniului

P –  factorii de ordin politic Aceștia pot influența organizația prin intermediul evoluției legislative, nivelului taxelor sau al diverselor facilități fiscale existente la un anumit moment, tensiunilor etnice sau ale corupției etc., factori care ar trebui să influențeze deciziile de acțiune. De asemenea, un aspect important îl   constituie și gradul de stabilitate politică. De exemplu, dacă organizaţia se bazează pe materii prime provenite dintr-o țară care se confruntă cu instabilitate politică, viabilitatea organizației ar putea fi pusă în pericol.   Dacă nu cunoaștem aceste modificări, atunci organizația se poate confrunta cu probleme serioase, în timp ce utilizarea “inteligentă” a acestora, cât mai curând posibil, ar putea reprezenta oportunități.  E  – factorii economici Dinamica factorilor macro-economici (inflație, PIB, șomaj, rata dobânzii), nivelul de consum în rândul populației, dinamica prețurilor, nivelul competitivității economice naționale, dezvoltarea economică globală ar putea avea un impact major asupra organizației și, ca urmare, este necesară o analiză profundă înainte de orice luare de decizie.   S  – factorii de ordin social-cultural  În această categorie putem include nivelul educațional, stilul de viață al populației, atitudinea față de calitate a consumatorului și a mass-media, media de vârstă, structura populației după diverse criterii, nivelul de trai, factori demografici și migrarea populației în afara țării etc.  T – factorii  tehnologici Inovațiile și evoluțiile tehnologice reprezintă, de asemenea, aspecte critice pentru succesul organizației: orientarea către energia verde, utilizarea pe scară largă a tehnologiei informației care permite accesul rapid la informații sau diverse servicii, nivelul competiției în dezvoltarea tehnologică, fonduri alocate cercetării, modalități de acces la tehnologie etc.  NOTĂ Numai dupe efectuarea acetei acțiuni de depistare și analiză a factorilo ce au sau pot avea un ipact fie pozitiv sau negativ trecem la procesul de modelare funcțional-structurală a domeniului de interes a) Diagrama de context (Context Diagram) Diagrama de context: este un model al funcţiei din Domeniul (obiectul) la cel mai înalt nivel de intrări, control, mecanisme şi ieşiri: -intrări: elemente care declanşează activitatea;

-control: ghidează sau reglează activitatea; -mecanisme: sisteme, oameni, echipamente utilizate pentru a efectua activitatea; -ieşiri: rezultatele efectuării activităţii.

5.2.4.1. Modelarea funcţiilor standardul IDEF0 Esenţa abordării structurale. Principiile de bază ale abordării structurale. Esenţa metodologiei abordării funcţionale IDEF0. Noţiuni principale privind metodologia IDEF0. Reguli de construire a modelelor în IDEF0. Exemple de modele funcţionale în notaţia IDEF0. Abordarea structurală a domeniului La abordarea structurală Sistemul este divizată în subsisteme funcționale, care la rândul lor se divizează în subfunții, aceste subfuncții sunt compuse din aplicații concrete Subsistem Funcțional 1 SISTEMA

Subsistem Funcțional 2

…

SUBFUNCȚIA 2

…

Subsistem Funcțional n

Aplicație 1

SUBFUNCȚIA 1

… Aplicație 2

…

… … SUBFUNCȚIA n

…

Aplicație n

Fig.5.31. Decompoziţia structurală a domeniului

Principiile de bază ale abordării structurale: -principiul «divide şi domină»; -principiul structurare ierarhică; -principiul de abstracţie; -principiul eliminare conflicte; -principiul structurare date. Modele ce se construiesc pentru abordarea structurală În abordarea structurală sunt utilizate următoarele tipuri de modele prezentate în tabelul 5.1: a) modele funcţionale (МF); b) modele informaţionale (МI); c) modele dinamice (МD). Tabelul 5.1. Modele pentru abordarea structurală МF

SADT (IDEF0)-Modele DFD-Modele

Aplicaţii BPWin, Design/IDEF Aplicaţii BPWin

МI

ERD (IDEF1X)

Aplicaţii Design/IDEF, ERWin

МD

IDEF/CPN IDEF3

Aplicaţii Design/IDEF Aplicaţii BPWin

Standardul IDEF0. Modelarea funcţiilor. IDEF0 modelează: -deciziile;

-acţiunile; -activităţile unei organizaţii; -activităţile unui sistem pentru a identifica perspectiva funcţională a sistemului. Crearea modelelor IDEF0 este una dintre primele sarcini în dezvoltarea unui sistem, deoarece: - descriu funcţiile care sunt efectuate; - descriu ce este necesar pentru a realiza aceste funcţii; - descriu sintaxa (ontologia). Primul pas spre modelarea funcţională este determinarea contextului funcţional al sistemului ce va fi creat. În acest scop se creează diagrama de context (figura 5.32, a; 5.32, b). La elaborarea diagramei de context se identifică funcţionalul principal şi cele patru tipuri de conexiuni ale sistemului cu mediul exterior: intrările, ieşirile, controlul şi mecanismele ce asigură procesele funcţionalului principal.

Fig.5.32, a). Diagrama de context: dreptunghiurile reprezintă activităţi (verbe); săgeţile reprezintă entităţi (lucruri).

Fiecare cutie (dreptunghi) este etichetată, indexată şi cu săgeţi care reprezintă: - input: "lucrurile" transformate de sistem; - output: în care sunt transformate intrările; - control: constrângeri / reguli ale unei activităţi în procesul de transformare; - mecanisme: resurse / instrumente necesare pentru asigurarea procesului. Apelurile sunt un tip de săgeţi de mecanism care permit schimbul de informaţii cu alte modele sau subsecţiuni ale modelului. Al doilea pas la modelarea funcţională este decompoziţia funcţionalului principal în subfuncţii, care în fond reprezintă subsisteme funcţionale.

Fig.5.32, b). Diagrama de context

Al doilea pas la modelarea funcţională este decompoziţia funcţionalului principal în subfuncţii, care în fond reprezintă subsisteme funcţionale figura 5.33 (a, b, c, d).

Fig.5.33, a). Decompoziţia diagramei de context (decomposition diagrama)

Această boxă este părinte pentru diagrama de nivelul mai jos

NOTĂ: Numerele nodurilor indică faptul că activitatea a fost detaliată. numărul C sau numărul paginii din diagrama fiică poate fi .C. în loc de numărul nodului

Fig.5.33, b). Decompoziţia diagramei de context

Fig.5.33, c), d). Arborele nodal al decompoziţiei diagramei de context

Reguli de bază pentru construirea diagramei - pe o diagramă se recomandă a interpreta între 3 şi 6 blocuri. În caz contrar, diagrama va fi greu de interpretat; - blocurile funcţionale se poziţionează de la stânga spre dreaptă şi de sus în jos în ordinea (dominantă) de subordonare; - trebuie de evitat intersecţiile excesive ale arcurilor de interconexiuni; -ieşirea unui bloc poate fi o intrare pentru alt bloc din cadrul diagramei. Pot fi conexiuni inverse spre „intrare” şi către „control”; -arcurile de conexiune pot fi „contopite” sau „ramificate” figura 5.34, figura 5.35.

Fig.5.34. Evitarea intersecţiei

Fig.5.35. Reguli de bază privind construirea diagramei

Arcurile de conexiune Arcuri marginale Arcurile pe diagrama contextuală servesc pentru a descrie interacţiunea sistemului cu mediul ambiant. Ele pot începe de la marginea diagramei şi terminate la blocul funcţional, şi invers, în cazul „ieşiri”. Aceste arcuri se numesc „arcuri marginale”. „Arcurile marginale” se marchează cu ajutorul ICOM-semne (Input, Control, Output, Mechanism) Tunelare arcuri În unele cazuri, este necesar a indica arcurile marginale, care sunt importante pentru nivelul respectiv, dar mai puţin importante pentru diagrama paternală. De exemplu, unele date se utilizează doar la acest nivel. În aceste scopuri se aplică arcurile cu tunelare.

Glosare şi pagina FEO - pentru fiecare element din diagrama IDEF0 trebuie să fie creată ontologia respectivă – noţiuni, cuvinte-cheie, denumiri funcţii, denumiri operaţii şi altele ce caracterizează obiectul (entitatea) reprezentată în diagramă. Această ontologie se numeşte – glosariu, ce defineşte descrierea entităţii reprezentate; - diagrama FEO (For Exposition Only), aceasta este o diagramă ce descrie unele aspecte speciale din diagrame. Diagramele FEO nu sunt limitate de sintaxa notaţiei IDEF0. Ele pot conţine informaţii în format text, grafică, scheme, un alt punct de vedere asupra procesului dat şi alte însemnări, aceste diagrame nu se utilizează pentru dezvoltarea modelului, sunt utilizate numai pentru discuţii. Pagina ”MASTER” (carcasa diagramei) Este divizată în 3 câmpuri principale (figura 5.37): - câmpul informaţiei de serviciu (pentru ghidarea diagramei în procesul de modelare); - câmpul mesajelor (câmpul unde se desenează diagrama); - câmpul de identificare (identificarea diagramei şi poziţionarea ei în ierarhie).

Fig.5.37. Pagina Master în IDEF0

USED AT: Universitatea tehnicã din Moldova FCIM

AUTHOR: Student Basarabean

DATE: 02.07.2019

WORKING

PROJECT: Familiarizare IDEF

REV:

DRAFT

02.07.2019

READER

DATE CONTEXT:

TOP

RECOMMENDED NOTES: 1 2 3 4 5 6 7 8 9 10

PUBLICATION

Informație despre locul diagramei în ierarhia arborescenă

Informație despre proiect: - autor - denumire proiect - data creării - data revizuirii - destinație - note - statutul proiectului - cititorii experți și data

Funcționalul: - denumire - poziția ierarhică - costuri

Studiere IDEF 0

1,00

A0

Informații despre identificarea diagramei: - identificator ierarhic - denumire funcțional - numărul paginii - numărul versiunii

NODE:

TITLE:

A-0

Studiere IDEF 0

NUMBER:

C-3

1-1

Fig.5.38. descriere câmpuri Paginii Master în IDEF0

Exemplu modelare funcțională a unei companii. 1. Definirea contextului funcţionării obiectului ce va fi informatizat. În această lucrare subiectul modelării este „Compania”, şi anume, procesele ce se petrec în interiorul Companiei. Scopul modelării - construirea business-proceselor ce se vor petrece în Companie (modelul TO-BY). Punctul de vedere este viziunea directorului Companiei ca persoană care cunoaşte în general toată structura Companiei. Pentru a efectua modelarea funcţională identificăm contextul funcţionării Companiei. În acest scop, cercetăm toate documentele ce reglementează activitatea Companiei: statutul Companiei, misiunea Companiei, legislaţia ce reglementează acest gen de activitate, regulamentele interne ale Companiei, standardele pentru produsele Companiei, normele interne, fişele de post ale angajaţilor Companiei şi alte documente ce reglementează activitatea Companiei (figura 5.38).

Fig.5.39. Diagrama cadru contextul funcționării Companiei

Dacă am definit contextul modelării, putem începe construirea diagramei de context („cutia neagră”), unde se indică ce avem la intrare şi ce avem la ieşire fără a detalia componentele sale (blocurile funcţionale). Această diagramă este constituită numai dintr-un singur bloc care va reflecta întreaga Companie (fig.5.10). Intrări – aici se va reflecta informaţia sau materialele ce vor fi procesate de această lucrare (bloc). Ieşire – informaţia sau materialele care sunt produse de această lucrare (bloc). Reglementări (control) – proceduri, reguli, strategii, standarde şi norme de care se conduce lucrarea (blocul). Mecanisme – resursele ce asigură executarea lucrărilor (angajaţi, echipamente, baze de date şi altele). Pentru Compania noastră vor fi: Arcurile de intrare:  comenzile clienţilor: lista calculatoarelor şi a notebook-urilor şi completaţia lor cerute de clienţi;  ansambluri şi subansambluri de la furnizori;  informaţii (propuneri comerciale) de la furnizori;  informaţii despre cererea pieţei. Arcurile de ieşire:  produsele finite: calculatoarele şi notebook-uri asamblate;  facturi pentru produsele ce vor fi livrate;  cereri pentru furnizori: lista ansamblurilor, subansamblurilor şi materialelor necesare Companiei;  achitările facturilor furnizorilor: achitări pentru ansambluri, subansambluri şi materiale necesare Companiei;

 materiale de marketing ale produselor proprii: price-list, publicitate. Arcurile de control (reglementare):  cadrul legal: diverse acte legislative ce reglementează activitatea Companiei;  reguli şi proceduri: reguli şi proceduri care reglementează procesele de producere (reguli de asamblare, reguli de testare, norme de asamblare produse, standarde interne ale produselor asamblate, procedura relaţiilor cu clienţii, norme de protecţie a muncii). Arcurile mecanismelor:  resursele umane (ingineri IT, programatori, marketologi, economişti);  sistemul de evidenţă contabilă;  sistemul de evidenţă a contractelor;  echipamente tehnice;  unităţi de transport.

Fig.5.40. Diagrama- contextul funcționării Companiei

Decompoziţia funcţională de nivelul unu şi doi în notaţia IDEF0 Scopul: a efectua decompoziţia funcţiilor de nivelul unu în notaţia IDEF0. În sarcina precedentă a fost determinat contextul funcţionării obiectului nostru şi a fost construită diagrama de context, constituită numai dintr-un bloc general care reflectă activitatea Companiei în general (la macro) fără devalizarea componentelor principale ale Companiei. În acest capitol vom evidenţia subdiviziunile principale ale Companiei ce asigură funcţionalitatea ei şi vom efectua decompoziţia de nivelul unu şi doi prin construcţia diagramelor de decompoziţie în notaţia IDEF0.

Decompoziţia înseamnă partajarea unui obiect complex în părţi componente care interacţionează între ele.  În acest scop, identificăm procedurile principale care asigură procesul de asamblare a calculatoarelor şi laptopurilor. Procesele principale ale companiei:  colaboratorii cercetează cerinţele pieţei de calculatoare şi laptopuri;  vânzătorii recepţionează comenzile de la clienţi;  colaboratorii selectează comenzile conform tipurilor de calculatoare;  colaboratorii cercetează piaţa furnizorilor de ansambluri şi subansambluri;  colaboratorii secţiei de achiziţii comandă şi procură ansambluri şi subansambluri necesare pentru asamblarea calculatoarelor;  colaboratorii planifică producerea produselor pe termen scurt şi pe termen lung;  colaboratorii calculează preţul de cost şi costul de livrare al produselor finite;  colaboratorii asamblează şi testează calculatoarele;  colaboratorii asigură deservirea pe garanţii;  colaboratorii efectuează evidenţa produselor finite la depozit, evidenţa vânzărilor, evidenţa stocurilor de subansambluri;  colaboratorii împachetează produsele finite conform comenzilor primite de la clienţi;  colaboratorii livrează clientului comanda respectivă;  colaboratorii efectuează evidenţa contabilă şi evidenţa muncii;  colaboratorii perfectează comanda, eliberează conturile de plată, urmăresc achitările conform conturilor. Pentru a evidenţia subdiviziunile principale ale Companiei vom grupa aceste procese ce asigură funcţionalitatea ei astfel: Management:  colaboratorii efectuează evidenţa contabilă şi evidenţa muncii;  colaboratorii perfectează comanda, eliberează conturi de plată, urmăresc achitările conform conturilor;  colaboratorii efectuează evidenţa produselor finite la depozit, evidenţa vânzărilor, evidenţa stocurilor de subansambluri;  colaboratorii calculează preţul de cost şi costul de livrare al produselor finite;  colaboratorii planifică producerea produselor pe termen scurt şi pe termen lung. Marketing şi vânzări:  colaboratorii cercetează cerinţele pieţei de calculatoare şi laptopuri;  colaboratorii cercetează piaţa furnizorilor de ansambluri şi subansambluri;  vânzătorii recepţionează comenzile de la clienţi. Producere (asamblare şi testare):  colaboratorii selectează comenzile conform tipurilor de calculatoare;  colaboratorii asamblează şi testează calculatoarele;  colaboratorii asigură deservirea pe garanţii. Achiziţii şi livrări:  colaboratorii împachetează produsele finite conform comenzilor primite de la clienţi;  colaboratorii livrează clientului comanda respectivă;  colaboratorii secţiei de achiziţii comandă şi procură ansambluri şi subansambluri necesare pentru asamblarea calculatoarelor.

Astfel, am evidenţiat 4 subdivizi principale ala Companiei ce asigură funcţionalitatea ei şi în conformitate cu aceasta vom face prima decompoziţie:  management;  marketing şi vânzări;  producere (asamblare şi testare);  achiziţii şi livrări. Ca instrument de modelare vom utiliza aplicaţia AllFusion ProcessModeller (V.7.9). Pentru a efectua decompoziţia, lansăm aplicaţia şi activăm iconiţa  Go to Child Diagram,  apoi butonăm pe lucrarea pe care vrem să o decompoziţionăm. Se va afişa o fereastră Activity Box Count (figura 5.42, 5.13) în care trebuie să alegem notaţia modelului şi numărul de blocuri funcţionale în care va fi efectuată decompoziţia (numărul de diagrame-fiică).

Fig.5.41. Creare decompoziţie de nivelul unu

Fig.5.42. Decompoziţie de nivelul unu

În continuare, atribuim denumiri blocurilor funcţionale şi conectăm săgeţile marginale cu blocurile funcţionale (figura 5.43).

Fig.5.43. Atribuirea denumirilor blocurilor şi conexiunile marginale

În continuare, interconectăm blocurile funcţionale pentru a asigura executarea proceselor de producere şi obţinem diagrama finală de nivelul unu (figura 5.44).

Fig.5.44. Decompoziţie de nivelul unu. Diagrama blocurilor funcţionale

Decompoziţie de nivelul doi în notaţia IDEF0 Din diagrama de decompoziţie de nivelul unu (figura 5.15) se observă că blocurile funcţionale Marketing şi vânzări şi Asamblare şi testare au mai multe interconexiuni. Aceasta vorbeşte despre faptul că în aceste blocuri au loc mai mule procese, fiind necesar a adânci decompoziţia la următorul nivel - nivelul doi (figura 5.45).

Fig.5.45. Diagrama de decompoziţie de nivelul doi Marketing şi vânzări

În procesul de analiză a proceselor care au loc la testarea pieţei externe şi interne s-au evidenţiat 4 blocuri funcţionale (figura 5.17). În acelaşi mod, efectuăm decompoziţia pentru blocul funcţional Asamblare şi testare.

Fig.5.46. Diagrama de decompoziţie de nivelul doi Asamblare şi testare

În procesul de analiză a proceselor care au loc la asamblarea produselor s-au evidenţiat 4 blocuri funcţionale (figura 5.47).

Fig.5.47. Diagrama de decompoziţie de nivelul doi Asamblare şi testare

5.2.4.1. Modelarea proceselor. Standardul IDEF3

O definiţie corectă a unui proces este descrierea unei serii de paşi sau acţiuni interconectate pentru realizarea unui obiectiv. Un proces are următoarele caracteristici: - un punct de plecare şi un punct final, acesta este obiectivul; - o propunere sau un scop pentru obţinerea rezultatului; - reguli care reglementează standardul sau calitatea intrărilor pe tot parcursul procesului; - de regulă, este legat de alte procese (interconectare procese); - procesul poate fi simplu şi scurt sau complex şi lung. În general, un рroces este o suită de acţiuni consecutive într-o ordine respectivă. Prin urmare, modelarea proceselor permite: • reflectarea consecutivităţii proceselor; • evidenţierea logicii interacţiunilor elementelor sistemului. Scopul IDEF3 – a facilita munca analiştilor la descrierea situaţiei când procesele se execută într-o ordine determinată, precum şi obiectele ce participă la aceste procese. Efectele modelării proceselor în IDEF3: - oferă un mecanism pentru colectarea şi documentarea proceselor curente privind

standardizarea; - capturează şi analizează procesele AS-IS; - asigură procesul de proiectare/reproiectare pentru scenariile TO-BE; - testează proiectul unui nou proces înainte de a ne angaja într-un proiect costisitor de dezvoltare (elaborare). IDEF3 identifică precedenţa, cauzalitatea şi relaţiile dintre situaţii şi evenimente într-o formă naturală a domeniului pentru exprimarea cunoştinţelor despre modul în care funcţionează un sistem, un proces sau o organizaţie. Spre deosebire de limbajele de simulare (cum ar fi SIMAN, SLAM, GPSS, WITNESS) care construiesc modele matematice predictive, IDEF3 construieşte descrieri structurate. Două tipuri de modele IDEF3 (figura 5.48 a,b,c): - descrierea fluxului de procese; - reţeaua de tranziţie a stării obiectului.

Modele IDEF3

DIAGRAME CE DESCRIU FLUXURI DE PROCESE

DIAGRAMA CE DESCRIU TRANZIȚIA STÂRII OBIECTELOR

Fig.5.48, a). Tipuri de modele IDEF3

Descrierea fluxului de procese generează cunoştinţe despre „modul în care funcţionează lucrurile” într-o organizaţie, de exemplu, descrierea a ceea ce se întâmplă cu o parte pe măsură ce aceasta trece printr-o secvenţă de procese de fabricaţie. Exemplu de diagramă ce descrie procesele în IDEF3

Pasul 3a

Pasul unu

Pasul doi

Testare

Pasul 3b

Fig.5.48, b). Descrierea fluxului de procese

Reţeaua de tranziţie a stării obiectului rezumă tranziţiile admisibile pe care un obiect le poate suporta pe parcursul unui anumit proces. UC - Unitatea Comportamentală (în engleză UOB)

UC/ acoperire de testare

UC/ vopsirea părții

Partea Lichidă în mașină

Stratul acoperit cu vopseau nouă

Partea solidă a mașinii

Partea acoperită cu luciu UC/ uscarea părții

UC/ acoperire de testare

Fig.5.48, c). Tranziţia stării obiectului

Fig.5.49. Diagrama de decompoziţie IDEF3

Elementele de bază ale modelării dinamice în IDEF3 1) unităţi de lucru - (UOW - Unit of Work), (UOB-Unit of Behavior); 2) conexiunile; 3) joncţiunile; 4) obiectele de referinţă. IDEF3 – descrierea fluxului procesului. Dezvoltarea unei descrieri a fluxului de proces IDEF3 constă în exprimarea faptelor colectate de la experţii domeniului în termeni de cinci blocuri descriptive de bază (figura 5.50).

Activitate notată prin arc

Logica numită casetă de joncțiune

Unitate de comportament / Unitate de lucru notată prin boxă

Starea obiectului

Diagrame ce descriu procesele

Diagrame ce descriu tranziția stării obiectelor

notată prin cerc

Starea tranziției notată prin arc

Fig.5.50. Semantica în descrierea flux, procese și starea tranziției

Tipuri de joncţiuni în IDEF3 În tabelul 5.2 sunt reprezentate principalele tipuri de joncțiuni în IDEF3. Tabelul 5.2. Tipuri de joncţiuni în IDEF3

Simbol Joncțiune

Denumire Joncțiune

Sensul Joncțiunii în Sensul Joncțiunii în cazul – contopire cazul – ramificare conexiuni conexiuni

Asincron

Toate procesele precedente trebuie să fie terminate Toate procesele precedente trebuie să se termine concomitent Unul sau mai multe procese precedente trebuie să se termine

Toate procesele următoare trebuie să fie lansate Toate procesele următoare trebuie să fie lansate concomitent Unul sau mai multe procese ce urmează trebuie să fie lansate

Sincron

Unul sau mai multe procese precedente trebuie să se termine concomitent

Unul sau mai multe procese ce urmează trebuie să fie lansate concomitent

Exclusiv (exclude )

Numai un proces precedent trebuie să fie terminat

Numai unul din procesele viitoare trebuie să fie lansat

Sincron >

Asincron

1) Joncţiunea Asincron «&» (figura 5.51): la intersecţie - toate procesele precedente trebuie să fie terminate; la ramificare - toate procesele următoare trebuie să fie lansate.

Fig.5.51. Procesele în joncţiunea Asincron «&»

2) Joncţiunea Sincron «&» (figura 5.52): la intersecţie - toate procesele precedente trebuie să se termine concomitent; la ramificare - toate procesele următoare trebuie să fie lansate concomintent.

Fig.5.52. Procesele în joncţiunea Sincron «&»

3) Joncţiunea Sincron «Sau» (figura 5.53): la intersecţie - unul sau mai multe procese precedente trebuie să se termine concomitent; la ramificare - unul sau mai multe procese ce urmează trebuie să fie lansate concomitent.

Fig.5.53. Procesele în joncţiunea Sincron «Sau»

4) Joncţiunea asincron «Sau» (figura 5.54): la intersecţie - unul sau mai multe procese precedente trebuie să se termine; la ramificare - unul sau mai multe procese ce urmează trebuie să fie lansate.

Fig.5.54. Procesele în joncţiunea Asincron «Sau»

5) Joncţiunea Exclusiv (exclude «sau») (figura 5.55): la intersecţie - numai un proces precedent trebuie să fie terminat; la ramificare - numai unul din procesele viitoare trebuie să fie lansat.

Fig.5.55. Procesele în joncţiunea Exclusiv (exclude «sau»)

În cazul în care fluxul de proces diverge (split) (fan-out) sau converge (join) (fan-in) utilizăm cutii de joncţiune. Joncţiunile sunt din AND, OR sau tip Exclusiv OR şi pot fi sincrone sau asincrone (figura 5.56).

Joncțiuni

Întări în

Ieșiri din

Fig.5.56. Utilizarea cutiilor de joncţiune

Cazuri şi condiţii de activare a unui obiect Activarea unui obiect este o colecție de procese ale unor sau tuturor unităților de lucru (UOB) în procesul reprezentat schematic a cărei proprietăți temporale și logice îndeplinesc condițiile pentru o schemă dată.

Fie Φ denotă o activitate a lui P1 şi P2 (1) Link-ul Simpla Precedență exprimă o ordonare temporală între instanțele a două procese conectate: În orice activare Φ, orice instanțe asociate a și b ale p1 și p2, respectiv, unde b nu pornește (2) Link-ul cu Restricții de Precedență înaintează o obligație asupra lansării procesului p2: pentru orice activare validă Φ, activarea instanței p1 trebuie să fie urmată de activarea instanței p2. (3) Link-ul cu Restricție de Precedență înaintează o constrângere asupra lansării procesului p1: pentru orice activitate validă Φ, procesul p2 trebuie precedat de procesul p1. (4) Link-ul cu Restricție de Precedență înaintează o constrângere asupra lansării proceselor p1 și p2: pentru orice activare validă Φ, o instanță p1 trebuie să fie urmată de o Instanța p2; și orice instanță p2 trebuie precedată de o instanță p1. (5) Link-ul cu restricție generală restricționează orice alte constrângeri pe link (definite de utilizator). De exemplu, procesul p2 poate întârzia nu mai mult de 5 minute după ce procesul p1 este terminat.

(6) Legătura relațională indică orice alt tip de relații sau constrângeri între cele două procese conectate, p1 și p2.

Joncțiunea Și-Split (fan-out): sunt date instanțele a, b și c, după instanța a întotdeauna urmează instanțele b și c. Dacă s-a folosit un AND sincron, înseamnă că procesele B și C trebuie să înceapă simultan.

Joncțiunea Și-Join (fan-in): sunt date instanțele a, b și c, instanța a este întotdeauna precedată de instanțele b și c. Dacă s-a folosit un AND sincron, înseamnă că ambele procese B și C trebuie să se termine simultan. Joncțiunea Or-Split (fan-out): un proces A va fi urmat de cel puțin un proces, adică de procesul B sau C sau ambele. Dacă s-a folosit un sincron OR, înseamnă că acele instanțe (dacă sunt mai multe) trebuie să înceapă simultan.

Joncțiunea Or-Join (fan-in): un proces A trebuie precedat de cel puțin un proces, adică procesul B sau C, sau ambele. Dacă s-a folosit un AND sincron, înseamnă că acele instanțe (dacă sunt mai multe) trebuie să se termine simultan. Joncțiunea Xor-Split (fan-out): procesul A va fi urmat de procesul B sau C, dar nu și de ambele. XOR - sincronă nu este aplicabilă, deoarece există o singură instanță care începe sau se termină.

Joncțiunea Xor-Join (fan-in): procesul A trebuie să fie urmat exact de procesul B sau C, dar nu ambele... XOR - sincronă nu este aplicabilă, deoarece există o singură instanță care începe sau se termină.

Combinaţiile conexiunilor de bază şi constrângerile temporale în activarea proceselor

Cazul 1. După realizarea joncţiunii Şi-divizate (and-split) se vor genera ativităţile B şi C; joncţiunea Şi-join nu este terminată decât dacă ambele procese B şi C îşi termină activităţile. Cazul 2. După realizarea joncţiunii Or-divizate (or-split) se generează cel puţin o activitate B sau C; joncţiunea Or-join nu este terminată decât dacă cel puţin o activitate B sau C îşi termină acţiunile.

Cazul 3. După realizarea joncţiunii xor-split, se generează exact o instanţă B sau C; Conexiunea xor-join nu este terminată decât dacă procesul B sau C îşi termină activarea. Cazul 4. Deşi procesele B şi C sunt generate după activarea joncţiunii Şi-divizare, nu este necesar ca ambele instanţe să fie terminate înainte ca activarea să treacă prin joncţiunea Or-join la următoarea instanţă de proces (figura 5.28 a) . Alte combinaţii de joncţiuni minore

Fig.5.57 a). Joncţiuni între elementele unui model Joncţiunile sunt tipuri speciale de activităţi cu semantică predeterminată a logicii proceselor. Astfel de combinaţii simple permit menţinerea practicilor de modelare de la 1 la mulţi şi de la multe la 1 pentru joncţiuni, permiţând în acelaşi timp impunerea unor constrângeri asupra proceselor înainte şi după acestea. Este posibil să le scurtaţi pe acestea, folosind o singură joncţiune, când începe şi se termină cu aceeaşi joncţiune.

Exemple de modelare a proceselor în standardul IDEF3 Exemplul 1. Căi de execuţie ale unui model de proces într-o maşină secvenţială (figura 5.57 b)

Figura 5.57 b). Exemplu modelare procese de execuţie

Constrângeri: a → exe(b, c, d), b → exe(e, f), (e ∨f) ∧(c ∧d) →exe(g), (note that xor(e, f) and par(c, d) )

Given that: exe(List) → List(a simplified operation). Calcularea tuturor căilor de execuţie: a, par(b, c, d), xor(e, f), g (6x2 = 12 aths) a, par(b, c), e, d, g 2 paths a, par(b, c), f, d, g 2 paths a, par(b, d), e, c, g 2 paths a, par(b, d), f, c, g 2 paths a, b, xor(e, f), par(c, d), g (2x2 =4 paths) În total, there are 24 possible execution paths.

Exemplul 2. Costul de timp al proceselor într-o maşină paralelă. Presupune că toate procesele sunt executate cu succes, astfel încât să nu existe o manipulare excepţională neaşteptată necesară pentru a face orice întârziere şi când nu există timp de aşteptare pentru a începe executarea unui proces de îndată ce s-a atins în modelul de proces, când costul de timp al unui proces poate fi calculat precum este arătat mai jos: - procese paralele ale lui p1, pn: max (p1, ..pn); - procese secvenţiale ale lui p1, pn: sum (p1, ..pn); - alegerea proceselor între p1, pn; - min (p1, ..pn) - cel mai bun caz; - max (p1, ..pn) - caz mai rău. Studiu de caz: utilizaţi exemple de modele pentru a calcula costul de timp posibil. Costul maxim şi cel minim al unui model de proces (figura 5.28 c)

Fig.5.57 c). Exemplu modelare costuri proces

Care este costul maxim al timpului? Care este ruta de execuţie? Time cost: 3 + 18 + 12 = 33 Execution route: a, (b, c, d), e, g Max(be, c, d) = 5+13 = 18 Care este costul minim al timpului? Care este ruta de execuţie? Time cost: 3 + 9 + 12 = 24 Execution route: a, (b, c, d), f, g Max(bf, c, d) = 9 Exemplul 3. Modelare proceselor în standardul IDEF3. În acest exemplu se modelează procesele Companiei de asamblare laptop-uri şi PC pentru care se efectuează modelarea funcţională în standardul IDEF0. Se va efectua studiul proceselor „Asamblare şi testare”, blocul funcțional А3 (vezi diagramele IDEF0). Executarea acestei lucrări începe odată cu procesul „plasare comenzi” la asamblare. Prima acţiune începe astfel: - verificarea dacă sunt destule „ansambluri şi subansambluri” - se „comandă ansambluri şi subansambluri” de la depozit (elementele ce lipsesc). În continuare se pregătesc ansamblurile şi subansamblurile pentru asamblare (scoatere din cutii, decuparea capacelor de pe fişele de intrare şi ieşire...). Apoi începe procesul de asamblare: - instalarea plăcii de bază în carcasă şi a procesorului pe placa de bază, Instalare (RAM) memorie operativă, Instalare Hard-Disk. Aceste acţiuni se efectuează pentru fiecare PC şi nu depind de configuraţia calculatorului. În continuare, în dependenţă de comanda clientului pot fi instalate:

- DVD, TV- tuner, Card-ryder. Cu aceasta se termină asamblarea calculatorului. La următoarea operaţie: - se instalează sistemul de operare; - la solicitarea clientului pot fi instalate şi alte aplicaţii soft. Ultima acţiune în această etapă este perfectarea rapoartelor „RaportPC asamblate” şi ”Raport rezultate asamblare”. Crearea diagramei de decompoziţie în notaţia IDEF3. Pentru aceasta se inserează pe diagrama A3 lucrarea Asamblare şi testare, butonând iconiţa"Go to Child Diagram", se selectează notaţia IDEF3 (figura 5.58).

Fig.5.58. Diagrama iniţială în notaţia IDEF3 nivelul unu

În diagrama de decompoziţie-fiică oricând pot fi adăugate noi lucrări. Din această cauză, când alegem numărul lucrărilor, putem indica un număr de lucrări arbitrar. La crearea diagrameifiică, aplicaţia BPWin nu transferă săgeţile marginale din diagrama maternă, ele trebuie înlocuite cu blocuri „obiecte de referinţă”: plasare comenzi, ansambluri şi subansambluri, comanda ansambluri şi subansambluri, raport PC asamblate şi raport rezultate asamblare. Pentru aceasta se activează iconiţa ”R” (Referent) de pe bara de instrumente şi în fereastra de dialog se indică ”Arrow” şi se alege din lista denumirilor de săgeţi conexiunea necesară (figura 5.59).

Fig.5.59. Fereastra de dialog Referent

În continuare se construiesc lucrările şi conexiunile dintre lucrări în ordinea desfăşurării proceselor de asamblare şi se obţine diagrama finală (figura 5.60).

Fig.5.60. Diagrama de decompoziţie IDEF3 nivelul unu

Menţionăm particularităţile principale ale acestei diagrame. După ce se efectuează lucrarea se verifică prezenţa ansambluri/subansambluri, sunt posibile două acţiuni: se comandă de la depozit elementele ce lipsesc sau, dacă sunt toate elementele necesare, se execută lucrarea Pregătire ansambluri/subansambluri. De aceea, se include joncţiunea „Sincron «Sau» (Synchronous OR). Lucrările Pregătire ansambluri/subansambluri şi Instalare placă de bază şi procesor se interconectează cu săgeata fluxuri de obiecte . Aceasta denotă că între lucrări se transmit obiecte. Lucrările ulterioare se interconectează cu săgeata conexiune predecesoară (Precedence), deoarece ele arată consecutivitatea acţiunilor asupra aceloraşi obiecte. După instalarea Hard-Discului este posibilă instalarea DVD, ТВ-tuner, Cardreader sau altor componente. Pentru aceasta se utilizează joncţiunea ”asincron «sau» (Asynchronous OR)”. Aceeaşi joncţiune se construieşte şi după terminarea lucrării. În continuare, după ce se instalează SO (Sistemul Operaţional), la cererea clientului, pot fi instalate şi alte aplicaţii soft, sau dacă nu, se perfectează Rapoartele. Pentru aceasta se utilizează

joncţiunea joncţiunea

Exclusiv (exclude

«sau») XOR (Exclusive OR). După cum se ştie, după

poate urma numai joncţiunea

, din această cauză înaintea lucrării Perfectare

raport se utilizează aceeaşi joncţiune. Rezumat Sunt preferate legăturile (conexiunile): - One-many şi many-one relationships only. Diferenţa dintre joncţiunile split (fan-out) şi join (fan-in): - când se ajunge la o joncţiune divizată, aceasta plasează controlul logic al procesului la procesele ce urmează acestuia - aceasta este o relaţie 1-la-multe; - când se ajunge la o joncţiune de asociere, se asigură că procesele înainte de a se întâlni cu constrângerile de joncţiune înainte de a trece la următorul nod - aceasta este o relaţie multe-launu. Combinaţii de joncţiuni ilegale: de exemplu, combinările şi/xor şi xor /şi , oricare altele. Sincronizări şi tipuri de joncţiuni. IDEF3 oferă multe relaţii fundamentale între două procese. 5.2.4.4. Modelarea logică a fluxurilor de date în conotaţia DFD Flux de date, definiţie - flux de date: totalitatea informaţiilor transmise, într-un interval de timp determinat, de la o sursă de informaţie la un receptor, printr-o mulţime de canale informaţionale; - mai multe: fluxuri informaţionale într-un sistem. Conexiuni ce se stabilesc între diferitele componente ale fluxurilor (figura 5.61): - pe orizontală; - pe verticală.

Fig.5.61. Conexiuni dintre diferitele componente ale fluxurilor

Indiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate apelează la operaţiunea de modelare logică a datelor şi prelucrărilor sub formă de diagrame, diferenţele constând doar în folosirea mai pronunţată a diagramelor pentru descrierea sistemului, încadrându-le în diagrame de context, diagrame ale fluxurilor de date fizice şi diagrame ale

fluxului de date logice. Altele apelează la combinaţii de diagrame, tabele şi forme descriptive. Diagrama de context scoate în evidenţă aria de întindere a sistemului analizat, prin specificarea elementelor din interiorul organizaţiei şi a celor externe, sub denumirea de entităţi externe ale sistemului analizat. Diagramele fluxurilor de date (DFD) - diagrama fluxului de date ale nivelului logic curent, independentă de tehnologie, reliefează funcţiile de prelucrare a datelor executate de către sistemul informaţional curent; - diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor, structura lor şi cerinţele funcţionale ale noului sistem; - descrieri ale obiectelor DFD se regăsesc în aşa-zisele dicţionare ale proiectelor sau depozitele CASE (repository); - diagramele fluxului de date DFD au ca obiectiv urmărirea modului de transfer al datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc şi modele ale proceselor de prelucrare, iar operaţiunea se numeşte modelarea proceselor; - DFD reprezintă doar una din tehnicile de analiză structurată. Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor fluxurilor de date a căpătat noi accepţiuni prin încorporarea ei în instrumentele de analiză şi proiectare cu ajutorul calculatorului, adică în instrumente CASE; - DFD – Data Flow Diagrams – Diagrama Fluxurilor de Date; - Modelul DFD al Sistemului este prezentat ca o ierarhie a diagramelor fluxurilor de date, ce descriu procesele asincron de transformare a datelor de la intrarea în sistem, procesarea lor şi livrarea utilizatorului; - scopul principal al acestei reprezentări îl constituie identificarea transformării datelor de intrare în date de ieşire de către proces şi de stabilirea relaţiilor dintre aceste procese. Remarcă. Modelele DFD în multe cazuri se utilizează ca fiind complementarea modelelor IDEF0 şi IDEF3 pentru a relata circulaţia documentelor în sistemele informaţionale corporative. Simboluri şi notaţii folosite în DFD Două sisteme comune de simboluri sunt denumite după numele autorilor ce le-au creat: - Yourdon and Coad, Yourdon and DeMarco; - Gane and Sarson. O diferenţă majoră în simbolurile lor este faptul că Yourdon-Coad şi Yourdon-DeMarco folosesc cercuri pentru procese, în timp ce Gane şi Sarson folosesc dreptunghiuri cu colţuri rotunjite, uneori numite comprimate (tabletă). Există şi alte variaţii ale simbolurilor, astfel încât lucrurile importante care trebuie memorizate să fie clare şi coerente în formele şi notaţiile utilizate pentru a comunica şi a colabora cu alţii. Folosind regulile sau liniile directoare ale convenţiei DFD, simbolurile descriu (reprezintă) cele patru componente ale diagramelor fluxului de date (figura 5.62).

Fig.5.62. Conotaţiile DFD

DFD – reguli şi sugestii - orice proces trebuie să posede cel puţin o intrare şi ieşire; - datele păstrate în sistem trebuie să treacă prin procese; - toate procesele în DFD interacționează cu un alt proces sau depozit de date. Proces: - un proces poate avea doar ieşiri (un miracol)? - un proces poate avea doar intrări (gaură neagră)? - un proces are o etichetă (verb, frază). Depozit de date: - datele nu pot fi transferate de la un depozit la altul; - datele nu se pot deplasa dintr-o sursă externă la un depozit de date; - datele nu se pot deplasa în mod direct de la un depozit de date la o sursă de date; - depozitul de date are o etichetă (substantiv).

Sursă: - datele nu se pot deplasa în mod direct de la o sursă; - o sursă are o etichetă – substantive. Flux de date: - un flux de date are o singură direcţie de traversare a datelor (flux) între simboluri; - structura Fork arată că exact aceleaşi date provin dintr-o locaţie comună şi sunt recepţionate de două sau mai multe procese, depozite de date sau surse; - structura Join arată că exact aceleaşi date provin de la oricare două (sau mai multe): procese, depozite de date sau surse, acestea fiind diferite, sosind într-o locaţie comună; - un flux de date nu poate merge direct înapoi la acelaşi proces de la care a provenit; - un flux de date într-un depozit de date înseamnă actualizare; - un flux de date dintr-un depozit de date înseamnă a prelua sau a folosi; - un flux de date are ca etichetă un substantiv. Balansarea Diagrame Flix de Date Când descompunem o DFD trebuie să conservăm intrările şi ieşirile procesului la nivelul următor de decompoziţie. Aceasta se numeşte balansare. Fluxul de date poate fi împărţit în fluxuri de date mai mici separate între ele în componenţa diagramei de nivel mai jos. Patru reguli adiţionale avansate de balansare ale DFD: 1. Un flux de date compus la un nivel superior poate fi împărţit în subfluxuri la nivelul următor, dar nu pot fi adăugate date noi şi toate datele din fluxul compus trebuie să fie luate în consideraţie de unul sau mai multe subfluxuri. 2. Datele de intrare pentru un proces trebuie să fie suficiente pentru a produce ieşirile (inclusiv pentru datele de intrare) din proces. Astfel, toate ieşirile pot fi produse, precum şi toate datele din intrări pot fi deplasate undeva, fie la un alt proces sau la un depozit de date în afara procesului pe o DFD mai detaliată, care indică o descompunere a acestui proces. 3. La cel mai scăzut nivel al DFDS, pot fi adăugate noi fluxuri de date pentru a reprezenta datele care sunt transmise în condiţii excepţionale; aceste fluxuri de date, de regulă reprezintă mesaje de eroare sau notificările de confirmare. 4. Pentru a evita liniile fluxului de date ce se intersectează, se poate repeta depozitul de date sau sursă de date pe DFD.

Reguli de desenare a DFD

Niveluri şi straturi DFD De la diagrama de context la pseudocod O diagramă a fluxului de date poate fi detaliată prin utilizarea nivelurilor şi straturilor (figura 5.63). Nivelurile DFD sunt numerotate de la 0, 1 sau 2 şi, ocazional, chiar nivelul 3 sau mai mult. Nivelul necesar de detaliere depinde de domeniul de aplicare a ceea ce se încearcă să se realizeze. DFD de nivelul 0 se mai numeşte şi diagramă de context. Acesta este o schiţă a întregului sistem în ansamblu, fiind analizat sau modelat, reprezentând sistemul ca un proces de nivel înalt, având relaţii cu entităţile externe. Aceasta este uşor de explicat unui public larg precum analişti de afaceri, analiştii de date şi dezvoltatori. DFD de nivelul 1 oferă o descompunere mai detaliată a părţilor componente ale diagramei de context. Sunt atenţionate principalele funcţii efectuate de sistemul în studiu, împărţind procesul de nivel înalt al diagramei de context în subprocese. DFD de nivelul 2 merge cu un pas mai jos, analizând părţile nivelului 1. Pentru aceasta va trebui mult text pentru a ajunge la nivelul necesar de detaliu cu privire la funcţionarea sistemului. Progresând la nivelurile 3, 4 şi mai departe, utilizarea a mai mult de 3 niveluri este mai puţin frecventă. Acest lucru poate crea o complexitate pe care o face dificil de a comunica, compara sau modela eficient. Cu ajutorul straturilor DFD, nivelurile în cascadă pot fi incluse direct în diagramă, oferind un aspect clar cu acces uşor la nivelurile inferioare. Cunoscând bine DFD, dezvoltatorii şi designerii îl pot folosi pentru a scrie pseudocodul, o combinaţie a limbii engleze şi limbajelor de programare. Pseudocodul facilitează dezvoltarea codului real.

Fig.5.63. Niveluri şi straturi DFD

Numerotarea nivelurilor Înrtr-o diagramă DFD cu multe niveluri este uşor să se uite la ce nivel ne aflăm într-un moment de timp. De aceea, fiecare nivel are o numerotare diferită pentru procesele din diagramă. ’Nivelul’ corespunde numărului de cifre zecimale pentru a defini un proces în acesta (figura 5.64 a,b,c,d). De exemplu: - Context Diagram Process labeled “0” - Level 0 Processes labeled 1.0, 2.0, 3.0, . - Level 1 Processes labeled 1.1, 1.2, 1.3, . - Level 2 Processes labeled 1.11, 1.12,...

Fig.5.64, a). Unele reguli la construcţia fluxurilor de date

Fig.5.64, b). Unele reguli la construcţia fluxurilor de date

Fig.5.64, c). Unele reguli la construcţia fluxurilor de date

Fig.5.64, d). Unele reguli la construcţia fluxurilor de date

5.2.4.5. Modelarea datelor. Standardul IDEF1x Primul pas în modelarea datelor este analiza datelor şi elaborarea unei scheme conceptuale (model conceptual) al acestor date. În această etapă sunt analizate natura şi modul de utilizare a datelor.

Sunt identificate datele care vor trebui memorate şi procesate, se împart aceste date în grupuri logice şi se identifică relaţiile care există între aceste grupuri. Mdelul relațional al datelor Sistemele de gestiune ale bazelor de date relaționale (SGBDR) au devenit principalul soft în prelucrarea datelor folosite pâmă și astăzi. Fiecare relație are un nume căruia îi corespunde o coloana din tabel (atribut). Fiecare tuplu (linie de tabelă) conține o valoare a fiecărui atribut. Un mare avantaj al modelului relațional este această structură logică simplă. De remarcat că orice structura de date poate fi prezentata prin una sau mai multe tabele de date, în cadrul carora este necesar sa existe si informatii de legatură, pentru asigurarea legaturilor între tabele. Aplicabilitatea IDEF1x - IDEF1x este o tehnică de modelare a informaţiei, fiind utilizată pentru a modela datele într-un mod standard, consecvent, previzibil, în scopul de a gestiona resursa. Utilizarea acestui standard este recomandată pentru toate proiectele care necesită un mijloc standard privind definirea şi analiza resurselor informaţionale în cadrul unei companii. Astfel de proiecte includ: - încorporarea unei tehnici de modelare a datelor într-o metodologie; - utilizarea tehnicii de modelare a datelor pentru managementul resursei informaţionale; - utilizarea tehnicii de modelare a datelor pentru integrarea sistemelor informaţionale; - utilizarea tehnicii de modelare a datelor pentru proiectarea bazelor de date. IDEF1X este o metodologie pentru eleborare Baze de Date Relaționale. Pentru aceasta IDEF1X utilizează o sintaxă convențională elaborată special în acest scop pentru a putea construi scheme conceptuale. Schemă conceptuală o să numim – Reprezentare generală a datelor (informației) în cadrul Companiei, care este independentă de realizarea finală și de platforma pe care va fi realizată această Bază de Date. Utilizarea metodologiei IDEF1X este rațională pentru a construi structura logică a Bazei de Date atunci, când sunt studiate toate resursele informaționale și decizia de a construi o Bază de Date Relațională ca parte componemntă a Sistemului Informațional Corporatv a fost deja adoptată. Trebui de menționat că instrumentele de modelare IDEF1x a fost elaborast special pentru a construi Sisteme Informaționale Relaționale și în caz ca este necesitatea de a construi un alt Sistem Informațional, de exemplu un sistem Obiect Orientat atunci ar fi mai bine să alegem o altă metodologie de modelare. Sunt cel puțin două motive pentru a nu utiliza IDEF1X în cazul când nu se construesc Sisteme Informaționale relaționale. - În primul rând, IDEF1X cere de la proiectanți să determine atributele cheie, asta pentru a putea diferenția entitățile una de alta, pe când sistema Obiect Orientată nu cere determinarea atributelor cheie pentru a putea identifica obiectele. - În al doilea rând, în caz că există mai multe atribute ce identifică univoc entitatea, proiectantul trebuie să disemneze unul din aceste atribute ca cheie primară, iar celelalte ca chei secundare.

IDEF1X – este bazat pe conceptul ”Entitate – Relații”; un instrument ce se utilizează la analiza structurii informaționale a obiectelor.  Modelul informațional, construit în conotația IDEF1x reprezintă – structura logică a informației despre obiectele din componența sistemului. Poate fi interpretată ca structura logică a Bazei de Date Modelul informațional în IDEF 1x – este o suplinire a modelului funcțional (IDEF0), acest model detaliază obiectele, care sunt manipulate de funcțiile sistemei. Componentele principale ale standardului IDEF1x Trei Componentele principale sunt: Entitate Relații Atribute 1) oamenii, obiectele, fenomenele despre care se colectează și stochează informația (în continuare – Entitate). 2) Interconexiunile între aceste entități ((în continuare – Relații). 3) Caracreristicile ce descriu aceste elemente ((în continuare – Atribute) Diagramele (ERD) «entitate – relaţii» sunt cele mai răspândite instrumente de modelare a datelor. Cu ajutorul ERD sunt detaliate depozitele de date în diagramele DFD. Sunt documentate aspectele informaţionale ale sistemului, inclusiv: - identificarea obiectelor importante pentru domeniul obiectiv - entităţile; - identificarea proprietăţilor acestor obiecte - atributele; - identificarea legăturile cu alte obiecte - relaţiile. Entitatea (Entity) este mulţimea obiectelor reale sau abstracte care posedă aceleaşi atribute sau caracteristici. Un obiect al sistemului poate fi reprezentat numai printr-o singură entitate, identificată în mod unic. Numele entităţii nu va fi legat de un exemplar (instanţă) concret al obiectului. Fiecare entitate va avea un identificator unic. Fiecare exemplar al entităţii va fi identificat în mod univoc. Fiecare entitate va avea anumite proprietăţi: - nume unic; - unul sau câteva atribute. O entitate poate avea un număr arbitrar de relaţii cu alte entităţi ale modelului. Relaţie şi atribut Relaţia (Relationship) este o asociere (căreia i-a fost atribuit un nume) între două entităţi, relevantă pentru domeniul obiectiv considerat. Relaţia este asocierea dintre entităţi în care fiecare instanţă (exemplar) a unei entităţi este asociată cu un număr arbitrar (inclusiv zero) de instanţe (exemplare) ale celeilalte entităţi, şi invers. Atributul este caracteristica entităţii, relevantă pentru domeniul obiectiv şi utilizată la calificarea, identificarea, clasificarea şi caracterizarea cantitativă sau exprimarea stării entităţii. Atributul reprezintă tipul de caracteristici sau proprietăţi asociate cu o mulţime de obiecte reale sau abstracte (persoane, locuri, evenimente, stări, idei, obiecte etc.). Modelarea datelor este un proces analitic impus nu numai de nevoia de extragere a caracteristicilor obiectelor date, ci deseori şi de necesitatea de a genera date noi din datele iniţiale. Extragerea caracteristicilor are ca finalitate estimarea vizuală a informaţiei cuprinsă în structuri complexe de date. Generarea datelor noi are la bază modelarea matematică a problemei

pentru care au fost colectate datele experimentale şi are ca finalitate estimarea vizuală a informaţiei, achiziţia de noi cunoştinţe. Un model de date reprezintă o colecţie integrată de concepte necesare descrierii datelor, relaţiilor dintre ele, precum şi a constrângerilor asupra datelor (Connolly ş.a. 1998). Modelul de date este utilizat la descrierea schemei bazei de date, definind structura datelor, legăturile dintre acestea, semantica lor, precum şi constrângerile impuse, deşi nu este obligatoriu ca întotdeauna acestea să fie regăsite în orice model de date. Pe scurt, un model de date este utilizat pentru a reprezenta date despre date. Modelele de date oferă înţelegerea descriptivă necesară definirii schemelor logice şi externe şi sunt utile descrierii formale a schemei bazei de date. Schema logică a unei baze de date reprezintă o descriere abstractă a unei porţiuni din realitatea modelată împreună cu instanţele bazei de date. Destinaţie IDEF1X. IDEF1X este o metodologie pentru elaborarea Bazei de Date Relaţionale. Pentru aceasta, IDEF1X utilizează o sintaxă convenţională elaborată special în acest scop pentru a putea construi scheme conceptuale. Schema conceptuală este reprezentarea generală a datelor (informaţiei) în cadrul companiei independentă de realizarea finală şi de platforma pe care va fi realizată această bază de date. Utilizarea metodologiei IDEF1X este raţională pentru a construi structura logică a bazei de date când sunt studiate toate resursele informaţionale şi decizia de a construi o bază de date relaţională ca parte componentă a sistemului informaţional corporativ care a fost deja adoptată. Totodată, e de menţionat că instrumentele de modelare IDEF1X au fost elaborate special pentru a construi sisteme informaţionale relaţionale, iar dacă apare necesitatea de a construi un alt SI, de exemplu un sistem Obiect Orientat, atunci se alege o altă metodologie de modelare. Există cel puţin două motive pentru a nu utiliza IDEF1X în cazul când nu se construiesc sisteme informaţionale relaţionale. În primul rând, IDEF1X cere de la proiectanţi să determine atributele-cheie, aceasta pentru a putea diferenţia entităţile una de alta, pe când sistemul Obiect Orientat nu cere determinarea atributelor-cheie pentru a putea identifica obiectele. În al doilea rând, dacă există mai multe atribute ce identifică univoc entitatea, proiectantul trebuie să desemneze unul din aceste atribute ca cheie primară, iar celelalte ca chei secundare. Noțiunile de bază a metodologiei IDEF1X IDEF1X este o abordare semantică la modelarea datelor, IDEF1X este bazat pe conceptul „Entitate–Relaţii”; un instrument ce se utilizează la analiza structurii informaţionale a obiectelor. Modelul informaţional, construit în conotaţia IDEF1X, reprezintă structura logică a informaţiei despre obiectele din componenţa sistemului şi poate fi interpretată ca structură logică a bazei de date. Modelul informaţional este o suplinire a modelului funcţional (IDEF0). Acest model detaliază obiectele care sunt manipulate de funcţiile sistemului. Componentele principale ale standardului IDEF1x. Componentele principale ale acestui standard sunt: Entitate Relaţii Atribute: - oamenii, obiectele, fenomenele despre care se colectează şi stochează informaţia (în continuare – Entitate); - interconexiunile dintre aceste entităţi (în continuare – Relaţii);

caracteristicile ce descriu aceste elemente (în continuare – Atribute). Entitate – mulţimea obiectelor reale (oameni, obiecte, fenomene) care au caracteristici şi atribute comune. Un obiect al sistemului poate fi reprezentat doar de o singură entitate, ce trebuie să fie identificată în mod unic. De exemplu: Entitatea – Studenţi. Un exemplar al aceste entităţi – Vasile BASARABEANUL. Relaţii – interconexiunile dintre două sau mai multe entităţi. Denumirea relaţiilor este formulată în mod determinant. Atribute – caracteristica entităţii. De exemplu, Entitatea – Student are ca atribut „Numele şi Prenumele”. Rezumat. Entitatea reprezintă tipul de informaţie de bază ce se stochează şi se păstrează în baza de date, iar relaţiile arată cum sunt interconectate aceste date între ele. Reguli de bază ale entităţilor - trebuie să aibă o denumire unicală şi să fie un substantiv la singular. Exemplu: student, angajat, contract, carnet de note, buletin de identitate; - poate avea unul sau mai multe atribute care îi aparţin sau sunt moştenite prin relaţii; - poate avea unul sau mai multe atribute care identifică univoc fiecare exemplar al entităţii şi se numesc ”cheie”; - poate avea unul sau mai multe relaţii cu alte entităţi; - dacă cheia externă este integral utilizată în cheia primară a Entităţii, atunci se spune că Entitatea este dependentă de identificator; - în notaţia IDEF1X, Entitatea este reprezentată în formă de dreptunghi.

Fig.5.65. Tipuri de entităţi în IDEF1x

Reguli de bază pentru ”Atribut” (figura 5.66 a, b, c, d) - atributul unei entităţi are un nume unic; - o entitate poate avea mai multe atribute; - atributele sunt proprii sau moştenite; - atributele proprii sunt unicale în cadrul acestui model;

- atributele moştenite se transmit de la entitatea paternală odată cu determinarea conexiunii de identificare.

Fig.5.66, a). Atribute-cheie

Reguli de bază ale relaţiilor – „Relaţia” (Relationship) Relaţia (Relationship) este o asociere (căreia i-a fost atribuit un nume) între două entităţi, relevantă pentru domeniul obiectiv considerat. Relaţia este definită suplimentar prin cardinalul relaţiei (numărul cuplurilor conţinute în relaţia dată) sau numărul de instanţe ale entităţiidescendent, care pot fi create de fiecare instanţă a entităţii-părinte (figura 5.67). Relaţii unitare

Fig.5.67a. Relaţii unitare

Relaţii one-to-one – acest tip de relaţii este destul de rar întâlnit. Uneori astfel de relaţii pot fi modelate, transformând una dintre entităţi în atribut al celeilalte entităţi (figura 5.67).

Fig.5.67b. Relaţii unitare

Relaţii one-to-many – sunt cele mai întâlnite tipuri de relaţii, însă şi aici cazurile c) şi d) reprezentate în figura 5.68 sunt mai puţin uzuale. Menţionăm câteva observaţii pe marginea exemplelor: - cazul a) este foarte des întâlnit; - în cazul b) am ales o relaţie opţională dinspre POEZIE spre POET, deoarece poate fi vorba de o poezie populară şi în acest caz nu există un poet cunoscut; - în cazul c) am considerat că o formaţie nu poate exista fără a avea cel puţin un membru, însă un artist poate avea o carieră solo, deci, nu face parte din nici o formaţie. - varianta d) modelează o colecţie de filme memorate pe CD. Pentru afacerea considerată, un CD conţine obligatoriu un film, dar unul singur, însă un film poate să nu încapă pe un singur CD, de aceea poate fi memorat pe unul sau mai multe CD.

Fig.5.68. Relaţii one-to-many

Relaţii many-to-many – aceste tipuri de relaţii apar în prima fază a proiectării bazei de date, însă ele trebuie să fie ulterior eliminate. În figura 5.69 sunt reprezentate câteva exemple de relaţii many-to-many; - în punctul b) am considerat că un curs poate apărea pe oferta de cursuri a unei facultăţi, însă poate să nu fie aleasă de nici un student, de aceea un curs poate fi urmat de unul sau mai mulţi studenţi; - şi invers, este posibil ca un student să fi terminat studiile şi să se pregătească pentru susţinerea examenului de licenţă şi el nu mai frecventează nici un curs; - la punctul c) un profesor angajat al unei şcoli trebuie să predea cel puţin o disciplină. Iar o disciplină din planul de învăţământ trebuie să fie predată de cel puţin un profesor.

Fig.5.69. Relaţii many-to-many

Nontransferabilitatea relaţiilor Spunem că o relaţie este nontransferabilă dacă o asociaţie între două instanţe ale celor două entităţi, dacă a fost stabilită, nu mai poate fi modificată. Nontransferabilitatea unei relaţii se reduce la faptul că valorile cheii străine corespunzătoare relaţiei respective nu pot fi modificate. Condiţia de nontransferabilitate a unei relaţii este asigurată prin program. De aceea trebuie să documentăm această restricţie. În ERD o relaţie nontransferabilă se notează cu un romb pe linia corespunzătoare relaţiei, spre entitatea a cărei cheie străină nu este permis să o modificăm (adică în partea cu many a unei relaţii one-to-many). În figura 5.70, este dat un exemplu de relaţie nontransferabilă. Este vorba despre notele date elevilor. Este normal ca o notă dată unui elev să nu poată fi apoi transferată unui alt elev.

Fig. 5.70. Exemplu de relaţie nontransferabilă Cazuri posibile. Fiecărei entităţi i se atribuie un nume şi un număr unic, separate prin "/" şi plasate deasupra blocului. Relaţia este definită suplimentar prin cardinalul relaţiei (numărul cuplurilor conţinute în relaţia dată) sau numărul de instanţe ale entităţii-descendent, care pot fi create de fiecare instanţă a entităţii-părinte. În IDEF1X pot exista următoarele cazuri: - fiecare instanţă a entităţii-părinte poate fi legată de zero, unul sau mai multe instanţe ale entităţii-descendent;

- fiecare instanţă a entităţii-părinte trebuie să fie legată de cel puţin o instanţă a entităţiidescendent; - fiecare instanţă a entităţii-părinte trebuie să fie legată de cel mult o instanţă a entităţiidescendent; - fiecare instanţă a entităţii-părinte este legată de un număr fix de instanţe ale entităţiidescendent. Legătură identificatoare. În cazul în care o instanţă de entitate-descendent este determinată în mod univoc prin legătura sa cu entitatea-părinte, relaţia este numită identificatoare (Authenticator), în caz contrar - neidentificatoare. Legătura (relaţia) este notată printr-o linie cu un punct bine pronunţat la sfârşitul liniei la entitatea-descendent (figura 5.71 a). Cardinalul relaţiei poate lua valorile: N – zero, unu sau mai multe; Z – zero sau unu; P – unu sau mai multe. Valoarea implicită este N. Exemplu de relaţie identificatoare

Fig.5.71, a). Relaţie identificatoare

Legătura neidentificatoare O legătură neidentificatoare este reprezentată cu ajutorul unei linii punctate. Entitateadescendent într-o relaţie neidentificatoare se numeşte independentă de identificator, dacă nu este entitate-descendent într-o oarecare legătură identificatoare (figura 5.71 b).

Fig.5.71, b). Relaţie neidentificatoare

5.2.4.6. ERWin data modeller. Instrument CASE modelare date.

Baza IDEF1x - abordare propusă de Peter Chen care permite construirea unui model al datelor echivalent modelului relaţional în forma normală trei. Perfecţionarea metodei IDEF1 a condus la crearea versiunii IDEF1X, care a fost elaborată în scopul sporirii simplităţii şi posibilităţilor de automatizare. Diagramele IDEF1X sunt utilizate într-o serie de instrumente CASE cum ar fi: ERWin sau Design/IDEF. Există două niveluri de prezentare a modelelor – logic şi fizic. În modelul logic datele sunt prezentate analogic, aşa cum există în lumea reală şi pot fi numite tot aşa cum sunt numite în realitate, de exemplu, “Client”, “Departament” sau “Nume angajat”. Obiectele modelului sunt numite entităţi şi atribute. Modelul logic al datelor este universal şi sub nici o formă nu este legat de realizarea concretă a SGBD. În modelul fizic datele depind de SGBD. Într-un model fizic este inclusă informaţia despre toate obiectele BD. Unui model logic îi pot corespunde câteva modele fizice diferite. Dacă într-un model logic nu contează tipul de date al unui atribut, într-un model fizic este important să fie descrisă toată informaţia privind obiectele fizice concrete – tabele, coloane, indici, proceduri etc. Interfaţa ERWin. Fiecărui nivel de afişare a modelului îi corespunde panoul de instrumente propriu (figura 5.72). La nivel logic panoul de instrumente include: - butonul indicatorului de mouse; - pentru introducerea unei entităţi; - butonul categoriei; - introducerea unui bloc de text; - pentru deplasarea atributelor; - butonul pentru crearea legăturilor: identificatoare, “mulţi-la-mulţi” şi neidentificatoare. La nivel fizic: în locul butonului categoriilor – butonul pentru introducerea vederilor (view); în locul butonului legăturii “mulţi-la-mulţi” – butonul pentru legarea vederilor. Pentru crearea modelelor datelor pot fi utilizate două notaţii: IDEF1X şi IE (Information Engineering). În continuare vom utiliza notaţia IDEF1X. Pentru comutarea între ML şi MF a datelor serveşte lista cu două opţiuni din partea centrală a panoului de instrumente ERwin. Dacă la comutare MF încă nu există, el va fi creat automat. Niveluri de afişare. În ERWin există câteva niveluri de afişare a diagramelor: (clik ”wiev”- ”display level” - nivelul entităţilor (entity), nivelul atributelor (atribute) , nivelul cheilor primare (primare key), nivelul cheilor (keys), nivelul definiţiilor (definition) şi nivelul pictogramelor (icon). Nivelurile modelului logic. În funcţie de profunzimea prezentării informaţiei despre date există trei niveluri ale modelului logic: - diagrama entitate-relaţie (Entity Relationship Diagram, ERD); - modelul datelor bazat pe chei (Key Based model, KB); - modelul atributiv complet (Fully Attributed model, FA). Diagrama entitate-relaţie reprezintă modelul de nivel superior al datelor. Acesta include entităţile şi legăturile reciproce, care reflectă procesele business principale ale domeniului obiectiv. Aceste diagrame nu sunt detaliate în profunzime, ele includ doar

entităţile principale şi legăturile dintre ele, sistemului informaţional.

entităţi care satisfac cerinţele principale ale

Fig.5.72. Interfaţa ERWin

Modelul datelor bazat pe chei permite prezentarea mai amănunţită a datelor (figura 5.73). Modelul include descrierea tuturor entităţilor şi a cheilor primare şi este destinat prezentării structurii de date şi a cheilor, care corespund domeniului obiectiv.

Fig.5.73. Modelul datelor bazat pe chei

Modelul atributiv complet. Este cea mai detaliată prezentare a structurilor de date: prezintă datele în forma normală trei şi include toate entităţile, atributele şi legăturile (figura 5.74).

Fig.5.74. Modelul atributiv complet

SGBD susţinute de ERWin. Modelul SGBD este generat în mod automat din modelul transformaţional şi reflectă exact catalogul de sistem al SGBD: - nivelul fizic la care este prezentat modelul depinde de serverul selectat. ERwin susţine peste 20 de tipuri (relaţionale şi nu numai) de BD; - DB2 LUW 9.x, DB2 ZOS 9.x; - Informix 11.x, Oracle 11g; - MS SQL Server 2000,2005,2008,2012; - MySQL 5.x, SQL Azure; - Sybase (ASE) 15.0, Sybase IQ 12.x; - Teradata v13, ODBC 3.x; - DB2 iSeries 5.x/6.x; - SAS, Progress 10.x. Această aplicaţie poate fi descărcată http://download.freedownloadmanager.org/Windows-PC/CA-ERwin-Data-Modeler/FREE9.6.00.4430.html