APOO Curs 1 20 martie 2007 20:57
1. Parcurgerea in cascada (waterflow) Dezavantaje: - Necesitatea reluarii complete in cazul unor defecte majore. - Poate conduce la cresterea timpului de realizare - Este un risc foarte mare.
Analiza Proiectarea Implementare Testare
Pentru scaderea riscului s‐au gandit tot felul de alte combinatii pt parcurgerea etapelor de dezvoltare.
2. Parcurgerea in spirala ‐abordare pe versiuni ‐se parcurg intrun mod care le lasa incomplete ‐vor fi completate la o noua trecere ‐versiunile incomplete reprezinta bazele dezvoltarii urmatorului nivel de parcurgere ‐o astfel de abordare scade riscul de a avea timp mare de realizare (risc de piata) ‐pe parcurs se pot insusii tehnici noi
Analiza
Testare
Proiectare
Implementare
2. Parcurgerea incrementala (incremental) ‐modelul: RUP ‐> Rational unified process(proces de realizare unficata) (folosind toolsetul Relational Rod)
Faze:
Intiere(Inception)
Elaborare
Constructie
Iteratii: ‐Fiecare faza poate contine mai multe iteratii(un numar oarecare) ‐Fiecare iteratie contine toate cele 4 etape prezentate mai sus
Faza de initiere ‐definirea scopului proiectului Faza de elaborare ‐stabileste modul de abordare (obiect orientata sau component orientata) ‐se incearca limitarea(excluderea) zonelor de risc Faza de constructie ‐proiectarea detaliata si implementarea aplicatiei Faza de migratie ‐accentul se pune pe trecerea de la produsul in stare de prototip la inglobarea la utilizator. Accentul se pune pe testare
APOO Curs Page 1
Migrare
Analiza si proiectarea Obiect Orientata ca modalitate de sistematizare a dezvoltarii software - Modelul obiect : ○ ‐permite dezvoltarea aplicatiilor ‐> colectii de clase si obiecte ○ ‐obiectele colaboareaza intre ele ‐> sunt instante ale claselor ○ ‐clasele sunt membre ale unei ierarhii de clase (prin mostenire) Modelul obiect constituie o viziune integratoare in proiectarea mai multor sisteme(hardware, arhitectura, etc). Acest lucru contine o unificare a caracteristicilor.
Caracteristici fundamentale: 1. Abstractizarea i. Nu este proprie numai modelului obiect dar este obligatorie pt modelul obiect. ii. Prin abstractizare se definesc clasele ‐ >tipuri de date (tipuri abstracte) ‐>fiecare clasa inglobeaza atributele cele mai relevante 2. Modularitate i. Abordarea prin care aplicatia se imparte in module 1) Modulele trebuie sa fie "slab cuplate" ii. In OO modulele contin clase si obiecte iii. Nu este specifica OO dar (obligatorie) recomandabila 3. Mostenirea i. Proprietatea prin care se pot definii ierarhii de clase 1) Clase de baza 2) Clase derivate ii. Se poate face prin 2 procese: 1) Specializare ‐ pornind de la o clasa de baza si definind clase specializate ‐>mostenesc caractere generale din clasa de baza si au si propriul lor specific 2) Generalizare ‐ pronind de la mai multe clase oarecum corelate(indrudite) se extrag caracteristicile comune ‐> se folosesc pt a definii o clasa de baza 4. Incapsularea si ascunderea implementarii i. Asigura ca o clasa sa fie impartita in 2 parti 1) Structura a) Multimea atributelor (date membre ale clasei) b) Implementarea metodelor 2) Comportarea ‐ data de ceea ce se numeste interfata clasei‐>asigura legatura cu ext. Multimea metodelor publice ale clasei ‐ prototipurile ii. Permite reutilizarea codului iii. Permite modificari independente in diferitele module Exmeplu: Class punct{ Float x; // datele membre sa fie de tip private Float y; Public: Punct(float a, float b); // constructor Float getx();// Float gety();// Void setx(float Void sety(float
functii de tip getter citesc variabile private (f selector) a);// modifica valuarea datelor membre b);// f modificator sau de tip setter
APOO Curs Page 2
Void translate(folat a, float b); } Punct::Punct(float a, float b)//constructor { X = a; y = b; } Puncg::getx(){ Return x; } iv. Fiecare obiect = instanta unei clase reprezinta o colectie de valori ale atributelor clasei (general) v. Se comporta in moduri diferite in functie de tipul de abordare al programarii 1) Programare procedurala ‐ dificil de implementat 2) Programarea OO ‐ incapsularea este recomandata si limbajele ofera suport pt aceasta proprietat (nerespectarea este posibila dar pot sa apara probleme de siguranta a utilizarii obiectelor). 3) Programarea orientata pe componente ‐ incapsularea este obligatorie Tehnologiile de componente soft te obliga sa ai separatie completa intre interfata si implementare
Caracteristici secundare: 1. Tipizarea = regulile prin care se pot combina sau de conversii intre diferite tipuri de date dintr‐un limbaj i. Slab tipizate: smaltalk ( C )‐ permit orice fel de combinatii intre obiecte. ii. Puternic tipizate: Eifel, Java, C# iii. Mediu tipizat: C++ 2. Persistenta = capacitatea de stocare permanenta a datelor create intr‐un program. Exista posibilitatea ca aceste date sa supravietuiasca programului. Serializare 3. Concurenta = se intelege posibilitatea de executie concomitenta(simultana) a mai multor obiecte din aceeasi clasa sau clase diferite. Are loc numai daca avem deaface cu un calculator paralel sau sistem distribuit (reala). (simulata : threaduri).
APOO Curs Page 3
APOO Curs 2 20 martie 2007 20:55
Caracteristicile modelului obiect 1. Caracteristici fundamentale a. Abstractizarea b. Modularitatea c. Mostenirea d. Incapsularea
Clase: - Structura: date modul+impl. Modul - Comportarea: interfata = met de protectie, functii public
Fiecare obiect = instanta a clasei ‐ obiecte cu valoare de atribut a clasei?? Principiul incapsularii si al ascunderii implementarii se compolrta in moduri diferite in functie de tipul de abordare al programarii: - Pentru programarea procedurala, aceasta proprietate este dificil de implementat - Pentru programarea OO, incapsularea este recomandata si limbajele OO ofera suport pentru aceasta proprietate (specificatori diferiti, date separate, etc.) ○ Nerespectarea acestei proprietati este posibila dar pot sa apara probleme de siguranta a utilizarii obiectielor. - Progamarea orientata pe componente ‐ incapsularea este obligatorie ○ Tehnologiile de componente software te obliga sa ai separatie completa intre interfata si implementare 2. Caracteristici secundare ‐ model obiect: a. Tipizarea ‐ se refera la regulile prin care se pot combina in expresii sau de conversii intre diferite tipuri de date dintr‐un limbaj ‐ modul de conversie e precizat prin caracteristicile de tipizare (tipizarea se refera la tipui, tipurile=clase => tipzarea se refera la clase) i. Limbaje slab tipizate : Smaltalk care permite orice fel de combinatii intre obiecte (programatorul trebuie sa aiba grija) ii. Limbaje putrenic tipizate:Eifell, Java, C# iii. Limbaje mediu tipizate: C++ b. Persistenta = capacitatea de stocare permanenta a datelor creeate intr‐un program ‐ datele creeate intr‐un program sa supravietuiasca programului;"serializatea datelor"=datele sunt transformate in secvente de octeti, sunt scrise si raman acolo cand se termina programul. La o noua executie ele pot fi utilizate. c. Concurenta relativa la modelul OO = posibilitatea de executie concomitenta a mai multor obiecte din aceeasi clasa sau clase diferite. Concurenta apare la calcualtoare paralele sau sisteme distribuite.
Analiza, proiectarea, programarea Obiect Orientata Aplicarea proprietatiilor si a conceptelor modelului obiect in aceste etape de dezvoltarea software. 1. Analiza OO a. Analiza cerintelor respecta principiul general de abstractizare: i. principiul prin care se slecteaza caracteristicile relevante ale realitatii modelate ii. Identificarea claselor care vor constituii programul Entitatile ‐> tip de entitate <‐ clasa O entitate reprezinta orice exista in realitatea modelata Multimea entitatilor de acelas tip reprezinta multimea obiectelor instante ale clasei respective;
APOO Curs Page 4
2. Proiectare OO a. Detalierea claselor, obiectelor si legaturilor dintre acestea pe baza cerintelor stabilite in faza de analiza b. Se stabilesc modulele proiectului intr‐o abordare; Intr‐o abordare OO, un modul este o colectie de clase c. Se stabilesc tehnologiile de realizare ‐> platforma, SO, hardware, limbaje si alte standarde (biblioteci, etc.) 3. Implementarea OO (programarea) a. Programarea ‐ foloseste un limbaj OO ‐ toolseturi, biblioteci b. Se scriu programele 4. Testarea OO ‐ se folosesc clase gata testate din biblioteci
Avantajele abordarii obiect orientate a dezvoltarii softwareului 1) Reutilizabilitate codului ‐ se folosesc biblioteci de clase 2) Extensibilitatea codului ‐ se folosesc clase derivate din clasele din bilioteci 3) Mentenanta aplicatiilor obiect orientate = intretinerea bunei functionari a aplicatiilor e mai simpla in OO din 2 motive: a. Existenta incapsularii ‐ accesarea inmod unitar prin interfata a obiectelor b. Se impun mecanisme de tratare a exceptiilor mai precise decat in alte limbaje Limitarile abordarii OO 1. La inceput se credea ca OO va rezolva problema reutilizabilitatii codului. In realitatea avem doar o reutilizabilitate limitate a codului. a. S‐a constatat ca totusi clasele sunt prea mici si prea speciale b. Biblioteci de uz general au functionalitate limitata. MFC (Microsoft Foundation Clases) a reprezentat baza dezvoltarii programelor Windows in C++. 2. Interoperabilitatea limitata; interoperabilitate = posibilitatea de a opera impreuna a diferitelor clase si obiecte. Ea este limitata datorita faptului ca bibliotecile sunt cu destinatii limitate la randul lor. Ex: clasele si pakageurile java comunica greu cu clasele C++. Tendintele de dezvoltare software Scop: Eliminarea (micsoararea) limitarilor OO. - Software orientat pe componente ○ beneficiaza de standarde generale care permit obtinerea Reutilizabilitatii ‐ ea creste datorita faptului ca componentele sunt mai mari decat clasele Interoperabilitatii ‐ creste datorita standardelor impuse si datorita faptului ca orice componenta contine o interfata. Ea poate fii folosita deci mai comod in programare.
Dezvoltarea programelor folosind modelare UML - Modul de dezvoltare soft; se folosec modele (concepte care sintetizeaza abstractizare din realitate pentru un anumit scop si o anumita utilizare). Modelele se pot dezvolta in limbaje de modelare - Anii 1990 ‐ zeci de limbaje diferite, fiecare propunand un anumit mod de reprezentare a programelor. - Unificarea prin standardizare a proiectarii soft a fost o cerinta inerenta
In anul 1995 3 cercetatori au unificat cele 3 limbaje definite de ei - Grady Bookh ‐ 1994 Object Oriented Analisys and Design ‐ limbaj G.B - James Rumbourgh ‐ OMT (Object Modeling Tehnology) - Ivan Jacobson ‐ OOSE (Object Oriented modeling language)
APOO Curs Page 5
¾ ¾ ¾ ¾
In 1997 limbajul UML a fost preluat de OMG (Object Management Group) (www.omg.org) si au dat primul standard si specificare UML 1.1. Actualmente s‐a ajuns la versiunea 2.1.1 Limbajul UML Este un limbaj pentru dezvoltare, specificare, documentare si vizualizare a produselor software. UML este un limbaj grafic; elementele sale sunt elemete de grafica 2D si aceste elemente sunt procedee care specifica diversele aspecte ale produsului software. Toate elementele sunt insotite de texte Limbajul UML trebuie sa ajute dezvoltatorii sa il foloseasca si deci defineste concepte ale limbajului, semantica (intelesul diverselor elemente), precizeaza notatii (ex: conceptul de clasificator se noteaza asa...) si de asemenea ofera solutii sau recomandari de proiectare (pattern‐uri, tipare)
Caracteristicile limbajului UML Limbajul uml inseamna UNIFICARE+FLEXIBILITATE ¾ Unificarea in modalitatile de dezvoltare software ○ Integreaza cele mai bune practici. ○ Integrarea continua prin adaugarea la diferitele revizii a uno aspecte noi de proiectare software. Ex: ulterior s‐au inglobat componentele software. ¾ Foloseste modelul obiect ca baza a abordarii proiectarii software. ○ Poate fi utilizat si in alte abordari deoarece conceptele pe care le defineste au un caracter mai general decat modelul obiect. ¾ Limbajul foloseste tipuri de date (incluse in elemetele grafice) ‐ independente de limbajele de programare existenta (Defineste Real sau Integer fara sa faca o precizare stricta a legaturii cu aceste tipuri din limbajele de programare existente. Admite si tipuri ale limbajelor ‐ FLEXIBILITATE). Flexibilitatea este si mai puternic relevata de faptul ca limbajul UML oferea o multitudine de vederi ale sistemului software (views). Aceleasi sistem poate fii privit din mai multe puncte de vedere, aspecte modelate si apoi dezvoltate. ○ Sistemele software complexe nu pot sa fie reprezentate si necesita: Specificari; fiecare specificare corespunde unui aspect si fiecare aspect mai multor vederi Colaborarea mai multor categorii de personal □ Analisti □ Proiectanti
- Diagramelor de functionare (use‐case). Acestea au fost preluate din OOSE al lui Jacobson ‐ servesc managerilor - Diagramele fizice Diagrame ale componentelor Diagrame de deployment ‐ se refera la instalarea diverselor parti (deployment ?= desfasurare) - Diagrame de organizare a sistemului software Diagrame de pachete Diagrame de subsisteme Diagrame ale modelelor Fiecare categorie de personal de dezvoltare foloseste diferite vederi (diagrame) in functie de atributile fiecaruia ¾ Limbajul UML ofera posibilitatea definirii pe diferite grade de detaliere. - Acelasi element poate sa fie reprezentat in mai multe moduri de la foarte general pana la foarte detaliat. - Limbajul UML poate fi folosit in toate etapene de dezvoltare. In faza de analiza avem elemente reprezentate simplificat ajungand in fazele de testare si implementare pana la reprezentarea detaliata a aceluias element Pentru limbajul UML s‐au dezvoltat numeoase toolseturi in functie de necesitati si specificatii. Important este ca un toolset nu respecta intru totul specificatiile standard ale limbajului.
APOO Curs Page 6
APOO Curs 3 13 martie 2007 10:05
Modelarea structurala Structura se refera la partile componente ale unui sistem; arhitectura unui sisteme se refera la partile componente si legaturile(interfata) dintre ele. - Reprezentarea structurala a unui sistem software ‐ partile componente - Diagrama claselor si diagrama obiectelor. 1) Diagrama claselor este un model structural al unui sistem i. Este reprezentat printr‐un graf □ In noduri avem clase □ Arcele reprezinta legaturile UML ii. Capteaza informatii statice ale modelului. 2) Diagrama obiectelor: i. sunt reprezentate obiectele in UML. Obiectele sunt instante ale claselor. ii. Este o reprezentare la unmoment dat (obiectele au comportare dinamica) iii. Utilitate restransa OBS: 1. Se pot combina cele 2 tipuri de diagrame! (clase+obiecte). Reprezentarea se face in functie de necesitati. 2. Mai exista si alte diagrame structurale: diagrama componenteleor (sotfware) Elementele structurale ale diagramei claselor In UML, un clasificator (classifier) este un element structural care reprezinta un concept de modelare care reuneste elemente de structura, elemente de comportare si elemente semantice. Exista mai multe categorii de clasificatori: - Clasa (class) - Tip de date (type) - Interfata O clasa in UML reprezinta o multime de elemente de aceealsi tip care sunt caracterizate prin structura data de atribute, comportarea data prin metode si pentru care se poate identifica un inteles precis (caracterul semantic) UML Class atribut
OO Class atribut
Principiul incapsulaii transforma clasa in structura cu atribute+implementare si comportare data de atributele metodelor publice ‐ interfata clasei. O clasa in def din UML corespunde unei clase din OO. Ea corespunde unui tip de entitate sau unei multimi de entitiati. Atributul entitatii corespunde atributului din UML. Desi definitile UML sunt mai generale, in anumite situatii se observa o foarte buna echivalare cu notiunile cunoscute din programarea OO. Reprezentarea in UML: - 3 compartimente ale unui dreptunghi Numele clasei + alte specificatii (compartiment obligatoriu) □ Numele clasei (obligatoriu) □ Un stereotip
APOO Curs Page 7
□ Constrangerile Persoana (stereotipul si constrangerile sunt facultative) Compartimetul de atribute (optional) ‐Nume:String □ Nume atribut ‐ tip atribut: ‐Varsta:integer Tip generic (UML) ‐adresa:string Specific limbajelor OO □ Indicator de vizibilitate +Set nume:void □ "+" ‐ public +Get nume:string □ "‐" ‐ private □ "#" ‐ protected Compartimentul de metode (optional) □ Nume metoda (obligatoriu) □ Indice vizibilitate Stereotip pt structura □ Tip returnat - Clasa reprezinta forma implicita a unui clasificator - Type si interfata necesita stereotipuri de precizare a clasificatorului. - Interfata este o colectie de metode (3 modalitati de reprezentare) <> Itranzaction
Itranzaction +begin():void +commit():void +abort():void <>
Persoana
Persoana
+set Nume:string legatura
Nota
<> Dimensiune
Itranzaction Componente software
O componenta software in UML e o extindere a clasificatorilor Pentru clase mai apar si constrangeri
Forma {abstract]
Clasa abstracta
2. Clase parametrizate (clase template). O clasa template e o clasa care defineste o comportare unica pentru tipuri diferite de date. Tipul datei este un parametru. In cazul stivei, tipul LIFO reprezinta un parametru: Tstiva
E
‐element[n]:E ‐dim:integer ‐poz:integer +push():void +pop():E
Clasificatorii cu diversele constrangeri reprezinta elemente de structura din diagrama structurala. Elemente de legatura (din diagrama claselor) - Este un element care realizeaza o corespondenta (legatura) intre clasificatori si alte elemente) - Elementrul se repreznta prin unul sau mai multe segmente de dreapta + diferite marcaje (acestea depind de tipul legaturii): ○ Linie intrerupta ○ Sageti ○ Diverse texte pe linie sau la capete - Tipuri de legaturi UML: ○ Generalizarea (generalization) ○ Asocierea (asociation) ○ Depndentele (dependecies) ○ Alte legaturi
APOO Curs Page 8
1. Generalizarea: - Este legatura dintre 2 clasificatori in care un clasificator numit fiu mosteneste caracteristicile clasificatorului numit parinte si adauga noi caractere specifice acestuia. Generalizarea este deci legata de MOSTENIRE. vehicul
automobil
tractor
bicicleta generalizare
Reprezentarea legaturii:
Sageata continua
Se pot definii ierarhii de clase pe oricate niveluri.
- Se poate definii o ierarhie printr‐un procedeu invers (prin specializare). Specializarea e operatia inversa prin care se pleaca de la o clasa cu caracter general si se merge spre clase mai specializate (exista suport in limbajele OO pentru mostenire si deci nu se mai fac specificari in UML) 2. Legatura de asociere - Prin asociere se realizeaza corespondente(legaturi) intre elementele diferitilor clasificatori. In UML un obiect este o instanta a unei clase (clasificator). Nu exista suport specific pentru asociere in limbajele OO. Se folosesc diferite mecanisme care sa asigure asocierea. Clasificari ale asocierilor: I. Din punct de vedere al numarului de clase (clasificatori) pusi in corespondenta: a. 2 clasificatori ‐ asocieri binare b. >2 clasificatori ‐ asocieri multiple; n‐are ‐> pot fi restranse in asocieri binare II. Din punct de vedere al raportului de cardinalitate III. Din punct de vedere semantic (al intelesului). Din punct de vedere semantic exista: a. Asocieri simple b. Asocieri de tip parte intreg (intreg parte ??)
II. Clasificarea din punct de vedere al raportului de cardinalitate 1) Asocieri de tip unul la unu 1:1. Ele reprezinta asocierea prin care unui element din prima multime ii corespunde un singur element din a 2‐a multimea. 2) Asocierea unul la mai multi 1:N. Asocierea prin care unui elem din prima multime ii corespund mai multe elemente din a 2‐a multime dar nu si invers 3) Asocierea multi la multi
APOO Curs Page 9
x x x
y y y
1:1
x
y y y y
1:N
y y y y
M:N
x
x x x
Prin cardinalitate sau multiplicitate se intelege numarul de elemente a unei asocieri fata de unul din clasificatori (sau multime de elemente) este egala cu numarul de elemente din acel clasificator care pot fii legate la un element din celalalat clasificator Raportul de multiplicitate ‐ criteriu de clasificare. - Asocierile multiple se reprezinta prin mai multe rapoarte de cardinalitate sau de multiplicitate. - Reprezentarea asocierilor: asocierile in uml se reprezinta prin unul sau mai multe segmente contiunue, intre clasificator (asocieri binare)
Rol numeasoc rol
Class 1
0...1 1...*
Class 2
Marcaje pe asocierile binare UML a. Numele asocierii (facultativ) b. Multiplicitatile fata de fiecare clasificator. Se scriu la capatul liniei. Conceptul am avut 1:1, 1:N, M:N; In UML: i. min...max 0 1 1 val c. Rol ‐ rolul clasificatorului in asocierea respectiva (se reprezinta tot la capete) d. Navigabilitatea ‐ posibilitatea de a ajunge de la un element dintr‐o clasa in cealalata. Ea poate sa fie unidirectionala si se reprezinta cu o sageata. Ea poate sa fie bidirectionala sau neprecizata. Exemple de asociere: a) 1:N (generic) Intreprindere
Angajator angajari angajat
1...1 1...*
APOO Curs Page 10
Persoana
Daca se impune conditia ca o persoana sa lucreze intr‐o singura inntreprindere ‐ asocierea este 1:N. Se pot da mai multe variante de multiplicitate in functie de diferitele precizari ale modelului
b) M:N
Profesor
Student * * 1...10 1...1000
c) Asocierile multiple. Ele se reprezinta folosind un romb cu linii
Clasificarea din punct de vedere semantic a asocierilor: 1) Asocieri simple = asocieri in care elementele asociate au existenta proprie, independent de asociere si de elementele din clasificatorul cu care are loc asocierea. 2) Asocierile de tip intreg‐parte sunt asocierile (in general binare) in care exista un clasificator cu rol de intreg si unul sau mai multi clasificatori cu rol de parte (parti) [general]. Pot exista si 2 sau mai multi clasificatori intreg fiecare cu 2 sau mai multi clasificatori de tip parte. a. Asocieri de tip compozitie b. Asocieri de tip agregare
APOO Curs Page 11
APOO Curs 4 20 martie 2007 10:20
Legaturi de asociere - Au abordari mai putin fixe (precizate) (fiecare limbaj are toolset‐uri proprii - La nivel UML avem asocieri ○ Simple ○ Tip intreg‐parte Rapoarte de multiplicitate: 1:1; 1:N; M:N; I ‐ asocieri simple ‐> clasificator e de sine statator; pot exista asocieri; este cea mai slaba in sensul legaturii care exista intre cei 2 clasificatori I. Asocierea de tip intreg‐parte a. Compozitie b. Agregare - Legaturi intre clasificatori dintre care un clasificator are rolul de intreg (exprima o entitate complexa) si una sau mai multe entitati complexe care reprezinta parti ale intregului - Pot avea unul sau mai multi clasificatori cu rol de intreg 1) Compozitie ‐> are urmatoarele caracteristici: a. Obiectul de tip intreg este compus din obiecte de tip parte b. De regula obiectul de tip intreg nu poate exista fara obiectele de tip parte c. (de regula) un obiect parte apartine unui singur obiect intreg (la un moment dat) d. Este (in general) heterogena (exista clasificatori diferiti ca parti ce intra in combinatie pentru a forma intregul) Reprezentare UML Masina
Club 0...*
1 1 4 Caroserie Motor Roata
0...* Persoana M:N
Legatura de compozitie este cea mai puternica legatura de asociere din cele existente. 2) Legatura de agregare - Este legatura care stabileste corespondenta intre grupuri de instante ale clasificatorilor asociati. - Clasificatori care reprezinta: ○ Grup ○ Membrii ai grupurilor - Caracteristici: ○ Este de regula de tipul M:N dar poate fii si 1:N (caz particular) ○ O instanta a clasificatorului grup care reprezinta un intreg poate exista si fara membrii sai. ○ O instanta a clasificatorului poate fii asociata mai multor grupuri ○ Legatura este de regula omogena.
APOO Curs Page 12
Padure 1
0...* Copac 1:N
Clasificarea unei asocieri ‐‐‐> depinde de interpretarea data de dezvoltator
Legaturile de dependenta - Dependentele pot sa fie de mai multe feluri. Ea este legatura prin care un clasificator numit client depinde de un alt clasificator numit target (supplier)
Client Furnizor
uses Clasa1 Clasa 2 Tipuri de dependenta: 1) Legatura de utilizare (stereotip <>) a. Folosim obiecte din clasa furnizor in implementari de metode b. In argumente ale metodei clasei client 2) Legaturi de coeziune. a. Clasificatorul template ‐> clasificatorul tipului de date folosit tip Cl. Template
Cl. Tip <=>
Template
3) Legatura de trasare (stereotip <>) a. Intre clasificatori care reprezinta acelasi concept pe niveluri de dezvoltare diferite Preprezinta evolutia soft din punct de vedere al versiunii 4) Legatura rafine (stereotip <>) 5) Legatura de realizare. Ea se refera la faptul ca un anumit concept este specificat prin intremediul altui concept sau instanta. a. Poate fii legatura intre interfata si clasa b. Poate fii legatura de instantiere inre clasa si obiectul din acea clasa Reprezentare aleternativa: <>
<> Interfata 1
<> Cl
d
ifi APOO Curs Page 13
Clasa 1
Interfata 1 <> Clasa de specificare Clasa de specificare
Obiect 1
Obiecte si diagrame ale obiectelor Punct ‐x:float ‐y:float
- In UML, un obiect este o instanta a unei clase - Reprezentare:
‐getx():float ...
P1:Punct x:float = 1 y:float = 1
Diagrama obiectelor: - Graf, obiecte la un moment dat - Legaturile dintre obiecte: instante ale legaturii din clasele instantiate Diagrama obiectelor este considerata un snapshot. De cele mai multe ori ea este inlocuita cu alte diagrame. Ex:
Profesor Student
p1
s1
p2
s2
p3
s3
Diagrama obiectelor poate contine si clase! Exemplu ‐ diagrama claselor. (Ele nu trebuie sa fie detaliate)
APOO Curs Page 14
1 P1
*
Cerc
-End9 -End10
Class1
* -End12 1 1
Class2
*
S1
-End11 -End13
-End14
Implementarea claselor si a legaturilor dintre elemente - Scrierea programului intr‐un limbaj obiect orientat. - Detalierea diagramelor UML I. Scrierea programelor ‐ implementarea aplicatiilor soft in modelul OO pornind de la UML 1) Implementarea claselor: Class(UML) ‐‐‐> class(OO) <> ‐‐‐‐> in functie de limbaj unei interfete ii corespunde tot o clasa sau tipul interface 2) Implementarea legaturilor ditre clase. a. Legatura de generalizatedevine legatura de mostenire in limbaje OO Class Culoare{ Int r; Int g; Int b; Public:...}; Class punct{ Float x; Float y; Public:....}; Class forma{ //clasa abstracta deoarece contine functii virtuale pure Culoare culoare; .... Public: Virtual float aria()=0; Virtual float perimetru()=0; //functii virtuale pure Class cerc:public forma{ Punct centru; Float raza; Public: Int intersectie(segment s); ..... }; Class segment:public forma{ Punct p1;
APOO Curs Page 15
Punct p2; Public:.... }; Class poligon:public forma{ Punct varfuri [max]; Int nr_varfuri; Public:.... };
b. Implementarea legaturilor de asociere i. Asocierile de compozitie ‐ compunerea claselor 1) Variabile de tipul clasei "parte" a) Obiecte incluse in clasa intreg b) Pointeri sau referinte la obiecte din clasa parte: in Java sunt numai referinte, in C# de regula referinte iar in C++ putem avea ambele Diagrama claselor mai detaliate (in etapa de implementare)
APOO Curs Page 16
APOO Curs 5 27 martie 2007 10:08
Implementarea claselor (UML) si a legaturilor dintre acestea Clasa(UML) ‐‐‐‐> clasa in limbaj OO Legaturile dintre clase: - Generalizarea (UML) ‐‐‐‐>clase derivate in limbaje OO - Asocierea (UML) Compozitia ‐‐‐‐> obiecte ca date membre de clase sau referinte la obiecte Simpla, de agregare □ Variabile de asociere □ Clase de asociere I. Variabile de asociere Ex:
#define max 100 Class Student; Class Profesor{ Char *nume; Student *lista_studenti[max]; Int nr_studenti; //ultimele 2 informatii reprezinta variabila de asociere care poate fii o lista //inlantuita sau o alta structura de date cu o asemenea legatura. Variabila se //numeste variabila de asociere public: Profesor (char *n){ New char[strlen(n)+1}; strcopy (nume, n); nr_studenti=0; } void addStudent(Student *s){ //presupunem ca lista este de tipul LIFO; presupunem ca nr_studenti este //prima locatie libera if(nr_studenti0){ nr_studenti.... } else{tratare eroare depasire} } Class Student{ Char *nume; Profesor *lista_profesori[max]; //pot fii si referinte Int nr_profesori; //Variabila de asociere care permite directia de navigabilitate student ----> //profesor public: Student(char *n){ nume=new char[strlen(n)+1]; strcopy(nume,n); nr_profesori=0; } //functii de asociere void add_Profesor(Profesor *p){ if(nr_profesor
APOO Curs Page 17
Profesor *getProfesor() if (nr_profesori>0){ nr_profesori--; return lista_profesori; } else{.........} } int main(){ profesor *p1=new Profesor("prof1"); profesor *p2=new Profesor("prof2"); profesor *p3=new Profesor("prof3"); Student *s1=new Student("stud1"); Student *s2=new Student("stud2"); Student *s3=new Student("stud3"); Student *s4=new Student("stud4"); //Obiectele sunt de sine statatoare; Asocierea se face folosind diverse metore ale //claselor
-End4 s1 : Student -End3 p1 : Profesor
*
-End7
p2 : Profesor
-End5 *
-End6
*
-End10
-End9
*
-End11
*
*
-End12
*
-End14 -End8
-End13 p3 : Profesor
*
-End15 *
s2 : Student
s3 : Student
* ** -End16
*
s4 : Student *
Fiecare legatura este creeata de addStudent si addProfesor la fiecare obiect in parte OBS: Exemplul de mai sus reprezinta o asociere simpla M:N bidirectionala. Faptul ca e asociere simpla nu difera de situatia in care am avea o agregare. Directionalitatea asocierii ‐‐‐‐> daca este bidirectionala avem variabile de asociere in ambele clase. Daca este unidirectionala, atunci avem nevoie de o variabila de asociere numai in clasa de origine a sagetii de navigabilitate.
Variabilele de asociere sunt de regula vectori de pointeri la clasa asociata (sau referinte). Putem avea liste inlantuite sau orice alte structuri. Din punct e vedere al raportului de multiplicitate: a) M:N ‐‐‐‐> se folosesc vectori de pointeri in ambele clase (exemplul dat) b) 1:N ‐‐‐‐> in clasa care are coeficientul de multiplicitate 1 avem un vector de pointeri si in a 2‐a clasa avem un pointer simplu.
class Sectie;
APOO Curs Page 18
class Angajat{ char *nume; Sectie *s; .... }; class Sectie{ char *nume; Angajati *lista_angajati[max] int nr_angajati; .... };
c) 1:1 ‐‐‐‐> variabilele de asociere sunt pointeri
Clase de asociere - Se folosesc in general pentru M:N
Implementare: #define max 100 class Profesor{ char *nume; public:.... } class Student{ char *nume; public:.... } struct PS{ pointer *Profesor; pointer *Student; PS(Profesor *p1, Student *s1){ p=p1; s=s1; } }; class APS{ //clasa de asociere PS asocieri[max];//existenta a mai multor pointei pe fiecare element permite //accesul sau din mai multe directii int nr_asocieri; public: //functii de asociere propriu-zisa APS(){nr_asocieri=0;) void addPS(PS i); PS getPS(); } int main(){ profesor p1=new profesor("prof1"); student s1=new student("stud1"); student s2=new student("stud2"); student s3=new student("stud3"); student s4=new student("stud4"); PS ps11(p1,s1); asocieri.addPS(ps11); PS ps12(p1,s2);
APOO Curs Page 19
asocieri.addPS(ps12); .... return 0; }
Mostenirea asocierilor Cl Baza1
Cl Baza2 *
*
Deriv1
Deriv2 *
*
Clasele derivate mostenesc variabilele de asociere, metodele de adaugare a instantelor Ex: class Profesor{ //cu var de asocirere }; class Student{ //cu var de asociere }; class ProfesorInvitat:public Profesor{ char *univ_de_unde_vine; public: ProfesorInvitat (char *nume, char *u):Profesor(nume){ univ_de_unde_vine=new char[strlen(u)+1; strcopy(univ_de_unde_vine, u); }; } class StudentBursier:public Student{ float *bursa; public: StudentBursier(char *n, float b):Student(n){bursa=b;); } //in clasele derivate nu avem variabile de asociere.
ProfesorInvitat *p1=new ProfesorInvitat("prof1", "Univ1"); ProfesorInvitat *p2=new ProfesorInvitat("prof2", "Univ2"); StudentNursier *s1=new StudentBursier("stud1", 1000); StudentNursier *s2=new StudentBursier("stud2", 1200); //asocierea dintre student bursier si profesor invitat este o asociere mostenita.Nu //ameplam nici o alta functie pentru a o implementa. // p1 ----> addStudent(s1); // s1 ----> addProfesor(p1); . . . . }
Mostenirea+asocierile constituie un mecanism foarte putrenic de reutilizare a datelor in programarea obiect orientata. Alt exemplu: MFC: CDocument
CView 0..1
0..*
CMyDoc
CMyView 0..1
0..*
APOO Curs Page 20
CDocument
CView 0..1
0..*
CMyDoc
CMyView 0..1
0..*
Este implementata prin variabile si functii de asociere. Asocierea intre CMyDoc si CMyView este mostenita. Implementarea legaturilor de dependenta. 1) Legatura de rafinare (<>) ‐‐‐‐> nu se implementeaza intr‐un mod specific (no code); 2) Legatura de trasare (<< trace>>) ‐‐‐‐> nu se implementeaza nici ea (no code); 3) Legatura de conectare (<>) ‐‐‐‐> se implementeaza prin clasele template; template class Tvector{.........};
4) Legatura de realizare a) Instantierea obiectelor ‐‐‐‐> Class1
Object1
class X{...}; class X obx;
b) Legatura de realizarea a unei interfete de catre o clasa «interface» Interfata1 «uses»
ClasaY
Implementare Java: Interface clasay implements interfata{....}; C++: pt metoda: clasa abstracta - mostenire :-??
5) Legatura de utilizare a) un ob dintr‐o clasa este folosit in alta clasa in functie de argument class Cerc: public Forma{ . . . } public: int intersectie(Segment s){ float panta=s.getPanta(); } }; Punct
1 Cerc
*
*
1 Segment
APOO Curs Page 21
Punct
1 Cerc
*
*
1 Segment
Observatie: Pana acum am studiat diagrame ale claselor si obiectelor. Aceste diagrame sunt statice si reprezinta structura modelului (la nivel foarte detaliat) Ulterior vom intalnii si alte diagrame de sctructura pe niveluri mai inalte - diagrame de componente - diagrame ale sistemeor si subsistemelor - diagrame ale pachetelor
APOO Curs Page 22
APOO Curs 6 3 aprilie 2007 10:01
Modelarea comportamentala (behaveior) a sistemelor. - O alta vedere asupra sistemului software - Ne da informatii despre comportarea elementelor sistemului (prin interactiuni intre elementele unui sistem) Modelarea comportarii • La nivel generic ‐‐‐‐> comportarea intre clase, sisteme, pachete. • La nivel de instante: intre obiecte, instante ale sistemelor si instante de pachete. Modelarea comportarii pe diferite niveluri de detaliere ale sistemului: • Clase (clasificatori) • Sisteme (si subsisteme) • Pachete Mod comportarii: un element trimite un mesaj unui alt element. (interactiunea) - In UML: un mesaj = un element comportamental care reprezinta o interactiune intre elemente ale modelului. (interactiunile dau functionarea sistemului) Un mesaj implica 2 entitati: • Client ‐‐‐‐> care cere o anumita actiune • Server ‐‐‐‐> furnizeaza un rezultat (al unei actiuni de regula). - Agent = element care are atat rol de server cat si de client. Mesaj • Ex: mesaj intre 2 obiecte = apelul unei functii a unui obiect de catre alt obiect (dintr‐o functie a obiectului client mai exact). • Ex: intre subsisteme: trimiterea unui mesaj pe o retea; web browser trimite unu mesaj catre un web server - Pentru trimiterea unu mesaj: • Existenta unei legaturi intre elementele client si server care comunica. Orice legatura poate permite trimiterea unui mesaj: de asociere, de utilizare, de generalizare, etc.) • Conditia de vizibilitate a serverului fata de client. Ex: serverul sa fie vizibil; adica sa fie accesibil, sa fie in acealas domeniu. Exemplu:
class Punct{ float x; public: Punct(float a, float b) {x=a;y=b}; void move (float m, float n) {x+=m; y+=n}; }; class Segment{ Punct p1; Punct p2; public: Segment (Punct a, Punct b){p1=a; p2=b}; void move (float a, float b){ p1.move(a,b); p2.move(a,b); } //clasa segment trimite un mesaj clasei punct - interact la nivel generic //un obiect din clasa segment trimte un mesaj unui ob din clasa punct -
APOO Curs Page 23
//nivel de instanta float getPanta(){........}; class Cerc{ Punct cemtru; float raza; public: Cerc (float cx, float cy, float r):centru(cx,cy){raza r;} int intersectie (Segment s){ float panta=s.getPanta(); /*legatura de utilizare (Cerc, Segment) este un mesaj intre clasa cerc si clasa segment; el este reprezentat de apelul functiei getPanta*/
Reprezentarea in UML a interactiunilor intre elemente ale sistemului se poate face in 2 feluri: - prin diagrame de colaborare - prin diagrame de secventa a mesajelor Diagrame de colaborare: • la nivel generic ¾ intre clase ¾ intre subsisteme ¾ cazuri de utilizare
• la nivel de instanta ¾ intre obiecte ¾ intre instante de subsisteme ¾ intre cazuri de utilizare, etc. void main(){ Punct p1(1,2); Punct p2(4,5); Segment s1(p1,p2); s1.move (7,8) Punct c(100,200); Cerc c1(c,10); c1.intersectie(s1); }
Diagrama de secventa a mesajelor: Segment
Punct
move
APOO Curs Page 24
Segment
Punct
move
lifeline
Ordonarea temporara a mesajelor este implicita in diagrama de secventa amesajelor deoarece axa verticala reprezinta timpul. Diagramele de secventa a mesajelor sunt mult mai utile si mult mai intuitive.
ob1
ob2
ob3
APOO Curs Page 25
ob4
ob1
ob2
ob3
ob4
Cele 2 reprezentari sunt similare Diagrame de stare Se refera la starile prin care trec obiectele instante ale unei clase. - o satare este o colectie bine definita de valori ale atributelor. - trecerea se face prin tranzitie. O tranzitie are loc intre 2 stari si are loc de regula ca urmare a unei activitati. Daca starile prezinta valori cu semnificatii diferite de la o valoare la alta, atunci putem avea nevoie de astfel de reprezentari. Ex: motor: • pornit • oprit Cele 2 stari pot fi date de turaitie (comparatie fata de 0)
Tranzitia de la o stare la alta Ex: Diagrama de stare a unui proces (gestionat de SO): stare lansare
Aparitia eveniment ului
Gata de executie
planificare
prelevare Executie
Blocat
Asteptare eveniment extern
Diagrama de activitate
APOO Curs Page 26
Se reprezintasecventa activitatilor care asigura rezolvarea unei anumite functiuni [elementul UML corespunzator organigramelor folosite inainte de UML] Ea se compune din: a) o stare de ctivitate ‐ ea reprezinta o procedura care se executa pentru a realiza ceva anume.
b) tranzitii ‐ treceri intre stari de activitate ce au loc in cursul rezolvarii functiunii respective Activitate
Activitate 2
c) Decizie (branch) Activitate
Activitate 2
State1
State2
d) Elemente de executie concurenta
State3
State4
Ex: diagrama de activitate "Livrare Produs"
Primire ordin de livrare
Inregistrare ordin
Trimitere factura
Primirea facturii Livrare de noapte
Livrare zi
APOO Curs Page 27
Primire ordin de livrare
Inregistrare ordin
Trimitere factura
Primirea facturii Livrare de noapte
Livrare zi
Inchidere ordin
- Modelarea structurala (clase, obiecte.....) ‐‐‐‐> vedere structurala - Mocelarea comportamentala (instante.....) - Modelarea utilisarii sistemelor use‐case (cazuri de utilizare) • vedere a sistemului din punct de vedere al utilizarii • recomandate pentru a stabilii cerintele de dezvolatare ale unui sistem • Diagrame use‐case ¾ la nivel generic ¾ le nivel de instante - de structuri - de componente a) Actor - un set de roluri pe care il poate juca un element al ansamblului - tip "actor" (generic) - instanta a unui tip - Un actor poate fii o persoana sau un alt sistem care utilizeaza sistemul dat. Poate reprezenta chiar un eveniment de timp! b) Cazul de utilizare (context de utilizare; use‐case) - un caz de utilizare reprezinta un set de functiuni pe care un element il ofera actorilor. Se reprezinta printr‐un cerc in care apare denumirea cazului de utilizare
c) Legaturi: - intre actori - intre use‐case‐uri - intre actori si use‐case‐uri
APOO Curs Page 28
APOO Curs 7 17 aprilie 2007 09:59
Modelarea utilizarii - Use‐case - De regula este foarte utila ○ mai ales in faza de stabilire a cerintelor ○ pentru utilizatori care nu sunt interesati de structura sistemului ci de utilizare. - Entitati: ○ Actorii (un set de roluri; poate fii o persoana sau un sistem) ○ Contexte de utilizare(seturi de functii sau functionalitati) - Diagrama de utilizare in care se reprezinta actorii si contextele cu legaturile dintre acestia. Legaturile sunt mai speciale, ele specificand modul de utilizare (asemanatoare cu leg de asociere)
Alte legaturi posibile in cadrul modelarii utilizarii: a) Legaturi intre actori: i. Generalizare ii. Dependente 1) De utilizare (<>) 2) De instantiere
b) Intre contexte: a) Generalizare b) Dependenta i. <> ii. <> iii. De instantiere (<>)
APOO Curs Page 29
Extends si include au dir diferite. Ar putea fii considerate echivalente dar legatura de includere este mai puternica. In cadrul functionalitatilor de modelarea a utilizarii se pot folosii: - Diagrame use‐case ‐‐‐‐> modelare structurala - Diagrame de interactiune ‐‐‐‐> modelare comportamentala
Furnizare bani Client Introducere card Cerere Pin Introducere pin Cerere suma Introducere suma
Eliberare card
Ca recomandare, un context de utilizare trebuie sa ofere functionalitati care sa corespunda unui scop al actorului . Toate actiunile mentionate mai sus alcatuiesc un scop. Modelarea componentelor. - Componente software: este o unitate de program (executabil) - Ofera o anumita functionalitate printr‐o interfata - Pot fi dezvoltate, achizitionate si utilizate independent - Pot fi inlocuibile - Impreuna duc la creearea softului bazat pe componente.
O componenta este o extindere a notiunii de clasificator. Experienta de programare a dus la necesitatea de a avea componente mai mari, cu mai multe functii. O componenta=o grupare de: - La programare OO ‐‐‐‐‐> clase si obiecte - La programarea non OO ‐‐‐‐> mai multe functii
APOO Curs Page 30
In cadrul modelarii componentelor: - Reprezentare de diagrame a compenentelor (reprez structurale) ‐‐‐‐> exitindere a diagramei claselor - Diagrame de interactiune (reprez modelare comportamentala) ‐‐‐‐> diagrame de secventa a mesajelor, diagrame de colaborare, etc Diagramele pot fii de 2 tipuri: - Generic ‐‐‐‐> tip componenta - Instanta ‐‐‐‐> instante ale componentelor Legauti intre componente ¾ legatura de compozitie ¾ Leg de dependenta Utilizare Instantiere Legatura de compozitie
Diagrame de interactiune
Component4
Object1
Actor1 Message1 Message2
Message3 Message4
Message5
Message6
Componentele pot fii deployed in noduri de calcul Organizarea modelelor UML - Reducerea complexitatii Grupare de elemente (ale modelului) □ Package (pachet) □ Systems (subsisteme) □ Model
APOO Curs Page 31
Component5
Organizare ierarhica 1) Pachete ¾ Un pachet este o grupare de elemente ale modelului. Elementele grupate de un pachet pot fii:
Clasificatori Alte pachete Diagrama pachetelor: pachetele + legaturile intre acestea. Legaturile: - De generalizare
- De compozitie - De dependente ‐‐‐‐> de utilizare <> sau <> 2) Subsisteme (UML): a) Este un pachet (grupare) de elemente; Organizare unui subsistem se face pre criteriul functionalitatii. «subsystem» SubSystem1
Cel mai inalt nivel b) Diagrame ale subsistemelor: Subsisteme + legaturi de date: ¾ Legatura de compozitie (la fel ca la pachete, cu semnul +) ¾ Legaturi de utilizare posibile intre diverse subsisteme. ¾ Legatura de compozitie ‐‐‐‐> duce la ierarhii de subsisteme «subsystem» SubSystem1 * 1
-End3 1 * -End4
«subsystem» SubSystem2
*
«subsystem» SubSystem5
1
1* -End5 -End6
-End1 -End2
«subsystem» SubSystem3 -End8 -End7
«subsystem» SubSystem4
APOO Curs Page 32
Controler Specification elements ‐‐‐‐> options
Realization elements
Specification
Model: o grupare (package) de elemente ale modulului - Pe criteriul vederii (utilizarii) in cadrul proiectului
- Diagrame de modele: leg de compozitie Putem avea ierarhii de modele sau ierarhii combinate: modele + subsistem
APOO Curs Page 33
APOO Curs 8 24 aprilie 2007 10:10
Diagrame de deployment - Nodurile retelei: calculatoare (host): din punct de vedere al rolului jucat in apl respectiva - Elemente ale modelului (grupare): subsisteme, componente + leg de date dintre acestea Diagrame: - Generice - Ale instantelor
Ex. de legatura intre elemente ale modelului:
Legatura de dependenta (in exemplul de mai sus) Concluzii: Modelare UML 1) Aplicatiile software mari nu pot fii dezvoltate oricum. Ele beneficiaza de o abordare sistematica in care sunt precizate diversele etapesi operatii care trebuiesc efectuate. Cea mai des folosita abordare exte cu ajutorul limbajului UML care poate fii folosit in toate etapele. a. UML e mai intuitiv b. UML asigura compatibilitatea intre diferiti utilizatori si dezvoltator.
Tehnologii de dezvoltare software (software engineering) Printr‐o tehnologie software se intelege un ansamblu de limbaje, standarde, biblioteci, interfete, sisteme de dezvoltare, toolset‐uri, toate avand ca obiectiv dezvoltarea softului, inclusiv implementare (pana la testarea si executia programului) Clasificarea unui numar de domenii: I. Modul de abordare a dezvoltarii software a. Dezvoltarea "from scratch" ‐ custom mode (se pleaca de la 0). Se folosesc cel mult niste biblioteci fara diverse alte componente. Se pot dezvolta aplicatii software mici. Avantaje: flexibilitate foarte mare si adaptare foarte buna la cerintele clientului. Dezavantaje: risc de piata, ce provine dintr‐un posibili timp de realizare ridicat ‐ eficienta scazuta. b. Dezvoltarea prin achizitie de produse software gata realizate. Avantaje: risc de piata redus, timp de realizare mic si deci eficienta mare. Dezavantaje: flexibilitate redusa, adaptabilitatea este redusa ‐ se adapteaza cerintele la software nu software‐ul la cerinte, dificultate de intretinere, vulnerabilitate in fata concurentei.
APOO Curs Page 34
flexibilitate
% soft cumparat
eficienta
% soft cumparat
c. Software bazat pe componente ‐ realizarea softului prin asamblare de componente software. i. O componenta software este o unitate de: productie, achizitie, asamblare (deployment) independenta de alte unitati. ii. O componenta software poate fii considerata si ca o unitate executabila. iii. Au interfete bine precizate care sunt denumite contracte (intre componenta si utilizatorii ei) iv. Au avut o dezvoltare mai lenta decat alte componente (hardware) Acest lucru provine din caracterul abstract al produselor software. Chiar definitia este controversata. Pana la ce nivel se merge cu compartimentarea? In momentul de fata exista o piata de componente a caror dezvoltare a avut loc mai lent dar ea exista. v. Componentele software au inceput ca si VBX ‐ visual basic controls ‐ componente folosite pentru dezvoltarea de interfete. vi. Dezvoltarea software‐ului bazat pe componente este o solutie intermediara intre cele 2 extreme: Are un grad de flexibilitate mai mare decat soft‐ul cumparat, eficienta intermediara, etc. Alt avantaj: se pot combina solutii. Se poate cumpara o parte gata facuta lipita cu un soft propriu care impreuna sa prezinte toate cerintele dorite incluziv un anumit avantaj fata ce competitori. In realitate: - Combinarea componentelor software nu este atat de flexibila deoarece depinde de producator. [compatibilitate redusa, mai ales intre producatori] - Exista dezvoltari de componente pe baza catorva tehnologii. Clasificarea aplicatiilor din punct de vedere al numarului de statii pe care se executa. 1) Aplicatii locale ‐ desktop, nedistribuite; - 1 proces (unul sau mai multe) cu unul sau mai multe thread‐uri care se executa pe o singura statie. Nu apar comunicatii pe retea si deci aplicatia se rezolva local. - Exista diferite toolset‐uri de dezvoltare MSDEV (bazat pe C++) care se sprijina pe biblioteca MFC ce permite dezvoltarea usoara ai interfetelor grafice prin intermedul Visual C++. Un framework = grupare de elemente care permite dezvoltarea unor anumite tipuri de aplicatii.
APOO Curs Page 35
JDK ‐ J2SE. Desi Java a fost dezvoltat pentru internet, el poate fii folosit ca modalitate de dezvoltarea a unui software local. 2) Aplicatii distribuite: mai multe procese, posibil cu mai multe thread‐uri, care se executa pe mai multe statii interconectate printr‐o retea. - Arhitecturi de dezvoltare a aplicatiilor distribuite: Arhitectura client server (pe 2 niveluri):
Arhitectura client slab (pe 2 niveluri): Necesita un server puternic, este simplu de implementat, ofera o securitate puternica (toate operatiile se rezolva la server) si intretinerea este simpla. Dezavantaje: poate sa apara congestia serverului. Arhitectura client puternic (pe 2 nivele): Avantaje: serverul nu se congestioneaza. Dezavantaje: intretinere complicata (orice schimbare presupune schimbari la toti clientii), securitate mai slaba, etc. - Arhitecturi pe mai multe niveluri:
Nivel de prezentare
Logica aplicatiei
retea
Client
Nivel de date.
retea
Nivelul “business logic”
Sisteme de gestionare a bazelor de date
Rol de server – Aplication server
Portiunea din mijloc, mai poarta si denumirea de middle‐ware. Ex de aplicatie 3‐tier: Aplicatie web in care avem clientul ‐ web browser ‐ care cere informatii de la un server web care la randul lui poate sa ceara date dintr‐un sgdb care personalizeaza sau specifica mai clar cerintele clientului web.
Nivelurile unei aplicatii multi tier sunt niveluri logice. Ele pot sa fie executate fiecare pe cate un host sau pot sa fie grupate III. Tehnologiile de dezvoltare software a. Tehnologii Microsoft ‐ pornind de la o viziune (Desktop) s‐a ajuns la aplicatii distribuite puternice (1985). b. Tehnologia CORBA ‐ Comon Object Request Broker Arhitecture. Arhitectura porneste din
APOO Curs Page 36
perspectiva enterprise. 1) In 1991, tehnologia a fost specificata de OMG (Object Management Group). Momentana s‐a ajuns la CORBA 3.0 denumita si CCM ‐ corba component model. c. Tehnologiile Java ‐1995 ‐ dezvoltata de Sun Microsystems pornita din perspectiva internet. Ea si‐a propus sa ofere solutii pt aplicatiile in internet. 1) JDK ‐ Java standard edition care ofera in mare parte aplicatii desktop si aplicatii distribuite in diverse acceptiuni dintre care applet‐urile sunt folosite in internet. Exista un pachet java.net care permite comunicatia prin socluri si care poate sa fie folosti direct. Mai avem si pachetul java.rmi care pemite comunicatia in retea 2) J2EE ‐ Java enterprise edition. Enterprise inseamna distribuit. Acest pachet ofera suport pentru aplicatii distribuite atat in retea locala. Din pachetul J2EE fac parte EJB ‐ enterprise java beans care sunt componente software utilizate in relele locale si in internet servleti si JSP. Acestea din umra pot fii considerate componente software. Toate componentele sunt OO. Se remarca o spirala de dezvoltare a tehnologiilor software. Se reiau anumite idei de la o tehnologie la alta. Tehnologia CORBA este considerata internet unfriendly. Nu are prevazut un mecanism eficient de travesare a firewall‐urilor. Tehnologii Microsoft - Dezvoltarea de aplicatii de tip desktop ‐ MSDEV - Dezvoltarea aplicatilor distribuite: ○ Etapa COM‐DCOM. (Componente Object Model ‐ Distributed COM). Aceasta tehnologie este inglobata in sistemele de operare. A inceput in 1991 prin tehnologia OLE 1.0 ‐ object linking and editing 1.0. S‐a incercat legarea de aplicatii de tip desktop. In 1992 standardul introduce notiunea de componenta. IN1993 ‐ OLE 2; 1996 ‐ ActiveX ‐ tehnologia COM pentru internet; In 2000 ‐ com+ ○ IN 2001 ‐ tehnologia .NET ‐ orientata pe aplicatii Internet (distribuita) In 2002 .NET Framework 1.0; C#. Aplicatiile sunt orientate pe componente software. In .NET componentele software sunt mai inregimentate. Un ansamblu (o entitate dezvoltata in .NET) reprezinta o componenta software .NET
APOO Curs Page 37
APOO Curs 9 15 mai 2007 10:12
Tehnologia Microsoft .NET - Dezvoltata dupa anul 2003; Este directionata catre aplicatii distribuite; Inlocuim tehnologia COM, DCOM - Principii .NET: ○ Interoperabilitaea intre diferite aplicatii ○ Integrarea limbajelor (in aplicatii se pot folosii mai multe limbaje diferite) ○ Este limitata la sistemele de operare de tip Windows. - .NET Framework ‐ cadru de dezvlotare a aplicatiilor care permite dezvoltarea aplicatiilor in platforma .NET. Mai poarta si numele de platforma .NET
Web Services Web Form\Windows Forms Data & XML Framework Base Clases (FBC) Windows
Intre biblioteca si sistemul de operare mai apare si CLR ‐ partea executiva a programelor (.NET Framework). ¾ Este echivalent cu o masina virtuala Java. ¾ Executa (controleaza executia) in limbaj intermediar IL (MSIL: Microsoft Internal Language) ¾ IL se obtin din compilarea resurselor: limbajele .NET: C# (seamana si cu C++ si cu Java) VB. NET J# Managed C++ Toate programele produc cod in limbaj IL
Sursa C#
Sursa J#
Managed module IL
Singurul program diferit este Managed C++ care poate genera modul managed sau nu. Managed module ‐ modul administrabil: IL si poate fii executat sub controlul CLR. Un unmanaged module ‐ modul neadministrat ‐ poate fii executat direct de SO si este un modul in cod nativ (limbajul CPU pe care se lucreaza) - Functionare CLR
APOO Curs Page 38
Modul managed
incarcare
Managed IL
Verificare cod
Managed IL
Compilat
NU
Cod nativ managed
Garbage col DA executie
executie
Controlul executiei CLR ¾ Verificare de runtime ¾ "Garbage colector": obiectele din memoria libera sunt distruse. Executia este sigura pentru ca nu mai exista operatorul delete care genera probleme in C++ Organizarea progr. NET ¾ Compilator ‐ Modul(managed): Codul IL "Metadata": tabele care descriu tipurile definite in modulul respectiv ¾ Unitatea de executie, instalare, versionare si securitate este denumita ansamblu (assembly). Un ansamblu este unitatea care se poate instala. Un ansamblu poate sa contina 1 sau mai multe module. El are deci modulele propriu‐zise (care contin cod IL si metadata), diverse resurse si un manifest (care contine lista datelor). Un ansamblu este o componenta software. Exemplu HelloWorld: //fisier sursa Hello.cs using System; class Hello{ public static void Main(){ Console.Writeline("HelloWorld"); } }
Compilare csc Hello.cs In urma acestei comenzi se creeaza Hello.exe (ansamblu continut in windows pe ‐ portable executable) - Instalare CLR (.NET Framework) ¾ Se modifica loader‐ul SO ai loader‐ul poate deosebii un PE in cod nativ de un PE in cod IL.
In windows librariile poarta denumirea de dll (Dinamib Link Library) a) C# este mai pur din punct de vedere al OO fata de C++. Nu admite metode si variabile globale. Med main cu care incepe executia devine o metoda statica a unei clase. Ea poate fii invocata fara instantierea clasei din care face parte. b) Spatiile de nume a. sunt grupari logice de entitati b. clase in care numele de identificatori sunt unice c. permit evitarea coliziunilor de nume. d. spatiile de nume se pot grupa ierarhic namespace Spatiul1{
APOO Curs Page 39
....... manespace Subspatiul1{ class Clasa1{ ...... } } }
Numele unei clase: Spatiul1.Subspatiul1.Clasa1. La utilizare, directiva using ne permite o utilizare mai simpla a spatiilor. Astfel Syste.Console devine Console System System.Collection System.IO System.Data System.Winows.Forms System.Web.UI System.Web.Services Tipurile de date .NET - Integrarea limbajelor ○ tipuri comune CTS (Common Type Specifications) ○ tipuri impuse limbajelor numite CLS (Common Language Specifications) ○ fiecare limbaj defineste ca multimea tipurilor sale o multime care este o submultime a CTS si include CLS
CTS
VB .NET
CLS
C++
C#
Clasificarea tipurilor distribuite din .NET - Dupa modul de creere: ○ tipuri valoare ○ tipuri referinta - Dupa locul de creeare: ○ tipuri definite in .NET ○ tipuri definite de utilizator.
APOO Curs Page 40
Tip .NET C#
Managed C++ Dimensiune
Byte
byte
unsigned char 8biti
Int32
int
ins,long
32biti
Single
float
float
32biti
Char
char
‐
16biti
bool
1bit
Boolean bool
Limbajul C# Limbajul oficial al .NET - Andreas Hejsberg, cott Wiltamuth - C++, Java Tipuri de date C# I. Tipuri valoare a. Tipuri primitive: int x=1; i. se creeaza prin declaratie ii. se creeaza in stiva iii. nu avem referinte b. Tipul enumerare ‐ defineste o colectie de valori constante. using System; public class Class1{ enum Valori{ mica=1; potrivita=2; mare=3; }; public void static Main(){ Console.Writeln ("Valori {0},{1},{2}", Valori.mica,Valori.potrivita, Valori.mare); } }
Se afiseaza: Valori 1,2,3 c. Structuri: //Fisier... struct Locatie{ //implicit derivata din valuetype; nu permite derivarea. intx; inty; public Locatie(int a, int b){ x=a; y=b;} public override string ToString(){//override se refera la dominare return "Locatie"+x+" "+y; } } public class Program{ public static void Main(){ Locatie.l1=new Locatie(4,5);//returneaza valoarea - obiectul care se //creeaza in stiva
APOO Curs Page 41
System.Console.Writeln(l1.ToString); }
}
Afiseaza: Locatie 4 5 Curs se continua cu laboratoarele .NET (7 si 8) Exemplu clasa statica: //Fisier statice.cs using System; public class Clasa{ private int x; private const int c=10;//se poate initializa numai in declaratie o const private readonly int r=2;//se mai poate initializa si in constructor public static s;//ca in Java, nu in C++!!! public Clasa(int a, intb, int c){x=a;r=b;s=c;} public void inc(){x++;s++}//met nestatice pot accesa date membre statice si //nestatice public static void incs(){x++;/*da eroare*/s++;} public override string toString(){ return "x="+x+"r="+r+"s="+s; } public class Program{ punlic static void Main(){ Clasa c1=new Clasa(1,2,3); Console.writeline(c1);//toString de aici e mostenit din object insa daca //vrem sa afiseze ceva anume se va face redefinirea. Se poate folosii //Console.Writeln(c1.toString()); Clasa.s=5; c1.inc(); Console.Writeline(c1);//afiseaza x=2r=2s=6 c1.incs();//eroare, nu se poate accesa metoda statica folosind un obiect Clasa.incs();//corect
} }
APOO Curs Page 42
