TIPARUL EXECUTAT LA IMPRIMERIA EDITURI UNIVERSITAT ALEXANDRU IOAN CUZA™ DIN IASI Aparut: 2010 Comanda:s02 Informati si comenzi www.editura.uaic.ro editura@uaic.ro94. 95. 96. 97. 98, 99, INDEX 173 ‘Vaduva, I. §.a. — Ingineria programéirit, Editura Academici, Bucuresti, 1985 (vol. ), 1986 (vol. I). Voss, G. - Object-Oriented Programming. An Introduction, Osborne McGraw-Hill, Berkeley, 1991 Wiederhold, G., Wegner, P., Ceri, S. — Toward Megaprogramming”, in Communications of ACM 35, nr. 11, November 1992, Wilkie, G.- Object-Oriented Software Engineering, Addison Wesley, Reading, Massachusetts, 1993. Yourdon, E. — Decline & Fall of the American Programmer, Englewood Clifis, New Jersey, ‘Yourdon Press, 1993, ‘Zwass, V.— Management Information Systems, WCB-Wm, C, Brown Publishers, Dubuque, 1992. 100.*** — Foundation of Business Systems, Second Edition, Andersen Consulting ~ Arthur A. Andersen & Co. S.C, Dryden, 1989. 101.*** — Software Process Engineering Metamodel, version 1.1, OMG, 2005. 102.*** — Unified Modeling Language (UML) Specification: Infrastructure, version 2.0, OMG, 2004, p. 10. 103.%#* ~ Project Management — Guidelines, www.projectmanagement.tas.gov.au (accesat 06.07.2004). 104.*** - Gracle® Database Performance Tuning Guide 10g Release 2 (10.2), www.oracle.com. 105.*** — Incident Description Report, www.gantthead.com (accesat 12.01.2006).im PROIECTAREA SISTEMELOR INFORMATIONALE 63. Oprea, D., Airinei, D., Andone, I. ~ Bazele informaticii economice, Editura Universitit AL L Cuza”, Iasi, 1990 64. Oprea, D., Andone, I., Airinel, D. ~ Limbaje de programare si banci de date, Editura Universitat AL L Cuza”, Iasi, 1990 65. Oprea, D. - Analiza si proiectarea sistemelor informationale economice, Editura Polirom, Iasi 1999. 66. Oprea, D. ~ Premisele si consecinfele informatizarii contabilitafii, Editura Graphix, lasi, 1994. 67. Oprea, D. ~ Protectia si securitatea informariilor, Editura Polirom, Iasi, 2002. 68. Oprea, D. ~ Protecria si securitatea sistemelor informational, Editura Polirom, Iasi, 2002. 69. Oprea, D.— Managementul proiectelor. Teorie gi cazuri practice, Editura Sedcom Libris, Iasi, 2001. 70. Oprea, D., Mesniti, G.—,Documentatia sistemelor informationale — problema a managementului proiectelor?”, in vol. Societatea informationala: Educatie, Cercetare, Sisteme informationale, Tehnologii Informationale, Editura ETP Tehnopress, lagi, 2004, 71. Ozsu, M.T., Valduriez, P. — Principles of Distributed Database Systems, Second Edition, Prentice Hall Intemational, Inc., Upper Saddle River, New Jersey, 1999. 72. Page, J., Hooper, P. — Accounting and Information Systems, Fourth Edition, Prentice Hall, Englewood Cliffs, New Jersey, 1992. 73. Porter, A. — C++ Programming for Windows, McGraw-Hill, Berkeley, 1993. 74, Post, G.V. - Database Management Systems, Designing and Building Business Applications, McGraw-Hill, Boston, 199. 75. Powers, M.J., Cheney, P.H., Crow, G. ~ Structured Systems Development: Analysis, Design, Implementation, Boyd & Fraser Publishing Company, Boston, 1990. 76. Pressman, RS. - Software Engineering. A Practitioner's Approach, Fifth Edition, McGraw-Hill Publishing Company, London, 2000. 77. Richard, L.K. — Testing Requirements, www.gantthead.com (accesat 18.01.2006). 78. Riordan, RM. - Designing Relational Database Systems, Microsoft Press, Redmond, Washington, 1999, 79. Rodgers, U. — ,.Denormalization: Why, What and How?”, in Database Programming & Design, 2(12), December 1989. 80. Roman, D. - Ingineria programari obiectuale, Editura Albastra, Cluj-Napoca, 1996. 81. Satzinger J.W., Jackson, R.B., Burd, S.D. ~ Systems Analysis and Design in a Changing World, Course Technology, Thomson Learning, Boston, 2002 82. Schach, S. - Object-Oriented and Classical Software Engineering, Fifth Edition, McGraw-Hill, Boston, 2002 - 83. Schiesser, R. —IT Systems Management. Designing, Implementing, and Managing World-Class Infrastructures, Prentice Hall PTR, Upper Saddle River, New Jersey, 2002. 84, Schultels, R., Sumner, M., Bock, D.~ Management Information Systems: The Manager's View, Second Edition, IRWIN, Homewood, Boston, 1992. 85. Shelly, G.B., Cashman, T.J., Rosenblatt, H.J.— Systems Analysis and Design, Fourth Edition, Course Technology, Thomson Learning, Boston, 2001. 86. Shneiderman, B. — Designing the User Interface, Addison Wesley, 1998, Third Edition, http://www. cscutexas.edu/users/almstrum/es3 70/elvisino/rules. html 87. Shneiderman, B. ~ Designing the User Interface: Strategies for Effective Human-Computer Interaction, Addison Wesley, Reading, Massachusetts, 1992. ia, CL. Ian, B.C.Y., Teo, H.-H, Wei, K.-K. ~ , Applying Total Quality Concepts to Continuous Process Redesign”, in International Journal of Information Management, vol. 17, nr. 2, 1997. 89, Simon, J.C., Chaney, LH. — Systems and Procedures for the Modern Office -A Simulation Approach, Second Edition, Regents/Prentice Hall, Englewood Clifis, New Jersey, 1993, 90. Simsion, G.C, - Data Modeling Essentials. Analysis, Design, and Innovation, Second Edition, The Coriolis Group, Scottsdale, Arizona, 2001. 91, Tanenbaum, A.S., van Steen, M. ~ Distributed Systems. Principles and Paradigms, Prentice Hall, Inc., Upper Saddle River, New Jersey, 2002 92. Teorey, TJ. - Database Modeling & Design, Morgan Kaufmann Publishers, Inc, San Francisco, 1999. 93. van Viiet, H. ~ Software Engineering. Princples and Practice, Second Edition, John Wiley & Sons, LTD, Chichester, 2002. 88.32. 33. 34, 35, 36. 37. 38. 39. |. Jalies, P.J. - ,COBOL on a PC: A New Perspective on a Language and Its Performance”, in al. 22 43. 45, 46. 41, 48, 49, 50. Sl. 52. 33. 54, 55. 56 57. 58 59. 60. 61 62 INDEX m1 Hall, G., Rosenthal, J., Wade, J. Review, November-December 1993. Halpin, T. - Information Modeling and Relational Databases, Kaufmann Publishers, Inc, San Francisco, 2001 Hammer, M. - Re-engineering work: don’t automative, obliterate”, in Harvard Business Review, July-August 1990. Hayley, K., Plewa, J., Watts, M. — Reengineering Tops CIO Menu”, in Datamation, vol. 38., nr. 6, April 15, 1993. Hicks Jr., J.0. — Management Information Systems: A User Perspective, Second Edition, West Publishing Company, St. Paul, 1987. Hoffer, J.A., Prescott, M.B., McFadden, F.R. — Modern Database Management, Sixth Edition, Pearson Education, Inc., Prentice Hall, Upper Saddle River, New Jersey, 2002. Hoffer, JA. George, J.F, Valacich, J.S. - Modern Systems Analysis and Design, Benjamin/Cummings Publishing Company, Inc., Sand Hill Road, Menlo Park, 1996. Hughes, B.— Practical software measurement, McGraw-Hill, London, 2000. How to make reengineering really work”, in Harvard Business Communications of ACM 30, nr. 2, February 1987. Jones, T.C. - Programming productivity: Issues for the 80s, IEEE Computer Society Press, 1981 Kendall, K.E., Kendall, J.E. ~ Systems Analysis and Design, Fifth Edition, Prentice Hall, Upper Saddle River, New Jersey, 2002. Koval, J. A. ~ Analyzing Systems, Prentice Hall, Upper Saddle River, New Jersey, 1988. Langer, A.M. ~ Analysis and Design of Information Systems, Second Edition, Springer ~ Verlag, New York, 2001 Madison, J.— Five “T's” of Database Availability, www standishgroup.com (aecesat 20.10.2004). Mandel, T. ~ The Elements of User Interface Design, Jon Wiley & Sons, New York, 1997, Mandelkern, D. — Graphical User Interfaces: The Next Generation”, in Communication of ACM 36, nr. 4, April 1993 Marakas, G.~ Systems Analysis and Design. An Active Approach, Prentice Hall, New Jersey, 2001 Marchesi, M. — Object-Oriented Programming with Smallialk/V, Prentice Hall International Ltd, London, 1994. Martin, J. — Information Engineering: Book II ~ Planning & Analysis, Prentice Hall, Englewood Cliffs, New Jersey, 1990. Martinsons, M.G., Revenaugh, D.L. ~ Re-engineering is Dead; Long Live Re-engineering”, in International Journal of Information Management, vol. 17, nr. 2, 1997. May, J.C. - Extended the Macintosh Toolbox: Programming Menus, Windows, Dialogues and ‘More, Addison Wesley, Reading, Massachussetts, 1991. McFadden, F.R, Hoffer, J.A. — Data Base Management, Second Edition, The Benjamin/Cummings Publishing Company, Inc., Menlo Park, 1988. McFadden, F:R., Hoffer, J.A. ~ Modern Database Management, Benjamin/Cummings Publishing ‘Company, Inc., Redwood City, 1994 MeLeod, Jr., R., Jordan, E. ~ Systems Development. A Project Management Approach, John Wiley & Sons, Inc., New York, 2002. Mesnita, G.— ,Reproiectarea proceselor economice (BPR)”, in Analele $tiintifice ale Universitatii AL I. Cuza” Tagi ~ Seria Stinge Economice, Tomul XLVI, Editura Universititt Al. L. Cuza”, lasi, 2000. Morris, D., Brandon, J.— Re-engineering Your Business, McGraw-Hill, New York, 1993, Morse, A., Reynolds, G. — .Overcoming Current Growth Limits in UI Development”, in Communications of ACM 36, nr. 4, April 1993. Mosley, D.J.- The Handbook of MIS Application Software Testing, Yourdon Press, Englewood Cliffs, New Jersey, 1993. Naumann, J.D., Jenkins, A.M. — Prototyping: The New Paradigm for Systems Development”, in MIS Quarterly, 6 (3). 1993. Nelson, R.R., Cheney, P.H. ~ ,.Training End Users: An Exploratory Study”, in MIS Quarterly 11, December 1987. Norman, K.L. ‘The Psychology of Memu Selection, Ablex, Norwood, New Jersey, 199110, u 12, 13 14. 15, 16. 17 18, 19. 20. 21 2. 2B. 24, 28. 26. 21. 28, 29. 30. 31 Bibliografie generala Airinei, ~ Medii de programare, Editia a 1V-a, Editura Sedcom Libris, Iasi, 2004 Alter, S.- Op. cit, pp. 147-148; Mintzberg, H. — ,,The Manager's Job: Folklore and Fact”, in Harvard Business Review 53, nt. 4, July-August 1975 Bachenski, B. - ,GUI Builders Pay Price for User Productivity”, in Software Magazine, April 1992; Beizer, B.— Personal Computer Quality: A Guide for Victims and Vendors, Van Nostrand Reinhold Company, New York, 1986. Benbasat. L, Dexter, A.S., Todd, P. — ,,The Influence of Color and Graphical Information Presentation in a Managerial Decision Simulation”, in Human-Computer Interaction 2, 1986. Bidgoli, H. (editor) ~ Encyclopedia of Information Systems, vol. 4, Academic Press, Amsterdam, 2003, Blatiner, M., Schultz, E. — ,User Interface Tutorial”, Proceedings of the International Conference on System Sciences, Kona, Hawaii, January 1988. Bloor, R. — ,The Disappearing Programmer”, in DBMS 7(9) (august), 1994. Booch, G. ~ Object-Oriented Analysis and Design with Applications, Addison Wesley, New York, 1994, Booth, P. — An Introduction to Human-Computer Interaction, Lawrence Erlbaum Associates, Londra, 1989. Budd, T. — An Introduction to Object-Oriented Programming, Second Edition, Addison Wesley, Reading, Massachusetts, 1998. Carliner, S.—Industry Report: Overview of the Technical Communication Industry, 2002, www.ste.org (accesat 2.01.2006). Caroll, J.M. Designing Interaction, Cambridge University Press, Cambridge, 1991. Connoly, T.M., Begg, C.K. ~ Database Systems. A Practical Approach to Design, Implementation, and Management, Third Edition, Addison Wesley, Harlow, 2002. Coulouris, G., Dollimore, J., Kindberg, T. — Distributed Systems. Concepts and Design, Pearson Education Limited, Addison Wesley, Reading, Massachusetts, 2001 Craig, J.S., Beck, B.E. ~ ,A New Look at Documentation and Training: Technical Communicator as Problem Solver”, in Information Systems Management, 10 (Summer), 1993, Crowley, A. ~,,The Help Desk Gains Respect”, in PC Week, no. 10, November 15, 1993. Cushing, BLE., Romney, M.B, — Accounting Information Systems, Addison Wesley Publishing Company, New York, 1994. Date, C.J. - An Introduction to Database Systems, Seventh Edition, Addison Wesley, Reading, Massachusetts, 2000, Date, C.J. — Baze de date, Editura Plus, Bucuresti, 2005, traducere a lucrdrii Date, CJ. — An Introduction to Database Systems, Eighth Edition, Pearson Education, Inc., Boston, 2004. Davenport, T.H. — Process Innovation: Reengineering Work through Information Technology, Harvard Business School Press, Boston, 1993. Dollinger, R. ~ Baze de date si gestiunea tranzacriilor, Editura Albastr8, Cluj-Napoca, 1999. Dumas, J.S. ~ Designing User Interface for Software, Prentice Hall, Englewood Cliffs, 1988. Elmasri, R., Navathe, S.B. ~ Fundamentals of Database Systems, Third Edition, Addison Wesley. ‘Reading, Massachusetts, 2000. Finaru, L., Brava, ILM. ~ Visual Basic. Primi pasi... si urmatorit, Editura Polirom, Iasi, 2001. Flynn, D. ~ Information System Requirements: Determination & Analysis, McGraw-Hill, London, 1998. Forward, A. ~ Software Documentation ~ Building and Maintaining Artefacts of Communication, University of Ottawa, Ontario, Canada, 2002. Fotache, M. ~ Proiectarea bazelor de date. Normalizare $i postnormalizare, Implementari SOL si Oracle, Editura Polirom, lasi, 2005. Gliedman, C. — Thirty-one Best Practices for the Service Desk, Sune 28, 2005, bttp:/i.comvenwk.ld/tp (accesat 25.10.2005). Greenbaum, J. — ,,The Evolution Revolution”, in Information Week, March 14, 1994. Haarind, R. - ,Software’s New Object Lesson”, in Technology Review, February-March, 1992.PARTICULARITATI ALE ANALIZEI $1 PROIECTARI ORIENTATE-OBIECT 168 Diagrama de secveni anterioari ne sugereazd (prin mesajele Expeditie, Facturare, Documente de plata) existenta si a altor subclase ale clasei Tranzactie, pe langa subclasa Comandé, cum ar fi: Expeditie, Facturare, incasare. (=) [em] [ee] [eee] eee Ss Resngere: Set Street Stearn) pe eee eee ‘itomeseatspersch) ' t ' ' 1 1 1 ' t t ' moe] t fe rnetautar sara Coane sepa 1 7 | t ' t Prezentul capitol inceared s& faci o incursiune in abordarea orientati-obiect si in influentele ei asupra procesului de analiza si proiectare a aplicatillor economice, in speranta acumulérii nofiunilor de baza. Capitolul incepe cu prezentarea principalelor concepte ale abordaii orientate-obiect, concepte valabile in orice metoda de analiza si proiectare orientati-obiect, folosind, pentru reprezentarea graficd a acestora, standardul UML. Clasa de obiecte reprezinta un tip abstract de date care defineste structura obiectelor din acea clasé. Pentru a asigura functionalitatea aplicaiilor, intre elementele specifice orientirli obiect se stabilesc 0 setie de relatii, si anume: asocieri, dependent, derivari. Plecind de la aspectele fundamentale ale abordarii orientate-obiect, se poate trece la modelarea specifica fiecdrei etape de dezvoltare a unui sistem informational intrebari recapituls 1. Care sunt elementele ce definesc un obiect? Dar pentru o clas? 2. Cerelaii pot exista inte clase si prin ce se particularizeaza ele? 3. Realizafi o comparatie intre modul de redare a unei relati in modelul relational si cel obiectual 1, Prezentafi diagrama claselor pentru un sistem informational al unei firme despre care detinefi informarii. 2. Prezentati exemple din fiecare tip de relajie posibila in abordarea orientata-obiect, folosindu-va de componentele cunoscute ale sistemului informational abordat in problema anterioar8, 3. Transformaji diagrama entitate-relatie @ unui sistem informational intr-o diagramA a claselor gi ‘motivati fiecare modificare. 4, Prezentati diagrams de secventé specific® unui sistem informational si argumentati rolul acesteia in rafinarea diagramei claselor.168 PROUECTAREA SISTEMELOR INFORMATIONALE 8.3.1 Diagrame de seeventi Diagramele de secvenjé sunt diagrame de interactiune ce evidentiaza ordinea realizdrii prelucritilor (transmiterii mesajelor). Ele se pregdtesc in etapa de analizé a sistemului, iar realizarea lor duce, de multe ori, la modificari ale structurii claselor identificate pana in aceasta faza. Elementele de baza ale unei diagrame de secventi sunt: © obiectele ce intervin in prelucrari, prin transmiterea gi primirea de mesaje. Ele se reprezinté prin dreptunghiuri, plasate orizontal, in partea de sus a diagramei, in care sunt scrise numele acestora. © liniile de viafa a obiectelor evidentiazi duratele de existenti a obiectelor. Ele se reprezint& cu un dreptunghi atasat unor linii verticale punctate ce vin de la fiecare obiect. « mesajele sunt elementele de comunicare dintre obiecte, cum ar fi apelurile de operat si se reprezint cu sigeti ce unesc liniile de viata ale obiectelor. Mesajele pot fi insotite de conditii, pentru transmiterea sau nu a unui mesaj si de parametri. Mesajele transmise intre obiecte (tabel 8.4) pot fi clasificate si descrise astfel: © mesaje sincrone: mesaje dup care se asteapt& terminarea completi a prelucrarii indicate de mesaj, prin furnizarea sau nu a unui rispuns; # mesaje asincrone: mesaje care indic& faptul cA se poate initia o noua prelucrare, chiar daca nu s-a finalizat cea curenta. © mesaje simple: mesaje pentru care nu se specific& proprietatea de sincronizare. in timpul realizarii diagramelor de secvenfa, dezvoltatorii, cunoscénd domeniul afacerii, identifics mesajele ce au loc intre diferite clase, flind momentul in care existi posibilitatea de stabilire completa a operatiilor specifice claselor. Tabel nr. 8.4 — Simboturile folosite in UML ‘pentru reprecentarea mesajelor Element Mesaj sincron ‘Mesaj asincron ‘Mesaj simplu in urma culegerii cerintelor, cu ajutorul cazurilor de utilizare, se pot crea scenarii folositoare nu doar pentru a acumula date despre dinamica sistemului (mesajele dintre obiecte si ordinea acestora, stirile obiectelor etc.), ci $i pentru a verifica si completa clasele si relatiile dintre acestea. De exemplu, urmatoarea secvenfa de activitai poate fi prezentata in mod grafic cain figura 8.26: Clientul introduce comanda in sistem; Managerul consulté un raport cu ultimele comenzi neprelucrate si datele despre clienii respectivi; Managerul aprobi / respinge o parte din comenzi; Distributia consulta stocurile curente specifice elementelor comandate; Distributia expediazi elementele comandate existente pe stoc; Distributia creeaza facturile corespunzatoare elementelor vandute; Contabilitatea inregistreaza facturile trimise clientilor; Clientul achité o parte din debite; Contabilitatea inregistreazi documentele de incasare de la clienti.PARTICULARITATI ALE ANALIZE! SI PROIECTARIM ORIENTATE-OBIECT 167 in astfel de cazuri, nu este obligatoriu sa existe o singur& metoda de scriere si o singura metoda de citire. Exemplul poate continua cu aparitia si a altor metode pentru acelasi atribut calculat: * © metoda (Citeste_StocCurent) ce apartine clasei Material si care are ca parametru codul gestiunii pentru care se citeste stocul curent, * © metoda’ (Actualizeaza_StocCurent) ce apartine clasei Material si care ate ca parametru codul gestiunii pentru care se actualizeazA stocul curent si cantitatea curcare se face aceasta modificare. © 0 metodi (Citeste_StocCurent) ce aparfine clasei Firmd si are ca parametri codul materialului si codul gestiunii pentru care se citeste stocul curent. © 0 metoda (Actualizeaza_StocCurent) ce aparfine clasei Firma si care are ca parametri codul materialului si codul gestiunii pentru care se actualizeazi stocul curent si cantitatea cu care se face aceasta modificare. fn modelul obiectual, atributul StocCurent poate s& dispari (inclusiv operatiile Actualizeaza_StocCurent), urmand ca, la fiecare apelare a metodei Citeste_StocCurent, si se recalouleze stocul curent, pe baza stocului initial, a intrailor si a iegirilor. Modelul objectual oferd, in acest caz, un loc unic de calculare a acestei valori, fra a exista nevoia calculdrii aceluiasi lucru in diversele aplicatii ce folosesc aceeasi baz de date. Calculul stocului curent de fiecare dati cfnd este necesar poate avea si dezavantajul standardelor impuse de optimizarea aplicatiei. fntr-o alti ordine de idei, pot exista si metode care nu modifica valorile atributelor din aceleasi clase, ci, de exemplu, introduc sau sterg obiecte dintr-o colectie de obiecte. Un exemplu de colectie de obiecte o reprezint& randurile de pe o not& de receptie si constatare diferente. Aceasti colectie este intr-o relatie de compozitie fata de intregul document, manipularea acesteia la momentul operarii fiind, evident, necesara. De multe ori, doar diagrama claselor nu ajunge pentru a explica toate detaliile privind clasele sistemului. De exemplu, in diagrama din fig. 8.28, atributul Tip al metaclasei Persoand poate fi interpretat in mai multe feluri, El face referire la persoanele fizice si persoanele juridice, dar cel care citeste aceasta diagrama poate atribui alte sensuri acestui atribut fra existenta unor informatii suplimentare. Exist mai multe solufii in astfel de cazuri. O solufie ar fi crearea unei clase dedicate tipurilor de persoane si folosirea acesteia ca tip al atributului Tip din clasa Persoand. Solutia reuseste sé impuna restrictiile necesare in acest model de date, dar in cadrul sistemelor mari, cu sute de clase, apare problema complexititii, mai ales in cazul in care denumirea fiecirui tip trebuie si fie memorati in mai multe limbi. O alt& solutie ar fi gestiunea unitaré a tuturor acestor stereotipuri intr-o singuré clasé. Aceasta clasé ar prelua si sarcina traducerii denumiri in diferite limb 8.3 Modelarea in etapa de proiectare orientaté-obiect Dupf intelegerea cerintelor (in modelul cazurilor de utilizare) si a conceptelor (In modelul domeniului), se poate trece la etapa de proiectare a sistemului, respectiv realizarea modelului proiectarii, prin introducerea de concepte specifice programfrii, Acest model descrie atat structura interna a sistemului (clase, obiecte gi relatii), cat si colaborarile care intervin cand obiectele transmit mesaje pentru a realiza functionalitatea doritd. Structura statica este descris& {in diagrame de clase, iar dinamica sistemului este descrisé prin diagramele de comunicare sau de secventa. Descrierea dinamicii sistemului poate si inceap’ tot printr-o descriere narativa a secventelor de activititi identificate, ce vor ajuta nu doar la realizarea diagramelor de interacfiune (diagramele de secventa si diagramele de comunicare), dar vor fi folosite si la rafinarea diagramei claselor.166 PROIECTAREA SISTEMELOR INFORMATIONALE camuri, nevoia adaugarii unor metode pentru citirea si actualizarea propriilor atribuite se face simfita numai in cazul atributelor calculate. Atributele derivate (calculate, nenormalizate) ale unei entitéti din diagrama entitate- relatie, specific’ modelului structurat, pot fi exprimate, in abordarea orientati-obiect, ca mesaje read-only (numai citire). De exemplu, atributul Valoare_cu_TVA al entitafii Doc_insorire poate fi exprimat ca mesajul Valoare_cu_TVA al obiectului Doc_insotire, iar metoda care fl implementeazi poate obtine valoarea prin citirea atributelor Cantitate, Pref si Procent_TVA din toate obiectele instantiate din clasa Produs incluse in obiectul Doc_insotire. in continuare, ne propunem si luim un exemplu dintr-un model conceptual pe care si-1 transformam atat cu elementele specifice modelului relational, cat si cu cele specifice abordarii orientate-obiect. 7 <= Ber | PBB T way Nao [a Cur fans) scene LOM“ Bae coo | Sane TBAN PreUnitar Fig, 8.23 Relatia dintre Firma, Gestiune si Material in modelul conceptual in cadrul modelului conceptual al unui sistem ce gestioneazA materiale, putem spune ca relafia dintre entitatea Gestiune si entitatea Material este o relatie multe-la-multe, deoarece un material este in stoc la zero sau mai multe gestiuni, iar o gestiune are pe stoc zero sau mai multe materiale. in modelul relational, relatia multe-la-multe se descompune in doua relafii unu-la-multe, prin crearea unei entitati-intersectie. Astfel, apare entitatea Stoc, o entitate asociativa intre entitatea Material si entitatea Gestiune. Fig. 8.24 Relatia dintre Firma, Gestiune st Material in modetul relational in abordarea obiectuala, atributul StocCurent al entitaii Stoc poate fi inlocuit de: '* 0 metoda (Citeste_StocCurent) ce apartine clasei Gestiune si care are ca parametru codul materialului pentru care se citeste stocul curent; © 0 metoda (Actualizeaza_StocCurent) ce aparjine aceleiagi clase, Gestiune, si care are ca parametru codul materialului pentru care se actualizeaz4 stocul curent si cantitatea cu care se face aceast |tasse State a (FApsalines, Section | Fete Storer |ScicseSeccirat | Fig. 8.25 Relatia dintre Firma, Gestiune si Material in modelul obiectualPARTICULARITATI ALE ANALIZE! §] PROIECTARHI ORIENTATE-OBIECT 16s intr-un sistem informational ce realizeazi gestiunea comenzilor primite de la clienti pot fi identificate anumite reguli ale afacerii, precum cele din tabelul 8.3. Tabel nr. 8.3 ~Reguli ale afaceri intr-un sistem de gestiune a comenzilor clientilor | Reguli ale afaceri | " Clienti pot fi anumite persoane (lizice sau juridice) ances] | Clienti Client pot realize tranzactii, dar persiste | clientului nu este strns legatd de o anumita | Tranzactie | tranzactie _ Un tip de tranzacfie este comanda ‘0 comanda confine unul sau mai multe produse, iar Comanda datele despre produsele confinute Intr-o anumiti | Produs comand’ nu pot avea o existent mai scurté sau mai lungii decét a comenzii din care fac parte __} _ | Despre fiecare produs confinut intr-o comand | Linie_Comands | Clasi de agregare trebuie memorate anumite date si chiar pot exista | _ptelucrai specifice Dupi cum se observa din tabelul 8.3, fiecare regula ne ajuti s& identificam clasele folosite in cadrul sistemului i relatiile dintre acestea. Regulile pot fi modelate obiectual si reprezentate grafic, ca in diagrama claselor din figura 8.22. Realizarea diagramei claselor in etapa de analiza orientati-obiect este un efort asemanitor realizdrii diagramei entitate-relatie specificd abordarii structurate. ‘Aseminarea dintre diagrama claselor si diagrama entitate-relatie provine din existenfa unui model conceptual comun, bazat pe analiza direct a elementelor din lumea reala. Practic, diagramei entitate-relatie ii pot fi adaugate elementele de comportament specific obiectelor si relafiile de generalizare pentru inceperea procesului de construire a diagramei claselor. Adiugarea modelului conceptual al unor elemente de comportament presupune identificarea pentru fiecare clas& a unui set de operatii, prin stabilirea principalelor actiuni ce pot fi atribuite clasetor. = ra os bapa or panes ease al Lec e| Sener acme wees [Stee ce | beam fiat] ese, | eee [Client : Client |+Cantitate_Onorata : Double 7 1 [ee yreaizeazs | * | [Franzactia: Comanda 1 |__Predus _| aera (=| 1. ere [-Lmte_ creat: Double I alcere: Double KL —|+Denumie : Char eaves fice Sra ong Fig. 8.22 Diagrama claselor pentru gestiunea comenzilor cliengilor in demersul urmator incerc&m s& prezentam rationamentul folosit la addugarea de operatii entitatilor de date din modelul conceptual Teoretic, fiecdrui atribut al unei clase fi pot corespunde cel putin doud metode, una de actualizare si una de citire. Pentru simplitate, multe modele orientate-obiect permit citirea si modificarea variabilelor direct, fara a mai fi nevoie s& se defineasca metode specifice. In aceste164 PROIECTAREA SISTEMELOR INFORMATIONALE Daca elementele de modelare specifice UML nu fac referire si la informafii mai greu de structurat, ce se concretizeazA doar in note explicative sau comentarii, in cadrul reprezentarilor grafice pot fi adaugate elemente pentru adnoti, redate prin simbolul utilizat in figura 8.21. Fig, 8.21 Simbolul UML pentru note explicative Pentru o intelegere mai usoari a termenilor, propunem in tabelul 8.2 0 paralela intre termenii folositi in abordarea structurata si termenii folosifi in cea orientaté-obiect. Tabel nr. 8.2 ~ Paralela intre termenii abordérii structurare si cet al abordarii orientate-obiect (Declarare la execulie ["Ascunderea informatie! | incapsulare in continuare, pe baza conceptelor definite, vom incerca sé surprindem cAteva din particularitafile specifice etapelor de dezvoltare a sistemelor informationale, din perspectiva abordarii orientate-obiect. 8.2 Modelarea orientata-obiect in timpul etapei de analiza Dupa prezentarea exterioara a functionalit&tilor sistemului, echipa de dezvoltare are nevoie si de o descriere intern’ a acestuia, prin diagrame grupate in modelul domeniului. Echipa inci se gindeste la obiectele si relatiile din lumea real, in detrimentul conceptelor specifice programarii. Modelul domeniului se realizeaza in etapa de analiza a sistemului gi este de preferat ca la realizarea lui s& participe si economisti cu experienta in domeniul afacerii respective. El presupune crearea unor diagrame de clase (la nivel conceptual) si eventual definirea pachetelor de astfel de diagrame. fncd nu este Iuati decizia folosirii unui anumit model de organizare a datelor cu care s& se satisfacd nevoile de persistent, asa incat acest model conceptual nu respect restrictiile nici unui model de organizare 2 datelor. Clasele identificate si, eventual, cazurile de utilizare pot fi asociate anumitor diagrame ale stirilor de ‘tranzitie si/sau diagrame de activitate pentru a se infelege ciclul de viata a obiectelor. §. Diagramele claselor prezint& clasele existente intr-un sistem informatic $i relatiile dintre acestea. intr-o abordare fop-down, se pot identifica toate elementele lumii reale specifice domeniului afacerii studiat, urménd ca ulterior sa fie adaugate relatiile dintre ele si detaliile din structura lor.PARTICULARITATI ALE ANALIZEI §I PROIECTARH ORIENTATE-OBIECT 163 are 0 implementare care nu trebuie schimbati sub nici o forma in subclasele ei, fiind critica pentru consistenta stiri unui obiect. ‘Avantajul legirii dinamice, fati de legarea statica, const in faptul ca ofera un grad mare de flexibilitate. Astfel, ierarhiile de clase sunt mai usor de realizat si de intretinut. Dezavantajul legarii dinamice consti in diminuarea performantei de vitezi. Legarea dinamic& presupune un efort suplimentar de alegere dintr-un tabel de functii, pe cfnd o functie legata static se apeleaza direct. De obicei, se foloseste legarea static& si numai unde este esential se recurge la legarea dinamica, daca respectivul limbaj permite ambele tipuri. Nici notiunea de polimorfism nu aparfine intru-totul tehnologiei orientate-obiect. in programarea structurati exist operatori care lucreazA in exact acelasi mod pe mai multe tipuri de date. je orientar -ctuale 8.1.5 Alte concepte in functie de durata de viati a obiectelor, ele pot fi: volatile sau persistente. Cu alte cuvinte, daci un obiect se poate salva pentru ruléri ulterioare ale aplicatiilor el este obiect persistent. Un obiect volatil este un obiect care poate supraviefui cel mult pe perioada rulirii programului care I-a creat. Sistemele de gestiune a bazelor de date orientate-obiect permit combinarea tehnicilor de programare orientati-obiect cu caracteristicile bazelor de date, astfel incat obiectele definite de utilizator pot fi stocate si recuperate pentru prelucrare. Acolo- unde se intflnesc volume mari de date, cum ar fi domeniul financiar-contabil, accesarea obiectelor dintr-o baz de date orientati-obiect poate deveni o problema spinoas’, datorita lipsei unor metode rapide, neprocedurale si descriptive de ciutare si regasire a datelor (cum este de exemplu, limbajul SQL, intilnit in marea majoritate a sistemelor de gestiune a bazelor de date relationale). Pentru a putea exprima modele in cele mai diferite domenii gi pentru a detalia informatia prezentaté in mod grafic, se pot folosi mecanisme de extensie, cum ar fi: stereotipuri, restricfii si valori atasate. Stereotipurile pot fi folosite atat in cazul elementelor, cat si al relatiilor si trebuie vazute ca subtipuri de elemente. Un stereotip reprezint& o clas in cadrul metamodelului de modelare. Astfel, un element sau o relafie poate face parte dintr-un stereotip (dar nu in mod obligatoriu), Unele stereotipuri sunt predefinite, dar proiectantul igi poate defini propriile stereotipuri. Restricfiile extind semantica elementelor prin addugarea de reguli. De exemplu, putem impune unei metode destinate prelucrarii unei tranzacfii de vanzare s4 determine aparitia unui mesaj de eroare sau de atentionare atunci cénd soldul clientului depaseste limita de creditare, ca urmare a tranzactiei respective Valorile atasate (tagged values) ofera elemente de descriere suplimentari unui element, prin prezentarea unor proprietti, cum ar fi: autorul elementului, autorul ultimelor modificari, versiunea curenta, data ultimei modificAri sau motivul ultimei modificari, in cazul sistemelor informationale de marime medie sau mare, UML pune la dispozitie un mecanism general de organizare a clementelor in grupuri, si anume pacherul, Pachet Fig. 8.20 Simbolul UML pentru pachete Pachetele sunt doar elemente conceptuale (existi doar neconcretizindu-se obligatoriu in fisiere. timpul dezvoltarii),162 PROIECTAREA SISTEMELOR INFORMATIONALE. resurse de pomnire find probabil deja testate. Mai mult, pot fi refolosite resurse chiar si fara 0 infelegere temeinic& a implementirii ce se ascunde in spatele lor. O resursd existent poate fi extinsi, atat prin versiune, adica prin adiugare de metode noi, cat si prin re-specializare, prin derivarea de noi ramuri in cadrul unei ierarhii de clase. Chiar gi bibliotecile de clase, a cdror implementare nu este disponibila sub forma de fisiere sursd, pot fi usor extinse prin derivari (specializari) succesive. Relafia de derivare prezinta si un dezavantaj: astfel de relafii mu pot s& apara pe parcursul rularii unei aplicati. 8.1.4 Redefinire in abordarea obiectuala Redefinirea se imparte in dowd categorii. Una staticd (supraincarcare, over-loading), ce are Joc in faza de compilare si se aplicd atét la metodele unei clase, ct gi la operatorii predefinifi ai limbajului. Cea de-a doua este redefinrea dinamica (polimorfism/supradefinire, over-riding), desfasurdindu-se in faza de rulare a aplicafiilor 8.1.4.1 Supraincdrcarea metodelor in multe dintre limbajele de programare actuale se pot defini functii diferite, dar care au acelasi nume. Aceste functii au totusi semnaturi diferite (numa, tip si ordine a parametrilor), astfel incdt s& poatl fi desemnatd funcfia ce trebuie efectiv apelats. Aceastd alegere este facutd in momentul compilarii si riméne neschimbata pe parcursul rularii programulu Din moment ce se pot supraincdrca functii, in general, este evident faptul c& si metodele unei clase pot fi supraincircate, Avantajul adus de suprainc&rcare este flexibilitatea, deoarece cu ajutorul ei o clas poate oferi implementiri diferite pentru acelasi aspect comportamental. 8.1.4.2 Suprainc&rcarea operatorilor Printr-o expresie se infelege 0 secventi de operanzi si operatori. Prin evaluarea unei astfel de expresii se obtine un rezultat. in abordarea obiectuala, expresiile pot avea ca operanzi obiecte instantiate dintr-o anumita clasa. in aceste situatii operatorii de baz& ai limbajului pot fi redefiniti. in cazul in care, intr-o expresie, apare un operator aplicat unui obiect a c&rui clas a redefinit acel operator, se apeleaz o functie care confine noud semnificatie a operatorului, Supraincdrcarea operatorilor nu este posibila pentru tipurile fundamentale de date. Suprainearcarea operatorilor nu aparfine doar tehnologiei orientate-obiect. $i in programarea structurat& exist operatori diferiti, dar care se noteaz& la fel. Avantajul oferit de supraincdrcarea operatorilor consti in méarirea posibilitatilor de exprimare oferite de limbaj 8.1.4.3 Polimorfismul Polimorfismul reprezint& abilitatea unor obiecte similare de a raspunde la acelasi mesaj in ‘moduri diferite. El apare cind o subclas& are 0 metoda cu acelagi nume si aceeasi semndtura ca si o metoda din superclasd. Se spune cé metoda din clasa derivati suprascrie metoda superclasé. Polimorfismul este o facilitate a metodelor din clase diferite, dar aflate in relafie de derivare intre ele, nefiind legat intrinsec de clase gi obiecte. Cu polimorfismul, fiecare element al colectiei primeste acelasi mesaj, dar fiecare este programat sd reactioneze in mod diferit. Polimorfismul descrie posibilitatea unor obiecte de a se comporta diferit in functie de condifiile din momentul rulirii, asa incat decizia privind comportamentul nu se ia la compilare ca in cazul suprainc&rcarii (cuvantul polimorfism a fost creat prin unirea a doud cuvinte din limba greac&: poli, ce inseamna multe, si morphos, ce inseamnd forma). ‘Metodele care nu ar trebui si mai poaté fi supradefinite in subclasele clasei in care sunt definite poarti numele de metode finale. O metoda trebuie declarati ca fiind final& atunci céndPARTICULARITATI ALE ANALIZE! §! PROIECTARII ORIENTATE-OBIECT 161 Derivarea este o relajie intre dou& sau mai multe clase, prin care se modeleazi similitudinile si diferentele specifice dintre acestea. Derivarea este capacitatea de a declara un tip pe baza unor elemente (atribute si operafii) ale unui tip declarat anterior. Pornind de la o clasé, se pot deriva noi clase ce adauga diferente specifice. Conceptual de derivare este probabil cel mai important concept al abordirii orientate- obiect, dup’ conceptul de clas. Asa cum toate limbajele orientate-obiect sprijind conceptul de clas, toate aceste limbaje sprijina si conceptul de derivare. Lipsa posibilitatii de derivare intr- un mediu de programare, ce foloseste clase si obiecte, impiedica folosirea in acest caz a termenului de programare orientata-obiect, vorbindu-se doar de o programare bazat& pe obiecte sau, altfel spus, abstractizare a datelor. Termeni de specializare, generalizare, mostenire se referi la relatia de derivare. Termenul de mostenire este folosit mai mult in legaturd cu reutilizarea atributelor si metodelor clasei de baz4. Prin intermediul acestei relafii, obiectele unei clase derivate mostenesc atribute simetode ale clasei de bazi la care se adauga membrii clasei proprii. Relatia de derivare este reprezentat& in UML printr-o linie dreapt& care are 1a un capat un triunghi gol, ce arati clasa general ce este supus& specializarii Fig. 8.18 Reprezentarea graficd in UML a unei relatii de derivare Un tip particular de derivare este extensia, Prin ea, un element (clas, component sau caz de utilizare) extinde comportamentul unui alt element prin adaugarea unor comportamente noi. Extensia se reprezinté in UML prin specificarea stereotipului extends pe simbolul unei deriva. Fig, 8.19 Reprezentarea graficd in UML a unei relafii de extensie Termenul de ierarhie de clase desemneaza clase intre care exist relatii de derivare. Clasa din care deriva o alté clas poarté numele de metaclasd. Dup’ aceeasi regula morfologica, un model din care deriva alt model poarta numele de metamodel. Clasa derivaté dintr-o alt& clas poarté numele de subclasd. O clasi poate deriva dintr-o singuré clas, cand apare mostenirea simpla, sau din mai multe clase, vorbind de mostenire multipld. Nu toate mediile de programare orientate-obiect au implementat’ mostenirea multipl’, deoarece este dificil de utilizat si dezvoltat in timp. Problemele mostenirii multiple apar cénd metaclasele au atribute si/sau operatii cu acelasi nume, iar clasa specializati din acestea trebuie si facd referire numai la una sau la 0 combinafie a acestora. Cand o clas mosteneste un element de la mai mult de o clasa, se vorbeste de generalizare suprapusd (overlapping). Opusul generalizSrii suprapuse poarti numele de generalizare disjuncta (disjoint), in functie de capacititile de derivare, clasele pot fi clase rideicind (root classes), in sensul c& nu pot avea predecesori, si clase frunzd (leaf classes), indicénd faptul cA nu pot avea descendenti Atunei cand unei clase nu i se mai pot face alte specificatii de subclase se vorbeste de generalizare completa. Generalizarea incompleta apare atunci cand o clas’ se mai poate specializa si in alte subclase. Avantajele oferite de derivare sunt date de posibilitatile de reutilizare a codului si de extensibilitate a sistemului creat. O serie de resurse de baz, puse la punct in anumite aplicatii, pot fi usor refolosite in alte aplicatii, prin derivari succesive, Timpul de testare scade, aceste160 PROIECTAREA SISTEMELOR INFORMATIONALE. Agregirile se pot clasifica in: ‘© agregari fixe: au numar fix de componente; de exemplu, un lot de produse poate avea fix cinci tipuri de produse; © agregari variabile: au un numar finit, dar variabil de componente; de exemplu, mai multe produse pot face parte dintr-un lot pregatit pentru livrare, dar numérul acestora ru este fix; © agregari recursive: au componente de acelasi tip; de exemplu, asocierea dintre un departament si birourile componente. in cazul in care partile componente au aceeasi durata de viata cu a intregului si se pot regisi fizic in cadrul acestuia, avem de-a face cu un caz particular de agregare, numit compozitie. in cadrul compozitiei, clasa compusi nu poate s& participe si la alte agregari, pe clind operatia clasic& de agregare, numiti si agregare partajatl, permite participarea unei clase agregat la oricdte agregari. ‘Simbolul UML pentru agregare este rombul. in cazul agregirilor partajate acest romb este {gol la mijloc, iar in cazul agregarilor compuse acesta este plin. -pariajeaza OO ‘i : Fig. 8.14 Reprezentarea graficd in UML a unei agregiiri partajate Fig. 8.15 Reprezentarea graficé in UML a unei compociit Alt tip de asociere este comunicarea, care indicd o asociere intre un actor si un caz de utilizare, reprezentindu-se grafic ca o asociere binar& simpli, ce poate avea anumite cardinalitafi si anumite roluri Asocierea ce reprezint trecerea unui obiect dintr-o stare intr-o alta stare se numeste tranziie. Ea se reprezinté grafic prin adaugarea la linia unei asocieri a unei sgeti care arati starea destinatie. ——e UML a unet tranzipi Fig. 8.16 Reprezentarea grafic 8.1.3.2 Dependente Dependenta este o relatie intre dou’ elemente prin care schimbérile intr-un element surs& pot determina schimbari in elementul destinatie. O dependent leags elementele fara a fi necesar& o instantiere, de aceea nu are cardinalititi, Relatia de dependenfé este unidirectionala, un element fiind considerat independent, iar celalalt, dependent. Modificirile asupra clementului independent se vor reflecta si asupra elementului dependent. De exemplu, dependenta apare in cazul relatiilor dintre doug clase intre care exista relatii de incredere, denumite clase prieten (friend), in care 0 clas& oferd altei clase accesul la clementele protejate, chiar dac& intre ele nu exist asociere direct&. Simbolul folosit in UML, pentru reprezentarea dependenjelor este o linie intrerupta care are la un capat o sAgeaté ce aati elementul dependent. > Fig. 8.17 Reprezentarea graficd in UML a unei dependentePARTICULARITATI ALE ANALIZE! $I PROIECTARI ORIENTATE-OBIECT 159 01 jy [Namar® har (Data: Date |Doe_ anterior: Doe_insotre een Get Valoare_fare_TVAQ): Decimal I+Get_TVA):Decinal Set valoer_cuTVAQ: Decimal | 0.1 Fig. 8.11 Reprezentarea grafica in UML a nei asocieri reflexive Asocierea reflexiva din figura 8.11 aratd faptul cd unele documente insofitoare (cum ar fi avizele de expeditie) pot corespunde altor documente justificative (cum ar fi facturile). Tot asocieri reflexive s-ar obfine si la prezentarea asocierilor dintre un angajat si seful siu ierarhic, sau la asocierea dintre un document justificativ si documentul sau de stornare. Cand o asociere are caracteristicile unei clase ea este denumita clasd de asociere. De exemplu, asocierea dintre clasa ce defineste notele de receptie si clasa ce defineste materialele dintr-un sistem de gestiune a materiilor prime, poate avea propriile atribute (cantitatea gi pretul fiecdrui material) si propriile operatii (calcularea cantititii rAmase de consumat dintr-un anumit material si o anumita nota de receptie necesara intr-un sistem ce foloseste metoda FIFO, ca metoda de evaluare a stocurilor). Simbolul folosit in UML pentru reprezentarea unei clase de asociere este cel al unei clase, unite de asocierea respectiva printr-o linie intrerupta. de asoclere Fig. 8.12 Reprezentarea graficd in UML a unei clase de asocier! binare O clas de asociere poate uni mai mult de dowd elemente, caz in care ea este denumité. clasd de asociere n-ard. [clasa de asocier : Fig, 8.13 Reprezentarea grafica in UML a unei clase de asocieri n-are Uneori, asocierile dintre dowd elemente presupun o anumiti ordine a obiectelor instantiate. De exemplu, mérfurile dintr-o anumit& facturA sunt ordonate intr-un anumit mod, in asa fel inet reproducerea exacté a unei anumite facturi presupune si persistenfa ordinii mérfurilor referite. fn aceste cazuri se vorbeste de o asociere ordonata. Cand o clasi este implicati in mai multe asocieri si nu pot exista instanje simultane ale claselor cu care se afld in asociere, asocierile se conecteaza printr-o linie intrerupta, cu eticheta XOR. Un tip aparte de asociere este agregarea, cu ajutorul careia 0 clasa poate fi modelat, ca fiind parte a unei alte clase. O clasi agregat este o clasa ale cArei obiecte contin alte obiecte. De exemplu, 0 comanda confine, pe ling’ datele specifice acestui tip de tranzactie, si obiecte de tipul produseior.158 PROTECTAREA SISTEMELOR INFORMATIONALE 8.1.3.1 Asocieri Asocierile sunt relafii intre dowi sau mai multe clase, prin care se modeleazi interdependente intre obiectele instantiate din clasele respective. Un exemplu de asociere poate fi: jun mijloc fix este in gestiunea unui anumit gestionar”. O instanga a unei asocieri poarti numele de legdturd, ea descriind relatia dintre douk sau mai multe obiecte. Un exemplu de legitura poate fi: ,Mijlocul fix cu numirul de inventar 331265 este in gestiunea Iui Gestiondrescu Fix”, ‘Asocierile dintre clase au céte un ro! (0 explicatie) pentru fiecare clas participant. Un rol poate fi privit ca o imagine a unui obiect. intre doud clase pot exista mai multe asocieri, fiecare cu roluri distincte. De exemplu, intre clasa ,Bon_de_transfer” si clasa ,Gestiune” pot exista dou’ asocieri, una privind gestiunea in care se transfera si cea de a doua asociere privind gestiunea de ta care se transferd. Asocierile au pentru fiecare element pe care il leagi 0 cardinalitate (multiplicitate) corespunz&toare numarului de obiecte ce pot apairea la instantiere sub forma: - 1 —unul si doar un obiect; - 0.1 nici unul sau maxim un obiect; - 0..*=nici unul sau mai multe obiecte; - *—tot zero sau mai multe obiecte; - 1.*—unul sau mai multe obiecte; - 1.n—unul sau maxim n obiecte; = 0..n sau n~ nici unul sau maxim n obiecte; - nl, n2, n3 —ingiruire de numere, care exprimi numérul de obiecte; = n-m~numir de obiecte cuprins intre n si m. in functie de numérul de elemente pe care le leaga, asocierile pot fi: binare sau n-are. in UML, o asociere binari se reprezint grafic printr-o linie dreapti ce uneste cele dous elementele implicate. Cand elementele unite sunt actori, cazuri de utilizare sau clase, pe aceste linii se pot specifica rolurile si cardinalititile elementelor. Fig. 8.9 Reprezentarea grafica in UML a unei asocieri binare Asocierile n-are se reprezinta, in UML, cu ajutorul unui romb, de la care pleacd spre fiecare element implicat in relajie cate o linie dreapt®, pe care se poate atasa cardinalitatea si rolul specific elementului respectiv. Fig. 8.10 Reprezentarea graficd in UML a unei asocieri n-are Cand un element se asociaza cu el insusi se obtine 0 asociere reflexivd. De exemplu, acest tip de asociere poate ardta legaturile dintre obiectele aceleiasi clase.PARTICULARITATI ALE ANALIZEI $I PROIECTARI ORIENTATE-OBIECT 137 acesta este comun tuturor obiectelor instantiate din acecasi clas. fn partea destinata starii se prezinta valorile curente ale fiecdrui atribut, asa cum este prezentat in figura 8.5. “aStereolps INume_Obiect:Nume. MstaClasa:Nume_ Clas [Airbut pubic: Tip_Data = Valoare_Curenta latbut protejat: Tip_Date = Valoare_Curenta trbut privat: Tip ‘Date = Valoare Gurenta Fig. 8.5 Simbolul folosit in UML pentru reprezentarea obiectelor in figura 8.6, se prezinté un exemplu de reprezentare graficd a clasei ,,Angajat” sia obiectului ,,Popescu Ion” instantiat din aceasté clasd. ‘Angalat Popescu lon: Angalat Parca Char Varoa :Char= 1001 ‘Nume : Chat INume : Cnar = Popescu Prenume » Char IPrenume : Cn Funeba: Char fFuncia ‘GNP : Char NP : Chi [iintorneaza(in Raper : Ona Fig. 8.6 Exemple de clase si obiecte Termenul de interfaja desemneaz’ serviciile oferite de clase sau componente. Interfata unei clase se specificd prin operatiile ce pot fi invocate de o clasi client. Operafiile sunt implementate cu ajutorul metodelor. Specificarea unei operafii in cadrul unei clase se numeste semniturd, iar modul de implementare se numeste corpul metodei. Interfetele descriu comportamentul vizibil din exterior al claselor sau componentelor; nu specific’ niciodatS implementarea acestor operatii. Interfetele pun in practicd unul din conceptele abordarii orientate-obiect, de separare a structurii unui obiect de implementarea sa. Asadar, o interfapa poate fi priviti ca un protocol de comunicare intre obiecte. O clasé poate implementa una sau mai multe interfefe, depinzind de functionalititile pe care le implementeaza. O interfati se reprezinti in UML cu un dreptunghi in care sunt prezentate: numele acesteia si operatiile ei publice, ca in figura 8.7: . “interface Interfata Operation?) |+Operatiea) Fig. 8.7 Simbolul folosit in UML pentru reprezentarea interfejelor De exemplu, intr-o aplicatie economic, clasele de tranzactii ce modifica patrimoniul unititii pot si implementeze urmitoarea interfaja destinaté contabilizirii respectivelor modifica: wrieracer Contabiizare [+Set Plan de contuntin Plan de_contur) Fig. 8.8 Exemplu de interfaja 8. til € e Pentru a asigura funcjionalitatea aplicafiilor intre elementele specifice orientarii-obiect se stabilesc o serie de relati, si anume: asocieri, dependente, derivari.136 PROIECTAREA SISTEMELOR INFORMATIONALE. Practic, incapsularea mascheaza atributele unei clase, modul propriu de executie a operailor, dnd posibilitatea clasei de a evolua in timp, fr’ si afecteze intregul sistem, incapsularea faciliteaz4 materializarea unui avantaj oferit de orientarea-obiecte, si anume: reutilizarea. incapsularea este complementara abstractizarii, aceasta din urma ocupiindu-se de partea exterioara, iar incapsularea impiedica accesul in interior, acolo unde este implementaté manifestarea abstractizarii. Pentru atributele de vizibilitate, se mai pot declara: © tipul de data — sub forma: tip_data; © valoarea initiald — sub forma: valoare_initiala; © cardinalitatea; * lista de proprietafi — se declara intre acolade {} si se utilizeaz& pentru a reprezenta caracteristici suplimentare, atunci cand este cazul. Operatiile pot fi declarate impreun’ cu eventualii parametrii si cu tipul de dat& returnat. Tipurile posibile de parametri sunt: /n (parametri de intrare), Out (parametri de iesire) si InOut (parametri de intrare/iesire). ‘Simbolul folosit in UML pentru reprezentarea unei clase este un dreptunghi in care sunt evidentiate trei componente: numele clasei, atributele $i operafiile clasei, Completarea acestor tei pis face inind cont de urmatoarele reguli: daci respectiva clas este abstract’ (neinstanfiabila direct), numele ei se serie cu caractere italice; deasupra numelui clasei, se serie stereotipul acesteia intre caracterele << >>", dact exist’; © in fata numelui clasei se scrie, dac& exist, metaclasa specializat& prin aceasta; in fata numelor atributelor si a operatiilor se scrie simbolul de vizibilitate; © oumele fiecirui atribut este urmat de tipul de dati al acestuia; © tipurile de data ale atributelor pot fi precedate de valorile initiale ale acestora; © daca o operatic este abstract (nu are nici o metoda care si o implementeze), toate proprietitile ei se scriu cu caractere italice; © operafiile sunt urmate de lista de parametri, prezentat’ intre paranteze rotunde ,()"; ‘* in fata numelui fiecirui parametru se specific& tipul acestuia; © dupa numele fiecirui parametru se scrie caracterul dou& puncte ,,:” si tipul de data al acestuia; * parametrii operatiilor, cu toate proprietatile acestora, se despart cu caracterul virgula; © chiar dacé o operatie nu are nici un parametru, dup’ numele acesteia, tot se scriu parantezele rotunde; © dac& © operatie intoarce o valoare, dup inchiderea parantezei rotunde, destinate specificirii parametrilor, se scrie caracterul dou puncte si tipul de data al valorii intoarse. ee arp Nume_MelaCises:Nome_ Cisse [pAtout pone Tp_Osa in ut prea :Tip_Data = Valare, nila bat privat: T_Dala= Voor Ira Foperatiepubicaln Paramety_1: Tp_Dala = Veowe_ pica, oA ParenataNTp_baa) To_Date hsOperate potiatan Parametiy_1 Tip Dela, haut Paremor rametw.N: Te_Ost): Te_Dat pera privat) Te Dela Fig. 84 Simbolul folosit in UML pentru reprezentarea claselor }bolul folosit in UML pentru reprezentarea unui obiect instantiar dintr-o anumita clas este tot un dreptunghi in care sunt evidentiate doar dou’ din cele tei parti: idencitarea si starea. A treia parte, comportamentul, nu se reprezint3 si in simbolul fiecdrui obiect, deoarecePARTICULARITATI ALE ANALIZEI $I PROIECTARH ORIENTATE-OBIECT 135 Starea unui obiect este data de valorile atributelor pe care le confine. De exemplu, obiectul ,clientul SC ALFA SRL” are o anumitd adres, un anumit numar de telefon, nu este incert etc. Cénd se schimba starea obiectului, nu este afectaté in nici un fel identitatea acestuia. Atributele unui obiect mu trebuie s& apartina, in mod obligatoriu, unor tipuri scalare de date, ci pot fi la randul lor alte obiecte. Comportamentul obiectului se refera la serviciile pe care le ofera altor obiecte. Aceste servicii sunt asigurate prin operatiile pe care le confine datorité instantierii sale dintr-o anumita clasi. Cererile adresate unui obiect pentru a intoarce o valoare sau pentru a schimba o stare se numesc mesaje. Un obiect primeste mesaje de la alte obiecte si rispunde acestora prin intermediul serviciilor pe care le oferé. De exemplu: ,,afigeazi soldul curent” sau ,schimb& adresa” sunt o operatii posibile asupra obiectului ,,clientul SC ALFA SRL”. Dac& o metodi este vazuti in mod asemfn&tor cu o proceduri dintr-un limbaj conventional, atunci trimiterea unui mesaj este similar cu apelarea unei proceduri. Diferenja fntre transmiterea mesajelor gi apelarea procedurilor este aceea c& in transmiterea mesajelor exist un receptor, iar interpretarea (selectia unei metode pentru a fi executatii ca rispuns al mesajului) poate varia de la un receptor la altul”. ‘Componentele unui mesaj sunt: receptorul (obiectul cdruia i se cere si execute o metoda), selectorul (metoda ceruta a fi declansat& receptorului) si argumentele (parametrii metodei). Rezultatul mesajului este si el o referire a unui obiect si este trimis expeditorului mesajului. Odat& ce un mesaj a fost trimis unui obiect, obiectele din afar’, nu pot si nici nu ar trebui s& stie cum, s& prelucreze datele in obiect. ‘Metodele unui obiect pot fi de actualizare sau doar de citire. Metodele de actualizare sunt cele ce modifica valorile atributelor propriului obiect, pe cand metodele destinate citirii nu afecteazi aceste valori, ci doar le citeste in vederea realiz4rii anumitor operafii. in mod analog, pot fi clasificate mesajele la care rAspund obiectele, dup metoda la care fac referire. Metodele fiiré nici o implementare (care nu confin cod) se numese metode abstracte si pot aplrea doar in clase abstracte. Tipuri aparte de metode sunt constructorii si destructorii Un constructor este 0 metoda care creeazi un obiect, in sensul ca fi alocd spajiu si/sau inifializeaz& atributele acestuia si nu intoarce nici o valoare. Constructorii sunt apelafi automat la instanfierea unui obiect. Prezenta constructorilor in corpul-unei clase nu este obligatorie, 0 clas’ poate s& nu aiba nici un constructor, si aiba unul sau mai mulfi constructori. Daci o clas are mai mulfi constructori, acestia trebuie s& difere prin semnaturd (lista de argumente primite) in felul acesta, sunt permise diverse tipuri de inifializari ale obiectului la crearea sa, in functie de numarul si tipul parametrilor cu care este apelat constructorul. Destructorul este 0 metoda care incheie ciclul de viata al unui obiect, eliberdnd spafiul pe care acesta I-a ocupat. fin vederea ascunderii detaliilor de implementare a atributelor unei clase gi a operatiilor acesteia, se poate controla accesul la aceste resurse prin definirea unor operafii speciale. ‘Aceasti ascundere se defineste cu ajutorul unor atribute de vizibilitate, care se pot asocia atributelor si operatiilor dintr-o clas. Atributele de vizibilitate si reprezentarea lor in UML sunt prezentate in tabelul 8.1: 8.1 ~ Atributele de vizibilitate si reprezentarea lor in UML ‘Simbol UML oricdrei clase + ~ numai in eadral propriei clase gi subclaselor = ‘numai induntrul propriei clase : 57. Budd, T. — An Introduction to Object-Oriented Programming, Second Edition, Addison Wesley, Reading, Massachusetts, 1998, p. 9Isa PROIECTAREA SISTEMELOR INFORMATIONALE Clasele de obiecte sunt tipuri abstracte de date care definesc structura obiectelor din acea clasa (setul de date $i prelucrarile reunite). Clasele sunt aranjate intr-o ierarhie, in aga fel incat ele pot mosteni o parte din structura (date si prelucriri) de la propriii parinfi. O clasi este considerati clasi abstracta daci nu este folosité pentru a crea obiecte direct prin ea, ci este folosita doar pentru a crea alte clase. Termenul de metaclasi desemneaza clasa unei clase Caracteristicile esentiale ale metodei orientate-obiect sunt * orice este un obiect; * prelucrarile sunt realizate de obiecte ce comunici intre ele, cerénd unul altuia si execute anumite actiuni. Obiectele comunicd prin transmiterea si primirea mesajelor. ‘Un mesaj este cererea pentru o acfiune, insofiti de anumite argumente ce pot fi necesare indeplinirii acesteia; * fiecare obiect are propria memorie, ce este, la randul ei, alt obiect; © orice obiect este instanta unei clase. O clas reprezint& o grupare a unor obiecte similare; ‘© clasa este dictionarul comportamentului asociat unui obiect, aga incét toate obiectele ce sunt instanfe ale aceeasi clase pot realiza aceleasi actiuni; + clasele sunt organizate intr-o singura structurd arborescent8, numita ierarhia claselor sau ierarhia mostenirii. Memoria si comportamentul, asociate cu instantele unei clase, sunt disponibile automat oricarei clase descendente acesteia, in structura arborescentl. in urma acestei incursiuni in cateva dintre elementele specifice orientarii-obiect, putem concluziona c&: * oclasi este o colectie de date si proceduri ce abstractizeazA un element al lumii reale. © un obiect este o implementare a unei clase, de la aceasta ludnd structura gi comportamentul. Tipuri aparte de clase sunt cele ce reprezint grupurile de utilizatori ai sistemului, inclusiv alte sisteme cu care se interactioneazi. Termenul folosit pentru desemnarea acestora este de actor. Actorii nu fac parte din sistem, fiind doar generatori de evenimente, avand acelasi rol ca si entitafile exteme (sursele sau destinatiile fluxurilor de date) din modelarea structuratd, cu ajutorul diagramelor fluxurilor de date. In figura 8.3, se prezinti modalitatea de reprezentare graficd a actorilor, propusi in UML. ‘Actor Fig. 8.3 Simbolul UML de reprezentare a actorilor Asa cum am vazut, elementele prin care se caracterizeaz un obiect sunt: identitatea, starea $i comportamentul Identitatea unui obiect este reprezentati printr-un identificator unie (UID), care permite diferentierea obiectelor intre ele. Nu trebuie facut nici o confuzie intre identitatea unui obiect, si nofiunea de cheie primar, intélnita in cazul bazelor de date relationale, care se bazeazi pe unicitatea valorilor unui atribut sau a unui grup de atribute (identificare in functie de confinut) in cazul obiectelor, avem de-a face cu identificatori interni, fara nici o legdtura cu identificatorii impliciti, prin care se realizeazi diferentierea obiectelor intre ele. 56. Budd, T. - An Introduction 10 Object-Oriented Programming, Second Edition, Addison Wesley, Reading, Massachusetts, 1998, p. 13,puternice. Conceptele cu care opereazi abordarea oriental PARTICULARITATI ALE ANALIZEI $1 PROIECTARII ORIENTATE-OBIECT 153 -obiect, sunt: obiecte si clase, identitate, stare si comportament, asocieri, dependente si derivari, redefinire, componente, 1.1 Obiecte si clase in literatura de specialitate exist’ numeroase definifii ale termenului de obiect, dintre care pe cele mai relevante le prezentm in continuare: © obiectele sunt principala unitate structurala a programarii orientate-obiect. Clasele sunt ,,template-uri” ale obiectelor. Clasele sunt ca si tipurile de date din limbajele traditionale de programare, iar obiectele sunt asemandtoare cu variabilele*; * un obiect are o stare, un comportament $i 0 identitate; structura si comportamentul unor obiecte similare sunt definite in clasa lor comund. Termenii de instanté si obiect sunt interschimbabili®; un obiect este 0 colectie de date si procedurile destinate prelucrarii acestora®; un obiect este 0 incapsulare a stirii (valorii datelor) si comportamentului (operatiilor)"; * un object este un element al unui sistem informatic ce are o identitate unicd, o stare (reprezentat& de date publice sau private) si operatii (metode) publice gi private, ce reprezinti comportamentul obiectului in decursul timpului®; © un obiect este ceva distinct, identificabil, pentru care sistemul trebuie s& stocheze date pentru a realiza activititile fundamentale in sistem", ‘© obiectul este 0 componentii a descrierii bazei de date logice ce reprezinta o entitate a lumii reale despre care sunt stocate informatii®; © obiectele sunt componente active ce prezinti un comportament cénd sunt stimulate de mesaje sau tranzactii®. Din definifiile de mai sus se desprind trei puncte de vedere folosite pentru descrierea noiunii de obiect: 1. structural, cnd obiectul este vizut ca o instan{ a unui tip de dat& caracterizat de 0 structura ascuns’ prin operatii (se prezint& ce confine obiectul); 2. conceptual, cand obiectul este vazut ca find corespondentul unui concept din lumea reali (se prezint& ce abstractizeazA obiectul); 3. actor, cand obiectul este viizut ca o entitate activa care rispunde la mesaje (se prezinté ce face obiectul).. Notiunea de mesaj dintre obiecte, folosit in abordarea obiectualé, inseamn& apelarea procedurilor unui obiect de cdtre alt obiect. Prezentarea abordarii obiectuale, in contextul aplicatiilor economice, ne determin’ si prezentim uneori obiectul din punct de vedere conceptual, comparandu-l cu un alt corespondent al elementelor din lumea real: entitatea din modelul relational de organizare a datelor. in descrierea unui anumit sistem modelat orientat-obiect, nu trebui ins’ minimalizata prezentarea structurii si functionalit&tii fiecdirei clase de obiecte. 48, 30, 51 32, 34, 55, Voss, G.~ Object-Oriented Programming. An Introduction, Osbome McGraw-Hill, Berkeley, 1991, pp. 19-21. Booch, G. ~ Object-Oriented Analysis and Design with Applications, Addison Wesley, New York, 1994, p. 516. Marchesi, M. — Object-Oriented Programming with Smailtalk/V, Prentice Hall International Ltd, London, 1994, pel Budd, T. - An Introduction 10 Object-Oriented Programming, Second Edition, Addison Wesley, Reading, “Massachusetts, 1998, p. 22. ‘Wilkie, G.— Object-Oriented Software Engineering, Addison Wesley, Reading, Massachusetts, 1993, p. 386. Koval, J. A. — Analyzing Systems, Prentice Hall, Upper Saddle River, New Jersey, 1988, p. 184. Martin, J. — Information Engineering: Book Il ~ Planning & Analysis, Prentice Hall, Englewood Cliffs, New Jersey, 1990, p. 474. ‘+5 — Foundation of Business Systems, Second Edition, Andersen Consulting - Arthur A, Andersen & Co. $.C., Dryden, 1989, p. 233.sz PROIECTAREA SISTEMELOR INFORMATIONALE © diagramele de secventa sunt diagrame de interactiune ce evidenfiaz& ordinea realizarii prelucrarilor (transmiterii mesajelor); © diagramele de comunicare sunt diagrame de interactiune ce evidentiazd organizarea structurala a obiectelor ce trimit si primesc mesaje; © diagramele de componente arati organizarea si dependenfa intre un set de componente; © diagramele de amplasare arati configurafia la rulare a nodurilor gi a componentelor ce existd in ele. Aceste diagrame UML pot fi impirfite in dou mari categorii: diagrame de structurd si diagrame de comportament. Diagramele de structurd arata structura static’ a elementelor unui sistem, prin prezentarea acestora intr-o specificatie independent de factorul timp. Elementele dintr-o diagrama de structurd reprezinté conceptele semmificative ale unei aplicatii si pot include concepte abstracte, ale lumii reale sau de implementare. Diagramele de structuri nu aratd detaliile comportamentului obiectelor, céci acestea sunt ilustrate in diagramele de comportament. Diagramele de comportament prezinté dinamica unui sistem prin descrierea seriilor de schimbari posibile ale acestuia in decursul timpului ‘Aceast& taxonomie asigura o organizare logic& a tipurilor de diagrame, dar nu inlatura mixarea lor, cum ar fi combinarea unor elemente structurale cu altele comportamentale, prin prezentarea unor stari de tranzitie intr-o structur& intern’. in consecint&, granitele dintre diferite tipuri de diagrame nu sunt impuse in mod strict. Figura 8.2 reflect’ impirjirea tipurilor de diagrame in cele doua categorii, asa cum este ea prezentat8 chiar in cadrul standardului UML. Folosirea diagramelor UML ca modalitate de reprezentare a unui sistem informational economic, nu exclude folosirea unor descrieri narative ale sistemului, in toate etapele de dezvoltare a acestuia. Fig, 8.2 Tipurile de diagrama de structurd si de comportament 8.1 Concepte ale abordarii orientate-obiect Conform metodelor orientate-obiect, in fiecare etapa de dezvoltare se construiesc modele, reprezentate grafic cu ajutorul unor diagrame. Desi, aceste modele sunt axate pe anumite componente si perspective diferite ale sistemului informational, intre ele exist legaturiPARTICULARITATI ALE ANALIZE! $1 PROIECTARII ORIENTATE-OBIECT 131 in domeniul dezvoltarii sistemelor informationale, UML poate fi aplicat oricarei metode de analiza si proiectare orientate-obiect ce respect principiile de mai sus. Locul UML in cadrul procesului de dezvoltare software este prezentat in specificatiile OMG, denumite Software Process Engineering Metamodel (SPEM), a MetaObject Facility MetaModel Model MetaObject Facility Fig. 8.1 Niveluri de modelare conform SPEM” Exemple de metode de analiza si proiectare orientate-obiect ce ar putea folosi ca limbaj grafic UML sunt: Rational Unified Process (RUP), DMR Macroscope, IBM Global Services Method si Fujitsu SDEM, Dintre aceste metode se remarci RUP, denumit si procesul unificat (Unified Process), care ii are ca autori pe cei din grupul de cercetitori de 1a Rational Corporation, ce au participat si la realizarea UML. UML presupune 0 metodologie sistemic& aplicaté unui proces iterativ si incremental, condus prin cazuri de utilizare $i centrat pe o arhitecturd, fiind principalele caracteristici ale procesului unificat. Detaliile acestui proces se adapteazi Ia factori cum ar fi: domeniul aplicatiei, experienta si organizarea echipei de dezvoltatori. Un proces software iterativ presupune o detaliere succesiva a arhitecturii, astfel incat fiecare noua versiune a acesteia se bazeazA pe experienta si rezultatele obtinute din versiunea anterioara. Un proces software incremental presupune c& fiecare trecere printr-un ciclu de viata, de la culegerea cerintelor si pfn& la intretinere, conduce spre o detaliere treptat’ a deciziilor strategice si tactice, obfinandu-se in ultimi instanfa solutionarea cerinfelor reale ale utilizatorului, sistemul ramAndnd ins& simply, fiabil si adaptabil. Una din initiativele OMG este Arhitectura Bazatdl pe Modele (Model Driven Architecture, MDA), o arhitectura conceptuala evolutiva, destinati unui set de specificatii tehnologice larg raspandite, ce sprijin’ o abordare bazat& pe modele a procesului de dezvoltare software. Ideal ar fi ca pentru descrierea sistemului si se foloseascd un singur grup de diagrame, ins, de cele mai multe ori, acesta nu poate s& surprinda toate informafiile necesare descrierii sistemului sau ar amesteca diferite aspecte de urmarit in dezvoltarea unui sistem informational. Astfel, in UML putem apela la urmatoarele tipuri de diagrame pentru modelarea sistemului: © diagramele cazurilor de utilizare arat& functiile de prelucrare la care au acces diferitele categorii de utilizatori (actori); © diagramele de clase contin seturi de clase (inclusiv interfeje) si relafiile dintre acestea, reflectind aspectul static al sistemului; © diagramele de obiecte contin multimi de obiecte si relatiile acestora; * diagramele stérilor de tranzifie arat’ o serie de stiri, tranzitii, evenimente si activitati ale obiectelor; © diagramele de activitate un tip de diagrama de stari ce arat’ evolutia de la o activitate la alta intr-un sistem; 47.4% ~ Software Process Engineering Metamodel, version 1.1, OMG, 2005, p. 1-2130 PROIECTAREA SISTEMELOR INFORMATIONALE. conferinfei OOSLA), cénd cei doi stabilesc caracteristicile de bazi ale unei noi metode de analiza si proiectare, rezultat& prin unificarea metodei lui Booch (OOD) cu OMT, metoda denumiti initial metoda unificati (The Unified Method). La sfargitul anului 1995, celor doi li se altura Ivar Jacobson, un alt nume de referinta din domeniu, autorul metodei OOSE (Object-Oriented Software Engineering) fn 1996, metoda unificatd isi schimb& numele in limbajul unificat de modelare (Unified Modeling Language) datoriti faptului c& eforturile initiale de unificare au fost concentrate asupra limbajului grafic de modelare, a semanticii lui si abia dup’ aceea a modului de utilizare a conceptelor. Schimbarea denumirii a fost justificatA si prin faptul c& acest efort stiintific nua tratat inifial si aspecte de metodologie, permifénd astfel separarea limbajului de modelare de procesul aplicirii metodologiei. Punerea accentului pe limbaj nu echivaleaza cu ignorarea modului de folosire a acestuia. in 1997, apare versiunea 1.0, ce continea o documentatie mai detaliat& decat versiunile anterioare, versiune ce este propusi OMG-ului (Object Management Group) pentru standardizare. Raspunsul pozitiv al celor de la OMG vine in acelasi an, UML devenind astfel un limbaj standard de modelare orientati-obiect. De la standardizare si pani in prezent au mai apérut si alte versiuni ale limbajului unificat de modelare, cum ar fi: versiunea 1.5, din martie 2003, si versiunea 2.0, din septembrie 2005. ‘UML nu este o metoda de proiectare, ci un limbaj universal pentru modelarea gi realizarea oricdrui tip de sistem, de orice mfrime, asigurand posibilitati unitare de reprezentare grafic in toate fazele dezvoltirii unui sistem informatic: definirea cerintelor, analiz8, proiectare, implementare, testare, instalare, intretinere. Conform definifiei date chiar de OMG“, UML este un limbaj vizual pentru specificarea, construirea si documentarea elementelor sistemelor. Este un limbaj de modelare universal ce poate fi folosit cu toate metodele obiectuale si in toate domeniile de aplicatii (de exemplu, economie, sanatate, telecomunicatii, gestiunea fluxurilor de lucru) si pe toate platformele de implementare (de exemplu, J2EE, NET). ‘Nu toate posibilitafile de modelare pe care le ofer sunt necesare in toate domeniile de aplicafii. Acest lucru sugereaz c& limbajul trebuie structurat modular, cu posibilitatea de a selecta doar acele parfi ale limbajului care sunt de interes intr-un anumit proces de modelare. Pe de alta parte, un exces de flexibilitate creste probabilitatea.ca dou instrumente diferite UML sa suporte subseturi diferite de limbaj, ducand la probleme de interactiune intre ele. UML 2.0 confine dowd specificatii complementare: infrastructura UML (UML Infrastructure) si superstructura UML (UML Superstructure). Daca prima specificatie prezinta componentele fundamentale ale limbajului, partea a doua prezint& constructorii accesibili utilizatorilor acestui limbaj. ‘Metamodelul UML a fost creat tindndu-se cont de urmatoarele principii: © principiul modularitdyii se asigur printr-o coeziune strans’ si cuplare slaba cu ajutorul pachetelor si organizarea metaclaselor; © principiul stratificdrii. presupune separarea conceptelor pe diferite niveluri de abstractizare; © principiul partitiondrii folosit pentru a organiza zone in cadrul aceluiasi nivel de abstractizare; © principiul extensibilitafii se asigur’ prin douk modalitat: —definirea de profile (Profiles) pentru a adapta limbajul anumitor platforme (de exemplu, J2EE sau NET) si domenii (de exemplu, economic, finante etc.); — 0; ORDER BY Datalntrare n= ALEN(@Stocuti, ROW") DIMENSION aConsum(n,3 INCREMENT vCantConsum BY aStocuri(i,2) @ J sConsuani1) = aStoeur(,1) aConsum(i2) = aStocur(.2) sConsumni,3) = aStocusii.3) ELSE ‘aConsum(i,1) = aStocurii1) @ + eConsumni.2) = vCanttate — vCantConsum aConsumn(.3) = aStocuri(3) ‘yCantConsim = vCantiate ND IF @tncrenenripy 1 @ ENppo. r (econ Fas @ ISPLAY_MESSAGE(,Stocul este insuficient") @ fs, ‘bConsValid = TRUE @{Q7F Fig. 6.3 Construcfile elementare pentru crearea grafului fluurilor logice de control Pentru pseudocodul din caseta 6.2, graful fluxurilor logice de control este prezentat in figura din caseta 6.3. 2. Determinarea complexititii logice a programului pe baza grafului Complexitatea Logica a programului (cyclomatic complexity) trebuie determinata in vederea stabilirii numrului clilor independente de executie. O cale independenta de executie a programului reprezintA orice cale din program care implic& cel putin un nod nou (adic un grup nou de instrucfiuni sau o condifie nou’), adic& el nu a fost inclus in c&ile definite anterior. Complexitatea logica poate fi determinaté in mai multe moduri. Unul dintre acestea are la baza formula: Cl = P + 1, in care P reprezinta numérul nodurilor predicative din graful fluxurilor de control. Un nod predicativ este acela care confine 0 conditie logica (un predicat) Prin urmare, in graf, din fiecare nod predicativ vor pleca cel putin doua sagetiIMPLEMENTAREA SISTEMULUL na « verificarea validititi structurilor de date inteme ale programelor. ‘Testarea de tip ,,cutia neagra” urmireste s& rispunda la urmatoarele intrebari: Cum poate fi testat& validitatea functional a aplicatiei? Cum pot fi testate performantele aplicatiei? Ce volum de date si ce rata a intrlrilor poate accepta sistemul? Ce efect va avea asupra modului de functionare a sistemului o anumit& combinatie a datelor de intrare? ‘tn realizarea acestui tip de testare, un rol important il au diagramele fluxurilor de date, pe baza cirora se pot defini clascle de intriri care si permiti testarea eficace a fiecarei tranzacti/transformari (in functie de orientarea sistemului) si a fiec&rui proces in realizarea ei Pomnind de la diagramele fluxurilor de date, se poate realiza testarea pe baza unor grafuri, in care nodurile reprezint& procesele necesare unei tranzacfii, iar legaturile reprezinté conexiunile logice dintre acestea. in cazul sistemelor orientate pe transforméri, nodurile reprezinta datele, iar legaturile dintre noduri reprezinté transformarile la care acestea sunt supuse. fn concluzie, testarea tip ,,cutia neagra” si cea tip ,,cutia alba” sunt complementare, ambele trebuind si fie utilizate pentru o bun’ testare. De asemenea, de refinut cf mu exist 0 tehnicd de testare sau o categorie de tehnici catalogat& drept cea mai bund. Fiecare tehnica este orientat& spre detectarea anumitor tipuri de erori sau atingerii anumitor obiective. Din acest motiv, se va apela la utilizarea mai multor tehnici, in functie de obiectivele propuse, strategia de testare, complexitatea sistemului informatic, resursele alocate etc. 6.2.2.2 Tehnica testirii cAilor independente de executie ‘Aceasté tehnic& de testare se incadreazA in categoria celor tip ,,cutia albi”. Baa fost propusé pentru prima dati in 1976, de Tom McCabe, si are drept criteriu de acceptabilitate garantarea executiei cel pusin o datd a fiecdrei instructiuni din program. Aplicarea ei presupune determinarea indicatorului complexitatea logica a specificapiilor procedurale, pe baza céruia se va defini un set de baz al c&ilor independente de executie @ programului. Fiecare cale independent de executie va reprezenta un caz (scenariu) de testare, urmand a fi determinate datele de test (intrare). fn continuare vom prezenta un exemplu de aplicare a tehnicii testarii cAilor independente, pornind de la pseudocodul pentru modulul EvaluareFIFO din caseta 6.2., si vom urma cei patru pasi specifici. 1. Construirea grafului fluxurilor logice de control din program, pe baza pseudocodului sau a programului surs& Fluxurile logice de control dintr-un program sunt puse in evidenfé intr-un graf. Fiecare nod al grafului, reprezentat printr-un cerculet, reprezinti una sau mai multe instructiuni program, iar sgetile dintre noduri reprezintd fluxurile logice de control din cadrul modulului de program, Orice sdgeati trebuie sé aiba la capatul stu un nod, chiar daca este posibil ca unui nod si nu-i corespund’ nici o instructiune, Printr-un nod se poate reprezenta un grup de instructiuni secventiale gi o instrucfiune care codificd o structur’ de control. In cazul in care structura de control confine o conditie compus, se va crea cate un nod separat pentru fiecare conditie elementara. O conditie compusi reprezinti o expresie logica in care se folosese unul sau mai multi operatori logici (OR, AND). fn caseta 6.2 sunt evidentiate nodurile care vor apare in graf. in construirea grafului apeleazé la notafiile din figura 6.3120 PROIECTAREA SISTEMELOR INFORMATIONALE, general, tehnicile manuale nu implic’ executia programelor”, iar tehnicile de testare automat presupun de cele mai multe ori execufia programelor, deci ele sunt considerate tehnici de testare dinamica. in mod tradifional, exist doud abordari complementare in testarea programelor, in functie de sursele de informatii utilizate pentru generarea cazurilor de test. Celor dou abordari le corespund dou categorii de tehnici de testare: tehnici tip .,cutia neagra” sau tehnici tip ,,cutia alba”. Testarea tip .,cutia neagra”, numit si functionald, nu ia in considerare detaliile procedurale interne ale componentei testate, ci urmareste functiile acesteia. Se vor alege date de test pentru fiecare functie in parte. in cazul unui modul de program, responsabilii testarii nu Vor examina instructiunile acestuia, ei fiind interesafi doar de datele de intrare gi rezultatele asteptate pentru fiecare functie 2 modulului Testarea tip ,,cutia alba”, numita si structurald, presupune concentrarea atentiei asupra detaliilor procedurale ale componentei testate, pentru a putea determina cazurile de test si datele de intrare necesare. Ea implic& identificarea cazurilor de test care permit executia tuturor ramurilor programului, derivate din structurile de control alternative si/sau repetitive. Prin urmare, se va defini céte un caz de test pentru fiecare ramuri logic a programului. Tehnica testirii cailor de baz, ce va fi prezentata in paragraful urmator, se incadreazi in aceast categorie, Deoarece pomeste de la analiza structurilor de control din specificatiile procedurale de proiectare sau codul program, s-ar putea crea impresia cA aplicarea aceste testari, tip ,.cutia alba”, ar conduce inevitabil cdtre obtinerea de programe 100% corecte si ci testarea de tip wcutia neagrs” ar fi inutili. Ar putea fi adevSrat dac& ar fi posibilé testarea exhaustivi a programelor (reamintiti-va unul din principiile testarii enuntate anterior). Problema poate fi formulata si din cealalta perspectiva: de ce trebuie si cheltuim atéta timp si energie cu testarea la nivelul detaliilor programelor, in loc si ne concentrim atentia asupra testelor care si vizeze fiecare functie 2 programelor? Agadar, de ce si ne complicam cu testarea tip ,,cutia alba”, in loc si consumim toate resursele cu testarea tip ,cutia neagri"? Raspunsul la intrebarea anterioar§ deriva din natura erorilor intalnite in programe. Multe erori apar atunci cénd se proiecteaz& si implementeaz4 conditii sau structuri de control care privesc cazurile speciale ale functiei tratate si care nu fac parte din fluxul logic principal al programului. Se estimeaza ci numarul erorilor logice este invers proportional cu probabilitatea de executie a unei ramuri logice a programului™. Erorile de scriere a programelor sursa pot aprea oriunde in programe, att in ramurile logice principale, cat si in cele care trateazi cazurile speciale, ceea ce justificd necesitatea tehnicilor de testare de tip ,cutia alba”. Pe de alta parte, aplicarea tehnicilor de testare de tip ,cutia alba” permite identificarea gi localizarea mai usoara a erorilor, tocmai datorité faptului ci acest tip de testare se desfasoara la nivelul detaliilor procedurale, S4 ne imaginim ce dificila ar fi localizarea unei erori identificate la testarea unei functii a sistemului ce presupune executia mai multor module de program. in plus, noi stim c& rezultatele obfinute nu sunt corecte, dar ar putea fi vorba de mai multe eroti si nu doar de una singur’. Acesta este unul din motivele pentru care strategia de testare trebuie definita astfel incdt s& se aplice mai intai tebnicile de testare tip ,cutia alb&” si apoi cele tip .cutia neagra”. De regulf, testarea tip ,cutia alba” urmareste generarea cazurilor de test astfel incat: © executia fiecdrei structuri de control alternative pe ambele ramuri; © execufia fiecarei structuri de control repetitive, atit la numfrul minim, cét si cel maxim al iterafiilor, dar si a unuia intermediar; 33. van Vliet, H. ~ Software Engineering. Prineples and Practice, Second Edition, John Wiley & Sons, LTD, Chichester, 2002, p. 399. 34, Jones, T.C. — Programming productivity: Issues for the 80s, IEEE Computer Society Press, 1981, citat in Presmann, RS. — op. cit, . 433IMPLEMENTAREA SISTEMULU! ns 6. Testarea nu vizeazd numai produsul fal, ci si rezultatele fazelor intermediare ale decvoltarii sistemului. Nu doar programele sunt supuse test&rii, ci si cerinfele informationale si functionale ale sistemului (structurate in faza de analiza), solutiile generale de proiectare, specificatiile detaliate de proiectare (intocmite in fazele proiectarii logice si fizice), documentatia sistemului etc. Cele mai grave erori sunt cele derivate din identificarea incompleti sau formularea gresita a cerintelor. Insistim asupra ultimului principiu prezentat, tocmai pentru ca el este, adesea, ignorat in practic’, consecinfele fiind aparitia de costuri suplimentare, De aceea, una dintre activititile care trebuie realizati inainte de proiectarea si implementarea sistemului priveste verificarea ceringelor sistemului, Prin aceasté activitate nu se urmareste a stabili dac& cerinfele sunt corecte sau gresite, ci a determina dac& ele sunt complete. Altfel spus, se stabileste dact”: cerinjele sunt detaliate suficient, astfel incat s% permiti proiectarea si implementarea lor; cerinfele nu intra in contradictie unele cu altele. ‘Atingerea obiectivelor urmérite prin verificarea cerintelor presupune utilizarea a doud metode de lucru: mai intai se efectueazi inspectia cerintelor, urmata de schitarea planului de testare. Inspectia cerintelor presupune efectuarea unor verificari simple asupra documentului cerinfelor, intocmit la sfarsitul fazei de analiza, pentru a fi siguri c& el confine suficiente detalii si ch mu exist doul cerinfe contradictorii. Acesti operatiune trebuie realizati de autorul documentului, impreun& cu reprezentanti ai echipelor de proiectare, implementare si testare. Dupi finalizarea inspectiei cerintelor, echipa de testare va intocmi o schit’ a planului de testare, prin care se stabileste ct de detaliat sunt formulate cerinjele. Dac& se constaté. dificultéti in elaborarea testelor pe baza documentatiei, atunci este de asteptat c& nici proiectanfii sau programatorii s& nu poaté implementa aceste cerinfe. in cel mai bun caz, ei vor incerca si citesc printre randuri si si deduc& propriile solutii, care ar putea fi in contradictie cu asteptirile utilizatorilor. 6.2.2 Tehnici de testare Tehnicile de testare au un caracter preponderent euristic si empiric, mai pusin fundamentate teoretic, ceea ce explich multitudinea tehnicilor prezentate in literatura de specialitate. Importanta este alegerea unei strategii prin care si se selecteze tehnicile cele mai adecvate pentru atingerea obiectivelor definite in faza de planificare a testarii. Pentru a fi in misurd de a alege cele mai potrivite tehnici de testare, este necesara cunoasterea modalitatilor de clasificare a lor. 6.2.2.1 Clasificarea tehnicilor de testare in literatura de specialitate, tehnicile de testare sunt grupate dupa diverse criterii. Mosley diferenfiaza testele in functie de modul in care acestea angajeaza tehnici dinamice sau statice, precum si in functie de modul de efectuare, automat sau manual”. Testarea staticd inseamna verificarea programelor sursi fir’ ca acestea si fie lansate in executie, Multe din aceste tehnici sunt aplicate la testarea rezultatelor fazelor de analiza gi proiectare sau a documentatiei sistemului. Testarea dinamicd implica execusia programelor. Pomind de la un set de date de intrare se va lansa in executie programul si se vor compara rezultatele executiei programului cu rezultatele scontate. Testarea automatdi este efectuata sub controlul calculatorului, in timp ce testarea manual se desfagoara sub controlul omului ‘Cele dow’ moduri de clasificare sunt relativ redundante, in sensul c majoritatea tebnicilor de testare manual se regisesc si in categoria tehnicilor de testare staticd, atat timp cét, in 31, Richard, LK. Testing Requirements, www gantthead.com (accesat 18.01.2006), 32, Mosley, D.J. — The Handbook of MIS Application Software Testing, Yourdon Press, Englewood Cliffs, New Jersey, 1993,18 PROIECTAREA SISTEMELOR INFORMATIONALE rezultatele Gatelor de ES obtinute Intrare Fig. 6.2 Schema generald a procesului de testare (adaptare dup& van Vliet, H. — Software Engineering. Principles and Practicies, John Wiley & Sons, LTD, Chichester, 2000, p. 401) Prima activitate se refer la definirea strategiei, care are drept scop definirea setului minim al datelor de test care s& satisfac& cerintele testarii, cuantificate prin intermediul criteriilor de acceptabilitate. De exemplu, criteriile de acceptabilitate pot fi exprimate astfel: la testare se va urmiiri execufia cel putin o data a tuturor instructiunilor din program; prin testare se va urmari executia tuturor ramurilor logice din program etc. Evident c& cele dou exemple ‘nu sunt echivalente, intru-cat primul criteriu nu permite testarea ramurilor vide. Dupa stabilirea criteriilor de acceptabilitate, se va trece la generarea setului de teste care SA raspunda acestor criterii, adicd a unui subset al datelor de intrare in P. Aceast activitate nu se desftisoari la intamplare, ci de-o maniera sistematicd, apeland la diferitele tehnici de testare pe care le avem la dispozitie. in functie de tehnicile de testare alese se va genera si subsetul datelor de test. Odat& definit setul de teste, se va trece la determinarea rezultatelor asteptate pentru fiecare test in parte si apoi la execusia componentei P. in final, se realizeazi compararea rezultatelor obtinute in urma execufiei cu cele asteptate, eventualele diferente semnaland existenfa unor erori, ce vor fi transmise spre rezolvare proiectantilor sau programatorilor responsabili de componenta testatd, Rezultatele testirii vor fi consemnate intr-o documentatie special. Existi cdteva principii generale care ghideaz& activitatea de testare a programelor: 1. Testele trebuie concepute astfel incdt sé urmareascd respectarea cerinfelor utilizatorilor. Cele mai numeroase erori sunt legate de nesatisfacerea cerinfelor sistemului, identificate si formulate in faza de analiza. 2, Testele trebuie planificate cu mult timp inainte de inceperea activitétii de testare. Toate testele trebuie planificate si proiectate inainte de scrierea/ generarea programelor sursi, chiar din timpul analizei sistemului odati ce modelul cerintelor sistemului este complet. Definirea detaliati a cazurilor de test poate incepe inc& din timpul fazei de proiectare, odata cu intocmirea specificatiilor de proiectare. 3. Testarea trebuie sa inceapé cu detaliile, desfésurata la nivelul modulelor componente, iar, pe mésurd ce ea progreseazd, atentia va fi indreptatd spre identificarea erorilor de integrare a acestor componente $i, in final, asupra intregului sistem. 4, Testarea exhaustivi nu este posibild. Numérul cazurilor de test, derivate din combinarea tuturor situatiilor posibile, este foarte mare chiar si pentru programele de Gimensiuni mai mici, De aceea, este necesari utilizarea unor tehnici speciale de definire a cazurilor de test care s4 corespunda criteriilor de acceptabilitate. 5. Pentru a fi eficient’, testarea trebuie sé fie realizata de persoane care nu au fost implicate in fazele anterioare de dezvoltare a sistemului. Chiar dacé acest principiu nu trebuie interpretat in mod absolut, totusi, de cele mai multe oi, persoanele implicate in crearea sistemului nu sunt cele mai indicate in realizarea testirii programelor, cu exceptia aplicatiilor de dimensiuni mai mici,IMPLEMENTAREA SISTEMULUI nT * identificarea factorilor de risc si a modalitatilor strategice de eliminare sau de diminuare a riscurilor, © apelarea la diagramele Gantt pentru urmirirea modului de desfasurare a etapei de implementare; © folosirea tehnicii PERT pentru identificarea activitatilor critice. Planul de implementare are un rol esential in derularea activitatilor specifice si de el depind calitatea sistemului si momentul in care poate dat in exploatare. Faria face neaparat 0 ierarhie, se considera c& planificarea implementarii ocup’ unul din primele locuri intre factorii de succes sau esec al unui proiect, pentru ca prin implementare se asigur’, pana la urma, functionarea sistemului. 6.2 Testarea sistemelor informationale Dezvoltarea rapida a tehnologiilor informationale a determinat extinderea rapida a ariei de informatizare, conditii in care calitatea existentei noastre depinde din ce in ce mai mult de calitatea sistemelor informatice cu care lucrém. De aceea, trebuie acordati o atentie deosebiti activititilor de testare. Testarea este ultima ocazie pentru revizuirea cerinfelor sistemului, a specificatiilor de proiectare si a programelor surs&. Obiectivul general al testarii il reprezint& dentficarea mumrald maxim de eror cu fort mini. general, cheltuielile asociate activitatii de testare pot ajunge pana la o pondere de 30- 40% din totalul cheltuielilor necesare dezvoltarii unui sistem informatic. In domeniile cu activitati critice (controlul traficului aerian, monitorizarea reactoarelor nucleare etc) aceste cheltuieli pot fi de 3-5 ori mai mari decat toate celelalte cheltuieli cu dezvoltarea sistemului informatic”. 6.2.1 Aspecte generale privind organizarea te Testarea este un termen mai general care face referire la alte dou nofiuni: verificarea si validarea. Verificarea reprezint’ procesul de evaluare a sistemului sau a unei componente a lui, pentru a se determina dacd o anumiti functie a fost implementata corect, oferind réspunsul la intrebarea: A fost construit bine sistemul? Validarea poate fi definita ca procesul de evaluare a sistemului sau a unei componente a lui, pentru a se determina dac8 sunt respectate cerintele functionale identificate in faza de analizi, raspunzind la intrebarea: A fost construit sistemul care trebuie? Asadar, verificarea vizeazi modul cum a fost construit sistemul, iar validarea se referd la ce a fost construit, Atit verificarea, cat si validarea trebuie desfisurate pe parcursul intregului proces de dezvoltare a sistemului, nu doar la sfarsitul acestuia. Practic, testarea intregului sistem nu este posibila, deoarece ea nu ar fi fezabila economic si tehnic. Un exemplu simplu este edificator: daci un program confine doua structuri de control repetitive imbricate, fiecare din cele dow’ structuri presupunand un numar de iteratii cuprins fntre 1 si 20, iar structura de control interioar& contine patru structuri de control alternative simple, atunci numérul ramurilor logice din program care trebuie testate va fi de 10"! Din acest motiv, activitatea de testare trebuie organizati in mod riguros si eficient. in general, testarea implica elaborarea planurilor testelor, stabilirea standardelor testarii, precum si incadrarea intregii activitayi de testare in ciclul de viafa al sistemelor, in vederea asigurarii completitudinii planurilor de testare a programelor si sistemului cdruia apartin. intr-o forma schematicd, principalele activitati care formeaza procesul de testare sunt evidentiate in figura 6.2. P reprezint& obiectul supus test&rii, respectiv un modul de program, specificatiile procedurale sau intregul sistem. 30. Pressman, RS. — Software Engineering. A Practitioner's Approact, Fifth Edition, McGraw-Hill Publishing ‘Company, London, 2000, p.426.16 PROTECTAREA SISTEMELOR INFORMATIONALE 6.1 Planificarea implementarii in timpul implementirii, vor fi executate simultan mai multe activitaji. De aceea, ele trebuie si fie planificate si programate de citre o echipa de implementare format din utilizatori, manager si specialisti in proiectarea sistemelor. Planificarea implementirii, firesc, incepe anterior demararii unei astfel de actiuni. De fapt, problemele implement&rii sunt abordate chiar la inceputul proiectului, iar aspectele conceptuale si strategiile implementirii si conversiei sistemelor trebuie sa fie luate in discutie fn fiecare stadiu al ciclului de viaf’ al sistemelor. Totusi, planurile detaliate de implementare nu pot fi finalizate pini cind conducerea nu aprob& proiectul noului sistem. Planul de implementare este revizuit si modificat la interventiile comitetului de informatizare, ale utilizatorilor, ale conducdtorilor sistemului, inainte de a incepe operafiunea de implementare. Un plan de implementare evidentiazi toate activititile necesare, ajutind pe cei ce-1 intocmesc s& fie siguri c& totul a fost prezentat corect. Prin el se vor consemna toate activitatile de efectuat, precum si timpul alocat. Responsabilititile de executie trebuie si fie foarte clare, De asemenea, trebuie estimate costurile fiecdrei activitati astfel incat si poatd fi elaborat un buget special. fn acelasi timp, trebuie determinate reperele de executat in timp, pentru a putea fi controlate. Mai dificil este de estimat momentul cénd se va finaliza implementarea. De fiecare dati utilizatorii sunt cei care isi dau acceptul final, iar procesul, teoretic, poate fi considerat ca desfasurdindu-se pe o perioada nedefinita. Fig. 6.1 Principalele activitdfi ale etapei de implementare Planificarea, coordonarea si controlarea activititii de implementare sunt cel mai des realizate prin doua tehnici cunoscute: diagramele Gantt si PERT. Dintre cele mai relevante aspecte ale planificarii implementfrii, pot fi enumerate © incepe odati cu luarea startului conceperii unui nou proiect; «© se incheie odaté cu aprobarea dati pentru inplementare; aprobarea planului de implementare, firesc, se obfine inainte de a incepe aceasti etapa; © identificarea activitatilor principale, a desftgurarii lor calendaristice, a responsabilitatilor, precum si a rezultatelor finale ale acestora; » urmirirea riguroasa a modului in care se respect planul de implementare;CAPITOLUL VI Implementarea sistemului Dintre toate etapele dezvoltarii sistemului, implementarea are gradul de rise cel mai mare. Acest lucru se datoreazi faptului cd, in timpul etapelor anterioare (microanalizi, analizi, proiectare), proiectul de dezvoltare este desftigurat intr-un mediu ce nu afecteaza activitatile zilnice ale firmei. in schimb, implementarea presupune influentarea operatiunilor economice reflectate de c&tre sistemul dezvoltat, prin faptul c’ ea consti in inlocuirea efectiva a sistemului vechi, cea ce inseamna c& orice eroare nedepistat’ nici acum poate declansa grave probleme. De aceea, este necesar ca activitatile etapei de implementare si fie planificate si gestionate cu atenfie pentra a minimiza cét mai mult potentialele efecte negative si si se conceapa un plan de actiune pentru evenimentele neprevizute. Implementarea este procesul de transformare a componentelor proiectate intr-un sistem functional. De regula, proiectarea fizick se concretizeaz& intr-un rapart al proiectérii fizice a sistemelor, intocmit cu scopul furnizarii informafiilor necesare factorilor de decizie pentru a efectua ultimele verificari si pentru a-si da sau nu acceptul de trecere la etapa de implementare. intr-o forma destul de concentratd, in caseta 6.1, prezentim confinutul unui astfel de raport pentru firma ABC. Caseta nr. 6.1 ~ Confinutul raportului proieetirit fizice S.C. ABC Raportul proiectirii fizice a sistemelor I. Sinteza proiectani fizice a sistemelor I Prezentarea generald a scopului proicctului si sinteza Ia zi a constatérilor de pe teren IIL. Recomandirile principale ale proiectari fizice Proiectarea iesirilor Proiectarea intririlor Proieciarea bazelor de date Proiectarea prelucritilor (softului) Proiectarea echipamentelor Proiectarea controalelor Proiectarea procedurilor de lucru IV. Ipoteze de lucru si probleme nerezolvate V. Coneluziit V1. Anexe si glosar de termeni Implementarea sistemelor este procesul de instalare @ echipamentelor i softulul, in vederea finalizSrii sistemului si darii Tui in functiune. Operatiunea se deruleaza printr-un set bine definit de activitati, redate in fig. 6.1 AAWAYREry PROIECTAREA SISTEMELOR INFORMATIONALE 6. De ce modulele de program trebuie sé fie independente functional? 7. Explicafi de ce douk module cuplate prin informatii de control sunt dependente functional intre ele. Care sunt efectele negative ale acestui tip de cuplare? Care este diferenta intre coeziunea secventiala si cea comunicationala? De ce, in unele situatii, nu este eficienti descompunerea unui modul cu coeziune comunicafionala in doud sau mai multe module cu coeziune funcfionala? Probleme 1. Dafi un exemplu de pseudocod care si confing o structuri de control altemnativ generalizatt. 2. Dati un exemplu de pseudocod care s& contin o structura de control repetitivl cu un numar definit de pasi 3. Dati exemple din propriul studiu de caz de module caracterizate de urmitoarele tipuri de coeziune: functionalé, secvenfial’, comunicationala. 4, Dafi céte un exemplu, din propriul studiu de caz, de cuplare prin date elementare i prin informatii de control.PROIECTAREA PROCEDURILOR $1 A PROGRAMELOR 3 © Evaluarca structurii programului in vederea reducerii cuplarii si imbundtatirii coeziunii. in scopul sporirii independentei functionale a modulelor, ele pot fi descompuse sau recompuse. Necesitatea descompunerii modulelor apare atunci cand existd prelucrari comune dows sau mai mmultor module, cea ce impune redefinirea acestor prelucriri ca module separate coezive. De asemenea, in cazul modulelor cu un grad mare de cuplare se poate realiza unirea lor in unul singur, in vederea reducerii complexititii interfefei, a fluxurilor de control si a referingelor la dare globale. ‘© Minimizarea structurilor in care un modul are in sfera sa de control prea multe module. De regula, odati cu cresterea nivelului de detaliere ereste $i numarul modulelor care apeleazi un modul (fan-in). Mentinerea sferei efectelor unui modul in limita sferei sale de control. Sfera efectelor unui modul cuprinde toate modulele care sunt afectate de 0 decizie localizata in modulul respectiv. Sfera de control este formats din toate modulele subordonate ierarhic modulului respectiv. ‘© Evaluarea interfefelor dintre module in vederea reducerii complexititii sia redundanfei. Complexitatea interfejelor reprezinta principala cauzi a erorilor de programare. Interfefele trebuie proiectate astfel incat sé fie transmise de Ia un modul la altul numai informafiile semnificative pentru functiile celor dou module. Rezumat La baza orictrui program stau nofiunile de insiructiune (declarativa) $i modul, Instructiunile constituie ce! mai de jos nivel al operafiunilor ce pot fi executate intr-un limbaj de programare, ele fiind astfel grupate incat s& constituie anumite structuri executabile de calculator. Modulul este 0 colectie sau o forma grupatd de instructiuni de programe sursi. Modulele se pot grupa pentru a forma programele. {n proiectarea programelor pot fi distinse dow mari activiti: proiectarea arhitecturii programelor si proiectarea logicit modulelor. Arhitectura unui program defineste componentele acestuia, proprietatile jor vizibile din exterior, precum si relatile dintre componente. Prin componenti facem referire la modulele de program, iar proprietajile lor vizibile din exterior sunt functia si interfefele. Relafile dintre ‘module asigura transmiterea controlului executiei si tansferul structurilor de date. Rafinarea arhitecturii, presupune aplicarea unor concepte si reguli practice de proiectare care privese imbundtifirea calitafii programului, Calitatea programelor este apreciati prin prisma usurintei implementiri, testrii, inreyinerii $i modificdrii lor si are 1a baz conceptul de independenté functionala. Conform acestuia, fiecare modul de program s& fie proiectat si realizeze o singur& fimctie, bine definita, a programului Independenja functionala este misurat& prin intermediul a doi indicatori calitativi: coeziunea si cuplarea. Coeziunea este misura legdturilor interne dintre componentele de prelucrare sau instructiunile ‘unui modul, iar cuplarea reflecté gradul de interconectare a modulelor de program. Existi mai multe tipuri de coeziune si cuplare, scopul oricarui proiect software flind coeziunea functional si cuplarea prin date clementare. Rafinarea arhitecturii objinute in urma transpunerii diagramelor fluxurilor de date const fn recompunerea sau descompunerea unor module pentru a se obfine o coeziune maxims si o cuplare minima. Dup& ce proiectarea structurii programului a fost finalizatd, se trece la cea de-a doua activitate, proiectarea logicii modulelor. Pentru redarea logicii modulelor se pot utiliza mai multe instrumente: pseudocodul, tabelele sau arborii decizionali, diagrama starilor de tranziie etc. inerebari recapituta 1. Definiti umatoarele concepte: program, modul de program, athitectura programelor, logica modulului de program. Care este diferenta dintre o dati elementara si o informatie de control? Explicati rolul coeziunii si cuplarii in proiectarea programelor. Deserieti cele cinei principi utiliza in proiectarea programelor. Explicati de ce un modul cu coeziune functionalé este usor de testatu2 PROIECTAREA SISTEMELOR INFORMATIONALE Sa ne reamintim c& 0 primi formé a structurii programului, reprezentat& cu ajutorul diagramei de structuré, a fost obfinut’ in urma aplicarii celor dou strategii: analiza transformarilor gi analiza tranzactiilor. Ele prezint& numeroase avantaje: © Proiectarea ierarhict se realizeazi prin metoda rop-down, similar descompunerii functionale, * Deoarece proiectele au la baz funciile de prelucrare din unitate, ca si relatiile dintre ele, conexiunile dintre modulele programelor vor avea o forma similar’. Schimbarile din structura functiilor se vor reflecta si in structura programelor. © Criteriile de descompunere a ramurilor aferente si eferente sunt incluse in strategia proiectarii, Ca atare, procedurile de intrare si iesire sunt localizate in locuri diferite ale sistemului, ceea ce va asigura o intrefinere performanta © Se oferd certitudinea c& structura programului corespunde structurii problemei intr-o foarte mare misur. Prin diagramele fluxurilor de date se poate realiza descrierea fidela a functiilor principale ale intreprinderii si, in consecinf&, sistemul le va respecta intocmai. © Se asigura consistenta proiectelor datoriti uniformitatii criteriului de partitionare. Pe aceasta cale, se ajunge ca doi sau mai multi proiectanti si aiba rezultate comparabile. fns&, dincolo de aceste avantaje, la proiectarea programelor trebuie si se urmireasci atingerea unor obiective de calitate, cum ar fi: functionare corecté, si fie sigur, usor de folosit, implementat, intretinut si testat, si foloseasca eficient resursele sistemului informatic, si fie usor adaptabil diverselor medii de operare 5.a. Dup cum am vazut in paragrafele anterioare, la baza calititii programelor sti conceptul de independenf& functionala, apreciat cu ajutorul cuplaii si coeziunii Cuplarea si coeziunea prezint& o important crucial in proiectarea sistemelor informatice, demonstrat prin urmitoarele argumente*: © Se reduce comunicarea intre membrii echipei de dezvoltare a sistemului, deoarece permite uarea unor decizi fara a lua in considerare deciziile si activitatile care privesc alte module; * Se reduce probabilitatea propagiirii modificarii unui modul c&tre alte module, ceea ce reduce costurile intretinerii; © Sporeste gradul de reutilizabilitate a modulelor, in cazul reproiectirii sistemului sau a proiectirii unui sistem asemanator; © Creste inteligibilitatea modulelor; simplitatea interfefelor dintre module faciliteaza infelegerea unei componente a programului, independent de contextul in care este utilizata; * Studiile empirice arata c& proiectele caracterizate de 0 coeziune putemnica si o cuplare redus& sunt mai putin supuse erorilor. Cuplarea si coeziunea se situeazi uneori pe pozitii contradictorii, in sensul ci 0 coeziune buna a modulelor unui program va determina un grad mare de cuplare a acestora. De aceea, la rafinarea arhitecturii sistemului informatic cele dou caracteristici trebuie analizate impreund. in practic’, nu este necesara stabilirea tipului de coeziune pentru fiecare modul, ci este necesara injelegerea deplini 2 conceptului in vederea recunoasterii si evitarii tipurilor de coeziune cele mai slabe. Ar fi ideal ca toate modulele unui program sé fie caracterizate de coeziune functionali, ins& practic acest lucru este imposibil. Structura programului poate fi imbun&tatita prin reanalizarea diagramei de structura si aplicarea urmétoarelor recomandari™: 28. van Vliet, H. — Software Engineering. Principles and Practice, John Wiley & Sons, Ltd., Chichester, 2000, 29, Presmann, RS. ~ Software Engineering. A practitioner's Approach, McGraw Hill Publishing Company, London, 2000, p. 348-350,PROIECTAREA PROCEDURILOR $I A PROGRAMELOR mn Modulele cu coeziune temporal sunt dificil de intretinut datorit’ nu numai multiplelor funcfii pe care le realizeazii dar si faptului acestea nu sunt dependente de fluxurile datelor sau fluxurile de control. Coeziunea logics in acest tip de coeziune legaturile dintre instructiunile unui modul sunt foarte slabe. Funcfiile unui astfel de modul sunt grupate impreund pe considerentul includerii lor intr-o categorie general, urmarindu-se evitarea redundantei in sotierea codului. Modulele cu coeziune logic implica un grad mare de cuplare, ordinea de executie a instructiunilor dintr-un astfel de modul find dictata din afara, prin intermediul unei informatii de control, Figierele DLL din mediul WINDOWS sunt, in cele mai multe cazuri, proiectate s& fie logic coezive. De exemplu, fisierul COMMDLG.DLL contine instructiunile pentra configurarea cAsutelor de dialog activate la utilizarea optiunilor File Open, File Save, Search si Print. Avantajul unei astfel de abordiri const in oferirea unei interfefe unice pentru intreaga aplicatie si scrierea de cod mai putin. Numai ci, daca proiectantii unei aplicatii in mediul WINDOWS doresc si nu se limiteze la facilititile oferite de COMMDLG.DLL, vor trebui sa serie propriul cod pentru a adauga noi facilititi. Ori, acest lucru este imposibil de realizat fara a dezmembra o bund parte a logicii programului. Coeziunea coincidental Este tipul de coeziune cel mai nedorit. Ea se manifesta atunci cénd intre elementele unui modul exist putine legituri sau chiar nici o legatura. Toate functiile pe care le realizeazi modulul au fost grupate cu totul intimplitor, ca urmare a neatenfiei proiectantului sau din doringa acestuia de a economisi timp cu activititile de proiectare si programare. in mod normal, modulele cu coeziune coincidentala sunt foarte rar intalnite (sau cel putin ar trebui). Page-Jones a dezvoltat 0 diagram’ foarte utilé pentru infelegerea tipurilor de coeziune, el ordondndu-le intr-un arbore decizional, redat in oe 5.13 )}—$ A rrnetionatt Sepoate considera ct sol aio sevens (Oa) Servet? “= Seo impor? o—— nunc ce eff Severn (Bi) —— Procedurat? feriie in ec prea ale modululiy? ec ‘importa? oo SES G)— coincisentar Fig, 5.13 Arborele de decizie privind tipurile de coeziune a modulelor fn acest paragraf dorim s& revenim la demersul proiectirii arhitecturii programelor, mai exact la ultima etapa — rafinarea structurii programelor.uo PROIECTAREA SISTEMELOR INFORMATIONALE succesiune in vederea calcularii salariului net, fiecare modul subordonat realizind calculul unui anumit tip de spor sau refinere. Prin urmare, se poate spune c4 modulul de control CALCUL_SPORURI_RETINERI_SALARII este coeziv functional. Coeziunea seeventiali Un modul este caracterizat de coeziune secvengiala atunci cénd realizeaz& functii multiple de prelucrare asupra acelorasi structuri de date. Ordinea in care sunt apelate functiile este foarte important. Rezultatele objinute prin execufia unei operatiuni (functii) devin intrari pentru urmatoarele. Asadar, prima functie (operatiune) va prelucra structura de date primita, dupa care rezultatul transformirii va constitui intrare pentru a doua functie, iar la randul ei iesirea celei de-a doua funcfie va constitui intrarea pentru cea de-a treia functie 5.a.m.d. Rezultatul objinut prin aplicarea ultimei funcfii va reprezenta iesirea modulului respectiv, Un exemplu general de coeziune secvenfiala este regasit Ia modulele care citesc datele dintr-un fisier, le prelucreaz& si apoi le afiseazi/tipareste intr-o anumité forma. Multiplele functii pe care le realizeazi un modul caracterizat de coeziune secventiala fac dificil intretinerea acestuia. ins, dezavantajul cel mai important este legat de limitarea reutilizirii unei functii interne a acestui modul de c&tre celelalte module din sistem. Acceptarea acestui tip de coeziune poate fi justificat’ de reducerea complexitatii interfefelor dintre modulele ce s-ar obfine prin descompunerea modulului, respectiv evitarea abuzului in utilizarea de variabile globale, Oricum, eventualele probleme cauzate de coeziunea secventiala pot fi inléturate prin descompunerea modulului respectiv in dou& sau mai multe module subordonate ierarhic. Coeziunea comunicationala intr-un modul caracterizat de coeziune comunicationala, multiplele functii pe care le realizeaz4 sunt legate intre ele tot prin datele pe care modulul le utilizeaz4, ins&, spre deosebire de coeziunea secventiali, succesiunea functiilor nu este importanta. De exemplu, un modul proiectat pentru inregistrarea unei facturi, va realiza urmitoarele functii: inserarea facturii in baza de date, actualizarea soldului clientului, actualizarea stocului pentru produsele vandute si generarea notei contabile. El este caracterizat de o coeziune comunicafionali, deoarece cele patru funcfii prelucreaz& aceleasi date, dar ordinea de realizare mu este important’. Coeziunea proceduralé Un modul prezinti coeziune procedurala atunci cand contine elemente grupate pe baza fluxurilor de control din cadrul programului, adic& functii independente, reunite doar pentru a asigura transferul controlului de la o functie interna Ja alta, dar a cdror secventi este importanta. Un exemplu de coeziune procedural este cel al unui program de actualizare a inregistrarilor, in cadrul ciruia se realizeazi adfugarea, stergerea sau modificarea unei inregistrari, Astfel, in functie de codul operafiunii care urmeazi sa fie executatd, programul transmite controlul uneia din cele trei functii de prelucrare. Coeziunea temporala Modulele caracterizate de coeziune temporalé grupeaz mai multe functii intre care nu existd até legiturd decat cea legat& de factorul timp, in sensul c& toate trebuie executate la un moment dat in executia programului, fiird ca secventa de executie a lor si prezinte importanta. Cele mai cunoscute exemple sunt modulele de initializare si cele de finalizare a programelor. La lansarea unui program, un modul poate fi conceput pentru a realiza initializarea variabilelor de memorie, conectarea la baza de date, deschiderea tabelelor necesare, configurarea mediului de lucru etc.PROIECTAREA PROCEDURILOR $1 A PROGRAMELOR 109 Cele trei tipuri de cuplare prezentate pnd acum sunt frecvent intélnite in practicd. Mai rar intalnite sunt ultimete doud tipuri de cuplare. nregutare comands oor] — i Fig. 5.12 Exemplu de cuplare prin informatii de control Cuplarea comund (common coupling) intervine atunci cand dou’ sau mai multe module acceseaz in comun aceleasi date elementare aflate intr-un loc comun, cunoscut si ca bloc de date. Limbajele FORTRAN gi COBOL au performante deosebite pentru gestionarea acestui tip de date aflate in blocuri. Cuplarea prin conginut (content coupling) este considerata ca fiind cea mai de nedorit forma de cuplare. Ea presupune implicarea direct a unui modul in intimitatea prelucrarilor altuia. De exemplu, un modul poate si schimbe datele altuia sau, mai grav, si schimbe instructiunile acestuia. Se poate vorbi de o adevaratd increngiturd a modulelor, fri sé mai fie pusi in discufie limita independenfei acestora. Din fericire, limbajele performante nu accept astfel de cuplari. 5.3.2 Coeziunea Misura in care toate instructiunile unui modul se refera la una si aceeasi functie se numeste coeziune. in timp ce cuplarea se referi la conexiunile externe dintre module, coeziunea se preocupa de legaturile dintre elementele interne modulelor, ea fiind o masuri interna a calititii proiectului. Se spune c& idealul ar consta intr-o coeziune maxima, adic& un modul s& realizeze o singura functie (sarcina). Cercetitorii au sesizat sapte niveluri ale coeziunii. in ordinea valorii lor, de la cea mai bund la cea mai slab’, aceste niveluri sunt: functionala, secventialé, comunicationala, procedural, temporal, logic si coincidental. Scala valorilor coeziunii este neliniara, in sensul c& tipurile de coeziune cele mai slabe sunt mult mai ,rele” decat tipurile de coeziune medii care sunt ,destul de bune” in comparatie cu tipurile de coeziune cele mai bune. Coeziunea functional Un modul cu coeziune funcfionala este cel mai dorit intrucat instructiunile Tui au ca obiectiv realizarea unei funefii sau activititi. Comportamentul acestor module este tipic cutie! negre, in sensul c& pentru folosirea lor trebuie cunoscute doar intririle si iesirile modulului, {fara sA intereseze prelucrarile Iui interne. O modalitate deosebita de testare a coeziunii functionale a unui modul o constituie atribuirea numelui de modul. Dack modulul poate fi descris ca realizind o singura functie asupra unei singure structuri de date, atunci functionalitatea lui este asigurata. Astfel de exemple sunt: CALCUL_DOBANDA, ACTUALIZARE_STOC, CALCUL_IMPOZIT_SALARIU,. La numirea modulelor vor fi evitate elementele de legaturd (si, ,_”), cea ce poate sugera ca modulul respectiv realizeaz’ mai mult decét o singura fumcfie si ar putea fi necesara descompunerea acestuia. Aceast& caracteristica este valabild pentru modulele aflate pe nivelurile inferioare ale structurii ierarhice a programului, dar nu si pentru modulele situate pe nivelurile superioare, care au ca rol controlul executiei programului, in primul rénd, si nu realizarea unor sarcini elementare. De exemplu, modulul CALCUL_SPORURI_RETINERI_SALARII este un modul de control a cdrui functie consti in apelarea modulelor subordonate ierarhic intr-o anumité