Faza de implementare

Ingineria programării
11. Faza de implementare
Florin Leon
Universitatea Tehnică „Gheorghe Asachi” din Iași
Facultatea de Automatică și Calculatoare
http://florinleon.byethost24.com/curs_ip.htm
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de implementare
1. Introducere
2. Procesul de implementare
3. Refactorizarea
4. Analiza statică
5. Metrici de implementare
6. Anti-șabloane de implementare
7. Managementul configurației
8. Concluzii

4
Faza de implementare
 Implementarea este faza în care este produs codul
corespunzător proiectului
 Se îndeplinesc restricțiile de resurse, acuratețe și performanță
indicate de specificații
 Sistemul este construit ori plecând de la zero, ori prin
asamblarea unor componente pre-existente
 De cele mai multe ori proiectarea nu va realiza o
transformare de 1 la 1 către implementare
 Este necesar un oarecare efort pentru a scrie codul
corespunzător, iar aceasta este o sursă de erori
 Erorile de proiectare determină pierderea timpului
programatorilor în a rezolva probleme puse greșit

5
Erori
 Implementarea însăși este predispusă către
erori, fiind un proces creator uman
 Un programator are 50% șanse să descopere
o eroare într-un interval de 5-10 linii de cod și
numai 20% șanse să o descopere într-un
domeniu de 40-50 de linii

6
Documente
 Documentele de bază produse în această
fază sunt:
 Codul sursă comentat, respectând anumite
convenții
 Diagrame ale produsului software
 Manualul de utilizare
 Planul pentru coordonarea configurației
(versionare)

7
Clase de limbaje
 Din punct de vedere al semanticii, sunt larg
recunoscute următoarele clase mari de limbaje:
 Limbaje imperative (procedurale): cum se execută
prelucrările
 Fortran, Basic, Pascal, C, C++, Java, C#
 Limbaje declarative: ce trebuie realizat
 Subparadigma funcțională: Lisp (de exemplu, dialectele Scheme,
Common Lisp), F# (Ten things F# can do, and C# can’t,
https://www.youtube.com/watch?v=hMjv8m--W28)
 Subparadigma logică: Prolog
 Reguli și potrivirea modelelor: Clips, Jess, Drools

8
Programarea: știință sau artă?
 Artă
 Construirea unor produse care pot acționa asupra
simțămintelor
 Tradițional, orice talent sau măiestrie (gr. τέχνη)
 Ştiință
 Adunarea de probe prin observații și experimente
măsurabile și repetabile
 Formularea de ipoteze și testarea acestora

9
Landon Curt Noll & Larry Bassel
International Obfuscated C Code Contest, 1988

10

11
 Competiție de scripturi JavaScript de 1 KB
(http://js1k.com)

12
JS1k: The JavaScript code
golfing competition, 2010
Óscar Toledo G.: nanochess
http://nanochess.org

13
 Rgba and TBC: Elevated
 4 KB exe, Breakpoint 2009, http://www.rgba.org

15
Scopul implementării
 Implementarea afectează atât testarea cât și
întreținerea
 Efortul de testare este 30-50% din efortul de
dezvoltare
 Rata de efort întreținere-dezvoltare: 60:40 - 80:20
 Scopul nu este diminuarea costurilor de
implementare, ci a costurilor fazelor ulterioare
 Programele nu trebuie să fie ușor de scris,
ci ușor de citit și înțeles

16
Experimentul Weinberg
 Când programatorii primesc un obiectiv clar, de
obicei îl îndeplinesc
 Îndeplinirea unui obiectiv afectează alte obiective
 Compromisuri

17
Implementarea incrementală
 Simplifică testarea și depanarea
(engl. “debugging”)

19
Refactorizarea
 engl. “refactoring”
 Schimbările succesive conduc la o structură suboptimă a codului
 Crește complexitatea
 Scade claritatea
 Refactorizarea este o schimbare în structura internă a unui
produs software cu scopul de a-l face mai ușor de înțeles și de
modificat fără a-i schimba comportamentul observabil
 Este o formă de proiectare incrementală
 Rezultate:
 Scăderea cuplării
 Creșterea coeziunii
 Respectarea principiului deschis-închis

20
Refactorizarea
 Schimbările pot introduce noi defecte
 Refactorizarea trebuie efectuată în pași mici
 Trebuie să existe teste care să indice locurile unde apar erori
 Refactorizarea nu se referă la introducerea de noi
funcționalități
 Cele două activități sunt diferite și trebuie separate
 Refactorizarea îmbunătățește structura, nu codul
 Codul prost scris nu trebuie refactorizat, ci rescris
 Refactorizarea nu trebuie să introducă niveluri de
complexitate inutile
 Costurile suplimentare ale refactorizării sunt compensate de
economiile ulterioare

Semnale pentru refactorizare
 Următoarele situații sunt semnale pentru necesitatea
refactorizării (engl. “code smells”):
 Cod duplicat
 Metode lungi
 Clase mari
 Liste lungi de parametri
 Instrucțiuni condiționale care determină diferențele de
comportament: se recomandă polimorfismul
 Generalitate speculativă: ierarhie de clase în care subclasele au
același comportament
 Comunicare intensă între obiecte: cuplare puternică
 Înlănțuirea de mesaje: cuplare inutilă
21

22
Optimizarea metodelor
 Scop: simplificarea și creșterea coeziunii
 Prin simplificarea interfeței, scade și cuplarea
 Extragerea de metode
 Pentru o metodă lungă, o parte a metodei este
transformată într-o nouă metodă
 Unele din variabilele primei metode devin parametri pentru
a doua
 O metodă care schimbă starea unui obiect și returnează o
valoare trebuie partiționată într-o metodă care schimbă
starea și o metodă care returnează o valoare

23
Optimizarea metodelor
 Adăugarea de parametri
 Când o metodă trebuie să îndeplinească
funcționalități noi și are nevoie de mai multe
informații
 Ștergerea de parametri
 Când nu toți parametrii sunt folosiți efectiv

24
Optimizarea claselor
 Scop: creșterea coeziunii și reducerea cuplării
 Mutarea metodelor
 Când o metodă din clasa A interacționează mult cu obiectele
clasei B, metoda poate fi mutată în clasa B
 Dacă este posibil, metoda din clasa A trebuie eliminată cu totul
 Dacă nu, în clasa A poate fi păstrat un „proxy” care să delege
apelurile
 Mutarea câmpurilor
 Dacă un câmp din clasa A este folosit mai des de către metodele
clasei B, câmpul poate fi mutat în clasa B
 Câmpul fiind privat, referințele din clasa A trebuie modificate iar
în clasa B trebuie să se introducă proprietăți accesor (get) și
mutator (set)

25
Optimizarea claselor
 Extragerea de clase
 De obicei, pe parcursul implementării, funcționalitatea
claselor este extinsă
 O clasă poate ajunge să aibă prea multe responsabilități
 Se creează o nouă clasă și apoi se aplică refactorizările de
metode și câmpuri
 Dacă există o cuplare puternică între cele două clase
rezultate, înseamnă că partiționarea este artificială
 Înlocuirea valorilor de date cu obiecte
 Dacă asupra unor câmpuri se efectuează operații multiple,
acestea pot fi convertite în obiecte

26
Optimizarea ierarhiilor
 Scop: utilizarea polimorfismului pentru a facilita
extensiile ulterioare
 Înlocuirea instrucțiunilor condiționale după flag-uri
sau tipul obiectelor cu clase polimorfice
 „Ridicarea” câmpurilor și/sau metodelor
 Elementele comune sunt incluse în clasele părinte
 Elementele variabile sunt incluse în clasele fiu
 Invers, „coborârea” câmpurilor și/sau metodelor pe
nivelurile unde sunt relevante

27
Exemplu
 Situația matricolă a studenților
 Structura inițială
GradReport are un vector de obiecte Student
Student are vectori pentru toate cursurile

28
Prima refactorizare
Se transformă vectorii în obiecte
CourseTaken este cursul urmat de student;
dacă a picat, l-a urmat de mai multe ori
Course este un curs din planul de învățământ

29
A doua refactorizare
Se elimină informațiile
redundante: Student
avea câmpurile DOB
(data nașterii) și Age
Funcționalitatea se
mută acolo unde
există cele mai multe
informații: clasa
CourseTaken are
metoda printGrade

30
A treia refactorizare
Se înlocuiește câmpul
pg_or_ug cu o ierarhie
Thesis rămâne doar
pentru nivelul de licență

31
Utilitare
 JetBrains Resharper, integrat cu mediul de dezvoltare
Visual Studio, care permite:
 Evidențierea erorilor
 Refactorizarea
 Navigarea și căutarea mai ușoară
 Formatarea și curățarea codului
 Generarea automată de cod
 Suport pentru testarea unităților
 https://www.jetbrains.com/resharper/features
 CodeMaid, plug-in pentru Visual Studio
 http://www.codemaid.net

32
Analiza codului

33
Analiza codului
IList : IEnumerable

34
Navigarea și căutarea

35
Refactorizarea
 Schimbarea semnăturii unei metode
 Convertirea unei clase abstracte într-o interfață și
viceversa
 Convertirea proprietăților sau indexatorilor în metode și
viceversa
 Introducerea de câmpuri, variabile locale sau parametri
 Extragerea de interfețe și metode
 Mutarea membrilor mai sus sau mai jos în ierarhie
 Încapsularea câmpurilor
 Redenumiri

36
Asistența la scrierea de cod

37
Asistența la scrierea de cod

38
Curățarea codului

39
Curățarea codului

40
Șabloane

42
Analiza statică și dinamică
 Analiza statică verifică reprezentarea sistemului
pentru a descoperi eventualele probleme, de
exemplu analiza codului sursă
 Analiza dinamică se ocupă cu rularea și
observarea comportamentului programului în
timpul execuției

43
Analiza statică
 Analiza automată a unui program pentru detectarea
erorilor potențiale și pentru generarea de informații utile
la depanare
 Compilatoarele realizează o analiză statică restrânsă, în vederea
generării executabilului
 Instrumentele dedicate au ca scop principal detectarea defectelor
 Caracteristici ale analizoarelor statice:
 Corectitudinea (engl. “soundness”): sunt corecte dacă nu
detectează situații fals pozitive
 Completitudinea (engl. “completeness”): sunt complete dacă nu
ratează unele defecte existente
 Este necesar un compromis

44
Analiza statică automată
 Analizoarele statice sunt instrumente software
pentru prelucrarea codului sursă
 Ele parsează textul programului și încearcă să
descopere condiții potențial eronate

45
Verificări în analiza statică
 Defecte de date
 Variabile utilizate înainte de inițializare; situația
este posibilă în C/C++, dar nu și în C#
 Variabile declarate, dar nefolosite
 Variabile atribuite de două ori, dar nefolosite între
atribuiri
 Variabile nedeclarate
 Posibile violări ale limitelor de vectori

46
 Defecte de control
 Cod care nu poate fi atins
 Ramificări necondiționale în bucle
 Defecte de intrare/ieșire
 Variabile trimise la ieșire de două ori fără atribuiri
intermediare

47
 Defecte de interfață
 Nepotriviri de tip la parametri
 Nepotriviri la numărul de parametri
 Neutilizarea rezultatelor unor funcții
 Metode neapelate
 Defecte de stocare
 Pointeri neatribuiți
 Aritmetică de pointeri

48
Abordarea 1
 Căutarea tiparelor
neobișnuite în cod:
 Operații idempotente
(o variabilă intră într-o
operație cu ea însăși)
 Atribuiri neutilizate
 Cod ne-executabil
 Ramuri condiționale
imposibil de atins

Abordarea 1
 Experimentele asupra multor sisteme software
utilizate pe scară largă au indicat că 20-50% din
atenționări sunt fals pozitive
 Există totuși o corelație puternică între
problemele de acest fel descoperite și erorile
reale din programe
49

50
Abordarea 2
 Căutarea explicită a defectelor
 Folosirea memoriei
neinițializate
 Dereferențierea pointerilor
neinițializați
 Dereferențierea pointerilor nuli
 Dereferențierea pointerilor
invalizi
 Dereferențierea sau returnarea
pointerilor la memorie eliberată
 Scurgeri de memorie sau alte
resurse, de exemplu fișiere
 Returnarea pointerilor la
variabile locale din stivă
 Diviziuni cu 0
• dacă size = 1, result nu este dezalocat
(scurgere de memorie)
• dacă size ≤ 0, se accesează
(dereferențiază) pointerul neinițializat
în linia 10
• dacă malloc nu poate aloca memorie,
se dereferențiază pointerul neinițializat

51
Utilizarea analizei statice
 Valoroasă mai ales când se folosește un limbaj
slab tipizat precum C-ul, unde multe erori nu
sunt detectate de compilator
 Mai puțin necesară în cazul limbajelor puternic
tipizate precum C# sau Java, care pot detecta
multe erori la compilare

52
FxCop
 FxCop este un instrument de analiză statică a codului care verifică assembly-urile
.NET în conformitate cu recomandările companiei Microsoft

54
Metrici
 Măsuri pentru:
 Dimensiune
 Complexitate

55
Metrici de dimensiune
 Dimensiunea ca număr de linii de cod
 Ce este o linie de cod?
 engl. “line of code”, LOC
 În general, o linie nevidă, care nu este comentariu
 Măsură corelată cu productivitatea, costul și
calitatea (defecte / KLOC)
 Bunele practici curente: mai puțin de 1 defect / KLOC

Metrici de complexitate
 Complexitatea indică nivelul de dificultate la
înțelegerea unui modul
 Metrici:
 Dimensiunea: complexitatea crește cu dimensiunea
codului și cu numărul de decizii
 Complexitatea ciclomatică: M = e – n + 2p
 vezi cursul 4, Faza de proiectare, secțiunea Proiectarea
detaliată
56

57
Variabile vii
 engl. “live variable”
 Pentru a scrie sau citi instrucțiunile, un programator trebuie
să țină minte o serie de variabile, inclusiv altele decât cele
implicate direct în instrucțiunea curentă
 O variabilă este vie de la prima până la ultima referențiere
dintr-un modul, incluzând toate instrucțiunile intermediare
 Pentru o instrucțiune, numărul de variabile vii reprezintă o
măsură a dificultății de înțelegere a acelei instrucțiuni
 Extindere la un modul: definirea numărului mediu de
variabile vii

58
Anvergura
 engl. “span”
 Numărul de instrucțiuni dintre 2 utilizări succesive ale
unei variabile
 Dacă o variabilă este referențiată de n ori, atunci are
n – 1 anverguri
 Anvergura medie este numărul mediu de instrucțiuni
executabile dintre 2 referiri succesive ale unei variabile
 Cu cât anvergura este mai mare, cu atât modulul este
mai complex

Discuție
 Complexitatea ciclomatică este definită doar pe
baza logicii de control
 Variabilele vii și anvergura sunt definite doar din
punct de vedere al utilizării datelor
59

60
Metrici în .NET Reflector

62
Anti-șabloane de programare
 Accidental complexity
(complexitatea accidentală)
 Action at a distance
(acțiunea la distanță)
 Blind faith (credința oarbă)
 Boat anchor (ancora de
vapor)
 Busy waiting (așteptarea
activă)
 Caching failure
(depozitarea eșecului)
 Cargo cult programming
 Coding by exception
(codarea prin excepții)
 Error hiding (ascunderea
erorilor)
 Expection handling
 Hard code
 Magic numbers (numerele
magice)
 Lava flow
 Spagetti code
Pentru explicații, vezi suportul de curs

63
Anti-șabloane metodologice
 Copy and paste programming
 Improbability factor (factorul de improbabilitate)
 Low hanging fruit
 Premature optimization (optimizarea prematură)
 Programming by permutation (programarea prin
permutări)
 Reinventing the wheel (reinventarea roții)
 Reinventing the square wheel (reinventarea roții pătrate)
Pentru explicații, vezi suportul de curs

65
Managementul configurației
 Pe parcursul ciclului de viață al unui proiect de
dezvoltare software sunt create și actualizate un
mare număr de elemente, precum module de
cod sursă, cerințe de modificare etc.
 Pentru gestionarea acestora trebuie să existe un
set de proceduri bine definite, care poartă
numele de managementul configurației

66
Definiții (standarde IEEE)
 Linie de bază (engl. “baseline”)
 O specificație sau un produs care a fost analizat și
acceptat în mod formal, care servește în continuare ca
bază pentru dezvoltarea viitoare și care poate fi modificat
numai prin proceduri formale de control al modificărilor
 Articole de configurație (engl. “configuration items”)
 O colecție de elemente hardware sau software tratate ca o
unitate în scopul gestionării configurației
 Exemple: fișiere sursă, module de cod obiect, specificarea
cerințelor, documentația de proiectare, planul, cazurile și
rezultatele testării, manualul utilizatorului etc.

67
Controlul formal al modificărilor
 O cerere de modificare este trimisă comisiei de control
al configuraţiei
 Comisia evaluează cererea, care poate fi aprobată,
respinsă sau amânată dacă sunt necesare mai multe
informaţii
 Dacă este aprobată, se stabileşte un termen de
implementare
 Comisia se asigură că toate articolele de configuraţie
afectate de schimbare vor fi actualizate corespunzător

68
Noțiuni
 Controlul surselor
 Reține structura directoarelor și fișierelor de cod sursă
ale proiectului dezvoltat și gestionează modificările și
accesul concurent la acestea
 Controlul versiunilor
 Un sistem de control al surselor care memorează
modificările făcute asupra fișierelor și permite
inspectarea, regăsirea și compararea oricăror variante
(versiuni) ale unui fișier pe durata întregului ciclu de
dezvoltare

69
Numerotarea versiunilor
 Schema GNU: versiunea majoră, versiunea minoră și patch-ul
(tripletă de întregi)
 Între două versiuni majore, în produs au loc schimbări majore ale
funcționalității și nu este garantată compatibilitatea înapoi
 Între două versiuni minore ale aceleiași versiuni majore trebuie să existe
compatibilitate
 Rolul unei versiuni minore este introducerea unor funcții noi. Funcțiile
vechi nu sunt îndepărtate; totuși documentația programului îl poate
avertiza pe utilizator că la anumite funcții se va renunța în viitor (sunt
marcate ca “obsolete” sau “deprecated”)
 Patch-ul nu poate realiza decât schimbări în implementarea unor funcții.
De obicei, rolul său este corectarea unor defecte ale programului
 Aceste reguli nu se aplică însă și pentru programele în versiuni alfa sau
beta (0.X)
 Microsoft .NET: major, minor, build, revision

70
Instrumente de control
al versiunilor
 Alături de alte instrumente, menționăm:
 Microsoft Visual SourceSafe (VSS)
 Concurent Versions System (CVS)
 Git
 Subversion (SVN)
 Microsoft Team Foundation Server (TFS)

71
Microsoft Visual SourceSafe
 Sistem de control al versiunilor destinat în special
dezvoltării software, dar util pentru gestionarea
versiunilor oricărui tip de documente
 Previne pierderea accidentală a fișierelor
 Permite revenirea la o versiune anterioară
 Permite partajarea și îmbinarea fișierelor
 Permite lucrul cu proiecte întregi

72
Check in

73
Check in

74
Lista de proiecte

75
Check out

76
Memorarea versiunilor
 Pentru fișiere sursă,
se recomandă
memorarea tuturor
versiunilor
 Pentru fișiere binare,
se poate reține
numai ultima
versiune

77
Lock-Modify-Unlock
 Un dezvoltator preia
(checks out) un fișier
în mod exclusiv
 Lucrează asupra lui
 În acest timp, fișierul
este blocat pentru
ceilalți dezvoltatori
 Primul dezvoltator
încarcă la loc (checks
in) fișierul
 Fișierul este deblocat

78
Preluarea non-exclusivă

79
Copy-Modify-Merge

80
Modificările

81
Check in multiplu

82
File difference

83
File difference

84
Merge (îmbinarea)
 Versiunea de bază
 Modificarea 1
 Modificarea 2

85
Îmbinarea: conflicte

86
Share (partajarea)
 Permite ca un fișier să fie partajat de mai multe proiecte
 Dacă fișierul este modificat într-un proiect, schimbările
se vor reflecta simultan și în celelalte proiecte

87
Branch (ramificarea)
 Permite ca după partajare, fișierele comune să devină
independente
 Exemplul 1
 Exemplul 2
 Două proiecte foarte asemănătoare pentru doi clienți diferiți
 O mare parte a proiectelor este comună
 Unele fișiere specifice sunt diferite
 Se partajează un proiect (recursiv) și se ramifică fișierele
specifice

88
Cloak (ascunderea)
 Proiectele de
dimensiuni mari, care
se modifică rar, pot fi
ignorate în cadrul
operațiilor recursive
Fereastra de
proprietăți pentru
directoare/proiecte,
nu pentru fișiere

89
Label (etichetarea)
 Permite etichetarea fișierelor sau proiectelor
 O scurtă descriere în vederea identificării mai ușoare
 File → Label... / Show History...

90
Concluzii
 Implementarea este faza în care este produs codul proiectat,
îndeplinind restricțiile de resurse, acuratețe și performanță
indicate de specificații
 Există limbaje imperative (procedurale), precum C/C++, Java,
C# și limbaje declarative, precum Lisp, F#, Prolog, Clips
 Alegerea unui limbaj trebuie să țină seama de natura
proiectului, de timpul dorit pentru implementare și de
experiența echipei
 Structura programului trebuie optimizată ori de câte ori este
necesar prin refactorizare
 Visual SourceSafe este un instrument des utilizat pentru
controlul versiunilor

Faza de implementare

Recommended

Recommended

More Related Content

What's hot

What's hot (6)

Similar to Faza de implementare

Similar to Faza de implementare (16)

More from Florin Leon

More from Florin Leon (17)

Faza de implementare