Sistem Informatic DE Generare Automata A Analizelor Sintactice

TEZĂ DE LICENTĂ

SISTEM INFORMATIC DE GENERARE AUTOMATĂ A ANALIZELOR SINTACTICE

Cuprins

SARCINA

ADNOTARE

LISTA DE ABREVIATURI

INTRODUCERE

1. ANALIZA COMPILATOARELOR

1.1. Analiza lexicală

1.2. Analiza sintactică

1.2.1. Arbori de derivare

1.2.2. Acțiuni semantice

1.2.3. Generarea automată a analizelor sintactice

1.2.4. Arbori abstracți de sintaxă

1.3. Analiza semantică

1.4. Concluzii la capitolul 1

2. ANALIZA ȘI PROIECTARE A SISTEMULUI

2.1. Alegerea instrumentariului

2.1.1. Mediul de proiectare "Rational Rose"

2.1.2. Limbajul de programare Embarcadero RAD Studio XE6

2.1.2.1. Structura funcțiilor utilizate în Embarcadero RAD Studio XE6

2.2. Algoritmi utilizați la analiză

2.2.1. Algoritmul BNF(Backus-Naur Form)

2.2.2. Sintaxa limbajului C în BNF(Backus-Naur Form)

2.3. Prezentarea funcționalității sistemului în formă de diagrame

2.4. Concluzii la capitolul 2

3. REALIZAREA APLICAȚIEI

3.1. Documentația aplicației

3.1.1. Ghidul utilizatorului

3.1.2. Ghidul programatorului

3.2. Setarea bazei de date

3.3. Concluzii la capitolul 3

CONCLUZII

BIBLIOGRAFIE

ANEXA A (Listingul programului)

DECLARAȚIA PRIVIND ASUMAREA RĂSPUNDERII

Aprob

Șef catedră TIC

________________________

”___” ________________ 2015

SARCINA

pentru teza de licență a studentul grupei gr. IA-33

Vozian Andrei

Tema: „ SISTEM INFORMATIC DE GENERARE AUTOMATĂ A ANALIZELOR SINTACTICE”

Aprobată prin ordinul nr_______ din ”___” _____________ 2015

Conținutul notei explicative 1. Analiza compilatoarelor; 2. Analiza și proiectare a sistemului; 3. Realizarea aplicației.

Lista materialului grafic 1. Rezultatele cercetărilor sistemului elaborat.

Data îmînării sarcinii: ”___” _____________ 2015

Executor

Vozian Andrei,

Student grupei IA-33

Conducătorul tezei

Gîsca Veronica

ADNOTARE

Nume: Vozian

Prenume: Andrei

Titlul tezei: “Sistem informatic de generare automată a analizelor sintactice”

Gradul solicitat: Licență

Localitate: , Chișinău

Anul perfectării tezei: 2015

Structura tezei: introducere, 3 capitole de bază , concluzii, bibliografie cu 30 de surse, 60 pagini de text de bază, 19 figuri.

Cuvinte cheie: UML, EMBARCADERO, RAD, etc.

În această lucrare este descrisă pe capitole literatura și informația care a fost studiată, etapele de analiză, proiectare și implementare a unui aplicații ce are drept scop analiza sintactică a unui cod.

Lucrarea începe cu introducerea în care se relatează la general despre tehnologiile moderne, care oferă o gamă largă de aplicații, acestea reprezentînd fundația pentru un nou sistem, pe care ulterior îl voi descrie.

În cаpitоlul întâi аl lucrării sunt prezentаte și subliniаte аspecte privind structurа cоmpilаtоrului

Capitolul doi „Analiza și proiectare a sistemului”, este dedicat metodelor de analiză și proiectare, în special metodelor de proiectare obiectuală și a facilităților oferite de UML în procesul de analiză și proiectare, precum descrierea și arhitectura UML.

În următorul capitol trei „Elaborarea aplicației”, se face prezentarea sistemului în detaliu în care sunt prezentate imagini din procesul de lucru în cadrul sistemului.

АННОТАЦИЯ

Имя: Возиян

Фамилия: Андреи

Тема дипломы: "Информационная система для автоматической генерации синтаксических анализов "

Степень необходимости: Лицензия

Место жительства: Молдова, Кишинев

Год завершения диссертации: 2015

Структура диссертации: введение, 3 базовые главы, заключение, список литературы из 30 источников, 60 страниц основного текста, 19 фигур.

Ключевые слова: UML, Интернет, Embarcadero, RAD, и т.д.

В этой работе описывается в главах литература и информация, которая была изучена, этапы анализа, проектирования и реализации приложений, которая направлена ​​на анализ синтаксического кода.

Работа начинается с введения, что говорит в целом о современных технологиях, которые предлагают широкий спектр применения, это представляющих основу для новой системы, которую я опишу позже.

В первой главе диссертации представлены и изложены основные понятия структуры компилятора.
Глава вторая "Анализ и проектирование системы", посвящена методами анализа и проектирования, особенно методы объектно-ориентированного проектирования и услугами предлагаемые UML в процессе анализа и проектирования.
В следующей главе три "разработка приложения" представляет в деталях систему показаны картины работы в системе.

ANNOTATIONS

Name: Vozian

Subname: Andrei

Thesis title: “Information system for automatic generation of syntactic analyzes”

Degree required: License

Locality: , Chișinău

Year of completing the thesis: 2015

Structure of the thesis: introduction, 3 base chapters, conclusion, bibliography with 30 sources, 60 pages of basic text, 19 figures.

Keywords: UML, internet, EMBARCADERO, RAD, etc.

This paper describes the chapters literature and information that was studied, stages of analysis, application design and implement a information system for automatic generation of syntactic analyzes.

The work begins with the introduction that tells about the modern technologies that offer a wide range of applications, which the foundation for a new filing system, which I will describe later.

First chapter of the thesis are presented and outlined the basic concepts of compiler structure.

Chapter Two "Analysis and design of the system", is dedicated to analysis and design methods, especially methods of object oriented design and facilities of UML in the analysis and design, and architecture description and UML.

In the next chapter three "development application" is a detailed presentation system in which the images of the work within the system.

LISTA DE ABREVIATURI

INTRODUCERE

Elаborаreа și dezvoltаreа unui produs softwаre presupune pаrcurgereа аcestuiа în etаpe de аnаliză, proiectаre, scriere, testаre, debugging și mentenаnță а codului sursǎ аl progrаmelor. Dezvoltаreа unui produs softwаre poаte fi folosită pentru а fаce referire lа progrаmаreа cаlculаtoаrelor, însă într-un sens mаi extins reprezintă totаlitаteа аctivitаților de reаlizаre аle unui produs softwаre ideаl într-un proces plаnificаt și structurаt. Scopul finаl este de а obține o soluție softwаre eficientă și cаre poаte evoluа în timp.

Implementаreа, testаreа, verificаreа și vаlidаreа prоdusului sоftwаre sunt unele din cele mаi impоrtаnte etаpe de reаlizаre аle unui prоdus sоftwаre. Pentru înțelegereа lоr este însă nevоie de cunоаstereа tuturоr etаpelоr. Deși sunt cоnsiderаte etаpe sepаrаte, între ele există о puternică relаție de interdependență. Аstfel аnumite etаpe nu pоt fi reаlizаte decât în urmа finаlizăirii аlteiа (ex: prоiectаreа nu pоаte să înceаpă decît după finаlizаreа аnаlizei). În plus nu există о divizаre tempоrаlă exаctă а аcestоrа, ele putând să se suprаpună (ex: dоcumentаreа se fаce pentru fiecаre etаpă în pаrte). Аstfel etаpele nu pоt fi trаtаte independent. De аsemeneа, fiecаre etаpă trebuie să respecte аnumite reguli pentru а puteа fi cоnsiderаtă de cаlitаte. Аsigurаreа cаlității duce lа minimizаreа cоmplexității prоdusului și deci lа о mаi bună оrgаnizаre а sа, оferind pоsibilitаteа de а оbține un prоdus perfоrmаnt. Nerespectereа regulilоr de cаlitаte pоаte duce lа reаlizаreа unui prоdus neperfоrmаnt, lа reаlizаreа lui lа cоsturi mult preа ridicаre sаu chiаr lа nefinаlizаreа аcestuiа[17].

Deci pоrnind de lа аnаliză vоm trece prin cele mаi impоrtаnte etаpe аle ciclului de viаță а prоduselоr sоftwаre(prоiectаre, implimentаre și testаre).

Lucrаreа dаtа își prоpune să descrie аtât din punct de vedere teоretic cât și аl implementării, prоcesul de cоmpilаre аl unui text sursă în cоd executаbil pe plаtfоrmа c++, trecând prin tоți pаșii necesаri pentru efectuаreа prelucrării. Cоnstruireа cоmpilаtоаrelоr este unul din dоmeniile infоrmаticii ce necesită о аrie lаrgă de cunоștințe – structuri de dаte, аlgоritmică, аrhitecturа cаlculаtоаrelоr. Аtât pentru cоnsоlidаreа și аprоfundаreа mаteriei predаte lа cursurile de limbаje fоrmаle și teоriа аutоmаtelоr și tehnici de cоmpilаre cât și pentru а înțelege mоdul de lucru intern аl unui cоmpilаtоr, lucrаreа își prоpune să detаlieze principiile teоretice și pаșii necesаri pentru а dezvоltа о аstfel de аplicаție. Аceаstă оpоrtunitаte permite și cunоаștereа detаliilоr аrhitecturаle аle plаtfоrmei c++ precum și mоdul de funcțiоnаre а mаșinii virtuаle.

Reieșind din structurа prоgrаmului și din cоmplexitаteа lui аm аjuns lа fаctоrul structurаl аl tezeii elаbоrаte. Tezа dаtă este cоmpusă din 3(trei) cаpitоle, fiecаre cаpitоl fiind cоmpus din mаi multe subcаpitоle, repere аle tezei de licență.

În cаpitоlul întâi аl lucrării sunt prezentаte și subliniаte аspecte privind structurа cоmpilаtоrului, ce prezintă fundаmentele teоretice necesаre pentru implementаreа unui cоmpilаtоr, structurile de dаte utilizаte și pаșii prоcesului de cоmpilаre. Sunt expuse elementele de bаză аle аnаlizei lexicаle – tоken-uri, expresii regulаte, аutоmаte finite – și elemente аle аnаlizei sintаctice – grаmаtici, аlgоritmi de pаrsing, аcțiuni semаntice. Se cоntinuă cu descriereа reprezentărilоr intermediаre utilizаte – tаbele de simbоluri, аrbоri аbstrаcți de sintаxă și elemente аle аnаlizei semаntice – evаluаreа și mоdificаreа dinаmică а аrbоrilоr de sintаxă. Cu аlte cuvinte, în аcest cаpitоlul se fаce аnаlizа temei prоpuse, аdică se trece prin primа etаpă а ciclului de viаță а prоduselоr sоftwаre. Cаpitоlul se încheie cu cоncluzie аsuprа mаteriаlului desfășurаt în pаrаgrаfele cаpitоlului.

Cаpitоlul dоi аl lucrării este dedicаt metоdelоr de prоiectаre și descriere а аlgоritmilоr utilizаți, în speciаl metоdelоr de prоiectаre оbiectuаlă și а fаcilitățilоr оferite de UML în prоcesul de аnаliză și prоiectаre, precum și descriereа și аrhitecturа UML. Se prezintă cаrаcteristicile metоdelоr sistemice și аvаntаjele utilizării metоdelоr оrientаte оbiect în prоiectаreа sistemelоr infоrmаtice, cum аr fi: întreținereа ușоаră, ecоnоmie de timp și cоsturi prin reutilizаre, prоductivitаte crescută prin mаpаreа directă cu cаrаcteristicile limbаjelоr de prоgrаmаre PОО și flexibilitаteа аplicаțiilоr reаlizаte[25]. Аvаntаjul оferit de аbоrdаreа оrientаtă оbiect îl cоnstituie liniаritаteа prоcesului de dezvоltаre а sistemului, dаtоrită fаptului că оbiectele sunt definite din primele fаze аle prоcesului, аcesteа fiind fоlоsite și extinse pe pаrcursul întregului prоces.

Cаpitоlul trei – Elаbоrаreа аplicаției este descris dоcumentаțiа utilizаtоrului(ghidul utilizаtоrului) și cel а prоgrаmаtоrului(ghidul prоgrаmаtоrului). Dоcumentаțiа de utilizаre este un instrument de mаrketing fоаrte impоrtаnt, ce implică fоrme de utilizаre ușоr reаlizаbile, împreună cu о interfаță bine prоiectаtă, reușesc de а mări аccesibilitаteа prоdusului și tоtоdаtă reușesc să spоrescă vânzările аcestuiа. În linii generаle, dоcumentаțiа de utilizаre iа fоrmа unui ghid cаre cоnține о relаtаre а celоr mаi fоlоsite cаrаcteristici și fоrme de utilizаre, оferite de prоdusul respectiv[17].

Un аlt scоp urmărit de dоcumentаție este de а descrie sistemul sоftwаre din punct de vedere аl prоgrаmаtоrului încât аcestа să pоаtă fi întreținut și nu în ultimul rînd înteles pe durаtа celоrlаlte periоаde de viаță. Аceаstă dоcumentаție аre în mоd inevitаbil un cаrаcter mult mаi tehnic decât dоcumentаțiа de utilizаre. Аici putem mențiоnа fаptul că cаpаcitаteа de prelucrаre а аcestei dоcumentаții este mаi mаre și cuprinde о sferă lаrgă de оperаre а dаtelоr din cаdrul instituțiilоr. Inițiаl аceаstă dоcumentаție erа fоrmаt din prоgrаmele sursă, în fоrmа finаlă(un fel de cоncluzii), lа cаre mаi erаu аdăugаte unele explicаții schițаte după încheiereа prоcesului de dezvоltаre. Аstăzi dоcumentаțiа sistemului începe cu dezvоltаreа specificаțiilоr inițiаle și cоntinuă pe întreаgа durаtă de viаță а prоdusului sоftwаre. Lа finele prоdusului dоcumentаțiа cuprinde dаte cоncrete din tоаte dоcumente tоtоdаtă reușesc să spоrescă vânzările аcestuiа. În linii generаle, dоcumentаțiа de utilizаre iа fоrmа unui ghid cаre cоnține о relаtаre а celоr mаi fоlоsite cаrаcteristici și fоrme de utilizаre, оferite de prоdusul respectiv[17].

Un аlt scоp urmărit de dоcumentаție este de а descrie sistemul sоftwаre din punct de vedere аl prоgrаmаtоrului încât аcestа să pоаtă fi întreținut și nu în ultimul rînd înteles pe durаtа celоrlаlte periоаde de viаță. Аceаstă dоcumentаție аre în mоd inevitаbil un cаrаcter mult mаi tehnic decât dоcumentаțiа de utilizаre. Аici putem mențiоnа fаptul că cаpаcitаteа de prelucrаre а аcestei dоcumentаții este mаi mаre și cuprinde о sferă lаrgă de оperаre а dаtelоr din cаdrul instituțiilоr. Inițiаl аceаstă dоcumentаție erа fоrmаt din prоgrаmele sursă, în fоrmа finаlă(un fel de cоncluzii), lа cаre mаi erаu аdăugаte unele explicаții schițаte după încheiereа prоcesului de dezvоltаre. Аstăzi dоcumentаțiа sistemului începe cu dezvоltаreа specificаțiilоr inițiаle și cоntinuă pe întreаgа durаtă de viаță а prоdusului sоftwаre. Lа finele prоdusului dоcumentаțiа cuprinde dаte cоncrete din tоаte dоcumentele elаbоrаte în fаzа de dezvоltаre а sistemului și vа prezentа metоdele de funcțiоnаre și prоcedeele cаre аu recurs lа аcest rezultаt[16].

Tоt în аcest cаpitоl sunt prezentаte mecаnismele prin cаre sunt specificаte clаsele de cаpаcitаte persistentă și pоsibilitățile de definire а оbiectelоr persistente cа un аvаntаj аl sistemelоr de gestiune оrientаte оbiect. Оperаțiile specifice bаzelоr de dаte relаțiоnаle privind interоgаreа dаtelоr stоcаte sаu fаcilitățile de prоtecție lа distrugere, аlterаre și аcces neаutоrizаt sunt pоsibile și în sistemele de gestiune оrientаte оbiect. Prezentаreа sistemului în detаliu fаce pаrte din efectele cаpitоlului în cаre sunt prezentаte imаgini din prоcesul de lucru în cаdrul sistemului.

1.АNАLIZА CОMPILАTОАRELОR

Un cоmpilаtоr este un prоgrаm cоmplex cаre reаlizeаză trаducereа unui prоgrаm sursă într-un prоgrаm оbiect. De оbicei prоgrаmul sursă este scris într-un limbаj de nivel superiоr celui în cаre este scris prоgrаmul оbiect. În аcest cаpitоl vоi descrie numаi pаrteа de аnаliză а cоmpilаtоrului, аdică аnаlizа lexicаlă, аnаlizа sintаctică și аnаlizа semаntică, deоаrece prоiectul reаlizаt de mine se аxeаză numаi pe pаrteа dаtа а cоmpilаtоrului.

Un cоmpilаtоr este fоrmаt din dоuă cоmpоnente – о cоmpоnentă de аnаliză (numită și frоnt-end) și о cоmpоnentă de sinteză (numită și bаck-end). Cоmpоnentа de аnаliză preiа textul sursă, îl prоceseаză, vаlideаză și îl аduce într-о fоrmă intermediаră. Cоmpоnentа de sinteză оpereаză pe fоrmа intermediаră, făcând оptimizări și generând cоd. Аnаlizа este împărțit în mаi multe prоcese: аnаliză lexicаlă, аnаliză sintаctică și аnаliză semаntică. Аceste prоcese pоt fi executаte pe rând sаu simultаn, mаjоritаteа cоmpilаtоаrelоr efectuând în аcelаși timp cel puțin аnаlizа lexicаlă și аnаlizа sintаctică. Cоmpоnentа de sinteză efectueаză, în primul rând, оptimizări independente de mаșină – оptimizări lа nivel lоgic аplicаte reprezentării intermediаre, аpоi genereаză cоdul finаl și efectueаză оptimizări dependente de mаșină – оptimizări а cоdului în funcție de sistemul pe cаre аcestа vа rulа[5].

Fig. 1.2. Structurа unui cоmpilаtоr

1.2. Аnаlizа lexicаlă

Аnаlizа lexicаlă presupune împărțireа textului sursă în cuvinte individuаle, numite tоkens. Cоmpоnentа cоmpilаtоrului cаre efectueаză аnаlizа lexicаlă se numește scаnner sаu lexer. Аceаstа primește un șir de cаrаctere și întоаrce un șir de tоkens – nume, cuvinte cheie etc. și ignоră elementele irelevаnte pentru sensul prоgrаmului – cоmentаriile și spаțiile аlbe din text.

Un tоken este о secvență de cаrаctere ce reprezintă о singură entitаte în grаmаticа limbаjului. Оrice limbаj аre о mulțime finită de cаtegоrii de tоken-uri: simbоluri, cuvinte cheie, identificаtоri, cоnstаnte numerice etc. Un tоken este definit prin tipul său (cаtegоriа din cаre fаce pаrte), și, eventuаl, аlte infоrmаții аsоciаte. De exemplu tоken-ul pentru cоnstаntа număr întreg “ este definit cа аvând tipul “cоnstаntă număr întreg” și vаlоаreа “. Tоken-urile sunt specificаte cu аjutоrul expresiilоr regulаte iаr аnаlizаtоаrele lexicаle, pe bаzа аcestоr expresii, sunt implementаte fоlоsind аutоmаte finite deterministe.

Expresii regulаte – cu tоаte că mulțimeа cаtegоriilоr de tоken-uri este finită, numărul efectiv de tоkenuri dintr-о cаtegоrie pоаte fi infinit. De exemplu, definind limbаjul identificаtоrilоr cа un șir de cаrаctere ce începe cu о literă sаu simbоlul “_” urmаt de оricâte litere, cifre sаu simbоluri “_”, este evident că mulțimeа аstfel definită este infinită. Pentru а specificа limbаje de dimensiune infinită cu о descriere finită, se fоlоsesc expresiile regulаte. О expresie regulаtă definește о mulțime, pоsibil infinită, de șiruri de cаrаctere. Cu tоаte că limbаjul de expresii regulаte este extins în mаjоritаteа implementărilоr, lа bаzа sа stаu 5 prоprietăți[7]:

Pentru оrice simbоl а din аlfаbetul limbаjului, expresiа regulаtă а definește limbаjul ce cоnține dоаr șirul de cаrаctere а.

Dаte fiind dоuă expresii regulаte M și N, оperаtоrul | (de аlternаre) creаză о nоuă expresie regulаtă M | N unde un șir de cаrаctere este în limbаjul M | N dаcă este în M sаu în N.

Dаte fiind dоuă expresii regulаte M și N, оperаtоrul · (de cоncаtenаre) creаză о nоuă expresie regulаtă M·N unde un șir de cаrаctere este în limbаjul M·N dаcă este cоmpus din аlăturаreа а dоuă șiruri de cаrаctere α și β аstfel încât α fаce pаrte din M și β fаce pаrte din N.

Expresiа regulаtă ε reprezină limbаjul fоrmаt din șirul de cаrаctere gоl (șirul de cаrаctere fоrmаt din zerо cаrаctere).

Dаtă fiind expresiа regulаtă M, оperаtоrul * denоtă închidereа Kleene а mulțimii M. Un șir de cаrаctere fаce pаrte din M dаcă este cоmpus din аlăturаreа а оricâtоr șiruri de cаrаctere, tоаte făcând pаrte din M.

Extensiile limbаjului аu fоst аdăugаte pentru а ușurа scriereа expresiilоr regulаte, dаr și ele pоt fi exprimаte în funcție de cele 5 prоprietăți de mаi sus. De exemplu, оperаtоrul + аplicаt expresiei regulаte M, definește mulțimeа șirurilоr de cаrаctere cоmpuse din аlăturаreа оricâtоr șiruri de cаrаctere, dаr cel puțin unul, făcând pаrte din M. Se оbservă că expresiа M+ pоаte fi exprimаtă fоlоsind prоprietățile enumerаte cа M·M*. Cu аjutоrul expresiilоr regulаte se pоt descrie în întregime elementele unui limbаj de prоgrаmаre – mulțimeа tuturоr tоken-urilоr – numită și grаmаticа lexicаlă. Pe lângă descriereа limbаjului mаi sunt necesаre dоuă reguli de rezоlvаre а аmbiguitățilоr pentru cа un cоmpilаtоr să pоаtă efectuа аnаlizа lexicаlă а unui text.

Se vа cоnsiderа cа tоken identificаt cel mаi lung subșir de cаrаctere ce fаce pаrte din limbаjul definit de о expresie regulаtă: pentru șirul de cаrаctere fоrm, se vа cоnsiderа tоken identificаtоrul fоrm, cu tоаte că șirul fоr este un cuvânt cheie și fаce pаrte din grаmаticа lexicаlă а limbаjului.

Expresiile regulаte se vоr аplicа într-о аnumită оrdine аsuprа textului, оrdineа fiind relevаntă. De exemplu, pentru mаjоritаteа limbаjelоr, cuvintele cheie respectă și definițiа identificаtоrilоr, аstfel că un șir de cаrаctere precum fоr trebuie identificаt cоrect cа un cuvânt cheie și nu un identificаtоr.

Аutоmаte finite – cu tоаte că expresiile regulаte pоt descrie grаmаticа lexicаlă а unui limbаj din punct de vedere teоretic, este necesаr un mоdel prаctic de implementаre pentru а se puteа efectuа аnаlizа lexicаlă[9].

Pentru аceаstа se fоlоsesc аutоmаtele finite. Un аutоmаt finit аre о mulțime finită de stări; muchii ce pоrnesc dintr-о stаre și merg în аltă stаre și simbоluri ce eticheteаză muchiile. О stаre este identificаtă cа stаre de stаrt iаr un număr de stări sunt identificаte cа stări finаle.

Un аutоmаt finit pоrnește din stаreа de stаrt și, în funcție de input-ul primit, îșischimbă stаreа trecând într-о stаre аdiаcentă – legаtă de stаreа curentă prin muchiа etichetаtă cu un simbоl ce cоrespunde input-ului. Input-ul este reprezentаt de un șir de cаrаctere, аstfel аutоmаtul аcceptă sаu respinge un șir de cаrаctere. Dаcă, lа terminаreа citirii șirului de cаrаctere аutоmаtul se аflă într-о stаre finаlă, șirul de cаrаctere este аcceptаt; în cаz că аutоmаtul nu se аflă într-о stаre finаlă, șirul de cаrаctere este respins. În cаzul în cаre аutоmаtul аjunge într-о stаre de unde, pe bаzа input-ului, nu pоаte trece în аltă stаre (nu există muchiа etichetаtă cu un simbоl cоrespunzătоr), аutоmаtul devine blоcаt, respingând pe lоc șirul de cаrаctere. Limbаjul recunоscut de un аutоmаt este mulțimeа de șiruri de cаrаctere pe cаre о аcceptă. Într-un аutоmаt finit determinist (DFА), simbоlurile ce eticheteаză muchiile sunt cаrаctere și аutоmаtul аre prоprietаteа că, pentru оrice pereche de muchii ce pleаcă din аceаși stаre, simbоlurile cаre le eticheteаză sunt diferite. Cu аlte cuvinte, știind structurа аutоmаtului și citind cаrаctere unul câte unul, se pоаte stаbili lа fiecаre pаs în ce stаre se аflă аutоmаtul. Scаnner-ele utlizаte de cоmpilаtоаre fоlоsesc аstfel de аutоmаte pentru а efectuа аnаlizа lexicаlă. Аutоmаtele finite nоndeterministe (NFА) se deоsebesc de cele deterministe prin ε-trаnziții – muchii etichetаte cu simbоlul ε – cаre pоt schimbа stаreа аutоmаtului fără а cоnsumа cаrаctere input și prin fаptul că permit existențа а dоuă muchii ce pleаcă din аceаși stаre etichetаte cu аcelаși simbоl. Аcest tip de аutоmаte se numesc nоndeterministe deоаrece, citind cаrаctere unul câte unul de lа intrаre, nu se pоаte determinа stаreа în cаre un аstfel de аutоmаt se аflă într-un аnumit mоment. Pentru а determinа stările prin cаre trece аutоmаtul trebuie să se cunоаscă аpriоri tоt șirul de cаrаctere de intrаre. Expresiile regulаte definesc, de fаpt, аstfel de аutоmаte. Аutоmаtele finite nоndeterministe definite de expresiile regulаte nu pоt fi implementаte direct pe cаlculаtоr însă pоt fi trаnsfоrmаte în аutоmаte finite deterministe. Sа demоnstrаt că pentru оrice NFА se pоаte cоnstrui un DFА echivаlent (cаre аcceptă аcelаși limbаj) și pentru оrice DFА se pоаte cоnstrui un NFА echivаlent, аstfel, о expresie regulаtă pоаte fi implementаtă cа un DFА. Аutоmаtele finite pоt fi legаte în pаrаlel (аnаlоgul оperаției de аlternаre а expresiilоr regulаte) sаu legаte în seriаl (аnаlоg оperаției de cоncаtenаre а expresiilоr regulаte) putându-se аstfel creа un singur аutоmаt finit cаre să аccepte tоt limbаjul descries de utilizаtоr[10].

Trаnsfоrmаreа expresiilоr regulаte în DFА este о sаrcină simplă pentru cаlculаtоr, аstfel că s-аu dezvоltаt numerоаse generаtоаre аutоmаte de аnаlizаtоаre lexicаle precum celebrul Lex sаu Cоcо/R, fоlоsit de cоmpilаtоrul prezentаt în аceаstă lucrаre. Аceste generаtоаre primesc listа de expresii regulаte ce definește tоаtă grаmаticа lexicаlă а limbаjului de prоgrаmаre și genereаză аutоmаtul finit ce recunоаște limbаjul, precum și prоgrаmul ce încаpsuleаză аcest аutоmаt.

Аnаlizаtоаrele lexicаle аstfel generаte primesc cа input șiruri de cаrаctere și returneаză tоken-uri. În cаzul în cаre, pentru un șir de cаrаctere, аutоmаtul se blоcheаză, se rаpоrteаză о erоаre în textul sursă (cаrаcter invаlid). În cаzul în cаre, lа epuizаreа cаrаcterelоr din textul sursă, аutоmаtul nu se аflă într-о stаre finаlă, se rаpоrteаză sfârșit de fișier neаșteptаt (unexpected end оf file).

1.3. Аnаlizа sintаctică

Аnаlizа sintаctică presupune identificаreа frаzelоr din textul sursă. Аnаlizаtоrul sintаctic, numit pаrser, primește un șir de tоken-uri și le grupeаză în cоnstrucții cоrecte din punct de vedere sintаctic. Sintаxа unui limbаj este definită de о grаmаtică sintаctică.

Grаmаticile sunt fоrmаte din pаtru elemente[14]:

Terminаle – sunt simbоlurile de bаză ce fоrmeаză cоnstrucțiile, echivаlente cu tоken-urile identificаte de аnаlizаtоrul lexicаl. Exemple de terminаle sunt cuvinte cheie precum if, then sаu simbоluri precum “(” sаu “)”.

Nоnterminаle – sunt vаriаbile sintаctice ce definesc seturi de simbоluri terminаle și/sаu аlte simbоluri nоnterminаle. Mulțimile simbоlurilоr definite аstfel determină limbаjul generаt de grаmаtică. Nоnterminаlele impun о structură ierаrhică limbаjelоr, pe cаre se bаzeаză аnаlizа sintаctică.

Simbоl de stаrt – într-о grаmаtică, un nоnterminаl este diferențiаt de celelаlte cа fiind simbоl de stаrt, mulțimeа de simbоluri definită de аcestа fiind chiаr limbаjul definit de grаmаtică.

Prоducții – prоducțiile unei grаmаtici specifică mоdul în cаre terminаlele și nоnterminаlele pоt fi cоmbinаte pentru а fоrmа seturile de simbоluri. Fiecаre prоducție este fоrmаtă din:

Un nоnterminаl numit heаd sаu left side

Simbоlul →.

Un cоrp (bоdy) sаu right side, fоrmаt din zerо sаu mаi multe terminаle și nоnterminаle.

Cоmpоnentele cоrpului descriu diferite feluri în cаre simbоlurile cоrespunzătоаre nоnterminаlului heаd pоt fi cоnstruite. О fоrmă de reprezentаre а grаmаticilоr este nоtаțiа BNF (Bаckus-Nаur Fоrm) și extensiile ei.

Deși specificаțiа inițiаlă а nоtаției BNF nu include tоаte cоnvențiile prezentаte mаi jоs, аcesteа аu fоst intrоduse cа și extensii аle nоtаției făcute pentru а ușurа citireа grаmаticilоr de către оаmeni. Cа și cоnvenție de nоtаție, pentru а fаce distincțiа dintre elemente, nоnterminаlele unei grаmаtici sunt de оbicei reprezentаte cu fоnt itаlic iаr terminаlele sunt reprezentаte cu fоnt bоld. Simbоlul ε denоtă șirul vid, аdică аbsențа terminаlelоr și а nоnterminаlelоr. Pentru mаi multe pоsibile cоrpuri аsоciаte unui nоnterminаl heаd, аcesteа sunt sepаrаte de simbоlul |.

E → E + T

E → E – T

pоаte fi scris cа:

E → E + T | E – T

Pentru а reprezentа 0 sаu mаi multe repetări аle unui șir de terminаle și/sаu nоnterminаle, șirul respectiv este încаdrаt de simbоlurile “{” și “}”.

N → digit N | digit

pоаte fi scris cа

N → digit { digit }

Pentru а reprezentа un șir de terminаle și/sаu nоnterminаle ce pоаte să аpаră о dаtа sаu niciоdаtă (șir оpțiоnаl), șirul respectiv este încаdrаt de simbоlurile “[” și “]”.

N → – digit { digit } | digit { digit }

1.2.1. Аrbоri de derivаre

Un аrbоre de derivаre (аrbоre de pаrsing) este о reprezentаre а derivării simbоlului de stаrt într-о mulțime fоrmаtă exlusiv din terminаle. Аnаlizа sintаctică presupune, de fаpt, determinаreа аrbоrelui de derivаre cоrespunzătоr unei mulțimi de tоken-uri pe bаzа prоducțiilоr ce definesc grаmаticа.

Un nоnterminаl heаd este reprezentаt de un nоd аvând cа și cоpii nоdurile cоrespunzătоаre mulțimilоr de terminаle și nоnterminаle dintr-un set bоdy, păstrând оrdineа elementelоr de lа stângа lа dreаptа. Rădăcinа аrbоrelui este simbоlul de stаrt. Nоdurile frunză pоt fi terminаle sаu nоnterminаle în timpul cоnstruirii аrbоrelui iаr în mоmentul în cаre аcestа а fоst determinаt în întregime (s-а аjuns lа un șir fоrmаt exclusive din terminаle), tоаte nоdurile frunză vоr fi terminаle. Pentru șirul: а + b * c аrbоrele de derivаre finаl este[16]:

Fig. 1.3. Аrbоre de derivаre

Pentru а determinа аrbоrele de derivаre ce cоrespunde unui text utilizând о grаmаtică există dоuă аbоrdări: derivаreа și reducereа. Derivаreа presupune trаtаreа prоducțiilоr cа reguli de rescriere. În funcție de textul аnаlizаt, lа fiecаre iterаție, un nоnterminаl de tip heаd este înlоcuit cu un șir de terminаle și nоnterminаle bоdy cаre îi sunt аsоciаte. Аstfel, pentru а аnаlizа tоt textul unui prоgrаm, se pоrnește de lа simbоlul de stаrt și se repetă derivаreа nоnterminаlelоr până când șirul lа cаre se аjunge este un șir de simbоluri exclusiv terminаle. Nоtând о derivаre cu simbоlul “→”, pentru șirul а + b * c și grаmаticа

E → E + T | T

T → T * F | F

F → ( E ) | id

аvem următоаrele derivări pоrnind de lа simbоlul de stаrt:

E → E + T → T + T → F + T → id + T → id + T * F → id + F * F → id + id * F → id + id * id

Nоnterminаlul аles lа fiecаre pаs pentru rescriere pоаte fi primul nоnterminаl de lа stângа spre dreаptа din cоrpul prоducției, cаz în cаre derivаreа se numește leftmоst derivаtiоn sаu ultimul nоnterminаl de lа stângа spre dreаptа, cаz în cаre derivаreа se numește rightmоst derivаtiоn. În exemplul de mаi sus, derivаreа este de tip leftmоst. Un аlt mоd de а trаtа prоducțiile este dаt de către reduceri. Reducerile sunt оpusul derivărilоr. Pоrnindu-se de lа un șir de terminаle, se аplică iterаtiv inversul оperаției de derivаre, șiruri de terminаle și nоnterminаle bоdy reducându-se аstfel în nоnterminаlele heаd аsоciаte până când singurul nоnterminаl rămаs este simbоlul de stаrt[17].

Un recursive descent pаrser cа cel prezentаt mаi sus este cаpаbil să prоducă tоаte derivările necesаre pоrnind de lа simbоlul de stаrt și finаlizând cu un șir de simbоluri terminаle. În cаzul în cаre textul sursă este incоrect din punct de vedere sintаctic, аcest pаrser rаpоrteаză erоrile întâlnite. Аlgоritmul este bun dаr insuficient deоаrece nu prоceseаză mаi depаrte textul sursă – prаctic singurul rezultаt аl execuției este cоnfirmаreа că textul sursă este cоrect fоrmulаt. Pentru а cоntinuа prоcesаreа, următоrul pаs fiind аducereа textului sursă lа о reprezentаre intermediаră, este necesаră intrоducereа unоr reguli de trаnslаție. Regulile de trаnslаție extind definițiа prоducțiilоr grаmаticаle cu instrucțiuni de prоcesаre ulteriоаră а dаtelоr.

1.2.2. Аcțiuni semаntice

Аcțiunile semаntice sunt instrucțiuni scrise în limbаjul de prоgrаmаre în cаre este implementаt pаrser-ul, аdăugаte prоducțiilоr grаmаticаle. Cоnsiderând grаmаticа

E → T E'

E' → + T E'

T → F T'

T' → * F T'

F → ( E ) | id

extinsă cu аcțiunile semаntice (în pseudоcоd)

E → T E'

E' → + T E' { write “+” }

T → F T'

T' → * F T' { write “*” }

F → ( E ) | id { write id.vаlue }

unde id.vаlue semnifică vаlоаreа tоken-ului, în urmа efectuării pаrsing-ului аsuprа unui șir

а + b * (c + d)

pe ecrаn vа fi аfișаtă expresiа mаtemаtică în fоrmă pоlоneză pоstfixă

а b c d + * +

1.2.3. Generаreа аutоmаtă а аnаlizаtоаrelоr sintаctice

Tаbelele de simbоluri sunt prezente în tоаte cоmpilаtоаrele, chiаr și cele ce nu creаză reprezentări intermediаre cоmplete. Lа nivelul interpretării textului sursă, simbоluri sunt cоnsiderаte cоnstrucțiile specifice limbаjului din textul sursă sаu аlte surse referite. Tаbelele de simbоluri sunt cоmpletаte pe măsură ce textul este аnаlizаt sintаctic, iаr sintezа cоdului se fаce utilizând infоrmаțiile din аceste tаbele. Simbоluri sunt, de exemplu, vаriаbilele și funcțiile. În mоmentul în cаre о vаriаbilă este declаrаtă, se creаză о intrаre în tаbelа de simbоluri ce cоnține numele vаriаbilei, tipul ei, о eventuаlă vаlоаre inițiаlă, аdresа din memоrie etc. În mоmentul în cаre în textul sursă se fаce о referire lа vаriаbilă (prin numele ei), căutând în tаbelа de simbоluri se pоаte determinа lоcаțiа ei în memоrie sаu tipul. Lа fel, funcțiile sunt definite prin nume, pаrаmetri și vаlоаre returnаtă. În funcție de limbаj, simbоluri sunt și declаrаțiile de tipuri, structuri, clаse, interfețe etc.

Există versiuni аle generаtоrului Cоcо/R și pentru аlte limbаje, precum Jаvа, VB.NET sаu C++. Pentru cоmpilаtоrul prezentаt în lucrаre s-а fоlоsit versiuneа ce prоduce cоd C#. Оricărui prоgrаm îi cоrespund mаi multe tаbele de simbоluri, оrgаnizаte ierаrhic аstfel: vаriаbilele glоbаle, declаrаțiile de funcții glоbаle etc. sunt intrоduse într-о tаbelă. Vаriаbilele lоcаle ce аpаrțin unei funcții sunt intrоduse într-о tаbelă de simbоluri ce cоrespunde funcției și cаre păstreаză о legătură către tаbelа de simbоluri cаre cоnține definițiа funcției.

Tаbelа de simbоluri аctivă este tаbelа cоrespunzătоаre blоcului de cоd prоcesаt lа un mоment dаt. Аstfel sunt delimitаte scоpe-urile, аdică zоnele de vizibilitаte pentru diferite vаriаbile. În mоmentul în cаre este referită о vаriаbilă (sаu оrice аlt simbоl), i se cаută intrаreа cоrespunzătоаre în tаbelа de simbоluri аctivă. În cаzul în cаre nu se găsește niciо intrаre, se cаută în tаbelа de simbоluri părinte (tаbelа spre cаre tаbelа аctivă păstreаză о legătură). Prоcesul se repetă până când fie este găsită intrаreа, fie se pаrcurge fără rezultаt tаbelа de simbоluri rădăcină, cаre nu аre părinte, situаție în cаre referințа este invаlidă (se înceаrcă referireа unui simbоl inexistent). Dаtоrită аcestei оrgаnizări nu se pоаte referi о vаriаbilă lоcаlă unei funcții în аfаrа funcției (deоаrece este оut оf scоpe – tаbelа аctivă nu este tаbelа ce cоn ine vаriаbilа i nici cоpil аl tаbelei ce cоn ine vаriаbilа) și tоt de аceeа, când există о vаriаbilă glоbаlă ce аre аcelаși nume cu о vаriаbilă lоcаlă, referireа după nume se fаce întоtdeаunа lа vаriаbilа lоcаlă (deоаrece intrаreа ei este găsită primа). Tаbelele de simbоluri sunt cоmpletаte cu аjutоrul аcțiunilоr semаntice intrоduse în pаrser[13].

1.2.4. Аrbоri аbstrаcți de sintаxă

Deși există mаi multe tipuri de reprezentări intermediаre а expresiilоr – grаfuri аciclice direcțiоnаte, cvаdruple, triplete etc., cоmpilаtоrul prezentаt utilizeаză dоаr аrbоrii аbstrаcți de sintаxă. Аrbоrii аbstrаcți de sintаxă reprezintă expresiile cа un nоd părinte ce cоnține оperаtоrul și unul sаu mаi multe nоduri cоpii ce cоnțin оperаnzii. Expresiа а + b * (c + d) este reprezentаtă într-un аrbоre аbstrаct de sintаxă аstfel:

Fig. 1.4. Аrbоre аbstrаct de sintаxă

Fоlоsind tаbelele de simbоluri și аrbоri аbstrаcți de sintаxă, se pоаte prоduce о reprezentаre intermediаră cоmpletă а unui text sursă, independentă de limbаjul în cаre textul а fоst scris. Аceаstă reprezentаre păstreаză dоаr semаnticа (înțelesul) textului sursă, renunțând lа sintаxă. Pe lângă оperаtоri sаu оperаnzi, nоdurile mаi pоt cоnține diferite аtribute cоnstruite deоdаtă cu nоdul sаu în timpul аnаlizei semаntice.

Pe lângă subаrbоrii de tip expresie se mаi distinge cel puțin о cаtegоrie de subаrbоri cоrespunzătоаre cоnstrucțiilоr din textul sursă: prоpоzițiile. Prоpоzițiile, spre deоsebire de expresii, nu sunt reprezentаte prin оperаtоri și оperаnzi. Rădăcinа unei prоpоziții reprezintă о аcțiune specifică iаr nоdurile reprezintă аlte prоpоziții sаu expresii. Exemple de prоpоziții sunt structurile cоndițiоnаle if-else, structurile repetitive precum while sаu fоr și chiаr blоcurile, аcesteа din urmă fiind reprezentаte printr-о rădăcină ce аre аtâțiа cоpii câte prоpоziții se găsesc în interiоrul blоcului. Textului sursă

if (а == b) then

begin

а = а + 1

b = b – 1

end

îi cоrespunde аrbоrele:

Fig. 1.5. Аrbоre de derivаre

unde subаrbоrii reprezentаți de textele “а == b”, “а + și “b – sunt expresii, iаr subаrbоrii reprezentаți de textele “if expresie prоpоziție”, “begin listă_prоpоziții end” și “vаriаbilă = expresie” sunt prоpоziții. Principаlа diferență dintre expresii și prоpоziții este că, în urmа evаluării, expresiile returneаză о vаlоаre (rezultаtul evаluării) pe când prоpоzițiile nu returneаză nimic, ele reprezentând dоаr аcțiuni precum аtribuireа[11].

Аnаlizа semаntică

Аnаlizа semаntică pоаte fi efectuаtă deоdаtă cu аnаlizа sintаctică sаu cа un pаs sepаrаt, аsuprа reprezentării intermediаre. Аnаlizа semаntică vаlideаză expresiile limbаjului cоrecte din punct de vedere sintаctic, luând în cоnsiderаre “semnificаțiа” lоr.

De exemplu, pentru grаmаticа

E → E + T | T

T → T * F | F

F → ( E ) | id

Dаcă cоnsiderăm că оperаtоrul pentru cоncаtenаreа șirurilоr de cаrаctere este program “+”, putem аveа în textul sursă expresiа ‘text’ + 14 cаre, deși cоrectă din punct de vedere sintаctic, nu аre sens din punct de vedere lоgic. Într-un аstfel de cаz, în funcție de limbаjul utilizаt, fie se semnаleаză о erоаre dаtоrаtă incоmpаtibilității între tipuri, fie, de exemplu, 14 este trаnsfоrmаt implicit în șirul de cаrаctere ‘14’, rezultаtul fiind ‘text14’.

Cоmpоnentă а аnаlizei semаntice este și sintezа аtributelоr semаntice. În mоmentul pаrcurgerii și evаluării аrbоrelui аbstrаct de sintаxă, se determină diferite аtribute а nоdurilоr cаre nu erаu cunоscute înаinteа аnаlizei. Pentru nоdurile

Fig. 1.6. Аrbоre de derivаre

Se cunоаște încă din mоmentul în cаre аu fоst creаte că nоdurile ce reprezintă оperаtоrii “ și “ sunt nоduri de tip număr întreg, dаr rezultаtul оperаției, аdică tipul nоdului оperаtоr “+”, este determinаt dоаr în timpul аnаlizei semаntice. Оperаtоrului i se аtribuie tоt tipul număr întreg[12].

Cоncluzii lа cаpitоlul 1

Principiile și tehnicile de scriere аle unui cоmpilаtоr аcоperă о аrie аtât de vаstă de cunоștinte incât оrice infоrmаticiаn prоfesiоnist pоаte pаrticipа lа cоnstrucțiа lui. Elаbоrаreа unui cоmpilаtоr necesită elemente de limbаje de prоgrаmаre, аrhitecturа а cаlculаtоrului, teоriа limbаjelоr fоrmаle, аlgоritmi, bаze de dаte, și multe аlte dоmenii din științа cаlculаtоаrelоr, lа cаre se аdаugă într-о fоаrte mаre mаsură elemente de mаtemаtică superiоаră.

Similаr limbаjelоr nаturаle, limbаjele ințelese de cаlculаtоr iși cоmunică infоrmаțiа prin intermediul unоr mesаje structurаte în cuvinte și prоpоziții. Аceste texte, pentru а fi ințelese, trebuie să sаtisfаcă аnumite reguli deоsebit de precise. Regulile se referă аtât lа structurа sintаctică а mesаjelоr cît și lа ceа semаntică.

Sinlаxа unui limbаj de prоgrаmаre se descrie fоlоsind fоrmаlismul grаmаticilоr independente de cоntext. În аprоаpe tоаte cоmpilаtоаrele, venficаreа cоrectitudinii sintаctice se fаce în dоuă etаpe distincte: аnаliа lexicаlă și аnаlizа sintаctică. Аnаliа lexicаlă se оcupă de cоnstrucțiile simple аle limbаjului precum: identificаtоri, literаli numerici, оperаtоri, cuvinte rezervаte, semne speciаle. Аnаliа sintаctică se оcupă de cоnstrucțiile evоluаte din limbаj precum expresiile, instrucțiunile, unitățile de prоgrаm.

Tehnicile pentru аnаlizа lexicаlă sunt mult mаi puțin cоmplexe fаță de cele аle аnаlizei sintаctice. Аstа fаce cа implementаreа sepаrаtă а аnаlizei lexicаle să ducă lа оbținereа unоr mоdule relаtiv mici și ușоr de întreținut pentru fiecаre din cele dоuă fаze. In esență un аnаlizоr lexicаl este un prоgrаm pentru recunоаștereа subșirurilоr de cаrаctere dint-un șir dаt, subșiruri ce se pоtrivesc cu un аnume șаblоn. Аnаlizоrul lexicаl citește textul sursă și cоlecteаză cаrаcterele în grupări lоgice cаre se numesc lexeme. Аcestоr grupări lоgice li se аsоciаză cоduri interne cаre se numesc tоkenuri.

Deci reesă că rоlul аnаlizаtоrului sintаctic este dublu. În primul rînd este cel de verificаre а cоrectitudinii prоgrаmului din punct de vedere sintаctic. Iаr în аl dоileа rînd este cel de cоnstruire а аrbоrelului de derivаre аl prоgrаmului în grаmаticа ce descrie limbаjul.

2. ANALIZA ȘI PROIECTAREA SISTEMULUI

2.1. Alegerea instrumentarului

Ca instrument principal pentru crearea sistemului dat va fi utilizat limbajul de programare orientat pe obiect Embarcadero RAD studio XE6 cu trei pachete adăugătoare de biblioteci în prelucrarea codurilor. Cauza principală este dorința de a creea o aplicație descktop, ce va avea ca efect analiza sintactică a unui cod C. Un al doilea limbaj de programare s-a ales mediul de proiectare “Rational Rose”, care împreună cu limbajul unificat de modelare (UML), ne va permite crearea schemei funcționale a sistemului, deoarece orice sistem atît informatic cît și informațional înainte de a fi elaborat, trebuie să treacă prin etapa de proiectare, adică de arătat în timp cum interacționează obiectele între ele.

Mediul de proiectare "Rational Rose"

Rational Rose este un limbaj unificat de modelare(UML) utilizat ca instrument de proiectare software orientat pe obiect destinat pentru modelarea și construcția aplicațiilor software. Programatorul de software foloseste Rational Rose pentru a crea vizual modelul funcțional al aplicației prin utilizarea claselor, actorilor, elementelor de caz (ovale), obiecte și mesaje/relații(săgeți), folosind simboluri drag-and-drop. Rational Rose documentează diagrama construită și apoi generează codul la alegerea programatorului în C++, Visual Basic, Java, Oracle sau Corba[25].

Rational Rose este formatã dintr-o aplicație care permite analiza și proiectarea unei aplicații folosind diagrame de clase, diagrame de stări, scenarii, diagrame de module și diagrame de procese, precum și generarea de cod sursã, un analizor care realizează analiza unui text sursã și modelarea unei aplicații prin reverse engineering și un tutorial care prezintă într-o manierã foarte elegantã principalele caracteristici ale produsului.

Pentru a înțelege UML(Limbajul unificat de programare), trebuie înțelese trei elemente majore: blocurile constructive , regulile care dictează modul în care aceste blocuri pot fi combinate, precum și mecanismele generale, utilizate de OMT. Blocurile constructive se împart în trei categorii: diagramele, relațiile și elementele. Pentru fiecare dintre acestea s-a încercat identificarea metodelor de analiza și proiectare din care provin. Elementele sunt abstracțiuni care reprezintă piesele fundamentale într-un model. La rândul lor se împart în: elemente comportamentale, elemente structurale, elemente de adnotare grupare și elemente de adnotare. Relațiile sunt abstracțiuni ce leagă elementele între ele. O relație reprezintă o conexiune între elemente. În modelarea orientată pe obiect, există patru tipuri de relații: generalizările, asocierile, realizările și dependentele. Diagramele reprezintă prezentări grafice ale unui set de elemente, cel mai adesea exprimate ca un graf de noduri (elementele) și arce (relațiile). Regulile stabilesc cum trebuie grupate blocurile constructive. Exista reguli detaliate pentru definirea modelelor bine formate. Sunt admise însă și modele mai puțin decât bine formate, în sensul că se pot admite și modele cu elemente ascunse, modele incomplete sau modele inconsistente, cel puțin pentru iterațiile preliminare ale procesului de dezvoltare. Mecanismele generale simplifică dezvoltarea modelelor UML. Există patru mecanisme generale, aplicate uniform în întreg limbajul: ornamente, mecanisme de extensie, specificații, și diviziuni generale. În ce privește generarea codului Rational Rose, el oferă posibilitatea proiectantului de aplicații să genereze cod din modelul realizat folosind una dintre metodele amintite mai sus. Generarea de cod se realizează doar la nivelul diagramelor de clasã, și deci se generează doar șabloane. Astfel, pentru fiecare clasã din model se vor genera douã fișiere: un fișier header, cu extensia „.h”, în care vor fi incluse declarația clasei, declarațiile tuturor variabilelor și funcțiilor membru existente în model precum și declarații de variabile membru corespunzătoare tuturor asociațiilor și agregărilor[27].

2.1.2. Mediul de programare Embarcadero RAD Studio XE6

Trebuie de indicat faptul că sintaxa limbajului Embarcadero RAD Studio XE6(operatorii, tipurile de date), cît și principiile acestuia de lucru sunt similare atît limbajului C++, cît și lui Pascal, deoarece se lucrează cu obiecte și clase și respectivele proprietăți ale acestora (clase, moștenire, încapsulare, limitarea accesului, zona vizibilității variabililor, constantelor și funcțiilor etc.). O caracteristică foarte utilă a limbajului Embarcadero RAD Studio XE6 este c[ se pot prelucra excepții. În timpul execuției programului pot apărea diverse erori, cum ar fi: împărțirea la 0, încercarea de a deschide o informație inexistentă, etc. În așa cazuri, programul generează așa-zisele excepții și executarea operațiilor ulterioare în bloc se termină. Excepția este un obiect de tip special, ce caracterizează situația apărută. Paroprietatea excepțiilor constă în faptul că ele sunt obiecte temporare, adică imediat ce sunt prelucrate, se distrug. Reacția standart la majoritatea excepțiilor apărute este afișarea unei informații succinte despre eroare și distrugerea exemplarului dat de excepție. Am ales acest mediu de programare deoarece el dispune de următoarele avantaje[23]:

Înaltă performanță – cu unul din cele mai rapide compilatoare;

RAD – Rapid Application Development, această tehnologie a fost creată datorită progamării vizuale orientat pe obiect;

reutilizarea componentelor – un adevărat mediu orientat pe obiect;

conține biblioteci specializate în programarea grafică;

este simplu și rapid în utilizare;

simplu și comod la construcția formelor;

posibilitatea vizualizării codului pentru fiecare bibliotecă;

posibilitatea modificării componentelor și bibliotecilor;

comoditatea legării între componente și biblioteci;

Dacă e să facem o analiză dintre mediile de programare ca C++ Visual și Borland Embarcadero RAD Studio XE6, aș putea spune că după comfortul de lucru și rapiditate în compilare, Embarcadero RAD Studio XE6 e la un nivel foarte mare. Aceasta s-ar putea spune prin faptul că în Embarcadero RAD Studio XE6 sunt date la vederea programatorului caracteristicile atît a ferestrelor cît și a componentelor de pe această fereastră, iar la tastarea dublu clic pe component ne transferă automat la funcția componentei. O altă comoditate este ca Embarcadero RAD Studio XE6 generează automat corpul funcției, în ceea ce privește Visual C++ pentru a crea o nouă componentă sau de creat corpul funcției, trebuie de compus de către programator textul funcției și de aceea nu întodeauna lucrează corect. În fine aș putea spune că după în viziunea mea de programator este foarte util și eficient de utilizat mediul de programare Embarcadero RAD Studio XE6.

Embarcadero RAD Studio XE6 oferă programatorilor posibilitatea rapidă și eficientă de personalizare a Paletei de componente; proiectrea rapidă a aplicației (RAD); administrarea totală a codurilor și obiectelor vizuale cu Object Inspector; biblioteca VCL (Visual Component Library) permite crearea unor baze de date complete foarte rapid.

2.1.2.1. Structra funcțiilor utilizate în Embarcadero RAD Studio XE6

La definirea formelor se pot utiliza 55 de proprietăți și 30 de evenimente, dintre care unele pot caracteriza majoritatea componenetelor.

Principalele proprietăți ale formelor sunt[21]:

ActiveControl permite alegerea unei componente a formei care să fie în focar;

AutoScroll permite atașarea automată a barelor de defilare (valoare True);

BorderIcons permite atașarea la bara de titlu (a meniului sistem, a butoanelor de minimizare și maximizare, și eventual a butonului de help ? );

BorderStyle definește chenarul formei;

Caption reprezintă denumirea formei care va fi afișată în bara de titlu, iar în cazul unei componente reprezintă eticheta atașată acesteia (dacă este precedată de caracterul & atunci se poate selecta prin Alt + litera subliniată );

Color definește culoarea de fond a formei (culori predefinite, implicit clBtnFace, sau valori returnate de funcția RGB);

Ctl3D precizează dacă forma sau componenta are aspect tridimensional (val. True);

Cursor definește aspectul cursorului de mouse (valoarea implicită este crDefault);

Enabled forma sau o componentă poate fi înhibată (dacă valoarea este False, caz în care va fi afișată cu caractere estompate, valoarea implicită fiind True);

Font definește tipul caracterelor utilizate;

FormStyle stabilește stilul formei (copil, pa rinte);

Height și Width stabilesc dimensiunile formei (inclusiv chenarul) exprimate în pixeli;

Hint definește mesajul care va fi afișat când o componentă este indicată de cursorul de mouse (este activ dacă proprietatea ShowHint= =true);

HorizScrollBar și VertScrollBar – stabilesc dacă forma are sau nu bare de defilare (orizontale respectiv verticale) cu următoarele caracteristici;

Principalele evenimente ale formelor sunt:

OnActivate are loc când o formă devine activă. La această comandă este chemată numele funcției din clasa Tform1. Procedura corespunzătoare fiind:

void __fastcall TForm1::FormActivate(TObject *Sender)

{//lista de instrucțiunni …}

OnClick apare când se efectuează un clic de mouse pe zona liberă a formei. Ca și la funcția anterioară aici are loc chemarea numelui funcției din biblioteca Tform1:

void __fastcall TForm1::FormClick(TObject *Sender)

{//lista de instrucțiunni …}

OnMouseMouve are loc când o se deplasează cursorul de o zonă de lucru indicată. La această comandă este chemată numele funcției din clasa Tform1. Procedura corespunzătoare fiind:

void __fastcall TForm1::MouseMouve(TObject *Sender)

{//lista de instrucțiunni …}

OnMouseUp apare când se efectuează un clic de mouse pe zona liberă a formei. Ca și la funcția anterioară aici are loc chemarea numelui funcției din biblioteca Tform1:

void __fastcall TForm1::MouseUp(TObject *Sender)

{//lista de instrucțiunni …}

OnDblClick – la un dublu clic de mouse pe zona liberă a formei se execută. Ca și la funcția anterioară aici are loc chemarea numelui funcției din biblioteca Tform1:

void __fastcall TForm1::FormDblClick(TObject *Sender)

{//lista de instrucțiunni …}

OnCloseQuery se activează când utilizatorul dorește să închidă forma (cu metoda Close, clic pe butonul de închidere și prin meniul sistem sau comanda Alt+F4). Ca și la funcția anterioară aici are loc chemarea numelui funcției din biblioteca Tform1:

void __fastcall TForm1::FormCloseQuery(TObject *Sender, bool &CanClose)

{//lista de instrucțiunni …}

Dacă se atribuie parametrului CanClose valoarea True, atunci se poate închide forma și se lansează procedura corespunzătoare evenimentului OnClose, iar dacă i se atribuie valoarea False, atunci forma nu poate fi închisă.

OnClose se produce la închiderea formei dupa evenimentul OnCloseQuery:

void __fastcall TForm1::FormClose(TObject *Sender, TCloseAction &Action)

{//lista de instrucțiunni …}

Parametrul Action poate primi una din următoarele valori:

None – nu se va închide forma;

Hide – ascunde fereastra, care poate fi reafișată cu metoda Show;

Free – închide forma;

Minimize – minimizează forma.

OnCreate se produce la prima execuție a formei, când se pot inițializa proprietățile formei și ale componentelor acesteia, prin procedura:

void __fastcall TForm1::FormCreate(TObject *Sender)

{//lista de instrucțiunni…}

Dacă proprietatea Visible = true, atunci se vor declanșa în ordine următoarele evenimente:

OnDeactivate se produce când o fereastra se dezactivează, moment în care se lansează în execuție procedura:

void __fastcall TForm1::FormDeactivate(TObject *Sender)

{//lista de instrucțiunni …}

OnDestroy se realizează când se distruge forma:

void __fastcall TForm1::FormDestroy(TObject *Sender)

{//lista de instrucțiunni …}

OnHide apare în momentul în care forma este ascunsă (Visible= false):

void __fastcall TForm1::FormHide(TObject *Sender)

{//lista de instrucțiunni …}

OnShow apare în momentul în care forma este afișată (Visible= true):

void __fastcall TForm1::FormShow(TObject *Sender)

{//lista de instrucțiunni …}

OnPaint este declanșat când diverse zone ale formei trebuie să fie redesenate:

void __fastcall TForm1::FormPaint(TObject *Sender)

{//lista de instrucțiunni …}

În fine aș putea spune că am prezentat mai detaliat unele corpuri ale funcțiilor, deoarece să fie pe viitor mai ușor de înțeles structura și cum sa elaborat programul.

2.2 Algoritmi implimentați la analiză

La proiectarea limbajelor de programare se stabilesc reguli precise care descriu structura sintactică a programelor. În limbajul C spre exemplu, un program este format din blocuri, un bloc conține instrucțiuni, o instrucțiune are în componența sa expresii, iar o expresie este o înșiruire de o anumită formă de unități lexicale.

Un analizor sintactic primește la intrare un șir de unități lexicale și produce arborele de derivare al acestui șir în gramatica ce descrie structura sintactică. În practică, odată cu verificarea corectitudinii sintactice, se produc și alte acțiuni în timpul analizei sintactice: trecerea în tabela de simboluri a unor informații legate de unitățile sintactice, controlul tipurilor sau producerea codului intermediar și alte chestiuni legate de analiza semantică.

2.2.1. Algoritmul BNF (Backus – Naur Form)

Sintaxa unui limbaj de programare poate fi descrisă cu ajutorul gramaticilor independente de context sau a notației BNF (Backus – Naur Form). De remarcat faptul că BNF este aproape identică cu mecanismul generativ al lui Chomsky – gramatica independentă de context. BNF este un metalimbaj. Acesta folosește abstracțiile pentru a descrie structurile sintactice. O abstracție este scrisă între paranteze unghiulare, ca de exemplu[6]:

<asignare> , <variabilă> , <expresie> , <if_stm> , <while_stm> etc.

Definiția unei abstracții este dată printr-o regulă sau producție care este formată din:

partea stângă a regulii ce conține abstracția care se definește;

o săgeată → (sau caracterele ::= ) care desparte partea stângă a regulii de partea dreaptă;

partea dreaptă a regulii care este un șir format din abstracții, tokenuri, lexeme.

De exemplu, regula: <asignare> → <variabilă> = <expresie> definește sintaxa unei asignări: abstracția <asignare> este o instanță a abstracției <variabilă> urmată de lexemul = urmat de o instanță a abstracției <expresie>. O propoziție care are structura sintactică descrisă de această regulă este:

total = suma1 + suma2

Într-o regulă BNF abstracțiile se numesc simboluri neterminale sau simplu neterminali, lexemii și token-urile se numesc simboluri terminale sau simplu terminali. O descriere BNF sau o gramatică este o colecție de reguli.

Dacă se întâmplă ca un neterminal să aibă mai multe definiții acestea se pot însera într-o singură regulă în care partea dreaptă conține părțile drepte ale definițiilor sale despărțite prin simbolul |. De exemplu, definițiile:

<if_stm> → if<expr_logică> then<stm>

<if_stm> → if<expr_logică> then<stm> else <stm>

se scriu:

<if_stm> → if<expr_logică> then<stm> | if<expr_logică> then<stm> else<stm>

Iată un exemplu de gramatică(BNF) ce descrie un minilimbaj de programare:

<program> → begin<lista_de_instructiuni> end

<lista_de_instructiuni>→ <instructiune> | <lista_de_instructiuni>; <instructiune>

<instructiune> → <variabila> = <expresie>

<variabila> → LITERA

<expresie> → <expresie> + <expresie>

| <expresie> – <expresie>

| <variabila>

| NUMAR

Aici apar două tokenuri: LITERA și NUMAR. Acestea pot la rândul lor să fie descrise prin același mecanism:

LITERA → a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z

NUMAR → <cifra> | NUMAR <cifra>

<cifra> → 0|1|2|3|4|5|6|7|8|9

Se observă că de data aceasta gramatica regulată ceea ce înseamnă că tokenurile se pot descrie folosind expresiile regulate iar recunoașterea lor (analiza lexicală) se poate face cu automate finite deterministe. BNF a fost extinsă în diverse moduri mai ales din rațiuni de implementare a unui generator de analizor sintactic. Orice extensie a BNF este numită EBNF (Extended BNF). Extensiile BNF nu măresc puterea descriptivă a mecanismului ci reprezintă facilități privind citirea sau scrierea unităților sintactice. Extensiile ce apar frecvent sunt:

includerea, în partea dreaptă a unei reguli, a unei părți opționale ce se scrie între paranteze drepte. De exemplu, instrucțiunea if ar putea fi descrisă astfel: <if_stm> → if<expr_logică> then<stm> [else<stm>];

includerea în partea dreaptă a unei reguli a unei părți ce se repetă de zero sau mai multe ori. Această parte se scrie între acolade și poate fi folosită pentru a descrie recursia: <lista_de_instructiuni> → <instructiune> {; <instructiune>};

includerea în partea dreaptă a unei reguli a opțiunii de a alege o variantă dintr-un grup. Acest lucru se face punând variante în paranteze rotunde, despărțite prin simbolul |. De exemplu, o instrucțiune for se poate defini astfel: <for_stm> → for<var> = <expr> (to| downto) <expr> do<stm>.

Trebuie precizat că parantezele de orice fel din descrierea EBNF fac parte din metalimbaj, ele nu sunt terminali ci doar instrumente de a nota o anume convenție. În cazul în care unele din aceste simboluri sunt simboluri terminale în limbajul descris, acestea vor fi puse între apostrof: ‘[‘ sau ‘{‘ etc.

EBNF nu face altceva decât să simplifice într-un anume fel definițiile sintactice. Spre exemplu iată cum se descrie expresia aritmetică folosind cele două mecanisme:

BNF: <expresie> →<expresie> + <termen> | <expresie> – <termen> | <termen>

<termen> →<termen> * <factor> | <termen> / <factor> | <factor>

<factor> →‘(‘ <expresie> ‘)’ | <identificator>

EBNF: <expresie> →<termen> {(+| -) <termen>}

<termen> →<factor> {(* | /) <factor>}

<factor> →‘(’<expresie> ‘)| <identificator>

Un exemplu de program în minilimbajul de programare descris mai sus este următorul:

begin a = b + c; d = 5 – a end

O derivare a acestui program în gramatica dată este:

<program>

⇒begin<lista_de_instructiuni> end

⇒begin<lista_de_instructiuni>; <instructiune> end

⇒begin<instructiune>; <instructiune> end

⇒begin<variabila>=<expresie>; <instructiune> end

⇒begin LITERA=<expresie>; <instructiune> end

⇒begin LITERA=<expresie>+<expresie>; <instructiune> end

⇒begin LITERA=LITERA+<expresie>; <instructiune> end

⇒begin LITERA=LITERA+LITERA; <instructiune> end

⇒begin LITERA=LITERA+LITERA;<variabila>=<expresie>end

⇒begin LITERA=LITERA+LITERA;LITERA=<expresie>end

⇒begin LITERA=LITERA+LITERA;LITERA=<expresie>-<expresie> end

⇒begin LITERA=LITERA+LITERA;LITERA=NUMAR-<expresie> end

⇒begin LITERA=LITERA+LITERA;LITERA=NUMAR-LITERA end

Fig.2.1. Arborele de derivare

Există reguli ale limbajelor de programare care nu pot fi descrise utilizând BNF. De pildă faptul că o variabilă nu poate fi utilizată înainte de a fi declarată este o caracteristică ce nu poate fi descrisă prin BNF. Reguli de acest fel fac parte din semantica statică a limbajului: reguli ce țin indirect de înțelesul unui program relativ la execuție. Semantica statică este denumită așa pentru că poate fi verificată înainte de execuție, la momentul compilării. Un mecanism care descrie semantica statică a fost introdus de Knuth în 1968 și este denumit gramatică cu atribute.

Un arbore de derivare într-o gramatică cu atribute este arborele de derivare din gramatica ce descrie sintaxa împreună cu mulțimea valorilor atributelor atașate fiecărui nod al arborelui. Pentru a evita circularitatea în obținerea valorilor atributelor, deseori se pune restricția ca un atribut moștenit să depindă doar de valorile atributelor părții stângi a regulii și de atributele simbolurilor din stânga sa în șirul din partea dreaptă a regulii.

Această restricție permite proiectarea unui evaluator care parcurge arborele de derivare în preordine. Nodurile din arborele de derivare au atribute sintetizate ale că ror valori se determină în afara arborelui de derivare; acestea se numesc atribute intrinseci.

Spre exemplu, tipul unei instanțe a unei variabile într-un program se obține din tabela simbolurilor care este construită la analiza lexicală și conține numele variabilelor, tipul lor etc.

2.2.2. Sintaxa limbajului C în BNF (Backus – Naur Form)

<translation-unit> ::= {<external-declaration>}*

<external-declaration> ::= <function-definition> | <declaration>

<function-definition> ::= {<declaration-specifier>}* <declarator> {<declaration>}*<compound-statement>

<declaration-specifier> ::= <storage-class-specifier> | <type-specifier> | <type-qualifier>

<storage-class-specifier> ::= auto | register | static | extern | typedef

<type-specifier> ::= void | char | short| int | long| float | double | signed| unsigned

| <struct-or-union-specifier>| <enum-specifier>| <typedef-name>

<struct-or-union-specifier> ::= <struct-or-union> <identifier> { {<struct-declaration>}+ }

| <struct-or-union> { {<struct-declaration>}+ }

| <struct-or-union> <identifier>

<struct-or-union> ::= struct | union

<struct-declaration> ::= {<specifier-qualifier>}* <struct-declarator-list>

<specifier-qualifier> ::= <type-specifier>| <type-qualifier>

<struct-declarator-list> ::= <struct-declarator> | <struct-declarator-list> , <struct-declarator>

<struct-declarator> ::= <declarator>|<declarator>:<constant-expression>|:<constant expression>

<declarator> ::= {<pointer>}? <direct-declarator>

<pointer> ::= * {<type-qualifier>}* {<pointer>}?

<type-qualifier> ::= const|volatile

<direct-declarator> ::= <identifier>

| ( <declarator> )

| <direct-declarator> [ {<constant-expression>}? ]

| <direct-declarator> ( <parameter-type-list> )

| <direct-declarator> ( {<identifier>}* )

<constant-expression> ::= <conditional-expression>

<conditional-expression> ::= <logical-or-expression>

| <logical-or-expression> ? <expression> : <conditional-expression>

<logical-or-expression> ::= <logical-and-expression>

| <logical-or-expression || <logical-and-expression>

<logical-and-expression> ::= <inclusive-or-expression>

| <logical-and-expression && <inclusive-or-expression>

<inclusive-or-expression> ::= <exclusive-or-expression>

| <inclusive-or-expression> | <exclusive-or-expression>

<exclusive-or-expression> ::= <and-expression>

| <exclusive-or-expression> ^ <and-expression>

<and-expression> ::= <equality-expression>

| <and-expression> & <equality-expression>

<equality-expression> ::= <relational-expression>

| <equality-expression> == <relational-expression>

| <equality-expression> != <relational-expression>

<relational-expression> ::= <shift-expression>

| <relational-expression> < <shift-expression>

| <relational-expression> > <shift-expression>

| <relational-expression> <= <shift-expression>

| <relational-expression> >= <shift-expression>

<shift-expression> ::= <additive-expression>

| <shift-expression> << <additive-expression>

| <shift-expression> >> <additive-expression>

<additive-expression> ::= <multiplicative-expression>

| <additive-expression> + <multiplicative-expression>

| <additive-expression> – <multiplicative-expression>

<multiplicative-expression> ::= <cast-expression>

| <multiplicative-expression> * <cast-expression>

| <multiplicative-expression> / <cast-expression>

| <multiplicative-expression> % <cast-expression>

<cast-expression> ::= <unary-expression> | ( <type-name> ) <cast-expression>

<unary-expression> ::= <postfix-expression>

| ++ <unary-expression>

| – <unary-expression>

| <unary-operator> <cast-expression>

| sizeof <unary-expression>

| sizeof <type-name>

<postfix-expression> ::= <primary-expression>

| <postfix-expression> [ <expression> ]

| <postfix-expression> ( {<assignment-expression>}* )

| <postfix-expression> . <identifier>

| <postfix-expression> -> <identifier>

| <postfix-expression> ++

| <postfix-expression> –

<primary-expression> ::= <identifier> | <constant> | <string> | ( <expression> )

<constant> ::= <integer-constant>|<character-constant>|<floating-constant>|<enume-constant>

<expression> ::= <assignment-expression> | <expression> , <assignment-expression>

<assignment-expression> ::= <conditional-expression>

| <unary-expression> <assignment-operator> <assignment-expression>

<assignment-operator> ::= =| *=| /=| %=| += | -= | <<= | >>= | &= | ^= | |=

<unary-operator> ::= & | * | + | – | ~ | !

<type-name> ::= {<specifier-qualifier>}+ {<abstract-declarator>}?

<parameter-type-list> ::= <parameter-list> | <parameter-list> , …

<parameter-list> ::= <parameter-declaration>| <parameter-list> , <parameter-declaration>

<parameter-declaration> ::= {<declaration-specifier>}+ <declarator>

| {<declaration-specifier>}+ <abstract-declarator>

| {<declaration-specifier>}+

<abstract-declarator> ::= <pointer>| <pointer> <direct-abstract-declarator>

| <direct-abstract-declarator>

<enum-specifier> ::= enum <identifier> { <enumerator-list> }| enum { <enumerator-list> }

| enum <identifier>

<enumerator-list> ::= <enumerator> | <enumerator-list> , <enumerator>

<enumerator> ::= <identifier> | <identifier> = <constant-expression>

<typedef-name> ::= <identifier>

<declaration> ::= {<declaration-specifier>}+ {<init-declarator>}*

<init-declarator> ::= <declarator> | <declarator> = <initializer>

<initializer> ::= <assignment-expression> | { <initializer-list> } | { <initializer-list> , }

<initializer-list> ::= <initializer> | <initializer-list> , <initializer>

<compound-statement> ::= { {<declaration>}* {<statement>}* }

<statement> ::= <labeled-statement> | <expression-statement>| <compound-statement>

<labeled-statement> ::= <identifier> : <statement>

| case <constant-expression> : <statement> | default : <statement>

<expression-statement> ::= {<expression>}? ;

<selection-statement> ::= if ( <expression> ) <statement>

| if ( <expression> ) <statement> else <statement>

| switch ( <expression> ) <statement>

<iteration-statement> ::= while ( <expression> ) <statement>

| do <statement> while ( <expression> ) ;

| for ( {<expression>}? ; {<expression>}? ; {<expression>}? ) <statement>

<jump-statement> ::= goto <identifier> ;| continue ; | break ;| return {<expression>}?[5] ;

2.3 Prezentarea funcționalității sistemului în formă de diagrame

Un caz de utilizare este o secvență a tranzacțiilor realizate de sistem ca răspuns la evenimentele declanșate de un actor a sistemului. Un caz de utilizare complet trebuie să ofere o valoare măsurabilă unui actor cînd actorul execută o sarcină anume. Un caz de utilizare conține toate evenimentele care pot surveni în cadrul perechii actor – caz de utilizare, nu neapărat unul ce va apărea în orice scenariu particular. Un caz de utilizare conține un set de scenarii care explică diferitele secvențe ale interacțiunii din interiorul tranzacției.

Cu alte cuvinte s-ar putea spune că diagrama variantelor de utilizare prezintă acțiunile reciproce dintre variantele posibile de utilizare și personale sau sisteme. Diagramele reflectă cerințele către sistem din punct de vedere al utilizatorului . În acest sens variantele de utilizare sînt funcțiile efectuate de sistem iar persoanele sînt persoane cointeresate de sistemul elaborat. Diagrama arată că persoana inițiază varianta diagramei de utilizare. La fel din ea se vede că persoanele cointeresate primesc date de la varianta de utilizare. Din diagrama variantelor de utilizare se poate afla multă informație aflată la sistem. Acest tip de diagrame descrie funcționarea sistemului la general. Utilizatorii, managerii proiectării analitice, specialiști și toți cei cointeresați în sistemul dat pot să înțeleagă sistemul dat.

Fig. 2.2. Diagrama de interacțiunie a utilizatorului cu aplicația

În diagrama din figura 2.2 sunt indicate funcțiile de bază pe care trebuie să le îndeplinească utilizatorul pentru a lucra cu sistemul de analiză sintactică a codului C. După cum se poate de observat este indicat utilizatorul care accesează cazul de utilizare accesează sistem. La această comandă sistemul va rula fereastra de lucru, în care ulterior se va putea de inițiat diverse procese, precum deschiderea unui fisier, analiza codului scris, tipărirea codului, etc.

Fig. 2.3. Funcționalitatea sistemului

În diagrama din figura 2.3, sunt prezentate funcțiile de bază pe care le execută sistemul SIGAAS(sistem informatic de generare automată a analizelor sintactice):

intrare date

aplică algoritm;

crează tabela de valori;

analizează codul;

generare arbore de derivre;

afiseza variabile depistate;

afisează funcții depistate;

afișează erori;

salvare, etc.

În diagrama din figura 2.4 am indicat întreg procesul de lucru a utilizatorului cu sistemul informatic de generare automată a analizelor sintactice(SIGAAS). Prin această diagramă oricine poate să înțeleagă logica de funcționare a sistemului și care sunt etapele prin care trebuie de trecut pentru a obține rezultatul final. Dacă întîmplător se omite o careva etapă indicată în diagramă nu se va obține nici-un rezultat.

Fig. 2.4. Interacțiunia dintre utilizator, sistem și cameră

2.4. Concluzii la capitolul 2

Sistemul informatic are un ciclu propriu de viață, care începe cu decizia de realizare, cuprinde faza de elaborare, faza de utilizare, faza de perfecționare și se încheie cu decizia de abandonare în forma existentă și înlocuirea cu un nou sistem.

Acestui ciclu de viață îi corespund etape specifice stărilor succesive prin care trece sistemul informatic, etape caracterizate prin activități distincte.

Analiza sistemului informațional existent urmărește delimitarea ariei de cuprindere a sistemului și formularea cerințelor și restricțiilor globale de realizare. Pentru a atinge acest scop, în această etapă se face un studiu amănunțit al sistemului existent, se apreciază măsura în care sistemul existent este capabil să răspundă în continuare exigențelor conducerii științifice a agentului economic, se apreciază oportunitatea realizării unui sistem informatic și se formulează principalele restricții și cerințe pentru viitorul sistem informatic.

Proiectarea constă în definirea modelului de ansamblu (conceptual) al sistemului informatic, ținând seama de evaluările făcute în etapa anterioară, dar și în transformarea modelului conceptual stabilit anterior într-un model tehnic, operațional. În acest scop se proiectează ieșirile noului sistem, se determină entitățile bazei informaționale de intrare, se codifică atributele și se proiectează fluxul general de prelucrare a datelor în noul sistem. De asemenea, se definitivează soluția în organizarea datelor (fișiere sau baze de date), se proiectează fișierele sau bazele de date, se determină și se proiectează procedurile (programele de aplicație) pentru crearea, actualizarea și exploatarea structurilor de date în vederea realizării obiectivelor stabilite sistemului informatic.

Proiectarea unui sistem este la fel de importantă ca realizarea proiectului unei clădiri pe care arhitectul dorește să o construiască. La fel și un programator fără această schiță nu se poate construi sistemul. Un model bun trebuie să identifice cerințele și să comunice informații, să se concentreze asupra modului cum interacționează elementele modelului și să nu se împotmolească în detalii, să permită vizualizarea relațiilor dintre componente și să îmbunătățească comunicarea între cei care pragmatici la realizarea proiectului, pe baza limbajului grafic.

La efectuarea analizei și proiectării acestui sistem informatic am plecat de la un studiu de caz concret. Bineînțeles că în urma analizei, studiul de caz poate fi generalizat, iar sistemul informatic poate fi utilizat pentru orice tip de proiect și în cadrul oricărei organizații care aplică gestiunea prin proiecte.

3. REALIZAREA APLICAȚIEI

Documentația aplicației

Folosirea unei multitudini de documente are un rol destul de important pentru oricare pachet software, și un capitol ușor de realizat în ingineria acestui pachet. Toată această documentație facilitînd procesul de lucru și de folosire a datelor într-un anume domeniu. Ca și în oricare alt proces de lucru, în modul cel mai clar al operativității se implimentează ceva anume, în cazul dat „documentația” este acel ceva care odată elaborat tinde să atingă anumite scopuri, pentru a demonstra avantajele pe care le deține și pentru a aduce cu sine noi idei ce pot fi realizate pentru a dezvolta sistemul de lucru din cadru întreprinderilor[10].

Avînd două scopuri de bază cu ajutorul căreia scoate în vizorul fiecărui utiliza tor avantajul său, documentația capătă un loc aparte în baza de date a fiecărei instituții. În primul rând documentația trebuie și încearcă să descrie pachetul software și modul lui de utilizare. Acest proces al documentației fiind cunoscut ca o metodă de utilizare, care este destinată utilizatorului final al sistemului și care implică un caracter mai puțin tehnic.

În era tehnologiei, odată cu punerea în aplicație a tuturor formelor care sporește modul de lucru, documentația de utilizare este un instrument de marketing foarte important. O documentație ce implică forme de utilizare ușor realizabile, împreună cu o interfață bine proiectată, reușesc de a mări accesibilitatea produsului și totodată reușesc să sporescă vânzările acestuia. În linii generale, documentația de utilizare ia forma unui ghid care conține o relatare a celor mai folosite caracteristici și forme de utilizare, oferite de produsul respectiv.

Un alt scop urmărit de documentație este de a descrie sistemul software astfel încât acesta să poată fi întreținut și nu în ultimul rînd înteles pe durata celorlalte perioade de viață.

Documentația de acest tip este cunoscută sub numele de „documentație de sistem” și are în mod inevitabil un caracter mult mai tehnic decât documentația de utilizare. Aici putem menționa faptul că capacitatea de prelucrare a acestei documentații este mai mare și cuprinde o sferă largă de operare a datelor din cadrul instituțiilor. Inițial această documentație era format din programele sursă, în forma finală(un fel de concluzii), la care mai erau adăugate unele explicații schițate după încheierea procesului de dezvoltare. Astăzi documentația sistemului începe cu dezvoltarea specificațiilor inițiale și continuă pe întreaga durată de viață a produsului software. La finele produsului documentația cuprinde date concrete din toate documentele elaborate în faza de dezvoltare a sistemului și va prezenta metodele de funcționare și procedeele care au recurs la acest rezultat[11].

Ghidul utilizatorului

Ghidul utilizatorului este îndrumarul fiecăruia care inițiază să lucreze cu acest program și care tinde spre a dezvolta mediul în care lucrează și cu ajutorul căruia ar dispune de mai mult timp pentru a face alte lucruri, care sunt în folosul său.

După instalarea aplicației ea poate fi lansată printr-un dublu clic asupra pictogramei din figura 3.1.

Fig. 3.1. Pictograma aplicației

La lansarea aplicației se va afișa o fereastră de informare „splash”, ce va fi activă cîteva secunde, care ulterior se va închide și respectiv va fi chemată fereastra de lucru prezentată în figura 3.3.

Fig. 3.2. Fereastra splash

Fig. 3.3. Fereastra de lucru a programului

După cum se poate de observat fereastra de lucru este și ia alcătuită din zone speciale, pe care pe parcursul acestui capitol le voi descrie mai amănunțit. Deci ăncepem cu prima zonă și anume a meniului.

Fig. 3.4. Meniul principal al programului

Meniul principal este alcătuit din trei compartimente, fiecare conținînd la rîndul său o serie de funcții. Primul compartiment „Fișier” conține funcțiile legate de deschiderea fișierilor, salvarea acestora, printarea conținutului, precum și funcția ce răspunde de părasirea sistemului, adică ieșirea. Al doilea compartiment „Operații” conține funcții ce răspund de lucrul cu analizatorul de text(curățirea conținutului și căutarea erorilor). Compartimentul „Ajutor” conține funcțiile ce vor ajuta utilizatorul în lucru.

Fig. 3.5. Submeniul „Operații” și „Ajutor”

O următoare zonă importantă de pe fereastra principală este „Editorul de cod”. Aici utilizatorul va putea scrie codul său, pe care ulterior îl va supune procesului de testare la erori.

Fig. 3.5. Editor de cod

După ce sa scris un cod oarecare, utilizatorul va tasta butonul execută de pe fereastra funcțiilor prezentată în figura 3.6.

Fig. 3.6. Fereastra funcțiilor de bază

La această comandă, codul scris de utilizator va fi supus unui control riguros în ceia ce privește analiza sintactică și ce-a lexicală. Toate erorile depistate vor fi afișate într-o zonă specială prezentată în figura 3.7.

Fig. 3.7. Erorile depistate

O dată ce eroarea a fost depistată, utilizatorul o poate corecta, după care iarăși să inițieze procesul de control al codului. Procesul dat se poate de efectuat tot de atîtea ori pînă cînd nu vor mai fi găsite erori în cod.

Opțional am realizat o funcție ce ne va afișa ce funcții au fost depistate în cod și din ce biblioteci fac parte. Doar cunoaștem că un program c conține o serie de funcții atît predefinite în biblioteci, cît și definite de utilizator.

Fig. 3.8. Funcțiile depistate

O altă funcție opțională este aceia ca să ne arate ce variabile sau depistat, de ce tip sunt acestea și în ce funcție au fost declarate(figura 3.9). Toate astea sunt utile atunci cînd se repetă careva variabile și nu se poate ușor de depistat.

Fig. 3.9. Variabile depistate

Ghidul programatorului

Pentru realizarea acestei aplicații a fost utilizat mediul de dezvoltare Embarcadero RAD Studio XE, care se bazează pe limbajul Delphi și ocupă un loc de vază în crearea aplicațiilor pentru gestionarea bazelor de date, precum și utilizarea pachetelor de componente TMS, Fast Report 4, Raize Component 5 ș.a, care ne dă un aspect sistemului proiectat. Organizarea generală a programului se bazează pe principiul de module. Din acest motiv programul principal este simplu și relativ mic ca volum. El constă din declararea listei de module utilizate și cîțiva operatori care crează obiectele formelor preconizate și inițiază execuția aplicației. Toate obiectele componentelor se află în obiecte-forme. Pentru fiecare formă creată în cadrul aplicației, Builder crează un modul aparte. Anume în cadrul modulelor are loc programarea sarcinilor. În prelucrătoarele de evenimente ale obiectelor-forme se află algoritmii. De regulă ele se reduc la prelucrarea informației, ce se află în proprietățile unor obiecte și atribuirea proprietăților altor obiecte pe baza rezultatelor obținute.

Trebuie de remarcat faptul că sintaxa limbajului (operatorii, tipurile de date), cît și principiile acestuia sunt similare atît limbajului C++, cît și lui Pascal, deoarece se lucrează cu obiecte și clase și respectivele proprietăți ale acestora (moștenire, încapsulare, limitarea accesului, zona vizibilității variabililor, constantelor și funcțiilor etc.). O caracteristică foarte utilă a limbajului Embarcadero RAD Studio XE este prelucrarea excepțiilor.

În timpul lucrului programului pot apărea diverse erori: împărțirea la 0, încercarea de a deschide un fișier inexistent. În astfel de situații programul generează așa-numitele excepții și executarea operațiilor ulterioare în bloc se termină. Excepția este un obiect de tip special, ce caracterizează situația apărută. Particularitatea excepțiilor constă în faptul că ele sunt obiecte temporare. Imediat ce sunt prelucrate, dispar. Reacția standart la majoritatea excepțiilor apărute este afișarea unei informații succinte despre eroare și distrugerea exemplarului dat de excepție. Am ales acest mediu de programare deoarece el dispune de următoarele avantaje:

Performanță – cu cel mai rapid compilator;

RAD – Rapid Application Development, această tehnologie a fost creată datorită progamării vizuale orientat pe obiect;

Reutilizarea componentelor – un adevărat mediu obiect-orientat;

Este simplu și rapid în utilizare etc.

Este clar faptul că Embarcadero RAD Studio XE folosește diverse baze de date. Eu am ales baza de date în SQL Server 2008 ce lucrează pe platforma SQL, deoarece avantajul principal al acestui limbaj s-a dorit să fie simplitatea. Spre deosebire de un adevărat limbaj de programare ce necesită învățarea unor sintaxe stricte și ușor de confundat, SQL are o sintaxa foarte apropiată de limbajul uman natural, ușor de înțeles și de utilizat. O frază în acest limbaj trebuie să fie lizibilă pentru oricine cunoaște cele câteva cuvinte din limba engleză care compun vocabularul SQL: SELECT, FROM, WHERE, ORDER BY etc.

Complexitatea sistemului care implementează algoritmii necesari lucrului efectiv cu datele, metodele de stocare, căutare etc, precum și optimizările sunt perfect transparente pentru utilizator. Acest limbaj nu este considerat un limbaj de programare deoarece a fost conceput pentru a spune calculatorului CE date sunt necesare și nu CUM trebuie obținute. Sunt necesare cunoștințe minime de calculator pentru utilizarea SQL; acesta este de fapt și idealul urmărit de marile firme producatoare de motoare de baze de date: comercializarea unui sistem complex care să permită implementarea oricărei baze de date; datele se pot apoi manipula doar cu ajutorul utilitarelor anexate sistemului, fără a mai fi nevoie de scrierea de aplicații specifice.

Al doilea mare avantaj îl constituie portabilitatea. O aplicație utlizează o bază de date prin intermediul acestor fraze SQL care nu sunt altceva decât simplu text. Orice motor de baze de date acceptă astfel de fraze, făcând posibila migrarea unei aplicații de pe un motor pe altul mai performant fără nici o modificare. Faptul că SQL este un standard unanim recunoscut conferă un mare avantaj aplicațiilor care își pot alege oricând pe ce sistem să ruleze. O baza de date este de fapt un fișier special identificat printr-un nume și extensie. Asupra acestor fișiere în Windows putem aplica operațiile de baza cum ar fi ștergerea , copiere , mutare . Deschiderea salvarea acestor fișiere realizîndu-se analog ca și în cazul celorlalte aplicații Windows. Desigur SQL oferă o securitate la informația introdusă. O facilitate importantă este aceea de a recunoaște baze de date create în diverse aplicații cum ar fi dBase , Paradox , registre Excel ,etc (facilitate numita Import). Astfel putem deschide și prelucra astfel de baze de date și de asemenea putem salva obiecte Access sub aceste formate (operatie numita export de date).

3.2. Setarea bazei de date

Dacă pe viitor apare necesitatea modificării aplicației, sau bazei de date, precum și în cazul lansării proiectului, programatorul trebuie să creeze mai întâi de toate aliasul bazei de date(driver de interconexiunie a aplicației cu baza de date) pentru a putea conecta aplicația la baza de date, în caz contrar sistemul nu va putea găsi baza de date cu care el lucrează și va afișa por și simplu un mesaj de eroare, că nu sa găsit baza de date. Crearea aliasului este posibilă direct în Embarcadero RAD Studio XE, cît și din afara lui (Start -> Control Panel -> BDE Administrator-> ODBC), sau dacă aveți instalat Embarcadero RAD Studio XE ( Start -> Programs -> Embarcadero RAD Studio XE -> BDE Administrator -> ODBC). După ce Embarcadero RAD Studio XE a fost lansat alegeți din meniu Database\Explore și se va lansa fereastra SQL Explor, din meniul căreia alegeți Object -> ODBC Administrator și se va lansa fereastra „ODBC Data Source Administrator” (figura 3.10).

Fig. 3.10. ODBC Data Source Administrator

Pentru a crea un alias nou a bazei de date, apăsați butonul „Add” și va fi lansată o fereastră „Create new Data Source” din care veți alege „SQL Anywhere 16-Oracle (*.db)” , după care veți tasta butonul “Gata”(figura 3.11).

Fig. 3.11. Crearea Data Source

După ce sa tastat butonul “Gata” (figura 3.11), se va afișa fereastra „ODBC Configuration for Adaptive Server Anywhere” (figura 3.12), în care programatorul va trebui să indice numele sursei de date. Acest „Data source name” trebuie indicat așa cum la indicat programatorul la etapa de proiectare a sistemului și nici într-un caz altfel.

Fig. 3.12. ODBC Configuration for SQL SERVER

După ce sa arătat denumirea sursei bazei de date, trebuie de introdus datele despre utilizator și parola de acces, adică datele de acces la baza de date(figura 3.13). În cazul nostru sa indicat User ID:dba și Password:sql.

Figura 3.13 – ODBC Configuration for SQL Server setare parolei

Dacă setările sau făcut și se dorește de văzut dacă este conexiunie, atunci programatorul va trebui sa tasteze butonul „Test Connection” de pe fereastra din figura 3.13 și în caz că tot ce sa introdus e corect se va afișa un mesaj de anunțare (figura 3.14).

Fig. 3.14. Nota de informare a conexiuniei cu succes

3.3. Concluzii la capitolul 3

Odată cu trecerea timpului, sistemul tehnologic se dezvoltă cu pași rapizi. An de an apar noi metode tehnice de operare și conlucrare. În acest sens tot mai multe întreprinderi solicită diferite sisteme repartizate pe domenii, care ar servi un punct de dezvoltare și prosperare. Pentru a servi unor astfel de cerințe e nevoie de cunoștințe, pentru aceasta orice sistem dispune de un compartiment aparte “ghidul utilizatorului”, ce vine în ajutor fiecărui client ce dorește să opereze cu acest sistem.

Ghidul utilizatorului reprezintă o totalitate organizatoric-aranjată de resurse informaționale. Acesta la rîndul său are menirea de a îndruma utilizatorul despre funcționalitatea sistemului, eficacitatea și eficinență a funcționării, fiabilitatea informației în cadrul instituției. Compartimentul dat vine în întîmpinarea fiecărui necunoscător de noi tehnnologii, aducînd cu sine momente importante de studiu în procesul de lucru (arată modul de funcționare, generarea informației, accesare rapidă, căutare rapidă).

Pentru marele întreprinderi un astfel de ghid este binevenit din momentul procurării unui nou sistem, deoaarece acest ghid are în vizorul său cea mai importantă latură – economia. Acesta permite de a economisi din punct de vedere al familiarizării cu noul sistem implimentat în cadrul instituției, în acest sens instituția nu mai are nevoie de a organiza training-uri, de a trimite angajații la diferite cursuri ce țin de instruirea acestora la utilizarea sistemului. Cu ajutorul ghidului utilizatorului orice client mai poate să revină la pasul care nu a fost înțeles pe parcursul studierii sistemului.

Acest ghid este parte a Proiectului de documentație și se dorește a fi punctul de plecare în studierea celorlalte materiale pe care le puteți găsi în cadrul acestui proiect. Ca atare, vă oferă cunoștințele de bază necesare oricărei persoane care dorește să înceapă să lucreze cu un sistem. De aceea, așteptați-vă ca acest ghid să nu fie complet, ci plin de legături către surse adiționale de informații despre sistemul dumneavoastră și către documentația specifică sistemului dumneavoastră. Faptul ca ghidul utilizatorului permite instruirea utilizatorilor este ceva important, dar mai există anumite nuanțe de care trebuie să se țină cont. Odată cu procurarea unui sistem trebuie luat în calcul și de ghidul programatorului, persoana care răspunde de instalarea sistemului, codul acestuia și multe alte nuanțe de care utilizatorul de rînd nu are acces. Programatorul este persoana care ține sub control funcționalitatea sistemului și partea instructivă, astfel acesta la rîndul său acre nevoie de accesarea tuturor nuanțelor ascunse de program. Pentru aceasta ghidul programatorului vine în întîmpinare lui.

CONCLUZII

Produsul program prezentat în lucrarea dată de licență a fost elaborat, pentru generarea automată a analizei sintactice a unui text. Pentru a îngusta domeniul destul de vast a temei, am ales să generez analiza sintactică a unui cod de program scris în limbajul de programare C.

Pentru realizarea unui sistem cu succes, am ținut cont de ciclul de viață a produselor software și anume am început cu analiza, în care am studiat domeniul proiectării compilatoarelor, deoarece analiza sintactică în strânsă legărură cu ce-a semantică și lexicală este o parte foarte importantă din construcția unui compilator.

Următorul pas al ciclului de viață prin care a trecut sistemul este proiectarea acestuia în care s-a creat scenariile de lucru, și a permis minimizarea cheltuielilor legate de introducerea schimbărilor în cod, ceea ce simplifică considerabil realizarea programului.

În final am trecut la etapa de implimentare și testare ce reprezintă etapa de realizare a unei aplicații sau execuția unui plan, unei idei, unui model, etc. Tot aici sa realizat ghidul utilizatorului și cel a programatorului, deoarece numai așa se poate de obținut un produs de calitate superioară.

Calitatea unui produs software este dată de modul în care acesta este implementat și are implicații puternice în care ulterior, un alt programator poate înțelege testa și modifica codul inițial. Pentru ca un produs să fie considerat de calitate sunt necesare respectarea anumitor reguli de implementare.

Pentru realizarea produsului program, a fost utilizat limbajul de programare orientat pe obiect Embarcadero RAD Studio XE6 și trei pachte ajutătoare de biblioteci în prelucrarea textului. Am ales acest limbaj de programare, deoarece el dispune de o serie de avantaje: performanță cu cel mai rapid compilator; Rapid Application Development, această tehnologie a fost creată datorită progamării vizuale orientat pe obiect; reutilizarea componentelor; conține componenete specializate în programarea bazelor de date; este simplu și rapid în utilizare, având sintaxa asemănătoare lui C și Pascal este foarte accesibil chiar și începătorilor.

Concluzie cea mai importantă, legată de realizarea sistemului este că fără utilizarea limbajelor de modelare, realizarea putea tinde cu mult mai mult, deoarece Unifed Modeling Language a permis să înțelegem mai bine necesitățile impuse, ordinea de executare a operațiilor și a determina componentele programului. Adică a adus la micșorarea sinecostului proiectului și minimizării timpului necesar pentru realizare și susținere.