Cap

4.TEHNOLOGII NOI IN REALIZAREA SI DEZVOLTAREA SISTEMELOR INFORMATIONALE Obiective 1.Orientari privind tehnologiile de realizare si dezvoltare a SI 2.Tehnologia orientata obiect 3.Tehnologia orientata agent 4.Tehnologia modelarii unitare a proceselor (RUP) bazata pe UML 5.Structura statica a RUP 6.Structura dinamica a RUP 7.Avantajele relative ale diferitelor tehnologii

În prezentarea generală a sistemelor informaţionale(SI), ca arhitectură, ca modelare a activităţilor şi proceselor şi ca realizare a lor pe baza noilor TIC, s-a observat dificultatea unei abordări unitare a construcţiei SI, mai ales când anumite metode, tehnici, standarde, nu au un suport în instrumente, care să permită adaptarea simplă şi eficientă a cadrului metodologicconceptual la cerinţele particulare impuse de mediul unei firme/organizaţii. Realizarea în ultimii ani a mediilor de programare orientate obiect, a permis dezvoltarea unor metodologii care valorifică această orientare, prin care se poate trece la o tratare unitară, unificată, raţională, a descrierii activităţilor şi proceselor pe baza unui limbaj de modelare unificat (UML-Uniffied Modeling Language). Pe baza reunirii a trei metodologii orientate obiect, concepute şi/sau realizate de G. Booch (OOD – Object Oriented Design), J. Rumbaugh (OMT – Object Modeling Technique) şi J.Jacobson (OOSE – Object Oriented Software Engineering), s-a ajuns la elaborarea unui concept general pentru dezvoltare orientată obiect de produse informatice utilizate în SI. Acest concept a fost realizat şi este dezvoltat sub denumirea RUP (Rational Uniffied Processes) de firma Rational Software Corporation, unul din partenerii importanţi ai OMG (Object Management Group). Acest concept este susţinut de un instrument de realizare şi implementare foarte răspândit în ultimul timp, care utilizează UML – Rational Rose. Relativ recent, s-a extins conceptul de obiect, cu facilităţi de mobilitate şi cu reguli care să ghideze acţiunile lui, obţinându-se transformarea obiectului într-un agent activ, care întreprinde şi orientează acţiuni, reprezentând obiectul în lumea reală. Tehnologia bazată pe agenţi poate fi considerată o alternativă a tehnologiei bazată pe obiecte, însă această nouă tehnologie, în mod eficient, se poate implementa ca o extensie a tehnologiei orientată obiect. Această evoluţie recentă, foarte avansată, prin faptul că este susţinută de instrumente bazate pe noile TIC, impune o prezentare succintă a tehnologiilor orientate obiect şi agent şi a RUP, care se bazează pe UML, ca tehnologii de bază în conceperea SI. Prezentarea urmăreşte înţelegerea principiilor care susţin aceste tehnologii, în beneficiul utilizării lor în firme/organizaţii in cadrul SI care le utilizează, urmărind o flexibilizare şi adaptabilitate a lor în raport cu evoluţiile din piaţă.

4.1. Tehnologia orientată obiect Această tehnologie s-a impus deoarece asigură realizarea unor sisteme adaptive, flexibile, în condiţiile în care cerinţele de schimbare au o frecvenţă mare. O firmă uşor adaptabilă la cerinţele pieţei, trebuie să ofere soluţii rapide clienţilor, depăşind pe competitori ca timp de răspuns, prin reducerea inerţiei naturale, care inhibă schimbarea. SI pot fi prin ele însele inerţiale, dacă nu sunt concepute să facă faţă cerinţelor de schimbare. Realizarea în termen scurt a SI sau a dezvoltării lui, nu înseamnă că, automat, sistemul răspunde şi repede la schimbări. De aceea, sofware-ul realizat trebuie conceput suficient de flexibil pentru a fi uşor modificat în raport cu noi cerinţe şi oportunităţi, care apar pentru firmă/organizaţie. Tehnologia orientată obiect corespunde acestor cerinţe, obiectele în sine fiind unităţi adaptabile de software, cu condiţia să nu fie blocate în aplicaţii convenţionale. Prima utilizare a conceptului de obiect s-a făcut în libajul de simulare SIMULA (SIMUlation LAnguage), dezvoltat în Norvegia, în anii 1960, din nevoia de a realiza modelarea unor sisteme fizice complexe, cu mii de componente. Fiecare componentă trebuia descrisă în limbaj ca un modul, care corespunde deci unui obiect fizic din sistem, cu anumite caracteristici de mediu (vecinătăţi) şi date/informaţii despre starea lui. Interacţiunea acestor module/obiecte defineşte simularea. Conceptul de obiect-sofware a rezultat din necesitatea modelării obiectelor lumii reale (fizice), în vederea simulării, ca metodă de testare/experimentare în rezolvarea unor probleme de cercetare, fără a recurge la realizarea fizică a sistemului cercetat. În definirea tehnologiei orientate obiect există un standard, care se exprimă prin trei concepte-cheie: 1. Obiectele, care încapsulează procedurile şi datele 2. Mesajele, care susţin polimorfismul pe ansamblul obiectelor 3. Clasele, care implementează moştenirea în cadrul unor ierarhiii de clase. 1. Obiectele şi încapsularea Obiectul este un program (software package) care conţine o colecţie de proceduri înrudite/legate,asociate cu date. Procedurile se numesc frecvent metode, pentru a le deosebi de procedurile convenţionale, neataşate unor obiecte. Datele, de asemenea, sunt referite ca variabile, deoarece valoarea lor poate fi diferită în timp. O reprezentare a obiectului, definit în acest mod este cea din Figura 4.1, unde metodele şi variabilele sunt asamblate, pentru a forma un obiect. Ca exemplu, ne putem referi la un mijloc de transport ghidat automat (AGV – Automated Guided Vehicle), utilizat în transportul de piese, subansamble, semifabricate între maşini şi

diferite magazii/depozite, folosind palete special concepute. Un astfel de AGV, ca obiect într-o aplicaţie de simulare poate fi definit prin: •

Caracteristici tehnice, ca variabile/date: dimensiunea şi tipul paletei, capacitatea de încărcare, viteza de deplasare pe traseul ghidat (fir inductiv pe podea, pe căile de acces), tensiunea şi sursa de alimentare cu energie electrică etc.

•

Acţiuni sau activităţi, ca metode/proceduri, prin care intră în relaţii cu mediul înconjurător: deplasarea între diferite locaţii (maşini, depozite), încărcarea sau descărcarea paletei, cuplarea sau decuplarea AGV la sursa de energie, când este nevoie etc. M1

M2

M3

M11

M4 V1

V2 ..……...

M5 M8

Variabile

Mi

Metode

VN

M10 M9

Vi

M7

M6

Figura 4.1. Reprezentarea unui obiect prin variabile şi metode Obiectul definit în acest mod, reprezintă un mecanism de încapsulare, ca tehnică de a reuni variabilele (datele) şi metodele (procedurile) corespunzătoare. Pe timpul unei simulări, obiectul va realiza diferite acţiuni, utilizând anumite caracteristici, ca efect al cerinţelor impuse de acţiuni. Obiectul acţionează ca un element independent (definit şi întreţinut independent de alte obiecte), arătând „ceea ce ştie” prin variabile şi „ceea ce poate face” prin metode. 2. Mesaje şi polimorfism Varietatea infinită de obiecte a lumii reale interacţionează prin mesaje. Calea prin care un obiect interacţionează cu altul este reprezentată de o întrebare privind realizarea unei metode la obiectul adresat. În acest mod, unei mesajul reprezintă un nume al unui obiect, urmat de un nume al metodei pe care acel obiect ştie s-o execute. Obiectul care iniţiază mesajul (emiţător/sender) poate fi solicitat cu informaţii suplimentare (pentru metoda solicitată, ţinute de emiţător ca parametri), de către obiectul adresat (receptor/receiver). În exemplul dat cu AGV, un mesaj poate fi:

În acest mesaj, „transportor 202” este numele receptorului (AGV), „deplasează la” este metoda cerută a fi executată, iar „maşina M05”, este un parametru reprezantând codul maşinii destinaţie, prin care se spune AGV-ului unde să facă deplasarea. Obiectele emiţătoare şi receptoare trebuie să se pună de acord asupra formatului mesajelor, în cadrul „semnăturii mesajului”, care specifică numele metodei care se va executa şi parametrii incluşi, necesari execuţiei. Diferite obiecte pot răspunde la un mesaj generic, însă fiecare obiect poate interpreta acest mesaj în moduri diferite. Mesajul „deplasează la”, poate fi interpretat deosebit de un obiect „mijloc de transport”, depinzând de natura lui (AGV, camion, vapor, tren etc). Polimorfismul reprezintă abilitatea diferitelor obiecte de a răspunde la un mesaj receptat în moduri diferite. Comunicarea umană este natural polimorfică. În tehnologia orientată obiect, fiecare obiect poate avea un răspuns unic la acelaşi mesaj. 3. Clase şi moşteniri În activităţile de modelare şi simulare, de cele mai multe ori, se lucrează cu mai multe obiecte de acelaşi tip, pentru a face mai eficient modul de lucru, prin eliminarea unor definiri multiple a obiectelor pentru fiecare tip de obiect în parte, cum ar fi cazul cu definirea mai multor AGV-uri de diferite tipuri, ca vehicule de transfer într-o fabrică cu linii flexibile de fabricaţie. În acest fel, se ajunge la definirea clasei, ca un program parametrizat (software template), care defineşte metodele şi variabilele ce urmează a fi incluse în definirea unui tip de obiect particular. Metodele şi variabilele asociate obiectului sunt definite o singură dată în clasă, iar obiectele care intră în compunerea ei, denumite exemple (instances) sau instanţieri, sunt definite prin valorile particulare ale variabilelor. În exemplul dat, putem defini clasa AGV prin metode şi variabile, iar instanţierile clasei sunt transportoare de tip AGV cu caracteristici particulare („transportor 202”, „transportor 201” etc). O funcţie importantă a clasei se referă la specificarea mesajelor pe care obiectele clasei le pun la dispoziţia altor obiecte, prin ceea ce numeşte interfaţa mesajului. Această interfaţă este definită prin colecţia de semnături de mesaje, fiecare semnătură definind numele şi parametrii pentru un mesaj particular. În Figura4.2 se prezintă o ilustrare a noţiunilor de clasă, instanţiere/exemplu şi interfaţă a mesajului.

Clasa Variabile Metode

Instantiere

Interfata mesaje

Valori

…...

Valori

…...

Valori

Figura 4.2. Reprezentarea noţiunilor de clasă de obiecte, de exemple/instanţieri şi de interfeţe ale mesajelor (colecţie de semnături) Pentru a simplifica modul de lucru cu clasele, se recurge la definirea unei clase ca un caz particular al unei clase mai generale, printr-un mecanism numit de moştenire (inheritance). În mod obişnuit, se folosesc noţiunile de superclase (clase generale) şi subclase (clase speciale) legate prin mecanismul de moştenire, cum se arată în Figura 4.3.

Mostenire

Superclasa

Suprapunere

... Subclase

...

Subclase

Figura 4.3. Reprezentarea superclasei şi sublaselor cu mecanismul de moştenire şi suprapunere Subclasele, în plus faţă de superclase pot defini metode şi variabile proprii, prin tehnica de suprapunere (overriding). În exemplul prezentat, clasa mai generală (superclasă) AGV poate fi partajată în două subclase: AGV Palete şi AGV Role, fiecare moştenind caracteristicile generale de AGV, cu particularitatea realizării transferului prin palete (cu aşezarea pieselor) sau prin dispozitive de

fixare a rolelor (de tablă, tole, turnate de tip tor etc). Fiecare subclasă de AGV îşi poate stabili caracteristicile proprii, prin adăugire sau suprapunere la cele definite prin moştenire. Prin moştenire se transmit şi interfeţele pentru mesaje, asigurând că subclasele pot răspunde la orice mesaj preluat de superclasă (clasă părinte). Cu ajutorul claselor se pot realiza ierarhii, de tipul structurilor arborescente, în care moştenirea se acumulează automat prin toate nivelurile. O asemenea structură ierarhică este cunoscută ca o clasă ierarhică. 4.2 Tehnologia orientată agent În multe aplicaţii ce compun sistemele informaţionale, mai ales atunci când deservesc medii cu mare dispersie geografică sau medii cu prelucrare distribuită, se simte nevoia ca obiectele definite şi utilizate în tehnologia orientată obiect, să fie dotate/echipate/înzestrate cu capacitatea de a acţiona asupra mediului pe baza unor reguli, asumându-şi responsabilităţi în funcţionarea sistemului. Aşa cum s-a amintit în partea introductivă a capitolului, prin această evoluţie s-a ajuns ca un obiect să devină un agent activ, reprezentând şi orientând acţiuni ce corespund

obiectivelor

din

lumea

reală,

care

constituie

mediul

de

acţiune

al

aplicaţiilor/sistemelor, mediu care poate fi într-o continuă schimbare. O reprezentare generală a agentului se arată în Figura 4.4, unde se evidenţiază capacitatea agentului de a percepe mediul sau lumea reală, de a acţiona asupra acestui mediu şi de a comunica cu alţi agenţi, care acţionează în acelaşi mediu sau în medii diferite.

Agent

Agent

Comunicare Perceptie/Intrare Actiune/Iesire

Mediu

Mediu

Figura 4.4 Reprezentarea unui agent în raport cu mediul în care acţionează În definirea noţiunii de agent există dificultăţi, deoarece această noţiune este folosită în limbajul uzual, polisemantic (agent imobiliar, agent secret, agent de asigurări, agent financiar etc), iar în comunitatea IT ca un metatermen în definirea unor cercetări în diferite domenii: roboţi bazaţi pe cunoştinţe (knowbot, knowledge-based robot), robot software(softbot, software-robot), robot bazat pe task (taskrobot, task-based robot) etc . Se consideră de asemenea că agentul trebuie tratat în contextul unei mulţimi de agenţi care acţionează în lumea reală.

În domeniul sistemelor informaţionale, un agent nu poate fi în esenţă decât de natură software, un program care realizează, în „numele cuiva” sau al altui agent, o serie de acţiuni: -

automatizarea unui task într-un program complex de tip utilitar (sortare, indexare etc) sau de altă natură;

-

utilizarea cunoştinţelor acumulate pentru activităţi de planificare, programare a fabricaţiei, sau de negociere a utilizării resurselor pentru aceste operaţiuni;

-

poate fi activat de un anumit eveniment monitorizat sau executat de un alt task, de exemplu cel de colectare şi filtrare a informaţiilor de interes prin căutarea anumitor pagini web;

-

se poate muta de pe un site pe altul pentru a colecta informaţii sau pentru a se executa;

-

interacţionează cu utilizatorul şi comunică cu alţi agenţi în mod cooperant şi coordonat;

-

acumulează cunoştinţe (învaţă) în timp, schimbându-şi comportamentul ca răspuns la condiţiile în schimbare din mediu;

-

operează din proprie iniţiativă în anumite momente, raportând periodic asupra acţiunilor întreprinse.

Agenţii pot fi individuali sau membri ai unui sistem cu mai mulţi agenţi (Sistem multiagent-SMA). Practic, un SMA este o implementare a unei colecţii de agenţi (de natură software) care se caracterizează prin: -

existenţa mai multor platforme de tip agent, reprezentând un ansamblu de servicii corelate între ele;

-

oferirea unor servicii de tip agent (înregistrare, logg-in, vizualizarea activităţilor etc) şi a unor resurse (entitate cu anumite proprietăţi, alocator uniform de resurse - URL şi limitări de capacitate);

-

asigurarea mijloacelor pentru definirea, denumirea şi înregistrarea agenţilor cu permiterea (opţională) a mobilităţii lor.

În general, în cadrul unui SMA, agenţii sunt omogeni, însă pot fi şi eterogeni, caz în care interoperabilitatea se asigură printr-o structură de tip grilă (grid), în curs de definitivare. Internetul este un mediu deschis, în care agenţii pot interacţiona între ei pentru a-şi atinge scopurile individuale sau comune pentru care au fost realizaţi, cu condiţia rezolvării a două probleme: -

agenţii trebuie să se găsească reciproc, deoarece pot apare, dispare sau muta în orice moment;

-

după ce s-au identificat şi găsit, să fie capabili să interacţioneze.

Cele mai importante proprietăţi ale agenţilor software, care trebuie să se regăsească în proiectarea unui singur agent sau SMA, sunt [BRAD97]: -

autonomia, prin care agenţii sunt proactivi, orientaţi spre anumite scopuri, acţionând pe cont propriu, realizând taskuri în numele utilizatorului, fără a apela la el (încunoştinţare, confirmare, intuiţie);

-

adaptivitate, prin care se adaptează şi învaţă, în mod dinamic, în şi despre mediul în care acţionează;

-

reactivitate, prin care sunt activaţi de evenimente, fiind senzitivi la evenimente în timp real, deci o capabilitate de a simţi şi reacţiona;

-

mobilitate, prin care se pot deplasa unde sunt necesari, urmând un itinerariu;

-

cooperativitate, prin care cooperează în mod coordonat şi negociază, pentru a atinge obiective comune, putând delega anumite funcţii/responsabilităţi altor agenţi;

-

interactivitate, prin care interacţionează cu omul, cu alţi agenţi, cu sisteme existente (moştenite), cu surse de informaţii;

-

sociabilitate, prin care asigură o cooperare în atingerea unor scopuri comune, fără a avea intenţii negative şi distructive;

-

personalitate, prin care agenţii manifestă caracteristici specifice omului: convingeri, dorinţe, intenţii şi chiar emoţii, inclusiv abilitatea de a lua în considerare preferinţe şi caracteristici personale ale utilizatorilor, adaptându-şi comportamentul în funcţie de aceştia ( prin ceea ce se numeşte personalizare).

Pentru a defini gradul de autonomie şi autoritate cu care este investit un agent, se foloseşte noţiunea de agentitate, măsurată calitativ, prin natura interacţiunii între agenţi şi alte entităţi din sistem. La minimum, agentul trebuie să se execute asincron, iar prin creşterea gradului de agentitate el poate atinge, în extrem, un utilizator. Agenţii, în diversitatea lor, pot fi clasificaţi după mai multe criterii: 1. După rolul pe care-l are în cadrul SMA: -

agent asistent personal al utilizatorului, care acţionează cu acesta şi în numele acestuia;

-

agent de interfaţă, care asigură monitorizarea acţiunilor utilizatorului în cadrul interfeţei cu acesta;

-

agent de informare, care poate fi individual sau un SMA, urmărind colectarea informaţiei din surse multiple, direcţionând-o chiar către mai multe destinaţii;

-

agent de translatare, care translatează informaţii dintr-un format/limbaj în alt format/limbaj;

-

agent de rutare, care este parte a unui graf distribuit, asigurând extragerea, concatenarea şi direcţionarea datelor către alţi agenţi din acel graf;

-

agent de resurse, care este ataşat unei resurse pe care o reprezintă;

-

agent de execuţie, care este implementat ca un sistem de cunoştinţe bazat pe reguli, cu mai multe funcţii pentru supervizarea execuţiei cererilor, pentru operare pe bază de script-uri etc.

-

agent de ontologie, ca un agent de translatare special, cu un rol important în translatarea expresiilor, declaraţiilor între diferite ontologii, asigurând accesul la ontologii şi gestionând evoluţia lor.

2. După atributul principal: -

agent reactiv, caracterizat de un fir propriu (succesiune...) de execuţie şi control, care răspunde în timp real la mesaje ale altor agenţi şi la evenimente din mediul exterior;

-

agent inteligent, care dispune de capacitatea de a raţiona şi de comportament bazat pe învăţare, adaptându-se la mediu în funcţie de obiectivele utilizatorului şi de resursele disponibile.

3. După gradul de mobilitate: -

agent mobil, care se poate deplasa/muta din mai multe motive (pentru a urma un utilizator, pentru a executa task-uri pe alte calculatoare, pentru a rezolva o problemă cu entităţi mobile în lumea reală), fiind caracterizaţi de mobilitate, ca măsură a gradului ce exprimă capacitatea de a „călători” în reţea (scenariile/scrip-urile mobile, obiectele mobile, pot fi compuse pe un calculator şi deplasate pe altele, pentru execuţie);

-

agent staţionar, care execută numai pe platforma pe care a fost creat, influenţând numai acţiuni la distanţă prin comunicare.

Agenţii care cooperează în cadrul sistemelor multi-agent sunt de mai multe tipuri: -

agent furnizor (de informaţii sau servicii), care oferă utilizatorilor sau altor agenţi diferite tipuri de servicii: căutare de informaţii, operaţiuni specifice în e-commerce etc;

-

agent solicitant (de informaţii sau servicii), care consumă informaţii şi servicii oferite de alţi agenţi din sistem, de obicei printr-un intermediar;

-

agent intermediar sau de mediere, care poate avea mai multe funcţii: cea de identificare sau consultare (agent de tip matchmaker), cea de brokeraj (agent de tip broker), sau cea de stocare (agent de tip blackboard).

O ilustrare a modului în care cooperează cele trei tipuri de agenţi în cadrul unui sistem multiagent se arată în Figura 4.5. Cerere de serviciu Agent solicitant

Nume furnizor

Agent matchmaker

Rezultatul serviciului Agent furnizor

Prezentarea serviciilor oferite

Cerere de serviciu

a) Agent intermediar de tip matchmaker Cerere de serviciu Agent solicitant

Agent broker

Rezultat serviciu Cerere de serviciu Agent furnizor

Prezentarea serviciilor oferite

b) Agent intermediar de tip broker Figura 4.5. Cooperarea agenţilor în cadrul SMA Pentru a înţelege mai bine structurarea şi suportul acţiunilor agenţilor în cadrul SMA, este utilă prezentarea arhitecturilor bazate pe agenţi, pe baza noţiunilor definite: •

Arhitectura agentului, care prezintă agentul ca entitate independentă, reactivă sau proactivă, în care percepţia alimentează raţionamentul care, la rândul lui, generează acţiunile agentului: Perceptie

•

Rationament

Actiune

Arhitectura sistemului multi-agent (SMA), care prezintă agentul ca entitate de tip furnizor/ consumator de servicii, care interacţionează cu alţi agenţi, direct sau prin intermediul unui mediator:

Furnizori de servicii

Consumator de servicii

. . .

Mediator

Furnizori de servicii

Consumator de servicii

Funcţionarea SMA se bazează pe o infrastructură, prin care se asigură regulile pe care trebuie să le respecte şi să le urmeze agenţii, pentru a comunica între ei şi pentru a se înţelege reciproc. Infrastructura SMA, într-o formă generală, se poate reprezenta în următoarea componenţă:

Agent

Protocol de comunicare

Ontologii

Protocol de interactiune

Canal de comunicare

Agent

Componenta infrastructurii SMA

Principalele elemente ale infrastructurii SMA se referă la: •

ontologii, prin care se pun de acord asupra semnificaţiei conceptelor;

•

protocoale de comunicare, prin care se descrie limbajul de comunicare între agenţi;

•

protocoale de interacţiune, prin care se descriu convenţiile în interacţiunea agenţilor;

•

canale de comunicare, prin care se precizează mediul de comunicare între agenţi. În utilizarea agenţilor, se folosesc instrumente de construire a lor, care constituie aşa

numitul cadru de lucru al agentului, realizat de diferite firme (ex. Agent Builder – Reticular Systems Inc., Aglets – IBM, Agents – International Knowledge Systems, Line Agent – Alcatel etc.).

Informaţii

privind

astfel

de

instrumente

se

pot

găsi

la

adresa:

http://www.agentbuilder.com/AgentTools/ În comparaţie cu tehnologia orientată obiect, tehnologia bazată pe agenţi în realizarea SI prezintă o serie de avantaje: •

agenţii au autonomie, reactivitate etc, care lipseste obiectelor;

•

obiectele necesită control extern în execuţia propriilor metode, în timp ce agenţii îşi ghidează singuri acţiunile;

•

obiectele au un fir de execuţie pentru toată aplicaţia, în timp ce agentul are un fir de execuţie propriu;

•

obiectele încapsulează numai starea, comportamentul fiind ghidat din exterior, pe când agenţii încapsulează atât starea cât şi comportamentul;

•

interfaţa standard pentru instrumentele în orientarea obiect se realizează prin manipulare directă (see – and – point) cu o serie de probleme atunci când creşte complexitatea produselor software; interfaţa standard la instrumentele pentru agenţi se realizează prin manipulare indirectă (ask – and – delegate), cu o serie de avantaje: scalabilitate şi descentralizare, acţiuni planificate sau conduse de evenimente, flexibilitate, abstractizare, orientare pe task-uri etc. Aceste avantaje sunt evidente în reingineria proceselor, care se realizează prin lucrul într-o

echipă, în general distribuită ca locaţii, cu resurse informaţionale şi de cunoaştere distribuite, care favorizează lucrul autonom, dominant prin comunicare asincronă. În acest sistem se poate realiza o coordonare şi negociere între utilizatori, o mediere între utilizatori în folosirea resurselor precum şi planificarea dinamică a activităţilor în funcţie de rezultate etc.

4.3 Tehnologia modelării unitare a proceselor În acest paragraf se prezintă noţiunile de bază care definesc un proces unitar (unificat) de modelare a proceselor care exploatează la maximum facilităţile oferite de standardul UML. Acest proces, denumit în continuare RUP (Rational Unified Process), se bazează pe lucrarea lui Philippe Kruchten [KRUC99], arhitectul conceptului şi produsului RUP, marcă înregistrată a firmei Rational Software Corporation. Merită prezentată şi aprecierea celor trei autori de bază ai tehnologiei orientată obiect (Booch, Jacobson, Rumbaugh) în legătură cu RUP: ” RUP cuprinde cele mai bune şi verificate practici ale metodelor de dezvoltare a software-ului, adaptate optimal la facilităţile UML.” 4.3.1. Prezentarea generală a RUP RUP este un proces de inginerie software, care permite o abordare ordonată în asigurarea sarcinilor şi responsabilităţilor în cadrul unei organizaţii, urmărind asigurarea producerii unui software de înaltă calitate, care satisface cerinţele utilizatorului final în cadrul unui interval de timp şi a unui buget predictibil. RUP este un produs proces (process – product) dezvoltat şi întreţinut de firma Rational Software, cu ajutorul unui set de instrumente de dezvoltare. Această caracteristică deosebeşte RUP de alte metode şi tehnici, care s-au elaborat în timp, fiind statice prin natura lor (cărţi, manuale, documentaţii etc.), repede depăşite de cerinţe şi evoluţiile în domeniul TIC. Caracteristicile de bază ale RUP sunt:

•

actualizarea curentă de către firma producătoare;

•

produsul este disponibil folosind tehnologia web la site-ul firmei (www.rational.com);

•

poate fi adaptat la nevoile organizaţiei;

•

este susţinut de un ansamblu de instrumente care stau la dispoziţia conceptorilor şi proiectanţilor, inclusiv standardul UML Componentele produsului RUP sunt accesibile în versiune on-line sau ca un set de

manuale: 1. Versiunea on-line (în HTML) cuprinde: -

ghid de utilizare a setului de intrumente de lucru (ex. Rational Rose for visual modeling sau Clear Quest for configuration management)

-

„Templates” (modele/ prototipuri) pentru principalele „artifacts”, ca principale grupări informaţionale (rezultate din prelucrarea datelor), care se produc, modifică sau utilizează de un proces: •

Rational SoDA, pentru documentarea automată a software-ului

•

Requsite Pro, pentru gestiunea cerinţelor

•

MS Word, pentru majoritatea documentelor elaborate

•

MS Project, pentru planificarea proceselor

•

MS Front Page, pentru extinderea procesului on-line în sine, dacă este nevoie.

2. Set de manuale şi documentaţii care descriu RUP, utile celor ce sunt ataşaţi în timp proiectului sau celor care doresc să studieze în mod tradiţional. Versiunea on-line are multe conexiuni (hipertext links) şi imagini interactive, care permit o navigare uşoară, folosind browsere suport, de tipul Netscape Navigator sau MS Internet Explorer. Arhitectura generală a RUP se bazează pe două structuri de bază, sau dimensiuni, aşa cum arată în Figura 4.6: -

dimensiunea orizontală, reprezentând structura dinamică, cu fazele, iteraţiile, ciclurile şi reperele desfăşurării în timp a procesului;

-

dimensiunea verticală, reprezentând structura statică, prin fluxurile de lucru în care activităţile sunt grupate logic, prin natura lor.

În cadrul RUP sunt incluse cele mai reuşite practici în realizarea aplicaţiilor şi sistemelor de mare complexitate, între care:

Inceputul

Elaborarea

Constructia

Iteratiile de început

Elab.nr.1... Elab.nr.n

Constr.nr.1... Constr.nr.m

Tranzitia la noul sistem

Fluxuri de lucru

Modelarea Definirea cerintelor Analiza si proiectare Implementare Testare

Fluxuri suport

Structura statica (fluxuri de lucru)

Faze

Aplicare si dezvoltare Configurarea si managementul schimbarii Managementul proiectului Schimbari ale mediului

Tr.nr.1... Tr.nr.k

Iteratii pe faze Structura dinamica (iteratii, faze) Figura 4.6. Arhitectura pe două dimensiuni a RUP - Dezvoltarea iterativă, superioară celei liniare sau în cascadă (salturi), deoarece permite considerarea cerinţelor care se schimbă, asigurând integrarea treptată şi nu bruscă, evitând riscurile care pot apărea din timp şi corectarea treptată a erorilor. - Cerinţele privind mamagementul proiectului prin: control mai bun, creşterea calităţii software-ului la utilizator, reducerea costurilor şi întârzierilor, creşterea eficienţii lucrului în echipă. - Concentrarea activităţilor de proiectare pe conceptul de arhitectură adoptat şi pe utilizare a componentelor software, prin care sunt realizate funcţii bine definite, cu delimitări

clare, care pot fi integrate într-o arhitectură

definitivă. Acestă tendinţă este susţinută de

orientarea CORBA (Common Object Request Broker Arhitecture), de utilizarea Internet, Java Beans ca standard de reutilizare a codului, accentuând tendinţa spre compunerea software (prin asamblare de componente), în locul programării clasice. - Utilizarea modelării şi a UML la un sistem de dezvoltare, deoarece modelele ajută la conturarea şi înţelegerea atât a problemei, cât şi a soluţiei pentru acea problemă. UML este un limbaj grafic pentru vizualizarea, specificarea, construirea şi documentarea artifactelor (artifacts) unui sistem realizat prin software. - Utilizarea managementului schimbării, ca abordare sistematică a gestiunii schimbărilor, a proiectării şi implementării, în cadrul unei dezvoltării iterative. - Asigurarea calităţii se realizează atât la nivelul produsului (ca software sau sistem) şi a elementelor care îl compun (componente, subsisteme etc.), cât şi la nivelul procesului în ansamblul său şi al artifactelor realizate ca suport al produsului principal. În plus, RUP mai are trei caracteristici importante, referitoare la utilizarea în „cazurile care conduc la valoare” (use cases) pe timpul dezvoltării, la cadrul general ce poate fi adaptabil oricărei organizaţii, folosind instrumente suport pentru proces. Noţiunea use-cases se defineşte în RUP ca o secvenţă de acţiuni realizate de sistem, care produce un rezultat cu valoare pentru un utilizator (în RUP se numeste actor, ca persoană exterioară sistemului, care interacţionează cu sistemul). 4.3.2. Structura statică în RUP Un proces, în general, descrie cine face, ce face, cum face şi dupa ce face, în cadrul procesului, considerat ca un ansamblu coerent de activităţi. În cadrul RUP procesul este reprezentat cu ajutorul a patru elemente de modelare primare: -

executanţii (workers) pentru cine face,

-

activităţile (activities) pentru ce face,

-

artifactele (artifacts) pentru cum face,

-

fluxurile de lucru (workflows) pentru după ce face, ca secvenţă a diagramelor de activităţi ce conduc la un rezultat, reprezentate în Figura 4.6 Executantul în cadrul RUP se referă la rolurile care definesc modul cum o persoană ar

trebui să muncească. În acest sens, un executant realizează unul sau mai multe roluri si ca urmare este posesorul (owner) unui set de artifacte. În cadrul RUP executantul nu se referă la o persoană fizică, ci la rolurile pe care o persoană le poate avea şi la responsabilităţile lor pentru artifacte. În acest sens, în RUP există 27 de executanţi, între care:

•

Arhitectul, care conduce activităţile tehnice şi artifactele în derularea proiectului, stabilind structura de ansamblu a activităţilor şi interfeţele între diferite grupări de lucru.

•

Proiectantul, care defineşte responsabilităţile, operaţiile, atributele şi relaţiile uneia sau mai multor clase (ca set de obiecte), stabilind modul de adaptare al lor la mediul de implementare.

•

Analistul de sistem, care pregăteşte şi coordonează cerinţele necesare şi modelarea claselor (use-cases) prin conturarea funcţionalităţii sistemului şi limitările lui.

•

Proiectantul de baze de date, care defineşte toate elementele necesare construcţiei bazei de date, necesare la memorarea, regăsirea şi ştergerea obiectelor.

•

Managerul de proiect, care alocă resursele, stabileşte priorităţile, coordonează interacţiunile cu utilizatorii şi clienţi, asigurând concentrarea echipei pe realizarea obiectivelor definite în proiect. Pentru fiecare executant, trebuie definit un set de aptitudini pe care trebuie să le

îndeplinească o persoană care a fost desemnată ca executant. Activitatea se defineşte ca o unitate/parte a execuţiei (muncii, work), pe care un executant (worker) poate fi solicitat să o realizeze. Scopul activităţii este de a crea sau actualiza artifactele (modele, clase, planuri, etc). Fiecare activitate este atribuită unui executant anume. Ca exemple de activităţi sunt: realizarea şi iterarea planului proiectului (de către managerul de proiect), verificarea proiectării (de către proiectantul evaluator), realizarea testului de performanţă (de către verificatorul de performanţă) etc. Activităţile se realizează în mai mulţi paşi/faze: -

faza de gândire, în care este înţeleasă natura taskului, se strâng şi se examinează artifactele de intrare şi se formulează ieşirile;

-

faza de realizare, în care executantul realizează şi actualizează artifactele;

-

faza de evaluare, în care executantul compară rezultatele cu unele critrii stabilite. Artifactele se definesc ca un ansamblu de informaţii care sunt produse, modificate

sau utilizate de un proces. Artifactele sunt produsele unui proiect, care se realizează şi utilizează pe parcursul proiectului, în vederea obţinerii produsului final. Artifactele sunt folosite ca intrări de către executanţi pentru activităţi sau se obţin ca rezultate ale acestor activităţi. Artifactele sunt grupate în RUP în una din următoarele cinci categorii, sau seturi informaţionale (information sets): -

pentru management (M)

-

pentru cerinţe (C)

-

pentru proiectare (P)

-

pentru implementare (I)

-

pentru utilizare şi dezvoltare (D)

În cadrul unui proces iterativ de dezvoltare a procesului, fiecare set din cele cinci categorii se modifică pe durata ciclui de dezvoltare, aşa cum se arată în Figura4.7.

Faza de început

M C

P

I

Faza de elaborare

D

M C

P

I

D

Faza de constructie

M C

P

I

D

Faza de tranzitie

M C

P

I

D

Figura 4.7 Evoluţia artifactelor în cele cinci categorii Fluxurile de lucru Executanţii, activităţile şi artefactele, pentru a constitui un proces, trebuie să fie asociate unor secvenţe de activităţi, care produc anumite rezultate de valoare, cu specificarea interacţiunilor între executanţi. Fluxul de lucru (workflow) este o secvenţă de activităţi care produce un rezultat cu o valoare observabilă. Un exemplu de flux de lucru se prezintă în Figura 4.8, sub forma unor diagrame de activităţi. Organizarea activităţilor în fluxurile de lucru se poate face în mai multe feluri: -

prin fluxuri de bază (core process workflow), aşa cum se prezintă în Figura4.6 pentru nouă grupări,

-

prin fluxurile iterative, ca instanţieri ale procesului pentru o iteraţie,

-

prin fluxuri de detaliu, ca o explicitare a fluxurilor de bază. În structura statică a RUP, în afară de executanţi, activităţi şi artifacte, se mai folosesc

încă trei elemente de proces adiţionale: -

ghidurile, care însoţesc activităţile, diferite faze şi artifactele;

-

templetele (templates), ca modele sau prototipuri pentru artifacte;

-

asistentul, pentru instrumentele software folosite (tool mentor);

-

conceptele, introduse separat, în diferite secţiuni ale procesului, ataşate fluxurilor de bază.

Structura statică prezentată, constituie în RUP ceea ce se numeşte cadrul de lucru pentru proces (process frame work).

Arhitect

Proiectant

Analiza arhitecturii

Descrierea concurentei

Proiectarea arhitecturii

Analiza obiectelor

Proiectarea obiectelor

Evaluarea analizei

Evaluator

Descrierea distribuirii

Evaluarea proiectarii

Evaluarea arhitecturii

Figura 4.8 Exemplu de flux de lucru cu trei executanţi

4.3.3 Structura dinamică a RUP Structura dinamică a RUP se referă la ciclul de viaţă al procesului, pe baza unei dezvoltări iterative, cu fazele, reperele şi iteraţiile sale, asociate cu factorii ce influenţează procesul: reducerea riscului şi evoluţia incrementală. Rezolvarea multor probleme sau proiecte inginereşti, se realizează în timp, parcurgând etapele rezolvării secvenţial, cum se arată în Figura 4.9.

Cerinta clientului

Analiza cerintei

Specificatii ale cerintei 1 Specificatii de proiectare

Proiectare 2

Constructie Programe sursa (codificare, testare) 3

Integrare 4

Produsul software Fig. 4.9 Procesul secvenţial în realizarea unui produs software Etapele specifice rezolvării problemelor inginereşti tradiţionale au fost preluate şi mai sunt încă, în realizarea produselor software mai simple sau mai complexe. Aceste etape sunt: 1. Cerinţa clientului (utilizatorului) trebuie bine înţeleasă şi analizată, cu restricţiile posibile în satisfacerea ei. Analizată şi înţeleasă, cerinţa se trece, sub forma unor specificaţii scrise, etapei următoare, după ce au fost validate de toţi cei interesaţi. 2. Pe baza specificaţiilor cerinţei, se realizează proiectarea soluţiei, care satisface cerinţele şi restricţiile evidenţiate în prima etapă. Soluţiile agreate de cei interesaţi, sub formă de proiect, se transmit etapei următoare (ca specificaţii rezultate din proiectare, deci ca documentaţie). 3. Implementarea sau realizarea folosind metodele şi tehnicile cele mai evoluate, ca medii de programare (limbaje, instrumente , testare) în cazul produselor software, care sunt livrate ca programe sursă etapei următoare.

4. Integrarea diferitelor componente şi verificarea lor în raport cu cerinţele şi specificaţiile din etapele anterioare. În cazul satisfacerii acestor cerinţe şi specificaţi, rezultă produsul software final, implementat şi utilizat pe platforme hardware dimensionate corespunzător. 5. Recepţia produsului şi confirmarea satisfacerii cerinţei clientului (utilizatorului). Practica inginerească de zeci şi sute de ani, în realizarea unor proiecte mai simple sau mai complexe, de tipul caselor, podurilor, avioanelor, vapoarelor etc, care au o expresie fizică, confirmă corectitudinea şi succesul realizării unor asemenea proiecte, parcurgând etapele prezentate. În realizarea produselor software există o experienţă de câţiva zeci de ani, din care rezultă concluzia că succesiunea etapelor nu duce totdeauna la succes, datorită specificului acestor produse şi a modului în care ele sunt specificate şi realizate. Câteva din motivele acestei concluzii sunt: -

contextul realizării produselor software este complet diferit de cel al altor produse inginereşti

deoarece pe parcurs cerinţele se pot schimba: •

utilizatorul exprimă cerinţe noi;

•

problema se poate schimba, atunci când utilizatorul vede soluţia finală;

•

tehnologia de realizare a produsului se schimbă pe timpul derulării proiectului;

•

cerinţele pieţei se modifică, în raport cu produsul obţinut la final;

•

cerinţele şi specificaţiile iniţiale nu pot fi realizate cu suficientă precizie şi detalii cerute de execuţia lor.

-

proiectele simple, de scurtă durată (luni, un an) se pot realiza ca un proiect secvenţial cu

succes, în timp ce proiectele complexe, de lungă durată (ani), cu multe noutăţi, necunoscute şi riscuri, nu au succes. -

defecţiunile în produsele software se descoperă târziu, în faza de integrare şi testare, de aceea procesele trebuie să aibă o reacţie inversă la intervale scurte de timp, pentru a creşte

responsabilitatea şi a face corecţiile înainte de a deveni greu de făcut; se ajunge în acest fel la nevoia de a „comprima timpul” şi de a obţine rezultatul final chiar şi parţial, la intervale cât mai scurte de timp. -

în abordarea secvenţială, obiectivul fiecărei faze/etape îl reprezntă

producerea

sau

completarea unui artifact intermediar (de obicei o documentaţie), care este revăzut, aprobat şi fixat, ca punct de pornire în etapa următoare; orice revenire, ca reacţie inversă, în etapele precedente este posibilă, însă este considerată o perturbare, mai greu acceptată. -

în procesele secvenţiale nu se poate garanta o bază de timp în execuţia unui produs, deoarece

schimbarea unei facilităţi/funcţii în etapa finală, presupune consum de timp suplimentar în refacerea sau îmbunătăţirea ei, începând chiar din etapa iniţială; în acest caz este acceptat ca bază volumul realizărilor validate într-un interval de timp mai mare. Toate aceste realităţi în realizarea produselor software au forţat trecerea la o altă abordare, prin care se asigură o perfomanţă superioară faţă de cea secvenţială. Această abordare nouă, numită şi iterativă, aplică în interiorul fiecărei etape a ciclului din abordarea secventiala, toate etapele specifice ciclului, pentru a asigura obţinerea, de la sfârşitul întregului ciclu, un produs complet (ca funcţii), stabil şi de calitate, preluat de client (utilizator). O comparaţie a celor două abordări se arată în Figura 4.10.

Abordare secventiala

A P PT IT A

A P

Abordare iterativa

A P

PT

P PT

IT

P PT

IT

PF

A PT IT

IT PF t

Figura 4.10 Comparaţie între abordarea secvenţială şi abordarea iterativă în ciclul de viaţă al unui produs Această abordare nouă ridică şi o serie de probleme care au soluţii în RUP: •

Cum se obţine în această abordare un produs, fără a relua de la început procesul în fiecare iteraţie/etapă?

•

Cum se face selecţia obiectivelor care trebuie finalizate în fiecare iteraţie (care cerinţe sunt considerate şi cu ce risc)?

•

Cum rezolvă această abordare problemele prezentate mai sus, ca fiind neajunsuri ale abordării secvenţiale?

Răspunsurile – soluţii ale RUP sunt următoarele: câştigarea/realizarea controlului prin faze şi repere.

Din punctul de vedere al managementului de proiect, trebuie asigurată convergenţa de la iteraţie la iteraţie, spre produsul final, iar din cel al managementului, trebuie evidenţiate repere în timp, care au rol de funcţii de intrare, definite pe bază de criterii clare. În acest fel se ajunge la organizarea procesului pe faze, cu repere (milesotnes), la care se decide validarea, respingerea sau schimbarea drumului parcurs (cu rezultate prevăzute), aşa cum se arată în Figura 4.11.

Legenda: P - Produsul final I – Inceputul E – Elaborare C - Constructia T - Tranzitia

I

E Reper de obiective

C Reper de arhitectura

T

P

Reper de capabilitate initiala operationala

Reper de produs final

Figura 4.11 Fazele şi reperele în procesul iterativ Fazele în această abordare se deosebesc de etapele din abordarea secvenţială prin faptul că fiecare fază se termină cu un reper de verificare/evaluare. Conţinutul fazelor este: •

Începutul (I) – presupune definirea viziunii asupra produsului final şi a scopului proiectului pentru un caz particular de organizaţie/firmă (business), care sunt marcate de reperul de obiectiv în ciclul de viaţă (LCO- life cycle obiective milesotne).

•

Elaborarea (E) – presupune o planificare a activităţilor şi resurselor necesare, cu specificarea caracteristicilor şi a arhitecturii care va trebui proiectată, având la final „reperul arhitectura în ciclul de viaţă” (LCA – life cycle arhitecture milesotne).

•

Construcţia (C) – presupune realizarea produsului conform viziunii si arhitecturii evaluate la trecerea de reperele primelor două etape, în forma unui produs gata de a fi livrat beneficiarului. Această fază este marcată de reperul capabilităţii operaţionale iniţiale (IOC – Initial Operational capability milestone).

•

Tranzitia (T) – înseamnă transferul produsului la utilizator în anumite condiţii (instalare, instruire, întreţinere) până la opţinerea satisfacţiei acestuia. Faza se termină prin „reperul de produs”, care reprezintă confirmarea unei versiuni viabile a produsului software acceptat de utilizator.

Parcurgerea celor patru faze constituie ciclul de realizare a produsului software, care este începutul unei generaţii de produse, datorită faptului că un produs finit se va dezvolta în cadrul unei evoluţii impusă de îmbunătăţiri sugerate de utilizator, de schimbări în mediul de utilizare, schimbări/perfecţionări ale tehnologiilor, sau ca reacţie la realizarile similare ale competiţiei. În

această situaţie , specifică produselor software, primul ciclu, de început, în realizarea lui, se numeşte ciclul iniţial de realizare , iar modificările ulterioare, ca imbunătăţiri, se realizează în cadrul unor cicluri de evoluţie, prin parcurgerea aceloraşi faze în cadrul ciclului, însă cu accente/priorităţi pe anumite faze. Pentru ciclurile iniţiale, timpul alocat diferitelor faze este de obicei 10% pentru I, 30% pentru E, 50% pentru C şi 10% pentru T. Important în fiecare fază este obiectivul urmărit şi reperul care confirmă terminarea ei. Dacă se are în vedere ponderea diferitelor tipuri de activităţi pe parcursul desfăşurării fazelor, se constată o serie de elemente particulare fiecărei faze: In faza I, ponderea o au activităţile legate de înţelegerea cerinţelor şi definirea

•

scopului efortului de realizare a produsului In faza E, ponderea o au cerinţele şi prototipurile pentru arhitectura produsului, cu

•

finalitate intr-un prototip de arhitectură. In faza C, ponderea o au proiectarea si elaborarea software-ului, conform cerinţelor

•

şi arhitecturii, cu finalitate într-un prototip operaţional pentru produs. In faza T, ponderea o au testarea şi evaluarea respectării cerinţelor, instruirea,

•

corectarea unor anomalii, completări cu elemente care lipsesc, pentru a se obţine produsul final, care se predă utilizatorilor. Fiecare fază a ciclului se poate prezenta cu mai multe detalii, însă se consideră interesantă, pentru a trezi un interes mai larg, prezentarea fazei T care este foarte importantă pentru utilizator (de fapt, comunitatea utilizatorilor dintr-o organizaţie/firmă). In faza T, după ce produsul a fost preluat de utilizatorul final şi se dă în exploatare, apar o serie de probleme legate de elaborarea unei sesiuni noi, de corectare a unor anomalii sau de finalizare a unor cerinţe care au fost amânate pentru această fază. Faza T presupune realizarea unor activităţi specifice: •

Testarea versiunii beta, pentru a valida asteptările utilizatorului la cerinţele exprimate

•

Operarea în paralel cu sistemul existent, care va fi înlocuit treptat cu noul produs

•

Conversia fişierelor si a bazelor de date

•

Instruirea comunităţii utilizatorilor şi a persoanelor care vor face întreţinerea noului produs

•

Predarea responsabilităţii produsului către echipele de marketing, distribuţie şi vânzări din cadrul organizaţiei care a realizat produsul.

În multe situaţii, acest final în faza T poate fi un inceput pentru un nou ciclu, în care se va realiza o nouă versiune a produsului, sau cu o predare a artifactelor unei alte organizatii care îşi asumă responsabilitatea pentru operare , întreţinere (în sistem outsourcing). Priorităţile, ca obiective, în faza T sunt următoarele:

•

Asigurarea că utilizatorul poate prelua produsul

•

Asigurarea celor interesaţi că produsul este cel dorit, corespunzând criteriilor de evaluare convenite

•

Asigurarea că produsul final este util, practic şi eficient în raport cu costul de elaborare

Activităţile în faza T pot fi simple sau foarte complexe, în funcţie de tipul produsului final. Pentru aplicaţii realizate pe staţii de lucru, cu versiuni noi de software, activitîţile sunt extrem de simple, în timp ce un sistem integrat, într-o organizaţie cu profil complex, cu o distribuţie geogafică mare a unităţilor organizaţionale, presupune activităţi complexe şi de durată. Reperul specific finalizării fazei T este reprezentat de o versiune a produsului, acceptată de utilizator, prin care se decide dacă obiectivele/cerinţele au fost îndeplinite şi dacă se începe un nou ciclu de realizare a produsului, caz în care această fază reprezintă faza I a noii versiuni a produsului. Evaluarea fazei T se rezumă la răspunsurile pentru două întrebări: •

Este utilizatorul satisfăcut?

•

Sunt acceptabile diferenţele între resursele planificate şi consumate în realizarea produsului?

În finalul prezentării tehnologiei RUP, se pot remarca o serie de avantaje faţă de alte tehnologii tradiţionale: •

Asigură succesul în abordarea aplicaţiilor şi sistemelor complexe

•

Prin procesul iterativ se asigură realizarea mai eficientă a produselor, într-un timp mai scurt şi cu riscuri mai mici

•

Asigură un control financiar al proiectului prin faze şi repere

•

Permite introducerea unor modificări în cerinţele si etapele finale, fără pierderi mari, prevenind riscul unui eşec în realizarea produsului.

Tehnologiile prezentate în acest capitol sunt reluate prin ilustrări de produse şi instrumente de mare performanţă în capitolele următoare.

************************* Termeni si notiuni de baza •

Mediu de programare

•

Limbaj de modelare unificat (UML)

•

Obiectele si incapsularea

•

Mesaje si polimorfism

•

Clase si mosteniri

•

Agentul software

•

Sistem multi-agent (SMA)

•

Criteriide clasificare pentru agenti

•

Cooperarea agentilor in SMA

•

Arhitecturi bazate pe agenti

•

Tehnologia RUP

•

Arhitectura RUP

•

Elemente de modelare RUP : executanti, activitati, artifacte, fluxuri de lucru

•

Abordari in realizarea produselor sofware : secventiala, iterativa

******************************** Intrebari si teme recapitulative 1.Cum definiti tehnologia orientata obiect ? 2.Definiti urmatoarele notiuni : - obiect si incapsulare ; - mesaje si polimorfism ; - clasa si mostenire. 3.Cum definiti tehnologia orientata agent ? 4.Enumerati cele mai importante proprietati ale unui agent (sofware) ! 5.Care sunt criteriile de clasificare pentru agenti ? 6.Prezentati relatiile de cooperare ale agentilor de tip broker si matchmaker in cadrul SMA! 7.Care sunt principalele elemente ale infrastructurii SMA ? 8.Descrieti principalele caracteristici ale tehnologiei RUP : -prezentare generala ; -structura statica ; -structura dinamica. 9.Analizati abordarea secventiala si abordarea iterativa in ciclul de viata al unui

produs software!

**************************** Tema de casa - Dupa exemplul AGV, ca obiect intr-o aplicatie de simulare, definiti si alte obiecte in cadrul proceselor de fabricatie discreta. - Analizati tendintele si solutiile in managementul intreprinderilor virtuale care folosesc tehnologia SMA.

*************************