Facultatea de Informatic Universitatea Al I Cuza Iai

Facultatea de Informatică Universitatea “Al. I. Cuza” - Iaşi Practică - Cursul I – Adrian Iftene adiftene@info. uaic. ro

CONŢINUT t t t t Prezentarea generală; modalitatea de notare Alegerea platformei; licenţierea codului Stil de programare; organizarea proiectului Testare; unităţi de testare Persitenţa: XML, baze de date Modele de dezvoltare; analiza cerinţelor UML; modele de proiectare Controlul versiunilor, lucrul în echipă 2

Desfăşurare t t Scop: Realizarea unui proiect (program de o complexitate medie) Cerinţe în realizarea proiectului: i. Folosirea unui stil de programare (elegant) i. Realizarea unei arhitecturi clare i. Realizarea unor scenarii de Testare t t Nota se obţine exclusiv la laborator Termenele limită: i. Lab 1: discutarea intenţiei de proiect i. Lab 2: predarea documentului cu scenariile utilizare i. Ultimul Laborator: prezentare proiect 3

Notarea t Prezentarea finală: i. Trimitere arhivă zip cu surse + documente adiţionale la adresa adiftene@info. uaic. ro t t Nu se fac prezentări de proiecte în sesiune Prezentări în sesiunea de restanţe: rezoluţie admisrespins. Se pot folosi resurse externe (cod, biblioteci), dar se va documenta şi discuta cu conducătorul de laborator. În caz contrar: nota mica, refacere disciplina etc. 4

Exemple de Teme date în Anii Anteriori: 1. MP 3 Playlist Generator 2. Admitere 3. Evidenta Populatiei, evidenta stocurilor 4. Editor de (Di)Grafuri 5. Simulator de Automate 6. Salarizare si Gestiunea Personalului 7. Orar 8. Dictionar Enciclopedic Multimedia 9. Generarea aleatoare a retetelor culinare 10. Jocuri 11. Pagini Web 5

Alegerea Platformei şi a Mediului de Dezvoltare t Sistem de operare: i. Windows, Linux, UNIX, Solaris, Mac. OS etc. t Tehnologia de dezvoltare inativ (C/C++), Java, . NET etc. t Mediu de dezvoltare i. Visual Studio, JDeveloper, Net. Beans, KDevelop etc. 6

De ce trebuie ţinut cont? t t Costul: cost necesar implementării soluţiei (dezvoltatori), cost necesar adoptării soluţiei (utilizator) Disponibilitatea platformei Cunoaşterea platformei de către dezvoltatori Portabilitate 7

Sistem de operare: Windows t Produs de firma Microsoft: i http: //www. microsoft. com i http: //www. thocp. net/companies/microsoft_company. htm t Cel mai raspandit SO pentru PC-uri (90%) i http: //www. itfacts. biz/index. php? id=P 1059 t t Closed-source (deschis pentru guverne) Orientare recenta spre interoperabilitate i http: //www. microsoft. com/mscorp/execmail/2005/0203 interoperability. asp t t Baza de aplicaţii foarte puternică Contestat: i http: //www. gnu. org/philosophy/microsoft. html i http: //www. eubusiness. com/afp/050225135302. vy 8 d 5 vux 8

Sistem de operare: GNU/Linux t Produs de. . . hm. . . i http: //www. linux. org/ i http: //www. li. org/linuxhistory. php t Promotor al filozofiei open-source i http: //www. gnu. org/philosophy/ t Producători şi susţinători: Debian, Red. Hat, Su. Se, Mandrake, IBM i http: //www. debian. org/social_contract i http: //news. com/2100 -1001 -825723. html t Contestat: i http: //www. microsoft. com/resources/sharedsource/Articles/Licensi ng. Basics. mspx i http: //www. groklaw. net/staticpages/index. php? page=20031016162 215566 9

Sistem de operare: Mac. OS t Produs de Apple i http: //www. apple. com i http: //www. apple-history. com t t Closed-source Cunoscut pentru puternice aplicaţii multimedia i http: //www. apple. com/macosx/applications/photoshop/ i http: //www. apple. com/itunes/ t Contestat: i http: //www. computerdictionaryonline. org/Boycott%20 Apple. htm? q=Boycott%20 Apple i http: //www. gnu. org/philosophy/apsl. html 10

Sistem de operare: UNIX t Revendicat de SCO i http: //www. sco. com t t Unul dintre cele mai vechi sisteme de operare, renumit pentru stabilitate, scalabilitate şi performanţă. SCO este la originea unei mari agitaţii, prin procesul intentat IBM în care i Acuza IBM ca ar introdus “secrete UNIX” în Linux i http: //sco. tuxrocks. com/Docs/IBM/complaint 3. 06. 03. html t SCO atacă constituţionalitatea licenţei GPL i http: //www. thescogroup. com/copyright/ i http: //www. linuxworld. com/story/44643. htm 11

Întrebări t t t t Care este viitorul platformei pe care o aleg? Cine altcineva mai foloseşte această platformă? Ce se întâmpla daca platforma pe care am ales-o ajunge la sfârşitul vieţii? Ce se întâmpla daca va trebui sa migrez spre o alta platformă? Ce se întâmpla daca am probleme şi am nevoie de ajutor? Cât mă costă pe mine şi pe utilizatori folosirea unei anumite platforme? . . . etc. 12

Tehnologia de dezvoltare: nativ t C/C++ i. Avantaje u. Viteza uÎncrederea i. Dezavantaje u. Probleme cu portabilitatea u. API greoi pentru tehnologii moderne: XML, GUI u. Poate fi privită ca demodată 13

Tehnologia de dezvoltare: Java t Java i. Avantaje u. Portabilitate u. Limbaj modern, puternic (J 2 SE, J 2 EE) i. Dezavantaje u. Viteza u. Gestionarea Memoriei 14

Tehnologia de dezvoltare: . NET t C#, Visual. Basic etc. i. Avantaje u. Limbaje moderne, puternice u. Suport Microsoft, tehnologie cu bătaie lungă u. Aparent mai rapide ca Java i. Dezavantaje u. Portabilitatea: Doar pe Windows. . . u http: //www. mono-project. com/about/index. html 15

Medii de dezvoltare t t t Visual. Studio. NET: http: //msdn. microsoft. com/vstudio/ JDeveloper: http: //www. oracle. com/technology/products /jdev/index. html Net. Beans: http: //www. netbeans. org/ KDevelop: http: //www. kdevelop. org/. . . multe altele 16

Total Cost of Ownership: TCO t t t t http: //www. webopedia. com/TERM/T/TCO. html http: //www. solutionmatrix. com/tcogo. A. html TCO: Costul total de proprietate Costul original al echipamentelor şi programelor Costul pentru îmbunătăţirea echipamentelor şi programelor Costul întreţinerii Costul pentru suport tehnic Costul instruirii 17

În rezumat, ce tehnologie voi folosi eu? t t În general: depinde de tipul de proiect. . . Dar: la Practică sunt acceptate doar tehnologiile la care Facultatea de Informatică şi membrii Facultăţii de Informatică (studenţi, cadre didactice) pot avea acces în mod gratuit. Asta înseamnă: Tehnologii Microsoft: ihttp: //msdn. microsoft. com/academic/ t Tehnologii Open-Source (i. e. GNU/Linux), Java: ihttp: //ftp. iasi. roedu. net/mirrors/ ihttp: //java. sun. com 18

Licenţierea programelor t Programe close-source i. Unicat i. La bucată t Programe open-source ihttp: //www. opensource. org/ ihttp: //www. gnu. org/ ihttp: //www. apache. org/ 19

Concluzii Ce se face la Practică? La Practică sunt prezentate tehnologiile necesare pentru a crea un proiect intr-un limbaj la alegere (C++, Java, C#, Python). Scopul este crearea unui proiect cu o arhitectura clara, implementat folosind un stil de programare elegant si care foloseste unitati de testare automata. Ce nu se face la Practică? La Practică nu se preda un limbaj de programare (C++, Java), o biblioteca de dezvoltare (MFC, wx. Windows, Swing) sau un IDE (Visual Studio, Net. Beans). Invatarea acestor lucruri cade in sarcina studentului, functie de tipul de proiect pe care si l-a ales. La curs si la laborator vor fi oferite resurse pentru a indruma invatarea. Scop: "invat sa invat" (o constanta a meseriei de programator). Ce sa fac pentru a nu promova? Nu discut proiectul cu conducatorul de lucrari astfel incat atunci cand se fac prezentarile finale acesta nu stie cine sunt si cu ce ma ocup. Ce sa fac pentru a lua o notă (foarte) mică? Imi proiectez programul ca si cum nu as fi aflat nimic de la curs, scriu codul la intamplare si nu fac unitati de testare. Daca excelez, se poate chiar ca nota foarte mica sa nu fie de trecere! Alegerea platformei de Windows, Linux (distributions), Free. BSD, Apple Costuri si beneficii dezvoltare (termen scurt, mediu, lung). Portabilitate. Alegerea licenţei de distribuţie a programului Closed-source, open-source (GNU (L)GPL, Apache licence, BSD 20 licence). Strategii de "marketing".

Proprietarul dreptului de autor t Dreptul de autor asupra unui program-calculator aparţine autorului cu condiţia ca acesta să nu fie întruna dintre excepţiile: i Atribuţii de servici i Contracte şi granturi de cercetare i Proiecte, lucrări diplomă, dizertaţii ale studenţilor ((co) autor) i Utilizarea resurselor facultăţii t t Dacă un program-calculator este realizat în colaborare, atunci dreptul de autor aparţine coautorilor acestuia. Dacă un program-calculator este realizat şi modificat în timp de către diferiţi angajaţi şi studenţi ai facultăţii astfel încât este imposibil de determinat cine este autorul, atunci dreptul de autor asupra programului aparţine facultăţii. 21

Modele de Dezvoltare t Pentru a dezvolta un program este nevoie de: i O înţelegere clară a ceea ce se cere i Un set de metode şi instrumente de lucru i Un plan de acţiune t Plan de acţiune = şablon = model de dezvoltare 22

Etapele Dezvoltării Programelor Analiza cerinţelor t Proiectarea arhitecturală t Proiectarea detaliată t Scrierea codului t Integrarea componentelor t Validare t Verificare t Întreţinere t 23

Analiza Cerinţelor t t t Se stabileşte ce anume vrea clientul ca programul să facă Scopul este înregistrarea cerinţelor într-o manieră cât mai clară şi mai detaliată Probleme i Comunicare i Negociere i Sfătuirea clientului 24

Proiectarea Arhitecturală t Proiectarea arhitecturală i. Din motive de complexitate, programele mari nu pot fi concepute şi implementate ca o singură bucată i Programul este împărţit în module sau componente mai simple, care pot fi abordate individual t Proiectarea detaliată i Se proiectează fiecare modul al aplicaţiei, în cele mai mici detalii 25

Implementare, Integrare t Implementare i Proiectul detaliat este transpus intr-un limbaj de programare i Acesta se realizează modular, pe structura rezultată la proiectarea arhitecturală t Integrare i Modelul big-bang i Modelul incremental 26

Validare şi Verificare t Validare: ne asiguram ca programul îndeplineşte cerinţele utilizatorului. i Construim produsul corect? t Verificare: ne asigurăm că programul este stabil şi că funcţionează corect din punctul de vedere al dezvoltatorilor. i Construim corect produsul? 27

Întreţinere t După livrare i Sunt descoperite greşeli ce trebuie reparate i Pot apare schimbări în specificaţii i Pot apare noi cerinţe t Întreţinere = gestionarea acestor tipuri de probleme 28

Modele de dezvoltare t t Cum efectuam activităţile indicate de etapele dezvoltarii programelor Exemple de modele de dezvoltare: i Ad-hoc: descurca-te cum poţi i Modelul în cascadă (cu feedback) i Prototipizare i Metode formale i Modelul în spirală i RUP (Rational Unied Process) i XP (Extreme Programming) 29

Ingineria Cerinţelor Modelul în cascadă Proiectarea Arhitecturală Proiectarea Detaliată Implementare Testarea Unităţilor Testarea Sistemului Acceptare 30

Modelul în cascadă +: Împarte o sarcină complexă în paşi mai mici t +: Uşor de administrat şi controlat t +: Fiecare pas are ca rezultat un produs bine definit t -: Erorile se propagă între paşi t -: Nu exista mecanisme de reparare a erorilor t 31

Modelul în cascadă cu întoarcere Ingineria Cerinţelor Proiectarea Arhitecturală Proiectarea Detaliată Implementare Testarea Unităţilor Testarea Sistemului Acceptare 32

Modelul în Cascadă cu Întoarcere +: Oferă cadrul pentru remedierea erorilor din pasul precedent t -: Erorile la pasul i care sunt descoperite la pasul i + 2 nu sunt remediate t -: Clientul vede produsul final abia la sfârşitul dezvoltării t 33

Modelul în Spirală Studiul de fezabilitate t Analiza cerinţelor t Proiectarea arhitecturii t Implementarea Pentru fiecare pas, se fac următoarele activităţi: t 1 : pregătirea [take stock] 4 : planificarea următorului stagiu [planning] 2 : gestiunea riscului [dealing with risk] 3 : dezvoltarea [development] 34

Modelul în Spirală t t t +: Păstrează avantajele modelului în cascadă +: Ia în calcul noţiunea de risc Exemple de riscuri: i O firmă concurentă lansează un produs rival i Un arhitect părăseşte echipa i Clientul schimba cerinţele i O echipă nu respecta termenele de livrare 35

Prototipizare t Tipuri de prototipuri i. De aruncat (throw-away) u Scop: clarificarea specificaţiilor u Se dezvoltă repede, orice altceva e secundar (quickand-dirty) u Util în a rezolva “architecural/technology spikes” u Programul “adevărat” este scris apoi de la 0 i Evoluţionar u Scop: construire incrementală a produsului final u Se construieşte un nucleu funcţional la care se adaugă apoi noi funcţionalităţi 36

Prototipizare t Avantaje i. Se poate elimina lipsa de claritate a specificaţiilor i. Clienţii pot schimba cerinţele (e ieftin de gestionat) iÎntreţinere ieftină (verificare pe parcurs) i. Se poate facilita instruirea utilizatorilor t Dezavantaje i. Mediu artificial, probleme ascunse i. Da' nu-i aproape gata? ! De ce mai durează atât? i. Putem să schimbăm specificaţiile? Pai aş vrea şi. . . i. Adică munca mea este aruncată la gunoi? 37

Extreme Programming t t Extreme Programing (XP) este o model modern, uşor (lightweight), de dezvoltare, inspirat din RUP. Dezvoltarea programelor nu înseamnă ierarhii, responsabilităţi şi termene limită, ci înseamnă colaborarea oamenilor din care este formată echipa Membrii echipei sunt încurajaţi să-şi afirme personalitatea, să ofere şi să primească cunoaştere şi să devină programatori străluciţi XP consideră că dezvoltarea de programe înseamnă în primul rând scrierea de programe (fişierele Power. Point nu se pot compila). 38

Idei majore in XP t t t t t Echipa de dezvoltare nu are o structură ierarhica. Fiecare contribuie la proiect folosind maximul din cunoştinţele sale. Scrierea de cod este activitatea cea mai importantă. Proiectul este în mintea tuturor programatorilor din echipa, nu în documentaţii, modele sau rapoarte. La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerinţelor. Codul se scrie cât mai simplu. Se scrie cod de test întâi. Daca apare necesitatea rescrierii sau aruncării de cod, aceasta se face fără milă. Modificările aduse codului sunt integrate continuu (de câteva ori pe zi). Se programează în echipă (programare în perechi). Echipele se schimbă la sfârşitul unei iteraţii (1 -2 săptămâni). Se lucrează 40 de ore pe săptămână, fără lucru suplimentar. 39

Revenim. . . t Etapele dezvoltării programelor i. Analiza cerinţelor i. Proiectarea i. Scrierea codului i. Testare iÎntreţinere Toate etapele dezvoltării programelor depind de analiza cerinţelor. 40

Începutul unui proiect t Un proiect poate începe: i cu o idee a clientului i cu o idee a unei echipe de dezvoltare t Aceasta idee poate fi: i clara, bine definita i vaga, prost definita t Pentru a continua cu succes, este nevoie de ingineria cerintelor. 41

Specificaţia bună t t t Spune ce trebuie facut, nu cum Este clara (neambigua) Este suficient de detaliata Este completa Exemplu (sau contraexemplu? ): Scrieti un program Pascal care ofera functionalitatea unei agende telefonice personale. Ar trebui sa implementeze functii pentru cautarea unui numar si pentru introducerea unui nou numar de telefon. Programul va oferi o interfata utilizator prietenoasa. 42

Detalii de implementare la analiză? t NU i. Clientul nu este competent in detalii tehnice i. Clientul nu poate fi de acord in cunostinta de cauza cu stipularile tehnice din specificatii (Stiu secretarele COM? Stiu soferii ciclul Carnot? ). i. E necesar sa restrangem multimea posibilelor solutiile tehnice? t DA i. Este nevoie sa integram intr-un sistem existent i. Timpul de dezvoltare depinde de implementare i. Intretinerea (costul) depinde de implementare 43

Responsabilităţile Analistului t t t sa extraga si sa clarifice cerintele clientului sa ajute la rezolvarea diferentelor de opinie intre clienti si utilizatori. sa sfatuiasca clientul despre ce este tehnic posibil sau imposibil sa documenteze cerintele sa negocieze si sa obtina o intelegere cu clientul. 44

Activităţile Analistului t t Ascultare: Inregistreaza cerintele clientului. Reflectare: Traduce cerintele in limbaj tehnic. Verifica pertinenta. Scriere: Se cade de acord asupra formularilor. Repeta pana cand se ajunge la o intelegere cu clientul in ceea ce priveste cerintele. 45

Probleme Potenţiale t t t Procesul iterativ poate fi lung si complicat Negocieri (dure) Diferenta culturala dintre client si analist Diferente intre cerintele clientului si ale utilizatorilor Filmele SF vazute de client Filmele SF vazute de programatori 46

Rezultatul Analizei t t t Document de specificare a cerintelor Acest document este folosit ca referinta Provocari i. Nivelul de detaliu u Mare: mai precis, obtinut mai greu, munca inutila u Mic: prea vag, nu poate ghida eficient dezvoltarea i. Audienta documentelor u 2 versiuni: una pentru client, alta pentru dezvolatori? i. Notatia folosita u Informala, semiformala, formala 47

Tipuri de Cerinţe t Cerinte functionale i. Ce trebuie sa faca sistemul t Cerinte privind datele i. Formatul datelor la intrare/iesire i. Formatul datelor din interiorul sistemului t Constrangeri i. Cerinte de respectat ad-literam i. Influenteaza direct implementarea t Recomandari i. Ajuta la luarea deciziilor de proiectare cand sunt mai multe optiuni 48

Exemple t Cerinte functionale i Sistemul se va opri in maxim 5 secunde dupa ce temperatura procesorului atinge 80 grade Celsius. i Sistemul va permite cautarea si afisarea titlurilor cartilor scrise de un anumit autor. t Cerinte privind datele i Datele vor fi exportate in format XML i Datele din tampoanele de intrare si iesire vor fi criptate t Constrangeri i Implementarea se va realiza folosind un limbaj orientat obiect. i Metodologia de dezvoltare va fi Prototipizare t Recomandari i Se va folosi cat mai putina memorie 49

Link-uri Utile: t t Pagina cursului: http: //thor. info. uaic. ro/~adiftene Ovidiu Gheorghieş: http: //thor. info. uaic. ro/~ogh 50