Programare Vizuala Si Modelare

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

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


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

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

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

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

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:

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

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)


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

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

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.

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.

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

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-

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.

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-

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

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.

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.

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

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

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


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)).

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

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.


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

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

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
p
1
este intrare pentru tranziia t
1
, iar locurile p
2
, i p
3
sunt ieiri pentru tranziia t
1
.

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

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 = {p
1
, p
2
, p
m
} este un set finit de locuri,
2) T = { t
1
, t
2
, t
m
} este un set finit de tranziii, P I , i P I u,
3) I: (P I) N este o funcie de intrare care definete arcele orientate de la locuri la tranzi-
ii, unde N este un set de ntregi pozitivi,
4) 0: (P I) N este o funcie de ieire care definete arcele orientate de la tranziii la locuri
i
5) H
0
: P N 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:

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 t
1
activat. (b) Tranziia activat t
1
este executat
Regulile de activare i de execuie sunt ilustrate n Fig. 1.26. n Fig. 1.26 (a), tranziia t
1
este activat
deoarece locul de intrare p
1
al tranziiei t
1
conine dou jetoane i I(p
1
, t
1
) = 2. Execuia tranziiei activate
t
1
nltur din locul de intrare p
1
dou jetoane, deoarece I(p
1
, t
1
) = 2, i depoziteaz un jeton n locul de
ieire p
3
, O(p
3
, t
1
) = 1 i dou jetoane n locul de ieire p
2
, O(p
2
, t
1
) = 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,
adic abilitatea de a testa dac un loc nu are jetoane. Acest lucru este realizat prin introducerea unui arc
inhibitor, care conecteaz un loc de intrare cu o tranziie i este reprezentat grafic cu un arc terminat cu
un mic cerc (Fig. 1.27). Prezena unui arc inhibitor ntre un loc de intrare i o tranziie va schimba condii-
ile de activare a tranziiei. n acest caz, tranziia este activat dac fiecare loc de intrare, conectat la
tranziie printr-un arc normal (terminat cu sgeat), conine cel puin numrul de jetoane egal cu pon-
derea arcului i nici un jeton nu este prezent n fiecare loc de intrare conectat la tranziie printr-un arc
inhibitor. Regula de execuie a tranziiei este aceiai, doar c nu modific marcajul locurilor conectate
prin arc inhibitor.
Se spune c o reea Petri este pur sau fr bucle dac nu exist un loc care s fie i intrare i ieire a
aceleiai tranziii. O reea Petri care conine bucle poate fi convertit la o reea Petri pur, ca n Fig. 1.28.

Pagina 33

Fig. 1.28 nlturarea buclelor

Fig. 1.29 Model de reea Petri pentru un sistem multirobot
Pentru a ilustra modul n care reelele Petri pot fi folosite pentru a modela proprieti precum activiti
concurente, sincronizare, excludere mutual etc., se consider un exemplu simplu al unui sistem cu ro-
boi. Sistemul este reprezentat de reeaua Petri din Fig. 1.29, cu detalii n Tabelul 1. n acest model, dou
brae robotizate realizeaz operaii de preluare i plasare, accesnd un spaiu comun la preluarea sau la
transferul pieselor. Pentru a evita coliziunile, se presupune c doar un robot poate accesa spaiul de
lucru la un anumit moment de timp. n plus, se consider c spaiul de lucru conine un buffer cu spaiu
limitat pentru produse. Exemplul poate reprezenta operarea a dou brae robotizare ntr-un sistem cu
dou maini unelte, unde un bra transfer semiprodusele de la prima main n buffer, iar celalalt bra
transfer semiprodusele de la buffer la a doua main.
Locuri (cu jetoane) Interpretare
p
1
(p
4
) Robotul R
1
(R
2
) realizeaz operaii n afara spaiului comun
P
2
(p
5
) Robotul R
1
(R
2
) ateapt accesul n spaiului comun
p
3
(p
4
) Robotul R
1
(R
2
) realizeaz operaii n spaiului comun
p
7
Excludere mutual
p
8
(p
9
) Buffer plin (gol)
Tranziii Interpretare
t
1
(t
4
) Robotul R
1
(R
2
) cere acces n spaiului comun
t
2
(t
5
) Robotul R
1
(R
2
) intr n spaiului comun
t
3
(t
4
) Robotul R
1
(R
2
) prsete spaiului comun
Tabel 1 Interpretarea locurilor i tranziiilor pentru modelul de reea Petri
al sistemului de asamblare multirobot

Pagina 34

n acest model, locurile p
1
, p
2
, p
3
i tranziiile t
1
, t
2
, t
3
modeleaz activitile braului robotizat R1. Locuri-
le p
4
, p
5
, p
6
i tranziiile t
4
, t
5
, t
6
modeleaz activitile braului robotizat R2. Tranziiile t
1
i t
4
reprezint
activiti concurente ale lui R1 i R2. Fiecare dintre aceste tranziii poate fi tras nainte sau dup sau n
paralele cu cealalt. Accesul la spaiul comun necesit sincronizarea activitilor braelor pentru a evita
coliziunea. Doar un bra robotizat poate accesa spaiul comun de lucru la un anumit moment de timp.
Aceast sincronizare este realizat prin mecanismul de excludere mutual implementat de subreeaua
format din locurile p
7
, p
3
, p
6
i tranziiile t
2
,

t
3
, t
5
, t
6
. Tragerea tranziiei t
2
dezactiveaz t
5
, presupunnd
c t
5
este activat, i viceversa. Astfel, doar un bra robotizat poate accesa spaiul comun la un moment
dat. n plus, se consider capacitatea bufferului ca fiind b. n acest fel, spre exemplu, dac p
8
este gol,
atunci t
2
nu poate fi activat. Aceast mpiedic braul R1 s ncerce transferul unei piese ctre buffer
cnd acesta este plin. De asemenea, R2 nu poate accesa bufferul dac nu sunt piese n el, adic locul p
9

este gol.

2.3 Proprieti ale reelelor Petri
Ca instrument matematic, reelele Petri posed un numr de proprieti. Aceste proprieti, atunci cnd
sunt interpretate n contextul sistemului modelat, permit designer-ului de sistem s identifice prezena
sau absena proprietilor funcionale specifice domeniului de aplicare al sistemului proiectat. Astfel,
pot fi distinse dou tipuri de proprieti: comportamentale i structurale. Proprietile comportamentale
sunt acelea care depind de starea iniial, sau marcajul, unei reele Petri i de topologia acesteia. Vor fi
discutate n cele ce urmeaz proprieti precum accesibilitatea, limitabilitatea, conservativitatea, nivelul
de activare (liveness), reversibilitatea i starea de pornire (home state).
2.3.1 Accesibilitate
O problem important n designul sistemelor distribuite const n capacitatea sistemului de a atinge o
anumit stare sau de a prezenta un comportament funcional particular. n general, ntrebarea la care se
caut rspuns este dac sistemul modelat cu reele Petri are toate proprietile dorite, aa cum sunt ele
specificate n cerine, i nicio proprietate nedorit.
Pentru a afla dac sistemul modelat poate atinge o anumit stare ca rezultat al comportamentului func-
ional cerut, este necesar gsirea unei astfel de secvene de execuii ale tranziiilor care va avea ca
efect transformarea marcajului M
0
n M
i
, unde M
i
reprezint starea specific i secvena de execuii re-
prezint comportamentul funcional cerut. Trebuie subliniat faptul c sistemele reale pot atinge o anu-
mit stare prin mai multe comportamente funcionale permise. ntr-o reea Petri, acest lucru este reflec-
tat de existena unor secvene specifice de execuii de tranziii, reprezentnd comportamentul funcio-
nal cerut ,care vor transforma un marcaj M
0
n marcajul M
i
cerut. Dac ntr-un model de reea Petri exis-
t secvene adiionale de execuie a tranziiilor care s transforme un marcaj M
0
n marcajul M
i
poate
indica faptul c acel model de reea Petri nu reflect cu exactitate structura i dinamica sistemului des-
cris. De asemenea, acest fapt poate indica i prezena unor aspecte neanticipate privind comportamen-
tul funcional al sistemului real, ceea ce nseamn c reeaua Petri reflect cu precizie specificaiile sis-
temului descris.

Pagina 35

Un marcaj M
i
este accesibil pornind de la marcajul M
0
dac exist e secven de execuie a tranziiilor
care transform marcajul M
0
n M
i
. Un marcaj M
1
este imediat accesibil dup marcajul M
0
dac o execu-
ie a tranziiilor activate din M
0
determin obinerea marcajului M
1
. Spre exemplu, n modelul sistemului
cu multirobot din Fig. 1.29, starea n care braul robotic R1 realizeaz sarcini n spaiul comun, n timp ce
braul robotic R2 ateapt n afara spaiului, este reprezentat de vectorul M
i
= (0, 0, 1, 0, 1, 0, 0, 2, 1)
T
.
M
i
este accesibil din marcajul iniial M
0
, unde M
0
= (1, 0, 0, 1, 0, 0, 1, 3, 0)
T
, prin urmtoarea secven de
execuie a tranziiilor: t
1
t
2
t
4
. Marcajul M
i
= (0, 1, 0, 0, 1, 0, 1, 3, 0)
T
, care reprezint starea sistemului n
care braul robotic R1 ateapt accesul n spaiul comun i braul robotic R2 realizeaz sarcini n afara
spaiului comun, este accesibil imediat din marcajul iniial M
0
prin execuia tranziiei t
1
. n M
0
,att tran-
ziia t
1
, ct i tranziia t
4
, sunt activate. Setul tuturor marcajelor accesibile din M
0
este denumit setul de
accesibilitate i este notat R(M
o
). Setul tuturor secvenelor posibile de execuie din M
0
este notat cu
L(M
o
). n acest fel, problema identificrii existenei unei stri specifice M
i
n care sistemul poate s ajun-
g poate fi redefinit ca problema gsirii lui H

R(H
0
).
2.3.2 Limitabilitate i siguran
The regul, locurile sunt folosite pentru reprezentarea unei zone de pstrare a datelor n comunicare
sau sistemele computerizate, a unor produse sau zone de pstrare a uneltelor n sistemele de producie
etc. Este foarte important de stabilit dac strategiile de control stabilite asigur evitarea strii de supra-
ncrcare a acestor zone. Zonele de pstrare a datelor pot pstra, fr a le corupe, doar un numr res-
tricionat de pri de date. n sistemele de fabricaie, ncercarea de a nmagazina mai multe unelte n
zona destinat acestui lucru poate duce la defectarea echipamentului. Proprietatea unei reele Petri
care permite identificarea n cadrul sistemului modelat a situaiei de suprancrcare se numete limitabi-
litate. O reea Petri este k-limitat dac numrul de jetoane n orice loc p, unde p P, este totdeauna
mai mic sau egal cu k (k este un numr ntreg pozitiv), pentru orice marcaj M accesibil din marcajul iniial
M
0
, H R(H
0
). O reea Petri este sigur dac este 1-limitat (Fig. 1.30). ntr-o astfel de reea, niciun loc
nu poate conine mai mult de un jeton. O reea Petri este nelimitat dac exist cel puin un loc care s
conin un numr orict de mare de jetoane (Fig. 1.31, locul p
4
).

Fig. 1.30 Reea Petri sigur

Fig. 1.31 Reea Petri nelimitat

2.3.3 Conservativitate
n sistemele reale, numrul resurselor utilizate este, n mod normal, limitat prin constrngeri financiare
sau de alt gen. Dac jetoanele sunt utilizate pentru reprezentarea resurselor, al cror numr ntr-un

Pagina 36

sistem este fix, atunci numrul jetoanelor din reeaua Petri a respectivului sistem ar trebui s rmn
neschimbat indiferent de marcajul curent al sistemului. Aceast directiv descinde din faptul c resurse-
le nu pot fi nici create, nici distruse, cu excepia cazului cnd ar trebui s se ntmple aa. Spre exemplu,
o unealt distrus poate fi nlturat din celula de fabricare, iar numrul uneltelor disponibile se va re-
duce.
Fig. 1.32 Reea Petri conservativ n raport cu w = [1,1,2,1,1]

Fig. 1.33 Reea Petri strict conservativ

O reea Petri este conservativ dac numrul de jetoane este conservat. Din punct de vedere structural,
acest lucru este posibil doar dac numrul de arce de intrare n fiecare tranziie este egal cu numrul de
arce de ieire. n sistemele reale, ns, resursele sunt, n mod frecvent, combinate astfel nct anumite
sarcini s fie executate, apoi separate dup finalizarea sarcinilor. Spre exemplu, ntr-un sistem de fabri-
caie flexibil un vehicul ghidat automat colecteaz paleii cu produse de la o celul de prelucrare i i
transport la o staie de descrcare unde paleii sunt preluai (scenariu ilustrat n Fig. 1.32). Tranziia t
1

modeleaz ncrcarea unui palet ntr-un vehicul. Tranziia t
2
reprezint livrarea paletului la staia de des-
crcare i nlturarea acestuia de pe vehicul. Dei numrul de jetoane se schimb de la dou la unu
atunci cnd este executat t
1
i napoi la dou cnd este executat t
2
, numrul resurselor din sistem nu
se modific. Pentru a prentmpina acest problem, locurilor li se pot asocia ponderi pentru ca suma
ponderat a jetoanelor din reea s rmn constant.
Se spune c o reea Petri este conservativ dac exist un vector w, w = [w
1
, w
2
, ...., w
m
], unde m este
numrul de locuri i w(p) > 0 pentru fiecare p P, astfel nct suma ponderat a jetoanelor rmne
neschimbat pentru fiecare marcaj M care poate fi accesat din marcajul iniial M
o
. O reea Petri este
strict conservativ dac toate intrrile vectorului w sunt unitare. Reeaua Petri din Fig. 1.32 este conser-
vativ n raport cu vectorul w = [1,1,2,1,1] deoarece suma ponderat a jetoanelor n fiecare marcaj este
doi. Un exemplu de reea Petri care nu este conservativ este prezentat n Fig. 1.31 deoarece locul p
4

poate deine un numr nelimitat de jetoane. Dac o reea Petri este conservativ n raport cu un vector
unitar, atunci reeaua este strict conservativ (Fig. 1.33).
2.3.4 Nivelul de activare
Acest concept este strns corelat cu situaia de blocare (deadlock), care a fost studiat n mod extensiv
n contextul sistemelor de operare. S-a artat c aceast situaie poate s apar n patru condiii:

Pagina 37

1) Excluderea mutual: o resurs este fie disponibil, fie alocat unui proces care are acces exclusiv
asupra ei.
2) Deine i ateapt: unui proces i se permite s dein o resurs (sau mai multe) i s acceseze n-
c o resurs (sau mai multe).
3) Fr preempiune: o resurs (sau mai multe) alocat unui proces nu poate fi eliberat dect de
ctre procesul n sine.
4) Ateptare circular: dou sau mai multe procese sunt aranjate ntr-un lan n care fiecare proces
ateapt dup resursele deinute de procesul poziionat naintea lui n lan.

Fig. 1.34 Reea Petri cu diferite niveluri de activare a tranziiilor
Spre exemplu, ntr-un sistem flexibil de fabricaie poate interveni o situaie de blocare atunci cnd un
buffer de intrare/ieire al unei unelte de prelucrare deine un palet cu produse prelucrate i alt palet cu
produse care trebuie prelucrate a fost trimis la buffer. Dac buffer-ul poate pstra doar un palet la un
moment de timp i vehiculul ghidat automat, care transport paleii, are loc doar pentru un palet, atunci
tocmai a intervenit o situaie de blocare. Paletul cu piese prelucrate nu poate fi mutat din buffer n ma-
in, iar paletul cu piese neprelucrate nu poate fi mutat din main n buffer. n acest exemplu, toate
cele patru condiii de mai sus au fost ndeplinite, dac spaile pentru palei din buffer i de pe main
sunt privite ca resurse. Dac n software-ul de control nu exist prevzut o rutin pentru detectarea i
ieirea din starea de blocare, o astfel de stare, dei aprut ntr-un subsistem, se poate propoga i poate
afecta o mare parte a sistemului.
O reea Petri care modeleaz un sistem fr stri de blocare este o reea activ. Aceasta nseamn c
pentru toate marcajele M, care pot fi accesate din marcajul iniial M
o
, este posibil execuia oricrei
tranziii din reea prin progresul obinut de parcurgerea a cteva secvene de execuii. Reeaua Petri din
Fig. 1.33 este activ. Cu toate acestea, scenariul de mai sus poate fi prea strict pentru a reprezenta anu-
mite sisteme reale care prezint comportament fr blocaje. Spre exemplu, iniializarea unui sistem
poate fi modelat de o tranziie (sau mai multe) care se execut de un numr finit de ori. Dup iniializa-
re, sistemul poate avea un comportament lipsit de blocaje, dei reeaua Petri reprezentnd acest sistem
nu mai este activ, conform cu definiia anterioar. Din acest motiv, exist mai multe niveluri de activare
pentru o tranziie t i marcajul M
o
. Astfel, o tranziie t ntr-o reea Petri poate fi:
L0-activ (sau moart) dac nu exist nicio secven de execuie din L(M
o
) n care t s fie execu-
tat,

Pagina 38

L1-activ (potential executabil) dac t poate fi executat cel puin o dat n anumite secvene
de execuie din L(M
o
),
L2-activ dac t poate fi executat de cel puin k ori n anumite secvene de execuie din L(M
o
)
pentru orice k ntreg i pozitiv,
L3-activ dac t poate fi executat de un numr infinit de ori n anumite secvene de execuie
din L(M
o
), i
L4-activ (sau vie) dac t este L1-activ (potenial executabil) n orice marcaj din R(M
o
).
Urmnd aceast clasificare, o reea Petri se spune c este Li-activ, pentru marcajul M
o
, dac orice tran-
ziie din reea este Li-activ. n Fig. 1.34 sunt prezentate diverse niveluri de activare. Astfel, tranziiile t
0
,
t
1
, t
2
i t
3
sunt L0, L1, L2, i, respectiv, L3-active.
2.3.5 Reversibilitate i starea de pornire
O problem important n sistemele de operare reale, precum sistemele de fabricaie, sistemele de con-
trol al proceselor etc., const n abilitatea acestor sisteme de a-i reveni dintr-a situaie de eroare. Aces-
te sisteme trebuie s se ntoarc din starea care a euat la stri corecte anterioare. Aceast cerin este
strns legat de proprietile unei reele Petri denumite reversibilitate i stare de pornire. Pentru marca-
jul iniial M
o
, o reea Petri este reversibil dac pentru orice marcaj M din R(M
o
), M
o
este accesibil din M.
Starea de pornire este o proprietate mai puin restrictiv, i mult mai practic din acest motiv, dect
proprietatea de reversibilitate a unei reele Petri. O stare M a unei reele Petri este stare de pornire
dac pentru orice marcaj M din R(M
o
), M
i
este accesibil din M. Reeaua Petri din Fig. 1.30 este reversi-
bil, iar reeaua din Fig. 1.31 este nereversibil.

2.4 Metode de analiz
n paragraful anterior au fost definite cteva proprieti ale reelelor Petru care sunt folositoare pentru
analiza sistemelor modelate. Un aspect important care trebuie avut n vedere n timpul analizei const n
verificarea existenei unei corespondene funcionale de unu-la-unu ntre modelul reelei Petri i specifi-
caiile originale, de regul, exprimate ntr-un mod informal. Conceperea unor modele de reele Petri din
specificaii informale nu este o sarcin uoar, ea necesitnd o mare experien n modelare, precum i
cunoaterea tehnicilor de asisten n construirea modelului. Ca urmare, un model poate diferi foarte
mult de specificaiile iniiale, lucru general valabil cnd este vorba despre reele Petri mari ale unor sis-
teme complexe. Existena unei corespondene funcionale de unu-la-unu ntre specificaiile iniiale i
reprezentarea n reea Petri a sistemului permite proiectarea rezultatelor analizei, obinute pe model,
asupra descrierii iniiale. Acest lucru permite obinerea unui feedback pentru clieni pe baza cruia, n
multe situaii, clienii i clarific propria percepie despre sistem.
Un alt aspect important care trebuie urmrit n timpul analizei este respectarea n totalitate a specificai-
ilor. De cele mai multe ori, aceste specificaii definesc comportamentul funcional extern al sistemului,
exprimat uzual prin relaionrile de tip intrare/ieire. Intrrile sunt generate de mediul nconjurtor sis-
temului, iar ieirile reprezint rspunsurile sistemului la aceste intrri. Dac anumite intrri, generate de

Pagina 39

ctre mediu asupra sistemului, nu sunt incluse n specificaii, atunci sistemul nu va fi capabil s rspund
la aceste intrri n mod corespunztor atunci cnd ele vor aprea pe parcursul operrii normale. Necesi-
tatea ca specificaiile s fie complete este cu att mai important cu ct sistemul este mai critic, cnd
specificaii incomplete pot duce la apariia unor evenimente catastrofice. Spre exemplu, apariia unei
stri neanticipate n operarea unui reactor nuclear poate duce la imposibilitatea rezolvrii ei de ctre
sistemul de control, fapt deosebit de grav pentru sigurana ntregii zone.
Consistena specificaiilor iniiale este o alt problem care trebuie luat n consideraie n timpul anali-
zei. Inconsistene apar atunci cnd pentru o combinaie permis de intrri specificaiile permit dou sau
mai multe combinaii permise ale ieirilor. Acest lucru se datoreaz, n general, unei percepii vagi, in-
complete i deseori incorecte a funcionalitii sistemului. n continuare vor fi prezentate dou metode
fundamentale de analiz. Una se bazeaz pe arborele de accesibilitate i cealalt pe reprezentarea ma-
triceal a reelei. Pe lng aceste metode mai exist i altele, destinate analizei unei reele Petri, care
permit o transformare sistematic a reelei prin reducerea numrului de locuri i tranziii, dar cu pstra-
rea unor proprieti precum limitabilitatea, conservabilitatea, nivelul de activare etc., pe principiul c
reelele mai mici sunt mult mai uor de utilizat.
2.4.1 Arborele de acoperire
Aceast metod se bazeaz pe enumerarea tuturor marcajelor posibile accesibile din marcajul iniial M
o
.
Pornind de la marcajul iniial M
o
, se poate construi setul de accesibilitate prin execuia tuturor tranziii-
lor posibile activate n toate marcajele posibile accesibile din marcajul iniial. n arborele de acoperire,
fiecare nod este etichetat cu un marcaj i fiecare arc cu tranziiile necesare. Nodul rdcin este etiche-
tat cu marcajul iniial M
o
. Setul de accesibilitate devine nelimitat din dou motive: existena unor marca-
je duplicate sau reeaua n sine este nelimitat. Pentru a preveni un arbore de acoperire s devin foarte
mare, trebuie parcuri doi pai pe parcursul construirii arborelui. Primul pas presupune eliminarea mar-
cajelor duplicate: dac pe calea dintre un marcaj iniial M
o
i un marcaj curent M apare un marcaj M'
identic cu marcajul M, atunci marcajul M, fiind duplicat, devine nod terminal. Apariia unui marcaj ter-
minal implic faptul c toate marcajele posibile a fi accesate din M au fost deja adugate arborelui.
n ceea ce privete reelele nelimitate, pentru a pstra arborele finit, s-a introdus simbolul , care este
interpretat drept infinit. Astfel, pentru un ntreg n, + n = , - n = , n < . n acest caz, dac pe calea
de la marcajul iniial M
o
ctre un marcaj curent M apare un marcaj M' ale crui intrri sunt mai mici sau
egale cu intrrile corespondente din marcajul M, atunci intrrile lui M, care sunt strict mai mari dect
intrrile corespondente din M', trebuie nlocuite cu simbolul . n anumite ci, existena marcajelor cu
intrrile corespondente egale sau mai mari (pe msur ce se deprteaz de nodul rdcin) indic faptul
c secvenele de execuie care transform M' la M pot fi repetate la infinit. De fiecare dat cnd aceast
secven este repetat, numrul de jetoane din locurile etichetate cu simbolul va crete.
Arborele de acoperire este construit conform cu urmtorul algoritm:
1) Marcajul iniial M
o
este rdcina arborelui i se eticheteaz cu nou.
2) Att timp ct exist marcaje noirealizeaz urmtoarele:
3) Selecteaz un nou marcaj M

Pagina 40

a. Dac M este identic cu alt marcaj din arbore, se eticheteaz M ca vechi i se trece la
un alt marcaj nou.
b. Dac nicio tranziie nu se activeaz n M, se eticheteaz M ca terminal.
4) Pentru orice tranziie t activat n marcajul M realizeaz:
a. Obine marcajul M' care rezult din execuia lui t n M.
b. Dac pe calea de la rdcin la M exist un marcaj M" astfel nct M'(p) M"(p) pentru
fiecare loc p, i M' = M", atunci nlocuiete M'(p) cu pentru fiecare p, atta vreme ct
M'(p) > M"(p).
c. Introduce M' ca nod, traseaz un arc de la M la M' etichetat t i eticheteaz M' ca nou.
Urmtorul exemplu va ilustra aceast metod. Se consider reeaua din Fig. 1.35 i arborele ei de acope-
rire din Fig. 1.36. Dat fiind marcajul iniial, nodul rdcin este M
o
= (1,0,1,0)
T
. n acest marcaj, tranziia
t
3
este activat.

Fig. 1.35 Model de reea Petri

Fig. 1.36 Arborele de acoperire pentru modelul de reea Petri
din Fig. 1.35
Cnd t
3
este executat, se obine un nou marcaj: M
1
= (1,0,0,1)
T
. Aceste este un marcaj nou n care
tranziia t
2
este activat. Execuia lui t
2
din M, va determina obinerea lui M
2
= (1,1,1,0)
T
. Deoarece M
2
=
(1,1,1,0)
T
M
o
= (1,0,1,0)
T
, a doua component trebuie nlocuit cu simbolul . Aceast reflect faptul c
execuia secvenei t
3
t
2
poate fi repetat de un numr arbitrar de ori. n marcajul M
2
= (1,,1,0)
T
sunt
activate dou tranziii: tranziia t
1
i tranziia t
3
. Execuia lui t
1
va determina marcajul M
3
= (1,,0,0)
T
,
care este un nod terminal. Execuia tranziiei t
3
va determina un marcaj nou M
4
= (1,,0,1)
T
, care
activeaz tranziia t
2
. Execuia lui t
2
din M
4
va duce la un nod vechi: M
5
= (1,,1,0)
T
care este identic cu
M
2
.
Folosind arborele de acoperire se pot studia cteva proprieti ale reelei Petri. Spre exemplu, dac un
nod din arbore conine simbolul , atunci reeaua este nelimitat, dat fiind faptul c simbolul poate
deveni orict de mare. Altfel (adic nu apare simbolul ), reeaua este legat. Dac fiecare nod al arbo-
relui conine doar valori de 0 i 1, atunci reeaua este sigur. O tranziie este moart dac nu apare ca o

Pagina 41

etichet de arc n arbore. Dac un marcaj M este accesibil din marcajul M
o
, atunci exist un nod M' astfel
nct M M'. Cu toate acestea, deoarece simbolul poate fi orict de mare, anumite probleme, precum
acoperirea sau nivelul de activare, nu pot fi rezolvate doar prin studiul arborelui de acoperire. Pentru o
reea Petri limitat, arborele de acoperire conine, ca noduri, toate marcajele posibile accesibile din
marcajul iniial M
o
. n acest caz, arborele de acoperire se numete arbore de accesibilitate i orice pro-
blem de analiz poate fi rezolvat prin simpla lui inspecie.
2.4.2 Matricea de inciden i ecuaia de stare
O metod alternativ de reprezentare i analiz a reelelor Petri se bazeaz pe ecuaii matriciale, folosite
pentru reprezentarea comportamentului dinamic al reelelor Petri. Metoda presupune construirea ma-
tricei de inciden care definete toate interconexiunile posibile dintre locuri i tranziii. Matricea de
inciden a unei reele Petri pure este o matrice A cu dimensiunile n x m ntregi, unde n este numrul de
tranziii i m este numrul de locuri. Intrrile n matricea de inciden sunt definite astfel:
o
]
= o
]
+
o
]
-

unde: o
]
+
este egal cu numrul de arce care conecteaz tranziia t
i
cu locurile sale de ieire p
j

(o
]
+
= 0(p
]
, t
))
o
]
-
este egal cu numrul de arce care conecteaz tranziia t
i
cu locurile sale de intrare p
j

(o
]
-
= I(p
]
, t
)).
Cnd tranziia t
i
se execut, o
]
+
reprezint numrul de jetoane depozitate n locurile sale de ieire p
j
, o
]
-

reprezint numrul de jetoane nlturate din locurile sale de intrare p
j
, iar o
]
reprezint modificarea
numrului de jetoane n locul p
j
. Astfel, se spune c tranziia t
i
este activat n marcajul M dac
o
]
-
H(p
]
), i = 1, 2, m
Pentru reelele Petri cu bucle, o
]
= u pentru un loc p
j
i o tranziie t
i
care aparin unei bucle. Din acest
motiv, pentru a avea sigurana c matricea de inciden reflect structura reelei Petri, se presupune c
reeaua este pur sau este fcut pur prin introducerea de locuri adiionale (Fig. 1.28). Ecuaia de stare
pentru o reea Petri reprezint modificarea din distribuia jetoanelor pe locuri (marcaje) ca rezultat al
executrii tranziiilor. Aceast ecuaie este definit astfel:
H
k
= H
k-1
+A
1
u
k
, k = 1,2,
M
k
este un vector coloan cu dimensiunea m x 1 reprezentnd un marcaj M
k
accesibil imediat din marca-
jul M
k-1
dup execuia tranziiei t
i
. Vectorul k de execuie, u
k
, este un vector coloan de dimensiune n x 1,
care are toate intrrile diferite de zero. Valoarea 1 n poziia i reprezint execuia tranziiei t
i
n execuia
k a secvenei de execuii a reelei, pornind de la marcajul iniial M
o
. Aceast intrare corespunde cu linia i
a matricei de inciden A, care reprezint o modificare n marcaj ca urmare a execuiei tranziiei t
i
. Ecua-
ia matriceal este folositoare n studiul problemei de accesibilitate.

Pagina 42

Dou concepte asociate cu matricea de inciden sunt folositoare n studiul proprietilor modelelor cu
reele Petri: invariantul T i invariantul P.
O soluie ntreag x a ecuaiei A
1
x = u este denumit invariant T. Intrrile diferite de zero ntr-un inva-
riant T reprezint numrul execuiilor tranziiilor corespunztoare care aparin unei secvene de execu-
ie ce transform marcajul M
0
pn se ajunge din nou n M
0
. Dei un invariant T conine tranziiile cu-
prinse n secvena de execuii care transform marcajul M
0
n M
0
, precum i numrul de ori n care aces-
te tranziii apar n secven, nu specific ordinea de execuie a tranziiilor.
O soluie ntreag y a ecuaiei Ay = u este denumit invariant P. Acesta poate fi explicat, n mod intuitiv,
astfel: intrrile deferite de zero reprezint ponderile asociate locurilor corespunztoare astfel nct su-
ma ponderat a jetoanelor din aceste locuri s fie constant pentru toate marcajele accesibile din mar-
cajul iniial.
Subsetul de locuri (tranziii) care corespund intrrilor diferite de zero din invariantul P (invariantul T)
este denumit suport pentru invariant i este notat x(y).

Fig. 1.37 Arborele de acoperire al reelei Petri din Fig. 1.29

Fig. 1.38 Graful de accesibilitate al reelei Petri din Fig. 1.29

2.4.3 Un exemplu
n aceast seciune se va demonstra modul n care arborele de acoperire i tehnicile bazate pe invariani
pot fi folosite pentru a analiza un model de reea Petri, pe baza exemplului din Fig. 1.29 privind un sis-
tem multirobot. Presupunnd c b = 1, arborele de acoperire, n acest caz un arbore de accesibilitate,
este prezentat n Fig. 1.37, iar matricea de inciden n Fig. 1.38.

Pagina 43

Fig. 1.39 Matricea de inciden a reelei Petri pentru celula de asamblare cu multirobot
Invarianii P obinui pentru aceast reea sunt:
y
1
= (1 1 1 u u u u u u)
1

y
2
= (u u u 1 1 1 u u u)
1

y
3
= (u u 1 u u 1 1 u u)
1

y
4
= ( u u u u u u u 1 1)
1

Urmtorii sunt invarianii suport corespunztori:
y
1
= {p
1
, p
2
, p
3
]
y
2
= {p
4
, p
5
, p
6
]
y
3
= {p
3
, p
6
, p
7
]
y
4
= {p
8
, p
9
]
Limitabilitate i siguran: Reeaua Petri din Fig. 1.29 este limitat. Acest lucru este evident din arborele
de accesibilitate: nici un marcaj accesibil din marcajul iniial M
0
nu conine simbolul . n plus, deoarece,
pentru toate marcajele, nicio intrare nu este mai mare dect unu, reeaua este sigur. Aceste proprieti
pot fi foarte uor determinate folosind invarianii P. Deoarece fiecare loc din reea aparine unui invari-
ant suport iar reeaua pornete de la un marcaj iniial limitat, ntreaga reea este limitat. n plus, deoa-
rece numrul de jetoane din fiecare invariant suport din marcajul iniial este unu, reeaua este sigur.
Din proprietatea de limitabilitate a modelului de reea Petri pot fi deduse dou proprieti privind ope-
rarea sistemului real. Buffer-ul nu poate fi suprancrcat, deci nu exist nicio probabilitate c R1 va acce-
sa zona buffer-ului cnd acesta este plin. De asemenea, buffer-ul nu poate fi supradescrcat, deci nu
exist nicio probabilitate c R2 va accesa zona buffer-ului cnd acesta este gol. Folosind arborele de
accesibilitate, aceste proprieti decurg din sigurana reelei. Intrrile n fiecare marcaj, care reprezint
numrul de jetoane n locurile p
8
i p
9
sunt fie zero, fie unu. Folosind invariani: invariantul suport y
4

conine locurile p
8
i p
9
. Din moment ce coninutul de jetoane n y
4
n marcajul iniial este unu,la un
moment dat va fi doar un jeton fie n p
8
, fie n p
9
. Din acest motiv nu va fi nici suprancrcare, nici
subdescrcare a buffer-ului.
Conservativitatea: Reeaua Petri din Fig. 1.29 este conservativ. Din graficul de accesibilitate, se poate
observa c reeaua este conservativ raportat la vectorul = [1,1,2,1,1,2,1,1,1]. Suma ponderat a je-

Pagina 44

toanelor rmne aceeai pentru fiecare marcaj accesibil din marcajul iniial i este egal cu patru. Folo-
sind invariani: coninutul de jetoane n fiecare invariant suport din marcajul iniial este unu. Invarianii
suport y
1
, y
2
, i y
4
sunt mutual exclusivi. Invarianii suport y
1
i y
3
conin locul p
3
ca ele-
ment comun. Invarianii suport y
2
i y
3
conin locul p
6
ca element comun. Astfel, ponderea locuri-
lor p
3
i p
6
ar trebui s fie doi pentru ca reeaua s fie conservativ. Implicaia acestei proprieti este c
numrul de brae robotizate care opereaz n sistemul de asamblare este doi i nu se poate modifica. De
asemenea, spaiul din buffer este unu i nu se poate modifica
Nivel de activare: Reeaua Petri din Fig. 1.29 este vie, toate tranziiile fiind activate. Fig. 1.38 prezint un
graf de accesibilitate al reelei Petri din Fig. 1.29. Acesta este un graf direcionat, format dintr-un set de
noduri i un set de arce direcionate. Setul de noduri prezint toate nodurile distincte din arborele de
accesibilitate, iar setul de arce direcionate, unde fiecare arc este etichetat cu cte o tranziie, reprezint
toate tranziiile posibile ntre nodurile din arborele de accesibilitate.
La simpla inspecie, reeaua este L4-activ, deoarece pentru orice marcaj accesibil din marcajul M
0
, este
posibil execuia oricrei tranziii prin parcurgerea unei anumite secvene de execuie. Invarianii pot fi
folosii pentru a demonstra manual c reeaua este vie. Cu toate acestea, pentru o reea de aceast
dimensiune, acest lucru ar fi laborios. Deoarece reeaua este vie, sistemul nu poate ajunge ntr-o stare n
care nicio operaie s nu fie posibil.
Reversibilitatea: Reeaua Petri din Fig. 1.29 este reversibil. Tot prin inspecie, se poate constata, pe
baza grafului de accesibilitate, c M
0
este accesibil din orice marcaj M R(Mo).

2.5 Reele Petri: concluzii
Dezvoltarea reelelor Petri a fost motivat de nevoia de a modela sistemele industriale. Reelele Petri
ordinare nu sunt totdeauna suficiente pentru reprezentarea i analiza sistemelor industriale complexe,
fapt care a dus la dezvoltarea unor noi clase de reele. n reele ordinare, jetoanele nu au identitate, fapt
care ridic probleme n modelarea unor sisteme precum cele de comunicare sau de fabricaie, ce necesi-
t resurse fizice sau mesaje cu identitate (dac sunt reprezentate prin jetoane). Fr aceast identitate
este imposibil de urmrit cursul diferitelor resurse sau mesaje n sistem. O soluie potenial const n
construcia unui model ntr-o aa manier nct fluxul fiecrui mesaj s fie asociat cu o subreea dedicat.
Cum resursele i mesajele partajeaz, n multe cazuri, acelai sistem, toate aceste subreele sunt identi-
ce, doar c aceast metod crete complexitatea grafic a modelului. Pentru a rezolva aceste probleme
au fost propuse reele Petri care permit jetoanelor s aib identitate distinct. Aceste reele, denumite
reele Petri de nivel ridicat, includ reele cu tranziia predicatelor, reele colorate i reele cu jetoane
individuale.
n reelele Petri de nivel ridicat, un jeton poate fi un obiect compus care transport date. Aceste date
pot avea complexitate arbitrar, implicnd numere ntregi, numere reale, iruri de caractere, nregistrri,
liste etc. Toate tipurile de reele Petri au aceeai putere descriptiv, dar reelele de nivel ridicat asigur
faciliti de structurare mult mai bune. Reelele colorate i cele cu tranziia predicatelor sunt aproape

Pagina 45

identice n ceea ce privete descrierea i simularea. Cu toate acestea, exist diferene considerabile n
ceea ce privete analiza formal. Reelele Petri colorate sunt utilizate n diverse domenii, incluznd pro-
tocoale de comunicare, sisteme de producie etc. O dezvoltare important n domeniul reelelor Petri de
nivel ridicat const n introducerea modelelor orientate pe obiecte. n aceast clas de reele, jetoanele
sunt considerate instane sau tuplete ale instanelor claselor de obiecte definite ca liste de atribute.
Acest tip de reea a fost utilizat pentru a modela i analiza sisteme FMS (Flight Management System),
sarcini de asamblare i sisteme de asamblare.
Nevoia de specificaii calitative ale controlului industrial, precum i nevoia pentru reprezentri ale in-
formaiilor aproximative i incerte au dus la dezvoltare de reele Petri fuzzy. Definirile acestor reele au
fost influenate, de regul, de domeniile diverse de aplicare. Reele Petri fuzzy au fost folosite pentru
reprezentarea cunotinelor i a raionamentului, precum i pentru modelarea sistemului de monitoriza-
re i control al FMS.
Reele Petri ordinare nu sunt suficient de puternice pentru reprezentarea i studiul unor proprieti
importante ale sistemelor concurente, precum eventualitatea (anumite tranziii trebuie s fie executate,
n cele din urm) i corectitudine (fairness) (dac o tranziie devine executabil de un numr infinit de ori,
atunci trebuie s fie executat de un numr infinit de ori). Pentru a rezolva aceste probleme au fost
create reelele Petri temporale, n care sunt reprezentate constrngerile de timp prin operatori precum
next, hencefort, eventually, until etc. Abilitatea reelelor Petri temporale de a exprima eventualitatea au
fcut aceste modele potrivite pentru reprezentarea i studiul comportamentului funcional extern al
sistemelor. Aceste funcionaliti sunt exprimate prin relaionri de intrare/ieire, spre exemplu dac a
fost stabilit un anumit ablon de intrare, atunci, n cele din urm, va fi generat un anumit ablon de iei-
re.
Dei ncercrile de a combina reelele Petri cu alte tehnici, precum reelele neuronale, logica fuzzy etc.
par s fie n vog, acest tip de reele sunt, totui, restricionate doar n cercetare i mediul academic.
Acest lucru rezult din lipsa unor unelte software ieftine i disponibile pe scar larg pentru dezvoltarea
sistemelor industriale. Acest tip de unelte vor fi necesare pentru a asigura faciliti de lucru cu probleme
din domenii specifice pentru un nivel de pregtire relativ sczut care s nu necesite cunotine privind
reelele Petri i metodele lor de analiz. Transformarea modelelor realizate cu reele Petri n cod execu-
tabil va fi, de asemenea, esenial, permind prototipizarea rapid a sistemelor dezvoltate direct n
mediul operaional
Un alt motiv pentru care reelele Petri sunt folosite mai mult n mediu academic i n instituiile de cer-
cetare const n dificultatea construciei modelelor. Aceasta necesit o mare experien, mai ales pentru
sistemele complexe i foarte mari. Nu exist metodologie disponibil, pentru a automatiza n vreun fel
procedeul de construcie, ci modelele sunt concepute ntr-o manier adhoc. n ultima perioad s-au
fcut ncercri de a sistematiza acest aspect, clasificare, folosind termeni ai ingineriei software, n meto-
de de jos n sus (bottom-up), de sus n jos (top-down) i hibride. Refolosirea reelelor Petri este, de ase-
menea, restricionat, mai ales de felul n care se concep modelele, pe baza unei documentaii insufici-
ente. Este clar c, folosirea pe scar larg a reelelor Petri, mai ales n industrie, va trebui s fie susinut
de metode i unelte suport care s permit o construcie automat sau semiautomat a modelelor pe

Pagina 46

baza specificaiilor de dezvoltare. Soluiile care au ncercat s pun n practic acest deziderat folosesc
pentru construcia automat specificaii exprimate prin reguli de producie, diagrame de fluxuri, logic
temporal, limbaje semi-formale pentru anumite domenii de aplicare etc.


Pagina 47

3 Modelare cu App Invetor
3.1 Sistemul de operare Android
3.1.1 Scurt istoric
Android (al crui logo este prezentat n Fig. 1.40 Logo Android (20)) este o platform software i un sis-
tem de operare pentru dispozitive digitale i telefoane mobile, dezvoltat iniial de compania Google, iar
mai trziu de consoriul comercial Open Handset Alliance. Android permite dezvoltatorilor s scrie cod
gestionat n limbajul Java, controlnd dispozitivul prin intermediul bibliotecilor Java dezvoltate de Goo-
gle. Aplicaiile scrise n C i n alte limbaje pot fi compilate n cod main ARM i executate, dar acest
model de dezvoltare nu este sprijinit oficial de ctre Google.

Fig. 1.40 Logo Android
n iulie 2005, Google a achiziionat Android Inc., o companie de tip startup, cu sediul n Palo Alto, Cali-
fornia, SUA. Cofondatorii companiei Android, care au continuat s munceasc la Google, au fost Andy
Rubin (cofondator al Danger), Rich Miner (cofondator al Wildfire Communications, Inc.), Nick Sears (fost
vicepreedinte al T-Mobile) i Chris White (unul dintre primii ingineri ai WebTV). La acea dat se cuno-
tea foarte puin despre Android, Inc., doar c fceau software pentru telefoane mobile. Aceast achiziie
a generat zvonuri cum c Google ar plnui s intre pe piaa telefoniei mobile, dei era neclar la vremea
respectiv ce funcie ar putea ndeplini n aceast pia.
La Google, echipa condus de Rubin a dezvoltat un sistem de operare pentru dispozitive mobile bazat pe
Linux, pe care l-au prezentat productorilor de telefoane mobile i operatorilor de reele de telefonie
mobil, cu perspectiva de a asigura un sistem flexibil, rennoibil. Google a raportat c a aliniat deja o
serie de parteneri productori de componente hardware i software la noul concept i a semnalat ope-
ratorilor de reele de telefonie mobil c este deschis la diferite grade de cooperare din partea acestora.
Mai multe speculaii c Google ar intra pe piaa telefoniei mobile au aprut n decembrie 2006. Rapoarte
de la BBC i Wall Street Journal au remarcat faptul c Google i dorea cutarea web i aplicaiile sale pe
telefoane mobile i c lucra din greu ctre acest el. Presa i siturile de tiri au publicat curnd zvonuri c
Google ar dezvolta un dispozitiv mobil marca Google. A urmat i mai mult speculaie, susinnd c n
timp ce Google definea specificaiile tehnice, ar fi demonstrat prototipuri productorilor de telefoane
mobile i operatorilor de reea. S-a raportat c pn la 30 de telefoane prototip operau deja pe pia. n
septembrie 2007 Information Week a publicat un studiu care dezvluia c Google a depus cereri pentru
mai multe brevete de invenie n domeniul telefoniei mobile.

Pagina 48

Lansarea platformei Android la 5 noiembrie 2007 a fost anunat prin fondarea Open Handset Alliance,
un consoriu de 48 de companii de hardware, software i de telecomunicaii, printre care i Google, HTC,
Intel, Motorola, Qualcomm, T-Mobile, Sprint Nextel i Nvidia, consacrat dezvoltrii de standarde pentru
dispozitive mobile. Google a lansat cea mai mare parte a codului Android sub licena Apache, o licen
de tip free-software i open source. n 9 decembrie 2008, s-a anunat c 14 noi membri au aderat la pro-
iectul Android, incluznd: Sony Ericsson, Vodafone Group Plc, ARM Holdings Plc, Asustek Computer Inc,
Toshiba Corp i Garmin Ltd.
ncepnd cu 21 octombrie 2008, Android a fost disponibil ca open source. Google a deschis ntregul cod
surs (inclusiv suportul pentru reea i telefonie), care anterior era indisponibil, sub licena Apache. Sub
licena Apache, productorii sunt liberi s adauge extensii proprietare, fr a le face disponibile comuni-
tii open source. n timp ce contribuiile Google la aceast platform se ateapt s rmn open source,
numrul versiunilor derivate ar putea exploda, folosind o varietate de licene.
3.1.2 Caracteristici
Printre caracteristicile i specificaiile actuale se numr urmtoarele (21):
platforma Android este adaptabil la configuraii mai mari
maina virtual Dalvik este optimizat pentru dispozitive mobile
navigatorul web disponibil este bazat pe platforma de aplicaii open source WebKit
biblioteci grafice 2D incluse
biblioteci grafice 3D incluse, bazate pe specificaia OpenGL ES 1.0
suport media
software-ul de baze de date SQLite este utilizat n scopul stocrii datelor
Android suport tehnologii de conectivitate incluznd GSM/EDGE, CDMA, EV-DO, UMTS, Blue-
tooth i Wi-Fi
SMS i MMS sunt formele de mesagerie instant disponibile, inclusiv conversaii de mesaje text.
Software-ul scris n Java poate fi compilat n cod main Dalvik i executat de maina virtual Dalvik, care
este o implementare specializat de main virtual conceput pentru utilizarea n dispozitivele mobile,
dei teoretic nu este o Main Virtual Java standard.
Android accept urmtoarele formate media audio/video/imagine: MPEG-4, H.264, MP3, AAC, OGG,
AMR, JPEG, PNG, GIF. Android poate utiliza camere video/foto, touchscreen, GPS, accelerometru, i gra-
fic accelerat 3D. Include un emulator de dispozitive, unelte de depanare, un plug-in pentru mediul de
dezvoltare Eclipse.
Similar cu App Store de pe iPhone, Android Market (acum Google Play) este un catalog de aplicaii care
pot fi descrcate i instalate pe hardware-ul int prin comunicaie fr fir, fr a se utiliza un PC. Iniial
au fost acceptate doar aplicaii gratuite. Aplicaii contra cost sunt disponibile pe Android Market nce-
pnd cu 19 februarie 2009.

Pagina 49

Android are suport nativ pentru multi-touch, dar aceast funcionalitate este dezactivat (posibil pentru
a se evita nclcarea brevetelor Apple pe tehnologia touch-screen). O modificare neoficial, care permite
multi-touch a fost dezvoltat.
Primele aprecieri cu privire la dezvoltarea aplicaiilor pentru platforma Android au fost amestecate. Pro-
blemele citate includeau bug-uri, lipsa de documentaie, infrastructura de testare inadecvat i lipsa
unui sistem de gestionare public a problemelor. Google a anunat un sistem de gestionare a problemelor
la data de 18 ianuarie 2008. n decembrie 2007, fondatorul startup-ului mobil MergeLab, Adam MacBeth,
a declarat: "Funcionalitatea lipsete, este prost documentat sau pur i simplu nu funcioneaz. Este
clar c nu este gata pentru prime time". n ciuda acestui fapt, aplicaiile pentru Android au nceput s
apar, deja, n sptmna urmtoare celei n care a fost anunat platforma. Prima aplicaie public a
fost jocul Snake. Telefonul Android Dev este un dispozitiv cu SIM i hardware neblocate care este desti-
nat dezvoltatorilor avansai. Cu toate c dezvoltatorii pot utiliza un dispozitiv de consum achiziionat de
pe pia pentru a-i testa i a utiliza aplicaiile, unii dezvoltatori pot alege s nu utilizeze un dispozitiv de
pe pia, prefernd un aparat neblocat sau fr contract.
3.1.3 Evoluia sistemului Android i impactul su pe pia
Android ar putea deveni pentru telefoane ceea ce e Windows pentru PC-uri. Sistemul de operare mobil
Android de la Google concureaz cu sistemul de operare iPhone n piaa telefoanelor inteligente, iar
compania de cercetare NPD a anunat recent ca Android are o cot de pia mai mare dect Apple n
Statele Unite. (22)
Adopia Android a crescut n ultimul an datorit disponibilitii acestuia la un numr mare de produc-
tori de telefoane mobile. Conform analitilor financiari ai companiei de cercetare Trefis, exist o paralel
ntre strategia Google din piaa smartphone-urilor i campania Microsoft mpotriva Apple, care a ajutat
Windows s devin sistemul de operare dominant n piaa PC-urilor. Microsoft a oferit licena sistemului
su de operare pentru orice productor de computere interesat, iar Google face un lucru asemntor cu
sistemul su de operare pentru productorii de telefoane. Acest lucru ar putea nsemna c iPhone nu va
obine o cot de pia la ct estimaser anterior analitii.
Android deja este compatibil cu majoritatea productorilor de telefoane mobile, de la Motorola la HTC,
care nu dein un sistem de operare propriu. Primul telefon Android a fost vndut la mai bine de un an
dup lansarea iPhone. Cu toate c a fost lansat mai trziu, Android a depit iPhone n piaa de
smartphone-uri din SUA i din ntreaga lume. Dei piaa din Statele Unite este una atipic, i este foarte
diferit fa de ceea ce se ntmpl n restul lumii, aceasta prezint un trend interesant, care s-ar putea
s fie mprtit i n alte regiuni ale globului.
Astfel, la sfritul primului trimestru al anului 2010, cota de pia a Android a crescut cu 4% fa de tri-
mestru precedent, ajungnd la sfritul lunii mai la 13%. Aceast cretere este cu att mai spectaculoas
cu ct Android este singurul sistem de operare mobil care reuete s ctige cota de pia, ceea ce n-
seamn c Google reuete s fure o bucat foarte mare din piaa rivalilor si.

Pagina 50

3.1.4 Arhitectura Android
Diagrama din Fig. 1.41 (21) prezint principalele componente ale sistemului de operare Android. Astfel,
acesta este oferit cu un set de aplicaii incluse, precum client de email, program SMS, calendar, hri,
navigator pe Internet, contacte etc. (nivelul aplicaii).

Fig. 1.41 Arhitectura sistemului Android
Asigurnd o platform de dezvoltare deschis, Android ofer dezvoltatorilor posibilitatea de a construi
aplicaii complexe i inovative. Acetia sunt liberi s se foloseasc de hardware-ul echipamentului, de
informaii despre accesarea locaiei, de rularea de servicii de background, s seteze alarme, s adauge
notificaii pe bara de stare etc. Dezvoltatorii au acces total la aceleai API-uri ca i aplicaiile distribuite
cu Android. Arhitectura aplicaiilor este gndit pentru a simplifica reutilizarea componentelor: orice
aplicaiei i poate publica capabilitile, iar orice alt aplicaie poate utiliza, apoi, aceste capabiliti.
Acelai mecanism permite i nlocuirea componentelor de ctre utilizator.
Ca suport pentru toate aplicaiile, se afl un set de servicii i sisteme, incluznd:
Un set bogat i extensibil de vizualizri (Views) care pot fi folosite pentru a construi o aplicaie,
incluznd liste, griduri, casete de text, butoane, chiar i un browser web ncorporat.
Furnizori de coninut (Content Providers) care permite aplicaiilor s acceseze date din alte apli-
caii (precum Contacts), sau s i partajeze propriile date.
Un manager de resurse (Resource Manager), care asigur acces la resursele care nu sunt cod (i-
ruri de caractere, grafice, fiiere)
Un manager de notificare (Notification Manager) care permite tuturor aplicaiilor s afieze aler-
te pe bara de stare.
Un manager al activitilor (Activity Manager) care managerizeaz ciclul de via al aplicaiilor i
navigare comun backstack (istorie de parcurgere a aplicaiilor pe baza creia, cu tasta back, se
poate reveni la activiti anterioare).

Pagina 51

Android include un set de biblioteci C/C++ folosite de diverse componente ale sistemului. Capabilitile
asociate sunt oferite dezvoltatorilor prin suportul descris anterior. Cteva dintre aceste biblioteci sunt:
Biblioteci media: asigur suport de redare i de nregistrare a numeroase formate audio i video
populare, precum i fiiere cu imagini statice, incluznd MPEG4, H.264, MP3,AAC, AMR, JPG i
PNG
Managerul suprafeei de lucru (Surface Manager): asigur accesul la subsistemul afiorului i
compune layer-e grafice 2D i 3D pentru aplicaii
LibWebCore: un motor de cutare pe Internet
SGL: motorul grafic 2D
Biblioteci 3D: API implementat pe baza OpenGL ES 1.0
SQLite: un puternic motor de baze de date disponibil tuturor aplicaiilor.
Android include un set de biblioteci principale care asigur majoritatea funcionalitilor disponibile n
bibliotecile limbajului de programare Java. Fiecare aplicaie Android ruleaz n propriul proces i n pro-
pria instan a mainii virtuale Dalvik, scris astfel nct un dispozitiv s ruleze eficient multiple instane
ale mainii virtuale. Maina virtual Dalvik se bazeaz pe un nucleu Linux pentru funcionaliti de baz
precum lucrul cu fire de execuie i managementul memoriei low-level.
Sistemul Android are la baz versiunea 2.6 de Linux pentru servicii de sistem precum securitatea, mana-
gementul memoriei, managementul proceselor etc. Nucleul funcioneaz i ca un nivel de abstractizare
ntre hardware i software.
3.1.5 SDK-ul Android
SDK-ul Android include un set complet de instrumente de dezvoltare. Acestea conin un program de
depanare, biblioteci, un emulator de dispozitiv (bazat pe QEMU), documentaie, mostre de cod i
tutoriale. Platformele de dezvoltare sprijinite n prezent includ calculatoare bazate pe x86 care ruleaz
Linux (orice distribuie Linux desktop modern), Mac OS X 10.4.8 sau mai recent, Windows XP sau Vista.
Cerinele includ, de asemenea, Java Development Kit, Apache Ant, i Python 2.2 sau o versiune ulterioa-
r. Mediul de dezvoltare (IDE) suportat oficial este Eclipse (3.2 sau mai recent), utiliznd plug-in-ul An-
droid Development Tools (ADT), dei dezvoltatorii pot folosi orice editor de text pentru a edita fiiere
XML i Java i apoi s utilizeze unelte din linia de comand pentru a crea, construi i depana aplicaii
Android.
O versiune pentru examinare a Android Software Development Kit (SDK) a fost lansat la data de
12 noiembrie 2007. La 18 august 2008, a fost lansat Android SDK 0.9 beta. Aceast versiune ofer un API
actualizat i extins, instrumente de dezvoltare mbuntite i un design actualizat pentru ecranul de
baz. Instruciuni detaliate pentru actualizare sunt disponibile pentru cei care lucreaz deja cu o versiu-
ne anterioar. La 23 septembrie 2008 a fost lansat SDK-ul Android 1.0 (Release 1). Conform documenta-
iei de lansare, includea "n principal remedii pentru probleme, dei au fost adugate unele capabiliti
mai puin semnificative". Includea, de asemenea, cteva modificri ale API-ului fa de versiunea 0.9.

Pagina 52

Pe 9 martie 2009, Google a lansat versiunea 1.1 pentru telefonul Android Dev. Dei exist cteva actuali-
zri estetice, cteva actualizri cruciale includ suport pentru "cutare prin voce, aplicaii contra cost,
remedii pentru ceasul cu alarm, remediu pentru blocarea la trimiterea gmail, notificri de pot elec-
tronic i intervale de mprosptare". O alt schimbare important este c telefoanele Dev pot acum
accesa aplicaii pltite i dezvoltatorii le pot vedea pe piaa Android.
Dei este un produs de tip open source, o parte din dezvoltarea software pentru Android a fost continua-
t ntr-o ramur privat. n scopul de a face acest software public, a fost creat o ramur oglind read
only, cunoscut sub numele unui desert, anume cupcake. Se crede c numele vine de la Marissa Mayer
(vicepreedinte la Google), care are o pasiune pentru acesta. Cupcake este n mod obinuit interpretat
greit ca numele unei actualizri, dar dup cum este declarat pe situl de dezvoltare al Google: Cupcake
[] este o ramur de dezvoltare, nu o versiune stabil. Modificri notabile la software-ul Android intro-
duse n cupcake includ modificri la download manager, platform, Bluetooth, software-ul de sistem,
radio i telefonie, instrumente de dezvoltare, sistemul de dezvoltare i cteva aplicaii, precum i o serie
de remedieri de probleme. i alte versiuni Android au fost numite dup deserturi: donut, eclair,
gingerbread etc.
3.2 MIT (Google) App Inventor
Google App Inventor este un limbaj de programare iniiat de Google i preluat de MIT din 2012. Acesta
este conceput pentru utilizatorii obinuii, fr cunotine speciale de programare i permite crearea
unor aplicaii pentru sistemul de operare Android. Pentru a interaciona ntr-un mod ct mai simplu cu
utilizatorul, programul a fost conceput vizual: pentru a crea o aplicaie, utilizatorul deseneaz vizual
modul n care aplicaia va arta i folosete blocuri pentru a specifica comportamentul aplicaiei lui. App
Inventor folosete o interfa grafic, foarte asemntoare cu interfaa de utilizator de la Scratch i
StarLogo TNG, care permite utilizatorilor s aeze obiectele vizuale pentru a crea o aplicaie, care poate
rula pe sistemul Android sau alte sisteme. Raionamentul este c, dac tinerii dezvolt aplicaia, o vor
face pentru a-i ndeplini propriile necesiti cu ajutorul telefonului mobil. (23)
Prin crearea lui App Inventor pentru Android, Google a fcut cercetri semnificative prealabile n pro-
gramarea educaional. Editorul de blocuri folosete biblioteca Java Open Blocks pentru crearea de lim-
baje de programare cu blocuri vizuale. Open Blocks este distribuit de Massachusetts Institute of Techno-
logy Scheller Teacher Education Program (STEP) i provine din dizertaia de master a lui Ricarose Roque.
Profesorul Eric Klopfer i Daniel Wendel din Programului Scheller au sprijinit distribuirea Open Blocks
sub licen MIT. Blocurile de programare vizual sunt strns legate de TNG StarLogo, proiectul STEP al lui
Klopfer lui i Scratch un proiect al MIT Media Laboratory Lifelong Kindergarten Group. Aceste proiecte
sunt ele nsele susinute de ctre teoriile constructive de nvare, care subliniaz c programarea poate
fi un vehicul pentru angajarea de idei puternice prin nvare activ. Ca atare, aceasta este parte a unei
micri n curs de desfurare n computere i educaie, care a nceput cu munca lui Seymour Papert i
MIT Grupul Logo n anii 1960.
Compilator care traduce limbajul vizual al blocurilor pentru implementarea pe sistemul Android folose-
te cadrul de lucru al limbajului de programare Scheme i dialectul Kawa, dezvoltat de Per Bothner i

Pagina 53

distribuit ca parte a sistemului de operare GNU Free Software Foundation. n august 2011 Google a
anunat c App Inventor nu va mai fi un produs Google, ci parte a MIT Center for Mobile Learning din
cadrul MIT Media Lab, condus chiar de creatorul App Inventor, Hal Abelson.
3.2.1 Ce se poate face cu App Inventor?
App Inventor permite, ca orice mediu vizual, crearea de aplicaii pentru Android fr a scrie cod de pro-
gram, prin crearea aplicaiei i specificarea comportamentului su prin configurarea de blocuri. Echipa
AppInventator a creat blocuri pentru aproape orice se poate face cu un telefon Android, precum i blo-
curi pentru a face aproape programare: variabile pentru memorare, blocuri for i while pentru
repetarea operailor i condiii (blocuri ,if ), astfel nct aplicaia s poat s pun ntrebri i s se
ghideze pe rspunsuri. Exist chiar i blocuri pentru a stoca informaiile ntr-o baz de date i conexiune
la servicii online, precum Twitter.
Se poate construi aproape orice aplicaie imaginabil cu App Inventor: jocuri, aplicaii informaionale cu
datele generate de utilizatori, aplicaii personale, aplicaii pentru a ajuta oamenii s comunice, aplicaii
care folosesc senzorii telefonului i chiar aplicaii care se conecteaz la reele de socializare. Astfel, pe
lng aplicaiile de pe telefonul personal sau cele din Android Market, pot fi create aplicaii personaliza-
te.
O modalitate de a ncepe programarea cu App Inventor o constituie realizarea de jocuri. Se poate folosi
chiar i senzorul de orientare al telefonului pentru a construi, spre exemplu, un joc n care se mic o
minge printr-un labirint n timp ce juctorul nclin telefon. Dar App Inventor nu este doar pentru a con-
strui jocuri. Se poate utiliza, de asemenea, pentru a construi software-uri educaionale: chestionare i
alte aplicaii care permit unui utilizator s nainteze printr-o secven de informaii. Se pot crea aplicaii
test pentru diverse studii. Se pot aduga la aceste chestionare toate sunetele dorite, utiliznd compo-
nenta Music Player, sau componenta video pentru a crea un test care arat clipuri din filmele preferate.
Cu componenta TextToSpeech s-ar putea programa telefonul s pun ntrebri sau s rspund cu voce
tare.
Aplicaiile construite nu trebuie neaprat s se bazeze pe date fixe, dar pot stoca, n loc de date fixe,
date generate de utilizatori ntr-o baz de date. Astfel, se poate crea o aplicaie antrenament care per-
mite utilizatorului s introduc numrul de abdomene fcute n fiecare zi, sau se poate modifica o apli-
caie test astfel nct ntrebri noi pot fi create din zbor.
Deoarece App Inventor ofer acces la un senzor pentru locaie prin GPS, se pot construi, de asemenea,
aplicaii de orientare n spaiu. Se pot scrie aplicaii care s utilizeze funcionaliti ale telefonului cu
Android. De exemplu, o aplicaie care periodic trimite anumite texte, sms-uri, sau o aplicaie cu titlul Nu
trimit sms n timp ce conduc, care rspunde la toate sms-urile automat cu mi pare ru, eu sunt la vo-
lan i v voi contacta mai trziu. Se pot crea chiar aplicaii de citit sms-urile primite cu voce tare.
Nu n ultimul rnd, App Inventor este prevzut cu componente care permit aplicaiilor s comunice cu
Internetul. TinyWeb DB este o component mult mai general pentru comunicarea cu serviciile de web,
astfel nct se poate utiliza App Inventor pentru a scrie Android front-end-uri care vorbesc cu siturile
preferate. De exemplu, un programator ar putea scrie o aplicaie web n AppInventor pentru accesarea

Pagina 54

datelor de pe situl Amazon, o aplicaie de navigare prin librrie care s permit vizualizarea preului unei
cri.
Nu se pot construi chiar orice fel de aplicaii cu App Inventor. Acest instrument ofer, totui, un numr
limitat de componente de nivel nalt i nu ofer acces la toate funcionalitile definite n setul Android
(care este accesibil prin intermediul limbajului de programare Java, prin SDK Android). Dar se pot con-
strui mai multe aplicaii doar cu instrumente i componenta TinyWebDB care ofer o punte de legtur
pentru mai multe elemente de calcul complexe i servicii web, astfel nct AppInventor poate fi folosit n
colaborare cu programatori back-end.
3.2.2 Capaciti i limitri
Capacitile App Inventor includ:
accesul la cea mai mare parte a funcionalitilor telefonului: convorbiri telefonice, mesaje text
SMS, senzori de locaie, orientare i accelerare, funcia text-to-speech sau recunoaterea vorbirii,
sunet, video.
capacitatea de a invoca alte aplicaii, cu componenta ActivityStarter
programare de control ca ntr-un limbaj textual. Exist blocuri pentru condiionare (if, if else),
foreach i o list destul de cuprinztoare de blocuri de matematic i logic.
baza de date de acces, att pe dispozitiv, ct i pe web
accesul la surse de informare web (API) App Inventor are urmtoarele limitri n ceea ce privete
n ceea ce privete limitrile Ap Inventor, acestea sunt:
interfa cu utilizatorul limitat: constructorul interfeei cu utilizator s-a mbuntit, dar este
nc un pic defectuos i limitat, astfel nct nu se poate construi orice interfa de utilizator. De
exemplu, nu pot fi create aplicaii cu ecrane multiple i care s permit schimbri n orientarea
ecranului. Aceste probleme nu sunt fundamentale pentru proiectarea App Inventor i vor fi n
curnd rezolvate.
acces limitat la funciile aparatului: nu exist componente pentru toate datele i funcionalitile
telefonului. De exemplu, nu se pot salva i prelua fiiere din sistem i exist doar un acces limitat
la lista de contacte (nu se pot crea grupuri).
acces limitat la Web: pot fi accesate doar API-uri care s urmeze un protocol special (API App-
Inventor-compatibile).
nu exist componente polimorfe: funciile blocurilor sunt legate de componentele specifice i nu
exist nici o modalitate de a apela funcii pe o component generic. De exemplu, dac se cre-
eaz o procedur MutaXY, ea trebuie s fie legat de o imagine specific, nu de o imagine gene-
ral.
accesul limitat la Android Market: aplicaiilor generate de App Inventor le lipsete configurarea
necesar pentru includerea direct pe pia. Cu toate acestea, exist n prezent o soluie pentru
publicarea pe pia.


Pagina 55

3.2.3 Modul de lucru
App Inventor a fost conceput pentru a dezvolta aplicaii pentru telefoanele cu Android, folosind un
browser web i un telefon conectat la Internet sau emulatorul (Fig. 1.42). Serverele App Inventor sto-
cheaz aplicaiile dezvoltate i ofer, de asemenea, o form a versiunii de management, prin urmrirea
modificrii (change tracking). Practic, aceasta nseamn c mediul de programare face uz de metoda
numit cloud computing - utilizatorul/programatorul folosete computerul su doar s se conecteze la
Internet i la server i utilizeaz serverul cu resursele lui partajate spaiu de stocare sau chiar puterea
de procesare.

Fig. 1.42 Mediul de dezvoltare App Inventor
Aplicaiile pot fi construite n App Inventor astfel:
n App Inventor Designer, sunt selectate componentele care vor alctui aplicaia
n App Inventor Blocks Editor, blocurile din program sunt asamblate pentru a specifica modul n
care componentele trebuie s se comporte. Se pot asambla programele vizual, montnd piesele
mpreun, ca piesele unui puzzle.
Aplicaia apare pe telefon pas-cu-pas, pe msur ce piesele sunt adugate n ea, aa c poate fi testat
n timp ce este construit. Cnd e gata, poate fi ambalat pentru a produce o aplicaie de sine stttoare

Pagina 56

care ulterior se poate instala. Dac nu este disponibil un telefon cu Android, aplicaiile pot fi rulate cu
ajutorul emulatorului Android, un software care ruleaz pe calculator i se comport exact ca pe telefon.
Mediul de dezvoltare App Inventor poate rula pe Mac OS X, GNU/Linux, sistemele de operare Windows,
i pe modele de telefon deja populate cu Android. Aplicaiile create cu App Inventor pot fi instalate pe
orice telefon Android. nainte ca App Inventor s fie folosit, este necesar instalarea pachetului App
Inventor pentru computer.
Pentru a putea lucra cu App Inventor, sunt absolut necesare o conexiune la Internet i un cont Gmail. Cu
un browser web se navigheaz la pagina http://beta.appinventor.mit.edu/, unde se cere logarea cu con-
tul Gmail. Ceea ce se deschide este App Inventor Designer (Fig. 1.43 App Inventor Designer), unde se
creeaz proiectele i se adaug componentele viitoarei aplicaii. Pentru a stabili comportamentul aplica-
iei, este necesar pornirea editorului de blocuri (Blocks Editor), care se va deschide conform cu (Fig.
1.44), dac este instalat, n prealabil, Java.
3.2.4 Selectarea componentelor pentru crearea de aplicaii
Componentele App Inventor sunt situate pe partea stng a ecranului Designer (Fig. 1.43 App Inventor
Designer), sub titlul Palette i sunt elementele de baz care pot fi utilizate pentru a face aplicaii pentru
telefon cu Android. Unele componente sunt foarte simple, ca Label, care arat doar textul de pe ecran,
sau o component buton care se apas pentru a iniia o aciune. Alte componente sunt mai elaborate: o
pnz de desen, care poate conine imagini statice sau animaii, un accelerometru (senzor pentru mica-
re), care funcioneaz ca un controler Wii i detecteaz deplasarea sau scuturarea telefonului, compo-
nentele care fac sau trimit mesaje text, componente care ruleaz muzic i video, componente care
obin informaii de la situri web etc.

Fig. 1.43 App Inventor Designer

Pagina 57

Pentru a utiliza o component n aplicaie, aceasta se selecteaz printr-un clic i se trage pe mijlocul
Designer-ului. Dup adugare, componenta va aprea i n lista de componente, pe partea dreapt a
afiorului. Componentele au proprieti care pot fi ajustate pentru a schimba modul n care aceasta apa-
re n aplicaie. Pentru a vizualiza i modifica proprietile unei componente, ea trebuie selectat, mai
nti, din list.

Fig. 1.44 App Inventor Blocks Editor
3.2.5 Deschiderea editorului de blocuri i pornirea emulatorului
Designer-ul este unul dintre cele trei instrumente cheie folosite n crearea de aplicaii. Al doilea este
editorul de blocuri, utilizat pentru a atribui comportamente componentelor, cum ar fi ceea ce ar trebui
s se ntmple atunci cnd utilizatorul apas un buton. Editorul de blocuri (Fig. 1.44) se ruleaz ntr-o
fereastr separat. La deschiderea editorului de blocuri din fereastra Designer, un fiier care permite
computerului s comunice cu un dispozitiv conectat va fi descrcat i ar trebui s se deschid n mod
automat. Acest proces poate dura 30 de secunde sau mai mult. n cazul n care nu se deschide editorul,
atunci s-ar putea ca browser-ul s nu fie configurat pentru a rula aplicaii descrcate n mod automat. n
acest caz, se deschide fiierul descrcat numit AppInventorForAndroidCodeblocks.jnlp.
n partea stng a ferestrei editorului exist trei categorii de seturi de blocuri (pallete): Built-in, My
Blocks (unde vor aprea blocurile adugate n Designer) i Advanced. Cnd se acioneaz un set,
printr-un clic de maus, vor fi vizibile blocurile stocate n acea zon. Categoria Built-in conine setul stan-
dard de blocuri necesare pentru orice aplicaie (text, liste etc.). Categoria Advanced conine blocuri pen-
tru realizarea unor aplicaii mai avansate, cu o logic mai complex.
Designer-ul ruleaz n browser, iar editorul ruleaz folosind Java. Cu toate acestea, ele sunt conectate
astfel nct chiar dac se nchide fereastra editorului, toate informaiile din acesta sunt salvate n Desig-
ner. Cnd se face click pe butonul Open the Blocks Editor, un nou fiier .jnlp este descrcat pe calculator

Pagina 58

i acesta va fi deschis. n acest fel, editorul de blocuri va conine toate blocurile care fuseser deja pro-
gramate n pai anteriori.
Programatorul are posibilitatea s utilizeze un telefon sau tablet cu Android sau un emulator. Dac se
selecteaz emulator (Fig. 1.45), atunci ncrcarea va dura cteva minute, timp n care nu se va ntreprin-
de nicio aciune. Dup pornirea emulatorului, acesta trebuie conectat la editor, prin selectarea lui din
lista disponibil n colul din dreapta sus. Mai departe, editorul va ncepe comunicarea cu emulatorul i
aplicaia ar trebui s apar pe emulator. Se poate folosi mausul pentru a aciona butoanele de pe emula-
tor, dar dac butonul nu a fost programat, atunci nimic nu se va ntmpla. Mergnd mai departe, orice
modificri aduse aplicaiei n Designer i n editorul de blocuri, acestea vor aprea pe emulator.

Fig. 1.45 Emulatorul App Inventor
3.2.6 Componente App Inventor
Fiecare component poate avea metode, proprieti i evenimente. Majoritatea proprietilor pot fi
modificate de ctre aplicaii, prin blocurile de citire i setare pe care le dein, restul de proprieti pu-
tnd fi doar citite. n cele ce urmeaz sunt prezentate doar cteva categorii de componente disponibile
n App Inventor. Mai multe se pot afla la (24).
3.2.6.1 Componente de baz
Button component pe care utilizatorul o apas pentru a realiza o aciune asociat. Butoanele detec-
teaz cnd sunt apsate i i pot modifica aspectul.
Proprieti:
BackgroundColor: culoare pentru fundalul butonului.

Pagina 59

Enabled: dac este setat, butonul poate fi apsat.
FontBold: dac este setat, textul de pe buton este bold.
FontItalic: dac este setat, textul de pe buton este italic.
FontSize: dimensiunea textului de pe buton.
FontTypeface: tipul fontului de pe buton.
Height: nlimea butonului (dimensiunea y).
Width: limea butonului (dimensiunea x).
Image: imagine afiat pe buton.
Text: text afiat pe buton.
TextAlignment: stnga, centru, dreapta.
TextColor: culoarea textului de pe buton.
Evenimente:
Click(): utilizatorul a apsat i a eliberat butonul.
GotFocus(): butonul a devenit componenta activ
LostFocus(): butonul nu mai este componenta activ.
CheckBox component care detecteaz acionarea de ctre utilizator i i modific starea boolean.
Proprieti:
BackgroundColor: culoarea fundalului.
Checked: Adevrat dac este marcat i fals altfel.
Enabled: dac este setat, componenta poate fi acionat.
Height: nlimea casetei (dimensiunea y).
Width: limea casetei (dimensiunea x).
Text: text afiat pe caset.
TextColor: culoarea textului din caset.
Visible: dac este setat, componenta este vizibil
Evenimente:
Click(): utilizatorul a apsat i a eliberat caseta.
GotFocus(): caseta a devenit componenta activ
LostFocus(): caseta nu mai este componenta activ.
Label component pentru afiare de text specificat de proprietatea Text.
Proprieti:
BackgroundColor: culoare pentru fundalul etichetei.
FontBold: dac este setat, textul din etichet este bold.
FontItalic: dac este setat, textul din etichet este italic.

Pagina 60

FontSize: dimensiunea textului din etichet.
FontTypeface: tipul fontului textului din etichet.
Height: nlimea etichetei (dimensiunea y).
Width: limea etichetei (dimensiunea x).
Text: text afiat pe etichet.
TextColor: culoarea textului din etichet.
Visible: dac este setat, componenta este vizibil.
ListPicker component folosit pentru ca utilizatorul s poat selecta un element dintr-o list care
apare la acionarea componentei. Elementele listei pot fi specificate n proprietatea ElementsFromString
sub forma (selecie1, selectie2, selectie3), sau dintr-o list extern prin setarea proprietii Elements la o
list List n editorul de blocuri.
Proprieti:
Selection: elementul selectat din list.
Items: list de elemente separate prin virgul.
ElementsFromString: folosirea listei de elemente.
BackgroundColor: culoare pentru fundalul listei.
FontBold: dac este setat, textul din list este bold.
FontItalic: dac este setat, textul din list este italic.
FontSize: dimensiunea textului din list.
FontTypeface: tipul fontului textului din list.
Height: nlimea listei (dimensiunea y).
Width: limea listei (dimensiunea x).
Text: text afiat n list.
TextColor: culoarea textului din list.
Visible: dac este setat, componenta este vizibil.
Evenimente:
AfterPicking(): Utilizatorul a selectat un element din list.
BeforePicking(): Utilizatorul a acionat lista, dar nu a selectat nimic din ea.
GotFocus(): lista a devenit componenta activ
LostFocus(): lista nu mai este componenta activ.
Screen nu apare n palet ca alte componente, dar apare automat odat cu proiectul. Fiecare proiect
pornete cu un ecran, numit Screen1. Acest nume nu poate fi schimbat. Ulterior se pot aduga i alte
ecrane.
Proprieti

Pagina 61

AlignHorizontal: un numr care codific alinierea pe orizontal a coninutului ecranului. Valorile
pot fi 1= aliniere la stnga, 2=centrare, 3=aliniere la dreapta.
AlignVertical: un numr care codific alinierea pe vertical a coninutului ecranului. Valorile pot
fi 1= aliniere sus, 2=centrare, 3=aliniere jos.
BackgroundColor: culoarea de fundal pentru ecran.
BackgroundImage: o imagine care se ncarc pe fundalul a ecranului.
Height: nlimea ecranului (dimensiunea y).
Icon: o imagine care poate fi utilizat ca pictogram pentru aplicaia instalat pe telefon. Aceas-
ta ar trebui s fie PNG sau JPG; 48x48 este o dimensiune bun. n cazul folosirii altor imagini de-
ct PNG sau JPG, de exemplu fiiere ICO, App Inventor nu va putea s mpacheteze aplicaia.
ScreenOrientation: orientarea ecranului. Valorile posibile sunt: unspecified, landscape, portrait,
sensor, user.
Scrollable: opiunea este specificat printr-un checkbox n designer. Cnd este selectat, va exista
o bar de derulare vertical pe ecran i nlimea aplicaiei poate depi nlimea fizic a dispo-
zitivului. Cnd nu este bifat, nlimea aplicaiei va fi constrns la nlimea dispozitivului.
Title: titlu pentru ecran (text). Aceasta va aprea n partea stng sus a telefonului atunci cnd
aplicaia ruleaz. O alegere normal pentru titlu este chiar titlul aplicaiei, dar ar putea fi altceva,
sau poate fi chiar schimbat n timp ce aplicaie se execut.
Width: limea ecranului (dimensiunea x).
Evenimente:
BackPressed(): apsarea butonului de pe spatele echipamentului.
Initialize(): semnalat atunci cnd aplicaia ncepe. Acesta poate fi utilizat pentru stabilirea valori-
lor iniiale i efectuarea altor operaiuni de configurare.
ErrorOccurred(): semnalat atunci cnd apare o eroare. Este utilizat n prezent pentru un set limi-
tat de erori.
OtherScreenClosed(text otherScreenName, any result): nchiderea unui alt ecran i returnarea
controlului ecranului curent.
ScreenOrientationChanged(): modificarea orientrii ecranului
Metode:
CloseScreenAnimation(text animType): pregtete animaia pentru nchiderea ecranului curent
i ntoarcerea la ecranul anterior. Opiuni valide sunt: default, fade, zoom, slidehorizontal,
slidevertical i none.
OpenScreenAnimation(text animType): pregtete animaia pentru trecerea la alt ecran. Opiuni
valide sunt: default, fade, zoom, slidehorizontal, slidevertical i none.
TextBox component pentru introducerea de text. Se poate stabili o valoare iniial (n proprietatea
Text), sau se poate oferi o sugestie de completare (n proprietatea Hint). Textul introdus poate avea una
sau mai multe rnduri (proprietatea MultiLine). Dac este permis o singur linie de text, la completarea
ei, tastatura se va nchide automat la semnalizarea utilizatorului (apsarea tastei Done). De regul, case-

Pagina 62

tele de text sunt folosite n combinaie cu butoane, astfel nct utilizatorul s acioneze un buton cnd a
finalizat introducerea textului.
Proprieti:
BackgroundColor: culoare pentru caset.
Enabled: dac este setat, se poate introduce text n caset.
FontBold: dac este setat, textul din caset este bold.
FontItalic: dac este setat, textul din caset este italic.
FontSize: dimensiunea textului din caset.
FontTypeface: tipul fontului testului din caset.
Height: nlimea casetei (dimensiunea y).
Width: limea casetei (dimensiunea x).
Text: text afiat n caset.
TextColor: culoarea textului din caset.
Visible: dac este setat, componenta este vizibil
Hint: text pentru sugestionarea utilizatorului. Vizibil doar dac Text nu conine nimic.
MultiLine: dac este adevrat, atunci este permis introducerea mai multor linii.
NumbersOnly: dac este adevrat, atunci caseta accept ca intrri doar valori numerice
Evenimente:
GotFocus(): caseta a devenit componenta activ.
LostFocus(): caseta nu mai este componenta activ.
Metode:
HideKeyboard(): ascunde tastatura. Este necesar pentru mai multe linii. La o singur linie se
apas tasta Done.
TinyDB se face pentru a stoca datele care vor fi disponibile de fiecare dat cnd aplicaia se execut.
TinyDB este o component non-vizibil (adic utilizatorul nu o vede pe ecranul aplicaiei).
Aplicaiile create cu App Inventor sunt iniializate de fiecare dat cnd ruleaz. Dac o aplicaie stabile-
te valoarea unei variabile i utilizatorul nchide apoi aplicaia, valoarea acelei variabile nu va fi memorat
data viitoare cnd aplicaia ruleaz. TinyDB este un stocator de date persistent pentru aplicaie, adic
datele stocate vor fi disponibile de fiecare dat cnd aplicaia se execut. Un exemplu ar putea fi un joc
care a salvat scorul cel mai mare, i refcut de fiecare dat cnd jocul este jucat.
Instanele de date sunt stocate n tag-uri. Ulterior, se poate prelua un element care a fost stocat ntr-un
anumit tag. Dac nu exist nici o valoare depozitat sub ntr-un tag, atunci valoarea returnat este textul
gol. Prin urmare, pentru a vedea dac o etichet are o valoare stocat sub ea, se testeaz dac valoarea
returnat este egal cu text gol (de exemplu, o caset text cu nici un text completat).

Pagina 63

Exist doar o singur stocare de date pentru o aplicaie. Dac e nevoie de mai multe componente
TinyDB, ele vor folosi aceleai date. De asemenea, fiecare aplicaie are propriul loc de stocare. Nu se
poate utiliza TinyDB pentru a muta date ntre dou aplicaii diferite de pe telefon. Pentru a terge din
baza de date a unei aplicaii, de pe telefon din meniul SettingsApplicaons Manage applicaons, se
alege aplicaia i se apas Clear data.
Datele din TinyDB sunt persistente numai dup mpachetarea i descrcarea aplicaiei. Dac aplicaia
este n curs de dezvoltare i telefonul este conectat la PC i se repornete aplicaia App Inventor, sau
dac se deconecteaz i apoi reconecteaz telefonul, baza de date va rencepe n stare proaspt
(refresh). Acesta este cazul n care aplicaia nu este doar oprit i repornit, ci este tears din telefon i
apoi rencrcat.
Proprieti: nu are
Evenimente: nu are
Metode:
StoreValue(text tag, valueToStore): salveaz valoarea n tag, care trebuie s fie un text. Valoarea
poate fi un text sau o list.
GetValue(text tag): citete valoare salvat n tag. Dac nu e nimic, returneaz textul vid.
3.2.6.2 Componente de tip senzor
AccelerometerSensor Aceast component detecteaz accelerometrul dispozitivului Android care, la
rndul lui, detecteaz scuturarea telefonului i msoar acceleraia n 3 dimensiuni. Dac telefonul este
aezat pe o suprafa plan, pe spate, acceleraia Z este 9.8m/s
2
. Componenta produce trei valori:
XAccel: pozitiv cnd dispozitivul este nclinat spre dreapta (adic partea stng este ridicat) i
negativ cnd este nclinat spre stnga.
YAccel: pozitiv cnd partea de jos este ridicat i negativ cnd partea de sus este ridicat.
ZAccel: pozitiv cnd ecranul este orientat n sus i negativ cnd ecranul este orientat n jos.
Proprieti
Available: dac exist accelerometru.
Enabled: activarea accelerometrului.
XAccel: acceleraie pe dimensiunea X.
YAccel: acceleraie pe dimensiunea Y.
ZAccel: acceleraie pe dimensiunea Z.
MinimumInterval: intervalul de timp minim ntre scuturarea telefonului.
Evenimente:
AccelerationChanged(number xAccel, number yAccel, number zAccel): apelat cnd se modific
acceleraia.

Pagina 64

Shaking(): apelat repetitiv cnd echipamentul este scuturat.
Metode:
Nu are.
LocationSensor Aceast component ofer locaia dispozitivului Android, folosind GPS-ul dac este
disponibil i o metod alternativ altfel, cum ar fi turnuri celulare sau reele fr fir cunoscute.
LocationSensor este o component non-vizibil care furnizeaz informaii de locaie, inclusiv longitudine,
latitudine, altitudine (dac este acceptat de aparat) i adresa. Aceast component poate oferi, de
asemenea, geocodare, de conversie a unei adrese date (nu neaprat pe cea curent) la o latitudine i o
longitudine. Pentru a funciona, componenta trebuie s aib proprietatea Enabled setat pe true, iar
dispozitivul s aib activat funcia de detectare a locaiei.
Proprieti:
Accuracy: indic nivelul de exactitate al dispozitivului Android, n metri.
Altitude: altitudinea dispozitivului Android, dac este disponibil.
AvailableProviders: lista furnizorilor de servicii disponibile, cum ar fi GPS sau de reea
CurrentAddress: adresa fizic a dispozitivului Android.
Enabled: dac este setat, informaiile de localizare sunt disponibile.
HasAccuracy: dac este adevrat, dispozitivul Android poate raporta nivelul de precizie.
HasAltitude: dac este adevrat, dispozitiv Android pot raporta altitudinea sa.
HasLongitudeLatitude: dac dispozitivul Android poate raporta longitudinea i latitudinea.
Latitude: latitudinea dispozitivului Android.
Longitude: longitudinea dispozitivului Android.
ProviderLocked: dispozitivul nu va schimba furnizorul de servicii.
ProviderName: furnizorul de servicii actual
Evenimente:
LocationChanged (number latitude, number longitude, number altitude): apelat atunci cnd dis-
pozitivul Android gsete o locaie nou.
StatusChanged(text provider, text status): apelat atunci cnd starea furnizorului de servicii se
modific.
Metode:
LatitudeFromAddress (text locationName): determin latitudinea adresei indicate.
LongitudeFromAddress (text locationName): determin longitudinea adresei indicate.
OrientationSensor este o component ce se folosete pentru a determina spaial orientarea telefonu-
lui. Acesta este o component non-vizibil care raporteaz urmtoarele trei valori, n grade:

Pagina 65

Roll: 0 atunci cnd dispozitivul este drept, crescnd la 90 cnd dispozitivul este nclinat cu par-
tea de sus spre partea stng i scznd la -90 atunci cnd dispozitivul este nclinat cu partea de
sus spre partea dreapt.
Pitch: 0 atunci cnd dispozitivul este drept, crescnd la 90 cnd dispozitivul este nclinat astfel
nct vrful su este ndreptat n jos, creterea n continuare la 180 cnd acesta devine ntors
invers. n mod similar, cnd aparatul este nclinat astfel nct partea sa de jos este ndreptat n
jos, scade la -90, apoi pn la -180 pe msur ce este rsucit tot drumul peste cap.
Azimuth: 0 atunci cnd partea de sus a aparatului este ndreptat spre nord, la 90 atunci cnd
este ndreptat spre est, la 180 atunci cnd este ndreptat spre sud, la 270 de grade atunci cnd
este ndreptat spre vest, etc
Aceste msurtori presupun c aparatul n sine nu este n micare.
Proprieti:
Available: arat dac senzorul de orientare este prezent pe dispozitivul Android.
Enabled: dac este setat, senzorul de orientare este activat.
Azimuth: returneaz unghiul de deviaie al dispozitivului.
Pitch: returneaz unghiul de ntoarcere peste cap al dispozitivului.
Roll: returneaz unghiul de rotire al dispozitivului.
Magnitude: returneaz un numr ntre 0 i 1, care indic gradul de nclinare al dispozitivului.
Mrimea d magnitudinea forei pe care ar simi-o o bil pe suprafaa de rulare a dispozitivului.
Angle: returneaz unghiul care spune direcia n care dispozitivul este ndreptat. Adic, se spune
direcia forei pe care ar simi-o o bil pe suprafaa de rulare a dispozitivului.
Evenimente
OrientationChanged(number yaw, number pitch, number roll): numit atunci cnd orientarea s-a
schimbat.
3.2.7 Blocuri din App Inventor
n cele ce urmeaz sunt prezentate principalele tipuri de blocuri care pot fi utilizate pentru realizarea
unei aplicaii cu App Inventor. Materialul complet poate fi gsit la (24).
3.2.7.1 Blocuri de definire
procedure (procedureWithResult) grupeaz o secven de blocuri care, ulterior, poate fi utilizat n
mod repetat, ca apel de procedur. La crearea unei proceduri, App Inventor creeaz n mod automat un
bloc de apel (call) care va fi plasat n zona My Definitions. Acest bloc de apel poate fi folosit pentru a
invoca procedura. La crearea unui nou bloc de acest tip, App Inventor alege un nume care poate fi, ulte-
rior, modificat. Acest nume, la nivel de aplicaie, trebuie s fie unic. Fig. 1.46 prezint modul de afiare al
acestor blocuri.

Pagina 66

a)

b)
Fig. 1.46 Blocuri de proceduri, fr a) i cu b) returnare de rezultat
name creeaz un argument cu nume care poate fi utilizat la apelul unei proceduri. Argumentul pro-
cedurii se specific prin plasarea unui astfel de bloc la intrarea arg a procedurii. Numrul de argumente
nu este limitat, la completarea unuia aprnd, de fiecare dat, un port nou. La specificarea unui argu-
ment, App Inventor va asocia acest argument cu blocul call generat pentru procedur: sloturile pentru
argumente ale blocului de apel vor vizualiza numele argumentelor. Pentru fiecare bloc name definit, App
Inventor creeaz un bloc value asociat i l plaseaz n zona My Definitions. Aceste blocuri vor fi folosite
pentru referirea la valori la apelul procedurilor.
variable creeaz o valoare care poate fi modificat pe parcursul rulrii aplicaiei i d un nume pentru
aceast valoare. Variabilele sunt globale i pot fi folosite oriunde n aceeai aplicaie. Numele variabilei
trebuie s fie unic. Fig. 1.47 prezint modul de afiare a blocurilor name i variable.

a)

b)
Fig. 1.47 Bloc de tip nume a) i bloc de tip variabil b)
3.2.7.2 Handler de evenimente
Programele App Inventor descriu cum ar trebui se comporte telefonul n anumite circumstane: un bu-
ton a fost apsat, telefonul a fost scuturat etc. Aceste aciuni specifice sunt descrise de un handler de
evenimente care ncepe cu cuvntul when. Majoritatea handler-elor au culoare verde.

Fig. 1.48 Handler de evenimente
Evident, cnd un eveniment apare, handler-ul asociat va fi executat.

Pagina 67

3.2.7.3 Comenzi i expresii
Cnd este executat un handler de evenimente, de fapt se ruleaz o secven de comenzi din corpul su.
O comand este un bloc care specific o aciune care va fi realizat pe telefon. Majoritatea comenzilor
sunt mov sau albastre.

Fig. 1.49 Exemplu de comenzi
Anumite comenzi au nevoie de una sau mai multe valori de intrare (cunoscute i sub numele de parame-
trii sau argumente) pentru a-i putea realiza aciunea. Spre exemplu (Fig. 1.49), Sound1.Vibrate are ne-
voie de un timp de vibrare, n milisecunde. Nevoia unui parametrul este marcat de socket-ul din partea
dreapt a comenzii.
Socket-ul poate primi valori i de la o expresie, adic blocuri cu valori. Blocurile de expresii au un capt
de prindere n partea stng, prin care i transmit valoarea socket-ului. Pot fi construite expresii foarte
complexe folosind expresii mai simple, prin compunere orizontal (Fig. 1.50).

Fig. 1.50 Expresii
Forma comenzilor este astfel realizat, nct ele se pot compune pe vertical ntr-o stiv de comenzi. De
fapt, aceasta este o comand complex compus din comenzi mai simple.

Fig. 1.51 Comenzi compuse

Pagina 68

Dac o astfel de stiv este plasat n handler-ul unui eveniment, comenzile vor fi executate de sus n jos.
Spre exemplu, n Fig. 1.51 telefonul va emite un sunet, apoi va vibra, apoi eticheta i va schimba culoa-
rea i va afia textul specificat. Dat fiind faptul c execuia are lor foarte repede, toate aciunile au loc
aproape simultan.
3.2.7.4 Aranjarea elementelor pe ecran
Implicit, componentele sunt aranjate pe vertical. Dac se dorete modificarea acestui mod de aranjare,
atunci se poate folosi una dintre componentele HorizontalArrangement, VerticalArrangement sau
TabletArrangement din seciunea ScreenArrangement.
3.2.7.5 Manipularea strii componentelor
Fiecare component este caracterizat de numeroase proprieti. Valorile curente ale acestor proprie-
ti reprezint starea componentei. Un program App Inventor poate determina i schimba starea oric-
rei componente prin metode prin blocuri specifice de tip getter i setter (exemplu pentru etichet).

Fig. 1.52 Getter-e i setter-e pentru etichet
3.2.7.6 Evenimente ale butoanelor
Cel mai frecvent eveniment legat de butoane este Click. Alte evenimente asociate sunt LongClick,
GetFocus i LostFocus. Majoritatea componentelor primesc focusul cnd sunt atinse i l pierd cnd nu
mai sunt atinse. Butonul este special pentru c, atunci cnd este atins, lanseaz evenimentul Click.
3.2.7.7 Comentarii
O parte important din munca de programare o constituie realizarea unei documentaii. App Inventor
permite ncorporarea de comentarii chiar n cod care explic diverse elemente i aspecte ale codului.
Adugarea unui comentariu pentru blocuri se face cu clic dreapta pe bloc (Fig. 1.53).

Fig. 1.53 Adugarea de comentarii

Pagina 69

3.2.8 Exemplu de realizare a unei aplicaii cu App Inventor.
n continuare, este prezentat realizarea unui joc (Fig. 1.54) n cadrul cruia utilizatorul are pe ecran o
poart de fotbal, o minge, un indicator de for a utului, un indicator de direcie i un portar. Scopul
jocului este de a nscrie gol, avnd mingea n punctul de 11 m. Portarul, direcia i fora sunt n continu
micare, fiecare avnd viteze diferite. Portarul se mic pe linia porii efectund o curs complet, care
se repet pn cnd mingea ajunge la el, sau mingea intr n poart, sau mingea trece pe lng poart.
Utilizatorul are la dispoziie dou butoane: unul pentru a uta, iar cellalt pentru a repune mingea pe
punctul de la 11 m. n funcie de indicatorul de for i de direcie, mingea va merge mai repede sau mai
ncet, respectiv mai la stnga sau mai la dreapta. n momentul n care mingea intr n poart este afiat
mesajul GOOOOL, cnd mingea este prins de portar, mesajul , iar cnd mingea trece pe lng poart,
mesajul Ce ratare.
3.2.8.1 Elemente vizuale
Terenul de fotbal este reprezentat de un element Canvas al crui fundal este o imagine cu extensia .jpg
ce conine, n partea superioar, poarta de fotbal, imaginat ntr-o manier tridimensional, punctul de
la 11 m, de unde se va executa lovitura de pedeaps i dou marcaje folosite pentru orientarea direciei
i stabilirea forei utului. Portarul este reprezentat printr-un element de tipul ImageSprite, avnd ca
fundal o imagine sugestiv a unui portar, dup cum se poate observa n Fig. 1.54. Portarul se mic pe
orizontal, ntre barele porii, cu viteza constant. Mingea este reprezentat printr-un control de anima-
ie de tip Ball, avnd dimensiunea 5 i culoarea inspirat din jocurile de fotbal, galben.

Fig. 1.54 Joc realizat cu App Inventor
Indicatorul de direcie (Fig. 1.55) si indicatorul pentru fora utului (Fig. 1.56) sunt realizai tot cu con-
troale de animaie de tipul Ball. Acetia execut o micare n plan orizontal, respectiv vertical, iar limitele
sunt evideniate prin indicatoarele din fundal. Butonul Shoot este folosit pentru a lansa mingea ctre
poart. Aceasta va avea direcia dat de indicatorul de direcie i fora dat de indicatorul de for al

Pagina 70

utului. Butonul Retry repune mingea pe punctual de la 11 m, pentru a se putea efectua un nou ut pe
poart.

Fig. 1.55 Indicator de direcie

Fig. 1.56 Indicator pentru fora utului

3.2.8.2 Stabilirea aciunii
Aciunea jocului este realizat foarte simplu i const n sincronizarea a patru ceasuri. Ceasul utilizat
pentru micarea portarului are intervalul setat la 100 milisecunde. Poziia portarului are ordona-
ta constant, de valoare 40, n sistemul de coordinate carteziene cu originea n colul din stnga sus.
Abscisa variaz ntre 104 i 186, bazat pe dimensiunea porii, simulnd perfect realitatea. Incrementarea
si decrementarea abscisei se face cu un pas de 3 pixeli, astfel nct, ntr-o curs complet, portarul s
acopere suprafaa ntregii pori.
Fig. 1.57 descrie modul de programare al ceasului portarului. Poziia portarului este stabilit de valoarea
curent a variabilei globale pozG. La fiecare pas, se verific dac micarea este spre stnga sau spre
dreapta (dat de valoarea variabilei globale wayG) i dac, dup ajustarea corespunztoare a poziiei
portarului, acesta este ntre limitele admise.
Fora utului este dat de poziia bilei albastre din Fig. 1.56. Acest indicator are abscisa fix, cu valoa-
rea 306, iar ordonata variabil, cu valori ntre 302 i 225. Intervalul este mprit n 11 pri, viteza fiind
incrementat cu pas egal de la poziia 302 spre 255, i decrementat invers. Fig. 1.57 descrie modul de
programare al ceasului asociat forei utului. Poziia bilei este stabilit de valoarea curent a variabilei
globale Ball3.y. La fiecare pas, se verific dac micarea este n sus sau n jos (dat de valoarea variabilei
globale wayy) i dac, dup ajustarea corespunztoare a poziiei bilei, acesta este ntre limitele admise.

Pagina 71

Fig. 1.57 Stabilirea poziiei portarului
Indicatorul de direcie a mingii este programat similar cu cel de stabilire a forei utului, folosind un ceas
pentru a realiza micarea orizontal ntre punctele 236 si 306, ordonata 320. Intervalul este mprit la
17, rezultnd, astfel, o vitez diferit de deplasare fa de indicatorul de for a utului. Dac butonul
Shoot este apsat cnd bila se afl n centrul intervalului, aceasta va fi utat perpendicular pe direcia
porii. Cu ct abaterea este mai mare fa de centrul intervalului, cu att mingea se va deplasa mai la
stnga sau mai la dreapta fa de centrul porii.
Mingea se deplaseaz ntre poziiile 103 i 190 pe abscis i 50 i 306 pe ordonat. Viteza este dat de
indicatorul de vitez, n timp ce direcia este influenat att de indicatorul de direcie, ct i de ut (Fig.
1.59). La fel cum n realitate, un ut puternic este mai puin plasat, i n cadrul acestui joc un ut cu vite-
z mai mic va avea anse mai mari de a nimeri direcia porii.

Pagina 72

Fig. 1.58 Stabilirea forei utului

Fig. 1.59 Determinarea direciei mingii
n cazul n care ntre minge i portar exist coliziune, jocul se ncheie cu mesajul Saved (Fig. 1.60). Dac
mingea intr n poart, mesajul este GOOOOOL, iar dac mingea trece pe lng poart, va fi afiat mesa-
jul Ce ratare (Fig. 1.60).

Pagina 73

Fig. 1.60 Rezultatele posibile
Metoda CollidedWith a componente de tip ImageSprite, care implementeaz portarul, surprinde mo-
mentul n care mingea se ciocnete de portar (Fig. 1.61). n acest caz, sunt oprite toate ceasurile i se
afieaz pe ecran mesajul corespunztor.
Evident, fiecare buton are asociat o aciune proprie. Apsarea butonului este surprins de metoda Click
asociat acestuia. Butonul Retry aduce jocul n stare iniial. Ca urmare, va opri ceasul mingii, va porni
celelalte trei ceasuri (pentru portar, direcie i for) i va pune mingea la poziia punctului de 11 m.
Butonul Shoot, va opri ceasurile direciei i forei, va determina direcia de deplasare i va porni ceasul
mingii. Fig. 1.62 prezint, n detaliu, modul n care cele dou butoane au fost programate.

Fig. 1.61 Portarul prinde mingea

Fig. 1.62 Aciunile asociate celor dou butoane

Pagina 74

4 Modelare cu Simulink
Simulink, dezvoltat de MathWorks, este un instrument comercial pentru modelarea, simularea i analiza
sistemelor multidomain dinamice. Interfaa sa principal este constituit de o unealt pentru realizarea
de diagrame cu blocuri grafice i un set personalizabil de biblioteci de astfel de blocuri, care permit pro-
iectarea, simularea, punerea n aplicare sau testarea unei varieti de sisteme dependente de timp, in-
clusiv de comunicaii, control, procesare de semnal, prelucrare video i de procesare a imaginii. Simulink
este integrat cu restul mediului MATLAB i poate controla programe MATLAB sau poate fi controlat din
program Matlab. Simulink este utilizat pe scar larg n teoria sistemelor i teoriile de procesare ale
semnalului digital pentru simulare multidomain i model bazat pe design.
Printre facilitile oferite de Simulink se numr (25):
biblioteci extensibile i expandabile de blocuri predefinite;
editor grafic interactiv pentru asamblarea i managementul diagramelor intuitive de blocuri;
abilitatea de a manageriza design-uri complexe prin segmentarea modelelor n ierarhii de com-
ponente
un mediu gen explorer pentru navigarea, crearea, configurarea i cutarea tuturor semnalelor,
parametrilor, proprietilor i codului generat asociat cu modelul;
blocuri de funcii Matlab ncorporate pentru a aduce algoritmi Matlab n Simulink;
moduri de simulare (Normal, Accelerator i Rapid Accelerator) pentru rularea simulrilor n mod
interpretativ sau la vitezele de compilare ale codului C, folosind pai de rezolvare fici sau varia-
bili;
debuger grafic i analizor pentru analizarea rezultatelor simulrii, pentru diagnoza performanei,
precum i a comportamentelor neateptate ale modelelor;
acces total la Matlab pentru analiza i vizualizarea datelor, particularizarea mediului de modela-
re, definirea semnalelor, parametrilor i a datelor de test;
analiza modelelor i unelte de diagnostic pentru a asigura consistena modelului i a identifica
erorile de modelare.
Care sunt avantajele folosirii Simulink?
Chiar dac nu respect o anumit metodologie, ofer majoritatea avantajelor unui CASE tool i permite
execuia modelelor n interiorul su. De asemenea, este foarte folositor pentru depanare. Simulink per-
mite reutilizarea componentelor funcionale i integrarea lor n diverse subsisteme. n aceeai manier
pot fi refolosite i abloane de testare utilizate n alte modele. Dup efectuarea testrii, Matlab/Simulink
poate genera un raport automat care poate fi folosit ca documentaie pentru rezultatele testrii. Nu n
ultimul rnd, vizualizarea rezultatelor ajut utilizatorul n realizarea i depanarea modelului.
Care sunt dezavantajele folosirii Simulink?
Pachetul Matlab este destul de scump, ceea ce l poate face prohibitiv pentru proiectele mici. Ca orice
unealt comercial, i Simulink suport update-uri i s-a constatat c, dei n-ar trebui s se ntmple,
uneori apar conflicte de versiune. Conceptul de memorie al Matlab nu suport nevoile unui proiect sof-

Pagina 75

tware complex, ci este, mai degrab, propice pentru analizele tiinifice numerice sau matematice.
Matlab/Simulink nu respect a anumit metodologie, fiind necesar standardizarea unor metode de
design i de codare.

Fig. 1.63 Construirea unui model prin asamblarea de componente, fiecare dintre ele putnd fi un model separat

4.1 Crearea i realizarea modelelor
n Simulink se poate crea, modela i menine o diagram detaliat de blocuri pentru sistemul descris,
folosind un set comprehensiv de blocuri predefinite. Exist unelte pentru modelarea ierarhic, mana-
gementul datelor i personalizarea subsistemelor care permit realizarea unor reprezentri concise i
corecte ale sistemelor, chiar dac acestea sunt destul de complexe.
Simulink conine o bibliotec extensiv de funcii comune care pot fi utilizate la crearea modelelor,
compus din (25):
Blocuri dinamice continue i discrete, precum Integration i Unit Delay
Blocuri algoritmice, precum Sum, Product i Lookup Table
Blocuri structurale, precum Mux, Switch i Bus Selector
Aceste blocuri predefinite pot fi personalizate sau se pot crea alte blocuri noi, care vor fi plasate n libr-
rii personale.
Seturi de blocuri adiionale (disponibile separat) extind Simulink cu funcionaliti specifice pentru
aerospaiu, comunicaii, radiofrecven, procesarea sunetelor, procesri video i de imagini i alte apli-
caii. De asemenea, se pot modela i sisteme fizice. Simscape, SimDriveline, SimHydraulics,
SimMechanics i SimPowerSystems (toate disponibile separat) ofer capabiliti extinse pentru modela-
rea sistemelor fizice, cum ar fi cele cu componente mecanice, electrice i hidraulice.

Pagina 76

Realizarea unui model se face prin selectarea blocurilor din librrii i tragerea lor pe editorul grafic. Co-
nectarea blocurilor se face prin linii, care stabilesc relaii matematice ntre acestea. Aranjarea modelului
se face n editorul grafic prin tehnica drag and drop sau prin funcii precum copiere, alipire, refacere,
aliniere, distribuire i redimensionare.

Fig. 1.64 Realizarea unui model n Simulink
Blocurile pot fi conectate manual, folosind mausul, sau automat, prin linii de rutare n jurul blocurilor
vizate sau prin topologii complexe. Interfaa cu utilizatorul din Simulink ofer un control complet asupra
ceea ce este vizibil i poate fi utilizat. Utilizatorul poate aduga propriile comenzi i submeniuri la editor
i meniurile contextuale. Se pot dezactiva i ascunde meniuri, elemente din meniuri i controale de tip
casete de dialog.
Simulink permite organizarea modelului n nivelurile clare, uor de gestionat, sub form de ierarhie de
subsisteme, folosind corelarea la model. Subsistemele cuprind un grup de blocuri i semnale ntr-un
singur bloc. Se poate aduga o interfa personalizat pentru un subsistem care ascunde coninutul i
face ca subsistemul s apar ca un bloc atomic cu propria lui pictogram i caset de dialog a parametri-
lor.
Se poate, de asemenea, segmenta modelul n componentele de proiectare ale sistemului, simula i veri-
fica fiecare component independent. Componentele pot fi salvate ca modele separate prin afilierea la
model, sau ca subsisteme ntr-o bibliotec i se pot reutiliza n proiecte multiple. Organizarea de modele
n acest fel permite selecia nivelului de detaliere adecvat la sarcina de proiectare. De exemplu, se pot
utiliza iniial relaii simple pentru a modela specificaiile de nivel nalt i se adaug relaii mai detaliate
pe msur ce se nainteaz n dezvoltare.
4.2 Simularea unui model
Dup construirea modelului n Simulink, se poate simula comportamentul dinamic i vizualiza rezultatele
instantaneu. Software-ul Simulink ofer mai multe caracteristici i instrumente pentru a asigura viteza i
acurateea simulrii, inclusiv rezolvatori (solver) cu pas fix i cu pas variabil, un depanator (debugger)
grafic i un analizor de modele.

Pagina 77

Rezolvatorii sunt algoritmi numerici de integrare, care calculeaz dinamica sistemului de-a lungul timpu-
lui folosind informaiile coninute n model. Simulink ofer rezolvitori pentru susinerea simulrii unei
game largi de sisteme, inclusiv de timp continuu (analog), timp discret (digital) i hibrid (cu semnal mixt).
Aceti rezolvitori pot simula sisteme rigide i sisteme cu evenimente de stare, cum ar fi discontinuiti,
inclusiv modificrile instantanee n dinamica sistemului. Exist posibilitatea de a specifica opiunile de
simulare, inclusiv tipul i proprietile rezolvitorului, timer-ele de la nceputul i sfritul simulrii i dac
se dorete ncrcarea sau salvarea datele de simulare. Se pot seta, de asemenea, metodele de optimiza-
re i informaii de diagnostic pentru simulare. Diferite combinaii de opiuni pot fi salvate odat cu mo-
delul.
Depanatorul Simulink este un instrument interactiv de simulare pentru examinarea rezultatelor i locali-
zarea i diagnosticarea unui comportament neateptat ntr-un model. Acesta permite identificarea rapi-
d a problemelor n model prin rularea pas cu pas, simulnd la un moment dat o singur metod i exa-
minnd rezultatelor dup executare acestei metode. Metodele sunt funcii pe care Simulink le folosete
pentru a rezolva un model la fiecare pas n timpul de simulare. Blocuri sunt alctuite din mai multe me-
tode.

Fig. 1.65 Depanatorul Simulink

Pagina 78

Depanatorul Simulink permite stabilirea de puncte de oprire (breakpoints), controlul simulrii i afiarea
informaiilor despre model. Acesta poate fi rulat de pe o interfa grafic (GUI) sau de la linia de coman-
d MATLAB. GUI ofer o imagine clar, n culori a statutului execuiei modelului. n timp ce modelul si-
muleaz, se pot afia informaii cu privire la strile blocurilor, intrrile i ieirile acestora i alte informa-
ii, precum i execuia metodelor direct pe model.
Dup stabilirea opiunilor de simulare pentru un model, se poate rula simularea n mod interactiv, folo-
sind Simulink GUI, sau sistematic, din linia de comand a Matlab. Se pot folosi urmtoarele moduri de
simulare (25):
Normal (implicit), simuleaz interpretativ modelul
Accelerat, mrete viteza de execuie a modelului i genereaz cod compilat dar i permite utili-
zatorului modificarea unor parametri ai modelului
Accelerat rapid, viteza de simulare este mai mare dect n cazul anterior, interactivitatea mult
mai sczut i genereaz cod executabil
4.3 Analiza rezultatelor
Rezultatele sistemului pot fi vizualizate prin afiarea semnalelor generate cu afiorul specializat (Scope),
sau printr-un display personalizat folosind vizualizarea Matlab i uneltele de dezvoltare GUI. De aseme-
nea, semnalele pot fi folosite i pentru post-procesare. Pentru o mai bun nelegere a comportrii un
unui sistem 3D complex, se pot ncorpora scene de realitate virtual, folosind Simulink 3D Animation.
Simulink include unelte pentru generarea de condiii de test pentru validarea performanelor sistemului
creat. Acestea includ blocuri pentru crearea testelor. Spre exemplu, blocul Signal Builder permite crea-
rea n mod grafic a unor forme de und care s alimenteze modelul. Folosind Signal&Scope Manager se
pot injecta semnale n model, se pot vizualiza semnale, fr adugarea de blocuri suplimentare. Simulink
ofer i blocuri de verificare a modelului pentru a verifica dac ieirile blocului corespund cu cerinele de
design.
Modelul poate fi documentat foarte uor. Se pot aduga adnotaii direct pe diagram, precum i descri-
eri detaliate ale proprietilor blocurilor i ale proprietilor modelului. Blocul DocBlock permite include-
rea unui fiier de documentaie ca bloc al modelului. De asemenea, Simulink ofer capabiliti de tipri
care permit documentarea cu uurin a modelului. Cu o singur comand se poate crea un fiier HTML
care descrie ntregul model, inclusiv capturi de ecran ale diverselor niveluri de ierarhie existente n mo-
del, precum i toate specificaiilor blocurilor.
Modelele construite n Simulink pot fi configurate s genereze cod. Folosind Simulink Coder i Embedded
Coder (ambele disponibile separat) se poate genera cod C/C++ pentru simulri n timp real, prototipizare
rapid i dezvoltarea sistemelor ncorporate. Folosind Simulink HDL Coder (disponibil separat) se poate
genera cod Verilog i VHDL.

Pagina 79

4.4 Modelare n SimMechanics
SimMechanics face parte din suita MATLAB i este un pachet software pentru modelarea, simularea i
analiza dinamic a sistemelor mecanice. Simularea se realizeaz n doi pai: se creeaz modelul grafic al
sistemului care se dorete a fi simulat (folosind editorul specializat), model care descrie relaiile mate-
matice dependente de timp ale intrrilor, ieirilor i strilor sistemului, dup care se simuleaz acest
model pe o perioad de timp specificat.
SimMechanics ofer un set de instrumente pentru implementarea virtual a unor sisteme mecanice. De
fapt, SimMechanics este un mediu de modelare folosind diagrame bloc a proiectelor inginereti i de
simulare a micrii sistemelor compuse din corpuri rigide, care prezint diferite grade de libertate, au
anumite poziii, orientri i mase. El permite modelarea i simularea sistemelor mecanice folosind o
serie de unelte pentru specificarea corpurilor i a proprietilor lor, a micrilor posibile ale acestora, a
constrngerilor cinematice i a sistemelor de referin ataate, precum i iniializarea i msurarea mi-
crii corpurilor. Uneltele de vizualizare ale SimMechanics animeaz reprezentri simplificate ale sisteme-
lor 3D, nainte i n timpul simulrii, folosind sistemul grafic al MATLAB.
Folosind SimMechanics trebuie parcurse patru etape principale pentru construirea i rularea modelului
unui sistem:
specificarea proprietilor ineriale ale corpurilor, a gradele de libertate, a constrngerile i a sis-
temelor de referin ataate corpurilor necesare pentru msurarea poziiilor i a vitezelor;
stabilirea senzorilor i a elementelor de execuie pentru a nregistra i a iniia micrile corpuri-
lor i pentru a aplica fore sau cupluri;
pornirea simulrii prin apelarea elementelor specifice Simulink de rezolvare pentru a calcula
micrile sistemului, innd cont de toate constrngerile impuse;
vizualizarea i animarea simulrii folosind fereastra de vizualizarea SimMechanics.
Exemplul concret la care se va face referire n cele ce urmeaz prezint modelul unei mini umane pen-
tru studiul comportamentului cinematic al acesteia. Pentru o nelegere mai bun a modelului sunt ne-
cesare cteva precizri privind structura minii umane.
4.4.1 Studiul minii umane
Mna uman este compus din 27 de oase care sunt mprite n trei grupe: carpiene (oasele ncheietu-
rii), metacarpiene (oasele palmei) i falange (oasele degetelor), dup cum se poate observa n Fig. 1.66
(26), (27). Primele falange sunt conectate de oasele metacarpiene. Toate degetele au acelai numr de
falange (trei), exceptnd degetul mare care are doar dou. Oasele metacarpiene constituie palma i sunt
ataate oaselor carpiene. Micarea acestora din urm permite rotaia minii n raport cu braul. Oasele
metacarpiene prezint o asimetrie: o suprafa semisferic la contactul cu oasele carpiene i o suprafa
sferic pentru conectarea la primele falange.
Articulaiile minii se numesc: articulaia distal interfalangeal (DIP), articulaia proximal interfalangeal
(PIP) i articulaia metacarpofalangeal (MCP). Fiecare dintre ele este caracterizat de o anume geome-
trie a suprafeelor de contact i de un unghi maxim. Micrile minii sunt de diferite tipuri: fiecare deget

Pagina 80

se poate deplasa spre palm (aducie) i dinspre palm (abducie), se poate flexa sau extinde. Degetul
mare este capabil i s se mite n opoziie cu celelalte degete.

Fig. 1.66 Mna uman
Ligamentele din palm conecteaz oasele metacarpiene la cele carpiene. Ele pot bloca anumite micri
ale oaselor metacarpiene pentru a oferi o structur mai rigid palmei. Falangele sunt conectate prin
ligamente reduse.

Fig. 1.67 Tendoanele flexoare ale minii i tecile lor

Fig. 1.68 Muchi i tendoane ale palmei

Tendoanele conecteaz muchii i oasele, fiind ataate n mod diferit de acestea (Fig. 1.67, Fig. 1.68,
(28)). Intern, ele sunt fcute din colagen i sunt elastice, astfel nct sunt capabile s readuc degetele n
poziia original dup flexare. Ele sunt ataate diferit de oase i de muchi. Tendoanele superficiale
flexoare pornesc de la muchii antebraului (Fig. 2.12, (28)): de la primul nivel pornesc tendoanele ctre

Pagina 81

degetele inelar i mijlociu, de la nivelul al doilea, tendoanele ctre degetele mic i index. Dup conecta-
rea la falangele proximale, tendoanele se divid n dou i se conecteaz de o parte i de alta a falangelor
medii (Fig. 1.69, (28)). Ele mic, n secven, falanga median i apoi falanga distal.
Tendoanele de adncime pornesc tot de la antebra, se divid n patru i sunt ataate falagelor distale (Fig.
1.71, (28)). Ele flexeaz falangele distale dup ce tendoanele superficiale au nchis primele dou falange.
Degetul mare are doar un tendon flexor. Tendoanele extensoare pornesc de la un muchi din partea
superioar a antebraului i se divid n trei pentru a merge la degetele index, mijlociu i inelar. Degetul
mic este conectat la degetul inelar (Fig. 1.70, (28)).

Fig. 1.69 Tendoanele degetului inelar

Fig. 1.70 Muchii care acioneaz asupra degetului opozabil

a) muchi superficiali

b) muchi de adncime

c) muchi superficiali

d) muchi de adncime
Fig. 1.71 Muchi ai antebraului: a), b) partea interioar (cu podul palmei); c), d) partea exterioar


Pagina 82

Muchii umani pot aplica fore prin contractare. Muchii minii sunt mprii n trei grupe (28):
muchii degetului opozabil (Fig. 1.70), care ocup partea dinspre radius i produc eminena
tenar;
muchii degetului mic, care ocup partea dinspre ulna i produc eminena hipotenar (Fig. 1.68);
muchii care ocup zona central a palmei (Fig. 1.68).
n mn activeaz dou seturi de muchi: extrinsec, localizat n bra i intrinsec, localizat n mn. Mu-
chii intrinseci sunt responsabili de dexteritatea i de flexibilitatea minii. Tendoanele sunt meninute
aproape de oase prin intermediul unor teci (Fig. 1.67), care menin poziia tendoanelor relativ la falange,
pe linia de aciune a degetelor. Acestor teci se datoreaz, de fapt, aciunea fin a tendoanelor.
Tendoanele flexoare au rolul de a nchide degetele, cu scopul de a prinde obiectele, iar tendoanele ex-
tensoare au rolul de a deschide mna. Un tendon flexor acioneaz prin intermediul tecilor, de a lungul
articulaiilor, pentru a mica cele trei falange ale unui deget. Un muchi intrinsec ataat la falangele
proximale activeaz ca flexor al articulaiei metacarpofalangeal i ca extensor pentru articulaia
interfalangeal. Degetul opozabil este micat prin intermediul a opt muchi care acioneaz de a lungul
articulaiei de la baza sa (Fig. 1.70). Patru sunt extrinseci i acioneaz individual asupra articulaiei prin
intermediul unor tendoane lungi care traverseaz ncheietura nainte de a ajunge la degetul opozabil, iar
ceilali patru sunt intrinseci. Dintre cei opt muchi, ase acioneaz articulaia distal. Un tendon de
flexare conecteaz falanga distal la un muchi i transmite falangei fora produs de acesta.

Fig. 1.72 Seciune transversal prin muchi n zona ante-
braului

Fig. 1.73 Seciune transversal prin palm
Suprafaa articulaiilor i a tecilor (Fig. 1.67 (28)) care protejeaz tendoanele prezint un coeficient de
frecare foarte mic. n fiecare punct n care tendonul traverseaz spaiul unei articulaii acioneaz ca un
cuplu care are tendina de a flexa acea articulaie. La fiecare articulaie traversat de ctre un tendon,
schimbrile de poziie ale articulaiei utilizeaz o parte din potenialul excursiei muchiului. Dac un
muchi activeaz de a lungul mai multor articulaii, el trebuie s dispun de o capabilitate foarte mare
de micri. Muchii umani sunt optimi pentru strngere la flexare, nu pentru extensie. Astfel, exist mai
muli muchi flexori dect extensori, iar extensorii mpreun cu tendoanele lor sunt mai compaci i mai
puin puternici dect flexorii. (26)

Pagina 83

Muchii sunt elementele de execuie ale minii umane. Structura lor este destul de complex, fiind alc-
tuii din numeroase fibre (Fig. 1.72 (28)). Ei sunt ataai de oasele adiacente prin tendoane i induc mi-
care n articulaiile care se formeaz acolo unde dou oase se ntlnesc. Fibrele din care este compus un
muchi sunt grupate n uniti funcionale numite uniti motoare. O astfel de unitate motoare este
format din neuronul motor, axonul acestuia i din toate fibrele musculare care sunt ataate de acesta
pentru a primi semnalul de contractare. Un singur muchi poate avea mai multe uniti motoare.
Pe msur ce semnalul primit de la creier pentru contractare crete, se recruteaz noi uniti motoare i,
totodat, se crete frecvena de contractare la cele deja recrutate. Toate celulele musculare dintr-o uni-
tate motoare devin active n acelai timp. Variind numrul unitilor motoare active, corpul poate con-
trola fora contractrii musculare. Cnd un anumit motor se contract, acesta emite repetitiv cte un
scurt impuls de activitate electric, denumit potenial al unitii motoare n aciune (motor unit action
potential MUAP). Acesta poate fi detectat prin intermediul unor electrozi poziionai pe suprafaa
pielii, n apropierea motorului. (29)
Funcionarea muchiului poate fi modelat folosind dou componente de baz care acioneaz n paralel:
o component elastic i o component format dintr-o serie de elemente, unul elastic, unul contractil.
Prima component elastic se datoreaz esuturilor de conectare din jurul fibrelor, iar elementele elasti-
ce din componenta a doua se datoreaz tendoanelor. n funcie de sarcin, muchiul arat o cretere
exponenial n lungime. Cnd sistemul nervos trimite semnal de contractare, elementele contractile
ncep s se scurteze. Prile elastice din componenta a doua se lungesc ncet, astfel nct n tendoane se
nregistreaz o cretere uoar de tensiune. Cnd elementele contractile revin la poziia iniial, sunt
urmate, dup o scurt perioad, de elementele elastice. Viteza acestui fenomen depinde de forele
exercitate. Ea este ridicat cnd fora este nul (fr sarcin) i este foarte sczut cnd fora este ma-
xim. n cazul minii, muchii au nevoie de 80200 ms pentru a finaliza o contracie la vitez maxim.
Sarcina maxim pentru un muchi variaz ntre 25 kg/cm2. (26)
Fig. 1.74 Sistemul senzorial pentru muchi i tendoane
Sistemul senzorial al minii este de diferite tipuri, fiind prezeni esteroceptori i proprioceptori. Elemen-
tele de conversie sunt mecanice, electrice, fotoelectrice i termoelectrice. Un numr mare de receptori
trimit informaii continue despre deformarea muchilor i a tendoanelor sub aciunea forelor aplicate.
Multe dintre semnale nu sunt contientizate, dar ofer informaii despre poziia degetelor. Receptorii
sunt organizai n serii i n paralel cu fibrele musculare (Fig. 1.74) (26).

Pagina 84

Spre exemplu, organele Golgi sunt n serii cu fibrele musculare i sunt capabile s msoare deformarea
tendoanelor sub aciunea forelor. Terminaiile Ruffini din esuturile de conectare ale articulaiilor sunt
sensibile la flexare i la extensie (n mn exist foarte multe astfel de terminaii). Semnalele de atingere,
cldur, durere sunt generate de numeroi receptori din piele.
Sistemul biologic uman este condus de ctre sistemul nervos, alctuit din creier i mduva spinrii. La fel
ca n cazul tuturor vertebratelor, controlul micrii este distribuit n numeroase centre. Muchiul prime-
te impulsuri nervoase de la fibrele nervoase ale neuronilor motori. Aceste impulsuri sunt reglate de c-
tre semnalele de la receptorii periferici, pe de o parte, i de ctre centrele motoare din creier, pe de alt
parte. Aciunile reflexe depind doar de mduva spinrii. Cel mai simplu sistem biologic de control este
arcul reflex, care nu include activitatea encefalului i care prezint anumite caracteristici precum [45]:
timpul reflexului: timpul dintre apariia stimulului la receptor i apariia rspunsului. Pentru re-
flexe simple, acest timp este cuprins ntre 0,5 i 1,5 ms;
zona reflexului: zona n care sunt localizai receptorii responsabili de activarea reflexului;
pragul reflexului: valoarea minim a stimulului pentru a activa reflexul;
nsumarea reflexului: nsumarea mai multor stimuli din punct de vedere al intesitii i al zonei;
inhibarea reflexului: anumii neuroni sunt capabili s inhibe un reflex (spre exemplu, la realiza-
rea unei flexri a unui deget, muchii extensori sunt inhibai).
n funcie de receptorii implicai, reflexele pot fi esteroceptive sau proprioceptive. Reflexul proprioceptiv
cel mai important este reflexul miotatic, care pornete din fibrele neuromusculare. Acest reflex presu-
pune dou faze: o contracie rapid, urmat de o contracie lent i lung, care stabilizeaz muchii la o
anumit lungime. Reflexul miotatic invers pornete de la organele Gorgi, ajunge la centrii spinali unde
inhib neuronii motori ai muchiului corespunztor care este relaxat.
4.4.2 Constrngeri ale minii umane
Mna uman (Fig. 1.75 (30)) este un sistem foarte articulat, prezentnd 26 de grade de libertate. Siste-
mul mn uman este supus, ns, i la un numr mare de constrngeri, existnd dependene ntre de-
gete i articulaii. Pentru a modela articularea degetelor este necesar descrierea structurii cinematice a
minii umane. Din acest motiv, scheletul minii poate fi abstractizat precum n Fig. 1.76, n care fiecare
deget este considerat un lan cinematic cu baza n palm i cu fiecare vrf de deget drept efector final
(31).
Fiecare dintre cele patru degete are cte patru grade de libertate. Articulaiile distal interfalangeal (DIP,
marcat cu A n Fig. 1.75) i proximal interfalangeal (PIP, marcat cu B n Fig. 1.75) ofer fiecare cte un
grad de libertate, iar articulaia metacarpofalangeal (MCP, marcat cu C n Fig. 1.75) asigur dou grade
de libertate prin flexare i abducie (Fig. 1.77 (32)). Structura degetului opozabil este diferit de a celor-
lalte degete, el putndu se mica n opoziie cu acestea. Articulaiile interfalangeal (IP, marcat cu D n
Fig. 1.75) i MCP asigur cte un grad de libertate, iar articulaia carpometacarpian (CMC, marcat cu E
n Fig. 1.75) asigur dou grade de libertate prin flexare i abducie. Cele cinci degete ale minii au m-
preun 20 de grade de libertate. Cele 6 grade de libertate rmase se datoreaz micrilor de rotaie i
translaie ale palmei, cu cte trei grade fiecare.

Pagina 85

Micarea unui deget poate fi reprezentat printr un set de variabile articulare. Ea este supus unor
anumite constrngeri astfel nct, n final, mna nu poate realiza gesturi arbitrare. Spre exemplu, un
deget nu se poate ndoi foarte mult spre exteriorul minii, iar degetul mic nu poate fi ndoit fr a ndoi
i degetul inelar. Micarea natural a minii umane este, implicit, determinat de aceste constrngeri de
micare (31). Anumite constrngeri ale micrii minii umane au o reprezentare foarte clar, fiind foarte
des folosite n cercetrile curente legate de animarea sistemului mn. Cu toate acestea, majoritatea
constrngerilor de micare sunt foarte greu de exprimat printr o formulare matematic.
Constrngerile la care este supus mna uman pot fi divizate n trei mari categorii (31):
Constrngerile de tipul I sunt reprezentate de limitrile micrii unui deget datorate anatomiei
minii (constrngeri statice).
Constrngerile de tipul II sunt limitrile impuse n articulaii n timpul micrii (constrngeri di-
namice).
Constrngerile de tipul III includ acele limitri necesare pentru a realiza o micare natural, care,
ns, nu sunt acoperite de stadiul actual al cercetrii.

Fig. 1.75 Structura minii umane: 1) falanga distal, 2) falan-
ga medie, 3) falanga proximal, 4) os metacarpian, 5) ulna, 6)
radius
Fig. 1.76 Abstractizarea scheletului minii umane

Fig. 1.77 Articulaiile unui deget

Pagina 86

4.4.2.1 Constrngeri de tipul I
Aceste constrngeri se refer la limitrile domeniului de micri ale degetelor determinate de anatomia
minii. Se consider doar domeniul de micri care pot fi realizate fr aplicarea unor fore externe,
precum ndoirea degetelor spre partea exterioar a minii folosind cealalt mn. Acest tip de constrn-
geri se reprezint cu ajutorul urmtoarelor inegaliti (31):
0
MCP-F
90
0
PIP
110
0
DIP
90
-15
MCP-AA
15
unde:

MCP-F
reprezint variabila articular a articulaie metacarpofalangeale pentru flexare;

MCP-AA
reprezint variabila articular a articulaie metacarpofalangeale pentru abducie sau
aducie;

PIP
reprezint variabila articular a articulaiei proximal interfalangeale;

DIP
reprezint variabila articular a articulaiei distal interfalangeale.
O alt constrngere susine c degetul mic ofer o micare de abducie sau aducie redus, motiv pentru
care, pentru acest deget, se folosete urmtoarea aproximare (31):
MCP-AA
= 0
Aceast aproximare poate determina reducerea unui grad de libertate din cele 20 ale degetelor. De
asemenea, i articulaia CMC a degetului opozabil asigur o micare de abducie limitat, motiv pentru
care, de regul, ea se aproximeaz astfel (31):
CMC-AA
= 0
Drept rezultat, micarea degetului mare poate fi caracterizat de trei parametri n loc de patru. Pe lng
acestea, degetele index, mijlociu, inelar i mic sunt manipulatoare planare deoarece articulaiile DIP, PIP
i MCP ale fiecrui deget se mic ntr-un singur plan (articulaiile DIP i PIP ofer un singur grad de liber-
tate, pentru flexare).
4.4.2.2 Constrngeri de tipul II
Acest tip de constrngeri se refer la limitrile impuse n articulaii n timpul micrii degetelor. Ele sunt
denumite constrngeri dinamice i pot fi clasificate n constrngeri:
intra deget (ntre articulaiile aceluiai deget);
inter deget (ntre articulaiile dintre degete).

Pagina 87

Constrngerea intra deget cea mai utilizat se bazeaz pe anatomia minii i stipuleaz c, pentru a n-
doi articulaia DIP trebuie ndoit i articulaia PIP, pentru cazul degetelor index, mijlociu, inelar i mic
(Fig. 1.78 (27)). Din punct de vedere formal, afirmaia anterioar se exprim astfel (31):
DIP
= 2/3
PIP

Fig. 1.78 Relaia dintre articulaiile DIP i PIP
Datorit acestei aproximri, modelul care iniial avea 20 de grade de libertate se reduce la un model cu
16 grade de libertate. Literatura de specialitate a demonstrat faptul c degradarea de performan este
nesemnificativ n cazul exprimrii poziiei minii folosind constrngerile din relaiile anterioare. Un
exemplu de constrngere inter deget este urmtorul: ndoirea degetului mic din articulaia MCP deter-
min, n mod natural, i ndoirea degetului inelar din aceeai articulaie. Pn n prezent, ns, acest tip
de constrngeri nu au fost cuantificate sub forma unor ecuaii.

Fig. 1.79 Constrngerea flexrii n cazul articulaiei metacarpofalangeale

Pagina 88

4.4.2.3 Constrngeri de tipul III
Aceste constrngeri sunt impuse de modul natural n care se mic mna i sunt destul de dificil de de-
tectat. Constrngerile de tipul III difer de cele de tipul II prin faptul c ele nu au nicio legtur cu limit-
rile impuse de anatomia minii ci, mai degrab, ele reprezint un rezultat al micrilor naturale i comu-
ne. Dei naturaleea micrii minii difer de la persoan la persoan, ea este similar la toat lumea.
Spre exemplu, modul cel mai natural pentru orice persoan de a nchide pumnul const n ndoirea de-
getelor n acelai timp i nu cte unul pe rnd. De asemenea, la flexarea din articulaia metacarpian
atunci cnd degetele sunt flexate mpreun, trebuie redus aducia pentru a evita forarea degetelor
(Fig. 1.79) (27). Din pcate, pn n prezent, nici acest tip de constrngeri nu a fost cuantificat sub forma
unor ecuaii.
4.4.3 Modelul cinematic i modelul SimMechanics
Dup cum s a artat n paragrafele anterioare, modelarea corpului uman, n general, i a minii umane,
n particular, este un lucru dificil, care implic ntotdeauna anumite concesii. Astfel, modelul propus (Fig.
1.80) prezint cteva diferene fa de modelul natural, rezultate din necesitatea simplificrii procesului
de modelare. Palma a fost abstractizat sub forma unui dreptunghi cu lungimea p i limea 2d1 + d2.
Degetele centrale respect gradele de libertate i structura degetelor naturale, sunt paralele ntre ele i
plasate la distanele marcate pe Fig. 1.80. Degetul opozabil, n schimb, difer de modelul natural prin
faptul ca are doar dou falange i trei grade de libertate. Baza degetului opozabil este plasat la distana
d2 fa de palm, n planul palmei i distana d3, pe o ax perpendicular pe planul palmei. Baza celei de
a doua falange este plasat fa de baza degetului opozabil la distan d5, msurat pe o ax perpendi-
cular pe planul palmei.
Fig. 1.80 Modelul propus pentru mna uman
Pentru a putea modela micarea degetelor minii se folosete modelul cinematic direct (Fig. 1.81), care
exprim micarea vrfului fiecrui deget n raport cu sistemul de referin fix, ataat primei cuple cine-
d
3

d
5

p
p/2
d
1

d
2

d
2

d
1


Pagina 89

matice a ncheieturii. Pentru variabilele articulare comune tuturor degetelor,
1
q ,
2
q ,
3
q , s-au stabilit
constrngerile urmtoare, impuse de limitrile domeniului de micri ale degetelor, determinate de
anatomia minii:
90 90
1
q 2 / 2 /
1
q
15 15
2
q adic 12 / 12 /
2
q
15 15
3
q 12 / 12 /
3
q
Variabilele articulare specifice degetelor centrale,
4
q ,
5
q ,
6
q ,
7
q , dat fiind faptul c ele au aceeai
structur au valorile stabilite prin relaiile (2.54):
15 15
4
q 12 / 12 /
4
q
90 0
5
q adic 2 / 0
5
q
110 0
6
q 18 / 11 0
6
q
90 0
7
q 2 / 0
7
q
n ceea ce privete domeniile specifice variabilelor articulare ale degetului opozabil, acestea sunt expri-
mate astfel:
15 15
4o
q 12 / 12 /
4

o
q
90 0
5o
q adic 2 / 0
5

o
q
90 0
6o
q 2 / 0
6

o
q
Pentru a putea realiza studiul cinematic, este necesar s se atribuie valori tuturor mrimilor care apar n
sistemul cinematic determinat. Pentru aceasta, s-au considerat mrimile specifice unei mini de adult,
mrimi exprimate de relaiile urmtoare.
mrimi generale:
m cm p 1 , 0 10

m cm d 03 , 0 3
1

m cm d 02 , 0 2
2

m cm d 02 , 0 2
3

m cm d 03 , 0 3
5

degetul opozabil:
m cm f
o
035 , 0 5 , 3
1

m cm f
o
025 , 0 5 , 2
2


Pagina 90

degetul arttor:
m cm f
a
045 , 0 5 , 4
1

m cm f
a
03 , 0 3
2

m cm f
a
02 , 0 2
3

degetul mijlociu:
m cm f
m
05 , 0 5
1

m cm f
m
035 , 0 5 , 3
2

m cm f
m
025 , 0 5 , 2
3

degetul inelar:
m cm f
i
05 , 0 5
1

m cm f
i
035 , 0 5 , 3
2

m cm f
i
02 , 0 2
3

Fig. 1.81 Modelul cinematic al minii umane

q4l
q7m
q6m
q5m
q4m
q6o
q5o
q4o
q3
q2
q1
y
0
,z
2
, x
1
L
3
L
2
d
2
d
1
d
5
d
3
z
6m
7
L
1
p

a

x
3m,
x
4m
x
5m
x
6m,

z
dm
z
5m
z
4m
z
3m
f
3m
f
2m
f
1m
f
3l
f
2l
f
1l
f
2o
f
1o
x
3l
,x
4l
x
5l
x
6l,
x
dl
z
dl
z
6l
z
5l
z
4l
z
3l
x
do
,
z
6
z
5o
z
4
x
4o
,
z
3o
6
5
4
7
6
5
4
6
5
4
3
2
1
z
0
, x
2
z
1
, x
0
q5l
q6l
q7l

Pagina 91

degetul mic:
m cm f
c
04 , 0 4
1

m cm f
c
025 , 0 5 , 2
2

m cm f
c
02 , 0 2
3

Fig. 1.82 Modelul SimMechanics al minii umane
Schema rezultat (

Fig. 1.82) a fost implementat inndu-se cont de urmtoarele consideraii:
deoarece se studiaz doar micrile de deschidere i de nchidere ale pumnului, ncheietura este
rigidizat. Din acest motiv, n schem, ea este reprezentat printr-o articulaie rigid, de tip
Weld;
sistemul de referin fix se situeaz pe ncheietura minii, avnd axele orientate astfel: axa Ox
de-a lungul palmei, pe direcia degetului mijlociu, axa Oy perpendicular pe palm i axa Oz

Pagina 92

perpendicular pe celelalte dou i orientat astfel nct degetele mic i inelar s fie situate n
zona pozitiv;
palma este modelat folosind un bloc de tip Body, configurat conform cu Fig. 1.83. Sistemul de
referin al palmei (CS1) este acelai cu sistemul de referin fix. Fa de acesta, sistemele de re-
ferin ale degetelor sunt orientate astfel, pentru a respecta anatomia minii umane:
o sistemul de referin al degetului mijlociu (CS2) se afl la distana de 10 cm pe axa Ox
fa de sistemul fix (lungimea palmei), fr deplasri pe celelalte axe;
o sistemul de referin al degetului inelar (CS3) se afl la distana de 10 cm pe axa Ox i
de 3 cm pe Oz;
o sistemul de referin al degetului mic (CS4) se afl la distana de 10 cm pe axa Ox i
de 5 cm pe Oz;
o sistemul de referin al degetului arttor (CS5) se afl la distana de 10 cm pe axa Ox
i de -3 cm pe Oz;
Fig. 1.83 Configurarea blocului palm
sistemul de referin al degetului opozabil (CS6) se afl la distana de 5 cm pe axa Ox , de 3 cm
pe axa Oy i de -5 cm pe Oz.
micarea degetelor centrale are loc n jurul axei Oz, spre axa Oy , iar micarea degetului opo-
zabil se realizeaz n jurul axei Oy , spre axa Ox . Valorile pentru unghiurile de rotaie sunt ge-
nerate de ctre blocul denumit Comanda. n cazul degetului opozabil, s-a considerat c falanga
proximal realizeaz doar micare de aducie iar falanga distal acoper tot domeniul disponibil
pentru flexare;
curbele micrii sunt captate, pentru fiecare deget n parte, de ctre un bloc de tip Scope.

Pagina 93

Fig. 1.84 Structura degetelor centrale
Toate degetele centrale au aceeai structur, ceea ce difer este lungimea falangelor (Fig. 1.84). Fiecare
deget central este format din trei corpuri, legate ntre ele prin articulaii i reprezentate de blocurile de
tip Body, denumite Falanga3, Falanga2 i Falanga1. Micarea fiecrui corp este permis de cte o arti-
culaie cu unul sau mai multe grade de libertate. Deoarece aceast schem urmrete simularea micri-
lor de nchidere i deschidere a pumnului, micarea de aducie a fost exclus, astfel c articulaia
Articulatie3 asigur falangei proximale doar un singur grad de libertate (rotaie) fa de palm. Celelalte
falange sunt legate prin acelai tip de articulaii. Micarea are loc n jurul axei Oz.
Fiecare articulaie mobil trebuie comandat de ctre un bloc cu denumirea Joint Actuator. n cazul de
fa, avnd trei articulaii mobile, sunt necesare trei blocuri de comand: Comanda2, Comanda3 i Co-
manda4. Fiecare bloc de comand trimite articulaiei corespunztoare un unghi de rotaie, valoare asi-
gurat de blocul denumit Comanda n

Fig. 1.82.
Micarea vrfului degetului fa de sistemul de referin fix, este captat de blocul de tip Body Position
Sensor, sub forma proieciilor pe cele trei axe ale sistemului. Blocul Produs genereaz rezultanta micrii.
Curbele de micare obinute sunt afiate de ctre blocul de tip Scope, denumit Rezultate.
Fig. 1.85 Structura degetului opozabil
Spre deosebire de degetele centrale, degetul opozabil are o structur diferit (Fig. 1.85), prezentnd
doar dou falange. i n acest caz articulaia de la baz are doar un grad de libertate (renunndu-se la
micarea de flexare).

Pagina 94

Fiecare corp introdus n schem trebuie configurat corespunztor pentru ca modelul final s funcioneze
corect. Astfel, n Fig. 1.83 este prezentat fereastra de configurare a corpului Palma. Este permis speci-
ficarea masei corpului, a sistemului inerial, a poziiei sistemului de referin asociat corpului, a poziiei
centrului de greutate i a poziiei altor sisteme ataate corpurilor cu care acesta se nvecineaz, toate
fa de sistemul de referin fix (denumit World). De asemenea, se poate specifica i orientarea sisteme-
lor deja menionate fa de sistemul de referin fix. n cazul de fa, centrul de greutate este situat la
mijlocul palmei (la 5 cm fa de origine, pe axa Ox ), sistemul de referin al palmei este identic cu cel
fix, iar celelalte corpuri cu care este conectat palma se afl la distanele stabilite prin specificaiile de
proiectare. n aceeai manier se configureaz toate corpurile din model.

a)

b)

c)

d)

e)
Fig. 1.86 Curbele obinute la nchiderea pumnului

Pagina 95

Simulnd sistemul care descrie mna uman, conform cu consideraiile menionate, se pot obine curbe-
le de micare pentru cele dou situaii avute n vedere: nchiderea i deschiderea pumnului. Pentru n-
chiderea pumnului, se alimenteaz blocurile de acionare a articulaiilor cu valorile corespunztoare:
cresctoare, de la valoarea cea mai mic pn la valoarea cea mai mare a domeniului specific. Traiectori-
ile de micare ale vrfurilor degetelor sunt raportate la sistemul de referin fix i sunt prezentate n Fig.
1.86, unde imaginile corespund: a) degetului mic, b) degetului inelar, c) degetului mijlociu, d) degetului
arttor i e) degetului opozabil.
Simulink pune la dispoziia utilizatorului i un mediu grafic de vizualizare a modelelor simulate. Astfel,
Fig. 1.87 prezint cteva ipostaze din micarea de nchidere a pumnului, micare vzut din perspectiva
planului xOy , iar Fig. 1.88 prezint aceeai micare, dar tridimensional:
mna n poziia iniial, deschis (imaginea a));
poziii intermediare ale micrii (imaginile b) i c));
mna n poziia final, cu pumnul nchis (imaginea d)).

a)

b)

c)

d)
Fig. 1.87 nchiderea pumnului vedere din planul xOy


Pagina 96

a)

b)

c)

d)
Fig. 1.88 nchiderea pumnului imagine 3D
4.4.4 Conectarea la o lume virtual
Suita MATLAB ofer posibilitatea conectrii unei lumi virtuale, definit n VRML, la o schem Simulink,
prin Virtual Reality Toolbox. Aceast aplicaie este o soluie pentru interacionarea n timp cu modele
virtuale ale sistemelor dinamice. Sunt puse la dispoziia utilizatorului blocuri care s conecteze direct
semnalele Simulink la modelele virtuale, permind, astfel, vizualizarea modelului ca o animaie tridi-
mensional.
Pentru a asigura un mediu de lucru complet, Virtual Reality Toolbox include i dou componente adiio-
nale:
o aplicaie pentru vizualizarea lumilor virtuale
o aplicaie pentru implementarea lumilor virtuale, V-Realm Builder realizat de firma Ligos
Corporation.

Pagina 97

V-Realm Builder este o aplicaie foarte puternic i intuitiv, fiind uor de utilizat chiar i de ctre nespe-
cialiti, pentru a crea obiecte 3D i lumi n care acestea s fie vzute. Astfel, folosind facilitile puse la
dispoziie de acesta a fost realizat un model al minii umane (Fig. 1.89), respectnd considerentele
enunate la realizarea modelului cinematic: degetele centrale au aceeai structur, fiind diferite doar
lungimile falangelor componente, iar degetul central este compus doar din dou falange, avnd o pozii-
onare prestabilit fa de palm.
Fig. 1.89 Modelul minii umane realizat cu Virtual Reality Builder
Acest model poate fi conectat la modelul realizat n Simulink pentru a obine datele necesare n scopul
controlrii i animrii lumii virtuale. Conexiunea se realizeaz prin intermediul unui bloc VR Sink adugat
la schema Simulink (Fig. 1.90), bloc care preia datele din Simulink i le transmite lumii virtuale. Pentru a
realiza efectiv conexiunea, trebuie specificat fiierul care conine modelul virtual n fereastra Parameters
a blocului VR Sink (Fig. 1.91). Acest lucru are ca efect apariia n caseta din partea dreapt a ferestrei a
unei ierarhii VRML care prezint structura modelului virtual. Cum din Simulink se vor transmite unghiuri-
le de rotaie, se vor bifa toate csuele corespunztoare rotaiilor falangelor, ceea ce va determina mar-
carea acestora pe caseta extern a VR Sink drept ieiri (Fig. 1.90).
n lumea virtual, rotaia este definit ca un vector cu patru elemente. Primele trei precizeaz axa de
rotaie (spre exemplu, dac rotaia se face n jurul axei Oz, atunci vor fi de forma [0 0 1]), iar ultimul re-
prezint valoarea unghiului de rotaie. Pentru transmiterea unei poziii (translaie) este necesar un vec-
tor cu trei elemente, de forma [x, y, z]. Dup realizarea conexiunilor care se impun, se pornete simula-
rea modelului i mediul de vizualizare permite urmrirea animrii modelului virtual. Fig. 1.92 prezint
patru ipostaze din flexarea minii.

Pagina 98

Fig. 1.90 Modelul Simulink al minii conectat la un model virtual

Fig. 1.91 Stabilirea modelului virtual cu care se lucreaz i a conexiunilor necesare

Pagina 99

Fig. 1.92 Flexarea minii folosind realitatea virtual


Pagina 100

5 Bibliografie

1. Mayers, Brad A. Taxonomies of Visual Programming and Program Visualization. Pittsburgh : Carnegie
Mellon University, 1989.
2. Direct Manipulation Systems. [Online] http://www.gale.cengage.com/pdf/samples/sp655664.pdf.
3. Boshernitsan, M., Downes M. Visual Programming Languages: A Survey. Berkeley : University of
California, 2004. UCB/CSD-04-1368.
4. Burnett, Margaret M. Visual Programming. Encyclopedia of Electrical and Electronics Engineering.
1999.
5. Tanimoto, S. VIVA: a visual language for image processing. Journal of Visual Languages Computing
2(2). 1990, Vol. 2, 2.
6. Heterogeneous visual languages : Integrating visual and textual programming. Meyer, M., Erwig B.
s.l. : 1995 IEEE Symposium Visual Languages, 1995.
7. Chang, S.-K. Principles of Visual Programming Systems. New York : Prentice Hall, 1990.
8. Rhor, G. Using visual concepts. [book auth.] S.-K., Ichikawa, T., and Ligomenides, P. Chang. Visual
Languages. New York : Plenum Press, 1986.
9. Tortora, G. Structure and interpretation of visual languages. [book auth.] S.-K. Chang. Visual
Languages and Visual Programming. New York : Plenum Press, 1990.
10. Lakin, F. Spatial parsing for visual languages. [book auth.] S.-K., Ichikawa, T., and Ligomenides, P.
Chang. Visual Languages. New York : Plenum Press, 1986.
11. Golin, E. J. A method for the specication and parsing of visual languages. PhD dissertation. s.l. :
Brown University, 1990.
12. Kurlander, D.J. Graphical editing by example in Chimera. [Online] Columbia University.
http://kurlander.net/DJ/Pubs/PBEBookChap12.PDF.
13. Burnett, Margaret. Forms/3. [Online]
http://web.engr.oregonstate.edu/~burnett/Forms3/forms3.html.
14. David Heise, Tomas Joyner. Prograph: A Visual Programming Language. [Online]
http://students.cs.byu.edu/~dheise/cs330/Prograph_final_report.pdf.
15. Hayes-Roth, F. Rule-based systems. Communications of the ACM. 1985, Vol. 28, 9.

Pagina 101

16. Smith, Allen Cypher and David Canfield. KIDSIM: END USER PROGRAMMING OF SIMULATIONS.
[Online] http://www.sigchi.org/chi95/proceedings/papers/ac1bdy.htm.
17. Visual programming in 3-d. Najork, M. 12, s.l. : Dr. Dobbs Journal, 1995, Vol. 20.
18. MArk A. Najork, Simon M. Kaplan. A Prototype Implementation of the CUBE Language. [Online]
http://www.google.ro/url?sa=t&rct=j&q=a%20prototype%20implementation%20of%20the%20cube%20
language&source=web&cd=1&sqi=2&ved=0CBkQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fvie
wdoc%2Fdownload%3Fdoi%3D10.1.1.67.7089%26rep%3Drep1%26type%3Dpdf&ei=222pTr3gC.
19. Petri Nets and Industrial Applications: A Tutorial. Zurawski, R., Zhou, M.C. 6, s.l. : IEEE
TRANSACTIONS ON INDUSTRIAL ELECTRONICS, 1994, Vol. 41.
20. Android operating system. Wikipedia. [Online]
http://en.wikipedia.org/wiki/Android_(operating_system).
21. What is Android? Android developers. [Online] http://developer.android.com/guide/basics/what-is-
android.html.
22. Varban, G. Wall-Street.ro. [Online] http://www.wall-street.ro/articol/IT-C-
Tehnologie/86693/Android-ar-putea-deveni-pentru-telefoane-ceea-ce-e-Windows-pentru-PC-uri.html.
23. Google App Inventor. Wikipedia. [Online] http://en.wikipedia.org/wiki/App_inventor.
24. Reference Documentation. App Inventor. [Online] http://appinventor.mit.edu/explore/support.html.
25. Simulink. MatWorks. [Online] http://www.mathworks.com/products/simulink/description1.html.
26. Blackfingers: an Artificial Hand that Copies Human Hand in Structure, Size, and Functions. M.
Folgheraiter, G. Gin. s.l. : MIT, Cambridge, Mass,, 2000.
27. A Hand Control and Automatic Grasping System for Synthetic Actors. R.M. Sanso, D. Thalmann. Oslo :
s.n., 1994.
28. Grays Anatomy of the Human Body, The Bartebly.com Edition. [Online]
http://education.yahoo.com/reference/gray/.
29. Feature Extraction for Classification of Prehensile Electromiography Patterns. Du, S. s.l. : San Diego
State Universit, 2003.
30. Human Hand Modeling from Surface Anatomy. T. Rhee, U. Neumann, J.P. Lewis. s.l. : Acm
SIGGRAPH Symposium on Interactive 3D Graphics and Games, 2006.
31. Modeling the Constraints of Human Hand Motion. J. Lin, Z. Wu, T.S. Huang. Maryland : Proc. of 5th
Annual Federated Laboratory Symposium, 2001.

Pagina 102

32. Development of a Robot Finger for Five Fingered Hand using Ultrasonic Motors. I. Yamano, K.
Takemura, T. Maeno. Las Vegas : Intl. Conference on Intellingent Robots and Systems, 2003.

Programare Vizuala Si Modelare

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Programare Vizuala Si Modelare

Uploaded by

Copyright:

Available Formats

Programare Vizual i

You might also like