ALTE DOCUMENTE
|
||||||||||
Software engineering: stadiul actual, tendinte
1.1. Ingineria software; proiectarea si realizarea software-ului
Un produs software vazut ca obiect utilitar distinct si identificabil individual este rezultatul unui proces creativ uman (ca multe altele) cu caracteristici specifice ce il fac net diferit de alte obiecte construite de oameni:
- este un element logic si nu unul fizic fiind in principal dezvoltat si nu manufacturat;
- nu se "uzeaza" la fel ca produsele fizice (datorita utilizarii sau folosirii lui); software-ul se deterioreaza datorita unor defecte de proiectare sau la modificare;
- intretinerea software-ului implica un grad mai mare de complexitate pentru ca nu exista "piese de rezerva"; in momentul "defectarii" se cauta cauza in proiectare sau in procesul de transformare in cod executabil;
- se face, de regula, la comanda si nu in "serie" (prin asamblare de componente existente), etc.
Ingineria software este aceea care tinind cont de aceste caracteristici incearca sa stabileasca "principii ingineresti valide pentru a obtine economic software care este fiabil si functioneaza eficient".
Procesul ingineriei software contine 3 faze generice:
a) definirea = in care se pune accentul pe "ce": ce informatii trebuie prelucrate, ce functii / performante se doresc, ce interfete se cer, etc.
b) dezvoltarea = in care se stabileste "cum": cum trebuie proiectate structurile de date, cum se implementeaza detaliile procedurale, cum se traduce proiectul intr-un limbaj de programare, etc.
c) intretinerea = in care se evidentieaza "schimbarea": corectarea erorilor, adaptarea la noi cerinte, modificari pentru cresterea performantelor.
Aceste faze generice sint completate cu o serie de activitati "auxiliare" dar care concura impreuna la realizarea produsului software:
- evaluari, dupa fiecare etapa, pentru pastrarea calitatii
- realizarea documentatiei de proiectare, de implementare, de utilizare, etc.
In procesul dezvoltarii ingineriei software s-au evidentiat pina acum mai multe moduri de aplicare si realizare a acestor etape (mai multe "filozofii" sau "paradigme"):
a) Prima abor 959c23j dare poate fi denumita "ciclul de viata clasic" sau "modelul in cascada". Esenta acestui model este perfecta structurare si delimitare a fazelor prin care trece un produs software si "legarea in cascada" a acestor etape:
Ingineria │
sistemului ├────┐
│
│ ┌────┴────┐
│ │ Analiza ├───┐
│ └──┬──────┘ │
│ │ ┌───────┴─────┐
│ │ │ Proiectarea ├──┐
│ │ └────┬────────┘ │
│ │ │ ┌───────┴─────┐
│ │ │ │ Codificarea ├───┐
│ │ │ └─────┬───────┘ │
│ │ │ │ ┌─────┴────┐
│ │ │ │ │ Testarea ├──┐
│ │ │ │ └───┬──────┘ │
│ │ │ │ │ ┌──────┴───────┐
│ │ │ │ │ │ Intretinerea │
│ │ │ │ │ └──────┬───────┘
│ │ │ │ │ │
└───────────┴───────┴─────────┴─────────┴─────────┘
Fig. 1
Modelul in cascada
Acest model prezinta si mari deficiente:
- proiectele reale urmeaza rar fluxul secvential "ideal"; apar foarte des "iteratii" intre etapele intermediare ("feed back- uri")
- clientul nu poate intodeauna sa formuleze in mod explicit TOATE cerintele din primele etape (pentru a realiza complet aceste etape)
- clientul trebuie sa aiba rabdare; o versiune functionala apare tirziu (dupa codificare); orice defect detectat implica reluarea (iterarea) etapelor anterioare.
b) Prototipizarea = consta in realizarea unui "model" al software-ului ce va fi construit, pe baza caruia se stabilesc cerintele de proiectare. Modelul poate lua una din formele:
- prototip pe hirtie = ce prezinta interactiunea / functiunile ce le va indeplini software-ul intr-un mod sugestiv pe hirtie
- prototip functional = ce implementeaza un subset al functiilor (de obicei cele mai simple) si sugereaza celelalte functii
- program existent = executa o parte din functiile cerute (eventual chiar "aproximativ"), dar are si alte facilitati nelegate direct de proiectul software ce se proiecteaza.
Prototipul serveste doar ca "prim sistem", se creaza nu pentru a fi livrat, ci doar pentru a ajuta la proiectarea software-ului. Daca prototipul este functional se va incerca refolosirea unei parti din el (structuri de date, proceduri, etc)
│ Colectarea ├───┐
│ de cerinte │ │
│ │ │ Proiectare │
│ │ │ "rapida" ├────┐
│ │ │ │ Constructie ├───┐
│ │ │ │ prototip │ │
│ │ Evaluare si ├───┐
│ │ rafinare cerinte │ │
└─────────────────────────────┘ │ │ Inginerie │
│ │ produs │
│ └─────┬──────┘
│ │
Fig. 2
Paradigma prototipizarii
Deficientele majore ale acestui mod de a realiza software:
- clientul vedea "ceea ce pare a fi o versiune functionala"; cind realizeaza ca produsul trebuie reconstruit cere, de obicei, "citeva mici schimbari" pentru a putea fi perfect adaptat nevoilor sale
- plecind de la un prototip, pentru a-l face rapid functional proiectantul este tentat sa faca unele compromisuri de proiectare care devin in cele din urma parti integrante ale sistemului
c) Tehnici de generatia a patra (4GT) = ce se bazeaza pe un set de unelte ce permit proiectantului specificarea unor caracteristici ale software-ului la un nivel foarte inalt (aproape in limbaj natural), uneltele generind apoi automat cod SURSA bazat pe aceste specificatii (CASE - "Computer Aided Software Engineering"). Aceasta implementare foloseste limbaje specializate, foarte evoluate = "limbaje de generatia a patra" (4GL).
│ Colectarea ├────┐
│ de cerinte │ │
│ │ Strategia de ├───┐
│ │ proiectare │ │
│ │ │ Implementare ├──────┐
│ │ │ cu 4GL │ │
│ │ │ │ Produs │
Fig. 3
Tehnici de generatia a patra
Limitarile principale ale acestui model sint:
- trebuie sa existe o structura de date cu informatii relevante usor accesibile, astfel incit domeniul actual de aplicabilitate este limitat (la sisteme informatice comerciale cum ar fi, de exemplu analiza si raportarea de informatii aflate in baze mari de date )
- timpul cerut pentru a produce software este redus pentru aplicatii mici si mijlocii, dar creste foarte mult pentru proiecte mari de dezvoltare de software.
Se observa deci, ca in ingineria software modelele de realizare a produselor software sint departe de a satisface cerintele actuale. Astfel incit se vorbeste in termeni foarte categorici (si de foarte mult timp) de o adevarata "criza software".
1.2. Criza software; necesitatea unei revolutii in software
In ultimii 20 ani ingineria hardware a beneficiat de pe urma revolutiei tehnologice, descoperind ca trebuie sa proiecteze si sa dezvolte folosind munca celorlalti. Cel ce a permis aceasta orientare in ingineria hardware a fost "chip"-ul. Aceasta adevarata "revolutie" in ingineria hardware a condus la imbunatatirea exponentiala a capabilitatii hardware.
Acest lucru nu s-a petrecut insa si cu ingineria software. In timp ce inginerii hardware au invatat sa construiasca cu module a caror putere a crescut exponential, inginerii software continua sa creeze programe ca intotdeauna punind instructiunile una linga alta.
"Revolutiile" ce au avut loc pina acum in software engineering sint net nesemnificative fata de evolutia ingineriei hardware.
Prima revolutie a avut loc atunci cind s-a realizat ca programele, odata ajunse in memoria calculatorului sint doar un alt tip de date ce pot fi manipulate de catre calculatorul insusi. Ca rezultat a fost aparitia TRANSLATOARELOR (compilatoare si interpretoare) ce traduc o notatie simbolica (utila oamenilor) intr-o succesiune de biti (utila masinii).
A doua revolutie a fost provocata de recunoasterea faptului ca transferul neconditionat al controlului in cadrul unui program este cauza majora a defectelor si proastei functionari a unui program. Aceasta s-a intimplat la sfirsitul anilor 60 - inceputul anilor 70 si s-a materializat in programarea structurata, si aparitia unor limbaje corespunzatoare (Algol si descendentii sai: C, Pascal).
Programele structurate sint organizate in concordanta cu operatiile ce le indeplinesc: fiecare program este impartit in proceduri individuale ce indeplinesc functii discrete. Prin izolarea proceselor in cadrul functiilor se minimizeaza transferul necontrolat in cadrul programului si sansele ca o functie sa afecteze alte functii. Acest lucru insa (din pacate) nu este valabil si pentru DATE.
Odata cu programarea structurata a fost introdus un concept nou si foarte puternic, care insa s-a folosit numai pe jumatate ABSTRACTIZAREA, avind doua componente:
- abstractizarea functionala = posibilitatea de a utiliza o functie fara a fi interesat de detaliile interne ale acesteia; implementari exhanstive: proceduri & functii.
- abstractizarea datelor = avind pina acum posibilitati de implementare neesentiale (tipurile de date real, integer...)
Odata cu aceasta revolutie software-ul a cunoscut o larga raspindire si intrebuintare in domeniile vietii reale. Complexitatea si functionalitatea sistemelor software a inceput sa creasca. Odata cu aceasta crestere au aparut din ce in ce mai pregnant si problemele. Sistemele software mari sint mult prea scumpe, slabe calitativ, greu de intretinut si aproape imposibil de condus de o persoana. Rezultatul ?
┌─────────────┬──────────┬───────
│ (5) = 2% │ │
├─────────────┤ │
│ (4) = 3% │ │
├─────────────┤ │
├─────────────┤ │
│ (2) = 29% │ Total 100 %
│ │ │
├─────────────┤ │
│ (1) = 47% │ │
│ │ │
│ │ │
│ │ │
Fig. 4
Costul sofware vs rezultate
(US Goverment Accounting Office, 1985 Report)
(1) = platit si nelivrat 47%
(2) = livrat dar nefolosit 29%
(3) = abandonat 19%
Total 1: 95%
(4) = folosit dupa reproiectare 3%
(5) = folosit la livrare 2%
Total 2: 5%
Aceasta situatie grava (adevarata "criza software") este cauzata de o mare cerere de software si insuficienta oferta de software de calitate. In general, se apreciaza decalajul dintre cererea de aplicatii si capacitatile hardware, pe de o parte, si produsele software de pe piata, pe de alta parte, ca fiind intre cinci si zece ani.
Este timpul pentru o adevarata revolutie in software. Revolutia este OOP (Object Oriented Programming) - Programarea Orientata pe Obiecte.
1.3. Constructia programelor vs. Constructia sistemelor software
Se apreciaza ca pina la 70% din cererea de software o reprezinta aplicatiile simple sau doar moderate ca si complexitate, care ar putea fi dezvoltate chiar de catre utilizatori, daca li s-ar pune la dispozitie "unelte adecvate". Avind aceste unelte adecvate utilizatorii ar putea sa-si creeze propriul software "personalizat" si mult imbunatatit. Ca o consecinta, va scadea presiunea asupra programatorilor de aplicatii de mare anvergura si asupra programatorilor de sistem, eliberindu-i de "povara" acestor mici aplicatii, putindu-se concentra pe dezvoltarea acelor aplicatii ce necesita o pregatire calificata si o experienta bogata.
Este o mare si fundamentala diferenta intre constructia si uneltele folosite pentru programe si cele pentru sisteme mari software.
Uneltele de constructie a programelor (unelte de programare la scara redusa) suporta si se bazeaza pe relatia programator - masina, in timp ce uneltele pentru constructia sistemelor (unelte de programare la scara larga) suporta si se bazeaza pe relatia dintre producatorul de software si consumatorul de software (consumator de cod).
Unealta esentiala si suficienta pentru constructia programelor este programarea structurata.
Pentru constructia sistemelor software avem nevoie de o unealta noua: OOP (Object Oriented Programming). OOP este inainte de toate o astfel de unealta (metoda) de proiectare si construire a sistemului software. OOP pune in centrul proiectarii refolosirea, facind din aceasta modul uzual de constructie a lucrurilor noi. In acest mod se imbunatateste atit productivitatea cit si se controleaza complexitatea sistemelor software si a costului intretinerii acestuia.
Daca proiectarea programelor se poate baza pe apeluri ocazitionale de rutine (functii, proceduri) din biblioteci, proiectarea sistemelor software se poate face eficient numai folosind componente deja construite (software IC). Un program se poate construi prin adaugarea unor "bare" (instructiuni) una linga alta. Un sistem se face prin asamblarea unor componente software produse de altii.
Constructia sistemelor software se deosebeste fundamental de constructia unor programe.
Exemplu
Automatizarea muncii intr-un birou ce lucreaza intens cu formulare (birou "paper-intensiv") ca de exemplu: banci, agentii de asigurari, agentii de relatii cu publicul, etc.
Se doreste folosirea unui sistem distribuit: mainframe, workstations (PC-uri), periferice grafice de inalta rezolutie.
Sistemul trebuie sa integreze in functiile lui toate datele, formularele si hirtiile "plimbate": liste (de preturi, de servicii, de angajare, etc), banci de date (telefoane, adrese, clienti, producatori, etc.), rapoarte, etc, etc.
O cerinta stricta dar absolut necesara: toate hirtiile computerizate trebuie sa arate si sa se "comporte" EXACT ca cele reale (cu care se lucreaza curent).
Modalitatea traditionala de realizare: se face o analiza, se discuta, se implementeaza ideile "reiesite" din discutii si apoi incepe sa se modifice ce s-a scris. Pare OK? Oare intr-adevar este OK ? NU! Dupa toate probabilitatile proiectul va fi abandonat fara a se livra si utiliza efectiv 1 singura linie de cod! De ce?
Aceste tipuri de sisteme implica o atitudine asupra MODIFICARII ce nu este oferita pina acum nici de uneltele de programare, nici de metodologii si nici de CONCEPTE. Un astfel de proiect este peste stadiul manufacturier (state-of-the-art), pentru ca astfel, cu metodele si conceptele traditionale nu se pot produce sisteme care sa supravietuiasca SCHIMBARILOR ulterioare.
Daca intr-un anumit moment a existat un "boom" al software- ului acesta s-a datorat maleabilitatii - fata de creion+hirtie, de exemplu. Aceasta a fost insa pentru aplicatii mici.
Diferenta primara dintre programe si sisteme software este capacitatea de adaptare la schimbare, reprezentata de mentenabilitate si extensibilitate.
Pina acum, un program (vazut ca o "cutie neagra") era responsabil de transformarea "intrarii" in "iesire". Aceasta perspectiva trateaza programarea ca o activitate comportamentalista in sensul clasic: dindu-se 2 programe A si B (ce rezolva aceeasi problema) singura cale de a face o distinctie intre ele este pe baza comportarii. Presupunind ca atit A cit si B reusesc transformarea unor intrari corecte in iesiri corecte se cauta criterii de comportare pentru a le deosebi:
- cum trateaza intrarile incorecte
- cit sint de rapide
- cit spatiu utilizeaza. Aceste criterii corespund celor 3 dimensiuni traditionale ale calitatii programelor: corectitudine, tratarea erorilor si exceptiilor si eficienta. In ultimul timp, pentru programe sau sisteme software pe scara redusa (de dimensiuni mici) se accepta si: portabilitatea si independenta fata de periferia calculatorului (display in primul rind, etc.)
Pentru sistemele software de mare anvergura aceste 3 (5) dimensiuni NU mai sint suficiente. Apar cel putin alte 2 criterii (cerinte) noi:
- mentenabilitatea = capacitatea de a fi usor schimbat pentru a elimina noi defecte descoperite, pentru a satisface adaptarii la noi cerinte;
- extensibilitatea = capacitatea de a fi modificat pentru a trata noi clase de intrari.
Pentru satisfacerea in conditii acceptabile a acestor noi dimensiuni pentru sistemele software trebuie facuta o deplasare de la modelul "cutiei negre a programului" la conceptele OOP. Aceste concepte OOP nu elimina modelul "cutiei negre" ci numai ii reduce "granularitatea" de la program la OBIECT. Obiectele devin acum cutii negre (contin informatie si prezinta o anumita comportare). In acest fel crearea si "schimbarea" sistemelor software devine mai eficienta si mai sigura.
Strategia conventionala de a domina schimbarea este elaborarea unor structuri defensive care sa o previna. Pina acum aceasta structura defensiva era semnatura beneficiarului pe cerintele de programare. Maleabilitatea este in acest caz responsabilitatea programului si nu a uneltelor sale.
Pentru a schimba aceasta stare trebuie considerata o alta cale:
1. sistemele pot fi facute mai maleabile lasind o anume elasticitate a rularii - relaxind cererea ca totul sa fie cunoscut si facut din primele etape ale constructiei - la compilare. Legarea dinamica (tirzie) sau "late binding" este un pas in aceasta directie.
2. sistemele pot fi facute mai adaptate la schimbare si mai interschimbabile facindu-le mai mici si mai usor de construit si de proiectat. Incapsularea si mostenirea reusesc aceasta.
3. sistemele pot fi create din obiecte (bucati) ce se comporta ca si "cutiile negre" ce nu interactioneaza decit prin metode specifice. Acestea sint mesajele.
Aceasta cale noua, ce contine aceste deziderate, se numeste generic "tehnologia impachetarii" (package tehnology). Sint cunoscute 3 tehnologii de impachetare:
Pipe = modalitate de conectare a unor programe in care iesirea unuia reprezinta intrare pentru altul
Filtre = programe mici, independente logic ce realizeaza o sarcina bine conturata (poate fi considerat o unealta)
Exemplu
Sa se determine numarul de cuvinte dintr-un text.
Se poate da "comanda":
tr -cs 'A-Za-zO-9' '\012' | sort -u | wc -l
unde:
tr = program (filtru) ce translateaza caractere
aici: orice caracter nealfanumeric in LF
Sort = program (filtru) ce sorteaza
aici: elimina duplicatele
wc = program (filtru) ce numara
aici: liniile
II. tehnologia bibliotecilor de subprograme (functii & proceduri)
In biblioteca exista functii ce realizeaza operatii bine definite. Are ca dezavantaj major faptul ca fiecare subprogram este strins legat de mediul pentru care a fost scris neputind fi integrat in altul.
Exemplu
Compilatorul cauta si el insusi cuvinte, are rutine pentru aceasta dar acestea nu pot fi refolosite ! Are totusi ca avantaj o eficienta net superioara metodei (I).
III. tehnologia OOP & software IC
OOP permite producatorilor crearea unor unitati cu functionalitate generica ce pot fi folosite de alti constructori (proiectanti) de software, vazuti ca si consumatori de software in diverse aplicatii specifice. OOP impacheteaza functionalitate astfel incit orice obiect poate fi refolosit asa cum e.
Discutie
Cele 3 metode acopera un spatiu continuu al legaturii ce poate sa existe intre diversi programatori (producatori de software).
Un capat al spectrului este tehnologia UNIX (I), unde legatura dintre programatori este extrem de slaba, iar celalalt capat este tehnologia subprogramelor (II) unde legatura este foarte puternica (fiind facut de consumatorul de software atunci cind scrie fiecare linie de cod).
OOP se afla intre aceste doua extreme , preluind si de la (I) si de la (II). Nu este nevoie de recompilari pentru reutilizare, iar eficienta codului este apropiata de cea a subprogramelor.
Exista insa si piedici obiective / subiective puse in calea dezvoltarii uneltelor software si a pietii software:
a) copierea neautorizata a software-ului
b) efortul de documentare a software-ului este mare
c) refolosire inseamna incredere in munca altuia
|
