Tehnici de dezvoltare a sistemelor informatice (elemente de inginerie software)

Tehnici de dezvoltare a sistemelor informatice (elemente de inginerie software)

Progresele inregistrate in domeniul tehnicii de calcul si mai ales in domeniul limbajelor de programare, au determinat aparitia si dezvoltarea Ingineriei Software (Software Engineering). Privita ca un cumul de metode si tehnici bazate pe realizari din domeniul IT, permite trece de la o dezvoltare a produselor ad-hoc si imprevizibila, la o dezvoltare structurata, constructiva si sistematica, cu scopul de a produce in mod industrial sisteme informatice de cea mai buna calitate.

Termenul a fost adoptat in 1968 la NATO Software Engineering Conference, tinuta la Garmisch, Germania. Include cunostinte, instrumente si metode pentru definirea cererilor, pentru specificarea, construirea si intretinerea programelor.

Dintre definitii mentionam:

F. L. Bauer (prima definitie data ingineriei software):

Ingineria programarii este stabilirea si utilizarea de principii ingineresti solide pentru a obtine in mod economic programe sigure si care functioneaza eficient pe masini de calcul reale.

IEEE Standard Glossary of Software Engineering Technology (1983):

Ingineria software reprezinta abordarea sistematica a dezvoltarii, functionarii, intretinerii si retragerii din functiune a programelor.

Acest domeniu:

▪▪▪ are ca scop dezvoltarea metodelor, instrumentelor si tehnicilor ce pot asigura un proces de producere software controlat, rezultatul fiind sisteme software performante si fiabile.

▪▪▪ este legat de tehnologii si practici apartinand stiintei calculatoarelor, managementului proiectelor, ingineriei, proiectarii interfetelor si altor domenii.

▪▪▪ este in relatie cu alte discipline de inginerie: inginerie de sistem si gestiune de proiecte, siguranta si fiabilitatea sistemelor.

▪▪▪ se preocupa de procedeele de construire software, astfel incat sa fie indeplinite urmatoarelor criterii:

▪ sistemul creat raspunde nevoilor utilizatorilor;

▪ calitatea corespunde contractului de service initial;

▪ costurile raman in limitele prevazute initial;

▪ intarzierile raman in limitele prevazute initial.

Tema:

Prezentati si comentati citeva definitii/caracteristici ale ingineriei software.

Principalele ramuri ale ingineriei software acopera:

▪ tehnicile de specificare

▪ tehnicile de conceptie

▪ tehnicile de validare/verificare

▪ gestiunea proiectelor

▪ aspectele socio-economice ale proiectelor de dezvoltare a produselor software.

1 Tehnici de specificare

Prin specificare intelegem o descriere a unor caracteristici ale produsului final, (un program sau o aplicatie formata dintr-un sistem de programe) care trebuie sa fie realizat in mod obligatoriu de catre proiectant (programator) pentru ca produsul sa poata fi acceptat si utilizat de beneficiarul sau.

In fiecare dintre etapele de dezvoltare a sistemelor software complexe scopul si instrumentele de descriere a specificatiilor sunt diferite. Corespunzator, exista diferite tehnici de specificare, caracteristice fiecarei faze de dezvoltare:

▪ tehnici de specificare a cerintelor sau a exigentelor functionale si nefunctionale (eficacitate, dimensiuni, siguranta in functionare etc.); se aplica in faza de analiza a cerintelor si se exprima, in general, in limbaj natural;

▪ tehnici de specificare a sistemului; se aplica in faza de analiza de sistem si se refera la natura functiilor oferite, la comportamentul dorit si la datele necesare pentru realizarea functiilor;

▪ tehnici de specificare a arhitecturii sistemului; se aplica in faza de conceptie generala si definesc modulele de arhitectura ce urmeaza sa fie realizate;

▪ tehnici de specificare tehnica (sau de detaliu); se aplica in faza de proiectare detaliata a modulelor, programelor si structurilor de date;

In teoria ingineriei software sunt recunoscute doua criterii de clasificare a specificatiilor:

1▪ prin formalismul utilizat:

▪▪ specificatii informale - exprimate, in general, in limbaj natural;

. permite comunicarea intre nespecialisti;

. nu impune reguli sau conventii de structurare si este lipsita de precizie,

fiind, prin urmare, dificil de analizat.

▪▪ specificatii semiformale - prezentate in general in forme grafice, avand un inteles mai mult sau mai putin precis;

. modelul nu este normalizat, fiind deschis fata de alte metode de reprezentare care aduc elemente specifice fara a denatura modelul;

. modelul permite specificarea structurilor de date si a relatiilor dintre elementele de date care compun structurile reprezentate;

▪▪ specificatii formale - a caror sintaxa si semantica sunt definite in mod formal printr-un aparat matematic adecvat.

. sunt bazate pe aparate matematice (teoria multimilor, logica clasica, logicile neclasice (cum ar fi logicile temporale) etc.

. sunt utilizate pentru specificarea tipurilor de date abstracte, dar pot fi generalizate pentru a permite specificarea unor sisteme complete (ex: limbajul "Z").

2 ▪ prin caracteristicile descrise:

. specificatii declarative - descriu doar proprietatile produsului, necesare pentru a raspunde cerintelor utilizatorului;

. specificatii operationale - descriu comportamentul produsului in raport cu cerintele utilizatorului; sunt descrise printr-un model care poate fi simulat pe o cale oarecare.

Tema:

Exemplificati utilizarea limbajului UML in specificarea semiformala a produselor software

2 Tehnici de conceptie

Faza de conceptie consta in construirea unei prime forme a sistemului, pe baza specificatiilor rezultate din faza de analiza. Prin rafinarea acestei prime forme, in etape succesive (iterativ), se obtine o imagine finala a sitemului, imagine ce permite trecerea la etapa de realizare a programelor (implementare).

Tehnicile de conceptie permit definirea arhitecturii logice a sistemului proiectat intr-o forma care corespunde cerintelor functionale exprimate in faza de analiza. Prin urmare, tehnicile de conceptie fac legatura intre cerintele utilizatorului si solutia de programare gasita pentru implementarea aplicatiei.

Sunt cunoscute in prezent doua paradigme, de conceptie diferita, privind modelarea conceptuala a produselor software: functionala si obiectuala.

Tehnicile functionale permit, in general, modelarea proceselor informationale sub trei aspecte, care pot fi vazute separat sau complementar:

1. dinamic, referitor la fluxurile de date si care reprezinta transformarea datelor in sistem;

2. static, referitor la structura logica a datelor (entitate-relatie);

functional, referitor la structura logica a prelucrarilor (componentele programabile si relatiile lor in sistem).

Printre cele mai cunoscute tehnici functionale se numara: SADT (Structured Analysis and Design Technique, JSD (Jackson Software Development), MERISE.

Tehnicile obiectuale (orientate obiect) au fost concepute pentru a permite dezvoltarea unor componente reutilizabile ale sistemelor software. Aceste componente (module) incorporeaza intr-o forma coerenta datele, functiunile si logica de control a modulelor programabile. Tehnicile obiectuale pot fi considerate ca fiind, in mod egal, metode de specificare (analiza) si metode de conceptie (proiectare).

Abordarea obiectuala se deosebeste de cea functionala prin faptul ca nu trateaza (separa) in mod distinct datele de prelucrari, propunand regruparea si asocierea datelor si prelucrarilor in entitati numite "obiecte". Fiecare obiect poseda un ansamblu de proprietati ale datelor cu care opereaza (numite "atribute") si un ansamblu de operatii predefinite (numite "metode") care ii permit sa raspunda unor cereri de prelucrare. Obiectele comunica intre ele prin mesaje care activeaza metodele din obiectele receptoare. Toate obiectele care poseda aceeasi structura apartin unei clase, toate obiectele similare ca structura fiind numite instante ale clasei careia ii apartin.

Sunt cunoscute mai multe astfel de metode: metoda OMT (Object Modeling Technique), metoda Booch, metoda OOSE (Object Oriented Software Engineering).

Tema:

Exemplificati utilizarea UML in faza de conceptie a produselor software

3 Tehnici de validare

Verificarea sistemelor software nu se refera numai la cod (program), acoperind toate produsele specifice fazelor ciclului de viata al unui proiect informatic. Rezultatul verificarii nu consta, in mod necesar, in acceptarea sau respingerea produsului. De cele mai multe ori, se cauta anomaliile posibile in functionarea produsului. Identificarea unor defectiuni posibile ale produselor software este limitata, mai ales in cazurile programelor de mari dimensiuni. Verificarea sistemelor software este necesara, in primul rand, pentru descoperirea erorilor de conceptie care pot influenta functionalitatea produsului (caz in care verificarea consta in testarea comportamentului produsului in diverse contexte de functionare), sau pentru identificarea cauzelor unor defectiuni care apar in functionarea curenta a produsului.

In terminologia IEEE (norma 729), termenul de defectiune (cadere) este folosit pentru a desemna o stare a produsului care genereaza o eroare manifestata printr-o anomalie in functionarea programului, si care consta in producerea unui rezultat anormal (in raport cu o anumita norma), sau intr-o pana provocata la nivelul sistemului gazda (blocaj unitate centrala sau periferice, blocarea sistemului de operare etc.):

Anomalie (fault)

Defectiune Eroare

Pana (failure)

Exista doua moduri de abordare a procesului de verificare, care trebuie sa fie considerate complementare:

verificare dinamica (numita si verificare experimentala sau testarea produsului) a comportamentului produsului folosind seturi de date care simuleaza conditiile reale de exploatare;

verificare statica si analiza proprietatilor produsului, fara simularea executiei programelor componente.

1 Verificare dinamica

Se efectueaza jocuri de test (de incercare) care nu pot fi, in general, exhaustive. Jocul de test este ales astfel incat rezultatele executiei programului sa fie comparabile cu rezultatele asteptate conform specificatiilor de functionare ale produsului (partiale sau globale). Scopul este de a pune in evidenta eventualele erori. Testele pot sa arate prezenta erorilor dar nu pot demonstra absenta erorilor.

In construirea testelor se disting trei moduri de abordare a constructiei jocurilor de test:

a) Abordarea aleatoare a testului

Testul este ales in mod aleator din domeniul de definitie al datelor de intrare ale programului. Domeniul de definitie este stabilit pe baza specificatiilor de interfata operator-masina ale programului (intrari-iesiri). Metoda nu garanteaza o buna acoperire a ansamblului intrarilor. In particular, testul poate sa nu surprinda unele limite sau situatii de exceptie, avand astfel o eficacitate limitata.

b) Abordarea functionala (sau a "cutiei negre") :

Se iau in considerare numai specificatiile privind functiunile programului (sau CE trebuie sa faca produsul). Specificatiile trebuie sa fie suficient de clare si complete pentru a permite verificarea fiecarei functiuni predefinite. Verificarea functionala se refera in special la date si rezultate. Poate sa apara insa riscul unor "explozii combinatoriale", care antreneaza necesitatea de a dispune de un volum foarte mare si de o larga varietate de date de intrare, si care ar putea duce la costuri si durate excesive de testare.

c) Abordarea structurala (sau a "cutiei albe"):

In aceasta forma, testarea se refera la structura interna a programului (modulului). Se pot stabili mai multe criterii de aplicare a testului:

c1) Criteriul parcurgerii instructiunilor - jocul de test trebuie sa arate ca toate instructiunile elementare sunt executate cel putin o data;

c2) Criteriul parcurgerii arcelor si nodurilor grafului de control - graful de control este o retea care cuprinde structurile de control ale programului, cum ar fi spre exemplu:

c3) Criteriul de parcurgere a drumurilor din graful de control.

c4) Criteriul de verificare a conditiilor.

Exemplu de aplicare a testului cutiei albe

Fie urmatorul program descris in pseudocod:

citeste(x)

citeste(y)

z = 0

semn = 1

daca x < 0 atunci

semn = -1

x = - x

sfarsit daca

daca y < 0 atunci

semn = - semn

y = - y

sfarsit daca

atata timp cat x >= y executa

x = x - y

z = z + 1

sfarsit

z = semn * z

a) Desenati graful de control asociat programului si numerotati nodurile.

b) Prin ce secventa de noduri trebuie sa trecem pentru a satisface criteriul de acoperire a instructiunilor? Precizati jocul de test minim necesar pentru satisfacerea acestui criteriu.

c) Prin ce secventa de noduri trebuie sa trecem pentru a satisface criteriul de acoperire a arcelor ? Precizati jocul de test minim necesar pentru satisfacerea acestui criteriu.

d) Prin ce secvente de noduri trebuie sa trecem pentru a acoperi toate drumurile posibile din graf ? Precizati jocul de test minim necesar pentru satisfacerea acestui criteriu.

Solutie:

a)

b)noduri 1 2 3 4 5 6 7 8 9 10 11 12

joc de test (x=-5, y=-2)

c) noduri 1 2 5 8 11 12 si 1 2 3 4 5 6 7 8 9 10 11 12

joc de test (x=2, y=5) et (x=-5, y=-2)

d) noduri 1 2 5 8 11 12 si 1 2 5 8 9 10 11 12 / 1 2 3 4 5 8 11 12 si

1 2 3 4 5 8 9 10 11 12 / 1 2 5 6 7 8 11 12 si

1 2 5 6 7 8 9 10 11 12 / 1 2 3 4 5 6 7 8 11 12 si

1 2 3 4 5 6 7 8 9 10 11 12

joc de test (x=2, y=5) (x=5, y=2)

(x=-2, y=5) (x=-5, y=2)

(x=2, y=-5) (x=5, y=-2)

(x=-2, y=-5) (x=-5, y=-2)

2 Verificare statica

Spre deosebire de verificarea dinamica, verificarea statica are ca scop analiza proprietatilor produsului, fara simularea executiei programelor componente.

Sunt cunoscute doua tipuri de tehnici de verificare statica: tehnici informale si tehnici formale. Aplicarea acestor tehnici depinde de complexitatea produsului software analizat si de scopurile testarii.

Tema: prezentati tehnicile informale si tehnicile formale din cadrul verificarii statice.