Programare Vizuala

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 CLASIfiCAREA 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 demonstrație ................................................................. 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 REȚELE PETRI (19) ................................................................................................................ 28

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

2.2 DESCRIEREA REȚELELOR PETRI ................................................................................................................................. 30

2.3 PROPRIETĂȚI ALE REȚELELOR 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 ecuația de stare .................................................................................................. 41

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

2.5 REȚELE 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 Evoluția sistemului Android și impactul său 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 Capacități și limitări ..................................................................................................................................... 54

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

3.2.4 Selectarea componentelor pentru crearea de aplicații ............................................................................. 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 aplicații 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 mâinii umane ................................................................................................................................... 79

4.4.2 Constrângeri ale mâinii 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 convenționale sunt dificil de învățat și folosit, necesitând abilități pe care foar-

te mulți oameni nu le au. Din acest motiv, interfețele cu utilizatorul de la o gamă largă de programe au

început să vină cu facilități care să suplinească și să ușureze capabilitățile de programare. Spre exemplu,

succesul foilor de calcul poate fi parțial atribuit abilității utilizatorilor de a scrie programe (sub formă de

colecții de „formule“).

Pe măsură ce distribuția de calculatoare personale a crescut, foarte mulți utilizatori au ajuns să dețină

unul, fără ca marea majoritate să aibă cunoștințe în a scrie programe. Ei cumpără calculatoarele și pa-

chetele software fără să fie capabili să aducă o modificare cât de mică software-ului. Pentru a permite

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

opțiuni, fapt care ar putea induce transformarea sistemului într-unul și mai complex fără să rezolve pro-

blemele utilizatorului. Sisteme software ușor de utilizat, precum sistemele de manipulare directă (Direct

Manipulation) nu fac decât să mărească distanța dintre utilizator și programator în condițiile în care

codul este mult mai complicat (din cauza suplimentului necesar manipulării interfețelor pentru utiliza-

tor), chiar dacă mai mulți utilizatori vor putea folosi software-ul (fiind ușor 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 făcut numeroase eforturi pentru a pune în valoare abilitatea umană de a procesa informații

vizuale. Spre exemplificare, se poate considera următoarea situație: un om poate urmări pe ecranul

televizorului o imagine și să discearnă un șablon constând în milioane de pixeli pe secundă, care se mo-

difică în timp și spațiu. Dacă, însă, privește imaginea din Fig. 1.1 (2), probabilitatea este aproape nulă ca

cineva să deslușească șablonul reprezentat de următorul 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, așa 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ă persistăm î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

minţii noastre atunci când ne gândim la soluţiile unor probleme speciale? Evident, susţinătorii limbajelor

de programare vizuală susţin că răspunsul la ambele întrebări este afirmativ.

Fig. 1.2 Puncte

Întrebările de mai sus subliniază motivarea principală a cercetării în limbajele de programare vizuală. În

primul rând, majoritatea oamenilor gândesc și își amintesc lucrurile în imagini. Ei se referă la lumea în-

conjurătoare într-un mod grafic și folosesc imaginile drept componente principale în gândirea creatoare.

Reducând sau înlocuind în totalitate necesitatea traducerii ideilor vizuale în reprezentări textuale artifi-

ciale poate ajuta la diminuarea problemelor de învățare. Mai mult, numeroase aplicații 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 informație. Exemple de astfel de dimensiuni adiționale sunt: folosirea obiectelor multi-dimensionale,

folosirea relaționărilor spațiale, sau folosirea dimensiunii timp pentru specificarea relațiilor semantice de

tip „înainte–după”. Fiecare multi-dimensional sau relație este un jeton (token), așa cum în limbajele de

programare textuală tradiționale fiecare cuvânt este un jeton. O colecție de unul sau mai multe astfel de

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

grame, schițe, icoane sau demonstrații de acțiuni realizate cu obiecte grafice. Atunci când sintaxa unui

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

programare este un limbaj de programare vizuală (LPV).

Deși limbajele de programare textuală tradiționale 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 spațierea opțională a liniilor în document — doar una dintre aceste dimensiuni

transmite semantică, pe când cea de-a doua dimensiune a fost limitată la o informație legată de tastarea

relațiilor spațiale astfel încât să poată fi exprimate într-o gramatică unidimensională. Astfel, multidimen-

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

Când 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ă tradiționale reprezintă o trecere între

LPV-uri și cunoscutele limbaje textuale. Spre deosebire de acum câțiva ani, când mediile de programare

strict textuale și în linie de comandă reprezentau normalul, astăzi MPV-urile pentru limbajele textuale

tradiționale au preluat controlul în lumea programatorilor. MPV-urile comerciale pentru limbajele tradi-

ționale sunt gândite pentru programatorii de profesie. Acești programatori folosesc limbajele textuale

pe care le cunosc deja și sunt ajutați de tehnici de interfațare grafică cu utilizatorul și de nivelul de acce-

sibilitate al informației pe care metodele vizuale îl pot aduce. MPV-urile pentru limbajele tradiționale


Pagina 6

reprezintă o modalitate de a transfera avansurile datorate cercetării din LPV-uri în practică prin aplicarea

acestor noi idei limbajelor tradiționale deja familiare programatorilor. În acest fel se permite migrarea

graduală de la tehnicile de programare textuale către cele vizuale. (4)

1.2 Istoric

Programarea vizuală a apărut din combinarea graficii pe calculator, a limbajelor de programare și a inte-

racțiunii om-calculator. Nu este o surpriză, deci, faptul că dezvoltările din programarea vizuală au repre-

zentat avansuri în unul dintre aceste domenii. Sistemul revoluționar 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 aplicație 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 operații (precum copierea) și a unor constrângeri asupra geometriei formelor.

Interfața sa grafică și suportul pentru specificarea constrângerilor de către utilizator reprezintă contribu-

țiile cele mai importante ale lui Sketchpad la dezvoltarea LPV-urilor. Prin definirea constrângerilor potri-

vite, utilizatorii puteau realiza structuri complexe precum legături mecanice complicate și să le miște în

timp real. Fratele lui Ivan SUTHERLAND, William, a adus, de asemenea, o contribuție importantă la dez-

voltarea programării vizuale în 1965, când 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.

Următorul 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 câteva direcții de cercetare în acest domeniu care continuă și în ziua de as-

tăzi. 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 proprietăți definite pentru a

realiza calcule. De atunci s-au adus multe îmbunătățiri 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 arăta sistemului cum să

realizeze o sarcină într-o situație specifică, iar sistemul folosea această informație 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 ieșire un program care realiza calcu-

le asupra unor intrări arbitrare. (3)

Inițial, dezvoltarea programării vizuale a avut loc în două direcții: abordări vizuale asupra limbajelor de

programare tradiționale (precum diagramele executabile de fluxuri de date) și noi abordări vizuale de

programare care s-au depărtat semnificativ de abordările tradiționale (precum programarea prin de-

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

păreau interesante și intuitive când au fost utilizate pe programe “jucărie”, dar care au indus probleme

dificile când s-a încercat extinderea lor în programe realiste. Aceste probleme au dus la o “decădere”


Pagina 7

incipientă a programării vizuale, făcându-i pe mulți să creadă că programarea vizuală este nepotrivită

pentru industrie, fiind doar un exercițiu academic.

Pentru a depăși aceste probleme, cercetătorii din domeniul vizual au început să dezvolte căi de folosire a

programării vizuale doar în anumite domenii software, crescând astfel numărul 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 specificațiile textuale din interfețele grafice pentru utilizator

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

și/sau vizualizarea relaționărilor dintre structurile de date

folosite pentru a combina vizual unitățile programate textual pentru a construi noi programe

În curând 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ă specificații vizuale (spre exemplu, folosind diagrame) ale rela-

țiilor dintre modulele programului, culminând prin generarea automată a codului.

Alți cercetători 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 numărul proiectelor care pot fi programate vizual. Un beneficiu imediat a fost creşterea

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

meniilor specifice pentru LPV şi MPV au descoperit că, găsind modalităţi de a scrie programe pentru

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

iniţiale, 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ă obligaţi să părăsească

acel stil de comunicare. Această abordare a dat rezultate atât în cercetare, cât şi pe piaţă. Astăzi există

LPV-uri şi MPV-uri pentru diverse domenii: programarea achiziţiilor de date de laborator (LabView de la

National Instruments), programarea vizualizărilor specifice (AVS de la Advanced Visual Systems), pro-

gramarea telefoniei şi a mail-ului de voce (PhonePro de la Cypress Research) şi programarea simulărilor

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

tware încep să fie incluşi în software-ul pentru calculatoarele personale, permiţând ca macro comenzi

care ajută cu sarcini repetitive să fie deduse prin manipulările utilizatorului final (ca în Chimera, de

exemplu).

Încercarea iniţială — 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 cercetări îl reprezintă îmbunătăţirea continuă a modalităţilor prin care programarea vizuală poa-

te fi folosită. Un alt scop este acela de a asigura aceleaşi modalităţi de îmbunătăţire în dezvoltarea sof-

tware în general, precum cele deja disponibile pentru programarea unor domenii specifice. Deşi toate


Pagina 8

acestea sunt încă la nivel de cercetare, au apărut 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 priveşte cercetarea în programarea vizuală în general şi în LPV în particular, există o părere

greşită precum că acestea au drept scop eliminarea textului. În fapt, majoritatea LPV-urilor includ text

într-o oarecare măsură într-un context multidimensional. Scopul lor este de a aduce îmbunătăţiri desig-

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

au mai puţine restricţii sintactice privind modul în care un program poate fi exprimat (de către calculator

sau de către om), situaţie ce oferă o libertate de a explora mecanismele programării 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 audienţe particulare

îmbunătăţi corectitudinea cu care oamenii realizează sarcini de programare

îmbunătăţi 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

instanțe particulare. Spre exemplu, unui programator i se permite specificarea unor aspecte se-

mantice privind un obiect sau o valoare specifice, sau sistemul să poată afișa în mod automat

efectele unui porțiuni din program asupra unui obiect sau valori specifice.

Direct: în contextul manipulării directe, această strategie este descrisă ca fiind “sentimentul pe

care îl are cineva manipulând direct un obiect”. Din perspectivă cognitivă, direct în calculatoare

înseamnă o distanță cât mai mică între scop și acțiunile 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), fără necesitatea ca programatorul să le specifice. Un exemplu îl reprezintă sis-

temul care generează explicit relaționări între fluxurile de date (sau părți din program) prin de-

senarea unor arce direcționale între variabilele relaționate ale programului.

Răspuns vizual imediat (feedback vizual): în contextul programării vizuale, acest deziderat pre-

supune afișarea imediată a efectelor produse prin editarea programului. Tanimoto (5) a introdus

termenul de liveness (adaptat în limba română ca “timp de răspuns”), termen care caracterizea-

ză cât de imediat este răspunsul semanticii oferit în mod automat pe parcursul procesului de

editarea a programului. Tanimoto descrie patru niveluri de timp de răspuns:


Pagina 9

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

torului. Un exemplu în acest sens îl reprezintă diagramele de tip entitate-relaționare

pentru documentație.

o Nivelul 2: programatorul poate să obțină răspuns despre o porțiune a programului, dar

acest răspuns nu este automat. Compilatoarele suportă minimal acest nivel, iar interpre-

toarele ceva mai mult deoarece nu sunt restricționate doar la valorile finale de ieșire.

o Nivelul 3: un răspuns semantic incremental este asigurat în mod automat de fiecare da-

tă când programatorul realizează o editare incrementală a programului, caz în care toate

valorile afișate pe ecran și afectate de modificare sunt retipărite automat. Aceasta asi-

gură consistența dintre starea afișată și starea sistemului dacă singura acțiune care de-

termină schimbarea stării sistemului este editarea programului. Facilitatea de recalcula-

re automată a foilor de calcul tabelar suportă acest nivel de timp de răspuns.

o Nivelul 4: sistemul răspunde la editările 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-

rând în orice moment acuratețea dintre datele afișate și starea curentă a sistemului pe

tot parcursul rulării.

1.4 Clasificarea Limbajelor de Programare Vizuală

Pe măsură ce domeniul LPV a început să se maturizeze, a apărut interesul creării unei clasificări standard

și robuste pentru tot ce s-a descoperit. O astfel de clasificare nu este de interes doar pentru cercetători,

care vor putea găsi mai ușor lucrări asemănătoare, ci asigură și o bază pentru compararea și evaluarea

diferitelor sisteme. Această clasificare se datorează unor nume importante din domeniu, incluzând pe

Chang, Shu sau Burnett, care s-au străduit să identifice caracteristicile care definesc principalele catego-

rii de LPV. Următoarea 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 constrângeri

Sisteme bazate pe formulare

În fapt, aceste categorii nu sunt mutual exclusive, numeroase limbaje putând 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 reprezentări grafice pentru a-și crea programul care, apoi,

este depanat și executat în același 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 secțiuni precum limbaje cu icoane și fără icoane, orientate pe obiect, funcționale și imperative.

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

de sisteme hibride include atât sistemele în care programele sunt create vizual și apoi translatate într-un

limbaj textual de nivel înalt, cât și sistemele care folosesc elemente grafice într-un limbaj textual. Exem-

ple din această categorie includ Rehearsal World și rezultatul cercetării 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 soluției.

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ă înlănțuită, după care se realizează

asupra listei operații (precum ștergerea unui nod) prin desenarea pașilor în cadrul procesului.

Pe lângă aceste două categorii majore, numeroase LPV-uri sunt clasificate într-o varietate de ramificații.

Spre exemplu, o parte dintre LPV-uri se aseamănă cu Pygmalion, permițând utilizatorului să creeze și să

manipuleze obiecte grafice cu care să “învețe” 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 constrângerilor, creată de Sutherland în Sketchpad. Aceste sis-

teme orientate pe constrângeri sunt populare pentru design de simulare, în care programatorul mode-

lează obiectele fizice ca obiecte ale mediului vizual cărora li se impun constrângeri gândite să copieze

comportamentul legilor naturale (precum gravitatea). De asemenea, sisteme orientate pe constrângeri

se mai folosesc și în dezvoltarea de interfețe grafice pentru utilizatori. Thinglab și ARK, ambele LPV-uri

de simulare, reprezintă exemple de limbaje bazate pe constrângeri.

Câteva 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 înțeleg programarea ca

modificarea în timp a unui grup de celule interconectate, deseori permițând programatorului să vizuali-

zeze execuția programului ca pe o secvență de stări diferite ale celulelor care progresează în timp.

Form/3 este un exemplu de astfel de LPV. Este important de evidențiat faptul că în fiecare dintre catego-

riile menționate anterior se pot găsi atât exemple de LPV-uri de uz general, cât și limbaje speciale pentru

aplicațiile unor anumite domenii.

Domeniul programării vizuale s-a dezvoltat foarte mult în ultimii ani. Dezvoltarea continuă și rafinarea

limbajelor din categoriile menționate mai sus au dus la unele rezultate care au fost inițial considerate ca

făcând 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 execuției programelor și unelte de dez-

voltare a interfețelor 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ă, aplicații grafice sau generatoare de șabloane decât limbaje de programare. (3)


Pagina 11

1.5 Teoria Limbajelor de Programare Vizuală

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

sară prezentarea câtorva definiții (7):

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

zică (imaginea).

sistem iconic: un set structurat de icoane relaționate.

propoziție iconică (propoziție vizuală): o aranjare spațială a icoanelor pentru sistemul iconic.

limbaj vizual: un set de propoziții iconice construit pe baza unei sintaxe și a unei semantici date.

analiză sintactică (analiză spațială): analiza unei propoziții iconice pentru determinarea structu-

rii de bază.

analiză semantică (interpretare spațială): analiza unei propoziții iconice pentru determinarea

sensului de bază.

Detaliile care urmează sunt restrânse 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 spațial care constituie o propoziție vizuală reprezintă omologul bidimensional al unui

aranjament unidimensional de jetoane în limbajele de programare convenționale (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 propoziție ale cărei structură și sens sunt determinate prin analiză sintactică și

semantică. Astfel, regula de construcție este implicită în limbaj și nu trebuie să fie precizată explicit ca

parte a specificațiilor limbajului. Invers, în limbajele de programare vizuală se disting trei reguli de con-

strucție care sunt folosite pentru aranjarea icoanelor: concatenare orizontală (notată cu &), concatenare

verticală (notată cu ^) și suprapunere spațială (notată cu +).

Pentru a putea formaliza limbajele de programare vizuală, trebuie făcută distincția 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 spațială a icoanelor obiect elementare). De fapt, termenul icoane elementare se referă

atât la icoanele de proces, cât ș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ă câteva icoane din setul de icoane Heidelberg (8) și o propoziție

vizuală completă.

Un limbaj de programare vizuală este specificat de o tripletă de forma (DI,G0,B), unde DI este dicționarul

de icoane, G0 este gramatica și B este o bază de cunoștințe specifică unui anumit domeniu (9). Dicționa-

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

spațială. Trebuie remarcat faptul că este obligatorie specificarea acestor operatori spațiali de compoziție


Pagina 12

ca elemente terminale deoarece ei nu mai fac parte implicit din definirea limbajului. Baza de cunoștințe

B conține informații specifice domeniului necesare pentru construirea sensului propoziției vizuale dorite.

Aceasta conține informații privind numele evenimentelor, relații conceptuale, numele obiectelor rezul-

tate și referințele la obiectele rezultate.

Fig. 1.3 Câteva icoane din setul Heidelberg. Icoane obiect elementare: (a) un caracter şi (b) un caracter selectat. Icoane de proces: (c) operaţia de inserţie şi (d) operaţia 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). Propoziţie vizuală (g) reprezentând înlocuirea unui subşir într-un şir.

1.5.2 Analiza Limbajelor de Programare Vizuală

Propoziţiile vizuale sunt construite din icoane elementare cu ajutorul operatorilor iconici. Analiza sintac-

tică a propoziţiilor vizuale (cunoscută şi sub denumirea de analiză spaţială (10)) se bazează pe câteva

abordări (7):

Gramatici pentru procesarea imaginilor: iniţial gândite pentru distribuirea imaginilor digitale pe

o reţea de pătrate, aceste gramatici se bazează pe faptul că imaginile digitale sunt compuse din

pixeli. Aceste gramatici descoperă structura unei propoziţii vizuale compunând pixelii în elemen-

te vizuale recognoscibile (linii, arce etc.) (11). Această metodă este folositoare când un sistem

iconic trebuie să recunoască icoane cu o anumită toleranţă de eroare (spre exemplu, digiţi din

scrisul de mână).

Gramatici de precedenţă: aceste gramatici de analiză spaţială pot fi folosite pentru analiza ex-

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

ziţiilor vizuale construite din icoane elementare şi operatori iconici. Arborele de analiză este


Pagina 13

construit prin compararea precedenţei 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 compoziţia propoziţiile vizuale folosind formalisme cunoscute.

Gramatici gen graf: acestea sunt, de departe cele mai puternice (deşi mai puţin eficiente) speci-

ficaţii ale limbajelor vizuale. Aceste formalisme prevăd cele mai multe mijloace pentru stabilirea

unor relaţii contextuale și mare parte din cercetarea recentă în acest domeniu a fost dedicată

încercării de a face analiza cu gramatici de acest tip fezabile din punct de vedere computațional.

Arborele de analiză determinat printr-una dintre metodele enunțate anterior este analizat ulterior folo-

sind metode tradiționale de analiză semantică.

1.6 Problemele limbajelor vizuale

În cele ce urmează vor fi prezentate câteva dintre problemele comune ale limbajelor vizuale (4). Aceste

probleme se întâlnesc mai ales în limbajele vizuale de uz general (potrivite pentru a genera programe

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

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

ințifică).

1.6.1 Controlul fluxului

La fel ca în limbajele de programare convenționale, 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 secvențierea operațiilor modifică starea programului, ceea ce nu es-

te o caracteristică dorită pentru sistem (mai ales dacă este destinat unor începători)

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 stării este evitată prin folosirea atribuirii singulare: programatorul creează un nou obiect

prin copierea unuia existent și precizarea diferențelor dorite și nu prin modificarea stării obiec-

tului existent. De asemenea, în loc să specifice o secvență de modificării ale stării, programatorul

definește operații prin specificarea dependențelor dintre obiecte. Spre exemplu, dacă progra-

matorul definește Y ca X+1, atunci această formulare, de fapt, stabilește explicit că Y trebuie cal-

culat folosind obiectul X, iar sistemul înțelege că valoare lui X trebuie calculată prima. Astfel, în-

că este prezentă secvențierea operațiilor, dar ea trebuie dedusă de către sistem și nu definită de

programator. În acest caz, sistemul are de rezolvat problema dependențelor 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 menținerea 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 întâlnită în diverse sisteme orientate pe un anumit

domeniu, precum uneltele de mentenanță software și mediile de vizualizare științifică. De cealaltă parte

sunt limbajele vizuale de nivel scăzut 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

facilități de programare, pornind de la proprietăți de nivel scăzut (incluzând condiționările, recursivitatea,

iterația) la proprietăți de nivel ridicat care permit combinarea logicii de nivel scăzut în module abstracte

(proceduri, clase, biblioteci etc.).

1.6.3 Abstractizarea datelor

Facilitățile de abstractizare a datelor sunt întâlnite doar în limbajele de programare de uz general. Noți-

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

convenționale, 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ă secțiune vor fi prezentate câteva exemple de LPV-uri pentru a demonstra câteva modalități

prin care au fost implementate strategiile prezentate anterior.

1.7.1 Chimera. Programarea vizuală imperativă prin demonstrație

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

punerea programatorului să își demonstreze acțiunile 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 îmbunătățirii nivelului de accesibilitate al programării anumitor tipuri

de sarcini.

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

te constata apariția unor sarcini de editare repetitive, caz în care poate indica o secvență de manipulări

tocmai realizate asupra unei scene ca putând fi generalizate și tratate ca un macro. Acest lucru este po-

sibil deoarece istoricul acțiunilor utilizatorului este prezentat folosind o tehnică de benzi desenate, iar

utilizatorul poate selecta paneluri din istoric. Istoricul folosește același limbaj vizual ca interfața, deci

utilizatorul le va înțelege fără probleme. Spre exemplu, Fig. 1.4 a) prezintă o ilustrație conținând două

pătrate și o săgeată. Istoricul generat prin crearea ilustrației 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 înfățișează 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 împărțit pentru a vizualiza

atât partea de control, cât și partea de editare. Următoarele paneluri prezintă modificări ale grosimii și

culorii marginii dreptunghiului, adăugarea unei linii paralelă cu dreptunghiul și a încă două linii deasupra

acesteia pentru a forma o săgeată. A doua parte a istoricului înfățișează adăugarea unui nou dreptunghi,

tragerea săgeții până la acest dreptunghi, rotirea săgeții pentru a-i alinia baza cu primul dreptunghi și, în

final, întinderea săgeții pentru a atinge primul dreptunghi.

Fig. 1.5 Programarea prin demonstrație în Chimera. În acest exemplu, utilizatorul a desenat o cutie cu o săgeată indicând spre ea (ca într-o diagramă), iar această demonstrație este prezentată după realizarea ei printr-o serie de paneluri. Acest set de demonstrații poate fi generalizat într-un macro pentru utilizarea sa ulterioară.

Pentru a face istoricele mai scurte și mai simplu de înțeles, se folosesc mai multe strategii. Mai multe

operații înrudite se unesc într-un singur panel. Spre exemplu, panelul doi conține mai multe operații:

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

lui indică numărul de comenzi pe care le reprezintă și poate fi desfăcut 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 încărcat, fiecare panel arată doar obiectele care participă în operațiile sale și contextul adiacent


Pagina 16

cu el al scenei. Obiectele în panel sunt distribuite conform cu rolul pe care îl au în explicație. 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 operații adăugate în istoric

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

do) sau reluarea (redo) unei secvențe din aceste operații. Pentru exemplul din Fig. 1.4, se dorește 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 evidențiate cu etichete albe pe fundal negru. În pasul următor se apelează operația

Redo-Selected-Panels, iar dreptunghiul de sus se va modifica în mod corespunzător.

Istoricele grafice editabile din Chimera reduc repetiția prin faptul că oferă o interfață pentru operația de

reluare a operațiilor. Chimera are și un mecanism pentru inserarea de operații noi în orice punct al unui

istoric. Istoricele pot fi făcute editabile, ceea ce transformă fiecare panel static într-un editor grafic. În

acest fel, panelurile pot fi modificate, iar comenzile invocate își propagă modificările î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

dorește modificarea săgeții (Fig. 1.6 b), se modifică ultimul panel din primul rând al istoricului din Fig. 1.5.

Se modifică acest panel și nu altul pentru că, ulterior, săgeata nu mai este aliniată cu axele grilei, iar

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

1.4 b).

Fig. 1.7 Istoric grafic prezentând crearea și alinierea a două dreptunghiuri

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

sește istoricele grafice editabile ca reprezentare vizuală pentru revizuirea, editarea, generalizarea pro-

gramului și raportarea erorilor. Spre exemplu, se consideră problema de aliniere la stânga a două drep-

tunghiuri. Pașii necesari sunt capturați în istoricul grafic din Fig. 1.7. Se creează inițial 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ă colțul din stânga sus al dreptunghiului de jos (panelul 5) și colțul din dreapta jos al

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

sus și se trage până ajunge la intersecția celor două linii.

Fig. 1.8 Fereastra pentru construirea macro-ului, care conține un macro pentru alinierea la stânga a două dreptunghiuri

Dacă se dorește generalizarea acestei proceduri și încapsularea ei într-un macro, nu se repetă procedura

într-un mod special de învățare, 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 apărea o fereastră

de construcție a macro-ului conținând panelurile selectate. În pasul următor se vor alege argumentele,

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

Make-Argument. Efectul va fi adăugarea 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 apărea o

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

Fig. 1.9 Fereastra de invocare a unui macro

Chimera folosește inferența pentru determinarea versiunii generalizate a unui macro. Folosirea inferen-

ței este un lucru comun în limbajele prin demonstrație, iar succesul ei depinde de limitabilitatea dome-

niului de aplicare (așa cum este cazul Chimera). Cu toate acestea, sunt și limbaje prin demonstrație care

nu folosesc inferența ș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 către

Margaret Burnett în 1991, ca prototip al lucrării sale de disertație (13). În acest caz, programatorul își

realizează programul prin crearea unui formular și specificarea conținutului acestuia. Această paradigmă

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

iar conținutul 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 manipulând direct celulele pentru a le plasa pe

formular și definind o formulă pentru fiecare celulă prin folosirea unei combinații flexibile de indicare,

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

mulele se combină într-o rețea (unidirecțională) de constrângeri, iar sistemul asigură în mod continuu că

toate valorile afișate pe ecran satisfac aceste constrângeri.

Fig. 1.10 Definerea suprafeței unui pătrat 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 pătratului fie desenând un pătrat, fie tastând textual specificațiile (spre exemplu, „box 30 30“)

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

de foi de calcul tabelar prin suportul funcționalităților avansate necesare pentru programare. Astfel,

suportă facilități precum grafică, animație și recursivitate, dar fără a recurge la macrouri de modificare a

stării sau conexiuni cu limbajele de programare tradiționale. Spre exemplu, Forms/3 oferă o colecție 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

răspuns vizual imediat, conform nivelului 4 de timp de răspuns. Facilitatea „concret“ este prezentă prin

faptul că elementul grafic rezultat este văzut 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ă specificațiile direct pe elementul

grafic creat.

Grupul țintă al Forms/3 sunt „viitorii“ programatori, adică aceia a căror treabă va fi să creeze aplicații,

dar a căror formare nu a pus accent pe limbajele de programare tradiționale actuale. Un scop al lui

Forms/3 a fost să reducă numărul și complexitatea mecanismelor necesare pentru programarea aplica-

țiilor, cu speranța că programatorilor le va fi mai ușor decât dacă ar folosi limbajele tradiționale, iar pro-

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


Pagina 19

dine mai ridicată și viteză atât în crearea programului, cât și în depanarea lui, folosind Forms/3 în com-

parație cu o varietate de tehnici alternative.

1.7.2.1 Exemplu de calcul al ariei unui pătrat în Forms/3

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

pe ecran la pornirea aplicației. Formularul System, listat în fereastra principală a formularelor, este în-

totdeauna încărcat la pornirea sistemului. Pentru a crea un formular nou se apasă butonul New Form,

acțiune urmată de apariția 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 stânga al mausului (butonul din stânga este folosit pentru selecție, butonul

din dreapta este folosit pentru alte sarcini). Cu un clic în spațiul 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 stânga, după care se acționează butonul asociat tabului formu-

lei pentru celulă. Va apărea un câmp unde se tastează formula (Fig. 1. 14), în cazul de față valoarea 5,

după care se apasă butonul Apply. Valoarea celulei este acum afișată. Acesta este un exemplu de răs-

puns imediat: de fiecare dată când se introduce o formulă toate valorile afectate sunt reafișate în mod

automat.

Fig. 1.13 Formular conținând o celulă nouă

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

mulă


Pagina 20

Repetând procedura se creează o nouă celulă în care se va calcula aria pătratului (Fig. 1.15,) ca fiind

formula Abox * Abox. Noua celulă (denumită Area) va afișa numărul 25. Modificarea valorii lui Abox va

atrage după sine modificarea valorii celulei Area.

Fig. 1.15 Formularul finalizat pentru calculul ariei pătratului

1.7.3 Prograph. Programarea vizuală cu fluxuri de date

Prograph a fost conceput în 1983 de către Tomasz Pietrzykowski și Philip T. Cocs (14). Cel de-al doilea

rămânând în proiect mai multă vreme i-a adus îmbunătățiri de-a lungul anilor. Prograph este un LPV

bazat pe fluxuri de date destinat programatorilor profesioniști. 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 științifică și sistemele de simulare

Prograph este un limbaj funcțional și ușor de folosit. Datele sunt reprezentate prin linii, iar metodele

prin diverse dreptunghiuri. Fiecare dreptunghi conține noduri pentru intrări și ieșiri. Datele sunt transmi-

se prin valori, ceea ce permite metodelor să folosească drept intrări, ieșirile 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 operații. Operațiile colectează datele și le tran-

smit spre alte operații până se obține 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 răspuns este 2, deoarece programatorul cere explicit

vizualizarea acestora când dorește să le vadă. Cu toate acestea, activitățile din timpul rulării și ordinea

de execuție a nodurilor pot fi vizualizate pe tot parcursul execuției, 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 răspuns.


Pagina 21

Fig. 1.16 Programarea prin fluxuri de date în Prograph. Programatorul folosește operații de nivel scăzut (primitive) pentru a calcula ipotenuza unui triunghi dreptunghic. Prograph permite numirea și compunerea unor astfel de prafuri de nivel scăzut î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 relaționările 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 inițial KidSim) este un LPV bazat pe reguli, în care programatorul specifică reguli pentru

demonstrarea unei postcondiții plecând de la o precondiție. „Programatorii“ vizați sunt copiii, iar dome-

niul asociat este specificarea simulărilor grafice și jocuri. Cocoa este un limbaj Turing complet, doar că

facilitățile lui nu au fost proiectate pentru programarea de uz general, ci pentru a facilita accesul copiilor

la programarea propriilor simulări.

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

folosesc demonstrația ca modalitate de a specifica semantica. Cu toate acestea, nivelul de timp de răs-

puns este diferit, în Cocoa fiind între 2 și 3. Nu este nivel 3 pentru anumite tipuri de modificări ale pro-

gramului (spre exemplu, adăugarea unor noi reguli) care nu afectează afișarea curentă a variabilelor

până la cererea expresă a programatorului de reluare a rulării. Pentru alte modificări ale programului

(modificarea aspectului unui obiect), modificările sunt imediat propagate pe afișaj.

În indicarea proprietăților 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ă conțină o varietate de

caractere, aspecte și proprietăți. O regulă specifică ce face un caracter într-o situație particulară, aspec-

tul permite caracterului să își modifice înfățișarea, iar proprietățile sunt folosite pentru a reține informa-

ții despre caracter. Simularea se face pe baza unui ceas, astfel încât la fiecare tact al acestuia fiecărui

caracter din scenă i se permite funcționarea conform propriilor lumi. Fig. 1.17 (16) prezintă un ecran

Cocoa tipic.


Pagina 22

Fig. 1.17 Ecranul Cocoa. Fereastra din colțul stânga sus constituie placa de lucru, cu caseta de copiere sub ea. În dreapta, utilizatorul a deschis carnețele pentru cele două personaje de pe placă

Fiecare caracter are o listă de reguli. Când unui caracter îi vine rândul să acționeze, sistemul parcurge

lista de reguli, selectează prima regulă aplicabilă stării curente și o execută. Regulile se creează prin spe-

cificarea propriu-zisă de către programator a acțiunilor care vor fi incluse, după care sistemul le generali-

zează (creează regula) pentru a putea fi folosite în mod automat de câte 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 pătrățel la dreapta. După apăsarea butonului New

Rule, întreaga placă se întunecă, cu excepția unui spot de lumină în jurul caracterului, care poate fi di-

mensionat pentru a include contextul regulii (pătratul din dreapta caracterului). În pasul următor, se

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

reguli prezintă o imagine cu starea regulii înainte (stânga) și după (dreapta), unite cu o săgeată. Regula


Pagina 23

se interpretează: „dacă este spațiu 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 plăcii.

Fig. 1.19 Regula de salt. Caseta acțiunii din dreapta a fost expandată pentru a vizualiza acțiunile 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 pătrat deasupra gardului, duce aspectul

„de salt“ în caseta aspectului curent (current appearance box) de pe pagina de aspect din carnețelul

caracterului, mută caracterul un pătrat la dreapta gardului, după care revine la aspectul „normal“.

Fig. 1.20 Modificarea regulii de mers la dreapta

De multe ori simulările devin interesante deoarece caracterele se modifică pe parcurs: îmbătrânesc,

obosesc, devin mai puternice sau mai deștepte. Pentru a permite modificarea stării interne a caractere-

lor, Cocoa oferă atribuirea de proprietăți, care pot fi predefinite sau create de utilizator. Spre exemplu,

utilizatorul poate crea proprietăți precum „vârstă“ sau „flămând“ pentru un anumit caracter. Aceste

proprietăți joacă rolul instanțelor din programarea orientată pe obiecte. Fig. 1.20 (16) prezintă modifica-

rea regulii de mers la dreapta astfel încât caracterul să flămânzească. Utilizatorul creează proprietatea

denumită hunger în lista de proprietăți a caracterului cu valoare inițială 0. Pentru a modifica regula, se

folosește butonul Add On pentru acea regulă, care execută acțiunile asociate regulii, după care permite

utilizatorului să demonstreze noi acțiuni. În acest caz, utilizatorul modifică valoarea din proprietatea

hunger din 0 în 1. Sistemul generalizează această demonstrație, dându-i sensul „Adună 1 la foamea


Pagina 24

mea“. Dacă nu este aceasta interpretarea demonstrației, utilizatorul îi poate edita descrierea. Cocoa

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

În fiecare ciclu de execuție, regulile asociate fiecărui 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 considerație.

Apoi, dacă regula nu poate fi aplicată la starea curentă a caracterului, indicatorul devine roșu. Dacă re-

gula poate fi aplicată, este executată și indicatorul din dreptul ei devine roșu. După aplicarea unei reguli

pentru un caracter, acesta este oprit și nu se mai verifică nicio regulă pentru el până în următorul ciclu.

(4)

Fig. 1.21 Un cățărător de zid în Cocoa care urmează regulile demostrate pentru el. Tocmai a terminat regula 2, care îl pune în poziția cerută de regula 1 (în pasul următor)

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 reprezentări 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 folosește o paradigmă de flux de date pentru construcția programelor. Lucrul în 3D asigură un

număr de avantaje asupra limbajelor 2D tradiționale. Spre exemplu, lucrul în 3D îi permite sistemului să

afișeze mai multe informații într-un mediu cu care este mai ușor de interacționat decât cu o reprezenta-

re 2D care folosește aceleași 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 secțiuni 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 funcție

recursivă pentru calculul factorialului unui număr 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 funcția definită în interiorul cubului.

Cubul de definire are două porturi conectate la el, unul la stânga și unul la dreapta. Portul din stânga

asigură intrarea, iar portul din dreapta este ieșirea, deși, tehnic vorbind, ambele porturi pot asigura am-

bele funcții, în Cube porturile fiind bidirecționale. Cele două porturi sunt conectate prin conducte la

cuburile suport în planul de jos al diagramei, care reprezintă cazul de bază al recursivității. Fiecare plan

reprezintă o diagramă de fluxuri de date. Pentru situația 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 ieșire. Dacă intrarea este mai mare decât zero, atunci este satisfăcut predicatul din

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

din partea de sus. Diferența este introdusă în apelul recursiv al funcției factorial, iar rezultatul este mul-

tiplicat cu valoarea de intrare. Rezultatul este trimis la portul de ieșire. După definirea funcției 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 provocările legate de programarea vizuală o reprezintă scalarea limbajelor pentru a dezvolta

programe cât mai extinse. Aceasta este o problemă mai mare pentru LPV-uri decât pentru limbajele

tradiționale textuale din motive legate de reprezentare, designul și implementarea limbajului și nouta-

tea relativă a domeniului. Spre exemplu, unele mecanisme vizuale folosite pentru a obține caracteristici

precum explicit pot ocupa un spațiu atât de mare încât devine dificilă menținerea contextului. De ase-

menea, este dificil de aplicat tehnici dezvoltate pentru limbajele tradiționale, deoarece ele pot aduce cu

sine reintroducerea complexității pe care LPV-urile au încercat să o înlăture sau să o simplifice.

Dezvoltări recente în domeniul abstractizării au fost foarte importante pentru scalabilitatea LPV-urilor.

Cele două tipuri de abstractizare, cele mai răspândite atât în programarea vizuală, cât ș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 abstractizării

procedurale în LPV-uri l-a reprezentat consistența cu restul programării în același LPV. Soluții reprezen-

tative includ: posibilitatea programatorului de a selecta, numi și iconifica o secțiune a unui graf de flux

de date (Fig. 1.16), care adaugă un nod, reprezentând subgraful, la o bibliotecă de noduri funcții î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 „funcții“ definite de utilizator într-un limbaj bazat pe formulare; înregistrarea

și generalizarea unei secvențe de manipulări 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 găsit o cale pentru a menține caracteristici precum concret și răspuns direct, și a

adăuga suport pentru ideile centrale legate de abstractizarea datelor, precum generalitate și ascunderea

informației. Cu toate acestea, în anumite LPV-uri a apărut 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 obișnuite se

definesc operații sau metode și cu două celule diferențiate se permite compunerea obiectelor complexe

din cele simple și definirea modului de vizualizare pe ecran al obiectului. În Cocoa, aspectul fiecărui ca-

racter este desenat folosind un editor grafic și fiecare demonstrație a unui noi reguli „aparține“ tipului

caracterului manipulat, asigurând aproximativ funcționalitatea unei operații sau metode. Ambele,

Form/3 și Cocoa, asigură și un suport limitat pentru moștenire.

1.9 Concluzii privind programarea vizuală

Domeniul limbajelor de programare vizuală abundă cu exemple ale eforturile de a lărgi accesibilitatea și

mări puterea programării calculatoarelor. Deși numeroasele proiecte existente variază în detaliile oferite,

în special în metafora vizuală implicată și în domeniul de aplicare țintit, toate împărtășesc scopul comun

al îmbunătățirii procesului de programare. În plus, cercetările recente pentru solidificarea fundamente-

lor teoretice ale programării vizuale și eforturile serioase depuse pentru dezvoltarea unor clasificări 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 douăzeci de ani, contribuții incipiente importante, precum

Sketchpad și Pygmalion, și-au menținut influența în numeroase design-uri de LPV-uri.

În ciuda migrării spre afișajele grafice și a interacțiunilor 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

decât cele care folosesc text pentru etichete și anumite operații atomice. Spre exemplu, deși o operație

precum adunarea poate fi reprezentată grafic în LPV-uri, făcând acest lucru se poate încărca foarte mult

afișajul. Pe de altă parte, folosind text pentru a reprezenta o astfel de operație atomică se obține un

afișaj mult mai simplu, fără a pierde metafora vizuală globală.

În condițiile în care grafica computerizată, atât hardware, cât și software, continuă să-și îmbunătățească

performanța și să-și scadă prețul, LPV-uri tridimensionale, precum Cube, atrag atenția comunității de

cercetători. LPV-urile 3D nu doar rezolvă problema includerii unei cantități mari de informații pe un

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

lator și interfețele om-calculator, ceea ce a fost o marcă a programării vizuale încă de la începuturile sale.


Pagina 28

2 Modelare cu rețele Petri (19)

2.1 Introducere

Creșterea în complexitate a sistemelor industriale moderne, precum producția, controlul procesului,

sisteme de comunicații etc., a indus apariția a numeroase probleme privind dezvoltarea acestora. În faza

de planificare apare confruntarea cu capabilitățile crescute ale acestor sisteme, datorită combinațiilor

unice de hardware și software care operează sub un număr mare de constrângeri ce rezultă din resurse-

le limitate ale sistemului. În condițiile 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 substanțial la timpul și costul de dezvoltare. Chiar și eficiența operațională poate fi afec-

tată. Din acest motiv, o atenție specială trebuie acordată corectitudinii modelor care sunt folosite la

toate nivelurile de planificare.

Ca unelte grafice și matematice, rețelele Petri asigură un mediu uniform pentru modelare, analiză for-

mală și design al sistemelor cu evenimente discrete. Unul dintre principalele avantaje al folosirii rețelelor

Petri îl constituie faptul că același model este folosit atât pentru analiza proprietăților comportamentale

și evaluarea performanțelor, cât și pentru construcția sistematică a simulatoarelor și controlerelor cu

evenimente discrete. Rețelele Petri au fost numite după Carl A. Petri, care a creat în 1962 o unealtă ma-

tematică sub formă de rețea pentru studiul comunicării cu automatele. Dezvoltarea lor ulterioară a fost

ușurată de faptul că rețelele Petri pot fi folosite pentru modelarea unor proprietăți precum sincroniza-

rea proceselor, evenimente asincrone, operații concurente, rezolvarea conflictelor sau partajarea resur-

selor. Aceste proprietăți caracterizează sistemele cu evenimente discrete care includ sistemele automa-

te industriale, sistemele de comunicare și sistemele bazate pe calculator. Toate acestea transformă rețe-

lele Petri într-o unealtă promițătoare și o tehnologie pentru aplicații în automatizări industriale.

Ca unealtă grafică, rețelele Petri asigură un puternic mediu de comunicare între utilizator (de regulă,

inginer) și client. Cerințele complexe din caietele de sarcini pot fi reprezentate grafic folosind rețele Petri

în locul unor descrieri textuale ambigue sau al unor notații matematice dificil de înțeles de către client.

Acest aspect, combinat cu existența unor unelte computerizate care permit simularea grafică interactivă

a rețelelor 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 rețea Petri poate fi descris de un set de ecuații lineare algebrice

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

ficare formală a proprietăților asociate comportamentului sistemului vizat (relații de precedență între

evenimente, operații concurente, sincronizările necesare, eliminarea situațiilor de blocare (deadlock),

activitățile repetitive și excluderile mutuale ale resurselor partajate, pentru a aminti câteva dintre ele).

Validarea modelului prin simulare poate doar produce un set limitat de stări ale sistemului modelat, și

astfel poate arăta doar prezența (nu și absența) erorilor din model și specificațiile sale de bază. Abilita-

tea rețelelor Petri de a verifica formal modelul este importantă în mod special pentru sistemele în timp


Pagina 29

real critice din punct de vedere al securității, precum sistemele de control al traficului aerian, sistemele

de control al traficului feroviar, sistemele de control al reactoarelor nucleare etc. Rețelele Petri au fost

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

securității, pentru detectarea erorilor și pentru monitorizarea proceselor.

Un domeniu de succes de aplicare al rețelelor Petri îl constituie modelarea și analiza protocoalelor de

comunicare (încă de la începutul anilor ’70). În ultimii ani au fost propuse câteva abordări care permit

construirea modelelor de rețele Petri pentru protocoale din specificațiile scrise într-un limbaj relativ

nespecializat.

Rețele Petri, însă, au fost folosite în mod extensiv pentru modelarea și analiza sistemelor de producție.

În acest domeniu, rețeaua Petri reprezenta linii de producție cu buffer-e, sisteme automate de producție,

sisteme flexibile de producție, linii automate de asamblare, sisteme cu partajarea resurselor și, recent,

sisteme de producție de tip just-in-time.

Un alt domeniu de succes îl constituie aplicarea rețelelor Petri în modelarea controlerelor secvențiale.

Controlerele logice programabile (PLC) sunt folosite în mod uzual pentru controlul secvențial 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 secvențiale bazare pe rețele Petri, pe de

altă parte, sunt ușor de proiectat, implementat și întreținut. La începutul anilor ’80, Hitachi Ltd. a dezvol-

tat un controler secvențial bazat pe rețele Petri care a fost folosit cu succes în aplicații reale pentru con-

trolul sistemului de asamblare a pieselor și în sistemul automat de încărcare/descărcare din depozit.

Utilizatorii rețelelor Petri, conform statisticilor, au redus substanțial timpul de dezvoltare, în comparație

cu metodele tradiționale.

Rețele Petri au fost folosite extensiv și în dezvoltări software. Utilizarea în acest domeniu s-a concentrat

pe modelarea și analiza sistemelor software, iar cea mai complexă dezvoltare a implicat folosirea rețele-

lor Petri colorate. S-a demonstrat că acest tip de rețele Petri este un limbaj folositor pentru proiectarea,

specificarea, simularea, validarea și implementarea sistemelor software complexe.

Ca unealtă matematică, rețelele Petri permit evaluarea performanțelor sistemelor modelate. Perfor-

manțele deterministe și stocastice pot fi măsurate și evaluate folosind o gamă largă de modele de rețele

Petri care încorporează în definiția lor funcții de timp determinist și/sau probabilistic. Evaluarea perfor-

manțelor 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ă funcții de timp

cu distribuție probabilistică permit obținerea ratelor de producție pentru modelele sistemelor de fabri-

cație, capacitatea de producție, întârzieri, capacitatea pentru comunicare și modelele sistemelor cu mi-

croprocesor, utilizarea resurselor critice și măsuri de fiabilizare ale acestora. În ultimii ani, această clasă

de rețele Petri a fost folosită extensiv pentru modelarea și studiul performanțelor 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 distribuiți.

Un alt domeniu de aplicare îl constituie rețelele de comunicare. S-a lucrat pe rețele 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ă atenție în ultimii ani, acest lucru fiind oare-

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

nalat un interes în creștere pentru modelarea și evaluarea rețelelor de mare viteză (High Speed

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

Rețelele Petri cu extindere de timp, combinate cu tehnici euristice de căutare, au fost folosite pentru

modelarea și studiul problemelor de dispecerizare din sistemele de fabricație și din sistemele cu roboți.

De asemenea, acest tip de rețele Petri au fost folosite și pentru modelarea și analiza proceselor chimice

continue.

2.2 Descrierea rețelelor Petri

O rețea Petri poate fi identificată cu un tip particular de grafuri orientate bipartite populate cu trei tipuri

de obiecte. Aceste obiecte sunt locuri, tranziții și arce orientate care conectează locuri cu tranziții sau

tranziții cu locuri. Din punct de vedere grafic, locurile sunt reprezentate prin cercuri iar tranzițiile prin

bare sau dreptunghiuri. Un loc este intrare pentru o tranziție dacă există un arc orientat de la acel loc la

tranziție. Un loc este ieșire pentru o tranziție dacă există un arc orientat de la tranziție la loc. În forma sa

cea mai simplă, o rețea Petri poate fi reprezentată printr-o tranziție împreună cu locurile sale de intrare

și de ieșire. Această rețea elementară poate fi folosită pentru reprezentarea unor aspecte diverse ale

sistemelor modelate. Spre exemplu, locurile de intrare (ieșire) pot reprezenta precondiții (postcondiții),

iar tranzițiile — evenimente. Locurile de intrare pot semnifica disponibilitatea resurselor, tranziția —

utilizarea lor, iar locurile de ieșire — eliberarea resurselor. Un exemplu de rețea Petri este prezentată în

Fig. 1.24. Această rețea este formată din cinci locuri, reprezentate prin cercuri, patru tranziții, reprezen-

tate prin bare și arce orientate ce conectează locurile cu tranzițiile și tranzițiile cu locurile. În rețea, locul

p1 este intrare pentru tranziția t1, iar locurile p2, și p3 sunt ieșiri pentru tranziția t1.

Fig. 1.24 Exemplu de reprezentare grafică a unei rețele Petri

Pentru a studia comportamentul dinamic al sistemului modelat, adică stările acestuia și modificările lor,

fiecare loc poate deține niciunul sau un număr pozitiv de jetoane, reprezentate grafic prin mici cercuri


Pagina 31

solide, așa ca în Fig. 1.24. Prezența sau absența unui jeton dintr-un loc poate indica faptul că o condiție

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

numărul de jetoane în loc indică numărul resurselor disponibile. La un anumit moment dat de timp, dis-

tribuția jetoanelor în locuri, denumită marcajul rețelei Petri, definește starea curentă a sistemului mode-

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

cărui elemente, notate M(p), sunt numere întregi pozitive reprezentând numărul de jetoane în locurile

corespunzătoare. O rețea Petri ce conține jetoane se numește rețea marcată. Spre exemplu, în modelul

de rețea Petri din Fig. 1.24, M = (1,0,0,0,0)T.

Formal, o rețea Petri poate fi definită astfel:

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

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

2) T = { t1, t2, … tm } este un set finit de tranziții, � ∪ � ≠ ∅, și � ∩ � ≠ 0,

3) �: (� × �) → � este o funcție de intrare care definește arcele orientate de la locuri la tranzi-

ții, unde N este un set de întregi pozitivi,

4) �: (� × �) → � este o funcție de ieșire care definește arcele orientate de la tranziții la locuri

și

5) ��:� → � este marcajul inițial.

Dacă I(p, t) = k (O(p, t) = k), atunci există k arce orientate (paralele) conectând locul p cu tranziția t (tran-

ziția 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 (tranziție) 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.

Modificând distribuția jetoanelor în locuri, lucru care poate reflecta apariția unor evenimente sau execu-

ția unor operații, se poate studia comportamentul dinamic al sistemului modelat. Următoarele reguli

sunt folosite pentru controlul fluxului de jetoane:

Regula de activare. O tranziție t se spune că este activată dacă fiecare loc de intrare p al lui I conține cel

puțin numărul de jetoane egal cu ponderea arcelor orientate ce conectează p cu t.

Regula de execuție:


Pagina 32

(a) O tranziție activată t poate sau nu să fie executată dependent de interpretarea adițională asoci-

ată și

(b) Execuția unei tranziții activate t înlătură din fiecare loc de intrare p un număr de jetoane egal cu

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

șire p un număr de jetoane egal cu ponderea arcului direcțional care conectează t cu p.

Fig. 1.26 (a) Tranziția t1 activată. (b) Tranziția activată t1 este executată

Regulile de activare și de execuție sunt ilustrate în Fig. 1.26. În Fig. 1.26 (a), tranziția t1 este activată

deoarece locul de intrare p1 al tranziției t1 conține două jetoane și I(p1, t1) = 2. Execuția tranziției activate

t1 înlătură din locul de intrare p1 două jetoane, deoarece I(p1, t1) = 2, și depozitează un jeton în locul de

ieșire p3, O(p3, t1) = 1 și două jetoane în locul de ieșire p2, O(p2, t1) = 2. Toate acestea sunt reliefate în Fig.

1.26 (b).

Fig. 1.27 Rețea Petri cu un arc inhibitor

Puterea de modelare a rețelelor Petri poate fi crescută prin adăugarea abilității 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 tranziție și este reprezentat grafic cu un arc terminat cu

un mic cerc (Fig. 1.27). Prezența unui arc inhibitor între un loc de intrare și o tranziție va schimba condiți-

ile de activare a tranziției. În acest caz, tranziția este activată dacă fiecare loc de intrare, conectat la

tranziție printr-un arc normal (terminat cu săgeată), conține cel puțin numărul de jetoane egal cu pon-

derea arcului și nici un jeton nu este prezent în fiecare loc de intrare conectat la tranziție printr-un arc

inhibitor. Regula de execuție a tranziției este aceiași, doar că nu modifică marcajul locurilor conectate

prin arc inhibitor.

Se spune că o rețea Petri este pură sau fără bucle dacă nu există un loc care să fie și intrare și ieșire a

aceleiași tranziții. O rețea Petri care conține bucle poate fi convertită la o rețea Petri pură, ca în Fig. 1.28.


Pagina 33

Fig. 1.28 Înlăturarea buclelor

Fig. 1.29 Model de rețea Petri pentru un sistem multirobot

Pentru a ilustra modul în care rețelele Petri pot fi folosite pentru a modela proprietăți precum activități

concurente, sincronizare, excludere mutuală etc., se consideră un exemplu simplu al unui sistem cu ro-

boți. Sistemul este reprezentat de rețeaua Petri din Fig. 1.29, cu detalii în Tabelul 1. În acest model, două

brațe robotizate realizează operații de preluare și plasare, accesând un spațiu comun la preluarea sau la

transferul pieselor. Pentru a evita coliziunile, se presupune că doar un robot poate accesa spațiul de

lucru la un anumit moment de timp. În plus, se consideră că spațiul de lucru conține un buffer cu spațiu

limitat pentru produse. Exemplul poate reprezenta operarea a două brațe robotizare într-un sistem cu

două mașini unelte, unde un braț transferă semiprodusele de la prima mașină în buffer, iar celalalt braț

transferă semiprodusele de la buffer la a doua mașină.

Locuri (cu jetoane) Interpretare

p1 (p4) Robotul R1 (R2) realizează operații în afara spațiului comun

P2 (p5) Robotul R1 (R2) așteaptă accesul în spațiului comun

p3 (p4) Robotul R1 (R2) realizează operații în spațiului comun

p7 Excludere mutuală

p8 (p9) Buffer plin (gol)

Tranziții Interpretare

t1 (t4) Robotul R1 (R2) cere acces în spațiului comun

t2 (t5) Robotul R1 (R2) intră în spațiului comun

t3 (t4) Robotul R1 (R2) părăsește spațiului comun Tabel 1 Interpretarea locurilor și tranzițiilor pentru modelul de rețea Petri

al sistemului de asamblare multirobot


Pagina 34

În acest model, locurile p1, p2, p3 și tranzițiile t1, t2, t3 modelează activitățile brațului robotizat R1. Locuri-

le p4, p5, p6 și tranzițiile t4, t5, t6 modelează activitățile brațului robotizat R2. Tranzițiile t1 și t4 reprezintă

activități concurente ale lui R1 și R2. Fiecare dintre aceste tranziții poate fi trasă înainte sau după sau în

paralele cu cealaltă. Accesul la spațiul comun necesită sincronizarea activităților brațelor pentru a evita

coliziunea. Doar un braț robotizat poate accesa spațiul comun de lucru la un anumit moment de timp.

Această sincronizare este realizată prin mecanismul de excludere mutuală implementat de subrețeaua

formată din locurile p7, p3, p6 și tranzițiile t2, t3, t5, t6. Tragerea tranziției t2 dezactivează t5, presupunând

că t5 este activată, și viceversa. Astfel, doar un braț robotizat poate accesa spațiul comun la un moment

dat. În plus, se consideră capacitatea bufferului ca fiind b. În acest fel, spre exemplu, dacă p8 este gol,

atunci t2 nu poate fi activată. Această împiedică brațul R1 să încerce transferul unei piese către buffer

când acesta este plin. De asemenea, R2 nu poate accesa bufferul dacă nu sunt piese în el, adică locul p9

este gol.

2.3 Proprietăți ale rețelelor Petri

Ca instrument matematic, rețelele Petri posedă un număr de proprietăți. Aceste proprietăți, atunci când

sunt interpretate în contextul sistemului modelat, permit designer-ului de sistem să identifice prezența

sau absența proprietăților funcționale specifice domeniului de aplicare al sistemului proiectat. Astfel,

pot fi distinse două tipuri de proprietăți: comportamentale și structurale. Proprietățile comportamentale

sunt acelea care depind de starea inițială, sau marcajul, unei rețele Petri și de topologia acesteia. Vor fi

discutate în cele ce urmează proprietăți 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 funcțional particular. În general, întrebarea la care se

caută răspuns este dacă sistemul modelat cu rețele Petri are toate proprietățile dorite, așa cum sunt ele

specificate în cerințe, și nicio proprietate nedorită.

Pentru a afla dacă sistemul modelat poate atinge o anumită stare ca rezultat al comportamentului func-

țional cerut, este necesară găsirea unei astfel de secvențe de execuții ale tranzițiilor care va avea ca

efect transformarea marcajului M0 în Mi, unde Mi reprezintă starea specifică și secvența de execuții re-

prezintă comportamentul funcțional cerut. Trebuie subliniat faptul că sistemele reale pot atinge o anu-

mită stare prin mai multe comportamente funcționale permise. Într-o rețea Petri, acest lucru este reflec-

tat de existența unor secvențe specifice de execuții de tranziții, reprezentând comportamentul funcțio-

nal cerut ,care vor transforma un marcaj M0 în marcajul Mi cerut. Dacă într-un model de rețea Petri exis-

tă secvențe adiționale de execuție a tranzițiilor care să transforme un marcaj M0 în marcajul Mi poate

indica faptul că acel model de rețea Petri nu reflectă cu exactitate structura și dinamica sistemului des-

cris. De asemenea, acest fapt poate indica și prezența unor aspecte neanticipate privind comportamen-

tul funcțional al sistemului real, ceea ce înseamnă că rețeaua Petri reflectă cu precizie specificațiile sis-

temului descris.


Pagina 35

Un marcaj Mi este accesibil pornind de la marcajul M0 dacă există e secvență de execuție a tranzițiilor

care transformă marcajul M0 în Mi. Un marcaj M1 este imediat accesibil după marcajul M0 dacă o execu-

ție a tranzițiilor activate din M0 determină obținerea marcajului M1. Spre exemplu, în modelul sistemului

cu multirobot din Fig. 1.29, starea în care brațul robotic R1 realizează sarcini în spațiul comun, în timp ce

brațul robotic R2 așteaptă în afara spațiului, este reprezentată de vectorul Mi = (0, 0, 1, 0, 1, 0, 0, 2, 1)T.

Mi este accesibil din marcajul inițial M0, unde M0 = (1, 0, 0, 1, 0, 0, 1, 3, 0)T, prin următoarea secvență de

execuție a tranzițiilor: t1 t2 t4. Marcajul Mi = (0, 1, 0, 0, 1, 0, 1, 3, 0)T, care reprezintă starea sistemului în

care brațul robotic R1 așteaptă accesul în spațiul comun și brațul robotic R2 realizează sarcini în afara

spațiului comun, este accesibil imediat din marcajul inițial M0 prin execuția tranziției t1. În M0,atât tran-

ziția t1, cât și tranziția t4, sunt activate. Setul tuturor marcajelor accesibile din M0 este denumit setul de

accesibilitate și este notat R(Mo). Setul tuturor secvențelor posibile de execuție din M0 este notat cu

L(Mo). În acest fel, problema identificării existenței unei stări specifice Mi în care sistemul poate să ajun-

gă poate fi redefinită ca problema găsirii lui �� ∈ �(��).

2.3.2 Limitabilitate și siguranță

The regulă, locurile sunt folosite pentru reprezentarea unei zone de păstrare a datelor în comunicare

sau sistemele computerizate, a unor produse sau zone de păstrare a uneltelor în sistemele de producție

etc. Este foarte important de stabilit dacă strategiile de control stabilite asigură evitarea stării de supra-

încărcare a acestor zone. Zonele de păstrare a datelor pot păstra, fără a le corupe, doar un număr res-

tricționat de părți de date. În sistemele de fabricație, încercarea de a înmagazina mai multe unelte în

zona destinată acestui lucru poate duce la defectarea echipamentului. Proprietatea unei rețele Petri

care permite identificarea în cadrul sistemului modelat a situației de supraîncărcare se numește limitabi-

litate. O rețea Petri este k-limitată dacă numărul de jetoane în orice loc p, unde � ∈ �, este totdeauna

mai mic sau egal cu k (k este un număr întreg pozitiv), pentru orice marcaj M accesibil din marcajul inițial

M0, � ∈ �(��). O rețea Petri este sigură dacă este 1-limitată (Fig. 1.30). Într-o astfel de rețea, niciun loc

nu poate conține mai mult de un jeton. O rețea Petri este nelimitată dacă există cel puțin un loc care să

conțină un număr oricât de mare de jetoane (Fig. 1.31, locul p4).

Fig. 1.30 Rețea Petri sigură

Fig. 1.31 Rețea Petri nelimitată

2.3.3 Conservativitate

În sistemele reale, numărul resurselor utilizate este, în mod normal, limitat prin constrângeri financiare

sau de alt gen. Dacă jetoanele sunt utilizate pentru reprezentarea resurselor, al căror număr într-un


Pagina 36

sistem este fix, atunci numărul jetoanelor din rețeaua Petri a respectivului sistem ar trebui să rămână

neschimbat indiferent de marcajul curent al sistemului. Această directivă descinde din faptul că resurse-

le nu pot fi nici create, nici distruse, cu excepția cazului când ar trebui să se întâmple așa. Spre exemplu,

o unealtă distrusă poate fi înlăturată din celula de fabricare, iar numărul uneltelor disponibile se va re-

duce.

Fig. 1.32 Rețea Petri conservativă în raport cu w = [1,1,2,1,1]

Fig. 1.33 Rețea Petri strict conservativă

O rețea Petri este conservativă dacă numărul de jetoane este conservat. Din punct de vedere structural,

acest lucru este posibil doar dacă numărul de arce de intrare în fiecare tranziție este egal cu numărul de

arce de ieșire. În sistemele reale, însă, resursele sunt, în mod frecvent, combinate astfel încât anumite

sarcini să fie executate, apoi separate după finalizarea sarcinilor. Spre exemplu, într-un sistem de fabri-

cație flexibilă un vehicul ghidat automat colectează paleții cu produse de la o celulă de prelucrare și îi

transportă la o stație de descărcare unde paleții sunt preluați (scenariu ilustrat în Fig. 1.32). Tranziția t1

modelează încărcarea unui palet într-un vehicul. Tranziția t2 reprezintă livrarea paletului la stația de des-

cărcare și înlăturarea acestuia de pe vehicul. Deși numărul de jetoane se schimbă de la două la unu

atunci când este executată t1 și înapoi la două când este executată t2, numărul resurselor din sistem nu

se modifică. Pentru a preîntâmpina acestă problemă, locurilor li se pot asocia ponderi pentru ca suma

ponderată a jetoanelor din rețea să rămână constantă.

Se spune că o rețea Petri este conservativă dacă există un vector w, w = [w1, w2, ...., wm], unde m este

numărul de locuri și w(p) > 0 pentru fiecare � ∈ �, astfel încât suma ponderată a jetoanelor rămâne

neschimbată pentru fiecare marcaj M care poate fi accesat din marcajul inițial Mo. O rețea Petri este

strict conservativă dacă toate intrările vectorului w sunt unitare. Rețeaua 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 rețea Petri care nu este conservativă este prezentat în Fig. 1.31 deoarece locul p4

poate deține un număr nelimitat de jetoane. Dacă o rețea Petri este conservativă în raport cu un vector

unitar, atunci rețeaua este strict conservativă (Fig. 1.33).

2.3.4 Nivelul de activare

Acest concept este strâns corelat cu situația de blocare (deadlock), care a fost studiată în mod extensiv

în contextul sistemelor de operare. S-a arătat că această situație poate să apară în patru condiții:


Pagina 37

1) Excluderea mutuală: o resursă este fie disponibilă, fie alocată unui proces care are acces exclusiv

asupra ei.

2) Deține și așteaptă: unui proces i se permite să dețină o resursă (sau mai multe) și să acceseze în-

că o resursă (sau mai multe).

3) Fără preempțiune: o resursă (sau mai multe) alocată unui proces nu poate fi eliberată decât de

către procesul în sine.

4) Așteptare circulară: două sau mai multe procese sunt aranjate într-un lanț în care fiecare proces

așteaptă după resursele deținute de procesul poziționat înaintea lui în lanț.

Fig. 1.34 Rețea Petri cu diferite niveluri de activare a tranzițiilor

Spre exemplu, într-un sistem flexibil de fabricație poate interveni o situație de blocare atunci când un

buffer de intrare/ieșire al unei unelte de prelucrare deține un palet cu produse prelucrate și alt palet cu

produse care trebuie prelucrate a fost trimis la buffer. Dacă buffer-ul poate păstra doar un palet la un

moment de timp și vehiculul ghidat automat, care transportă paleții, are loc doar pentru un palet, atunci

tocmai a intervenit o situație 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 mașină în buffer. În acest exemplu, toate

cele patru condiții de mai sus au fost îndeplinite, dacă spațile pentru paleți din buffer și de pe mașină

sunt privite ca resurse. Dacă în software-ul de control nu există prevăzută o rutină pentru detectarea și

ieșirea din starea de blocare, o astfel de stare, deși apărută într-un subsistem, se poate propoga și poate

afecta o mare parte a sistemului.

O rețea Petri care modelează un sistem fără stări de blocare este o rețea activă. Aceasta înseamnă că

pentru toate marcajele M, care pot fi accesate din marcajul inițial Mo, este posibilă execuția oricărei

tranziții din rețea prin progresul obținut de parcurgerea a câteva secvențe de execuții. Rețeaua 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 fără blocaje. Spre exemplu, inițializarea unui sistem

poate fi modelată de o tranziție (sau mai multe) care se execută de un număr finit de ori. După inițializa-

re, sistemul poate avea un comportament lipsit de blocaje, deși rețeaua Petri reprezentând acest sistem

nu mai este activă, conform cu definiția anterioară. Din acest motiv, există mai multe niveluri de activare

pentru o tranziție t și marcajul Mo. Astfel, o tranziție t într-o rețea Petri poate fi:

L0-activă (sau moartă) dacă nu există nicio secvență de execuție din L(Mo) în care t să fie execu-

tată,


Pagina 38

L1-activă (potential executabilă) dacă t poate fi executată cel puțin o dată în anumite secvențe

de execuție din L(Mo),

L2-activă dacă t poate fi executată de cel puțin k ori în anumite secvențe de execuție din L(Mo)

pentru orice k întreg și pozitiv,

L3-activă dacă t poate fi executată de un număr infinit de ori în anumite secvențe de execuție

din L(Mo), şi

L4-activă (sau vie) dacă t este L1-activă (potențial executabilă) în orice marcaj din R(Mo).

Urmând această clasificare, o reţea Petri se spune că este Li-activă, pentru marcajul Mo, dacă orice tran-

ziție din rețea este Li-activă. În Fig. 1.34 sunt prezentate diverse niveluri de activare. Astfel, tranzițiile t0,

t1, t2 și t3 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 fabricație, sistemele de con-

trol al proceselor etc., constă în abilitatea acestor sisteme de a-și reveni dintr-a situație de eroare. Aces-

te sisteme trebuie să se întoarcă din starea care a eșuat la stări corecte anterioare. Această cerință este

strâns legată de proprietățile unei rețele Petri denumite reversibilitate și stare de pornire. Pentru marca-

jul inițial Mo, o rețea Petri este reversibilă dacă pentru orice marcaj M din R(Mo), Mo este accesibil din M.

Starea de pornire este o proprietate mai puțin restrictivă, și mult mai practică din acest motiv, decât

proprietatea de reversibilitate a unei rețele Petri. O stare M a unei rețele Petri este stare de pornire

dacă pentru orice marcaj M din R(Mo), Mi este accesibilă din M. Rețeaua Petri din Fig. 1.30 este reversi-

bilă, iar rețeaua din Fig. 1.31 este nereversibilă.

2.4 Metode de analiză

În paragraful anterior au fost definite câteva proprietăți ale rețelelor Petru care sunt folositoare pentru

analiza sistemelor modelate. Un aspect important care trebuie avut în vedere în timpul analizei constă în

verificarea existenței unei corespondențe funcționale de unu-la-unu între modelul rețelei Petri și specifi-

cațiile originale, de regulă, exprimate într-un mod informal. Conceperea unor modele de rețele Petri din

specificații informale nu este o sarcină ușoară, ea necesitând o mare experiență în modelare, precum și

cunoașterea tehnicilor de asistență în construirea modelului. Ca urmare, un model poate diferi foarte

mult de specificațiile inițiale, lucru general valabil când este vorba despre rețele Petri mari ale unor sis-

teme complexe. Existența unei corespondențe funcționale de unu-la-unu între specificațiile inițiale și

reprezentarea în rețea Petri a sistemului permite proiectarea rezultatelor analizei, obținute pe model,

asupra descrierii inițiale. Acest lucru permite obținerea unui feedback pentru clienți pe baza căruia, în

multe situații, clienții își clarifică propria percepție despre sistem.

Un alt aspect important care trebuie urmărit în timpul analizei este respectarea în totalitate a specificați-

ilor. De cele mai multe ori, aceste specificații definesc comportamentul funcțional extern al sistemului,

exprimat uzual prin relaționările de tip intrare/ieșire. Intrările sunt generate de mediul înconjurător sis-

temului, iar ieșirile reprezintă răspunsurile sistemului la aceste intrări. Dacă anumite intrări, generate de


Pagina 39

către mediu asupra sistemului, nu sunt incluse în specificații, atunci sistemul nu va fi capabil să răspundă

la aceste intrări în mod corespunzător atunci când ele vor apărea pe parcursul operării normale. Necesi-

tatea ca specificațiile să fie complete este cu atât mai importantă cu cât sistemul este mai critic, când

specificații incomplete pot duce la apariția unor evenimente catastrofice. Spre exemplu, apariția unei

stări neanticipate în operarea unui reactor nuclear poate duce la imposibilitatea rezolvării ei de către

sistemul de control, fapt deosebit de grav pentru siguranța întregii zone.

Consistența specificațiilor inițiale este o altă problemă care trebuie luată în considerație în timpul anali-

zei. Inconsistențe apar atunci când pentru o combinație permisă de intrări specificațiile permit două sau

mai multe combinații permise ale ieșirilor. Acest lucru se datorează, în general, unei percepții vagi, in-

complete și deseori incorecte a funcționalității 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 rețelei. Pe lângă aceste metode mai există și altele, destinate analizei unei rețele Petri, care

permit o transformare sistematică a rețelei prin reducerea numărului de locuri și tranziții, dar cu păstra-

rea unor proprietăți precum limitabilitatea, conservabilitatea, nivelul de activare etc., pe principiul că

rețelele mai mici sunt mult mai ușor de utilizat.

2.4.1 Arborele de acoperire

Această metodă se bazează pe enumerarea tuturor marcajelor posibile accesibile din marcajul inițial Mo.

Pornind de la marcajul inițial Mo, se poate construi setul de accesibilitate prin execuția tuturor tranziții-

lor posibile activate în toate marcajele posibile accesibile din marcajul inițial. În arborele de acoperire,

fiecare nod este etichetat cu un marcaj și fiecare arc cu tranzițiile necesare. Nodul rădăcină este etiche-

tat cu marcajul inițial Mo. Setul de accesibilitate devine nelimitat din două motive: existența unor marca-

je duplicate sau rețeaua în sine este nelimitată. Pentru a preveni un arbore de acoperire să devină foarte

mare, trebuie parcurși doi pași pe parcursul construirii arborelui. Primul pas presupune eliminarea mar-

cajelor duplicate: dacă pe calea dintre un marcaj inițial Mo și un marcaj curent M apare un marcaj M'

identic cu marcajul M, atunci marcajul M, fiind duplicat, devine nod terminal. Apariția unui marcaj ter-

minal implică faptul că toate marcajele posibile a fi accesate din M au fost deja adăugate arborelui.

În ceea ce privește rețelele nelimitate, pentru a păstra 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 inițial Mo către un marcaj curent M apare un marcaj M' ale cărui intrări sunt mai mici sau

egale cu intrările corespondente din marcajul M, atunci intrările lui M, care sunt strict mai mari decât

intrările corespondente din M', trebuie înlocuite cu simbolul ω. În anumite căi, existența marcajelor cu

intrările corespondente egale sau mai mari (pe măsură ce se depărtează de nodul rădăcină) indică faptul

că secvențele de execuție care transformă M' la M pot fi repetate la infinit. De fiecare dată când această

secvență este repetată, numărul de jetoane din locurile etichetate cu simbolul ω va crește.

Arborele de acoperire este construit conform cu următorul algoritm:

1) Marcajul inițial Mo este rădăcina arborelui și se etichetează cu „nou”.

2) Atât timp cât există marcaje „noi”realizează următoarele:

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 tranziție nu se activează în M, se etichetează M ca „terminal”.

4) Pentru orice tranziție t activată în marcajul M realizează:

a. Obține marcajul M' care rezultă din execuția lui t în M.

b. Dacă pe calea de la rădăcină la M există un marcaj M" astfel încât M'(p) ≥ M"(p) pentru

fiecare loc p, și M' = M", atunci înlocuiește M'(p) cu ω pentru fiecare p, atâta vreme cât

M'(p) > M"(p).

c. Introduce M' ca nod, trasează un arc de la M la M' etichetat t și etichetează M' ca „nou”.

Următorul exemplu va ilustra această metodă. Se consideră rețeaua din Fig. 1.35 și arborele ei de acope-

rire din Fig. 1.36. Dat fiind marcajul inițial, nodul rădăcină este Mo = (1,0,1,0)T. În acest marcaj, tranziția

t3 este activată.

Fig. 1.35 Model de rețea Petri

Fig. 1.36 Arborele de acoperire pentru modelul de rețea Petri

din Fig. 1.35

Când t3 este executată, se obține un nou marcaj: M1 = (1,0,0,1)T. Aceste este un marcaj „nou” în care

tranziția t2 este activată. Execuția lui t2 din M, va determina obținerea lui M2 = (1,1,1,0)T. Deoarece M2 =

(1,1,1,0)T ≥ Mo = (1,0,1,0)T, a doua componentă trebuie înlocuită cu simbolul ω. Această reflectă faptul că

execuția secvenței t3t2 poate fi repetată de un număr arbitrar de ori. În marcajul M2 = (1,ω,1,0)T sunt

activate două tranziții: tranziția t1 și tranziția t3 . Execuția lui t1 va determina marcajul M3 = (1,ω,0,0)T,

care este un nod „terminal”. Execuția tranziției t3 va determina un marcaj „nou” M4 = (1,ω,0,1)T, care

activează tranziția t2. Execuția lui t2 din M4 va duce la un nod „vechi”: M5 = (1,ω,1,0)T care este identic cu

M2.

Folosind arborele de acoperire se pot studia câteva proprietăți ale rețelei Petri. Spre exemplu, dacă un

nod din arbore conține simbolul ω, atunci rețeaua este nelimitată, dat fiind faptul că simbolul ω poate

deveni oricât de mare. Altfel (adică nu apare simbolul ω), rețeaua este legată. Dacă fiecare nod al arbo-

relui conține doar valori de 0 și 1, atunci rețeaua este sigură. O tranziție este moartă dacă nu apare ca o


Pagina 41

etichetă de arc în arbore. Dacă un marcaj M este accesibil din marcajul Mo, atunci există un nod M' astfel

încât M ≤ M'. Cu toate acestea, deoarece simbolul ω poate fi oricât de mare, anumite probleme, precum

acoperirea sau nivelul de activare, nu pot fi rezolvate doar prin studiul arborelui de acoperire. Pentru o

rețea Petri limitată, arborele de acoperire conține, ca noduri, toate marcajele posibile accesibile din

marcajul inițial Mo. În acest caz, arborele de acoperire se numește arbore de accesibilitate și orice pro-

blemă de analiză poate fi rezolvată prin simpla lui inspecție.

2.4.2 Matricea de incidență și ecuația de stare

O metodă alternativă de reprezentare și analiză a rețelelor Petri se bazează pe ecuații matriciale, folosite

pentru reprezentarea comportamentului dinamic al rețelelor Petri. Metoda presupune construirea ma-

tricei de incidență care definește toate interconexiunile posibile dintre locuri și tranziții. Matricea de

incidență a unei rețele Petri pure este o matrice A cu dimensiunile n x m întregi, unde n este numărul de

tranziții și m este numărul de locuri. Intrările în matricea de incidență sunt definite astfel:

�� = �� −��

�

unde: �� este egal cu numărul de arce care conectează tranziția ti cu locurile sale de ieșire pj

(�� = ��, ��)

�� este egal cu numărul de arce care conectează tranziția ti cu locurile sale de intrare pj

(�� = �(��, ��)).

Când tranziția ti se execută, �� reprezintă numărul de jetoane depozitate în locurile sale de ieșire pj, ��

�

reprezintă numărul de jetoane înlăturate din locurile sale de intrare pj, iar �� reprezintă modificarea

numărului de jetoane în locul pj. Astfel, se spune că tranziția ti este activată în marcajul M dacă

�� ≤ �(��), i = 1, 2, … m

Pentru rețelele Petri cu bucle, �� = 0pentru un loc pj și o tranziție ti care aparțin unei bucle. Din acest

motiv, pentru a avea siguranța că matricea de incidență reflectă structura rețelei Petri, se presupune că

rețeaua este pură sau este făcută pură prin introducerea de locuri adiționale (Fig. 1.28). Ecuația de stare

pentru o rețea Petri reprezintă modificarea din distribuția jetoanelor pe locuri (marcaje) ca rezultat al

executării tranzițiilor. Această ecuație este definită astfel:

�� = �� + ��,� = 1,2,…

Mk este un vector coloană cu dimensiunea m x 1 reprezentând un marcaj Mk accesibil imediat din marca-

jul Mk-1 după execuția tranziției ti. Vectorul k de execuție, uk, este un vector coloană de dimensiune n x 1,

care are toate intrările diferite de zero. Valoarea 1 în poziția i reprezintă execuția tranziției ti în execuția

k a secvenței de execuții a rețelei, pornind de la marcajul inițial Mo. Această intrare corespunde cu linia i

a matricei de incidență A, care reprezintă o modificare în marcaj ca urmare a execuției tranziției ti. Ecua-

ția matriceală este folositoare în studiul problemei de accesibilitate.


Pagina 42

Două concepte asociate cu matricea de incidență sunt folositoare în studiul proprietăților modelelor cu

rețele Petri: invariantul T și invariantul P.

O soluție întreagă � a ecuației �� = 0 este denumită invariant T. Intrările diferite de zero într-un inva-

riant T reprezintă numărul execuțiilor tranzițiilor corespunzătoare care aparțin unei secvențe de execu-

ție ce transformă marcajul M0 până se ajunge din nou în M0. Deși un invariant T conține tranzițiile cu-

prinse în secvența de execuții care transformă marcajul M0 în M0, precum și numărul de ori în care aces-

te tranziții apar în secvență, nu specifică ordinea de execuție a tranzițiilor.

O soluție întreagă � a ecuației �� = 0 este denumită invariant P. Acesta poate fi explicat, în mod intuitiv,

astfel: intrările deferite de zero reprezintă ponderile asociate locurilor corespunzătoare astfel încât su-

ma ponderată a jetoanelor din aceste locuri să fie constantă pentru toate marcajele accesibile din mar-

cajul inițial.

Subsetul de locuri (tranziții) care corespund intrărilor diferite de zero din invariantul P (invariantul T)

este denumit suport pentru invariant și este notat ‖�‖(‖�‖).

Fig. 1.37 Arborele de acoperire al rețelei Petri din Fig. 1.29

Fig. 1.38 Graful de accesibilitate al rețelei Petri din Fig. 1.29

2.4.3 Un exemplu

În această secțiune se va demonstra modul în care arborele de acoperire și tehnicile bazate pe invarianți

pot fi folosite pentru a analiza un model de rețea Petri, pe baza exemplului din Fig. 1.29 privind un sis-

tem multirobot. Presupunând 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 rețelei Petri pentru celula de asamblare cu multirobot

Invarianții P obținuți pentru această rețea sunt:

�� = (111000000)�

�� = (000111000)�

�� = (001001100)�

�� = (000000011)�

Următorii sunt invarianții suport corespunzători:

‖��‖ = {��, ��, ��}

‖��‖ = {��, ��, ��}

‖��‖ = {��, ��, ��}

‖��‖ = {��, ��}

Limitabilitate și siguranță: Rețeaua Petri din Fig. 1.29 este limitată. Acest lucru este evident din arborele

de accesibilitate: nici un marcaj accesibil din marcajul inițial M0 nu conține simbolul ω. În plus, deoarece,

pentru toate marcajele, nicio intrare nu este mai mare decât unu, rețeaua este sigură. Aceste proprietăți

pot fi foarte ușor determinate folosind invarianții P. Deoarece fiecare loc din rețea aparține unui invari-

ant suport iar rețeaua pornește de la un marcaj inițial limitat, întreaga rețea este limitată. În plus, deoa-

rece numărul de jetoane din fiecare invariant suport din marcajul inițial este unu, rețeaua este sigură.

Din proprietatea de limitabilitate a modelului de rețea Petri pot fi deduse două proprietăți privind ope-

rarea sistemului real. Buffer-ul nu poate fi supraîncărcat, deci nu există nicio probabilitate că R1 va acce-

sa zona buffer-ului când acesta este plin. De asemenea, buffer-ul nu poate fi supradescărcat, deci nu

există nicio probabilitate că R2 va accesa zona buffer-ului când acesta este gol. Folosind arborele de

accesibilitate, aceste proprietăți decurg din siguranța rețelei. Intrările în fiecare marcaj, care reprezintă

numărul de jetoane în locurile p8 și p9 sunt fie zero, fie unu. Folosind invarianți: invariantul suport ‖��‖

conține locurile p8 și p9. Din moment ce conținutul de jetoane în ‖��‖ în marcajul inițial este unu,la un

moment dat va fi doar un jeton fie în p8, fie în p9. Din acest motiv nu va fi nici supraîncărcare, nici

subdescărcare a buffer-ului.

Conservativitatea: Rețeaua Petri din Fig. 1.29 este conservativă. Din graficul de accesibilitate, se poate

observa că rețeaua este conservativă raportat la vectorul ω = [1,1,2,1,1,2,1,1,1]. Suma ponderată a je-


Pagina 44

toanelor rămâne aceeași pentru fiecare marcaj accesibil din marcajul inițial și este egală cu patru. Folo-

sind invarianți: conținutul de jetoane în fiecare invariant suport din marcajul inițial este unu. Invarianții

suport ‖��‖, ‖��‖, și ‖��‖ sunt mutual exclusivi. Invarianții suport ‖��‖ și ‖��‖ conțin locul p3 ca ele-

ment comun. Invarianții suport ‖��‖ și ‖��‖ conțin locul p6 ca element comun. Astfel, ponderea locuri-

lor p3 și p6 ar trebui să fie doi pentru ca rețeaua să fie conservativă. Implicația acestei proprietăți este că

numărul de brațe robotizate care operează în sistemul de asamblare este doi și nu se poate modifica. De

asemenea, spațiul din buffer este unu și nu se poate modifica

Nivel de activare: Rețeaua Petri din Fig. 1.29 este vie, toate tranzițiile fiind activate. Fig. 1.38 prezintă un

graf de accesibilitate al rețelei Petri din Fig. 1.29. Acesta este un graf direcționat, format dintr-un set de

noduri și un set de arce direcționate. Setul de noduri prezintă toate nodurile distincte din arborele de

accesibilitate, iar setul de arce direcționate, unde fiecare arc este etichetat cu câte o tranziție, reprezintă

toate tranzițiile posibile între nodurile din arborele de accesibilitate.

La simpla inspecție, rețeaua este L4-activă, deoarece pentru orice marcaj accesibil din marcajul M0, este

posibilă execuția oricărei tranziții prin parcurgerea unei anumite secvențe de execuție. Invarianții pot fi

folosiți pentru a demonstra „manual” că rețeaua este vie. Cu toate acestea, pentru o rețea de această

dimensiune, acest lucru ar fi laborios. Deoarece rețeaua este vie, sistemul nu poate ajunge într-o stare în

care nicio operație să nu fie posibilă.

Reversibilitatea: Rețeaua Petri din Fig. 1.29 este reversibilă. Tot prin inspecție, se poate constata, pe

baza grafului de accesibilitate, că M0 este accesibil din orice marcaj M ∈ R(Mo).

2.5 Rețele Petri: concluzii

Dezvoltarea rețelelor Petri a fost motivată de nevoia de a modela sistemele industriale. Rețelele Petri

ordinare nu sunt totdeauna suficiente pentru reprezentarea și analiza sistemelor industriale complexe,

fapt care a dus la dezvoltarea unor noi clase de rețele. În rețele ordinare, jetoanele nu au identitate, fapt

care ridică probleme în modelarea unor sisteme precum cele de comunicare sau de fabricație, ce necesi-

tă resurse fizice sau mesaje cu identitate (dacă sunt reprezentate prin jetoane). Fără această identitate

este imposibil de urmărit cursul diferitelor resurse sau mesaje în sistem. O soluție potențială constă în

construcția unui model într-o așa manieră încât fluxul fiecărui mesaj să fie asociat cu o subrețea dedicată.

Cum resursele și mesajele partajează, în multe cazuri, același sistem, toate aceste subrețele sunt identi-

ce, doar că această metodă crește complexitatea grafică a modelului. Pentru a rezolva aceste probleme

au fost propuse rețele Petri care permit jetoanelor să aibă identitate distinctă. Aceste rețele, denumite

rețele Petri de nivel ridicat, includ rețele cu tranziția predicatelor, rețele colorate și rețele cu jetoane

individuale.

În rețelele Petri de nivel ridicat, un jeton poate fi un obiect compus care transportă date. Aceste date

pot avea complexitate arbitrară, implicând numere întregi, numere reale, șiruri de caractere, înregistrări,

liste etc. Toate tipurile de rețele Petri au aceeași putere descriptivă, dar rețelele de nivel ridicat asigură

facilități de structurare mult mai bune. Rețelele colorate și cele cu tranziția predicatelor sunt aproape


Pagina 45

identice în ceea ce privește descrierea și simularea. Cu toate acestea, există diferențe considerabile în

ceea ce privește analiza formală. Rețelele Petri colorate sunt utilizate în diverse domenii, incluzând pro-

tocoale de comunicare, sisteme de producție etc. O dezvoltare importantă în domeniul rețelelor Petri de

nivel ridicat constă în introducerea modelelor orientate pe obiecte. În această clasă de rețele, jetoanele

sunt considerate instanțe sau tuplete ale instanțelor claselor de obiecte definite ca liste de atribute.

Acest tip de rețea a fost utilizat pentru a modela și analiza sisteme FMS (Flight Management System),

sarcini de asamblare și sisteme de asamblare.

Nevoia de specificații calitative ale controlului industrial, precum și nevoia pentru reprezentări ale in-

formațiilor aproximative și incerte au dus la dezvoltare de rețele Petri fuzzy. Definirile acestor rețele au

fost influențate, de regulă, de domeniile diverse de aplicare. Rețele Petri fuzzy au fost folosite pentru

reprezentarea cunoștințelor și a raționamentului, precum și pentru modelarea sistemului de monitoriza-

re și control al FMS.

Rețele Petri ordinare nu sunt suficient de puternice pentru reprezentarea și studiul unor proprietăți

importante ale sistemelor concurente, precum eventualitatea (anumite tranziții trebuie să fie executate,

în cele din urmă) și corectitudine (fairness) (dacă o tranziție devine executabilă de un număr infinit de ori,

atunci trebuie să fie executată de un număr infinit de ori). Pentru a rezolva aceste probleme au fost

create rețelele Petri temporale, în care sunt reprezentate constrângerile de timp prin operatori precum

next, hencefort, eventually, until etc. Abilitatea rețelelor Petri temporale de a exprima eventualitatea au

făcut aceste modele potrivite pentru reprezentarea și studiul comportamentului funcțional extern al

sistemelor. Aceste funcționalități sunt exprimate prin relaționări de intrare/ieșire, spre exemplu dacă a

fost stabilit un anumit șablon de intrare, atunci, în cele din urmă, va fi generat un anumit șablon de ieși-

re.

Deși încercările de a combina rețelele Petri cu alte tehnici, precum rețelele neuronale, logica fuzzy etc.

par să fie în vogă, acest tip de rețele sunt, totuși, restricționate 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 facilități de lucru cu probleme

din domenii specifice pentru un nivel de pregătire relativ scăzut care să nu necesite cunoștințe privind

rețelele Petri și metodele lor de analiză. Transformarea modelelor realizate cu rețele Petri în cod execu-

tabil va fi, de asemenea, esențială, permițând prototipizarea rapidă a sistemelor dezvoltate direct în

mediul operațional

Un alt motiv pentru care rețelele Petri sunt folosite mai mult în mediu academic și în instituțiile de cer-

cetare constă în dificultatea construcției 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 construcție, ci modelele sunt concepute într-o manieră adhoc. În ultima perioadă s-au

făcut încercări 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 rețelelor Petri este, de ase-

menea, restricționată, mai ales de felul în care se concep modelele, pe baza unei documentații insufici-

ente. Este clar că, folosirea pe scară largă a rețelelor Petri, mai ales în industrie, va trebui să fie susținută

de metode și unelte suport care să permită o construcție automată sau semiautomată a modelelor pe


Pagina 46

baza specificațiilor de dezvoltare. Soluțiile care au încercat să pună în practică acest deziderat folosesc

pentru construcția automată specificații exprimate prin reguli de producție, 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 cărui 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ă inițial de compania Google, iar

mai târziu de consorțiul comercial Open Handset Alliance. Android permite dezvoltatorilor să scrie cod

gestionat în limbajul Java, controlând dispozitivul prin intermediul bibliotecilor Java dezvoltate de Goo-

gle. Aplicațiile scrise în C și în alte limbaje pot fi compilate în cod mașină ARM și executate, dar acest

model de dezvoltare nu este sprijinit oficial de către Google.

Fig. 1.40 Logo Android

În iulie 2005, Google a achiziționat 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

vicepreședinte al T-Mobile) și Chris White (unul dintre primii ingineri ai WebTV). La acea dată se cunoș-

tea foarte puțin despre Android, Inc., doar că făceau software pentru telefoane mobile. Această achiziție

a generat zvonuri cum că Google ar plănui să intre pe piața telefoniei mobile, deși era neclar la vremea

respectivă ce funcție 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 producătorilor de telefoane mobile și operatorilor de rețele de telefonie

mobilă, cu perspectiva de a asigura un sistem flexibil, reînnoibil. Google a raportat că a aliniat deja o

serie de parteneri producători de componente hardware și software la noul concept și a semnalat ope-

ratorilor de rețele de telefonie mobilă că este deschis la diferite grade de cooperare din partea acestora.

Mai multe speculații că Google ar intra pe piața telefoniei mobile au apărut în decembrie 2006. Rapoarte

de la BBC și Wall Street Journal au remarcat faptul că Google își dorea căutarea web și aplicațiile sale pe

telefoane mobile și că lucra din greu către acest țel. Presa și siturile de știri au publicat curând zvonuri că

Google ar dezvolta un dispozitiv mobil marca Google. A urmat și mai multă speculație, susținând că în

timp ce Google definea specificațiile tehnice, ar fi demonstrat prototipuri producătorilor de telefoane

mobile și operatorilor de rețea. S-a raportat că până la 30 de telefoane prototip operau deja pe piață. În

septembrie 2007 Information Week a publicat un studiu care dezvăluia că Google a depus cereri pentru

mai multe brevete de invenție în domeniul telefoniei mobile.


Pagina 48

Lansarea platformei Android la 5 noiembrie 2007 a fost anunțată prin fondarea Open Handset Alliance,

un consorțiu de 48 de companii de hardware, software și de telecomunicații, printre care și Google, HTC,

Intel, Motorola, Qualcomm, T-Mobile, Sprint Nextel și Nvidia, consacrat dezvoltării de standarde pentru

dispozitive mobile. Google a lansat cea mai mare parte a codului Android sub licența Apache, o licență

de tip free-software și open source. În 9 decembrie 2008, s-a anunțat că 14 noi membri au aderat la pro-

iectul Android, incluzând: Sony Ericsson, Vodafone Group Plc, ARM Holdings Plc, Asustek Computer Inc,

Toshiba Corp și Garmin Ltd.

Începând cu 21 octombrie 2008, Android a fost disponibil ca open source. Google a deschis întregul cod

sursă (inclusiv suportul pentru rețea și telefonie), care anterior era indisponibil, sub licența Apache. Sub

licența Apache, producătorii sunt liberi să adauge extensii proprietare, fără a le face disponibile comuni-

tății open source. În timp ce contribuțiile Google la această platformă se așteaptă să rămână open source,

numărul versiunilor derivate ar putea exploda, folosind o varietate de licențe.

3.1.2 Caracteristici

Printre caracteristicile și specificațiile actuale se numără următoarele (21):

platforma Android este adaptabilă la configurații mai mari

mașina virtuală Dalvik este optimizată pentru dispozitive mobile

navigatorul web disponibil este bazat pe platforma de aplicații open source WebKit

biblioteci grafice 2D incluse

biblioteci grafice 3D incluse, bazate pe specificația OpenGL ES 1.0

suport media

software-ul de baze de date SQLite este utilizat în scopul stocării datelor

Android suportă tehnologii de conectivitate incluzând GSM/EDGE, CDMA, EV-DO, UMTS, Blue-

tooth și Wi-Fi

SMS și MMS sunt formele de mesagerie instant disponibile, inclusiv conversații de mesaje text.

Software-ul scris în Java poate fi compilat în cod mașină Dalvik și executat de mașina virtuală Dalvik, care

este o implementare specializată de mașină virtuală concepută pentru utilizarea în dispozitivele mobile,

deși teoretic nu este o Mașină Virtuală Java standard.

Android acceptă următoarele 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 aplicații care

pot fi descărcate și instalate pe hardware-ul țintă prin comunicație fără fir, fără a se utiliza un PC. Inițial

au fost acceptate doar aplicații gratuite. Aplicații contra cost sunt disponibile pe Android Market înce-

pând cu 19 februarie 2009.


Pagina 49

Android are suport nativ pentru multi-touch, dar această funcționalitate este dezactivată (posibil pentru

a se evita încălcarea brevetelor Apple pe tehnologia touch-screen). O modificare neoficială, care permite

multi-touch a fost dezvoltată.

Primele aprecieri cu privire la dezvoltarea aplicațiilor pentru platforma Android au fost amestecate. Pro-

blemele citate includeau bug-uri, lipsa de documentație, infrastructura de testare inadecvată și lipsa

unui sistem de gestionare public a problemelor. Google a anunțat un sistem de gestionare a problemelor

la data de 18 ianuarie 2008. În decembrie 2007, fondatorul startup-ului mobil MergeLab, Adam MacBeth,

a declarat: "Funcționalitatea lipsește, este prost documentată sau pur și simplu nu funcționează. Este

clar că nu este gata pentru prime time". În ciuda acestui fapt, aplicațiile pentru Android au început să

apară, deja, în săptămâna următoare celei în care a fost anunțată platforma. Prima aplicație publică a

fost jocul Snake. Telefonul Android Dev este un dispozitiv cu SIM și hardware neblocate care este desti-

nat dezvoltatorilor avansați. Cu toate că dezvoltatorii pot utiliza un dispozitiv de consum achiziționat de

pe piață pentru a-și testa și a utiliza aplicațiile, unii dezvoltatori pot alege să nu utilizeze un dispozitiv de

pe piață, preferând un aparat neblocat sau fără contract.

3.1.3 Evoluția sistemului Android și impactul său 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 piața telefoanelor inteligente, iar

compania de cercetare NPD a anunțat recent ca Android are o cotă de piață mai mare decât Apple în

Statele Unite.” (22)

Adopția Android a crescut în ultimul an datorită disponibilității acestuia la un număr mare de producă-

tori de telefoane mobile. Conform analiștilor financiari ai companiei de cercetare Trefis, există o paralelă

între strategia Google din piața smartphone-urilor și campania Microsoft împotriva Apple, care a ajutat

Windows să devină sistemul de operare dominant în piața PC-urilor. Microsoft a oferit licența sistemului

său de operare pentru orice producător de computere interesat, iar Google face un lucru asemănător cu

sistemul său de operare pentru producătorii de telefoane. Acest lucru ar putea însemna că iPhone nu va

obține o cotă de piață la cât estimaseră anterior analiștii.

Android deja este compatibil cu majoritatea producătorilor de telefoane mobile, de la Motorola la HTC,

care nu dețin un sistem de operare propriu. Primul telefon Android a fost vândut la mai bine de un an

după lansarea iPhone. Cu toate că a fost lansat mai târziu, Android a depășit iPhone în piața de

smartphone-uri din SUA și din întreaga lume. Deși piața din Statele Unite este una atipică, și este foarte

diferită față de ceea ce se întâmplă în restul lumii, aceasta prezintă un trend interesant, care s-ar putea

să fie împărtășit și în alte regiuni ale globului.

Astfel, la sfârșitul primului trimestru al anului 2010, cota de piață a Android a crescut cu 4% față de tri-

mestru precedent, ajungând la sfârșitul lunii mai la 13%. Această creștere este cu atât mai spectaculoasă

cu cât Android este singurul sistem de operare mobil care reușește să câștige cota de piață, ceea ce în-

seamnă că Google reușește să fure o bucată foarte mare din piața rivalilor săi.


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 aplicații incluse, precum client de email, program SMS, calendar, hărți,

navigator pe Internet, contacte etc. (nivelul aplicații).

Fig. 1.41 Arhitectura sistemului Android

Asigurând o platformă de dezvoltare deschisă, Android oferă dezvoltatorilor posibilitatea de a construi

aplicații complexe și inovative. Aceștia sunt liberi să se folosească de hardware-ul echipamentului, de

informații despre accesarea locației, de rularea de servicii de background, să seteze alarme, să adauge

notificații pe bara de stare etc. Dezvoltatorii au acces total la aceleași API-uri ca și aplicațiile distribuite

cu Android. Arhitectura aplicațiilor este gândită pentru a simplifica reutilizarea componentelor: orice

aplicației își poate publica capabilitățile, iar orice altă aplicație poate utiliza, apoi, aceste capabilități.

Același mecanism permite și înlocuirea componentelor de către utilizator.

Ca suport pentru toate aplicațiile, se află un set de servicii și sisteme, incluzând:

Un set bogat și extensibil de vizualizări (Views) care pot fi folosite pentru a construi o aplicație,

incluzând liste, griduri, casete de text, butoane, chiar și un browser web încorporat.

Furnizori de conținut (Content Providers) care permite aplicațiilor să acceseze date din alte apli-

cații (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, fișiere)

Un manager de notificare (Notification Manager) care permite tuturor aplicațiilor să afișeze aler-

te pe bara de stare.

Un manager al activităților (Activity Manager) care managerizează ciclul de viață al aplicațiilor și

navigare comună backstack (istorie de parcurgere a aplicațiilor pe baza căreia, cu tasta back, se

poate reveni la activități anterioare).


Pagina 51

Android include un set de biblioteci C/C++ folosite de diverse componente ale sistemului. Capabilitățile

asociate sunt oferite dezvoltatorilor prin suportul descris anterior. Câteva dintre aceste biblioteci sunt:

Biblioteci media: asigură suport de redare și de înregistrare a numeroase formate audio și video

populare, precum și fișiere cu imagini statice, incluzând MPEG4, H.264, MP3,AAC, AMR, JPG și

PNG

Managerul suprafeței de lucru (Surface Manager): asigură accesul la subsistemul afișorului și

compune layer-e grafice 2D și 3D pentru aplicații

LibWebCore: un motor de căutare 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 aplicațiilor.

Android include un set de biblioteci principale care asigură majoritatea funcționalităților disponibile în

bibliotecile limbajului de programare Java. Fiecare aplicație Android rulează în propriul proces și în pro-

pria instanță a mașinii virtuale Dalvik, scrisă astfel încât un dispozitiv să ruleze eficient multiple instanțe

ale mașinii virtuale. Mașina virtuală Dalvik se bazează pe un nucleu Linux pentru funcționalități de bază

precum lucrul cu fire de execuție ș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 funcționează ș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 conțin un program de

depanare, biblioteci, un emulator de dispozitiv (bazat pe QEMU), documentație, mostre de cod și

tutoriale. Platformele de dezvoltare sprijinite în prezent includ calculatoare bazate pe x86 care rulează

Linux (orice distribuție Linux desktop modernă), Mac OS X 10.4.8 sau mai recent, Windows XP sau Vista.

Cerințele 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), utilizând plug-in-ul An-

droid Development Tools (ADT), deși dezvoltatorii pot folosi orice editor de text pentru a edita fișiere

XML și Java și apoi să utilizeze unelte din linia de comandă pentru a crea, construi și depana aplicații

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 îmbunătățite și un design actualizat pentru ecranul de

bază. Instrucțiuni 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, deși au fost adăugate unele capabilități

mai puțin semnificative". Includea, de asemenea, câteva modificări ale API-ului față de versiunea 0.9.


Pagina 52

Pe 9 martie 2009, Google a lansat versiunea 1.1 pentru telefonul Android Dev. Deși există câteva actuali-

zări estetice, câteva actualizări cruciale includ suport pentru "căutare prin voce, aplicații contra cost,

remedii pentru ceasul cu alarmă, remediu pentru blocarea la trimiterea gmail, notificări de poștă elec-

tronică și intervale de împrospătare". O altă schimbare importantă este că telefoanele Dev pot acum

accesa aplicații plătite și dezvoltatorii le pot vedea pe piața Android.

Deși 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

(vicepreședinte la Google), care are o pasiune pentru acesta. Cupcake este în mod obișnuit interpretat

greșit ca numele unei actualizări, dar după cum este declarat pe situl de dezvoltare al Google: „Cupcake

[…] este o ramură de dezvoltare, nu o versiune stabilă.” Modificări notabile la software-ul Android intro-

duse în cupcake includ modificări la download manager, platformă, Bluetooth, software-ul de sistem,

radio și telefonie, instrumente de dezvoltare, sistemul de dezvoltare și câteva aplicații, 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 inițiat de Google și preluat de MIT din 2012. Acesta

este conceput pentru utilizatorii obişnuiţi, fără cunoştinţe speciale de programare și permite crearea

unor aplicații pentru sistemul de operare Android. Pentru a interacţiona într-un mod cât mai simplu cu

utilizatorul, programul a fost conceput vizual: pentru a crea o aplicaţie, utilizatorul desenează vizual

modul în care aplicația va arăta și folosește blocuri pentru a specifica comportamentul aplicației lui. App

Inventor folosește o interfaţă grafică, foarte asemănătoare cu interfaţa de utilizator de la Scratch şi

StarLogo TNG, care permite utilizatorilor să așeze obiectele vizuale pentru a crea o aplicație, care poate

rula pe sistemul Android sau alte sisteme. Raţionamentul este că, dacă tinerii dezvoltă aplicația, o vor

face pentru a-şi îndeplini propriile necesități cu ajutorul telefonului mobil. (23)

Prin crearea lui App Inventor pentru Android, Google a făcut cercetări semnificative prealabile în pro-

gramarea educațională. Editorul de blocuri folosește 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 dizertația 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 strâns 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 susținute de către teoriile constructive de învăţare, care subliniază că programarea poate

fi un vehicul pentru angajarea de idei puternice prin învăţare activă. Ca atare, aceasta este parte a unei

mişcări în curs de desfăşurare în computere şi educaţie, 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

anunțat 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 aplicaţii pentru Android fără a scrie cod de pro-

gram, prin crearea aplicației și specificarea comportamentului său 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 operaților şi condiţii (blocuri ,„if ”), astfel încât aplicația să poată să pună întrebări şi să se

ghideze pe răspunsuri. Există chiar şi blocuri pentru a stoca informaţiile într-o bază de date şi conexiune

la servicii online, precum Twitter.

Se poate construi aproape orice aplicație imaginabilă cu App Inventor: jocuri, aplicații informaţionale cu

datele generate de utilizatori, aplicații personale, aplicații pentru a ajuta oamenii să comunice, aplicaţii

care folosesc senzorii telefonului şi chiar aplicaţii care se conectează la rețele de socializare. Astfel, pe

lângă aplicaţiile de pe telefonul personal sau cele din Android Market, pot fi create aplicații 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 mișcă o

minge printr-un labirint în timp ce jucătorul înclină telefon. Dar App Inventor nu este doar pentru a con-

strui jocuri. Se poate utiliza, de asemenea, pentru a construi software-uri educaţionale: chestionare şi

alte aplicaţii care permit unui utilizator să înainteze printr-o secvenţă de informaţii. Se pot crea aplicații

test pentru diverse studii. Se pot adăuga la aceste chestionare toate sunetele dorite, utilizând 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ă întrebări sau să răspundă cu voce

tare.

Aplicațiile construite nu trebuie neapărat 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 aplicație antrenament care per-

mite utilizatorului să introducă numărul de abdomene făcute în fiecare zi, sau se poate modifica o apli-

cație test astfel încât întrebări noi pot fi create din zbor.

Deoarece App Inventor oferă acces la un senzor pentru locație prin GPS, se pot construi, de asemenea,

aplicații de orientare în spațiu. Se pot scrie aplicații care să utilizeze funcţionalități ale telefonului cu

Android. De exemplu, o aplicație care periodic trimite anumite texte, sms-uri, sau o aplicație cu titlul „Nu

trimit sms în timp ce conduc”, care răspunde la toate sms-urile automat cu „Îmi pare rău, eu sunt la vo-

lan și vă voi contacta mai târziu”. Se pot crea chiar aplicații de citit sms-urile primite cu voce tare.

Nu în ultimul rând, App Inventor este prevăzut cu componente care permit aplicaţiilor să comunice cu

Internetul. TinyWeb DB este o componentă mult mai generală pentru comunicarea cu serviciile de web,

astfel încât 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 aplicație web în AppInventor pentru accesarea


Pagina 54

datelor de pe situl Amazon, o aplicație de navigare prin librărie care să permită vizualizarea preţului unei

cărți.

Nu se pot construi chiar orice fel de aplicații cu App Inventor. Acest instrument oferă, totuși, un număr

limitat de componente de nivel înalt şi nu oferă acces la toate funcţionalităţile definite în setul Android

(care este accesibil prin intermediul limbajului de programare Java, prin SDK Android). Dar se pot con-

strui mai multe aplicaţii doar cu instrumente şi componenta TinyWebDB care oferă o punte de legătură

pentru mai multe elemente de calcul complexe şi servicii web, astfel încât AppInventor poate fi folosit în

colaborare cu programatori back-end.

3.2.2 Capacități și limitări

Capacităţile App Inventor includ:

accesul la cea mai mare parte a funcționalităților telefonului: convorbiri telefonice, mesaje text

SMS, senzori de locație, orientare şi accelerare, funcția text-to-speech sau recunoaşterea vorbirii,

sunet, video.

capacitatea de a invoca alte aplicații, cu componenta ActivityStarter

programare de control ca într-un limbaj textual. Există blocuri pentru condiționare (if, if else),

foreach şi o listă destul de cuprinzătoare de blocuri de matematică și logică.

baza de date de acces, atât pe dispozitiv, cât şi pe web

accesul la surse de informare web (API) App Inventor are următoarele limitări în ceea ce priveşte

În ceea ce privește limitările Ap Inventor, acestea sunt:

interfață cu utilizatorul limitată: constructorul interfeței cu utilizator s-a îmbunătățit, dar este

încă un pic defectuos și limitat, astfel încât nu se poate construi orice interfaţă de utilizator. De

exemplu, nu pot fi create aplicații cu ecrane multiple şi care să permită schimbări în orientarea

ecranului. Aceste probleme nu sunt fundamentale pentru proiectarea App Inventor şi vor fi în

curând rezolvate.

acces limitat la funcțiile aparatului: nu există componente pentru toate datele şi funcționalitățile

telefonului. De exemplu, nu se pot salva şi prelua fişiere 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: funcțiile blocurilor sunt legate de componentele specifice și nu

există nici o modalitate de a apela funcții 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: aplicațiilor generate de App Inventor le lipsește configurarea

necesară pentru includerea direct pe piață. Cu toate acestea, există în prezent o soluție pentru

publicarea pe piață.


Pagina 55

3.2.3 Modul de lucru

App Inventor a fost conceput pentru a dezvolta aplicaţii pentru telefoanele cu Android, folosind un

browser web şi un telefon conectat la Internet sau emulatorul (Fig. 1.42). Serverele App Inventor sto-

chează aplicațiile dezvoltate şi oferă, de asemenea, o formă a versiunii de management, prin urmărirea

modificării (change tracking). Practic, aceasta înseamnă că mediul de programare face uz de metoda

numită cloud computing - utilizatorul/programatorul folosește computerul său doar să se conecteze la

Internet şi la server şi utilizează serverul cu resursele lui partajate — spaţiu de stocare sau chiar puterea

de procesare.

Fig. 1.42 Mediul de dezvoltare App Inventor

Aplicaţiile pot fi construite în App Inventor astfel:

în App Inventor Designer, sunt selectate componentele care vor alcătui aplicația

î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, montând piesele

împreună, ca piesele unui puzzle.

Aplicația apare pe telefon pas-cu-pas, pe măsură ce piesele sunt adăugate în ea, aşa că poate fi testată

în timp ce este construită. Când e gata, poate fi ambalată pentru a produce o aplicaţie de sine stătătoare


Pagina 56

care ulterior se poate instala. Dacă nu este disponibil un telefon cu Android, aplicațiile 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. Aplicațiile 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 aplicații. 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 aplicații

Componentele App Inventor sunt situate pe partea stângă a ecranului Designer (Fig. 1.43 App Inventor

Designer), sub titlul Palette și sunt elementele de bază care pot fi utilizate pentru a face aplicații 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 iniţia o acţiune. Alte componente sunt mai elaborate: o

pânză de desen, care poate conţine imagini statice sau animații, un accelerometru (senzor pentru mişca-

re), care funcţionează 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

obţin informaţii de la situri web etc.

Fig. 1.43 App Inventor Designer


Pagina 57

Pentru a utiliza o componentă în aplicație, aceasta se selectează printr-un clic şi se trage pe mijlocul

Designer-ului. După adăugare, componenta va apărea și în lista de componente, pe partea dreaptă a

afișorului. Componentele au proprietăţi care pot fi ajustate pentru a schimba modul în care aceasta apa-

re în aplicație. Pentru a vizualiza şi modifica proprietăţile unei componente, ea trebuie selectată, mai

întâi, 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 aplicații. Al doilea este

editorul de blocuri, utilizat pentru a atribui comportamente componentelor, cum ar fi ceea ce ar trebui

să se întâmple atunci când 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 fișier care permite

computerului să comunice cu un dispozitiv conectat va fi descărcat ş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 aplicaţii descărcate în mod automat. În

acest caz, se deschide fişierul descărcat numit AppInventorForAndroidCodeblocks.jnlp.

În partea stângă a ferestrei editorului există trei categorii de seturi de blocuri (pallete): Built-in, My

Blocks (unde vor apărea blocurile adăugate în Designer) și Advanced. Când se acționează un set,

printr-un clic de maus, vor fi vizibile blocurile stocate în acea zonă. Categoria Built-in conține setul stan-

dard de blocuri necesare pentru orice aplicație (text, liste etc.). Categoria Advanced conține blocuri pen-

tru realizarea unor aplicații mai avansate, cu o logică mai complexă.

Designer-ul rulează în browser, iar editorul rulează folosind Java. Cu toate acestea, ele sunt conectate

astfel încât chiar dacă se închide fereastra editorului, toate informațiile din acesta sunt salvate în Desig-

ner. Când se face click pe butonul Open the Blocks Editor, un nou fișier .jnlp este descărcat pe calculator


Pagina 58

și acesta va fi deschis. În acest fel, editorul de blocuri va conține toate blocurile care fuseseră deja pro-

gramate în pași anteriori.

Programatorul are posibilitatea să utilizeze un telefon sau tabletă cu Android sau un emulator. Dacă se

selectează emulator (Fig. 1.45), atunci încărcarea va dura câteva minute, timp în care nu se va întreprin-

de nicio acțiune. După pornirea emulatorului, acesta trebuie conectat la editor, prin selectarea lui din

lista disponibilă în colțul din dreapta sus. Mai departe, editorul va începe comunicarea cu emulatorul și

aplicația ar trebui să apară pe emulator. Se poate folosi mausul pentru a acționa butoanele de pe emula-

tor, dar dacă butonul nu a fost programat, atunci nimic nu se va întâmpla. Mergând mai departe, orice

modificări aduse aplicației în Designer şi în editorul de blocuri, acestea vor apărea pe emulator.

Fig. 1.45 Emulatorul App Inventor

3.2.6 Componente App Inventor

Fiecare componentă poate avea metode, proprietăți și evenimente. Majoritatea proprietăților pot fi

modificate de către aplicații, prin blocurile de citire și setare pe care le dețin, restul de proprietăți pu-

tând fi doar citite. În cele ce urmează sunt prezentate doar câteva 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 acțiune asociată. Butoanele detec-

tează când sunt apăsate și își pot modifica aspectul.

Proprietăți:

BackgroundColor: culoare pentru fundalul butonului.


Pagina 59

Enabled: dacă este setat, butonul poate fi apăsat.

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: înălțimea butonului (dimensiunea y).

Width: lățimea butonului (dimensiunea x).

Image: imagine afișată pe buton.

Text: text afișat pe buton.

TextAlignment: stânga, centru, dreapta.

TextColor: culoarea textului de pe buton.

Evenimente:

Click(): utilizatorul a apăsat și a eliberat butonul.

GotFocus(): butonul a devenit componenta activă

LostFocus(): butonul nu mai este componenta activă.

CheckBox — componentă care detectează acționarea de către utilizator și își modifică starea booleană.

Proprietăți:

BackgroundColor: culoarea fundalului.

Checked: Adevărat dacă este marcată și fals altfel.

Enabled: dacă este setat, componenta poate fi acționată.

Height: înălțimea casetei (dimensiunea y).

Width: lățimea casetei (dimensiunea x).

Text: text afișat pe casetă.

TextColor: culoarea textului din casetă.

Visible: dacă este setat, componenta este vizibilă

Evenimente:

Click(): utilizatorul a apăsat și a eliberat caseta.

GotFocus(): caseta a devenit componenta activă

LostFocus(): caseta nu mai este componenta activă.

Label — componentă pentru afișare de text specificat de proprietatea Text.

Proprietăți:

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: înălțimea etichetei (dimensiunea y).

Width: lățimea etichetei (dimensiunea x).

Text: text afișat 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 acționarea componentei. Elementele listei pot fi specificate în proprietatea ElementsFromString

sub forma (selecție1, selectie2, selectie3), sau dintr-o listă externă prin setarea proprietății Elements la o

listă List în editorul de blocuri.

Proprietăți:

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: înălțimea listei (dimensiunea y).

Width: lățimea listei (dimensiunea x).

Text: text afișat î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 acționat 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

pornește cu un ecran, numit Screen1. Acest nume nu poate fi schimbat. Ulterior se pot adăuga și alte

ecrane.

Proprietăți


Pagina 61

AlignHorizontal: un număr care codifică alinierea pe orizontală a conținutului ecranului. Valorile

pot fi 1= aliniere la stânga, 2=centrare, 3=aliniere la dreapta.

AlignVertical: un număr care codifică alinierea pe verticală a conținutului 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: înălţimea ecranului (dimensiunea y).

Icon: o imagine care poate fi utilizată ca pictogramă pentru aplicația instalată pe telefon. Aceas-

ta ar trebui să fie PNG sau JPG; 48x48 este o dimensiune bună. În cazul folosirii altor imagini de-

cât PNG sau JPG, de exemplu fişiere ICO, App Inventor nu va putea să împacheteze aplicația.

ScreenOrientation: orientarea ecranului. Valorile posibile sunt: unspecified, landscape, portrait,

sensor, user.

Scrollable: opțiunea este specificată printr-un checkbox în designer. Când este selectat, va exista

o bară de derulare verticală pe ecran şi înălţimea aplicației poate depăşi înălţimea fizică a dispo-

zitivului. Când nu este bifat, înălţimea aplicației va fi constrânsă la înălţimea dispozitivului.

Title: titlu pentru ecran (text). Aceasta va apărea în partea stângă sus a telefonului atunci când

aplicaţia rulează. O alegere normală pentru titlu este chiar titlul aplicației, dar ar putea fi altceva,

sau poate fi chiar schimbat în timp ce aplicație se execută.

Width: lăţimea ecranului (dimensiunea x).

Evenimente:

BackPressed(): apăsarea butonului de pe spatele echipamentului.

Initialize(): semnalat atunci când aplicaţia începe. Acesta poate fi utilizat pentru stabilirea valori-

lor iniţiale şi efectuarea altor operaţiuni de configurare.

ErrorOccurred(): semnalat atunci când 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 orientării ecranului

Metode:

CloseScreenAnimation(text animType): pregătește animația pentru închiderea ecranului curent

și întoarcerea la ecranul anterior. Opțiuni valide sunt: default, fade, zoom, slidehorizontal,

slidevertical și none.

OpenScreenAnimation(text animType): pregătește animația pentru trecerea la alt ecran. Opțiuni

valide sunt: default, fade, zoom, slidehorizontal, slidevertical și none.

TextBox — componentă pentru introducerea de text. Se poate stabili o valoare inițială (în proprietatea

Text), sau se poate oferi o sugestie de completare (în proprietatea Hint). Textul introdus poate avea una

sau mai multe rânduri (proprietatea MultiLine). Dacă este permisă o singură linie de text, la completarea

ei, tastatura se va închide automat la semnalizarea utilizatorului (apăsarea tastei Done). De regulă, case-


Pagina 62

tele de text sunt folosite în combinație cu butoane, astfel încât utilizatorul să acționeze un buton când a

finalizat introducerea textului.

Proprietăți:

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: înălțimea casetei (dimensiunea y).

Width: lățimea casetei (dimensiunea x).

Text: text afișat în casetă.


TextColor: culoarea textului din casetă.

Visible: dacă este setat, componenta este vizibilă

Hint: text pentru sugestionarea utilizatorului. Vizibil doar dacă Text nu conține nimic.

MultiLine: dacă este adevărat, atunci este permisă introducerea mai multor linii.

NumbersOnly: dacă este adevărat, atunci caseta acceptă ca intrări 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ă când aplicaţia se execută.

TinyDB este o componentă non-vizibilă (adică utilizatorul nu o vede pe ecranul aplicației).

Aplicațiile create cu App Inventor sunt iniţializate de fiecare dată când rulează. Dacă o aplicaţie stabileş-

te valoarea unei variabile şi utilizatorul închide apoi aplicația, valoarea acelei variabile nu va fi memorată

data viitoare când aplicația rulează. TinyDB este un stocator de date persistent pentru aplicație, adică

datele stocate vor fi disponibile de fiecare dată când aplicaţia se execută. Un exemplu ar putea fi un joc

care a salvat scorul cel mai mare, şi refăcut de fiecare dată când jocul este jucat.

Instanțele 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 aplicație. Dacă e nevoie de mai multe componente

TinyDB, ele vor folosi aceleaşi date. De asemenea, fiecare aplicație are propriul loc de stocare. Nu se

poate utiliza TinyDB pentru a muta date între două aplicaţii diferite de pe telefon. Pentru a şterge din

baza de date a unei aplicaţii, de pe telefon din meniul Settings→Applica�ons→ Manage applica�ons, se

alege aplicaţia şi se apasă Clear data.

Datele din TinyDB sunt persistente numai după împachetarea şi descărcarea aplicației. Dacă aplicația

este în curs de dezvoltare și telefonul este conectat la PC şi se repornește aplicaţia App Inventor, sau

dacă se deconectează şi apoi reconectează telefonul, baza de date va reîncepe în stare proaspătă

(refresh). Acesta este cazul în care aplicația nu este doar oprită şi repornită, ci este ștearsă din telefon şi

apoi reîncărcată.

Proprietăți: 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): citește 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

rândul lui, detectează scuturarea telefonului și măsoară accelerația în 3 dimensiuni. Dacă telefonul este

așezat pe o suprafață plană, pe spate, accelerația Z este 9.8m/s2. Componenta produce trei valori:

XAccel: pozitiv când dispozitivul este înclinat spre dreapta (adică partea stângă este ridicată) și

negativ când este înclinat spre stânga.

YAccel: pozitiv când partea de jos este ridicată și negativ când partea de sus este ridicată.

ZAccel: pozitiv când ecranul este orientat în sus și negativ când ecranul este orientat în jos.

Proprietăți

Available: dacă există accelerometru.

Enabled: activarea accelerometrului.

XAccel: accelerație pe dimensiunea X.

YAccel: accelerație pe dimensiunea Y.

ZAccel: accelerație pe dimensiunea Z.

MinimumInterval: intervalul de timp minim între scuturarea telefonului.

Evenimente:

AccelerationChanged(number xAccel, number yAccel, number zAccel): apelat când se modifică

accelerația.


Pagina 64

Shaking(): apelat repetitiv când echipamentul este scuturat.

Metode:

Nu are.

LocationSensor — Această componentă oferă locaţia dispozitivului Android, folosind GPS-ul dacă este

disponibil şi o metodă alternativă altfel, cum ar fi turnuri celulare sau reţele fără fir cunoscute.

LocationSensor este o componentă non-vizibilă care furnizează informaţii de locație, 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 neapărat pe cea curentă) la o latitudine şi o

longitudine. Pentru a funcţiona, componenta trebuie să aibă proprietatea Enabled setată pe true, iar

dispozitivul să aibă activată funcția de detectare a locației.

Proprietăți:

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 reţea

CurrentAddress: adresa fizică a dispozitivului Android.

Enabled: dacă este setat, informaţiile de localizare sunt disponibile.

HasAccuracy: dacă este adevărat, dispozitivul Android poate raporta nivelul de precizie.

HasAltitude: dacă este adevărat, 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 când dis-

pozitivul Android găsește o locaţie nouă.

StatusChanged(text provider, text status): apelat atunci când 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 folosește pentru a determina spaţial orientarea telefonu-

lui. Acesta este o componentă non-vizibilă care raportează următoarele trei valori, în grade:


Pagina 65

Roll: 0° atunci când dispozitivul este drept, crescând la 90° când dispozitivul este înclinat cu par-

tea de sus spre partea stângă şi scăzând la -90° atunci când dispozitivul este înclinat cu partea de

sus spre partea dreaptă.

Pitch: 0° atunci când dispozitivul este drept, crescând la 90° când dispozitivul este înclinat astfel

încât vârful său este îndreptat în jos, creşterea în continuare la 180° când acesta devine întors

invers. În mod similar, când aparatul este înclinat astfel încât partea sa de jos este îndreptată în

jos, scade la -90°, apoi până la -180° pe măsură ce este răsucit tot drumul peste cap.

Azimuth: 0° atunci când partea de sus a aparatului este îndreptată spre nord, la 90° atunci când

este îndreptat spre est, la 180° atunci când este îndreptat spre sud, la 270° de grade atunci când

este îndreptat spre vest, etc

Aceste măsurători presupun că aparatul în sine nu este în mişcare.

Proprietăți:

Available: arată dacă senzorul de orientare este prezent pe dispozitivul Android.

Enabled: dacă este setat, senzorul de orientare este activat.

Azimuth: returnează unghiul de deviaţie al dispozitivului.

Pitch: returnează unghiul de întoarcere peste cap al dispozitivului.

Roll: returnează unghiul de rotire al dispozitivului.

Magnitude: returnează un număr între 0 şi 1, care indică gradul de înclinare al dispozitivului.

Mărimea dă magnitudinea forţei pe care ar simţi-o o bilă pe suprafaţa de rulare a dispozitivului.

Angle: returnează unghiul care spune direcţia în care dispozitivul este îndreptat. Adică, se spune

direcţia forţei pe care ar simţi-o o bilă pe suprafaţa de rulare a dispozitivului.

Evenimente

OrientationChanged(number yaw, number pitch, number roll): numit atunci când 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 aplicații cu App Inventor. Materialul complet poate fi găsit 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 aplicație, trebuie să fie unic. Fig. 1.46 prezintă modul de afișare al

acestor blocuri.


Pagina 66

a)

b) Fig. 1.46 Blocuri de proceduri, fără 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. Numărul de argumente

nu este limitat, la completarea unuia apărând, 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 rulării aplicației și dă un nume pentru

această valoare. Variabilele sunt globale și pot fi folosite oriunde în aceeași aplicație. Numele variabilei

trebuie să fie unic. Fig. 1.47 prezintă modul de afișare 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 circumstanțe: un bu-

ton a fost apăsat, telefonul a fost scuturat etc. Aceste acțiuni specifice sunt descrise de un handler de

evenimente care începe cu cuvântul when. Majoritatea handler-elor au culoare verde.

Fig. 1.48 Handler de evenimente

Evident, când un eveniment apare, handler-ul asociat va fi executat.


Pagina 67

3.2.7.3 Comenzi și expresii

Când este executat un handler de evenimente, de fapt se rulează o secvență de comenzi din corpul său.

O comandă este un bloc care specifică o acțiune 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 acțiunea. 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 capăt

de prindere în partea stângă, 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ă, încât 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 afișa textul specificat. Dat fiind faptul că execuția are lor foarte repede, toate acțiunile au loc

aproape simultan.

3.2.7.4 Aranjarea elementelor pe ecran

Implicit, componentele sunt aranjate pe verticală. Dacă se dorește modificarea acestui mod de aranjare,

atunci se poate folosi una dintre componentele HorizontalArrangement, VerticalArrangement sau

TabletArrangement din secțiunea ScreenArrangement.

3.2.7.5 Manipularea stării componentelor

Fiecare componentă este caracterizată de numeroase proprietăți. Valorile curente ale acestor proprie-

tăți 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 când sunt atinse și îl pierd când nu

mai sunt atinse. Butonul este special pentru că, atunci când este atins, lansează evenimentul Click.

3.2.7.7 Comentarii

O parte importantă din munca de programare o constituie realizarea unei documentații. App Inventor

permite încorporarea de comentarii chiar în cod care explică diverse elemente și aspecte ale codului.

Adăugarea unui comentariu pentru blocuri se face cu clic dreapta pe bloc (Fig. 1.53).

Fig. 1.53 Adăugarea de comentarii


Pagina 69

3.2.8 Exemplu de realizare a unei aplicații cu App Inventor.

În continuare, este prezentată realizarea unui joc (Fig. 1.54) în cadrul căruia utilizatorul are pe ecran o

poartă de fotbal, o minge, un indicator de forță a șutului, un indicator de direcție și un portar. Scopul

jocului este de a înscrie gol, având mingea în punctul de 11 m. Portarul, direcția și forța sunt în continuă

mișcare, fiecare având viteze diferite. Portarul se mișcă pe linia porții efectuând o cursă completă, care

se repetă până când mingea ajunge la el, sau mingea intră în poartă, sau mingea trece pe lângă poartă.

Utilizatorul are la dispoziție două butoane: unul pentru a șuta, iar celălalt pentru a repune mingea pe

punctul de la 11 m. În funcție de indicatorul de forță și de direcție, mingea va merge mai repede sau mai

încet, respectiv mai la stânga sau mai la dreapta. În momentul în care mingea intră în poartă este afișat

mesajul GOOOOL, când mingea este prinsă de portar, mesajul , iar când mingea trece pe lângă poartă,

mesajul Ce ratare.

3.2.8.1 Elemente vizuale

Terenul de fotbal este reprezentat de un element Canvas al cărui fundal este o imagine cu extensia .jpg

ce conține, î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 direcției

și stabilirea forței șutului. Portarul este reprezentat printr-un element de tipul ImageSprite, având ca

fundal o imagine sugestivă a unui portar, după cum se poate observa în Fig. 1.54. Portarul se mișcă pe

orizontală, între barele porții, cu viteza constantă. Mingea este reprezentată printr-un control de anima-

ție de tip Ball, având dimensiunea 5 și culoarea inspirată din jocurile de fotbal, galbenă.

Fig. 1.54 Joc realizat cu App Inventor

Indicatorul de direcție (Fig. 1.55) si indicatorul pentru forța șutului (Fig. 1.56) sunt realizați tot cu con-

troale de animație de tipul Ball. Aceștia execută o mișcare în plan orizontal, respectiv vertical, iar limitele

sunt evidențiate prin indicatoarele din fundal. Butonul Shoot este folosit pentru a lansa mingea către

poartă. Aceasta va avea direcția dată de indicatorul de direcție și forța 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 direcție

Fig. 1.56 Indicator pentru forța șutului

3.2.8.2 Stabilirea acțiunii

Acțiunea jocului este realizată foarte simplu și constă în sincronizarea a patru ceasuri. Ceasul utilizat

pentru mișcarea portarului are intervalul setat la 100 milisecunde. Poziția portarului are ordona-

ta constantă, de valoare 40, în sistemul de coordinate carteziene cu originea în colțul din stânga sus.

Abscisa variază între 104 și 186, bazat pe dimensiunea porții, simulând perfect realitatea. Incrementarea

si decrementarea abscisei se face cu un pas de 3 pixeli, astfel încât, într-o cursă completă, portarul să

acopere suprafața întregii porți.

Fig. 1.57 descrie modul de programare al ceasului portarului. Poziția portarului este stabilită de valoarea

curentă a variabilei globale pozG. La fiecare pas, se verifică dacă mișcarea este spre stânga sau spre

dreapta (dată de valoarea variabilei globale wayG) și dacă, după ajustarea corespunzătoare a poziției

portarului, acesta este între limitele admise.

Forța șutului este dată de poziția 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 împărțit în 11 părți, viteza fiind

incrementată cu pas egal de la poziția 302 spre 255, și decrementată invers. Fig. 1.57 descrie modul de

programare al ceasului asociat forței șutului. Poziția bilei este stabilită de valoarea curentă a variabilei

globale Ball3.y. La fiecare pas, se verifică dacă mișcarea este în sus sau în jos (dată de valoarea variabilei

globale wayy) și dacă, după ajustarea corespunzătoare a poziției bilei, acesta este între limitele admise.


Pagina 71

Fig. 1.57 Stabilirea poziției portarului

Indicatorul de direcție a mingii este programat similar cu cel de stabilire a forței șutului, folosind un ceas

pentru a realiza mișcarea orizontală între punctele 236 si 306, ordonata 320. Intervalul este împărțit la

17, rezultând, astfel, o viteză diferită de deplasare față de indicatorul de forță a șutului. Dacă butonul

Shoot este apăsat când bila se află în centrul intervalului, aceasta va fi șutată perpendicular pe direcția

porții. Cu cât abaterea este mai mare față de centrul intervalului, cu atât mingea se va deplasa mai la

stânga sau mai la dreapta față de centrul porții.

Mingea se deplasează între pozițiile 103 și 190 pe abscisă și 50 și 306 pe ordonată. Viteza este dată de

indicatorul de viteză, în timp ce direcția este influențată atât de indicatorul de direcție, cât și de șut (Fig.

1.59). La fel cum în realitate, un șut puternic este mai puțin plasat, și în cadrul acestui joc un șut cu vite-

ză mai mică va avea șanse mai mari de a nimeri direcția porții.


Pagina 72

Fig. 1.58 Stabilirea forței șutului

Fig. 1.59 Determinarea direcției 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 lângă poartă, va fi afișat 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 ciocnește de portar (Fig. 1.61). În acest caz, sunt oprite toate ceasurile și se

afișează pe ecran mesajul corespunzător.

Evident, fiecare buton are asociată o acțiune proprie. Apăsarea butonului este surprinsă de metoda Click

asociată acestuia. Butonul Retry aduce jocul în stare inițial. Ca urmare, va opri ceasul mingii, va porni

celelalte trei ceasuri (pentru portar, direcție și forță) și va pune mingea la poziția punctului de 11 m.

Butonul Shoot, va opri ceasurile direcției și forței, va determina direcția 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 Acțiunile 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. Interfaţa 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 varietăți de sisteme dependente de timp, in-

clusiv de comunicaţii, 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 facilitățile oferite de Simulink se numără (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 căutarea tuturor semnalelor,

parametrilor, proprietăților și codului generat asociat cu modelul;

blocuri de funcții Matlab încorporate pentru a aduce algoritmi Matlab în Simulink;

moduri de simulare (Normal, Accelerator și Rapid Accelerator) pentru rularea simulărilor în mod

interpretativ sau la vitezele de compilare ale codului C, folosind pași de rezolvare ficși sau varia-

bili;

debuger grafic și analizor pentru analizarea rezultatelor simulării, pentru diagnoza performanței,

precum și a comportamentelor neașteptate 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 consistența 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

execuția modelelor în interiorul său. De asemenea, este foarte folositor pentru depanare. Simulink per-

mite reutilizarea componentelor funcționale și integrarea lor în diverse subsisteme. În aceeași manieră

pot fi refolosite și șabloane de testare utilizate în alte modele. După efectuarea testării, Matlab/Simulink

poate genera un raport automat care poate fi folosit ca documentație pentru rezultatele testării. Nu în

ultimul rând, 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ă, deși n-ar trebui să se întâmple,

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 științifice 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 putând fi un model separat

4.1 Crearea și realizarea modelelor

În Simulink se poate crea, modela și menține 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 reprezentări concise și

corecte ale sistemelor, chiar dacă acestea sunt destul de complexe.

Simulink conține o bibliotecă extensivă de funcții 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 adiționale (disponibile separat) extind Simulink cu funcționalități specifice pentru

aerospațiu, comunicații, radiofrecvență, procesarea sunetelor, procesări video și de imagini și alte apli-

cații. De asemenea, se pot modela și sisteme fizice. Simscape, SimDriveline, SimHydraulics,

SimMechanics şi SimPowerSystems (toate disponibile separat) oferă capabilităţi 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 librării și tragerea lor pe editorul grafic. Co-

nectarea blocurilor se face prin linii, care stabilesc relații matematice între acestea. Aranjarea modelului

se face în editorul grafic prin tehnica drag and drop sau prin funcții 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. Interfața cu utilizatorul din Simulink oferă un control complet asupra

ceea ce este vizibil și poate fi utilizat. Utilizatorul poate adăuga 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, uşor 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 adăuga o interfaţă personalizată pentru un subsistem care ascunde conţinutul ş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 selecţia nivelului de detaliere adecvat la sarcina de proiectare. De exemplu, se pot

utiliza inițial relaţii simple pentru a modela specificaţiile de nivel înalt şi se adaugă relaţii mai detaliate

pe măsură 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

acurateţea simulării, 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 informaţiile conţinute în model. Simulink oferă rezolvitori pentru susținerea simulării unei

game largi de sisteme, inclusiv de timp continuu (analog), timp discret (digital) și hibrid (cu semnal mixt).

Acești rezolvitori pot simula sisteme rigide şi sisteme cu evenimente de stare, cum ar fi discontinuităţi,

inclusiv modificările instantanee în dinamica sistemului. Există posibilitatea de a specifica opţiunile de

simulare, inclusiv tipul şi proprietăţile rezolvitorului, timer-ele de la începutul și sfârșitul simulării şi dacă

se dorește încărcarea sau salvarea datele de simulare. Se pot seta, de asemenea, metodele de optimiza-

re şi informaţii de diagnostic pentru simulare. Diferite combinaţii de opţiuni 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 neaşteptat într-un model. Acesta permite identificarea rapi-

dă a problemelor în model prin rularea pas cu pas, simulând la un moment dat o singură metodă şi exa-

minând rezultatelor după executare acestei metode. Metodele sunt funcţii pe care Simulink le folosește

pentru a rezolva un model la fiecare pas în timpul de simulare. Blocuri sunt alcătuite din mai multe me-

tode.

Fig. 1.65 Depanatorul Simulink


Pagina 78

Depanatorul Simulink permite stabilirea de puncte de oprire (breakpoints), controlul simulării şi afişarea

informaţiilor 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 execuției modelului. În timp ce modelul si-

mulează, se pot afişa informaţii cu privire la stările blocurilor, intrările şi ieşirile acestora şi alte informa-

ţii, precum şi execuția metodelor direct pe model.

După stabilirea opțiunilor 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 următoarele moduri de

simulare (25):

Normal (implicit), simulează interpretativ modelul

Accelerat, mărește viteza de execuție a modelului și generează cod compilat dar și permite utili-

zatorului modificarea unor parametri ai modelului

Accelerat rapid, viteza de simulare este mai mare decât în cazul anterior, interactivitatea mult

mai scăzută și generează cod executabil

4.3 Analiza rezultatelor

Rezultatele sistemului pot fi vizualizate prin afișarea semnalelor generate cu afișorul 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ă înțelegere a comportării un

unui sistem 3D complex, se pot încorpora scene de realitate virtuală, folosind Simulink 3D Animation.

Simulink include unelte pentru generarea de condiții de test pentru validarea performanțelor 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, fără adăugarea de blocuri suplimentare. Simulink

oferă și blocuri de verificare a modelului pentru a verifica dacă ieșirile blocului corespund cu cerințele de

design.

Modelul poate fi documentat foarte ușor. Se pot adăuga adnotații direct pe diagramă, precum și descri-

eri detaliate ale proprietăților blocurilor și ale proprietăților modelului. Blocul DocBlock permite include-

rea unui fișier de documentație ca bloc al modelului. De asemenea, Simulink oferă capabilități de tipări

care permit documentarea cu ușurință a modelului. Cu o singură comandă se poate crea un fișier HTML

care descrie întregul model, inclusiv capturi de ecran ale diverselor niveluri de ierarhie existente în mo-

del, precum și toate specificațiilor 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 simulări î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 paşi: se creează modelul grafic al

sistemului care se doreşte a fi simulat (folosind editorul specializat), model care descrie relaţiile mate-

matice dependente de timp ale intrărilor, ieşirilor şi stărilor 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 inginereşti şi de

simulare a mişcării sistemelor compuse din corpuri rigide, care prezintă diferite grade de libertate, au

anumite poziţii, orientări şi mase. El permite modelarea şi simularea sistemelor mecanice folosind o

serie de unelte pentru specificarea corpurilor şi a proprietăţilor lor, a mişcărilor posibile ale acestora, a

constrângerilor cinematice şi a sistemelor de referinţă ataşate, precum şi iniţializarea şi măsurarea miş-

cării corpurilor. Uneltele de vizualizare ale SimMechanics animează reprezentări simplificate ale sisteme-

lor 3D, înainte şi în timpul simulării, folosind sistemul grafic al MATLAB.

Folosind SimMechanics trebuie parcurse patru etape principale pentru construirea şi rularea modelului

unui sistem:

specificarea proprietăţilor inerţiale ale corpurilor, a gradele de libertate, a constrângerile şi a sis-

temelor de referinţă ataşate corpurilor necesare pentru măsurarea poziţiilor şi a vitezelor;

stabilirea senzorilor şi a elementelor de execuţie pentru a înregistra şi a iniţia mişcările corpuri-

lor şi pentru a aplica forţe sau cupluri;

pornirea simulării prin apelarea elementelor specifice Simulink de rezolvare pentru a calcula

mişcările sistemului, ţinând cont de toate constrângerile impuse;

vizualizarea şi animarea simulării folosind fereastra de vizualizarea SimMechanics.

Exemplul concret la care se va face referire în cele ce urmează prezintă modelul unei mâini umane pen-

tru studiul comportamentului cinematic al acesteia. Pentru o înțelegere mai bună a modelului sunt ne-

cesare câteva precizări privind structura mâinii umane.

4.4.1 Studiul mâinii umane

Mâna umană este compusă din 27 de oase care sunt împărţite î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 acelaşi număr de

falange (trei), exceptând degetul mare care are doar două. Oasele metacarpiene constituie palma şi sunt

ataşate oaselor carpiene. Mişcarea acestora din urmă permite rotaţia mâinii în raport cu braţul. Oasele

metacarpiene prezintă o asimetrie: o suprafaţă semisferică la contactul cu oasele carpiene şi o suprafaţă

sferică pentru conectarea la primele falange.

Articulaţiile mâinii se numesc: articulaţia distal interfalangeală (DIP), articulaţia proximal interfalangeală

(PIP) şi articulaţia metacarpofalangeală (MCP). Fiecare dintre ele este caracterizată de o anume geome-

trie a suprafeţelor de contact şi de un unghi maxim. Mişcările mâinii sunt de diferite tipuri: fiecare deget


Pagina 80

se poate deplasa spre palmă (aducţie) şi dinspre palmă (abducţie), se poate flexa sau extinde. Degetul

mare este capabil şi să se mişte în opoziţie cu celelalte degete.

Fig. 1.66 Mâna umană

Ligamentele din palmă conectează oasele metacarpiene la cele carpiene. Ele pot bloca anumite mişcări

ale oaselor metacarpiene pentru a oferi o structură mai rigidă palmei. Falangele sunt conectate prin

ligamente reduse.

Fig. 1.67 Tendoanele flexoare ale mâinii şi tecile lor

Fig. 1.68 Muşchi şi tendoane ale palmei

Tendoanele conectează muşchii şi oasele, fiind ataşate în mod diferit de acestea (Fig. 1.67, Fig. 1.68,

(28)). Intern, ele sunt făcute din colagen şi sunt elastice, astfel încât sunt capabile să readucă degetele în

poziţia originală după flexare. Ele sunt ataşate diferit de oase şi de muşchi. Tendoanele superficiale

flexoare pornesc de la muşchii antebraţului (Fig. 2.12, (28)): de la primul nivel pornesc tendoanele către


Pagina 81

degetele inelar şi mijlociu, de la nivelul al doilea, tendoanele către 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 mişcă, în secvenţă, falanga mediană şi apoi falanga distală.

Tendoanele de adâncime pornesc tot de la antebraţ, se divid în patru şi sunt ataşate 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 muşchi din partea

superioară a antebraţului ş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 Muşchii care acţionează asupra degetului opozabil

a) muşchi superficiali

b) muşchi de adâncime

c) muşchi superficiali

d) muşchi de adâncime

Fig. 1.71 Muşchi ai antebraţului: a), b) partea interioară (cu podul palmei); c), d) partea exterioară


Pagina 82

Muşchii umani pot aplica forţe prin contractare. Muşchii mâinii sunt împărţiţi în trei grupe (28):

muşchii degetului opozabil (Fig. 1.70), care ocupă partea dinspre radius şi produc eminenţa

tenară;

muşchii degetului mic, care ocupă partea dinspre ulna şi produc eminenţa hipotenară (Fig. 1.68);

muşchii care ocupă zona centrală a palmei (Fig. 1.68).

În mână activează două seturi de muşchi: extrinsec, localizat în braţ şi intrinsec, localizat în mână. Muş-

chii intrinseci sunt responsabili de dexteritatea şi de flexibilitatea mâinii. Tendoanele sunt menţinute

aproape de oase prin intermediul unor teci (Fig. 1.67), care menţin poziţia tendoanelor relativ la falange,

pe linia de acţiune a degetelor. Acestor teci se datorează, de fapt, acţiunea 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 mâna. Un tendon flexor acţionează prin intermediul tecilor, de a lungul

articulaţiilor, pentru a mişca cele trei falange ale unui deget. Un muşchi intrinsec ataşat la falangele

proximale activează ca flexor al articulaţiei metacarpofalangeală şi ca extensor pentru articulaţia

interfalangeală. Degetul opozabil este mişcat prin intermediul a opt muşchi care acţionează de a lungul

articulaţiei de la baza sa (Fig. 1.70). Patru sunt extrinseci şi acţionează individual asupra articulaţiei prin

intermediul unor tendoane lungi care traversează încheietura înainte de a ajunge la degetul opozabil, iar

ceilalţi patru sunt intrinseci. Dintre cei opt muşchi, şase acţionează articulaţia distală. Un tendon de

flexare conectează falanga distală la un muşchi şi transmite falangei forţa produsă de acesta.

Fig. 1.72 Secţiune transversală prin muşchi în zona ante-

braţului

Fig. 1.73 Secţiune transversală prin palmă

Suprafaţa articulaţiilor şi a tecilor (Fig. 1.67 (28)) care protejează tendoanele prezintă un coeficient de

frecare foarte mic. În fiecare punct în care tendonul traversează spaţiul unei articulaţii acţionează ca un

cuplu care are tendinţa de a flexa acea articulaţie. La fiecare articulaţie traversată de către un tendon,

schimbările de poziţie ale articulației utilizează o parte din potenţialul excursiei muşchiului. Dacă un

muşchi activează de a lungul mai multor articulaţii, el trebuie să dispună de o capabilitate foarte mare

de mişcări. Muşchii umani sunt optimi pentru strângere la flexare, nu pentru extensie. Astfel, există mai

mulţi muşchi flexori decât extensori, iar extensorii împreună cu tendoanele lor sunt mai compacţi şi mai

puţin puternici decât flexorii. (26)


Pagina 83

Muşchii sunt elementele de execuţie ale mâinii umane. Structura lor este destul de complexă, fiind alcă-

tuiţi din numeroase fibre (Fig. 1.72 (28)). Ei sunt ataşaţi de oasele adiacente prin tendoane şi induc miş-

care în articulaţiile care se formează acolo unde două oase se întâlnesc. Fibrele din care este compus un

muşchi sunt grupate în unităţi funcţionale numite unităţi motoare. O astfel de unitate motoare este

formată din neuronul motor, axonul acestuia şi din toate fibrele musculare care sunt ataşate de acesta

pentru a primi semnalul de contractare. Un singur muşchi poate avea mai multe unităţi motoare.

Pe măsură ce semnalul primit de la creier pentru contractare creşte, se recrutează noi unităţi motoare şi,

totodată, se creşte frecvenţa de contractare la cele deja recrutate. Toate celulele musculare dintr-o uni-

tate motoare devin active în acelaşi timp. Variind numărul unităţilor motoare active, corpul poate con-

trola forţa contractării musculare. Când un anumit motor se contractă, acesta emite repetitiv câte un

scurt impuls de activitate electrică, denumit potenţial al unităţii motoare în acţiune (motor unit action

potential — MUAP). Acesta poate fi detectat prin intermediul unor electrozi poziționaţi pe suprafaţa

pielii, în apropierea motorului. (29)

Funcţionarea muşchiului poate fi modelată folosind două componente de bază care acţionează î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 funcţie de sarcină, muşchiul arată o creştere

exponenţială în lungime. Când sistemul nervos trimite semnal de contractare, elementele contractile

încep să se scurteze. Părţile elastice din componenta a doua se lungesc încet, astfel încât în tendoane se

înregistrează o creştere uşoară de tensiune. Când elementele contractile revin la poziţia iniţială, sunt

urmate, după o scurtă perioadă, de elementele elastice. Viteza acestui fenomen depinde de forţele

exercitate. Ea este ridicată când forţa este nulă (fără sarcină) şi este foarte scăzută când forţa este ma-

ximă. În cazul mâinii, muşchii au nevoie de 80–200 ms pentru a finaliza o contracţie la viteză maximă.

Sarcina maximă pentru un muşchi variază între 2–5 kg/cm2. (26)

Fig. 1.74 Sistemul senzorial pentru muşchi şi tendoane

Sistemul senzorial al mâinii este de diferite tipuri, fiind prezenţi esteroceptori şi proprioceptori. Elemen-

tele de conversie sunt mecanice, electrice, fotoelectrice şi termoelectrice. Un număr mare de receptori

trimit informaţii continue despre deformarea muşchilor şi a tendoanelor sub acţiunea forţelor aplicate.

Multe dintre semnale nu sunt conştientizate, dar oferă informaţii despre poziţia degetelor. Receptorii

sunt organizaţi î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ă măsoare deformarea

tendoanelor sub acţiunea forţelor. Terminaţiile Ruffini din ţesuturile de conectare ale articulaţiilor sunt

sensibile la flexare şi la extensie (în mână există foarte multe astfel de terminaţii). Semnalele de atingere,

căldură, durere sunt generate de numeroşi receptori din piele.

Sistemul biologic uman este condus de către sistemul nervos, alcătuit din creier şi măduva spinării. La fel

ca în cazul tuturor vertebratelor, controlul mişcării este distribuit în numeroase centre. Muşchiul 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 către centrele motoare din creier, pe de altă

parte. Acţiunile reflexe depind doar de măduva spinării. 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 apariţia stimulului la receptor şi apariţia răspunsului. Pentru re-

flexe simple, acest timp este cuprins între 0,5 şi 1,5 ms;

zona reflexului: zona în care sunt localizaţi 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 intesităţii şi al zonei;

inhibarea reflexului: anumiţi neuroni sunt capabili să inhibe un reflex (spre exemplu, la realiza-

rea unei flexări a unui deget, muşchii exten¬sori sunt inhibaţi).

În funcţie de receptorii implicaţi, reflexele pot fi esteroceptive sau proprioceptive. Reflexul proprioceptiv

cel mai important este reflexul miotatic, care porneşte din fibrele neuromusculare. Acest reflex presu-

pune două faze: o contracţie rapidă, urmată de o contracţie lentă şi lungă, care stabilizează muşchii la o

anumită lungime. Reflexul miotatic invers porneşte de la organele Gorgi, ajunge la centrii spinali unde

inhibă neuronii motori ai muşchiului corespunzător care este relaxat.

4.4.2 Constrângeri ale mâinii umane

Mâna umană (Fig. 1.75 (30)) este un sistem foarte articulat, prezentând 26 de grade de libertate. Siste-

mul mână umană este supus, însă, şi la un număr mare de constrângeri, existând dependenţe între de-

gete şi articulaţii. Pentru a modela articularea degetelor este necesară descrierea structurii cinematice a

mâinii umane. Din acest motiv, scheletul mâinii poate fi abstractizat precum în Fig. 1.76, în care fiecare

deget este considerat un lanţ cinematic cu baza în palmă şi cu fiecare vârf de deget drept efector final

(31).

Fiecare dintre cele patru degete are câte patru grade de libertate. Articulaţiile distal interfalangeală (DIP,

marcată cu A în Fig. 1.75) şi proximal interfalangeală (PIP, marcată cu B în Fig. 1.75) oferă fiecare câte un

grad de libertate, iar articulaţia metacarpofalangeală (MCP, marcată cu C în Fig. 1.75) asigură două grade

de libertate prin flexare şi abducţie (Fig. 1.77 (32)). Structura degetului opozabil este diferită de a celor-

lalte degete, el putându se mişca în opoziţie cu acestea. Articulaţiile interfalangeală (IP, marcată cu D în

Fig. 1.75) şi MCP asigură câte un grad de libertate, iar articulaţia carpometacarpiană (CMC, marcată cu E

în Fig. 1.75) asigură două grade de libertate prin flexare şi abducţie. Cele cinci degete ale mâinii au îm-

preună 20 de grade de libertate. Cele 6 grade de libertate rămase se datorează mişcărilor de rotaţie şi

translaţie ale palmei, cu câte trei grade fiecare.


Pagina 85

Mişcarea unui deget poate fi reprezentată printr un set de variabile articulare. Ea este supusă unor

anumite constrângeri astfel încât, în final, mâna nu poate realiza gesturi arbitrare. Spre exemplu, un

deget nu se poate îndoi foarte mult spre exteriorul mâinii, iar degetul mic nu poate fi îndoit fără a îndoi

şi degetul inelar. Mişcarea naturală a mâinii umane este, implicit, determinată de aceste constrângeri de

mişcare (31). Anumite constrângeri ale mişcării mâinii umane au o reprezentare foarte clară, fiind foarte

des folosite în cercetările curente legate de animarea sistemului mână. Cu toate acestea, majoritatea

constrângerilor de mişcare sunt foarte greu de exprimat printr o formulare matematică.

Constrângerile la care este supusă mâna umană pot fi divizate în trei mari categorii (31):

Constrângerile de tipul I sunt reprezentate de limitările mişcării unui deget datorate anatomiei

mâinii (constrângeri statice).

Constrângerile de tipul II sunt limitările impuse în articulaţii în timpul mişcării (constrângeri di-

namice).

Constrângerile de tipul III includ acele limitări necesare pentru a realiza o mişcare naturală, care,

însă, nu sunt acoperite de stadiul actual al cercetării.

Fig. 1.75 Structura mâinii umane: 1) falanga distală, 2) falan-ga medie, 3) falanga proximală, 4) os metacarpian, 5) ulna, 6)

radius

Fig. 1.76 Abstractizarea scheletului mâinii umane

Fig. 1.77 Articulaţiile unui deget


Pagina 86

4.4.2.1 Constrângeri de tipul I

Aceste constrângeri se referă la limitările domeniului de mişcări ale degetelor determinate de anatomia

mâinii. Se consideră doar domeniul de mişcări care pot fi realizate fără aplicarea unor forţe externe,

precum îndoirea degetelor spre partea exterioară a mâinii folosind cealaltă mână. Acest tip de constrân-

geri se reprezintă cu ajutorul următoarelor inegalităţi (31):

0° ≤ θMCP-F ≤ 90°

0° ≤ θPIP ≤ 110°

0° ≤ θDIP ≤ 90°

-15° ≤ θMCP-AA ≤ 15°

unde:

θMCP-F reprezintă variabila articulară a articulaţie metacarpofalangeale pentru flexare;

θMCP-AA reprezintă variabila articulară a articulaţie metacarpofalangeale pentru abducţie sau

aducţie;

θPIP reprezintă variabila articulară a articulaţiei proximal interfalangeale;

θDIP reprezintă variabila articulară a articulaţiei distal interfalangeale.

O altă constrângere susţine că degetul mic oferă o mişcare de abducţie sau aducţie redusă, motiv pentru

care, pentru acest deget, se foloseşte următoarea aproximare (31):

θMCP-AA = 0

Această aproximare poate determina reducerea unui grad de libertate din cele 20 ale degetelor. De

asemenea, şi articulaţia CMC a degetului opozabil asigură o mişcare de abducţie limitată, motiv pentru

care, de regulă, ea se aproximează astfel (31):

ΘCMC-AA = 0

Drept rezultat, mişcarea degetului mare poate fi caracterizată de trei parametri în loc de patru. Pe lângă

acestea, degetele index, mijlociu, inelar şi mic sunt manipulatoare planare deoarece articulaţiile DIP, PIP

şi MCP ale fiecărui deget se mişcă într-un singur plan (articulaţiile DIP şi PIP oferă un singur grad de liber-

tate, pentru flexare).

4.4.2.2 Constrângeri de tipul II

Acest tip de constrângeri se referă la limitările impuse în articulaţii în timpul mişcării degetelor. Ele sunt

denumite constrângeri dinamice şi pot fi clasificate în constrângeri:

intra deget (între articulaţiile aceluiaşi deget);

inter deget (între articulaţiile dintre degete).


Pagina 87

Constrângerea intra deget cea mai utilizată se bazează pe anatomia mâinii şi stipulează că, pentru a în-

doi articulaţia DIP trebuie îndoită şi articulaţia PIP, pentru cazul degetelor index, mijlociu, inelar şi mic

(Fig. 1.78 (27)). Din punct de vedere formal, afirmaţia anterioară se exprimă astfel (31):

θDIP = 2/3 θPIP

Fig. 1.78 Relaţia dintre articulaţiile DIP şi PIP

Datorită acestei aproximări, modelul care iniţial 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 exprimării poziţiei mâinii folosind constrângerile din relaţiile anterioare. Un

exemplu de constrângere inter deget este următorul: îndoirea degetului mic din articulaţia MCP deter-

mină, în mod natural, şi îndoirea degetului inelar din aceeaşi articulaţie. Până în prezent, însă, acest tip

de constrângeri nu au fost cuantificate sub forma unor ecuaţii.

Fig. 1.79 Constrângerea flexării în cazul articulaţiei metacarpofalangeale


Pagina 88

4.4.2.3 Constrângeri de tipul III

Aceste constrângeri sunt impuse de modul natural în care se mişcă mâna şi sunt destul de dificil de de-

tectat. Constrângerile de tipul III diferă de cele de tipul II prin faptul că ele nu au nicio legătură cu limită-

rile impuse de anatomia mâinii ci, mai degrabă, ele reprezintă un rezultat al mişcărilor naturale şi comu-

ne. Deşi naturaleţea mişcării mâinii 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 acelaşi timp şi nu câte unul pe rând. De asemenea, la flexarea din articulaţia metacarpiană

atunci când degetele sunt flexate împreună, trebuie redusă aducţia pentru a evita forţarea degetelor

(Fig. 1.79) (27). Din păcate, până în prezent, nici acest tip de constrângeri nu a fost cuantificat sub forma

unor ecuaţii.

4.4.3 Modelul cinematic și modelul SimMechanics

După cum s a arătat în paragrafele anterioare, modelarea corpului uman, în general, şi a mâinii umane,

în particular, este un lucru dificil, care implică întotdeauna anumite concesii. Astfel, modelul propus (Fig.

1.80) prezintă câteva diferenţe faţă de modelul natural, rezultate din necesitatea simplificării procesului

de modelare. Palma a fost abstractizată sub forma unui dreptunghi cu lungimea p şi lăţimea 2d1 + d2.

Degetele centrale respectă gradele de libertate şi structura degetelor naturale, sunt paralele între ele şi

plasate la distanţele 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 distanţa

d2 faţă de palmă, în planul palmei şi distanţa d3, pe o axă perpendiculară pe planul palmei. Baza celei de

a doua falange este plasată faţă de baza degetului opozabil la distanţă d5, măsurată pe o axă perpendi-

culară pe planul palmei.

Fig. 1.80 Modelul propus pentru mâna umană

Pentru a putea modela mişcarea degetelor mâinii se foloseşte modelul cinematic direct (Fig. 1.81), care

exprimă mişcarea vârfului fiecărui deget în raport cu sistemul de referinţă fix, ataşat primei cuple cine-

d3

d5

p

p/2

d1

d2

d2

d1


Pagina 89

matice a încheieturii. Pentru variabilele articulare comune tuturor degetelor, 1q , 2q , 3q , s-au stabilit

constrângerile următoare, impuse de limitările domeniului de mişcări ale degetelor, determinate de

anatomia mâinii:

9090 1q 2/2/ 1 q

1515 2q adică 12/12/ 2 q

1515 3q 12/12/ 3 q

Variabilele articulare specifice degetelor centrale, 4q , 5q , 6q , 7q , dat fiind faptul că ele au aceeaşi

structură au valorile stabilite prin relaţiile (2.54):

1515 4q 12/12/ 4 q

900 5q adică 2/0 5 q

1100 6q 18/110 6 q

900 7q 2/0 7 q

În ceea ce priveşte domeniile specifice variabilelor articulare ale degetului opozabil, acestea sunt expri-

mate astfel:

1515 4oq 12/12/ 4 oq

900 5oq adică 2/0 5 oq

900 6oq 2/0 6 oq

Pentru a putea realiza studiul cinematic, este necesar să se atribuie valori tuturor mărimilor care apar în

sistemul cinematic determinat. Pentru aceasta, s-au considerat mărimile specifice unei mâini de adult,

mărimi exprimate de relaţiile următoare.

— mărimi generale:

mcmp 1,010

mcmd 03,031

mcmd 02,022

mcmd 02,023

mcmd 03,035

— degetul opozabil:

mcmf o 035,05,31

mcmf o 025,05,22


Pagina 90

— degetul arătător:

mcmf a 045,05,41

mcmf a 03,032

mcmf a 02,023

— degetul mijlociu:

mcmf m 05,051

mcmf m 035,05,32

mcmf m 025,05,23

— degetul inelar:

mcmf i 05,051

mcmf i 035,05,32

mcmf i 02,023

Fig. 1.81 Modelul cinematic al mâinii umane

q4l

q7m

q6m

q5m

q4m

q6o q5o

q4o

q3

q2

q1

y0 ,z2, x1

L3 L2

d2 d1

d5

d3

z6m 7

L1

p

a

x3m,x4m

x5m

x6m, zdm

z5m

z4m

z3m

f3m

f2m

f1m

f3l

f2l

f1l

f2o

f1o

x3l,x4l

x5l

x6l, xdl

zdl

z6l

z5l

z4l

z3l

xdo,

z6z5o

z4

x4o,

z3o

6

5

4

7

6

5

4

6 5

4

3 2

1

z0, x2

z1, x0

q5l

q6l

q7l


Pagina 91

— degetul mic:

mcmf c 04,041

mcmf c 025,05,22

mcmf c 02,023

Fig. 1.82 Modelul SimMechanics al mâinii umane

Schema rezultată (

Fig. 1.82) a fost implementată ţinându-se cont de următoarele consideraţii:

deoarece se studiază doar mişcările de deschidere şi de închidere ale pumnului, încheietura este

rigidizată. Din acest motiv, în schemă, ea este reprezentată printr-o articulaţie rigidă, de tip

Weld;

sistemul de referinţă fix se situează pe încheietura mâinii, având axele orientate astfel: axa Ox

de-a lungul palmei, pe direcţia degetului mijlociu, axa Oy perpendiculară pe palmă şi axa Oz


Pagina 92

perpendiculară pe celelalte două şi orientată astfel încât 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 acelaşi cu sistemul de referinţă fix. Faţă de acesta, sistemele de re-

ferinţă ale degetelor sunt orientate astfel, pentru a respecta anatomia mâinii umane:

o sistemul de referinţă al degetului mijlociu (CS2) se află la distanţa de 10 cm pe axa Ox

faţă de sistemul fix (lungimea palmei), fără deplasări pe celelalte axe;

o sistemul de referinţă al degetului inelar (CS3) se află la distanţa de 10 cm pe axa Ox şi

de 3 cm pe Oz;

o sistemul de referinţă al degetului mic (CS4) se află la distanţa de 10 cm pe axa Ox şi

de 5 cm pe Oz;

o sistemul de referinţă al degetului arătător (CS5) se află la distanţa 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 distanţa de 5 cm pe axa Ox , de 3 cm

pe axa Oy şi de -5 cm pe Oz.

mişcarea degetelor centrale are loc în jurul axei Oz, spre axa Oy , iar mişcarea degetului opo-

zabil se realizează în jurul axei Oy , spre axa Ox . Valorile pentru unghiurile de rotaţie sunt ge-

nerate de către blocul denumit Comanda. În cazul degetului opozabil, s-a considerat că falanga

proximală realizează doar mişcare de aducţie iar falanga distală acoperă tot domeniul disponibil

pentru flexare;

curbele mişcării sunt captate, pentru fiecare deget în parte, de către un bloc de tip Scope.


Pagina 93

Fig. 1.84 Structura degetelor centrale

Toate degetele centrale au aceeaşi structură, ceea ce diferă este lungimea falangelor (Fig. 1.84). Fiecare

deget central este format din trei corpuri, legate între ele prin articulaţii şi reprezentate de blocurile de

tip Body, denumite Falanga3, Falanga2 şi Falanga1. Mişcarea fiecărui corp este permisă de câte o arti-

culaţie cu unul sau mai multe grade de libertate. Deoarece această schemă urmăreşte simularea mişcări-

lor de închidere şi deschidere a pumnului, mişcarea de aducţie a fost exclusă, astfel că articulaţia

Articulatie3 asigură falangei proximale doar un singur grad de libertate (rotaţie) faţă de palmă. Celelalte

falange sunt legate prin acelaşi tip de articulaţii. Mişcarea are loc în jurul axei Oz.

Fiecare articulaţie mobilă trebuie comandată de către un bloc cu denumirea Joint Actuator. În cazul de

faţă, având trei articulaţii mobile, sunt necesare trei blocuri de comandă: Comanda2, Comanda3 şi Co-

manda4. Fiecare bloc de comandă trimite articulaţiei corespunzătoare un unghi de rotaţie, valoare asi-

gurată de blocul denumit Comanda în

Fig. 1.82.

Mişcarea vârfului degetului faţă de sistemul de referinţă fix, este captată de blocul de tip Body Position

Sensor, sub forma proiecţiilor pe cele trei axe ale sistemului. Blocul Produs generează rezultanta mişcării.

Curbele de mişcare obţinute sunt afişate de către 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), prezentând

doar două falange. Şi în acest caz articulaţia de la bază are doar un grad de libertate (renunţându-se la

mişcarea de flexare).


Pagina 94

Fiecare corp introdus în schemă trebuie configurat corespunzător pentru ca modelul final să funcţioneze

corect. Astfel, în Fig. 1.83 este prezentată fereastra de configurare a corpului Palma. Este permisă speci-

ficarea masei corpului, a sistemului inerţial, a poziţiei sistemului de referinţă asociat corpului, a poziţiei

centrului de greutate şi a poziţiei altor sisteme ataşate 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 menţionate 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 distanţele stabilite prin specificaţiile de

proiectare. În aceeaşi manieră se configurează toate corpurile din model.

a)

b)

c)

d)

e)

Fig. 1.86 Curbele obţinute la închiderea pumnului


Pagina 95

Simulând sistemul care descrie mâna umană, conform cu consideraţiile menţionate, se pot obţine curbe-

le de mişcare pentru cele două situaţii avute în vedere: închiderea şi deschiderea pumnului. Pentru în-

chiderea pumnului, se alimentează blocurile de acţionare a articulaţiilor cu valorile corespunzătoare:

crescătoare, de la valoarea cea mai mică până la valoarea cea mai mare a domeniului specific. Traiectori-

ile de mişcare ale vârfurilor 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

arătător şi e) degetului opozabil.

Simulink pune la dispoziţia utilizatorului şi un mediu grafic de vizualizare a modelelor simulate. Astfel,

Fig. 1.87 prezintă câteva ipostaze din mişcarea de închidere a pumnului, mişcare văzută din perspectiva

planului xOy , iar Fig. 1.88 prezintă aceeaşi mişcare, dar tridimensional:

mâna în poziţia iniţială, deschisă (imaginea a));

poziţii intermediare ale mişcării (imaginile b) şi c));

mâna în poziţia 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 conectării unei lumi virtuale, definită în VRML, la o schemă Simulink,

prin Virtual Reality Toolbox. Această aplicaţie este o soluţie pentru interacţionarea în timp cu modele

virtuale ale sistemelor dinamice. Sunt puse la dispoziţia utilizatorului blocuri care să conecteze direct

semnalele Simulink la modelele virtuale, permiţând, astfel, vizualizarea modelului ca o animaţie tridi-

mensională.

Pentru a asigura un mediu de lucru complet, Virtual Reality Toolbox include şi două componente adiţio-

nale:

— o aplicaţie pentru vizualizarea lumilor virtuale

— o aplicaţie pentru implementarea lumilor virtuale, V-Realm Builder realizat de firma Ligos

Corporation.


Pagina 97

V-Realm Builder este o aplicaţie foarte puternică şi intuitivă, fiind uşor de utilizat chiar şi de către nespe-

cialişti, pentru a crea obiecte 3D şi „lumi” în care acestea să fie văzute. Astfel, folosind facilităţile puse la

dispoziţie de acesta a fost realizat un model al mâinii umane (Fig. 1.89), respectând considerentele

enunţate la realizarea modelului cinematic: degetele centrale au aceeaşi structură, fiind diferite doar

lungimile falangelor componente, iar degetul central este compus doar din două falange, având o poziţi-

onare prestabilită faţă de palmă.

Fig. 1.89 Modelul mâinii umane realizat cu Virtual Reality Builder

Acest model poate fi conectat la modelul realizat în Simulink pentru a obţine datele necesare în scopul

controlării şi animării lumii virtuale. Conexiunea se realizează prin intermediul unui bloc VR Sink adăugat

la schema Simulink (Fig. 1.90), bloc care preia datele din Simulink şi le transmite lumii virtuale. Pentru a

realiza efectiv conexiunea, trebuie specificat fişierul care conţine modelul virtual în fereastra Parameters

a blocului VR Sink (Fig. 1.91). Acest lucru are ca efect apariţia î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 rotaţie, se vor bifa toate căsuţele corespunzătoare rotaţiilor falangelor, ceea ce va determina mar-

carea acestora pe caseta externă a VR Sink drept ieşiri (Fig. 1.90).

În lumea virtuală, rotaţia este definită ca un vector cu patru elemente. Primele trei precizează axa de

rotaţie (spre exemplu, dacă rotaţia se face în jurul axei Oz, atunci vor fi de forma [0 0 1]), iar ultimul re-

prezintă valoarea unghiului de rotaţie. Pentru transmiterea unei poziţii (translaţie) este necesar un vec-

tor cu trei elemente, de forma [x, y, z]. După realizarea conexiunilor care se impun, se porneşte simula-

rea modelului şi mediul de vizualizare permite urmărirea animării modelului virtual. Fig. 1.92 prezintă

patru ipostaze din flexarea mâinii.


Pagina 98

Fig. 1.90 Modelul Simulink al mâinii 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 mâinii 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 specification 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. Dobb’s 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. Gray’s 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.

Date post:	08-Feb-2016
Category:	Documents
Author:	corinacorina
View:	115 times
Download:	3 times

Programare Vizuala

Documents

Program Are Vizuala Si Modelare

Documentare - Comunicare Vizuala

PACHET CONTROL PREOPERATOR CATARACTA...PACHET CONTROL PREOPERATOR CATARACTA /medoptic 150 RON 1 CONSULT OFTALMOLOGIC – cu programare (include: refractometrie, acuitate vizuala, presiune

Manual Identitate Vizuala RADET

educatia vizuala

16 JAVA Introducere in programarea vizuala · 2019-01-01 · doua biblioteci pentru realizarea unei interfete grafice: ... 30.12.2018 Curs - Programare orientată pe obiecte 5 •Pachetele

Functia Vizuala Anatomia Vederii

IITO Curs MIX Ergonomie Vizuala

Identitatea Vizuala a Companiei Dacia

manual de identitte vizuala

Manual ate Vizuala Posdru

Imaginea Vizuala

Manual Identitate Vizuala TRANS editie_revizuita.pdf

Manual POO Si Vizuala

Istoria vizuala a organizatiilor neguvernamentale

SEMIOTICA VIZUALA

Manual identitate Vizuala Media Digitala

Imaginea Vizuala in Publicitate