Ingineria software – teorie

1. Problemele ingineriei software

- Satisfacerea cerintelor clientilor
- Costul produsului
- Varietatea din practica
- Lipsa productivitatii

2. Etapele de dezvoltare a unei aplicații software

- Analiza – model formal/abstract
- Proiectare – model structural si comportamental
- Implementare
- (Integrare)
- Testare
- Mentenanta

Modelare structurala
- Diagrama claselor si a obiectelor

Modelarea comportamentala
- Diagrama de interactiune
o Diagrama de secventa
o Diagram de colaborare
- Diagrama de stare
- Diagrama de tip activitate
- Diagram de tip caz de utilizare
3. Limbajul UML. Generalitați
- un limbaj pentru construirea, specificarea, vizualizarea şi
documentarea modelelor.
- poate fi folosit in diverse domenii
- a evoluat din mai multe limbaje existente
- este fuziunea metodologiilor dezvoltate de Grady Booch,
James Rumbaughşi Ivar Iacobsen

4. UML – Diagrama claselor

- Diagrama claselor defineşte modelul structural al unui sistem
prin intermediul unui graf, ale cărui noduri (vârfuri)
reprezintă clasele, iar arcele reprezintă legăturile dintre
clase.

- arata relatiile dintre clase de tipul: mostenire, agregare si

asociere, precum si operatiile si atributele aferente fiecareia.
Element Descriere Notaţie
O clasă este reprezentată printr-un dreptunghi cu trei
compartimente: în cel de sus se trece numele clasei, în mijloc
Clasă
se trec atributele clasei iar jos se trec operaţiile specifice
clasei.

Moştenirea este o relaţie care indică faptul că o clasă

Moştenire
moşteneşte caracteristicile unei clase părinte.

Asocierea este o relaţie generică între două clase. Aceste

Asociere relaţii pot fi de tipurile unu la unu, unu la mulţi, mulţi la
mulţi.

Atunci când o clasă depinde de o altă clasă, în sensul că

Dependenţă utilizează acea clasă ca şi atribut al său, se foloseşte relaţia
de dependenţă.

Agregarea indică o relaţie de tip întreg-parte (se poate spune

Agregare despre clasa părinte că are clase de tip copil). În această
relaţie, clasa copil poate exista şi fără clasa părinte.

Această relaţie derivă din agregare dar se utilizează atunci

Compoziţie când o clasă copil nu poate exista decât în cazul existenţei
clasei părinte.

- În reprezentarea clasei atributele şi operaţiile sunt declarate

în compartimentele speciale:
o atributele: numele atributului: tipul atributului =
valoare implicit
o operaţiile: numele operaţiei (parametri): tipul valorii
returnate
5. UML – Diagrama obiectelor
- diagrama obiectelor reprezintă structura statică a sistemului
la un moment particular de timp, folosind instanţe ale
claselor (obiecte) şi instanţe ale legăturilor dintre clase
existente în acel moment, folosind, de asemenea, un graf.
- diagramele claselor şi ale obiectelor se reprezintă folosind
elemente structurale şi elemente de legătură

6. UML – Diagrama secventelor

Diagrama de interactiune
- Reprezintă modul în care obiectele (instanţe ale claselor)
interacţionează între ele
- se reprezintă obiecte şi mesajele dintre acestea
- mesajul - este o specificare a unei comunicaţii între obiecte
care au o anumită legătură
- un obiect poate juca rol de client, server (furnizor) sau rol
dual (agent)
- pentru ca un obiect client să trimită un mesaj unui obiect
server, trebuie ca obiectul server să fie vizibil obiectului client
- obiectul server este global sau se află în domeniul de
definiţie al obiectului client
- există o legătură între clasele obiectelor server şi client
- aproape orice legătură între clase permite transmiterea unui
mesaj de la client la server

Diagrama secventelor
- se pune accentul pe ordinea temporală a mesajelor
schimbate între obiecte
- pe axa verticală se reprezintă timpul
- pe axa orizontală se reprezintă o listă de obiecte între care au
loc transferuri de mesaje
- timp de viaţă (Object Lifeline)
 - simbol de activare (Activation) – dreptunghi aflat la
intersecţia mesajului transmis cu linia de viaţă a obiectului

7. UML – Diagrama de stare

- reprezintă stările pe care obiectele (instanţe ale unei clase) le
pot avea şi tranziţiile între aceste stări.
- este utilă pentru descrierea claselor care au unul sau mai
multe atribute ale cărui valori au semnificaţii precise şi
modificarea acestor valori implică diferenţe de comportare a
obiectelor.
- o stare a unui obiect se reprezintă printr-un dreptunghi cu
colţurile rotunjite în care se înscrie denumirea stării
obiectului.
- starea iniţială (Initial State) se reprezintă printr-un cerc, plin
sau gol, depinde de aplicaţia folosită.
- o tranziţie între două stări se reprezintă printr-o linie
continuă care are o săgeată la capătul dinspre starea finală a
tranziţiei.
- lângă o linie de reprezentare a unei tranziţii se poate înscrie
numele metodei care provoacă tranziţia sau condiţiile (în
funcţie de valori ale atributelor) care produc tranziţia
respectivă.
- starea finală este reprezentată printr-un cerc plin inclus intr-
un alt cerc gol.

8. Uml – Diagrama de tip activitate

-sunt variante ale diagramelor de stare care reprezintă fluxul de lucru al
unei activităţi executate de un obiect

-elementele folosite sunt:

- Stări de acţiune (action state): reprezintă o acţiune executată
de un obiect (procedură, funcţie).
 o Reprezentate printr-un dreptunghi rotunjit la colţuri
- Tranziţii: treceri de la o acţiune la alta.
o Reprezentate printr-o săgeată
- Puncte de ramificare de decizie (branch) si unificare după
decizii (un-branch)
o Reprezentate printr-un romb
- Puncte de ramificare a acţiunilor concurente (fork, thread) cu
puncte de join corespunzătoare.
o Reprezentate printr-un dreptunghi cu lungimea mult
mai mare decat lăţimea, plin.

9. Metodologii de dezvoltare a sistemelor software. Generalitati

O metodologie de lucru pentru un produs software reprezinta modul de
structurare, planificare si control al procesului de dezvoltare.

- Metodologie (sau metoda) – o anumita colectie de principii si/sau

practici
- Familie de metodologii – un set de metode alternative care coexista
- Framework – un schelet (pentru metode) care trebuie dezvoltat sau
personalizat inainte de utillizare
- Model – o descriere (pentru metode) care trebuie implementata de o
metoda, familie sau framework.

10. Metodologii de dezvoltare a sistemelor software. Aspecte

specific fiecarui model

1. Code and fix(codeaza si repara)

- este cea mai rapidă şi mai puţin eficientă metodă de
dezvoltare a aplicaţiilor.
2. Metodologia secventiala
3. Metodologia cascada

4. Metodologia ciclica

5. Metodologia spirala
o Ciclul 1 – Analiza preliminară
 Obiective, alternative, constrângeri
  Analiza riscului şi prototipul
 Conceperea operaţiilor
 Cerinţele şi planul ciclului de viaţă
 Obiective, alternative, constrângeri
 Analiza riscului şi prototipul
o Ciclul 2 – Analiza finală
 Simulare, modele
 Cerinţe software şi validare
 Plan de dezvoltare
 Obiective, alternative, constrângeri
 Analiza riscului şi prototipul
o Ciclul 3 – Proiectarea
 Simulare, modele

6. Metodologia hibrida ecluza

7. Prototipizarea
→ Abandonabil – doar obţinerea unei specificaţii
→ Evoluţionar – crearea unui schelet al aplicaţiei
8. Modelul V

9. Metoda de programare ”agila”

- Metoda de programare „agilă” este potrivită dezvoltării
rapide de aplicaţii
o Principiile metodelor agile:
o Implicarea clientului
o Livrarea incrementală
o Oamenii nu procesul
o Acceptarea schimbării
o Menţinerea simplităţii

10. Extreme Programming

- Caracteristici:
o Echipa de dezvoltare nu are o structură ierarhică;
fiecare contribuie la proiect folosind maximul din
cunoştinţele sale
o Proiectul este în mintea tuturor programatorilor din
echipă, nu în documentaţii,modele sau rapoarte
o Cerinţele clientului sunt exprimate ca scenarii sau
povestiri (“user stories”)
 o Acestea sunt scrise pe bileţele iar echipa de dezvoltare
le împarte în sarcini de implementare (care stau la baza
planificării orarului de lucru şi a estimării costurilor
o La orice moment, un reprezentant al clientului este
disponibil pentru clarificarea cerinţelor
o Scrierea de cod este activitatea cea mai importantă
o La fiecare pas se face numai ce este absolut necesar în
momentul următor
o Codul se scrie cât mai simplu şi se optimizează
(refactoring) de câte ori e posibil
o Se scrie mai întâi cod de test
o Modificările aduse codului sunt integrate continuu (de
câteva ori pe zi)
o Se programează în echipă (programare în perechi);
echipele se schimbă la sfârşitul unei iteraţii (1-2
săptămâni)
o Se lucrează 40 de ore pe săptămână, fără lucru
suplimentar

11. Metodologia Open Source

Codul sursă este transmis utilizatorului final într-o manieră
non-proprietară (fără patent), pe baza unei licenţe open-
source (gen GNU)

12. Reverse Engineering

Se analizează sistemele anterioare şi se încearcă
reutilizarea componenelor existente Software, hardware,
documentaţie, metode de lucru.

13. Metodologia de dezvoltare Offshore

Companiile folosesc outsourcing-ul pentru funcţiile care pot fi
dezvoltate mai ieftin în altă ţară.
Etape
 1. Iniţierea proiectului (local)
2. Analiza cerinţelor (local)
3. Proiectarea de nivel înalt (local)
4. Proiectarea detaliată (offshore)
5. Implementarea (offshore)
6. Testarea (offshore sau local)
7. Livrarea (local)

11. Ciclul de viata a unui proiect

Ciclu de viata = ansamblul etapelor parcurse în dezvoltarea unui produs
software.
Etapele ciclului de viata:
- Culegerea de specificatii
- Analiza
- Proiectarea
- Implementarea si Testarea
- Validare si Integrare
- Calificare
- Punerea în functiune
- Mentinerea
- Retragerea sau înlocuirea

12. Programare vizuala in Java. Aspecte fundamentale

- Ferestre - un obiect al clasei JFrame, care se gaseste in
pachetul javax.swing

- Clasa Container - In general ferestrele contin o gama variata

de obiecte (butoane, meniuri, texte, …). Structura care retine
referintele catre obiectele ce se afla pe fereastra este un
obiect al clasei Container. Accesul la container-ul unei
ferestre se face utilizand o metoda din JFrame, numita
getContentPane(), care returneaza o referinta catre
containerul ferestrei.
 - Compoentte de tip JTextField - Edit-urile sunt folosite pentru
ca utilizatorul sa introduca sau sa afiseze siruri de caractere.

- Afisarea vizuala a datelor - Afisarea datelor poate fi realizata

folosind o cutie de dialog.

13. Metode de testare. Exemple

- Functuinala(black box): bazata pe cerinte(specificatie) - Nu se
bazeaza pe cunoasterea interna a design-ului sau a codului .
Testele sunt bazate pe cerinte si functionalitate.

o Datele de test sunt generate pe baza specificatiei

(cerintelor) programului, structura programului
nejucand nici un rol
o Tipul de specificatie ideal pentru testarea functionala
este alcatuit din pre-conditii si post-conditii
o Majoritatea metodelor functionale se bazeaza pe o
partitionare a datelor de intrare astfel incat datele
apartinand unei aceeasi partitii vor avea proprietati
similare (identice) in raport cu comportamentul
specificat.

- Structurala(white box): bazata pe program(implementare) -

Se bazeaza pe cunoasterea logicii interne a codului aplicatiei.
o datele de test sunt generate pe baza implementarii
(programului), fara a lua in considerare specificatia
(cerintele) programului
o pentru a utiliza metode structurale de testare
programul poate fi reprezentat sub forma unui graf
structurat
o datele de test sunt alese astfel incat sa parcurga toate
elementele (instructiune, ramura sau cale) grafului
macar o singura data. In functie de tipul de elemente
ales, vor fi definite diferite masuri de acoperire a
grafului: acoperire la nivel de instructiune, acoperire la
nivel de ramura sau acoperire la nivel de cale
14. Verificare si validare
Verificarea: software-ul trebuie sa fie conform cu specificatiile.
Validarea: software-ul trebuie sa faca ceea ce utilizatorul are nevoie.

- Scop: verificarea si validarea trebuie sa stabileasca gradul in

care software-ul se potriveste scopului sau.

Procesul de verificare se desfasoara pe intreaga durata de viata a

sistemului. Are doua obiective principale:

- Descoperirea defectelor de system;

- Evaluarea masurii in care sistemul este util si utilizabil intr-o
situatie operationala.

15. Testarea aplicatiilor web. Aspecte specifice

Testarea aplicatiilor web este diferita de testarea produselor
software traditionale, lucru datorat caracteristicilor specifice
aplicatiilor web:
- erorile din 'continut' pot fi deseori gasite doar prin masuri
costisitoare sau organizationale;
- cand testam structura hipertext, trebuie sa ne asiguram ca
paginile sunt legate in mod corect (de exemplu, fiecare
pagina trebuie sa fie accesibile printr-o legatura si, la randul
sau, ar trebui sa aiba o legatura inapoi la structura hipertext).
- cerintele soft, subiective de pe nivelul prezentare al
aplicatiilor web (de exemplu,'estetica'), sunt dificil de
specificat.
- ........

16. Applet-uri in Java

Un applet este un program mic care ruleaza in interiorul unui
browser Web.
Un applet reprezintă o suprafaţă de afişare (container) ce poate fi
inclusă într-o pagina Web şi
 gestionată printr-un program Java. Un astfel de program se mai
numeşte miniaplicaţie.
Codul unui applet poate fi format din una sau mai multe clase. Una
dintre acestea este principală şi extinde clasa JApplet, fiind clasa ce
trebuie specificată în documentul HTML ce descrie pagina de Web în
care dorim să includem applet-ul.

Functiile unui applet:

- Incarcarea in memorie – se creeaza o instanta a clasei
principale a applet-ului si se incarca in memorie.
- Initializarea – se apeleaza metoda ”init” responsabila cu
initializarea diverselor variabile etc si cu asezarea tuturor
componentelor in forma.
- Pornirea – se apeleaza metoda ”start”
- Executia propiu-zisa – interactiunea dintre utilizator si
componentele afisate pe suprafata applet-ului.
- Oprirea temporara – se apeleaza metoda ”stop” atunci cand
utilizatorul paraseste pagina web, iar cand pagina devine
avtiva se va reapela metoda ”start”.
- Oprirea definitiva – appletul este eliminate din memorie si se
apeleaza metoda ”destroy” care este precedata de apelul
metodei ”stop”.

17. Pachete Java

Un pachet este alcatuit dintr-una sau mai multe clase si eventual din
unul sau mai multe pachete.
Idea de baza pentru crearea pachetelor este de a permite celor ce
scriu programe sa utilizaza clasele respective sau numai unele metode
continute de aceste clase.