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,
