arhitectură pentru sistem suport pentru deciziibazat pe ... · pdf filearhitectura unei...
TRANSCRIPT
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;