Home > Documents > Programare Vizuala

Programare Vizuala

Date post: 08-Feb-2016
Category:
Author: corinacorina
View: 85 times
Download: 2 times
Share this document with a friend
Description:
Programare Vizuala
Embed Size (px)
of 102 /102
Programare Vizuală și Modelare Curs pentru master Sisteme Informatice Aplicate în Pr o- ducţie şi Servicii Dr.ing. Loredana STANCIU, PhD
Transcript
  • Programare Vizual i Modelare Curs pentru master S i s t e m e I n f o r m a t i c e A p l i c a t e n P r o -d u c i e i S e r v i c i i Dr.ing. Loredana STANCIU, PhD

  • Programare Vizual i Modelare

    Pagina 2

    Cuprins

    1 PROGRAMAREA VIZUAL .............................................................................................................................. 4

    1.1 INTRODUCERE ......................................................................................................................................................... 4

    1.2 ISTORIC .................................................................................................................................................................. 6

    1.3 STRATEGII N PROGRAMAREA VIZUAL ....................................................................................................................... 8

    1.4 CLASICAREA LIMBAJELOR DE PROGRAMARE VIZUAL .................................................................................................. 9

    1.5 TEORIA LIMBAJELOR DE PROGRAMARE VIZUAL ........................................................................................................ 11

    1.5.1 Specificarea formal a Limbajelor de Programare Vizual....................................................................... 11

    1.5.2 Analiza Limbajelor de Programare Vizual ................................................................................................ 12

    1.6 PROBLEMELE LIMBAJELOR VIZUALE ........................................................................................................................... 13

    1.6.1 Controlul fluxului .......................................................................................................................................... 13

    1.6.2 Abstractizarea procedural ......................................................................................................................... 14

    1.6.3 Abstractizarea datelor ................................................................................................................................. 14

    1.7 EXEMPLE DE LIMBAJE DE PROGRAMARE VIZUAL ........................................................................................................ 14

    1.7.1 Chimera. Programarea vizual imperativ prin demonstraie ................................................................. 14

    1.7.2 Forms/3. Programarea vizual bazat pe foi de calcul tabelar ................................................................ 17

    1.7.3 Prograph. Programarea vizual cu fluxuri de date.................................................................................... 20

    1.7.4 KidSim/Cocoa. Programarea vizual bazat pe reguli .............................................................................. 21

    1.7.5 Cube. Limbaje de programare vizual 3D .................................................................................................. 24

    1.8 PROGRAMAREA VIZUAL I ABSTRACTIZAREA ............................................................................................................. 26

    1.9 CONCLUZII PRIVIND PROGRAMAREA VIZUAL ............................................................................................................. 27

    2 MODELARE CU REELE PETRI (19) ................................................................................................................ 28

    2.1 INTRODUCERE ....................................................................................................................................................... 28

    2.2 DESCRIEREA REELELOR PETRI ................................................................................................................................. 30

    2.3 PROPRIETI ALE REELELOR PETRI .......................................................................................................................... 34

    2.3.1 Accesibilitate ................................................................................................................................................ 34

    2.3.2 Limitabilitate i siguran ............................................................................................................................ 35

    2.3.3 Conservativitate ........................................................................................................................................... 35

    2.3.4 Nivelul de activare ....................................................................................................................................... 36

    2.3.5 Reversibilitate i starea de pornire ............................................................................................................. 38

    2.4 METODE DE ANALIZ .............................................................................................................................................. 38

    2.4.1 Arborele de acoperire .................................................................................................................................. 39

    2.4.2 Matricea de inciden i ecuaia de stare .................................................................................................. 41

    2.4.3 Un exemplu................................................................................................................................................... 42

    2.5 REELE PETRI: CONCLUZII ........................................................................................................................................ 44

    3 MODELARE CU APP INVETOR ...................................................................................................................... 47

    3.1 SISTEMUL DE OPERARE ANDROID ............................................................................................................................. 47

    3.1.1 Scurt istoric ................................................................................................................................................... 47

    3.1.2 Caracteristici................................................................................................................................................. 48

    3.1.3 Evoluia sistemului Android i impactul su pe pia ................................................................................ 49

  • Programare Vizual i Modelare

    Pagina 3

    3.1.4 Arhitectura Android ..................................................................................................................................... 50

    3.1.5 SDK-ul Android ............................................................................................................................................. 51

    3.2 MIT (GOOGLE) APP INVENTOR ............................................................................................................................... 52

    3.2.1 Ce se poate face cu App Inventor? .............................................................................................................. 53

    3.2.2 Capaciti i limitri ..................................................................................................................................... 54

    3.2.3 Modul de lucru ............................................................................................................................................. 55

    3.2.4 Selectarea componentelor pentru crearea de aplicaii ............................................................................. 56

    3.2.5 Deschiderea editorului de blocuri i pornirea emulatorului ...................................................................... 57

    3.2.6 Componente App Inventor .......................................................................................................................... 58

    3.2.7 Blocuri din App Inventor .............................................................................................................................. 65

    3.2.8 Exemplu de realizare a unei aplicaii cu App Inventor. ............................................................................. 69

    4 MODELARE CU SIMULINK ............................................................................................................................ 74

    4.1 CREAREA I REALIZAREA MODELELOR ........................................................................................................................ 75

    4.2 SIMULAREA UNUI MODEL ........................................................................................................................................ 76

    4.3 ANALIZA REZULTATELOR.......................................................................................................................................... 78

    4.4 MODELARE N SIMMECHANICS ................................................................................................................................ 79

    4.4.1 Studiul minii umane ................................................................................................................................... 79

    4.4.2 Constrngeri ale minii umane ................................................................................................................... 84

    4.4.3 Modelul cinematic i modelul SimMechanics ............................................................................................ 88

    4.4.4 Conectarea la o lume virtual ..................................................................................................................... 96

    5 BIBLIOGRAFIE ............................................................................................................................................ 100

  • Programare Vizual i Modelare

    Pagina 4

    1 Programarea Vizual

    1.1 Introducere

    Limbajele de programare convenionale sunt dificil de nvat i folosit, necesitnd abiliti pe care foar-

    te muli oameni nu le au. Din acest motiv, interfeele cu utilizatorul de la o gam larg de programe au

    nceput s vin cu faciliti care s suplineasc i s uureze capabilitile de programare. Spre exemplu,

    succesul foilor de calcul poate fi parial atribuit abilitii utilizatorilor de a scrie programe (sub form de

    colecii de formule).

    Pe msur ce distribuia de calculatoare personale a crescut, foarte muli utilizatori au ajuns s dein

    unul, fr ca marea majoritate s aib cunotine n a scrie programe. Ei cumpr calculatoarele i pa-

    chetele software fr s fie capabili s aduc o modificare ct de mic software-ului. Pentru a permite

    utilizatorului final s reconfigureze i s modifice sistemul, pachetele software ar trebui s ofere aceste

    opiuni, fapt care ar putea induce transformarea sistemului ntr-unul i mai complex fr s rezolve pro-

    blemele utilizatorului. Sisteme software uor de utilizat, precum sistemele de manipulare direct (Direct

    Manipulation) nu fac dect s mreasc distana dintre utilizator i programator n condiiile n care

    codul este mult mai complicat (din cauza suplimentului necesar manipulrii interfeelor pentru utiliza-

    tor), chiar dac mai muli utilizatori vor putea folosi software-ul (fiind uor de utilizat). (1) Cel mai bun

    exemplu de sistem cu manipulare direct este sistemul de operare cu pictograma Recycle Bin. Pentru a

    terge ceva, utilizatorul selecteaz i duce efectiv cu mausul (prin tehnica drag and drop) elementele n

    co.

    Pe de alt parte, oamenii au comunicat mult vreme folosind imagini, ca urmare, pe parcursul anilor 80

    i 90 s-au fcut numeroase eforturi pentru a pune n valoare abilitatea uman de a procesa informaii

    vizuale. Spre exemplificare, se poate considera urmtoarea situaie: un om poate urmri pe ecranul

    televizorului o imagine i s discearn un ablon constnd n milioane de pixeli pe secund, care se mo-

    dific n timp i spaiu. Dac, ns, privete imaginea din Fig. 1.1 (2), probabilitatea este aproape nul ca

    cineva s deslueasc ablonul reprezentat de urmtorul set de numere: un set de perechi X, Y, unde

    prima linie reprezint valorile lui X, iar a doua linie valorile lui Y. Chiar i tiind c sunt perechi de coor-

    donate n plan, majoritatea oamenilor tot ar avea probleme n a discerne un ablon din acest exemplu

    numeric. Dac, ns, aceste puncte sunt desenate, ablonul reiese rapid, aa cum se poate observa n Fig.

    1.2 (2).

    47 42 93 122 68 85 105 133 137 58 100 95 46 126 133 181 108 68

    Fig. 1.1 Perechi de coordonate X,Y

    Din aceste considerente limbajele de programare vizual ntreab: de ce, atunci, s persistm n ncerca-

    rea de a comunica cu calculatoarele noastre folosind limbaje de programare textuale? N-am fi mai pro-

    ductivi i puterea de calcul a calculatoare moderne n-ar fi mai accesibil la o gam mai larg de oameni,

    dac am fi capabili de a instrui un computer prin simpla desenare a imaginilor pe care le vedem cu ochii

  • Programare Vizual i Modelare

    Pagina 5

    minii noastre atunci cnd ne gndim la soluiile unor probleme speciale? Evident, susintorii limbajelor

    de programare vizual susin c rspunsul la ambele ntrebri este afirmativ.

    Fig. 1.2 Puncte

    ntrebrile de mai sus subliniaz motivarea principal a cercetrii n limbajele de programare vizual. n

    primul rnd, majoritatea oamenilor gndesc i i amintesc lucrurile n imagini. Ei se refer la lumea n-

    conjurtoare ntr-un mod grafic i folosesc imaginile drept componente principale n gndirea creatoare.

    Reducnd sau nlocuind n totalitate necesitatea traducerii ideilor vizuale n reprezentri textuale artifi-

    ciale poate ajuta la diminuarea problemelor de nvare. Mai mult, numeroase aplicaii se mpac foarte

    bine cu metodele de dezvoltare vizual. (3)

    Programarea vizual este programarea n care mai mult de o dimensiune este folosit pentru a transmi-

    te informaie. Exemple de astfel de dimensiuni adiionale sunt: folosirea obiectelor multi-dimensionale,

    folosirea relaionrilor spaiale, sau folosirea dimensiunii timp pentru specificarea relaiilor semantice de

    tip naintedup. Fiecare multi-dimensional sau relaie este un jeton (token), aa cum n limbajele de

    programare textual tradiionale fiecare cuvnt este un jeton. O colecie de unul sau mai multe astfel de

    jetoane este o expresie vizual. Exemple de expresii vizuale folosite n programarea vizual includ dia-

    grame, schie, icoane sau demonstraii de aciuni realizate cu obiecte grafice. Atunci cnd sintaxa unui

    limbaj de programare (semnificativ din punct de vedere semantic) include expresii vizuale, limbajul de

    programare este un limbaj de programare vizual (LPV).

    Dei limbajele de programare textual tradiionale adeseori ncorporeaz sintax bidimensional ntr-un

    sens foarte limitat o dimensiune x pentru a transmite ir de caractere liniar legal n limbaj i o dimen-

    siune y care permite spaierea opional a liniilor n document doar una dintre aceste dimensiuni

    transmite semantic, pe cnd cea de-a doua dimensiune a fost limitat la o informaie legat de tastarea

    relaiilor spaiale astfel nct s poat fi exprimate ntr-o gramatic unidimensional. Astfel, multidimen-

    sionalitatea este principal diferen dintre LPV-uri i limbajele strict textuale.

    Cnd expresiile vizuale sunt folosite ntr-un mediu de programare drept o facilitate de editare rapid

    pentru generarea de cod, acesta este denumit mediu de programare vizual (MPV). Aceste medii de

    programare vizual pentru limbajele de programare textual tradiionale reprezint o trecere ntre

    LPV-uri i cunoscutele limbaje textuale. Spre deosebire de acum civa ani, cnd mediile de programare

    strict textuale i n linie de comand reprezentau normalul, astzi MPV-urile pentru limbajele textuale

    tradiionale au preluat controlul n lumea programatorilor. MPV-urile comerciale pentru limbajele tradi-

    ionale sunt gndite pentru programatorii de profesie. Aceti programatori folosesc limbajele textuale

    pe care le cunosc deja i sunt ajutai de tehnici de interfaare grafic cu utilizatorul i de nivelul de acce-

    sibilitate al informaiei pe care metodele vizuale l pot aduce. MPV-urile pentru limbajele tradiionale

  • Programare Vizual i Modelare

    Pagina 6

    reprezint o modalitate de a transfera avansurile datorate cercetrii din LPV-uri n practic prin aplicarea

    acestor noi idei limbajelor tradiionale deja familiare programatorilor. n acest fel se permite migrarea

    gradual de la tehnicile de programare textuale ctre cele vizuale. (4)

    1.2 Istoric

    Programarea vizual a aprut din combinarea graficii pe calculator, a limbajelor de programare i a inte-

    raciunii om-calculator. Nu este o surpriz, deci, faptul c dezvoltrile din programarea vizual au repre-

    zentat avansuri n unul dintre aceste domenii. Sistemul revoluionar Sketchpad, dezvoltat de Ivan SUT-

    HERLAND, este cel mai bun exemplu n acest sens. Sketchpad, realizat n 1963 pe calculatorul TX-2 la

    MIT, a fost considerat prima aplicaie de grafic pe calculator. Sistemul permitea utilizatorilor s lucreze

    cu un creion cu lumin pentru a crea grafice 2D prin combinarea unor primitive simple, precum linii i

    cercuri, i aplicarea unor operaii (precum copierea) i a unor constrngeri asupra geometriei formelor.

    Interfaa sa grafic i suportul pentru specificarea constrngerilor de ctre utilizator reprezint contribu-

    iile cele mai importante ale lui Sketchpad la dezvoltarea LPV-urilor. Prin definirea constrngerilor potri-

    vite, utilizatorii puteau realiza structuri complexe precum legturi mecanice complicate i s le mite n

    timp real. Fratele lui Ivan SUTHERLAND, William, a adus, de asemenea, o contribuie important la dez-

    voltarea programrii vizuale n 1965, cnd a folosit TX-2 pentru a implementa un limbaj vizual simplu de

    fluxuri de date. Sistemul permitea utilizatorilor s creeze, s depaneze i s execute diagrame de fluxuri

    de date ntr-un mediu vizual unificat.

    Urmtorul jalon n geneza LPV-urilor la reprezentat publicarea n 1975 a tezei de doctorat a lui David

    CANFIELD-SMITH intitulat Pygmalion: A Creative Programming Environment. Aceast lucrare a constitu-

    it puncte de plecare pentru cteva direcii de cercetare n acest domeniu care continu i n ziua de as-

    tzi. Spre exemplu, Pygmalion se baza pe o paradigm de programare bazat pe icoane n care utilizato-

    rul crea, modifica i conecta mici obiecte, denumite icoane, care aveau proprieti definite pentru a

    realiza calcule. De atunci s-au adus multe mbuntiri acestei metode, ns multe LPV-uri nc se bazea-

    z pe aceast paradigm.

    Pygmalion a folosit i conceptul de programare prin exemple, unde utilizatorul i arta sistemului cum s

    realizeze o sarcin ntr-o situaie specific, iar sistemul folosea aceast informaie pentru a genera un

    program care s realizeze sarcina n cazuri generale. n acest sistem, utilizatorul seta modul memorare,

    realiza calculele de interes, reseta modul de memorare i primea ca ieire un program care realiza calcu-

    le asupra unor intrri arbitrare. (3)

    Iniial, dezvoltarea programrii vizuale a avut loc n dou direcii: abordri vizuale asupra limbajelor de

    programare tradiionale (precum diagramele executabile de fluxuri de date) i noi abordri vizuale de

    programare care s-au deprtat semnificativ de abordrile tradiionale (precum programarea prin de-

    monstrarea pe ecran a aciunilor dorite). Multe dintre aceste sisteme incipiente au avut avantaje care

    preau interesante i intuitive cnd au fost utilizate pe programe jucrie, dar care au indus probleme

    dificile cnd s-a ncercat extinderea lor n programe realiste. Aceste probleme au dus la o decdere

  • Programare Vizual i Modelare

    Pagina 7

    incipient a programrii vizuale, fcndu-i pe muli s cread c programarea vizual este nepotrivit

    pentru industrie, fiind doar un exerciiu academic.

    Pentru a depi aceste probleme, cercettorii din domeniul vizual au nceput s dezvolte ci de folosire a

    programrii vizuale doar n anumite domenii software, crescnd astfel numrul proiectelor n care pro-

    gramarea vizual ar putea ajuta. n acest sens, tehnici vizuale au fost:

    ncorporate pe larg n medii de programare care suport limbaje de programare textuale

    folosite pentru a nlocui specificaiile textuale din interfeele grafice pentru utilizator

    folosite pentru a realiza formele electronice ale diagramelor din ingineria software n crearea

    i/sau vizualizarea relaionrilor dintre structurile de date

    folosite pentru a combina vizual unitile programate textual pentru a construi noi programe

    n curnd au nceput s apar MPV-uri comerciale de succes. Printre primele exemple au fost Microsoft

    Visual Basic (pentru Basic) i sistemele VisualWorks (pentru Smalltalk) de la Cincom. Alt grup de MPV-uri

    comerciale, orientate n principal pe programarea de tip large-grained, sunt uneltele CASE (Computer-

    Aided Software Engineering) care suport specificaii vizuale (spre exemplu, folosind diagrame) ale rela-

    iilor dintre modulele programului, culminnd prin generarea automat a codului.

    Ali cercettori din programarea vizual au preferat o alt cale. Ei au contribuit la dezvoltarea acelor

    proiecte potrivite pentru programarea vizual prin implementarea sistemelor specifice unor anumite

    domenii. Folosind aceast strategie, prin determinarea unui nou domeniu care s suporte aceast facili-

    tate au crescut numrul proiectelor care pot fi programate vizual. Un beneficiu imediat a fost creterea

    nivelului de accesibilitate pentru utilizatorii care ajungeau n contact cu acele sisteme. Dezvoltatorii do-

    meniilor specifice pentru LPV i MPV au descoperit c, gsind modaliti de a scrie programe pentru

    rezolvarea unei anumite probleme dintr-un domeniu, au eliminat multe dintre dezavantajele metodelor

    iniiale, deoarece au lucrat direct n stilul de comunicare al domeniului respectiv i au folosit artefacte

    vizuale (spre exemplu, anumite icoane sau meniuri) care s reflecte nevoile particulare, diagramele de

    rezolvare a problemelor i vocabularul specific acelui domeniu, nefiind niciodat obligai s prseasc

    acel stil de comunicare. Aceast abordare a dat rezultate att n cercetare, ct i pe pia. Astzi exist

    LPV-uri i MPV-uri pentru diverse domenii: programarea achiziiilor de date de laborator (LabView de la

    National Instruments), programarea vizualizrilor specifice (AVS de la Advanced Visual Systems), pro-

    gramarea telefoniei i a mail-ului de voce (PhonePro de la Cypress Research) i programarea simulrilor

    grafice i a jocurilor (Cocoa de la Stagecoach Software). De asemenea, ageni pentru generarea de sof-

    tware ncep s fie inclui n software-ul pentru calculatoarele personale, permind ca macro comenzi

    care ajut cu sarcini repetitive s fie deduse prin manipulrile utilizatorului final (ca n Chimera, de

    exemplu).

    ncercarea iniial de a concepe LPV-uri cu destul putere i generalitate pentru a rezolva orice varie-

    tate de probleme de programare reprezint un domeniu de cercetare n plin dezvoltare. Un scop al

    acestei cercetri l reprezint mbuntirea continu a modalitilor prin care programarea vizual poa-

    te fi folosit. Un alt scop este acela de a asigura aceleai modaliti de mbuntire n dezvoltarea sof-

    tware n general, precum cele deja disponibile pentru programarea unor domenii specifice. Dei toate

  • Programare Vizual i Modelare

    Pagina 8

    acestea sunt nc la nivel de cercetare, au aprut deja LPV-uri comerciale cu caracteristici necesare pen-

    tru programarea de uz general, fiind folosite pentru a produce pachete software comerciale. Un exem-

    plu este Prograph CPX de la Pictorius International. (4)

    1.3 Strategii n Programarea Vizual

    n ceea ce privete cercetarea n programarea vizual n general i n LPV n particular, exist o prere

    greit precum c acestea au drept scop eliminarea textului. n fapt, majoritatea LPV-urilor includ text

    ntr-o oarecare msur ntr-un context multidimensional. Scopul lor este de a aduce mbuntiri desig-

    nului limbajului de programare. ansa de a atinge acest deziderat se bazeaz pe simplul fapt c LPV-urile

    au mai puine restricii sintactice privind modul n care un program poate fi exprimat (de ctre calculator

    sau de ctre om), situaie ce ofer o libertate de a explora mecanismele programrii care nu a mai fost

    atins din simplul motiv c nu era posibil n trecut.

    elurile care s-au dorit a fi atinse prin cercetarea n LPV-uri au fost de a:

    face programarea mai accesibil unei audiene particulare

    mbunti corectitudinea cu care oamenii realizeaz sarcini de programare

    mbunti viteza cu care oamenii realizeaz sarcini de programare.

    Pentru a atinge aceste scopuri, exist patru strategii utilizate n LPV-uri:

    Concret: este opusul lui abstract i presupune exprimarea unor aspecte ale programului folosind

    instane particulare. Spre exemplu, unui programator i se permite specificarea unor aspecte se-

    mantice privind un obiect sau o valoare specifice, sau sistemul s poat afia n mod automat

    efectele unui poriuni din program asupra unui obiect sau valori specifice.

    Direct: n contextul manipulrii directe, aceast strategie este descris ca fiind sentimentul pe

    care l are cineva manipulnd direct un obiect. Din perspectiv cognitiv, direct n calculatoare

    nseamn o distan ct mai mic ntre scop i aciunile necesare pentru a atinge acest scop. Un

    exemplu n acest sens ar fi s i se permit programatorului s manipuleze un obiect sau o valoa-

    re specifice n mod direct, prin semantic, n loc s descrie aceast semantic textual.

    Explicit: anumite aspecte ale semanticii sunt explicite n mediu dac pot fi precizate direct (tex-

    tual sau vizual), fr necesitatea ca programatorul s le specifice. Un exemplu l reprezint sis-

    temul care genereaz explicit relaionri ntre fluxurile de date (sau pri din program) prin de-

    senarea unor arce direcionale ntre variabilele relaionate ale programului.

    Rspuns vizual imediat (feedback vizual): n contextul programrii vizuale, acest deziderat pre-

    supune afiarea imediat a efectelor produse prin editarea programului. Tanimoto (5) a introdus

    termenul de liveness (adaptat n limba romn ca timp de rspuns), termen care caracterizea-

    z ct de imediat este rspunsul semanticii oferit n mod automat pe parcursul procesului de

    editarea a programului. Tanimoto descrie patru niveluri de timp de rspuns:

  • Programare Vizual i Modelare

    Pagina 9

    o Nivelul 1: nu se aplic nicio semantic, deci sistemul nu ofer niciun rspuns programa-

    torului. Un exemplu n acest sens l reprezint diagramele de tip entitate-relaionare

    pentru documentaie.

    o Nivelul 2: programatorul poate s obin rspuns despre o poriune a programului, dar

    acest rspuns nu este automat. Compilatoarele suport minimal acest nivel, iar interpre-

    toarele ceva mai mult deoarece nu sunt restricionate doar la valorile finale de ieire.

    o Nivelul 3: un rspuns semantic incremental este asigurat n mod automat de fiecare da-

    t cnd programatorul realizeaz o editare incremental a programului, caz n care toate

    valorile afiate pe ecran i afectate de modificare sunt retiprite automat. Aceasta asi-

    gur consistena dintre starea afiat i starea sistemului dac singura aciune care de-

    termin schimbarea strii sistemului este editarea programului. Facilitatea de recalcula-

    re automat a foilor de calcul tabelar suport acest nivel de timp de rspuns.

    o Nivelul 4: sistemul rspunde la editrile programului ca n nivelul 3, dar i la alte eveni-

    mente, precum ntreruperi de la ceasul de timp al sistemului sau clicuri de maus, asigu-

    rnd n orice moment acurateea dintre datele afiate i starea curent a sistemului pe

    tot parcursul rulrii.

    1.4 Clasicarea Limbajelor de Programare Vizual

    Pe msur ce domeniul LPV a nceput s se maturizeze, a aprut interesul crerii unei clasificri standard

    i robuste pentru tot ce s-a descoperit. O astfel de clasificare nu este de interes doar pentru cercettori,

    care vor putea gsi mai uor lucrri asemntoare, ci asigur i o baz pentru compararea i evaluarea

    diferitelor sisteme. Aceast clasificare se datoreaz unor nume importante din domeniu, incluznd pe

    Chang, Shu sau Burnett, care s-au strduit s identifice caracteristicile care definesc principalele catego-

    rii de LPV. Urmtoarea list (3) prezint un sumar al schemei de clasificare ce va fi dezvoltat pe parcur-

    sul acestui subcapitol:

    Limbaje vizuale pure

    Sisteme hibride (text i vizuale)

    Sisteme de programare prin exemplificare

    Sisteme orientate pe constrngeri

    Sisteme bazate pe formulare

    n fapt, aceste categorii nu sunt mutual exclusive, numeroase limbaje putnd fi ncadrate la mai mult de

    o categorie.

    n contextul acestui curs, cea mai important categorie o reprezint limbajele pur vizuale. Aceste limbaje

    sunt caracterizate de faptul c ele se bazeaz pe tehnici vizuale pe toat durata procesului de programa-

    re. Programatorul manipuleaz icoane sau alte reprezentri grafice pentru a-i crea programul care, apoi,

    este depanat i executat n acelai mediu vizual. Programul este compilat direct prin reprezentarea sa

    vizual i nu este niciodat tradus ntr-un limbaj intermediar bazat pe text. Exemplu de astfel de sistem

  • Programare Vizual i Modelare

    Pagina 10

    complet vizual este Prograph. n literatura de specialitate a domeniului, aceast categorie este subdivi-

    zat n seciuni precum limbaje cu icoane i fr icoane, orientate pe obiect, funcionale i imperative.

    Un subset important al LPV ncearc s combine elementele vizuale cu cele textuale. Aceast categorie

    de sisteme hibride include att sistemele n care programele sunt create vizual i apoi translatate ntr-un

    limbaj textual de nivel nalt, ct i sistemele care folosesc elemente grafice ntr-un limbaj textual. Exem-

    ple din aceast categorie includ Rehearsal World i rezultatul cercetrii lui Erwing i a echipei sale (6). n

    Rehearsal World, utilizatorul antreneaz sistemul s rezolve o problem particular prin manipularea

    unor actori grafici, dup care sistemul genereaz un program Smalltalk pentru implementarea soluiei.

    Erwing a dezvoltat extensii la limbajele C i C++ care permit programatorilor s insereze n cod diagrame.

    Spre exemplu, se poate defini textual o structur de date de tip list nlnuit, dup care se realizeaz

    asupra listei operaii (precum tergerea unui nod) prin desenarea pailor n cadrul procesului.

    Pe lng aceste dou categorii majore, numeroase LPV-uri sunt clasificate ntr-o varietate de ramificaii.

    Spre exemplu, o parte dintre LPV-uri se aseamn cu Pygmalion, permind utilizatorului s creeze i s

    manipuleze obiecte grafice cu care s nvee sistemul s realizeze o anumit sarcin. i Rehearsal

    World, pomenit n paragraful anterior, se ncadreaz n aceast categorie de programare prin exemple.

    Alte LPV-uri se bazeaz pe manipularea constrngerilor, creat de Sutherland n Sketchpad. Aceste sis-

    teme orientate pe constrngeri sunt populare pentru design de simulare, n care programatorul mode-

    leaz obiectele fizice ca obiecte ale mediului vizual crora li se impun constrngeri gndite s copieze

    comportamentul legilor naturale (precum gravitatea). De asemenea, sisteme orientate pe constrngeri

    se mai folosesc i n dezvoltarea de interfee grafice pentru utilizatori. Thinglab i ARK, ambele LPV-uri

    de simulare, reprezint exemple de limbaje bazate pe constrngeri.

    Cteva LPV-uri au mprumutat modul de vizualizare i metaforele de programare de la foile de calcul

    tabelar. Aceste limbaje pot fi clasificate drept LPV-uri bazate pe formulare. Ele neleg programarea ca

    modificarea n timp a unui grup de celule interconectate, deseori permind programatorului s vizuali-

    zeze execuia programului ca pe o secven de stri diferite ale celulelor care progreseaz n timp.

    Form/3 este un exemplu de astfel de LPV. Este important de evideniat faptul c n fiecare dintre catego-

    riile menionate anterior se pot gsi att exemple de LPV-uri de uz general, ct i limbaje speciale pentru

    aplicaiile unor anumite domenii.

    Domeniul programrii vizuale s-a dezvoltat foarte mult n ultimii ani. Dezvoltarea continu i rafinarea

    limbajelor din categoriile menionate mai sus au dus la unele rezultate care au fost iniial considerate ca

    fcnd parte din domeniul vizual, dar ulterior au fost reclasificate ca apropiate de domeniu pentru c nu

    exemplific, de fapt, programarea vizual. Aceste LPV-uri orfane includ sisteme de animare folosind

    algoritmi, precum BALSA, care asigur display grafic interactiv al execuiei programelor i unelte de dez-

    voltare a interfeelor grafice, precum cele livrate cu numeroase compilatoare moderne (precum Micro-

    soft Visual C++). Ambele tipuri de sisteme includ, cu certitudine, componente vizuale, dar acestea sunt,

    mai degrab, aplicaii grafice sau generatoare de abloane dect limbaje de programare. (3)

  • Programare Vizual i Modelare

    Pagina 11

    1.5 Teoria Limbajelor de Programare Vizual

    Pentru a stabili un cadru pentru discuiile teoretice privind limbajele de programare vizuale, este nece-

    sar prezentarea ctorva definiii (7):

    icoan (icoan generalizat): un obiect cu reprezentare dual: partea logic (sensul) i partea fi-

    zic (imaginea).

    sistem iconic: un set structurat de icoane relaionate.

    propoziie iconic (propoziie vizual): o aranjare spaial a icoanelor pentru sistemul iconic.

    limbaj vizual: un set de propoziii iconice construit pe baza unei sintaxe i a unei semantici date.

    analiz sintactic (analiz spaial): analiza unei propoziii iconice pentru determinarea structu-

    rii de baz.

    analiz semantic (interpretare spaial): analiza unei propoziii iconice pentru determinarea

    sensului de baz.

    Detaliile care urmeaz sunt restrnse la limbajele vizuale 2D, dar tot ce este expus poate fi generalizat

    pentru 3D (sau mai mult).

    1.5.1 Specificarea formal a Limbajelor de Programare Vizual

    Un aranjament spaial care constituie o propoziie vizual reprezint omologul bidimensional al unui

    aranjament unidimensional de jetoane n limbajele de programare convenionale (textuale). n acele

    limbaje, un program este exprimat sub forma unui ir de caractere n care jetoane terminale sunt conca-

    tenate pentru a forma o propoziie ale crei structur i sens sunt determinate prin analiz sintactic i

    semantic. Astfel, regula de construcie este implicit n limbaj i nu trebuie s fie precizat explicit ca

    parte a specificaiilor limbajului. Invers, n limbajele de programare vizual se disting trei reguli de con-

    strucie care sunt folosite pentru aranjarea icoanelor: concatenare orizontal (notat cu &), concatenare

    vertical (notat cu ^) i suprapunere spaial (notat cu +).

    Pentru a putea formaliza limbajele de programare vizual, trebuie fcut distincia dintre icoanele de

    proces (care exprim calcule) i icoanele obiect. Acestea din urm pot fi subdivizate n icoane obiect

    elementare (identific obiecte primitive n limbaj) i icoane obiect compozite (identific obiecte formate

    printr-o aranjare spaial a icoanelor obiect elementare). De fapt, termenul icoane elementare se refer

    att la icoanele de proces, ct i la icoanele obiect elementare i specific acele icoane care sunt primiti-

    ve n limbaj. i cum o imagine (sau icoan, n acest caz) valoreaz 1000 de cuvinte, toate aceste concepte

    sunt ilustrate n Fig. 1.3, care prezint cteva icoane din setul de icoane Heidelberg (8) i o propoziie

    vizual complet.

    Un limbaj de programare vizual este specificat de o triplet de forma (DI,G0,B), unde DI este dicionarul

    de icoane, G0 este gramatica i B este o baz de cunotine specific unui anumit domeniu (9). Diciona-

    rul de icoane este setul de icoane generalizate, fiecare fiind reprezentat printr-o pereche de forma

    (Xm,Xi), cu o parte logic Xm (sensul) i o parte fizic Xi (imaginea). Gramatica G0 precizeaz modul n

    care icoanele obiect compozite pot fi construite din icoane elementare folosind operatori de aranjare

    spaial. Trebuie remarcat faptul c este obligatorie specificarea acestor operatori spaiali de compoziie

  • Programare Vizual i Modelare

    Pagina 12

    ca elemente terminale deoarece ei nu mai fac parte implicit din definirea limbajului. Baza de cunotine

    B conine informaii specifice domeniului necesare pentru construirea sensului propoziiei vizuale dorite.

    Aceasta conine informaii privind numele evenimentelor, relaii conceptuale, numele obiectelor rezul-

    tate i referinele la obiectele rezultate.

    Fig. 1.3 Cteva icoane din setul Heidelberg. Icoane obiect elementare: (a) un caracter i (b) un caracter selectat. Icoane de proces: (c) operaia de inserie i (d) operaia de tergere. Icoane obiect compozite: (e) un ir de caractere (compus din carac-tere) i (f) un ir selectat (compus dintr-un caracter i dou caractere selectate). Propoziie vizual (g) reprezentnd nlocuirea unui subir ntr-un ir.

    1.5.2 Analiza Limbajelor de Programare Vizual

    Propoziiile vizuale sunt construite din icoane elementare cu ajutorul operatorilor iconici. Analiza sintac-

    tic a propoziiilor vizuale (cunoscut i sub denumirea de analiz spaial (10)) se bazeaz pe cteva

    abordri (7):

    Gramatici pentru procesarea imaginilor: iniial gndite pentru distribuirea imaginilor digitale pe

    o reea de ptrate, aceste gramatici se bazeaz pe faptul c imaginile digitale sunt compuse din

    pixeli. Aceste gramatici descoper structura unei propoziii vizuale compunnd pixelii n elemen-

    te vizuale recognoscibile (linii, arce etc.) (11). Aceast metod este folositoare cnd un sistem

    iconic trebuie s recunoasc icoane cu o anumit toleran de eroare (spre exemplu, digii din

    scrisul de mn).

    Gramatici de preceden: aceste gramatici de analiz spaial pot fi folosite pentru analiza ex-

    presiilor matematice bidimensionale. Ele sunt foarte potrivite pentru analiza sintactic a propo-

    ziiilor vizuale construite din icoane elementare i operatori iconici. Arborele de analiz este

  • Programare Vizual i Modelare

    Pagina 13

    construit prin compararea precedenei operatorilor ntr-un ablon principal i subdivizarea a-

    blonului ntr-unul sau mai multe abloane secundare.

    Gramatici independente de context i gramatici dependente de context: aceste gramatici sunt

    folosite pentru a determina compoziia propoziiile vizuale folosind formalisme cunoscute.

    Gramatici gen graf: acestea sunt, de departe cele mai puternice (dei mai puin eficiente) speci-

    ficaii ale limbajelor vizuale. Aceste formalisme prevd cele mai multe mijloace pentru stabilirea

    unor relaii contextuale i mare parte din cercetarea recent n acest domeniu a fost dedicat

    ncercrii de a face analiza cu gramatici de acest tip fezabile din punct de vedere computaional.

    Arborele de analiz determinat printr-una dintre metodele enunate anterior este analizat ulterior folo-

    sind metode tradiionale de analiz semantic.

    1.6 Problemele limbajelor vizuale

    n cele ce urmeaz vor fi prezentate cteva dintre problemele comune ale limbajelor vizuale (4). Aceste

    probleme se ntlnesc mai ales n limbajele vizuale de uz general (potrivite pentru a genera programe

    executabile de dimensiuni rezonabile), dei unele dintre ele apar i n limbajele vizuale specifice unor

    anumite domenii (proiectate pentru domenii particulare precum ingineria software sau vizualizarea ti-

    inific).

    1.6.1 Controlul fluxului

    La fel ca n limbajele de programare convenionale, limbajele vizuale folosesc dou metode pentru con-

    trolul fluxului n programe:

    Metoda imperativ: n acest caz, programul vizual realizeaz una sau mai multe diagrame de

    control al fluxului sau diagrame de flux de date, care indic modul n care se realizeaz controlul

    pe parcursul programului. Un avantaj particular al acestei metode l reprezint faptul c asigur

    o reprezentare vizual efectiv a paralelismului. Dezavantaj este faptul c programatorul trebuie

    s fie atent la modul n care secvenierea operaiilor modific starea programului, ceea ce nu es-

    te o caracteristic dorit pentru sistem (mai ales dac este destinat unor nceptori)

    Metoda declarativ: este o alternativ la metoda imperativ i presupune c programatorul tre-

    buie s prevad ce calcule se efectueaz i nu cum se execut acele calcule. Modificarea explici-

    t a strii este evitat prin folosirea atribuirii singulare: programatorul creeaz un nou obiect

    prin copierea unuia existent i precizarea diferenelor dorite i nu prin modificarea strii obiec-

    tului existent. De asemenea, n loc s specifice o secven de modificrii ale strii, programatorul

    definete operaii prin specificarea dependenelor dintre obiecte. Spre exemplu, dac progra-

    matorul definete Y ca X+1, atunci aceast formulare, de fapt, stabilete explicit c Y trebuie cal-

    culat folosind obiectul X, iar sistemul nelege c valoare lui X trebuie calculat prima. Astfel, n-

    c este prezent secvenierea operaiilor, dar ea trebuie dedus de ctre sistem i nu definit de

    programator. n acest caz, sistemul are de rezolvat problema dependenelor circulare, care tre-

    buie detectate i semnalizate ca eroare.

  • Programare Vizual i Modelare

    Pagina 14

    1.6.2 Abstractizarea procedural

    Exist dou niveluri de abstractizare procedural. Limbajele de programare vizual de nivel nalt nu sunt

    limbaje de programare complete deoarece, spre exemplu, nu este posibil scrierea i meninerea unui

    ntreg program ntr-un astfel de limbaj i, inevitabil, exist i module non vizuale care sunt incluse n

    limbaj. Aceast metod de programare vizual este ntlnit n diverse sisteme orientate pe un anumit

    domeniu, precum uneltele de mentenan software i mediile de vizualizare tiinific. De cealalt parte

    sunt limbajele vizuale de nivel sczut care nu permit programatorului s combine n modulele procedu-

    rale logic fin granulat. Aceast metodologie este folosit n limbaje orientate pe domenii specifice,

    precum simulatoarele logice. Limbajele de programare vizual de uz general acoper ntregul spectru de

    faciliti de programare, pornind de la proprieti de nivel sczut (incluznd condiionrile, recursivitatea,

    iteraia) la proprieti de nivel ridicat care permit combinarea logicii de nivel sczut n module abstracte

    (proceduri, clase, biblioteci etc.).

    1.6.3 Abstractizarea datelor

    Facilitile de abstractizare a datelor sunt ntlnite doar n limbajele de programare de uz general. Noi-

    unea de date abstracte n programarea vizual este foarte similar cu cea din limbajele de programare

    convenionale, cu singura deosebire c tipurile de date abstracte trebuie definite vizual (i nu textual),

    au o reprezentare vizual (iconic) i asigur un comportament vizual.

    1.7 Exemple de limbaje de programare vizual

    n aceast seciune vor fi prezentate cteva exemple de LPV-uri pentru a demonstra cteva modaliti

    prin care au fost implementate strategiile prezentate anterior.

    1.7.1 Chimera. Programarea vizual imperativ prin demonstraie

    Chimera este o exemplificare a modului prin care programarea imperativ este suportat n LPV-uri, prin

    punerea programatorului s i demonstreze aciunile dorite. Sistemul a fost conceput de D.J. Kurlander

    n cadrul tezei sale de doctorat (12). n cazul Chimera, programatorul este un utilizator final, ca urmare

    este i un exemplu de LPV destinat mbuntirii nivelului de accesibilitate al programrii anumitor tipuri

    de sarcini.

    Domeniul Chimera este editarea grafic. Pe msur ce un utilizator final lucreaz la o scen grafic, poa-

    te constata apariia unor sarcini de editare repetitive, caz n care poate indica o secven de manipulri

    tocmai realizate asupra unei scene ca putnd fi generalizate i tratate ca un macro. Acest lucru este po-

    sibil deoarece istoricul aciunilor utilizatorului este prezentat folosind o tehnic de benzi desenate, iar

    utilizatorul poate selecta paneluri din istoric. Istoricul folosete acelai limbaj vizual ca interfaa, deci

    utilizatorul le va nelege fr probleme. Spre exemplu, Fig. 1.4 a) prezint o ilustraie coninnd dou

    ptrate i o sgeat. Istoricul generat prin crearea ilustraiei este prezentat n Fig. 1.5.

  • Programare Vizual i Modelare

    Pagina 15

    Fig. 1.4 Dou versiuni ale unei scene simple. Scena initial (a) i modificat (b)

    Primul panel al Fig. 1.5 nfieaz activarea grilei din panelul de control al editorului. Numele comenzii

    (Toggle-Grids) apare deasupra panoului. Al doilea panel prezint un dreptunghi creat n scena editorului

    cu ajutorul comenzii Add-Box. n panelul trei dreptunghiul este selectat, n caseta Text Input este tastat

    o culoare (galben) i este invocat comanda Set-Fill-Color. Acest panel este mprit pentru a vizualiza

    att partea de control, ct i partea de editare. Urmtoarele paneluri prezint modificri ale grosimii i

    culorii marginii dreptunghiului, adugarea unei linii paralel cu dreptunghiul i a nc dou linii deasupra

    acesteia pentru a forma o sgeat. A doua parte a istoricului nfieaz adugarea unui nou dreptunghi,

    tragerea sgeii pn la acest dreptunghi, rotirea sgeii pentru a-i alinia baza cu primul dreptunghi i, n

    final, ntinderea sgeii pentru a atinge primul dreptunghi.

    Fig. 1.5 Programarea prin demonstraie n Chimera. n acest exemplu, utilizatorul a desenat o cutie cu o sgeat indicnd spre ea (ca ntr-o diagram), iar aceast demonstraie este prezentat dup realizarea ei printr-o serie de paneluri. Acest set de demonstraii poate fi generalizat ntr-un macro pentru utilizarea sa ulterioar.

    Pentru a face istoricele mai scurte i mai simplu de neles, se folosesc mai multe strategii. Mai multe

    operaii nrudite se unesc ntr-un singur panel. Spre exemplu, panelul doi conine mai multe operaii:

    selectarea unei scene obiect i modificarea culorii fundalului pentru obiectele selectate. Eticheta panelu-

    lui indic numrul de comenzi pe care le reprezint i poate fi desfcut pentru a vizualiza panelurile in-

    cluse. Panelul doi se deschide n primele dou paneluri prezentate n Fig. 1.6. Pentru ca istoricul s nu fie

    foarte ncrcat, fiecare panel arat doar obiectele care particip n operaiile sale i contextul adiacent

  • Programare Vizual i Modelare

    Pagina 16

    cu el al scenei. Obiectele n panel sunt distribuite conform cu rolul pe care l au n explicaie. Spre exem-

    plu, n primul panel sunt importante caseta pentru marcaj i eticheta ei, motiv pentru care sunt eviden-

    iate, dar nu i celelalte elemente de control ale panelului.

    Fig. 1.6 Folosirea istoricului pentru modificarea unei scene: (a) panourile selectate pentru refolosire, (b) noi operaii adugate n istoric

    Istoricul grafic editabil poate fi folosit pentru revizuirea operaiilor dintr-o sesiune, pentru anularea (un-

    do) sau reluarea (redo) unei secvene din aceste operaii. Pentru exemplul din Fig. 1.4, se dorete aplica-

    rea pentru dreptunghiul de sus a comenzilor care stabilesc culoarea de umplere, grosimea i culoarea

    linei la fel ca la dreptunghiul de jos. Se selecteaz dreptunghiul de jos, se caut n istoric panelurile rele-

    vante i se selecteaz i ele (n cazul exemplului de fa, ultimele trei paneluri din Fig. 1.6), panelurile

    selectate fiind evideniate cu etichete albe pe fundal negru. n pasul urmtor se apeleaz operaia

    Redo-Selected-Panels, iar dreptunghiul de sus se va modifica n mod corespunztor.

    Istoricele grafice editabile din Chimera reduc repetiia prin faptul c ofer o interfa pentru operaia de

    reluare a operaiilor. Chimera are i un mecanism pentru inserarea de operaii noi n orice punct al unui

    istoric. Istoricele pot fi fcute editabile, ceea ce transform fiecare panel static ntr-un editor grafic. n

    acest fel, panelurile pot fi modificate, iar comenzile invocate i propag modificrile n ntreg istoricul.

    Pentru a insera o comand nou n mijlocul unui istoric, sistemul anuleaz toate comenzile ulterioare

    panelului afectat, execut noile comenzi, dup care le reface pe cele anulate. Spre exemplu, dac se

    dorete modificarea sgeii (Fig. 1.6 b), se modific ultimul panel din primul rnd al istoricului din Fig. 1.5.

    Se modific acest panel i nu altul pentru c, ulterior, sgeata nu mai este aliniat cu axele grilei, iar

    modificarea ar fi mult mai dificil. Dup propagarea acestor modificri, o nou scen va fi disponibil (Fig.

    1.4 b).

    Fig. 1.7 Istoric grafic prezentnd crearea i alinierea a dou dreptunghiuri

    Chimera include i o component de programare prin exemple, sau macro-uri prin exemple, care folo-

    sete istoricele grafice editabile ca reprezentare vizual pentru revizuirea, editarea, generalizarea pro-

    gramului i raportarea erorilor. Spre exemplu, se consider problema de aliniere la stnga a dou drep-

    tunghiuri. Paii necesari sunt capturai n istoricul grafic din Fig. 1.7. Se creeaz iniial cele dou dreptun-

  • Programare Vizual i Modelare

    Pagina 17

    ghiuri (panelurile 1 i 2), dup care se activeaz liniile pentru aliniere de 0 i 90 de grade (panelurile 3 i

    4) i se selecteaz colul din stnga sus al dreptunghiului de jos (panelul 5) i colul din dreapta jos al

    dreptunghiului de sus (panelul 6) pentru generarea acestor linii. La final se selecteaz dreptunghiul de

    sus i se trage pn ajunge la intersecia celor dou linii.

    Fig. 1.8 Fereastra pentru construirea macro-ului, care conine un macro pentru alinierea la stnga a dou dreptunghiuri

    Dac se dorete generalizarea acestei proceduri i ncapsularea ei ntr-un macro, nu se repet procedura

    ntr-un mod special de nvare, ci se parcurge istoricul, se selecteaz panelurile relevante i se execut

    comanda de transformare n macro. Pentru exemplul anterior, se selecteaz toate panelurile, cu excep-

    ia celor de creare a dreptunghiurilor, deoarece ele vor fi argumente al macro-ului. Va aprea o fereastr

    de construcie a macro-ului coninnd panelurile selectate. n pasul urmtor se vor alege argumentele,

    prin selectarea obiectelor dorite (cele dou dreptunghiuri), se vor denumi i se va invoca comanda

    Make-Argument. Efectul va fi adugarea a dou paneluri la nceputul istoricului pentru declararea argu-

    mentului (Fig. 1.8). Pentru a folosi macro-ul ulterior, pentru un alt set de dreptunghiuri, va aprea o

    fereastr de invocare (Fig. 1.9) ce va permite selectarea i vizualizarea argumentelor.

    Fig. 1.9 Fereastra de invocare a unui macro

    Chimera folosete inferena pentru determinarea versiunii generalizate a unui macro. Folosirea inferen-

    ei este un lucru comun n limbajele prin demonstraie, iar succesul ei depinde de limitabilitatea dome-

    niului de aplicare (aa cum este cazul Chimera). Cu toate acestea, sunt i limbaje prin demonstraie care

    nu folosesc inferena i un exemplu este Cocoa.

    1.7.2 Forms/3. Programarea vizual bazat pe foi de calcul tabelar

    Forms/3 este un exemplu de LPV bazat pe paradigma foilor de calcul tabelar, implementat de ctre

    Margaret Burnett n 1991, ca prototip al lucrrii sale de disertaie (13). n acest caz, programatorul i

    realizeaz programul prin crearea unui formular i specificarea coninutului acestuia. Aceast paradigm

    este folosit uzual n foile de calcul tabelar comerciale, unde formularul este sub form de gril marcat,

    iar coninutul este specificat prin formulele celulelor.

  • Programare Vizual i Modelare

    Pagina 18

    Programele Forms/3 includ formulare (foi de calcul tabelar) cu celule, doar c celulele nu sunt ncastrate

    ntr-o gril. Un programator Forms/3 creeaz un program manipulnd direct celulele pentru a le plasa pe

    formular i definind o formul pentru fiecare celul prin folosirea unei combinaii flexibile de indicare,

    tastare i gesturi (Fig. 1.10). Calculele unui program sunt determinate complet de aceste formule. For-

    mulele se combin ntr-o reea (unidirecional) de constrngeri, iar sistemul asigur n mod continuu c

    toate valorile afiate pe ecran satisfac aceste constrngeri.

    Fig. 1.10 Definerea suprafeei unui ptrat folosind celule de tip calcul tabelar i formule n Forms/3. Tipurile grafice sunt suportate ca valori de prim clas, iar programatorul poate crea celula cu formula ptratului fie desennd un ptrat, fie tastnd textual specificaiile (spre exemplu, box 30 30)

    Forms/3 este un limbaj Turing complet. Scopul lui este s mreasc domeniul de utilitate al conceptului

    de foi de calcul tabelar prin suportul funcionalitilor avansate necesare pentru programare. Astfel,

    suport faciliti precum grafic, animaie i recursivitate, dar fr a recurge la macrouri de modificare a

    strii sau conexiuni cu limbajele de programare tradiionale. Spre exemplu, Forms/3 ofer o colecie de

    tipuri bogat i extensibil prin faptul c permite ca atributele unui tip s fie definite prin formule, iar o

    instan a unui tip s fie valoare a unei celule, care poate fi referit ca o celul. n Fig. 1.10, o instan a

    tipului box a fost specificat prin desenarea grafic. Aceast specificare poate fi modificat, dac este

    necesar, prin ntinderea elementului grafic prin manipulare direct. n ambele cazuri este asigurat un

    rspuns vizual imediat, conform nivelului 4 de timp de rspuns. Facilitatea concret este prezent prin

    faptul c elementul grafic rezultat este vzut imediat ce suficiente formule au fost oferite pentru a face

    acest lucru posibil. Facilitatea direct este prezent prin mecanismul de manipulare direct pentru spe-

    cificarea elementului grafic, deoarece programatorul demonstreaz specificaiile direct pe elementul

    grafic creat.

    Grupul int al Forms/3 sunt viitorii programatori, adic aceia a cror treab va fi s creeze aplicaii,

    dar a cror formare nu a pus accent pe limbajele de programare tradiionale actuale. Un scop al lui

    Forms/3 a fost s reduc numrul i complexitatea mecanismelor necesare pentru programarea aplica-

    iilor, cu sperana c programatorilor le va fi mai uor dect dac ar folosi limbajele tradiionale, iar pro-

    gramarea va fi mai corect i/sau accelerat. n studii empirice, programatorii au demonstrat corectitu-

  • Programare Vizual i Modelare

    Pagina 19

    dine mai ridicat i vitez att n crearea programului, ct i n depanarea lui, folosind Forms/3 n com-

    paraie cu o varietate de tehnici alternative.

    1.7.2.1 Exemplu de calcul al ariei unui ptrat n Forms/3

    Fereastra principal a Forms/3 (versiune recent de implementare) (13), prezentat n Fig. 1.11, apare

    pe ecran la pornirea aplicaiei. Formularul System, listat n fereastra principal a formularelor, este n-

    totdeauna ncrcat la pornirea sistemului. Pentru a crea un formular nou se apas butonul New Form,

    aciune urmat de apariia unei ferestre de dialog (Fig. 1.12) pentru specificarea numelui formularului.

    Dup crearea unui nou formular, acesta apare listat n fereastra principal.

    Fig. 1.11 Fereastra principal a Forms/3

    Fig. 1.12 Caseta de dialog pentru New Form

    Dup deschiderea formularului Area_box creat anterior (Fig. 1.13), se selecteaz butonul de introducere

    a unei celule cu butonul din stnga al mausului (butonul din stnga este folosit pentru selecie, butonul

    din dreapta este folosit pentru alte sarcini). Cu un clic n spaiul formularului se introduce o nou celul,

    care const ntr-un chenar i un tab pentru formul. Dup inserare, apare un cursor pe numele implicit

    al celulei, care poate fi modificat (n cazul exemplului, Abox). Pentru a introduce o formul se apas pe

    butonul ce indic un cursor pe paleta din stnga, dup care se acioneaz butonul asociat tabului formu-

    lei pentru celul. Va aprea un cmp unde se tasteaz formula (Fig. 1. 14), n cazul de fa valoarea 5,

    dup care se apas butonul Apply. Valoarea celulei este acum afiat. Acesta este un exemplu de rs-

    puns imediat: de fiecare dat cnd se introduce o formul toate valorile afectate sunt reafiate n mod

    automat.

    Fig. 1.13 Formular coninnd o celul nou

    Fig. 1. 14 Caset pentru formula n care se insereaz o for-

    mul

  • Programare Vizual i Modelare

    Pagina 20

    Repetnd procedura se creeaz o nou celul n care se va calcula aria ptratului (Fig. 1.15,) ca fiind

    formula Abox * Abox. Noua celul (denumit Area) va afia numrul 25. Modificarea valorii lui Abox va

    atrage dup sine modificarea valorii celulei Area.

    Fig. 1.15 Formularul finalizat pentru calculul ariei ptratului

    1.7.3 Prograph. Programarea vizual cu fluxuri de date

    Prograph a fost conceput n 1983 de ctre Tomasz Pietrzykowski i Philip T. Cocs (14). Cel de-al doilea

    rmnnd n proiect mai mult vreme i-a adus mbuntiri de-a lungul anilor. Prograph este un LPV

    bazat pe fluxuri de date destinat programatorilor profesioniti. Paradigma bazat pe fluxuri de date este

    modalitatea de programare vizual folosit larg n industrie, dar i de mediile vizuale de programare

    pentru anumite domenii, precum sistemele de vizualizare tiinific i sistemele de simulare

    Prograph este un limbaj funcional i uor de folosit. Datele sunt reprezentate prin linii, iar metodele

    prin diverse dreptunghiuri. Fiecare dreptunghi conine noduri pentru intrri i ieiri. Datele sunt transmi-

    se prin valori, ceea ce permite metodelor s foloseasc drept intrri, ieirile de la alte metode. Prograph

    nu are variabile, ci doar date care curg prin metode.

    Prograph este un limbaj de programare Turing complet, adic orice program care poate fi scris n C++

    (sau orice alt limbaj de nivel nalt) poate fi scris i n Prograph. Programele sunt create construind dia-

    grame de fluxuri de date n cadrul editorului. Clasele, metodele i atributele Prograph sunt reprezentate

    i manipulate grafic.

    Fig. 1.16 prezint un program care calculeaz valoarea ipotenuzei unui triunghi dreptunghic. Datele sunt

    introduse textual i curg de-a lungul liniilor conectate la operaii. Operaiile colecteaz datele i le tran-

    smit spre alte operaii pn se obine rezultatul final, care este vizualizat.

    Prograph asigur un mecanism puternic pentru depanare, folosind extensiv tehnici de vizualizare dina-

    mic. Pentru valorile datelor nivelul de timp de rspuns este 2, deoarece programatorul cere explicit

    vizualizarea acestora cnd dorete s le vad. Cu toate acestea, activitile din timpul rulrii i ordinea

    de execuie a nodurilor pot fi vizualizate pe tot parcursul execuiei, iar dac programatorul modific o

    parte din date sau cod, acestea sunt n mod automat aplicate asupra sistemului. Acest aspect are nive-

    lul 3 de timp de rspuns.

  • Programare Vizual i Modelare

    Pagina 21

    Fig. 1.16 Programarea prin fluxuri de date n Prograph. Programatorul folosete operaii de nivel sczut (primitive) pentru a calcula ipotenuza unui triunghi dreptunghic. Prograph permite numirea i compunerea unor astfel de prafuri de nivel sczut n grafuri de nivel ridicat, care pot fi compuse ulterior n alte grafuri etc.

    O cale prin care aceast paradigm de programare se distinge de alte paradigme (prin prezentarea expli-

    cit a arcelor n graf) este explicitatea sa privind relaionrile fluxurilor de date n cadrul programului.

    Cum numeroase limbaje bazate pe fluxul de date guverneaz chiar i fluxul de control prin fluxul de date,

    arcele sunt suficiente i pentru a reflecta, n mod explicit, fluxul de control.

    1.7.4 KidSim/Cocoa. Programarea vizual bazat pe reguli

    Cocoa (denumit iniial KidSim) este un LPV bazat pe reguli, n care programatorul specific reguli pentru

    demonstrarea unei postcondiii plecnd de la o precondiie. Programatorii vizai sunt copiii, iar dome-

    niul asociat este specificarea simulrilor grafice i jocuri. Cocoa este un limbaj Turing complet, doar c

    facilitile lui nu au fost proiectate pentru programarea de uz general, ci pentru a facilita accesul copiilor

    la programarea propriilor simulri.

    Felul n care atributele concret i direct sunt atinse n Cocoa sunt similare cu Chimera, deoarece ambele

    folosesc demonstraia ca modalitate de a specifica semantica. Cu toate acestea, nivelul de timp de rs-

    puns este diferit, n Cocoa fiind ntre 2 i 3. Nu este nivel 3 pentru anumite tipuri de modificri ale pro-

    gramului (spre exemplu, adugarea unor noi reguli) care nu afecteaz afiarea curent a variabilelor

    pn la cererea expres a programatorului de reluare a rulrii. Pentru alte modificri ale programului

    (modificarea aspectului unui obiect), modificrile sunt imediat propagate pe afiaj.

    n indicarea proprietilor comune tuturor sistemelor bazate pe reguli, Hayes-Roth include abilitatea de

    a le explicita comportamentul (15). n Cocoa, un copil poate crea lumi care s conin o varietate de

    caractere, aspecte i proprieti. O regul specific ce face un caracter ntr-o situaie particular, aspec-

    tul permite caracterului s i modifice nfiarea, iar proprietile sunt folosite pentru a reine informa-

    ii despre caracter. Simularea se face pe baza unui ceas, astfel nct la fiecare tact al acestuia fiecrui

    caracter din scen i se permite funcionarea conform propriilor lumi. Fig. 1.17 (16) prezint un ecran

    Cocoa tipic.

  • Programare Vizual i Modelare

    Pagina 22

    Fig. 1.17 Ecranul Cocoa. Fereastra din colul stnga sus constituie placa de lucru, cu caseta de copiere sub ea. n dreapta, utilizatorul a deschis carneele pentru cele dou personaje de pe plac

    Fiecare caracter are o list de reguli. Cnd unui caracter i vine rndul s acioneze, sistemul parcurge

    lista de reguli, selecteaz prima regul aplicabil strii curente i o execut. Regulile se creeaz prin spe-

    cificarea propriu-zis de ctre programator a aciunilor care vor fi incluse, dup care sistemul le generali-

    zeaz (creeaz regula) pentru a putea fi folosite n mod automat de cte ori este nevoie.

    Fig. 1.18 Crearea unei noi reguli

    Cea mai simpl regul este cea care mut un caracter. Fig. 1.18 (16) prezint un exemplu de creare a

    unei reguli care permite mutarea unui caracter un ptrel la dreapta. Dup apsarea butonului New

    Rule, ntreaga plac se ntunec, cu excepia unui spot de lumin n jurul caracterului, care poate fi di-

    mensionat pentru a include contextul regulii (ptratul din dreapta caracterului). n pasul urmtor, se

    demonstreaz regula prin mutarea caracterului n zona dorit (Fig. 1.18). Reprezentarea vizual a unei

    reguli prezint o imagine cu starea regulii nainte (stnga) i dup (dreapta), unite cu o sgeat. Regula

  • Programare Vizual i Modelare

    Pagina 23

    se interpreteaz: dac este spaiu liber la dreapta mea, m mut n el. Cum regulile sunt revizuite la

    fiecare tact al ceasului, doar aceast simpl regul este suficient pentru deplasarea caracterului de-a

    lungul plcii.

    Fig. 1.19 Regula de salt. Caseta aciunii din dreapta a fost expandat pentru a vizualiza aciunile realizate de regul

    Pot fi create i reguli pentru modificarea aspectului unui caracter. Fig. 1.19 (16) prezint realizarea unei

    reguli pentru saltul unui gard. Programatorul mut caracterul un ptrat deasupra gardului, duce aspectul

    de salt n caseta aspectului curent (current appearance box) de pe pagina de aspect din carneelul

    caracterului, mut caracterul un ptrat la dreapta gardului, dup care revine la aspectul normal.

    Fig. 1.20 Modificarea regulii de mers la dreapta

    De multe ori simulrile devin interesante deoarece caracterele se modific pe parcurs: mbtrnesc,

    obosesc, devin mai puternice sau mai detepte. Pentru a permite modificarea strii interne a caractere-

    lor, Cocoa ofer atribuirea de proprieti, care pot fi predefinite sau create de utilizator. Spre exemplu,

    utilizatorul poate crea proprieti precum vrst sau flmnd pentru un anumit caracter. Aceste

    proprieti joac rolul instanelor din programarea orientat pe obiecte. Fig. 1.20 (16) prezint modifica-

    rea regulii de mers la dreapta astfel nct caracterul s flmnzeasc. Utilizatorul creeaz proprietatea

    denumit hunger n lista de proprieti a caracterului cu valoare iniial 0. Pentru a modifica regula, se

    folosete butonul Add On pentru acea regul, care execut aciunile asociate regulii, dup care permite

    utilizatorului s demonstreze noi aciuni. n acest caz, utilizatorul modific valoarea din proprietatea

    hunger din 0 n 1. Sistemul generalizeaz aceast demonstraie, dndu-i sensul Adun 1 la foamea

  • Programare Vizual i Modelare

    Pagina 24

    mea. Dac nu este aceasta interpretarea demonstraiei, utilizatorul i poate edita descrierea. Cocoa

    include i un calculator pentru a permite editarea unor reguli complicate.

    n fiecare ciclu de execuie, regulile asociate fiecrui caracter sunt parcurse n lista acestuia de sus n jos

    (Fig. 1.21). Indicatorul din dreptul unei reguli este off (gri) nainte ca regula s fie luat n consideraie.

    Apoi, dac regula nu poate fi aplicat la starea curent a caracterului, indicatorul devine rou. Dac re-

    gula poate fi aplicat, este executat i indicatorul din dreptul ei devine rou. Dup aplicarea unei reguli

    pentru un caracter, acesta este oprit i nu se mai verific nicio regul pentru el pn n urmtorul ciclu.

    (4)

    Fig. 1.21 Un crtor de zid n Cocoa care urmeaz regulile demostrate pentru el. Tocmai a terminat regula 2, care l pune n poziia cerut de regula 1 (n pasul urmtor)

    1.7.5 Cube. Limbaje de programare vizual 3D

    Cube, realizat de M. Najork, reprezint un avans important n design-ul limbajelor de programare vizuale,

    fiind primul limbaj vizual 3D. Deoarece programele Cube sunt traduse n reprezentri interne mai simple

    pentru verificare i interpretare, limbajul ar fi mai degrab unul hibrid. Cu toate acestea, utilizatorul nu

    este expus niciodat la nicio reprezentare textual, ca urmare este mai corect dac se spune c limbajul

    este foarte aproape de a fi complet vizual.

    Cube folosete o paradigm de flux de date pentru construcia programelor. Lucrul n 3D asigur un

    numr de avantaje asupra limbajelor 2D tradiionale. Spre exemplu, lucrul n 3D i permite sistemului s

    afieze mai multe informaii ntr-un mediu cu care este mai uor de interacionat dect cu o reprezenta-

    re 2D care folosete aceleai dimensiuni ale ecranului (3). ntr-o vizualizare 3D, programatorul este liber

    s i modifice punctul de vedere n interiorul lumii virtuale pentru a se uita la orice seciuni particular a

    programului. Acest tip de flexibilitate nu este disponibil n LPV-urile 2D

  • Programare Vizual i Modelare

    Pagina 25

    Fig. 1.22 Function to compute the factorial of a number in Cube

    Fig. 1.22 prezint principalele componente ale unui program Cube, folosite pentru a descrie o funcie

    recursiv pentru calculul factorialului unui numr dat (17). Programele Cube sunt compuse din cuburi

    suport, cuburi predicat, cuburi de definire, porturi, conducte i planuri. ntreaga structur din Fig. 1.22

    este nconjurat de un cub de definire care asociaz icoana ! cu funcia definit n interiorul cubului.

    Cubul de definire are dou porturi conectate la el, unul la stnga i unul la dreapta. Portul din stnga

    asigur intrarea, iar portul din dreapta este ieirea, dei, tehnic vorbind, ambele porturi pot asigura am-

    bele funcii, n Cube porturile fiind bidirecionale. Cele dou porturi sunt conectate prin conducte la

    cuburile suport n planul de jos al diagramei, care reprezint cazul de baz al recursivitii. Fiecare plan

    reprezint o diagram de fluxuri de date. Pentru situaia de start, diagrama asigur valorile implicite

    pentru porturi i indic ce tip de valori poate accepta sau produce fiecare port. Dac valoarea de la por-

    tul de intrare este zero, atunci planul de jos este activ i valoarea din cubul de suport din dreapta (unu)

    pleac spre portul de ieire. Dac intrarea este mai mare dect zero, atunci este satisfcut predicatul din

    planul de sus, este extras valoarea unu din intrare de ctre ramura de jos a diagramei de fluxuri de date

    din partea de sus. Diferena este introdus n apelul recursiv al funciei factorial, iar rezultatul este mul-

    tiplicat cu valoarea de intrare. Rezultatul este trimis la portul de ieire. Dup definirea funciei factorial

    n program, ea poate fi apelat prin simpla conectare a cubului predicat etichetat cu icoana ! la cuburi

    de suport, prin cele dou porturi (Fig. 1.23 (18)).

  • Programare Vizual i Modelare

    Pagina 26

    Fig. 1.23 Folosirea programului factorial, dup evaluare

    1.8 Programarea vizual i abstractizarea

    Una dintre provocrile legate de programarea vizual o reprezint scalarea limbajelor pentru a dezvolta

    programe ct mai extinse. Aceasta este o problem mai mare pentru LPV-uri dect pentru limbajele

    tradiionale textuale din motive legate de reprezentare, designul i implementarea limbajului i nouta-

    tea relativ a domeniului. Spre exemplu, unele mecanisme vizuale folosite pentru a obine caracteristici

    precum explicit pot ocupa un spaiu att de mare nct devine dificil meninerea contextului. De ase-

    menea, este dificil de aplicat tehnici dezvoltate pentru limbajele tradiionale, deoarece ele pot aduce cu

    sine reintroducerea complexitii pe care LPV-urile au ncercat s o nlture sau s o simplifice.

    Dezvoltri recente n domeniul abstractizrii au fost foarte importante pentru scalabilitatea LPV-urilor.

    Cele dou tipuri de abstractizare, cele mai rspndite att n programarea vizual, ct i n programarea

    textual, sunt abstractizarea procedural i abstractizarea datelor. n particular, abstractizarea procedu-

    ral s-a demonstrat a fi suportat ntr-o varietate de LPV-uri. Un atribut cheie n suportul abstractizrii

    procedurale n LPV-uri l-a reprezentat consistena cu restul programrii n acelai LPV. Soluii reprezen-

    tative includ: posibilitatea programatorului de a selecta, numi i iconifica o seciune a unui graf de flux

    de date (Fig. 1.16), care adaug un nod, reprezentnd subgraful, la o bibliotec de noduri funcii ntr-un

    limbaj de tip flux de date; setarea unor foi de calcul separate (Fig. 1.10), care pot fi generalizate n mod

    automat pentru a permite funcii definite de utilizator ntr-un limbaj bazat pe formulare; nregistrarea

    i generalizarea unei secvene de manipulri directe (Fig. 1.5), ntr-un limbaj prin demonstrare.

    Abstractizarea datelor a cunoscut un proces mai lent de dezvoltare n LPV-uri, mai ales pentru c, de

    multe ori, este dificil de gsit o cale pentru a menine caracteristici precum concret i rspuns direct, i a

    aduga suport pentru ideile centrale legate de abstractizarea datelor, precum generalitate i ascunderea

    informaiei. Cu toate acestea, n anumite LPV-uri a aprut suport pentru abstractizarea datelor. Spre

  • Programare Vizual i Modelare

    Pagina 27

    exemplu, n Form/3, un nou tip de dat este definit n foaia de calcul tabelar astfel: cu celule obinuite se

    definesc operaii sau metode i cu dou celule difereniate se permite compunerea obiectelor complexe

    din cele simple i definirea modului de vizualizare pe ecran al obiectului. n Cocoa, aspectul fiecrui ca-

    racter este desenat folosind un editor grafic i fiecare demonstraie a unui noi reguli aparine tipului

    caracterului manipulat, asigurnd aproximativ funcionalitatea unei operaii sau metode. Ambele,

    Form/3 i Cocoa, asigur i un suport limitat pentru motenire.

    1.9 Concluzii privind programarea vizual

    Domeniul limbajelor de programare vizual abund cu exemple ale eforturile de a lrgi accesibilitatea i

    mri puterea programrii calculatoarelor. Dei numeroasele proiecte existente variaz n detaliile oferite,

    n special n metafora vizual implicat i n domeniul de aplicare intit, toate mprtesc scopul comun

    al mbuntirii procesului de programare. n plus, cercetrile recente pentru solidificarea fundamente-

    lor teoretice ale programrii vizuale i eforturile serioase depuse pentru dezvoltarea unor clasificri for-

    male standard ale LPV-urilor indic faptul c domeniul a nceput s se reevalueze i s se maturizeze.

    Chiar dac domeniul s-a dezvoltat n ultimii douzeci de ani, contribuii incipiente importante, precum

    Sketchpad i Pygmalion, i-au meninut influena n numeroase design-uri de LPV-uri.

    n ciuda migrrii spre afiajele grafice i a interaciunilor incluse n LPV-uri, un studiu al domeniului arat

    c nu se justific, nc, excluderea n totalitate a textului. n timp ce multe LPV-uri pot reprezenta toate

    aspectele unui program n mod vizual, aceste programe sunt, n general, mai greu de citit i de folosit

    dect cele care folosesc text pentru etichete i anumite operaii atomice. Spre exemplu, dei o operaie

    precum adunarea poate fi reprezentat grafic n LPV-uri, fcnd acest lucru se poate ncrca foarte mult

    afiajul. Pe de alt parte, folosind text pentru a reprezenta o astfel de operaie atomic se obine un

    afiaj mult mai simplu, fr a pierde metafora vizual global.

    n condiiile n care grafica computerizat, att hardware, ct i software, continu s-i mbunteasc

    performana i s-i scad preul, LPV-uri tridimensionale, precum Cube, atrag atenia comunitii de

    cercettori. LPV-urile 3D nu doar rezolv problema includerii unei cantiti mari de informaii pe un

    ecran destul de mic, ci i exemplific sinergia inerent dintre limbajele de programare, grafica pe calcu-

    lator i interfeele om-calculator, ceea ce a fost o marc a programrii vizuale nc de la nceputurile sale.

  • Programare Vizual i Modelare

    Pagina 28

    2 Modelare cu reele Petri (19)

    2.1 Introducere

    Creterea n complexitate a sistemelor industriale moderne, precum producia, controlul procesului,

    sisteme de comunicaii etc., a indus apariia a numeroase probleme privind dezvoltarea acestora. n faza

    de planificare apare confruntarea cu capabilitile crescute ale acestor sisteme, datorit combinaiilor

    unice de hardware i software care opereaz sub un numr mare de constrngeri ce rezult din resurse-

    le limitate ale sistemului. n condiiile naturii complexe i intensive a capitalului sistemelor moderne

    industriale, designul i operarea acestora necesit modelare i analiz pentru selectarea alternativei

    optime de design i a politicii de operare. Este binecunoscut faptul c fluxul n procesul de modelare

    poate contribui substanial la timpul i costul de dezvoltare. Chiar i eficiena operaional poate fi afec-

    tat. Din acest motiv, o atenie special trebuie acordat corectitudinii modelor care sunt folosite la

    toate nivelurile de planificare.

    Ca unelte grafice i matematice, reelele Petri asigur un mediu uniform pentru modelare, analiz for-

    mal i design al sistemelor cu evenimente discrete. Unul dintre principalele avantaje al folosirii reelelor

    Petri l constituie faptul c acelai model este folosit att pentru analiza proprietilor comportamentale

    i evaluarea performanelor, ct i pentru construcia sistematic a simulatoarelor i controlerelor cu

    evenimente discrete. Reelele Petri au fost numite dup Carl A. Petri, care a creat n 1962 o unealt ma-

    tematic sub form de reea pentru studiul comunicrii cu automatele. Dezvoltarea lor ulterioar a fost

    uurat de faptul c reelele Petri pot fi folosite pentru modelarea unor proprieti precum sincroniza-

    rea proceselor, evenimente asincrone, operaii concurente, rezolvarea conflictelor sau partajarea resur-

    selor. Aceste proprieti caracterizeaz sistemele cu evenimente discrete care includ sistemele automa-

    te industriale, sistemele de comunicare i sistemele bazate pe calculator. Toate acestea transform ree-

    lele Petri ntr-o unealt promitoare i o tehnologie pentru aplicaii n automatizri industriale.

    Ca unealt grafic, reelele Petri asigur un puternic mediu de comunicare ntre utilizator (de regul,

    inginer) i client. Cerinele complexe din caietele de sarcini pot fi reprezentate grafic folosind reele Petri

    n locul unor descrieri textuale ambigue sau al unor notaii matematice dificil de neles de ctre client.

    Acest aspect, combinat cu existena unor unelte computerizate care permit simularea grafic interactiv

    a reelelor Petri, asigur inginerilor de dezvoltare o unealt puternic ce s i asiste n procesul de dez-

    voltare al sistemelor complexe.

    Ca unealt matematic, un model de reea Petri poate fi descris de un set de ecuaii lineare algebrice

    sau de alte modele matematice care s reflecte comportamentul sistemului. Acest lucru permite o veri-

    ficare formal a proprietilor asociate comportamentului sistemului vizat (relaii de preceden ntre

    evenimente, operaii concurente, sincronizrile necesare, eliminarea situaiilor de blocare (deadlock),

    activitile repetitive i excluderile mutuale ale resurselor partajate, pentru a aminti cteva dintre ele).

    Validarea modelului prin simulare poate doar produce un set limitat de stri ale sistemului modelat, i

    astfel poate arta doar prezena (nu i absena) erorilor din model i specificaiile sale de baz. Abilita-

    tea reelelor Petri de a verifica formal modelul este important n mod special pentru sistemele n timp

  • Programare Vizual i Modelare

    Pagina 29

    real critice din punct de vedere al securitii, precum sistemele de control al traficului aerian, sistemele

    de control al traficului feroviar, sistemele de control al reactoarelor nucleare etc. Reelele Petri au fost

    folosite pentru modelarea sistemelor de timp real tolerante la defectare i critice din punct de vedere al

    securitii, pentru detectarea erorilor i pentru monitorizarea proceselor.

    Un domeniu de succes de aplicare al reelelor Petri l constituie modelarea i analiza protocoalelor de

    comunicare (nc de la nceputul anilor 70). n ultimii ani au fost propuse cteva abordri care permit

    construirea modelelor de reele Petri pentru protocoale din specificaiile scrise ntr-un limbaj relativ

    nespecializat.

    Reele Petri, ns, au fost folosite n mod extensiv pentru modelarea i analiza sistemelor de producie.

    n acest domeniu, reeaua Petri reprezenta linii de producie cu buffer-e, sisteme automate de producie,

    sisteme flexibile de producie, linii automate de asamblare, sisteme cu partajarea resurselor i, recent,

    sisteme de producie de tip just-in-time.

    Un alt domeniu de succes l constituie aplicarea reelelor Petri n modelarea controlerelor secveniale.

    Controlerele logice programabile (PLC) sunt folosite n mod uzual pentru controlul secvenial al sisteme-

    lor automate. Ele sunt proiectate folosind diagrame logice scar (ladder logic diagrams), care sunt cu-

    noscute ca fiind dificile de depanat i modificat. Controlerele secveniale bazare pe reele Petri, pe de

    alt parte, sunt uor de proiectat, implementat i ntreinut. La nceputul anilor 80, Hitachi Ltd. a dezvol-

    tat un controler secvenial bazat pe reele Petri care a fost folosit cu succes n aplicaii reale pentru con-

    trolul sistemului de asamblare a pieselor i n sistemul automat de ncrcare/descrcare din depozit.

    Utilizatorii reelelor Petri, conform statisticilor, au redus substanial timpul de dezvoltare, n comparaie

    cu metodele tradiionale.

    Reele Petri au fost folosite extensiv i n dezvoltri software. Utilizarea n acest domeniu s-a concentrat

    pe modelarea i analiza sistemelor software, iar cea mai complex dezvoltare a implicat folosirea reele-

    lor Petri colorate. S-a demonstrat c acest tip de reele Petri este un limbaj folositor pentru proiectarea,

    specificarea, simularea, validarea i implementarea sistemelor software complexe.

    Ca unealt matematic, reelele Petri permit evaluarea performanelor sistemelor modelate. Perfor-

    manele deterministe i stocastice pot fi msurate i evaluate folosind o gam larg de modele de reele

    Petri care ncorporeaz n definiia lor funcii de timp determinist i/sau probabilistic. Evaluarea perfor-

    manelor poate fi realizat fie prin tehnici analitice, bazate pe rezolvarea proceselor (semi)Markov de

    baz, sau prin simularea cu evenimente discrete. Folosirea modelelor care ncorporeaz funcii de timp

    cu distribuie probabilistic permit obinerea ratelor de producie pentru modelele sistemelor de fabri-

    caie, capacitatea de producie, ntrzieri, capacitatea pentru comunicare i modelele sistemelor cu mi-

    croprocesor, utilizarea resurselor critice i msuri de fiabilizare ale acestora. n ultimii ani, aceast clas

    de reele Petri a fost folosit extensiv pentru modelarea i studiul performanelor analitice ale sisteme-

    lor multiprocesor, ale magistralelor sistemelor multiprocesor, ale canalelor de comunicare DSP, ale arhi-

    tecturilor paralele de calculatoare, precum i ale algoritmilor paraleli i distribuii.

    Un alt domeniu de aplicare l constituie reelele de comunicare. S-a lucrat pe reele locale cu fibr optic

    (Fiber Optics Local Area Networks) precum Expressnet, Fastnet, D-Net, U-Net, Token Ring. Protocoalele

  • Programare Vizual i Modelare

    Pagina 30

    de tip fieldbuss, precum FIP i ISA-SP50 au atras foarte mult atenie n ultimii ani, acest lucru fiind oare-

    cum normal, ele fiind reele importante pentru sistemele industriale complexe. De asemenea, s-a sem-

    nalat un interes n cretere pentru modelarea i evaluarea reelelor de mare vitez (High Speed

    Networks), cruciale pentru dezvoltarea cu succes a sistemelor multimedia.

    Reelele Petri cu extindere de timp, combinate cu tehnici euristice de cutare, au fost folosite pentru

    modelarea i studiul problemelor de dispecerizare din sistemele de fabricaie i din sistemele cu roboi.

    De asemenea, acest tip de reele Petri au fost folosite i pentru modelarea i analiza proceselor chimice

    continue.

    2.2 Descrierea reelelor Petri

    O reea Petri poate fi identificat cu un tip particular de grafuri orientate bipartite populate cu trei tipuri

    de obiecte. Aceste obiecte sunt locuri, tranziii i arce orientate care conecteaz locuri cu tranziii sau

    tranziii cu locuri. Din punct de vedere grafic, locurile sunt reprezentate prin cercuri iar tranziiile prin

    bare sau dreptunghiuri. Un loc este intrare pentru o tranziie dac exist un arc orientat de la acel loc la

    tranziie. Un loc este ieire pentru o tranziie dac exist un arc orientat de la tranziie la loc. n forma sa

    cea mai simpl, o reea Petri poate fi reprezentat printr-o tranziie mpreun cu locurile sale de intrare

    i de ieire. Aceast reea elementar poate fi folosit pentru reprezentarea unor aspecte diverse ale

    sistemelor modelate. Spre exemplu, locurile de intrare (ieire) pot reprezenta precondiii (postcondiii),

    iar tranziiile evenimente. Locurile de intrare pot semnifica disponibilitatea resurselor, tranziia

    utilizarea lor, iar locurile de ieire eliberarea resurselor. Un exemplu de reea Petri este prezentat n

    Fig. 1.24. Aceast reea este format din cinci locuri, reprezentate prin cercuri, patru tranziii, reprezen-

    tate prin bare i arce orientate ce conecteaz locurile cu tranziiile i tranziiile cu locurile. n reea, locul

    p1 este intrare pentru tranziia t1, iar locurile p2, i p3 sunt ieiri pentru tranziia t1.

    Fig. 1.24 Exemplu de reprezentare grafic a unei reele Petri

    Pentru a studia comportamentul dinamic al sistemului modelat, adic strile acestuia i modificrile lor,

    fiecare loc poate deine niciunul sau un numr pozitiv de jetoane, reprezentate grafic prin mici cercuri

  • Programare Vizual i Modelare

    Pagina 31

    solide, aa ca n Fig. 1.24. Prezena sau absena unui jeton dintr-un loc poate indica faptul c o condiie

    asociat cu acel loc este adevrat sau fals. Pentru un loc care reprezint disponibilitatea unor resurse,

    numrul de jetoane n loc indic numrul resurselor disponibile. La un anumit moment dat de timp, dis-

    tribuia jetoanelor n locuri, denumit marcajul reelei Petri, definete starea curent a sistemului mode-

    lat. Marcajul unei reele Petri cu m locuri este reprezentat de un vector M cu dimensiunea (m x 1), ale

    crui elemente, notate M(p), sunt numere ntregi pozitive reprezentnd numrul de jetoane n locurile

    corespunztoare. O reea Petri ce conine jetoane se numete reea marcat. Spre exemplu, n modelul

    de reea Petri din Fig. 1.24, M = (1,0,0,0,0)T.

    Formal, o reea Petri poate fi definit astfel:

    RP = (P, T, I, 0, Mo); unde

    1) P = {p1, p2, pm} este un set finit de locuri,

    2) T = { t1, t2, tm } este un set finit de tranziii, , i 0,

    3) : ( ) este o funcie de intrare care definete arcele orientate de la locuri la tranzi-

    ii, unde N este un set de ntregi pozitivi,

    4) : ( ) este o funcie de ieire care definete arcele orientate de la tranziii la locuri

    i

    5) : este marcajul iniial.

    Dac I(p, t) = k (O(p, t) = k), atunci exist k arce orientate (paralele) conectnd locul p cu tranziia t (tran-

    ziia t cu locul p). Dac I(p, t) = 0 (O(p, t) = 0), atunci nu exist niciun arc orientat care s conecteze p cu t

    (t cu p). Frecvent, n reprezentarea grafic, arcele paralele care conecteaz un loc (tranziie) cu o tranzi-

    ie (loc) sunt reprezentate printr-un singur arc etichetat cu multiplicitatea sa, sau ponderea k. Aceast

    reprezentare compact a arcelor multiple este reprezentat n Fig. 1.25.

    Fig. 1.25 (a) Arce multiple. (b) Reprezentare compact a arcelor multiple.

    Modificnd distribuia jetoanelor n locuri, lucru care poate reflecta apariia unor evenimente sau execu-

    ia unor operaii, se poate studia comportamentul dinamic al sistemului modelat. Urmtoarele reguli

    sunt folosite pentru controlul fluxului de jetoane:

    Regula de activare. O tranziie t se spune c este activat dac fiecare loc de intrare p al lui I conine cel

    puin numrul de jetoane egal cu ponderea arcelor orientate ce conecteaz p cu t.

    Regula de execuie:

  • Programare Vizual i Modelare

    Pagina 32

    (a) O tranziie activat t poate sau nu s fie executat dependent de interpretarea adiional asoci-

    at i

    (b) Execuia unei tranziii activate t nltur din fiecare loc de intrare p un numr de jetoane egal cu

    ponderea arcului orientat care conecteaz p cu t. De asemenea, depoziteaz n fiecare loc de ie-

    ire p un numr de jetoane egal cu ponderea arcului direcional care conecteaz t cu p.

    Fig. 1.26 (a) Tranziia t1 activat. (b) Tranziia activat t1 este executat

    Regulile de activare i de execuie sunt ilustrate n Fig. 1.26. n Fig. 1.26 (a), tranziia t1 este activat

    deoarece locul de intrare p1 al tranziiei t1 conine dou jetoane i I(p1, t1) = 2. Execuia tranziiei activate

    t1 nltur din locul de intrare p1 dou jetoane, deoarece I(p1, t1) = 2, i depoziteaz un jeton n locul de

    ieire p3, O(p3, t1) = 1 i dou jetoane n locul de ieire p2, O(p2, t1) = 2. Toate acestea sunt reliefate n Fig.

    1.26 (b).

    Fig. 1.27 Reea Petri cu un arc inhibitor

    Puterea de modelare a reelelor Petri poate fi crescut prin adugarea abilitii de testabilitate zero,


Recommended