Proiectarea Sistemelor Informatice - Curs 2 - 2024-2025 (PDF)

ACADEMIA DE STUDII ECONOMICE BUCUREŞTI FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ PROIECTAREA SISTEMELOR INFORMATICE -CURS 2- BUCUREȘTI 2024-2025 IDENTIFICAREA CERINŢELOR SISTEMELOR INFORMA...

ACADEMIA DE STUDII ECONOMICE BUCUREŞTI FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ PROIECTAREA SISTEMELOR INFORMATICE -CURS 2- BUCUREȘTI 2024-2025 IDENTIFICAREA CERINŢELOR SISTEMELOR INFORMATICE Cuprins ✔Problematica ingineriei cerinţelor ✔Categorii de cerinţe ale sistemelor informatice ✔Cerinţe non-funcţionale ✔Tehnici pentru identificarea cerinţelor ✔Caracteristici de calitate ale cerinţelor PREMIZE ⮚ Slaba calitate a cerinţelor este în mod constant pe primele locuri în ierarhia cauzelor care duc la eşecul proiectelor software. ⮚ O explicaţie ar fi aceea că echipele de dezvoltare alocă prea puţin timp înţelegerii problemelor reale ale afacerii, a nevoilor utilizatorilor sau a naturii mediului în care va rula sistemul. ⮚ De asemenea, dezvoltatorii încearcă să furnizeze cât mai rapid soluţii tehnice, plecând însă de la înţelegerea insuficientă a cerinţelor problemei. IDENTIFICAREA CERINȚELOR ⚫ Activitatea de analiză a sistemului trebuie să urmărească în principal identificarea şi definirea detaliată a cerinţelor, de comun acord cu beneficiarul, în paralel cu analiza datelor şi proceselor. ⚫ Reprezintă procesul prin care culegem și documentăm cerințele sistemului. ⚫ Identificarea şi definirea detaliată a cerinţelor se realizează de comun acord cu beneficiarul. ⚫ Pot fi identificate: ✔Cerinţe care rezolvă sau reduc deficienţele sistemului existent. ✔Cerinţe care exprimă noi facilităţi. Ele nu sunt asigurate de vechea implementare a sistemului. ⚫ Se identifica cerinţele funcţionale şi cerintele nefuncţionale. IDENTIFICAREA CERINȚELOR ⚫ Aspecte practice: ▪ Cu cât descoperim mai multe cerințe, cu atât va fi mai bun sistemul construit. ▪ Cerințele se schimbă. ▪ Pot exista cerințe care sunt deja implementate. ▪ Cerințele pot fi: ✔explicite – furnizate de beneficiar; ✔implicite – le descoperă analistul. PROBLEMATICA INGINERIEI CERINŢELOR Pentru a fi siguri că un sistem informatic rezolvă în mod corect o anumită problemă, trebuie, mai întâi, să se înţeleagă în mod corect problema care trebuie rezolvată. În acest sens sunt necesare descoperirea, înţelegerea, specificarea şi analiza următoarelor componente: ⮚CE problemă trebuie rezolvată; ⮚DE CE o astfel de problemă necesită rezolvare; ⮚CINE este implicat şi va fi responsabil de rezolvarea acestei probleme. În mare, aceste trei componente, stau la baza Ingineriei Cerinţelor Sistemelor Informatice. PROBLEMATICA INGINERIEI CERINŢELOR Activităţi de bază pentru construirea unui model al cerinţelor PROBLEMATICA INGINERIEI CERINŢELOR Deseori, dificultăţile în modelarea şi analiza cerinţelor provin din înţelegerea insuficientă a părţii de logică a sistemului/aplicatiei, cunoscută şi sub denumirea de logică a afacerii. Logica afacerii reprezintă elementul definitoriu pentru o afacere aflată în proces de modelare şi de automatizare, ea incluzând atât regulile afacerii, cât şi fluxul de lucru (procesele) din cadrul afacerii prin care se descrie modul de transfer al documentelor sau al datelor de la un participant (persoană fizică sau sistem software) la altul. În dezvoltarea de sistemelor informatice, logica afacerii are ca obiective: – modelarea obiectelor afacerii din lumea reală (precum stocuri, clienţi, produse); – gestionarea modului de stocare a obiectelor afacerii (maparea obiectelor afacerii în tabelele bazei de date); – descrierea modului în care obiectele afacerii interacţionează între ele. CATEGORII DE CERINŢE ALE SISTEMELOR INFORMATICE În dezvoltarea sistemelor informatice, o cerinţă defineşte un deziderat pe care acesta trebuie să-l îndeplinească, ca răspuns la necesităţile utilizatorilor săi. Ea reprezintă o parte a scopului pentru care se dezvoltă un proiect informatic. Cerinţele dictează şi modul în care sistemul trebuie să răspundă la interacţiunea cu utilizatorul. În linii mari, dezvoltatorii trebuie să aibă în vedere următoarele aspecte legate de cerinţele unui sistem: – folosirea unui limbaj tehnic: cerinţele trebuie întotdeauna specificate în limbajul utilizatorului, putând include aici şi jargonul domeniului analizat; – relaţia cu obiectivele afacerii: fiecare cerinţă trebuie în mod clar legată de obiectivele oamenilor de afaceri. CATEGORII DE CERINŢE ALE SISTEMELOR INFORMATICE Prin procesul de inginerie a cerinţelor se urmăreşte culegerea, elaborarea, corectarea şi adaptarea unui volum mare de specificaţii, care diferă în ceea ce priveşte scopul şi modul de exprimare. O astfel de diferenţiere se poate realiza între cerinţele: – descriptive; – prescriptive. Specificaţiile descriptive prezintă proprietăţi pe care sistemul trebuie să le aibă indiferent de modul în care acesta va funcţiona. Astfel de proprietăţi sunt generate, de obicei, de legi ale naturii sau de constrângeri fizice. Exemple de specificaţii descriptive: ❑Aceeaşi carte nu poate fi împrumutată de doi abonaţi în acelaşi timp. ❑Dacă o cameră a hotelului este în renovare, atunci aceasta nu poate fi ocupată. CATEGORII DE CERINŢE ALE SISTEMELOR INFORMATICE Specificaţiile prescriptive descriu proprietăţile pe care se doreşte să le aibă sistemul informatic şi pe care acesta le îndeplineşte sau nu, acest lucru depinzând de modul în care sistemul va funcţiona Exemple de specificaţii prescriptive sunt: ❑Un abonat nu poate să împrumute mai mult de trei cărţi în acelaşi timp. ❑Un produs trebuie livrat în intervalul orar specificat de cumpărător. Distincţia dintre specificaţiile descriptive şi cele prescriptive este foarte importantă în contextul ingineriei cerinţelor, în sensul că putem negocia, schimba sau găsi alternative pentru specificaţiile prescriptive, în timp ce pentru cele descriptive aceste lucruri nu sunt posibile. CATEGORII DE CERINŢE ALE SISTEMELOR INFORMATICE Prin prisma funcţionalităţii, cerinţele unui sistem sunt de două tipuri: – funcţionale ; – non-funcţionale. Cerinţele funcţionale definesc funcţiile unui sistem informatic sau ale componentelor acestuia, prin intermediul unui mulţimi de intrări, ale comportamentului şi a ieşirilor. În această categorie putem încadra calcule, detalii tehnice, informaţii privind procesarea şi manipularea datelor, precum şi alte funcţionalităţi care arată, de exemplu, cum trebuie realizat un caz de utilizare. CATEGORII DE CERINŢE ALE SISTEMELOR INFORMATICE Cerinţele non-funcţionale surprind criteriile care pot fi folosite pentru a analiza aspectele legate de operaţionalitatea sistemului, şi nu de comportamentul acestuia. Acestea impun constrângeri la nivel de proiectare sau de implementare asupra cerinţelor funcţionale (de exemplu, cerinţe legate de performanţă, securitate sau fiabilitate). Cerinţele non- funcţionale sunt deseori referite prin termenul de calităţi ale unui sistem, dar pot fi menţionate şi ca atribute de calitate, obiective de calitate, caracteristici de calitate sau constrângeri. CERINŢE NON-FUNCŢIONALE Tipuri de cerinţe non-funcţionale CERINŢE NON-FUNCŢIONALE A. Cerinţele de calitate definesc aspecte referitoare la “cât de bine” trebuie să funcţioneze sistemul. Acestea includ specificaţii legate de: – Cerinţele de siguranţă care sunt cerinţe de calitate prin care se preîntâmpină producerea unor accidente sau degradarea mediului. – Cerinţele de securitate descriu măsuri de protecţie a sistemului împotriva unor comportamente nedorite. Cerinţele de confidenţialitate arată că anumite informaţii nu pot fi divulgate părţilor neautorizate. Cerinţele de integritate arată că anumite informaţii pot fi modificate dacă acest lucru a fost realizat într-o manieră corectă şi autorizată. Cerinţele de disponibilitate se referă la faptul că anumite cerinţe sau resurse pot fi folosite de către persoanele autorizate atunci când este necesar. CERINŢE NON-FUNCŢIONALE A. Cerinţele de calitate -continuare – Cerinţele de fiabilitate constrâng sistemul informatic să funcţioneze aşa cum este de aşteptat şi de dorit, pentru perioade lungi de timp. Exceptând circumstanţele excepţionale, sistemul trebuie să furnizeze servicii într-o manieră corectă şi robustă. – Cerinţele de performanţă impun condiţii asupra modului în care operează sistemul, cum ar fi, spre exemplu, timpul maxim necesar pentru execuţia unei operaţii. – Cerinţele de interfaţă arată cum interacţionează sistemul cu mediul, utilizatorii, precum şi cu alte sisteme. CERINŢE NON-FUNCŢIONALE B. Cerinţele de conformitate impun condiţiile necesare astfel încât sistemul să funcţioneze în conformitate cu legile naţionale, reglementările internaţionale, normele sociale, constrângerile politice şi culturale, standarde etc. C. Cerinţele arhitecturale impun constrângeri structurale asupra sistemului informatic, astfel încât acesta să poată funcţiona corespunzător în mediul unde va fi implementat. Oferă dezvoltatorilor indicaţii privind tipul de arhitectură potrivită pentru sistem. D. Cerinţele de dezvoltare sunt cerinţe non-funcţionale care constrâng modul în care sistemul ar trebui dezvoltat, şi nu felul în care acesta ar trebui să satisfacă cerinţele funcţionale. Sunt inlcuse aici cerinţe privind costurile de dezvoltare, planul de livrare şi instalare, detalii referitoare la mentenanţă, portabilitate etc. EXEMPLE DE CERINŢE NON-FUNCŢIONALE Cerinţe de calitate – Siguranță Sistemul nu trebuie să mai funcționeze dacă temperatura exterioară scade sub 4 grade C. Sistemul nu trebuie să mai funcționeze în caz de incendiu. Sistemul nu trebuie să mai funcționeze în cazul în care se observă atacuri evidente. – Securitate Permisiunile de acces la date pot fi modificate numai de către administratorul de date al sistemului. Toate datele de sistem trebuie să fie copiate la fiecare 24 ore și copiile de rezervă stocate într-un loc sigur, care nu se află în aceeași clădire ca și sistemul. Toate comunicările externe între serverul de date și clienți trebuie să fie criptate. – Fiabilitate Sistemul trebuie să aibă o disponibilitate de 999/1000 sau 99%. Aceasta este o cerință de fiabilitate care presupune ca din fiecare 1000 de cereri ale serviciului, 999 trebuie să fie îndeplinite. – Performanță Sistemul va procesa un minim de 100 tranzacții pe secundă. EXEMPLE DE CERINŢE NON-FUNCŢIONALE Cerinţe de conformitate – Cerințe legale și de reglementare: Toate modificările aduse datelor utilizatorilor trebuie păstrate minim 6 ani. – Cerințe de licențiere: Sistemul este licenţiat pentru a fi utilizat simultan de către maxim 100 de utilizatori. Licenţele pentru soluţia de baze de date trebuie să permită lucrul cu până la 4 procesoare fără limită pentru lucrul cu memoria RAM şi dimensiunea bazei de date. Cerinţe arhitecturale – Persistența datelor va fi asigurată printr-o baze de date relațională. – Această baze de date va fi Oracle 18c. – Sistemul va rula 24 de ore pe zi, 7 zile pe săptămână. Cerinţe de dezvoltare – Modulul de raportare inclus în soluţia de bază de date trebuie să conţină un instrument de dezvoltare de rapoarte adiţionale. – Modulul de raportare inclus în soluţia de bază de date trebuie să aibă o interfaţa web de configurare şi acces proprie. SURSE PENTRU IDENTIFICAREA CERINȚELOR Cerințele le identificăm prin două modalități de bază: 1. De la beneficiar prin: ⮚Interviuri ⮚Ședințe comune ⮚Observații directe ⮚Prototipizare 2. Prin consultarea artefactelor ⮚Documente de intrare ⮚Rapoarte de ieșire ⮚Legislație ⮚.... ARTEFACTE Artefactele conțin orice informații existente despre sistem care pot fi culese din diverse surse: ▪ Documente preexistente despre funcționarea sistemului ▪ Eșantioane de date ▪ Chestionare ▪ Scenarii ▪ Prototipuri de interfețe ▪ Scheme conceptuale ▪...... În primul rând trebuie înțeleasă organizația, chiar și la nivel de bază: ▪ Cu ce se ocupă ▪ Care sunt fluxurile de lucru ▪ Ce politici a adoptat ▪ Cine sunt beneficiarii sistemului TIPURI DE ARTEFACTE Organizația ✔Organigrame ✔Planuri de afaceri ✔Politici ✔Rapoarte financiare ✔Procese verbale ale întâlnirilor ✔Fișe de post Domeniu ✔Cărți, studii, articole ✔Reglementările din domeniu ✔Rapoarte privind sisteme similare Sistemul existent ✔Rapoarte privind fluxul de informații, proceduri de lucru, reguli de afaceri ✔Rapoarte care conțin defecte, reclamații, solicitarea unor schimbări ✔Manuale de utilizare ANALIST Responsabilități legate de cerințe: ⮚Culege ⮚Documentează ⮚Analizează ⮚Validează În cadrul echipei: ⮚Reprezintă legătura dintre client și dezvoltator ⮚Rol important în evoluția proiectului ⮚Gestionează activități în contextul schimbării cerințelor, luării unor noi decizii de dezvoltare sau apariției unor riscuri ANALIST Documentează specificațiile cerințelor ⮚Modelează cerințele ⮚Reprezentări grafice ⮚Ecuații ⮚Diagrame ⮚Tabele ⮚Prototipuri de interfețe Gestionează procesul de validare a cerințelor ⮚Cerințele culese îndeplinesc caracteristicile de calitate necesare pentru ca sistemul descris să satisfacă nevoile beneficiarului PROBLEME LEGATE DE IDENTIFICARE CERINȚELOR ✔Surse distribuite și conflictuale ✔Dificultatea de a accesa sursele ✔Cunoștințe tacite/ascunse (Cunoștințe care sunt implicite din punct de vedre al beneficiarului sau cu care sunt atât de familiarizați încât le consideră de bun simț și nu simt nevoia să dea explicații suplimentare) ✔Condiții instabile ✔Factori sociopolitici ✔Competiții între departamente ✔Competiții între indivizi/angajați ✔Interese divergente ✔Priorități diferite ✔Documente neactualizate ✔Rezistența la schimbare ABORDĂRI TRADIȚIONALE VS. AGILE Abordările tradiționale ✔Încercăm să documentăm cât mai multe cerințe de la început ✔Planifică și documentează ✔Uneori sute sau mii de pagini ✔Definește totul ✔Înregistrează toate presupunerile ✔Explică raționamente, alternative ✔De lungă durată Abordările agile Agile Tradiționale Indivizi și interacțiuni Procese și instrumente Software care funcționează Documentație exhaustivă Colaborare cu clientul Negocierea contractului Reacție la schimbare Urmărirea unui plan TEHNICI PENTRU IDENTIFICAREA CERINŢELOR 1. Interviurile Intervievarea beneficiarului este cea mai uzuală metodă de identificare a cerinţelor. Succesul său depinde de implicarea tuturor părţilor interesate, incluzând aici manageri, acţionari angajaţi, etc. pe care în continuare îi vom plasa sub titulatura generală de utilizatori. Un interviu, în mod normal, se va concentra asupra activităţii desfăşurate de utilizator în cadrul organizaţiei, a modului în care implementarea sistemului va influenţa munca sa şi a problemelor pe care acesta le-a identificat în procesele actuale care au loc în organizaţie. Interviul poate scoate la iveală cerinţe care nu au fost iniţial identificate ca făcând parte din obiectivele proiectului, dar şi cerinţe contradictorii. TEHNICI PENTRU IDENTIFICAREA CERINŢELOR 1. Interviurile - continuare Apariţia cerinţelor contradictorii poate fi derutantă, în sensul că nu pare firesc ca diferite persoane care lucrează în aceiaşi organizaţie să aibă viziuni contradictorii asupra aceluiaşi aspect analizat. Analistul îşi poate pune următoarea întrebare pertinentă: ”Cum poate o afacere să fie competitivă şi profitabilă dacă nu există un consens, cel puţin în interiorul ei, privind modul în care aceasta funcţionează?” Un posibil răspuns: “…nivelul de detaliu necesar pentru construirea unei aplicaţii informatice este mai mare decât nivelul de detaliu necesar pentru a conduce cu succes o afacere.” INTERVIURI – BUNE PRACTICI ✔Identificați eșantionul intervievat potrivit pentru acoperirea completă a problemelor – nu este nevoie de mai mulți angajați care au aceleași responsabilități sau de toți managerii. ✔Centrați interviul pe munca intervievaților și pe preocupările acestora. ✔Luați în considerare și persoana, nu numai rolul acesteia. ✔Oferiți motivare, puneți întrebări cât mai ușor de înțeles. ✔Fiți deschiși, flexibili în cazul în care apar răspunsuri neașteptate ✔Puneți frecvent întrebarea “DE CE?” pentru a clarifica aspectele neînțelese. ✔Evitați întrebările care exprimă opinii sau sunt interpretabile sau al căror răspunsuri sunt evidente sau imposibile pentru intervievat. ✔Adaptați întrebările la nivelul de expertiză al fiecărui intervievat (trebuie să cunoașteți responsabilitățile acestora). TEHNICI PENTRU IDENTIFICAREA CERINŢELOR 2. Sesiunile comune pentru stabilirea cerinţelor Sesiunile comune pentru stabilirea cerinţelor (engl. Join Requirement Planning- JRP) pot fi asimilate cu efectuarea interviurile tuturor utilizatorilor (sau cel puţin a unei părţi semnificative a acestora) în acelaşi timp şi în aceeaşi încăpere. Toate persoanele care vor influenţa direcţia în care se dezvoltă sistemul sunt reunite într-un singur loc pentru a furniza detalii despre ceea ce trebuie să facă sistemul. Este necesară existenţa unui mediator care să modereze aceste sesiuni, dar şi a unei persoane care să documenteze propunerile utilizatorilor, ajutându-se, de exemplu, de un proiector şi de un produs software pentru modelarea vizuală. TEHNICI PENTRU IDENTIFICAREA CERINŢELOR 3. Cazurile de utilizare Cazurile de utilizare descriu interacţiunile dintre utilizatori şi sistem şi reflectă ceea ce trebuie să facă utilizatorii cu sistemul prin identificarea funcţiilor importante. Un caz de utilizare surprinde secvenţa de interacţiuni dintre sistem şi actorii externi (cum ar fi persoane, dispozitive hardware sau alte sisteme software), incluzând şi variante sau extensii ale comportamentului de bază al sistemului. Cazurile de utilizare pot constitui una dintre primele forme de reprezentare a cerinţelor unui sistem informatic, motiv pentru care ele sunt potrivite pentru stadiile incipiente ale procesului de dezvoltare software. Analiştii, împreună cu beneficiarii sistemului, vor trebui să examineze şi să valideze fiecare caz de utilizare propus TEHNICI PENTRU IDENTIFICAREA CERINŢELOR 4. Observaţiile şi analizele sociale Metodele bazate pe observaţii presupun existenţa unui observator care să urmărească utilizatorii sistemului şi să noteze informaţii referitoare la activitatea pe care aceştia o desfăşoară. Observaţiile pot fi directe, implicând prezenţa observatorului pe parcursul executării activităţilor sau indirecte, atunci când activitatea este vizualizată prin intermediul altor mijloace, cum ar fi o înregistrare video. Metoda prezintă avantajul de a facilita culegerea unor date de calitate şi este utilă pentru analiza activităţilor şi proceselor reale, prin care se pot evita eventualele omisiuni sau erori furnizate de o descriere a fluxului de lucru de către beneficiar. TEHNICI PENTRU IDENTIFICAREA CERINŢELOR 5. Prototipurile Prototipul este util pentru utilizatorul final care va înţelege mai bine ce vrea sau ce se aşteaptă de la produs şi este util dezvoltatorului pentru a testa unele tehnici, algoritmi folosiţi, interfeţe realizate etc. Referitor la prototip există două abordări : – prototip de încercare care trebuie să fie rapid, chiar dacă nu perfect şi care poate fi utilizat pentru validarea interfeţei, pentru particularizarea arhitecturii pentru a cuprinde cerinţele cât mai bine, sau pentru a valida algoritmi particulari; – prototip evolutiv care, dimpotrivă, dezvoltă produsul final astfel încât să se poată aprecia toate caracteristicile de calitate ale produsului software final; în general acest prototip nu poate fi rapid, dar permite îmbunătăţirea modelului prin asigurarea unei calităţi ridicate a produsului software. CARACTERISTICI DE CALITATE ALE CERINŢELOR Literatura de specialitate face referire la o multitudine de proprietăţi “dorite” ale specificaţiilor. În ansablul lor, se urmăreşte ca cerinţele să fie: Complete: Documentaţia cerinţelor include toate informaţiile necesare referitoare la cerinţe: cerinţe funcţionale şi non-funcţionale, constrângeri, cerinţe referitoare la interfeţele externe, cerinţe ale datelor etc. Consistente: Între cerinţele de la acelaşi nivel, nu există conflicte interne care să ducă la contradicţii. De asemenea, nu trebuie să existe contradicţii între cerinţele de la niveluri diferite. Se va urmări şi consistenţa terminologiei, astfel încât: a) un cuvânt să aibă acelaşi sens de fiecare dată când este folosit; b) două cuvinte diferite nu se folosesc pentru a desemna acelaşi lucru. Modificabile: Documentaţia care include cerinţele este organizată şi scrisă într-o manieră care facilitează modificările ulterioare şi, în acest sens, o cerinţă trebuie să fie: – Neredundantă: Fiecare cerinţă este specificată o singură dată; – Schimbabilă: Fiecare cerinţă poate fi schimbată fără a avea un impact major asupra altor cerinţe.  CARACTERISTICI DE CALITATE ALE CERINŢELOR Totodată, este de dorit ca fiecare cerinţă individuală să fie: Neambiguă: Fiecare specificare a unei cerinţe trebuie să aibă o singură interpretare şi să fie descrisă într-o manieră coerentă şi uşor de înţeles. Concisă: Fiecare cerinţă trebuie să fie scurtă, folosind un limbaj orientat spre acţiune şi evitându-se detaliile inutile. Măsurabilă: Dacă este necesar, pentru fiecare cerinţă se precizează limite sau valori măsurabile specifice. Caracteristica este utilă în special pentru cerinţele non-funcţionale. Fezabilă: cerinţa poate fi implementată folosind tehnici, tehnologii, instrumente şi resurse existente, cu ajutorul personalul disponibil şi în limite cunoscute de cost şi timp. Testabilă: Din perspectiva costurilor, există o modalitate acceptabilă de a stabili dacă sistemul informatic satisface acea cerinţă. Poate fi urmărită: Pentru fiecare cerinţă, pot fi identificate sursa acesteia, precum şi formele sub care este reprezentată la diferite niveluri de specificare. De asemenea, cerinţa trebuie specificată într-o manieră care permite urmărirea acesteia în etapele următoare ale dezvoltării sistemului, şi anume proiectare, implementare şi testare. ASPECTE PRACTICE Combinarea tehnicilor Datorită limitărilor, o singură tehnică nu poate fi suficientă Sunt necesare atât identificarea pornind de la artefacte, cât și identificarea pornind de la beneficiar Exemple: – Interviuri + observații directe + prototipizarea – Rapid Application Decelopment: sesiuni JAD + prototip evolutive Implicare Este necesară implicarea activă a beneficiarului, deoarece: ✔Cerințele se schimbă ✔Obținem feedback în mod frecvent ✔Rezolvăm aspecte neînțelese ✔Încercăm să eliminăm ambiguități NU PIERDEȚI DIN VEDERE!! ⮚Analiza riscurilor - beneficiarii pot vorbi despre soluții care nu sunt fezabile datorită: ▪ Mediului ▪ Bugetului ▪ Tehnologiei ⮚Cere sunt cerințele reale ale clientului ⮚Prioritizarea cerințelor ⮚Întotdeauna fii pregătit pentru schimbare  LIMBAJE PENTRU MODELAREA INFORMAŢIONALĂ Cuprins ✔Modelarea în realizarea sistemelor informatice ✔Limbaje pentru modelarea informaţională ✔Categorii de limbaje pentru modelarea informaţională ✔Limbajul UML MODELAREA ÎN REALIZAREA SISTEMELOR INFORMATICE Modelarea - una dintre cele mai importante tehnici de concepere a sistemelor informatice. Model – abstractizare a unei părţi a realităţii înconjurătoare Trăsăturile caracteristice ale modelării: – simplificarea, – subordonarea la un scop, – reprezentarea unei realităţi, – divizarea, – ierarhizarea – comunicarea. MODELAREA ÎN REALIZAREA SISTEMELOR INFORMATICE Analiza şi proiectarea orientată-obiect foloseşte trei tipuri diferite de modele pentru descrierea unui sistem informatic: ⮚modelul static care descrie obiectele si relaţiile lor în sistem; ⮚modelul dinamic ce descrie interacţiunile între obiecte în cadrul sistemului ; ⮚modelul funcţional care descrie transformarea valorii datelor în sistem. LIMBAJE PENTRU MODELAREA INFORMAŢIONALĂ La modul general, limbajele pentru modelarea informaţională fac posibilă descrierea concisă şi exactă a proprietăţilor sistemelor la diferite nivele de abstractizare. Sunt o parte integrantă a procesului de dezvoltare a sistemelor informatice în cadrul căruia pot fi folosite pentru: – a face legătura între etapa de analiză a cerinţelor şi cea de implementare; – a verifica proprietăţile critice ale unor sisteme; – a ajuta la generarea automată de cod şi de cazuri de test. CATEGORII DE LIMBAJE PENTRU MODELAREA INFORMAŢIONALĂ În funcţie de nivelul de formalizare pe care îl impun, limbajele pentru modelarea informaţională se împart în: ⮚Limbaje informale ⮚Limbaje semi-formale ⮚Limbaje formale  LIMBAJUL UML Limbajul standardizat UML (Unified Modeling Language) a apărut din necesitatea unei standardizări a tipologiei, semanticii şi a reprezentării rezultatelor. În prezent, UML este un standard de modelare recunoscut de catre OMG (Object Management Group), standardizarea fiind realizată în noiembrie 1997, iar până în prezent realizându-se o perfecţionare continuă a acestuia. UML poate fi definit ca fiind un limbaj de vizualizare, specificare, construire si documentare a modelelor. Valoarea lui constă în faptul că este un standard deschis, realizează întreg ciclul de dezvoltare al software-ului, acoperă multe tipuri de aplicaţii, este bazat pe marea experienţă a celor care l-au realizat şi poate fi implementat de multe produse de tip CASE.  LIMBAJUL UML UML are notaţii standard şi semantică adecvată modelării sistemelor orientate obiect. Odată cu apariţia acestui limbaj, proiectanţii de sisteme pot înţelege mai uşor documentaţiile de sistem. Înaintea acestei standardizări, un proiect orientat-obiect putea fi descris folosind una din multele metode orientate-obiect disponibile, iar dacă era necesară o revizuire, se pierdea un timp important cu analiza notaţiilor şi semanticii metodei folosite, înainte de a începe logica proiectării. ISTORIA UML 2017 UML 2.5.1  ELEMENTELE DE BAZĂ ALE UML 1. Metamodel pentru modelarea orientată obiect – Set coerent de definiţii ale unor concepte şi a relaţiilor dintre ele; – Se defineşte, folosind o sintaxă precisă, fiecare element utilizat în modelare (exemplu: definirea unei clase); – Limbaj suport pentru transmiterea modelelor vizuale între diferite instrumente; – Are o arhitectură pe patru niveluri. Strat Descriere Exemplu meta-metamodel Defineşte limbajul pentru Concepte abstracte din care este specificarearea metamodelelor. derivat metamodelul. metamodel Defineşte limbajul pentru Concepte: Clasă, Atribut, specificarea modelului. Operaţie, Componentă model Defineşte limbajul folosit pentru Concepte: Student, Materie, descrierea domeniului analizat. Client, Produs, Comandă obiectele Definesc informaţii despre obiectele Exemple: Student #3456, utilizatorului domeniului analizat. Materia #0512  ELEMENTELE DE BAZĂ ALE UML 2. Tipuri de diagrame  ELEMENTELE DE BAZĂ ALE UML 3. Mecanisme de extensie – Stereotipurile caracterizează un element din model sau o relaţie între elemente (există sterotipuri predefinite). – Comentariile (notele) descriu suplimentar un element din model. – Contrângerile limitează utilizarea unui element din model. – Valori etichetate reprezintă atribute definite pentru un stereotip. – Profilele personalizează metamodelul prin construcţii care sunt specifice unui anumit domeniu, platformă sau metodă de dezvoltare.  MODELAREA CU AJUTORUL DIAGRAMELOR UML Modelarea proceselor de afaceri se realizează folosind diagrama cazurilor de utilizare. Această diagramă dirijează întreg procesul de dezvoltare a sistemului în cazul metodelor orientate pe cazuri de utilizare. Modelarea structurii statice se face cu ajutorul diagramei claselor (pentru modelarea structurii statice a claselor sistemului) şi diagramei obiectelor (pentru modelarea structurii statice a obiectelor sistemului). Diagrama pachetelor este un mijloc de grupare a elementelor diagramelor în pachete.  MODELAREA CU AJUTORUL DIAGRAMELOR UML Modelarea dinamicii este realizată utilizând diagrame de interacţiune şi diagrame care descriu comportamentul. UML utilizează două diagrame de interacţiune, una pentru modelarea circuitului mesajelor între obiecte, numită diagrama de secvenţă şi alta, pentru modelarea interacţiunilor între obiecte, denumită diagrama de comunicare. Ca diagrame ce descriu comportamentul, se utilizează diagrama de stare pentru modelarea comportamentului obiectelor din sistem şi respectiv diagrama de activitate pentru modelarea comportamentului cazurilor de utilizare, obiectelor sau a operaţiilor. Modelarea implementării se face cu ajutorul a două diagrame. Modelarea componentelor se realizează utilizând diagrama componentelor, iar modelarea distribuirii sistemului se obţine folosind diagrama de desfăşurare. CURSUL 3... Diagrama Cazurilor de Utilizare Instrumente CASE 51