Programare Vizuală
Curs 
 
Ingineria Sistemelor 

 
Dr.ing. Loredana STANCIU, PhD 
 
 
 Programare Vizuală 
 
 
   

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 

   

 
Pagina 2

 Programare Vizuală 
 
 
1 Programarea Vizuală
 

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. 

 
Pagina 3

 Programare Vizuală 
 
 

 
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) 

 
Pagina 4

 Programare Vizuală 
 
 
 

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 

 
Pagina 5

 Programare Vizuală 
 
 
 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 în Programarea Vizuală

Î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 

 
Pagina 6

 Programare Vizuală 
 
 
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‐

 
Pagina 7

 Programare Vizuală 
 
 
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 Clasificarea Limbajelor de Programare Vizuală

Pe  măsură  ce  domeniul  LPV  a  început  să  se  maturizeze,  a  apărut  interesul  creării  unei  clasificări 
standard și robuste pentru tot ce s‐a descoperit. O astfel de clasificare nu este de interes doar 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. 

 
Pagina 8

 Programare Vizuală 
 
 
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 Teoria Limbajelor de Programare Vizuală

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

 
Pagina 9

 Programare Vizuală 
 
 
 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 Specificarea formală a Limbajelor de Programare Vizuală

Un aranjament spațial care constituie o propoziție vizuală reprezintă omologul bidimensional al unui 
aranjament unidimensional de jetoane în limbajele de programare convenționale (textuale). În acele 
limbaje,  un  program  este  exprimat  sub  forma  unui  șir  de  caractere  în  care  jetoane  terminale  sunt 
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 

  Pagina
10
 Programare Vizuală 
 
 
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 Analiza Limbajelor de Programare Vizuală

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

  Pagina
11
 Programare Vizuală 
 
 
1.6 Problemele limbajelor vizuale
În  cele  ce  urmează  vor  fi  prezentate  câteva  dintre  problemele  comune  ale  limbajelor  vizuale  (4). 
Aceste probleme se întâlnesc mai ales în limbajele vizuale de uz general (potrivite pentru a genera 
programe  executabile  de  dimensiuni  rezonabile),  deși  unele  dintre  ele  apar  și  în  limbajele  vizuale 
specifice  unor  anumite  domenii  (proiectate  pentru  domenii  particulare  precum  ingineria  software 
sau vizualizarea științifică). 

1.6.1 Controlul fluxului

La 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 Abstractizarea procedurală

Există două niveluri de abstractizare procedurală. Limbajele de programare vizuală de nivel înalt nu 
sunt limbaje de programare complete deoarece, spre exemplu, nu este posibilă scrierea și menț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.). 

  Pagina
12
 Programare Vizuală 
 
 
1.6.3 Abstractizarea datelor
Facilităț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 Exemple de limbaje de programare vizuală

Î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. Programarea vizuală imperativă prin demonstrație

Chimera este o exemplificare a modului prin care programarea imperativă este suportată în LPV‐uri, 
prin  punerea  programatorului  să  își  demonstreze  acțiunile  dorite.  Sistemul  a  fost conceput de  D.J. 
Kurlander în cadrul tezei sale de doctorat (12). În cazul Chimera, “programatorul” este un utilizator 
final, ca  urmare  este  și  un exemplu  de  LPV destinat îmbunătățirii  nivelului  de accesibilitate al  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. 

  Pagina
13
 Programare Vizuală 
 
 

 
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 

  Pagina
14
 Programare Vizuală 
 
 
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. 

  Pagina
15
 Programare Vizuală 
 
 

 
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. Programarea vizuală bazată pe foi de calcul tabelar

Forms/3 este un exemplu de LPV bazat pe paradigma foilor de calcul tabelar, implementat de către 
Margaret Burnett în 1991, ca prototip al lucrării sale de disertație (13). În acest caz, programatorul își 
realizează programul prin crearea unui formular și specificarea conținutului acestuia. Această 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. 

  Pagina
16
 Programare Vizuală 
 
 
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 Exemplu de calcul al ariei unui pătrat în Forms/3

Fereastra  principală  a  Forms/3  (versiune  recentă  de  implementare)  (13),  prezentată  în  Fig.  1.11, 
apare pe ecran la pornirea aplicației. Formularul System, listat în fereastra principală a formularelor, 
este  î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.12 Caseta de dialog pentru New Form 

 
Fig. 1.11 Fereastra principală a Forms/3 
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), 

  Pagina
17
 Programare Vizuală 
 
 
î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. Programarea vizuală cu fluxuri de date

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

  Pagina
18
 Programare Vizuală 
 
 
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. Programarea vizuală bazată pe reguli

Cocoa  (denumit  inițial  KidSim)  este  un  LPV  bazat  pe  reguli,  în  care  programatorul  specifică  reguli 
pentru demonstrarea unei postcondiții plecând de la o precondiție. „Programatorii“ vizați sunt copiii, 
iar 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 

  Pagina
19
 Programare Vizuală 
 
 
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 

  Pagina
20
 Programare Vizuală 
 
 
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. 

  Pagina
21
 Programare Vizuală 
 
 
Î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 

  Pagina
22
 Programare Vizuală 
 
 
1.7.5 Cube. Limbaje de programare vizuală 3D
Cube,  realizat  de  M.  Najork,  reprezintă  un  avans  important  în  design‐ul  limbajelor  de  programare 
vizuale, fiind primul limbaj vizual 3D. Deoarece programele Cube sunt traduse în reprezentări interne 
mai simple pentru verificare și interpretare, limbajul ar fi mai degrabă unul hibrid. Cu toate acestea, 
utilizatorul nu este expus niciodată la nicio reprezentare textuală, ca urmare este mai corect dacă se 
spune că limbajul este foarte aproape de a fi complet vizual. 

Cube folosește o paradigmă de flux de date pentru construcția programelor. Lucrul în 3D asigură un 
număr de avantaje asupra limbajelor 2D tradiționale. Spre exemplu, lucrul în 3D îi permite sistemului 
să afișeze mai multe informații într‐un mediu cu care este mai ușor de interacționat decât cu o 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‐

  Pagina
23
 Programare Vizuală 
 
 
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 Programarea vizuală și abstractizarea

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 Concluzii privind programarea vizuală

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 

  Pagina
24
 Programare Vizuală 
 
 
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. 

   

  Pagina
25
 Programare Vizuală 
 
 
2 Modelare cu App Invetor
2.1 Sistemul de operare Android
2.1.1 Scurt istoric
Android (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 

  Pagina
26
 Programare Vizuală 
 
 
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 Caracteristici
Printre caracteristicile și specificațiile actuale se numără următoarele (21): 

 platforma Android este adaptabilă la configurații mai mari 
 mașina virtuală Dalvik este optimizată pentru dispozitive mobile 
 navigatorul web disponibil este bazat pe platforma de aplicații open source WebKit 
 biblioteci grafice 2D incluse 
 biblioteci grafice 3D incluse, bazate pe specificația OpenGL ES 1.0 
 suport media 
 software‐ul de baze de date SQLite este utilizat în scopul stocării datelor 
 Android  suportă  tehnologii  de  conectivitate  incluzând  GSM/EDGE,  CDMA,  EV‐DO,  UMTS, 
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 

  Pagina
27
 Programare Vizuală 
 
 
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ția sistemului Android și impactul său pe piață

“Android  ar  putea  deveni  pentru  telefoane  ceea  ce  e  Windows  pentru  PC‐uri.  Sistemul  de  operare 
mobil Android de la Google concurează cu sistemul de operare iPhone în piața telefoanelor 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 Arhitectura Android

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

  Pagina
28
 Programare Vizuală 
 
 
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. 

  Pagina
29
 Programare Vizuală 
 
 
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‐ul Android

SDK‐ul Android include un set complet de instrumente de dezvoltare. Acestea conțin un program de 
depanare,  biblioteci,  un  emulator  de  dispozitiv  (bazat  pe  QEMU),  documentație,  mostre  de  cod  și 
tutoriale. Platformele  de dezvoltare sprijinite în prezent  includ calculatoare bazate pe x86 care 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. 

  Pagina
30
 Programare Vizuală 
 
 
2.2 MIT (Google) App Inventor
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 Ce se poate face cu App Inventor?

App Inventor permite, ca orice mediu vizual, crearea de aplicaţii pentru Android fără a scrie cod de 
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. 

  Pagina
31
 Programare Vizuală 
 
 
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 și limitări

Capacităţile App Inventor includ: 

 accesul la cea mai mare parte a funcționalităților telefonului: convorbiri telefonice, mesaje 
text SMS, senzori de locație, orientare şi accelerare, funcția text‐to‐speech sau recunoaş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)  

  Pagina
32
 Programare Vizuală 
 
 
Î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 Modul de lucru

App Inventor a fost conceput pentru a dezvolta aplicaţii pentru telefoanele cu Android, folosind un 
browser  web  şi  un  telefon  conectat  la  Internet  sau  emulatorul  (Fig.  1.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 

  Pagina
33
 Programare Vizuală 
 
 
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 Selectarea componentelor pentru crearea de aplicații

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

  Pagina
34
 Programare Vizuală 
 
 

 
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 Deschiderea editorului de blocuri și pornirea emulatorului

Designer‐ul este unul dintre cele trei instrumente cheie folosite în crearea de aplicații. Al doilea este 
editorul  de  blocuri,  utilizat  pentru  a  atribui  comportamente  componentelor,  cum  ar  fi  ceea  ce  ar 
trebui să se întâmple atunci când utilizatorul apasă un buton. Editorul de blocuri (Fig. 1.28) se rulea‐
ză într‐o fereastră separată. La deschiderea editorului de blocuri din fereastra Designer, un fișier care 

  Pagina
35
 Programare Vizuală 
 
 
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 

  Pagina
36
 Programare Vizuală 
 
 
2.2.6 Componente App Inventor
Fiecare componentă poate avea metode, proprietăți și evenimente. Majoritatea proprietăților pot fi 
modificate de către aplicații, prin blocurile de citire și  setare pe  care le dețin, restul de  proprietăți 
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 Componente de bază

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:  

  Pagina
37
 Programare Vizuală 
 
 
 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. 

  Pagina
38
 Programare Vizuală 
 
 
 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: 

  Pagina
39
 Programare Vizuală 
 
 
 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 

  Pagina
40
 Programare Vizuală 
 
 
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 Componente de tip senzor

AccelerometerSensor — Această componentă detectează accelerometrul dispozitivului Android care, 
la rândul lui, detectează scuturarea telefonului și măsoară accelerația în 3 dimensiuni. Dacă telefonul 
este  așezat  pe  o  suprafață  plană,  pe  spate,  accelerația  Z  este  9.8m/s2.  Componenta  produce  trei 
valori: 

 XAccel: pozitiv când dispozitivul este înclinat spre dreapta (adică partea stângă este ridicată) 
și negativ când este înclinat spre stânga. 
 YAccel: pozitiv când partea de jos este ridicată și negativ când partea de sus este ridicată. 
 ZAccel: pozitiv când ecranul este orientat în sus și negativ când ecranul este orientat în jos. 

Proprietăți 

 Available: dacă există accelerometru. 
 Enabled: activarea accelerometrului. 
 XAccel: accelerație pe dimensiunea X. 
 YAccel: accelerație pe dimensiunea Y. 

  Pagina
41
 Programare Vizuală 
 
 
 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. 

  Pagina
42
 Programare Vizuală 
 
 
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 Blocuri din App Inventor

În cele ce urmează sunt prezentate principalele tipuri de blocuri care pot fi utilizate pentru realizarea 
unei aplicații cu App Inventor. Materialul complet poate fi găsit la (24). 

2.2.7.1 Blocuri de definire

procedure (procedureWithResult) — grupează o secvență de blocuri care, ulterior, poate fi utilizată 
în mod repetat, ca apel de procedură. La crearea unei proceduri, App Inventor creează în mod 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. 

  Pagina
43
 Programare Vizuală 
 
 

 
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 Handler de evenimente

Programele 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 și expresii

Când este executat un handler de evenimente, de fapt se rulează o secvență de comenzi din corpul 
său. O comandă este un bloc care specifică o acțiune care va fi realizată pe telefon. Majoritatea co‐
menzilor sunt mov sau albastre.  

  Pagina
44
 Programare Vizuală 
 
 

 
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 Aranjarea elementelor pe ecran

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

  Pagina
45
 Programare Vizuală 
 
 
2.2.7.5 Manipularea stării componentelor
Fiecare 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 Evenimente ale butoanelor

Cel mai frecvent eveniment legat de butoane este Click. Alte evenimente asociate sunt LongClick, 
GetFocus și LostFocus. Majoritatea componentelor primesc focusul când sunt atinse și îl pierd când 
nu mai sunt atinse. Butonul este special pentru că, atunci când este atins, lansează evenimentul Click. 

2.2.7.7 Comentarii
O 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 Exemplu de realizare a unei aplicații cu App Inventor.

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

  Pagina
46
 Programare Vizuală 
 
 
2.2.8.1 Elemente vizuale
Terenul  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 Stabilirea acțiunii

Acțiunea jocului este realizată foarte simplu și constă în sincronizarea a patru ceasuri. Ceasul utilizat 
pentru  mișcarea  portarului  are  intervalul  setat  la  100  milisecunde.  Poziția  portarului  are  ordona‐
ta constantă, de valoare 40, în sistemul de coordinate carteziene cu originea în colțul din stânga sus. 
Abscisa variază între 104 și 186, bazat pe dimensiunea porții, simulând perfect realitatea. 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. 

  Pagina
47
 Programare Vizuală 
 
 

   
Fig. 1.39 Indicator de direcție  Fig. 1.40 Indicator pentru forța șutului 
 

 
Fig. 1.41 Stabilirea poziției portarului 

  Pagina
48
 Programare Vizuală 
 
 
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 

  Pagina
49
 Programare Vizuală 
 
 
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 

  Pagina
50
 Programare Vizuală 
 
 
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 

   

  Pagina
51
 Programare Vizuală 
 
 
 

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. 

  Pagina
52
 Programare Vizuală 
 
 
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=https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%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. 

  

  Pagina
53