Curs MPA - Management Proceselor de Afaceri PDF

Curs 1 1  În contextul globalizării managementul proceselor de afaceri - BPM a devenit foarte important pentru toate organizaţiile care doresc să atingă următoarele obiective:  crească numărul comenzilor;  crească viteza de transfer a datelor;  crească...

Curs 1 1  În contextul globalizării managementul proceselor de afaceri - BPM a devenit foarte important pentru toate organizaţiile care doresc să atingă următoarele obiective:  crească numărul comenzilor;  crească viteza de transfer a datelor;  crească viteza de luare a deciziilor;  adapteze rapid cerea şi oferta de produse şi  să asigure competitivitate pe piaţa internaţională. 2  Un proces de afaceri poate fi definit ca un set de activităţi sau sub-procese şi tranzacţii secvenţiale sau paralele, logic relaţionate menite să producă un anumit rezultat (output).  Definiţia BPM oferită de cercetători este următoarea: „asigurarea unui suport eficient pentru procesele de afaceri utilizând metode, tehnici şi software, pentru proiectarea, controlul şi analiza proceselor care implică oameni, organizaţii, aplicaţii, documente şi alte surse de informaţie”. 3  Process Designer care permite unui utilizator instruit să analizeze și să modeleze un proces pas cu pas și să îi confere o logică;  Process Engine care execută fluxul procesului și asignează activități manuale utilizatorilor și activități automatizate către aplicații în timpul execuției;  Rules Engine care realizează managementul fluxului de informații și activități dintr-un proces în conformitate cu regulile și formulele atașate acestuia și  Process Analytics care furnizează un feedback continuu asupra procesului pentru ca în viitor să se poată aduce îmbunătățiri acestuia. 4  Knowledge management care oferă utilizatorilor posibilitatea de a partaja activități, conținut, documente și notificări via comunități;  Document management care oferă un sistem pentru stocarea și securizarea documentelor electronice, imagini sau alte fișiere;  Collaborative Tools care înlătură barierele în comunicația intra/inter departamente prin intermediul forumurilor, spațiilor de lucru dinamice, etc.;  Business Analytics care permite managerilor să identifice problemele de afaceri, trend-uri și oportunități și să le coreleze cu rapoartele existente și  Work Portal care oferă utilizatorilor un spațiu de lucru productiv pentru managementul activităților, conținutului, formularelor, documentelor, notificărilor, etc. 5  Expertiză și experiență – focalizare pe dobândirea de aptitudini centrate pe proces, intruire, educație, certificare, cercetare, perspicacitate în afaceri și capital intelectual  Discipline organizaționale – adoptarea de noi și îmbunătățite culturi, structuri, roluri, responsabilități, politici, reguli și proceduri  Management și audit – îmbunătățirea proceselor prin definire, modelarea, simulare, execuție, monitorizare, analiză și optimizare  Parteneriate și servicii – suport din partea partenerilor pentru consultanță, implementare,etc. 6  BPMN sau notația BPM a fost dezvoltată de către BPMI pentru a furniza un set de elemente grafice care poate fi înțeleasă cu ușurință de către proiectanți, utilizatori, analiști,etc.  Business process model – BPMN definește un model ca un set de elemente grafice sau activități și fluxuri care definesc ordinea lor de desfășurare.  Cloud BPM presupune lansarea tehnologiilor BPM în cloud pentru modelare și execuția proceselor.  Mobile BPM presupune abilitatea de a accesa aplicații BPM via smatphone, tablete sau alte dispozitive mobile.  Social BPM referă posibilitatea de a utiliza colaborarea socială în contextul proceselor de afaceri.  Un glosar de termeni la adresa web  http://www.appian.com/bpmbasics/bpmintro.jsp 7 8 9  Faza din ciclul de viaţă WfM BPM BPM Proiectarea proceselor Există Există Configurarea sistemului Există Există Implementarea proceselor Există Există Diagnoză Punct slab Există 10 11 12 13 14 15 16 17  În continuare voi încerca să:  discut terminologia asociată cu BPM şi standardele acestuia;  clasifica sistematic standardele BPM;  discuta punctele tari şi punctele slabe ale fiecărui standard;  clarifica diferenţele teoretice care stau la baza celor mai importante standarde BPM şi  explora lacunele existente în standardele BPM actuale şi cum acestea pot fi depăşite. 18 Inițierea Dezvoltarea Ratificarea Adopția Difuzia Sisteme BPM Standarde și specificații BPM Teoria BPM 19  Proiectarea proceselor Configurarea Diagnoză sistemului Implementarea proceselor 20 21  Start Proces de afaceri sau Serviciu web serviciu web? Proces de afaceri Standard SOA Standard pentru procese de afaceri Public sau Public privat? Privat Standard B2B Standard BPM Care este faza din ciclul de Proiectarea BP Monitorizarea BP viață BPM? Automatizarea BP Proiectarea Implementarea Diagnoza proceselor proceselor proceselor Standard pentru Model bazat pe Translatare sau diagnoză diagrame? automatizare? Translatare Diagrame Automatizare Text Standard grafic Standard pentru Standard pentru execuție portabilitate 22 Denumire BPM/SOA/B2B? Iniţiat de Tip standard Standardizat Status către deja? BPDM BPM Industrie Portabilitate Da Nefinalizat BPEL BPM Industrie Execuţie Da Popular BPML BPM Industrie Execuţie Da Depăşit BPQL BPM Industrie Diagnoză Da Nefinalizat BPRI BPM Industrie Diagnoză Da Nefinalizat ebXML B2B Industrie B2B pentru Da Popular BPSS portabilitate EDI B2B Industrie B2B pentru Da Stabil portabilitate BPM Academic Grafic Nu Moştenit Petri Net Toate Academic Teorie/ NA Popular Grafic Pi- Toate Academic Teorie/ NA Popular Calculus Execuţie Rosetta- B2B Industrie B2B pentru Da Popular Net portabilitate 23 Denumire BPM/SOA/B2B? Iniţiat de Tip standard Standardizat Status către deja? UBL B2B Industrie B2B pentru Da Stabil portabilitate UML AD BPM Industrie Grafic Da Popular SOA Industrie Execuţie Da Depăşit WSCL SOA Industrie Execuţie Da Depăşit WS- SOA Industrie Execuţie Da Popular WSFL BPM Industrie Execuţie Nu Depăşit XLANG BPM Industrie Execuţie Nu Depăşit XPDL BPM Industrie Execuţie/ Da Stabil Portabilitate YAWL BPM Academi Grafic/ Nu Stabil c Execuţie 24  Standarde grafice BPM, UML AD Standarde pentru Standarde pentru portabilitate diagnoză XPDL, BPDM BPRI, BPQL Standarde pentru execuție BPEL, BPML,WSFL, XLANG Faza de proiectare și implementare Faza de diagnoză 25  UML (Unified Modelling Language )  BPMN (Business Process Model and Notation)  Alte tehnici:  EPC (Event-driven Process Chains)  RAD (Role Activity Diagram) 26  Solicitant Referent/Consilier SVC Depune dosar la SVC Inregistreaza in aplicatia software date referitoate la cererea solicitantului Atribuie un numar de verificare dosarului Completeaza: Fisa pentru fluxul operatiunilor si observatii Verifica daca dosarul este complet si corect Listeaza din aplicatia software: Fisa verificare dosar F01 fara observatii [dosar complet] [dosar incomplet] Adauga la dosar Solutioneaza documente aditionale dosar incomplet [dosar incomplet [dosar respins] admis] Completeaza Completeaza F01 cu retur F01 cu observatii Retrage dosar Verificare calitate de student a solicitantului 27 28  Diferenţele dintre UML AD şi BPMN BPD sunt:  de terminologie;  BPMN BPD utilizează mai puţine obiecte pentru a modela procese complexe;  UML AD solicită cunoştinţe tehnice analiştilor. 29 30  Pregătit să aleagă metoda de plată Nume rol Plătește cu card de Acțiune credit Plătește cu CEC Interacțiune I E A Furnizează detalii Start rol nou card de credit Scrie Descriere CEC stare Administrare flux proces Declanșator Postează Decizii formular Așteaptă produs 31  BPML (Business Process Modelling Language)  XLANG (Web Services for Business Process Design)  WSFL (Web Services Flow Language)  BPEL (Business Process Execution Language) 32  WSFL Prima versiune A doua versiune BPEL4WS Adăugare WS-BPEL Consolidare extensii XLANG BPEL este un limbaj bazat pe XML prin intermediul căruia putem defini procese de afaceri prin utilizarea serviciilor web şi care poate servi ca un limbaj de execuţie (procese executabile) şi ca un limbaj de descriere (procese abstracte). 33  Avantajele BPEL sunt :  cel mai popular  nu se concentrează pe programarea propriu-zisă ceea ce facilitează semnificativ modelarea proceselor şi micşorează şi numărul liniilor de cod;  adoptă paradigma serviilor web; BPEL prezintă următoarele limitări :  prezintă o sintaxă complexă dificil de implementat;  Sintaxa este restrictivă ceea ce cauzează numeroase probleme la translatarea BPMN-BPEL;  BPEL este restrictiv în modelarea comportamentului uman în cadrul proceselor;  BPEL nu oferă suport pentru toate construcţiile posibile de procese;  BPEL nu oferă suport B2B. 34  standardele grafice sunt orientate-graf standardele de execuţie sunt orientate-bloc nevoia de standarde pentru portabilitate care să asigure translatarea:  Business Process Definition Metamodel (BPDM) creat de OMG complex şi neprietenos  XML Process Definition Language (XPDL) creat de WfMC popular 35  Diferenţa esenţială între WM şi BPM rezidă în etapa de diagnoză din ciclul de viaţă BPM. Standardele pentru diagnoză monitorizează şi optimizează BP din BPMS. Exemple de standarde pentru diagnoză:  Business Process Runtime Interface (BPRI)  Business Process Query Language (BPQL) 36  [Ambler, 2004] Ambler Scott, The Object Primer: Agile Model Driven Development with UML 2.0,Cambridge University Press, Cambridge, 2004.  [ArisCommunity, 2013] Learn how to model BPMN diagrams in ARIS Express http://www.ariscommunity.com/videos/learn-how-model-bpmn-diagrams-aris-express, accesat în data de 11 martie 2013.  [AuraPortal, 2012] User Guide BPM Modeler Java, www.AuraPortal.com  [BPM Offensive, 2011] BPMN 2.0 Business Process Model and Notation poster, accesat în data de 13 februarie 2013, http://www.bpmb.de/images/BPMN2_0_Poster_EN.pdf  [Dumas M., ter Hofstede A.H.M., 2001] Marlon Dumas, Arthur H.M. ter Hofstede, „UML activity diagrams as a workflow specification language”, UML 2001: 4th International Conference on the Unified Modeling Language: Modeling Languages, Concepts, and Tools, Toronto, pp. 76-90, 2001.  [Gartner, 2010] Magic Quadrant for Business Process Management Suites, http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/enterprise/pdfs/magic-quadrant-for- business-process-management-suites.pdf accesat în data de 13 februarie 2013.  [Russell N., van der Aalst W.M.P., ter Hofstede A.H.M., Wohed P. 2006] Russell N., van der Aalst W.M.P., ter Hofstede A.H.M., Wohed P., „On the suitability of UML 2.0 activity diagrams for business process modeling”, Proceedings of the 3rd Asia-Pacific Conference on Conceptual Modelling, Vol. 53, pp. 95-104, 2006.  [Ryan K.L. Ko et al., 2009] Ryan K.L. Ko, Stephen S.G. Lee, Eng Wah Lee, „Business process management (BPM) standards: a survey”, Business Process Management Journal, Vol. 15, No. 5, pp. 744-791, 2009.  [Silver, 2010] Bruce Silver, Jump start your BPM program with standard-based process modeling, Industry Trend reports, 2010.  [van der Aalst et al., 2003] van der Aalst, W.M.P., ter Hofstede, A.H.M. and Weske, M. (2003), „Business process management: a survey”, Proceedings of the International Conference on Business Process Management, BPM 2003, Eindhoven, The Netherlands, 26-27 June 2003.  [Venter, 2010] Etienne Venter, BPMN starter guide: Which process type to use?, http://www.ariscommunity.com/users/etienne/2010-08-27-bpmn-starter-guide-which-process-type-use, accesat în data de 26 februarie 2013,  [White S., 2004] White Stephen, „Process modeling notations and workflow patterns”, Workflow Handbook, Future Strategies, Lighthouse Point, FL, pp. 265-294, 2004.  [Muehlen, 2007] Michael zur Muehlen, „Business Process Management Standards, Origin, Overview and Directions”, Howe Scholl of Technology Management, Stevens Institute of Technology, Hoboken NJ, http://www.slideshare.net/mzurmuehlen/business-process-management-standards-tutorial?from_search=1 , accesat în data de 30 septembrie 2013.  [Appian, 2013] Appian Learning Center, Introduction to BPM, http://www.appian.com/bpmbasics/bpmintro.jsp, accesat în data de 2 octombrie 2013.  [Odeh et.al , 2002] M. Odeh, I. Beeson, S. Green and J. Sa, Modelling Processes Using RAD and UML Activity Diagrams: an Exploratory Study, Systems Modelling Research Group, ACIT 2002, http://www.cems.uwe.ac.uk/~sjgreen/RAD&AD_V2.pdf, accesat în data de 3 octombrie 2013.  [Brennan, 2006] Kevin Brennan, RAD Stencil, 2006, https://www.graffletopia.com/stencils/140, accesat în data 37 de 3 octombrie 2013. 38 Standarde grafice:UML Curs 2 1  UML (Unified Modeling Language) este un limbaj vizual de modelare, el nu este încă un limbaj vizual de programare, deoarece nu dispune de întreg sprijinul semantic şi vizual pentru a înlocui limbajele de programare.  Limbajul este destinat vizualizării, specificării, construirii şi documentării sistemelor de aplicaţii, dar are limitări în ceea ce priveşte generarea codului. UML reuneşte cele mai bune tehnici şi practici din domeniul ingineriei programării, care şi-au dovedit eficienţa în construirea sistemelor complexe. 2  În octombrie 1994 se formează echipa Grady Booch - James Rumbaugh  În octombrie 1995 se lansează Metoda Unificată  În decembrie 1995 prima documentație a Metodei Unificate cu versiunea 0.8. Se alătură echipei și Ivar Jacobson. 3  În iunie 1996 apare versiunea 0.9 iar Metoda Unificată (Unified Method) devine Limbajul Unificat de modelare (Unified modeling language)  În octombrie1996 apare versiunea 0.91. Jacobson aduce îmbunătățiri semnificative conceptului de caz de utilizare, sunt explicate detaliat anumite noțiuni și se modifică denumirile unor diagrame. 4  În ianuarie 1997 este prezentată versiunea 1.0 cu documentație mult mai detaliată trimisă spre standardizare  În septembrie 1997 se propune versiunea 1.1. ca urmare a introducerii de către două firme competitoare a limbajului OCL folosit pentru descrierea regulilor de corectitudine ale metamodelului UML.  În noiembrie 1997 OMG a anunțat adoptarea specificației UML ca limbaj standard de modelare. 5  Schimbarea denumirii din Metoda Unificată în Limbaj de Modelare Unificat a fost justificată prin: ◦ reacţiile primite din partea utilizatorilor care au sugerat că este mult mai important să se acorde o atenţie sporită conceptelor utilizate în dezvoltarea aplicaţiilor; ◦ faptul că eforturile de unificare au fost concentrate asupra limbajului grafic de modelare, asupra semanticii lui şi abia după aceea asupra modului de utilizare a conceptelor și ◦ UML a fost conceput ca un limbaj universal care să fie utilizat la modelarea sistemelor.  Sublinierea aspectelor de limbaj nu semnifică nicidecum ignorarea modului de folosire a lor. UML presupune că metodologia este “ghidată” de cazurile de utilizare, că ea se bazează pe arhitectura sistemului, iar procesul de aplicare a metodologiei este iterativ şi incremental.  UML nu tratează aspecte de metodologie, permitând astfel separarea limbajului de modelare de procesul aplicării metodologiei. 6  Vederi (views)  Diagrame  Elemente de modelare  Mecanisme generale 7  Un sistem poate fi descris luând în considerare diferite aspecte:  - Funcţional: este descrisă structura statică şi comportamentul dinamic al sistemului;  - Non-funcţional: necesarul de timp pentru dezvoltarea sistemului și  - Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod. 8 9  Diagramele sunt grafuri care prezintă simboluri ale elementelor de modelare (model element) aranjate astfel încât să ilustreze o anumită parte sau un anumit aspect al sistemului. 10 11 12 13 14 15 16 17 18 19 20 21 1. http://etutorials.org/Programming/UML/ 2. http://www.agilemodeling.com/artifacts/classD iagram.htm 3. http://stst.elia.pub.ro 4. UML weekend crash course, Thomas Pender, WileyPublishing Incorporated, 2002, NY 5. http://msdn.microsoft.com/en- us/library/vstudio/dd409445.aspx 6. http://pic.dhe.ibm.com/infocenter/rsarthlp/v8 /index.jsp 22 23  Curs 3 Elemente de modelare UML Modelarea cazurilor de utilizare 1  Un element de modelare are o semantică, o definiţie formală a elementului sau un înţeles exact a ceea ce reprezintă el într-un anumit context şi o reprezentare grafică sau un simbol grafic cu care se reprezintă în cadrul diagramelor. 2 A modela cu UML înseamnă a construi mai multe modele pentru diferitele faze ale dezvoltării: 1.faza de analiză 2. faza de design 3.faza de implementare 3 4  În această fază de modelare sistemul este văzut ca o “cutie neagră”, care trebuie să poată realiza anumite sarcini, fără a ne interesa cum le face, cum vor fi implementate, sau cum lucrează intern.  Scopul principal al construirii acestui tip de diagramă este: ◦ Să decidă şi să descrie cerinţele funcţionale ale sistemului ◦ Să ofere o descriere clară şi consistentă a ce va trebui să facă sistemul ◦ Să constituie o bază pentru realizarea testelor de verificare ◦ Să permită o transformare uşoară a cerinţelor funcţionale în viitoare clase şi operaţii. 5 Un model use case este descris folosind una sau mai multe diagrame use case. Acestea conţin următoarele elemente de modelare: actori, cazuri de utilizare și relaţii între aceste elemente: generalizare, asociere, dependenţă. 6  Un actor poate fi orice sau oricine interacţionează cu sistemul, adică trimite sau recepţionează mesaje de la sistem sau schimbă informaţii cu acesta.  Actorul joacă un rol în cadrul sistemului, nu este un utilizator individual al acestuia, prin urmare reprezintă un tip (o clasă) nu o instanţă.  Exemplu “Studentul Popescu vrea să împrumute o carte de la bibliotecă”, rolul lui este de abonat al bibliotecii. Orice mesaj trimite actorul sistemului este un caz de utilizare, câteodată numit şi stimul. 7 Un actor poate fi: 1. Actor primar 2. Actor secundar O altă clasificare ar fi în: 1. Actori activi, 2. Actori pasivi 8  Putem utiliza următoarele întrebări: 1. Cine va folosi funcţionalitatea principală a sistemului (aceştia vor fi actorii principali)? 2. Cine va avea nevoie de sistem în munca de zi cu zi? 3. Cine va administra şi ţine în stare de funcţionare sistemul (aceştia vor fi actorii secundari)? 4. Ce unităţi (device-uri) hardware vor avea nevoie de sistem? 5. Cu ce alte sisteme va interacţiona? Aceste pot fi împărţite în sisteme (sisteme de calculatoare, aplicaţii) care vor iniţia un contact cu sistemul sau sisteme pe care acesta le va contacta. 6. Cine este interesat de rezultatele (valorile) generate de sistem? 9 Un caz de utilizare în UML este definit ca: “un set de secvenţe de acţiuni pe care sistemul le realizează pentru a furniza o valoare unui actor particular”. Caracteristicile cazurilor de utilizare sunt: 1. Un caz de utilizare este iniţiat întotdeauna de un actor; actorul trebuie să ceară direct sau indirect sistemului realizarea unui caz de utilizare; 2. Un caz de utilizare furnizează o valoare unui actor; 3. Un caz de utilizare trebuie să fie complet. Un caz de utilizare este o clasă nu o instanţă a acesteia. Cazurile de utilizare sunt conectate cu actorii prin asocieri, numite şi asocieri de comunicare. 10  Procesul de identificare a cazurilor de utilizare începe de la actorii deja identificaţi. Pentru fiecare actor se vor pune următoarele întrebări: 1. Care sunt funcţiile pe care actorul le aşteaptă de la sistem? Ce trebuie să poată face actorul? 2. Are nevoie actorul să citească, să creeze, să modifice, să distrugă sau să pastreze anumite tipuri de informaţii în sistem? 3. Trebuie să ştie actorul de apariţia unui anumit eveniment în sistem? Ce funcţionalitate reprezintă aceste evenimente? 4. Poate actorul să-şi simplifice munca de zi cu zi sau să lucreze mai eficient folosind funcţii noi ale sistemului? Sau alte întrebări care nu presupun un actor curent: 1. Ce intrări/ieşiri sunt necesare în sistem? De unde vin acestea şi unde merg? 2. Care sunt problemele majore în implementarea curentă a acestui sistem? Poate fi înlocuit un sistem manual cu unul automat? 11 12  Relaţia de extindere(extend)  Relaţia de incluziune(include)  Relația de generalizare 13 14 15 16 17  Descrierea va conţine: 1. Obiectivele cazurilor de utilizare; 2. Cum este iniţiat un caz de utilizare? Ce actori iniţiază execuţia şi în ce situaţii? 3. Care este fluxul de mesaje între actori şi cazurile de utilizare; 4. Fluxul alternativ în cazurile de utilizare; Un caz de utilizare poate să aibă o execuţie alternativă în funcţie de anumite condiţii sau excepţii; 5. Când un caz de utilizare este considerat terminat, şi care va fi valoarea transmisă actorului; 18  Întrebările care vor trebui puse în această fază sunt: 1. Toţi actorii implicaţi comunică cu cazuri de utilizare? 2. Sunt asemănări între actori, poate fi descrisă o clasă actor de bază? 3. Sunt asemănări între cazurile de utilizare existente? Există un flux comun de activitaţi care să poată fi descris ca o relaţie de utilizare a unui caz de utilizare? 4. Există cazuri de utilizare care să poată fi descrise ca extend-uri? 5. Sunt actori sau cazuri de utilizare fără asocieri de comunicare? Dacă există aşa ceva este greşit! 6. Sunt cerinţe funcţionale încă necuprinse în cazuri de utilizare? Dacă da, vor trebui rezolvate. 19 1. http://etutorials.org/Programming/UML/ 2. http://www.agilemodeling.com/artifacts/classD iagram.htm 3. http://stst.elia.pub.ro 4. UML weekend crash course, Thomas Pender, WileyPublishing Incorporated, 2002, NY 5. http://msdn.microsoft.com/en- us/library/vstudio/dd409427.aspx 6. http://pic.dhe.ibm.com/infocenter/rsarthlp/v8 /index.jsp 20 21  Curs 5 Clase, obiecte și relațiile lor 1  Un obiect este o entitate despre care putem vorbi şi pe care o putem gestiona.  O clasă este o descriere a proprietăţilor şi comportamentului unui tip obiect. Nume clasă Atribute Operații 2  Diagrama claselor furnizează o descriere statică a sistemului în termeni de clase și relațiile dintre acestea 3  Pentru identificarea claselor unui sistem putem să ne folosim de următoarele întrebări: 1. Avem informaţii care trebuiesc stocate sau analizate? Dacă da, ele sunt posibile candidate pentru o clasă. 2. Avem sisteme externe cu care va comunica sistemul ce-l construim? Dacă da, este normal să le luăm în considerare când modelam sistemul. 3. Avem biblioteci sau componente din proiecte anterioare pe care putem şi dorim să le folosim? În caz afirmativ acestea conţin clase candidate. 4. Sunt dispozitive în sistem care vor trebui gestionate? Orice dispozitiv conectat la sistem înseamnă o clasă candidat care sa-l gestioneze. 5. Avem părţi organizaţionale în sistem? Vom avea nevoie de clase în care să le implementăm. 6. Care sunt rolurile pe care actorii le joacă în sistem? Acestea pot fi văzute ca şi clase, de exemplu utilizator, client. 4 Atributele capturează informaţia care descrie şi identifică o instanţă specifică a unei clase şi au: ◦ Tip, de exemplu:integer ◦ Grad de vizibilitate: de exemplu public ◦ Sintaxa următoare: vizibilitate nume:tip_expresie=valoare_iniţială {lista de proprietăți} Asigurare Nume clasă +data:Date=data curentă Atribute +client:String Operații -administrator:String=“Nespecificat” -număr de asigurări=neplătit{neplătit,plătit} 5 public class Asigurare { public Date data = new Date(); public String client; private String administrator = new String (“Nespecificat”); static private int număr_de_asigurari = 0; public Stare starea = new Stare (“neplătit”); // constructorul care va fi apelat de fiecare dată când obiectul este //creat public Asigurare () { // alte iniţializări numar_de_asigurări ++; // incrementare pentru atributul de //clasă } // Alte metode }; 6  Operaţiile sunt folosite pentru manipularea atributelor sau pentru realizarea anumitor acţiuni.  O operație are: ◦ o semnătură ◦ un grad de vizibilitate ◦ O sintaxă formală: vizibilitate nume (lista_parametrii) : tip_rezultat {sir_de_proprietaţi}  Mulţimea operaţiilor unei clase descriu funcţionalitatea clasei respective, ce servicii oferă, aşadar pot fi văzute ca o interfaţă a clasei. Titlu carte -titlu:String -autor:String -isbn:String +titlu() +găseșteDupăNume():TitluCarte +găseșteDupăAutor():TitluCarte 7 Relaţiile dintre clase pot fi:  asocieri,  generalizări,  dependenţe sau  relaţii de rafinare. 8   Asocierea normală. Se citește Un copil folosește un calculator  Asocierea normală. Se citește O persoană are una sau mai multe maşini, şi o maşină aparţine unei persoane 9 O reţea ce conţine mai multe noduri, fiecare conectat la altul 10 O persoană poate juca rolul de “şofer” şi o maşină rolul de “maşină a firmei”. Rolurile sunt contexte în care acţionează obiectele. O maşină poate juca un alt rol într-un alt context, de exemplu poate fi maşină de poliţie, ambulanţă… Un soţ este căsătorit cu o soţie. Atât soţul cât şi soţia sunt persoane. Dacă o persoană nu este căsătorită, nu va putea juca rolul de “soţ” sau de “soţie”, ceea ce înseamnă ca această asociere nu se poate aplica. 11 O clasă poate juca roluri diferite în asocieri diferite. Aici persoana poate juca rolul de soţ, soţie sau asigurat. Compania joacă rolul de asigurator. O companie (asiguratorul) poate avea mai multe contracte de asigurare, fiecare contract va fi încheiat cu o persoana căsătorită. Un contract presupune cel mult o poliţă de asigurare. 12  Calificatorul precizează că în conexiune cu o Comandă există o Linie de comandă pentru fiecare instanță a Produsului. Conceptual înseamnă că nu pot exista două Linii de comandă pentru același Produs în aceiași Comandă. 13 O asociere-or arată că numai una dintre asocieri este validă la un moment dat. 14  Se utilizează componenta Constraint 15  O asociere ternală se reprezintă printr-un romb, dar nu va avea calificatori şi agregare. 16  O flotă are mai multe nave; se poate renunţa la unele sau se pot aduce nave noi. Agregare partajată- O echipă este compusă din mai mulţi membrii, iar o persoană poate fi membru în mai multe echipe. 17 O fereastră poate să conţină mai multe meniuri, butoane, liste sau texte. 18  O relaţie taxonomică între un element mai general şi un element specific. Elementul specific trebuie să fie complet inclus în elementul general, care în plus poate conţine informaţii suplimentare. În locul unei instanțe a elementului general poate fi folosită o instanță a elementului specific”. 19 O persoană conduce vehicule. Operaţia este specifică fiecărui tip de vehicul şi este implementată efectiv în fiecare din clasele care moştenesc clasa Vehicul. 20 1. Generalizarea suprapusă (Overlapping Generalization) 2. Generalizarea desparţită (Disjoint Generalization) 3. Generalizarea completă 4. Generalizarea incompletă 21 O dependenţă “friend” este una în care un element model oferă altuia un acces special la structura sa internă. Notația marchează un stereotip ce identifică tipul de dependență. 22  Dependență de utilizare  Dependență de conexiune  Dependență de trasare  Dependență de rafinare 23  Regulile pot fi ataşate oricărui element de modelare, dar sunt utile în special pentru atribute, asocieri, moşteniri sau constrângeri de timp în modele dinamice. Toate regulile vor fi prinse între acolade. 24 Relaţiile de asociere pot fi şi ele derivate; de exemplu, dacă o companie are contracte cu mai mulţi clienţi şi câțiva dintre ei sunt considerați mai importanţi (VIP), avem o asociere derivată care leagă clasa companie la clasa client. 25 Asocierea lider de partid este un subset al asocierii membru al. 26 Clasa A implementează interfeţele Runnable şi Storable. Clasa C implementează interfaţa Runable. Clasa B foloseşte interfeţele Runnable şi Storable din A şi interfaţa Runnable din C. Interfeţele sunt specificate ca şi clase cu stereotipul şi conţin operaţii abstracte care vor trebui implementate de clasele care le implementează. 27 Subsistemul E este dependent de subsistemul B, subsistemul C este dependent de subsistemele B şi D. Subsistemele B,C şi E sunt în subsistemul A. Toate subsistemele sunt reprezentate ca pachete. Subsistemele D şi E sunt specializări ale subsistemului C. Subsistemele B, C, D şi E sunt în subsistemul A. SubsistemuL C depinde de B (are Importate elemente din el). 28  Pachetul X conţine clasele P şi S. Pachetul A are o interfaţă I. Clasa S , din interiorul pachetului X este dependentă de interfaţa I a pachetului A. 29 1. http://etutorials.org/Programming/UML/ 2. http://www.agilemodeling.com/artifacts/cla ssDiagram.htm 3. http://stst.elia.pub.ro 4. UML weekend crash course, Thomas Pender, WileyPublishing Incorporated, 2002, NY 5. http://msdn.microsoft.com/en- us/library/vstudio/dd409437.aspx 6. http://pic.dhe.ibm.com/infocenter/rsarthlp /v8/index.jsp 30 31  Curs 5 Modelarea dinamică 1  Diagrama de stare  Diagrama de secvență  Diagrama de colaborare  Diagrama de activitate 2  Interacțiunea între obiecte se realizează prin intermediul mesajelor: ◦ Simple ◦ Sincrone ◦ Asincrone 3 Diagramele de stare au rolul de a captura ciclul de viaţă al obiectelor, subsistemelor şi sistemelor, prin specificarea stărilor în care se poate găsi un obiect şi a evenimentelor (mesaje primite, erori, condiţii care devin adevărate) care îi afectează starea de-a lungul execuției. 4  O diagramă de stare indică punctul de start (crearea obiectului) și punctul de stop (distrugerea obiectului). O stare se reprezintă printr-un dreptunghi cu colţurile rotunjite. Orice obiect are o stare care se modifică la apariția unui eveniment. Există două dimensiuni ale dinamicii: 1. interacţiunea cu obiectul şi 2. modificările survenite în starea lui internă 5  Pentru definirea unei stări pe lângă pentru numele stării se pot preciza variabile (atribute) iar câteodată este utilă folosirea unor variabile temporare unde vor fi specificate evenimente sau acțiuni.  Sunt trei tipuri de evenimente standard care pot fi folosite pentru precizarea activității: ◦ Entry ◦ Exit ◦ Do  Sintaxa formală pentru construcțiile care apar în compartimentul de activitate este: nume_eveniment lista_argumente / expresie_acțiune 6  Un eveniment are ataşat o stare tranzacțională care va fi realizată când se declanşează evenimentul respectiv.  Sintaxa formală de specificare a unei stări de tranziţie este: ◦ semnătură_eveniment [condiție_de_gardă ] / expresie_acțiune ^ clauza_de_trimitere Unde: ◦ semnătură_eveniment are sintaxa:  nume_eveniment ( parametru , …) ◦ iar clauza de trimitere este de forma:  expresie_destinație. nume_eveniment_destinație ( argument , …) 7 Un eveniment este ceva ce se întâmplă şi poate cauza o anumită acțiune, de exemplu apăsăm butonul în lift (eveniment) şi liftul urcă (acţiune). În UML există următoarele tipuri de evenimente: 1.O condiţie devine adevărată; 2.Se recepţionează un semnal de la un alt obiect; 3.Se recepţionează un apel de operaţie de un alt obiect (sau de obiectul însuşi) și 4.Scurgerea unui interval de timp. 8 O clasă poate recepţiona sau trimite mesaje care sunt apeluri de operaţii sau semnale. Semnalele sunt clase ordinare care pot fi folosite numai pentru trimiterea semnalelor. Clasele semnal pot fi stereotipizate cu. Erorile sunt evenimente deasemenea și pot fi modelate ca evenimente stereotipizate, de exemplu: out_of_memory 9 Diagrama de stare pentru un ascensor. Ascensorul porneşte de la parter şi poate fi mutat în sus sau jos. Dacă staţionează pe un anumit nivel un interval de timp este mutat la parter. Diagrama nu are stare finală. 10 O stare tranziţională între "Staţionează” şi “La parter” are o condiţie şi o acţiune care va fi executată. Când atributul timp va fi egal cu timp scurs aceasta va fi executată şi starea va fi schimbată din “Staţionează” în “La parter”. 11 12 13  Descrie modul în care obiectele interacţionează şi comunică între ele. Diagramele de secvență au două axe: timpul, axa verticală şi setul de obiecte pe axa orizontală.  Comunicarea între obiecte este reprezentată prin linii de mesaj verticale între liniile vieţii obiectelor. În aceste diagrame mesajele vor putea fi sincrone, asincrone sau simple, ca şi în cazul diagramelor de stare. Fiecare mesaj poate avea: ◦ O semnătură ◦ Un număr de secvență ◦ condiţii, ◦ rezultatele mesajelor sincrone  Diagramele de secvență pot fi utilizate în două forme: ◦ forma generică (generic form) şi ◦ forma instanță (instance form). 14 Mesajul de la serverul de imprimantă la imprimantă are o condiţie care arată ce alternative sunt descrise în diagrama de secvenţă. Fie mesajul este trimis imprimantei, fie este stocat în coada de a şteptare a imprimantei. 15 Timpul între a şi b nu trebuie să fie mai mare de 5 secunde iar mesajul Print de la server trebuie recep ţionat în cel mult o secundă. Săgeata înclinată arată că timpul între trimiterea şi recepţionarea mesajului este important. De obicei constrângerile sunt marcate de acolade. 16 Mesajul Client creează un nou obiect al clasei Client. Operaţia ŞtergeClient elimină un obiect Client. Rezultatul creării sau distrugerii poate fi văzut explicit dar nu în aceasta diagramă. 17 Operaţia() se va apela pe ea însăşi. Va trebui să existe o condiţie în blocul operaţiei care să oprească la un moment dat recursivitatea. 18  Un Actor trimite un mesaj Print unui Calculator. Acesta trimite un mesaj Print Serverului de Imprimantă, care trimite mesajul Imprimantei, dacă aceasta este liberă.  Sintaxa unei etichete este: predecesor condiție_de_gardă expresie_secvență valoare_returnată:= semnatură  Recurența se marchează prin: ◦ * [ clauza_de_iterare ] de exemplu  *[x= 1..10 ] : executaCeva() ◦ [ clauza_conditie ] de exemplu  [x