GENERALITĂȚI ALE INGINERI EI PROGRAM ĂRII [611606]

GENERALITĂȚI ALE INGINERI EI PROGRAM ĂRII
CURS 1 – ANUL III
INFORMATICĂ ECONOMICĂ
3 OBIECTIVE
De a face o introducere în ingineria software și de a explica importanța ei
De a prezenta răspunsuri la întrebările cheie legate de ingineria programării
De a prezenta aspecte etice și profesionale ce sunt legate de inginerii software
INTRODUCE RE ÎN INGINERIA PROGRAMĂRII
DE CE ESTE NECESARĂ?
 Economiile TUTUROR țărilor dezvoltate depind de software.
 Tot mai multe sisteme sunt controlate de programe.
 Ingineria software se ocupă cu teorii, metode și instrumente pentru dezvoltarea software
profesion ală.
 Cheltuielile legate de software reprezintă un procent semnificativ în toate țările
dezvoltate.
COSTURI SOFTWARE
 Costurile software de cele mai multe ori depășesc costurile hardware.
 Costurile de întreținere a unui program de obicei sunt mai mari decât costurile de
dezvoltare. Pentru sistemele cu o viață lungă, costurile de mentenanță pot depăși de
câteva ori costurile de dezvoltare.
 Ingineria programării se ocupă cu dezvoltarea eficientă a programelor .
PREVIZIUNI
 1946: Goldstine și von Neumann apreciau că 1000 de instrucțiuni reprezintă o limită
superioară rezonabilă pentru complexitatea problemelor de calculator
 1949: o revistă de popularizare a științei afirma că
în viitor ar putea exista calculatoare mai ușoare de 1,5 tone
 1981: Bill Gates considera că nici un program pentru calculatoare personale nu va necesita
vreodată mai mult de 640 KB de memorie RAM
CRIZA SOFTWARE
 Un raport prezentat de către o companie, în care erau analizate câteva proiecte și stadiile
lor de finalizare, a constatat că:
2% din sistemele software contractate au funcționat de la predare
3% din sistemele software au putut funcționa după câteva modificări
29% au fost predate dar n -au funcționat niciodată
19% au fost folosite dar au fost abandonate
47% au fost plătite dar niciod ată predate
TERMENUL INGINERIA PROGRAMĂRII
 1968: L a conferința organizată de comitetul științific al NATO a fost propus termenul de
ingineria programării (engl. “software engineering”)

Probleme generale ale ingineriei programării

4 DEFINIȚII IP
F. L. Bauer (prima definiție dată ingineriei programării) :
Ingineria programării este stabilirea și utilizarea de principii inginerești solide
pentru a obține în mod economic programe sigure și care funcționează eficient pe
mașini de calcul reale
IEEE Standard Glossary of Software Engineering Technology (1983):
Ingineria programării reprezintă abordarea sistematică a dezvoltării, funcționării,
întreținerii și retragerii din funcțiune a programelor .
CARACTERISTICI IP
 Ingineria programării are următoarele caracteristici importante:
 Este aplicabilă în producerea de programe mari
 Este o știință inginerească
 Scopul final este îndeplinirea cerințelor clientului
INGINERIA PROGRAMĂRII VS . INFORMATICĂ
 Informatica se ocupă de teorie și principii fundamentale; ingineria programării se
concentrează pe aspectele practice a le dezvoltării și livrării de produse software utile
clienților
 Teoriile informatice sunt încă insuficiente pentru a reprezenta o bază completă pentru
ingineria programării (de ex. cum e fizica pentru electrotehnică)
PROVOCĂRI ALE INGINERIEI PROGRAMĂRII
Eterogenit atea
 Dezvoltarea tehnicilor de creare a produselor care funcțione ază pe
platforme și medii de execuție eterogene
Livrarea
 Dezvoltarea tehnicilor care să conducă la livrări mai rapide ale
produselor software
Încrederea
 Dezvoltarea tehnicilor ca re să demonstreze că utilizatorii pot conta pe
rezultatele produselor software
FAZELE INGINERIEI PROGRAMĂRII
 Există patru faze fundamentale ale metodologiilor ingineriei programării:
 Analiza (ce dorim să construim)
 Această fază definește cerințele siste mului, independent de modul în care
acestea vor fi îndeplinite
 Se definește problema pe care dorește să o rezolve clientul
 Rezultatul este documentul cerințelor , care trebuie să precizeze clar ce
trebuie construit
 Proiectarea (cum vom construi)
 Pe baza c erințelor din faza de analiză, se stabilește arhitectura sistemului:
 Componentele sunt elementele constructive ale produsului. Acestea pot fi
create de la zero sau reutilizate dintr -o bibliotecă de componente.
 Componentele rafinează și capturează semnific ația detaliilor din
documentul cerințelor

GENERALITĂȚI ALE INGINERI EI PROGRAM ĂRII
CURS 1 – ANUL III
INFORMATICĂ ECONOMICĂ
5  Interfețele ajută la îmbinarea componentelor. O interfață reprezintă granița
dintre două componente, utilizată pentru comunicarea dintre acestea. Prin
intermediul interfeței, componentele pot interacționa
 Comport amentul , determinat de interfață, reprezintă răspunsul unei
componente la stimulii acțiunilor altor componente
 Implementarea (construirea propriu -zisă)
 În această fază este construit sistemul, ori plecând de la zero, ori prin
asamblarea unor componente p re-existente
 Scopul este producerea sistemului propriu -zis
 Testarea (asigurarea calității)
 Asigură calitatea produsului software
 Scopul este realizarea unui produs competitiv
 Un produs performant crește satisfacția clienților, iar funcționalitatea poate
fi dezvoltată în versiuni ulterioare
 Deși aceste faze se referă în mod special la dezvoltarea produsului software, ele pot fi
aplicate și altor stadii de existență prin care trece un program de la „naștere” până la
„moarte”: lansare, întreținere, ieșire din uz
ELEMENTE DE RESPONSABILITATE PROFESIONALĂ
 Proprietatea intelectuală
 Trebuie avute în vedere legile locale legate de patente, copyright, etc. Trebuie de asemnea
luate măsuri pentru protejarea proprietăților intelectuale ale angajaților și cliențilo r.
 Întrebuințare iresponsabilă a calculatorului
 Aptitudinile de lucru cu calculatorul nu trebuie folosite iresponsabil asupra calculatoarelor
altor persoane. Folosirea iresponsabilă variază de la lucruri relativ triviale (jucarea unor
jocuri pe calculatoa rele clientului) până la lucruri extrem de serioase (virusarea
calculatoarelor).
ÎNTREBĂRI LEGATE DE INGINERIA SOFTWARE
 Ce este software -ul?
Programele de calculator și documentația legată de ele cum ar fi cerințe, modele
de proiectare și manuale de util izare.
Produsele software pot fi dezvoltate pentru un client particular sau pentru o
piață generală.
Produsele software pot fi
 Generice – dezvoltate pentru a fi vândute unei game largi de utilizatori
(cum ar fi Excel sau Word).
 Dedicate – dezvoltate pentr u un singur client în conformitate cu cerințele
clientului.
Software nou poate fi creat prin dezvoltarea de noi programe, configurând
sisteme software generice sau reutilizând software existent.
 Scopul ingineriei programării
 Ingineria programării este preo cupată de toate aspectele producției de software
 Inginerii programatori trebuie să adopte o manieră de lucru sistematică și
organizată, să utilizeze instrumente și tehnici adecvate în funcție de problema care

Probleme generale ale ingineriei programării

6 trebuie rezolvată și să țină seama de constrâng erile de dezvoltare și de resursele
disponibile
 Ce este ingineria software?
Ingineria software este o disciplină de inginerie ce se ocupă de toate aspectele
producției software.
Inginerii software trebuie să adopte o abordare sistematică și organizată și să
folosească instrumente și tehnici potrivite cu problema de rezolvat, cu
constrângerile de dezvoltare și cu resursele disponibile.
 Ce este un proces software?
Este o mulțime de activități ale căror scop este dezvoltarea sau evoluția unui
software.
Activi tățile generice prezente în toate procesele software sunt:
Specificare – ce ar trebui să facă sistemul și care sunt constrângerile de
dezvoltare
Dezvoltare – producția sistemului software
Validare – verificarea dacă sistemul software este ceea ce dorește clientul
Evoluție – schimbarea sistemului software ca răspuns la cerințele
clientului
 Ce sunt metodele ingineriei software?
 Sunt abordări structurate ale dezvoltării software care includ modele de sistem,
notații, reguli, sfaturi de proiectare și ghid de proces.
 Diagrame de model
Descri eri grafice ale modelului de sistem ;
 Reguli
Constr ângeri aplicate modelelor de si stem;
 Recom andări
Sfaturi de bună proiectare;
 Ghid de proces
Ce activități ar trebui efectuate
 Ce este un model de proces software?
Este o reprezentare simplificată a unui proces software, prezentată dintr -o
perspectivă specifică.
Exemple de perspective prin care putem privi un process
 Perspectivă Workflow – secvență de activități;
 Perspectivă Data -flow – fluxul informației (de date);
 Perspe ctivă Rol/acțiune – cine ce face.
Modele generic de proces
 Waterfall (cascadă);
 Dezvoltare iterativă;
 Dezvoltare bazată pe componente.
 Care sunt costurile în ingineria software?
Aproximativ 60% din costuri sunt costuri de dezvoltare, iar 40% sunt costuri de
testare. Dar pentru software dezvoltat pentru un client particular, costurile de
evoluție de cele mai multe ori depășesc costurile de dezvoltare.

GENERALITĂȚI ALE INGINERI EI PROGRAM ĂRII
CURS 1 – ANUL III
INFORMATICĂ ECONOMICĂ
7
Costurile variază în funcție de tipul sistemului dezvoltat și în funcție de cerințele
sistemului mai ales c ele de performanță și fiabilitate.
Distribuția costurilor depinde mult de modelul de dezvoltare folosit.
 Ce este CASE (Computer -Aided Software Engineering)
Sunt sisteme software care oferă suport pentru activitățile proceselor software.
Sisteme software d estinate automatizării unor activități legate de procesele
software
Sistemele CASE sunt deseori folosite pentru a realiza o metodologie de
dezvoltare.
Upper -CASE
 Aplicații care vin în ajutorul activităților de început ale procesului de
dezvoltare cum ar fi specificarea cerințelor, analiză și proiectare;
Lower -CASE
 Aplicații care ajută activități ulterioare cum ar fi programare, depanare și
testare.
 Care sunt atributele unui software de calitate?
Un software de calitate trebuie să ofere funcționalitatea și p erformanța cerută de
client și să fie mentenabil, fiabil și acceptat de client.
Mentenabilitate
 Software -ul trebuie să evolueze pentru a fi în pas cu schimbările;
 Un produs cu un lung ciclu de viață este supus deseori modificărilor, de
aceea el trebuie f oarte bine documentat
Fiabilitate
 Software -ul trebuie să fie “de încredere”;
 Produsul trebuie să se comporte după cerințele utilizatorului și să nu „cadă”
mai mult decât e prevăzut în specificațiile sale
 Un program este fiabil dacă funcționează și conti nuă să funcționeze fără
întreruperi un interval de timp
 Această noțiune exprimă de fapt rezistența la condițiile de funcționare
 Un sistem de operare trebuie să fie fiabil pentru că trebuie să funcționeze o
perioadă suficient de lungă de timp fără să cadă , indiferent de programele
care rulează pe el, chiar dacă nu totdeauna la performanțe optime
Eficiență
 Software -ul nu trebuie să abuzeze de resursele sistemului;
 nu trebuie să folosească în pierdere resursele sistemului
Acceptanță
 Interfața trebuie să țină seama de capacitatea și cunoștințele utilizatorului
 Software -ul trebuie să fie acceptat de utilizatorii pentru care a fost
proiectat. Acest lucru înseamnă că trebuie să fie ușor de înțeles, utilizabil și
compatibil cu alte sisteme.

 UN SISTEM TREBUIE SĂ FIE DE ÎNCREDERE
 Datorită interdependențelor dintre componente, erorile se pot propaga în sistem
 Erorile sistemului apar deseori datorită legăturilor neprevăzute dintre componente
 Totalitatea relațiile posibile dintre componente este practic imposibil de anticipat

Probleme generale ale ingineriei programării

8  Deoarece un sistem socio -tehnic se bazează pe interacțiunea software -ului cu
hardware -ul și cu operatorii umani, considerarea exclusiv ă a încrederii software –
ului poate da o imagine falsă asupra încrederii întregului sistem .

 CONCLUZII:
Ingine ria programării este o colecție de metode și recomandări pentru
dezvoltarea eficientă de programe de mari dimensiuni
Programele sunt de obicei o parte din sistemele socio -tehnice, depinzând de
hardware și de operatorii umani
Fazele fundamentale ale dezvolt ării programelor sunt: analiza, proiectarea,
implementarea și testarea
Ingineria software este o disciplină de inginerie ce se ocupă cu toate aspecte
de producție software.
Produsul software constă din programele dezvoltate și documentația
corespunzătoare .
Atributele esențiale ale produselor software sunt mentenabilitate, fiabilitate,
eficiență și utilitate.
Procesul software constă din activitățile implicate în dezvoltarea produselor
software.
Activitățile de bază sunt specificare software, dezvoltare, validare și evoluție.
Met odele sunt moduri organizate de produc ție software. Ele includ sugestii
pentru procesul ce trebuie urmat , notații folosite , re guli ce guvernează
descrierile sistem ului ce este produs și sfaturi de proiectare .
Aplicațiile CASE sunt sisteme software proiectate să ajute activitățile de rutină
din procesul de dezvoltare software cum ar fi :
 editarea diagramelor,
 verificarea consistenței lor și
 evidența testelor rulate.

GENERALITĂȚ I ALE INGINERIEI PROGRAM ĂRII
Pentru a aprofunda aceată d isciplină este necesară definirea și prezentarea unor concepte
și fundamente pentru a afla răspun suri la câteva întrebări.
1. Ce este programarea?
În sens larg, programarea este operația de elaborare a unui program în vederea rezolvării
unei probleme folosind calculatorul electronic.
2. Ce este un produs program ( software )?
Un produs program, cu sinonimul de aplicație, pachet de programe, produs -soft,
software – sunt definite în literatura de specialitate în mai multe moduri.
 Astfel, A. Cozgarea1 definește pro gramul informatic drept “o succesiune logică de
instrucțiuni sau expresii destinate executării lor de către calculatorul electronic în
vederea obținerii unor rezultate ”.

1 A. Cozgarea – Programarea calculatoarelor, introducere în VB.NET, Editura ASE București, 2008.

GENERALITĂȚI ALE INGINERI EI PROGRAM ĂRII
CURS 1 – ANUL III
INFORMATICĂ ECONOMICĂ
9  Niklaus E. Wirth (părintele limbajului Pascal) percepe programul informatic după
form ula: Structuri de date + Algoritmi = Program .
 Alți specialiști2, descriu programul sub forma unei funcții matematice: Ieșiri =
Program (Intrări).
 Sau, traducerea într -un limbaj de programare a unuia sau mai multor algoritmi.

O definiție mai cuprinzătoare :
Un produs software este un rezultat/produs obținut în urma unui proces
creativ uman , fiind un obiect/i nstrument utilitar , distinct și identificabil individual
ca element logic și care există în format electronic pe un suport de memorie
magnetică/optică de tip FD (floppy disk), HD (hard disk), CD (compact disk).
Formatul electronic al produsului poate reprezenta:
un prog ram ce rezolvă anumite probleme;
un sistem de operare;
un sistem informatic;
un compilator;
un interpretor;
un program convertor;
un pr ogram utilitar;
un mediu de operare;
un mediu d e programare;
un mediu de rezolvare;
o platformă;
o procedură;
un program editor;
un generator de programme;
un program antivirus;
un document HTML/PHP/ASP;
un program de e -mail;
un browser etc.
Temă: DEFINIȚ I TOȚI TERMENII ENUMERAȚI MAI SUS!

Trebuie să avem în vedere permanent următoarele concepte și interacțiuni:

ALGORITM = LOGICĂ + CONTROL ( R. Kowalski 1979 )
PROGRAM = ALGORITM + STRUCTURI DE DATE ( N. Wirth 1976 )
SISTEM EXPERT = CUNOAȘ TERE + METAINTERPR ETARE (Sterling 1984 )
MODELARE = CUNOAȘ TERE + REPREZENTARE
LIMBAJE = PROCESARE + INTERPRETARE

2 http://cs.wwc.edu/ -aabyan

Probleme generale ale ingineriei programării

10
3. Care sunt f azele realizării unui program ?
Fazele realizării unui program sunt prezentate în schema
alăturată.
În literatura de specialitate mai întâlnim și varianta: analiza,
proiectarea, implementarea, testarea, exploatarea și întreținerea.

4. Care este s tructura clasică a unui program ?
Structura clasică a unui program este:

 Întrebări
1. Definiți conceptul de program informatic.
2. Care sunt caracteristicile programelor informatice?
3. Ce se înțelege prin portabilitatea unui program?
4. Care sunt etapele realizării unui program?
5. Cum se definește o expresie?

5. Ce este un a lgoritm ?
Algoritmul reprezintă o metodă prin care sunt descriși p așii necesari rezolvării unei
probleme – o succesiune de etape aplicate unei probleme specificate cu scopul obținerii unei
soluții, pornind de la un set de date de intrare.
Algoritmii pot fi reprezentați prin mai multe procedee. Cele mai cunoscute fiind
reprezentarea în pseudocod și cu ajutorul schemei logice.
Schema logică reprezintă o modalitate grafică de reprezentare a algoritmilor. Simbolurile
de bază utilizate într -o schemă logică sunt:

GENERALITĂȚI ALE INGINERI EI PROGRAM ĂRII
CURS 1 – ANUL III
INFORMATICĂ ECONOMICĂ
11 Pseudocodul este un mijloc (un limbaj)
de exprimare naturală și de dezvoltare
sistematică a algoritmilor.
Un algoritm definit prin pseudocod
este format din două tipuri de propoziții:
standard și nestandard.
Enunțurile nestandar d sunt fraze în
limbajul natural, care pot fi utilizate de
programator în schițarea formelor inițiale ale
algoritmilor.
În dezvoltarea algoritmilor ele sunt
înlocuite treptat, cu enunțuri standard , care
exprimă operații corespondente direct în
limbajele d e programare.
 Întrebări
1. Definiți conceptul de algoritm.
6. Ce este un limbaj de
programare ?
Limbajul de programare reprezintă o
tehnică de comunicare dintre om și calculator,
caracterizată prin vocabular, sintaxă și
semantică proprii .
Limbajul de progr amare se caracterizează prin:
 vocabular – mulțimea cuvintelor rezervate;
 sintaxă – reguli de compunere a propozițiilor
(instrucțiunilor sau expresiilor);
 regulile de punctuație;
 semantică – semnificațiile atribuite cuvintelor și
instrucțiunilor.
7. Care sunt f azele execuției unui program scris în
limbaj simbolic?
Fazele execuției unui program scris în limbaj simbolic sunt:
 Translatarea (traducerea sau compilarea) unui program din
programul sursă (PS) în programul obiect (PO) se poate face:
 Cu ajutorul unui interpretor – care translatează fiecare
instrucțiune și apoi încearcă să o execute.
 Cu ajutorul unui compilator – care traduce un modul (sau
întregul program) și apoi încearcă să îl lanseze în
execuție.
 Întrebări
1. Definiți conceptul de limbaj de programare.
2. Prin ce se caracterizează un limbaj de programare?
5. Care sunt fazele de execuție ale unui program scris în limbaj simbolic? Simbol Semnificație

Conectori

Test condiție ( Bloc
de control )

Început și sfârșit
prelucrare

Prelucrări

Operațiuni de
intrare -ieșire

Succesiunea
prelucrărilor

Subruti nă ( set de
prelucrări )

Probleme generale ale ingineriei programării

12 8. Care sunt m etode le de programare ?
Metoda de programare reprezintă un set de concepte, principii și regulile
aferente, după care programatorul se poate ghida în scrierea programelor.
În decursul timpului au fost dezvoltate mai multe metode de programare ,
dintre care cele mai importante sunt:
 programarea structurată,
 programarea orientată pe obiecte și
 programarea dirijată de evenimente.
Programarea structurată
Programarea structurată sau fără GO TO, este metoda de programare prin care modulele
de program se execută de sus în jos (fără revenire) . Programarea riguros structurată sau din clasa
D, are la bază teorema fundamentală a programării structurate emisă și demonstrată de Corrado
BOHM și Giuseppe JACOPINI în 1966.
Conform acestei teoreme:
Orice program/algoritm poate fi rezolvat prin trei structuri fundamentale de control:
liniară, alternativă și repetitivă cu test inițial.
 Structura liniară (sau secvențială) se poate simboliza astfel:

 Structura alternativă se poate simboliza astfel:

GENERALITĂȚI ALE INGINERI EI PROGRAM ĂRII
CURS 1 – ANUL III
INFORMATICĂ ECONOMICĂ
13

 Structura repetitivă cu test inițial.

9. Ce este p rogramarea orientată pe obiecte ?
Programarea orientată pe obiecte (OOP – Object Oriented Programming) este tehnica prin
care programul este format dintr -un ansamblu de obiecte care comunică între ele prin
intermediul mesajelor.
Conceptele de bază ale programării orientate obiect sunt:
 obiectul,
 abstractizarea,
 încapsularea,
 moștenirea,
 polimorfismul și persistența.
10. Ce este p rogramarea dirijată de evenimente ?
Sub un sistem de operare cu interfață grafică, programele nu sunt executate într -o ordine
stric tă și previzibilă din momentul programării. Derularea une i aplicații poate urma o mulțime de
alternative determinate de opțiunile utilizatorului sau de semnalele generate de sistem.
Practic programul este în așteptare și când se declanșează un eveniment se realizează
prelucrarea specifică rezolvării acestui eve niment.
În paradigma programării dirijată de evenimente programul se află într -o stare de
așteptare, iar în momentul apariției unui eveniment va executa acțiunea definită de programator.
 Întrebări
1. Definiți conceptul de metodă de programare.
2. Care sunt cele mai cunoscute metode de programare?
3. Care sunt structurile fundamentale de control specifice programării structurate?
4. Care sunt principalele conceptele de bază ale programării orientate pe obiecte?

Probleme generale ale ingineriei programării

14 5. Prin ce se caracterizează paradigma prog ramării dirijată de evenimente?

 Criza software -premisa apariției domeniului ingineriei
programării

Un produs program, ca obiect utilitar distinct și identificabil (de exemplu, un interpretor,
un compilator, un s istem de operare, un joc, un sistem info rmatic pentru gestiune), este
rezultatul unui proces creativ uman , ca multe alte produse rezultate din activitatea uman ă.
Exist ă însă câteva caracteristici ale programelor care le deosebesc de alte obiecte și
anume:
 un program este un element logic și nu fizic, acesta fiind în esen ță dezvoltat , nu
fabricat în sensul clasic, fapt ce influen țează distribuirea costurilor pe fazele procesului de
produc ție;
 între ținerea programelor implic ă un grad mai mare de complexitate , deoarece
nu exist ă piese de rezerv ă pentru programe.
 Fiecare defect indic ă o eroare în proiectare sau în procesul de implementare.
Problema 1. În ultimele dou ă decenii, s -a constatat o evolu ție ascendent ă a ponderii
sistemului de programe (ca num ăr, performan țe și cost) în cadrul sistemelor d e prelucrare
automat ă a datelor.
Datele statistice arat ă că ponderea costului programelor în cadrul sistemelor de prelucrare
automat ă a datelor era de 25% în 1960, 50% în 1970, 75% în 1980 și 90% în 1990.
În concluzie : costul echipamentelor tinde s ă fie n eglijabil în raport cu costul programelor.
Problema 2. O alt ă problem ă o reprezint ă creșterea continu ă a cererii de programe pe
piață. Se apreciaz ă că cererea de personal specializat în prelucrarea datelor cre ște cu 12% pe an,
iar ritmul real de cre ștere a a personalului angajat în prelucrarea datelor este de 4% pe an. Efectul
global îl reprezint ă creșterea continu ă a distan ței dintre cererea și oferta de programe.
Criza software reprezint ă motivul principal al apari ției domeniului ingineriei program ării
(IP). Aceasta s -a manifestat încep ând cu anii '60 prin următoarele tr ăsături:
termenele de livrare a programelor nu erau respectate
costurile de dezvoltare și între ținere a programelor erau subestimate
productivitatea în produc ția de programe era mic ă
prog ramele nu corespundeau întru totul cerin țelor utilizatorilor
erau detectate numeroase erori în programele livrate
programele erau greu de adaptat noilor cerin țe
Rezultatul final al crizei software l-a constituit creșterea inacceptabil ă a costului software –
ului, incluz ând dezvoltarea, între ținerea, etc .
Solu ția acestei probleme a ap ărut la o conferin ță a NATO în 1968, când s-a propus
ABORDAREA DEZVOLTĂRII PROGRAMELOR PRIN METODE INGINEREȘTI , ceea ce a dus la apari ția
domeniului ingineriei program ării.
Definiția dat ă atunci acestui domeniu a fost următoarea :
 IP urm ărește stabilirea și utilizarea de principii inginere ști robuste pentru
obținerea cu costuri c ât mai mici a unor produse soft ware fiabile și care să
ruleze eficient pe calculatoarele existente.
Aceast ă defini ție nu s -a modificat ulterior prea mult. Spre exemplu , defini ția dat ă de
Glosarul Standard de Termeni din Ingineria Program ării al IEEE (`83) este următoarea :

GENERALITĂȚI ALE INGINERI EI PROGRAM ĂRII
CURS 1 – ANUL III
INFORMATICĂ ECONOMICĂ
15  IP reprezint ă abordarea sistematic ă în dezvoltarea, operarea, întreținerea și
retra gerea programelor.

 Caracteristici ale domeniului ingineriei program ării

1. IP SE REFERĂ LA DEZVOLTAREA DE PROGRAME MARI.
Programarea -în-mic = dezvoltarea unui program de c ătre o persoan ă, într-o perioad ă
relativ scurt ă de timp (de regul ă mai mic ă de 6 luni). Apeleaz ă de regul ă la tehnicile
conven ționale de programare: programare modular ă, programare structurat ă, diagrame de
structur ă, etc.)
Programarea -în-mare = dezvoltarea unui program de c ătre un grup de persoane, într-o
perioad ă relativ mare de timp. (de regul ă mai mare de 6 luni).
2. UN OBIECTIV PRINCIPAL AL IP ESTE STĂPÂNIREA COMPLEXITĂȚII .
Acest lucru se realizeaz ă prin aplicarea teoremei fundamentale a ingineriei
program ării. Să presupunem c ă
 M(P) = m ăsura complexit ății problemei P și
 C(P) = cos tul rezolv ării lui P.
În mod evident, dacă M(P) > M(Q) atunci C(P) > C(Q).
Pentru dou ă probleme P și Q, C(P+Q) > C(P) + C(Q)
Este clar c ă deoarece M(P+Q) include și măsura interac țiunii dintre P și Q, avem M(P+Q) >
M(P) + M(Q) de unde rezult ă enun țul teor emei.
3. PROGRAMAREA -ÎN-MARE PRESUPUNE COOPERAREA ÎNTRE OAMENI ÎN GENERAL ȘI
ÎNTRE PROGRAMATORI ÎN SPECIAL.
Se au în vedere:
 distribu ția muncii
 metodele de comunicare
 responsabilit ățile
Succesul unui proiect depinde în mare m ăsură de disciplina participan ților (manageri,
anali ști, programatori).
4. IP ARE ÎN VEDERE EVOLUȚIA PROGRAMELOR. Orice program modeleaz ă o parte a
realit ății și, deoarece realitatea evolueaz ă, programele evolueaz ă și ele, deci trebuie
alocate costuri pentru evolu ție chiar dup ă livrarea pr ogramului .
5. IP ARE ÎN VEDERE MINIMIZAREA COSTURILOR DEZVOLTĂRII ȘI ÎNTREȚINERII
PROGRAMELOR .
Costurile se refer ă la consumurile de:
 Timp
 Efort
 resurse umane
 resurse financiare
6. IP ARE ÎN VEDERE CA PROGRAMELE SĂ CORESPUNDĂ CERINȚELOR REALE ALE
UTILIZATORILO R, adic ă să fie:
 func ționale
 fiabile
 prietenoase
 ușor de instalat
Concluzie: activitatea de programare ( codificare ) este inclus ă în IP și incluziunea este strict ă.

Probleme generale ale ingineriei programării

16
 Noțiunea de produs program
Un obiectiv principal al IP este ob ținerea de produse program ( PP).
Un PP este rezultatul unui proces creativ uman, în care este înglobat ă o mulțime eterogen ă
de elemente:
 imagina ție și rigoare,
 cuno ștințe și experien ță,
 inteligen ță și
 tehnic ă de calcul, care împreun ă cu
 un calculator (parte hardware) efectueaz ă toate prelucr ările dorite de utilizator.
Dificultatea el aborării PP rezid ă în caracterul logic, abstract al acestora. Astfel, spre
deosebire de alte obiecte produse de oameni, un PP nu este fabricat, ci este dezvoltat.
 Clasificarea PP
a. produse generice (PPG ): sunt PP ale unei companii de dezvoltare care sunt v ândute
pe pia ța liber ă oricărui client interesat
b. produse personalizate (PPP): sunt produse program destinate unui client
particular. Ele sunt dezvoltate special pentru acel client de c ătre un contracto r
Aceste categorii de PP difer ă semnificativ în specifica ții:
1. specifica țiile PPG sunt produse intern de departamentul de marketing al companiei
respective și ele reflect ă ceea ce cred membrii acestui departament c ă s-ar vinde (sunt
flexibile și neprescript ive)
2. specifica țiile PPP sunt baza contractului între client și contractor . Sunt foarte detaliate și se
negociaz ă foarte atent.
 Atributele PP
Atributele PP se refer ă la caracteristicile unui PP odat ă instalat și pus în exploatare . Ele nu
se refer ă la servic iile furnizate de PP, ci la utilitatea și calitatea acestora.
Atributele esen țiale ale unui PP sunt:
i) MENTENABILITATE : reflect ă capacitatea unui PP de a evolua pentru a satisface cerin țele în
continu ă schimbare ale clien ților
ii) CREDIBILITATE: reflect ă nivelul de încrederea într-un PP. Include caracteristici ca:
fiabilitate, siguran ță, securitate. Un PP credibil nu trebuie s ă cauzeze pagube fizice sau
economice în cazul apari ției unor defecte în func ționare
iii) EFICIENȚĂ: reflect ă măsura în care un PP folose ște resursele sistemului (memorie și timp
procesor)
iv) UTILIZABILITATE : reflect ă măsura în care un PP este u șor de folosit și bine documentat
 Metode de dezvoltare a programelor
Exist ă două abord ări principal și principial diferite în dezvoltarea programelor. Uneori ele
sunt numite paradigme de dezvoltare . Acestea sunt:
 paradigma structurat ă, predominant ă în anii `80
 paradigma orientat ă pe obiect, predominant ă în anii `90

GENERALITĂȚI ALE INGINERI EI PROGRAM ĂRII
CURS 1 – ANUL III
INFORMATICĂ ECONOMICĂ
17  Paradigma structurat ă
Aceast ă paradigm ă se bazeaz ă pe abstractizarea no țiunilor de procedur ă, funcție și
structur ă de bloc din limbaje de programare cum sunt Algol și Pascal. Uneori aceast ă paradigm ă
se nume ște func țional ă deoarece sugereaz ă rezolvarea unei probleme prin descompunere
func țional ă. PS pleac ă de la comportamentul dorit al PP pe care îl descompune utiliz ând un
procedeu de sus în jos – „top-down ”, până la obținerea unor elemente ce pot fi implementate
direct.
Dezavantaj :
Rezultatele ob ținute prin aplicarea metodelor acestei paradigme sunt puternic
dependente de problem ă și au astfel un g rad redus de reutilizabilitate , chiar și la probleme
asem ănătoare.
 Paradigma orientat ă pe obiect
Aceast ă paradigm ă inverseaz ă metodologiile
structurate, accentul fiind pus pe identificarea obiectelor
din domeniul problemei și nu pe descompunerea
func țională a problemei .
Avantaj :
La orice nivel în cadrul procesului de dezvoltare
pot fi identificate elemente candidate la reutilizare.
Se nume ște metod ă de dezvoltare cu un triplet compus din:
 O nota ție împreun ă cu semantica asociat ă, destinat ă model ării dive rselor aspecte
ale problemei sau PP, în cadrul procesului de dezvoltare
 O procedur ă/pseudo -algoritm/re țetă de aplicare a acestei nota ții
 Un criteriu de m ăsurare a progresului și decizie a termin ării
În general o metod ă acoper ă mai mult sau mai pu țin urm ătoarele activit ăți ale CVPP :
analiza, proiectarea, implementarea.
Observații:
În PS accentul este pus pe prelucr ări, cu alte cuvinte pe aspectul dinamic al
problemei.
În POO, accentul se pune pe ce anume se prelucreaz ă, cu alte cuvinte pe aspectul
static al problemei.
Metodele moderne de dezvoltare folosesc modele multiple ale problemei pentru a
nu neglija nici unele dintre aceste aspecte.
O astfel de metod ă este metoda UML – „Unified Modelling Language”.
În cazul metodelor de dezvoltare apar ținând para digmei orientate pe obiect (MDOO),
vom întâlni urm ătoarele activit ăți:
 Analiza orientat ă pe obiect : este o metod ă de analiz ă care examineaz ă
cerin țele din perspectiva claselor și obiectelor identificate în cadrul vocabularului
domeniului problemei.
 Proiect area orientat ă pe obiect : este acea metod ă de proiectare care
cuprinde un proces de decompozi ție orientat pe obiect și o nota ție pentru descrierea
atât a modelului logic și fizic, c ât și a celui static și dinamic al sistemului proiectat.

Probleme generale ale ingineriei programării

18 Noțiunea de descom punere orientat ă pe obiect se define ște prin constrast cu
decompozi ția func țional ă, specific ă metodelor de dezvoltare structurat ă, în care
accentul este pus pe algoritmi și nu pe obiecte.
 Programarea orientat ă pe obiect : este o metod ă de implementare
(codi ficare) în care programele sunt organizate sub forma unor colec ții de obiecte
coooperante, fiecare obiect fiind o instan ță a unei anumite clase, iar clasele sunt
membre ale unei ierarhii de clase construit ă pe baza unor relații de mo ștenire.

 Ce Este Model area Orientată pe Obiecte?
Ce Este un Model?
Un model este o abstractiune care scoate in evidenta partile esentiale ale unei probleme
sau structuri complexe, filtrand toate detaliile neesentiale , facand prin aceasta problema mai
usor de inteles.
Abstracti zarea este o capacitate fundamentala de care dispunem pentru a trata
complexitatea. Este de neconceput construirea unui avion sau a unui automobil
fara construirea in prealabil a unor modele, dupa cum si microprocesoarele sau
sistemele de telefonie necesit a un anumit grad de modelare pentru a putea fi mai
bine intelese, si pentru a putea comunica aceasta intelegere si altora.
Pe scurt, un model este o simplificare a realitatii.
Modelele pot fi construite la diferite nivele de detaliere de la foarte general, la
extrem de detaliat.
Un sistem poate fi descris din diferite perspective utilizand diferite modele, iar
fiecare model reprezinta o abstractiune cu o puternica contotatie semantica .
Un model poate fi:
 structural – descriind relatiile logice si statice intre componentele sistemului – sau
 dinamic (behavioral) – modeland comportamentul dinamic al sistemului la
executie.
 De Ce Modelă m?
Există un motiv fundamental care ne determi na să modelam: Construim modele
pentru a putea intelege mai bine sistemul pe ca re il dezvoltam. Modela rea ne ajuta in
urmatoarele privinte:
Modelele ne ajuta sa vizualizam un sistem asa cum este el, sau asa cum l -am dori sa fie.
Modelele ne permit sa specificam structura si comportamentul unui sistem.
Modelele ne ofera un tipar care sa controleze construirea sistemului
Modelele documenteaza deciziile pe care le luam in timpul dezoltarii sistemului.
Desi modelarea este benefica si pentru sistemele de mici dimensiuni, ea devine cu atat mai
importanta, cu cat sistemul pe care il construi m este mai mare si mai complex.
De fapt, construim modele ale sistemelor complexe pentru ca mintea umana nu poate
cuprinde a semenea sisteme in intregime.
 Triunghiul Succesului
Pentru realizarea unui proiect reusit , avem nevoie de toate cele trei fatete: – o notatie ,
un proces si un instrument .

GENERALITĂȚI ALE INGINERI EI PROGRAM ĂRII
CURS 1 – ANUL III
INFORMATICĂ ECONOMICĂ
19
Poti invata regulile unei notatii, dar daca nu stii cum sa o folosesti (procesul), proiectul pe
care il faci probabil va esua.
La fel de bine, s -ar putea sa dispui de un proces fenomenal , dar daca iti lispeste
capacitatea de a comunica procesul – printr -o notatie adecvata – este deasemenea foarte
probabil ca vei esua.
Si, in fine, pentru ca procesul si notatia sa poate fi folosite eficient, ai nevoie de un
instrument care sa -ti faciliteze acest lucru .
Cel mai s implu instrument este constituit din hartie+creion, dar acesta nu este cel mai
eficient. Este de preferat un instrument software.
Pentru a avea o imagine intuitiva asupra celor afirmate aici, vom lua un exemplu la
indemana oricarui programator:
Daca dorim sa cream un program si sa -l executam pe calculator avem nevoie de o
notatie cu ajutorul careia sa descriem programul respectiv. O asemenea notatie ar
putea fi limbajul masina. Cunoastem cu totii "expresivitatea" si "puterea de
abstractie" a unei asemenea notatii si drept urmare, daca dispunem de un limbaj de
programare de nivel inalt, il vom prefera pe acesta.
Cunoasterea unui limbaj de programare de nivel oricat de inalt, doar ca notatie
in sine, nu ne este de prea mare ajutor in scrierea programelor.
Trebuie sa stapanim procesul de transpunere a unei probleme date intr -o
succesiune de pasi care sa poata fi descrisi in termenii limbajului de programare.
In fine, pentru a putea obtine forma executabila a programului , este necesara
traducerea acestuia in limbaj masina. Ce e drept, nu ne impiedica nimeni sa facem
aceasta treaba manual, dar sub aspectul eficientei si al preciziei cel putin,
rezultatele vor fi probabil dezastruoase (mai ales daca timpul in care trebuie dusa
la indeplinire aceasta sarcina nu e ste infinit).
Un instrument software, compilatorul in acest caz, este mai mult decat de dorit.
In orice model notatia joaca un rol important, intrucat ea reprezinta liantul care tine
laolalta intreg procesul de dezvoltare .
Conform lui Booch [Booch95] NOTAȚIA ARE TREI ROLURI PRINCIPALE :
este limbajul de comunicare a deciziilor care nu sunt evidente si care nu pot fi deduse
din cod
ofera o semantica suficient de bogata pentru a descrie toate deciziile strategice si
tactice .
ofera o forma suficient de concr eta pentru ca oamenii sa o inteleaga iar masinile sa o
manipuleze.

Notatia UML (Unified Modeling Language) reprezinta o notatie extrem de robusta, ale
carei elemente pot acoperi atat faza de analiza cat si pe cea de proiectare .
Astfel, anumite elemente ale notatiei (ex. clase, relatii de asociere, agregare, mostenire
etc) sunt introduse in timpul analizei, in timp ce alte elemente ale notatiei (ex. proprietatile
claselor si indicatori legati de implementare ) vor fi int roduse in timpul proiectarii.

Probleme generale ale ingineriei programării

20  Procesul de Dezvoltare Software . Rolul unui Proces de Dezvoltare

PROCESUL DE DEZVOLTARE SOFTWARE (sau ciclul de viata) este succesiunea activitatilor
desfasurate in vederea dezvoltarii unui sistem software.
Un produs software de succes este unul care sati sface si chiar depaseste asteptarile
clientilor sai, care se incadreaza in limitele financiare si de timp impuse, si este usor adaptabil la
schimbari.
Ciclul de dezvoltare trebuie sa promoveze creativitatea si inovatia.
In acelasi timp, procesul de dezvo ltare trebuie sa poata fi controlabil si
masurabil pentru a putea asigura indeplinirea completa si corecta a tuturor cerintelor.
Booch afirma ca, "creativitatea este esentiala pentru construirea unor arhitecturi
orientate -obiect bine structurate , dar ace ia care permit in cadrul dezvoltarii o
creativitate nelimitata tind sa nu ajunga la o finalitate.
In mod similar, disciplina este necesara in organizarea eforturilor unei echipe de
dezvoltare, dar prea multa disciplina da nastere unei birocratii ingrozito are care ucide
in fasa orice tentativa de inovatie"[Booch95].
Un ciclu de viata iterativ si incremental bine condus va oferi controlul necesar fara a
afecta creativitatea.
 Dezvoltarea Incrementala si Iterativa a Software -ului
 Intr-un ciclu de viata itera tiv si incremental procesul de dezvoltare e ste
conceput ca o serie de iteratii care evolueaza inspre sistemul final.
 Fiecare iteratie se soldeaza cu dezvoltarea unei noi "bucati" care se adauga
la produsul obtinut in iteratia anterioara, sau cu modificare a unei parti
dezvoltate anterior.
 O iteratie consta din executia uneia sau mai multor activitati dintre cele de
mai jos:
 Captarea cerinț elor
 Analiza
 Proiectarea
 Implementarea
 Testarea
Acest tip de proces are la baza ideea ca cerintele nu sunt cunoscute in totalitate la inceputul
ciclului de viata; prin urmare, schimbarea trebuie anticipata de -a lungul tuturor fazelor .
Rational Objectory Process este un exemplu de proces iterativ si incremental care poate fi
analizat pe doua planuri:
 Temporal : reprezinta d ivizarea procesului pe faze.
 Al activitatilor : reprezinta enumerarea activitatilor componente si a produselor
rezultate din fiecare activitate.
 Fazele procesului Rational Objectory:
 Initiere = specificarea viziunii asupra proiectului
 Elaborare = planificar ea actiunilor si a resurselor necesare, specificarea
caracteristicilor si proiectarea arhitecturii.
 Constructie = construirea produsului in mod iterativ si incremental.

GENERALITĂȚI ALE INGINERI EI PROGRAM ĂRII
CURS 1 – ANUL III
INFORMATICĂ ECONOMICĂ
21  Tranzitie = livrarea produsului catre comunitatea de utilizatori.
Activitatile componen te ale procesului Rational Objectory:
 Captarea cerintelor = descrierea a ceea ce ar trebui sa faca sistemul.
 Analiza si proiectarea = descrierea modului in care va fi realizat sistemul.
 Implementare = scrierea codului pentru programele executabile.
 Test = verificarea produsului.
 Desfasurare = configurarea si livrarea produsului.
 Activitati de intretinere = controlul actualizarilor si modificarilor aduse
sistemului.
 Activitati de suport = activitatea de management si asigurarea infrastructurii
necesare dezvo ltarii sistemului.
Fiecare dintre activitati se desfasoara, intr -o masura mai mica sau mai mare, i n toate fazele
procesului:
Orice metoda de dezvoltare software, implica – chiar daca nu in mod absolut – existenta
unui instrument software care sa o faca ap licabila. Spuneam ca necesitatea nu este aboluta in
sensul in care creionul si hartia ar putea fi si ele imaginate ca "instrumente" de modelare ; pentru
momentul actual insa, acestea sunt departe de cerintele care se impun. Astazi exista pe piata o
multitud ine de astfel de instrumente de modelare, de la simple programe de desenare la
instrumente de modelare sofisticate dezvoltate pentru aplicatii orientate -obiect.
Astăzi se face uz de software -ul de modelare numit Rational Rose , actual lider
incontestabil in domeniul acestor instrumente software.
Familia de produse Rational Rose este gandita sa ofere proiectantilor de software orientat
pe obiecte un set complet de instrumente de modelare vizuala , care sa permita dezvoltarea unor
solutii robuste si eficiente adaptate cerintelor pietii in domenii cum ar fi aplicatiile client -server,
sisteme distribuite, sau sisteme de timp real.
Rational Rose v ofera un standard si un limbaj comun, care sa permita pe de o parte
programatorilor sa modeleze logica aplicatiilor , dar in acelasi timp sa permita ne-programatorilor
modelarea procesului ce se doreste realizat prin intermediul respectivei aplicatii .
Detalii despre Rational Rose precum si ultimele noutati pot fi consultate pe Internet la
adresa http://www.rational.com
 Facilitati
Acest instrument de modelare ofera urmatoarele facilitati:
Identificarea si proiectarea unor obiecte non -software (business objects), si
maparea lor in componente software
Partitionarea seriviciilor conf orm unui model bazat pe trei nivele.
Proiectarea distribuirii componentelor intr -o retea
Capacitatea de reverse -engineering pentru creare de modele din componente si
aplicatii existente.
Capacitatea de round -trip engineering pentru a pastra sincronizate pr oiectul si
implementarea sa (codul).