CAPITOLUL 4

INGINERIA SOFTWARE

În acest capitol vom aborda câteva subiecte legate de întregul proces de dezvoltare si întretinere a
unui produs software. Multe dintre tehnicile care se aplica în acest domeniu sunt similare celor utilizate
de inginerii care lucreaza în industrie, de exemplu de catre constructorii de automobile, poduri sau
televizoare. De altfel, domeniul poarta numele de „inginerie software”.
Ne vom referi în discutia noastra la sisteme software de mari dimensiuni, a caror complexitate
depaseste capacitatea de memorare pe termen scurt cu care suntem înzestrati. În aceasta categorie intra de
exemplu sistemele de gestiune economica, sistemele de comanda a legaturilor telefonice sau sistemele de
securitate pentru cladirile de birouri. Problemele care apar la dezvoltarea unor astfel de sisteme nu sunt
doar o ridicare la scara a celor cu care ne confruntam la scrier ea unei aplicatii simple. În acest caz apar
probleme noi, cum ar fi cele legate de faptul ca dezvoltarea unui sistem complex presupune implicarea pe
termen lung a unui mare numar de persoane, iar pe parcursul procesului specificatiile se pot modifica sau
personalul se poate schimba (prin transfer, promovare etc.). Prin urmare, ingineria software se ocupa si de
probleme legate de personal sau de managementul proiectelor, care sunt mai apropiate de domeniul
stiintelor economice decât de informatica. Nu vom aborda aici aceste subiecte, dar în final vom puncta
câteva aspecte juridice, legate de dreptul de proprietate si de garantiile oferite pentru produsele software.

1. INGINERIA SOFTWARE CA DISCIPLINA

Cei care abia acum se initiaza în informatica vor întelege mai greu unele aspecte ale ingineriei
software, deoarece nu au participat niciodata la dezvoltarea unui sistem informatic complex si de aceea nu
pot sesiza pe deplin toate problemele implicate Cel mai adesea, experienta lor se rezuma la realizarea
unor proiecte de programare care pot fi duse la bun sfârsit în câteva zile si probabil ca nu au fost niciodata
pusi în situatia de a lucra un timp mai îndelungat sau de a întretine programele pe care le-au scris.
De aceea, poate ca ar fi mai bine sa începem printr-o analogie cu problema proiectarii si
construirii unui alt obiectiv de mare complexitate (un automobil, cladire cu mai multe etaje sau - de ce
nu? - o catedrala). Gânditi-va doar la câte dintre problemele care apar. Cum putem estima resursele
financiare si umane timpul necesar realizarii proiectului? Cum putem împarti proiectul în componente
mai usor de controlat si cum ne încredintam ca aceste componente sunt compatibile. Cum asiguram
comunicarea între cei care realizeaza diferitele componente? Cum putem masura stadiul de realizare?
Cum rezolvam nenumaratele detalii care apar (alegerea clantelor pentru usi, aprovizionarea cu sticla
pentru vitralii, calculul r ezistentei grinzilor, proiectarea conductelor pentru sistemul de încalzire etc.)? La
fel de multe întrebari trebuie sa îsi gaseasca raspunsul si în cazul dezvoltarii unui sistem software
complex.
Ingineria fiind un domeniu cu reguli bine precizate, va gânditi probabil ca ingineria software ar
putea prelua unele dintre tehnicile utilizate deja în alte discipline. Un astfel de rationament trece însa cu
vederea deosebirile foarte mari din software si celelalte specialitati.
Sa luam ca exemplu problema tolerantelor. În general, în domeniile tehnice vorbim despre
produse care sunt acceptabile atunci când îsi îndeplinesc rolu l anumite limite. O masina de spalat care îsi
urmeaza programul încadrându-se în timp cu o toleranta de 2% este foarte buna. Despre produsele
software nu putem însa în aceiasi termeni; un program functioneaza corect sau incorect, iar un sistem
contabilitate cu o precizie de 2% nu este nici pe departe acceptabil.
O alta deosebire consta în lipsa unor sisteme cantitative (metrici) care sa permita masurarea
proprietatilor unui sistem informatic. Ce metrica am putea exemplu sa utilizam pentru a masura calitatea
unui produs software? În cazul dispozitivelor mecanice, adesea calitatea este exprimata sub forma
timpului mediu de buna functionare, care este o masura a uzurii. Produsele software însa nu se uzeaza, de
aceea în ingineria software nu putem aplica aceasta metoda de evaluare a calitatii.
Imposibilitatea masurarii cantitative a proprietatilor produselor software este unu l dintre motivele
pentru care ingineria software nu este înca bine fundamentata, asa cum sunt ingineria mecanica si cea
electrica. În timp ce aceste domenii se bazeaza pe legile fizicii, ingineria software nu are înca o baza la fel
de solida.
Ca urmare a acestei situatii, se disting în prezent doua niveluri de dezvoltare a acestei discipline:
unii cercetatori lucreaza la dezvoltarea unor tehnici cu aplicare imediata, în timp ce altii se concentreaza
asupra gasirii unor principii si fundamentale, pe baza car ora sa poata fi construite în viitor tehnici cu o
mai mare stabilitate. Deoarece nu se bazeaza pe niste temelii solide, multe metodologii dezvoltate la
53
primul nivel, considerate valabile la un moment dat, au fost înlocuite cu altele, care la rândul lor s-au
dovedit ulterior depasite. Pe de alta parte, progresul înregistrat pe cel de al doilea front a fost destul de
neconvingator.
La ambele niveluri este înca nevoie de progrese semnificative. Societatea noastra (cea americana,
în special) a devenit din ce în ce mai dependenta de calculatoare si de sistemele software asociate.
Economia, sistemul sanitar, administratia, sistemul judiciar, transporturile si apararea, toate se bazeaza pe
sisteme informatice a caror fiabilitate constituie înca o problema. Erorile software pot uneori sa duca la
situatii catastrofale: rasaritul lunii a fost luat drept un atac nuclear, banca din New York a pierdut într-o
singura zi 5 miliarde de dolari, sonda Mariner 18 s-a pierdut în spatiu, supradoze de radiatii au cauzat
moartea sau paralizia, iar în largi arii geografice comunicatiile au fost întrerupte datorita unor erori
software.
În timp ce stiinta înca mai cauta metode de dezvoltare a unor pachete software de calitate,
organizatiile profesionale si-au adus o contributie indirecta prin promovarea unor standarde înalte de etica
si comportament, impuse membrilor lor. The Association of Computing Machinery (ACM) a introdus un
cod de conduita profesionala, iar Data Processing Management (DPMA) si Institute of Electrical and
Electronics Engineers (IEEE) au adoptat fiecare propriile lor coduri etice. Aceste coduri au dus la
cresterea gradului de profesionalism al creatorilor de sisteme informatice, al caror comportament a
evoluat de la o atitudine mai degraba nonsalanta la asumarea unei responsabilitati individuale.
În acest capitol vom prezenta unele rezultate ale cercetarii în domeniu, printre care câteva
principii fundamentale ale ingineriei software (ciclul de viata al produselor software, modularitatea,
cuplarea si coeziunea), ca si unele dintre tehnicile si instrumentele de dezvoltare folosite în prezent.

2. CICLUL DE VIATA AL UNUI PRODUS SOFTWARE

Conceptul fundamental al ingineriei software îl constituie ciclul de viata.

Ciclul de viata ca întreg

Ciclul de viata al unui produs software este reprezentat în figura 4. l. Dupa cum puteti vedea aici,
odata dezvoltat, produsul intra într-un ciclu de utilizare si modificare, care continua pe toata durata sa de
viata. Tiparul nu este specific produselor software, el putând fi generalizat pentru majoritatea produselor
industriale, cu diferenta ca în cazul acestora din urma etapa de modificare se numeste etapa de reparare
sau de întretinere (ciclul este utilizare - modificare, pe masura ce componentele se uzeaza).

Figura 4.1 Ciclul de viata al unui produs software

Asa cum am mai aratat, produsele software nu se uzeaza, în schimb, ele trec prin faza de
modificare din alte motive: corectarea erorilor care nu au fost detectate în faza de dezvoltare, schimbari în
contextul în care sunt utilizate, schimbari efectuate modificarea anterioara care au avut efecte nedorite în
alte puncte ale programului. De exemplu, modificarea legii impozitului necesita corectarea programelor
pentru salarii, iar adesea aceste modificari au efecte adverse în alte zone ale programulu i efecte care sunt
observate ulterior.
Indiferent de motivul pentru care un produs informatic intra în faza de modificare, acest stadiu
presupune ca o persoana (adesea alta decât autorul programului sa studieze programul si documentatia
aferenta pâna când ajunge la un grad de întelegere care sa îi permita efectuarea modificarilor. În caz
contrar, este posibil ca modificarile efectuate sa cauzeze mai multe probleme decât rezolva. Întelegerea
unui program este adesea o sarcina foarte dificila, chiar în conditiile în care acesta a fost bine proiectat si
documentat. Nu sunt deloc rare cazurile în care în aceasta faza renunta complet la un anumit program
component, considerându-se (si nu fara temei) ca este mai usor sa se dezvolte de la zero un sistem nou,
decât sa se modifice cu bune rezultate sistemul existent.
Experienta arata ca un minim de efort în timpul dezvoltarii unui produs informatic poate sa
usureze mult sarcina modificarii produsului, atunci când acest lucru devine necesar. De exemplu, am

54
aratat ca în loc de valoarea literala 645 am putea folosi numele AirportAlt. Am spus atunci ca la o
eventuala modificare va fi mai usor sa schimbam valoarea asociata acestui nume decât sa cautam si sa
corectam nume roasele ocurente ale valorii 645 în întregul program. Este acum limpede de majoritatea
cercetarilor în domeniul ingineriei software se concentreaza pe faza de dezvoltare a produselor; eforturile
investite în aceasta faza aduc cele mai înalte beneficii pentru toate fazele ulterioare de viata.

Dezvoltarea clasica a programelor

Vom analiza acum mai îndeaproape etapele care intra în componenta primei faze din ciclul de
viata al produselor informatice: dezvoltarea (figura 4.2). Aceste etape sunt analiza, proiectarea,
implementarea si testarea.

Figura 4.2 Prima faza din ciclul de viata al produselor software este faza de dezvoltare

Analiza. Aceasta este etapa în care se constata ca ar fi utila o aplicatie informatica si se ia decizia
dezvoltarii unui sistem software. Fie ca se constata existenta unei piete pentru un produs de uz general, fie
ca o anumita organizatie are nevoie de o aplicatie specializata, în mare masura aceasta prima etapa
presupune mai degraba luarea unor decizii de management si marketing decât abordarea unor probleme
legate de studiul algoritmilor.
Dupa luarea deciziei de dezvoltare a unui sistem informatic începe adevarata analiza, al carei scop
principal este identificarea necesitatilor utilizatorului potential al sistemului. De exemplu, în cazul unui
produs de uz general care urmeaza a fi vândut pe o piata concurentiala, trebuie stabilit un public tinta.
Daca se construieste un sistem de gestiune de stocuri ce urmeaza a fi folosit intern în cadrul
departamentului de aprovizionare, atunci trebuie identificate necesitatile si asteptarile celor care lucreaza
în cadrul acestui departament.
Unul dintre rezultatele formale ale fazei de analiza îl reprezinta un set de cerinte pe care noul
sistem ar trebui sa le satisfaca. Ele trebuie formulate din punctul de vedere al utilizatorului, nu în limbajul
specializat al informaticienilor. Una dintre cerinte ar putea fi aceea ca accesul la date sa fie limitat, fiind
permis doar persoanelor autorizate. O alta cerinta ar putea fi ca datele sa reflecte situatia stocurilor la
sfârsitul ultimei zile lucratoare, sau ca datele sa fie afisate pe ecran într-un mod asemanator formularelor
utilizate în mod curent.
Dupa ce sunt identificate cerintele, ele sunt transformate în specificatii tehnice. De exemplu,
cerinta ca accesul la date sa fie permis doar persoanelor autorizate se poate transforma în specificatia ca
sistemul nu trebuie sa raspunda decât dupa introducerea unei parole de cinci cifre, sau ca daca datele nu
au fost preprocesate printr-o rutina cunoscuta doar de personalul autorizat, atunci ele vor fi afisate în
forma codificata.
Proiectarea. În faza de proiectare sunt dezvoltate detaliile tehnice ale sistemului. În aceasta etapa,
sistemul este descompus în componente mai usor de controlat, numite module.
Implementarea sistemelor complexe devin e posibila tocmai prin aceasta descompunere modulara.
Altfel, multimea detaliilor tehnice care trebuie luate în considerare ar fi imposibil de stapânit; prin
proiectarea modulara, este suficient sa avem în vedere pentru fiecare modul doar detaliile corespu nzatoare
acestuia. Pe de parte, proiectarea modulara ajuta si la întretinerea sistemului. (Daca se schimba exemplu
procedeul de calcul al asigurarilor de sanatate, va trebui modificat doi modulul respectiv.)
Prin urmare, o structura modulara bine proiectata este importanta atât pentru implementarea
sistemului, cât si pentru modificarea sa ulterioara. Acesta este unul dintre principalele motive pentru care
paradigma orientata spre obiecte câstiga teren: un sistem proiectat orientat spre obiecte este prin definitie
un sistem modular.
Implementarea. Aceasta faza se refera la scrierea efectiva a programelor, crearea fis ierelor de date
si dezvoltarea bazelor de date.
Testarea. Aceasta faza este strâns legata de faza anterioara, deoarece în normal fiecare modul al
sistemului este testat în timpul implementarii, într-un sistem bine proiectat, fiecare modul poate fi testat în
mod independent, utilizându-se versiuni simplificate ale celorlalte module pentru a se simula
55
interactiunile dine modulul tinta si restul sistemului. Desigur, pe masura ce diferite module sunt analizate
si combinate, testarea individuala trebuie continuata cu testarea generala a întregului sistem.
Din pacate, testarea si depanarea unui sistem sunt operatii foarte greu de dus la bun sfârsit.
Sistemele de mari dimensiuni pot contine foarte multe erori, chiar si dupa efectuarea celor mai complexe
teste. Multe dintre ele vor ramâne neobservate pe toata durata de viata a produsului, altele vor crea
disfunctionalitati majore, cum ar f i deschiderea usilor unui tren între statii sau alarme false ale sistemelor
de securitate Eliminarea unor astfel de erori este unul dintre principalele teluri ale ingineriei software, iar
faptul ca ele sunt înca destul de raspândite arata ca în acest domeniu mai sunt multe de facut.
Primele abordari ale ingineriei software se bazau pe o respectare stricta a ordinii analiza,
proiectare, implementare, testare. Se considera ca acceptarea unei proceduri de dezvoltare prin încercari
ar fi fost prea riscanta pentru sisteme complexe, de acea specialistii insistau ca proiectarea sa nu înceapa
înainte ca analiza sa fie complet terminata si sa nu se treaca la implementare decât dupa finalizarea
proiectarii. A rezultat un proces de dezvoltare care este cunoscut sub numele de modelul cascada
(waterfall model); acest nume subliniaza faptul ca procesul putea „curge” într-o singura directie.

Tendinte recente
Veti observa ca între cele patru faze de rezolvare a problemelor identificate de Polya si etapele de
dezvoltare a unui sistem software (analiza, proiectare, implementare si testare) similitudinea este
evidenta. În fond, dezvoltarea unui sistem informatic complex înseamna rezolvarea unei probleme. Pe de
alta parte, abordarea clasica în cascada a dezvoltarii sistemelor este într-o contradic tie flagranta cu
procesul liber, prin încercari, care este adesea vital pentru rezolvarea creativa a problemelor. În timp ce
abordarea în cascada încearca sa stabileasca un mediu riguros structurat, în care dezvoltarea se efectueaza
în mod secvential, rezolvarea creativa a problemelor se desfasoara într-un mediu nestructurat, în care
planurile anterioare pot fi uneori abandonate fara o motivatie clara, numai pe baza strafulgerarilor de
intuitie.
În ultimii ani, tehnicile specifice ingineriei software au început sa reflecte aceasta contradictie
fundamentala. Schimbarea de filozofie a fost determinata în mare masura de dezvoltarea instrumentelor
specifice ingineriei software asistate de calculator (computer aided software engineering - CASE) .
Este vorba de sisteme software care ofera asistenta pentru realizarea si actualizarea unor documente cum
ar fi diagramele fluxului de date diagramele relatiilor între entitati si dictionarele de date. Aceste
documente sunt utilizate pentru modelarea sistemului care se proiecteaza. Unele sisteme CASE cuprind
chiar generatoare de cod, care, daca se dau specificatiile pentru o parte a sistemului, creeaza programe
într-un limbaj de nivel înalt care implementeaza acea parte. Utilizarea instrumentelor automate reduce
semnificativ efortul necesar pentru parcurgerea fazelor de analiza, proiectare si implementare, astfel ca
este acum mult mai usor sa se revina si sa se modifice deciziile care s-au dovedit eronate. Ca rezultat al
aplicarii acestor tehnici, modelul de dezvoltare în cas cada a sistemelor informatice nu mai este urmat atât
de strict.
Una dintre cele mai spectaculoase consecinte ale noului mod de abordare este utilizarea unei
tehnici bazate pe prototipuri, tehnica de asemenea acceptata de multe instrumente CASE. Dezvoltarea
bazata pe prototipuri se refera la construirea unor versiuni sau componente simplificate ale sistemului
propus, care pot fi analizate înainte de a se continua dezvoltarea sistemului.
Ca rezultat al aplicarii acestei tehnici, dezvoltarea sistemelor informatice a încetat sa mai fie un
proces strict secvential, în care mai întâi se încheie o faza si de-abia apoi se trece la faza urmatoare.
Procesul a devenit unul în care analiza, proiectarea si construirea prototipurilor se îmbina, astfel încât ca
urmare a rezultatelor obtinute în urma testarii prototipului proiectul poate fi modificat. În multe cazuri,
prototipurile construite în urma acestui proces iterativ sunt abandonate, preferându-se implementarea de
la zero a variantei finale, în alte situatii, prototipul este rafinat pâna când se obtine chiar sistemul dorit.
O alta directie de dezvoltare cu adânci implicatii în ingineria software a fost aparitia paradigmei
orientate spre obiecte. Tehnicile ingineriei software aparute în anii '70 si '80 sunt în general instrumente
utile pentru construirea unor sisteme bazate pe paradigma de programare imperativa. Ele privesc procesul
de dezvoltare a unui sistem software ca pe un proces de construire a unei serii de proceduri care împreuna
rezolva o anumita problema. În schimb, în sistemele software bazate pe paradi orientata spre obiecte
structura generala este aceea a unui ansamblu de obiecte aceea, paradigma orientata spre obiecte a dus la
cautarea unor noi tehnici de dezvoltare a produselor software.

56
 3. MODULARIZARE

Una dintre observatiile cheie este ca persoana care modifica un produs software trebuie sa
înteleaga mai întâi programul respectiv, sau cel putin acele parti din program care au o legatura cu
modificarea ce trebuie efectuata. Acest luc ru este destul de greu de realizat chiar si în cazul programelor
mici, iar în lip sa modularizarii ar fi imposibil pentru sistemele informatice de mari dimensiuni. Prin
modularizare se întelege tehnica împartirii unui produs software în componente mai usor de controlat,
care realizeaza fiecare o parte din functiunile sistemului.

Implementarea modulara
Izolând detaliile unei activitati în proceduri distincte se poate obtine un program ale carui
obiective si metode sunt mai usor de înteles decât daca am fi descris toate activitatile într-un singur modul
de program.
De asemenea, am întâlnit acest concept si când am vorbit despre paradigma orientata spre obiecte.
În acest caz modulele luau forma unor obiecte fiecare dintre ele având o structura interna independenta de
restul obiectelor. Tocmai aceasta structura implicit modulara a fost unul dintre motivele pentru care
metoda de dezvoltare orientata spre obiecte se bucura de atâta succes.
Unul dintre principalele instrumente de reprezentare a structurii modulare al sistemelor software
bazate pe paradigma imperativa este schema de structura. În aceasta schema modulele sunt reprezentate
prin dreptunghiuri, iar legaturile dintre ele prin sageti. Schema de structura din figura 6.3 reprezinta un
sistem pentru calculul salariilor într-o firma mica. Din schema rezulta ca modulul ProcessPayroll
este dependent de modulul ComputeTax; aceasta înseamna ca, pentru a-si îndeplini functiunile, modulul
ProcessPayroll utilizeaza modulul ComputeTax (cel mai probabil apelându-l ca procedura).
Într-un fel, putem spune ca schema de structura ne ofera o imagine a diviziunii muncii în cadrul
sistemului. În cazul nostru, diviziunea muncii este urmatoarea:
ProcessPayroll este modulul principal, care are rolul de a calcula salariul cuvenit fiecarui
angajat.
ComputeEarnings interogheaza înregistrarea corespunzatoare unui angajat pentru a vedea
care este salariul brut cuvenit acestuia pentru perioada respectiva.
ComputePretaxWithholding determina contributia salariatului la sistemul de pensii al
firmei.
ComputeTax determina impozitele si taxele care trebuie platite catre stat si la nivel federal si
utilizeaza în acest scop modulele ComputeFederalTaxes si ComputeStateTaxes.
ComputePosttaxWithholding calculeaza contributia salariatului la cheltuielile sociale ale
firmei (pentru cresa, masa, parcare etc.).

Figura 4.3 Schema unui sistem simplu de calcul al salariilor

57
 Desi în trecut schemele de structura au jucat un rol important în ingineria software, faptul ca sunt
un mod de reprezentare a diviziunii muncii face ca ele sa fie în prezent pe cale de disparitie, deoarece
proiectarea sistemelor orientate spre obiecte nu se bazeaza pe o astfel de diviziune, ci pe identificarea
entitatilor, care de altfel reprezinta scopul principal urmarit la crearea lor. În proiectarea orientata spre
obiecte, analiza procedurala nu apare decât în momentul în care trebuie stabilit modul în care fiecare
obiect îsi îndeplineste functiunile.
Ca exemplu, vom relua problema calculului salariilor. Sistemul trebuie ca pe baza foilor de pontaj
sa actualizeze înregistrarile referitoare la impozite si sporuri si sa genereze statul de plata pentru fiecare
angajat. Prin urmare, în prima faza identificam câteva obiecte care trebuie sa se regaseasca în cadrul
sistemului: Paycheck, Employee, TimeSheet, TaxRecord si BenefitRecord. De fapt,
nu am facut decât sa extragem câteva dintre substantivele care apar în descrierea sistemului propus;
aceasta este o metodologie de proiectare orientata spre obiecte destul de des folosita în practic a. Pasul
urmator este sa vedem în ce mod trebuie sa comunice între ele aceste obiecte pentru ca sistemul sa îsi
îndeplineasca functiunile. În cursul procesului, colectia de obiecte va fi rafinata si extinsa dupa necesitati.
Dupa ce sunt identificate obiectele din componenta sistemului si sarcinile fiecaruia, se poate trece la
proiectarea detaliata a fiecarui obiect în parte.

Cuplare
În acest capitol, modularizarea a fost prezentata ca fiind o metoda de obtinere a sisteme software
usor de gestionat. Ideea de baza este aceea ca schimbarile ulterioare se vor aplica probabil doar asupra
câtorva dintre module, astfel încât în timpul procesului de modificare va trebui sa ne concentram atentia
doar asupra unei sistemului. Desigur, aceasta presupunere se bazeaza pe ideea ca modificarile a efectuate
într-unul dintre module nu afecteaza în mod imprevizibil comportarea celorlalte. Prin urmare, unul dintre
obiectivele modularizarii trebuie sa fie acela de a se maximiza independenta modulelor unele în raport cu
altele.
Pe de alta parte, pentru a forma un sistem coerent modulele trebuie conectate. Conectarea
modulelor este cunoscuta sub numele de cuplare. Prin obiectivul independentei maxime corespunde unei
cuplari minime.
Cuplare modulelor se manifesta practic în mai multe moduri. Unul dintre ele cuplarea prin
control, care apare atunci când unul dintre module cedeaza controlul catre alt modul. Alta forma este
cuplarea prin date, care se refera la partajarea datelor de catre module.
Schema de structura din figura 4.3 reprezinta cuplarea controlului pentru un sistem de calcul al
salariilor bazat pe paradigma imperativa. Cuplarea prin date se reprezinta de obicei în aceste scheme prin
intermediul unor sageti suplimentare, ca în figura 4.4. Aceasta schema este completata cu datele care sunt
transmise de modul la altul, în ambele directii. De exemplu, atunci când apeleaza
ComputePretaxWithholding, modulul ProcessPayroll îi transmite acestuia si informatiile
EmployeeID si TotalEarnings; dupa ce efectueaza calculele respective,
ComputePretaxWithholding transmite rezultatele la care a ajuns înapoi catre
ProcessPayroll, prin intermediul informatiei Withholding. În paradigma imperativa acest mod
de cuplare prin date este implementat de regula prin intermediul listei de parametri a procedurii
respective.
În sistemele orientate spre obiecte, cuplarea modulelor ia forma comod între obiecte, care este
implementata de obicei sub forma cuplarii prin control. Astfel, o cerere ca un obiect sa îndeplineasca o
anumita actiune este o cerere de executie a unei rutine din cadrul obiectului, controlul fiind cedat unui
obiect în aceeasi maniera în care se transfera catre o procedura. Abordarea orientata spre obiecte se
caracterizeaza astfel prin minimizarea cuplarii prin date; de fapt, obiectele sunt ansambluri de rutine care
manipuleaza anumite date în cadrul unui singur modul.
Indiferent de tipul cuplarii, este important ca în programul sursa ea sa fie cât se poate de vizibila,
deoarece cuplarea implicita (ascunsa) este cauza multor erori de programare. Unul dintre cele mai
raspândite moduri de a se obtine o cuplare implicita este utilizarea datelor globale. Datele globale sunt
acele date disponibile în mod automat în toate modulele sistemului. În schimb, datele locale sunt date la
care are acces doar un anumit modul, în afar a de cazul în care ele sunt transmise în mod explicit catre alt
modul. Majoritatea limbajelor de nivel înalt permit utilizarea ambelor tipuri de date.

58
 Figura 4.4 Schema de structura care arata cuplarea prin date

În exemplul nostru bazat pe paradigma imperativa, cuplarea implicita prin date ar putea sa apara
prin folosirea unei baze de date globale referitoare la angajati, care sa fie utilizata de orice modul fara a se
cere vreo permisiune în acest sens. Mai precis, modulul ComputeEarnings ar putea sa interogheze
baza de date pentru a afla numarul de ore lucrate de fiecare angajat, în timp ce modulul
ComputePretaxWithholding ar putea consulta aceeasi baza de date pentru a vedea care este
participarea angajatilor la sistemul de pensii al firmei.
Problema care ar putea sa apara este ca unul dintre module sa modifice informatiile utilizate de
celelalte într-o maniera imprevizibila pentru restul sistemului. În acest caz, daca dupa un timp sistemul
sufera modificari, e posibil ca o schimbare aparent clara sa aiba efecte colaterale neanticipate si
dezastruoase.

Efecte colaterale
Într-un mediu de programare, termenul de efecte colaterale este folosit pentru actiuni efectuate
de un program care nu sunt reprezentate „în clar” de sintaxa programului. Sa luam ca exemplu un modul
cu numele CheckPassword, care are rolul de a determina care sunt drepturile asociate cu diferite
parole de acces (de exemplu, unii utilizatori vor avea parole care sa le dea dreptul de a modifica datele, iar
altii parole care sa le permita doar citirea datelor). Daca informatiile referitoare la drepturi ar fi
implementate ca date locale si transmise prin lista de parametri, un apel al modulului respectiv ar putea sa
arate astfel
CheckPassword (Password, Privilege)
În schimb, daca Privilege ar fi implementat ca data globala, apelul ar arata astfel
CheckPassword (Password)
Aceasta forma nu reflecta în mod explicit implicarea datei Privileg, ceea ce înseamna ca
actiunea modulului CheckPassword este mascata într-un efect colateral.
Deoarece sunt invizibile, efectele colaterale constituie o sursa majora de erori de programare, si
cum una dintre cauzele importante producatoare de efecte colaterale este cuplarea implicita a datelor,
aceasta este uneori evitata de programatori. Pe de alta parte însa, utilizarea corecta a datelor globale poate
sa simplifice programul, facându-l mai usor de citit si de înteles. Iata o situatie care demonstreaza
utilitatea comentariilor. Este bine ca în astfel de cazuri sa se utilizeze comentarii care sa identifice toate
datele globale folosite de modul.
59
Coeziune
La fel de importanta ca si minimizarea cuplarii între module este cresterea gradului de coeziune
interna în cadrul acestora. Termenul de coeziune se refera aici la gradul „înrudire” a componentelor
interne ale unui modul, sau altfel spus la gradul specializare al acestuia. Astfel, un modul bazat pe
paradigma imperativa care estimeaza profitul unei investitii imobiliare este de asteptat sa aiba un grad mai
coeziune decât un modul care estimeaza profitul pentru o gama larga de inves titii.
Pentru a aprecia importanta coeziunii trebuie sa privim dincolo de faza initiala, de dezvoltare, si
sa consideram întregul ciclu de viata al unui sistem informatic. Daca sunt necesare modificari ale unui
modul, existenta unei largi varietati de activitati în cadrul acestuia complica un proces care altfel ar putea
fi foarte simplu. De aceea, în afara de o cuplare cât mai redusa între module, proiectantii încearca sa
obtina si un mare grad de coeziune în cadrul fiecar uia.
Una dintre formele mai slabe de coeziune este cunoscuta sub numele de coeziune logica. Acest
tip de coeziune în cadrul unui modul rezulta ca urmare a faptului ca elementele lui interne realizeaza
activitati de aceeasi natura. De exemplu, sa presupunem ca avem un modul care asigura comunicarea
sistemului cu lumea exterioara. Ceea ce uneste componentele unui astfel de modul este faptul ca toate
activitatile au o legatura cu comunicarea, însa comunicarea se poate referi la multe lucruri diferite, ca de
exemplu obtinerea datelor sau raportarea unor erori.
O forma mai puternica de coeziune este coeziunea functionala, care înseamna ca toate
componentele modulului sunt integrate cu scopul realizarii unei singure activitati. Desigur, ce se întelege
printr-o singura activitate depinde de instrumentele avute la dispozitie. Astfel, modulul
ProcessPayroll din figura 4.3 nu are o coeziune functionala daca includem în el calculul detaliat al
taxelor si contributiilor. Daca izolam însa aceste activitati în module separ ate si le folosim aici ca
instrumente abstracte, atunci putem spune ca modulul ProcessPayroll se concentreaza asupra
realizarii unei singure operatii (calculul salariilor) din multitudinea de activitati efectuate la nivelul firmei.
Într-un mediu orientat spre obiecte, coeziunea din cadrul fiecarui obiect este una logica, obiectul
fiind de fapt o serie de elemente de program care se refera la el. Cu toate acestea, proiectantii se
straduiesc sa ofere componentelor din cadrul obiectelor si o coeziune functionala, în sensul ca fiecare
rutina a obiectului respectiv trebuie sa efectueze o operatie bine definita.

4. TEHNICI SI INSTRUMENTE DE DEZ VOLTARE

În acest subcapitol vom discuta despre metoda prin care se realizeaza proiectarea modulara.
Dezvoltarea tehnicilor de proiectare este unul dintre principalele aspecte ale ingineriei software, în acest
domeniu reusindu-se obtinerea unor strategii de proiectare cu un grad de generalitate suficient de mare
pentru a putea fi utilizate în gama larga de aplicatii. De fapt, conceptele discutate aici pot fi adesea
aplicate indiferent daca proiectarea se face manual sau automat.

Proiectarea descendenta
Probabil ca cel mai utilizat concept asociat cu proiectarea sistemelor este metodologia
descendenta (top-down). Ideea de baza a acesteia este ca într-o activitate cum ar fi proiectarea unui sistem
sau programarea unui modul primul pas trebuie sa fie obtinerea unei scurte descrieri a solutiei, care
urmeaza a fi detaliata ulterior. Adesea, aceasta prima descriere este o simpla reformulare a problemei
initiale.
Pasul urmator consta în rafinarea descrierii simplificate, care trebuie detaliata împartita în
componente. Lucrul cel mai important este ca aceste elemente, prezentate cu mai multe detalii, sa se
refere fiecare în parte doar la anumite aspecte ale problemei originale. În acest mod, problema initiala va
fi împartita în mai multe probleme simple, ale caror solutii luate împreuna ofera o solutie pentru problema
initiala. Acest proces de rafinare continua pâna când se obtin unitati care pot fi gestionate usurinta.
În abordarea clasica, imperativa, rezultatul proiectarii descendente este un sistem ierarhizat care
poate fi transpus adesea direct într-o structura modulara. Astfel, cel mai mici unitati din ierarhie devin
module cu functiuni simple, în timp ce unitatile la nivelurile superioare devin module care realizeaza
activitati complexe, utilizând modulele subordonate ca instrumente abstracte. În schimb, mediile orientate
obiecte utilizeaza proiectarea descendenta în procesul de stabilire a tipurilor obiecte care sunt necesare si
în proiectarea elementelor interne ale acestora.

60
Proiectarea ascendenta
O metodologie opusa celei descendente este metodologia ascendenta, care porneste invers: se
identifica mai întâi activitatile simple din cadrul sistemului si apoi se determina modul în care pot fi
utilizate ca instrumente abstracte pentru rezolvarea problemelor de mai mare complexitate.
Multa vreme aceasta metoda a fost considerata inferioara proiectarii descendente, dar astazi ea
câstiga din ce în ce mai mult teren. Unul dintre motive este acela ca metodologia descendenta tinde sa
caute o solutie structurata ierarhic: procesul de împartire a activitatilor conduce în mod natural la un
proiect în care un modul principal utilizeaza submodule care se bazeaza la rândul lor pe alte submodule
etc. Pe de alta parte însa, pentru unele proiecte structura ierarhica nu este cea mai potrivita. Uneori, un
proiect în care doua module interactioneaza de la egal la egal (figura 4.5a se poate dovedi o solutie mai
buna decât daca exista un modul ierarhic superior, care se foloseste de modulul subordonat pentru a
efectua o anumita activitate (figura 4.5b).
De exemplu, un model economic multinational poate fi implementat sub forma mai module care
comunica direct între ele spre a simula interactiunile dintre economiile respective.
O alta problema a metodologiei descendente este tendinta de a se adopta o structura fixa înca din
primele faze ale procesului de proiectare. Daca descompunerea se dovedeste a fi fost gresita, decizia de
modificare a structurii poate zadarnici dintre eforturile depuse pâna în punctul respectiv.
Un al treilea motiv pentru interesul în crestere de care se bucura proiectarea ascendenta este faptul
ca în acest mod se pot construi instrumente abstracte, utiliza bile ca blocuri elementare într-o gama larga
de aplicatii. Aceasta metoda este favorizata si de popularitatea de care se bucura astazi programarea
orientata spre obiecte, în care programele sunt construite adesea din obiecte independ ente, capabile sa
comunice direct unele cu altele, nu prin intermediul unui modul supervizor. În plus, aceste obiecte sunt
disponibile ca prefabricate ce pot fi utilizate si în alte proiecte. În acest context, proiectarea noilor sisteme
urmeaza din ce în ce mai mult calea construirii din componente decât calea abordarii globale si a rafinarii
prin descompunere repetata.

(a) Module ce interactioneaza de la egal la egal

(b) Module sub controlul unui modul supervizor

Figura 4.5 Comparatie între metodele de proiectare modulara

Diagrama fluxului de date

Pentru analiza si proiectarea sistemelor, ingineria software a adoptat o serie de sisteme de notare,
dintre care unele pot fi aplicate atât paradigmei descendente, cât si celei ascendente. Una dintre acestea
este diagrama fluxului de date, în care accentul nu cade pe procedurile sau algoritmii ce urmeaza a fi
executati, ci pe datele care vor circula prin sistemul propus. Aceasta abordare a aparut în strânsa legatura
cu paradigma de proiectare imperativa, în ideea de a se urmari drumul datelor în cadrul sistemului si
punctele în care ele sunt modificate. Pentru ca în aceste puncte sunt necesare activitatile de efectuare a
calculelor activitatile respective, sau grupari de activitati, vor forma modulele sistemului. Urmarindu-se
fluxul de date se poate releva astfel o structura modulara a sistemului, fara a mai fi necesar ca acesta sa fie
descompus intuitiv în componente.
Desi dezvoltata în contextul paradigmei de programare imperativa, analiza fluxului de date poate
fi utilizata si în mediile orientate spre obiecte, unde poate ajuta la identificarea obiectelor necesare si a
activitatilor pe care trebuie sa le efectueze acestea.
Diagrama fluxului de date este o reprezentare grafica a drumului parcurs de date în cadrul
sistemului. Simbolurile utilizate în diagrama au semnificatii bine stabilite: sagetile reprezinta itinerariul
datelor, dreptunghiurile reprezinta sursele si destinatiile, cercurile sau elipsele arata locurile în care datele
sunt prelucrate, iar liniile groase reprezinta stocarea datelor. Fiecare simbol are o eticheta care specifica
numele obiectului reprezentat.

61
 În figura 4.6 puteti vedea o diagrama a fluxului de date pentru sistemul nostru de calcul al
salariilor. Observati ca acest tip de diagrama, în care accentul se pune pe date, reflecta mai bine rolul
bazei de date referitoare la angajati decât reuseste sa o faca schema de structura din figura 6.4.

Figura 4.6. Diagrama fluxului de date pentru un sistem simplu de calcul al salariilor

Diagrama relatiilor între entitati

Un alt instrument utilizat în analiza si proiectarea sistemelor informatice este diagrama relatiilor
între entitati, o reprezentare grafica a blocurilor elementare de informatii din cadrul sistemului (numite
entitati) si a relatiilor dintre ele. Sa luam ca exemplu un sistem de gestiune a informatiilor referitoare la
profesorii, studentii si cursurile dintr-o universitate.
Mai întâi trebuie sa identificam entitatile din cadrul sistemului. Acestea sunt: Professor, care
reprezinta un profesor care preda la universitatea respectiva; Student, care reprezinta un student; s i
Class, care reprezinta un curs. Pentru fiecare ocurenta a entitatii Professor avem asociate un nume,
o adresa, un numar de identificare, un salariu etc. Fiecarei aparit ii a entitatii Student îi sunt asociate un
nume, o adresa, un numar de identificare, o medie etc. Pentru fiecare ocurenta a entitatii Class vom
avea asociate disciplina de studiu, anul si semestrul, orarul etc.
Dupa ce am identificat entitatile din cadrul sistemului vom analiza relatiile care apar între ele.
Mai întâi, vom observa ca profesorii predau (teach) cursuri care sunt urmate (attend) de studenti. Prin
urmare, relatia dintre entitatile Professor si Class este Teaches, iar între entitatile Student si
Class relatia este Attends. (Entitatile au fost desemnate prin substantive, iar relatiile dintre ele prin
verbe.)

Figura 4.7 Diagrama relatiilor între entitati

62
 Pentru a reprezenta aceste entitati, precum si relatiile dintre ele, am utilizat diagrama din figura
4.7, în care fiecare entitate este redata printr-un dreptunghi, iar fiecare relatie printr-un romb. Relatia
dintre entitatile Professor si Class este o relatie 1-la-mai multe, deoarece fiecare profesor preda
mai multe cursuri, dar fiecare curs este tinut de un singur profesor. În schimb, relatia dintre Student si
Class este o relatie mai multe-la-mai multe: fiecare Student urmeaza mai multe cursuri, iar fiecare
curs este urmat de mai multi studenti. Aceasta informatie suplimentara - tipul relatiei - este reprezentata în
figura 4.7 prin sagetile de la capetele liniilor dintre relatii entitati. Astfel, daca sageata are un singur vârf,
înseamna ca în fiecare ocurenta a relatiei respective este implicata o singura ocurenta a entitatii, iar daca
are vârf dublu înseamna ca în relatie pot fi implicate mai multe ocurente ale entitatii1. Astfel, sageata
simpla îndreptata în figura 4.7 spre entitatea Professor arata ca un curs este predat de un singur
profesor, în timp ce sageata cu vârf dublu care indica spre entitatea Class în relatia Teaches arata ca
un profesor poate sa predea mai multe cursuri.
Dintre toate instrumentele utilizate pâna în prezent de informaticieni, diagrama relatiilor între
entitati pare cea mai adaptata pentru noile metodologii, orientate spre obiecte. În definitiv, identificarea
entitatilor se suprapune peste identificarea obiectelor, iar clasificarea relatiilor între ele este primul pas
catre identificarea relatiilor si a cailor de comunicare între obiecte.

Dictionare de date
Un alt ins trument folosit în procesul de dezvoltare a sistemelor software îl constituie dictionarul
de date, care este centralizatorul tuturor informatiilor referitoare la dat ele utilizate în cadrul sistemului.
Aceste informatii cuprind: identificatorul utilizat pentru fiecare element, valorile valide (tip numeric sau
alfanumeric, interval permis de valori etc.), locul de stocare (fisier sau baza de date, numele acesteia),
locurile în care elementul respectiv este folosit de catre program (ce module contin referiri la el).
Dezvoltarea unui astfel de dictionar de date are mai multe obiective, în primul rând, existenta lui poate
îmbunatati comunicarea între viitorul utilizator al sistemului si analistul care transforma solicitarile
acestuia în cerinte si specificatii. De exemplu, n-ar fi deloc placut ca dupa implementarea sistemului sa se
descopere ca numerele de ratificare ale componentelor nu sunt de fapt numerice, ci alfanumerice, sau ca
pentru tinerea unui inventar complet este necesara o capacitate de stocare mai mare decât cea disponibila.
Construirea unui dictionar de date ajuta la evitarea unor astfel de neîntelegeri.
Alt obiectiv este acela de a se asigura o abordare unitara a sistemului. Construirea dictionarului de
date pune în lumina eventualele redundante si contradictii: ceea ce în inventar se numeste PartNumber
în modulul de vânzari se cheama Partid, sau Name se refera la un angajat în modulul de personal, iar în
cel de evidenta a stocurilor la unele unei componente din stoc.

5. DOCUMENTATIA

Un sistem informatic al carui mod de utilizare nu poate fi usor învatat si care este greu de
întretinut nu este deloc folositor. De aceea, documentatia este o parte importanta a oricarui pachet
software, si prin aceasta un subiect important în ingineria software.
În mod normal, documentatia este elaborata în doua scopuri. În primul rând, ea trebuie sa descrie
pachetul software si modul lui de utilizare; aceasta este cunoscuta ca documentatie de utilizare este
destinata utilizatorului final al sistemului si are un caracter mai putin tehnic.
În zilele noastre, documentatia de utilizare este un instrument de marketing foarte important. O
documentatie de utilizare buna, împreuna cu o interfata bine proiectata, maresc accesibilitatea produsului
si prin aceasta sporesc vânzarile. Producatorii care acorda acestui aspect importanta cuvenita angajeaza de
obicei personal calificat pentru elaborarea documentatiei sau furnizeaza versiunea preliminara a
pachetului unor autori independenti, astfel încât la lansarea pe piata a produsului sa apara si cartile
necesare diferitelor categorii de utilizatori.
În general, documentatia de utilizare ia forma unui manual care contine o prezentare a celor mai
folosite caracteristici oferite de produsul respectiv (adesea sub forma unui ghid pas cu pas), un capitol cu
instructiuni de instalare si o sectiune de referinta în care toate functiile produsului sunt descrise detaliat.
Adesea, manualul este disponibil în forma tiparita, dar sunt si multe cazuri în care el este furnizat
sub forma unui fisier stocat pe acelasi mediu ca si produsul software. Aceasta modalitate permite
1
Nu exista un standard pentru reprezentarea relatiilor multiple. Reprezentarea folosita aici, sageti cu vârf simplu sau
dublu, poate sa difere de cele utilizate în alte carti.
63
utilizatorului sa vada pe ecran portiuni ale manualului chiar în timp ce foloseste produsul. În acest caz,
informatiile sunt împartite în segmente de mici dimensiuni, numite pachete de asistenta (help), care sunt
incluse direct în sistemul software, în sensul ca se poate cere acces chiar din cadrul programului sau
uneori apar automat pe ecran daca utilizatorul ezita prea mult între comenzi.
Cel de al doilea scop urmarit de documentatie este de a descrie sistemul software astfel încât
acesta sa poata fi întretinut pe durata celorlalte perioade de viata. Documentatia de acest tip este
cunoscuta sub numele de documentatie de sistem si are în mod inevitabil un caracter mult mai tehnic
decât documentatia de utilizare. Cu anii în urma, aceasta documentatie consta din programele sursa, în
forma finala, la care se mai adaugau unele explicatii schitate dupa încheierea procesului de dezvoltare -
abordare pe care o vor recunoaste probabil multi programatori la început de cariera. Aceasta maniera
dezordonata nu mai este însa acceptata în prezent, în special pentru sistemele de mari dimensiuni.
În zilele noastre, documentarea sistemului începe cu dezvoltarea specificatiilor initiale si continua
pe întreaga durata de viata a produsului software. Documentatia va consta în final din toate documentele
elaborate în faza de dezvoltare a sistemului, inclusiv specificatiile conform carora a fost verificat
sistemul, diagramele de flux si de relatii între entitati, dictionarul de date si schemele de sistem, care
reflecta structura sa modulara.
De o mare importanta sunt versiunile sursa ale tuturor programelor din sistem, care trebuie
prezentate într-un format lizibil. De aceea, specialistii încurajeaza utilizarea unor limbaje de nivel înalt,
bine proiectate, includerea în programe a comentariilor si proiectarea modulara, care permite prezentarea
fiecarui modul în parte ca un întreg coerent.
Faptul ca documentarea sistemului trebuie sa fie un proces permanent duce la aparitia unor
conflicte între principiile ingineriei software si natura umana. Pe masura ce dezvoltarea sistemului
înainteaza, este putin probabil ca specificatiile, diagramele si schemele initiale sa ramâna nemodificate.
De cele mai multe ori vor aparea schimbari datorate unor probleme care nu au fost prevazute de la început
(de aceea si tehnicile care utilizeaza prototipuri iau din ce în ce mai multa amploare) . În acest caz exista
tentatia de a se efectua direct modificarile respective, fara a se mai reveni la documentele proiectate
anterior. În aceasta situatie, documentele nu mai sunt conforme cu realitatea, iar documentatia finala va fi
incorecta.
Iata deci alt argument în favoarea instrumentelor CASE, care usureaza mult redesenarea
diagramelor si actualizarea dictionarelor de date. În plus, în contextul metodologiilor bazate pe
prototipuri, care accepta ideea ca analiza si proiectarea sunt procese iterative în cadrul implementarii,
modificarea documentatiei devine regula nu exceptia. În acest mediu, probabilitatea ca documentatia sa
fie actualizata creste, ca si cea de obtinere a unei documentatii finale corecte.
În încheiere, vom preciza din nou ca exemplul cu actualizarea documentatiei este doar una dintre
problemele întâmpinate de ingineria software, care trebuie sa îmbine regulile abstracte ale stiintei cu
întelegerea naturii umane. Este suficient sa spunem ca în orice proiect care implica lucrul în echipa apar
inevitabil conflicte interpersonale, ambitii si orgolii, ca sa întelegem ca ingineria software este un
domeniu vast, care include multe subiecte ce nu sunt legate direct de ceea ce numim informatica.

6. DREPTUL DE PROPRIETATE SI GARANTII

În încheierea acestui capitol vom lua în discutie câteva dintre aspectele juridice ale ingineriei
software. Desi s-ar putea crede ca principiile juridice generale sunt suficiente si pentru rezolvarea
disputelor aparute în industria software, lucrurile nu stau chiar asa. În particular, este necesara o metoda
prin care investitia importanta facuta de o persoana fizica sau juridica pentru a dezvolta un produs
software de calitate sa fie protejata, iar persoana respectiva sa-si poata acoperi cheltuielile si sa obtina
profit; în lipsa unei protectii a investitiei, putini ar fi cei care s-ar mai încumeta sa produca software-ul de
care societatea noastra are atâta nevoie. Din pacate, problemele referitoare la dreptul de proprietate asupra
produselor software nu se încadreaza foarte clar în legile existente privind protectia drepturilor de autor si
a brevetelor. Desi aceste legi au fost elaborate tocmai pentru a permite fabricantului unui „produs” sa-si
faca public produsul, pastrându-si totodata drepturile de proprietate asupra lui, particularitatile produselor
software au pus adesea instantele în mare dificultate în eforturile lor de a aplica si în acest caz legile
generale privind proprietatea intelectuala.
Initial, legile privind drepturile de autor au fost elaborate pentru a proteja operele literare. În acest
caz, valoarea nu sta în ideile exprimate, ci mai degraba în modul în care sunt redate aceste idei. Valoarea
unei poezii este data de ritm, stil si forma, nu de subiect. La fel si în cazul unui roman: nu conteaza
povestea în sine, ci modul în care o prezinta autorul. Prin urmare, munca poetului sau a romancierului
64
este protejata acordându-i-se acestuia dreptul de proprietate asupra unei anumite formulari a unei idei, nu
asupra ideii în sine. O alta persoana este deci libera sa exprime aceeasi idee, cu conditia ca între cele doua
versiuni sa nu apara „similitudini substantiale”.
În cazul unui produs software, ideea se exprima prin algoritm. Spre deosebire însa de o poezie sau
de un roman, valoarea unui produs software nu consta în maniera particulara în care este exprimat
algoritmul, ci chiar în algoritm. În multe cazuri, costurile fazei de dezvoltare a unui pachet software se
concentreaza tocmai în descoperirea unor algoritmi, si mai putin în reprezentarea acestora. Prin urmare,
aplicarea directa a legii drepturilor de autor va lasa neprotejata tocmai investitia principala a
producatorului de software, permitând unei firme concurente sa utilizeze liber algoritmul descoperit de
acesta, cu conditia ca reprezentarea sa nu fie „ substantial similara”.
Într-un fel, putem spune ca legile referitoare la drepturile de autor au concepute astfel încât sa
protejeze mai degraba implementarea decât functia, valoarea unui program consta adesea mai degraba în
functie decât în forma. De aceea, legile drepturilor de autor sunt mai potrivite pentru protectia
programelor care implementeaza algoritmi clasici, bine cunoscuti, decât pentru protectia investitiilor care
conduc la descoperirea de noi algoritmi. Daca un algoritm este deja cunos cut atunci într-adevar valoarea
programului consta în modul în care este expr imat respectivul algoritm; în schimb, pentru un algoritm
nou si creativ, principala valoare a programului este chiar algoritmul, pe care din pacate legea drepturilor
de autor nu îl protejeaza. Este paradoxal: cu cât eforturile de dezvoltare a unui program sunt creative, cu
atât legea drepturilor de autor le protejeaza mai putin.
În domeniul drepturilor de proprietate asupra pachetelor software, utiliz area brevetelor se loveste
de mai multe obstacole, dintre care cel mai important este principiul general care statueaza ca nimeni nu
poate fi proprietarul unor fenomene naturale, cum ar fi legile fizicii sau formulele matematice. În general,
instantele au decis ca algoritmii intra si ei în aceasta categorie, astfel ca si în acest caz legea lasa
neprotejata cea mai valoroasa componenta a programului - algoritmul. În plus obtinerea unui brevet este
un proces costisitor si îndelungat, a carui durata poate fi de ordinul anilor. În acest timp, un produs
software se uzeaza moral, iar pâna la obtinerea brevetului de inventie solicitantul nu are nici un drept de
exclusivitate.
Legile drepturilor de autor si cele legate de brevete au rolul de a încuraja atât cresterea numarului
de inventii, cât si schimbul liber de idei, în beneficiul societatii. Atunci când drepturile le sunt protejate,
creator ii si inventatorii sunt mai tentati sa îsi aduca realizarile la cunostinta publicului. În schimb, legile
secretului de serviciu sunt un mijloc de a împiedica libera raspândire a ideilor. Ele sunt destinate
mentinerii unei concurente corecte si îi protejeaza pe producatori împotriva furtului intelect Problema
secretului de serviciu este adesea rezolvata prin semnarea de catre cei care au acces la astfel de secrete a
unor angajamente prin care se obliga sa nu le dezvalu ie altor persoane sau organizatii. În general,
instantele au tinut seama de aceste angajamente.
Adesea, producatorii de software precizeaza pentru produsele lor un set de garantii, prin care îsi
stabilesc limitele de respons abilitate. Acestea iau forme ca „În nici o situatie compania X nu îsi asuma
raspunderea pentru pagubele de orice provocate prin utilizarea acestui software” sau „Compania Y nu
garanteaza ca software corespunde cerintelor dumneavoastra”. Cu toate acestea, instantele iau arareori în
considerare aceste limitari de responsabilitat e daca se dovedeste ca producatorul a dat dovada de
neglijenta. În astfel de cazuri, problema care se pune este daca producatorul a asigurat produsului un nivel
de calitate compatibil cu natura sa. Astfel, un nivel acceptabil pentru un procesor de text poate fi
considerat neglijenta daca este vorba de un sistem de control al unui reactor nuclear. Prin urmare, cea mai
buna metoda împotriva eventualelor reclamatii este abordarea cu maximum seriozitate a procesului de
dezvoltare a sistemului produs.

65