+ All Categories
Transcript
Page 1: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

 

   

ProgramareVizualăCurs  I n g i n e r i a   S i s t e m e l o r  

 Dr.ing. Loredana STANCIU, PhD   

Page 2: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

 Pagina2

   

Cuprins 

1  PROGRAMAREA VIZUALĂ ..................................................................................................................... 3 

1.1  INTRODUCERE ........................................................................................................................................ 3 

1.2  ISTORIC ................................................................................................................................................ 5 

1.3  STRATEGII ÎN PROGRAMAREA VIZUALĂ ........................................................................................................ 6 

1.4  CLASIfiCAREA LIMBAJELOR DE PROGRAMARE VIZUALĂ ..................................................................................... 8 

1.5  TEORIA LIMBAJELOR DE PROGRAMARE VIZUALĂ ............................................................................................ 9 

1.5.1  Specificarea formală a Limbajelor de Programare Vizuală ........................................................... 10 

1.5.2  Analiza Limbajelor de Programare Vizuală .................................................................................. 11 

1.6  PROBLEMELE LIMBAJELOR VIZUALE ............................................................................................................ 12 

1.6.1  Controlul fluxului.......................................................................................................................... 12 

1.6.2  Abstractizarea procedurală .......................................................................................................... 12 

1.6.3  Abstractizarea datelor ................................................................................................................. 13 

1.7  EXEMPLE DE LIMBAJE DE PROGRAMARE VIZUALĂ .......................................................................................... 13 

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

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

1.7.3  Prograph. Programarea vizuală cu fluxuri de date ....................................................................... 18 

1.7.4  KidSim/Cocoa. Programarea vizuală bazată pe reguli .................................................................. 19 

1.7.5  Cube. Limbaje de programare vizuală 3D ..................................................................................... 23 

1.8  PROGRAMAREA VIZUALĂ ȘI ABSTRACTIZAREA ............................................................................................... 24 

1.9  CONCLUZII PRIVIND PROGRAMAREA VIZUALĂ ............................................................................................... 24 

2  MODELARE CU APP INVETOR ............................................................................................................. 26 

2.1  SISTEMUL DE OPERARE ANDROID .............................................................................................................. 26 

2.1.1  Scurt istoric .................................................................................................................................. 26 

2.1.2  Caracteristici ................................................................................................................................ 27 

2.1.3  Evoluția sistemului Android și impactul său pe piață .................................................................... 28 

2.1.4  Arhitectura Android ..................................................................................................................... 28 

2.1.5  SDK‐ul Android ............................................................................................................................. 30 

2.2  MIT (GOOGLE) APP INVENTOR ................................................................................................................ 31 

2.2.1  Ce se poate face cu App Inventor? ............................................................................................... 31 

2.2.2  Capacități și limitări ..................................................................................................................... 32 

2.2.3  Modul de lucru ............................................................................................................................. 33 

2.2.4  Selectarea componentelor pentru crearea de aplicații ................................................................. 34 

2.2.5  Deschiderea editorului de blocuri și pornirea emulatorului .......................................................... 35 

2.2.6  Componente App Inventor ........................................................................................................... 37 

2.2.7  Blocuri din App Inventor ............................................................................................................... 43 

2.2.8  Exemplu de realizare a unei aplicații cu App Inventor. ................................................................. 46 

3  BIBLIOGRAFIE .................................................................................................................................... 52 

   

Page 3: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

 Pagina3

1 ProgramareaVizuală 

1.1 Introducere

Limbajele de programare convenționale sunt dificil de învățat și  folosit, necesitând abilități pe care 

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

grame 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 pro‐

grame (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ți‐

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

pachetele  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 problemele utilizatorului. Sisteme software ușor de utilizat, precum sistemele de ma‐

nipulare directă (Direct Manipulation) nu fac decât să mărească distanța dintre utilizator și progra‐

mator în condițiile în care codul este mult mai complicat (din cauza suplimentului necesar manipulă‐

rii  interfețelor pentru utilizator),  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 ani‐

lor ’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 secun‐

dă,  care  se modifică  î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 coordonate î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 

încercarea de a comunica cu calculatoarele noastre folosind limbaje de programare textuale? N‐am 

fi mai productivi  ş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 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. 

Page 4: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

 Pagina4

 

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  lu‐

mea înconjură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 artificiale 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 tran‐

smite  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 specifica‐

rea  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 diagrame, 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 dimensiune 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ă unidimensio‐

nală. Astfel, multidimensionalitatea este principala diferență dintre LPV‐uri și limbajele strict textua‐

le. 

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 vizual de programare (MVP). 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 progra‐

mare strict textuale și în linie de comandă reprezentau normalul, astăzi MVP‐urile pentru limbajele 

textuale  tradiționale  au  preluat  controlul  în  lumea  programatorilor.  MVP‐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 accesibilitate al informației pe care metodele vizuale îl pot aduce. MVP‐urile pentru 

limbajele tradiționale 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) 

Page 5: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

 Pagina5

 

1.2 Istoric

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

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

reprezentat  avansuri  în unul dintre  aceste domenii.  Sistemul  revoluționar Sketchpad, dezvoltat de 

Ivan SUTHERLAND, este cel mai bun exemplu în acest sens. Sketchpad, realizat în 1963 pe calculato‐

rul TX‐2 la MIT, a fost considerat prima aplicație de grafică pe calculator. Sistemul permitea utilizato‐

rilor să lucreze cu un creion cu lumină pentru a crea grafice 2D prin combinarea unor primitive sim‐

ple, 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 utili‐

zator  reprezintă  contribuțiile  cele mai  importante  ale  lui  Sketchpad  la  dezvoltarea  LPV‐urilor.  Prin 

definirea  constrângerilor  potrivite,  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 dezvoltarea 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 l‐a reprezentat publicarea în 1975 a tezei de doctorat a lui Da‐

vid CANFIELD‐SMITH  intitulată Pygmalion: A Creative Programming Environment. Această  lucrare a 

constituit puncte de plecare pentru câteva direcții de cercetare în acest domeniu care continuă și în 

ziua de astăzi. Spre exemplu, Pygmalion se baza pe o paradigmă de programare bazată pe icoane în 

care utilizatorul crea, modifica și conecta mici obiecte, denumite icoane, care aveau proprietăți defi‐

nite pentru a realiza calcule. De atunci s‐au adus multe îmbunătățiri acestei metode, însă multe LPV‐

uri încă se bazează 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 mo‐

dul “memorare”, realiza calculele de interes, reseta modul de memorare și primea ca ieșire un pro‐

gram care realiza calcule 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 vizua‐

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

prin demonstrarea pe ecran a acțiunilor dorite). Multe dintre aceste sisteme incipiente au avut avan‐

taje  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” 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 folo‐

sire a programării vizuale doar în anumite domenii software, crescând astfel numărul proiectelor în 

care programarea vizuală ar putea ajuta. În acest sens, tehnici vizuale au fost: 

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

Page 6: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

 Pagina6

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 crea‐

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

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

me 

În curând au început să apară MPV‐uri comerciale de succes. Printre primele exemple au fost Micro‐

soft 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 dia‐

grame) 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ă 

facilitate 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 domeniilor 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), programarea telefoniei şi a mail‐ului de voce (Phone‐

Pro de la Cypress Research) şi programarea simulărilor grafice şi a jocurilor (Cocoa de la Stagecoach 

Software). De asemenea, agenţi pentru generarea de software încep să fie incluşi în software‐ul pen‐

tru calculatoarele personale, permiţând ca macro comenzi care ajută cu sarcini repetitive să fie de‐

duse 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 

varietate 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ă poate  fi  folosită. Un alt  scop este acela de a asigura aceleaşi modalităţi de  îmbunătăţire  în 

dezvoltarea  software  în  general,  precum  cele  deja  disponibile  pentru  programarea  unor  domenii 

specifice. Deşi  toate  acestea  sunt  încă  la  nivel  de  cercetare,  au  apărut  deja  LPV‐uri  comerciale  cu 

caracteristici  necesare pentru programarea de uz  general,  fiind  folosite pentru a produce pachete 

software comerciale. Un exemplu este Prograph CPX de la Pictorius International. (4) 

 

1.3 StrategiiînProgramareaVizuală

În ceea ce priveşte cercetarea în programarea vizuală în general şi în LPV în particular, există o păre‐

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

Page 7: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

 Pagina7

text  într‐o oarecare măsură  într‐un  context multidimensional.  Scopul  lor este de a  aduce  îmbună‐

tăţiri designului  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 expri‐

mat  (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 fo‐

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

aspecte  semantice 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 calcu‐

latoare  î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 valoare specifice în mod direct, prin semantică, în loc să descrie această seman‐

tică textual. 

Explicit: anumite aspecte ale semanticii  sunt explicite  în mediu dacă pot  fi precizate direct 

(textual sau vizual), fără necesitatea ca programatorul să le specifice. Un exemplu îl reprezin‐

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

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

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

presupune 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 

caracterizează 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: 

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

gramatorului.  Un  exemplu  în  acest  sens  îl  reprezintă  diagramele  de  tip  entita‐

te‐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 

interpretoarele 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 

dată când programatorul realizează o editare incrementală a programului, caz în ca‐

re toate valorile afișate pe ecran și afectate de modificare sunt retipărite automat. 

Aceasta asigură consistența dintre starea afișată și starea sistemului dacă singura ac‐

țiune care determină schimbarea stării sistemului este editarea programului. Facili‐

Page 8: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

 Pagina8

tatea de recalculare 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 

evenimente, precum întreruperi de la ceasul de timp al sistemului sau clicuri de ma‐

us,  asigurând  în orice moment acuratețea dintre  datele  afișate  și  starea  curentă a 

sistemului pe tot parcursul rulării. 

 

1.4 ClasificareaLimbajelordeProgramareVizuală

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 pen‐

tru cercetători, care vor putea găsi mai ușor lucrări asemănătoare, ci asigură și o bază pentru compa‐

rarea  ș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 categorii de LPV. Următoarea listă (3) prezintă un sumar al schemei de clasifica‐

re ce va fi dezvoltată pe parcursul 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  programare.  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 di‐

rect prin reprezentarea sa vizuală și nu este niciodată tradus într‐un limbaj intermediar bazat pe text. 

Exemplu de astfel de sistem complet vizual este Prograph. În literatura de specialitate a domeniului, 

această categorie este subdivizată î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ă catego‐

rie 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. Exemple 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ă particula‐

ră 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. 

Page 9: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

 Pagina9

Pe lângă aceste două categorii majore, numeroase LPV‐uri sunt clasificate într‐o varietate de ramifi‐

caț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  sisteme  orientate  pe  constrângeri  sunt  populare  pentru  design  de  simulare,  în 

care programatorul modelează obiectele fizice ca obiecte ale mediului vizual cărora li se impun con‐

strâ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 utiliza‐

tori. Thinglab și ARK, ambele LPV‐uri de simulare, reprezintă exemple de limbaje bazate pe constrân‐

geri. 

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ă 

vizualizeze 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 categoriile menționate anterior se pot găsi atât exemple de LPV‐uri de uz general, cât și limba‐

je speciale pentru aplicațiile unor anumite domenii. 

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

rea limbajelor din categoriile menționate mai sus au dus la unele rezultate care au fost inițial consi‐

derate 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 progra‐

melor și unelte de dezvoltare a interfețelor grafice, precum cele livrate cu numeroase compilatoare 

moderne (precum Microsoft Visual C++). Ambele tipuri de sisteme includ, cu certitudine, componen‐

te vizuale, dar acestea sunt, mai degrabă, aplicații grafice sau generatoare de șabloane decât limbaje 

de programare. (3) 

 

1.5 TeoriaLimbajelordeProgramareVizuală

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

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

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

tea fizică (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 

structurii de bază. 

Page 10: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina10

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

rea sensului de bază. 

Detaliile care urmează sunt restrânse la limbajele vizuale 2D, dar tot ce este expus poate fi generali‐

zat pentru 3D (sau mai mult). 

1.5.1 SpecificareaformalăaLimbajelordeProgramareVizuală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 

concatenate  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 preci‐

zată explicit ca parte a specificațiilor limbajului. Invers, în limbajele de programare vizuală se disting 

trei reguli de construcție care sunt folosite pentru aranjarea icoanelor: concatenare orizontală (nota‐

tă cu &), concatenare verticală (notată cu ^) și suprapunere spațială (notată cu +). 

 

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

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ă obiec‐

te formate printr‐o aranjare spațială a  icoanelor obiect elementare). De fapt,  termenul  icoane ele‐

mentare se referă atât  la  icoanele de proces, cât și  la  icoanele obiect elementare și specifică acele 

icoane care sunt primitive  în  limbaj. Și cum o  imagine (sau  icoană,  în acest caz) valorează 1000 de 

Page 11: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina11

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țio‐

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

Dicționarul 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 precizea‐

ză modul în care icoanele obiect compozite pot fi construite din icoane elementare folosind opera‐

tori de aranjare spațială. Trebuie remarcat faptul că este obligatorie specificarea acestor operatori 

spațiali de compoziție ca elemente terminale deoarece ei nu mai fac parte implicit din definirea lim‐

bajului. 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 rezultate și referințele la obiectele rezultate. 

1.5.2 AnalizaLimbajelordeProgramareVizualăPropoziţiile  vizuale  sunt  construite  din  icoane  elementare  cu  ajutorul  operatorilor  iconici.  Analiza 

sintactică 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 com‐

puse din pixeli. Aceste gramatici descoperă structura unei propoziţii vizuale compunând pi‐

xelii în elemente 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 

expresiilor matematice bidimensionale. Ele sunt  foarte potrivite pentru analiza  sintactică a 

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

este construit prin compararea precedenţei operatorilor într‐un şablon principal şi subdiviza‐

rea şablonului î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 cunos‐

cute. 

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

specificaţ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 vede‐

re computațional. 

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

folosind metode tradiționale de analiză semantică. 

 

Page 12: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina12

1.6 Problemelelimbajelorvizuale

Î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 științifică). 

1.6.1 ControlulfluxuluiLa fel ca în  limbajele de programare convenționale,  limbajele vizuale folosesc două metode pentru 

controlul 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ă con‐

trolul pe parcursul programului. Un avantaj particular al acestei metode îl reprezintă faptul 

că  asigură  o  reprezentare  vizuală  efectivă  a  paralelismului.  Dezavantaj  este  faptul  că  pro‐

gramatorul trebuie să fie atent la modul în care secvențierea operațiilor modifică starea pro‐

gramului, ceea ce nu este 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 

trebuie să prevadă ce calcule se efectuează și nu cum se execută acele calcule. Modificarea 

explicită 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 obiectului 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ă programatorul definește Y ca X+1, atunci această formulare, de fapt, stabileș‐

te explicit că Y trebuie calculat folosind obiectul X, iar sistemul înțelege că valoarea lui X tre‐

buie calculată prima. Astfel, încă este prezentă secvențierea operațiilor, dar ea trebuie dedu‐

să de către sistem și nu definită de programator. În acest caz, sistemul are de rezolvat pro‐

blema dependențelor circulare, care trebuie detectate și semnalizate ca eroare. 

1.6.2 Abstractizareaprocedurală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ține‐

rea 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 procedurale 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 (inclu‐

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

Page 13: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina13

1.6.3 AbstractizareadatelorFacilitățile de abstractizare a datelor sunt  întâlnite doar  în  limbajele de programare de uz general. 

Noțiunea de date abstracte în programarea vizuală este foarte similară cu cea din limbajele de pro‐

gramare 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 Exempledelimbajedeprogramarevizuală

În această secțiune vor fi prezentate câteva exemple de LPV‐uri pentru a demonstra câteva modali‐

tăți prin care au fost implementate strategiile prezentate anterior. 

1.7.1 Chimera.ProgramareavizualăimperativăprindemonstrațieChimera 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 pro‐

gramării anumitor tipuri de sarcini. 

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

poate constata apariția unor sarcini de editare repetitive, caz în care poate indica o secvență de ma‐

nipulări  tocmai  realizate asupra unei  scene ca putând  fi generalizate  și  tratate ca un macro. Acest 

lucru  este  posibil  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. 

 

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 co‐

menzii (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. 

Page 14: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina14

 

Fig. 1.5 Programarea prin demonstrație  în Chimera.  În acest exemplu, utilizatorul a desenat o cutie cu o săgeată  indi‐câ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 

panelului indică numărul de comenzi pe care le reprezintă și poate fi desfăcut pentru a vizualiza pa‐

nelurile  incluse. 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 cu el al scenei. Obiectele în panel sunt distribuite conform cu rolul pe care îl au în 

explicație. Spre exemplu, î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 

(undo) sau reluarea (redo) unei secvențe din aceste operații. Pentru exemplul din Fig. 1.4, se dorește 

aplicarea 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 relevante ș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 ape‐

lează 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 

Page 15: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina15

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 co‐

menzile 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 

folosește  istoricele grafice editabile ca  reprezentare vizuală pentru revizuirea, editarea, generaliza‐

rea programului și raportarea erorilor. Spre exemplu, se consideră problema de aliniere la stânga a 

două dreptunghiuri. Pașii necesari sunt capturați în istoricul grafic din Fig. 1.7. Se creează inițial cele 

două dreptunghiuri (panelurile 1 și 2), după care se activează liniile pentru aliniere de 0 și 90 de gra‐

de (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 selec‐

tează 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ă proce‐

dura î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 paneluri‐

le, 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 istoricu‐

lui pentru declararea argumentului (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. 

Page 16: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina16

 

Fig. 1.9 Fereastra de invocare a unui macro 

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

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

domeniului de aplicare (așa cum este cazul Chimera). Cu toate acestea, sunt și limbaje prin demon‐

strație care nu folosesc inferența și un exemplu este Cocoa. 

1.7.2 Forms/3.ProgramareavizualăbazatăpefoidecalcultabelarForms/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ă para‐

digmă 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. 

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

trate î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. Formulele 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 Definirea 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 concep‐

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

Page 17: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina17

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 defi‐

nite prin formule, iar o instanță a unui tip să fie valoare a unei celule, care poate fi referită ca o celu‐

lă. Î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. Facili‐

tatea „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 meca‐

nismul  de manipulare  directă  pentru  specificarea  elementului  grafic,  deoarece  programatorul  de‐

monstrează 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 programarea va fi mai corectă și/sau accelerată. În studii empirice, programatorii au demonstrat 

corectitudine  mai  ridicată  și  viteză  atât  în  crearea  programului,  cât  și  în  depanarea  lui,  folosind 

Forms/3 în comparație cu o varietate de tehnici alternative. 

1.7.2.1 ExempludecalculalarieiunuipătratînForms/3Fereastra  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  întotdeauna  î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  intro‐

ducere 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 introdu‐

ce 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ă bu‐

tonul asociat tabului formulei pentru celulă. Va apărea un câmp unde se tastează formula (Fig. 1. 14), 

Page 18: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina18

în  cazul  de  față  valoarea 5,  după  care  se  apasă butonul Apply.  Valoarea  celulei  este acum afișată. 

Acesta este un exemplu de răspuns imediat: de fiecare dată când se introduce o formulă toate valo‐

rile afectate sunt reafișate în mod automat. 

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

 Fig. 1. 14 Casetă pentru formulă în care se inserează o 

formulă 

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.ProgramareavizualăcufluxuridedatePrograph a fost conceput în 1983 de către Tomasz Pietrzykowski și Philip T. Cocs (14). Cel de‐al doi‐

lea 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 simu‐

lare 

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 

transmise prin valori, ceea ce permite metodelor să folosească drept intrări, ieșirile de la alte meto‐

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

diagrame de fluxuri de date în cadrul editorului. Clasele, metodele și atributele Prograph sunt repre‐

zentate ș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 transmit spre alte operații până se obține rezultatul final, care este vizualizat. 

Page 19: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina19

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

dinamică.  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 nivelul 3 de timp de răspuns. 

 

Fig. 1.16 Programarea prin fluxuri de date în Prograph. Programatorul folosește operații de nivel scăzut (primitive) pen‐tru a calcula ipotenuza unui triunghi dreptunghic. Prograph permite numirea și compunerea unor astfel de grafuri 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 

explicită a arcelor  în graf) este explicitatea sa privind  relaționările  fluxurilor de date  în  cadrul pro‐

gramului. 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.ProgramareavizualăbazatăpereguliCocoa  (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 domeniul asociat este specificarea simulărilor grafice și jocuri. Cocoa este un limbaj Turing com‐

plet, doar că facilitățile lui nu au fost proiectate pentru programarea de uz general, ci pentru a facili‐

ta accesul copiilor la programarea propriilor simulări. 

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

bele folosesc demonstrația ca modalitate de a specifica semantica. Cu toate acestea, nivelul de timp 

de răspuns este diferit, în Cocoa fiind între 2 și 3. Nu este nivel 3 pentru anumite tipuri de modificări 

ale programului (spre exemplu, adăugarea unor noi reguli) care nu afectează afișarea curentă a vari‐

abilelor  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ă, 

aspectul 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 

Page 20: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina20

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

un ecran Cocoa tipic. 

 

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 

specificarea propriu‐zisă de către programator a acțiunilor care vor fi incluse, după care sistemul le 

generalizează (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 

dimensionat 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  se  interpretează:  „dacă este  spațiu  liber  la  dreapta mea, mă mut  în  el”.  Cum  regulile  sunt 

Page 21: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina21

revizuite la fiecare tact al ceasului, doar această simplă regulă este suficientă pentru deplasarea ca‐

racterului 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 carac‐

terelor, 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 carac‐

ter. Aceste proprietăți  joacă  rolul  instanțelor din  programarea orientată  pe obiecte.  Fig.  1.20  (16) 

prezintă modificarea  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. Pen‐

tru a modifica regula, se folosește butonul Add On pentru acea regulă, care execută acțiunile asocia‐

te regulii, după care permite utilizatorului să demonstreze noi acțiuni. În acest caz, utilizatorul modi‐

fică valoarea din proprietatea hunger din 0 în 1. Sistemul generalizează această demonstrație, dân‐

du‐i sensul „Adună 1 la foamea mea“. Dacă nu este aceasta interpretarea demonstrației, utilizatorul 

îi poate edita descrierea. Cocoa include și un calculator pentru a permite editarea unor reguli com‐

plicate. 

Page 22: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina22

Î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 consi‐

derație.  Apoi,  dacă  regula  nu  poate  fi  aplicată  la  starea  curentă  a  caracterului,  indicatorul  devine 

roșu. Dacă  regula  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) 

 

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

Page 23: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina23

1.7.5 Cube.Limbajedeprogramarevizuală3DCube,  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 re‐

prezentare 2D care folosește aceleași dimensiuni ale ecranului (3). Într‐o vizualizare 3D, programato‐

rul  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 

 

Fig. 1.23 Folosirea programului factorial, după evaluare 

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 cu‐

buri  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 interio‐

rul cubului. Cubul de definire are două porturi conectate la el, unul la stânga și unul la dreapta. Por‐

tul din stânga asigură intrarea, iar portul din dreapta este ieșirea, deși, tehnic vorbind, ambele por‐

turi pot asigura ambele funcții, în Cube porturile fiind bidirecționale. Cele două porturi sunt conecta‐

te prin conducte la cuburile suport în planul de jos al diagramei, care reprezintă cazul de bază al re‐

cursivităț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 portul 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 multiplicat cu valoarea de intrare. Rezultatul este tri‐

Page 24: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina24

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

1.8 Programareavizualășiabstractizarea

Una dintre provocările legate de programarea vizuală o reprezintă scalarea limbajelor pentru a dez‐

volta programe cât mai extinse. Aceasta este o problemă mai mare pentru LPV‐uri decât pentru lim‐

bajele tradiționale textuale din motive legate de reprezentarea, designul și implementarea limbajului 

și noutatea 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 con‐

textului. De asemenea, este dificil de aplicat tehnici dezvoltate pentru limbajele tradiționale, deoa‐

rece 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, ab‐

stractizarea procedurală 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 reprezentative 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 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 compune‐

rea obiectelor complexe din cele simple și definirea modului de vizualizare pe ecran al obiectului. În 

Cocoa, aspectul fiecărui caracter 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 ope‐

rații sau metode. Ambele, Form/3 și Cocoa, asigură și un suport limitat pentru moștenire. 

 

1.9 Concluziiprivindprogramareavizuală

Domeniul limbajelor de programare vizuală abundă cu exemple ale eforturilor de a lărgi accesibilita‐

tea și mări puterea programării calculatoarelor. Deși numeroasele proiecte existente variază în deta‐

liile 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  fundamentelor  teoretice  ale  programării  vizuale  și  eforturile  serioase  depuse  pentru 

Page 25: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina25

dezvoltarea unor clasificări formale 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 repre‐

zenta 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 comu‐

nității de cercetători. LPV‐urile 3D nu doar rezolvă problema includerii unei cantități mari de  infor‐

mații pe un ecran destul de mic, ci și exemplifică sinergia  inerentă dintre limbajele de programare, 

grafica pe calculator și interfețele om‐calculator, ceea ce a fost o marcă a programării vizuale încă de 

la începuturile sale. 

 

   

Page 26: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina26

2 ModelarecuAppInvetor

2.1 SistemuldeoperareAndroid

2.1.1 ScurtistoricAndroid (al cărui logo este prezentat în Fig. 1.24 Logo Android (20)) este o platformă software și un 

sistem de operare pentru dispozitive digitale și telefoane mobile, dezvoltată inițial de compania Go‐

ogle, 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 dez‐

voltate de Google. Aplicațiile scrise în C și în alte limbaje pot fi compilate în cod mașină ARM și exe‐

cutate, dar acest model de dezvoltare nu este sprijinit oficial de către Google. 

 

Fig. 1.24 Logo Android 

În  iulie 2005, Google a achiziționat Android  Inc., o  companie de tip  startup,  cu sediul  în Palo Alto, 

California, 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 ba‐

zat 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 operatorilor 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 demon‐

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

Lansarea platformei Android la 5 noiembrie 2007 a fost anunțată prin fondarea Open Handset Alli‐

ance, un consorțiu de 48 de companii de hardware,  software și de  telecomunicații, printre care  și 

Page 27: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina27

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  li‐

cenț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 proiectul Android, incluzând: Sony Ericsson, Vodafone Group Plc, ARM Hol‐

dings 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 Apa‐

che. Sub licența Apache, producătorii sunt liberi să adauge extensii proprietare, fără a le face dispo‐

nibile comunităț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. 

2.1.2 CaracteristiciPrintre 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, 

Bluetooth ș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 

grafică  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 începând cu 19 februarie 2009. 

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. 

Problemele citate  includeau bug‐uri,  lipsa de documentație,  infrastructura de testare  inadecvată și 

Page 28: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina28

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 Merge‐

Lab, 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 hardwa‐

re neblocate care este destinat dezvoltatorilor avansați. Cu toate că dezvoltatorii pot utiliza un dis‐

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

2.1.3 EvoluțiasistemuluiAndroidșiimpactulsăupepiață“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 inteligen‐

te, 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 produ‐

că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 

trimestru precedent, ajungând la sfârșitul lunii mai la 13%. Această creștere este cu atât mai specta‐

culoasă cu cât Android este singurul sistem de operare mobil care reușește să câștige cota de piață, 

ceea ce înseamnă că Google reușește să fure o bucată foarte mare din piața rivalilor săi. 

2.1.4 ArhitecturaAndroidDiagrama  din  Fig.  1.25  (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, calen‐

dar, hărți, navigator pe Internet, contacte etc. (nivelul aplicații). 

Asigurând o platformă de dezvoltare deschisă, Android oferă dezvoltatorilor posibilitatea de a con‐

strui aplicații complexe și inovative. Aceștia sunt liberi să se folosească de hardware‐ul echipamentu‐

lui, 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  compo‐

Page 29: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina29

nentelor:  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. 

 

Fig. 1.25 Arhitectura sistemului Android 

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 

aplicații (precum Contacts), sau să își partajeze propriile date. 

Un manager de resurse (Resource Manager), care asigură acces la resursele care nu sunt cod 

(șiruri de caractere, grafice, fișiere) 

Un manager de notificare (Notification Manager) care permite tuturor aplicațiilor să afișeze 

alerte pe bara de stare. 

Un manager al activităților (Activity Manager) care managerizează ciclul de viață al aplicații‐

lor și navigare comună backstack (istorie de parcurgere a aplicațiilor pe baza căreia, cu tasta 

back, se poate reveni la activități anterioare). 

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. 

Page 30: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina30

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 

propria  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ționali‐

tăț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, 

managementul memoriei, managementul proceselor etc. Nucleul funcționează și ca un nivel de ab‐

stractizare între hardware și software. 

2.1.5 SDK‐ulAndroidSDK‐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 ru‐

lează 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 ver‐

siune ulterioară. Mediul de dezvoltare  (IDE) suportat oficial este Eclipse  (3.2 sau mai recent), utili‐

zând plug‐in‐ul Android 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, con‐

strui ș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 ecra‐

nul de bază. Instrucțiuni detaliate pentru actualizare sunt disponibile pentru cei care lucrează deja cu 

o versiune 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. 

Pe 9 martie  2009, Google  a  lansat  versiunea  1.1 pentru  telefonul Android Dev. Deși  există  câteva 

actualizări estetice, câteva actualizări cruciale includ suport pentru "căutare prin voce, aplicații con‐

tra cost, remedii pentru ceasul cu alarmă, remediu pentru blocarea la trimiterea gmail, notificări de 

poștă electronică ș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 con‐

tinuată într‐o ramură privată. În scopul de a face acest software public, a fost creată o ramură oglin‐

dă read only, cunoscută sub numele unui desert, anume cupcake. Se crede că numele vine de la Ma‐

rissa 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  introduse  în cupcake  includ modificări  la download manager, platformă, Blue‐

tooth, 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. 

Page 31: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina31

2.2 MIT(Google)AppInventor

Google App  Inventor este un  limbaj de programare vizuală  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, utili‐

zatorul desenează vizual modul în care aplicația va arăta și folosește blocuri pentru a specifica com‐

portamentul aplicației  lui. App Inventor folosește o interfaţă grafică, foarte asemănătoare cu inter‐

faţ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 tele‐

fonului mobil. (23) 

Prin  crearea  lui  App  Inventor  pentru  Android,  Google  a  făcut  cercetări  semnificative  prealabile  în 

programarea educațională. Editorul de blocuri folosește biblioteca Java Open Blocks pentru crearea 

de limbaje de programare cu blocuri vizuale. Open Blocks este distribuit de Massachusetts Institute 

of Technology 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 distri‐

buirea Open Blocks sub licenţă MIT. Blocurile de programare vizuală sunt strâns legate de TNG Star‐

Logo, proiectul STEP al lui Klopfer lui şi Scratch un proiect al MIT Media Laboratory Lifelong Kinder‐

garten 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 folo‐

seşte cadrul de lucru al limbajului de programare Scheme şi dialectul Kawa, dezvoltat de Per Bothner 

şi 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. 

2.2.1 CesepoatefacecuAppInventor?App Inventor permite, ca orice mediu vizual, crearea de aplicaţii pentru Android fără a scrie cod de 

program, prin crearea aplicației  și  specificarea comportamentului său prin configurarea de blocuri. 

Echipa App Inventor a creat blocuri pentru aproape orice se poate face cu un telefon Android, pre‐

cum şi blocuri pentru a face „aproape” programare: variabile pentru memorare, blocuri „for” şi „whi‐

le” pentru repetarea operaților şi condiţii (blocuri ,„if ”), astfel încât aplicația să poată să pună între‐

bă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 

personalizate. 

Page 32: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina32

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 construi 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 componenta 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 

permite utilizatorului să introducă numărul de abdomene făcute în fiecare zi, sau se poate modifica 

o aplicaț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 aseme‐

nea, aplicații de orientare în spațiu. Se pot scrie aplicații care să utilizeze funcţionalități ale telefonu‐

lui 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 volan ș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  App  Inventor 

pentru accesarea 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 nu‐

mă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 construi mai multe aplicaţii doar cu instrumente şi componenta TinyWebDB care oferă o pun‐

te de legătură pentru mai multe elemente de calcul complexe şi servicii web, astfel încât App Inven‐

tor poate fi folosit în colaborare cu programatori back‐end. 

2.2.2 CapacitățișilimităriCapacităţ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şte‐

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

Page 33: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina33

În ceea ce privește limitările App Inventor, acestea sunt: 

interfață cu utilizatorul limitată: constructorul interfeței cu utilizator s‐a îmbunătățit, dar es‐

te încă un pic defectuos și limitat, astfel încât nu se poate construi orice interfaţă de utiliza‐

tor. 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 Inven‐

tor şi vor fi în curând rezolvate. 

acces limitat la funcțiile aparatului: nu există componente pentru toate datele şi funcționali‐

tățile telefonului. De exemplu, nu se pot salva şi prelua fişiere din sistem şi există doar un ac‐

ces 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 creează o procedură MutaXY, ea trebuie să fie legată de o imagine specifică, nu de o ima‐

gine generală. 

accesul limitat la Android Market: aplicațiilor generate de App Inventor le lipsește configura‐

rea necesară pentru includerea direct pe piață. Cu toate acestea, există în prezent o soluție 

pentru publicarea pe piață. 

 

2.2.3 ModuldelucruApp 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.26).  Serverele App  Inventor 

stochează aplicațiile dezvoltate şi oferă, de asemenea, o  formă a managementului versiunilor dez‐

voltate,  prin  urmărirea modificării  (change  tracking).  Practic,  aceasta  înseamnă  că mediul  de  pro‐

gramare face uz de metoda numită cloud computing ‐ utilizatorul/programatorul folosește compute‐

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

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 tes‐

tată în timp ce este construită. Când e gata, poate fi ambalată pentru a produce o aplicaţie de sine 

stătătoare 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 Win‐

dows,  şi  pe modele de  telefon deja  populate  cu Android. Aplicațiile  create  cu App  Inventor  pot  fi 

Page 34: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina34

instalate  pe  orice  telefon  Android.  Înainte  ca  App  Inventor  să  fie  folosit,  este  necesară  instalarea 

pachetului App Inventor pentru computer. 

 

Fig. 1.26 Mediul de dezvoltare App Inventor 

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/,  (App  Inventor clasic 

disponibil până în toamna lui 2014) sau la http://ai2.appinventor.mit.edu (App Inventor 2) unde se 

cere logarea cu contul Gmail. Ceea ce se deschide este App Inventor Designer (Fig. 1.27 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.28), dacă este instalată, în prealabil, Java. 

2.2.4 SelectareacomponentelorpentrucreareadeaplicațiiComponentele App Inventor sunt situate pe partea stângă a ecranului Designer (Fig. 1.27 App Inven‐

tor 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şcare), care funcţionează ca un controler Wii şi detectează deplasarea sau scutura‐

rea  telefonului,  componentele care  fac sau  trimit mesaje  text,  componente care  rulează muzică  şi 

video, componente care obţin informaţii de la situri web etc. 

Page 35: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina35

 

Fig. 1.27 App Inventor Designer 

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 

apare în aplicație. Pentru a vizualiza şi modifica proprietăţile unei componente, ea trebuie selectată, 

mai întâi, din listă. 

 

Fig. 1.28 App Inventor Blocks Editor 

2.2.5 DeschidereaeditoruluideblocurișipornireaemulatoruluiDesigner‐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.28) se rulea‐

ză într‐o fereastră separată. La deschiderea editorului de blocuri din fereastra Designer, un fișier care 

Page 36: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina36

permite computerului să comunice cu un dispozitiv conectat va fi descărcat şi ar trebui să se deschi‐

dă în mod automat. Acest proces poate dura 30 de secunde sau mai mult. În cazul în care nu se des‐

chide 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  AppInventorForAndroidCode‐

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

standard  de  blocuri  necesare  pentru  orice  aplicație  (text,  liste  etc.).  Categoria  Advanced  conține 

blocuri pentru 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 conecta‐

te astfel încât chiar dacă se închide fereastra editorului, toate informațiile din acesta sunt salvate în 

Designer. Când se face click pe butonul Open the Blocks Editor, un nou fișier .jnlp este descărcat pe 

calculator și acesta va fi deschis. În acest fel, editorul de blocuri va conține toate blocurile care fuse‐

seră deja programate în pași anteriori. 

Programatorul are posibilitatea să utilizeze un telefon sau tabletă cu Android sau un emulator. Dacă 

se  selectează emulator  (Fig.  1.29), atunci  încărcarea va dura câteva minute,  timp  în  care nu  se va 

întreprinde nicio acțiune. După pornirea emulatorului, acesta trebuie conectat la editor, prin selecta‐

rea 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 bu‐

toanele de pe emulator, dar dacă butonul nu a fost programat, atunci nimic nu se va întâmpla. Mer‐

gând mai departe, orice modificări aduse aplicației în Designer şi  în editorul de blocuri, acestea vor 

apărea pe emulator. 

 

 

Fig. 1.29 Emulatorul App Inventor 

Page 37: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina37

2.2.6 ComponenteAppInventorFiecare 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 

putând fi doar citite.  În cele ce urmează sunt prezentate doar câteva categorii de componente dis‐

ponibile în App Inventor. Mai multe se pot afla la (24). 

2.2.6.1 ComponentedebazăButton — componentă pe  care utilizatorul o  apasă pentru a  realiza o  acțiune asociată. Butoanele 

detectează când sunt apăsate și își pot modifica aspectul. 

Proprietăți: 

BackgroundColor: culoare pentru fundalul butonului. 

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 boo‐

leană. 

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:  

Page 38: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina38

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. 

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

TextAlignment: stânga, centru, dreapta. 

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 ElementsFrom‐

String  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ă. 

TextAlignment: stânga, centru, dreapta. 

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. 

Page 39: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina39

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ău‐

ga și alte ecrane. 

Proprietăți 

AlignHorizontal: un număr care codifică alinierea pe orizontală a conținutului ecranului. Va‐

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

Aceasta ar trebui să fie PNG sau JPG; 48x48 este o dimensiune bună. În cazul folosirii altor 

imagini decâ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, por‐

trait, 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 fizi‐

că a dispozitivului. Când nu este bifat, înălţimea aplicației va fi constrânsă la înălţimea dispo‐

zitivului. 

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 va‐

lorilor iniţiale şi efectuarea altor operaţiuni de configurare. 

ErrorOccurred(): semnalat atunci când apare o eroare. Este utilizat în prezent pentru un set 

limitat de erori. 

OtherScreenClosed(text otherScreenName, any  result):  închiderea unui alt ecran și  returna‐

rea controlului ecranului curent. 

ScreenOrientationChanged(): modificarea orientării ecranului 

Metode: 

Page 40: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina40

CloseScreenAnimation(text animType): pregătește animația pentru  închiderea ecranului cu‐

rent și întoarcerea la ecranul anterior. Opțiuni valide sunt: default, fade, zoom, slidehorizon‐

tal, 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 proprieta‐

tea 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ă, casetele de text sunt folosite în combinație cu butoane, astfel încât utilizatorul să acțione‐

ze 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ă. 

TextAlignment: stânga, centru, dreapta. 

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 stabi‐

leş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 

Page 41: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina41

aplicație, adică datele stocate vor fi disponibile de fiecare dată când aplicaţia se execută. Un exem‐

plu ar putea fi un joc care a salvat scorul cel mai mare, care este 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ă  î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). 

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‐

tions, 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 tele‐

fon ş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. Va‐

loarea poate fi un text sau o listă. 

GetValue(text tag): citește valoare salvată în tag. Dacă nu e nimic, returnează textul vid. 

2.2.6.2 ComponentedetipsenzorAccelerometerSensor — 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. 

Page 42: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina42

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 modifi‐

că accelerația. 

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 longitu‐

dine,  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 

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

Page 43: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina43

OrientationSensor — este o componentă ce se folosește pentru a determina spaţial orientarea tele‐

fonului. Acesta este o componentă non‐vizibilă care raportează următoarele trei valori, în grade: 

Roll: 0° atunci când dispozitivul este drept, crescând la 90° când dispozitivul este înclinat cu 

partea 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 as‐

tfel î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 în‐

dreptată î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 dispoziti‐

vului. 

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. 

2.2.7 BlocuridinAppInventorÎ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). 

2.2.7.1 Blocuridedefinireprocedure (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 au‐

tomat 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, ulterior, modificat. Acest nume,  la nivel de aplicație, trebuie să fie unic. Fig. 1.30 prezintă 

modul de afișare al acestor blocuri. 

Page 44: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina44

 a)   

b) Fig. 1.30 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 

procedurii se specifică prin plasarea unui astfel de bloc la intrarea arg a procedurii. Numărul de ar‐

gumente nu este limitat, la completarea unuia apărând, de fiecare dată, un port nou. La specificarea 

unui argument, App Inventor va asocia acest argument cu blocul call generat pentru procedură: slo‐

turile 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.31 prezintă modul de afișare a blocurilor name și variable. 

 a) 

 b) 

Fig. 1.31 Bloc de tip nume a) și bloc de tip variabilă b) 

2.2.7.2 HandlerdeevenimenteProgramele App Inventor descriu cum ar trebui se comporte telefonul în anumite circumstanțe: un 

buton 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.32 Handler de evenimente 

Evident, când un eveniment apare, handler‐ul asociat va fi executat. 

2.2.7.3 ComenzișiexpresiiCâ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 co‐

menzilor sunt mov sau albastre.  

Page 45: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina45

 

Fig. 1.33 Exemplu de comenzi 

Anumite comenzi au nevoie de una sau mai multe valori de intrare (cunoscute și sub numele de pa‐

rametrii sau argumente) pentru a‐și putea realiza acțiunea. Spre exemplu (Fig. 1.33), Sound1.Vibrate 

are nevoie 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 ex‐

presii foarte complexe folosind expresii mai simple, prin compunere orizontală (Fig. 1.34). 

 

Fig. 1.34 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.35 Comenzi compuse 

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.35 telefonul va emite un sunet, apoi va vibra, apoi eticheta își va schimba 

culoarea și va afișa textul specificat. Dat fiind faptul că execuția are lor foarte repede, toate acțiunile 

au loc aproape simultan. 

2.2.7.4 AranjareaelementelorpeecranImplicit, componentele sunt aranjate pe verticală. Dacă se dorește modificarea acestui mod de aran‐

jare, atunci se poate folosi una dintre componentele HorizontalArrangement, VerticalArrangement 

sau TabletArrangement din secțiunea ScreenArrangement. 

Page 46: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina46

2.2.7.5 ManipulareastăriicomponentelorFiecare componentă este caracterizată de numeroase proprietăți. Valorile curente ale acestor pro‐

prietăți reprezintă starea componentei. Un program App Inventor poate determina și schimba starea 

oricărei componente prin blocuri specifice de tip getter și setter (exemplu pentru etichetă). 

   Fig. 1.36 Getter‐e și setter‐e pentru etichetă 

2.2.7.6 EvenimentealebutoanelorCel 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. 

2.2.7.7 ComentariiO parte importantă din munca de programare o constituie realizarea unei documentații. App Inven‐

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

 

Fig. 1.37 Adăugarea de comentarii 

2.2.8 ExempluderealizareauneiaplicațiicuAppInventor.În continuare, este prezentată realizarea unui joc (Fig. 1.38) î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. Sco‐

pul 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 tre‐

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

Page 47: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina47

2.2.8.1 ElementevizualeTerenul de  fotbal este reprezentat de un element Canvas  al cărui  fundal este o  imagine cu exten‐

sia .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 ori‐

entarea direcției și stabilirea forței șutului. Portarul este reprezentat printr‐un element de tipul Ima‐

geSprite, având ca fundal o imagine sugestivă a unui portar, după cum se poate observa în Fig. 1.38. 

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.38 Joc realizat cu App Inventor 

Indicatorul  de direcție  (Fig.  1.39)  si  indicatorul  pentru  forța  șutului  (Fig.  1.40)  sunt  realizați  tot  cu 

controale 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 min‐

gea către poartă. Aceasta va avea direcția dată de indicatorul de direcție și forța dată de indicatorul 

de forță al șutului. Butonul Retry repune mingea pe punctual de la 11 m, pentru a se putea efectua 

un nou șut pe poartă. 

 

2.2.8.2 StabilireaacțiuniiAcț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. Incremen‐

tarea si decrementarea abscisei se face cu un pas de 3 pixeli, astfel încât, într‐o cursă completă, por‐

tarul să acopere suprafața întregii porți. 

 

Page 48: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina48

 Fig. 1.39 Indicator de direcție 

 Fig. 1.40 Indicator pentru forța șutului 

 

 

Fig. 1.41 Stabilirea poziției portarului 

Page 49: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina49

Fig. 1.41 descrie modul de programare al ceasului portarului. Poziția portarului este stabilită de va‐

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

 

Fig. 1.42 Stabilirea forței șutului 

 

Fig. 1.43 Determinarea direcției mingii 

Forța șutului este dată de poziția bilei albastre din Fig. 1.40. 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 

Page 50: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina50

fiind  incrementată cu pas egal de  la poziția 302 spre 255, și decrementată  invers. Fig. 1.41 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. 

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ă perpendi‐

cular 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.43). La fel cum în realitate, un șut puternic este mai puțin plasat, și în cadrul acestui joc un 

șut cu viteză mai mică va avea șanse mai mari de a nimeri direcția porții. 

În cazul  în care  între minge și portar există coliziune,  jocul  se  încheie cu mesajul Saved  (Fig. 1.44). 

Dacă mingea  intră  în poartă, mesajul este GOOOOOL,  iar dacă mingea trece pe  lângă poartă, va  fi 

afișat mesajul Ce ratare (Fig. 1.44). 

     Fig. 1.44 Rezultatele posibile 

Metoda  CollidedWith  a  componentei  de  tip  ImageSprite,  care  implementează  portarul,  surprinde 

momentul în care mingea se ciocnește de portar (Fig. 1.45). Î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 

Page 51: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina51

porni ceasul mingii. Fig. 1.46 prezintă, în detaliu, modul în care cele două butoane au fost programa‐

te.  

 

Fig. 1.45 Portarul prinde mingea 

 

Fig. 1.46 Acțiunile asociate celor două butoane 

 

   

Page 52: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina52

 

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

Page 53: Programare Vizuală - aut.upt.roloredanau/teaching/PV/Programare Vizuala.pdf · Programare Vizuală Pagina 4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală

Programare Vizuală 

 

 

  Pagina53

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%20cu

be%20language&source=web&cd=1&sqi=2&ved=0CBkQFjAA&url=http%3A%2F%2Fciteseerx.ist.ps

u.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.67.7089%26rep%3Drep1%26type%3Dpdf&ei=2

22pTr3gC. 

19. Android operating system. Wikipedia. [Online] 

http://en.wikipedia.org/wiki/Android_(operating_system). 

20. What is Android? Android developers. [Online] 

http://developer.android.com/guide/basics/what‐is‐android.html. 

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

22. Google App Inventor. Wikipedia. [Online] http://en.wikipedia.org/wiki/App_inventor. 

23. Reference Documentation. App Inventor. [Online] 

http://appinventor.mit.edu/explore/support.html. 

 

 

  


Top Related