Facultatea de Informatică

Universitatea “Al.I.Cuza” - Iaşi

Practică - Cursul I –

Adrian Iftene

adiftene@info.uaic.ro

2

CONŢINUT 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ă

3

Desfăşurare Scop: Realizarea unui proiect (program de o

complexitate medie) Cerinţe în realizarea proiectului:

Folosirea unui stil de programare (elegant) Realizarea unei arhitecturi clare Realizarea unor scenarii de Testare

Nota se obţine exclusiv la laborator Termenele limită:

Lab 1: discutarea intenţiei de proiect Lab 2: predarea documentului cu scenariile utilizare Ultimul Laborator: prezentare proiect

4

Notarea Prezentarea finală:

Trimitere arhivă zip cu surse + documente adiţionale la adresa adiftene@info.uaic.ro

Nu se fac prezentări de proiecte în sesiune Prezentări în sesiunea de restanţe: rezoluţie admis-

respins. 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.

5

Exemple de Teme date în Anii Anteriori:

1.   MP3 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

6

Alegerea Platformei şi a Mediului de Dezvoltare

Sistem de operare: Windows, Linux, UNIX, Solaris, MacOS etc.

Tehnologia de dezvoltare nativ (C/C++), Java, .NET etc.

Mediu de dezvoltare Visual Studio, JDeveloper, NetBeans,

KDevelop etc.

7

De ce trebuie ţinut cont?

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

8

Sistem de operare: Windows Produs de firma Microsoft:

http://www.microsoft.com http://www.thocp.net/companies/microsoft/microsoft_

company.htm Cel mai raspandit SO pentru PC-uri (90%)

http://www.itfacts.biz/index.php?id=P1059 Closed-source (deschis pentru guverne) Orientare recenta spre interoperabilitate

http://www.microsoft.com/mscorp/execmail/2005/02-03interoperability.asp

Baza de aplicaţii foarte puternică Contestat:

http://www.gnu.org/philosophy/microsoft.html http://www.eubusiness.com/afp/050225135302.vy8d5vux

9

Sistem de operare: GNU/Linux Produs de ... hm...

http://www.linux.org/ http://www.li.org/linuxhistory.php

Promotor al filozofiei open-source http://www.gnu.org/philosophy/

Producători şi susţinători: Debian, RedHat, SuSe, Mandrake, IBM http://www.debian.org/social_contract http://news.com.com/2100-1001-825723.html

Contestat: http://www.microsoft.com/resources/sharedsource/Articles/Licensi

ngBasics.mspx

http://www.groklaw.net/staticpages/index.php?page=20031016162215566

10

Sistem de operare: MacOS Produs de Apple

http://www.apple.com http://www.apple-history.com

Closed-source Cunoscut pentru puternice aplicaţii multimedia

http://www.apple.com/macosx/applications/photoshop/ http://www.apple.com/itunes/

Contestat: http://www.computer-dictionaryonline.org/Boycott%20Apple.htm

?q=Boycott%20Apple

http://www.gnu.org/philosophy/apsl.html

11

Sistem de operare: UNIX Revendicat de SCO

http://www.sco.com

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 Acuza IBM ca ar introdus “secrete UNIX” în Linux http://sco.tuxrocks.com/Docs/IBM/complaint3.06.03.html

SCO atacă constituţionalitatea licenţei GPL http://www.thescogroup.com/copyright/ http://www.linuxworld.com/story/44643.htm

12

Întrebări 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.

13

Tehnologia de dezvoltare: nativ

C/C++ Avantaje

Viteza Încrederea

Dezavantaje Probleme cu portabilitatea API greoi pentru tehnologii moderne: XML,

GUI Poate fi privită ca demodată

14

Tehnologia de dezvoltare: Java

Java Avantaje

Portabilitate Limbaj modern, puternic (J2SE, J2EE)

Dezavantaje Viteza Gestionarea Memoriei

15

Tehnologia de dezvoltare: .NET

C#, VisualBasic etc. Avantaje

Limbaje moderne, puternice Suport Microsoft, tehnologie cu bătaie lungă Aparent mai rapide ca Java

Dezavantaje Portabilitatea: Doar pe Windows... http://www.mono-project.com/about/index.html

16

Medii de dezvoltare

VisualStudio .NET: http://msdn.microsoft.com/vstudio/

JDeveloper: http://www.oracle.com/technology/products/jdev/index.html

NetBeans: http://www.netbeans.org/ KDevelop: http://www.kdevelop.org/ ... multe altele

17

Total Cost of Ownership: TCO http://www.webopedia.com/TERM/T/TCO.html http://www.solutionmatrix.com/tcogoA.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

18

În rezumat, ce tehnologie voi folosi eu?

Î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:

http://msdn.microsoft.com/academic/ Tehnologii Open-Source (i.e. GNU/Linux), Java:

http://ftp.iasi.roedu.net/mirrors/ http://java.sun.com

19

Licenţierea programelor

Programe close-source Unicat La bucată

Programe open-source http://www.opensource.org/ http://www.gnu.org/ http://www.apache.org/

20

ConcluziiCe 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, wxWindows, Swing) sau un IDE (Visual Studio, NetBeans). 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 dezvoltare

Windows, Linux (distributions), FreeBSD, Apple Costuri si beneficii (termen scurt, mediu, lung). Portabilitate.

Alegerea licenţei de distribuţie a programului

Closed-source, open-source (GNU (L)GPL, Apache licence, BSD licence). Strategii de "marketing".

21

Proprietarul dreptului de autor Dreptul de autor asupra unui program-calculator

aparţine autorului cu condiţia ca acesta să nu fie într-una dintre excepţiile: Atribuţii de servici Contracte şi granturi de cercetare Proiecte, lucrări diplomă, dizertaţii ale studenţilor ((co) autor) Utilizarea resurselor facultăţii

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.

22

Modele de Dezvoltare

Pentru a dezvolta un program este nevoie de: O înţelegere clară a ceea ce se cere Un set de metode şi instrumente de lucru Un plan de acţiune

Plan de acţiune = şablon = model de dezvoltare

23

Etapele Dezvoltării Programelor

Analiza cerinţelorProiectarea arhitecturalăProiectarea detaliatăScrierea codului Integrarea componentelorValidareVerificare Întreţinere

24

Analiza Cerinţelor

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 Comunicare Negociere Sfătuirea clientului

25

Proiectarea Arhitecturală Proiectarea arhitecturală

Din motive de complexitate, programele mari nu pot fi concepute şi implementate ca o singură bucată

Programul este împărţit în module sau componente mai simple, care pot fi abordate individual

Proiectarea detaliată Se proiectează fiecare modul al aplicaţiei, în

cele mai mici detalii

26

Implementare, Integrare

Implementare Proiectul detaliat este transpus intr-un limbaj

de programare Acesta se realizează modular, pe structura

rezultată la proiectarea arhitecturală Integrare

Modelul big-bang Modelul incremental

27

Validare şi Verificare

Validare: ne asiguram ca programul îndeplineşte cerinţele utilizatorului. Construim produsul corect?

Verificare: ne asigurăm că programul este stabil şi că funcţionează corect din punctul de vedere al dezvoltatorilor. Construim corect produsul?

28

Întreţinere

După livrare Sunt descoperite greşeli ce trebuie

reparate Pot apare schimbări în specificaţii Pot apare noi cerinţe

Întreţinere = gestionarea acestor tipuri de probleme

29

Modele de dezvoltare Cum efectuam activităţile indicate de etapele

dezvoltarii programelor Exemple de modele de dezvoltare:

Ad-hoc: descurca-te cum poţi Modelul în cascadă (cu feedback) Prototipizare Metode formale Modelul în spirală RUP (Rational Unied Process) XP (Extreme Programming)

30

Modelul în cascadăIngineria Cerinţelor

Proiectarea Arhitecturală

Proiectarea Detaliată

Implementare

Testarea Unităţilor

Testarea Sistemului

Acceptare

31

Modelul în cascadă

+: Împarte o sarcină complexă în paşi mai mici

+: Uşor de administrat şi controlat +: Fiecare pas are ca rezultat un

produs bine definit -: Erorile se propagă între paşi -: Nu exista mecanisme de reparare a

erorilor

32

Modelul în cascadă cu întoarcere

Ingineria Cerinţelor

Proiectarea Arhitecturală

Proiectarea Detaliată

Implementare

Testarea Unităţilor

Testarea Sistemului

Acceptare

33

Modelul în Cascadă cu Întoarcere

+: Oferă cadrul pentru remedierea erorilor din pasul precedent

-: Erorile la pasul i care sunt descoperite la pasul i + 2 nu sunt remediate

-: Clientul vede produsul final abia la sfârşitul dezvoltării

34

Modelul în Spirală Studiul de fezabilitate Analiza cerinţelor Proiectarea arhitecturii Implementarea

Pentru fiecare pas, se fac următoarele activităţi:

1 : pregătirea[take stock]

2 : gestiunea riscului[dealing with risk]

3 : dezvoltarea[development]

4 : planificareaurmătorului stagiu[planning]

35

Modelul în Spirală

+: Păstrează avantajele modelului în cascadă

+: Ia în calcul noţiunea de risc Exemple de riscuri:

O firmă concurentă lansează un produs rival Un arhitect părăseşte echipa Clientul schimba cerinţele O echipă nu respecta termenele de livrare

36

Prototipizare

Tipuri de prototipuri De aruncat (throw-away)

Scop: clarificarea specificaţiilor Se dezvoltă repede, orice altceva e secundar (quick-

and-dirty) Util în a rezolva “architecural/technology spikes” Programul “adevărat” este scris apoi de la 0

Evoluţionar Scop: construire incrementală a produsului final Se construieşte un nucleu funcţional la care se

adaugă apoi noi funcţionalităţi

37

Prototipizare Avantaje

Se poate elimina lipsa de claritate a specificaţiilor Clienţii pot schimba cerinţele (e ieftin de gestionat) Întreţinere ieftină (verificare pe parcurs) Se poate facilita instruirea utilizatorilor

Dezavantaje Mediu artificial, probleme ascunse Da' nu-i aproape gata?! De ce mai durează atât? Putem să schimbăm specificaţiile? Pai aş vrea şi... Adică munca mea este aruncată la gunoi?

38

Extreme Programming 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 PowerPoint nu se pot compila).

39

Idei majore in XP 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.

40

Revenim...

Etapele dezvoltării programelor Analiza cerinţelor Proiectarea Scrierea codului Testare Întreţinere

Toate etapele dezvoltării programelor depind de analiza cerinţelor.

41

Începutul unui proiect Un proiect poate începe:

cu o idee a clientului cu o idee a unei echipe de dezvoltare

Aceasta idee poate fi: clara, bine definita vaga, prost definita

Pentru a continua cu succes, este nevoie de ingineria cerintelor.

42

Specificaţia bună 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.

43

Detalii de implementare la analiză?

NU Clientul nu este competent in detalii tehnice Clientul nu poate fi de acord in cunostinta de cauza cu

stipularile tehnice din specificatii (Stiu secretarele COM? Stiu soferii ciclul Carnot?).

E necesar sa restrangem multimea posibilelor solutiile tehnice?

DA Este nevoie sa integram intr-un sistem existent Timpul de dezvoltare depinde de implementare Intretinerea (costul) depinde de implementare

44

Responsabilităţile Analistului 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.

45

Activităţile Analistului

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.

46

Probleme Potenţiale

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

47

Rezultatul Analizei Document de specificare a cerintelor Acest document este folosit ca referinta Provocari

Nivelul de detaliu Mare: mai precis, obtinut mai greu, munca inutila Mic: prea vag, nu poate ghida eficient dezvoltarea

Audienta documentelor 2 versiuni: una pentru client, alta pentru dezvolatori?

Notatia folosita Informala, semiformala, formala

48

Tipuri de Cerinţe Cerinte functionale

Ce trebuie sa faca sistemul Cerinte privind datele

Formatul datelor la intrare/iesire Formatul datelor din interiorul sistemului

Constrangeri Cerinte de respectat ad-literam Influenteaza direct implementarea

Recomandari Ajuta la luarea deciziilor de proiectare cand sunt mai

multe optiuni

49

Exemple Cerinte functionale

Sistemul se va opri in maxim 5 secunde dupa ce temperatura procesorului atinge 80 grade Celsius.

Sistemul va permite cautarea si afisarea titlurilor cartilor scrise de un anumit autor.

Cerinte privind datele Datele vor fi exportate in format XML Datele din tampoanele de intrare si iesire vor fi criptate

Constrangeri Implementarea se va realiza folosind un limbaj orientat obiect. Metodologia de dezvoltare va fi Prototipizare

Recomandari Se va folosi cat mai putina memorie

50

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