Proiectarea sistemelor software curs 13

1. Proiectarea sistemelor softwarecurs 13

2. PLAN CURS Reinginerie Reinigineria procesului business Reingineria software-lui Inginerie inversă (reverse) Restructurare Inginerie în avans (forward)

3. REINGINERIE Def. Reinginerie = înlocuirea unui produs software cu un nou produs ce are funcţionalitate suplimentară şi performanţă, fiabilitate şi mentenabilitate îmbunătăţite. Nivele: • Reingineria procesului business (BPR): • Definirea obiectivelor business • Evaluarea proceselor business existente • Crearea de procese business revizuite adaptate la obiectivele curente • Reingineria software-lui • Analiza inventarului de aplicaţii • Restructurare documentaţie • Inginerie inversă • Restructurare program şi date • Inginerie în avans

4. PLAN CURS Reinginerie Reinigineria procesului business Reingineria software-lui Inginerie inversă (reverse) Restructurare Inginerie în avans (forward)

5. REINGINERIA PROCESULUI BUSINESS Def. Proces business = set de activităţi legate logic, realizate pentru a obţine un rezultat business definit. Caracteristici • Combină persoane, echipament, resurse materiale şi proceduri business. • Are un beneficiar bine definit. • Poate depăşi graniţa organizaţiei. Exemple: proiectarea unui produs nou, plata furnizorilor, angajare de personal, etc. Def. Sistem business (funcţie business) – compus din unul sau mai multe procese business, fiecare definit de un set de subprocese ( ierarhie de procese).

6. REINGINERIA PROCESULUI BUSINESS Def. Reingineria procesului business = căutarea şi implementarea de modificări radicale în procesul business pentru a obţine consecinţe remarcabile. • Se poate aplica la oricare din nivelele ierarhiei procesului business. • Riscul asociat este mai mare la aplicarea pe nivelele superioare ale ierarhiei.

7. Identificare obiective business în contextul a 4 factori determinanţi: reducerea costurilor, reducerea timpului, creşterea calităţii, dezvoltarea şi întărirea personalului. Pentru fiecare din procesele critice în atingerea scopurilor identificate anterior. Identificare activităţi şi notare costuri şi timp consumate de acestea. Izolare probleme de calitate şi performanţă. Proiectarea cazurilor de utilizare. Utilizarea acestora ca specificaţii pentru proiectarea unui nou set de activităţi pentru proces. Rafinare pe baza feedback-lui de la prototip. Instanţiere în cadrul unui sistem busuness. REINGINERIA PROCESULUI BUSINESS Model pentru BPR - proces iterativ, evoluţionar, de adaptare la mediul de afaceri aflat în schimbare. http://www.brint.com/BPR.htm

8. REINGINERIA PROCESULUI BUSINESS Se pot utiliza instrumente software pentru: • analiza şi evaluarea proceselor business existente în vederea detectării ineficienţelor sau problemelor de funcţionalitate. • specificarea şi proiectarea unor procese business noi. Exemple: http://www.extendsim.com/ http://www.metastorm.com/products/e-work_integration.asp http://www.opfro.org/index.html?Components/Producers/Tools/BusinessProcessReengineeringTools.html~Contents

9. PLAN CURS Reinginerie Reinigineria procesului business Reingineria software-lui Inginerie inversă (reverse) Restructurare Inginerie în avans (forward)

10. REINGINERIA SOFTWARE-lui MENTENANŢA SOFTWARE-lui Reprezintă peste 60% din efortul organizaţiei de dezvoltare de software. Probleme: • tehnologie depăşită • modificări multiple  alterare structură, cod, logică, documentaţie • mobilitatea personalului Activităţi: • corectare erori • adaptare la schimbarea contextului aplicaţiei • extindere (perfecţionare) aplicaţie • reinginerie aplicaţie

11. REINGINERIA SOFTWARE-lui UN MODEL DE PROCES PENTRU REINGINERIA SOFTWARE-lui • Model ciclic. • Fiecare activitate poate fi revizitată. • Procesul se poate termina după oricare dintre activităţi.

12. REINGINERIA SOFTWARE-lui UN MODEL DE PROCES PENTRU REINGINERIA SOFTWARE-lui Analiza inventarului: • lista de aplicaţii şi caracteristici ale acestora (dimensiune, vechime, criticalitate, etc.) • sortată după criticalitate în raport cu afacerea, longevitate, mentenabilitate locală, etc. Rezultă aplicaţiile candidat pentru reinginerie. Recomandare: aplicarea principiului Pareto: selectarea celor 20% componente software responsabile cu 80% dintre probleme.

13. REINGINERIA SOFTWARE-lui UN MODEL DE PROCES PENTRU REINGINERIA SOFTWARE-lui Restructurarea documentaţiei: • Nu se va elabora mai multă documentaţie decât strictul necesar pentru înţelegerea aplicaţiei. • Se vor documenta doar a acele porţiuni ce urmează a fi modificate.

14. REINGINERIA SOFTWARE-lui UN MODEL DE PROCES PENTRU REINGINERIA SOFTWARE-lui Ingineria inversă: • Procesul de analizare a unui program pentru a crea o reprezentare a acestuia la un nivel superior de abstractizare faţă de codul sursă. • “design recovery” • Instrumente: extragere din codul sursă de informaţii despre date, arhitectură, design procedural.

15. REINGINERIA SOFTWARE-lui UN MODEL DE PROCES PENTRU REINGINERIA SOFTWARE-lui Restructurare cod • Analiza codului sursă utilizând un instrument de restructurare  localizare violări ale construcţiilor de programare structurată urmată de restructurarea codului. • Revizuirea şi testarea noului cod. • Actualizarea documentaţiei corespunzătoare. Obs. Include refactorizare (concept de reproiectare) - tehnică de reorganizare care simplifică design-ul sau codul unei componente fără a-i schimba funcţionalitatea şi comportamentul(îmbunătăţeşte structura internă).

16. În multe aplicaţii structura datelor este mai critică decât cea a codului. Are loc la toate nivelele de abstractizare. REINGINERIA SOFTWARE-lui UN MODEL DE PROCES PENTRU REINGINERIA SOFTWARE-lui Restructurare date: • Disecarea arhitecturii curente a datelor • Definirea modelelor de date necesare • Identificarea obiectelor de date şi a atributelor acestora • Revizuirea calităţii structurilor de date existente. • Reingineria datelor în cazul structurărilor slabe. Obs. În general induce schimbări şi la nivelul arhitecturii şi al codului.

17. REINGINERIA SOFTWARE-lui UN MODEL DE PROCES PENTRU REINGINERIA SOFTWARE-lui Inginerie în avans (renovare, “reclamation”): • Recuperarea informaţiilor de proiectare din software-ul existent • Utilizarea acestor informaţii pentru reconstituirea sistemului software în cadrul unui efort de creştere a calităţii acestuia. • Reimplementarea software-lui existent şi adăugarea de noi funcţii şi/sau creşterea performanţei.

18. PLAN CURS Reinginerie Reinigineria procesului business Reingineria software-lui Inginerie inversă (reverse engineering) Restructurare Inginerie în avans (forward)

19. INGINERIE INVERSĂ (REVERSE ENGINEERING) REVERSE ENGINEERING • Înţelegerea structurii interne de proiectare a programelor complexe. • Extragere de informaţii de proiectare din codul sursă. Variabile: • Nivelul de abstractizare • Completitudinea procesului de inginerie inversă şi a documentaţiei • Gradul de cooperare între instrumente şi analistul uman • Direcţionalitatea procesului

20. Creşte nivelul de abstractizare INGINERIE INVERSĂ (REVERSE ENGINEERING) • Variabile: • Nivelul de abstractizare • Completitudinea procesului de inginerie inversă şi a documentaţiei • Gradul de cooperare între instrumente şi analistul uman • Direcţionalitatea procesului Extragere de informaţii de proiectare din codul sursă. Nivelul de abstractizare (ideal – cât mai ridicat) • Informaţii despre structura programului şi a datelor • Modele ale obiectelor • Modele ale fluxurilor de date şi de control • Diagrame UML de clase, stări, repartizare.

21. INGINERIE INVERSĂ (REVERSE ENGINEERING) Extragere de informaţii de proiectare din codul sursă. Completitudinea procesului = nivelul de detaliu oferit la un anumit nivel de abstractizare. Scade cu creşterea nivelului de abstractizare. Creşte odata cu cît mai multăanaliză este realizată de către inginerul software. Interactivitatea = gradul de integrare ominstrumente în procesul ingineriei inverse. Pentru menţinerea completitudinii, interactivitatea trebuie să crească odată cu creşterea nivelului de abstractizare. • Variabile: • Nivelul de abstractizare • Completitudinea procesului de inginerie inversă şi a documentaţiei • Gradul de cooperare între instrumente şi analistul uman • Direcţionalitatea procesului

22. INGINERIE INVERSĂ (REVERSE ENGINEERING) Extragere de informaţii de proiectare din codul sursă. Direcţionalitatea procesului. • Unidirecţionalitate = toate informaţiile extrase din codul sursă sunt oferite inginerului software, care le poate utiliza în orice activitate de mentenanţă. • Bidirecţionalitate = informaţia este furnizată unui instrument de reinginerie care încearcă să restructureze sau să regenereze vechiul program. • Variabile: • Nivelul de abstractizare • Completitudinea procesului de inginerie inversă şi a documentaţiei • Gradul de cooperare între instrumente şi analistul uman • Direcţionalitatea procesului

23. INGINERIE INVERSĂ (REVERSE ENGINEERING) PROCESUL INGINERIE INVERSĂ CONTEXTUL

24. INGINERIE INVERSĂ (REVERSE ENGINEERING) INGINERIE INVERSĂ – Date Pe diferite nivele de abstractizare: • Program – structurile datelor interne programului Gruparea variabilelor program aflate în relaţie. Identificarea tipurilor de date abstracte (ex. structuri “record”, fişiere, liste).  Definiţiile claselor şi obiectelor. • Sistem – structurile datelor globale (fişiere, baze de date) Definirea modelului existent al datelor (etape): • construirea unui model obiect iniţial • determinarea cheilor candidat • rafinarea claselor • definire generalizări • descoperire asocieri. Aplicare de transformări pentru maparea structurii vechi pe o structură nouă a bazei de date.

25. INGINERIE INVERSĂ (REVERSE ENGINEERING) INGINERIE INVERSĂ – Procesare Pe diferite nivele de abstractizare: • Sistem Înţelegerea funcţionalităţii de ansamblu a sistemului  Stabilirea contextului pentru continuarea analizei Introspecţie în interoperabilitatea aplicaţiilor din sistem • Program = abstractizare funcţională de nivel ridicat Crearea unei diagrame bloc a interacţiunilor dintre programe • Componentă Realizază o subfuncţie Reprezintă o abstractizare procedurală Dezvoltarea unei naraţiuni de procesare per componentă • Şablon Identificare de secţiuni de cod ce reprezintă şabloane procedurale (ex. pregatire date, procesare, pregatire rezultate, sau mai mici: ex. validare date şi verificare limite (bounds) în cadrul pregătirii datelor). • Instrucţiune OBS. Dacă specificaţiile există deja, ele sunt verificate pentru conformitate cu codul existent.

26. INGINERIE INVERSĂ (REVERSE ENGINEERING) INGINERIE INVERSĂ – Interfaţă utilizator Obs. Una din cele mai răspândite activităţi de reinginerie. Elemente de bază pentru ingineria inversă a UI: • Acţiunile fundamentale (ex. apăsare taste şi click mouse) pe care trebuie să le proceseze interfaţa. • Descrierea compactă a răspunsului comportamental al sistemului la aceste acţiuni. • Conceptul de echivalenţă a interfeţelor relevant în acest caz. (i.e. Ce se înţelege prin “înlocuire”).

27. INGINERIE INVERSĂ (REVERSE ENGINEERING) INGINERIE INVERSĂ – Interfaţă utilizator Obs. Una din cele mai răspândite activităţi de reinginerie. Creare model comportamental: • Observarea manifestării externe a interfeţei existente • Extragerea de informaţii suplimentare din cod • Creare model comportamental (ex. diagrame de stări, diagrame de secvenţe). Obs. Noua interfaţă nu oglindeşte exact vechea interfaţă. Noua interfaţă poate fi radical diferită prin adoptarea de noi metafore de interacţiune. (ex. inlocuire cu

28. PLAN CURS Reinginerie Reinigineria procesului business Reingineria software-lui Inginerie inversă (reverse) Restructurare Inginerie în avans (forward)

29. RESTRUCTURARE Nu modifică arhitectura de ansamblu a programului. Concentrată pe detaliile de proiectare ale modulelor individuale sau ale structurilor de date locale din module. Utilizată la aplicaţii cu arhitectură de bază solidă. Iniţiată când doar un subset relativ redus al componentelor şi datelor necesită modificări majore. • Restructurare cod • Restructurare date

30. RESTRUCTURARE RESTRUCTURARE COD Scop: Obţinerea unui design care • produce aceeaşi funcţie cu programul original • are calitate superioară. Metodă generală: Transformare cod nestructurat (“spahetti-code”) în cod ce se conformează filozofiei programării structurate.

31. RESTRUCTURARE RESTRUCTURARE COD Tehnici de restructurare: A. • Modelarea logicii programului utilizând algebra booleană, • Aplicarea unei serii de reguli de transformare pentru restructurarea logicii. B. • Utilizarea unei diagrame (exchange diagram) ce pune în corespondenţă fiecare modul program cu resursele (tipuri de date, proceduri, variabile) care sunt schimbate de acesta cu alte module. • Reprezentarea fluxului resurselor. • Restructurarea arhitecturii software-lui în sensul minimizării cuplării între module.

32. RESTRUCTURARE RESTRUCTURARE DATE • Precedată de analiza codului sursă. • Analiza datelor • Evaluarea instrucţiunilor ce conţin definiţii date, descrieri de fişiere, descrieri I/E, descrieri interfaţă. • Extragerea • elementelor şi obiectelor de date • informaţiilor despre fluxul datelor • Înţelegerea structurilor de date implementate. • Reproiectarea datelor

33. RESTRUCTURARE RESTRUCTURARE DATE • Precedată de analiza codului sursă. • Analiza datelor. • Reproiectarea datelor. Variante simple: • Standardizarea înregistrărilor de date Consistenţa definiţiei datelor cu numele (pentru o anumită structură de date) sau cu formatele înregistrărilor fizice (pentru un format de fişier existent). • Raţionalizarea numelor datelor Conformitatea tuturor convenţiilor de numire cu standardele locale şi eliminarea alias-urilor. Variante complexe: • Modificări fizice la structurile de date existente. Transformare în alt format de fişier; transformare în alt tip de bază de date.

34. RESTRUCTURARE INSTRUMENTE pentru restructurare Obiectiv: transformare software nestructurat în structuri moderne de proiectare şi de limbaje de programare. Mecanism: codul sursă e preluat ca date de intrare şi transformat în cod în acelaşi limbaj de programare sau într-un limbaj de programare mai modern. Exemple: www.semdesigns.com - DMS Software Reengineering Toolkit www.cs.wayne.edu/~vip/RefactoringTools - Function Encapsulation Tool www.polyhedron.com - plusFORT

35. PLAN CURS Reinginerie Reinigineria procesului business Reingineria software-lui Inginerie inversă (reverse) Restructurare Inginerie în avans (forward)

36. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) (progresistă, de avangardă) Def. Procesul de construire a unui sistem plecând de la o structură existentă a acestuia. Opţiuni de aplicare de modificări asupra unui program complex şi nestructurat: • Aplicare modificări pur şi simplu. • Înţelegerea funcţionării interne generale în vederea eficientizării modificărilor. • Reproiectarea, recodificarea şi testarea porţiunilor de software ce necesită modificare, abordate conform principiilor ingineriei software. • Reproiectarea, recodificarea şi testarea completă a software-lui, asistată de instrumente de reinginerie pentru înţelegerea design-lui curent. Alegerea: funcţie de circumstanţe.

37. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) MENTENANŢĂ PREVENTIVĂ (structured retrofit). “Aplicarea metodologiilor de azi sistemelor de ieri pentru a face faţă cerinţelor de mâine”. Procedura: • Utilizând analiza inventarului se identifică elementele care: • vor fi în uz încă un număr preselectat de ani • sunt folosite cu succes • există o probabilitate mare să sufere modificări şi extinderi în viitor • Se aplică una din opţiunile 2,3,4 (v. slide precedent)

38. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) MENTENANŢĂ PREVENTIVĂ (structured retrofit). Motivaţii: • Costul mentenanţei poate ajunge la de 20 - 40 ori mai mare decât cel al dezvoltării iniţiale. • Reproiectarea arhitecturii software (structură date şi/sau program) utilizând concepte moderne de proiectare facilitează mentenanţa ulterioară. • Productivitatea va fi mult mai mare decât media, datorită existenţei unui prototip al software-lui. • Utilizatorul are experienţă cu software-ul, deci va putea descoperi mai uşor noi cerinţe şi direcţii de modificare. • Instrumente automate de reinginerie vor facilita parte din mentenenţa preventivă. • La terminarea mentenanţei preventive va exista o configuraţie software completă (documente, programe şi date).

39. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) Procesul aplică principiile, conceptele şi metodele ingineriei software pentru a recrea o aplicaţie existentă. Noua versiune (release): • echivalent modern al cele vechi • poate integra noi cerinţe utilizator (extindere) • poate integra noi tehnologii.

40. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) - Arhitecturi CLIENT/SERVER Reinginerie aplicaţii mainframe. Distribuirea resurselor de calcul centralizate (incluzând software) pe mai multe platforme client. Caracteristici: • Funcţionalitatea aplicaţiei migrează la fiecare calculator client. • La client sunt implementate interfeţe grafice noi. • Funcţile bazei de date sunt alocate server-lui. • Funcţionalitate specializată (ex. analize bazate pe calcul intensiv) pot rămâne la server. • Trebuie stabilite cerinţe noi de comunicare, securitate, arhivare şi control, atât la server cât şi la clienţi.

41. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) - Arhitecturi CLIENT/SERVER Necesită: • Reinginerie business • Reinginerie software • Stabilirea reţelei de infrastructură a întreprinderii Analiza contextului business pe trei nivele de abstractizare: • baza de date • regulile business • aplicaţiile client

42. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) - Arhitecturi CLIENT/SERVER Nivelul bazei de date • Gestionează tranzacţiile si interogările generate de aplicaţiile client Etape: • Ingineria inversă a funcţiilor DBMS şi a arhitecturii bazei de date • Reproiectarea nivelului • Reingineria bazei de date pentru asigurarea: • executării consistente a tranzacţiilor, • respectării autorizărilor de actualizare a bazei de date, • respectării regulilor businss, • găzduirii eficiente a tranzacţiilor • stabilirii capabilităţilor integrale de arhivare.

43. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) - Arhitecturi CLIENT/SERVER Nivelul regulilor business • Reprezentat de software atât la client cât şi la server • Execută activităţi de control şi coordonare a tranzacţiilor şi interogărilor dintre client şi baza de date conform regulilor business. Nivelul aplicaţiilor client • Implementează funcţii business specifice unui grup de utilizatori finali

44. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) - Arhitecturi OO Aplicabilitate: • Aplicaţii dezvoltate utilizând metode convenţionale. • Aplicaţii OO. Simptome comune: • Generale: • Documentaţie lipsă sau depăşită • Plecarea dezvoltatorilor sau a utilizatorilor iniţiali • Dispariţia cunoştinţelor introspective despre sistem • Înţelegerea limitată a sistemului • Lipsa testelor • La nivel de proces de dezvoltare: • Durată prea mare de realizare a modificărilor simple • Necesitate frecventă de eliminare erori • Mentenanţă intensivă şi dificilă • La nivelul codului: • Durată mare a generării codului executabil. • Duplicare cod. • Cod nestructurat • La nivel de arhitectură: • Organizare necorespunzătoare a nivelelor • Lipsa modularităţii • Funcţionalitate duplicată

45. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) - Arhitecturi OO • Aplicaţii dezvoltate utilizând metode convenţionale. Procedură: • Inginerie inversă  crearea modelelor datelor, funcţional şi comportamental. • if se extinde funcţionalitatea sau comportamentul aplicaţiei originale, then creare cazuri de utilizare • Utilizarea modelelor datelor în conjuncţie cu modelarea CRC  stabilirea bazelor pentru definirea claselor • Definirea ierarhiilor de clase, modelelor relaţiilor între obiecte, modelelor comportamentale ale obiectelor, subsistemelor. • Începerea proiectării OO.

46. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) - Arhitecturi OO • Aplicaţii dezvoltate utilizând metode convenţionale. Se poate invoca un model de dezvoltare bazat pe componente (CBSE). Dacă aplicaţia transformată există într-un domeniu care este deja populat cu multe aplicaţii OO  existenţa unei biblioteci de componente ce poate fi utilizază în procesul ingineriei în avans. Pentru clasele ce trebuie dezvoltate în totalitate, se pot reutiliza algoritmi şi structuri de date din aplicaţiile convenţionale existente. Acestea trebuie însă reproiectate pentru a se conforma arhitecturii OO.

47. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) – Arhitecturi OO • Aplicaţii OO Motivaţie: Legile lui Lehman şi Belady. Schimbare continuă • Un program utilizat în context real trebuie să fie schimbat sau devine din ce în ce mai puţin util în contextul dat. Complexitate în creştere • Pe măsură ce un program evoluează el devine mai complex, astfel încât sunt necesare resurse suplimentare pentru păstrarea şi simplificarea structurii sale.

48. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) – Arhitecturi OO • Aplicaţii OO TEHNICI • Restructurare cod • Refactorizare • Redenumire/mutare metode/clase, etc. Oportunităţi de refactorizare: • Proasta utilizare a moştenirii – reutilizare cod vs. polimorfism • Lipsa moştenirii – duplicare, instrucţiuni case • Operaţii plasate în afara claselor • Violarea principiului încapsulării • Abuz de clase • Restructurare date • integrarea şi centralizarea bazelor de date multiple • unificarea reprezentărilor multiple inconsistente • actualizarea modelelor de date

49. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) – Arhitecturi OO free OO Reeingineering Patterns books: http://www.iam.unibe.ch/~scg/OORP/ http://books.google.ro/books?hl=ro&id=TXvqCw6NuVMC&dq=Reengineering+Patterns&printsec=frontcover&source=web&ots=bzvKhJqsVj&sig=GSX4LETloTkLfuACvRGOKeLS9vU&sa=X&oi=book_result&resnum=7&ct=result http://labs.cs.utt.ro/labs/acs/html/lectures/1/lecture1.ppt

50. INGINERIE ÎN AVANS INGINERIE ÎN AVANS (forward engineering) - Interfeţele utilizator (UI) Ingineria UI are o pondere semnificativă în tranziţia de la calculul mainframe la arhitecturile client/server. Model pentru reingineria UI: • Înţelegerea interfeţei originale şi a datelor transferate de aceasta cu restul aplicaţiei • Remodelarea comportamentului implicat de interfaţa existentă sub forma unei serii de abstractizări cu sens în contextul unei GUI. • Introducerea de îmbunătăţiri care să facă mai eficient modul de interacţiune. • Construirea şi integrarea noii GUI.