Subiecte pentru examenul la Ingineria softului

1. Noţiunea de sistem din perspectiva ingineriei softului (Sistem, Structura, comportament)

2. Noţiunea de metodologie din perspectiva ingineriei softului (Model de dezvoltare, Limbaj de modelare, Stil de management)

3. Arhitectura UML a soluţiei unei problemei.4. Formalismul UML pentru capturarea cerinţelor.5. Formalismul UML pentru specificarea structurii unui sistem IT.6. Diagrame de interacţiune în UML

Prof. dr. Dorin Bocu

1. No ţ iunea de sistem din perspectiva ingineriei softului (Sistem, Structura, comportament).

Numim sistem o colectie de obiecte intre care exista legaturi controlabile si observabile, cu scopul de a coopera in vederea indeplinirii unui obiectiv sau a unui agregat de obiective.

Def. Se numeşte sistem soft orice produs al IS care poate fi utilizat pentru a fundamenta sau realiza protocoale efective şi relativ autonome de prelucrare sau comunicare a datelor şi informaţiilor într-un context informaţional dat.

Aşadar, atributele esenţiale ale unui sistem soft sunt: Capacitatea de a fundamenta / realiza protocoale efective de prelucrare /

comunicare a datelor / informaţiilor. Protocolul fundamentat sau realizat are o autonomie relative Protocolul operează într-un context informaţional dat.

Prezenta legaturilor observabile si controlabile dintre componentele sistemului ne permite specificarea structurii sistemului, cu aproximatia de rigoare. Structura unui sistem si frontiera acestuia sunt invarianti a caror calitate conditioneaza calitatea unui demers de modelare sau explicativ.

Structura de calitate genereaza ordine in sistem.Cunoasterea structurii unui sistem ne permite sa facem predictii relativ la

comportamentul acestuia, observandu-i parametrii de stare sau simulandu-i comportamentul.

Observarea parametrilor de stare ai unui sistem este posibila datorita faptului ca orice sistem are un anumit tip de deschidere fata de mediul in care opereaza. Deschiderea unui sistem fata de mediu este, de regula, bidirectionala si este mijlocita de interfata sistemului.

Exista două tipuri de proprietăţi ale sistemelor soft:proprietăţi externe şi proprietăţi interne.

Dintre proprietăţile externe care decid calitatea unui sistem soft, le considerăm ca fiind foarte importante pe următoatele:

-corectitudinea; -robusteţea; -extensibilitatea; -reutilizabilitatea; -compatibilitatea; -eficienţa; -portabilitatea; -uşurinţa în folosire.

2. No ţ iunea de metodologie din perspectiva ingineriei softului (Model de dezvoltare, Limbaj de modelare, Stil de management) Metodologia este o colectie de metode si tehnici utile in procesul de inginerie a

sistemelor soft.Componentele esentiale ale unei metodologii:

-Procesul soft (modelul de dezvoltare);-Limbajul de modelare (metoda de abstractizare);-Modelul de management al proiectelor;-tehnologiile suport

Modele de dezvoltare( procese soft):

a. model primitiv de dezvoltare

-in acest caz specialistul in IS trebuie sa faca un salt urias de la cerinte la codul care descrie, practic, in detaliu, solutia executabila a sistemului soft.

b. un model imbunatatit de dezvoltare a softului

-imbunatatirea e insuficienta

c. modelul cascata (waterfall)

ImplementareSpecificarea cerinţelor

Implementare

Diagrama de structură

Specificarea cerinţelor

Implementarea

Testarea

Proiectarea

Analiza

Utilizarea şi instruirea

Definirea cerinţelor

Acest model consta intr-o descompunere a ciclului de viata al unui sistem soft in faze secventiale. Fazele sunt descompuse in activitati. Trecerea de la o faza la alta se realizeaza dupa ce precedenta a fost parcursa integral.

Avantaje:-ofera un control total asupra fazelor-este usor de insusit de catre partenerii unui proiect-fiecare faza esete “acompaniata” de o documentatie destul de bine structurataDezavantaje:-aplicandu-se la nivel de sistem, nu ofera suport prea consistent pentru controlul

complexitatii in cazul sistemelor mari-restrictiile de timp impuse de programarea calendaristica a fazelor limiteaza

ofertele benefice ale posibilitatii de revenire la o etapa anterioara-sistemtul se preda doar dupa parcurgeea etapelor anterioare ceea ce inseamna o

lunga perioada de timp pana cand utilizatorul vede sistemul la lucru-nu ofera suport adecvat pentru abordarea dinamica a proceselor de modelat-nu are protectie explicita fata de modficarile care pot interveni pe parcursul

dezvoltarii sistemului soft

d. modelul V

Acest model preia ideile de baza ale modelului cascada. Descrie o strategie de organizare a procesului de abstractizare in care se propune o perspectiva mai clara asupra elementelor de feed-back ale procesului, o abordare mai moderna a relatiei sistem-componente, o delimitare mai precisa a interferentelor procesului cu utilizatorul sistemului soft rezultat. Acest model face o distinctie clara intre verificare si validare.

Codificare/ asamblare

componente

Testare subsisteme (componente)

Proiectare subsisteme

(componente)

Testare sistem

Proiectare sistem

ValidareDefinirea cerinţelor

Verificarea se refera la testarea sistemului in diverse faze de dezvoltare dpdv al corectitudinii logice.

Validarea permite verificarea corectitudinii specificarii cerintelor initiale fata de sistemul soft. Validarea stabileste daca sistemul in forma lui finala corespunde sau nu cerintelor (fiind in faza finala e un punct slab).

e. Modelul prototipizarii

Acest model ofera o abordare care poate contribui la eliminarea omisiunilor si ambiguitatilor care pot exista in cerinte. Un sistem soft aflat in faza de prototip se deosebeste de un sistem soft gata de livrare prin o serie de omisiuni asumate sau strecurate involuntar in faza de codificare( implementare). Astfel un prototip are o functionalitate incompleta si poate fi folosit pentru a determina cel mai adecvat gen de interfata.

Fazele principale pentru a pregati un prototip:-efectuarea unei analize initiale-definirea obiectivelor prototipului-specificarea prototipului-construirea prototipului-evaluarea prototipului si stabilirea schimbarilor de efectuatAvantaje:-ilustrarea timpurie a functionalitatii sistemului-cerintele client omise au sanse sa fie identificate

Prototip complet

Evaluare prototip şi stabilire schimbări

Construire protoip

Specificare prototip

Definire obiective prototip

Analiza iniţială

-dificultatile legate de proiectarea intefetei pot fi constientizate si rezolvate-realizabilitatea si utlitatea sistemului soft pot fi testate chiar daca prototipul este

incomplet

Probleme:-clientul poate percepe prototipul ca parte a sistemului final-prototipul poate distrage antetia de la aspectele functionale catre problemele de

interfata-prototipizarea se bazeaza pe o implicare semnificativa a utilizatorului-managementul care se bazeaza pe modelul MP are de luat deicizi dificile de-a

lungul ciclului de viata.

Ca o concluzie, un model de dezvoltare este bun daca este agreat de un numar mare de specialisti. Acest lucru se poate intampla daca: -modelul e usor de invatat si operationalizat

-modelul e bine ancorat in realitatea procesului de dezvoltare-modelul ofera suport consistent de-a lungul intregului proces de

dezvoltare a sistemelor soft

Limbajul de modelare (metoda de abstractizare):

Limbajele de modelare serversc urmatoarelor scopuri minimale:-specificarea solutiei, la diferite nivele de abstractizare-vizualizarea solutiei-comunicare eficienta intre partenerii de proiect-automatizarea activitatii de modelare, cu ajutorul unor tool-uri adecvate (CASE)

Un limbaj de modelare reprezinta un ansamblu de concepte siprincipii de relationare a conceptelor, impreuna cu ntoatia aferenta, avand ca scop rezolvarea problemelor dintr-o anumita clasa tipologica.

Invatarea unui limbaj de modelare ridica aceleasi probleme pe care le ridica invatarea unui limbaj in general:-invatarea sintaxei;-invatarea semanticii din spatele sintaxei;-invatarea celor mai bune practici de utilizare a limbajului

Exista doua categorii de specialisti interesati de limbajele de modelare: specificatorul limbajului si utilizatorul limbajului. Specificatorul doreste sa defineasca un limbaj care sa contina sintaxa putina dar inteligenta pentru a rezolva probleme dintre cele mai diverse. Utilizatorul doreste sa modeleze cu ajutorul limbajului solutia unei probleme depunand minimul de efort.

Cu ajutorul unui limbaj de modelare vom elabora modele care trebuie sa fie, in final, piese ale solutiei. Aceste modele descriu doua tipuri fundamentale de caractersitici ale sistemelor soft-client:

-aspecte statice/structurale-aspecte dinamice/comportamentale

Pentru capturarea aspectelor statice, limbajele de modelare ofera instrumente de tipizare si relationare a tipurilor.

Pentru capturarea aspectelor dinamice, limbajele de modelare ofera tehnici de descriere a interactiunii dintre instantele tipurilor.

Le ce folosim, totusi, un limbaj de modelare in genere?Raspuns: la elaborarea si reprezentarea riguroasa a solutiei unei

probleme IT. Altfel spus, este vorba de folosirea limbajului de modelare ca instrument

de ghidare a demersurilor conceptuale(functia demiurgica) dar si pentru reprezentarea solutiei(functia descriptiva).

Modelul de management:

Lucrul în cadrul unui proiect de dezvoltare a unui sistem soft ridică probleme deosebite din punctul de vedere al managementului. Deja, practica lucrului în cadrul proiectelor de realizare a unor sisteme soft serioase a confirmat valabilitatea afirmaţiei potrivit căreia:

Un management slab poate compromite uşor şansele de reuşită ale unei echipe de proiectare redutabilă profesional; un management bun poate gestiona eventualele probleme datorate nivelului profesional necorespunzător al unora dintre membrii echipei de proiectare.

Managementul anticipeaza riscurile posibile pe baza istoricului proiectelor firmei;Managementul se preocupa constant de identificarea de riscuri noi.

Managementul descrie riscurile planificate sau identificate, pana la un nivel la care cauzele lor devin transparente;

Managementul cuantifica riscurile pentru a ierarhiza procesul de tratare a lor.

Managementul trateaza operativ riscurile, luand masuri de contracarare a acestora. Pe termen scurt se opereaza in zona efectelor. Pe termen lung se opereaza la cauze, pentru a evita manifestarea riscurilor in viitor.

Managementul indeplineste functii precum: -planificarea-organizarea-coordonarea-comandaManagementul de TOP, dacă este specificat corect trebuie să aibă cea mai mare stabilitate structurală. Managementul TACTIC formulează politicile necesare pentru îndeplinirea obiectivelor managementului de TOP. Dacă este necesar, stabilitatea structurală a acestor politici poate fi schimbată. În sfârşit, managementul OPERATIV face tot ceea ce este necesar pentru a operaţionaliza politicile stabilite de managementul TACTIC.

3. Arhitectura UML a solu ţ iei unei problemei.

Perspectiva logica sistem( structural view):Aceasta perspectiva se refera la cerintele functionale ale unui sistem soft. Putem

spune ca arhitectura logica a unui sistem soft semnifica abilitatea echipei de dezvoltare de a imbina gestiunea abstractiilor majore ale sistemului soft cu gestiunea mecanismelor cheie ale sistemului soft.

Perspectiva componente sistem( implementation view):Cu ajutorul acestei perspective se precizeaza diferitele componente ale uni sistem

soft impreuna cu relatiile dintre acestea. Prin componenta a unui sistem soft se intelege un modul fizic de cod. Intre componente pot aparea dependente. Aceasta perspectiva este importanta pentru rezolvarea corecta a problemelor de reutilizare a codului, portabilitate a codului si de management eficient al pieselor fizice ale unui sistem soft.

Perspectiva procese sistem( Behavioral view):Aceasta perspectiva urmareste structura executabilelor sistemului soft( procese,

fire de executie, mecanisme de concurenta si sincronizare, etc).

Perspectiva contexte de utilizare (utilizator)Mod de folosireÎnţelegere sistem

Perspectivaprocese sistem (comportamentală)PerformanţăUtilitateToleranţă la erori

Perspectivatopologie sistem (desfăşurare în mediul de execuţie)PerformanţăUtilitateToleranţă la eroriLivrare şi instalareAccesibilitate

Perspectivacomponenete sistem (implementaţională)Managementul softuluiReutilizarePortabilitate

Perspectivalogică sistem (structurală)

Funcţionalitate

Perspectiva componente sistem si perspectiva procese sistem folosesc pentru reprezentare diagrame de componente care indica componentele(procesele), interfetele acestora si dependentele dintre acestea.

Perspectiva topologie-hard( Enviromental view):O astfel de perspectiva precizeaza nodurile care formeaza topologia hard care

asigura executia sistemului soft. In aceste noduri se vor executa diferite procese indicate in perspectiva procese sistem. Aceasta perspectiva este reprezentata cu ajutorul unor diagrame de noduri, purtand etichete care sugereaza repartizarea pe tipuri de activitati si informatii despre procesele executate in aceste noduri.

Perspectiva contexte de utlizare( User view):Aceasta perspectiva demonstreaza si valideaza celelalte patru perspective. De

fapt, perspectiva contexte de utilizare se bazeaza pe folosirea contextelor de utilizare( use case) pentru a descrie comportamentul sistemului soft, asa cum este acesta vazut de diferite categorii de utlizatori. Aspectele statice ale acestui tip de perspectiva sunt reprezentate cu ajutorul diagramelor de contexte de utilizare, iar aspectele dinamice sunt incapsulate in diagrame de interactiune, de stare, de activitate.

4. Formalismul UML pentru capturarea cerin ţ elor.

Un context de utlizare este o descriere a unui set de secvente de actiuni pe care sistemul le executa pentru a produce un rezultat observabil asteptat de un actor.

Reprezentare grafica:

Decan

Fiecare context de utilizare trebuie sa aiba un nume. Acest nume e un sir de caractere care poati fi asimilat cu un nume simplu. Daca numele apare prefixat de numele pachetului din care apartine contextul de urilizare atunci este vorba despre un nume cu cale.

Contextele de utilizare si actoriiUn actor reprezinta un set de roluri pe care utlizatorii unui context de

utilizare le joaca cand interactioneaza cu acesta. De exemplu un lucrator la o banca ar putea, abstractizat ca actor, sa joace rolul de Agent-de-Imprumuturi.. Actorii pot fi conectati la un context de utlizare numai prin asociere. O asociere intre un actor si un context de utlizare precizeaza faptul ca intre aceste entitati exista o relatie de comunicare, in sensul ca fiecare poate trimite sau primi mesaje.

actor

Nume actor

Consultare planuri de invatamant

Context de utilizare

Nume context de utilizare

Contextele de utilizare si fluxurile de evenimentte

Un context de utilizare descrie ce face un sistem dar nu specifica cum face sistemul ceea ce are de facut. In procesul de modelare a solutiei unei probleme e foare important sa se faca distinctie intre interfata unui sistem si implementarea lui.

Putem specifica comportamentul unui context de utilizare prin descrierea textuala a unui flux de evenimente. Cand se redacteaza acest flux de evenimente trebuie sa specificam cum si cand incepe si se termina contextul de utilizare, cand interactioneaza contextul de utilizare cu actorii si ce obiecte sunt schimbate, fluxul principal precum si fluxrule alternative de evenimente.

Exemplu: context de utilizare: ValidareUtilizatorFlux principal de evenimente: Contextul de utilizare incepe in momentul

in care sistemul invita Clientul sa introduca codul PIN. Clientul poate introduce codul PIN de la tastatura. Clientul termina de introdu codul PIN prin apasarea butonului Enter. Sistemul verifica validitatea codului PIN. Daca codul PIN este valid, sistemul confirma introducerea codului PIN, ceea ce inseamna terminarea contextului de utlizare.

Flux exceptional de evenimente: Clientul poate anula o tranzactie in orice moment prin apasarea butonului Cancel, fapt care restarteaza contextul de utlizare.

Flux exceptional de evenimente: Clientul poate sterge codul PIN, in orice moment, avand posibilitatea sa reia introducerea codului PIN.

Flux exceptional de evenimente: Daca Clientul introduce un cod PIN invalid contextul de utlizare este restartat.

Contextele de utilizare si scenariile

Vom numi scenariu o secventa specifica de actiuni care ilustreaza o varianta de comportament a unui context de utilizare.

De exemplu descrierea contextului de utilizare InmatriculareStudenti trebuie sa ia in consideratie mai multe variante, fiecare varianta avand asociata propria secveta de actiuni.

Contextele de utilizare si colaborarile

Un context de utilizare trebuie la un moment dat sa beneficieze de o implementare si in acest scop va trebui identificata familia de clase si alte entitati care, lucrand impreuna, implementeaza contextul de utilizare. Aceasta familie de elemente, incluzand atat structura statica., cati si structura dinamica este modelata in UML sub forma unei colaborari. La nivel inalt de abstractizare putem specifica explicit realizarea unui context de utilizare de catre o colaborare ca in figura urmatoare:

Organizarea contextelor de utilizare

Contextele de utilizare pot fi organizate prin gruparea lor in pachete. Organizarea acestora poate fi realizata si apeland la relatiile de generalizare, includere si extindere. Toate aceste tipuri de relatii sunnt utilizate pentru a partaja comportamente comune.Relatia de generalizare: orice context de utilizare copil mostenste comportamentul si semantica contextului de utilizare parinte; copilul poate adauga elemente de comportament noi sau poate suprascrie comportamentul parintelui.Relatia de includere: un context de utilizare de baza incorporeaza explicit comportamenul unui alt context de utlizare la o locatie specificata in baza. Contextul de utilizare inclus nu poate opera singur niciodata ci doar instantiat ca parte a unui context de utilizare de baza, care il include. Folosim relatia de includere pentru a evita descrierea aceluiasi flux de evenimente de mai multe ori. O relatie de includere se reprezinta ca o relatie de dependenta marcata cu stereotipul <<include>>.Relatia de extindere: un context de utilizare de baza incorporeaza implicit comportamentul unui alt context de utilizare, la o locatie specificata indirect de contextul de utilizare care realizeaza extinderea. Folosim relatia de extindere pentru a modela o parte a unui context de utilizare pe care utilizatorul o percepe ca fiind un comportament optionale al sistemului. O relatie de extindere este redata ca o relatie de depentdenta, marcata cu stereotipul <<extend>>.

Diagrame de contexte de utilizareDiagramele de contexte de utilizare sunt esentiale pentru modelarea

comportamentului unui sistem, subsistem sau al unei clase. Continutul unei diagrame de contexte de utilizare:

-Contexte de utlizare-Actori-Relatii de dependenta, generalizare si/sau asociere-Mai poate contine: note si constrangeri

Analiza cerintelor este justificata de faptul ca specialistii în IS, de regula nu sunt si specialistiîn domeniul problemei. Fireste, pentru a realiza un soft de calitate trebuie colectate informatiidespre problema de rezolvat. De fapt, însasi planificarea riguroasa a dezvoltarii unui soft esteposibila numai dupa ce au fost întelese bine cerintele fata de sistemul soft si au fost eliminateeventualele neîntelegeri relativ la aceste cerinte.Specificare de cerinte s-a

facut, într-o forma sau alta, dintotdeauna în industria softului. Ceea ce separa optica UML, în ceeace priveste specificarea cerintelor, de alte limbaje de modelare este „unghiul din care se facespecificarea cerintelor”. UML spune raspicat: „înainte de a gândi la solutia unui sistem soft,determina, cu maximum de acuratete, tipul utilizatorului acestui sistem soft”.Pasii pe care, în principiu, trebuie sa-i urmam când modela, cerintele fata de un sistem softsunt:1. Stabilirea contextului sistemului, prin identificarea actorilor care interactioneaza cuel.2. Pentru fiecare actor în parte se va identifica comportamentul pe care acesta îlasteapta de la sistem / sau, altfel spus, cerintele acestuia fata de sistem.3. Comportamentele care corespund satisfacerii unor sisteme unitare de cerinte suntgrupate iar gruparile rezultate sunt contexte de utilizare având un nume sugestiv.4. Elementele de comportament folosite în cadrul mai multor contexte de utilizare suntdesemnate ca fiind contexte de utilizare noi; de asemenea, elementele decomportament care extind optional comportamentele unor contexte de utilizare suntdesemnate ca fiind contexte de utilizare noi, partajate de catre mai multe contextede utilizare.5. Modelati contextele de utilizare, actorii si relatiile aferente lor într-o diagrama decontexte de utilizare.6. Adaugati, daca considerati util, note care declara cerinte non-functionale; astfel denote pot fi atasate si întregului sistem.

------------------------------------------

5. Formalismul UML pentru specificarea structurii unui sistem IT.

UML este alcatuit din trei tipuri de elemente: entitati, relatii, diagrame.

Entitatile desemneaza o serie de abstractii. Tipuri de entitati in UML:-Entitati cu functii structurale;-Entitati cu functii comportamentale;-Entitati cu functii de grupare;-Entitati cu functii de documentare.

Entitati cu functii structurale( EFS):Reprezinta parti statice ale unui model, reprezentand elemente care sunt de natura

conceptuala sau fizica. In uml exista 7 genuri de EFS:a. Clasa – este o abstractizare a unei multimi de obiecte care partajreaza aceleasi

atribute informationale, acelasi comportament, aceleasi relatii si aceeasi

semantica. Formalismul de reprezentare a unei clase presupune redarea acesteia ca un dreptunghi care, in mod uzual, include: numele clasei, atributele si operatiile ei.

b. Interfata – abstractizeaza o colectie de operatii care specifica serviciile furnizate de o clasa sau componenta. O interfata este redata printr-un cerc caruia I se ataseaza numele interfetei.

c. Colaborare – abstractizeaza o familie de clase, interfete si alte elemente care, prin cooperare, reusesc sa asigure un comportament care inseamna mai mult decat “suma mecanica ” a comportamentelor partilor. Notatia pentru colaborare este o elipsa al carei contur este realizat cu o linie intrerupta, in interiorul careia se trece numele colaborarii.

d. Un context de utilizare – abstractizeaza o colectie de secvente de actiuni pe care trebuie sa le execute un sistem pentru a produce un rezultat care trebuie observat de un actor particular. Notatia pentru context de utilizare este o elipsa al carei contur este o linie continua, in interioru careia se trece numele contextului de utilizare.

e. Clasa activa – este o clasa ale carei obciete poseda unul sau mai multe procese sau fire de executie, ceea ce inseamna ca obiectele pot initia activitati de control. Ca reprezentare se deosebeste de o clasa normala prin linia ingrosata a conturului.

f. Componenta – este o parte a unui sistem soft, reprezentata de un anumit gen de cod fizic, dedicata, in general, realizarii uneia sau mai multor interfete. Notatia UML pentru o componenta: (desenez un dreptunghi care are pe linia din stanga 2 dreptunghiuri si in centru numele componentei).

g. Un nod – este un element fizic, care exista la un moment dat si reprezinta o resursa de calcul. Notatia UML pentru un nod este un paralelipiped cu numele in centru.

Entitati cu functii comportamentale( EFC):Abstractizeaza aspectele dinamice ale unui sistem in cadrul modelelor UML.

Exista doua tipuri fundamentale de EFC:a. Interactiune – abstractizeaza un comportament care cuprinde o multime de

mesaje schimbate intre obiectele unui sistem, intr-un context particular, in vederea indeplinirii unui obiectiv specific. Notatia UML : o sageata cu vf spre dreapta si deasupra de ex metoda afiseaza()

b. Masina de stare – abstractizeaza comportamentul unui singur obiect sau al unei interactiuni dintre obiecte, pe timpul vietii acestora, ca succesiune de actiuni-raspuns la anumite evenimente. Notatia UML: dreptunghi cu colturile rotune in interiorul caruia se afla numele starii( ex. asteptare) si eventual substarile asociate.

Entitati cu frunctii de grupare( EFG):Specia fundamentala de EFG este pachetul. Acesta este un mecanism utilizat

pentru organizarea elementelor in grupuri de elemente. La diferite nivele de abstractizare, intr-un pachet pot fi grupate EFS, EFC si chiar alte EFG. Sunt reprezentate ca niste casete in care un anumit model poate fi descompus in ceea ce se considera a fi partile componente.

Entitati cu functii de documentare( EFD):Reprezinta partile explicative ale modelelor UML. De fapt, acestea sunt

comentarii folosite in descrierea modelelor UML. In UML sunt reprezentate ca note.

Relatii in UMLRelatiile abstractizeaza diferite tipuri de legaturi care pot exista intre entitati.UML utilizeaza patru tipuri de relatii:a. Dependentele – abstractizeaza o relatie semantica intre doua entitati,

caracterizata prin faptul ca o schimbare in una dintre ele poate afecta semantic cealalta entitate. Notatia UML este o sageata punctata.

b. Asocierile – abstractizeaza o relatie structurala prin care se descriu legaturile dintre obiecte, de tipuri diferite sau de acelasi tip. Notatia UML inseamna o linie continua, un nume si eventual restrictii de cardinalitate si nume de roluri, directionate sau nu.

c. Generalizarile – este abstractizarea unei relatii dintre doua concepte UML, compatibile, a carei semantica este exprimata astfel:

- Unul dintre concepte este concept tata, celalalt e concept fiu- Orice element din categoria conceptuala tata poate fi substituit de un

element fiu. Acest lucru e posibil deoarece un element fiu mosteneste structura si comportamentul elementului parinte asociat.

Notatia UML este o sageata cu varful gol.d. Realizarile – este abstractizarea unei relatii semantice intre clasificatori,

exprimata astfel: un clasificator specifica niste capabilitati pentru care alt clasificator furnizeaza suportul necesar. Notatia UML este o sageata punctata cu varful gol.

Diagrame in UMLDiagramele sunt folosite pentru a grupa colectiile de entitati, cu scopul de a

evidentia mai bine diferitele nivele de abstractizare ale solutiei unui sistem soft.In UML diagramele sunt reprezentari grafice ale unor colectii de elemente

(entitati si relatii). Diagramele UML sunt grafuri ale caror noduri sunt entitati si ale caror arce unt relatii.

Se recomanda utilizarea urmatoarelor tipuri de diagrame:a. Diagrame de claseb. Diagrame de obiectec. Diagrame de contexte de utilizared. Diagrame de secventae. Diagrame de comunicaref. Diagrame harti de stareg. Diagrame de activitateh. Diagrame de componentei. Diagrame de desfasurare.

6. Diagrame de interac ţ iune î n UML (SIPP_ID_2 pg 82) Diagramele de secventa si diagramele de colaborare, numite

impreuna diagrame de interactiune, sunt doua din cele cinci tipuri de diagrame folosite de UML pentru modelarea aspectelor dinamice ale sistemelor.

Diagramele de intercatiune sunt importante si pentru obtinerea codului executabil, atat prin inginerie directa cat si prin ingineria inversa.

Concepte vehiculate in procesul de elaborare si intelegere a diagramelor de interactiune

O diagrama de interactiune expune o interactiune, determinata de o multime de obiecte, imrepuna cu relatiile dintre ele, incluzand si mesajele dcare pot fi schimbate intre aceste obiecte.

O diagrama de secventa este o diagrama de interactiune care pune accent pe ordonrea in timp a mesajelor. Acest tip de diagrama poate fi reprezentat ca un tabel care expune obiectele aranjate de-a lungul axei absciselor si mesajele ordonate dupa evolutia in timp de-a lungul axei ordonatelor.

O diagrama de colaborare este o diagram de intercatiune care pune accent pe organizarea structural a obiectelor care trimit sau receptioneaza mesaje. Ca si reprezentare o diagrama de colaborare este o colectie de noduri si arce.

Continutul unei diagramde de interactiuneO diagrama de interactiune contine:

Obiecte Legaturi Mesaje Optional mai poate contine note si constrangeri

Atunci cand modelam aspecte dinamice ale unui sistem folosim diagrame de interactiune in doua moduri:

1. Pentru a modela fluxurile de control prin ordonarea in timp (in acest caz operam cu diagrame de secventa)

2. Pentru a modela fluxurile de control punand accent pe organizare (in acest caz operam cu diagrame de colaborare)

Ingineria directa si inversa a diagramelor de interactiune Ingineria directa este posibila pentru ambele tipuri de diagrame de interactiune, indeosebi atunci cand contextul diagramei este o operatie.

Ingineria inversa este, de asemenea, posibila pentru ambele tipuri de diagrame de interactiune, indeosebi atunci cand codul in cauza este implementarea unei operatii.