UNIVERSITATEA DIN CRAIOVA FACULTATEA DE ŞTIINŢE EXACTE SPECIALIZAREA INFORMATICĂ
LUCRARE DE LICENŢĂ
Coordonator ştiinţific:
Absolvent:
Lect.univ.dr. Dorel Săvulea
Văduva Liliana-Georgiana
-IULIE 2012-
UNIVERSITATEA DIN CRAIOVA
FACULTATEA DE Ş TIINŢE EXACTE SPECIALIZAREA INFORMATICĂ
Proiectarea sistemelor informatice utilizând
tehnologia orientată pe obiecte
Coordonator ştiinţific:
Absolvent:
Lect.univ.dr. Dorel Săvulea
Liliana-Georgiana Văduva Liliana-Georgiana
-IULIE 2012-
2Page
Cuprins
Introducere .......................................................................................... 5 Capitolul I. Concepte generale ............................................................. 9
1.1 Baze de date – date – Notiuni introductive ............................................. .............................. ............... 9 1.1.1 Sisteme de gestiune a bazelor de date .................................. ................... ............... 9 1.1.2 Limbajul SQL ....................................................................... 10 1.1.3 Limbajul SQL PLUS .............................................................. 11 1.1.4 Modelul obiectual-relational .............................................. 12 1.2 Introducere in .Net Framework ......................... ... ............................................ ........................... ..... 17 1.2.1 Microsoft Intermediate Language(MSIL sau IL) .................. 17 1.2.2 Common Language Specification(CLS).................... Specification(CLS)................................. ............. 18 1.2.3 Common Type System(CTS) .............................................. ......................... ....................... .. 18 1.2.4 Common Language Runtime(CLR) ....................................... ................... .................... 20 1.2.5 Trasaturi ale platformei .NET .............................................. 24 Capitolul II Proiectarea Orientata spre Obiect.....................................26
1. Introducere si obiective.................... obiective......................................... ...............................................26 ..........................26 1.1 Determinarea subsistemelor................................ subsistemelor.....................................................26 .....................26 1.2 Legatura subsistemelor cu unitati functionale..........................27 functionale..........................27 1.3 Alegerea si gestiunea depozitelor de date................................28 1.4 Determinarea arhitecturii sistemului........................................28 sistemului........................................28 2. Proiectarea Orientata Orientata spre obiect…………………………………………… obiect………………………………………………….29 …….29 2.1 Obiecte si clase de obiecte……………………………………………………..31 obiecte……………………………………………………..31 2.2 2.2 Mesajul…………………………………………………………………………………..32 3Page
2.3 Mostenirea……………………………………………………………………………..32 2.4 Polimorfismul………………………………………………………………………….33 2.5 Abstractizarea………………………………………………………………………...33 2.6 Incapsularea……………………………………………………………………………34 2.7 Reutilizarea………………………………………………………………………… ....35 2.8 Persistenta……………………………………………………………………………… 36 3. Metodologii de realizare a sistemelor informatice cu abordare orientata obiect…………………………………………………………………………………… 37 3.1 Object modeling technique…………………………………………………….38 3.2 Object lifecycles……………………………………………………………………..40 3.3 Object – oriented analysis and design…………………………………….42 3.4 Object – oriented system development………………………………….44 Capitolul III. Descrierea si folosirea aplicatiei ......................................46 Capitolul IV. Concluzii .........................................................................60 Capitolul V. Referinte .......................................................................... 62
5.1 Referinte WEB............................................................................... 62 5.2 Referinte literare........................................................................... 62
4Page
Introducere
Intr-o era a informatiei, abilitatea de a reactiona rapid si eficient la diferitele necesitati este cel mai important factor in orice domeniu de activitate al societatii. In acest caz, volumul si complexitatea informatiilor care se vehiculeaza pot fi covarsitoare, iar eficienta folosirii informatiilor depinde in cea mai mare masura de capacitatea de organizare a unui volum mare de date intr-un timp cat mai scurt. In prezent societatea moderna informatizata (pe plan global) reprezinta deja o realitate comuna, in care se ignora frontierele si se trece peste orice problema de ordin spatial sau temporal. Societatea, politica, economia, etc. se bazeaza azi, din ce in ce mai mult, pe aceasta infrastructura informatica. De asemenea, guvernele, firmele din sectoarul public si privat, organismele financiare nationale si internationale, invatamantul, cultura si cercetarea stiintifica, beneficiaza toate de aceste forme avansate, implementate si bine structurate de conducere, informare si comunicare. Lumea de azi este marcata de o noua dimensiune, trasata in plan global, data circulatiei si valorificarii informatiei, indiferent de zona geografica din care aceasta provine. Puterea de manipulare in timp rapid si cat mai eficace a informatiei a devenit azi unul din criteriile de evaluare a gradului de dezvoltare a unei societati. O baza de date este un instrument pentru colectarea
si
organizarea
informat iilor[14]. Bazele de date pot stoca informa t ii despre persoane, produse, comenzi sau orice altceva. Multe baze de date incep sub forma de liste intr-un editor de text sau intr-o foaie de calcul. Pe masura ce lista creste, incep sa apara redundant e si inconsistent e in datele prezente. Datele devin greu de int eles in forma de lista, iar posibilitat ile de a cauta si a extrage subseturi de date pentru revizuire sunt limitate. Odata ce incep sa apara aceste probleme, este o idee buna sa se transfere datele intr-o baza de date creata de un sistem de gestionare al bazelor de date (DBMS), cum ar fi Oracle9i[14]. O baza de date computerizata este un container de obiecte. O baza de date poate cont ine mai mult de un tabel. De exemplu, un sistem de gestionare a angajatilor
5Page
unei institutii care utilizeaza trei tabele nu reprezinta trei baze de date, ci o baza de date care cont ine trei tabele. O baza de date proiectata corespunzator furnizeaza acces la informat ii precise, actualizate. Deoarece o proiectare corecta este esent iala pentru atingerea scopurilor utilizarii unei baze de date, investi t ia in timpul necesar invat arii principiilor unei bune proiectari este esent iala. Anumite principii ghideaza procesul de proiectare al unei baze de date. Primul principiu este acela ca informat iile dublura (numite si date redundante) au o influen t a negativa, deoarece consuma spat iu si sporesc probabilitatea producerii de erori si inconsistent e. Al doilea principiu il reprezinta importan t a corectitudinii si caracterului complet al informat iilor. Daca baza de date cont ine informat ii incorecte, orice rapoarte care extrag informat ii din baza de date vor con t ine, de asemenea, informat ii incorecte. Drept urmare, orice decizie luata bazandu-va pe aceste rapoarte va fi gre sit informata. O proiectare buna a unei baze de date este, dupa cum urmeaza, una care:
Imparte informat iile in tabele pe baza subiectelor, pentru a reduce datele redundante.
Furnizeaza programului Access informat iile necesare pentru a asocia informat iile din tabele dupa necesitat i.
Asista si asigura acuratet ea si integritatea informat iilor.
Adapteaza necesitat ile de procesare a datelor si cele de raportare.
Lucrarea de fata a fost elaborata din nevoia de a facilita fluxul lucrarilor din interiorul unor institutii, in speta a celor din categoria muzeelor nationale, si pentru o mai buna monitorizare a modului de gestionare a datelor si informatiilor specific birotice. Stocarea datelor si informatiilor dintr-un sistem informatic este una dintre problemele fundamentale ale informaticii, iar in ceea ce priveste stocarea informatiei pe termen lung este unul din obiectele de interes ale activitatii de gestiune si arhivistica. Bazele de date isi propun sa serveasca cat mai rapid aplicatiile care au nevoie de acele date. O baza de date isi propune: - sa centralizeze toate datele ce sunt necesare unei firme; - sa fie capabile sa serveasca cat mai rapid cu informatii toate acele aplicatii. 6Page
O baza de date este formata din mai multe tabele relationate. Datele dintr-o baza de date sunt folosite de diferite aplicatii. Aceste aplicatii pot fi: - site-uri; - soft-uri de contabilitate; - etc. Pentru a putea tine o evidenta exacta a tuturor lucrarilor din institutie s-a implemetat un produs software cu ajutorul caruia sa se poata controla fluxul datelor. Acest sistem informatic va cuprinde doua fluxuri de date: 1.
unul care va fi format din categoria documentatelor intrate in institutie;
2.
si celalalt care va cuprinde toate cererile provenite din exterior si cele interne. Produsul software este destinat pentru a facilita si inlesni activitatea
administratorilor unor muzee nationale. De asemenea, pe parcursul derularii prezentului proiect se va incerca obtinerea unui produs software care sa corespunda la un nivel cat mai inalt nevoilor si cerintelor administratorilor. Se va urmarii realizarea unui program birotic ce va oferii o functionalitate sporita. Planul de proiect ofera o lista completa a scopurilor si obiectivelor lucrarii care pot fi rezumate dupa cum urmeaza:
sa se identifice principalele sarcini de lucru ale administratorilor acestor institutii si sa se implementeze corect in proiectarea produsului software
sa se obtina o versiune perfect functionala a unui produs software care sa faciliteze lucrul cu cele doua fluxuri de documente, specifice acestor institutiilor
produsul software sa ofere garantia unui grad ridicat de confidentialitate a datelor Produsul software va fi implementat utilizand doua tehnologii informatice:
-
tehnologia Oracle
- platforma .Net Framework Operatiile de stocare si manipulare a fluxurilor de date din interiorul institutiilor se vor implementa utilizand versiunea 9i a serverului de baze de date Oracle. De asemenea, pentru a se obtine o interfata simpla, prietenoasa si usor de
7Page
utilizat, view-ul aplicatiei va fi realizat utilizand platforma .Net Framework. Se va folosi modul de programare orientat obiect pus la dispozitie de ambele tehnologii. Prezenta este structurata dupa cum urmeaza : -
capitolul de fata cuprinde o expunere succinta a scopurilor si obiectivelor proiectului
-
capitolul I descrie principalele concepte ale celor doua tehnologii utilizate
-
capitolul II prezinta proiectarea orientata obiect
-
capitolul III expune functionalitatea de baza a pr odusului software
-
capitolul IV prezinta concluziile formulate in urma definitivarii proiectului
-
ultimul capitol cuprinde lista itemilor bibliografici
8Page
Capitolul I. Concepte generale
1. Baze de date – Notiuni introductive In aceasta sectiune se descrie o prezentare generala a conceptelor bazelor de date relationale. O baza de date este o colectie de informatii interrelationate gestionate ca o singura unitate. Aceasta definitie este foarte larga, deoarece exista mari diferente intre conceptiile diferitilor producatori care pun la dispozitie sisteme de baze de date. De exemplu, Oracle Corporation defineste o baza de date ca fiind o colectie de fisiere fizice gestionate de o singura instanta (copie) a produsului software pentru baze de date[14],in timp ce Microsoft defineste o baza de date SQL Server ca fiind o colectie de date si alte obiecte. Un obiect al bazei de date este o structura de date denumita, stocata in baza de date, cum ar fi un tabel, o vizualizare sau un index. Exista mari diferente intre implementarile furnizorilor de baze de date. In majoritatea sistemelor de baze de date, datele sunt stocate in mai multe fisiere fizice, dar in Microsoft Access toate obiectele bazei de date, impreuna cu datele care apartin unei baze de date sunt stocate intr-un singur fisier fizic.(Un fisier este o colectie de inregistrari inrudite stocate ca o singura untiate de sistemul de operare al calculatorului.) Totusi, unul dintre principalele avantaje ale bazelor de date relationale este faptul ca detaliile de implementare fizica sunt separate de definitiile logice ale obiectelor bazei de date, astfel incat majoritatea utilizatorilor bazei de date nu au nevoie sa stie unde (si cum) sunt stocate obiectele bazei de date in sistemul de fisiere al calculatorului[6].
1.1 Sisteme de gestiune a bazelor de date
Aparitia si dezvoltarea calculatoarelor electronice au condus la amplificarea activitatilor legate de stocarea, interogarea si administrarea colectiilor de date. Astazi,
9Page
cele mai multe dintre activitatile noastre zilnice necesita accesarea si actualizarea informatiei dintr-o baza de date: extragerea unei sume de bani din contul bancar, rezervarea unei camere de hotel, cumpararea unui bilet de avion, imprumutarea unei carti de la biblioteca, platirea facturilor de telefon, curent electric etc. Toate acestea se pot face rapid si in siguranta pentru ca datele respective sunt bine organizate intr-o baza de date si administrate de un sistem de gestiune a bazelor de date. Baza de date (BD) = o colectie de date aflate in relatie unele cu altele si structurata astfel incat sa poata servi unui anumit scop = un set de date corelate si organizate in scopul prelucrarii lor rapide si concomitente de catre mai multe persoane[9]. Exemple : 1) baza de date a unui muzeu, in care sunt inregist rate operele de arta (grupate dupa tip, autor, tehnica de lucru) si expozitiile itinerante (descrise prin perioada, itinerariu, responsabil, custozi participanti); 2) baza de date a unui magazin de muzica, in ca re sunt inregistrate albumele de muzica in functie tipul de suport fizic (CD, caseta etc.), stil, autori, solisti, anul aparitiei etc. Un sistem de gestiune a bazelor de date (SGBD) prin definitie este un ansamblu de programe care permit crearea si administrarea unei baze de date. Prin urmare, un SGBD (Database Management System) este un pachet software de nivel inalt care permite proiectarea, construirea si administrarea bazelor de date dedicate rezolvarii problemelor din cele mai variate domenii ale vietii reale.
1.2 Limbajul SQL
Procedural Language/Structured Query Language (PL/SQL) este extensia procedurala a limbajului SQL. PL/SQL este un limbaj de programare sofisticat care asigura accesarea datelor unei baze de date relationale orientate obiect si permite gruparea unei multimi de comenzi intr-un bloc unic de tratare a datelor[9]. Programul este format din unul sau mai multe blocuri care pot contine blocuri incuibarite. PL/SQL include atat instructiuni SQL pentru manipularea datelor si pentru gestiunea tranzactiilor, cat si instructiuni proprii[5]. Limbajul combina constructiile procedurale ale unui limbaj
10 P a g e
LG3 cu puterea si flexibilitatea lui SQL (LG4). Combinatia a generat un limbaj puternic pentru modelarea aplicatiilor complexe. PL/SQL extinde SQL prin constructii specifice limbajelor (definirea variabilelor, declararea tipurilor, utilizarea structurilor implementarea procedurilor si functiilor, introducerea tipurilor obiect etc.). PL/SQL ofera posibilitati moderne de tratare a informatiei: incapsularea datelor, analiza speciala a erorilor, mascarea informatiei, orientarea obiect. Posibilitatile lui SQL sunt folosite pentru un acces rafinat la date, iar facilitatile oferite de PL/SQL sunt folosite pentru fluxul controlului procesarii datelor. Dintre functionalitatile limbajului PL/SQL care determina ca acesta sa fie frecvent utilizat se remarca urmatoarele facilitati:
Integrarea comenzilor SQL de baza ;
Integrarea cu server-ul Oracle si cu utilitare Oracle;
Oferirea unui suport pentru programarea orientata obiect;
Asigurarea securitatii informatiei;
Definirea si gestiunea blocurilor de instructiuni;
Gestiunea variabilelor, constantelor si a cursoarelor;
Modularizarea programelor (subprograme, pachete);
Implementarea si utilizarea declansatorilor;
Utilizarea structurilor de control fundamentale;
Detectarea si gestiunea erorilor de executie si a situatiilor exceptionale;
1.3Limbajul SQL PLUS
SQL (Structured Query Language) este un limbaj neprocedural pentru interogarea si prelucrarea informatiilor din baza de date[9]. De asemenea, SQL este un limbaj declarativ, asfel incat este suficient ca utilizatorul doar sa descrie ceea ce trebuie obtinut, fara a indica modul in care se ajunge la rezultat. Compilatorul limbajului SQL genereaza automat o procedura care acceseaza baza de date si executa comanda dorita. SQL permite atat definirea, prelucrarea si interogarea datelor, cat si controlul accesului la acestea. Comenzile SQL pot fi integrate in programe scrise in alte
11 P a g e
limbaje, de exemplu Cobol, C, C++, Java etc. Principalele aspecte prin care SQL difera de limbajele de programare traditionale sunt urmatoarele:
Asigura accesarea automata a datelor;
Opereaza asupra unor multimi de date, si nu asupra elementelor individuale;
Permite programarea la nivel logic, necesitatea de a considera detaliile implementarii fiind redusa;
Oracle SQL include extensii ale limbajului SQL standard ANSI/ISO, iar instrumentele si aplicatiile Oracle furnizeaza instructiuni suplimentare. Utilitarele SQL*Plus si Oracle Enterprise Manager permit atat executarea instructiunilor limbajului SQL standard asupra unei baze de date Oracle, cat si a instructiunilor sau functiilor suplimentare disponibile. Desi unele utilitare si aplicatii Oracle simplifica sau mascheaza utilizarea SQL, toate operatiile asupra bazei de date sunt realizate folosind acest limbaj. Caracteristicile limbajului SQL pot fi sintetizate astfel[14]:
Este abordabil de diferite categorii de utilizatori, inclusiv de aceia care au putina experienta in programare;
Este un limbaj neprocedural, de comunicare cu server-ul Oracle;
Reduce timpul necesar crearii si intretinerii aplicatiilor de baze de date ;
1.4 Modelul obiectual-relational
Necesitatea gestionarii obiectelor complexe (precum texte foarte lungi, grafice, harti, imagini, sunete, etc.) a condus la introducerea conceptului de obiect in cadrul schemelor relationale. In prezent tehnologia bazelor de date orientate obiect este inca la inceput, neexistand un model general de SGBD orientat obiect. S-a impus insa un model relational care suporta majoritatea principiilor modelarii orientate pe obiect. Incepand cu versiunea Oracle 8 putem vorbi de SGBD-uri relational-obiectuale ce faciliteaza integrarea tehnologiei orientate pe obiect in modelul relational[7]. Un obiect este un model informational al unei entitati reale, care poseda o multime de proprietati si care are in acelasi timp un anumit comportament. Avand in vedere proprietatile comune si comportamentul similar al entitatilor pe care le modeleaza, obiectele pot fi impartite in multimi. Daca in limbajele de programare orientate obiect avem notiunea de clasa pentru a desemna o multime de obiecte de acelasi fel, in 12 P a g e
sistemul Oracle se poate defini un tip obiect , obiectele individuale similare constituind manifestari/realizari/instantieri ale acestuia[8]. Proprietatile obiectelor se pot defini cu ajutorul atributelor din definitia tipului obiect, iar comportamentul acestora va fi stabilit prin metodele precizate. Tipul obiect poate fi folosit in modelul relational pentru a defini tabele obiect sau campuri intr-un tabel relational. Oracle permite abordarea tabelelor obiect in doua maniere :
ca si tabele cu o singura coloana, in care fiecare linie este un obiect de tipul obiect ce a stat la baza definirii acestora ;
ca si tabele cu mai multe coloane, in care acestea corespund atributelor din definitia tipului obiect considerat.
Oracle ofera in prezent suport deplin pentru tehnologia orientata- obiect sub forma
unui nivel de abstractizare construit deasupra modelului relational. Tipuri
abstracte noi (numite si tipuri definite de utilizator) pot fi construite fie pornind de la tipurile de date scalare standard, fie pe baza unor alte tipuri abstracte, referinte la alte
obiecte
sau
tipuri colectii. Metadatele referitoare la tipurile abstracte sunt
stocate in schema bazei de date fiind astfel disponibile in SQL, PL/SQL , Java, C# sau alte limbaje. In spatele acestui model obiectual datele sunt in continuare stocate sub forma de tabele si atribute, dar pot fi tratate si ca entitati complexe (obiecte) din lu- mea reala. Utilizarea tipurilor abstracte pentru modelarea datelor poate oferi urmatoarele avantaje majore: Pot fi incapsulate operatii alaturi de date. Daca tabelele pot stoca doar date, tipurile abstracte ofera posibilitatea definirii unor functii (denumite metode) ce pot fi aplicate asupra datelor obiectelor. De exemplu pentru o factura, privita ca obiect ce cuprinde toate datele unui document real, se poate defini o metoda care sa calculeze suma totala si TVA- ul pentru produsele componente. Obiectele ofera eficienta sporita in dezvoltarea aplicatiilor datorita faptului ca sunt stocate in baza de date, includ operatiile ce se pot efectua asupra lor si pot fi accesate de orice alt modul-program. Ca urmare, programatorii nu sunt nevoiti sa recreeze structuri de mapare a datelor in fiecare aplicatie- client. Obiectele ofera o perspectiva de ―intreg‖ asupra datelor (partile componente), in mod similar modului de abordare a lucrurilor din perspectiva umana. Ca urmare sunt mai usor de reprezentat si de manipulat.
13 P a g e
Tipuri abstracte de date. Atribute si metode: in Oracle, pentru a defini un nou tip utilizam instructiunea CREATE TYPE astfel[14]: CREATE TYPE numeTip AS OBJECT(
,…, , [ MEMBER FUNCTION Metoda1 [(p1 tip,…)] RETURN Tip], [MEMBER PROCEDURE Metoda2[(p1 tip, …)]) Pentru definirea tipului fiecarui membru-atribut putem apela fie la tipurile predefinite (Number, Varchar2, Integer, etc…) fie la alte tipuri abstracte definite anterior. Definirea comportamentului obiectelor (operatiile pe care le pot realiza acestea asupra datelor proprii) se realizeaza prin implementarea functiilor membru specificate la crearea tipului, astfel[14]: CREATE TYPE BODY numeTip AS MEMBER FUNCTION Metoda1 IS … … BEGIN … Corpul metodei… END Metoda1; … END; Un obiect nou de un anumit tip se obtine cu ajutorul constructorului implicit (o metoda cu acelasi nume ca si al tipului si parametri pentru toate atributele declarate): NEW DenumireTip(val1, val2, .. valn) , unde vali (i=1,n) reprezinta o valoare pentru fiecare atribut al tipului. Un aspect deosebit de important in ceea ce priveste manipularea obiectelor intrun limbaj de programare se refera la modul de transfer al acestora (intre variabile sau intre un modul-program si altul). In acest sens este important de retinut faptul ca in Oracle obiectele se transmit in mod implicit prin valoare si nu prin referinta (asa cum se intampla de exemplu in C#). Astfel, fiind date doua obiecte, obj1 si obj2, adresate prin doua variabile, v1 respectiv v2, in urma atribuirii v1:=v2 nu vom obtine doua referinte spre un acelasi obiect (obj2) ci vom dispune de doua variabile ce puncteaza spre doua obiecte complet distincte dar cu un continut identic.
Stocarea si gestionarea obiectelor in baza de date: Oracle furnizeaza doua tehnologii de stocare a obiectelor in baza de date:
tehnologii ce au obiecte linie – sunt stocate sub forma de linii ale unei tabele construita pe baza tipului caruia ii apartin respectivele obiecte; atributele
14 P a g e
unei asemenea tabele vor fi tocmai atributele tipului iar un obiect va constitui o inregistrare;
obiecte coloana – persistenta se asigura sub forma de valori ale unui atribut declarat intr-o tabela relationala clasica; pentru fieca- re
inregistrare,
respectivul atribut va contine un obiect de tipul declarat.
Referinte spre obiecte: Asa cum precizam si ceva mai devreme, in orice aplicatie orientata- obiect exista diverse situatii in care avem nevoie de o adresa logica (asa numita ―pointer‖) spre un obiect existent, adresa prin intermediul careia sa gestionam exact obiectul respectiv si nu o copie a acestuia. Mai mult, daca privim lucrurile din perspectiva arhitecturii bazei de date, pentru tabelele copil avem nevoie de referinte spre obiectele din tabe lele parinte. In sprijinul acestor necesitati Oracle furnizeaza tipul de data REF ce defineste un pointer spre un obiect-linie existent, prin intermediul caruia putem modela relatii intre obiecte (in special relatii de tip ―one - to- many‖) si care poate fi utilizat in diverse scopuri: pentru a examina si actualiza datele obiectului sursa; pentru a obtine o copie a obiectului sursa; pentru a schimba obie ctul sursa spre care tine pointer- ul. Exista cateva aspecte esentiale in ceea ce priveste tipurile REF[6]:
referinta reprezinta adresa, identificatorul generat de sistem la
unic (OID-Object IDentifier)
crearea obiectului (acest identificator este
atribut
automat la momentul initializarii obiectului si este unic in baza de date);
prin intermediul referintelor manipulam obiectele in mod clasic orientatobiect, folosind notatia cu punct;
nu pot fi utilizate la definirea cheii primare;
un REF poate defini un pointer numai spre un obiect stocat intr-o tabela de obie cte si nu spre
obiecte rezidente pe campurile unei tabele relationale
clasice sau in memorie. Tipul obiectului trebuie sa fie obligatoriu cel declarat la definirea tipului REF, sau un tip derivat al acestuia. Extinderea
tipurilor.
Mostenire
si
polimorfism:
Un concept esential al
metodologiei orientate-obiect este reprezentat de mostenire , ca fiind procesul de specializare a tipurilor prin crearea unor subtipuri derivate din cel de baza, numit supertip. Subtipurile mostenesc toti membrii supertipului (date si metode) si adauga
15 P a g e
un element nou pentru a evidentia o anumita particularitate a obiectelor (entitatile din lumea reala). Elementul de noutate se poate concretiza in:
atribute si/sau metode noi;
modificarea comportamentului ( o alta implementare a metodelor mostenite).
Ansamblul alcatuit din tipul de baza (cel mai abstract) si toate subtipurile sale specializate este numit ierarhie . Specializarea subtipului poate insemna: adaugarea unor noi membri (atribute, metode) sau modificarea comportamentului uneia din metodele mostenite
(proces numit
suprascriere).
Suprascrierea
metodelor face
posibila manifestarea polimorfismului (doua obiecte de acelasi supertip, dar de subtipuri diferite se comporta diferit la executia metodei suprascrise). Incepand cu versiunea 9i, Oracle ofera suport deplin pentru toate conceptele descrise anterior. Astfel, definirea unui subtip derivat dintr -un supertip poate fi realizata numai daca acesta din urma a fost declarat NOT FINAL. De cele mai multe ori o aplicatie nu ―lucreaza‖ cu obiecte
instantiate din supertip ci cu obiecte
specializate. Supertipurile se utilizeaza pentru a trata la un moment dat toate obiectele din tipurile derivate in mod unitar. Avand in vedere aspectele discutate anterior, paradigma orientata - obiect ofera posibilitatea crearii unor tipuri ce nu pot fi instantiate (nu putem obtine obiecte de tipul respectiv) si a unor metode fara implementare ce vor trebui obligatoriu suprascrise de tipurile derivate.
16 P a g e
2. Introducere in .Net Framework Platforma .NET este un cadru (framework) de dezvoltare software cu ajutorul caruia se pot realiza, distribui si rula aplicatii desktop Windows si aplicatii WEB. .NET este o tehnologie care inglobeaza laolalta mai multe tehnologii (ASP, XML, OOP, SOAP, etc) si limbaje de programare (VB, C++, C#, J#) asigurand atat portabilitatea codului compilat intre diferite calculatoare cu un sistem de operare Windows, cat si reutilizarea codului in programe, indiferent de limbajul de programare utilizat[11]. In general, .NET Framework este o componenta livrata impreuna cu sistemul de operare Windows. Pentru a dezvolta aplicatii pe platforma .NET este bine sa avem 3 componente esentiale: -
un set de limbaje (C#, Visual Basic .NET, J#, Managed C++, Smalltalk, Perl, Fortran, Cobol, Lisp, Pascal, etc)
-
un set de medii de dezvoltare (Visual Studio .NET, Visio)
-
o biblioteca de clase pentru crearea serviciilor Web, aplicatiilor Web si aplicatiilor desktop Windows
Ca un element de portabilitate, trebuie spus ca .NET Framework este implementarea unui standard numit Common Language Infrastructure[10] ceea ce permite rularea aplicatiilor .NET nu numai pe sistemul de operare Windows, ci si pe unele tipuri de Unix, Linux, Solaris, Mac OS X si alte sisteme de operare.
2.1 Microsoft Intermediate Language(MSIL sau IL) In cazul limbajelor de programare, s-a ajuns treptat la crearea unor nivele de abstractizare a codului rezultat la compilare, precum p-code (cel produs de compilatorul Pascal-P) si bytecode (binecunoscut din limbajul Java). Bytecode-ul Java, generat prin compilarea unui fisier sursa, este cod scris intr-un limbaj intermediar care suporta tipul de programare orientata obiect. Bytecod-ul este in acelasi timp o abstractizare care permite executarea codului Java, indiferent de platforma tinta, atata timp cat aceasta platforma are implementata o masina virtuala Java, capabila sa transforme mai departe fisierul .class in cod nativ. 17 P a g e
Microsoft a realizat si el propria sa abstractizare de limbaj, aceasta numindu-se Microsoft Intermediate Language. Desi exista mai multe limbaje de programare de nivel inalt (C#, Managed C++, Visual Basic .NET, etc), la compilare toate vor produce cod in acelasi limbaj intermediar: Microsoft Intermediate Language (MSIL, sau IL pe scurt). Asemanator cu bytecod-ul, IL[10] are trasaturi ale programarii orientate
obiect,
precum
abstractizarea
datelor,
mostenirea,
polimor fismul,
incapsularea sau concepte care s-au dovedit a fi extrem de necesare, precum exceptiile sau evenimentele. De remarcat ca aceasta abstractizare de limbaj permite rularea aplicatiilor independent de platforma (cu aceeasi conditie ca si in cazul limbajului Java: sa existe o masina virtuala pentru acea platforma).
2.2 Common Language Speci fication(CLS) Unul din scopurile tehnologiei .NET este de a sprijini integrarea limbajelor de programare astfel incat programele, desi scrise in diferite limbaje, pot interopera, folosind concepte ale programarii orientate obiect precum mostenirea, polimor fismul, incapsularea, etc. Dar limbajele nu sunt identice: unele suporta supraincarcarea operatorilor (Managed C++, C#), altele nu (Visual Basic .NET); unele sunt case sensitive, altele nu. Pentru a se asigua totusi interoperabilitatea codului scris in diferite limbaje, Microsoft a publicat Common Language Specification (CLS) [10], un subset al lui CTS (Common Type System, vezi 1.3), continand specificatii de reguli necesare pentru integrarea limbajelor. CLS defineste un set de reguli pentru compilatoarele .NET, asigurand faptul ca fiecare compilator va genera cod MSIL. Obiectele si tipurile create in diferite limbaje pot interactiona fara probleme suplimentare. Combinatia CTS/CLS realizeaza de fapt interoperarea limbajelor. Concret, se poate ca o clasa scrisa in C# sa fie mostenita de o clasa scrisa in Visual Basic care arunca exceptii ce sunt prinse de cod scris in C++ sau J#.
2.3 Common Type System(CTS) Pentru a asigura interoperabilitatea limbajelor din .NET Framework, o clasa scrisa in C# trebuie sa fie echivalenta cu una scrisa in VB.NET, o interfata scrisa in Managed C++ trebuie sa fie perfect utilizabila in Managed Cobol. Toate limbajele 18 P a g e
platformei .NET trebuie sa aibe un set comun de concepte pentru a putea fi integrate. Modul in care acest deziderat s-a transformat in realitate se numeste Common Type System (CTS)[11]; orice limbaj trebuie sa recunoasca si sa poata manipula niste tipuri comune. Iata o scurta descriere a unor facilitati comune : Tipuri valoare - in general, CLR-ul (care se ocupa de managementul si executia codului IL, vezi mai jos) suporta doua tipuri diferite: tipuri valoare si tipuri referinta. Tipurile valoare reprezinta tipuri alocate pe stiva si nu pot avea valoare de null. Tipurile valoare includ tipurile primitive, structuri si enumerari. Datorita faptului ca de regula au dimensiuni mici si sunt alocate pe stiva, se manipuleaza eficient, reducand overhead-ul cerut de mecanismul de garbage collection. Tipuri referinta - se folosesc daca variabilele de un anumit tip cer resurse de memorie semnificative. Variabilele de tip referinta contin adrese de memorie heap si pot avea valoarea de null. Transferul parametrilor se face rapid, dar referintele induc un cost suplimentar datorita mecanismului de garbage collection . Boxing si unboxing - motivul pentru care exista tipuri primitive este acelasi ca si in Java: performanta. Insa orice variabila in .NET este compatibila cu clasa Object, radacina ierarhiei existente in .NET. De exemplu, int este un alias pentru System.Int32, care se deriveaza din System.ValueType. Tipurile valoare se stocheaza pe stiva, dar pot fi oricand convertite intr-un tip referinta memorat in heap; acest mecanism se numeste boxing. De exemplu: int i = 1; //i - un tip valoare object box = i; //box - un obiect referinta Cand se face boxing, se obtine un obiect care poate fi gestionat la fel ca oricare altul, facandu – se abstractie de originea lui. Inversa boxing-ului este unboxing-ul, prin care se poate converti un obiect in tipul valoare echivalent, ca mai jos: int j = (int)box; unde operatorul de conversie este suficient pentru a converti de la un obiect la o variabila de tip valoare. Clase, proprietati, indexatori - platforma .NET suporta pe deplin programarea orientata pe obiecte, concepte legate de obiecte (incapsularea, mostenirea, polimor fismul) sau trasaturi legate de clase (metode, campuri, membri statici, vizibilitate, accesibilitate, tipuri interioare, etc). trasaturi precum proprietati, indexatori, evenimente.
19 P a g e
De asemenea se includ
Interfete – in C# reprezinta acelasi concept precum clasele abstracte din C++ (dar continand doar functii virtuale pure), sau interfetele Java. O clasa care se deriveaza dintr-o interfata trebuie sa implementeze toate metodele acelei interfete. Se permite implementarea simultana a mai multor interfete (in rest mostenirea claselor este simpla). Delegati - inspirati de pointerii la functii din C, ce permit programarea generica. In C# reprezinta versiunea ―sigura‖ a pointerilor catre functii din C/C++ si sunt mecanismul prin care se trateaza evenimentele.
2.4 Common Language Runtime(CLR) CLR[10] este de departe cea mai importanta parte componenta a lui .NET Framework. Este responsabil cu managementul si executia codului scris in limbaje .NET, aflat in format IL; este foarte similar cu Java Virtual Machine. CLR instantiaza obiectele, face verificari de securitate, depune obiectele in memorie, disponibilizeaza memoria prin garbage collection. In urma compilarii unei aplicatii rezulta un fisier cu extensia exe, dar care nu este un executabil portabil Windows, ci un executabil portabil .NET (.NET PE). Acest cod nu este deci un executabil nativ, ci se va rula de catre CLR, intocmai cum un fisier class este rulat in cadrul JVM. CLR foloseste tehnologia compilarii JIT(just-in-time) - o implementare de masina virtuala, in care o metoda sau o functie, in momentul in care este apelata pentru prima oara, este tradusa in cod masina. Codul translatat este depus intr-un cache(zona de memorie rapida, in mod normal de dimensiune mai mica de 1 MB, situata pe sau in apropierea procesorului), evitand-se
astfel
recompilarea
ulterioara.
Exista
3 tipuri
de
compilatoare JIT: 1. Normal JIT - a se vedea descrierea de mai sus. 2. Pre-JIT - compileaza intregul cod in cod nativ o singura data. In mod normal este folosit la instalari. 3. Econo-JIT - se foloseste pe dispozitive cu resurse limitate. Compileaza codul IL bit cu bit, eliberand resursele folosite de codul nativ ce este stocat in cache. In esenta, activitatea unui compilator JIT este destinata a imbunatati performanta executiei, ca alternativa la compilarea repetata a aceleiasi bucati de cod in cazul unor apelari multiple. Unul din avantajele mecanismului JIT apare in clipa in
20 P a g e
care codul, o data ce a fost compilat, se executa pe diverse procesoare; daca masina virtuala este bine adaptata la noua platforma, atunci acest cod va bene ficia de toate optimizarile posibile, fara a mai fi nevoie recompilarea lui (precum in C++, de exemplu). CLR-ul este capabil sa inteleaga codul in format IL si sa-l compileze in cod masina. In general, exista o componenta a CLR-ului care este raspunzatoare pentru compilarea codului din format IL in cod masina. Aceasta componenta este compilatorul just-intime(JIT), care actioneaza atunci cand un program este instalat sau executat. Figura urmatoare schematizeaza fazele compilarii unui cod C# in cod masina[10]:
Figura 1 : Compilare cod C# in cod masina
21 P a g e
Exista numeroase componente ale lui CLR care il fac cea mai importanta parte a lui .NET Framework: metadata, assemblies, assembly cache, reflection, garbage collection. Metadata: Metadata inseamna in general ―date despre date‖. ˆ In cazul .NET, ea reprezinta informatii destinate a fi citite de catre masina, nu de utilizatorul uman. Este stocata impreuna cu codul pe care il descrie. Pe baza metadatei, CLR stie cum sa instantieze obiectele, cum sa le apeleze metodele, cum sa acceseze proprietatile. Printr-un mecanism numit reflection, o aplicatie (nu neaparat CLR) poate sa interogheze aceasta metadata si sa afle ce expune un obiect. Mai pe larg, metadata contine o declaratie a fiecarui tip si cate o declaratie pentru fiecare metoda, camp, proprietate, eveniment al tipului respectiv. Pentru fiecare metoda implementata, metadata contine informatie care permite incarcatorului clasei respective sa localizeze corpul metodei. De asemena mai poate contine declaratii despre cultura aplicatiei respective, adica despre localizarea ei (limba folosita in partea de interfata utilizator). Mecanismul prin care aceste informatii se folosesc pe parcursul rularii de catre aplicatii se numeste reflection. Assemblies : Un assembly reprezinta un bloc functional al unei aplicatii .NET. El formeaza unitatea fundamentala de distribuire, versionare, reutilizare si permisiuni de securitate. La runtime, un tip de date exista in interiorul unui assembly (si nu poate exista in exteriorul acestuia). Un assembly contine metadate care sunt folosite de catre CLR. Scopul acestor ―assemblies‖-uri este sa se asigure dezvoltarea softului in mod ―plug-and- play‖. Dar metadatele nu sunt suficiente pentru acest lucru; mai sunt necesare si ―manifestele‖. Un manifest reprezinta metadate despre assemblyul care gazduieste tipurile de date. Contine numele assembly-ului, informatia despre versiune, referiri la alte assemblies-uri, o lista a tipurilor in assembly, permisiuni de securitate si altele. Un assembly care este impartit intre mai multe aplicatii are de asemenea un shared name. Aceasta informatie care este unica este optionala, neaparand in manifestul unui assembly daca acesta nu a fost gandit ca o aplicatie partajata. Deoarece un assembly contine date care il descriu, instalarea lui poate fi facuta copiind assembly-ul in directorul destinatie dorit. Cand se doreste rularea unei aplicatii continute in assembly, manifestul va instrui mediul .NET despre modulele care sunt continute in assembly. Sunt folosite de asemenea si referintele catre orice assembly extern de care are nevoie aplicatia. 22 P a g e
Versionarea este un aspect deosebit de important pentru a se evita asa numitul ―DLL Hell‖. Scenariile precedente erau de tipul: se instaleaza o aplicatie care aduce niste fisiere .dll necesare pentru functionare. Ulterior, o alta aplicatie care se instaleaza suprascrie aceste fisiere (sau macar unul din ele) cu o versiune mai noua, dar cu care vechea aplicatie nu mai functioneaza corespunzator. Reinstalarea vechii aplicatii nu rezolva problema, deoarece a doua aplicatie nu va mai functiona in acest caz. Desi fisierele dll contin informatie relativ la versiune in interiorul lor, ea nu este folosita de catre sistemul de operare, ceea ce duce la probleme. O solutie la aceasta dilema ar fi instalarea fisierelor dll in directorul aplicatiei, dar in acest mod ar disparea reutilizarea acestor biblioteci. Assembly cache: Assembly cache este un director aflat in mod normal in directorul \Winnt \Assemblies. Atunci cand un assembly este instalat pe o masina, el va fi adaugat in assembly cache. Daca un assembly este descarcat de pe Internet, el va fi stocat in acest assembly cache, intr-o zona tranzienta. Aplicatiile instalate vor avea assemblies-urile intr-un assembly cache global. In acest assembly cache vor exista versiuni multiple ale aceluiasi assembly. Daca programul de instalare este scris corect, va evita suprascrierea assembly-urilor deja existente (si care functioneaza perfect cu acplicatiile instalate), adaugand doar noul assembly. Este un mod de rezolvare a problemei ―DLL Hell‖, unde suprascrierea unei biblioteci dinamice cu o varianta mai noua putea duce la nefunctionarea corespunzatoare a aplicatiilor anterior instalate. CLR este cel care decide, pe baza informatiilor din manifest, care este versiunea corecta de assembly de care o aplicatie are nevoie. Acest mecanism a pus capat unei epoci de trista amintire pentru programatori si utilizatori. Garbage collection: Managementul memoriei este una din sarcinile cele mai consumatoare de resurse umane. Garbage collection este mecanismul care se declanseaza atunci cand alocatorul de memorie raspunde negativ la o cerere de alocare de memorie. Implementarea este de tip ―mark and sweep‖: se presupune initial ca toata memoria alocata se poate disponibiliza, dupa care se determina care din obiecte sunt referite de variabilele aplicatiei; cele care nu mai sunt referite sunt dealocate, iar celelalte zone de memorie sunt compactate. Obiectele a caror dimensiune de memorie este mai mare decat un anumit prag nu mai sunt mutate, pentru a nu creste semnificativ penalizarea de performanta. In general, CLR-ul este cel care se ocupa de apelarea mecanismului de garbage collection. Totusi, la dorinta, programatorul poate cere rularea lui. 23 P a g e
2.5 Trasaturi ale platformei .NET Prin prisma celor prezentate mai sus putem rezuma urmatoarele trasaturi: •Dezvoltarea multilimbaj: Deoarece exista mai multe limbaje pentru aceasta platforma, este mai usor de implementat parti specifice in limbajele cele mai adecvate. Numarul limbajelor curent implementate este mai mare decat 10. Aceasta dezvoltare are in vedere si debugging-ul aplicatiilor dezvoltate in mai multe limbaje. • Independenta de procesor si de platforma: IL este independent de procesor. O data scrisa si compilata, orice aplicatie .NET (al carei management este facut de catre CLR) poate fi rulata pe orice platforma. Datorita CLR-ului, aplicatia este izolata de particularitatile hardware sau ale sistemului de operare. • Managementul automat al memoriei: Problemele de tipul memory leakage(fenomen ce apare in programare atunci cand un program consuma memorie pe care apoi este incapabil sa o elibereze) nu mai trebuie sa preocupe programatorii; overhead-ul indus de catre mecanismul de garbage collection este suportabil, fiind implementat in sisteme mult mai timpurii. • Suportul pentru versionare: Ca o lectie invatata din perioada de ―DLL Hell‖, versionarea este acum un aspect de care se tine cont. Daca o aplicatie a fost dezvoltata si testata folosind anumite componente, instalarea unei componente de versiune mai noua nu va atenta la buna functionare a aplicatiei in discutie: cele doua versiuni vor coexista pasnic, alegerea lor fiind facuta pe baza manifestelor. • Sprijinirea standardelor deschise: Nu toate dispozitivele ruleaza sisteme de operare Microsoft sau folosesc procesoare Intel. Din aceasta cauza orice este strans legat de acestea este evitat. Se foloseste XML si cel mai vizibil descendent al acestuia, SOAP. Deoarece SOAP este un protocol simplu, bazat pe text, foarte asemanator cu HTTP5 , el poate trece usor de firewall-uri, spre deosebire de DCOM sau CORBA. • Distribuirea usoara: Actualmente instalarea unei aplicatii sub Windows inseamna copierea unor fisiere in niste directoare anume, modificarea unor valori in registri, instalare de componente COM, etc. Dezinstalarea completa a unei aplicatii este in majoritatea cazurilor o utopie. Aplicatiile .NET, datorita metadatelor si reflectarii trec de aceste probleme. Se doreste ca instalarea unei aplicatii sa nu insemne mai mult decat copierea fisierelor necesare intr-un director, iar dezinstalarea aplicatiei sa se faca prin stergerea acelui director.
24 P a g e
• Arhitectura distribuita: Noua filosofie este de a asigura accesul la servicii Web distribuite; acestea conlucreaza la obtinerea informatiei dorite. Platforma .NET asigura suport si unelte pentru realizarea acestui tip de aplicatii. •
Interoperabilitate cu codul “unmanaged” : Codul ―unmanaged‖ se refera
la cod care nu se afla in totalitate sub controlul CLR. El este rulat de CLR, dar nu beneficiaza de CTS sau garbage collection. Este vorba de apelurile functiilor din DLL-uri, folosirea componentelor COM, sau folosirea de catre o componenta COM(Component Object Model) a unei componente .NET. Codul existent se poate folosi in continuare. • Securitate: Aplicatiile bazate pe componente distribuite cer automat securitate. Modalitatea actuala de securizare, bazata pe drepturile contului utilizatorului, sau cea din Java, in care codul suspectat este rulat intr-un ―sandbox‖( un mecanism de securitate folosit pentru a rula cod netestat sau programme nedorite), fara acces la resursele critice este inlocuit in .NET de un control mai fin, pe baza metadatelor din assembly (zona din care provine - ex. Internet, intranet, masina locala, etc) precum si a politicilor de securitate ce se pot seta.
25 P a g e
Capitolul II. Proiectarea orientata obiect 1.
Introducere si obiective Odata ce o problema a fost analizata, este necesar sa decidem cum ar trebui ea
proiectata. Etapa proiectarii sistemului descrie o strategie de nivel inalt, necasara pentru rezolvarea problemei. In aceasta faza, se stabilesc bazele arhitecturale ale sistemului atat din punct de vedere hardware, cat si software. Proiectarea obiectelor este a doua etapa a fazei de proiectare si se ocupa cu determinarea tuturor definitiilor, claselor si asocierilor pe care le folosim in implementare. In plus, trebuie proiectati si algoritmii care implementeaza operatia. Acest capitol descrie pasii care trebuie urmati de-a lungul proiectarii sistemului.
1.2 Determinarea subsistemelor O entitate poate fi orice tip de informatie, de exemplu caracteristica obiectului, numele clasei, fluxul datelor si decursul evenimentelor. Miller[MG] a introdus notiunea de fragment. Un fragment contine o cantitate de informative de nivel inalt sau scazut. Subsistemele, in dezvoltarea orientate spre obiect, sunt grupuri de clase inrudite, fiecare constituind o entitate avand atat proprietati (atribute), cat si comportament (operatii)[15]. O proiectare buna a sistemelor va produce subsisteme care au o puternica cuplare interna si o slaba cuplare externa, cu alte subsisteme. Tehnica de aplicare a conceptelor permite proiectantului sa le determine intr-o etapa recipient. Conceptul cheie va corespunde sistemului principal, in timp ce conceptele mai putin generale vor corespunde subsistemelor. Fiecare concept, mai putin general, poate fi la randul lui analizat ca un concept cheie. Exista un numar de piedici care apar la extinderea sistemelor software, si anume:
26 P a g e
Distributia excesiva a informatiilor: Sistemul postal este un bun exemplu despre modul in care deciziile de implementare luate sunt raspandite si propagate in intregul sistem. Proiectantul software ar trebui sa ia in considerare sursele de incertitudine in timpul fazei de proiectare al sistemului. Scopul ar trebui sa fie proiectarea de software, care este extensibil, fara schimbari majore in arhitectura sa de baza.
Inlantuirea transformarilor de date: O problema majora in proiectarea de software implica sisteme care produc iesiri dupa un format predefinit. O iesire dintr-un sistem poate fi folosita ca intrare de un altul.
Componente care indeplinesc mai mult de o functie: De exemplu, o greseala frecventa in C++ este implementarea de clase care indeplinesc activitati specific domeniului si care, in acelasi timp, se pot scrie pe discheta. Daca dorim sa extindem clasa in asa fel incat sa lucreze cu un sistem de baze de date orientate spre obiect, probabil va trebui sa schimbam codul sursa si sa testam din nou functionalitatea de baza a clasei.
Cicluri in ierarhia utilizarilor: Un subsistem dat poate folosi serviciile altui subsistem. Cu toate acestea, pot exista cicluri in aceste utilizari, relatiile rezultand dintr-un sistem care este viabil doar daca toate elementele functioneaza.
1.3. Legatura subsistemelor cu unitatile functionale Odata ce subsistemele au fost fondate, urmatorul pas este sa alocam fiecarui subsistem o unitate functionala. Aceasta poate fi un proces hardware, software sau unul de uz general. Aplicatiile in care informatia este distribuita printre diferite locatii va fi implementata de cateva unitati functionale. De exemplu, aplicatia client/server foloseste un singur dispozitiv de stocat informatii (serverul), in timp ce alte dispozitive contin subsisteme care acceseaza aceste informatii (clientii). Reprezentarea unitatilor functionale: Pasii care trebuie urmati in acest studiu al proiectarii sunt:
Estimarea nevoilor de performanta;
Determinarea unitatilor functionale care implementeaza fiecare sistem;
Determinarea conexiunii fizice, a unitatilor functionale rezultate;
27 P a g e
Alegerea unei unitati functionale depinde de aplicatie. Unele programe grafice implementeaza algoritmi tridimensionali de transformare geometrica in dispozitive hardware, pentru a imbunatati executia. Alte aplicatii produc o rezerva de date intr-o statie de lucru locala, in acest fel prevenindu-se nevoia de a accesa datele intr-un deposit permanent, mai lent. Unele unitati functionale produc date care sunt necesare altor unitati. Daca ambele unitati sunt localizate pe acelasi procesor sau daca ambele pot accesa datele, atunci nu este nevoie de transfer de date. In medii de retea, este de asemenea posibil sa se configureze statiile de lucru in asa fel incat aplicatiile care lucreaza pe diferite gazed sa poata accesa un disc dat. Acest lucru este atins de Sun Microsystems’ Network File System (NFS), care suporta accesul fisierelor printr-o retea si nu numai.
1.4. Alegerea si gestiunea depozitelor de date Un depozit de date este o entitate pasiva care stocheaza date. Comunicarea subsistemeleor prin referinta se pot efectua prin fisiere, sisteme de baze de date relationale (RDBMS) sau sisteme de baze de date orientate spre obiect (ODBMS). Bazele de date orientate spre obiect au avantajul ca suporta cele mai importante trasaturi mostenite din paradgima orientarii spre obiect, cum ar fi agregarea, mostenirea si incapsularea. Sistemele ODBMS modeleaza obiectele intr-un mod natural si folosirea lor este recomandata. Totusi, anumite subsisteme trebuie sa realizeze interfata cu alte sisteme care au fost scrise folosind limbaje neorientate spre obiect si sisteme de baze de date. Aceste subsisteme nu inteleg obiectele, astfel ca interfetele lor sunt implementate de obicei, ca fisiere ASCII sau tabele RDBMS[15].
1.5. Determinarea arhiteturii sistemului Exista un numar de prototipuri de structuri arhitecturale in care se incadreaza majoritatea problemelor din viata reala. Iata cateva tipuri de sisteme:
Manager de tranzactie – este un sistem de baze de date a carui functie principal este sa stocheze si sa acceseze informatii.
28 P a g e
Transformarile de serie – se diferentiaza prin faptul ca nu interactioneaza cu lumea exterioara. Ele sunt o aparitie comuna in constructia compilatoarelor in programele statului de plata si in implementari ale metodei elementului finit. Un program de elemente finite citeste fisierul continand specificatiile geometrice ale obiectelor bidimensionale si tridimensionale si calculeaza proprietatile asociate cu aceste obiecte.
Interfata interactiva – este un sistem in care interactiunile dintre sistem si agentii externi joaca un rol important. O astel de interfata poate fi o parte a unei aplicatii. De exemplu, PIR are nevoie de o interfata, astfel incat cititorii sa introduca date si cereri. Aceasta interfata ar putea fi un sistem alfanumeric sau un sistem Windows cu intrari de la tastatura si mouse.
Un sistem in timp real – este acel sitem dominat de constrangerile timpului in actiunile sale. Modelul dinamic este de o importanta absoluta, in timp ce modelele functionale si ale obiectelor pot fi impotante sau nu.
Un sistem de simulare dinamica – modeleaza obiectele din lumea reala. Modelul obiectelor este deseori complex, acesta fiind reprezentat prin clase pentru ansamblul pompei, rezervorului si liniei de debitare. Modelul dinamic descrie interactiunile clientului cu sistemul, in timp ce modelul functional descrie procesele care au loc odata ce un client a completat tranzactia de livrare si trebuie facuta o adeverinta de plata.
O transformare continua – este un sistem in care iesirile active depind de schimbarea intrarilor si care trebuie periodic reactulizat. Aceasta opereaza asupra unor fluxuri active, in care intrarea, cat si iesirea, sunt reactualizate continuu. Modelele obiectelor si cel functional sunt importante in transformarile continue, in vreme ce modelele dinamice sunt mai putin importante din moment ce majoritatea interactiunilor din sistem sunt datorate fluxului de date constant dintre diferite procese si nu interactiunilor cu agenti externi.
2. Programarea orientate spre obiect Dezvoltarea de sisteme orientate obiect pare a fi, la prima vedere, mai complicata si de durata mai mare decat dezvoltarea aplicatiilor traditionale. In realitate, durata si costurile dezvoltarii de aplicatii orientate obiect sunt mult mai mici. 29 P a g e
Etapa fundamentala in cadrul acestui proces o constituie cea de proiectare a sistemului, chiar daca este evident ca structura interna a acestuia este irelevanta pentru utilizatori[15]. S-a constatat de asemenea ca succesul aplicatiilor orientate obiect depinde in principal de doi factori: a) Existenta unei viziuni arhitecturale coerente si bine definite Arhitectura unui sistem orientat pe obiecte cuprinde atat structura claselor si interactiunea dintre obiecte, cat si impartirea aplicatiei in module si nivele de abstractizare. Cateva conditii in vederea realizarii unei arhitecturi corecte: - nivele de abstractizare bine definite - clase avand interfete bine definite, a caror modificare provoaca schimbari minime asupra celorlalte clase - modificarea modului de implementare a unei clase nu are repercursiuni asupra interfetei sau implementarii celorlalte clase - arhitectura sistemului este simpla, realizata prin abstractii si mecanisme obisnuite b) Urmarea unui ciclu de dezvoltare atat iterativ cat si incremental bine administrat Exista in principal doua tipuri de cicluri de dezvoltare: - ciclu de dezvoltare nedefinit. In acest caz, este imposibil de stiut viteza dezvoltarii sistemului, momentul la care va fi finalizat, calitatea sistemului ramanand permanent sub semnul intrebarii. Este posibila ca o parte din eforturile depuse sa fie ineficiente, asadar costurile dezvoltarii sa fie foarte mari. - reguli clare care stabilesc fiecare aspect al ciclului. In acest de-al doilea caz, este impiedicata creativitatea si experimentul, care ar putea produce o aplicatie avand calitate sporita. Cerintele utilizatorilor ajung cu dificultate la nivelul programatorilor ce realizeaza aplicatia, ingreunand procesul de dezvoltare si marindu-i costurile. In realitate, nu vom intalni nicaieri vreunul dintre aceste cazuri distinct. In cadrul dezvoltarii de sisteme software, aceste doua tipuri de cicluri de dezvoltare se intrepatrund, inclinand mai mult sau mai putin spre una dintre extreme, functie de deciziile luate de conducatorii acestor proiecte. S-a tras in multe locuri concluzia ca un ciclu de dezvoltare ideal este atat de tip iterativ cat si de tip incremental. Aplicata mai intai in domeniul programarii, abordarea orientata obiect s-a impus ca o noua paradigma informatica cu o utilizare din ce in ce mai larga. Vorbim astfel de programare orientata pe obiecte (sau obiectuala), baze de date orientate pe
30 P a g e
obiecte, analiza si proiectare orientata pe obiecte, metode de reprezentare a cunostintelor orientate pe obiecte. Modelarea obiectuala a devenit astfel trasatura comuna generatiei actuale de metode de proiectare a sistemelor si aplicatiilor informatice de gestiune[15]. Chiar daca implementarea urmeaza sa se faca utilizand o baza de date relationala sau un limbaj de programare fara functionalitati specifice, practica a dovedit ca aplicarea acestui demers conduce la solutii superioare calitativ, in special in cazul sistemelor de mari dimensiuni si complexitate. Abordarea obiectuala foloseste cinci concepte de baza: obiectul, clasa, mesajul, mostenirea si polimorfismul la care se adauga, intr-un plan mai general, abstractizarea, incapsularea, reutilizarea, persistenta.
2.1. Obiecte si clase de obiecte Obiectul constituie componenta elementara intr-un sistem orientat pe obiecte. Acesta poate corespunde unui concept, unei abstractiuni sau unui lucru cu limite bine definite si cu semnificatie precisa in spatiul problemei studiate. Fiecare obiect poseda o stare, un comportament si o identitate[11]. Starea caracterizeaza obiectul si este format din ansamblul de valori ale atributelor sau proprietatilor acestuia la un moment dat. Comportamentul este definit de ansamblul de operatii pe care le poate executa obiectul. Comportamentul mai poate fi perceput si ca un set de responsabilitati asumate sau de servicii oferite altor obiecte. Comportamentul obiectului este definit de ansamblul operatiilor sale si depinde de starea in care se afla. Identitatea semnifica posibilitatea reprezentarii si conservari individualitatii fiecarui obiect, indiferent de transformarile sau schimbarile de stare pe care le suporta. Identificarea obiectelor se face datorita existentei lor inerente si nu printr-o proprietate sau grup de proprietati. Distinctia
dintre
obiecte
- respectiv
desemnarea
sau
referirea unui anumit obiect - are un caracter uniform si independent de continut. Termenul "uniform" indica foarte clar ca identitatea unui obiect il separa pe acesta din ansamblul tuturor obiectelor, indiferent de tipul lor. Clasa descrie ansamblul, eventual infinit, de obiecte care au proprietati similare, comportament comun, relatii comune cu alte obiecte si aceeasi semantica. Gruparea obiectelor in clase este rezultatul abstractizarii, prin care se pleaca de la cazuri particulare. Clasa abstractizeaza un grup de obiecte similare. Clasa cuprinde
31 P a g e
elementele comune obiectelor ce-i apartin, adica descrierea atributelor si a operatiilor. Fiecare obiect este o instantiere a clasei sale si contine numai valorile proprii corespunzatoare fiecarui atribut. in plus, fiecare obiect mentine permanent legatura cu clasa sa. Ca instantiere a unei clase, orice obiect trebuie creat la un moment dat si poate disparea atunci cand nu mai este necesar. Operatiile corespunzatoare sunt denumite constructori si respectiv destructori[11].
Operatiile sunt de mai multe tipuri:
construc¬tor, destructori, selectori, modificatori. In cursul existentei unui obiect, pot apare operatii ce modifica starea acestuia, numite generic modificatori si operatii de consultare a stirii, numite selectori. Implementarea (maniera de executie) fiecarei operatii este memorata in cadrul clasei si constituie o metoda. Metoda este implemen¬tarea unei operatii de catre o clasa. Orice operatie are un argument implicit si anume obiectul caruia i se adreseaza. Obiectul invocat va obtine de la clasa careia ii apartine metoda corespunzatoare si o va aplica asupra datelor sale de stare. O operatie poate avea si alte argumente. Numarul, tipul si ordinea argumentelor impreuna cu tipul eventualului rezultat returnat definesc semnatura operatiei.
2.2. Mesajul Schimbul de mesaje reprezinta forma universala de interactiune intre obiecte. Mesajul este unitatea de comunicatie dintre obiecte[11]. Obiectele interactioneaza prin schimburi de mesaje. Un mesaj are un emitator si un destinatar si invoca o anumita operatie. Destinatarul poate raspunde singur solicitarii primite sau poate emite, la randul sau, mesaje adresate altor obiecte. Obtinand de la acesta durata corespunzatoare codului sau de clasificare, va determina amortizarea pentru luna si anul specificate, dupa care le va transmite ca raspuns emitatorului mesajului initial. Invocarea unei operatii este prefixata de identificatorul obiectului destinatar, delimitat de regula prin punct. Functionarea sistemului rezulta din aceasta interactiune a obiectelor iar derularea prelucrarii este decisa prin cooperarea dintre obiecte, dictata de comportamentul specific al fiecaruia si de starea in care se gasesc in momentul respectiv.
32 P a g e
2.3. Mostenirea Mostenirea desemneaza partajarea atributelor si operatiilor unei (sau unor) clase de catre o alta (sau alte) clase in cadrul unei relatii ierarhice, pastrand nealterate diferentele dintre ele. Clasa de la care se mosteneste este numita superclasa, iar cea care mosteneste poarta numele de subclasa sau clasa derivata. Mostenirea permite exprimarea relatiilor de generalizare/specializare dintre clase. Mostenirea este tranzitiva pe un numar oricat de mare de nivele[10]. Instantierea unei subclase este simultan instantiere a tuturor superclaselor sale. Prin intermediul mostenirii se pot exprima diferite relatii dintre specializarea,
clasificarea,
aproximatia
si
evolutia.
clase: generalizarea,
Posibilitatea
factorizarii
proprietatilor comune mai multor clase intr-o superclasa si a mostenirii proprietatile superclasei este unul dintre avantajele importante ale abordarii orientate pe obiecte.
2.4. Polimorfismul Polimorfismul desemneaza capacitatea unei operatii de a se aplica obiectelor din clase diferite. Unul dintre
cele mai comune exemple de polimorfism este
reprezentat de operatorii + si — (minus), care exprima adunarea, respectiv scaderea, atat pentru numerele
intregi cat si pentru cele reale. Operatiile polimorfe sunt
implementate de mai multe clase prin metode diferite[11]. Polimorfismul inseamna, asadar, ca o operatie poate fi implementata prin mai multe metode. Operatiile polimorfe au aceeasi semnatura in toate clasele care le implementeaza. Selectia metodei adecvate la apelul unei operatii se face automat, pe baza numelui operatiei si a clasei careia ii apartine obiectul implicat. Astfel, obiectul ce emite un mesaj prin care invoca o operatie nu trebuie sa stie nici cate implementari diferite exista pentru aceasta si nici modul in care operatia este executata de catre obiectul destinatar.
2.5. Abstractizarea Abstractizarea este procesul prin care se izoleaza si se retin numai o parte dintre aspectele unei probleme, considerate esentiale, ignorandu-le pe celelalte. Aspectele retinute depind de scopul urmarit. Rezulta de aici ca, pentru aceeasi problema sau aspect al realitatii, pot exista mai multe abstractizari diferite. Abstractizarea permite
33 P a g e
concentrarea asupra aspectelor conceptual-functionale si evitarea luarii premature in considerate a detaliilor[11]. Abstractizarea isi gaseste multiple utilizari in informatica, pe tot parcursul dezvoltarii unei aplicatii informatice, indiferent de metoda (sau de lipsa de metoda) folosita. De altfel, se apreciaza ca gasirea de bune abstractizari este problema esentiala pentru orice proiectare de sistem. In cadrul abordarii orientate obiect, exista multiple utilizari specifice ale abstractizarii. Una dintre acestea o reprezinta conceptul de clasa. Clasele reprezinta abstractizari ale unor multimi de obiecte. Una dintre
uzantele sale specifice in
abordare poate fi privit, in ansamblu, ca un proces de abstractizare, prin care se urmareste formularea in termeni informatici - inregistrare, cheie de acces, procedura, functie, modul etc. - a unor concepte sau parti ale lumii reale, cu un nivel mult mai inalt de abstractizare - persoane, structuri organizatorice, utilaje, facturi s.a.m.d. Din cauza complexitatii, acest demers se realizeaza progresiv, in mai multe stadii succesive, intr-o ordine in care mai intai se stabileste ce este si ce trebuie sa faca fiecare obiect si abia apoi se decide modul in care acesta este implementat. Clasele constituie, la randul lor, abstractizari ale unor ansambluri de obiecte.
2.6. Incapsularea Incapsularea plaseaza o bariera
intre comportamentul exterior si detaliile
interne[11]. Incapsularea, numita si mascarea informatiilor, consta in gruparea tuturor detaliilor de implementare - moduri de reprezentare si mecanisme de realizare a comportamentului - intr-o parte ascunsa, inaccesibila din exterior. Cooperarea cu restul componentelor are loc prin intermediul unei interfete, care expune numai caracteristicile functionale necesare utilizarii. Bariera dintre interfata si implementare trebuie sa fie inviolabila pentru orice componenta cu care are loc cooperarea. Prin incapsulare se reduce gradul de interdependenta necesare
modificari
pentru
inlantuirea
unor
intre erori
componente. Daca sunt sau
pentru
ameliorarea
performantelor de executie, aceasta afecteaza numai partea de implementare. Interfata ramane neschimbata si, in consecinta, functionarea celorlalte componente ale aplicatiei nu este afectata. Practic, incapsularea ascunde reprezentarea obiectelor si metodele acestora.
34 P a g e
O clasa nu trebuie
sa expuna decat ansamblul operatiilor care formeaza
comportamentul instantierilor sale. Aceasta inseamna ca si atributele trebuie sa fie mascate, deci invizibile si inaccesibile din exterior. In consecinta, sunt necesare operatii distincte pentru consultarea si modificarea - sau cel putin initializarea continutului lor. Dat fiind caracterul lor implicit, ele pot sa nu fie specificate in cursul analizei si proiectarii dar apar obligatoriu in faza de programare. Pentru a permite mascarea selectiva a atributelor si metodelor, indispensabila in practica, se recurge la conceptul de vizibilitate. In termeni generali, pentru ca un obiect sa poata invoca o operatie sau sa faca referire la un atribut, acestea trebuie sa fie vizibile pentru el. Vizibilitatea este structurata pe trei nivele: publica, privata , protejata. Atributele si metodele private sunt invizibile si, in consecinta, inaccesibile tuturor celorlalte clase. Prin contrast, atributele si metodele publice sunt expuse si deci accesibile intregului sistem. Nivelul protejat limiteaza vizibilitatea la ansamblul subclaselor. Gradul de incapsulare este indicat de nivelul de vizibilitate. Vizibilitatea poate fi fixata individual pentru fiecare atribut si operatie, respectiv metoda, ceea ce ofera un spor de flexibilitate.
2.7. Reutilizarea Reutilizarea constituie unul dintre
marile avantaje promise de abordarea
orientata pe obiecte. Calitatile de modularitate si flexibilitate conferite prin aplicarea abstractizarii, incapsularii si mostenirii permit construirea de biblioteci de componente reutilizabile, ce pot fi direct asamblate corespunzator cerintelor fiecarei aplicatii a sa cum se face, spre exemplu, cu caramizile sau prefabricatele la ridicarea unei constructii. La economia de efort de conceptie si programare realizate astfel, se adauga si o calitate superioara, provenita din faptul ca aceste componente sunt studiate, dezvoltate si testate independent. Utilizarea intr-un numar mare de aplicatii conduce, inevitabil, si la cresterea fiabilitatii[11]. Mostenirea structurilor de date si a comportamentului contribuie intr-un mod specific la reutilizare. Aceasta se manifesta in primul rand la nivelul codului de scris intr-un limbaj de programare, care devine mult mai redus deoarece pentru dezvoltarea unei noi subclase este necesar sa se redacteze numai partile specifice acesteia, restul fiind obtinut de la superclasa. Chiar la nivelul conceperii aplicatiei, mostenirea poate
35 P a g e
evidentia mult mai bine anumite similitudini si stereotipii si poate restrange astfel gradul de complexitate al proiectului. Experienta a evidentiat faptul ca nu se poate obtine un nivel suficient de semnificativ de reutilizare ramanand la nivelul claselor. S-a trecut astfel la conceptul de componente reutilizabile, formate din ansambluri de clase care coopereaza la furnizarea de functionalitati mai evoluate. Fiind foarte promitatoare, ideea reutilizarii s-a extins si spre nivelele care preced programarea propriu-zisa, sub forma sabloanelor (patterns) si a arhetipurilor. Au fost astfel definite sabloane de arhitectura, sabloane de analiza, sabloane de proiectare si chiar sabloane de modelare a intreprinderii (business patterns). Structurile idiomatice constituie echivalentul acestui tip de demers aplicat la nivelul limbajelor de programare. Dincolo de toate acestea, abordarea obiectuala, desi puternic favorizanta, nu este garantia sau formula magica a reutilizarii. Obtinerea sa solicita un efort permanent si concertat, pe intreaga durata de concepere si realizare si poate fi considerabil sustinuta sau sabotata de instrumentele si mediul de dezvoltare si executie folosit.
2.8. Persistenta Persistenta exprima sarcina memorarii obiectelor de la o executie la alta. Spre deosebire de caracteristicile mentionate anterior, persistenta are conotatii strict informatice. Scopul sau este acela de a permite obiectelor sa "supravietuiasca" de la o executie la alta. Cum nu toate obiectele trebuie conservate, se recurge la termenul de obiecte efemere sau tranzitorii, pentru cele a caror existenta poate inceta odata cu incheierea executiei programului si obiecte persistente, pentru cele care trebuie conservate astfel incat la urmatoarea executie sa poata fi regasite in starea pe care o aveau la terminarea prelucrarii precedente[11]. Solutiile de asigurare a persistentei oferite de limbajele de programare orientate pe obiecte
(daca
exista)
sunt concepute in ideea ca acestea sunt in numar (foarte)
redus, formand mai curand o exceptie de la cazul general al obiectelor, in mod implicit, tranzitorii. Din pacate, sistemele informatice economice si de gestiune au caracteristica de a lucra cu volume foarte mari de date (citeste obiecte), ceea ce schimba radical perspectiva. In consecinta, persistenta devine aici o problema de sine statatoare, care face sa apara stratificari arhitecturale si clase dedicate si pentru a carei
36 P a g e
rezolvare se recurge la baze de date orientate obiect in cazurile cele mai fericite, relationale in cazurile cele mai frecvente.
3. Metodologii de realizare a sistemelor informatice cu abordare orientata obiect
Evolutia rapida in domeniul tehnologiei informatiei a impus elaborarea de noi metodologii pentru dezvoltarea sistemelor si aplicatiilor informatice. Astfel au inceput sa fie dezvoltate metodologiile cu abordare orientata obiect, care permit construirea sistemelor informatice folosind conceptele tehnologiei orientate obiect. Premisele care au condus la aparitia acestor metodologii isi au originea in necesitatea eliminarii deficientelor metodologiilor cu abordare structurala. Metodologiile orientate obiect propun modelarea concomitenta a datelor si functiilor obtinand ierarhii de clase de obiecte care inglobeaza atat date cat si comportament. Desi exista un numar mare de metodologii cu abordare obiectuala de realizare a sistemelor informatice, fiecare avand anumite particularitati, acestea sunt dezvoltate in jurul unor aspecte comune:
activitatile sunt grupate in raport de omogenitatea si obiectivele urmarite in etape;
documentatia de sistem permite imbunatatirea comunicarii intre cei care participa la dezvoltarea noului sistem: analisti, utilizatori, proiectanti si programatori;
pentru
descrierea
sistemului
se
utilizeaza
trei
modele:
modelul
obiectelor (static), modelul dinamic si modelul functional;
realizarea sistemului informatic se bazeaza pe o abordare ciclica, iterativa;
ciclul de viata al dezvoltarii sistemelor cu abordare obiectuala contine in general trei faze: analiza, proiectarea si implementarea;
permit reutilizarea rezultatelor din fazele de analiza, proiectare si implementare;
comparativ cu metodologiile cu abordare structurata, abordarea orientata obiect muta centrul de greutate al solutionarii problemei in faza de analiza, fapt ce va fi compensat cu un minimum de efort in faza de implementare.
37 P a g e
In prezent exista mai multe metodologii de realizare a sistemelor orientate obiect dintre care amintim: Object Modeling Technique (OMT), Object Lifecycles (OL), Object - Oriented Analysis and Design (OOAD), Object – oriented System Development (OOSD) si metodologii de realizare a sistemelor informatice bazate pe UML[11].
3.1. Object modeling technique (OMT) Object Modeling Technique (OMT) - este o tehnica de proiectare a sistemelor informatice care insa a fost extinsa la rang de metodologie. Descrierea sistemului se realizeaza cu ajutorul a trei modele: a. Modelul obiectual – cu ajutorul sau se realizeaza descrierea structurii statice a obiectelor, claselor de obiecte, a operatiilor si atributelor precum si a legaturilor si a relatiilor dintre ele. La nivelul acestui model se foloseste Diagrama de asociere a claselor (Class Association Diagram). b. Modelul dinamic - cu ajutorul sau se realizeaza descrierea interactiunilor dintre obiecte si este focalizat pe aspecte ce se schimba in timp deoarece orice obiect are un ciclu de viata cu un punct de pornire si unul de sfarsit; modelul dinamic descrie acest ciclu de viata, ce se intampla de-a lungul sau si cum este influentat obiectul. La nivelul acestui model se folosesc: Diagrama de trasare a evenimentelor (Event Trace Diagram) si Diagrama de tranzitie a starilor (State Transition Diagram). c. Modelul functional - descrie transformarile valorilor datelor precizand sursa lor, transformarile lor (obtinerea iesirilor informationale pe baza intrarilor), precum si destinatia lor. La nivelul acestui model se foloseste Diagrama de flux a datelor (Data Flow Diagram), Diagrama de Comunicare a Claselor (Class Comunication
Diagram),
Diagrama
de
Generalizare
a
Mesajelor
(Message
Generalization Diagram). Conform acestei metodologii se parcurg patru faze, la nivelul fiecarei etape realizandu-se o serie de activitati specifice: 1. Etapa de analiza - vizeaza realizarea unui model global ce va contine obiectele
din
domeniul
aplicatiei,
precum
si
descrierea
proprietatilor
si
comportamentului acestora. La nivelul acestei etape se realizeaza urmatoarele activitati:
38 P a g e
formularea problemei – beneficiarul formuleaza problema si cuprinde
cerintele acestuia (ce anume asteapta sa realizeze viitorul sistem) vis-a-vis de sistemul care se va dezvolta; se initiaza procesul de realizare a modelului obiectual – se identifica
obiectele, clasele de obiecte, asocierile dintre clase si obiecte, atributele claselor si obiectelor. Acestea vor servi pentru descrierea statica a sistemului utilizand diverse diagrame si simboluri grafice; se initiaza procesul de realizare a modelului dinamic – se identifica starile
si evenimentele care conduc la trecerea dintr-o stare in alta, precum si succesiunea acestora in timp, toate acestea regasindu-se in diagramele de stare si diagrama globala de flux a evenimentelor; se initiaza procesul de realizare a modelului functional : se identifica
intrarile si iesirile realizandu-se diagrama de flux a datelor; se descriu procesele elementare fara a se lua in considerare detaliile legate de implementare; se identifica constrangerile, precum si modalitatile de optimizare. 2. Etapa de proiectare – la modelul obiectual obtinut in prima etapa se vor adauga detalii de implementare pentru a se putea genera automat cod sau pentru o dezvoltare ulterioara fara generare automata. Modelul functional va descrie operatiile pe care proiectantul trebuie sa le implementeze. Modelul dinamic descrie modul in care sistemul raspunde la stimuli externi, model din care deriva structura de control. La nivelul etapei se realizeaza urmatoarele activitati: sistemul se descompune in subsisteme pe baza unor criterii de structurare; se identifica subsistemele concurente pentru optimizarea implementarii; se determina necesarul resurselor hard si soft necesare fiecarui subsistem; se decide cu privire la modul de organizare al datelor, respectiv al tipurilor
de acces; 3. Etapa de proiectare a obiectelor – are ca scop rafinarea modelelor obtinute in fazele anterioare, parcurgandu-se urmatoarele activitati: se identifica operatiile pentru modelul obiectual folosind celelalte modele:
se definesc operatii pentru fiecare eveniment al modelului dinamic si se determina operatiile aferente fiecarui proces descris in modelul functional; se proiecteaza algoritmii pentru implementarea operatiilor;
39 P a g e
se definesc noi clase sau operatii daca acest lucru este necesar si se
realizeaza o restructurare a celor existente pentru a creste probabilitatea mostenirii; se optimizeaza caile de acces; se implementeaza controlul pornind de la solutia aleasa pentru proiectarea
de sistem; se proiecteaza implementarea asocierilor; clasele si asocierile se vor grupa in module.
4. Etapa de implementare – transpunerea modelului anterior obtinut intr-un limbaj de programare urmat de transferul sistemului realizat la nivelul beneficiarului, unde se va verifica si comportamentul acestuia in practica pentru a se putea trece la exploatarea lui curenta.
3.2. Object lifecycles (OL) Object Lifecycles (OL) divide analiza si proiectarea orientata obiect. 1.Procesul de analiza orientat obiect presupune: a. model area inf ormati ei - se determina entitatile conceptuale in termeni de obiecte si atribute ale obiectelor. Sunt definiti identificatorii pentru a defini fiecare instanta a obiectului. De asemenea se realizeaza o descriere a fiecarui atribut si a domeniului lui, precum si a legaturilor dintre obiectele modelate. Asocierile intre entitati se definesc ca legaturi bazate pe reguli si legi fizice rezultate din lumea reala. Au fost introduse elemente literare „key‖ pentru obiecte si numere pentru o corelatie mai usoara intre elemente cu efect benefic asupra intelegerii reprezentarii grafice a modelului informatiei. Tabelul de corelatie pentru obiecte asociat e a fost abandonat; b. modelarea star ii – vizeaza comportamentul obiectelor si a legaturilor in timp. Modelele de stare sunt prezentate prin Diagrame de tranzitie a starii (DTS) pentru fiecare obiect ce are comportament dinamic si tabelele starii de tranzitie pentru descrierea fiecarei actiuni prezentata in DTS si a evenimentelor din lista. Modelele de stare sunt astfel folosite pentru descrierea ciclului de viata al obiectelor precum si a legaturilor dintre acestea. Diagramele de tranzitie a starii sunt realizate multi-nivel pentru ca modelul comunicarii sa fie ordonat si usor de inteles.
40 P a g e
c. modelarea procesul ui – se realizeaza diagramele de actiune a fluxului de date, care descriu ordinea de executie a proceselor, iar rezultatele sunt prezentate explicit. Modelarea procesului se realizeaza astfel: 1. actiunile sunt impartite in procese; 2. fiecare proces va fi denumit si descris; 3. se realizeaza un tabel al procesului de stare care cuprinde toate procesele din sistem si actiunile in care sunt folosite; 4. se realizeaza un model de acces la obiect pentru intelegerea modului de comunicare intre modelele de stare si sistem. In aceasta faza de analiza se utilizeaza urmatoarele tehnici: diagrama structurii de informatie realizata pentru modelarea informatiei; diagrama de tranzitie a starii – pentru a descrie ciclul de viata al unui
obiect; modelul de comunicare al obiectului – face distinctie intre tipurile de
evenimente: evenimente externe (eveniment care apare din actiuni anterioare ale sistemului sau un eveniment solicitat si care reprezinta raspuns la o activitate anterioara a sistemului) si interne (generate de un model de stare din sistem). Sunt descrise doua modele de comunicare: trop – driven pattern (modelul condus spre varf ) si bottom – driven pattern (modelul condus spre baza); Thread od Control Chart – pentru indicarea ordinii evenimentelor si starilor
(secventa de actiuni si evenimente ce apar ca raspuns la un eveniment anume); diagrama actiunii fluxului de date -
pentru reprezentarea unitatilor de
procesare intr-o actiune si comunicare intre acele unitati ale procesului; modele de acces ale obiectului – cu ajutorul carora se obtine o imagine
complementara a modelului de comunicare a obiectului, prezentand maniera de comunicare sincronizata intre modelele de stare si datele aferente obiectului. 2.Procesul de proiectare orientat obiect se exprima in termenii unui singur program care contine: 1) un program principal pentru comunicarea intre stari, invocarea operatiilor si initializarea claselor aplicatiilor;
41 P a g e
2) patru clase arhitecturale care furnizeaza mecanismele necesare initializarii, pentru traversarea masinilor de stare si obiectului „timer‖ al fazei de analiza. Obiectul „timer‖ este un mecanism utilizat de o actiune pentru a genera un eveniment la un moment viitor; 3) clase de aplicatii care sunt derivate din obiecte si modelele de stare. In aceasta faza de proiectare se utilizeaza urmatoarele tehnici: diagrama de clasa pentru reprezentarea unei clase; diagrama de structura a clasei pentru prezentarea structurii interne a
codului de operatii al clasei; diagrama de dependenta defineste invocarea client-server si legaturile
„friend‖ dintre clase; diagrama de mostenire cu ajutorul careia se prezinta legaturile de
mostenire existente intre clase.
3.3. Object – oriented analysis and design (OOAD)
Object - Oriented Analysis and Design (OOAD) – cunoaste doua versiuni: prima publicata de Martin si Odell in 1992 si cea de a doua publicata de Martin in 1993 (spre deosebire de prima versiune nu se descriu pasii proceselor de analiza si proiectare, abordarea fiind preluata din prima versiune), versiuni ce sunt aproape identice. Se incepe cu identificarea rezultatelor care se doresc a fi obtinute si punctele de plecare. Se definesc apoi evenimentele si obiectele in mod ciclic, pentru fiecare nou eveniment identificat trebuie sa se repete ciclul. Procesul de analiza si proiectare conform acestei metodologii vizeaza urmatoarele etape: 1. defi ni r ea scopul ui anali zei – se identifica scopul sau universul de interes al problemei, etapa la care participa un analist si un expert in problema; 2. clar if icar ea tipul ui de eveni ment - identificarea tipului de eveniment caruia ii apartine cel identificat. Tipul de eveniment tinta este schimbarea in starea obiectului care trebuie atinsa in final. Trebuie sa fie de asemenea identificate tipurile de obiecte implicate in eveniment, eveniment caruia i se va atribui un nume (numele trebuie sa certifice starea pre si post eveniment si procesul pe care il reprezinta);
42 P a g e
3. generalizare – pentru a defini daca un tip eveniment descrie cel mai clar nivelul de abstractizare, tipul de eveniment cu starea lui pre si post eveniment trebuie sa fie generalizat si care este cel mai reprezentativ nivel al generalizarii; 4. defi ni rea conditi il or operati ei – se identifica operatiile care conduc la un eveniment specificat, dupa care se identifica natura operatiei: operatie interna sau externa. Sunt identificate de catre expert apoi conditiile de control pentru operatie intr-un limbaj adecvat, pentru ca analistul sa le poata transforma in conditii intr-o forma normalizata; 5. identi fi carea cauzelor oper atiei – se identifica evenimentul declansator. Se studiaza conditiile de control si se identifica evenimentul care apare pentru indeplinirea conditiilor de control, dupa care evenimentele care declanseaza actiunile sunt grupate in complexe sau nu. Daca evenimentele declansatoare se aplica numai unei anumite parti a conditiei de control atunci se realizeaza o regrupare pentru aceste conditii. Se vor specifica de asemenea regulile evenimentului declansator, adica se vor identifica specificatiile exacte ale obiectului de care este nevoie pentru a invoca operatia; 6. prelu crarea r ezul tatelor ciclul ui – in raport de evenimentele declansatoare identificate se stabileste care din acestea pot fi generalizate intr-un nivel eveniment mai ridicat. De asemenea se poate stabili daca este posibil sa se specializeze evenimente declansatoare „triggeri‖ pentru a se clarifica utilizarea lor, si sa se verifice daca triggerii sunt la fel sau sunt o subclasificare a tipului de eveniment. Se elimina tot in aceasta etapa evenimentele redundante. Tehnicile utilizate in cadrul acestei metodologii sunt: diagrame de legaturi intre obiecte – folosite pentru descrierea tipului
obiectelor si a legaturilor dintre ele; diagrame de comunicare a claselor – pentru prezentarea claselor
multiple si cerintele dintre ele; diagrama
de evenimente – pentru descrierea comportamentului
sistemului; diagrama fluxului de obiecte – pentru modelarea procesului printr-o
apropiere de nivelul strategic; 43 P a g e
diagrame de compunere – pentru a arata obiectul sau clasa care se
compune din alte tipuri de obiecte, respectiv clase; diagrama Fern – cu ajutorul careia se reprezinta relatia de generalizare,
indicandu-se directia mostenirii, fara insa sa indice ce anume a fost mostenit sau cum a functionat mostenirea; diagrama de tranzitie a starilor – prezinta secventa de stare prin care
trece un obiect si comportamentul lui; diagrama de generalizare.
3.4. Object – oriented system development (OOSD)
Object – oriented System Development (OOSD) – dezvoltata de catre Champeaux, costa in faze de analiza, proiectare si implementare, primele doua faze fiind reprezentate pe larg, in timp de faza de implementare este mentionata cu ajutorul catorva consideratii. Sistemul modelat este prezentat cu ajutorul unui vocabular central bazat pe patru componente: o componenta statica, o componenta dinamica, o componenta pentru comportamentul in interiorul unui singur obiect, o componenta pentru conexiunile dintre obiecte. Procesul de dezvoltare presupune urmatoarele faze: 1. Faza de analiza la nivelul careia sunt parcursi urmatorii pasi: se intocmeste un document care cuprinde cerintele complete; informatiile pot sa nu fie complete, daca descrierile limbajului natural nu
sunt precise si poate aparea situatia in care cerintele utilizatorului nu sunt de la inceput recunoscute. Atunci apare o descriere a comportamentului de catre interactiunea sistem – context; delimitarea sistemului; pentru fiecare subsistem gasit se foloseste un limbaj specific; se descriu clasele si legaturile intre clase; se realizeaza un model in care dinamica obiectelor este interconectata.
2. Faza de proiectare – activitatile acestei faze nu pot fi descrise algoritmic. Numai anumite actiuni pot fi desfasurate mecanic. Cea mai mare parte a transformarilor sunt cele cu situatii specifice si pot aparea cu specificatii despre cum trebuie executate. Acestea folosesc cerintele transformarilor functionale, de resurse si de performanta.
44 P a g e
3. Faza de implementare – constructia unui sistem soft intercluster, documentarea si testarea. Se obtine un sistem de lucru care satisface corectitudinea, eficienta si alte criterii de performanta.
45 P a g e
Capitolul III. Descrierea si folosirea aplicatiei
In acest capitol sunt descrise si expuse functionalitatile de baza pe care le ofera prezenta aplicatie. Produsul software a fost conceput prin contopirea scopurilor si obiectivelor prezentate in primul capitol, implementand o gama importanta a cerintelor de natura birotica si fiscala din cadrul unor institutii de arta si cultura, si anume din cadrul muzeelor nationale. Aplicatia dispune de o interfata prietenoasa si usor de utilizat, astfel incat utilizatorilor le sunt necesare cunostinte minimale de operare pe un calculator. Pentru a fi cat mai utila din punct de vedere al functionalitatii si pentru a fi cat mai usor de utilizata aplicatia este compusa din opt ferestre Windows principale: 1. Fereastra ―Log in‖ - reprezinta fereastra de start a aplicatiei; prin intermediul acestei un user administrator se poate loga pentru a executa operatii de intrare/iesire asupra datelor din baza sa de date; 2. Fereastra ―Account‖ - ofera posibilitatea unui user de a-si crea un cont nou; 3. Fereastra ―Main‖ - reprezinta fereastra principala a aplicatiei; 4. Fereastra ―Contact‖ - ofera posibilitatea administratorului bazei de date a muzeului de a gestiona usor si rapid informatiile de contact ale muzeului ; 5. Fereastra ―Patrimony‖ - fereastra in care se realizeaza operatii de gestiune asupra artefactelor din patrimoniul muzeului; 6. Fereastra ―Schedule‖ - permite manipularea informatiilor privitoare la programul normal de functionare al muzeului; 7. Fereastra ―Staff ‖ - ofera functionalitatea gestionarii informatiilor stocate referitoare la personalul angajat al muzeului; 8. Fereastra ―Pricelist‖ -
permite manipularea datelor referitoare la preturile
biletelor de acces in muzeu pentru vizitatori;
46 P a g e
Fereastra “Log in”
Prin intermediul aceastei fereastre utilizatorul se poate autentifica utilizand butonul [Log in] sau poate accesa fereastra ―Account‖ pentru a-si crea un cont nou de utilizator folosind butonul [New Account]. Daca autentificarea este realizata cu success atunci aplicatia va deschide fereastra ―Main‖.
47 P a g e
Fereastra “Account”
Aceasta fereastra ofera unui utilizator nou posibilitatea de a se inregistra dupa ce completeaza toate campurile necesare. Daca informatiile introduse sunt valide, atunci folosind butonul [Create account] noul utilizator se poate inregistra cu success. Daca inregistrarea este efectuata cu success, atunci prin intermediul unor scripturi SQL se va crea o baza de date proprie noului utilizator care va contine urmatoarele tabele:
48 P a g e
tabela ―Patrimony‖ cu urmatoarea structura
Aceasta tabela contine informatiile despre toate artefactele care se regasesc in patrimonial muzeului. Codul sursa SQL utilizat pentru crearea tabelei intr-o baza de date ORACLE este disponibil in continuare:
CREATE TYPE Patrimony AS OBJECT ( Museum_piece char(50), Description char(80), Dating_year number) CREATE TABLE adminPatrimony OF Patrimony ALTER TABLE adminPatrimony ADD PRIMARY KEY (Museum_piece)
tabela ―Schedule‖ cu urmatoarea structura
49 P a g e
Aceasta tabela contine informatiile despre programul normal de lucru in care este deschis muzeul. Codul sursa SQL utilizat pentru crearea tabelei intr-o baza de date ORACLE este disponibil in continuare:
CREATE TYPE Schedule AS OBJECT ( Day char(20), Opening_time char(10), Closing_time char(10)) CREATE TABLE adminSchedule OF Schedule ALTER TABLE adminSchedule ADD PRIMARY KEY (Day)
tabela ―Pricelist ―Pricelist‖‖ cu urmatoarea structura
Aceasta tabela contine informatiile despre preturile biletelor pentru vizitatorii muzeului. Codul sursa SQL utilizat pentru crearea tabelei intr-o baza de date ORACLE este disponibil in continuare:
CREATE TYPE Pricelist AS OBJECT ( Person char(20), Price number) CREATE TABLE adminPricelist OF Pricelist ALTER TABLE adminPricelist ADD PRIMARY KEY (Person)
50 P a g e
tabela ―Staff‖ cu urmatoarea structura
Aceasta tabela contine informatiile despre personalul angajat al muzeului. Codul sursa SQL utilizat pentru crearea tabelei intr-o baza de date ORACLE este disponibil in continuare:
CREATE TYPE Staff AS OBJECT ( Nr_crt number, Position_job char(30), First_name char(30), Last_name char(30), Address char(80), Age number, Salary number, Hiring_date char(10)) CREATE TABLE adminStaff OF Staff ALTER TABLE adminStaff ADD PRIMARY KEY (Nr_crt)
51 P a g e
tabela ―Contact‖ cu urmatoarea structura
Aceasta tabela contine informatiile despre datele de contact ale muzeului disponibile pentru public. Codul sursa SQL utilizat pentru crearea tabelei intr-o baza de date ORACLE este disponibil in continuare:
CREATE TYPE Contact AS OBJECT ( Museum char(50), Address char(80), Telephone char(30), Fax char(30), Email char(50)) CREATE TABLE adminContact OF Contact ALTER TABLE adminContact ADD PRIMARY KEY (Museum)
52 P a g e
tabela ―Login‖ cu urmatoarea structura
Aceasta tabela este creata de catre administratorul central al aplicatiei (cel care distribuie aplicatia) atunci cand aplicatia este instalata. Acesta poate oferi sau nu dreptul noilor utilizatori de a utiliza sau nu functionalitatile aplicatiei. Codul sursa SQL utilizat pentru crearea tabelei intr-o baza de date ORACLE este disponibil in continuare:
CREATE TABLE Login ( username char(30) not null primary key, password char(30) not null, name char(30) not null, email char(50) not null, museum char(50) not null)
53 P a g e
Fereastra “ Main”
Reprezinta fereastra principal a aplicatiei. Prin intermediul acesteia utilizatorul poate gestiona si manipula toate fluxurile de date din si dinspre aplicatie.
54 P a g e
Fereastra “ Contact”
Prin intermediul acestei ferestre utilizatorul are posibilitatea de a accesa si manipula rapid si usor datele publice de contact ale muzeului.
55 P a g e
Fereastra “ Patrimony”
Prin intermediul acestei ferestre se ofera posibilitatea utilizatorului de a gestiona si manipula datele stocate referitoare la multimea tuturor artefactelor din patrimoniul muzeului.
56 P a g e
Fereastra “ Schedule”
Prin intermediul acestei ferestre utilizatorul are posibilitatea de a accesa si manipula rapid si usor datele referitoare la programul public de lucru al muzeului.
57 P a g e
Fereastra “ Staff ”
Prin intermediul acestei ferestre utilizatorul are posibilitatea de a accesa si manipula rapid si usor datele publice ale angajatilor muzeului.
58 P a g e
Fereastra “ Pricelist”
Prin intermediul acestei ferestre utilizatorul i se permite gestionarea si manipularea datelor cu privire la preturile biletelor de vizitare a muzeului.
59 P a g e
Capitolul IV. Concluzii Intr-o era a informatiei, abilitatea de a reactiona rapid si eficient la diferitele necesitati este cel mai important factor in orice domeniu de activitate al societatii. In acest caz, volumul si complexitatea informatiilor care se vehiculeaza pot fi covarsitoare, iar eficienta folosirii informatiilor depinde in cea mai mare masura de capacitatea de organizare a unui volum mare de date intr-un timp cat mai scurt. Am elaborat aceasta lucrare din nevoia de a facilita fluxul lucrarilor din interiorul unor institutii, in speta a celor din categoria muzeelor nationale, si pentru o mai buna monitorizare a modului de gestionare a datelor si informatiilor specific birotice. Pentru a putea tine o evidenta exacta a tuturor lucrarilor din institutie s-a implemetat un produs software cu ajutorul caruia sa se poata controla fluxul datelor. Acest sistem informatic va cuprinde doua fluxuri de date: 1. unul care va fi format din categoria documentatelor intrate in institutie; 2. si celalalt care va cuprinde toate cererile provenite din exterior si cele interne. Produsul software este destinat pentru a facilita si inlesni activitatea administratorilor unor muzee nationale. De asemenea, pe parcursul derularii prezentului proiect se va incerca obtinerea unui produs software care sa corespunda la un nivel cat mai inalt nevoilor si cerintelor administratorilor. Se va urmarii realizarea unui program birotic ce va oferii o functionalitate sporita . Planul de proiect care ofera o lista completa a scopurilor si obiectivelor lucrarii a fost urmatorul:
sa se identifice principalele sarcini de lucru ale administratorilor acestor institutii si sa se implementeze corect in proiectarea produsului software
sa se obtina o versiune perfect functionala a unui produs software care sa faciliteze lucrul cu cele doua fluxuri de documente, specifice acestor institutiilor
produsul software sa ofere garantia unui grad ridicat de confidentialitate a datelor
60 P a g e
Produsul software a fost implementat utilizand doua tehnologii informatice extreme de utilizate: -
tehnologia Oracle
- platforma .Net Framework Operatiile de stocare si
manipulare a fluxurilor de date din interiorul
institutiilor s-au implementat utilizand versiunea 9i a serverului de baze de date Oracle. De asemenea, produsul software final contine o interfata simpla, prietenoasa si usor de utilizat, view-ul aplicatiei fiind realizat utilizand platforma .Net Framework. Modul de programare utilizat in implementarea aplicatiei a fost cel orientat obiect pus la dispozitie de ambele tehnologii. In general, exista un grad mare de multumire fata de programul pe care l-am creat. Acesta atinge toate obiectivele cheie pe care le-am stabilit, si este capabil sa ofere un standard bun al functionalitatii. Exista cu siguranta loc pentru unele imbunatatiri, pe care le-am identificat in decursul implementarii proiectului, dar avand in vedere aspectul general al programului, simt ca am facut o treaba buna si ca tot ceea ce am stabilit inainte de a derula proiectul de fata am relizat in mare masura.
61 P a g e
Capitolul V. Referinte
5.1 Referinte WEB 1. http://docs.oracle.com/cd/B10501_01/server.920/a96540/toc.htm 2. http://asktom.oracle.com 3. http://msdn.microsoft.com/en-us/library/dd264728.aspx 4. http://msdn.microsoft.com/enus/library/system.data.oledb.oledbconnection%28v=vs.71%29.aspx
5.2 Referinte literare 5. Trezzo, C.J. – Oracle PL/SQL. Tips & Techniques, McGrawHill, Osborne, 2002. 6. Mansaf ALAM, Siri Krishan WASAN - Migration from Relational Database into Object Oriented Database, revista Journal of Computer Science, nr. 2(10)/2006, pag. 781-784, ISSN 1549-3636. 7. Adkoli, Anand; Rama Velpuri (2002) - Oracle9i for Windows handbook . Oracle Press Series (2 ed.). McGraw-Hill Professional. p. 375. ISBN 978-0-07-219092-2. 8. Abbey, M., Corey, M., Abramson, I. – Oracle9i Notions Fondamentales, Oracle Press, Campus Press, 2002. 9. Feuerstein, S. – Oracle PL/SQL Programming , 3rd edition, O’Reilly & Associates, 2002. 10.Box, Don, with Chris Sells - Essential .NET, Volume 1: The Common Language Runtime, Boston, MA: Addison-Wesley, 2003.
62 P a g e
