Prezentare Curs Software: Mecanisme și Sisteme Informaționale PDF

**CURS 1** ========== **Sistem** = colectie de componente ce interactioneaza intre ele intr- un mod unitar **Sisteme:** **Naturale**: univers, atom, galaxie, ecosistem, sistemul anatomic, etc **Artificiale**: masini, avioane, sisteme de control al zborurilor, sisteme bancare, calculatoare, e...

**CURS 1** ========== **Sistem** = colectie de componente ce interactioneaza intre ele intr- un mod unitar **Sisteme:** **Naturale**: univers, atom, galaxie, ecosistem, sistemul anatomic, etc **Artificiale**: masini, avioane, sisteme de control al zborurilor, sisteme bancare, calculatoare, etc **Resurse:** materiale, energetice, informationale, tehnologice Orice sistem are o stare si un comportament Dpdv al comportamentului, sistemele se impart in: - **Simple**: biciclete, etc - **Complexe si organizate**: masini, vapoare, avioane, sisteme hardware, etc - **Complexe si neorganizate**: economia unei tarj, bursa marfurilor, etc Sisteme de lucru ---------------- **Sistem de lucru** = sistem artificial în care participanți umani și/sau mașini realizează activități organizate după anumite reguli, folosind resurse de intrare, inclusiv tehnologice, pentru a furniza resurse de ieșire în vederea îndeplinirii obiectivelor organizației sau întreprinderii. Orice sistem de lucru conține următoarele componente: - obiective, - participanți, - activități, - resurse de intrare și de ieșire, - reguli de utilizare a resurselor și de executare a activităților și a acțiunilor componente. **Sisteme informationale** **Sistem informational** = model informațional al unuia sau mai multor sisteme de lucru dintr-o organizație cu rolul de a furniza suportul informațional al sistemului reprezentat. Orice sistem informațional îndeplinește funcționalitățile de colectare, transmitere, memorare, căutare, manipulare și furnizare date, informații și cunoștințe. Un sistem informațional poate fi: - al unei întreprinderi, societăți comerciale, instituție guvernamentală sau organizație ce are ca scop obținerea de profit. În acest caz, sistemul poartă numele de sistem de afaceri. - al unui produs, - al unui serviciu, - al unui mediu tehnologic de prelucrare a datelor sau de control al proceselor. Pentru a-și îndeplini funcțiile, un sistem informațional folosește sisteme informatice, aplicații software, proceduri manuale și depozite interne sau externe de date. Sistem informatic si sistem software ------------------------------------ **Sistem informatic** = sistem complex si organizat format din: 1. Sistem software 2. Sistem hardware 3. Oameni 4. Baze date si/sau de cunostinte 5. Documentatie **Sistem software** = sistem complex si organizat format din: 1. Programe 2. Structuri de date 3. Documentatie **Caracteristicile** sistemelor software: · Nu sunt fabricate in sens clasic, ci dezvoltate sau inginerizate · Nu se demodeaza, dar se pot deteriora · Majoritatea sunt create de la zero, nu din compunerea componentelor existente A white paper with black text AI-generated content may be incorrect.  CURS 2 ====== Mecanisme de gestiune a complexitatii unui ------------------------------------------ sistem ------ 1. **Descompunere**: se bazeaza pe principiul \"Divide et Impera\" - orice sistem face parte dintr-un sistem mai larg care îl cuprinde și furnizează contextul acestuia; - orice sistem poate fi împărțit în mai multe subsisteme. **Avantaje:** - timpul de construire a unui sistem este micșorat; - ușurința de testare a fiecărui modul în parte; - flexibilitate; - înțelegere; - propagarea erorilor este redusă; - reutilizarea modulelor, care se datorează simplificării interfețelor modulelor. 2. **Conceptualizare** = capacitatea de abstractizare a unei clase de obiecte care sunt apoi încorporate într-o imagine sau într- un concept, și de asemenea, capacitatea de a sesiza proprietățile distinctive ale unei clase de obiecte - Concept = entitate cognitivă și semantică ce permite organizarea și interpretarea entitaților concrete sau abstracte. - Abstractizare = caracteristică a gândirii, care operează cu însușiri generale, abstracte, aflate pe nivelul concretului logic (gândit) și care redă lucrul în multitudinea însușirilor sale concrete interpretate însă, ceea ce determină ca acestea din urmă să capete o nouă semnificație. Așadar, abstractizarea ne permite să lucrăm cu concepte, în locul lucrurilor concrete, ceea ce determină înțelegerea și cunoașterea acestora din urmă. 3. **Rafinare**: mecanism introdus prima data de N. Wirth la construirea programelor 4. **Separarea concern-elor**: introdus prima data de E. W. Dijkstra - Concern = grija datorata unei probleme din lumea reala a unui sau mai multor participanti implicati in construirea sau evolutia unui sistem informational in mediul sau natural. Grija unui participant depinde de propriul sau interes sau preocupare pe care acesta il/o are in legatura cu o problema din lumea reala. Interesul unui participant deriva frecvent dintr-o nevoie, dar poate de asemenea sa provina dintr-o dorinta, un alt interes sau din responsabilitatea sa in procesul de evolutie a sistemului informational.\\ **Metodologii de dezvoltare a software** · **Metodologie** = colectie de metode folosite pentru rezolvareunei clase de probleme, aplicabile in timpul dezvoltarii unui sistem si grupate intr-o anumita abordare generala, filozofica. O metodologie de dezvoltare sw consta din doua component complementare: - Un proces software = secventa de activitati si decizii care muta sistemul de la concepere pana la terminare; - notatie standard = forma de comunicare folosita pentru a documenta cunostintele si deciziile luate pe parcursul procesului de dezvoltare a sistemului. 1. **Metodologia structurata** (1970-1989) se bazeaza pe principiile: abstractizare, ierarhizare, separarea datelor (entitatilor) de functii(procese). 2. **Metodologia orientata spre date** (1970-1980) se bazeaza pe principiile: - datele intreprinderii furnizeaza o baza mult mai stabila pentru o proiectare de sistem decat procedurile intreprinderii, si - datele ar trebui vazute ca o resursa a intreprinderii independenta de sistemele care le proceseaza. Baza acestei metodologii a fost pusa in 1970 odata cu inventarea modelului relational de baze de date si a modelarii entitate-relatie. 3. **Metodologia orientata spre obiecte** (1990-prezent): Sistemul este modelat numai in termeni de obiecte. Aceste obiecte ofera servicii (comportament) lumii inconjuratoare si contin informatie. Obiectele comunica intre ele prin mesaje. Principiile metodologiei orientata spre obiecte - **Abstractizare**: capacitatea de a capta proprietatile esentiale ale unei entitati, in cazul nostru, ale unui obiect. - **Incapsulare**: datele (starea) si comportamentul (operatii) sunt incapsulate in obiect. Accesul la un obiect se face numai prin intermediul interfetei naturale acestuia. - **Mostenire**: mecanism folosit pentru partajarea datelor si a comportamentului comun unei colectii de clase. Aceasta factorizeaza proprietatile comune ale claselor in supraclase si le reutilizeaza in definirea subclaselor. - **Polimorfism**: - de incluziune: subclasificare - parametrizat: clase template - **Modularitate**: Descompunerea unui sistem într-un ansamblu de module cu o mare coeziune interna si cu legaturi slabe intre ele. ### Modele Un model este o descriere (sau specificație) rezultată în urma aplicarii mecanismului de abstractizare asupra unui domeniu sau a unui sistem. Un domeniu este o porțiune limitată a lumii reale sau imaginată. **Obiective**: - Oferă o bază pentru construirea sistemelor. - Folosind rafinarea, putem construi modele pe nivele diferite de abstractizare. - Permit obținerea unei soluții bune din punct de vedere calitativ. - Furnizează produse de lucru reutilizabile. - Previn efectuarea unei modificări și facilitează restructurarea. - Furnizează o bază de comunicare între membri echipei de dezvoltare, respectiv între echipă și clienți. **Mecanisme de construire a modelelor** - Conceptualizare = capacitatea de abstractizare a unei clase de obiecte care sunt apoi încorporate într-o imagine sau într-un concept, și de asemenea, capacitatea de a sesiza proprietățile distinctive ale unei clase de obiecte. - Abstractizare = considerarea anumitor concepte cu anumite proprietati - Rafinare = adaugarea altor concepte si/sau altor proprietaticonceptelor existente ### ### **Puncte de vedere si vederi** **Punct de vedere** = tehnică de abstractizare folosind o mulțime de concepte arhitecturale și reguli de structurare cu scopul de a ne concentra pe o mulțime particulară de aspecte de interes din acel sistem. **Vedere** = model a unui sistem dintr-un punct de vedere ales. Limbajul UML (Unified Modeling Language). Limbaj semi-formal standardizat in 1997 · Realizat de catre Booch, Rumbaugh si Jacobson pe baza: OMT, OOSE si Booch method · \"este folosit pentru a specifica, vizualiza, construi și documenta artefactele unui sistem software\" · Artefactele capteaza cunostintele despre elementele componente ale unui proces initiat sau realizat de un sistem. · Limbajul poate fi folosit pentru specificarea oricarui tip de sistem (software sau nu), domeniu sau proces (business sau software) · UML permite captarea si prezentarea cunostintelor pentru a facilita comunicarea intre dezvoltatori si intre dezvoltatori si beneficiari. · URL: http://uml ora/ Vederi si diagrame construite cu UML A diagram of uml AI-generated content may be incorrect. CURS 3 ====== Partea a ll-a. Procesul de dezvoltare ------------------------------------- a unui sistem informational --------------------------- **Participanti** Participanții (en: stakeholders) unui proces de dezvoltare a unui sistem informațional sunt oameni care influențează direct sau indirect sau sunt afectați sau influențați de dezvoltarea și/sau utilizarea sistemului. În raport cu mediul (întreprindere, organizație, etc.) în care va fi „executat\" sistemul informațional, participanții pot fi: - externi, precum clienți, furnizori, dezvoltatori ai sistemelor care interacționează cu sau integrează sistemul informațional în curs de dezvoltare, etc. sau - interni, precum angajați ai departamentelor care suporta proiectul, personalul de conducere, reprezentanți ai departamentelor financiare, etc.  **Fazele procesului de dezvoltare** A diagram of a model AI-generated content may be incorrect. **Analiza sistemului actual** Scopul analizei este de a delimita domeniul de interes al organizației sau afacerii al carui sistem de lucru va fi modelat din punctul de vedere al informațiilor. Chestionarele trebuie să răspundă la următoarele întrebări: - ·Care sunt responsabilitățile cheie? - ·Ce sarcini îndeplinești zi de zi? - ·Care sunt sarcinile care necesită mult timp pentru îndeplinirea - lor? - ·Ce anume te interesează la locul de muncă? - ·Ce artefacte sau informații produci? - ·Pentru cine? - ·Ce informații ai nevoie pentru a produce artefactele? - ·Cum obții aceste informații? -.Cu ce probleme te confrunți în timpul producerii artefactelor? - ·Cum măsori succesul? - ·Ce probleme interferează cu succesul? **Proiectarea logica a sistemului viitor** Activitațile din modelul sistemului actual sunt clasificate în două categorii: - automatizate și - neautomatizate. Apoi, în cazul activităților **neautomatizate** se procedează înunul din urmatoarele moduri: - se elimină dacă sunt activități care prin informatizare devin superflu; - se propune posibila lor informatizare; - sunt lasate manuale. Proiectarea continuă cu dezvoltarea aplicațiilor software, construirea unei baze de date, de cunoștințe și a structurii datelor interne. Fiecare dintre aceste aplicații va fi dezvoltată conform unui model de proces software și urmând principiile ingineriei software. ### Modelul business Componente business  **Modele ale sistemelor business** 1\. **Modelul organizatiei** = organigrama organizatiei sau intreprinderii 2\. **Modelul agentilor business** Agent business = rol al unei persoane sau al unui echipament care participa la executarea unor activitati business folosind eventual instrumente pentru a indeplini un scop bine stabilit. Fiecare agent este descris prin responsabilitatile pe care trebuie sa le indeplineasca 3.**Modelul proceselor business** Proces business = colectie de activitati legate structural intre ele ce produc ceva de valoare organizatiei si participantilor. Fiecare proces are intrari, o metoda si iesiri. **Analiza business** - Identificarea actorilor business - Actor business = rol al unei persoane sau entitati externe sistemului business modelat care participa in activitatile procesului business pentru a-si indeplini un obiectiv. - Identificarea agentilor business - Descrierea proceselor business CURS 4 ====== Modelul business ---------------- Este format din: - Modelul cazurilor de utilizare business - Modelul obiectelor business Modelul cazurilor de utilizare business contine: - Diagrama UML a cazurilor de utilizare business - Diagrame UML de activitati **Caz de utilizare business** = descriere a comportamentului unui sistem ca raspuns la o cerere din exteriorul sistemului. ### Diagrama cazurilor de utilizare business Diagrama de cazuri de de utilizare business este un graf care arata atat actorii si cazurile de utilizare business, cat si relatiile dintre elemente de modelare. Cazurile de utilizare business sunt identificate in general din procesele business ale sistemului si din obiectivele actorilor business. A diagram of a business AI-generated content may be incorrect. Diagrama UML de activitati -------------------------- **Diagrama de activitati** = graf de activitati care prezinta executareaunui calcul sau workflow, precum si obiectele care le realizeaza. **Activitate** = descrierea unui comportament parametrizat cum ar fi coordonarea executarii actiunilor componente, folosind un flux de control sau de date. **Fluxul de control** este modelat ca un graf de noduri legate intre ele prin tranzitii. Fiecare **obiect** este descris prin clasa din care face parte si starea in care se afla in momentul respectiv. **Obiectele** sunt resurse de intrare/iesire ale activitatilor. **Activitatile pot fi organizate** in grupuri (swimlanes) in functie de responsabilitatea lor, atribuita de obicei departamentelor organizatiei implicate in gestionarea si realizarea activitatilor sau actorilor/agenti business/sistemului care le realizeaza. **Sintaxa diagrmaei UML de activitti**  **Modelarea concurentei** A diagram of a structure AI-generated content may be incorrect. CURS 5 ====== Modelare business ----------------- **Modelul obiectelor** Acest model conţine tipurile de informaţii persistente importante la nivelul sistemului de lucru modelat şi care sunt partajate de mai multe domenii, împreunǎ cu relaţiile dintre ele. ​ Exemple: ​ - producǎtori şi consumatori de informaţii şi cunoştinţe (clienţi, furnizori), ​ - structuri de date complexe (rapoarte, statistici), ​ - evenimente (contracte, comenzi), ​ - roluri administrative (director de vânzǎri, manager, etc.), ​ - unitǎţi organizative (marketing, producţie), ​ - locuri (locuri de producţie) şi ​ - informaţii structurate (dosarul unui angajat). **Diagrama UML de clase** **Noţiune** **Semantica** ------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Clasǎ Este un descriptor pentru un set de obiecte cu proprietǎţi (atribute) similare, cu acelaşi comportament (operaţii), cu aceleaşi relaţii cu alte obiecte şi cu o aceeaşi semanticǎ. O clasǎ are un nume unic în container-ul sǎu (pachet sau altǎ clasǎ), are o vizibilitate şi o multiplicitate. Atribut Descrie valorile pe care le poate lua obiectele clasei ce-l conţine. O clasǎ formeazǎ un spaţiu de nume pentru atributele sale. Tip de date Este un clasificator ale cǎrui instanţe sunt valori, adicǎ nu au identitate. Astfel douǎ apariţii ale aceleaşi valori nu pot fi diferenţiate. De obicei, un tip de date este folosit pentru specificarea tipului unui atribut. Operaţie Este o specificaţie a unei transformǎri a stǎrii obiectului ţintǎ (şi posibil asupra stǎrii celorlalte obiecte care folosesc obiectul respectiv) sau o accesare ce returneazǎ o valoare apelantului operaţiei. O operaţie poate fi implementatǎ ca o metodǎ sau ca un apel de eveniment ce determina o tranziţie în maşina de stǎri a unui obiect activ. Interfaţǎ Este descrierea comportamentului obiectelor altor clase fǎrǎ sǎ conţinǎ starea sau implementarea lor; conţine numai operaţii. ---------------- ------------------------------------------------------------------------------------------------------------------------------- Clasa template Clasa descrisa incomplet. Informatiile lipsa sunt specificate prin parametri. Clasa-asociere Clasa care provine dintr-o asociere, despre care trebuie sa memoram date/informatii **Categorii de relatii de asociere** ** ** Categorie Exemple ---------------------------------------------------------- ---------------------------------------------- A este o parte fizica a lui B **Tulpina-Floare, Cadru-Fereastra** A este o parte logica a lui B **Articol-Vanzare** A este continut fizic in B **Stoc-Magazin** A este continut logic in B **DescriereProdus-Catalog** A este o descriere a lui B **DescriereProdus-Produs, Masina-Model** A este un element al tranzactiei sau raportului B **Articol-Vanzare** A este cunoscut/inregistrat/logat/raportat/capturat in B **Vanzare - Chitanta** A este un membru al lui B **Ministru--Guvern, Profesor - Departament** A este o suborganizatie a lui B **Departament Salarizare - Universitate** A utilizeaza-gestioneaza B **Persoana-Masina** A comunica cu B **Profesor-Student** A este corelat cu B **Client-Vanzare** A este o tranzactie corelata cu alta tranzactie **Rezervare-Cumparare** A succede B **Inchiriere-Rezervare** A este in posesia lui B **Masina-Proprietar** **Relatia de agregare** Relatia de agregare = asociere binarǎ ce specificǎ o relaţie întreg-parte (tranzitivǎ şi anti-simetricǎ) dintre un agregat şi o parte constituentǎ. ​ O parte poate aparţine mai multor agregǎri şi poate exista în afara relaţiei de agregare.  **Relatia de compozitie** Relatia de compozitie = o formǎ puternicǎ de agregare, în sensul cǎ verificǎ urmǎtoarele constrângeri: ​ - un obiect poate fi parte a unei singure compoziţii şi ​ - obiectul compus are responsabilitatea creǎrii şi distrugerii tuturor pǎrţilor sale.​ - Obiectele parte nu pot fi mutate dintr-un obiect compus la altul. A diagram of a diagram AI-generated content may be incorrect. Relatia UML de generalizare Relaţie tranzitivǎ, antisimetricǎ între douǎ clase, în care una este supraclasa celeilalte numita subclasǎ, în sensul cǎ subclasa moşteneşte elementele de modelare ale supraclasei sale. ​ O supraclasǎ poate avea mai multe subclase, caz în care supraclasa este descrierea unei mulţimi de instanţe (indirecte) cu caracteristici comune tuturor subclaselor sale.  **Relatia de realizare** Relaţie între o specificaţie (interfaţǎ sau caz de utilizare) şi o implementare a sa (clasǎ sau colaborare). A diagram of a diagram AI-generated content may be incorrect. **Relatia de dependenta** Relaţie între douǎ clase (elemente de modelare) în care o modificare a unei clase (furnizor) poate afecta sau furniza informaţia necesarǎ altei clase. ​ Tipuri de dependenţǎ: ​ - abstractizare​ - legare​ - permisiune şi ​ - folosire.  CURS 6-7 ======== Modelare business ----------------- **Tehnica de construire a diagramei UML de clase a modelului obiectelor** Pas 1. Identificarea conceptelor problemei Pas 2. Identificarea claselor si atributelor lor Pas 3. Analiza rolurilor Rol = este o descriere a unei multimi de proprietati si actiuni pe care le au sau le executa instantele unui alt concept (clase) care joaca rolul respectiv intr-un anumit context. Roluri: materiale sau formale Pas 4. Realizarea diagramei UML de clase **Ingineria software** Ingineria software-ului este: - stabilirea si aplicarea principiilor ingineriei software pentru a obtine un sistem software de calitate in timpul si costul estimate, - aplicarea unei strategii sistematice, disciplinate si masurabile pentru dezvoltarea, utilizarea si intretinerea software-ului. Scop: dezvoltarea unui sistem software nou sau imbunatatirea unuia existent **Proces software** Proces care conduce la realizarea unui produs software O multime de activitati realizate de oameni si/sau masini cu scopul de a produce si intretine un sistem software si produse auxiliare: planul proiectului, documente de proiectare, cod, cazuri de testare, manual de utilizare, etc) Cadru de referinta in care se desfasoara toate activitatile necesare obtinerii unui sistem software de calitate Defineste strategia adoptata pentru producerea software-ului, nu si tehnologiile utilizate A screenshot of a computer AI-generated content may be incorrect. Modele ale procesului software ------------------------------ 1. **Modelul spirala** Probleme: - Este dificil sa fie convinsi clientii ca o dezvoltare de acest fel poate fi tinuta sub control; - Necesita competente de nivel inalt pentru estimarea riscurilor; - Daca un risc important nu este descoperit si controlat la timp, problemele pot creste ulterior exponential.  2. **Model Driven Architecture** - MDA este o abordare suportatǎ de OMG ce propune folosirea modelelor în dezvoltarea sistemelor şi în special a sistemelor software. - MDA propune construirea a trei vederi: modelul independent de calcul, modelul independent de platformǎ şi modelul specific platformei. - Modelul independent de calcul este o vedere a sistemului care nu aratǎ detaliile de implementare ale sistemului. De obicei un astfel de model se mai numeşte modelul domeniului sau al afacerii. - Modelul independent de platformǎ este o vedere a sistemului în care acesta este vǎzut ca o maşinǎ virtualǎ (definitǎ ca un sistem ce furnizeazǎ servicii) independentǎ de platformǎ. - Modelul specific platformei îmbinǎ modelul anterior cu detalii privind modul în care sistemul foloseşte un tip particular de platformǎ. 3. **Dezvoltarea agila a software-ului** - Model propus in 2001 de catre organizatia non-profit Agile Alliance - Principii: - Mai importanti sunt oamenii, decat procesele si instrumentele - Mai important este sa dezvoltam software, decat sa scriem documentatie - Mai important este sa colaboram cu clientii, decat sa negociem contracte - Mai important este sa modificam, decat sa urmam un plan - Dezvoltare iterativa, condusa de testare, cu refactorizari frecvente, cu integrare continua, cu implicarea clientilor in procesul de dezvoltare - Incurajeaza programarea in echipe de doi - Client: ajuta la definirea produsului - Proiectant/Programator: ajuta la construirea produsului - Tester: verifica daca produsul functioneaza dupa cum a fost definit - Tracker : ajuta la strangerea si prezentarea metricilor - Instructor: instruieste si ghideaza echipa - Manager(optional): gestioneaza comunicarea externa Analiza cerintelor software --------------------------- **Modelul functional** Caz de utilizare software = unitate coerenta de functionalitate furnizata de un clasificator manifestata prin secvente de mesaje intre clasificator si unul sau mai multi actori, impreuna cu actiunile realizate de sistem. Este un descriptor de comportament potential al unui clasificator in interactiunea lui cu actorii. Fiecare caz este descris printr-un sablon folosind limbaj natural care contine urmatoarele elemente: nume; - descriere; - actori software: - actori principali sau - actori secundari. - eveniment declansator; - preconditii si postconditii: - referinte incrucisate; - flux principal; - unul sau mai multe fluxuri alternative. CURS 8 ====== Analiza cerintelor software. Modelul functional ----------------------------------------------- **Diagrama UML a cazurilor de utilizare** Acest tip de diagrama descrie functionalitatea sistemului pe care o imparte in grupuri utile actorilor. ​ Acest tip de diagrama este aplicat in unul din urmatoarele doua moduri:​ - pentru a modela contextul sistemului care implica definirea frontierei sistemului, adica diferentierea task-urilor realizate de sistem si a celor indeplinite de actori, precum si gasirea actorilor care interactioneaza cu sistemul.​ - pentru a modela cerintele unui sistem, care implica specificarea a ceea ce trebuie sa faca sistemul independent de cum ar trebui sa faca. ​ Pasii de creare a unei astfel de diagrame UML:​ - stabilim contextul sistemului,​ - pentru fiecare actor, consideram comportamentul pe care-l asteapta sau il cere sistemului,​ - factorizam comportamentul comun in noi cazuri de utilizare ce sunt folosite de alte cazuri de utilizare; cream noi cazuri de utilizare ce extind fluxuri de evenimente principale.​ **Sintaxa abstracta a diagramei c.u.sw​**  **Evenimente de system** Evenimente externe generate de actiuni ale actorilor software asupra sistemului in curs de dezvoltare.​ Exista trei categorii de evenimente de sistem:​ - Evenimente flux de date​ - Evenimente de control​ - Evenimente temporale​ **Diagrama UML de secvente​** ** ** **Concept** **Semantica** -------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ **Linie de viata** **Indica existenta unui obiect pe o perioada de timp. Daca in aceasta perioada obiectul este creat sau distrus, atunci linia sa de viata incepe sau se termina in punctul respectiv.** **Activare** **Indica perioada in care un obiect executa o operatie, fie el insusi, fie prin intermediul altor operatii subordonate. Modeleaza atat durata executiei in timp cat si controlul dintre executie si apelantii ei.** **Mesaj** **Este o comunicare intr-un sens intre doua obiecte, un flux de informatie de la un obiect (expeditor) la un alt obiect (destinatar). Destinatarul poate coincide cu expeditorul, caz in care avem de-a face cu o modificare a starii obiectului respectiv. Un mesaj poate fi un semnal (o comunicare asicrona explicita intre obiecte) sau un apel (invocarea sincrona a unei operatii cu returnarea mai tarziu a controlului apelantului). Semnalul sau apelul reprezinta actiunea atasata mesajului. O actiune poate fi primitiva, cum ar fi crearea sau distrugerea unui obiect in timpul interactiunii. Actiunea poate contine o lista de parametri, o expresie pentru o multime de destinatari si o referinta la operatia sau semnalul implicat. De asemenea poate include o conditie si o iterare a executarii mesajului.** **Tipuri de mesaje** - Mesaje sincrone; Mesaje reply​ - Mesaje asincrone; Mesaje create; Mesaje destroy​ **Diagrama de secvențe de sistem** Diagramele de secvente de sistem sunt diagrame de secvente ce arata interactiunea (mesajele) transmise intre actorii software si sistem. Ex. A diagram of a system AI-generated content may be incorrect. **Diagrama de context** Diagrama de context este realizata din doua perspective:​ - functional: sistemul este descris ca un caz de utilizare software;​ - structural: sistemul este descris ca o clasa ale carei operatii sunt operatii de sistem.​.  **Diagrama de context d.p.d.v. structural** A screenshot of a computer AI-generated content may be incorrect. CURS 10 ======= Proiectare software ------------------- **Analiza vs proiectare** - Domeniul problemei vs domeniul solutiei - Analiza - Ce?, Proiectarea - Cum? - In timpul proiectarii se construieste o solutie conceptuala care sa indeplineasca cerintele functionale si nefunctionale (e.g. performanta, flexibilitate, intretinere, etc.) identificate si descrise in faza de analiza. - Modelul domeniului problemei constituie baza proiectarii bazei dedate. - Proiectarea se imparte in doi pasi: - Proiectarea arhitecturala: domeniul este partitionat functional. - Se stabilesc tehnologiile ce vor fi folosite pentru obtinerea unui sistem de calitate - Proiectarea obiectuala: sunt adaugate noi clase pentru a suporta functionalitatea asteptata de cazurile de utilizare software. Clasele sunt detalitate pentru a putea fi implementate. **Proiectarea arhitecturala** - Proiectarea arhitecturala evalueaza cerintele sistemului in raport cu tehnologiile ce ofera cele mai bune cadre pentru o solutie: - Diagrama UML de cazuri de utilizare software este folosita ca sursa pentru partitionarea functionala, - Diagrama UML de clase furnizeaza resurse pentru fiecare arie functionala, - Diagrame UML de interactiune furnizeaza dependentelepentru partitiile functionale. - Partitiile rezultate sunt modelate intr-o diagrama UML de pachete. **Arhitectura software** O arhitectură software = descriere a componentelor ce formeaza sistemul software si a conexiunilor ce coordoneaza actiunilor acestor componente O arhitectură software este utila in procesul de dezvoltare a unui sistem software: - este deseori primul artefact din proiectare ce rezolva decizii asupra cum sunt indeplinite cerintele sistemului; - este artefactul cheie in obtinerea unui sistem de calitate ce poate fi creat prin reutilizarea componentelor create in procesul de dezvoltare a unor sisteme similare anterioare; - este de obicei primul artefact citit de un programator; - suporta reutilizarea componentelor software, a modelelor de proiectare sau a framework-urilor in care pot fi integrate; - descrie un sistem complex pe un nivel de abstractizare pe care pot fi intelese mai usor deciziile de nivel inalt ale sistemului; - conduce la intelegerea mai buna a cerintelor, gasirea strategiilor de implementare si a riscurilor posibile. ### Principii de proiectare 1. **Principiul de proiectare Cuplare slaba** Cuplarea este o masura a cat de strans un element este legat de, are cunostinte despre sau se bazeaza pe alte elemente. Un element cu o cuplare joasa nu depinde de prea multe elemente. Aceste elemente includ clase, subsisteme, sisteme, etc. O clasa cu o cuplare inalta se bazeaza pe multe alte clase. In general astfel de clase sunt evitate, deoarece pot produce urmatoarele probleme: - modificarea claselor legate determina modificari locale; - sunt mai greu de inteles; - sunt mai greu de reutilizat deoarece necesita prezenta claselor de care este dependenta. In limbajele OO, formele obisnuite de cuplare a doua clase A si B sunt: - A are un atribut de tip B ( A are o asociere ce indica clasa B). - un obiect al clasei A apeleaza servicii ale unui obiect al clasei B (A are o asociere ce indica clasa B sau A are o relatie de dependenta cu B) - A are o operatie ce refera un obiect al clasei B sau a clasei B insasi (A are o relatie de dependenta cu B) - A este o subclasa directa sau indirecta a lui B (A specializeaza B, ie 2. **Principiul de proiectare Coeziune inalta** In termenii proiectarii pe obiecte, coeziunea este o masura a cat de corelate si tind spre acelasi obiective sunt responsabilitatile unei clase. O clasa a carei responsabilitati sunt strans legate intre ele si nu puncteaza prea multe obiective este o clasa cu coeziune inalta. O clasa cu coeziune joasa are multe lucruri nelegate intre ele sau face prea multe. Astfel de clase sunt evitate deoarece produc urmatoareleprobleme: - sunt greu de inteles - sunt greu de reutilizat - sunt greu de intretinut - sunt obiectul modificarilor mult mai des decat celelalte clase ### Stiluri arhitecturale Un stil arhitectural defineste o familie de sisteme in termenii unui sablon de organizare structurala. Un stil arhitectural specifica de obicei: - un vocabular de proiectare, - descrierea semanticii vocabularului si - constrangeri asupra modului in care este folosit acest vocabular. Exemple: - Sisteme call-reply - Sisteme bazate pe evenimente - Sisteme client-server - Sisteme stratificate - A. **Sisteme call-reply** - Datele impreuna cu operatii sunt incapsulate in obiecte sau tipuri abstracte de date - Reprezentarea interna a acestora este inaccesibila altor obiecte - Obiectele comunica prin intermediul apelurilor procedurilor sau functiilor/metode  B. **Sisteme bazate pe evenimente** - componenta poate anunta alte componente de aparitia unuia sau mai multor evenimente. - Celelalte componente se pot inregistra la un timp de evenimente prin asocierea de proceduri sau functii. - Cand un eveniment de acel tip este anuntat, sistemul insusi invoca procedurile, functiile sau metodele componentelor care gestioneaza evenimentul A diagram of a diagram AI-generated content may be incorrect. C. **Sisteme client-server** - Un sistem client-server este format dintr-un numar de procese client si un proces server care coopereaza pentru a realiza o activitate de elaborare a datelor. - Server-ul este o entitate pasiva care asteapta cereri de servicii de la clienti. - Un client este o entitate activa care trimite cereri de servicii catre server. - Clientul si server-ul sunt de obicei pe calculatoare diferite, dar pot rula si pe un acelasi calculator. **Avantaje**: - independenta clientilor si a server-ului pentru ca acestia se cunosc in retea; - faciliteaza modificarea, in sensul ca modificarea unui client nu afecteaza server-ul; - permite controlul strict al resurselor aflate pe server. **Dezavantaj**: trafic intens in retea D. **Sisteme stratificate** - Un sistem stratificat este organizat pe nivele, fiecare nivel furnizand servicii stratului superior si servind ca client pentru stratul inferior. - Interactiunile dintre componente sunt realizate pe baza de protocoale. - De obicei constrangerea este ca interactiunile sa aiba loc numai intre straturile adiacente. Astfel de arhitecturi se numesc inchise. - Intr-o arhitectura deschisa, un strat poate accesa straturi inferioare, indiferent de adancime. E. **Sisteme 2-tier**  F. **Sisteme 3-tier** Contine urmatoarele straturi: - Stratul de logica prezentarii este responsabil cu interactiunea cu utilizatorii - Stratul de logica domeniului ce contine principalele functionalitati ale sistemului - Stratul de logica surselor de date implementeaza comunicarea stratului superior cu baza de date, si poate contine alte aplicatii/subsisteme A diagram of a system AI-generated content may be incorrect. **Stilul architectural MVS** (Model-View-Separation Principle) \- Afirmă că obiectele model (domeniu) nu ar trebui să aibă cunoștințe directe despre obiectele vedere (UI). \- Clasele de domeniu încapsulează informațiile și comportamentul legate de logica aplicației si de functionalitatile ei. Principiul MVS are cel puțin două părți: 1\. Nu cuplați direct obiecte non-UI la obiecte UI. De ce? Deoarece ferestrele sunt legate de o anumită aplicație, în timp ce (în mod ideal) obiectele nonferestre pot fi refolosite în aplicații noi sau atașate la o nouă interfață grafica. 2\. Nu puneți logica aplicației (cum ar fi un calcul al impozitelor) în operatiile unui obiect UI. Obiectele UI ar trebui să inițializeze doar elemente UI, să primească evenimente UI (cum ar fi un clic al mouse-ului pe un buton) și să delege cereri pentru logica aplicației către obiecte non-UI (cum ar fi obiectele de domeniu). În acest context, Model este un sinonim pentru stratul de domeniu al obiectelor. View este un sinonim pentru obiecte UI, cum ar fi ferestre, pagini web, applet-uri, rapoarte si tabele. **Principiile SOLID** 1\. Single responsibility 2\. Open/Closed 3\. Liskov Substitution 4\. Interface Segregation 5\. Dependency inversion 1. **Principiul responsabilitatii unice** A class should have one and only one reason to change, meaning that a class should have only one job.  2. **Principiul Open/Close** Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification (Bertrand Meyer) Mecanisme folosite:. Ascunderea informatiilor · Abstractizare: introducerea interfetelor sau a claselor abstracte Polimorfism dinamic sau static A diagram of a computer AI-generated content may be incorrect. 3. **Principiul Liskov Substitution** If for each object ol of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when ol is substituted for 02 then S is a subtype of T (Barbara Liskov) Sau in termeni de clase: Daca B este o subclasa a lui A, atunci B poate inlocui A oriunde in program unde este folosit A.  4. **Principiul Interface segregation** Many client specific interfaces are better than one general purpose interface. A screenshot of a computer program AI-generated content may be incorrect. 5. **Principiul Inversion of Control** Principiu de proiectare care permite inversarea controlului, prin delegarea acestuia unei alte clase.  6. **Principiul Dependency inversion** Depend upon Abstractions. Do not depend upon concretions. sau \- Modulele de nivel înalt nu trebuie sa depinda de modulele de nivel jos. Ambele trebuie sa depinda de abstractizari. \- Abstractizările nu depind de detalii. Detaliile trebuie sa depinda de abstractizări. A diagram of a computer code AI-generated content may be incorrect. **Principiul DRY (Do not repeat yourself)** Situatii in care apare duplicarea codului: · Dublare impusa. Dezvoltatorii simt ca nu au de ales -- mediul pare sa necesite duplicarea. · Dublare accidentala. Dezvoltatorii nu realizeaza ca dubleaza informatii. · Dublare nerabdatoare. Dezvoltatorii devin comozi si dublează pentru ca li se pare mai usor. · Dublare intre dezvoltatori. Mai multe persoane dintr-o echipa (sau din echipe diferite) dubleaza o informatie. Principiul DRY: Fiecare informatie trebuie sa aiba o singura, neambigua, reprezentare în cadrul unni cictem **Solutii de aplicare a principiului DRY:** · Folosirea unui generator de cod - Documentarea codului - Actualizarea modelelor UML in consens cu codul - Implementarea atributelor derivate cu ajutorul operatiilor - citirea codului sursa si a documentatiei colegilor de echipa, fie informal, fie in timpul revizuirii codului. - Numirea unui bibliotecar al proiectului, a carui sarcina este de a facilita schimbul de cunostinte. CURS 11 ======= Modele de proiectare software ----------------------------- **Model de proiectare** = descriere a obiectelor si claselor care colaboreaza pentru rezolvarea unei probleme generale de proiectare intr-un context particular.\* ​ **Avantaje:​** - reutilizare,​ - cresterea calitatii produsului software,​ - imbunatateste documentatia.​ Structura generala a unui pattern: nume, problema, solutie, consecinte: avantaje si dezavantaje​ **Clasificarea** pattern-urilor data de E. Gamma:​ - Modele pentru atribuirea responsabilitatilor astfel incat sa fie indeplinite cele 2 principii foarte importante ale proiectarii: cuplarea slaba si coeziunea inalta a claselor.​ - Modele de proiectare fundamentale​ - Modele de creare​ - Modele de impartire​ - Modele structurale​ - Modele comportamentale​ - Modele de concurenta​ **Responsabilitati** In UML o responsabilitate este definita ca o **obligatie** a unui clasificator: clasa, pachet sau subsistem.​ ​Responsabilitatile sunt de doua tipuri:​ 1. **A sti (a cunoaste):** stiu datele private, stiu obiectele cu care obiectul respectiv este legat, stiu datele care pot fi calculate sau derivate; ​ 2. **A face**: creeaza alte obiecte, executa un calcul, porneste executia unei actiuni asupra altor obiecte, controleaza/coordoneaza actiunile realizate de obiectele cu care obiectul curent este legat. Modele de proiectare GRASP 1. **M.P. Creator** **Problema**: Cine ar trebui sa fie responsabil pentru crearea unui obiect al unei clase?​ **Solutie:** Atribuim clasei A responsabilitatea de a crea un obiect al unui clase B daca una sau mai multe din urmatoarele afirmatii sunt adevarate:​ - A *contine* obiecte ale lui B ​ - A *agrega* obiecte ale lui B​ - A *inregistreaza* obiecte ale lui B.​ - A *foloseste* obiecte ale lui B.​ - A *are date de initializare* ce vor transmise lui B cand este creat (astfel A este un - Expert in raport cu crearea lui B). ​ In aceste cazuri, spunem ca A este un *creator* al obiectelor lui B.​  2. **M.P. Information Expert (Expert)** **Problema**: Care este principiul general de atribuire a responsabilitatilor obiectelor/claselor?​ **Solutie**: Atribuim o responsabilitate acelei clase care are informatiile necesare indeplinirii ei.​ **Exemplu**. Intr-o aplicatie de gestiune a vanzarilor produselor dintr-un magazin, cine este responsabil cu calcul a costului total al unei vanzari? ​ ​ Dupa pattern-ul Expert, ar trebui sa cautam clasa care are toate informatiile necesare pentru a determina totalul=suma costurilor articolelor cumparate +tva-reducere​ ​ Unde cautam clasa? In modelul de domeniu sau in diagrama de clase a arhitecturii software? ​ Raspunsul este:​ Pas 1. Daca arhitectura software curenta din proiectare contine clase, cautam acolo.​ Pas 2. Altfel, cautam in diagrama de clase a modelului de domeniu si incercam sa cream clase software inspirandu-ne din clasele modelului de domeniu. ​ Ce informatii sunt necesare pentru a calcula costul total al unei vanzari?​ Trebuie sa stim care au fost produsele cumparate, pretul lor unitar si cantitatea cumparata. ​ costArticol=pretUnitarProdus\*cantitate​ A diagram of a function AI-generated content may be incorrect. 3. **M.P. Low Coupling​** **Problema**: Cum realizam arhitectura astfel incat sa avem cat mai putine legaturi de dependenta intre clase, impactul modificarii sa fie mic si gradul de reutilizare sa fie crescut?​ **Solutie:** Alocam o responsabilitate unei clase astfel incat cuplarea sa raman joasa. ​ Varianta 1: urmatoarea diagrama de secventa:​   Varianta 2:  A diagram of a diagram AI-generated content may be incorrect. Se allege varinata 2 4. **M.P. Pure Fabrication (Inventie)​** **Problema**: Ce clasă ar trebui sa aibă o responsabilitate cȃnd nu vrem să încălcăm principiile de proiectare de Coeziune înaltă şi Cuplare slabă?​  Există situații cȃnd atribuirea responsabilitătilor doar claselor care provin din domeniul problemei ar duce la probleme de cuplare înaltă sau de coeziune joasă sau grad de reutilizare mic.​ **Soluție**. Responsabilitatea este atribuită unei clase software artificială pentru a îndeplini principiile de coeziune inalta, cuplare slaba şi reutilizare crescută.​ **Exemplu**. Cine este responsabil cu salvarea datelor din obiectele clasei Vanzare? ​ Conform m.p. Expert este clasa Vanzare, dar în aceste caz, am încălca principiile de coeziune inalta si cuplare slaba.​ **Solutie**. Se creeaza o clasa ManagerVanzare (din domeniul solutie) care sa aiba responsabilitatea gestiunii informatiilor persistente ale obiectelor Vanzare adica memorate pe support persistent (bd si/sau Fisiere) ​   5. **M.P. Indirectare​** **Problema**: Cărei clase atribuim o responsabilitate pentru a evita cuplarea directă între două sau mai multe clase?​ **Solutie**: Atribuim responsabilitatea unei clase intermediar care face legătura între clase.​ Exemplu: Intr-o arhitectură software există mai multe clase ale căror date trebuie să fie memorate pe suport persistent. In acest caz, daca toate clasele au aceleaşi responsabilități, putem face o singură clasă abstracta SuportPersistent.​ Clasa SuportPersistent acţionează ca un intermediar ce face legătura între clasele Manager şi celelalte clase.​ 6. **M.P. Polimorfism​** **Probleme**: ​ 1\. Cum putem crea componente software sau clase reutilizabile? Adica vazand clasele si obiectele in roluri de client/furnizor, se pune problema cum putem inlocui o clasa sau obiect furnizor fara ca obiectul client sa fie afectat?​ 2\. Cum proiectam atunci cand avem comportamente asemanatoare, dar diferite intre ele in functie de tipul (clasa) in care se gaseste? Sau cum proiectam OO o responsabilitate rezolvata in mod diferit in clase diferite? ​ Solutia in proiectarea OO este de a declara comportamentul intr-o interfata sau o clasa abstracta ce va fi realizata/extinsa de clasele care vor realiza (implementa) comportamentul declarat.​ A diagram of a function AI-generated content may be incorrect. ​ 7. **M.P. Controller** **Problema**: Daca un sistem software primeste evenimente externe, cine este responsabil pentru gestiunea acestora?​ **Solutie:** *S*e adauga cate o clasa care decupleaza sursa evenimentelor externe de clasele interne care gestioneaza evenimentul. ​ Regula este de a asocia cate un obiect de control pentru fiecare caz de utilizare, sau daca acesta este complex, adaugam mai multe obiecte de control care impart fluxul de control in parti gestionabile. ​ Un alt criteriu este de a stabili cate un controller pentru fiecare actor software care interactioneaza cu sistemul software.​ 8. **M.P. Singleton** **Problema**: Cum proiectam o clasa astfel incat sa aiba un singur obiect?​ **Solutie:** Clasa A trebuie sa aiba:​ - Constructorul privat​ \- O variabila statica si privata de tip A​ - O metoda statica si publica care furnizeaza acces la unicul obiect al clasei​ public static A getInstanta(){}​ **Avantaj**: asigura ca o clasa are o instanta unica si furnizeaza un punct global de acces la instanta: toate obiectele care utilizeaza o instanta a clasei utilizeaza aceeasi instanta.​ ManagerPermise poate fi proiectat in unul din urmatoarele moduri:​ - Clasa Singleton​ - Clasa utilitara: operatiile ei sunt statice si nu are constructor​ - Clasa obisnuita: cu constructor public, iar operatiile sunt publice ​ CURS 12 ======= **Diagrame de interactiuni** ---------------------------- Sunt de doua tipuri:​ - Diagrame UML de secvente​ - Diagrame UML de comunicare​ **Diagramele UML de secvente** pun accentul pe aspectul comportamental al obiectelor unei colaborari.​ - Comportamentul unei colaborari este aratat printr-o multime de obiecte care comunica intre ele prin trimiterea mesajelor intre ele.​ **Diagramele UML de comunicare** pun accentul pe aspectul static al unei colaborari.​ 1. **Diagrame UML de secvente** Modelele folosite in construirea unei diagrame UML de secvente:​ - Descrierea cazului de utilizare pe care il proiectam​ - Diagrama UML de clase a domeniului ​ - Diagrama UML de secvente de sistem a c.u. proiectat​ - Stilul de proiectare aplicat: MVC, etc​ - Modele de proiectare GRASP si altele​ Cand o2 primeşte un mesaj, el poate trimite un alt mesaj următoarelor obiecte:​ - unui parametru de tip Clasa sau Interfata al mesajului unMesaj​ - obiectului o2​ - unui atribut extrinsec al obiectului o2​ - unui element al unei colecţii referite de un atribut al obiectului o2​ - unui obiect ce va fi creat cand este primit mesajul 1.​ Exemplu   2. **Diagrame UML de comunicare** **Concept** **Sintaxa concreta** ----------------- -------------------------- Obiect   Legatura (link) Mesaj   Autolegatura   **Diagramele UML de clase** --------------------------- Diagramele UML de clase fac parte din arhitectura software a sistemului software​ - Elementele continute de o diagrama UML de clase de proiectare:​ - Clase cu atribute si operatii​ - Interfete cu constante si operatii​ - Relatii intre clase sau intre clase si interfete​ Obs. Relatiile de asociere dintre clase au directie de cunoastere/navigare​ - Pe baza diagramelor UML de secvente/comunicare putem crea diagrame UML ale claselor de proiectare, urmând regulile:​ - Daca un obiect apare in diagrama de secvente, atunci clasa din care face parte va aparea in diagrama de clase de proiectare​ - Mesajele sunt transformate in operatii ale obiectelor destinatar​ - Mesajele create arata relatii de asociere intre clasele expeditor si destinatar​ - Daca un mesaj are un parametru de tip o alta clasa, arata o dependenta intre clasa destinatar al mesajului si clasa ce denota tipul parametrului​ - Daca un mesaj are un rezultat de tip o alta clasa, arata o dependenta intre clasa expeditor al mesajului si clasa ce denota tipul rezultatului​ Exemplu   **Masini UML de stari** -----------------------   **Concept** **Semantica** ------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- *Tranzitie* Reprezinta o cale potentiala intre starile din istoria unui obiect, cat si actiunile realizate in starea modificata. Defineste raspunsul obiectului din starea sursa la aparitia unui eveniment trigger. In general, o tranzitie are o stare sursa, un eveniment trigger, o conditie garda (guard), o actiune si o stare destinatie. Tipuri de tranzitii: tranzitii externe, interne, de terminare. *Actiune* Este un calcul atomic ce poate afecta obiectul de care apartine masina de stari si care are loc pe o tranzitie sau intr-o stare. Daca suntem in ultimul caz, este vorba de o actiune executata la intrarea in stare (*entry/*) sau in timpul in care obiectul se afla in starea respectiva (*do/*) sau cand obiectul paraseste starea respectiva (*exit/*). Tipuri de actiuni: de atribuire (*target:=exp*), apel (*numeop(arg, arg)*), creare (*new numeC(arg,arg)*), distrugere (*obiect.destroy()*), de returnare (*return valoare*), de trimitere a unui semnal (*numeS(arg, arg)*), de distrugere a obiectului curent (*terminate*). *Conditie* Este o expresie logica evaluata o singura data, anume in momentul aparitiei un eveniment trigger. Daca expresia este adevarata, atunci are loc tranzitia pe care se afla conditia respectiva. Conditia poate referi aribute ale obiectului curent si parametri ai evenimentului trigger. Exista doua categorii de obiecte:​ - Obiecte cu comportamente independente de stare​ - Obiecte cu comportamente dependente de stare​ ​ Exemple de obiecte cu comportamente dependente de stare: ​ - Sistem​ - Controller ​ - Tranzactii: Inchiriere,Vanzare, Comanda, Plata​ - Ferestre -- numai daca adauga/elimina in mod dinamic componente grafice​ - Dispozitive fizice controlate de software: mobile phone, etc ​ - Roluri ale obiectelor claselor​ Masinile de stari sunt construite pentru obiecte cu comportamente complexe dependente de stare.​ Masinile de stari pot fi construite si pentru obiectele unei colaborari. ​ **Stari paralele**  A diagram of a computer AI-generated content may be incorrect.