Inginerie software seminar 1. ISS - Seminar Multimi, structuri, sisteme, modelare

Size: px

Start display at page:

Download "Inginerie software seminar 1. ISS - Seminar Multimi, structuri, sisteme, modelare"

Angel Terry
5 years ago
Views:

1 ISS - Seminar 1 4 martie Multimi, structuri, sisteme, modelare Multimea este o colectie de elemente (despre care nu stim daca sunt sau nu structurate, conectate intre ele). Structura este o multime in care unele sau toate elementele sale sunt interconectate. Ex: constructii, structuri de date, structuri de calcul. Sistemul este o multime de elemente interconectate intre ele astfel incat genereaza o functie noua (ceva care e mai mult decat suma partilor sale si care de cele mai multe ori nu poate fi prevazut prin insumarea functiilor partilor). Functia (scopul in cazul sistemelor artificiale) este rezultanta unui mod particular de legare a partilor unui sistem (elemente sau structuri). Ex: inima, celula, sistemele soft, fiinta vie, Universul, etc. Clasificare naturale -propriu zise (fizice, chimice, biologice) - sociale (psihologice, sociale, economice) - artificiale (cladiri, masini, sisteme software) Analiza sistemelor desfacerea in bucati mai mici, fizic sau mental, pentru a intelege functionarea lor. Sinteza sistemelor se ocupa cu studiul metodelor prin care natura sau omul creaza sisteme. Atat in cazul analizei cat si al sintezei este necesara activitatea de modelare. Modelul este o imagine simplificata a realitatii (sisteme si fenomene) studiate împreună cu orice ipoteze necesare pentru a descrie sistemul sau a explica fenomenul. Alternativ, poate fi considerat o imagine a sistemului din care s-au eliminat intrarile care au efecte mici asupra iesirilor importante pentru aspectul dorit. Modelarea este activitatea (procesul) de reprezentare a elementelor sau esenţei unui sistem sau fenomen. Scopul modelarii este de a reduce complexitatea sistemului (realitatii) prin construirea unei reprezentari simplificate ale realitatii care ignora detaliile irelevante. Reducerea complexitatii are 2 avantaje majore: costuri mai mici si timp mai scurt. 1

2 2. UML (limbaj unificat de modelare) UML (unified modeling language) este un limbaj de modelare, folosit pentru a reprezenta solutiile sistemelor soft, in vederea transpunerii solutiilor sub forma de cod executabil. Este nu doar un instrument de reprezentare, ci si un instrument de comunicare intre participantii la proiect: manageri, clienti, programatori. Programatorii care creaza sisteme soft mici sau simple sunt obisnuiti sa concentreze intregul efort in faza de implementare. In acest context, Ingineria Software (SE) initiaza un programator in arta de a modela inainte de a implementa. UML poate fi folosit si poate modela si alte aspecte inafara celor specifice informaticii (IT), cum ar fi fluxurile de lucru in justitie, sanatate, etc;. UML opereaza cu 3 tipuri de elemente: Entitati, Relatii si Diagrame. a. Entitatile (things) sunt obiectele din modelele UML. Exista patru tipuri: entitati cu functii structurale (substantive), cu functii comportamentale (verbe), cu functii de grupare, cu functii de documentare. b. Relatiile abstractizeaza tipurile de legaturi dintre entitati. Ele sunt: dependente, asocieri, generalizari/specializari, realizari. Relatia de dependenta (relatie semantica unilaterala) - este caracterizata prin faptul ca o schimbare din oricare entitate o afecteaza semnatic pe cealalta. Entitatea independenta este entitatea in care poate interveni schimbarea, entitatea dependenta este entitatea afectata de schimbare. Notatie: o linie intrerupta cu sageata la un capat. Ex: Lista-Nod. Relatia de asociere (relatie structurala intre entitati, conceptual, egale; bidimensionala) descrie legaturile dintre entitati (obiecte). Suporta mai multe tipuri de multiplicitati. Notatie: linie continua, eventual un nume, nume de roluri, restrictii de cardinalitate. Ex: asocierile dintre clase. Relatia de agregare (has-a) este un caz particular al asocierii in care o entitate intreg consta din una sau mai multe entitati parte. Notare: linie continua cu un romb gol la capatul care indica inspre intreg. Ex: Automobil Roata; Facultate Profesor; Facultate Student. 2

3 Relatia de compozitie este un caz particular al agregarii in care intregul are responsabilitati clare asupra crearii si distrugerii partilor. Altfel spus, partile nu pot exista inafara intregului. Notare: idem agregare, doar ca rombul este plin. Ex: Facultate Departament. Relatia de generalizare (is-a) (relatie semantica unilaterala) descrie legaturile dintre entitati fiu care mostenesc atribute si comportamente de la entitati parinte. Notatie: linie continua cu sageata goala la un capat, orientata inspre entitatea parinte. Client Pers Fizica; Pers Juridica; Forma-Dreptinghi-Patrat. Relatia de realizare (relatie semantica) descrie legaturile dintre clasificatori. Ex: o clasa realizeaza o anumita interfata. Notatia: linie discontinua cu sageata goala la un capat, orientata inspre entitatea parinte. c. Diagramele UML sunt reprezentari grafice ale unor colectii de elemente (entitati si relatii) cu scopul de a obtine descrieri ale sistemelor modelate din diferite perspective. De fapt sunt grafuri ale caror noduri sunt reprezentate de entitati si ale caror arce sunt relatii. Diagramele UML sunt un suport pentru abstractizarea si vizualizarea solutiei unui sistem soft. Cele mai importante tipuri de diagrame UML: - diagrame statice (structurale): diagrama de clase, diagrama de obiecte, diagrama de componente, diagrama de desfasurare. - diagrame dinamice (comportamentale): diagrama de cazuri de utilizare, diagrama de secventa, diagrama de colaborare, diagrama hartilor de stare, diagrama de activitate. 3

4 3. Etapele dezvoltarii sistemelor software Etapele dezvoltarii unui sistem software (OO): 4 1. Analiza cerintelor (Requirments Elicitation) 2. Analiza 3. Proiectarea sistemului (System Design) 4. Object Design 5. Implementarea 6. Testarea (de integrare, functionala, unit, black-box, white-box) Documentarea Ingineria software este o activitate, condusa rational, pentru de modelare, pentru rezolvarea problemelor si pentru de achizitia cunostintelor. Plastic, Ing Soft inseamna Knowledges, Skills si Experience. Inginerii (inclusiv specialistii in SE) actioneaza, chiar inconstient, conform principiului: Inainte de a realiza un lucru, hotaraste cum vrei sa-l folosesti!. (care e valoarea lui de intrebuintare). UML cere precizarea cu maxim de acuratete determinarea tipului de utilizator al sistemului soft. Tipul utilizatorului este o abstractie in care se reflecta o serie de cerinte (functionale si nefunctionale). Analiza cerintelor (Requirments Elicitation) este etapa in care are loc analiza detaliata a informatiilor ce urmeaza a fi prelucrate de catre sistemul soft, specificarea clara a functionalitatilor sistemului si a constrangerilor impuse asupra acestuia. Cerintele functionale sunt afirmatii pe care sistemul software trebuie sa le contina, cum sa raspunda la anumite intrari sau cum sa reactioneze in anumite situatii. Exemple: Automatul trebuie să permită călătorului să cumpere carduri săptămânale Fereastra de rapoarte trebuie sa permita exportul datelor in format pdf. Cerintele nefunctionale sunt constrangeri impuse asupra sistemelor soft care nu sunt legate direct de functionearea sistemului. Aceste cerinte contin aspecte care nu sunt direct vizibile de catre utilizator. Exemple: Automatul de bilete trebuie să fie scris în Java. Automatul de bilete trebuie să fie usor de utilizat. Aplicatia trebuie sa fie de tip web.

5 Cerintele pot fi exprimate sub forma de text nestructurat, text structurat, diagrama cazurilor de utilizare, etc. 4. Diagrama cazurilor de utilizare (CU) Diagrama cazurilor de utilizare faciliteaza comunicarea dintre end-useri si IT-isti (ing soft, programatori, etc). Sunt esentiale pentru modelarea comportamentului unui sistem, subsistem al unei clase. Sunt utile in primele 2 etape: Analiza (specificare) a cerintelor si etapa de Analiza. Diagrama cazurilor de utlizare contine: cazuri de utilizare, actori, relatii si, optional, pentru a mari lizibilitatea, se pot folosi: frontiera sistemului, note, constrangeri si pachete. Actorul este o entitate (persoana, periferic sau alt sistem) care interactioneaza cu sistemul software. Se reprezinta grafic sub forma unui omulet stilizat. In modelele UML ei sunt rezidenti inafara sistemului (nu sunt parti ale sistemului software). Sunt conectati la un caz de utilizare numai prin relatii de asociere, care e o relatie de comunicare bidirectionala (schimb de mesaje). Actorii intre ei pot avea numai relatii de generalizare. Cazurile de utilizare (use case) (contexte de utilizare) descriu comportamentul unui sistem soft asa cum este el vazut de catre end-user-i, analisti si testeri. Implica interactiunea dintre actori si sistem. Este o descriere a unui set de secvente de actiuni pe care sistemul le executa pentru a produce un rezultat observabil, asteptat de actor. Cand cream cazuri de utilizare spunem ce face sistemul (interfata), nu cum face (implementarea). Doar se specifica un comportament dorit de end-useri sau de alti actori. Notare: o elipsa formata dintr-o linie continua, care in interior contine numele cazului de utilizare. Un caz de utilizare reprezinta o cerinta functionala care trebuie sa aiba un nume. Cazurile de utilizare pot fi grupate in pachete. Cazurile de utilizare pot avea intre ele relatii de generalizare, de dependenta (includere si extindere). Rol: identificarea neclaritatilor cerintelor, a formularilor vagi, a unor cerinte neformulate, dar necesare. 5

6 Relatiile din diagramele CU sunt: Relatia de generalizare a fost discutat mai sus. CU (caz de utilizare) copil mosteneste comportamentul si semantica CU parinte, pe care le poate suprascrie si la care poate adauga unele noi.parintele poate fi substituit de oricare dintre copiii lui. Exemplu: parinte: Validare utilizator; copii: Verificare parola, Scanare retina. Cazurile de utilizare copil sunt specializari ale cazului general. Ele mostenesc comportamentul si semantica parinteleui la care pot adauga comportamente noi sau pot suprascrie comportamente ale parintelui. Relatia de includere este o relatie de dependenta. Cazul de utilizare de baza incorporeaza comportamentul cazului de utilizare inclus. CU inclus nu poate opera singur, ci doar ca parte a CU de baza. Nici unul din cele doua CU nu pot accesa atributele celuilalt. Exista o asemanare vaga cu o functie apelata dintr-o functie de baza. Notare: o relatie de dependenta marcata cu <<include>>. Relatia de extindere este tot o relatie de dependenta in care un CU, optional, poate apela un alt CU in anumite conditii. CU de baza isi extinde comportamentul prin CU extins. Rol: Separarea comportamentului optional de comportamentul imperativ. Notare: Este redata ca o relatie de dependenta marcata cu <<extend>>. Metode de creare a digramelor CU: bazata pe actori; bazata pe evenimente. Pot modela contextul unui sistem (ne axam atentia pe actori si modul de interactiune cu sistemul). Etape: a. Identificarea actorilor; b. organizarea actorilor intr-o ierarhie bazata pe generalizare/specializare; c. Crearea diagramei Pot modela cerintele fata de un sistem software (ne axam atentia pe cerinte). Etape: a. Stabilirea cazurilor de utilizare si a actorilor care interactioneaza cu ele, b. Pentru fiecare actor se identifica comportamentul pe care acesta il asteapta de la Sistemul Software (identificarea cerintelor reale, asteptate, nu a celor neclar enuntate, de obicei, de actori), c. Gasirea relatiilor dintre actori, a celor dintre cazurile de utilizare, precum si a celor dintre actori si cazurile de utilizare, d. Crearea diagramei. 6

7 Indicatii: a. Numele CU incep cu verbe (actiuni efectuate de sistem), b. Numele actorilor sunt substantive, c. CU primare se pun in coltul dreapta sus, d. Actorii principali se pun in stanga sus, e. Dependentele temporare se marcheaza prin aliniere verticala, f. Fiecare CU trebuie sa fie legat (direct sau nu ) de cel putin un actor si fiecare actor de cel putin un CU. Fluxul de evenimente este o descriere textuala clara a ceea ce face un caz de utilizare pentru a putea fi inteles de un neinitiat. Aceasta descriere poate fi nestructurata (in limbaj natural) sau structurata. Model de caz de utilizare descris prin flux de evenimente (structurat): Numele CU Actori implicati: Flux de evenimente (pasi facuti de actori pasi facuti de sistem) Preconditii: conditii necesare pentru ca scenariul sa poata fi initializat Postconditii: conditiile care trebuie indeplinite dupa executia cazului de utilizare Cerinte de calitate, care trebuie indeplinite de sistem. Scenariul este o secventa de actiuni care ilustreaza o varianta de comportament a unui caz de utilizare. Exemplu: Inmatriculare studenti. Un scenariu pentru candidatii obisnuiti, alt scenariu pentru candidatii studenti la alta facultate, alt scenariu pentru candidatii absolventi de alta facultate. Ingineria directa. Procesul de transformare a unui model in cod (procesul poate fi efectuat de om sau de un instrument (tool) specializat). Ingineria inversa. Procesul de obtinere a modelului plecand de la cod (procesul poate fi efectuat de om sau de un instrument (tool) specializat). Prin natura lor, diagramele cazurilor de utilizare nu pot fi supuse operatiilor de inginerie directa sau inversa deoarece diagramele CU reflecta cum se comporta un sistem, nu cum trebuie implementat comportamentul sistemului. 7

STRUCTURI DE DATE. Compresia datelor

STRUCTURI DE DATE. Compresia datelor STRUCTURI DE DATE Compresia datelor Caracteristici: Proces de codificare; Utilizarea unui numar mai mic de biti pentru stocarea datelor; Functioneaza daca emitatorul si receptorul au algoritmul de codificare/decodificare;