Proiectarea sistemelor informatice - Curs 3 PDF

ACADEMIA DE STUDII ECONOMICE BUCUREŞTI FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ PROIECTAREA SISTEMELOR INFORMATICE -CURS 3- BUCUREȘTI 2024-2025 Diagrama de cazuri de Modelarea...

ACADEMIA DE STUDII ECONOMICE BUCUREŞTI FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ PROIECTAREA SISTEMELOR INFORMATICE -CURS 3- BUCUREȘTI 2024-2025 Diagrama de cazuri de Modelarea funcțională utilizare Cuprins ▪ Introducere ▪ Cazuri de utilizare ▪ Actori ▪ Relații între cazuri de utilizare și actori ▪ Relații între cazuri de utilizare ▪ Relații între actori ▪ Descrierea textuală a unui caz de utilizare ▪ Bune practici ▪ Erori frecvente ▪ Rezumat notații Introducere ▪ Cazul de utilizare reprezintă un concept fundamental al multor metodologii de dezvoltare orientate-obiect. Diagramele de cazuri de utilizare: ▪ Au rolul de a reprezenta într-o formǎ graficǎ funcţionalitǎţile pe care trebuie sǎ le îndeplineascǎ sistemul informatic în faza sa finalǎ. ▪ Exprimă așteptările clienților/beneficiarilor: ▪ esențial pentru o proiectare detaliată ▪ Sunt folosite în întreg procesul de analiză și proiectare. ▪ Modelul realizat de diagramele de cazuri de utilizare alǎturi de documentele de descriere succintǎ a fiecǎrui caz de utilizare identificat poartǎ numele de model al cerinţelor. Introducere ▪ Diagramele de cazuri de utilizare sunt formate din actori şi cazuri de utilizare, pe de o parte, şi relaţiile între acestea, pe de altă parte. ▪ Putem folosi diagrama de cazuri de utilizare pentru a răspunde la următoarele întrebări: ▪ Ce este descris? (Sistemul) ▪ Cine interacționează cu sistemul? (Actorii) ▪ Ce pot face actorii? (Cazuri de utilizare) Exemplu: Sistemul de administrare a studenților ▪ Sistem (Ce este descris?) ▪ Sistemul de administrare a studenților ▪ Actori (Cine interacționează cu sistemul?) ▪ Profesorul ▪ Cazuri de utilizare (Ce pot face actorii?) ▪ Interoghează date student ▪ Emite certificat ▪ Anunță examen Caz de utilizare ▪ “Specifică un set de acţiuni executate de către un sistem sau un subiect şi care conduc la un anumit rezultat. Rezultatul, în mod normal, este important pentru un actor sau un beneficiar. “ (OMG) ▪ Oferă beneficii tangibile pentru unul sau mai mulți actori care comunică cu acest caz de utilizare. ▪ Derivă din cerințele indentificate de la clienți. ▪ Mulțimea tuturor cazurilor de utilizare descrie funcționalitățile pe care sistemul trebuie să le ofere. ▪ Documentează funcționalitățile pe care le oferă acel sistem. ▪ Notații alternative: Actor (1/3) ▪ Actorii interacționeză cu sistemul: ▪ prin folosirea cazurilor de utilizare, spre exemplu, actorii inițiază execuția unui caz de utilizare ▪ find folosiți de către cazurile de utilizare, spre exemplu, actorii oferă funcționalități pentru execuția unui caz de utilizare ▪ Actorii reprezintă roluri pe care le adoptă utilizatorii. ▪ Anumiți utilizatori pot juca mai multe roluri în același timp. ▪ Actorii nu reprezintă o parte din sistem, ei se găsesc în afara granițelor sistemului. ▪ Notații alternative: Actor (2/3) ▪ De obicei datele utilizatorului sunt administrate în cadrul sistemului. Aceste date sunt modelate sub forma obiectelor și claselor. Exemplu: actor Asistent ▪ Actorul Asistent interacționează cu sistemul Activitate Seminar prin utilizarea acestuia. ▪ Clasa Asistent descrie obiectele care reprezintă datele utilizatorului (spre exemplu, nume, poziție etc.). Actor (3/3) ▪ Umani ▪ Exemple: Student, Profesor ▪ Non-umani ▪ Exemple: Server E-Mail,.... ▪ Primar: este principalul beneficiar al execuției unui caz de utilizare ▪ Secundar: nu primește niciun beneficiu direct ▪ Activ: inițiază execuția unui caz de utilizare ▪ Pasiv: oferă funcționalitate pentru execuția unui caz de utilizare ▪ Exemplu: Uman Uman Primar Secundar Activ Activ Non-uman Uman Secundar Primar Pasiv Activ 8 Relații între cazuri de utilizare și actori ▪ Asocierile simple sunt folosite pentru a conecta un actor cu un caz de utilizare. Aceasta reprezintă o cale de comunicare între cei doi. ▪ Fiecare actor trebuie să comunice cu cel puțin un caz de utilizare. ▪ Asocierea este întotdeauna binară. ▪ Pot fi specificate multiplicități. Multiplicitatea mai mare decât unu la capătul: ▪ corespunzător CU ⇨ actorul este implicat în mai multe cazuri de utilizare de acel tip şi poate iniţia cazuri de utilizare: în paralel (concurent), la diferite momente de timp sau mutual exclusiv în timp. ▪ corespunzător actorului ⇨ mai multe instanţe ale actorului sunt implicate în iniţierea cazului de utilizare putând realiza acţiuni simultane sau succesive. Relații între cazuri de utilizare Relația de includere ▪ Comportamentul unui caz de utilizare (cazul de utilizare inclus) este integrat în comportamentul altui caz de utilizare (cazul de utilizare de bază). ▪ Cazul de utilizare care îl include pe un altul nu este complet. Caz de utilizare de bază cere comportamentului cazului de utilizare inclus să îi permită să includă funcționalitatea sa Cazul de utilizare inclus este independent din punct de vedere al execuției Relații între cazuri de utilizare Relația de extindere ▪ Comportamentul unui caz de utilizare (cel care extinde ) poate fi integrat în comportamentul altui caz de utilizare (cazul de utilizare de bază), dar acest lucru nu este obligatoriu. ▪ Ambele cazuri de utilizare pot fi executate în mod independent. Caz de utilizare de bază Caz de utilizare care extinde ▪ A decide dacă B este executat. ▪ Punctele de extindere definesc punctul în care comportamentul este integrat. ▪ Condițiile definesc care sunt circumstanțele în care comportamentul este integrat. Relații între cazuri de utilizare Relația de extindere: puncte de extindere ▪ Punctele de extindere sunt scrise direct în cazul de utilizare. ▪ Este permisă specificarea mai multor puncte de extindere. Relații între cazuri de utilizare Relația de generalizare ▪ Cazul de utilizare A generalizează cazul de utilizare B. ▪ B moștenește comportamentul lui A și îl poate extinde sau suprascrie. ▪ B moștenește și toate relațiile lui A. Caz de utilizare de bază ▪ B adoptă funcționalitățile de bază ale lui A și Sub caz decide ce părți din A execută sau modifică. de utilizare ▪ A poate fi etichetat ca{abstract} ▪ Nu poate fi executat în mod direct ▪ Numai B este executabil Relații între actori Relația de generalizare între actori ▪ Actorul A moștenește de la actorul B. ▪ A poate comunica cu X și Y. Super-actor ▪ B poate comunica doar cu Y. ▪ Este permisă moștenirea multiplă. Sub-actor ▪ Pot exista actori abstracți. Profesorul ȘI Asistentul sunt necesari Profesorul SAU Asistentul sunt necesari pentru execuția Interoghează date student pentru execuția Interoghează date student Descrierea sub formă de șablon a unui caz de utilizare Element al cazului de Descriere utilizare Cod Un identificator unic asociat cazului de utilizare Stare Stadiul de finalizare în care se găseşte, de exemplu: schiţă, finalizat sau aprobat Scop Sistemul (parte a sistemului) sau aplicaţia căreia îi aparţine Nume Numele cazului de utilizare, cât mai scurt şi reprezentativ Actor principal Beneficiarul care iniţiază cazul de utilizare şi care urmăreşte un anumit scop Descriere Prezentare scurtă, in text liber, a cazului de utilizare Precondiţii Ce condiţii trebuie satisfăcute pentru ca scenariul să poată începe Postcondiţii Ce condiţii trebuie îndeplinite pentru a garanta un final reuşit al scenariului Posibile erori Erori relevante pentru domeniul problemei Starea sistemului în În ce stare se găsește sistemul după apariția erorii caz de eroare Declanşator Un eveniment sau o succesiune de evenimente care iniţiază cazul de utilizare Flux de bază Descrie înşiruirea evenimentelor atunci când totul se petrece conform unui scenariu prestabilit; nu există excepţii sau erori Fluxuri alternative Cele mai semnificative alternative şi excepţii ale scenariului de bază Relaţii Ce relaţii are cu alte cazuri de utilizare (de tipul include sau extend)15 Descrierea unui caz de utilizare - Exemplu Element al cazului de Descriere utilizare Cod CU01 Stare Schiţă Scop Gestiunea sălilor pentru desfășurarea activităților universitare Nume Rezerva sala Actor principal Angajat Descriere Angajatul rezervă o sală a universității pentru un eveniment Precondiţii Angajatul este autorizat să rezerve săli Postcondiţii Sala este rezervată Declanşator Angajatul solicită rezervarea unei săli Posibile erori Nu există sală liberă. Starea sistemului în caz de eroare Angajatul nu a rezervat sala. Flux de bază 1. Angajatul se autentifică în sistem. 2. Angajatul selectează sala. 3. Angajatul selectează data și ora. 4. Sistemul confirmă că sala este liberă. [Curs alternativ A: Sala nu este liberă] 5. Angajatul confirmă rezervarea. Fluxuri alternative A: 1. Sistemul propune săli alternative. 2. Angajatul selectează o sală alternativă și confirmă rezervarea. 16 Relaţii Extinde cazul de utilizare CU06 Anunta curs. Bune practici «include» Standard UML Bune practici Bune practici «extend» Standard UML Bune practici Bune practici Identificarea actorilor ▪ Cine folosește principalele cazuri de utilizare? ▪ Cine are nevoie de suport pentru munca lor zilnică? ▪ Cine este responsabil pentru administrarea sistemului? ▪ Care sunt dispozitivele externe/sistemele (software) cu care sistemul trebuie să comunice? ▪ Cine este interesat de rezultatele oferite de sistem? Identificarea cazurilor de utilizare ▪ Care sunt cele mai importante activități pe care trebuie să le realizeze un actor? ▪ Dorește un actor să interogheze sau să modifice informațiile conținute în sistem? ▪ Informează un actor sistemul despre schimbările din alte sisteme? ▪ Ar trebui ca un actor să fie informat despre rezultatele neașteptate apărute în sistem? Bune practici Erori de evitat - 1 ▪ Cazurile de utilizare nu modelează procese sau fluxuri de lucru! Bune practici Erori de evitat - 2 ▪ Actorii nu sunt parte a sistemului, de aceea trebuie poziționați în afara granițelor! Bune practici Erori de evitat - 3 ▪ Cazul de utilizare Distribuie informare necesită DOAR un actor Asistent SAU un actor Profesor pentru a se executa ✔ Bune practici Erori de evitat - 4 ▪ Mai multe cazuri de utilizare mici care au același obiectiv pot fi grupate într-un singur caz de utilizare. ✔ Bune practici Erori de evitat - 5 ▪ Pașii de executat sunt părți ale cazului de utilizare, cazurile de utilizare NU trebuie descompuse funcțional ✔ Notații - 1 Nume Notație Descriere Granițele dintre sistem și Sistem utilizatorii acestuia Caz de utilizare Unitate funcțională a sistemului Actor Rol al utilizatorilor în sistem Notații - 2 Nume Notație Descriere Relație între cazuri de utilizare și Asociere actori Relație de moștenire între actori Generalizare sau cazuri de utilizare Relația de B extinde A: utilizare opțională a extindere CU B de către CU A Relația de A include B: necesită folosirea CU includere B de către CU A Recapitulare 1. Ce descrie diagrama cazurilor de utilizare? 2. Ce relații există între actori și cazuri de utilizare? 3. Poate un actor să nu comunica cu niciun caz de utilizare? Dar cu mai multe cazuri de utilizare? 4. Ce semnifică într-o relație de asociere o multiplicitate mai mare decât unu la capătul actorului? 5. Se reprezintă un actor secundar? Dar un actor activ? 6. Pentru relația de includere, cazul de utilizare care îl include pe altul este complet? Argumentați. 7. Explicați relația de extindere dintre cazurile de utilizare. 8. Ce este un actor abstract și cum poate fi folosit? Exemplificați. 9. Cum reprezentăm situația în care mai mulți actori sunt necesari pentru realizarea unui caz de utilizare? Instrumente CASE Cuprins ▪ Instrumente CASE: concepte, obiective şi facilităţi ▪ Clasificarea instrumentelor CASE ▪ Arhitectura mediului CASE ▪ Visual Paradigm Instrumente CASE ❑ CASE : Computer Aided Software Engineering ❑ Instrumentele CASE - instrumentele integrate care susțin activitățile front-end și back-end legate de dezvoltarea sistemelor informatice ❑ Utilitate de ordin: ❑cantitativ ❑calitativ ❑ Instrumentele CASE reduc substanţial sau elimină multe din problemele de proiectare şi dezvoltare a aplicaţiilor informatice. Obiective ❑ Obiectivul principal al tehnologiei CASE: de a îmbunătăți productivitatea și calitatea sistemelor rezultate, asistând echipa de dezvoltare pe parcursul diferitelor etape ale procesului de realizare, de la identificarea cerințelor funcționale și nefuncționale ale sistemului până la proiectarea și implementarea acestuia, luând în considerare toate caracteristicile tehnice și operaționale relevante. Obiective ❑ specificarea corectă şi completă a cerinţelor sistemului; ❑ reducerea timpului şi costului de proiectare şi dezvoltare; ❑ integrarea activităţilor de proiectare şi dezvoltare prin utilizarea unor metodologii/metode comune; ❑ standardizarea procesului de proiectare şi dezvoltare a sistemelor informatice; ❑ simplificarea şi îmbunătăţirea procesului de testare; Obiective ❑ simplificarea etapei de întreţinere a sistemelor informatice; ❑ realizarea unor documentaţii de calitate; ❑ îmbunătăţirea managementului proiectelor; ❑ reutilizarea modulelor aplicaţiilor şi a documentaţiei; ❑ îmbunătăţirea portabilităţii aplicaţiilor; ❑ asigurarea acurateţei componentelor construite Facilităţi ❑ suport pentru conducerea proiectului. Deosebit de utile sunt instrumentele de planificare şi estimare a timpului şi resurselor necesare realizării sistemului, precum şi gestiunea versiunilor proiectului; ❑ generarea documentaţiei de realizare a sistemului informatic; ❑ stocarea şi regăsirea datelor din depozitul central de date (repository) prin utilitare specifice; ❑ verificarea automată a consistenţei şi completitudinii datelor printr-un analizor ce conţine reguli specifice pentru fiecare metodologie/metodă; ❑ generarea automată a codului de program, pornind de la specificaţiile de proiectare; ❑ tehnica de inginerie inversă (reverse ingineering) prin care se permite revenirea dintr-o etapă de realizare a aplicaţiei la o etapă precedentă pentru eventuale modificări ❑ suport pentru realizarea de prototipuri, prin limbaje de programare de nivel înalt şi generatoare. Tipologia instrumentelor CASE 1. După aria de cuprindere a ciclului de realizare a aplicaţiei: Planificar e Upper CASE Analiz Integrated CASE ă Proiectar e Implementa re Lower CASE Testar e Mentenanț ă Tipologia instrumentelor CASE ❑ Instrumente CASE front-end (sau upper CASE) care oferă suport pentru primele etape de realizare a aplicaţiilor informatice (analiza şi specificarea cerinţelor, proiectarea logică). ❑ Instrumente CASE back-end (sau lower CASE) care oferă suport pentru ultimele etape de realizare a aplicaţiilor informatice (proiectarea fizică, elaborarea programelor, testarea, întreţinerea sistemului). ❑ Instrumente CASE cross life cycle care oferă suport pentru activităţile ce apar în mai multe etape ale procesului de proiectare şi dezvoltare a sistemelor informatice (de exemplu, instrumente utilizate pentru managementul proiectului, generatoare de documentaţie). Tipologia instrumentelor CASE 2. După scopul utilizării: ❑ Instrumente CASE pentru construirea diagramelor – componentele sistemului, fluxurile de date și fluxurile de control între diferitele componente ale acestuia pot fi reprezentate în formă grafică/ ❑ Instrumente CASE pentru managementul proiectului - utilizate pentru planificarea proiectelor, estimarea costurilor și eforturilor și planificarea resurselor. Instrumentele de management al proiectelor ajută la stocarea și partajarea informațiilor despre proiect în timp real în întreaga organizație. Tipologia instrumentelor CASE ❑ Instrumentele de documentare generează documentaţie pentru utilizatorii tehnici și utilizatorii finali. Utilizatorii tehnici sunt specialisti, membri ai echipei de dezvoltare care utilizează manualule de sistem, manualule de instruire, manuale de instalare etc. Documentele utilizatorului final descriu funcționarea și instrucțiunile sistemului, cum ar fi manualul utilizatorului; ❑ Instrumente CASE pentru analiză - aceste instrumente ajută la colectarea cerințelor, verifică automat dacă există inconsecvențe, inexactități în diagrame, redundanțe de date sau omisiuni eronate. ❑ Instrumente CASE pentru proiectare - aceste instrumente îi ajută pe proiectanții de software să proiecteze structura produsului, care poate fi descompusă în module mai mici folosind tehnici de rafinare. Aceste instrumente oferă detalii despre fiecare modul și interconectările dintre module Tipologia instrumentelor CASE ❑ Instrumente pentru managementul schimbărilor - automatizează urmărirea modificărilor, gestionarea fișierelor, gestionarea codului etc ❑ Instrumente de programare - aceste instrumente constau din medii de programare precum IDE (Integrated Development Environment), biblioteci și instrumente de simulare. Ele oferă ajutor în construirea produselor software și includ facilități pentru simulare și testare. ❑ Instrumente de asigurare a calității - asigurarea calității într-o organizație software monitorizează procesul de inginerie și metodele adoptate pentru a dezvolta produsul software pentru a asigura îndeplinirea standardelor organizației. Instrumentele QA constau în instrumente de configurare și control al modificărilor și instrumente de testare software. Tipologia instrumentelor CASE 3. După dimensiunea suportului oferit: ❑ Instrumente CASE propriu-zise ce oferă suport pentru o singură activitate din cadrul unei etape de realizare a aplicaţiilor (de exemplu, editoare de diagrame şi text, instrumente pentru analiza consistenţei şi completitudinii specificaţiilor de sistem, depanatoare etc.); ❑ Bancurile de lucru CASE (workbenches) care oferă suport pentru o etapă din ciclul de realizare a aplicaţiei; ❑ Mediile CASE care oferă suport pentru cea mai mare parte (sau toate) dintre etapele de realizare a sistemului informatic. Din această categorie fac parte următoarele instrumente: IBM Rational Architect Cradle/3SL, Corporate Modeler/CASEWise Inc etc. Arhitectura mediului CASE Editoare pentru Instrumente diagrame pentru Generatoare conducerea de rapoarte proiectului Utilitare Instrumente pentru pentru testare si Depozitu validare depanare l central de date Instrumente pentru Instrumente generarea pentru automata a inginerie documentati inversa ei Instrumente pentru Utilitare generarea pentru automata a transformare codului Arhitectura mediului CASE ▪ Depozitul de date central (nucleul unui mediu I-CASE) stochează toate obiectele şi informaţiile necesare pentru proiectarea, modelarea şi generarea aplicaţiilor. Depozitul de date central conţine depozitul de informaţii (information repository) şi dicţionarul de date. Depozitul de informaţii conţine informaţiile despre afacerile organizaţiei şi portofoliul ei de aplicaţii. Dicţionarul de date gestionează şi controlează accesul la depozitul de informaţii. El stochează descrieri ale datelor şi ale resurselor de prelucrare a datelor. ▪ Editoarele pentru diagrame permit reprezentarea vizuală a unui sistem şi a componentelor lui. Diagramele sunt foarte eficace pentru reprezentarea fluxurilor de procese, a structurilor de date şi a structurilor de program. Arhitectura mediului CASE ▪ Utilitarele pentru transformare convertesc elementele obţinute cu instrumentele de analiză în elemente ale proiectării. ▪ Generatoarele de forme şi rapoarte sunt utilizate pentru a crea, modifica şi testa prototipurile de forme şi rapoarte şi pentru a identifica datele care vor fi afişate sau colectate pentru fiecare formă şi raport ▪ Instrumentele pentru validare/verificare generează rapoarte prin care se identifică inconsistenţele, redundanţa şi lipsurile din diagrame, forme şi rapoarte. ▪ Instrumente pentru generarea automată a codului pornind de la specificaţiile de proiectare conţinute în depozitul de date central (instrumente pentru generarea obiectelor bazei de date şi a modulelor aplicaţiei). Visual Paradigm Visual Paradigm 1. Se axează pe trei direcţii principale: Identificarea Construirea de Generarea de cod şi cerinţelor modele baze de date 2. Asigură interoperabilitatea cu alte instrumente CASE (Visio, Visual UML, Rational) şi integrarea cu instrumentele IDE de marcă (Net Beans) 3. Acoperă mare parte a ciclului de viaţă al unui sistem informatic  Visual Paradigm Enterprise Professional Standard Modeler Community Diagrame UML ✓ ✓ ✓ ✓ ✓ Diagrame SysML ✓ ✓ ✓ ✓ ✓ Diagrama EA ✓ ✓ ✓ ✓ ✓ Sabloane predefinite ✓ ✓ ✓ ✓ ✓ Analiză textuală ✓ ✓ ✓ ✓ ✓ Diagrame BPMN ✓ ✓ ✓ ✓ Instrument de machetare ✓ ✓ ✓ Harta Scrum User Story ✓ ✓ Ghid de management al ✓ proiectului Visual Paradigm Include modele ale unor limbaje standard ❑ Modelarea UML - Pot fi create toate tipurile de diagrame UML 2.x prin construirea de modele de cazuri de utilizare, comportamentale, de interacţiune, structurale, de amplasare, de cazuri de test. ❑ Modelarea BPMN – Pot fi create: diagrame de procese de afaceri, diagrame de flux de date, diagrame de hărţi de procese, diagrama lanţului de procese conduse prin evenimente, organigrame. Diagramele de procese de afaceri pot fi exportate în BPEL. ❑ Modelarea SysML - SysML este un limbaj general pentru ingineria aplicaţiilor şi sistemelor informatice. VP-UML permite crearea diagramei de cerinţe specifice limbajului SysML. Visual Paradigm Modelarea cerinţelor Identifică cerinţele prin intermediul a mai multe mecanisme: ❑ Analiza textuală oferă editor de text prin intermediul căruia sunt înregistrate cerinţele în format textual şi care permite identificarea termenilor sau obiectelor importante (clase, cazuri de utilitare) pentru descrierea problemei. ❑ Cardurile CRC conţin informaţii precum descrirea clasei, atributele acesteia şi responsabilităţile. Au formate proprii de afişare a informaţiilor. ❑ Diagrame de cerinţe SysML pentru a identifica cerinţele funcţionale sau non-funcţionale ale sistemului. ❑ Editorul de interfeţe utilizator prin intermediul căruia se crează machete ale ecranelor. ❑ Managementul glosarului de termeni prin care se identifică şi se descrie vocabularul proiectului. Visual Paradigm Modelarea bazelor de date ❑ Se pot crea două tipuri de diagrame pentru modelarea bazelor de date: diagrame Entitate-Relaţie şi diagrame ORM (pentru a vizualiza maparea dintre modelul de obiecte şi modelul de date). ❑ Se pot modela nu numai caracteristici ale tabelelor, ci şi proceduri stocate, declanşatori, secvenţe şi viziuni ale bazei de date într-o diagramă Entitate- Relaţie. ❑ Diagramele se pot construi de la zero sau prin inginerie inversă plecând de la o bază de date existentă. ❑ Sincronizare între diagrama de clase şi diagrama Entitate-Relaţie pentru a asigura consistenţa între cele două modele. ❑ Generarea de cod SQL pornind de la modele. Visual Paradigm Generare de cod ❑ Generatoarele de inginerie inversă şi directă oferă suport pentru ingineria modelelor. Facilitatea Java Round-Trip engineering permite sincronizarea continuă a codului şi a modelului pentru limbajul Java. Model Inginerie directă Inginerie inversă Java x x C++ x x XML Schema x x PHP x x Python Source x x Objective-C x x CORBA IDL Source x x.NET dll sau fişiere.exe x CORBA IDL Source x XML (structure) x JDBC x Hibernate x C# x VB.NET x ODL x ActionScript x Delphi x Perl x Ada95 x Ruby x Visual Paradigm Interoperabilitate ❑ Interoperabilitatea facilitează schimbul de modele cu alte instrumente. Model Import Export Telelogic Modeler x Rational Rose x ERwin Data Modeler proiect x Rational Software Architect x Rational DNX x NetBeans 6.x UML diagrame x Visio x BPEL for Oracle workflow engine x BPEL for JBoss workflow engine x Diagram (JPG, PNG, SVG, EMF, PDF) x Microsoft Excel x x EMF UML2 model x x XMI (1.0, 1.2, 2.1) x x XML (nativ) x x Microsoft Word pentru modelul CU) x x Visual Paradigm Integrarea cu medii IDE ❑ Oferă suport pentru întreg ciclul de dezvoltare a unui sistem informatic folosind pentru etapa de programare următoarele produse de tip IDE : ▪ Eclipse ▪ NetBeans/Sun ONE ▪ IntelliJ IDEA Generarea documentaţiei ❑ Documentaţia poate fi partajată şi proiectată împreună cu beneficiarii sistemului folosind unul dintre formatele: HTML (report generation) , HTML (project publisher) , PDF , Word.