Academia Română Secţia Ştiinţa şi Tehnologia Informaţiei Institutul de Cercetări pentru Inteligenţă Artificială

Referat II.

Arhitectură pentru sistem suport pentru decizii bazat pe comunicaţii.

Doctorand: ing. Mihai BÎZOI Coordonator ştiinţific: Acad. dr. ing. Florin-Gheorghe FILIP

2/38

Cuprins I. Introducere .................................................................................................................... 3

II. Arhitecturi pentru sisteme informatice ........................................................................... 4

A. Ciclul de viaţă al unui produs informatic ................................................................. 4

1. Faza de pre-proiectare ......................................................................................... 5

2. Faza analizei domeniului ..................................................................................... 6

3. Faza de proiectare schematică .............................................................................. 6

4. Faza de dezvoltare a proiectării ............................................................................ 7

5. Faza de construire ................................................................................................ 7

B. Procesul de proiectare al unei arhitecturi ................................................................. 8

1. Înţelegerea problemei .......................................................................................... 8

2. Identificarea elementelor de proiectare şi relaţiile dintre ele ................................. 8

3. Evaluarea arhitecturii ......................................................................................... 11

4. Transformarea arhitecturii ................................................................................. 11

C. Proiectarea software .............................................................................................. 13

1. Probleme în proiectarea arhitecturilor software .................................................. 13

2. Sarcini şi activităţi de proiectare ........................................................................ 14

III. Stabilirea cerinţelor de proiectare ............................................................................. 16

A. Luarea deciziilor în grup ....................................................................................... 16

1. Potenţiale avantaje şi dezavantaje ale lucrului în grup ........................................ 17

B. Tehnici pentru susţinerea lucrului în grup .............................................................. 18

1. Brainstorming-ul ............................................................................................... 18

2. Tehnica nominală de grup .................................................................................. 19

3. Metoda Delphi ................................................................................................... 20

C. Caracteristicile sistemelor de asistare a deciziilor multiparticipant ......................... 21

IV. Proiectarea modelului SSD experimental .................................................................. 24

A. Limbajul UML ...................................................................................................... 24

B. Descrierea modelului experimental ....................................................................... 26

V. Concluzii ..................................................................................................................... 32

VI. Referinţe bibliografice .............................................................................................. 34

3/38

I. Introducere

Lucrarea de faţă, Arhitectură pentru sistem suport pentru decizii bazat pe comunicaţii

încearcă să prezinte un model experimental de arhitectură al unui sistem suport pentru decizii

multiparticipant. Aceasta este organizată în trei mari capitole: Arhitecturi pentru sisteme

informatice, Stabilirea cerinţelor de proiectare şi Proiectarea modelului SSD experimental.

Capitolul Arhitecturi pentru sisteme informatice prezintă ciclul de viaţă al unui produs

informatic din perspectiva arhitecturală, luându-se în considerare cele patru faze: pre-

proiectarea, analiza de domeniu, proiectarea schematică şi realizarea propriu-zisă a

proiectului.

Procesul de proiectare al unei arhitecturi este descris la modul general pe baza

următorilor paşi: înţelegerea problemei, identificarea elementelor de proiectare şi a relaţiilor

dintre ele, evaluarea arhitecturii, transformarea arhitecturii.

De asemenea, sunt prezentate eventualele probleme care pot apărea în faza de

proiectare software, precum şi sarcinile şi activităţile de proiectare.

În capitolul Stabilirea cerinţelor de proiectare sunt prezentate caracteristicile generale

pentru luarea deciziilor în grup, precum şi potenţialele avantaje şi dezavantaje ale lucrului în

grup.

În cadrul aceluiaşi capitol sunt evidenţiate trei tehnici pentru susţinerea lucrului în

grup: brainstorming-ul, tehnica grupului nominal şi metoda Delphi. Totodată sunt prezentate

şi caracteristicile sistemelor de asistare a deciziilor multiparticipant.

Ultimul capitol, Proiectarea modelului SSD experimental descrie la modul general

limbajul de modelare UML şi prezintă un exemplu, arhitectura unui sistem suport pentru

decizii experimental. Modelul arhitecturii sistemului a fost realizat folosind diagrame de

clase. Subsistemele modelului au fost reprezentate sub formă de pachete software.

4/38

II. Arhitecturi pentru sisteme informatice

A. Ciclul de viaţă al unui produs informatic

Perspectiva arhitecturală furnizează puncte de vedere diferite dar complementare

asupra managementului software-ului şi proiectării inginereşti. Rolul tradiţional al

arhitectului este să ajute beneficiarul să înţeleagă nevoile sale în întregime şi cu exactitate şi

să creeze un concept arhitectural care va fi un sistem fezabil de construit pe baza tehnologiei,

resurselor şi a timpului disponibile. De asemenea, arhitectul va supraveghea construcţia.

Perspectiva arhitecturală a ciclului de dezvoltare software este centrată pe proiectarea

aplicaţiei sau sistemului şi pe modul în care proiectul conduce la realizarea acesteia. Aceasta

poartă numele de arhitectură bazată pe construirea software (Sewell, 2002).

Cele patru faze ale procesului de realizare al arhitecturii sunt:

• Faza de pre-proiectare;

• Analiza domeniului;

• Proiectarea schematică;

• Faza de dezvoltare a proiectului.

Aceste faze sunt executate secvenţial, dar ca şi ingineria software şi în cazul fazelor

de inginerie ale proiectului nu este absolut necesar ca acestea să aibă loc într-un singur pas

secvenţial. Cele patru faze de mai sus când sunt combinate cu următoarele faze formează o

metodă de arhitectură bazată pe construcţia software:

• Faza documentelor proiectului;

• Faza de contractare sau angajare de personal;

• Faza de construcţie;

• Faza post-construcţie.

În figura II.A.1. sunt prezentate fazele realizării unei arhitecturi software din

perspectiva arhitecturală a ciclului de viaţă al unui produs informatic.

5/38

Figura II.A.1. Fazele realizării unei arhitecturi.

1. Faza de pre-proiectare

Tradiţional, arhitectul este implicat în mod imparţial în proiect. În dezvoltarea

software, arhitectul software poate face parte atât din echipa de planificare a producţiei cât şi

din cea de inginerie. Arhitectul poate avea experienţă relevantă în domeniu şi poate contribui

la viziunea asupra produsului. Acesta este cazul cel mai des întâlnit în dezvoltarea software

comercială şi în dezvoltarea individuală (acasă). În dezvoltările contractate, arhitectul poate

face parte din organizaţia contractorului şi nu din organizaţia contractantului şi în consecinţă

nu este implicat în procesul de producţie.

Fără deosebire, arhitectul software trebuie să participe în planificarea producţiei şi în

analiza şi formularea de cerinţe la fel ca la crearea bugetului extins şi planificarea

obiectivelor prin stabilirea scopului şi a mărimii proiectului. Arhitectul trebuie să fie atent la

contractant şi să studieze întregul context al întreprinderii din care aplicaţia va face parte.

Arhitectul trebuie să permită contractantului să facă aprecieri în ce priveşte valoarea cum ar fi

detaliile de construcţie care nu sunt importante în aplicaţie.

Arhitectul software trebuie să studieze întreprinderea în care aplicaţia sau sistemul va

face parte. Arhitectura unei aplicaţii de afaceri trebuie să ia în considerare informaţiile de

arhitectură ale organizaţiei, nu numai informaţiile model ale aplicaţiei în sine, din moment ce

deseori aplicaţia de întreprindere se adresează unui număr limitat de aspecte ale întregii

Pre-proiectare

Analiza domeniu

Proiectare schematică

Documentele proiectului

Construirea

6/38

organizaţii. În plus, arhitectura aplicaţiei ar trebui să ia în considerare structura arhitecturii

informatice existente. Dacă un server de aplicaţii, server web, server de baze de date, sistem

de operare sau produse hardware sunt alese înainte de a începe proiectarea arhitecturii, atunci

acestea trebuie să fie considerate parte a arhitecturii IT.

Platforma tehnologică existentă sau stiva tehnologică devine parte a contextului în

care cerinţele sunt formulate şi nu parte a soluţiei. Un comerciant de software pentru

întreprindere trebuie de asemenea să ia în considerare alte tipuri de arhitecturi deoarece ele

devin parte a cerinţelor cumpărătorului. Deseori un client a investit în tehnologie cum ar fi

aplicaţiile server şi serverele de baze de date. Dacă un comerciant software nu utilizează o

platformă tehnologică compatibilă, riscă să fie în imposibilitatea de a vinde produsul sau

software-ul.

2. Faza analizei domeniului

Pe parcursul analizei domeniului, arhitectul software se străduieşte să înţeleagă cât

mai complet şi cât mai exact posibil nevoile contractorului şi ale utilizatorilor, domeniul

aplicaţiei şi se va documenta pe baza acestor cunoştinţe. Surse de cunoştinţe în domeniu

includ experţii domeniului, literatura de specialitatea a domeniului şi existenţa cerinţelor de

proiectare de la sisteme anterior realizate sau sisteme similare. Această fază corespunde

îndeaproape cu cerinţele de analiză şi specificaţii ale activităţilor de ingineriei software.

Marea masă de analiză de domeniu va continua pe parcursul fazei de elaborare şi va continua

şi în timpul fazei de construcţie.

Analiza domeniului este una din cele mai importante activităţi pentru realizarea

arhitecturii software. De altfel, ea este şi cea mai ignorată activitate în dezvoltarea software,

în special la proiectarea aplicaţiilor comerciale de întreprindere. Modelele de analiză de

domeniu foarte bine făcute pot contribui semnificativ la succesul dezvoltării aplicaţiilor

software. Inginerii software au tendinţa de a se concentra pe domeniul ştiinţei calculatoarelor.

Este datoria arhitectului software să se asigure că inginerii înţeleg modelele domeniului

aplicaţiei, deoarece aceste modele reprezintă semantica problemei. Rezolvarea unei false

probleme poate cauza ca întregul proiect să fie abandonat, pierzându-se astfel timp şi bani.

3. Faza de proiectare schematică

În timpul proiectării schematice, arhitectul software pregăteşte proiectul la nivel

arhitectural, acesta fiind specificat în descrierea arhitecturală. Acest proiect este reprezentat

prin modele de nivel înalt care reprezintă comportamentul sistemului, informaţia capturată şi

7/38

procesată de sistem, interfaţa utilizator şi proiectul de interacţiune între utilizatori, structura

modulară a soluţiei şi tehnologia necesară pentru implementarea aplicaţiei sau sistemul care

cuprinde raţionamentul pentru proiecte diferite sau tehnologii de luare a deciziilor.

Această fază implică multă comunicare între arhitect şi diferiţi manageri, revizori şi

evaluări ale variaţilor de proiectare reprezentate în descrierea arhitecturală. Această fază pune

accent pe proiectarea conceptuală.

4. Faza de dezvoltare a proiectării

Faza de dezvoltare a proiectului se concentrează pe rafinarea descrierii arhitecturale şi

selectarea unei alternative de proiectare. Descrierea arhitecturală a evoluat până la punctul în

care pot fi create grafice precise. Proiectarea schematică şi faza de dezvoltare a proiectării

sunt deseori iterate şi limita dintre ele tinde să se estompeze când arhitectura converge la un

proiect final care este detaliat suficient pentru a evalua riscurile şi se ia decizia de a se

proceda la realizare. Această fază reprezintă alcătuirea proiectului arhitectural.

5. Faza de construire

În faza de documentare a proiectului, arhitectul se concentrează pe dezvoltarea

preocupării, de exemplu cum ar trebui să fie construit sistemul şi în ce ordine ar trebui

dezvoltate componentele. O descriere despre cum poate fi construit sistemul poate fi

pregătită. Aceasta va include un plan de construire, un ghid pentru stilul interfeţei utilizator şi

un ghid de test.

Pe perioada angajării personalului şi faza contractării, arhitectul poate ajuta

contractorul să identifice un contractant pentru dezvoltare sau să îl ajute la crearea unei

echipe de dezvoltare folosind resurse interne. În construirea clădirilor, arhitectul de clădiri va

asista la stabilirea detaliilor contractelor şi evaluarea costurilor. Această fază s-ar putea să nu

aibă loc în majoritatea eforturilor de dezvoltare software, în special dacă contractorul este şi

constructor sau dacă constructorul este un comerciant software.

Din perspectiva arhitecturii, arhitectul va supraveghea construirea şi se va asigura că

ceea ce s-a construit este valid şi respectă descrierea arhitecturală. Arhitectul este implicat în

revizuirea proiectului şi în analiza problemelor proiectului neacoperite care necesită

realizarea de modificări. Chiar şi dacă marea parte a proiectului arhitectural este completă,

este încă nevoie ca arhitectul să facă schimbări proiectului şi să evalueze impactul acestor

schimbări asupra arhitecturii în sine şi asupra costurilor şi eforturilor de dezvoltare.

8/38

B. Procesul de proiectare al unei arhitecturi

1. Înţelegerea problemei

Multe proiecte software şi produse sunt considerate eşecuri datorită faptului că nu

rezolvă o problemă de afaceri validă sau nu au o returnare a investiţiei cuantificabilă. De ce

să se cheltuiască bani pentru construirea unui sistem care automatizează un proces dacă

costul total al investiţiei este mai mare decât atunci când nu s-ar fi construit sistemul de loc?

Inginerii software care nu au stabilit clar direcţia problemei de rezolvat pot sfârşi prin a-şi

concentra eforturile în rezolvarea unei probleme tehnice care nu corespunde cu problema

originală. Această situaţie se poate numi capcană de implementare (Albin, 2003).

Pentru a evita capcana de implementare, va trebui ca cei care proiectează sistemul să

se întrebe ce problemă rezolvă proiectul. Dacă răspunsul este o problemă tehnică sau una de

implementare, ar trebui să îşi pună această problemă în continuare, repetat până când va fi

condus la problema originală. Dacă nu se ajunge la problema originală sau proiectul original

de decizie asupra problemei este nesatisfăcător, atunci acesta este un bun indicator că acest

plan de proiectare particular a condus la o capcană de implementare.

2. Identificarea elementelor de proiectare şi relaţiile dintre ele

Arhitectura unei aplicaţii software este adesea reprezentată printr-un set de module

sau subsisteme interconectate numite componente. Aceste module sunt construite din punct

de vedere organizaţional ca structuri de cod sursă, dar deseori nu sunt direct vizibile în codul

sursă. Codul sursă reprezintă o abstracţie a instrucţiunilor maşină şi a tiparelor de date

structurate în termenii unei gramatici a limbajului de programare. Două programe scrise în

limbaje de programare diferite dar compilate pentru aceeaşi platformă hardware vor folosi

aceleaşi instrucţiuni maşină (Albin, 2003).

Limbajele de programare Java şi C furnizează concepte foarte diferite. C furnizează

tipul de date structură, tip de date slab definit de utilizator, iar Java furnizează un tip de clase

puternic definit pentru a fi un mecanism de definire a structurilor utilizator. Oricum, este

posibil ca la un program în Java şi un program în C, când sunt compilate, să rezulte acelaşi

cod maşină şi aceleaşi tipare de date. Java este compilat în byte code şi interpretat de maşina

virtuală Java, care la rândul său este compilată pentru o platformă hardware specifică. Din

punct de vedere teoretic, este posibil să se scrie un program în C care este identic cu

programul Java împreună cu maşina virtuală.

9/38

În termenii ierarhiei componentelor, atât programul Java cât şi programul C poate fi

văzut ca o structură care este compusă la rândul său din componente de nivel inferior.

Limbajele de programare definesc un set de componente în termenii expresiilor şi cuvintelor

cheie. Expresiile Java şi C, cum ar fi declararea unui întreg şi atribuirea unei valori acestuia,

poate fi văzută ca o componentă care este formată din componente de nivel inferior care

reprezintă cod maşină şi tipare de date. Este similar cu ideea în care un circuit integrat de

calculator poate fi compus din mai multe componente numite porţi logice, care la rândul lor

sunt compuse din componente de nivel inferior numite circuite. Astfel, un circuit integrat de

calculator şi un program software reprezintă ierarhii de componente (figura II.B.2.).

Figura II.B.2. Software-ul ca o ierarhie de componente (Albin, 2003)

Identificarea elementelor de proiectare şi a relaţiilor dintre acestea poate fi făcută pe

baza următorilor paşi:

1. Definirea contextului sistemului;

2. Identificarea modulelor;

Module Reguli de proiectare

Arhitectură

Expresii limbaje de programare

Structuri de date

Cod sursă

Instrucţiuni maşină

Tipare de date binare

Cod binar

10/38

3. Descrierea componentelor şi a conectorilor.

Primii doi paşi utilizează tehnica de proiectare prin abstracţie. Abstracţia este o

tehnică de proiectare care permite concentrarea la un anumit nivel de detaliere fără a focaliza

toate aspectele sau detaliile sistemului. Un model abstract reprezintă numai esenţialul care

este necesar pentru argumentarea despre sistem la un nivel particular de abstracţie. Următorul

pas implică aplicarea unor operaţii de proiectare care împarte sistemul în tipur i de module.

Ultimul pas implică crearea descrierilor instanţelor tipurilor de module în configuraţii

de execuţie tipice. Diferenţa între identificarea tipurilor de module şi instanţele diferitelor

sisteme de configurare depind cât de bine este configurat sistemul şi cât diferă interfaţa de

execuţie a sistemului de interfaţa modulului static. Într-un sistem simplu unde este o relaţie

de tip unu-la-unu între tipurile de module şi instanţe, nu este necesar să efectuăm ambii paşi.

Într-o linie de produse sau o familie de arhitecturi, diferenţa dintre aceşti paşi este

importantă deoarece pot exista numeroase posibile măsuri fizice ale unui sistem care constată

o suficientă diferenţă să justifice o evaluare şi o descriere independentă.

Contextul sistemului ajută la descrierea aplicaţiei dintr-o perspectivă externă, aceea a

utilizatorilor şi operatorilor aplicaţiei sau sistemului. Contextul sistemului este folositor în

descrierea scopului sistemului şi în identificarea interfeţelor externe ale sistemului. Intrarea

pentru definirea contextului sistemului o reprezintă lista iniţială de cerinţe.

Comportamentul extern al sistemului este descris de interfaţa sistemului. Fiecare

interfaţă reprezintă un subset coerent de funcţii sistem. Entităţile externe pot fi la nivel înalt,

scăzut sau la acelaşi nivel cu sistemul în sine. Elementele de nivel înalt compun sistemul

descris cu alte elemente pentru a forma un sistem mai mare. Entităţile – componente ale

contextului (Bosch, 2000) de nivel scăzut sunt utilizate de sistemul descris (sunt componente

care compun sistemul). Entităţile de acelaşi nivel sunt componente de sine stătătoare care nu

sunt dependente faţă de sistem, dar pot interacţiona cu sistemul descris în contextul unui

element de nivel înalt.

Modulele sunt unităţi software discrete (binare şi surse). Modulele binare devin

instanţe la momentul execuţiei şi aceste instanţe sunt numite comun componente sau

conectori. Un modul precizat poate conţine specificaţiile pentru o serie de tipuri de

componente şi conectori. Componentul (instanţa) poate fi un număr fix în anumite situaţii. De

exemplu, un server web executabil, când este lansat, rezultă într-o singură componentă

instanţă a serverului web. Modulul serverului de web este codul binar care există ca un set de

fişiere program. Componentul server web este instanţa serverului web care se execută.

11/38

Folosirea termenilor modul, component şi conector generează uneori confuzie. Un

modul este o unitate discretă de proiectare care este compusă dintr-un set de elemente

ascunse şi un set de elemente partajate. Modulele au o coeziune internă mare şi posibilitatea

de conectare externă slabă. Modulele pot reprezenta un pachet fizic al codului binar al

aplicaţiei, care poate fi descris mai departe de tipurile component sau tipurile conector.

Componentele şi conectorii descriu instanţa fizică a sistemului. Termenul component

este deseori utilizat cu sensul de tip component sau modul. Un modul se referă la o unitate

software care poate fi proiectată, implementată şi compilată într-o formă de livrare

executabilă, fiind o unitate de execuţie. Un component este o entitate de la momentul

execuţiei, definiţia a ce există în modul (Albin, 2003).

O arhitectură clasică modulară o reprezintă arhitectura client-server. Clientul şi

serverul sunt două module. Serverul exportă anumite elemente cum ar fi un set public de

tabele ale bazei de date relaţionale. Clientul cunoaşte despre schema vizibilă public. Clientul

şi serverul nu cunosc compoziţia internă a celuilalt.

3. Evaluarea arhitecturii

Un proiect de arhitectură poate fi evaluat în mai multe moduri. Oricum, cu cât este

mai puţin formal modelul de proiectare al arhitecturii, în aceeaşi mică măsură sunt şi

rezultatele specifice. Pentru a putea evalua un proiect de arhitectură trebuie să se cunoască

articulată clar calitatea atributelor cerinţelor care sunt afectate de arhitectură. Nu este

suficient să se spună că sistemul trebuie să fie rapid sau să fie uşor de modificat şi adaptat în

funcţie de cerinţele clientului. Aceste expresii pot fi acceptate într-o listă iniţială de cerinţe,

dar nu sunt suficient de specifice pentru a evalua proiectul (Albin, 2003).

Astfel de cerinţe trebuie întâi articulate cu atribute specifice de calitate şi valorile lor

acceptate. Majoritatea atributelor de calitate nu sunt cantitative în natură, deci nu pot avea

valori numerice. Un atribut de calitate performant va fi uzual stabilit ca o scară numerică sau

ca un set ideal de numere.

4. Transformarea arhitecturii

Acest pas este realizat după evaluarea unei arhitecturi sau aprecierea informală a

proiectului de arhitectură. Dacă proiectul de arhitectură nu satisface complet cerinţele

atributelor de calitate, atunci trebuie schimbat până când le va satisface. Oricum, în loc să se

pornească de la zero, se poate prelua proiectul existent şi aplica operatori de proiectare pentru

12/38

a fi modificat. Noua versiune de proiect este evaluată şi procesul continuă până satisfacţia de

proiectare este atinsă.

Câteodată este necesară revenirea la operaţiile anterioare care au fost deja aplicate

pentru a alege o altă cale de proiectare. De asemenea, se pot crea mai multe proiecte candidat

în acelaşi timp. Începând cu un proiect iniţial rădăcină (probabil un singur modul monolitic),

se poate crea direct un proiect grafic. Fiecare nod reprezintă o cale de decizie a proiectului.

Anumite căi se pot contopi, caz în care operaţiile proiectului de aplicaţie sunt comutative. În

acest caz, se pot transforma anumite părţi ale proiectului şi se pot elimina unele care evident

nu se vor transforma pe baza cerinţelor.

Un proiect este transformat prin aplicarea operatorilor de proiectare, stiluri sau tipare.

Sunt două tipuri de operatori de proiectare: aceia care afectează arhitectura modulară şi cei

care afectează componentele arhitecturii. După Baldwin (2000), sunt şase operatori modulari:

• Descompunerea unui proiect în mai multe module;

• Substituirea unui proiect al unui modul cu altul;

• Dezvoltarea sistemului prin adăugare de noi module;

• Excluderea unui modul din sistem;

• Inversarea unui modul pentru a crea o nouă interfaţă;

• Portarea unui modul pe un alt sistem.

În mod similar cu operatorii modulari sunt şi operatorii de proiectare, care au fost

identificaţi de Bass (1998):

• Descompunerea unui sistem în componente;

• Replicarea componentelor pentru a îmbunătăţi fiabilitatea;

• Compresia a două sau mai multe componente într-o singură componentă

pentru a îmbunătăţi performanţa;

• Abstracţia unei componente pentru a îmbunătăţi adaptabilitatea şi posibilitatea

de a efectua modificări;

• Partajarea resurselor sau partajarea unei singure instanţe componente cu alte

componente pentru a îmbunătăţi integrabilitatea (abilitatea de a integra

aplicaţii şi sisteme), portabilitatea şi posibilitatea de a efectua modificări.

13/38

C. Proiectarea software

1. Probleme în proiectarea arhitecturilor software

Experienţa ne arată că pe măsură ce cresc mărimea şi complexitatea unei aplicaţii,

precum şi echipa de dezvoltare, cu atât este nevoie de mai mult control asupra proiectului

aplicaţiei. O abordare ad-hoc a proiectării şi implementării aplicaţiei nu păstrează ordinul de

mărime al aplicaţiei în termenii funcţiilor îndeplinite şi al altor atribute de calitate. Aceasta se

manifestă adesea în ceea ce se numeşte criză software. Este necesar un control mai bun al

procesului de proiectare în vederea îmbunătăţirii calităţii produsului şi pentru a face o

predicţie cât mai precisă a cantităţii de efort cerută pentru dezvoltarea sistemului.

Obstacolele care previn obţinerea de proiecte arhitecturale de înaltă calitate în

dezvoltarea software sunt:

• Lipsa conştientizării importanţei proiectului arhitectural în dezvoltarea

software;

• Lipsa înţelegerii rolului de arhitect software;

• O viziune larg răspândită care sugerează că proiectarea este o formă de artă şi

nu o activitate tehnică;

• Lipsa înţelegerii procesului de proiectare;

• Lipsa experienţei în proiectare într-o organizaţie de dezvoltare;

• Insuficiente metode şi instrumente pentru proiectarea arhitecturii software;

• Lipsa înţelegerii modului în care se evaluează proiectul;

• Slaba comunicare dintre reprezentanţi.

Multe dintre aceste obstacole rezultă din ignoranţa cu privire la ce este proiectarea

arhitecturii software şi de ce reprezintă un punct critic pentru proiectul unei aplicaţii sau a

altui sistem de dezvoltare. Această ignoranţă rezultă în inabilitatea de a comunica efectiv

cărui tip probleme se adresează cu adevărat aplicaţia şi cum soluţia tehnică rezolvă aceste

probleme.

Soluţia la problema unui proiect inadecvat trebuie să cunoască obstacolele pentru a

obţine un proiect adecvat. Soluţia implică următoarele:

• Creşterea importanţei arhitecturii software;

• Îmbunătăţirea arhitecturii software în educaţie;

14/38

• Folosirea metodelor şi a instrumentelor pentru crearea arhitecturii.

Sunt mulţi autori care acordă o importanţă deosebită arhitecturilor software; anumiţi

autori chiar consideră arhitectura software ca o profesie separată de ingineria software

(Sewell, 2002). De aceea, este necesară o mai bună educaţie în câmpul arhitecturii software.

Alţi autori consideră că este o disciplină independentă separată de ingineria software şi

necesită forme de învăţământ separate. Esenţa soluţiei o reprezintă nevoia pentru metode şi

instrumente pentru realizarea arhitecturii. Prin instrumente înţelegându-se metode, tehnici,

principii, experimente şi cataloage cu elemente de proiectare reutilizabile.

Soluţia la obstacolele de comunicare nu este de a crea mai multe canale de

comunicare, ci îmbunătăţirea calităţii informaţiilor care sunt comunicate. Întâlnirile

săptămânale de revizie a proiectelor pot îmbunătăţi transferul informaţiilor, dar nu pot

îmbunătăţi transferul de cunoştinţe. Informaţia este şi va fi interpretată diferit, de aceea,

informaţiile comunicate ar trebui să fie mai uşor de înţeles şi să se bazeze mai puţin pe o

interpretare personală. Este foarte importantă standardizarea terminologiei arhitecturale, a

procesului de proiectare şi descrierea limbajului pentru comunicarea efectivă între

reprezentaţii proiectului.

Inima proiectului o reprezintă noţiunile de probleme, obstacole şi soluţii. O soluţie la

o problemă de proiectare software în shell (interpretor) este planificată cu grijă, iar procesul

de proiectare şi artefactele proiectării sunt executate sistematic. Fundamental, pentru a

înţelege proiectul, trebuie să înţelegem care sunt diferenţele dintre actul de proiectare şi alte

activităţi.

2. Sarcini şi activităţi de proiectare

Orice activitate poate fi văzută din mai multe puncte de vedere:

• Psihologice;

• Sistematice;

• Organizaţionale.

Din perspectiva psihologică, proiectul este un proces creativ care necesită cunoştinţe

în cadrul unor discipline apropiate cum ar fi ingineria software, ştiinţa calculatoarelor, logică,

15/38

ştiinţe cognitive, lingvistică, limbaje de programare şi metodologii de proiectare software

precum şi a cunoştinţelor din domeniul de aplicabilitate.

Din perspectivă sistematică, proiectul este văzut ca o activitate de arhitectură sau

inginerie care implică găsirea soluţiilor optimizate la un set de obiective sau probleme cât

timp se echilibrează competiţia obstacolelor şi a forţelor.

Perspectiva organizaţională consideră esenţiale elementele aplicaţiei sau sistemul

ciclu de viaţă. Dezvoltarea aplicaţiei începe cu o piaţă necesară pentru ideea noului produs.

Proiectarea aplicaţiei începe cu planificarea şi se termină când produsul a ajuns la sfârşitul

ciclului de viaţă (în software aceasta însemnând că produsul nu mai este întreţinut sau

folosit). Există posibilitatea ca anumite reciclări ale elementelor software să fie reutilizate în

alte produse.

16/38

III. Stabilirea cerinţelor de proiectare

A. Luarea deciziilor în grup

Luarea deciziilor în grup sau luarea deciziilor în organizaţie poate fi descrisă ca un

proces de luarea a deciziilor unde sunt implicaţi mai mulţi decidenţi. Luarea deciziei în grup

diferă de activitatea decizională care implică un singur decident din moment ce negocierea

deciziei trebuie să aibă loc între decidenţi, exceptând cazul în care ei au exact aceeaşi opinie

în ce priveşte decizia care trebuie luată.

Simon (1957) considera că influenţa unui context organizaţional este foarte

importantă în acest caz. Organizaţia reprezintă un tipar complex de comunicare şi alte relaţii

într-un grup de oameni. Acest tipar furnizează fiecărui membru al grupului multe informaţii,

presupuneri, scopuri, atitudini care influenţează decizia sa şi îi furnizează cu un set stabil şi

inteligibil de aşteptări referitor la ce fac alţi membri ai grupului şi cum vor reacţiona ei la ce

spune şi ce face.

Conform lui Beach (1997), este fundamental pentru înţelegerea luării deciziei în grup

sau la nivel organizaţional, mai întâi să înţelegem cum un mediu organizaţional formează

construcţia unor interpretări sociale partajate ale evenimentelor. Acesta considera că în

organizaţie există o gândire comună partajată de mai mulţi membri ai organizaţiei care le

permite acestora să lucreze împreună şi să comunice despre evenimentele apărute şi scopurile

comune. De fapt, această înţelegere partajată dezvoltă organizaţiile. Fără ea, nu ar mai o

organizaţie în nici un sens real.

Această înţelegere partajată în cadrul grupului sau organizaţiei nu este niciodată

perfectă. Nu este nimeni care să cunoască totul despre o situaţie sau o problemă şi membri

diferiţi ai organizaţiei sau grupului cunosc diferite lucruri despre probleme sau situaţii. Din

această cauză, toţi indivizii din organizaţie întâmpină problemele/situaţiile în mod diferit şi

de altfel au cadre de referinţă diferite în ce priveşte problema care îngrijorează organizaţia

sau grupul.

În afară de acest factor complicat, când deciziile sunt luate de grupuri în loc de

decidenţi individuali, coaliţiile între participanţi, precum şi politicile şi diferenţele formale

sau reale de putere dintre decidenţi fac ca luarea deciziei în grup să fie mult mai greu de

analizat. De altfel, când există probleme complexe în organizaţii mari, decidenţii sunt deseori

reprezentanţii unor grupuri de interese care pot complica procesul luării deciziei şi mai mult.

17/38

1. Potenţiale avantaje şi dezavantaje ale lucrului în grup

Turban & Aronson (1998), se referă la grupuri ca fiind doi sau mai mulţi (uzual până

la 25) oameni a căror misiune este să execute anumite sarcini şi să se comporte ca o singură

unitate. Aceştia au adunat potenţialele avantaje şi dezavantaje, conform tabelului III.A.1.

Potenţiale avantaje Potenţiale dezavantaje

1. Grupurile înţeleg problemele mai bine

decât indivizii;

2. Oamenii sunt luaţi în considerare pentru

deciziile la care participă;

3. Grupurile sunt mai bune faţă de indivizi

la găsirea erorilor;

4. Un grup deţine mai multe informaţii

(cunoştinţe) decât orice membru al

grupului şi poate combina aceste

cunoştinţe pentru a crea unele noi. Astfel,

rezultă mai multe alternative, care conduc

la o soluţie mai bună.

5. S-ar putea produce efecte de sinergie în

timpul rezolvării problemei;

6. Lucrul în grup ar putea stimula

participanţii în cadrul grupului şi al

procesului decizional;

7. Membrii grupului îşi vor încapsula ego-ul

în decizie, devenind astfel devotaţi

soluţiei;

8. Riscul este balansat în condiţiile în care

grupul are tendinţa de a modera pe cei

care îşi asumă riscuri mari şi de a-i

încuraja pe cei conservativi.

1. Gândirea de grup în care indivizi din

acelaşi grup au tendinţa să gândească la

fel şi să suprime noile idei;

2. Luarea deciziei în grup este în general un

proces încet, care consumă timp şi în care

numai un decident individual la un

moment dat poate vorbi;

3. Este mult mai dificil să coordonăm

munca desfăşurată de un grup decât

munca desfăşurată de un individ;

4. Influenţe nepotrivite cu privire, de

exemplu, la dominaţia timpului, opinia

sau subiectul unuia sau a mai multor

decidenţi din cadrul grupului;

5. Tendinţa membrilor grupului de a avea

încredere în alţii cu privire la distribuţia

muncii în legătură cu decizia;

6. Tendinţa îndreptată către o soluţie de

compromis rezultă o calitate slabă;

7. Existenţa riscului pentru incompleta

analiză a sarcinilor, timp neproductiv,

care poate consta în aşteptarea

participanţilor să sosească, socializare;

8. Costuri mari în luarea deciziei.

9. Tendinţa grupului de a lua decizii mai

riscante decât ar trebui.

Tabelul III.A.1. Potenţialele avantaje şi dezavantaje ale lucrului în grup

18/38

B. Tehnici pentru susţinerea lucrului în grup

Există în principal trei tehnici proiectate să susţină lucrul în grup (Delbecq şi alţii,

1975); acestea fiind câteodată folosite în conexiune cu utilizarea sistemelor suport pentru

decizii de grup (Gray, 1994). Cele trei tehnici sunt: brainstorming-ul, tehnica grupului

nominal şi metoda Delphi.

1. Brainstorming-ul Termenul brainstorming a apărut prima dată într-o carte scrisă de Osborn (1957).

Aceasta a provocat lungi discuţii despre acest termen şi despre valoarea metodei aplicată într-

un grup de luare a deciziei.

Brainstorming-ul este o încercare de a intensifica creativitatea decidenţilor prin

încurajarea schimbului de idei şi a discuţiei creative libere între indivizii implicaţi.

Brainstorming-ul ca tehnică, poate fi folosită şi individual, dar este mult mai eficientă când

este folosită în grup.

Pentru a elimina riscul de a neglija ideile bune, Osborn (1957) a enunţat patru reguli

pentru brainstorming care, în opinia sa, sunt importante de luat în considerare în vederea

evitării evaluării premature a ideilor:

1. Generarea a cât mai multe idei posibile. Cu cât sunt mai multe idei, cu atât

mai bine. Datorită numărului mare de idei, şansele de apariţie a ideilor bune

vor creşte.

2. Nu se va critica modul de exprimare al ideilor. Este important să nu se critice

noile idei pe parcursul stagiului de generare şi exprimare al ideilor de către

decidenţi. Nerespectându-se această regulă, participanţii se vor simţi

descurajaţi pentru a veni cu idei noi.

3. Se vor încuraja ideile diferite. Deşi pare ciudat, diferenţele de opinie vor fi

încurajate. Astfel, pot fi descoperite idei noi unice, care anterior nu păreau

importante.

4. Construirea pe ideea altora. Prin construirea pe sugestiile altora şi folosirea

lor ca sursă de inspiraţie, noi idei pot fi produse. Utilizarea unor idei vechi ca

sursă de inspiraţie ar trebui să fie încurajată în proces.

Deşi sunt multe opinii referitoare la eficacitatea grupului de brainstorming comparativ

cu brainstorming-ul individual, este interesant de notat că mulţi din cei care au participat la

19/38

brainstorming-ul de grup au considerat că performanţele au fost mai ridicate decât în cazul

brainstorming-ului individual (Camacho şi alţii, 1993).

Este foarte simplu să descoperim opinii critice despre brainstorming. Studii care au

comparat brainstorming-ul individual cu cel de grup au arătat că indivizii din cadrul grupului

generează de regulă cu aproape 50% mai puţine idei decât în cazul brainstorming-ului

individual, iar aceste idei puţine sunt de o calitate ridicată (Diehl and Stroebe 1994).

După Camacho & Paulus (1995), brainstorming-ul nu este eficient în condiţiile în care

anumiţi participanţi s-ar simţi incomodaţi în cadrul grupului, iar această situaţie ar produce

rezultate negative. O altă explicaţie ar fi aceea că în cadrul grupurilor s-ar produce mai puţine

idei datorită unei situaţii numită blocaj de producţie. Aceasta se referă la situaţia când

mărimea grupului creşte, iar participanţii trebuie să aştepte mult timp până când îşi pot

prezenta ideile.

2. Tehnica nominală de grup

După Turban şi Aronson (1998), tehnica nominală de grup constă dintr-o secvenţă de

activităţi în procesul de luare a deciziei, cum ar fi: generarea silenţioasă a ideilor prin scrierea

lor, listarea succesivă a ideilor, discuţii referitoare la ideile prezentate, listarea silenţioasă şi

votarea priorităţilor, o discuţie referitoare la aceste priorităţi şi în final o reclasificare şi

revotare a priorităţilor.

Prin folosirea tehnicii nominale de grup, decidenţii furnizează un forum în cadrul

căruia pot dezvolta şi scrie idei faţă în faţă, dar dezvoltarea ideii devine individuală şi

independentă (în ce priveşte vizualizarea şi influenţarea) faţă de membrii altui grup. Delbecq

şi alţii (1986) consideră că tehnica nominală de grup evită multe din problemele asociate cu

brainstorming-ul şi conform lor, tehnica nominală de grup este mai eficientă decât

brainstorming-ul.

Posibili paşi pentru aplicarea tehnicii nominale de grup:

1. Se împart participanţii prezenţi în mici grupuri de 5-6 persoane, care vor fi

aşezaţi, de preferat, în jurul unei mese;

2. Se va stabili o întrebare care va deschide-închide sesiunea;

3. Fiecare persoană se va gândi în linişte câteva minute şi îşi va nota idee;

4. În cadrul fiecărui grup se vor prezenta ideile succesiv (o idee la un anumit

moment de timp) şi vor fi notate pe un flipchart. Nu se permite criticarea

ideilor, dar se încurajează clarificări cu privire la răspunsul la întrebare;

20/38

5. Fiecare persoană va evalua ideile şi în mod individual şi anonim va vota

pentru cea mai bună;

6. Se va discuta situaţia votului în cadrul grupului şi va fi realizat un raport care

evidenţia ideea care a primit cele mai multe voturi;

7. În final, fiecare grup va prezenta pe scurt soluţia găsită.

Marele avantaj al tehnicii nominale de grup este acela că evită două probleme cauzate

de interacţiunea în grup: anumiţi participanţi nu îşi împărtăşesc ideea de teamă să nu fie

criticaţi, iar alţi participanţi se tem de generarea unor conflicte în cadrul grupului şi doresc

astfel să păstreze un climat calm. Această tehnică elimină problemele prezentate prin

minimizarea diferenţelor şi asigurarea unei egalităţi relative în ce priveşte participarea.

Un alt avantaj îl reprezintă numărul mare de idei produse, precum şi ideea concluzie

care încheie procesul decizional; această idee nefiind prezentă la alte metode de grup mai

puţin structurate. De asemenea, în multe cazuri, timpul de desfăşurare al procesului

decizional poate constitui un avantaj.

Dezavantajul major al metodei îl constituie lipsa de flexibilitate: aceasta se ocupă cu o

singură problemă la un moment dat. Participanţii trebuie să simtă confortabil în cadrul

grupului şi să fie de acord cu modul de structurare.

Această metodă nu implică spontaneitatea. Timpul câştigat în cadrul procesului

decizional poate fi anulat de timpul necesar pentru pregătirea activităţilor. Moderatorul /

facilitatorul trebuie să planifice foarte atent desfăşurarea activităţilor.

Un alt dezavantaj îl constituie faptul că în cadrul procesului de votare, e posibil ca

ideile să nu conveargă, încercarea de structurare să ducă la apariţia constrângerilor, iar întreg

procesul să pară mecanic.

3. Metoda Delphi

Clayton (1997) considera că metoda Delphi este similară în multe privinţe cu tehnica

nominală de grup, dar are caracteristici care nu se găsesc în această tehnica sau în

brainstorming. Prima caracteristică se referă la generarea idei, care în această metodă se face

nu numai individual şi independent, dar şi izolat şi în mod anonim de către fiecare decident

implicat.

O caracteristică secundară reprezintă comunicaţia dintre indivizi care în această

abordare este supravegheată de un moderator şi se desfăşoară prin utilizarea chestionarelor

scrise şi al rapoartelor de feedback.

21/38

Un avantaj important este oferit de metoda Delphi comparativ cu tehnica grupului

nominal prin furnizarea unui canal de comunicare unde indivizii pot participa fără a se întâlni

fizic. Astfel, se reduc costurile în timp şi bani în ce priveşte nevoia de a călători, deseori la

distanţă. Întâlnirile faţă în faţă sunt de multe ori necesare la un grup de lucru pentru luarea

deciziilor, iar acestea au avantajul alegerii unei alte metode de lucru (tehnica nominală de

grup, brainstorming etc.).

Decidenţii participă anonimi în procesele Delphi. Aceasta este o cerinţă esenţială a

metodei. Anonimitatea are un avantaj important în aceea că reduce anumite comportamente

social-emoţionale deseori întâlnite când se folosesc alte metode şi care pot distorsiona

procesul de luare a deciziei şi conduce la obţinerea unor rezultate inferioare.

Filip (2005) descrie etapele procesului astfel:

1. Datele iniţiale, formularele şi metodologia de completare sunt transmise de

către moderator participanţilor sub forma unui pachet cât mai concis;

2. Se verifică de către moderator la un interval scurt de timp, dacă participanţii

au înţeles sarcina. Tot la această etapă se vor elucida şi eventualele neclarităţi;

3. În mod independent, participanţii vor completa formularele şi le vor transmite

moderatorului în cel mai scurt timp;

4. Moderatorul va realiza o mediere a părerilor exprimate şi va indica abaterile

de la medie. Dacă se vor constata abateri intenţionate cu scopul alterării

rezultatului global, acestea vor fi filtrate.

5. Participanţii primesc reacţia moderatorului cu scopul de a-şi reconsidera

opinia în funcţie de informaţia suplimentară primită. Participantul care refuză

revizuirea punctului său de vedere, va transmite moderatorului argumentele

care susţin această atitudine.

Ultimii trei paşi se vor repeta până când se ajunge la un consens sau, după un număr

limitat de iteraţii, moderatorul va stabili o medie a părerilor exprimate. În cazul în care

persistă diferenţe mari, se va apela la o altă metodă.

C. Caracteristicile sistemelor de asistare a deciziilor multiparticipant

După Filip (2005), decizia este rezultatul unor activităţi conştiente, specifice omului,

care constau în acumularea crearea şi prelucrarea de cunoştinţe în cadrul procesului de

rezolvare a unei probleme de alegere dintre mai multe alternative identificate sau proiectate

anume, în vederea efectuării de acţiuni care implică alocarea unor resurse, în scopul realizării

22/38

unor obiective. O serie de autori au remarcat, de multă vreme, necesitatea considerării

deciziilor de grup (denumite si "de tip multiparticipant").

Astfel, P. Keen citat de Filip (2005) arăta că, este necesară o revizuire a „modelului

fundamental al decidentului singuratic, care străbate cu paşi mari, culoarele organizaţiei,

seara târziu, în încercarea de a lua o decizie”. Keen arăta că „ cele mai multe dintre deciziile

sunt luate după consultări intense”. Pe aceeaşi linie, cunoscutul economist J. K. Galbraith

citat de Filip (2005), descria luarea deciziilor de către decidenţi de tip multiparticipant astfel:

„Organizaţia modernă, sau acea parte a ei care necesită conducere şi ghidare, constă dintr-un

număr de indivizi care sunt angajaţi, în fiecare moment, în acţiunile de dobândire, sintetizare,

schimb şi testare de informaţii. Procedura cea mai răspândită este lucrul în comitete şi în

şedinţele acestor comitete. O decizie în întreprinderea modernă este produsul grupurilor nu al

indivizilor.”.

Avantajele implicării mai multor participanţi în elaborarea şi adoptarea deciziilor sunt

numeroase si diverse:

1. bagajul de cunoştinţe al grupului este în mod evident mai bogat decât al oricărui

participant component al grupului, care, la rândul său, are posibilitatea şi este

stimulat să dobândească mai multe elemente de cunoaştere de la ceilalţi participanţi;

2. grupul are performanţe superioare în ceea ce priveşte calitatea soluţiei şi poate detecta

mai uşor eventualele erori;

3. membrii grupului se simt coautori ai soluţiei adoptate şi, în consecinţă, o vor sprijini

şi, dacă e cazul, se vor angaja în transpunerea acesteia în execuţie.

Limitele şi dezavantajele implicării mai multor participanţi în elaborarea şi adoptarea

unei decizii sunt (Filip 2005):

1. performanţa grupului poate să fie afectată negativ de o planificare necorespunzătoare

şi de nerespectarea agendei de lucru;

2. unii membri ai grupului tind să se alinieze la părerea altora, din cauză că, fie îşi pierd

interesul, fie că se tem să exprime păreri discordante, sau care ar putea „încinge

spiritele” (aceasta poate conduce la o gândire de grup, într-o adunare dominată de o

personalitate sau de o coaliţie prea puternică);

3. monopolizarea discuţiilor de un număr restrâns de persoane poate cauza blocaje;

4. se pot manifesta tendinţe de adoptare comodă (sau, cu orice preţ, prin consens) a unor

soluţii de compromis, care, uneori, nu sunt şi de calitate;

23/38

5. supraîncărcarea informaţională a participanţilor poate conduce la pierderea atenţiei

sau la ignorarea aspectelor esenţiale;

6. sunt posibile pierderi de informaţie cauzate de receptarea greşită a intervenţiilor orale,

omisiuni şi distorsiuni de consemnare în documentele întâlnirii ( procese verbale,

minute);

7. se produce un consum exagerat de resurse ( timpul pierdut în dezbateri sterile , în

divagaţii, sau în activităţi sociale conexe, costurile ridicate pentru organizarea şi

desfăşurarea unor întâlniri „faţă în faţă”).

24/38

IV. Proiectarea modelului SSD experimental

A. Limbajul UML

Limbajul de modelare vizuală UML1

1. Meta-meta model - este limbajul pentru definirea metamodelelor;

(Unified Modeling Language) reprezintă un set

de notaţii grafice care ajută la descrierea şi proiectarea sistemelor informatice, în particular al

celor dezvoltate folosind tehnica programării orientate pe obiecte. UML ajuta la specificarea,

vizualizarea şi documentarea modelelor sistemelor informatice. De asemenea, limbajul UML

poate fi folosit la descrierea altor sisteme care nu sunt informatice (de exemplu se poate

modela un proces de afaceri, fără a avea ca scop obligatoriu crearea unui sistem informatic).

Folosind limbajul UML se poate modela orice tip de aplicaţie, destinată oricărei

combinaţii de hardware, sistem de operare, limbaj de programare. Flexibilitatea acestui

limbaj de modelare se poate utiliza pentru aplicaţii client-server, în timp real, tranzacţionale,

distribuite etc. UML este perfect compatibil cu limbajele de programare orientate obiect, dar

poate fi utilizat la fel de bine şi pentru aplicaţii dezvoltate cu limbaje procedurale.

Pentru reprezentarea oricărui tip de sistem, UML utilizează modelele, acestea fiind

abstractizări care permit explicarea si înţelegerea problemelor pe care le presupune

dezvoltarea unui sistem nou. Arhitectura UML, ca şi cea a altor limbaje de modelare, bazate

pe paradigma orientării pe obiecte este o arhitectură pe patru niveluri, după cum urmează:

2. Metamodel - este definit ca limbajul pentru definirea modelelor UML;

3. Model - este o instanţă a unui metamodel, utilizabil pentru formalizarea unui

domeniu informaţional;

4. Obiecte utilizator - sunt instanţe de modele, fiind practic domeniile

informaţionale descrise cu ajutorul modelelor.

Principalele părţi ale UML sunt:

1. Vederile (View) – surprind aspecte particulare ale sistemului de modelat. Un view este

o abstractizare a sistemului, iar pentru construirea lui se folosesc un număr de

diagrame.

2. Diagramele – sunt grafuri care descriu conţinutul unui view. UML are doisprezece

tipuri de diagrame, care pot fi combinate pentru a forma toate view-urile sistemului.

3. Elementele de modelare – sunt conceptele folosite în diagrame care au corespondenţă

în programarea orientată-obiect, cum ar fi: clase, obiecte, mesaje şi relaţii între

1 http://www.uml.org/

25/38

acestea: asocierea, dependenţa, generalizarea. Un element de modelare poate fi folosit

în mai multe diagrame diferite şi va avea acelaşi înţeles şi acelaşi mod de

reprezentare.

4. Mecanismele generale – permit introducerea de comentarii şi alte informaţii despre un

anumit element.

Limbajul UML, include 12 tipuri de diagrame, împărţite în 3 categorii, care definesc:

1. Partea statică a aplicaţiei ( structural diagrams )

a. Class Diagram

b. Object Diagram

c. Component Diagram

d. Deployement Diagram

2. Partea dinamica a aplicaţiei ( behavior diagrams )

a. Use Case Diagram

b. Sequence Diagram

c. Activity Diagram

d. Collaboration Diagram

e. Statechart Diagram

3. Modul de organizare al componentelor aplicaţiei ( model management diagrams )

a. Packages

b. Subsystems

c. Models

Utilizând unul din multele produse de modelare vizuala (bazate pe UML) de pe piaţa

de profil, dezvoltatorii de aplicaţii pot analiza cerinţele care trebuie sa le îndeplinească

viitoarele sisteme informatice şi să proiecteze o soluţie care le va îndeplini.

26/38

B. Descrierea modelului experimental

În figura IV.B.1. este descrisă arhitectura generală a modelului experimental ales.

Acesta este compus dintr-un model al unui sistem de asistare al deciziilor, o interfaţă web, o

bază de date şi un sistem de fişiere pentru stocarea documentelor.

Figura IV.B.1. Arhitectura generală a modelului experimental

În continuare se va descrie numai modelul sistemului suport pentru decizii; în figura

IV.B.2. fiind prezentată arhitectura modelului experimental organizată pe pachete software.

Figura IV.B.2. Arhitectura modelului experimental pe pachete

Pachetele software prezentate în arhitectura modelului experimental pot fi grupate

astfel: pachete care susţin activitatea decizională de bază (Generarea de idei, Organizarea de

idei, Prioritizarea, Elaborarea) şi pachete care susţin activitatea suport a activităţii decizionale

(Configurare, Stare, Comunicare, Resurse, Export).

27/38

Figura IV.B.3. Pachetul pentru generarea ideilor

Figura IV.B.3. prezintă pachetul folosit pentru generarea ideilor, prima fază din

cadrul procesului decizional. Acest pachet cuprinde trei clase (Brainstorming, Comentarea,

Conturarea) care vor fi utilizate la alegere în funcţie de configuraţia sistemului.

Prima clasă este folosită pentru generarea unei liste de idei folosind metoda

brainstorming. Astfel, clasa Brainstorming va descrie o instanţă care va fi folosită pentru a

adăuga idei într-o listă de idei. De asemenea, instanţa returnează lista ideilor.

Clasa Comentarea creează o instanţă cu ajutorul căreia fiecare participant are acces la

o listă de subiecte în vederea introducerii comentariilor proprii. Instanţa va returna o listă de

subiecte, va selecta un subiect anume pentru a putea adăuga un comentariu şi bineînţeles, va

permite adăugarea unui subiect nou.

Clasa Conturarea permite crearea unei instanţe care serveşte prezentarea subiectelor

sub formă arborescentă. Structura arborescentă este realizată prin folosirea subiectelor

structurate pe baza unor niveluri. La fiecare subiect pot fi adăugate comentariile în mod

ordonat.

Ideile generate de pachetul anterior vor fi prelucrate de clasele din pachetul

Organizare, prezentat în figura IV.B.4. Acesta conţine două clase care vor crea instanţe în

funcţie de configuraţia sistemului.

Clasa Grupare este folosită pentru a crea o instanţă care va permite crearea de grupuri

de idei. Acestea vor fi stabilite de moderatorul sistemului. În momentul în care lista

grupurilor de idei a fost creată, se pot grupa ideile generate la faza decizională anterioară.

28/38

Figura IV.B.4. Pachetul pentru organizarea ideilor

Participanţii pot să identifice apariţiile celor mai importante idei şi să finiseze

comentariile, cu ajutorul clasei Analiza.

În figura IV.B.5. sunt prezentate clasele pachetului Prioritizare (Votare, Chestionar,

Dictionar). Acestea sunt folosite pentru a obţine gradul de importanţă al fiecărei idei apărute.

Figura IV.B.5. Pachetul pentru priorizarea ideilor

Clasa Votare creează o instanţă care permite votarea ideilor. Instanţa permite de

asemenea stabilirea modului în care se realizează votarea (prin da/nu, note etc.). Clasa

Chestionar permite moderatorului realizarea chestionarelor on-line pentru sintetizarea

răspunsurilor introduse on-line de participanţi. Instanţa clasei Dictionar permite crearea

interactivă a definiţiilor pentru elementele utilizate în procesul decizional.

29/38

Figura IV.B.6. Pachetul pentru formularea politicilor

Clasele care compun pachetul software pentru formularea politicilor sunt prezentate în

figura IV.B.6. Cele două clase vor fi folosite alternativ în funcţie de configuraţia sistemului.

Instanţa clasei Formulare permite crearea documentelor referitoare la politici sau misiuni,

prin elaborarea acestora în comun de către participanţi. Clasa Analizap creează o instanţă prin

care se evaluează în mod sistematic politicile.

Înainte de începerea fazelor decizionale, aplicaţia necesită anumiţi parametrii de

configurare. Acest pas se realizează prin intermediul instanţelor claselor descrise în pachetul

Configurare (Moderator, Participant, Generare), din figura IV.B.7.

Figura IV.B.7. Pachetul pentru configurarea sistemului

Instanţele claselor Moderator şi Participant determină tipul de utilizator care

utilizează sistemul. Clasa Generare creează o instanţă care va stabili parametrii generali de

sistem (metoda aleasă de generare a ideii, numărul de participaţi, timpul pentru anumite faze

decizionale).

30/38

Pachetul din figura IV.B.8. (Stare) conţine trei clase al căror rol este acela de a

determina starea sistemului la un anumit moment.

Figura IV.B.8. Pachetul pentru starea sistemului

Instanţa clasei Evenimente monitorizează stadiul procesului decizional pe etape şi paşi

de execuţie. Lista participanţilor este administrată de instanţa clasei Participanţi. Deoarece la

un moment dat, în sistem pot fi în desfăşurare mai multe procese decizionale, instanţa clasei

Sesiune este folosită pentru stabilirea şi determinarea sesiunii curente a procesului decizional.

Figura IV.B.9. Pachetul de comunicare

Sistemul (dar şi moderatorul) poate comunica cu participanţii prin trimiterea de

mesaje de poştă electronică. În cadrul pachetului Comunicare (figura IV.B.9.) există o

singură clasă. Rolul instanţei acestei clase este de a facilita transmiterea de e-mailuri.

31/38

Figura IV.B.10. Pachetul pentru gestionarea resurselor

Unul din cele mai importante pachete pentru susţinerea activităţilor suport este

pachetul Resurse (figura IV.B.10). Acesta conţine două clase, care gestionează cele două

tipuri de resurse permise de sistem: fişierele de documente şi legăturile web. Clasa Comune

gestionează resursele comune (partajate) ale participanţilor, iar clasa Individuale gestionează

resursele individuale (nepartajate) ale participanţilor.

De remarcat, este faptul ca instanţa clasei Individuale conţine şi un jurnal, care

permite participanţilor luarea de notiţe cu privire la procesul decizional în desfăşurare.

Ultimul pachet din seria pachetelor care susţin activităţile suport conţine o singură

clasă. Aceasta este prezentată în figura IV.B.11. Rolul instanţei acestei clase este de a permite

participanţilor exportarea în formate diferite a documentului cu politici care a rezultat în urma

procesului decizional.

Figura IV.B.11. Pachetul pentru exportul documentelor

32/38

V. Concluzii

Perspectiva arhitecturală a ciclului de viaţă al unui sistem informatic furnizează

puncte de vedere diferite dar complementare asupra managementului software-ului şi

proiectării inginereşti. Rolul arhitectului este să ajute beneficiarul să înţeleagă nevoile sale în

întregime şi cu exactitate şi să creeze un concept arhitectural care va fi un sistem fezabil de

construit pe baza tehnologiei, resurselor şi a timpului disponibile.

Multe proiecte software şi produse sunt considerate eşecuri datorită faptului că nu

rezolvă o problemă validă sau nu au o returnare a investiţiei cuantificabilă. Inginerii software

care nu au stabilit clar direcţia problemei de rezolvat pot sfârşi prin a-şi concentra eforturile

în rezolvarea unei probleme tehnice care nu corespunde cu problema originală.

Arhitectura unei aplicaţii software este adesea reprezentată printr-un set de module

sau subsisteme interconectate numite componente. Aceste module sunt construite din punct

de vedere organizaţional ca structuri de cod sursă, dar deseori nu sunt direct vizibile în codul

sursă.

Contextul sistemului este folositor în descrierea scopului sistemului şi în identificarea

interfeţelor externe ale sistemului. Intrarea pentru definirea contextului sistemului o

reprezintă lista iniţială de cerinţe.

Modulele sunt unităţi software discrete (binare şi surse). Modulele binare devin

instanţe la momentul execuţiei şi aceste instanţe sunt numite comun componente sau

conectori. Un modul precizat poate conţine specificaţiile pentru o serie de tipuri de

componente şi conectori.

Componentele şi conectorii descriu instanţa fizică a sistemului. Termenul component

este deseori utilizat cu sensul de tip component sau modul. Un modul se referă la o unitate

software care poate fi proiectată, implementată şi compilată într-o formă de livrare

executabilă, fiind o unitate de execuţie.

Pentru a putea evalua un proiect de arhitectură trebuie să se cunoască articulată clar

calitatea atributelor cerinţelor care sunt afectate de arhitectură.

Dacă proiectul de arhitectură nu satisface complet cerinţele atributelor de calitate,

atunci trebuie schimbat până când le va satisface. Oricum, în loc să se pornească de la zero,

se poate prelua proiectul existent şi aplica operatori de proiectare pentru a fi modificat. Noua

versiune de proiect este evaluată şi procesul continuă până satisfacţia de proiectare este

atinsă.

33/38

O abordare ad-hoc a proiectării şi implementării aplicaţiei nu păstrează ordinul de

mărime al aplicaţiei în termenii funcţiilor îndeplinite şi al altor atribute de calitate. Aceasta se

manifestă adesea în ceea ce se numeşte criză software.

Soluţia la obstacolele de comunicare nu este de a crea mai multe canale de

comunicare, ci îmbunătăţirea calităţii informaţiilor care sunt comunicate. Este foarte

importantă standardizarea terminologiei arhitecturale, a procesului de proiectare şi descrierea

limbajului pentru comunicarea efectivă între reprezentanţii proiectului.

Luarea deciziei în grup diferă de activitatea decizională care implică un singur

decident din moment ce negocierea deciziei trebuie să aibă loc între decidenţi, exceptând

cazul în care ei au exact aceeaşi opinie în ce priveşte decizia care trebuie luată.

Este fundamental pentru înţelegerea luării deciziei în grup sau la nivel organizaţional,

mai întâi să înţelegem cum un mediu organizaţional formează construcţia unor interpretări

sociale partajate ale evenimentelor.

Există în principal trei tehnici proiectate să susţină lucrul în grup (Delbecq şi alţii,

1975); acestea fiind câteodată folosite în conexiune cu utilizarea sistemelor suport pentru

decizii de grup (Gray, 1994). Cele trei tehnici sunt: brainstorming-ul, tehnica grupului

nominal şi metoda Delphi.

Brainstorming-ul este o încercare de a intensifica creativitatea decidenţilor prin

încurajarea schimbului de idei şi a discuţiei creative libere între indivizii implicaţi.

Brainstorming-ul ca tehnică, poate fi folosită şi individual, dar este mult mai eficientă când

este folosită în grup.

Prin folosirea tehnicii nominale de grup, decidenţii furnizează un forum în cadrul

căruia pot dezvolta şi scrie idei faţă în faţă, dar dezvoltarea ideii devine individuală şi

independentă (în ce priveşte vizualizarea şi influenţarea) faţă de membrii altui grup.

Un avantaj important este oferit de metoda Delphi comparativ cu tehnica grupului

nominal prin furnizarea unui canal de comunicare unde indivizii pot participa fără a se întâlni

fizic.

Limbajul de modelare vizuală UML (Unified Modeling Language) reprezintă un set

de notaţii grafice care ajută la descrierea şi proiectarea sistemelor informatice, în particular al

celor dezvoltate folosind tehnica programării orientate pe obiecte. UML ajuta la specificarea,

vizualizarea şi documentarea modelelor sistemelor informatice.

Utilizând unul din multele produse de modelare vizuala (bazate pe UML) de pe piaţa

de profil, dezvoltatorii de aplicaţii pot analiza cerinţele care trebuie sa le îndeplinească

viitoarele sisteme informatice şi să proiecteze o soluţie care le va îndeplini.

34/38

VI. Referinţe bibliografice ***, A framework for distributed group multi-criteria decision support Systems,

http://ausweb.scu.edu.au/aw03/papers/li_______/paper.html

***, Banxia Software - Decision Support and Audience Response Tools,

http://www.banxia.com/

***, Decision support system, http://en.wikipedia.org/wiki/Decision_support_systems

***, Decision Support Systems Glossary,

http://dssresources.com/glossary/dssglossary1999.html

***, Elminanet, http://www.elmminanet.ro/despre_uml.html

***, Facilitate: Groupware, Web Collaboration Software, Decision Support System, Online

Meetings, Virtual meetings, Online Survey Software, http://www.facilitate.com/

***, Grouputer Solutions - Web Conferencing, Group Decision Support System, interactive

e-collaboration and real-time conferencing, http://www.grouputer.com/

***, IBM Rational Software, http://www-01.ibm.com/software/rational/

***, Meetingworks -Electronic meeting and collaboration, http://www.meetingworks.com/

***, Object Management Group – UML, http://www.uml.org/

***, SmartDraw - The World's Most Popular Business Graphics Software,

http://www.smartdraw.com/

***, Zing Technologies, http://www.anyzing.com/

Airinei, D., Sisteme de asistare a deciziilor si DD, http://portal.feaa.uaic.ro/C10/

Sisteme%20de%20asistare%20a%20deciziil/default.aspx, 2006;

ALBIN, S., T., The Art of Software Architecture: Design Methods and Techniques, John

Wiley & Sons, 2003;

35/38

Baldwin, C.,Clark, K. 2000. Design Rules: Volume 1. The Power of Modularity. Cambridge,

MA: The MIT Press;

Beach, L.R., 1997, The Psychology of Decision Making, People in Organizations, Sage

Publications Inc., California;

Bhargava, H., K., Power, D., J., Decision Support Systems and Web Technologies: A Status

Report, http://dssresources.com/papers/dsstrackoverview.pdf

Bosch, J. 2000. Design and Use of Software Architectures: Adopting and Evolving a Product-

Line Approach. Harlow, England: Addison-Wesley;

Camacho, L.M., Paulus, P.B., Dzindolet. M.T. & Poletes, G., 1993, Perception of

performance in group brainstorming: The illusion of group productivity, Personality and

Social Psychology Bulletin, No. 19, pp. 78-89;

Cvetkovic, D., These - Evolutionary Multi–Objective Decision Support Systems for

Conceptual Design, School of Computing, Faculty of Technology, University of Plymouth,

July 2000;

Delbecq, A.L., Van de Ven, A.H. & Gustafson, D.H., 1975, Group Techniques for Program

Planning, Foresman and Company, Glenview;

Druzdzel, M., J., Flynn, R., R., Decision Support Systems, Encyclopedia of Library and

Information Science, Second Edition, Ed. Allen Kent, New York, 2002;

FILIP, F., G., Decizie Asistata de Calculator: Decizii, decidenti - metode si instrumente de

baza, Ed. Tehnica, Bucuresti, 2002;

FILIP, F., G., Informatica industriala: Noi paradigme si aplicatii, Ed. Tehnica, Bucuresti,

1999;

FILIP, F., G., Sisteme suport pentru decizii, Ed. Tehnica, Bucuresti, 2004;

Fredman, J., Horndahl, M., Strömberg, L., T., Organizational Decision Support Systems - A

Theoretical and Practical Study, Focusing on Group Decision Support, Knowledge

Management and Means of Communication in Organizational Decision Support Systems,

Department of Informatics, Göteborg School of Economics, GÖTEBORG UNIVERSITY;

36/38

Gadomski, A., M., Bologna, S., DiCostanzo, G., Perini, Anna, Schaerf, M., An Approach to

the Intelligent Decision Advisor (IDA) for Emergency Managers, TIEMS'99, The Sixth

Annual Conference of The International Emergency Management Society, Delft,

Netherlands, June 8-11, 1999;

Gilliams, S., Van Orshoven, J., Muys, B., Kros, H., Heil, G., Van Deursen, W., AFFOREST

sDSS: a metamodel based spatial decision support system for afforestation of agricultural

land, New Forests, Vol. 30, No. 1. (July 2005), pp. 33-53;

Gonzalez, Cleotilde, Kasper, G., M., Animation in user interfaces designed for decision

support systems: The effects of image abstraction, transition, and interactivity on decision

quality, http://www.findarticles.com/p/articles/mi_qa3713/is_199710/ai_n8768245

Gray, P. ed., 1994, Decision Support and Executive Information Systems, Englewood Cliffs,

Prentice-Hall, New Jersey;

Gregg, G., D., Goul, M., A Proposal for an Open DSS Protocol, Communications of the

ACM, November 1999, Vol. 42, No. 11;

Gronlund, A., DSS in a Local Government Context – How to Support Decisions Nobody

Wants to Make?, Electronic Government: 4th International Conference, EGOV 2005,

Copenhagen, Denmark, August 22-26, 2005, Proceedings p. 69;

Hättenschwiler, P., Decision Support Systems, University of Fribourg, Department of

Informatics, DS Group, http://diuf.unifr.ch/ds/courses/dss2002/;

Jaramillo, P., Smith, R., A., Andreu, J., Multi-Decision-Makers Equalizer: A Multiobjective

Decision Support System for Multiple Decision-Makers, Annals of Operations Research,

Volume 138, Number 1, September 2005, pp. 97 - 111;

Kacprzyk, J., Zadrozny, S., Towards a Synergistic Combination of Web-Based and Data-

Driven Decision Support Systems via Linguistic Data Summaries, AWIC 2005, pp. 211–217;

Kim, W., Chung, M., J., A Web Service Support to Collaborative Process with Semantic

Information, Web Information Systems Engineering – WISE 2005: 6th International

Conference on Web Information Systems Engineering, New York, NY, USA, November 20-

22, 2005. Proceedings pp. 217 - 230;

37/38

Koshiba, H., Kato, N., Kunifuji, S., Awareness in Group Decision: Communication Channel

and GDSS, Knowledge-Based Intelligent Information and Engineering Systems: 9th

International Conference, KES 2005, Melbourne, Australia, September 14-16, 2005,

Proceedings, Part IV, p. 444;

Lai, K., K., Yu, L., Wang, S., Multi-agent Web Text Mining on the Grid for Enterprise

Decision Support, Advanced Web and Network Technologies, and Applications: APWeb

2006 International Workshops: XRA, IWSN, MEGA, and ICSE, Harbin, China, January 16-

18, 2006. Proceedings, pp. 540 - 544;

Lepreux, S., These - Approche de developpement centre decideur et a l'aide de patron de

Systemes Interactifs d'Aide a la Decision, Laboratoire d'Automatique, de Mecanique et

d'Informatique industrielles et Humaines, Universite de Valenciennes et du Hainaut-

Cambresis, jun. 2005;

Luo, J., Shi, Z., Wang, M.,Hu, J., AGrIP: An Agent Grid Intelligent Platform for Distributed

System Integration, Advanced Web and Network Technologies, and Applications: APWeb

2006 International Workshops: XRA, IWSN, MEGA, and ICSE, Harbin, China, January 16-

18, 2006. Proceedings pp. 590 - 594;

Lusk, E., J., Belhadjali, M., Halperin, M., Matzner, D., DSS utilization: A comparative study

for major firms in Germany and the USA: An examination of the Implementation Paradox,

Problems and Perspectives in Management, 2/2005, pp. 40-44;

Malczewski, J., Rinner, C., Exploring multicriteria decision strategies in GIS with linguistic

quantifiers: A case study of residential quality evaluation, Journal of geographical systems,

2005, vol. 7, no2, pp. 249-268;

Muntean, M., Teză de doctorat - Perfecţionarea sistemelor suport de decizie în domeniul

economic, Academia de Studii Economice, Facultatea de Cibernetică Statistică şi Informatică

Economică, 2003;

Osborn, A.F., 1957, Applied imagination, Scribner, New York;

Ou, L., Peng, H., XML and Knowledge Based Process Model Reuse and Management in

Business Intelligence System, Advanced Web and Network Technologies, and Applications:

38/38

APWeb 2006 International Workshops: XRA, IWSN, MEGA, and ICSE, Harbin, China,

January 16-18, 2006. Proceedings, pp. 117 - 121;

Potts, A., W., Decision Support Systems: A Knowledge-Based Approach, University of

Kentucky, http://www.uky.edu/BusinessEconomics/dssakba/instmat/dcnotes.htm;

Power, D., J., A Brief History of Decision Support Systems,

http://dssresources.com/history/dsshistory.html

Sewell, M.,Sewell, L. 2002. The Software Architect's Profession: An Introduction. Upper

Saddle River, NJ: Prentice Hall PTR;

Simon, H., 1957, Administrative behavior: A study of decision-making process in

administrative organization, Free Press, New York;

Sprague, R.,H., A framework for the development of Decision Support Systems

http://web.njit.edu/~bieber/CIS677F98/readings/sprague80.pdf

Starr, L., How to Build Articulate Class Models and get Real Benefits from UML,

http://www.uml.org/HTB_Articulate_Class_Models_OMG.pdf

Turban, E. & Aronson, J.E., 1998, Decision Support Systems and Intelligent Systems,

Prentice-Hall International Inc., London;

Umar, A., IT Infrastructure to Enable Next Generation Enterprises, Information Systems

Frontiers, Volume 7, Number 3, July 2005, pp. 217 - 256;

Zaraté, P., Soubie, J., L., Bui, T., Experiment of a Group Multi-criteria Decision Support

System for Distributed Decision Making processes, Proceedings of the 38th Hawaii

International Conference on System Sciences, 2005;