Elemente de arhitectura a sistemelor software

Majoritatea persoanelor care scriu programe pentru calculator si care nu sunt specialiste in ingineria software de obicei stapanesc satisfacator un limbaj de programare si incep, asa cum pare si firesc, sa scrie cod. Totul este foarte bine pana in momentul in care programul isi mareste dimensiunile, devine complex, greu de intretinut si de dezvoltat in continuare. Acesta este momentul in care dezvoltatorul de aplicatii realizeaza ca doar a cunoaste un limbaj de programare nu inseamna programare, aplicatiile presupun si altceva decat scrierea de cod, fiecare program are un ciclu de viata iar proiectarea acestuia nu este un moft ci rezolva multe probleme care apar mai tarziu. Pe plan mondial, 8 proiecte din 10 esueaza tocmai datorita lipsei unei perspective generale si a unei planificari adecvate.

Scopul acestor sectiuni nu este acela de a va forma ca programatori sau ca arhitecti de software. Poate insa veti ajunge sa va scrieti propriile programe aplicatie si este important sa stiti de unde trebuie sa incepeti.

Ciclul de viata al unei aplicatii

Orice aplicatie software se dezvolta urmand o procedura pas cu pas. Aceasta insiruire sistematizata de metode care asigura in final produsul software se numeste ciclu de viata si cuprinde patru mari domenii: analiza, proiectarea, implementarea si testarea

Analiza cerintelor si modelarea sistemului

Conditiile, sarcinile si functiile pe care trebuie sa le indeplineasca un sistem informatic sunt cunoscute sub denumirea generica de cerinte ale sistemului. Identificarea lor este necesara atat pentru delimitarea obiectivelor ce trebuie atinse cat si in vederea elaborarii de standarde pe baza carora sa se poata controla calitatea produsului.

Metoda de baza folosita in identificarea cerintelor cuprinde discutii cu beneficiarii, analiza documentelor, elaborarea de chestionare si instrumente care sa permita detalierea necesitatilor de proiectare.

Leffingwell identifica trei categorii de cerinte: functionale, nefunctionale si de proiectare.

Cerintele functionale descriu modul in care functioneaza programul precizand intrarile si iesirile sale, modul in care se ajunge de la o intrare la o iesire.

Cerintele nefunctionale se refera la proprietatile pe care le va avea sistemul, legate de performanta, fiabilitate, grad de utilizare etc.

Cerintele de proiectare nu afecteaza comportamentul sistemului insa cuprind detalii legate de implementarea interfetei cu utilizatorul, portabilitatea pe diferite platforme hardware, cerinte contractuale etc.

Identificarea cerintelor este urmata de modelarea sistemului software prin intermediul careia se incearca separarea diferitelor aspecte creand mai multe modele ale programului.

Proiectarea arhitecturii si a detaliilor

Daca analiza determina ceea ce trebuie implementat, proiectarea arata cum trebuie implementat descompunand sistemul treptat pana se ajunge la constructe ce pot fi scrise folosind un limbaj de programare.

Clasic, proiectarea arhitecturii se face pornind de sus in jos, de la stabilirea arhitecturii generale a sistemului, la identificarea unui set de componente din care este alcatuit sistemul si apoi la detalierea fiecarei componente.

Arhitectura unui sistem este deci o colectie de componente organizate care indeplinesc anumite functii si se afla la diferite niveluri de abstractizare astfel incat sistemul sa poata fi privit ca un intreg. Componentele sunt in asa fel alese incat sa interactioneze intre ele doar prin intermediul interfetelor si cu respectarea stricta a principiului incapsularii informatiilor.

La momentul actual exista trei tipuri de viziuni arhitecturale:

Structurala, care se refera la componente si la relatiile dintre ele

Comportamentala sau care vizeaza modul de interactiune in vederea indeplinirii responsabilitatilor

De executie care permite evaluarea optiunilor de distributie fizica, documentare si comunicarea deciziilor.

In proiectarea arhitecturii unei aplicatii se disting doua abordari majore:

Proiectarea functionala ce pleaca de la ideea ca structura datelor este folosita doar pentru a determina structura de prelucrare a acestora

Proiectarea orientata pe obiecte care foloseste principii de reutilizare a  codului, incapsuland elemente de cod in clase unde datele sunt asociate functiilor care lucreaza cu ele.

Implementarea

Din etapa anterioara rezulta o serie de modele detaliate pe care le folosesc membrii echipei de dezvoltare pentru a incepe scrierea codului necesar aplicatiei. Iata deci ca procesul de dezvoltare concreta a unui program incepe abia in cea de-a treia faza.

In aceasta etapa este necesara scrierea de metode care sa fie usor de inteles si de catre alte persoane, de aceea blocurile de cod, clasele trebuie sa fie mici si sa contina informatii coerente. Dupa Rumbaugh exista doua criterii importante pentru scrierea programelor, indiferent de dimensiunea acestora:

Reutilizarea codului este esentiala pentru extinderea usoara a programelor si evitarea redundantelor. Astfel se descopera elementele similare inca din etapa de proiectare si se folosesc facilitatile limbajului de programare pentru a utiliza implementari comune. De exemplu, in loc sa scriem aceeasi rutina de calcul a varstei unui subiect in mai multe formulare, o putem scrie o singura data, o inglobam intr-o functie si o apelam cand este necesar. Ca urmare, programele rezultate sunt mai mici iar depanarea este mai rapida.

Robustetea presupune ca un program nu se termina anormal si nu se blocheaza daca primeste date improprii. Robustetea unui program presupune atat comportamentul sau fata de erorile de nivel scazut (cauzate de defectiuni hardware sau de defectiuni ale sistemului de operare) cat si fata de erorile utilizatorilor care pot introduce date incorecte.

Implementarea unui program se poate efectua fie intr-un limbaj structurat care acorda o importanta mai mare functiilor ce nu sunt legate implicit de datele pe care le prelucreaza si care se afla intr-un plan secundar fie intr-un limbaj orientat pe obiecte unde accentul cade pe date carora le asociaza functiile care lucreaza cu ele, incapsulandu-le in tipuri de date definite de programator si care poarta denumirea de clase.

Testarea

Testarea programelor este poate cea mai laborioasa operatiune din ciclul de viata al unei aplicatii si implica descoperirea cat mai devreme posibil a erorilor existente, fara a indica insa cauza acestora. Procesul de testare debuteaza inca din faza de proiectare pentru ca erorile sa fie depistate din timp si sa se evite propagarea acestora.

Berard expune doua strategii majore de testare a aplicatiilor:

Testarea structurala (de timpul cutiei albe) in care se testeaza codul sursa fara a face legatura cu specificatia sa in vederea identificarii buclelor infinite, cailor ce nu pot fi executate sau a codului "mort", blocuri de cod care nu se executa niciodata.

Testarea comportamentala (de tipul cutiei negre) care verifica programul prin intermediul interfetei sale, descoperindu-se tipurile de date care cauzeaza erori, actiuni ilegale posibile ale utilizatorului care blocheaza programul etc.

O testare exhaustiva nu este niciodata posibila avand in vedere numarul mare al combinatiilor posibile. Testarea nu permite dezvoltatorilor sa demonstreze ca produsul realizat este cu totul demn de incredere, singurul rezultat fiind acela ca nivelul de incredere in functionarea corecta a programului sa fie cat mai mare.

Modele de dezvoltare

Modelele de dezvoltare reprezinta strategii diferite implicate in planificarea ciclului de viata al unei aplicatii. Exista un numar destul de mare de astfel de modele, fiecare cu avantajele si dezavantajele sale.

Modelul cascada pleaca de la teoria lui Winston Royce din anul 1970 care afirma ca un software poate fi analizat complet inainte de a se incepe proiectarea, proiectat complet inainte de implementare si asa mai departe. Ca urmare, aceste observatii au fost transformate in reguli stricte care impun trecerea programului prin fazele ciclului de viata fara posibilitatea vreunei reveniri.

Modelul prototiparii rapide presupune construirea unui prototip care sa fie incercat de beneficiar in vederea unei opinii rapide a acestuia asupra cerintelor pe care trebuie sa le indeplineasca aplicatia. Un prototip asadar un program creat pe baza unui model incomplet al aplicatiei dar care evidentiaza aspectele considerate cele mai importante. Dupa prototipare, dezvoltarea continua de obicei dupa modelul cascada.

Modelul dezvoltarii incrementale imparte un proiect in parti relativ mici si cat mai putin legate intre ele care apoi urmeaza a fi integrate in modelul global. Este o perspectiva modulara asupra sistemelor, aplicatiile rezultate fiind robuste si multifunctionale.

Modelul livrarii programelor in evolutie combinat dezvoltarea incrementala face parte din strategia de dezvoltare a proiectelor pe care o adopta multe firme prestigioase. Livrarea programelor in evolutie este privita ca un proces continuu de imbunatatire si de adaptare la nevoile beneficiarului. Sistemul dezvoltat initial este imediat livrat sub forma unei versiuni dupa care dezvoltarea continua. Astfel atat dezvoltatorii cat si utilizatorii identifica din mers modificarile necesare si cauta solutii pentru probleme. Acesta reprezinta unul dintre cele mai puternice modele de dezvoltare.

Analiza si proiectarea structurata

Analiza si proiectarea structurata se bazeaza pe conceptele de programare structurata si programare modulara si are la baza diagramele de flux de date. O specificatie structurata contine in general trei componente:

Specificatii de control precum organigrame, arbori de decizie sau diagrame de tranzitie a starilor ce caracterizeaza activitatile desfasurate la anumite momente de timp

Proiectarea functionala reprezentata prin diagrame de flux de date care pot descrie sisteme complexe ce contin un numar mare de functii si procese.

Modelarea datelor prin diagrame de tip entitate-relatie folosite pentru a proiecta structura datelor, bazele de date si formatul de fisiere.

Cele mai importante elemente raman insa diagramele de flux de date care nu sunt altceva decat grafuri avand ca arce fluxurile de date si ca noduri procese. Exista un limbaj conventional de reprezentare a acestor elemente. De exemplu, dreptunghiurile reprezinta elemente externe active precum oameni sau dispozitive, cercurile reprezinta noduri ale fluxului de date etc. Uneori diagramele de flux de date folosesc elemente caracteristice organigramelor si a proiectarii procedurale pentru a reprezenta elemente punctuale de proces.

In exemplul de mai sus prezentam o asemenea abordare extrasa din arhitectura software a sistemului de asistenta in psihologie Itemsoft CAT.

Alte elemente de proiectare folosite in proiectarea structurata sunt dictionarele de date, cataloage cu toate elementele de date din diagramele de flux, tabelele de decizie sau schemele structurale Jackson.

Analiza si proiectarea orientata pe obiecte

Se bazeaza pe identificarea obietelor ca entitati concrete sau abstracte, caracterizate prin structura datelor care le descriu si prin comportamentele pe care le pot manifesta.Toate obiectele cu aceeasi structura si cu acelasi comportament sunt incadrate intr-o clasa care descrie o infinitate de obiecte individuale, iar orice obiect creat poarta denumirea de instanta a clasei respective. Intr-o clasa, aspectele si procedurite interne sunt ascunse, clasa punand la dispozitie doar un set de proprietati, comportamente sau evenimente. Acest principiu de ascundere a informatiilor in interiorul unei clase poarta denumirea de incapsulare. O alta caracteristica a claselor este aceea ca una si aceeasi operatie poate avea comportari diferite in clase diferite, proprietate denumita polimorfism. Metoda corecta este selectata automat in functie de numele sau si de clasa din care face parte obiectul. In cazul in care mai multe clase au atribute si operatii comune, acestea pot fi declarate o singura data grupandu-le intr-o superclasa care poate fi mai apoi rafinata in diferite moduri. Aceasta caracteristica poarta denumirea de mostenire si contribuie la reducerea redundantei atat la nivelul proiectului arhitectural cat si la nivelul codului.

Incepand cu anii 1990, au fost dezvoltate o multitudine de metodologii orientate pe obiecte, insa doar un numar limitat s-au impus in aplicatii practice. Se utilizeaza chiar imbinarea metodologiilor structurate cu cele orientate obiect rezultand metodologii hibride cu diferite scheme de aplicare.

Una dintre cele mai raspandite metodologii de modelare orientate obiect este metodologia Rumbauch care a fost dezvoltata la inceputul anilor 90 si a castigat o mare popularitate datorita claritatii si simplitatii sale, cea mai mare parte a sa fiind incorporata in modelul UML. Aceasta metodologie presupune ca exista trei aspecte ale sistemelor: static, dinamic si functional. Prin urmare rezula 3 tipuri de modele ce trebuiesc abordate la analiza sistemelor:

Modelarea obiectuala descrie structura statica a datelor fiind formata din diagrame de clase si diagrame de obiecte. Un exemplu de diagrame de clase extras din modelul UML al sistemului Itemsoft CAT poate fi urmarit in figura de mai sus. Clasele se reprezinta prin dreptunghiuri impartite in 3 compartimente. Primul compartiment contine numele clasei, al doilea atributele si al treilea operatiile implementate. Intre aceste clase pot fi stabilite diferite tipuri de relatii: relatii de asociatie sau cooperari intre clase pentru care obiectele instantiate exista in mod independent unul de celelalte; de agregare ce identifica o relatie de tip parte-intreg, reprezentand o interdependenta puternica; de generalizare adica relatia dintre clase care prezinta similitudini intre ele si o superclasa in care sunt grupate elementele comune ale acesteia.

Modelarea dinamica necesita trei etape: scrierea scenariilor pentru secventele particulare de evenimente, precizarea diagramei succesiunii de evenimente in care sunt identificare obiectele care participa la interactiune si reprezentarea diagramei de stare pentru fiecare clasa cu comportament dinamic.

Modelarea functionala este compusa din diagrame de flux ale datelor prin care se reprezinta modul in care intrarile in sistem sunt transformate pentru a obtine iesirile acestuia.

Desigur aceasta este o perspectiva simplificata a metodologiei de modelare orientata obiect. Complexitatea si diversitatea unor proiecte software de amploare presupun modele extrem de elaborate, realizate de specialisti cu experienta si care controleaza procesul de dezvoltare software, numiti arhitecti de software (Software Architect). Programatorii nu primesc altceva decat modelele UML ale unor parti din aplicatie impreuna cu specificatiile de programare necesare dezvoltarii rutinelor specifice. In final, rutinele programatorilor sunt asamblate in produsul finit care urmeaza apoi fazele de testare Alfa, Beta in final ajungandu-se la versiunea oficiala, numita si Software Release.

Etapele descrise in decursul acestui capitol sunt aplicabile proiectelor de anvergura. Ar fi lipsit de sens si chiar hilar sa solicitam unui program care calculeaza o ecuatie de ordin doi sa urmeze toti pasii prezentati aici. Probabil ca arhitectura ar depasi cu mult timpul necesar programarii efective. Este bine de stiut totusi ca o aplicatie computerizata serioasa nu se poate face "dupa ureche" si dupa sfaturile prietenilor, deoarece oricat de bine ar arata aceasta si oricat de frumoase ar fi interfetele cu utilizatorul, ceea ce asigura valoarea unui produs software este functionalitatea sa interna. Fara o munca serioasa de conceptie si proiectare, functionalitatea sa interna ramane subreda, determinand programul sa se comporte surprinzator in timpul rularii si sa genereze erori neasteptate. Probabil ca nu ati vrea ca noul sistem achizitionat de firma la care lucrati in urma insistentelor dumneavoastra sa se blocheze tocmai in momentul in care conducerea doreste sa fie examinata.

Intrebari recapitulative si teme