+ All Categories
Home > Documents > Program Are Vizuala Si Modelare

Program Are Vizuala Si Modelare

Date post: 14-Jul-2015
Category:
Upload: clau-ban
View: 289 times
Download: 0 times
Share this document with a friend

of 92

Transcript

Programare Vizual i Modelare Curs pentru master S i s t e m e I n f o r m a t i c e A p l i c a t e n P r o -d u c i e i S e r v i c i i Dr.ing. Loredana STANCIU, PhD Programare Vizual i Modelare Pagina 2 Cuprins 1PROGRAMAREA VIZUAL .............................................................................................................................. 4 1.1INTRODUCERE ......................................................................................................................................................... 4 1.2ISTORIC .................................................................................................................................................................. 6 1.3STRATEGII N PROGRAMAREA VIZUAL ....................................................................................................................... 8 1.4CLASICAREA LIMBAJELOR DE PROGRAMARE VIZUAL .................................................................................................. 9 1.5TEORIA LIMBAJELOR DE PROGRAMARE VIZUAL ........................................................................................................ 11 1.5.1Specificarea formal a Limbajelor de Programare Vizual....................................................................... 11 1.5.2Analiza Limbajelor de Programare Vizual ................................................................................................ 12 1.6PROBLEMELE LIMBAJELOR VIZUALE ........................................................................................................................... 13 1.6.1Controlul fluxului .......................................................................................................................................... 13 1.6.2Abstractizarea procedural ......................................................................................................................... 14 1.6.3Abstractizarea datelor ................................................................................................................................. 14 1.7EXEMPLE DE LIMBAJE DE PROGRAMARE VIZUAL ........................................................................................................ 14 1.7.1Chimera. Programarea vizual imperativ prin demonstraie ................................................................. 14 1.7.2Forms/3. Programarea vizual bazat pe foi de calcul tabelar ................................................................ 17 1.7.3Prograph. Programarea vizual cu fluxuri de date.................................................................................... 20 1.7.4KidSim/Cocoa. Programarea vizual bazat pe reguli .............................................................................. 21 1.7.5Cube. Limbaje de programare vizual 3D .................................................................................................. 24 1.8PROGRAMAREA VIZUAL I ABSTRACTIZAREA ............................................................................................................. 26 1.9CONCLUZII PRIVIND PROGRAMAREA VIZUAL ............................................................................................................. 27 2MODELARE CU REELE PETRI (19) ................................................................................................................ 28 2.1INTRODUCERE ....................................................................................................................................................... 28 2.2DESCRIEREA REELELOR PETRI ................................................................................................................................. 30 2.3PROPRIETI ALE REELELOR PETRI .......................................................................................................................... 34 2.3.1Accesibilitate ................................................................................................................................................ 34 2.3.2Limitabilitate i siguran ............................................................................................................................ 35 2.3.3Conservativitate ........................................................................................................................................... 35 2.3.4Nivelul de activare ....................................................................................................................................... 36 2.3.5Reversibilitate i starea de pornire ............................................................................................................. 38 2.4METODE DE ANALIZ .............................................................................................................................................. 38 2.4.1Arborele de acoperire .................................................................................................................................. 39 2.4.2Matricea de inciden i ecuaia de stare .................................................................................................. 41 2.4.3Un exemplu................................................................................................................................................... 42 2.5REELE PETRI: CONCLUZII ........................................................................................................................................ 44 3MODELARE CU GOOGLE APP INVETOR ........................................................................................................ 47 3.1SISTEMUL DE OPERARE ANDROID ............................................................................................................................. 47 3.1.1Scurt istoric ................................................................................................................................................... 47 3.1.2Caracteristici................................................................................................................................................. 48 3.1.3Evoluia sistemului Android i impactul su pe pia ................................................................................ 49 Programare Vizual i Modelare Pagina 3 3.1.4Arhitectura Android ..................................................................................................................................... 50 3.1.5SDK-ul Android ............................................................................................................................................. 51 3.2GOOGLE APP INVENTOR ......................................................................................................................................... 52 3.2.1Selectarea componentelor pentru crearea de aplicaii ............................................................................. 54 3.2.2Deschiderea editorului de blocuri i pornirea emulatorului ...................................................................... 55 3.2.3Ce se poate face cu App Inventor? .............................................................................................................. 56 3.2.4Capaciti i limitri ..................................................................................................................................... 57 3.2.5Componente App Inventor .......................................................................................................................... 58 3.2.6Blocuri din App Inventor .............................................................................................................................. 64 4MODELARE CU SIMULINK ............................................................................................................................ 65 4.1CREAREA I REALIZAREA MODELELOR ........................................................................................................................ 66 4.2SIMULAREA UNUI MODEL ........................................................................................................................................ 67 4.3ANALIZA REZULTATELOR.......................................................................................................................................... 69 4.4MODELARE N SIMMECHANICS ................................................................................................................................ 69 4.4.1Studiul minii umane ................................................................................................................................... 70 4.4.2Constrngeri ale minii umane ................................................................................................................... 75 4.4.3Modelul cinematic i modelul SimMechanics ............................................................................................ 79 4.4.4Conectarea la o lume virtual ..................................................................................................................... 87 5BIBLIOGRAFIE .............................................................................................................................................. 90 Programare Vizual i Modelare Pagina 4 1Programarea Vizual 1.1Introducere Limbajele de programare convenionale sunt dificil de nvat i folosit, necesitnd abiliti pe care foar-te muli oameni nu le au. Din acest motiv, interfeele cu utilizatorul de la o gam larg de programe au nceput s vin cu faciliti care s suplineasc i s uureze capabilitile de programare. Spre exemplu, succesul foilor de calcul poate fi parial atribuit abilitii utilizatorilor de a scrie programe (sub form de colecii de formule). Pe msur ce distribuia decalculatoare personalea crescut,foarte muli utilizatori auajunss dein unul, frca mareamajoritate s aib cunotinen a scrieprograme.Eicumprcalculatoareleipa-chetele software fr s fie capabili s aduc omodificare ct de mic software-ului. Pentru a permite utilizatorului final s reconfigureze i s modifice sistemul, pachetele software ar trebuis ofere aceste opiuni, fapt care ar putea induce transformarea sistemului ntr-unul i mai complex fr s rezolve pro-blemele utilizatorului. Sisteme software uor de utilizat, precum sistemele de manipulare direct (Direct Manipulation)nufacdectsmreascdistanadintreutilizatoriprogramatorncondiiilencare coduleste multmai complicat(dincauzasuplimentuluinecesarmanipulrii interfeelor pentru utiliza-tor), chiar dac mai muli utilizatori vor putea folosi software-ul (fiind uor de utilizat). (1) Cel mai bun exemplu de sistem cu manipulare direct este sistemul de operare cu pictograma Recycle Bin. Pentru a terge ceva, utilizatorul selecteaz i duce efectiv cu mausul (prin tehnica drag and drop) elementele n co. Pe de alt parte, oamenii au comunicat mult vreme folosind imagini, ca urmare, pe parcursul anilor 80 i90s-au fcutnumeroase eforturi pentru a pune n valoare abilitatea uman de a procesainformaii vizuale.Spreexemplificare,sepoateconsideraurmtoareasituaie:unompoateurmripeecranul televizorului o imagine i s discearn un ablon constnd n milioane de pixeli pe secund, care se mo-dific n timp i spaiu. Dac, ns, privete imaginea din Fig. 1.1 (2), probabilitatea este aproape nul ca cinevasdeslueascablonulreprezentatde urmtorulsetde numere:unsetde perechiX,Y,unde prima linie reprezint valorile lui X, iar a doua linie valorile lui Y. Chiar i tiind c sunt perechi de coor-donate nplan, majoritateaoamenilor totar avea probleme na discerne un ablon din acest exemplu numeric. Dac, ns, aceste puncte sunt desenate, ablonul reiese rapid, aa cum se poate observa n Fig. 1.2 (2). 4742931226885105133137 58100954612613318110868 Fig. 1.1 Perechi de coordonate X,Y Din aceste considerente limbajele de programare vizual ntreab: de ce, atunci, s persistm n ncerca-rea de a comunica cu calculatoarele noastre folosind limbaje de programare textuale? N-am fi mai pro-ductivi i puterea de calcul a calculatoare moderne n-ar fi mai accesibil la o gam mai larg de oameni, dac am fi capabili de a instrui un computer prin simpla desenare a imaginilor pe care le vedem cu ochii Programare Vizual i Modelare Pagina 5 minii noastre atunci cnd ne gndim la soluiile unor probleme speciale? Evident, susintorii limbajelor de programare vizual susin c rspunsul la ambele ntrebri este afirmativ. Fig. 1.2 Puncte ntrebrile de mai sus subliniaz motivarea principal a cercetrii nlimbajele de programare vizual. n primul rnd, majoritatea oamenilor gndesc i i amintesc lucrurile n imagini. Ei se refer lalumea n-conjurtoare ntr-un mod grafic i folosesc imaginile drept componente principale n gndirea creatoare. Reducndsaunlocuind n totalitate necesitatea traducerii ideilorvizuale nreprezentri textuale artifi-ciale poate ajuta la diminuarea problemelor de nvare. Mai mult, numeroase aplicaii se mpac foarte bine cu metodele de dezvoltare vizual. (3) Programarea vizual este programarea n care mai mult de o dimensiune este folosit pentru a transmi-te informaie. Exemple de astfel de dimensiuni adiionale sunt: folosirea obiectelor multi-dimensionale, folosirea relaionrilor spaiale, sau folosirea dimensiunii timp pentru specificarea relaiilor semantice de tip naintedup. Fiecare multi-dimensional saurelaie este un jeton(token), aa cum nlimbajele de programare textual tradiionale fiecare cuvnt este un jeton. O colecie de unul sau mai multe astfel de jetoaneeste o expresievizual.Exemplede expresii vizuale folosite nprogramareavizual includdia-grame,schie,icoanesaudemonstraiide aciunirealizatecuobiecte grafice. Atuncicnd sintaxa unui limbaj de programare (semnificativ din punct de vedere semantic) include expresii vizuale, limbajul de programare este un limbaj de programare vizual (LPV). Dei limbajele de programare textual tradiionale adeseori ncorporeaz sintax bidimensional ntr-un sens foarte limitat o dimensiune x pentru a transmite ir de caractere liniar legal n limbaj i o dimen-siuneycarepermitespaiereaopionalaliniilorndocumentdoarunadintreacestedimensiuni transmite semantic, pe cnd cea de-a doua dimensiune a fost limitat la o informaie legat de tastarea relaiilor spaiale astfel nct s poat fi exprimate ntr-o gramatic unidimensional. Astfel, multidimen-sionalitatea este principal diferen dintre LPV-uri i limbajele strict textuale. Cndexpresiilevizualesuntfolositentr-unmediudeprogramaredreptofacilitatedeeditarerapid pentrugenerareadecod,acestaestedenumitmediudeprogramarevizual(MPV).Acestemediide programarevizualpentrulimbajeledeprogramaretextualtradiionalereprezintotrecerentre LPV-uri i cunoscutele limbaje textuale. Spre deosebire de acum civa ani, cnd mediile de programare stricttextualein liniedecomandreprezentaunormalul, astzi MPV-urilepentrulimbajeletextuale tradiionale au preluat controlul n lumea programatorilor. MPV-urile comerciale pentru limbajele tradi-ionalesuntgnditepentruprogramatoriideprofesie.Acetiprogramatorifolosesclimbajeletextuale pe care le cunosc deja i sunt ajutai de tehnici de interfaare grafic cu utilizatorul i de nivelul de acce-sibilitatealinformaieipecaremetodelevizualelpotaduce.MPV-urilepentrulimbajeletradiionale Programare Vizual i Modelare Pagina 6 reprezint o modalitate de a transfera avansurile datorate cercetrii din LPV-uri n practic prin aplicarea acestor noiideilimbajelor tradiionale dejafamiliareprogramatorilor. nacestfel sepermite migrarea gradual de la tehnicile de programare textuale ctre cele vizuale. (4) 1.2Istoric Programarea vizual a aprut din combinarea graficii pe calculator, a limbajelor de programare i a inte-raciunii om-calculator. Nu este o surpriz, deci, faptul c dezvoltrile din programarea vizual au repre-zentatavansurinunuldintre aceste domenii. Sistemulrevoluionar Sketchpad,dezvoltat deIvan SUT-HERLAND,estecelmaibunexemplunacestsens.Sketchpad,realizatn1963pecalculatorulTX-2la MIT, a fost considerat prima aplicaie de grafic pe calculator. Sistemul permitea utilizatorilor s lucreze cu un creion culuminpentru a creagrafice 2D princombinareaunor primitivesimple, precumliniii cercuri, i aplicarea unor operaii (precum copierea) i a unor constrngeri asupra geometriei formelor. Interfaa sa grafic i suportul pentru specificarea constrngerilor de ctre utilizator reprezint contribu-iile cele mai importante ale lui Sketchpad la dezvoltarea LPV-urilor. Prin definirea constrngerilor potri-vite, utilizatorii puteau realiza structuri complexe precumlegturi mecanice complicate i s le mite n timp real. Fratele lui Ivan SUTHERLAND, William, a adus, de asemenea, o contribuie important la dez-voltarea programrii vizuale n 1965, cnd a folosit TX-2 pentru a implementa un limbaj vizual simplu de fluxuri de date. Sistemul permitea utilizatorilor s creeze, s depaneze i s execute diagrame de fluxuri de date ntr-un mediu vizual unificat. UrmtoruljalonngenezaLPV-urilorlareprezentatpublicarean1975atezeidedoctorataluiDavid CANFIELD-SMITH intitulat Pygmalion: A Creative Programming Environment. Aceast lucrare a constitu-it puncte de plecare pentru cteva direcii de cercetare n acest domeniu care continu i n ziua de as-tzi. Spre exemplu, Pygmalion se baza pe o paradigm de programare bazat pe icoane n care utilizato-rulcrea,modificaiconectamiciobiecte,denumiteicoane,careaveauproprietidefinitepentrua realiza calcule. De atunci s-au adus multe mbuntiri acestei metode, ns multe LPV-uri nc se bazea-z pe aceast paradigm. Pygmalion a folosit i conceptul de programare prin exemple, unde utilizatorul i arta sistemului cum s realizezeosarcinntr-osituaiespecific,iarsistemulfoloseaaceastinformaiepentru agenera un program care s realizeze sarcina n cazuri generale. n acest sistem, utilizatorul seta modul memorare, realiza calculele de interes, reseta modul de memorare i primea ca ieire un program care realiza calcu-le asupra unor intrri arbitrare. (3) Iniial, dezvoltarea programrii vizuale a avut locndou direcii: abordri vizuale asupra limbajelor de programaretradiionale(precumdiagrameleexecutabiledefluxuridedate)inoiabordrivizuale de programarecares-audeprtatsemnificativdeabordriletradiionale(precumprogramareaprinde-monstrareape ecrana aciunilordorite).Multedintre acestesisteme incipiente au avutavantaje care preau interesante i intuitive cnd au fost utilizate pe programe jucrie, dar care au indus probleme dificilecnds-ancercatextinderealornprogramerealiste.Acesteproblemeauduslaodecdere Programare Vizual i Modelare Pagina 7 incipientaprogramriivizuale,fcndu-ipemuliscreadcprogramareavizualestenepotrivit pentru industrie, fiind doar un exerciiu academic. Pentru a depi aceste probleme, cercettorii din domeniul vizual au nceput s dezvolte ci de folosire a programrii vizuale doar n anumite domenii software, crescnd astfel numrulproiectelor ncare pro-gramarea vizual ar putea ajuta. n acest sens, tehnici vizuale au fost: ncorporate pe larg n medii de programare care suport limbaje de programare textuale folosite pentru a nlocui specificaiile textuale din interfeele grafice pentru utilizator folositepentruarealizaformeleelectronicealediagramelordiningineriasoftwarencrearea i/sau vizualizarea relaionrilor dintre structurile de date folosite pentru a combina vizual unitile programate textual pentru a construi noi programe n curnd au nceput s apar MPV-uri comerciale de succes. Printre primele exemple au fost Microsoft Visual Basic (pentru Basic) i sistemele VisualWorks (pentru Smalltalk) de la Cincom. Alt grup de MPV-uri comerciale,orientatenprincipalpe programarea de tiplarge-grained,suntunelteleCASE(Computer-Aided Software Engineering) care suport specificaii vizuale (spre exemplu, folosind diagrame) ale rela-iilor dintre modulele programului, culminnd prin generarea automat a codului. Alicercettoridinprogramareavizualaupreferatoaltcale.Eiaucontribuitladezvoltareaacelor proiectepotrivitepentruprogramareavizualprinimplementareasistemelorspecificeunoranumite domenii. Folosind aceast strategie, prin determinarea unui nou domeniu care s suporte aceast facili-tate au crescut numrul proiectelor care pot fi programate vizual. Un beneficiu imediat a fost creterea nivelului de accesibilitate pentru utilizatorii care ajungeau n contact cu acele sisteme. Dezvoltatorii do-meniilorspecificepentruLPViMPVaudescoperitc,gsindmodalitideascrieprogramepentru rezolvarea unei anumite probleme dintr-un domeniu, au eliminat multe dintre dezavantajele metodelor iniiale,deoarece au lucrat directnstilulde comunicare aldomeniuluirespectiviaufolositartefacte vizuale(spre exemplu,anumiteicoane saumeniuri) cares reflecte nevoile particulare, diagramele de rezolvare a problemelor i vocabularul specific aceluidomeniu,nefiind niciodat obligai s prseasc acel stil de comunicare. Aceast abordare a dat rezultate att n cercetare, ct i pe pia. Astzi exist LPV-uri i MPV-uri pentru diverse domenii: programarea achiziiilor de date de laborator (LabView de la NationalInstruments),programareavizualizrilorspecifice(AVSdelaAdvancedVisualSystems),pro-gramarea telefoniei i a mail-ului de voce (PhonePro de la Cypress Research) i programarea simulrilor grafice i a jocurilor (Cocoa de la Stagecoach Software). Deasemenea, ageni pentrugenerarea desof-twarencepsfieincluinsoftware-ulpentrucalculatoarele personale,permindcamacro comenzi careajutcusarcinirepetitivesfiededuseprinmanipulrileutilizatoruluifinal(canChimera,de exemplu). ncercarea iniial de a concepe LPV-uri cu destul putere i generalitate pentru a rezolva orice varie-tate de probleme de programare reprezint un domeniu de cercetare n plin dezvoltare. Un scop al acestei cercetri l reprezint mbuntirea continu a modalitilor prin care programarea vizual poa-te fi folosit. Un alt scop este acela de a asigura aceleai modaliti dembuntire n dezvoltareasof-twaren general,precumcele dejadisponibilepentru programarea unordomenii specifice. Deitoate Programare Vizual i Modelare Pagina 8 acestea sunt nc la nivel de cercetare, au aprut deja LPV-uri comerciale cu caracteristici necesare pen-tru programarea de uz general, fiind folosite pentru a produce pachete software comerciale. Unexem-plu este Prograph CPX de la Pictorius International. (4) 1.3Strategii n Programarea Vizual nceeace privete cercetarea nprogramarea vizual n generalinLPV nparticular,exist o prere greit precumc acestea audreptscopeliminarea textului.nfapt,majoritateaLPV-urilor includtext ntr-o oarecare msur ntr-un context multidimensional. Scopul lor este de a aduce mbuntiri desig-nului limbajului de programare. ansa de a atinge acest deziderat se bazeaz pe simplul fapt c LPV-urile au mai puine restricii sintactice privind modul n care un program poate fi exprimat (de ctre calculator sau de ctre om), situaie ce ofer o libertate de a explora mecanismele programrii care nu a mai fost atins din simplul motiv c nu era posibil n trecut. elurile care s-au dorit a fi atinse prin cercetarea n LPV-uri au fost de a: face programarea mai accesibil unei audiene particulare mbunti corectitudinea cu care oamenii realizeaz sarcinii de programare mbuntii viteza cu care oamenii realizeaz sarcini de programare. Pentru a atinge aceste scopuri, exist patru strategii utilizate n LPV-uri: Concret: este opusul lui abstract i presupune exprimarea unor aspecte ale programului folosind instane particulare. Spre exemplu, unui programator i se permite specificarea unor aspecte se-manticeprivindunobiectsauo valoarespecifice,sausistemuls poatafianmod automat efectele unui poriuni din program asupra unui obiect sau valori specifice. Direct: n contextul manipulrii directe, aceast strategie este descris ca fiindsentimentul pe care l are cineva manipulnd direct un obiect. Din perspectiv cognitiv, direct n calculatoare nseamn o distan ct mai mic ntre scop i aciunile necesare pentru a atinge acest scop. Un exemplu n acest sens ar fi s i se permit programatorului s manipuleze un obiect sau o valoa-re specifice n mod direct, prin semantic, n loc s descrie aceast semantic textual. Explicit: anumite aspecte ale semanticii sunt explicite n mediu dac pot fi precizate direct (tex-tualsauvizual),fr necesitatea caprogramatorul s lespecifice.Unexemplul reprezintsis-temulcare genereaz explicit relaionri ntre fluxurile de date (saupri dinprogram) prin de-senarea unor arce direcionale ntre variabilele relaionate ale programului. Rspuns vizual imediat (feedback vizual): n contextul programrii vizuale, acest deziderat pre-supune afiarea imediat a efectelor produse prin editarea programului. Tanimoto (5) a introdus termenul de liveness (adaptat n limba romn ca timp de rspuns), termen care caracterizea-zctdeimediatesterspunsulsemanticiioferitnmodautomatpeparcursulprocesuluide editarea a programului. Tanimoto descrie patru niveluri de timp de rspuns: Programare Vizual i Modelare Pagina 9 oNivelul 1: nu se aplic nicio semantic, deci sistemul nu ofer niciun rspuns programa-torului.Unexemplunacestsenslreprezintdiagrameledetipentitate-relaionare pentru documentaie. oNivelul 2: programatorul poate s obinrspuns despre o poriune a programului, dar acest rspuns nu este automat. Compilatoarele suport minimal acest nivel, iar interpre-toarele ceva mai mult deoarece nu sunt restricionate doar la valorile finale de ieire. oNivelul 3: un rspuns semantic incremental este asigurat n mod automat de fiecare da-t cnd programatorul realizeaz o editare incremental a programului, caz n care toate valorileafiate peecrani afectatede modificaresuntretipriteautomat.Aceasta asi-gur consistena dintre starea afiat i starea sistemului dac singura aciune care de-termin schimbarea strii sistemului este editarea programului. Facilitatea de recalcula-re automat a foilor de calcul tabelar suport acest nivel de timp de rspuns. oNivelul 4: sistemul rspunde la editrile programului ca n nivelul 3, dar i la alte eveni-mente, precum ntreruperi de la ceasul de timp al sistemului sau clicuri de maus, asigu-rnd n orice moment acurateea dintre datele afiate i starea curent a sistemului pe tot parcursul rulrii. 1.4Clasicarea Limbajelor de Programare VizualPe msur ce domeniul LPV a nceput s se maturizeze, a aprut interesul crerii unei clasificri standard i robuste pentru tot ce s-a descoperit. O astfel de clasificare nu este de interes doar pentru cercettori, care vor putea gsi mai uor lucrri asemntoare, ciasiguri obaz pentru compararea i evaluarea diferitelorsisteme.Aceastclasificaresedatoreazunornumeimportantedindomeniu,incluznd pe Chang, Shu sau Burnett, care s-au strduit s identifice caracteristicile care definesc principalele catego-rii de LPV. Urmtoarea list (3) prezint un sumar al schemei de clasificare ce va fi dezvoltat pe parcur-sul acestui subcapitol: Limbaje vizuale pure Sisteme hibride (text i vizuale) Sisteme de programare prin exemplificare Sisteme orientate pe constrngeri Sisteme bazate pe formulare n fapt, aceste categorii nu sunt mutual exclusive, numeroase limbaje putnd fi ncadrate la mai mult de o categorie. n contextul acestui curs, cea mai important categorie o reprezint limbajele pur vizuale. Aceste limbaje sunt caracterizate de faptul c ele se bazeaz pe tehnici vizuale pe toat durata procesului de programa-re. Programatorul manipuleaz icoane sau alte reprezentri grafice pentru a-i crea programul care, apoi, estedepanatiexecutatnacelaimediuvizual.Programulestecompilat directprinreprezentareasa vizual i nu este niciodat tradus ntr-un limbaj intermediar bazat pe text. Exemplu de astfel de sistem Programare Vizual i Modelare Pagina 10 complet vizual este Prograph.n literatura de specialitate a domeniului, aceast categorie este subdivi-zat n seciuni precum limbaje cu icoane i fr icoane, orientate pe obiect, funcionale i imperative. Un subset important al LPV ncearc s combine elementele vizuale cu cele textuale. Aceast categorie de sisteme hibride include att sistemele n care programele sunt create vizual i apoi translatate ntr-un limbaj textual de nivel nalt, ct i sistemele care folosesc elemente grafice ntr-un limbaj textual. Exem-ple din aceast categorie includ Rehearsal World i rezultatul cercetrii lui Erwing i a echipei sale (6). n RehearsalWorld,utilizatorulantreneazsistemulsrezolveoproblemparticularprinmanipularea unor actori grafici, dup care sistemul genereaz un program Smalltalk pentru implementarea soluiei. Erwing a dezvoltat extensii la limbajele C i C++ care permit programatorilor s insereze n cod diagrame. Spre exemplu, se poate defini textual ostructur de date de tip list nlnuit, dup care serealizeaz asupra listei operaii (precum tergerea unui nod) prin desenarea pailor n cadrul procesului. Pe lng aceste dou categorii majore, numeroase LPV-uri sunt clasificate ntr-o varietate de ramificaii. Spre exemplu, o parte dintre LPV-uri se aseamn cu Pygmalion, permind utilizatorului s creeze i s manipulezeobiectegraficecucaresnveesistemulsrealizezeoanumitsarcin.iRehearsal World, pomenit n paragraful anterior, sencadreaz n aceast categorie de programare prinexemple. AlteLPV-urise bazeaz pe manipulareaconstrngerilor, creat de Sutherland n Sketchpad.Acestesis-teme orientate pe constrngeri sunt populare pentrudesign de simulare, n care programatorul mode-leazobiectelefizicecaobiectealemediuluivizualcroraliseimpunconstrngerignditescopieze comportamentul legilor naturale (precumgravitatea).Deasemenea,sistemeorientatepe constrngeri semai folosesc indezvoltarea deinterfeegrafice pentruutilizatori. ThinglabiARK, ambeleLPV-uri de simulare, reprezint exemple de limbaje bazate pe constrngeri. CtevaLPV-uriaumprumutatmoduldevizualizareimetaforeledeprogramaredelafoiledecalcul tabelar.Acestelimbaje potficlasificate dreptLPV-uribazatepe formulare.Eleneleg programarea ca modificarea n timp a unui grup de celule interconectate, deseori permind programatorului s vizuali-zezeexecuiaprogramuluicapeosecvendestridiferitealecelulelorcareprogreseazntimp. Form/3 este un exemplu de astfel de LPV. Este important de evideniat faptul c n fiecare dintre catego-riile menionate anterior se pot gsi att exemple de LPV-uri de uz general, ct i limbaje speciale pentru aplicaiile unor anumite domenii. Domeniulprogramriivizuales-adezvoltatfoarte multnultimiiani.Dezvoltarea continuirafinarea limbajelor din categoriile menionate mai sus au dus la unele rezultate care au fost iniial considerate ca fcnd parte din domeniul vizual, dar ulterior au fost reclasificate ca apropiate de domeniu pentru c nu exemplific,defapt,programareavizual.AcesteLPV-uriorfaneincludsisteme deanimarefolosind algoritmi, precum BALSA, care asigur display grafic interactiv al execuiei programelor i unelte de dez-voltare a interfeelor grafice, precum cele livrate cu numeroase compilatoare moderne(precum Micro-soft Visual C++). Ambele tipuri de sisteme includ, cu certitudine, componente vizuale, dar acestea sunt, mai degrab, aplicaii grafice sau generatoare de abloane dect limbaje de programare. (3) Programare Vizual i Modelare Pagina 11 1.5Teoria Limbajelor de Programare Vizual Pentru a stabili un cadru pentru discuiile teoretice privind limbajele de programare vizuale, este nece-sar prezentarea ctorva definiii (7): icoan (icoan generalizat): un obiect cu reprezentare dual: partea logic (sensul) i partea fi-zic (imaginea). sistem iconic: un set structurat de icoane relaionate. propoziie iconic (propoziie vizual): o aranjare spaial a icoanelor pentru sistemul iconic. limbaj vizual: un set de propoziii iconice construit pe baza unei sintaxe i a unei semantici date. analiz sintactic (analiz spaial): analiza unei propoziii iconice pentru determinarea structu-rii de baz. analizsemantic(interpretarespaial):analizauneipropoziiiiconicepentrudeterminarea sensului de baz. Detaliilecare urmeaz sunt restrnse lalimbajele vizuale 2D, dar tot ce este expus poate fi generalizat pentru 3D (sau mai mult). 1.5.1Specificarea formal a Limbajelor de Programare Vizual Unaranjamentspaialcareconstituieopropoziievizualreprezintomologulbidimensionalalunui aranjamentunidimensionaldejetoanenlimbajeledeprogramareconvenionale(textuale).nacele limbaje, un program este exprimat sub forma unui ir de caractere n care jetoane terminale sunt conca-tenate pentru a forma o propoziie ale crei structur i sens sunt determinate prin analiz sintactic i semantic. Astfel,regula de construcieeste implicitn limbajinutrebuiesfie precizatexplicit ca parte a specificaiilor limbajului. Invers, nlimbajele de programare vizualse distingtrei reguli de con-strucie care sunt folosite pentru aranjarea icoanelor: concatenare orizontal (notat cu &), concatenare vertical (notat cu ^) i suprapunere spaial (notat cu +). Pentrua puteaformalizalimbajeledeprogramarevizual,trebuiefcut distinciadintreicoanelede proces(careexprimcalcule)iicoaneleobiect.Acesteadinurmpotfisubdivizatenicoaneobiect elementare (identific obiecte primitive n limbaj) i icoane obiect compozite (identific obiecte formate printr-o aranjare spaial a icoanelor obiect elementare). De fapt, termenul icoane elementare se refer att la icoanele de proces, ct i la icoanele obiect elementare i specific acele icoane care sunt primiti-ve n limbaj. i cum o imagine (sau icoan, n acest caz) valoreaz 1000 de cuvinte, toate aceste concepte suntilustratenFig.1.3, careprezint ctevaicoanedinsetul deicoaneHeidelberg(8)iopropoziie vizual complet.Un limbaj de programare vizual este specificat de o triplet de forma (DI,G0,B), unde DI este dicionarul de icoane, G0 este gramatica i B este o baz de cunotine specific unui anumit domeniu (9). Diciona-ruldeicoaneestesetuldeicoanegeneralizate,fiecarefiindreprezentatprintr-operechedeforma (Xm,Xi),cu o parte logicXm (sensul)iopartefizicXi (imaginea). GramaticaG0precizeaz moduln careicoaneleobiectcompozitepotficonstruitedinicoaneelementarefolosindoperatoride aranjare spaial. Trebuie remarcat faptul c este obligatorie specificarea acestor operatori spaiali de compoziie Programare Vizual i Modelare Pagina 12 ca elemente terminale deoarece ei nu mai fac parte implicit din definirea limbajului. Baza de cunotine B conine informaii specifice domeniului necesare pentru construirea sensului propoziiei vizuale dorite. Aceasta conineinformaii privind numele evenimentelor, relaii conceptuale, numele obiectelorrezul-tate i referinele la obiectele rezultate. Fig.1.3Cteva icoane dinsetul Heidelberg. Icoane obiect elementare:(a)un caracteri(b)uncaracterselectat. Icoane de proces: (c) operaia de inserie i (d) operaia de tergere. Icoane obiect compozite: (e) un ir de caractere (compus din carac-tere) i (f) un ir selectat (compus dintr-un caracter i dou caractere selectate). Propoziie vizual (g) reprezentnd nlocuirea unui subir ntr-un ir. 1.5.2Analiza Limbajelor de Programare Vizual Propoziiile vizuale sunt construite din icoane elementare cu ajutorul operatorilor iconici. Analiza sintac-ticapropoziiilorvizuale(cunoscutisubdenumireadeanalizspaial(10))sebazeazpecteva abordri (7): Gramatici pentru procesarea imaginilor: iniial gndite pentru distribuirea imaginilor digitale pe o reea de ptrate, aceste gramatici se bazeaz pe faptul c imaginile digitale sunt compuse din pixeli. Aceste gramatici descoper structura unei propoziii vizuale compunnd pixelii n elemen-tevizualerecognoscibile(linii,arceetc.)(11).Aceastmetodestefolositoarecndunsistem iconictrebuies recunoasc icoane cuoanumittoleran deeroare (spre exemplu, digiidin scrisul de mn). Gramaticidepreceden:aceste gramatici de analizspaial pot fi folosite pentru analizaex-presiilor matematice bidimensionale. Ele sunt foarte potrivite pentru analiza sintactic a propo-ziiilorvizualeconstruitedinicoaneelementareioperatoriiconici.Arboreledeanalizeste Programare Vizual i Modelare Pagina 13 construitprincompararea precedeneioperatorilorntr-unablonprincipalisubdivizareaa-blonului ntr-unul sau mai multe abloane secundare. Gramaticiindependentedecontextigramaticidependentede context:acestegramaticisunt folosite pentru a determina compoziia propoziiile vizuale folosind formalisme cunoscute. Gramatici gen graf: acestea sunt, de departe cele mai puternice (dei mai puin eficiente) speci-ficaii ale limbajelor vizuale. Aceste formalisme prevd cele mai multe mijloace pentru stabilirea unorrelaiicontextualeimarepartedincercetarearecentn acest domeniuafost dedicat ncercrii de a face analiza cu gramatici de acest tip fezabile din punct de vedere computaional. Arborele de analiz determinat printr-una dintre metodele enunate anterior este analizat ulterior folo-sind metode tradiionale de analiz semantic. 1.6Problemele limbajelor vizuale n cele ce urmeaz vor fi prezentate cteva dintre problemele comune ale limbajelor vizuale (4). Aceste problemese ntlnesc mai alesnlimbajelevizualede uzgeneral(potrivitepentru agenera programe executabilededimensiunirezonabile),deiuneledintreeleaparinlimbajelevizualespecificeunor anumite domenii (proiectate pentrudomenii particulare precum ingineria software sauvizualizareati-inific). 1.6.1Controlul fluxului La fel ca n limbajele de programare convenionale, limbajele vizuale folosesc dou metode pentru con-trolul fluxului n programe:Metodaimperativ:nacestcaz,programulvizualrealizeazunasaumaimultediagramede control al fluxului sau diagrame de flux de date, care indic modul n care se realizeaz controlul pe parcursul programului. Un avantaj particular al acestei metode l reprezint faptul c asigur o reprezentare vizual efectiv a paralelismului. Dezavantaj este faptul c programatorul trebuie s fie atent la modul n care secvenierea operaiilor modific starea programului, ceea ce nu es-te o caracteristic dorit pentru sistem (mai ales dac este destinat unor nceptori) Metoda declarativ: este o alternativ la metoda imperativ i presupune c programatorul tre-buie s prevad ce calcule se efectueaz i nu cum se execut acele calcule. Modificarea explici-tastriiesteevitatprinfolosireaatribuiriisingulare:programatorulcreeazunnouobiect prin copierea unuia existent i precizarea diferenelor dorite i nu prin modificareastrii obiec-tului existent. De asemenea, n loc s specifice o secven de modificrii ale strii, programatorul defineteoperaiiprinspecificareadependenelordintreobiecte.Spreexemplu,dacprogra-matorul definete Y ca X+1, atunci aceast formulare, de fapt, stabilete explicit c Y trebuie cal-culat folosind obiectul X, iar sistemul nelege c valoare lui X trebuie calculat prima. Astfel, n-c este prezent secvenierea operaiilor, dar ea trebuie dedus de ctre sistem i nu definit de programator. n acest caz, sistemul are de rezolvat problema dependenelor circulare, care tre-buie detectate i semnalizate ca eroare. Programare Vizual i Modelare Pagina 14 1.6.2Abstractizarea procedural Exist dou niveluri de abstractizare procedural. Limbajele de programare vizual de nivel nalt nu sunt limbajede programare completedeoarece,spre exemplu,nueste posibilscriereai meninerea unui ntregprogramntr-unastfeldelimbaji,inevitabil,existimodulenonvizualecaresuntinclusen limbaj. Aceast metod de programare vizual este ntlnit ndiversesisteme orientate pe un anumit domeniu, precum uneltele de mentenan software i mediile de vizualizare tiinific. De cealalt parte sunt limbajele vizuale de nivel sczut care nu permit programatorului s combine n modulele procedu-ralelogicfingranulat.Aceastmetodologieestefolositnlimbajeorientatepedomeniispecifice, precum simulatoarele logice. Limbajele de programare vizual de uz general acoper ntregul spectru de faciliti de programare, pornind de la proprieti de nivel sczut (incluznd condiionrile, recursivitatea, iteraia) la proprieti de nivel ridicat care permit combinarea logicii de nivel sczut n module abstracte (proceduri, clase, biblioteci etc.). 1.6.3Abstractizarea datelor Facilitile de abstractizare a datelor sunt ntlnite doar n limbajele de programare de uz general. Noi-unea de date abstracte nprogramareavizualeste foarte similar cu cea din limbajele de programare convenionale, cusingura deosebire ctipurilede dateabstractetrebuie definitevizual (inu textual), au o reprezentare vizual (iconic) i asigur un comportament vizual. 1.7Exemple de limbaje de programare vizual naceastseciunevorfiprezentatecteva exemplede LPV-uri pentrua demonstracteva modaliti prin care au fost implementate strategiile prezentate anterior. 1.7.1Chimera. Programarea vizual imperativ prin demonstraie Chimera este o exemplificare a modului prin care programarea imperativ este suportat n LPV-uri, prin punerea programatorului s i demonstreze aciunile dorite. Sistemul a fost conceput de D.J. Kurlander n cadrul tezei sale de doctorat (12). n cazul Chimera, programatorul este un utilizator final, ca urmare este i un exemplu de LPV destinat mbuntirii nivelului de accesibilitate al programrii anumitor tipuri de sarcini. Domeniul Chimera este editarea grafic. Pe msur ce un utilizator final lucreaz la o scen grafic, poa-te constata apariia unor sarcini de editare repetitive, caz n care poate indica o secven de manipulri tocmai realizate asupra unei scene ca putnd fi generalizate i tratate ca un macro. Acest lucru este po-sibildeoareceistoriculaciunilor utilizatoruluiesteprezentatfolosind o tehnic debenzidesenate, iar utilizatorulpoateselectapaneluridinistoric.Istoriculfoloseteacelailimbajvizualcainterfaa,deci utilizatorulleva nelegefrprobleme. Spreexemplu,Fig. 1.4a) prezint oilustraieconinnddou ptrate i o sgeat. Istoricul generat prin crearea ilustraiei este prezentat n Fig. 1.5. Programare Vizual i Modelare Pagina 15 Fig. 1.4 Dou versiuni ale unei scene simple. Scena initial (a) i modificat (b) Primul panel al Fig. 1.5nfieaz activarea grilei din panelul de control al editorului. Numele comenzii (Toggle-Grids) apare deasupra panoului. Al doilea panel prezint un dreptunghi creat n scena editorului cu ajutorul comenzii Add-Box. n panelul trei dreptunghiul este selectat, n caseta Text Input este tastat oculoare(galben)iesteinvocatcomandaSet-Fill-Color.Acestpanelestempritpentru a vizualiza att partea de control, ct i parteade editare. Urmtoarele paneluri prezint modificri ale grosimii i culorii marginii dreptunghiului, adugarea unei linii paralel cu dreptunghiul i a nc dou linii deasupra acesteia pentru a forma o sgeat. A doua parte a istoricului nfieaz adugarea unui nou dreptunghi, tragerea sgeii pn la acest dreptunghi, rotirea sgeii pentru a-i alinia baza cu primul dreptunghi i, n final, ntinderea sgeii pentru a atinge primul dreptunghi. Fig.1.5ProgramareaprindemonstraienChimera.nacestexemplu,utilizatoruladesenatocutie cuosgeatindicnd spre ea (ca ntr-o diagram), iar aceast demonstraie este prezentat dup realizarea ei printr-o serie de paneluri. Acest set de demonstraii poate fi generalizat ntr-un macro pentru utilizarea sa ulterioar.Pentru a faceistoricelemaiscurte imaisimplude neles, sefolosescmai multestrategii.Maimulte operaiinruditeseunescntr-unsingurpanel.Spreexemplu,paneluldoiconinemaimulteoperaii: selectarea unei scene obiect i modificarea culorii fundalului pentru obiectele selectate. Eticheta panelu-lui indic numrulde comenzi pe care le reprezint i poate fi desfcut pentru a vizualiza panelurile in-cluse. Panelul doi se deschide n primele dou paneluri prezentate n Fig. 1.6. Pentru ca istoricul s nu fie foartencrcat,fiecare panelarat doar obiectele careparticip noperaiilesale icontextul adiacent Programare Vizual i Modelare Pagina 16 cu el al scenei. Obiectele n panel sunt distribuite conform cu rolul pe care l au n explicaie. Spre exem-plu, n primul panel sunt importante caseta pentru marcaj i eticheta ei, motiv pentru care sunt eviden-iate, dar nu i celelalte elemente de control ale panelului. Fig. 1.6 Folosirea istoricului pentru modificarea unei scene: (a) panourile selectate pentru refolosire, (b) noi operaii adugate n istoric Istoricul grafic editabil poate fi folosit pentru revizuirea operaiilor dintr-o sesiune, pentru anularea (un-do) sau reluarea (redo) unei secvene din aceste operaii. Pentru exemplul din Fig. 1.4, se dorete aplica-reapentru dreptunghiul desusacomenzilorcarestabilescculoareade umplere,grosimeaiculoarea linei la fel ca la dreptunghiul de jos. Se selecteaz dreptunghiul de jos, se caut n istoric panelurile rele-vanteise selecteazi ele(ncazulexempluluide fa,ultimeletrei paneluridinFig.1.6),panelurile selectatefiindevideniatecuetichetealbepefundalnegru.npasulurmtorseapeleazoperaia Redo-Selected-Panels, iar dreptunghiul de sus se va modifica n mod corespunztor. Istoricele grafice editabile din Chimera reduc repetiia prin faptul c ofer o interfa pentru operaia de reluare a operaiilor. Chimera are i un mecanism pentru inserarea de operaii noi n orice punct al unui istoric. Istoricele potfi fcuteeditabile,ceeace transformfiecarepanelstaticntr-uneditor grafic.n acest fel, panelurile pot fi modificate, iar comenzile invocate i propag modificrile nntreg istoricul. Pentru ainseraocomandnounmijloculunuiistoric,sistemulanuleaztoatecomenzileulterioare paneluluiafectat,executnoilecomenzi,dupcarelerefacepeceleanulate.Spreexemplu,dacse dorete modificarea sgeii (Fig. 1.6 b), se modific ultimul panel din primul rnd al istoricului din Fig. 1.5. Semodificacestpanelinualtulpentruc,ulterior,sgeatanumaiestealiniatcuaxelegrilei,iar modificarea ar fi mult mai dificil. Dup propagarea acestor modificri, o nou scen va fi disponibil (Fig. 1.4 b). Fig. 1.7Istoric grafic prezentnd crearea i alinierea a dou dreptunghiuri Chimera include i o component de programare prinexemple, sau macro-uriprinexemple,care folo-seteistoricelegraficeeditabilecareprezentare vizual pentrurevizuirea,editarea,generalizareapro-gramului i raportarea erorilor. Spre exemplu, se consider problema de aliniere la stnga a dou drep-tunghiuri. Paii necesari sunt capturai n istoricul grafic din Fig. 1.7. Se creeaz iniial cele dou dreptun-Programare Vizual i Modelare Pagina 17 ghiuri (panelurile 1 i 2), dup care se activeaz liniile pentru aliniere de 0 i 90 de grade (panelurile 3 i 4)iseselecteaz coluldinstngasusaldreptunghiuluidejos(panelul5)icoluldindreaptajosal dreptunghiuluidesus(panelul6)pentrugenerareaacestorlinii. Lafinal seselecteaz dreptunghiul de sus i se trage pn ajunge la intersecia celor dou linii. Fig. 1.8 Fereastra pentru construirea macro-ului, care conine un macro pentru alinierea la stnga a dou dreptunghiuri Dac se dorete generalizarea acestei proceduri i ncapsularea ei ntr-un macro, nu se repet procedura ntr-un mod special de nvare, ci se parcurge istoricul, se selecteaz panelurile relevante i se executcomanda de transformare n macro. Pentru exemplul anterior, se selecteaz toate panelurile, cu excep-ia celor de creare a dreptunghiurilor, deoarece ele vor fi argumente al macro-ului. Va aprea o fereastr de construcie a macro-uluiconinnd panelurile selectate. n pasulurmtor se vor alege argumentele, prinselectareaobiectelordorite(celedoudreptunghiuri),sevordenumiisevainvocacomanda Make-Argument. Efectul va fi adugarea a dou paneluri la nceputul istoricului pentru declararea argu-mentului(Fig.1.8).Pentruafolosimacro-ululterior,pentruunaltsetdedreptunghiuri,vaapreao fereastr de invocare (Fig. 1.9) ce va permite selectarea i vizualizarea argumentelor. Fig. 1.9 Fereastra de invocare a unui macro Chimera folosete inferena pentru determinarea versiunii generalizate a unui macro. Folosirea inferen-ei este un lucru comun n limbajele prin demonstraie, iar succesul ei depinde de limitabilitatea dome-niului de aplicare (aa cum este cazul Chimera). Cu toate acestea, sunt i limbaje prin demonstraie care nu folosesc inferena i un exemplu este Cocoa. 1.7.2Forms/3. Programarea vizual bazat pe foi de calcul tabelar Forms/3esteunexempludeLPVbazatpeparadigmafoilordecalcultabelar,implementatdectre MargaretBurnettn 1991, caprototip allucrriisalede disertaie(13).nacestcaz,programatoruli realizeaz programul prin crearea unui formular i specificarea coninutului acestuia. Aceast paradigm este folosit uzual n foile de calcul tabelar comerciale, unde formularul este sub form de gril marcat, iar coninutul este specificat prin formulele celulelor. Programare Vizual i Modelare Pagina 18 Programele Forms/3 includ formulare (foi de calcul tabelar) cu celule, doar c celulele nu sunt ncastrate ntr-o gril. Un programator Forms/3 creeaz un program manipulnd direct celulele pentru a le plasa pe formularidefinindoformul pentrufiecarecelul prinfolosirea uneicombinaii flexibilede indicare, tastareigesturi (Fig.1.10). Calculeleunuiprogram suntdeterminate completde acesteformule.For-mulele se combin ntr-o reea (unidirecional) de constrngeri, iar sistemul asigur n mod continuu c toate valorile afiate pe ecran satisfac aceste constrngeri. Fig.1.10DefinereasuprafeeiunuiptratfolosindceluledetipcalcultabelariformulenForms/3.Tipurilegraficesunt suportatecavalorideprimclas,iarprogramatorulpoatecreacelulacuformulaptratuluifiedesenndunptrat,fie tastnd textual specificaiile (spre exemplu, box 30 30)Forms/3 este un limbaj Turing complet. Scopul lui este s mreasc domeniul de utilitate al conceptului defoidecalcultabelarprinsuportulfuncionalitiloravansatenecesarepentruprogramare.Astfel, suport faciliti precum grafic, animaie i recursivitate, dar fr a recurge la macrouri de modificare a strii sau conexiuni cu limbajele de programare tradiionale. Spre exemplu, Forms/3 ofer o colecie de tipuri bogat i extensibil prin faptul c permite ca atributele unui tip s fie definite prin formule, iar o instan a unui tip s fie valoare a unei celule, care poate fi referit ca o celul. n Fig. 1.10, o instan a tipului box a fost specificat prin desenarea grafic. Aceast specificare poate fi modificat, dac este necesar,prinntindereaelementuluigraficprinmanipularedirect.nambelecazuriesteasiguratun rspuns vizual imediat, conform nivelului 4 de timp de rspuns. Facilitatea concret este prezent prin faptul c elementul grafic rezultat este vzut imediat ce suficiente formule au fost oferite pentru a face acest lucru posibil. Facilitatea direct este prezent prin mecanismul de manipulare direct pentru spe-cificareaelementuluigrafic,deoareceprogramatoruldemonstreazspecificaiiledirectpeelementul grafic creat. Grupul int al Forms/3sunt viitoriiprogramatori, adic aceia a cror treabva fi screeze aplicaii, daracrorformarenuapusaccentpelimbajeledeprogramaretradiionaleactuale.Unscopallui Forms/3 a fost s reduc numruli complexitatea mecanismelor necesare pentru programarea aplica-iilor, cu sperana c programatorilor le va fi mai uor dect dac ar folosi limbajele tradiionale, iar pro-gramarea va fi mai corect i/sau accelerat. n studii empirice, programatorii au demonstrat corectitu-Programare Vizual i Modelare Pagina 19 dine mai ridicat i vitez att n crearea programului, ct i n depanarea lui, folosind Forms/3 n com-paraie cu o varietate de tehnici alternative. 1.7.2.1Exemplu de calcul al ariei unui ptrat n Forms/3Fereastra principal aForms/3(versiune recent de implementare)(13),prezentatnFig.1.11,apare pe ecran lapornirea aplicaiei.FormularulSystem,listat nfereastraprincipalaformularelor,este n-totdeauna ncrcatlapornirea sistemului. Pentru acrea unformular nouseapasbutonulNew Form, aciune urmat de apariia unei ferestre de dialog (Fig. 1.12) pentru specificarea numeluiformularului. Dup crearea unui nou formular, acesta apare listat n fereastra principal. Fig. 1.11 Fereastra principal a Forms/3 Fig. 1.12 Caseta de dialog pentru New Form Dup deschiderea formularului Area_box creat anterior (Fig. 1.13), se selecteaz butonul de introducere a unei celule cu butonul din stnga al mausului (butonul din stnga este folosit pentru selecie, butonul din dreapta este folosit pentru alte sarcini). Cu un clic n spaiul formularului se introduce o nou celul, care const ntr-un chenar i un tab pentru formul. Dup inserare, apare un cursor pe numele implicit al celulei, care poate fi modificat (n cazul exemplului, Abox). Pentru a introduce o formul se apas pe butonul ce indic un cursor pe paleta din stnga, dup care se acioneaz butonul asociat tabului formu-lei pentrucelul. Va apreaun cmpundesetasteazformula(Fig. 1.14),n cazuldefa valoarea 5, dupcareseapasbutonulApply.Valoarea celuleieste acum afiat.Acesta esteun exempluders-puns imediat: de fiecare dat cndse introduce oformul toate valorile afectate sunt reafiate n mod automat. Fig. 1.13 Formular coninnd o celul nou Fig. 1. 14 Caset pentru formula n care se insereaz o for-mul Programare Vizual i Modelare Pagina 20 Repetndprocedurasecreeazonoucelulncaresevacalculaariaptratului(Fig.1.15,)cafiind formula Abox * Abox. Noua celul (denumit Area) va afia numrul 25. Modificarea valorii lui Abox va atrage dup sine modificarea valorii celulei Area. Fig. 1.15 Formularul finalizat pentru calculul ariei ptratului 1.7.3Prograph. Programarea vizual cu fluxuri de date Prographafostconceputn1983de ctreTomaszPietrzykowskiiPhilipT. Cocs(14).Celde-aldoilea rmnndnproiectmaimultvremei-aadusmbuntiride-alungulanilor.PrographesteunLPV bazat pe fluxuri de date destinat programatorilor profesioniti. Paradigma bazat pe fluxuri de date este modalitateadeprogramarevizualfolositlargnindustrie,daridemediilevizualedeprogramare pentru anumite domenii, precum sistemele de vizualizare tiinific i sistemele de simulare Prographesteunlimbajfuncionaliuordefolosit.Datelesuntreprezentateprinlinii,iarmetodele prin diverse dreptunghiuri. Fiecare dreptunghi conine noduri pentru intrri i ieiri. Datele sunt transmi-se prin valori, ceea ce permite metodelor s foloseasc drept intrri, ieirile de la alte metode. Prograph nu are variabile, ci doar date care curg prin metode. Prographesteunlimbajdeprogramare Turingcomplet, adic oriceprogramcare poatefiscrisnC++ (sau orice altlimbajde nivel nalt)poatefiscrisinPrograph.Programelesuntcreate construinddia-grame de fluxuri de date n cadrul editorului. Clasele, metodele i atributele Prograph sunt reprezentate i manipulate grafic.Fig. 1.16 prezint un program care calculeaz valoarea ipotenuzei unui triunghi dreptunghic. Datele sunt introduse textual i curg de-a lungul liniilor conectate la operaii. Operaiile colecteaz datele i le tran-smit spre alte operaii pn se obine rezultatul final, care este vizualizat. Prographasigurun mecanism puternic pentru depanare, folosindextensiv tehnici devizualizare dina-mic.Pentruvaloriledatelorniveluldetimpderspunseste2,deoareceprogramatorulcereexplicit vizualizareaacestora cnd dorete slevad.Cutoateacestea, activitiledintimpul rulriiiordinea de execuieanodurilorpotfivizualizatepe totparcursulexecuiei,iardac programatorul modifico parte din date sau cod, acesteasunt nmod automat aplicate asupra sistemului. Acest aspect are nive-lul 3 de timp de rspuns. Programare Vizual i Modelare Pagina 21 Fig. 1.16 Programarea prin fluxuri de date n Prograph. Programatorul folosete operaii de nivel sczut (primitive) pentru a calcula ipotenuza unui triunghi dreptunghic. Prograph permite numirea i compunerea unor astfel de prafuri de nivel sczut n grafuri de nivel ridicat, care pot fi compuse ulterior n alte grafuri etc. O cale prin care aceast paradigm de programare se distinge de alte paradigme (prin prezentarea expli-citaarcelorngraf)esteexplicitateasaprivindrelaionrilefluxurilordedatencadrulprogramului. 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.4KidSim/Cocoa. Programarea vizual bazat pe reguli Cocoa (denumit iniial KidSim) este un LPV bazat pe reguli, n care programatorul specific reguli pentru demonstrarea unei postcondiii plecnd de la o precondiie. Programatorii vizai sunt copiii, iar dome-niul asociateste specificareasimulrilor graficeijocuri.Cocoaeste unlimbaj Turingcomplet,doarc facilitile lui nu au fost proiectate pentru programarea de uz general, ci pentru a facilita accesul copiilor la programarea propriilor simulri. Felul n care atributele concret i direct sunt atinse n Cocoa sunt similare cu Chimera, deoarece ambele folosesc demonstraia ca modalitate de a specifica semantica. Cu toate acestea, nivelulde timp de rs-puns este diferit, n Cocoa fiind ntre 2 i 3. Nu este nivel 3 pentru anumite tipuri de modificri ale pro-gramului(spreexemplu,adugareaunornoireguli)carenuafecteazafiareacurentavariabilelor pnlacerereaexpres aprogramatoruluidereluarearulrii.Pentrualtemodificrialeprogramului (modificarea aspectului unui obiect), modificrile sunt imediat propagate pe afiaj. n indicarea proprietilor comune tuturor sistemelor bazate pe reguli, Hayes-Roth include abilitatea de aleexplicitacomportamentul(15).nCocoa,uncopilpoatecrealumicaresconinovarietatede caractere, aspecte i proprieti. O regul specific ce face un caracter ntr-o situaie particular, aspec-tul permite caracterului s i modifice nfiarea, iar proprietile sunt folosite pentru a reine informa-iidesprecaracter.Simulareasefacepebaza unuiceas,astfelnctlafiecaretactalacestuiafiecrui caracterdinscenisepermitefuncionareaconformpropriilorlumi.Fig.1.17(16)prezintunecran Cocoa tipic. Programare Vizual i Modelare Pagina 22 Fig. 1.17 Ecranul Cocoa. Fereastra din colul stnga sus constituie placa de lucru, cucaseta de copiere sub ea. n dreapta, utilizatorul a deschis carneele pentru cele dou personaje de pe plac Fiecarecaracterareolistde reguli.Cndunui caracterivinernduls acioneze,sistemul parcurge lista de reguli, selecteaz prima regul aplicabil strii curente i o execut. Regulile se creeaz prin spe-cificarea propriu-zis de ctre programator a aciunilor care vor fi incluse, dup care sistemul le generali-zeaz (creeaz regula) pentru a putea fi folosite n mod automat de cte ori este nevoie. Fig. 1.18 Crearea unei noi reguli Ceamaisimplregul esteceacare mut un caracter.Fig.1.18(16)prezint unexempludecrearea uneiregulicarepermitemutareaunuicaracterunptrelladreapta.DupapsareabutonuluiNew Rule, ntreaga placse ntunec, cuexcepia unuispotde luminn jurulcaracterului, care poate fi di-mensionatpentruaincludecontextulregulii(ptratuldindreaptacaracterului).npasulurmtor,se demonstreaz regula prinmutareacaracteruluin zona dorit (Fig.1.18).Reprezentareavizual a unei reguli prezint o imagine custarea reguliinainte (stnga)i dup (dreapta), unite cu osgeat. Regula Programare Vizual i Modelare Pagina 23 seinterpreteaz:dacestespaiuliberladreaptamea,mmutnel.Cumregulilesuntrevizuitela fiecaretactalceasului,doaraceastsimplregulestesuficient pentru deplasareacaracteruluide-a lungul plcii. Fig. 1.19 Regula de salt. Caseta aciunii din dreapta a fost expandat pentru a vizualiza aciunile realizate de regul Pot fi create i reguli pentru modificarea aspectului unui caracter. Fig. 1.19 (16) prezint realizarea unei reguli pentru saltul unui gard. Programatorul mut caracterul un ptrat deasupra gardului, duce aspectul desaltncasetaaspectuluicurent(currentappearancebox)depepaginadeaspectdincarneelul caracterului, mut caracterul un ptrat la dreapta gardului, dup care revine la aspectul normal. Fig. 1.20 Modificarea regulii de mers la dreapta Demulteorisimulriledevininteresantedeoarececaracterelesemodificpeparcurs:mbtrnesc, obosesc, devin mai puternice sau mai detepte. Pentru a permite modificarea strii interne a caractere-lor, Cocoa ofer atribuirea de proprieti, care pot fi predefinite sau create de utilizator. Spre exemplu, utilizatorulpoatecreaproprietiprecumvrstsauflmndpentruunanumitcaracter.Aceste proprieti joac rolul instanelor din programarea orientat pe obiecte. Fig. 1.20 (16) prezint modifica-reareguliidemersladreapta astfel nctcaracterul sflmnzeasc. Utilizatorulcreeaz proprietatea denumit hunger nlista de proprieti a caracterului cu valoare iniial 0. Pentru a modifica regula, se folosete butonul Add On pentru acea regul, care execut aciunile asociate regulii, dup care permite utilizatoruluisdemonstrezenoiaciuni.nacestcaz,utilizatorulmodificvaloareadinproprietatea hungerdin0n1.Sistemulgeneralizeazaceastdemonstraie,dndu-isensulAdun1lafoamea Programare Vizual i Modelare Pagina 24 mea.Dacnuesteaceastainterpretareademonstraiei,utilizatorulipoateeditadescrierea.Cocoa include i un calculator pentru a permite editarea unor reguli complicate. n fiecare ciclu de execuie, regulile asociate fiecrui caracter sunt parcurse n lista acestuia de sus n jos (Fig. 1.21). Indicatorul din dreptul unei reguli este off (gri) nainte ca regula s fie luat n consideraie. Apoi, dac regula nu poate fi aplicat la starea curent a caracterului, indicatorul devine rou. Dac re-gula poate fi aplicat, este executat i indicatorul din dreptul ei devine rou. Dup aplicarea unei reguli pentru un caracter, acesta este oprit i nu se mai verific nicio regul pentru el pn n urmtorul ciclu. (4) Fig. 1.21 Un crtor de zid n Cocoa care urmeaz regulile demostrate pentru el. Tocmai a terminat regula 2, care l pune n poziia cerut de regula 1 (n pasul urmtor) 1.7.5Cube. Limbaje de programare vizual 3D Cube, realizat de M. Najork, reprezint un avans important n design-ul limbajelor de programare vizuale, fiind primul limbaj vizual 3D. Deoarece programele Cube sunt traduse n reprezentri interne mai simple pentru verificare i interpretare, limbajul ar fi mai degrab unul hibrid. Cu toate acestea, utilizatorul nu este expus niciodat la nicio reprezentare textual, ca urmare este mai corect dac se spune c limbajul este foarte aproape de a fi complet vizual. Cubefoloseteoparadigmdefluxdedatepentruconstruciaprogramelor.Lucruln3Dasigurun numr de avantaje asupra limbajelor 2D tradiionale. Spre exemplu, lucrul n 3D i permite sistemului s afieze mai multe informaii ntr-un mediu cu care este mai uor de interacionat dect cu o reprezenta-re 2D care folosete aceleai dimensiuni ale ecranului (3). ntr-o vizualizare 3D, programatorul este liber s i modifice punctul de vedere n interiorul lumii virtuale pentru a se uita la orice seciuni particular a programului. Acest tip de flexibilitate nu este disponibil n LPV-urile 2D Programare Vizual i Modelare Pagina 25 Fig. 1.22 Function to compute the factorial of a number in Cube Fig.1.22prezintprincipalelecomponentealeunuiprogramCube,folositepentruadescrieofuncie recursivpentrucalcululfactorialuluiunuinumrdat(17).ProgrameleCubesuntcompusedincuburi suport,cuburi predicat,cuburi de definire,porturi,conductei planuri.ntreagastructur din Fig. 1.22 este nconjurat de un cubde definire care asociaz icoana !cu funcia definit ninteriorul cubului. Cubuldedefinirearedouporturiconectatelael,unullastngaiunulla dreapta.Portuldinstnga asigur intrarea, iar portul din dreapta este ieirea, dei, tehnic vorbind, ambele porturi pot asigura am-belefuncii,nCubeporturilefiindbidirecionale.Celedouporturisuntconectateprinconductela cuburile suport n planul de jos al diagramei, care reprezint cazul de baz al recursivitii. Fiecare plan reprezintodiagramdefluxuridedate.Pentrusituaiadestart,diagramaasigurvalorileimplicite pentru porturi i indic ce tip de valori poate accepta sau produce fiecare port. Dac valoarea de la por-tul de intrare este zero, atunci planul de jos este activ i valoarea din cubul de suport din dreapta (unu) pleac spre portul de ieire. Dac intrarea este mai mare dect zero, atunci este satisfcut predicatul din planul de sus, este extras valoarea unu din intrare de ctre ramura de jos a diagramei de fluxuri de date din partea de sus. Diferena este introdus n apelul recursiv al funciei factorial, iar rezultatul este mul-tiplicat cuvaloarea de intrare. Rezultatul este trimisla portul de ieire. Dup definirea funciei factorial n program, ea poate fi apelat prin simpla conectare a cubului predicat etichetat cu icoana ! la cuburi de suport, prin cele dou porturi (Fig. 1.23 (18)). Programare Vizual i Modelare Pagina 26 Fig. 1.23 Folosirea programului factorial, dup evaluare 1.8Programarea vizual i abstractizarea Una dintre provocrile legate de programarea vizual o reprezint scalarea limbajelor pentru a dezvolta programectmaiextinse.AceastaesteoproblemmaimarepentruLPV-uridectpentrulimbajele tradiionaletextuale din motivelegate de reprezentare, designuliimplementarealimbajului inouta-tea relativ a domeniului. Spre exemplu, unele mecanisme vizuale folosite pentru a obine caracteristici precumexplicitpotocupa unspaiu attde mare nctdevinedificil meninereacontextului.Dease-menea, este dificil de aplicat tehnici dezvoltate pentru limbajele tradiionale, deoarece ele pot aduce cu sine reintroducerea complexitii pe care LPV-urile au ncercat s o nlture sau s o simplifice.Dezvoltrirecente ndomeniulabstractizrii aufost foarteimportantepentru scalabilitatea LPV-urilor. Cele dou tipuri de abstractizare, cele mai rspndite att n programarea vizual, ct i n programarea textual, sunt abstractizarea procedural i abstractizarea datelor. n particular, abstractizarea procedu-ral s-a demonstrat a fi suportat ntr-o varietate de LPV-uri. Un atribut cheie nsuportul abstractizrii procedurale n LPV-uri l-a reprezentat consistena cu restul programrii n acelai LPV. Soluii reprezen-tative includ: posibilitateaprogramatorului de a selecta, numi iiconifica oseciune a unui graf de flux de date (Fig. 1.16), care adaug un nod, reprezentnd subgraful, la o bibliotec de noduri funcii ntr-un limbaj de tip flux de date; setarea unor foi de calcul separate (Fig. 1.10), care pot fi generalizate n mod automat pentru a permite funcii definite de utilizator ntr-un limbaj bazat pe formulare; nregistrarea i generalizarea unei secvene de manipulri directe (Fig. 1.5), ntr-un limbaj prin demonstrare. AbstractizareadateloracunoscutunprocesmailentdedezvoltarenLPV-uri,maialespentruc,de multe ori, este dificil de gsit o cale pentru a menine caracteristici precum concret i rspuns direct, i a aduga suport pentru ideile centrale legate de abstractizarea datelor, precum generalitate i ascunderea informaiei.Cutoateacestea,nanumiteLPV-uriaaprutsuportpentruabstractizareadatelor.Spre Programare Vizual i Modelare Pagina 27 exemplu, n Form/3, un nou tip de dat este definit n foaia de calcul tabelar astfel: cu celule obinuite se definesc operaii sau metode i cu dou celule difereniate se permite compunerea obiectelor complexe din cele simple i definirea modului de vizualizare pe ecran al obiectului. nCocoa, aspectul fiecruica-racter este desenat folosind uneditor grafic i fiecare demonstraie a unuinoi reguli aparine tipului caracteruluimanipulat,asigurndaproximativfuncionalitateauneioperaiisaumetode.Ambele, Form/3 i Cocoa, asigur i un suport limitat pentru motenire. 1.9Concluzii privind programarea vizual Domeniul limbajelor de programare vizual abund cu exemple ale eforturile de a lrgi accesibilitatea i mri puterea programrii calculatoarelor. Dei numeroasele proiecte existente variaz n detaliile oferite, n special n metafora vizual implicat i n domeniul de aplicare intit, toate mprtesc scopul comun al mbuntirii procesuluide programare. n plus, cercetrile recente pentrusolidificarea fundamente-lor teoretice ale programrii vizuale i eforturile serioase depuse pentru dezvoltarea unor clasificri for-malestandard aleLPV-urilorindicfaptulcdomeniulanceputssereevaluezeissematurizeze. Chiar dac domeniuls-a dezvoltat nultimiidouzecide ani,contribuii incipiente importante,precum Sketchpad i Pygmalion, i-au meninut influena n numeroase design-uri de LPV-uri. n ciuda migrrii spre afiajele grafice i a interaciunilor incluse n LPV-uri, un studiu al domeniului arat c nu se justific, nc, excluderea n totalitate a textului. n timp ce multe LPV-uri pot reprezenta toate aspecteleunui programn modvizual, aceste programe sunt, n general,mai greude cititide folosit dect cele care folosesc text pentru etichete i anumite operaii atomice. Spre exemplu, dei o operaie precum adunarea poate fi reprezentat grafic n LPV-uri, fcnd acest lucru se poate ncrca foarte mult afiajul.Pedealtparte,folosindtextpentru areprezentao astfeldeoperaieatomicseobineun afiaj mult mai simplu, fr a pierde metafora vizual global. n condiiile n care grafica computerizat, att hardware, ct i software, continu s-i mbunteasc performanais-iscadpreul,LPV-uritridimensionale,precumCube,atragateniacomunitiide cercettori.LPV-urile3Dnudoarrezolvproblemaincluderiiuneicantitimarideinformaiipeun ecran destul de mic, ci i exemplific sinergia inerent dintre limbajele de programare, grafica pe calcu-lator i interfeele om-calculator, ceea ce a fost o marc a programrii vizuale nc de la nceputurile sale. Programare Vizual i Modelare Pagina 28 2Modelare cu reele Petri (19) 2.1Introducere Cretereancomplexitateasistemelorindustrialemoderne,precumproducia,controlulprocesului, sisteme de comunicaii etc., a indus apariia a numeroase probleme privind dezvoltarea acestora. n faza de planificareapareconfruntareacucapabilitilecrescutealeacestorsisteme,datoritcombinaiilor unice de hardware i software care opereaz sub un numr mare de constrngeri ce rezult din resurse-lelimitatealesistemului.ncondiiilenaturiicomplexeiintensiveacapitaluluisistemelormoderne industriale,designulioperareaacestoranecesitmodelareianalizpentruselectareaalternativei optimededesigniapoliticiideoperare.Estebinecunoscutfaptulcfluxulnprocesuldemodelare poate contribui substanial la timpul i costul de dezvoltare. Chiar i eficiena operaional poate fi afec-tat.Dinacestmotiv,oateniespecialtrebuieacordatcorectitudiniimodelorcaresuntfolositela toate nivelurile de planificare. Ca uneltegraficeimatematice, reelelePetri asigur unmediu uniformpentrumodelare,analizfor-mal i design al sistemelor cu evenimente discrete. Unul dintre principalele avantaje al folosirii reelelor Petri l constituie faptul c acelai model este folosit att pentru analiza proprietilor comportamentale ievaluareaperformanelor,ctipentruconstruciasistematicasimulatoareloricontrolerelorcu evenimente discrete. Reelele Petri au fost numite dup Carl A. Petri, care a creat n 1962 o unealt ma-tematic sub form de reea pentru studiul comunicrii cu automatele. Dezvoltarea lor ulterioar a fost uurat de faptul c reelele Petri pot fi folosite pentru modelarea unor proprieti precum sincroniza-rea proceselor, evenimente asincrone, operaii concurente, rezolvarea conflictelor sau partajarea resur-selor. Aceste proprieti caracterizeaz sistemele cu evenimente discrete care includ sistemele automa-te industriale, sistemele de comunicare i sistemele bazate pe calculator. Toate acestea transform ree-lele Petri ntr-o unealt promitoare i o tehnologie pentru aplicaii n automatizri industriale. Caunealtgrafic,reelelePetriasigurunputernicmediudecomunicarentreutilizator(deregul, inginer) i client. Cerinele complexe din caietele de sarcini pot fi reprezentate grafic folosind reele Petri nlocul unor descrieri textuale ambiguesau al unor notaii matematice dificil de neles de ctre client. Acest aspect, combinat cu existena unor unelte computerizate care permit simularea grafic interactiv a reelelor Petri, asigur inginerilor de dezvoltare ounealt puternicce s i asisten procesul de dez-voltare al sistemelor complexe. Ca unealt matematic,unmodel dereeaPetripoatefidescrisde unsetdeecuaiilineare algebrice sau de alte modele matematice care s reflecte comportamentul sistemului. Acest lucru permite o veri-ficareformalaproprietilorasociatecomportamentuluisistemuluivizat(relaiideprecedenntre evenimente,operaiiconcurente,sincronizrilenecesare,eliminareasituaiilordeblocare(deadlock), activitile repetitive i excluderile mutuale ale resurselor partajate, pentru a aminti cteva dintre ele). Validarea modeluluiprin simulare poate doar produce un setlimitatde strialesistemuluimodelat,i astfel poate arta doar prezena (nu i absena)erorilor dinmodel i specificaiile sale de baz. Abilita-tea reelelor Petri de a verifica formal modelul este importan n mod special pentru sistemele n timp Programare Vizual i Modelare Pagina 29 real critice din punct de vedere al securitii, precum sistemele de control al traficului aerian, sistemele de control al traficului feroviar, sistemele de control al reactoarelor nucleare etc. Reelele Petri aufost folosite pentru modelarea sistemelor de timp real tolerante la defectare i critice din punct de vedere al securitii, pentru detectarea erorilor i pentru monitorizarea proceselor. Un domeniu desucces de aplicare alreelelor Petrilconstituie modelarea ianaliza protocoalelor de comunicare(nc de la nceputulanilor70). nultimii aniaufost propuse cteva abordricare permit construireamodelelordereelePetripentruprotocoaledinspecificaiilescrisentr-unlimbajrelativ nespecializat. Reele Petri, ns, au fost folosite nmod extensiv pentrumodelarea i analiza sistemelor de producie. n acest domeniu, reeaua Petri reprezenta linii de producie cu buffer-e, sisteme automate de producie, sistemeflexibiledeproducie, linii automate de asamblare,sisteme cu partajarea resurselori,recent, sisteme de producie de tip just-in-time. Un altdomeniu desucceslconstituie aplicarea reelelorPetrinmodelareacontrolerelorsecveniale. Controlerele logice programabile (PLC) sunt folosite n mod uzual pentru controlul secvenial al sisteme-lor automate.Elesunt proiectatefolosind diagramelogicescar(ladderlogic diagrams),care suntcu-noscuteca fiinddificilede depanatimodificat. Controlerelesecvenialebazarepe reelePetri,pe de alt parte, sunt uor de proiectat, implementat i ntreinut. La nceputul anilor 80, Hitachi Ltd. a dezvol-tat un controler secvenial bazat pe reele Petri care a fost folosit cu succes n aplicaii reale pentru con-trolulsistemuluideasamblareapieselorinsistemulautomatdencrcare/descrcaredindepozit. Utilizatorii reelelor Petri, conform statisticilor, au redus substanial timpul de dezvoltare, n comparaie cu metodele tradiionale. Reele Petri au fost folosite extensiv i n dezvoltri software. Utilizarea n acest domeniu s-a concentrat pe modelarea i analiza sistemelor software, iar cea mai complex dezvoltare a implicat folosirea reele-lor Petri colorate. S-a demonstrat c acest tip de reele Petri este un limbaj folositor pentru proiectarea, specificarea, simularea, validarea i implementarea sistemelor software complexe. Caunealtmatematic,reelelePetripermitevaluareaperformanelorsistemelormodelate.Perfor-manele deterministice i stocastice pot fi msurate i evaluate folosind o gam larg de modele de ree-lePetricare ncorporeazn definiialorfunciidetimp deterministicei/sau probabilistice.Evaluarea performanelor poate fi realizat fie prin tehnici analitice, bazate pe rezolvarea proceselor (semi)Markov debaz,sauprinsimulareacuevenimentediscrete.Folosireamodelelorcarencorporeazfunciide timp cudistribuie probabilistic permitobinerea ratelordeproduciepentrumodelelesistemelorde fabricaie, capacitatea de producie, ntrzieri, capacitatea pentru comunicare i modelele sistemelor cu microprocesor,utilizarearesurselorcriticeimsuridefiabilizarealeacestora.nultimiiani,aceast clasdereelePetriafostfolositextensivpentrumodelareaistudiulperformaneloranaliticeale sistemelor multiprocesor, ale magistralelor sistemelor multiprocesor, ale canalelor de comunicare DSP,ale arhitecturilor paralele de calculatoare, precum i ale algoritmilor paraleli i distribuii. Un alt domeniu de aplicare l constituie reelele de comunicare. S-a lucrat pe reele locale cu fibr optic (Fiber Optics Local Area Networks) precum Expressnet, Fastnet, D-Net, U-Net, TokenRing. Protocoalele Programare Vizual i Modelare Pagina 30 de tip fieldbuss, precum FIP i ISA-SP50 au atras foarte mult atenie n ultimii ani, acest lucru fiind oare-cum normal, ele fiind reele importante pentrusistemele industriale complexe. De asemenea, s-a sem-nalatuninteresncreterepentrumodelareaievaluareareelelordemarevitez(HighSpeed Networks), cruciale pentru dezvoltarea cu succes a sistemelor multimedia. ReelelePetricuextinderedetimp,combinatecutehnicieuristicedecutare,aufostfolositepentru modelarea i studiul problemelor de dispecerizare din sistemele de fabricaie i din sistemele cu roboi. De asemenea, acest tip de reele Petri au fost folosite i pentru modelarea i analiza proceselor chimice continue. 2.2Descrierea reelelor Petri O reea Petri poate fi identificat cu un tip particular de grafuri orientate bipartite populate cu trei tipuri de obiecte.Aceste obiectesuntlocuri,tranziiiiarce orientate careconecteazlocuri cutranziiisau tranziiiculocuri.Dinpunctdevederegrafic,locurilesuntreprezentateprincercuriiartranziiileprin bare sau dreptunghiuri. Un loc este intrare pentru o tranziie dac exist un arc orientat de la acel loc la tranziie. Un loc este ieire pentru o tranziie dac exist un arc orientat de la tranziie la loc. n forma sa cea mai simpl, o reea Petri poate fi reprezentat printr-o tranziie mpreun cu locurile sale de intrare ideieire.Aceastreeaelementar poatefifolositpentrureprezentareaunoraspectediverseale sistemelor modelate. Spre exemplu, locurile de intrare (ieire) pot reprezenta precondiii (postcondiii), iartranziiileevenimente.Locuriledeintrarepotsemnificadisponibilitatearesurselor,tranziia utilizarea lor, iar locurile de ieire eliberarea resurselor. Un exemplu de reea Petri este prezentat n Fig. 1.24. Aceast reea este format din cinci locuri, reprezentate prin cercuri, patru tranziii, reprezen-tate prin bare i arce orientate ce conecteaz locurile cu tranziiile i tranziiile cu locurile. n reea, locul p1 este intrare pentru tranziia t1, iar locurile p2, i p3 sunt ieiri pentru tranziia t1. Fig. 1.24 Exemplu de reprezentare grafic a unei reele Petri Pentru a studia comportamentul dinamic al sistemului modelat, adic strile acestuia i modificrile lor, fiecare loc poate deine niciunul sau un numr pozitiv dejetoane, reprezentate grafic prinmici cercuri Programare Vizual i Modelare Pagina 31 solide, aa ca n Fig. 1.24. Prezena sau absena unui jeton dintr-un loc poate indica faptul c o condiie asociat cu acel loc este adevrat sau fals. Pentru un loc care reprezint disponibilitatea unor resurse, numrul de jetoane n loc indic numrul resurselor disponibile. La un anumit moment dat de timp, dis-tribuia jetoanelor n locuri, denumit marcajul reelei Petri, definete starea curent a sistemului mode-lat. Marcajul unei reele Petri cu m locuri este reprezentat de unvector M cu dimensiunea(m x 1), ale crui elemente, notate M(p), sunt numere ntregi pozitive reprezentnd numrulde jetoane nlocurile corespunztoare. O reea Petri ce conine jetoane se numete reea marcat. Spre exemplu, n modelul de reea Petri din Fig. 1.24, M = (1,0,0,0,0)T. Formal, o reea Petri poate fi definit astfel: RP = (P, T, I, 0, Mo); unde 1)P = {p1, p2, pm} este un set finit de locuri, 2)T = { t1, t2, tm } este un set finit de tranziii, P I , i P I u,3)I: (P I) N este o funcie de intrare care definete arcele orientate de la locuri la tranzi-ii, unde N este un set de ntregi pozitivi,4)0: (P I) N este o funcie de ieire care definete arcele orientate de la tranziii la locuri i5)H0: P N este marcajul iniial. Dac I(p, t) = k (O(p, t) = k), atunci exist k arce orientate (paralele) conectnd locul p cu tranziia t (tran-ziia t cu locul p). Dac I(p, t) = 0 (O(p, t) = 0), atunci nu exist niciun arc orientat care s conecteze p cu t (t cu p). Frecvent, n reprezentarea grafic, arcele paralele care conecteaz un loc (tranziie) cu o tranzi-ie (loc)sunt reprezentate printr-un singurarc etichetatcumultiplicitatea sa, sau ponderea k.Aceast reprezentare compact a arcelor multiple este reprezentat n Fig. 1.25. Fig. 1.25 (a) Arce multiple. (b) Reprezentare compact a arcelor multiple. Modificnd distribuia jetoanelor n locuri, lucru care poate reflecta apariia unor evenimente sau execu-iaunoroperaii,sepoatestudiacomportamentuldinamicalsistemuluimodelat.Urmtoarelereguli sunt folosite pentru controlul fluxului de jetoane: Regula de activare. O tranziie t se spune c este activat dac fiecare loc de intrare p al lui I conine cel puin numrul de jetoane egal cu ponderea arcelor orientate ce conecteaz p cu t.Regula de execuie: Programare Vizual i Modelare Pagina 32 (a)O tranziie activat t poate sau nu s fie executat dependent de interpretarea adiional asoci-at i (b)Execuia unei tranziii activate t nltur din fiecare loc de intrare p un numr de jetoane egal cu ponderea arcului orientat care conecteaz p cu t. De asemenea, depoziteaz n fiecare loc de ie-ire p un numr de jetoane egal cu ponderea arcului direcional care conecteaz t cu p. Fig. 1.26 (a) Tranziia t1 activat. (b) Tranziia activat t1 este executat ReguliledeactivareideexecuiesuntilustratenFig.1.26.nFig.1.26(a),tranziiat1esteactivat deoarece locul de intrare p1 al tranziiei t1 conine dou jetoane i I(p1, t1) = 2. Execuia tranziiei activate t1 nltur din locul de intrare p1 dou jetoane, deoarece I(p1, t1) = 2, i depoziteaz un jeton n locul de ieire p3, O(p3, t1) = 1 i dou jetoane n locul de ieire p2, O(p2, t1) = 2. Toate acestea sunt reliefate n Fig. 1.26 (b). Fig. 1.27 Reea Petri cu un arc inhibitor PutereademodelareareelelorPetripoateficrescutprinadugareaabilitiidetestabilitatezero, adic abilitatea de a testa dac un loc nu are jetoane. Acest lucru este realizat prin introducerea unui arc inhibitor, care conecteaz un loc de intrare cu o tranziie i este reprezentat grafic cu un arc terminat cu un mic cerc (Fig. 1.27). Prezena unui arc inhibitor ntre un loc de intrare i o tranziie va schimba condii-iledeactivareatranziiei.nacestcaz,tranziiaesteactivatdacfiecarelocdeintrare,conectatla tranziie printr-un arc normal (terminat cu sgeat), conine cel puin numrul de jetoane egal cu pon-derea arcului i nici un jeton nu este prezent nfiecare loc de intrare conectat latranziie printr-un arc inhibitor.Regula deexecuieatranziiei esteaceiai,doarcnumodific marcajullocurilorconectate prin arc inhibitor. Se spune c oreeaPetri este pursaufr bucle dac nuexistunloc care s fie i intrare i ieire a aceleiai tranziii. O reea Petri care conine bucle poate fi convertit la o reea Petri pur, ca n Fig. 1.28. Programare Vizual i Modelare Pagina 33 Fig. 1.28 nlturarea buclelor Fig. 1.29 Model de reea Petri pentru un sistem multirobot Pentru a ilustra modul n care reelele Petri pot fi folosite pentru a modela proprieti precum activiti concurente, sincronizare, excludere mutual etc., se consider un exemplu simplu al unui sistem cu ro-boi. Sistemul este reprezentat de reeaua Petri din Fig. 1.29, cu detalii n Tabelul 1. n acest model, dou brae robotizate realizeaz operaii de preluare i plasare, accesnd un spaiu comun la preluarea sau la transferulpieselor.Pentruaevitacoliziunile,sepresupunecdoarunrobotpoateaccesaspaiulde lucru la un anumit moment de timp. n plus, se consider c spaiul de lucru conine un buffer cu spaiu limitatpentruproduse.Exemplulpoatereprezentaoperarea a doubraerobotizarentr-unsistem cu dou maini unelte, unde un bra transfer semiprodusele de la prima main n buffer, iar celalalt bra transfer semiprodusele de la buffer la a doua main. Locuri (cu jetoane)Interpretare p1 (p4)Robotul R1 (R2) realizeaz operaii n afara spaiului comun P2 (p5)Robotul R1 (R2) ateapt accesul n spaiului comun p3 (p4)Robotul R1 (R2) realizeaz operaii n spaiului comun p7Excludere mutual p5 (p9)Buffer plin (gol) TranziiiInterpretare t1 (t4)Robotul R1 (R2) cere acces n spaiului comun t2 (t5)Robotul R1 (R2) intr n spaiului comun t3 (t4)Robotul R1 (R2) prsete spaiului comun Tabel 1 Interpretarea locurilor i tranziiilor pentru modelul de reea Petri al sistemului de asamblare multirobot Programare Vizual i Modelare Pagina 34 n acest model, locurile p1, p2, p3 i tranziiile t1, t2, t3 modeleaz activitile braului robotizat R1. Locuri-le p4, p5, p6 i tranziiile t4, t5, t6 modeleaz activitile braului robotizat R2. Tranziiile t1 i t4 reprezint activiti concurente ale lui R1 i R2. Fiecare dintre aceste tranziii poate fi tras nainte sau dup sau n paralele cu cealalt. Accesulla spaiul comun necesit sincronizarea activitilor braelor pentru a evita coliziunea. Doar unbrarobotizat poate accesaspaiulcomun delucrula un anumitmoment detimp. Aceastsincronizare esterealizat prinmecanismul deexcluderemutualimplementat desubreeaua format din locurile p7, p3, p6 i tranziiile t2, t3, t5, t6. Tragerea tranziiei t2 dezactiveaz t5, presupunnd c t5 este activat, i viceversa. Astfel, doar un bra robotizat poate accesa spaiul comun la un moment dat.n plus,se considercapacitateabufferuluicafiind b. nacestfel,spre exemplu, dacp8 estegol, atuncit2 nupoate fi activat.Aceast mpiedic braulR1 sncercetransferuluneipiesectrebuffer cnd acesta este plin. De asemenea, R2 nu poate accesa bufferul dac nu sunt piese n el, adic locul p9 este gol. 2.3Proprieti ale reelelor Petri Ca instrument matematic, reelele Petri posed un numr de proprieti. Aceste proprieti, atunci cnd sunt interpretate ncontextulsistemului modelat, permit designer-ului de sistems identifice prezena sauabsenaproprietilorfuncionalespecificedomeniuluideaplicarealsistemuluiproiectat.Astfel, pot fi distinse dou tipuri de proprieti: comportamentale i structurale. Proprietile comportamentale sunt acelea care depind de starea iniial, sau marcajul, unei reele Petri i de topologia acesteia. Vor fi discutate n cele ce urmeaz proprieti precum accesibilitatea, limitabilitatea, conservativitatea, nivelul de activare (liveness), reversibilitatea i starea de pornire (home state). 2.3.1Accesibilitate O problem important n designul sistemelor distribuite const n capacitatea sistemului de a atinge o anumit stare sau de a prezenta un comportament funcional particular. n general, ntrebarea la care se caut rspuns este dac sistemul modelat cu reele Petri are toate proprietile dorite, aa cum sunt ele specificate n cerine, i nicio proprietate nedorit. Pentru a afla dac sistemul modelat poate atinge o anumit stare ca rezultat al comportamentului func-ionalcerut,estenecesargsireauneiastfeldesecvenedeexecuiialetranziiilorcarevaaveaca efect transformareamarcajului M0 nMi, unde Mi reprezint stareaspecific i secvena deexecuii re-prezint comportamentul funcional cerut. Trebuie subliniat faptul c sistemele reale potatinge o anu-mit stare prin mai multe comportamente funcionale permise. ntr-o reea Petri, acest lucru este reflec-tat de existena unor secvene specifice deexecuii de tranziii, reprezentnd comportamentul funcio-nal cerut ,care vor transforma un marcaj M0 n marcajul Mi cerut. Dac ntr-un model de reea Petri exis-t secvene adiionale deexecuie a tranziiilor care s transforme un marcajM0nmarcajul Mipoate indica faptul c acel model de reea Petri nu reflect cu exactitate structura i dinamica sistemului des-cris. De asemenea, acest fapt poate indica i prezena unor aspecte neanticipate privind comportamen-tul funcional al sistemului real, ceea ce nseamn c reeaua Petri reflect cu precizie specificaiile sis-temului descris. Programare Vizual i Modelare Pagina 35 Un marcajMi este accesibil pornind de la marcajulM0 dac existe secven de execuie a tranziiilor care transform marcajul M0 n Mi. Un marcaj M1 este imediat accesibil dup marcajul M0 dac o execu-ie a tranziiilor activate din M0 determin obinerea marcajului M1. Spre exemplu, n modelul sistemului cu multirobot din Fig. 1.29, starea n care braul robotic R1 realizeaz sarcini n spaiul comun, n timp ce braul robotic R2 ateapt n afara spaiului, este reprezentat de vectorul Mi = (0, 0, 1, 0, 1, 0, 0, 2, 1)T. Mi este accesibil din marcajul iniial M0, unde M0 = (1, 0, 0, 1, 0, 0, 1, 3, 0)T, prin urmtoarea secven de execuie a tranziiilor: t1 t2 t4. Marcajul Mi = (0, 1, 0, 0, 1, 0, 1, 3, 0)T, care reprezint starea sistemului n care braulrobotic R1 ateapt accesuln spaiulcomunibraul robotic R2realizeaz sarcininafara spaiului comun, este accesibil imediat din marcajul iniial M0 prin execuia tranziiei t1. n M0,atttran-ziia t1, ct i tranziia t4, sunt activate. Setul tuturor marcajelor accesibile din M0 este denumit setul de accesibilitateiestenotatR(Mo).SetultuturorsecvenelorposibiledeexecuiedinM0estenotatcu L(Mo). n acest fel, problema identificrii existenei unei stri specifice Mi n care sistemul poate s ajun-g poate fi redefinit ca problema gsirii lui H R(H0). 2.3.2Limitabilitate i siguran Theregul,locurilesuntfolositepentrureprezentareauneizone depstrare adatelorncomunicare sau sistemele computerizate, a unor produse sau zone de pstrare a uneltelor n sistemele de producie etc. Este foarte important de stabilit dac strategiile de control stabilite asigur evitarea strii de supra-ncrcare a acestor zone. Zonele de pstrare a datelor pot pstra, fr a le corupe, doar un numr res-tricionatde pridedate.nsistemeledefabricaie,ncercareade anmagazinamaimulteunelten zonadestinatacestuilucrupoateduceladefectareaechipamentului.ProprietateauneireelePetri care permite identificarea n cadrul sistemului modelat a situaiei de suprancrcare se numete limitabi-litate. Oreea Petri este k-limitat dac numrul de jetoane norice loc p, unde p P, este totdeauna mai mic sau egal cu k (k este un numr ntreg pozitiv), pentru orice marcaj M accesibil din marcajul iniial M0, H R(H0). O reea Petri este sigur dac este 1-limitat (Fig. 1.30). ntr-o astfel de reea, niciun loc nu poate conine mai mult de un jeton. O reea Petri este nelimitat dac exist cel puin un loc care s conin un numr orict de mare de jetoane (Fig. 1.31, locul p4). Fig. 1.30 Reea Petri sigur Fig. 1.31 Reea Petri nelimitat 2.3.3Conservativitate n sistemele reale, numrul resurselor utilizate este, n mod normal, limitat prin constrngeri financiare saudealtgen.Dacjetoanelesuntutilizatepentrureprezentarearesurselor,alcrornumrntr-un Programare Vizual i Modelare Pagina 36 sistem estefix,atuncinumruljetoanelordin reeaua Petri arespectivuluisistem artrebuisrmn neschimbat indiferent de marcajul curent al sistemului. Aceast directiv descinde din faptul c resurse-le nu pot fi nici create, nici distruse, cu excepia cazului cnd ar trebui s se ntmple aa. Spre exemplu, ounealt distrus poate fi nlturat din celula de fabricare, iar numrul uneltelor disponibile se va re-duce. Fig. 1.32 Reea Petri conservativ n raport cu w = [1,1,2,1,1] Fig. 1.33 Reea Petri strict conservativ O reea Petri este conservativ dac numrul de jetoane este conservat. Din punct de vedere structural, acest lucru este posibil doar dac numrul de arce de intrare n fiecare tranziie este egal cu numrul de arce deieire. nsistemelereale,ns, resursele sunt, n modfrecvent,combinate astfelnct anumite sarcini s fie executate, apoi separate dup finalizarea sarcinilor. Spre exemplu, ntr-unsistem de fabri-caieflexibilun vehicul ghidatautomat colecteazpaleii cuprodusede la o celulde prelucrareii transport la o staie de descrcare unde paleii sunt preluai (scenariuilustrat n Fig. 1.32). Tranziiat1 modeleaz ncrcarea unui palet ntr-un vehicul. Tranziia t2 reprezint livrarea paletului la staia


Recommended