Ingineria software

o Economiile tuturor tarilor dezvoltate sunt dependente de software

o Din ce in ce mai multe sisteme sunt controlate prin software
o Ingineria software se ocupa cu teorii, metode si instrumente pentru
dezvoltarea de software professional
o Cheltuielile cu software reprezinta o fractiune semnificativa din produsul
national brut in toate tarile dezvoltate
Costurile pentru software
o Deseori costurile pentru software domina costurile sistemelor de calcul.
Costul software-lui instalat pe un PC este de obicei mai mare decat costul
hardware-lui
o Este mai scump sa intretii decat sa dezvolti software. Pentru sistemele cu
durata mare de viata costurile de intretinere pot ajunge la de cateva ori
costurile de dezvoltare
o Ingineria software este preocupata de dezvoltarea de software eficienta
din punct de vedere al costurilor
Ce inseamna software?
o Def: Programe pentru calculator si documentatia asociata (ex. cerinte,
modele proiectate, manuale de utilizare)
o Produsele software pot fi dezvoltate atat pentru un anume client cat si
pentru o piata generala, si ele pot fi:
-Generice - dezvoltate pentru a fi vandute unui spectru de clienti diferiti
(ex. Excel or Word)
-Bespoke (orientate client) - dezvoltate pentru un singur client, conform
specificatiilor acestuia
o Metode pentru realizare de software nou:
- Dezvoltare de programe noi
-Configurare de sisteme software generice
-Reutilizare software existent
Ce este ingineria software?
o Def. Ingineria software este o disciplina de tip inginerie care trateaza
toate aspectele productiei de software
o Inginerii software trebuie sa:
-Adopte o abordare sistematica si organizata a muncii lor
-Utilizeze instrumente si tehnici adecvate la: Problema de rezolvat +
Restrictiile de dezvoltare ++ Resursele disponibile
Care este diferenta intre ingineria software si stiinta calculatoarelor?
o Stiinta calculatoarelor se ocupa cu teorie si fundamente
 o Ingineria software se ocupa cu elementele practice ale dezvoltarii si
furnizarii de software util
o Teoriile din stiinta calculatoarelor nu reprezinta o baza completa pentru
ingineria software
Care este deosebirea dintre ingineria software si ingineria sistemelor?
o Ingineria sistemelor se ocupa de toate aspectele dezvoltarii de sisteme
bazate calculator, aceasta incluzand inginerie hardware, software si de
proces. Ingineria software este parte a acestui proces ocupandu-se cu
dezvoltarea infrastructurii software, a controlului, a aplicatiilor si a
bazelor de date din cadrul sistemului
o Inginerii de sistem sunt implicati in specificarea sistemului, in proiectarea
arhitecturala, in integrare si in instalare
Ce este un proces software?
o Def. Un set de activitati ce au ca scop dezvoltarea si evolutia software-lui
o Activitati generice ce apar in toate procesele software:
-Specificare – ce trebuie sa faca sistemul si care sunt constrangerile in
dezvoltarea sa
-Dezvoltare – producerea sistemului software
-Validare - verificarea faptului ca software-ul produs este ceea ce vrea
clientul
-Evolutie - modificarea software-lui ca raspuns la modificarea cerintelor
Ce este un model de proces software?
o Def. O reprezentare simplificata a procesului software vazut dintr-o
anume perspectiva
o Exemple de perspective pentru procesul software:
-Perspectiva fluxului de activitati (Workflow) - secventa de activitati
-Perspectiva fluxului de date (Data-flow) - fluxul informatiilor
-Perspectiva rol/actiune - cine ce face
o Modele generice pentru procesul software:
-Cascada (Waterfall)
- Dezvoltare iterativa
-Inginerie software bazata pe componente
Care sunt costurile ingineriei software?
o In general 60% sunt costuri de dezvoltare si 40% costuri pentru testare.
Pentru software-ul orientat pe client costurile de evolutie depasesc
deseori costurile de dezvoltare
o Costurile variaza in functie de:
-Tipul sistemului ce trebuie dezvoltat
 -Cerintele impuse atributelor sistemului cum ar fi performanta si
fiabilitate
o Distributia costurilor depinde de modelul de dezvoltare utilizat
Metodele ingineriei software?
o Def. Abordari structurate ale dezvoltarii de software care includ modele
de sistem, notatii, reguli, sfaturi pentru proiectare si ghidarea procesului
o Descrieri de modele - Descrieri ale modelelor grafice care trebuie
produse
o Reguli - Constrangeri aplicate modelelor sistemului
o Recomandari - Sfaturi cu privire la practici bune pentru proiectare
o Ghidare proces - Ce activitati trebuie urmate.
Ce inseamna CASE (Computer-Aided Software Engineering)
o Def. Sisteme software destinate furnizarii de suport automat pentru
activitatile procesului software
o Sistemele CASE sunt utilizate deseori ca suport pentru metodologii de
dezvoltare de software
o Upper-CASE: Instrumente in sprijinul activitatilor procesului referitoare la
cerinte si proiectare
o Lower-CASE: Instrumente ce sprijina activitatile de programare,
debugging si testare
Care sunt atributele unui software bun?
o Software-ul trebuie sa ofere utilizatorului functionalitatea si performanta
solicitata si trebuie sa fie mentenabil, dependabil si acceptabil
o Mentenabilitate: Software-ul trebuie sa evolueze pentru a respecta
cerinte in schimbare
o Dependabilitate: Software-ul trebuie sa fie demn de incredere; sa te poti
baza pe el
o Eficienta: Software-ul nu trebuie sa faca risipa de resursele sistemului
o Acceptabilitate: Software-ul trebuie sa fie acceptat de catre utilizatorii
pentru care a fost proiectat. Aceasta inseamna ca produsul software
trebuie sa fie inteligibil, utilizabil si compatibil cu alte sisteme
Care sunt provocarile adresate ingineriei software?
o Heterogenitate, livrare si incredere
o Heterogenitate: Dezvoltare de tehnici pentru construire de software care
poate sa faca fata la platforme si medii de executie eterogene
o Livrare: Dezvoltare de tehnici care sa conduca la livrare de software mai
rapida
o Incredere: Dezvoltare de tehnici care demonstreaza ca utilizatorii pot
avea incredere in produsul software
Responsabilitate etica si profesionala
o Ingineria software implica responsabilitati mai largi decat simpla aplicare
a competentelor tehnice
o Inginerii software trebuie sa aiba un comportament onest si sa manifeste
responsabilitate etica pentru a fi respectati ca profesionisti
o Comportamentul etic inseamna mai mult decat simpla sustinere a legii
Elemente de responsabilitate profesionala
o Confidentialitate: Inginerii trebuie sa respecte confidentialitatea
angajatorului si a clientilor, indiferent daca a fost sau nu semnat un
contract de confidentialitate
o Competenta: Inginerii trebuie sa-si reprezinte corect nivelul de
competenta. Ei nu trebuie sa accepte sarcini care nu se incadreaza in
competentele pe care le detin
Elemente de responsabilitate profesionala
o Drepturi de proprietate intelectuala: Inginerii trebuie sa fie constienti de
legile locale care guverneaza utilizarea proprietatii intelectuale, cum ar fi
patente, copyright, etc. Ei trebuie sa fie atenti in a se asigura ca este
protejata proprietatea intelectuala a angajatorului si a clientilor
o Abuzarea calculatorului: Inginerii software nu trebuie sa-si utilizeze
cunostintele tehnice pentru a abuza de calculatoarele altor persoane.
Abuzarea calculatoarelor variaza de la relativ trivial (ex. joc pe calculator)
la extrem de serios (diseminare de virusi).
Codul de etica ACM/IEEE
o Societatile profesionale din USA au cooperat in vederea producerii unui
cod de practica etica
o Membrii acestor organizatii semneaza un cod de practica etica in
momentul aderarii
o Codul contine Opt Principii relativ la comportamentul si deciziile
inginerilor software profesionisti, incluzand liber-profesionistii,
educatorii, managerii, supervizorii si cei care fac politicile, precum si
instructorii si studentii acestei profesiuni
Codul de etica - PREAMBUL
o Preambul: Versiunea scurta a codului rezuma, la un nivel ridicat de
abstractizare, aspiratiile; clauzele incluse in versiunea completa dau
exemple si detalii asupra modului in care aceste aspiratii modifica modul
in care actionam ca ingineri software profesionisti. Fara aspiratii, detaliile
pot deveni legalistice si anoste; fara detalii, aspiratiile pot suna pompuos
dar fara continut; impreuna, aspiratiile si detaliile formeaza un cod
coeziv si Inginerii software trebuie sa se angajeze in a face din analiza,
 specificarea, proiectarea, dezvoltarea, testarea si intretinerea software-
lui o profesiune folositoare si respectata. Conform cu angajamentul lor
relativ la sanatatea, siguranta si bunastarea publicului, inginerii software
trebuie sa adere la urmatoarele Opt Principii:
Codul de etica - PRINCIPII
1. PUBLIC: Inginerii software trebuie sa actioneze in concordanta cu
interesul public
2. CLIENT SI ANGAJATOR: Inginerii software trebuie sa actioneze intr-o
maniera care sa reprezinte cel mai bine interesele angajatorului si
ale clientului, in concordanta cu interesul public
3. PRODUS: Inginerii software trebuie sa asigure faptul ca produsele
lor si modificarile acestora respecta cele mai inalte standarde
profesionale
4. DISCERNAMANT: Inginerii software trebuie sa-si pastreze
integritatea si independenta in opiniile profesionale
5. MANAGEMENT: Managerii si conducatorii din ingineria software
trebuie sa subscrie si sa promoveze o abordare etica a
managementului dezvoltarii si intretinerii de software
6. PROFESIUNE: Inginerii software trebuie sa promoveze integritatea
si reputatia profesiunii in concordanta cu interesul public
7. COLEGIALITATE: Inginerii software trebuie sa fie cinstiti si sa-si
sprijine colegii
8. SELF: Inginerii software trebuie sa se perfectioneze continuu relativ
la practicarea profesiunii si trebuie sa promoveze o abordare etica
in practicarea acesteia
Dileme etice
o Dezacordul de principiu cu politicile managementului superior
o Angajatorul actioneaza intr-un mod lipsit de etica si lanseaza un sistem
critic din punct de vedere al sigurantei fara a finaliza testarea acestuia
o Participarea la dezvoltarea de sisteme militare sau nucleare
Puncte cheie
o Ingineria software este o disciplina de tip inginerie care se ocupa cu toate
aspectele producerii de software
o Produsele software constau din programe si din documentatia asociata
acestora. Atributele esentiale ale produselor software sunt
mentenabilitatea, dependabilitatea, eficienta si utilizabilitatea
o Procesul software consta din activitatile implicate in dezvoltarea de
produse software. Activitatile de baza sunt specificarea, dezvoltarea,
validarea si evolutia software-lui
 o Methodologiile sunt modalitati organizate de producere de software. Ele
includ sugestii pentru procesul ce trebuie urmat, notatiile ce se vor
utiliza, regulile ce guverneaza descrierile sistemului produse si indicatiile
de proiectare
o Instrumentele CASE sunt sisteme software care sunt proiectate pentru a
sprijini activitatile de rutina ale procesului software cum ar fi editarea
diagramelor de proiectare, verificarea consistentei diagramelor si
urmarirea testelor executate
o Inginerii software au responsabilitati fata de profesiunea de inginer si
fata de societate. Ei nu trebuie sa fie preocupati doar de problemele
tehnice
o Societatile profesionale publica coduri de conduita care precizeaza
standarde de comportament pentru membrii lor
Ce este un sistem?
o Def. Colectie semnificativa (cu un anume scop) de componente inter-
relationate care lucreaza impreuna pentru a realiza un obiectiv comun
o Poate include componente: Software & Hardware(mecanic, electric, etc)
si poate fi operat de persoane
o Componentele sistemului sunt interdependente
o Proprietatile si comportamentul componentelor sistemului sunt strans
corelate
Categorii de sisteme
o Sisteme tehnice bazate pe calculatoare:
-includ hardware si software
-operatorii si procesele operationale nu sunt considerate ca parte a
sistemului
-sistemul nu este “constient” se sine (self-aware)
o Sisteme socio-tehnice:
-includ sisteme tehnice
-includ procesele operationale si persoanele care utilizeaza si
interactioneaza cu sistemul tehnic
-sunt guvernate de politici si reguli organizationale
Caracteristicile sistemelor socio-tehnice
o Are proprietati emergente: Proprietati de ansamblu ale sistemului care
depind de componentele sistemului si de relatiile dintre acestea
o Non-deterministic: Nu produce intotdeauna aceeasi iesire pentru acelasi
set de intrare deoarece comportamentul sistemului este partial
dependent de operatorii umani
 o Relatii complexe cu obiectivele organizationale: Gradul in care sistemul
sprijina obiectivele organizationale nu depinde doar de acesta
Proprietati emergente
o Proprietati de ansamblu (globale) ale sistemului
o Sunt consecinta a relatiilor dintre componentele sistemului
o Pot fi evaluate si masurate doar dupa ce componentele au fost integrate
in sistem
Tipuri de proprietati emergente
o Proprietati emergente functionale: Apar atunci cand toate partile
sistemului lucreaza impreuna pentru a realiza un obiectiv. De exemplu, o
bicicleta, odata ce a fost asamblata din componentele sale, are
proprietatea functionala de a fi un dispozitiv de transport
o Proprietati emergente non-functionale:
-Exemple: fiabilitatea, performanta, siguranta, securitatea
-Sunt corelate cu comportamentul sistemului in contextul sau
operational
-Sunt deseori critice pentru sistemele bazate pe calculatoare deoarece
esuarea in a realiza un nivel minim definit pentru aceste proprietati
poate face ca sistemul sa nu poata fi utilizat
Ingineria fiabilitatii sistemului
o Defectele se pot propaga in sistem datorita inter-dependentei intre
componente
o Defectele sistemului apar deseori din cauza inter-relatiilor neprevazute
intre componente
o Este probabilistic imposibil de anticipat toate relatiile posibile intre
componente
o Rezultatele masuratorilor asupra fiabilitatii software-lui pot da o imagine
falsa a fiabilitatii sistemului
Influente asupra fiabilitatii
o Fiabilitate hardware: Probabilitatea ca o componenta hardware sa se
defecteze si durata repararii acesteia
o Fiabilitate software: Probabilitatea ca o componenta software sa
produca o iesire incorecta
o Fiabilitate operator: Probabilitatea ca un operator al sistemului sa faca o
greseala
Relatii de fiabilitate
o Un defect hardware poate genera semnale false care se afla in afara
domeniului intrarilor asteptate de catre software
 o Erori software pot produce activarea de alarme care cauzeaza stresarea
unui operator si conduc la erori produse de acesta
o Contextul in care este instalat un sistem poate afecta fiabilitatea sa
Proprietati de tip interdictie
o Exista proprietati care se exprima ca interdictii:
-Siguranta – sistemul nu trebuie sa se comporte in maniera nesigura
-Securitate – sistemul nu trebuie sa permita utilizare neautorizata
o Este dificil de masurat sau evaluat aceste proprietati
o Spre deosebire de acestea: Proprietati ca performanta si fiabilitatea pot
fi masurate mai simplu
Ingineria sistemelor
o Se refera la: Specificarea, proiectarea, implementarea, validarea,
repartizarea si intretinerea sistemelor socio-tehnice
o Se ocupa cu:
-Serviciile oferite de sistem
-Constrangerile asupra construirii si operarii sistemului
-Modurile in care este utilizat sistemul
Procesul ingineriei sistemelor
o Urmeaza in mod uzual modelul ‘waterfall’ datorita necesitatii de a
dezvolta in paralel diferite parti ale sistemului. Conditii restranse pentru
realizare de iteratii ale fazelor deoarece modificarile hardware sunt
foarte costisitoare. Software-ul poate avea sarcina de a compensa
problemele hardware
o Implica in mod inevitabil ingineri din discipline diferite care trebuie sa
lucreze impreuna. Posibilitate mare sa apara intelegeri gresite. Diferite
discipline utilizeaza vocabulare diferite deci este necesara negociere
indelungata. De asemenea, inginerii pot avea agende proprii de realizat
Definirea cerintelor sistemului
o In acest stadiu se definesc trei tipuri de cerinte:
-Cerinte functionale abstracte. Functiile sistemului sunt definite in
maniera abstracta
-Proprietatile sistemului. Sunt definite proprietatile de ansamblu non-
functionale ale sistemului
-Caracteristici indezirabile. Este specificat comportament inacceptabil
pentru sistem
o Obiective organizationale globale ale sistemului
Obiectivele sistemului
o Trebuie sa defineasca motivul procurarii sistemului pentru un context
particular, Exemplu:
 -Obiective functionale-Oferirea unui sistem de alarma incendii si intrusi
pentru o cladire, care va realiza averizare interna si externa a incendiilor
si intruziunilor neautorizate
-Obiective organizationale-Sa asigure faptul ca desfasurarea normala a
activitatilor din cladire nu este afectata serios de evenimente ca incendii
si intruziune neautorizata
Cerinte sistem: problematica
o Sistemele complexe sunt de obicei dezvoltate pentru a adresa probleme
dificile:
-Probleme care nu sunt complet intelese
-Probleme care se modifica pe masura ce sistemul este specificat
o Trebuie anticipata evfolutia hardware-lui/comunicatiilor pe perioada de
viata a sistemului
o Este dificil de definit cerintele non-functionale (in particular) fara
cunoasterea structurii sistemului la nivel de componente
Procesul proiectarii sistemului
o Partitionarea cerintelor: Organizarea cerintelor in grupuri pe baza de
relatii
o Identificarea sub-sistemelor: Identificarea unui set de sub-sisteme care
pot realiza, in colectiv, cerintele sistemului
o Alocarea cerintelor pe sub-sisteme: Produce probleme specifice cand
sunt integrate componente COTS (Commercial, Off-the-Shelf)
o Specificarea functionalitatii la nivel de sub-sistem
o Definirea interfetelor sub-sistemelor: Activitate critica in cazul dezvoltarii
de sub-sisteme in paralel
Proiectarea sistemului: problematica
o Partitionarea cerintelor intre hardware, software si componente umane
poate implica negociere intensa
o Deseori se presupune ca problemele dificile de proiectare sunt solvabile
prin utilizare de software
o Platformele hardware pot fi nepotrivite pentru cerintele software, lucru
ce trebuie compensat de software
Cerinte si proiectare
o Ingineria cerintelor si proiectarea sistemului sunt strans legate
o Constrangerile impuse de contextul sistemului si de alte sisteme
limiteaza variantele de proiectare astfel incat poate deveni o cerinta
chiar utilizarea unui anume proiect
o Pentru a structura cerintele poate fi necesara o etapa initiala de
proiectare
 o Pe masura desfasurarii proiectarii se afla lucruri noi referitoare la cerinte
Modelarea sistemului
o Un model arhitectural prezinta o perspectiva abstracta a sub-sistemelor
ce formeaza un sistem
o Poate include fluxuri majore de informatii intre sub-sisteme
o Este prezentata de obicei ca diagrama bloc
o Poate identifica diferite tipuri de componente functionale in model
Dezvoltare sub-sistem
o Proiecte (tipic) paralele pentru dezvoltare de hardware, software si
comunicatii
o Poate implica procurare de sisteme COTS (Commercial Off-the-Shelf)
o Lipsa de comunicare intre echipele de implementare
o Mecanism birocratic si lent pentru propunerea de modificari la sistem =>
orarul de dezvoltare poate necesita extindere datorita nevoii de relua
unele activitati
Integrare sistem
o Procesul de a pune impreuna hardware, software si persoane pentru a
construi un sistem
o Trebuie abordat incremental astfel incat sub-sistemele sunt integrate pe
rand
o In acest stadiu apar in mod uzual problemele de interfata intre sub-
sisteme
o Pot sa apara probleme cu furnizari necoordonate ale componentelor
sistemului
Instalare sistem
o Dupa finalizare, sistemul trebuie instalat in contextul clientului:
-Premizele asupra contextului pot fi incorecte
-Poate sa apara rezistenta umana la introducerea unui nou sistem
-E posibil ca sistemul sa fie nevoit sa coincida cu sisteme alternative
pentru o anumita perioada de timp
-Pot sa apara probleme de instalare fizica (ex. probleme de cablare)
-Trebuie identificate necesitatile de instruire a operatorilor
Evolutie sistem
o Sistemele mari au durate de viata lungi. Ele trebuie sa evolueze pentru a
indeplini cerinte in schimbare
o Evolutia este in mod inerent costisitoare:
-Modificarile trebuie analizate din perspectiva tehnica si din perspectiva
economica
 -Pot sa apara probleme neanticipate datorate interactiunii sub-
sistemelor
-Rareori exista o ratiune fundamentata pentru deciziile originale de
proiectare
-Structura sistemului este corupta pe masura ce apar modificari la ea
o Sistemele existente ce trebuie pastrate sunt numite uneori sisteme
legacy
Dezafectarea sistemului
o Def. Scoaterea din functiune a sistemului la sfarsitul duratei de viata utila
o Poate necesita indepartare de materiale (ex. chimicale periculoase) care
polueaza mediul: Trebuie pregatita in proiectarea sistemului prin
incapsulare
o Poate necesita restructurarea si conversia datelor pentru a fi utilizate in
alt sistem
Organizatii/persoane/sisteme
o Sistemele socio-technice sunt sisteme organizationale destinate
realizarii unui scop organizational sau aplicativ (al afacerii)
o Daca nu este inteles contextul organizational in care este utilizat
sistemul, este mai putin probabil ca acesta sa indeplineasca cerintele
reale ale afacerii si ale utilizatorilor lui
Factori umani si organizationali
o Modificari proces
o Modificari job
o Modificari organizationale
Procesele organizationale
o Procesele ingineriei sistemelor se suprapun si interactioneaza cu
procesele organizationale pentru procurari
o Procesele operationale sunt procesele implicate in utilizarea sistemului
pentru scopul caruia ii este destinat. Pentru sistemele noi, acestea
trebuie definite ca parte a proiectarii sistemului
o Procesele operationale trebuie proiectate astfel incat sa fie flexibile si sa
nu forteze realizarea operatiilor intr-un mod particular. Este important ca
operatorii umani sa-si poata utiliza initiativa atunci cand apar probleme
Procurare sistem
o Def. Achizitionarea unui sistem pentru a indeplini o cerinta a organizatiei
o De obicei este necesara specificare sistem si proiectare arhitecturala
inainte de procurare:
-Este nevoie de specificare pentru a lansa un contract de dezvoltare a
sistemului
 -Specificarea poate permite cumpararea unui sistem COTS (aproape
intotdeauna mai ieftin decat dezvoltarea integrala a sistemului)
o Sistemele mari si complexe constau din combinatii de componente COTS
si componente special proiectate. Procesele pentru procurarea acestor
tipuri diferite de componente sunt in mod uzual diferite
Problematica procurarii
o Cerintele ar putea necesita modificare pentru a se potrivi capabilitatilor
componentelor off-the-shelf
o Specificatiile cerintelor pot fi parte a contractului pentru dezvoltarea
sistemului
o Dupa ce a fost ales contractorul ce va construi sistemul, exista de obicei
o perioada de negociere in cadrul contractului pentru acordul asupra
modificarilor
Contractori si sub-contractori
o Procurarea de sisteme mari hardware/software graviteaza de obicei in
jurul unui contractor principal
o Sunt realizate sub-contracte cu alti furnizori pentru a furniza parti din
sistem
o Clientul tine legatura cu contractorul principal si nu trateaza direct cu
sub-contractorii
Sisteme legacy
o Sisteme socio-tehnice care au fost dezvoltate utilizand tehnologii vechi,
depasite
o Cruciale pentru operarea unei anumite afaceri si uneori este prea riscant
sa fie dezafectate:
-Sistem de contabilizare pentru client bancar
-Sistem de intretinere a avioanelor
o Sistemele legacy impun constangeri noilor procese economice (business)
si consuma o proportie insemnata din bugetele companiilor
Componentele sistemelor legacy
o Hardware-poate fi hardware depasit de tip mainframe
o Suport software-se pot baza pe suport software de la furnizori care nu
mai exista
o Software de aplicatie-pot fi scrise in limbaje de programare depasite
o Data ale aplicatiei-deseori incomplete si inconsistente
o Procese economice-pot fi constranse de structura si functionalitatea
software-lui
o Politici si reguli economice-pot fi implicite si incapsulate in software-ul
sistemului
Puncte cheie
o Sistemele socio-tehnice includ hardware, software si persoane si sunt
proiectate pentru a realiza un anume scop economic
o Proprietatile emergente sunt proprietati care sunt caracteristice
sistemului in ansamblu si nu partilor lui componente
o Procesul ingineriei sistemelor include specificare, proiectare, dzvoltare,
integrare si testare. Integrarea sistemului este in mod deosebit critica
o Factorii umani si organizationali au un efect semnificativ asupra modului
in care opereaza sistemele socio-tehnice
o Exista interactiuni complexe intre procesele pentru procurarea,
dezvoltarea si operarea sistemelor
o Un sistem legacy este un sistem vechi care continua sa ofere servicii
esentiale
o Sistemele legacy includ procese economice, software de aplicatii,
software support si hardware
Procesul software
o Def. Proces software = set structurat de activitati necesare pentru
dezvoltarea unui sistem software: specificare & proiectare && validare
&&& evolutie
o Def. Model pentru proces software = reprezentare abstracta a unui
proces. Prezinta o descriere a unui proces dintr-o perspectiva particulara
Modele generice pentru procesul software
o Modelul cascada (waterfall)- Etape separate si disticte de specificare si
de dezvoltare
o Dezvoltare evolutiva-Specificarea, dezvoltarea si validarea sunt
intercalate
o CBSE (Component-based software engineering)- Sistemul este asamblat
din componente existente
o Exista variante multiple ale acestor modele. De exemplu dezvoltarea
formala, unde se utilizeaza un proces de tip cascada dar specificarea este
o specificare formala care este rafinata de-a lungul mai multor stadii
pentru a deveni un proiect implementabil
Etapele modelului cascada
o Analiza si definirea cerintelor
o Proiectarea sistemului si a software-lui
o Implementarea si testarea unitatilor
o Integrarea si testarea sistemului
o Operarea si mentenanta (intretinerea)
 o Principalul dezavantaj al modelului cascada consta in dificultatea
adaptarii modificarilor dupa ce procesul demarat. Aceasta deoarece
inainte de a se trece la o noua etapa este necesara incheierea celei
precedente.
Problematica modelului cascada
o Partitionarea inflexibila a proiectului in stadii distincte face dificil
raspunsul la modificarea cerintelor clientului
o Modelul este potrivit doar in cazurile in care cerintele sunt bine intelese
si modificarile vor fi in limite acceptabile in timpul procesului de
dezvoltare
o Putine sisteme economice au cerinte stabile
o Modelul cascada este folosit in special pentru proiecte de ingineria
sistemelor mari, unde un sistem este dezvoltat pe mai multe sit-uri
Dezvoltare evolutiva
o Dezvoltare exploratorie-Obiectivul este acela de a lucra cu clientii si de a
dezvolta un sistem final dintr-o specificare schitata initial. Trebuie sa se
inceapa cu cerinte bine intelese si sa se adauge caracteristici noi pe baza
propunerilor clientului
o Prototipare (throw-away prototiping)- Obiectivul este acela de a intelege
cerintele sistemului. Trebuie sa se inceapa cu cerintele putin intelese si
sa se clarifice ceea ce este necesar cu adevarat
Dezvoltare evolutiva
o Probleme:
-Lipsa vizibilitatii procesului
-Sistemele sunt deseori slab structurate
-Pot fi necesare calificari speciale (ex. in limbaje pentru prototipare
rapida)
o Aplicabilitate:
-Pentru sisteme interactive de dimensiuni mici sau mijlocii
-Pentru parti din sisteme mari (ex. interfata utilizator)
- Pentru sisteme cu durate mici de viata
CBSE (Component-based software engineering)
o Bazata pe reutilizare sistematica, unde sistemele sunt integrate din
componente existente sau din sisteme COTS (Commercial-off-the-shelf)
o Etapele procesului:
-Analiza componente
-Modificare cerinte
-Proiectare sistem cu reutilizare
-Dezvoltare si integrare
 o Aceasta abordare este din ce in ce mai mult utilizata odata cu aparitia
standardelor de componente
Iterare proces
o Cerintele sistemului se dezvolta (INTOTDEAUNA) pe parcursul unui
proiect, astfel incat reiterarea, in care primele etape sunt reluate, este
intotdeauna parte a procesului pentru sisteme mari
o Iterarea se poate aplica oricarui model generic de proces software
o Doua abordari (corelate): Furnizare incrementala & Dezvoltare in spirala
Furnizare incrementala
o In loc de a livra sistemul deodata, dezvoltarea si livrarea sunt divizate in
incremente, cu fiecare increment livrand o parte a functionalitatii cerute
o Cerintele utilizatorului sunt prioritizate si cerintele cu cele mai mari
prioritati sunt incluse in primele incremente
o Odata ce a fost pornita dezvoltarea unui increment cerintele sunt
inghetate, desi cerintele pentru urmatoarele incremente pot continua sa
evolueze
Avantajele dezvoltarii incrementale
o Se poate furniza valoare la client cu fiecare increment, astfel incat
functionalitatea sistemului este disponibila mai devreme
o Primele incremente actioneaza ca un prototip care ajuta la obtinerea
cerintelor pentru incrementele urmatoare
o Risc mai scazut de esuare a intregului proiect
o Serviciile sistemului cu prioritati mari tind sa fie testate mai mult
Programare extrema
o Abordare a dezvoltarii bazata pe dezvoltarea si furnizarea de incremente
de functionalitate foarte mici
o Se bazeaza pe: imbunatatirea constanta a codului & implicarea
utilizatorului in echipa de dezvoltare && programare in mod pereche
(pairwise)
Dezvoltare in spirala
o Procesul este reprezentat sub forma de spirala (in loc de secventa de
activitati cu reluare)
o Fiecare bucla din spirala reprezinta o etapa in proces
o Nu exista faze fixe ca specificare sau proiectare – buclele din spirala sunt
alese functie de ceea ce este necesar
o Risurile sunt evaluate explicit si rezolvate de-a lungul procesului
Sectoarele modelului spirala
o Stabilire obiective-Sunt identificate obiectivele specifice etapei
 o Evaluare si reducere risc-Riscurile sunt evaluate si se realizeaza activitati
pentru reducerea riscurilor cheie
o Dezvoltare si validare-Se alege un model de dezvoltare pentru sistem,
care poate fi oricare din modelele generice
o Planificare-Proiectul este revazut si se planifica urmatoarea etapa a
spiralei
Activitatile procesului
o Specificarea software-lui
o Proiectarea si implementarea software-lui
o Validarea software-lui
o Evolutia software-lui
Specificarea software-lui
o Def. Procesul de stabilire a serviciilor cerute si a constrangerilor asupra
operarii si dezvoltarii sistemului
o Procesul pentru ingineria cerintelor: Studiu de fezabilitate & Obtinere si
analiza cerinte && Specificare cerinte &&& Validare cerinte
Proiectarea si implementarea software-lui
o Def. Procesul de convertire a specificatiilor sistemului intr-un sistem
executabil
o Proiectare software-Proiectarea unei structuri software care realizeaza
specificatiile
o Implementatare-Traducerea acestei structuri intr-un program executabil
o Activitatile de proiectare si implementare sunt strans corelate si pot fi
intercalate
Activitatile procesului de proiectare a software-lui
o Proiectare arhitecturala
o Specificare abstracta
o Proiectare interfata
o Proiectare componente
o Proiectare structura de date
o Proiectare algoritm
Metode structurate
o Def. Abordari sistematice ale proiectarii software-lui
o Proiectul este documentat (in mod uzual) sub forma de set de modele
grafice
o Modele posibile: Model obiecte & Model secvente && Model tranzitii de
stare &&& Model structural &&&& Model al fluxului de date
Programare si depanare
 o Def. Traducerea proiectului intr-un program si eliminarea erorilor din
acel program
o Programarea este o activitate personala – nu exista un proces generic
pentru aceasta activitate
o Programatorii realizeaza o testare initiala a programului in cursul
operatiei de depanare (debugging) pentru a descoperi si corecta erori ale
programului
Validarea software-lui
o Verificarea si validarea (V & V) au scopul de a arata ca sistemul se
conformeaza specificatiilor sale si indeplineste cerintele clientului
sistemului
o Implica procese de verificare/control si revizuire si testarea sistemului
o Testarea sistemului implica executarea sistemului cu cazuri de testare
care sunt derivate din specificarea de date reale ce trebuie procesate de
sistem
Stadiile testarii
o Testare componente sau unitati: Componentele individuale sunt testate
independent & Componentele pot fi functii sau obiecte sau grupuri
coerente de astfel de entitati
o Testare sistem: Testarea sistemului in ansamblu. Testarea proprietatilor
emergente are o importanta speciala
o Teste de acceptare: Testare cu datele clientului pentru a verifica daca
sistemul indeplineste cerintele acestuia
Evolutia software-lui
o Software-ul este in mod inerent flexibil si se poate modifica
o Pe masura ce cerintele se modifica odata cu modificarea circumstantelor
economice, software-ul suport pentru procesul economic trebuie, de
asemenea, sa evolueze si sa se schimbe
o Desi s-a facut demarcarea intre dezvoltare si evolutie (intretinere),
aceasta devine din ce in ce mai nerelevanta pe masura ce din ce in ce mai
putine sisteme sunt complet noi
RUP (Rational Unified Process)
o Model modern pentru procesul software, derivat din UML si procesele
asociate elaborarii acestuia
o Descris din 3 perspective: Perspectiva dinamica-arata repartizarea
etapelor in timp & Perspectiva statica-arata activitatile procesului &&
Perspectiva practica-sugereaza practici bune
Etapele RUP
o Conceptie-Stabilirea cazului business pentru sistem
 o Elaborare-Dezvoltarea unei intelegeri a domeniului problemei si a
arhitecturii sistemului
o Construire-Proiectarea sistemului, programarea si testarea
o Tranzitie-Repartizarea (deploy) sistemului in contextul sau de operare
Practici bune RUP
o Dezvoltare iterativa a software-lui
o Managementul cerintelor
o Utilizare de arhitecturi bazate pe componente
o Modelare vizuala a software-lui
o Verificarea calitatii software-lui
o Controlul modificarilor la software
CASE (Computer-aided software engineering)
o CASE (Computer-aided software engineering) este software folosit ca
suport pentru procesele de dezvoltare de software si de evolutie a
software-lui.
o Automatizare activitati: Editoare grafice pentru dezvoltarea modelului
sistemului & Dictionare de date pentru gestionarea entitatilor proiectarii
&& Constructor GUI pentru construirea interfetei utilizator &&&
Debugger-e pentru a sprijini gasirea erorilor in program &&&&
Traducatoare (translator) automate pentru generare de noi versiuni de
program
Tehnologia CASE
o Tehnologia CASE a condus la imbunatatiri semnificative ale procesului
software. Totusi nu atat de mult cat s-a prezis
o Ingineria software cere gandire creativa – aceasta nu este usor de
automatizat
o Ingineria software este o activitate de echipa si, pentru proiectele mari,
se cheltuieste mult timp cu interactiunile in cadrul echipei. Tehnologia
CASE ofera mai geru suport pentru acestea
Clasificare pentru CASE
o Clasificarea ajuta la intelegerea diferitelor tipuri de instrumente CASE si
suportul oferit de ele pentru activitatile procesului software
o Perspectiva functionala-Instrumentele sunt clasificate conform functiei
lor specifice
o Perspectiva proces-Instrumentele sunt clasificate conform activitatilor
procesului pentru care ofera suport
o Perspectiva integrarii-Instrumentele sunt clasificate conform organizarii
lor in unitati integrate
Integrare CASE
 o Instrumente-Suport pentru activitati individuale ale procesului, cum ar fi
verificarea consistentei proiectarii, editare text, etc
o Workbench-uri-Suport pentru o etapa a procesului cum ar fi specificare
sau proiectare; in mod normal includ mai multe instrumente integrate
o Medii-Suport pentru tot sau pentru o parte substantiala a intregului
proces software. In mod normal includ mai multe workbench-uri
integrate
Puncte cheie
o Procesele software sunt activitatile implicate in producerea si evolutia
unui sistem software.
o Modelele proceselor software sunt reprezentari abstracte ale acestor
procese
o Activitatile generale sunt specificarea, proiectarea si implementarea,
validarea si evolutia
o Modelele generice ale proceselor descriu organizarea proceselor
software. Exemplele includ modelul cascada, modelul dezvoltarii
evolutive si ingineria software bazata pe componente
o Modelele iterative ale procesului descriu procesul software sub forma de
ciclu de activitati
o Ingineria cerintelor este procesul de dezvoltare a specificatiilor software-
lui
o Procesele de proiectare si implementare transforma specificatiile in
program executabil
o Validarea implica controlarea faptului ca sistemele indeplinesc
specificatiile si necesitatile utilizatorului.
o Evolutia se refera la modificarea sistemului dupa ce a fost dat in
exploatare
o RUP (Rational Unified Process) este un model generic de proces care
separa activitatile de etape
o Tehnologia CASE ofera suport pentru activitatile procesului software
Ingineria cerintelor
o Def. Ingineria cerintelor = procesul de stabilire a serviciilor pe care le
solicita utilizatorul din partea sistemului si a constrangerilor impuse
operarii si dezvoltarii sistemului
o Def. Cerintele = descrierile serviciilor si constrangerilor sistemului, care
sunt generate in timpul procesului de inginerie a cerintelor
Ce este o cerinta?
 o Poate varia de la o descriere abstracta de nivel inalt a unui serviciu sau a
unei constrangeri a sistemului pana la o specificatie functionala precizata
in detaliu in termeni matematici
o Acest lucru este inevitabil deoarece cerintele pot servi unei functii duale:
Pot fi baza unei licitatii pentru un contract => trebuie sa fie deschise
catre interpretare & Pot fi baza contractului insusi => trebuie definite in
detaliu && Ambele declaratii (abstracta si detaliata) pot fi numite cerinte
Tipurile de cerinte
o Cerinte utilizator-Expuneri in limbaj natural plus diagrame ale serviciilor
pe care le furnizeaza sistemul si constrangerile sale operationale. Scrise
pentru clienti
o Cerinte sistem-Un document structurat care precizeaza descrieri
detaliate ale functiilor, serviciilor si constrangerilor operationale ale
sistemului. Defineste ceea ce trebuie implementat, deci poate fi parte a
contractului intre client si contractor
Definitii si specificatii
o Def. cerinta utilizator: Software-ul trebuie sa ofera un mijloc de a
reprezenta si accesa fisiere externe create de alte instrumente
o Specificatie cerinte sistem: .1 Utilizatorulului trebuie sa i se ofere
facilitati de a defini tipuri de fisiere externe .2 Fiecare tip de fisier extern
poate avea asociat un instrument care poate fi aplicat fisierului .3 Fiecare
tip de fisier extern poate fi reprezentat sub forma unei pictograme
specifice pe display-ul utilizatorului .4 Trebuie oferite facilitati pentru
definirea de catre utilizator a pictogramei pentru reprezentarea unui tip
de fisier extern .5 Cand un utilizator selecteaza o pictograma
reprezentand un fisier extern, efectul selectarii este acela de a aplica
instrumentul asociat tipului de fisier extern fisierului reprezentat de
pictograma selectata
Cerinte functionale si non-functionale
o Cerinte functionale: Precizarea serviciilor pe care trebuie sa le ofere
sistemul, cum trebuie sa reactioneze sistemul la intrari particulare si cum
trebuie sa se comporte sistemul in situatii particulare
o Cerinte non-functionale: Constrangeri asupra serviciilor sau functiilor
oferite de sistem, cum ar fi constrangeri de timp, constringeri asupra
procesului de dezvoltare, standarde, etc
o Cerinte de domeniu: Cerinte care vin din partea domeniului de aplicatie
al sistemului si care reflecta caracteristicile acelui domeniu
Cerinte functionale
o Descriu functionalitatea sau serviciile sistem
 o Depind de tipul de software, de utilizatorii preconizati si de tipul
sistemului in care este utilizat software-ul
o Cerintele utilizator functionale pot fi expuneri de nivel inalt despre ceea
ce trebuie sa faca sistemul
o Cerintele sistem functionale trebuie sa descrie serviciile sistemului in
detaliu
Exemplu: Sistemul LIBSYS
o Un sistem de biblioteca ce ofera o interfata unica catre mai multe baze
de date cu articole din diferite biblioteci.
o Utilizatorii pot cauta, descarca si imprima aceste articole pentru studiu
individual
Exemple de cerinte functionale
o Utilizatorul trebuie sa poata cauta fie in intregul set initial al bazelor de
date fie sa poata selecta un subset al acestuia
o Sistemul va oferi instrumente de vizualizare corespunzatoare pentru ca
utilizatorul sa citeasca documentele
o Fiecarui ordin i se va aloca un identificator unic (ORDER_ID) pe care
utilizatorul il va putea copia in zona de memorie permanenta a contului
Imprecizia cerintelor
o Daca cerintele nu sunt exprimate precis pot sa apara probleme.
o Cerinte ambigue pot fi interpretate in moduri diferite de catre
dezvoltatori si utilizatori
o Consideram termenul ‘instrumente de vizualizare corespunzatoare’ din
exemplul prezentat in slide-ul anterior: Intentia utilizatorului-
instrumente de vizualizare specifice pentru fiecare tip de document &
Interpretarea dezvoltatorului-Oferirea unui instrument simplu de
vizualizare text care sa arate continutul documentului
Completitudinea si consistenta cerintelor
o In principiu, cerintele trebuie sa fie atat complete cat si consistente
o Complete-Trebuie sa includa descrieri ale tuturor facilitatilor necesare
o Consistente-Nu trebuie sa existe conflicte sau contradictii in descrierile
facilitatilor sistemului
o In practica, este imposibil sa se produca un document al cerintelor si
complet si consistent
Cerinte non-functionale
o Definesc proprietatile (ex. fiabilitate, timp de raspuns, necesar de
memorie) si constrangerile (ex. capabilitatile dispozitivelor de I/E,
reprezentarile sistemului, etc)
 o De asemenea, pot fi specificate cerintele procesului software impunand
un anume sistem CASE, un limbaj de programare sau o metoda de
dezvoltare
o Pot fi mai critice decat cerintele functionale: daca nu sunt indeplinite
atunci sistemul este nefolositor
Clasificarea cerintelor non-functionale
o Cerinte produs-Cerinte care specifica modul particular in care trebuie sa
se comporte produsul furnizat (ex. viteza de executie, fiabilitate, etc)
o Cerinte de organizatie-Cerinte ce sunt consecinta a politicilor si
procedurilor organizationale (ex. standarde de proces utilizate, cerinte
de implementare, etc)
o Cerinte externe-Cerinte care provin de la factorii externi sistemului si
procesului dezvoltarii sale (ex. cerinte de interoperabilitate, cerinte
legislative etc)
Teluri si cerinte
o Poate fi foarte dificil de precizat unele cerinte non-functionale, iar
cerinte imprecise pot fi verificate cu dificultate
o Tzel: O intentie generala a utilizatorului (ex. usurinta in utilizare)
o Cerinta non-functionala verificabila-O exprimare care utilizeaza o masura
ce poate fi testata obiectiv
o Telurile sunt utile dezvoltatorilor deoarece transmit intentiile
utilizatorilor sistemului
Exemple
o Un tzel al sistemului: Sistemul trebuie sa fie usor de folosit de catre
controlorii experimentati si trebuie organizat astfel incat sa se
minimizeze erorile utilizatorilor
o O cerinta non-functionala verificabila-Controlorii experimentati trebuie
sa fie capabili sa utilizeze toate functiile sistemului dupa un total de doua
ore de antrenament. Dupa acest antrenament, numarul mediu de erori
efectuate de utilizatorii experimentati nu va depasi doua pe zi
Interactiunea cerintelor
o In sisteme complexe apar in mod obisnuit conflicte intre diferite cerinte
non-functionale
o Exemplu: Sistem pentru nava spatiala:
o Pentru a minimiza greutatea, trebuie minimizat numarul de chip-uri
separate in sistem.
o Pentru a minimiza consumul de energie, trebuie utilizate chip-uri la
puteri joase.
 o Totusi, utilizand chip-uri la puteri joase poate insemna ca trebuie
utilizate mai multe chip-uri.
Cerinte de domeniu
o Sunt derivate din domeniul aplicatiei si descriu caracteristicile si
trasaturile care reflecta domeniul ale sistemului
o Pot fi cerinte functionale noi, constrangeri asupra cerintelor existente
sau definitii ale unor operatii de calcul specifice
o Daca nu sunt satisfacute, sistemul poate fi nefunctional
Cerinte de domeniu: problematica
o Intelegere: Cerintele sunt exprimate in limbajul domeniului aplicatiei &
Acesta este deseori greu de inteles pentru inginerii care dezvolta
sistemul
o Subintelegere: Specialistii domeniului inteleg domeniul atat de bine incat
nu considera ca este necesar sa expliciteze cerintele de domeniu.
Acestea li se par subintelese si implicite
Cerinte utilizator
o Cerintele functionale si non-functionale trebuie descrise astfel incat sa
poata fi intelese de catre utilizatorii sistemului care nu au conostinte
tehnice de detaliu
o Sunt definite utilizand limbaj natural, tabele si diagrame deoarece
acestea pot fi intelese de toti utilizatorii
Probleme cu limbajul natural
o Lipsa de claritate-Odata cu cresterea preciziei exprimarii documentul
devine dificil de citit
o Confuzii ale cerintelor-Se tinde catre amestecarea cerintelor functionale
si non-functionale
o Amalgamarea cerintelor-Mai multe cerinte diferite ar putea fi exprimate
impreuna
Cerinte sistem
o Def: Specificatii, mai detaliate decat cerintele utilizator, ale functiilor,
serviciilor si constrangerilor sistemului
o Sunt destinate sa constituie baza pentru proiectarea sistemului
o Pot fi incorporate in contractul sistemului
o Pot fi definite sau ilustrate utilizand modele de sistem (curs ulterior)
Cerintele si proiectarea
o In principiu, cerintele trebuie sa exprime ceea ce sistemul trebuie sa faca
si proiectarea trebuie sa descrie cum se realizeaza aceasta.
o In practica, cerintele si proiectarea sunt inseparabile: Pentru a structura
cerintele se poate proiecta o arhitectura a sistemului & Sistemul poate sa
 inter-opereze cu alte sisteme care genereaza cerinte de proiectare &&
Utilizarea unei anumite proiectari poate fi o cerinta de domeniu
Probleme cu specificarea in limbaj natural
o Ambiguitate: Cititorii si scriitorii cerintei trebuie sa interpreteze aceleasi
cuvinte in acelasi fel. Limbajul natural este inerent ambiguu astfel incat
acest lucru este dificil
o Supra-flexibilitate: Acelasi lucru poate fi spus in mai multe moduri in
specificatie
o Lipsa modularizarii: Structurile limbajului natural nu sunt adecvate
structurarii cerintelor sistem
Specificatii in limbaje structura
o Libertatea scriitorului de cerinte este limitata de un tipar (template)
predefinit pentru cerinte
o Toate cerintele sunt scrise intr-o maniera standard
o Terminologia utilizata in descriere poate fi limitata
o Avantajul consta in faptul ca se pastreaza expresivitatea limbajului
natural dar se impune un grad de uniformitate asupra specificatiilor
Specificatii bazate pe forma
o Definitia functiei sau a entitatii
o Descrierea intrarilor si surselor acestora
o Descrierea iesirilor si a destinatiilor acestora
o Indicarea altor entitati necesare
o Pre si post conditii (daca e cazul)
o Efectele colaterale (daca exista) ale functiei
Specificare tabelara
o Utilizata pentru a suplimenta limbajul natural
o Utila in special atunci cand trebuie definite mai multe cursuri alternative
de actiune
Modele grafice
o Sunt foarte utile atunci cand este necesar sa se ilustreze cum se modifica
starile sau cand este necesara descrierea unei secvente de actiuni
o Diferite modele grafice vor fi explicate intr-un curs ulterior
Diagrame de secvente
o Ilustreaza secventele de evenimente care au loc in cursul unei
interactiuni a utilizatorului cu sistemul
o Ordinea actiunilor este exprimata de sus in jos: Exemplu: Sistem pentru
extragere cash de la un ATM: Validare card & Tratare cerere &&
Finalizare tranzactie
Specificatii de interfata
 o Majoritatea sistemelor trebuie sa lucreze cu alte sisteme iar interfetele
de operare trebuie specificate ca parte a cerintelor
o Trebuie definite trei tipuri de interfete: Interfetele procedurale &
Structurile datelor care sunt transferate && Reprezentarile datelor
o Notatiile formale = tehnica eficienta pentru specificarea interfetei
Standardul IEEE pentru cerinte
o Defineste o structura generica pentru un document de cerinte ce trebuie
instantiata pentru fiecare sistem specific
o Introducere: Scopul documentului cerintelor + Domeniul produsului +
Definitii, acronime si abrevieri + Referinte + Rezumat al restului
documentului
o Descriere generala: Perspectiva produsului + Functiile produsului +
Caracteristicile utilizator + Constrangeri generale + Premize si
dependente
o Cerinte specifice: Functionale + Non-functionale + De interfata
o Cea mai substantiala parte a documentului
o Variabilitate mare in practica organizationala-nu are o structura standard
o Apendice
o Index
Structura documentului cerintelor
o Prefata
o Introducere
o Glosar
o Definitiile cerintelor utilizator
o Arhitectura sistemului
o Specificatiile cerintelor sistem
o Modelele sistemului
o Evolutia sistemului
o Apendice
o Index
Puncte cheie
o Cerintele indica CE trebuie sa faca sistemul si definesc constrangeri
asupra operarii si implementarii lui.
o Cerintele functionale indica serviciile pe care trebuie sa le ofere sistemul
o Cerintele non-functionale constrang sistemul ce trebuie dezvoltat sau
procesul de dezvoltare a acestuia
o Cerintele utilizator sunt expuneri de nivel inalt despre ce trebuie sa faca
sistemul. Cerintele utilizator trebuie scrise utilizand limbaj natural, tabele
si diagrame
 o Cerintele sistem sunt destinate sa comunice functiile pe care sistemul
trebuie sa le furnizeze
o Un document al cerintelor software este o expunere agreata a cerintelor
sistemului
o Standardul IEEE este un punct de plecare util pentru definirea de
standarde specifice, mai detaliate, de cerinte
Procesul ingineriei cerintelor
o Scop: crearea si intretinerea unui document al cerintelor sistem
o Variaza functie de: domeniul aplicatiei & persoanele implicate &&
organizatia care dezvolta cerintele
o Activitati generice comune tuturor variantelor procesului: Identificarea
cerintelor & Analiza cerintelor && Validarea cerintelor &&&
Managementul cerintelor
Perspectiva alternativa asupra procesului ingineriei cerintelor
o Activitatile organizate sub forma unui proces iterativ in jurul unei spirale
impartita in trei zone
o Timpul si efortul alocat fiecarei activitati intr-o iteratie depinde de: Etapa
din cadrul procesului & Tipul sistemului dezvoltat
Perspectiva alternativa asupra procesului ingineriei cerintelor
o In etapele initiale-intelegerea: Cerintelor economice generale &
Cerintelor non-functionale && Cerintelor utilizator
o In etapele ulterioare: Ingineria cerintelor sistem & Modelarea sistemului
o Potrivita abordarilor in care cerintele sunt dezvoltate pe diferite nivele
de detaliu
o Numarul de iteratii in spirala poate varia => spirala poate fi parasita dupa
ce au fost identificate o parte sau toate cerintele utilizator
o Daca activitatea de prototipare este extinsa pentru a include dezvoltare
iterativa => modelul permite ca cerintele si implementarea sistemului sa
fie dezvoltate in paralel
Studiul de fezabilitate
o Studiul de fezabilitate decide daca sistemul propus merita sau nu a fi
dezvoltat
o Este un studiu scurt si concentrat care verifica daca: Sistemul contribuie
la obiectivele organizationale & Sistemul poate fi realizat utilizand
tehnologiile curente si bugetul alocat && Ssistemul poate fi integrat cu
alte sisteme utilizate
Implementarea studiului de fezabilitate
 o Intrari: Cerinte ale procesului economic (business) preliminare & Scurta
descriere a sistemului && Schitarea modului in care sistemul va sprijini
procesele economice
o Rezultat: Raport care recomanda continuarea sau renuntarea la
dezvoltarea sistemului
o Bazata pe: Evaluarea informatiilor despre ce se cere & Colectarea de
informatii && Scrierea unui raport
Identificarea si analiza cerintelor
o Numita si extragerea sau descoperirea cerintelor
o Implica activitati in comun ale personalului tehnic cu clientii pentru a
intelege: Domeniul aplicatiei & Serviciile pe care sistemul trebuie sa le
ofere && Constangerile operationale ale sistemului
o Stakeholder-ii (partile interesate, partenerii)= persoanele si asociatiile
implicate
o Exemple: Utilizatori finali & Manageri && Ingineri implicati in intretinere
&&& Experti ai domeniului &&&& Sindicate, etc
Analiza cerintelor: problematica
o Partile interesate nu stiu exact ce vor
o Partile interesate exprima cerintele in termenii lor proprii
o Diferite parti interesate pot avea cerinte contradictorii (conflictuale)
o Factorii organizationali si politici pot influenta cerintele sistemului
o Modificarea cerintelor in timpul procesului de analiza: Pot sa apara noi
parti interesate & Se poate schimba contextul economic
Activitatile procesului
o Descoperirea cerintelor-Interactiune cu partile interesate pentru a
descoperi cerintele acestora. In acest stadiu sunt descoperite cerintele
de domeniu
o Clasificarea si organizarea cerintelor-Gruparea cerintelor aflate in relatie
si organizarea lor in grupuri (cluster-e) coerente
o Metoda: Identificare cerinte comune. Utilizarea unui model arhitectural
al sistemului pentru a identifica subsistemele si a asocia cerinte fiecarui
subsistem
o Prioritizare si negociere-Prioritizarea cerintelor si rezolvarea conflictelor
dintre acestea
o Documentarea cerintelor-Cerintele sunt documentate si constituie
intrare in urmatoarea bucla a spiralei
Descoperirea cerintelor
o Def. Procesul de culegere de informatii despre sistemele propuse si cele
existente si distilarea cerintelor utilizator si sistem din aceste informatii
 o Surse de informatii: Documentatii & Partile interesate in sistem
(stakeholders) && Specificatii ale unor sisteme similare
Exemplu: Partile interesate pentru sistemul ATM
o Clientii bancii
o Reprezentanti ai altor banci
o Managerii bancii
o Personalul contabil
o Administratorii bazei de date
o Managerii pentru securitate
o Departmentul de vanzari (marketing)
o Inginerii de la intretinere hardware si software
o Reglementatorii bancari
Puncte de vedere
o Def. Punctele de vedere sunt un mod de a structura cerintele astfel incat
sa reprezinte perspectivele diferitelor parti interesate. Partile interesate
pot fi clasificate ca avand diferite puncte de vedere
o Obs. Fiecare punct de vedere ofera o noua perspectiva asupra
sistemului; aceste perspective nu sunt complet independente – de obicei
se suprapun propunand astfel cerinte comune
o Aceasta analiza multi-perspectiva este importanta deoarece nu exista un
mod unic corect de a analiza cerintele sistemului
Tipuri de puncte de vedere
o Puncte de vedere interactor-Persoane sau alte sisteme care
interactioneaza direct cu sistemul. Exemplu: intr-un sistem ATM -
punctul de vedere ale clientului, punctul de vedere al bazei de date.
o Puncte de vedere indirecte-Partile interesate care nu utilizeaza sistemul
direct dar care influenteaza cerintele. Exemplu: intr-un sistem ATM -
punctul de vedere al managementului, punctul de vedere al personalului.
o Puncte de vedere de domeniu-Caracteristicile si constrangerile de
domeniului care influenteaza cerintele. Exemplu: intr-un sistem ATM -
standarde pentru comunicare inter-bancara
Identificarea punctelor de vedere
o Furnizorii si beneficiarii serviciilor sistem
o Sistemele care interactioneaza direct cu sistemul specificat
o Regulamente si standarde
o Sursele cerintelor economice si non-functionale
o Inginerii care trebuie sa dezvolte si sa intretina sistemul
o Marketing si alte puncte de vedere economice
Intervievare
 o In intervievare formala sau informala, echipa pentru ingineria cerintelor
pune intrebari partilor interesate referitoare la sistemul pe care il
utilizeaza si la cel care trebuie dezvoltat
o Exista doua tipuri de interviu: Interviu inchis: se cauta raspunsuri la un
set de intrebari predefinite & Interviu deschis: nu exista o agenda
predefinita si este explorat, impreuna cu partile interesate, un domeniu
al problematicii
Interviuri in practica
o Un interviu combinat (cu caracteristici de interviu inchis si deschis)
o Interviurile sunt utile pentru a intelege in general ceea ce fac partile
interesate si modul in care ar putea interactiona cu sistemul
o Interviurile nu sunt bune pentru a intelege cerintele sistem deoarece:
Inginerii de cerinte nu pot intelege terminologia specifica a domeniului &
Anumite cunostinte din domeniu sunt atat de familiare, incat persoanele
din domeniul respectiv le exprima cu dificultate in cuvinte sau considera
ca nu trebuie exprimate explicit
Intervieviatori eficienti
o Intervieviatorii trebuie sa fie cu mintea deschisa, sa doreasca sa asculte
partile interesate si sa nu aiba idei preconcepute despre cerinte
o Trebuie sa formuleze intrebari sau propuneri concrete si sa nu se astepte
pur si simplu sa li se raspunda la intrebarea ‘ce doriti ?’
Scenarii
o Def. Scenariile sunt exemple din viata reala referitoare la modul in care
sistemul poate fi utilizat; Trebuie sa includa:
o O descriere a situatiei initiale
o O descriere a fluxului normal de evenimente
o O descriere a ceea ce poate functiona gresit
o Informatii despre alte activitati concurente
o O descriere a starii la finalizarea scenariului
Cazuri de utilizare
o Cazurile de utilizare sunt tehnici UML bazate pe scenariu care: Identifica
actorii implicati intr-o interactiune & Descriu interactiunea insasi
o Un set de cazuri de utilizare ar putea descrie toate interactiunile posibile
cu sistemul
o Pentru a adauga detalii la cazurile de utilizare pot fi folosite diagrame de
secvente care sa arate secventa de procesare a evenimentului in sistem
Factori sociali si organizationali
o Sistemele software sunt utilizate intr-un context social si organizational.
Aceasta poate influenta sau chiar domina cerintele sistem
 o Factorii sociali si organizationali nu constituie un punct de vedere ci
influenteaza toate punctele de vedere
o Analistii buni trebuie sa fie sensibili la acesti factori, fara a avea insa la
dispozitie un mod sistematic de a aborda analiza
Etnografie
o Sociologii petrec un timp considerabil observand si analizand modul in
care oamenii lucreaza
o Oamenii nu trebuie sa explice sau sa formuleze in cuvinte modul in care
lucreaza
o Se pot observa factori sociali si organizationali importanti
o Studii etnografice arata ca modul de lucru este de obicei mai bogat si mai
complex decat este sugerat prin diferite modele ale sistemului
Etnografie focalizata
o Combina etnografia cu prototiparea
o Ca rezultat la dezvoltarea prototipului apar intrebari fara raspuns care
focalizeaza analiza etnografica
o Problema cu etnografia este ca aceasta studiaza practicile existente, care
pot avea unele baze istorice ce nu mai sunt relevante
Domeniul de aplicare a etnografiei
o Cerintele care sunt derivate din modul in care oamenii lucreaza in
realitate si nu din modul in care definitiile procesului sugereaza ca ar
trebui sa lucreze
o Cerintele care sunt derivate din cooperarea cu si constientizarea
activitatilor altor persoane
Validarea cerintelor
o Se ocupa cu demonstrarea faptului ca cerintele definesc sistemul pe care
clientul il doreste cu adevarat
o Costurile erorilor la nivelul cerintelor este ridicat, deci validarea este
foarte importanta
o Eliminarea unei erori la nivelul cerintelor dupa livrare ar putea ajunge la
pana de 100 de ori costul eliminarii unei erori de implementare
o Obs. Validarea se suprapune cu analiza in sensul descoperirii unor
probleme legate de cerinte
Verificarea cerintelor
o Validitate
o Consistenta
o Completitudine
o Realism
o Verificabilitate
Tehnici pentru validarea cerintelor
o Revizuiri ale cerintelor-Analiza manuala sistematica a cerintelor.
o Prototipare-Utilizarea unui model executabil al sistemului pentru a
certifica cerintele
o Generare de cazuri de testare-Dezvoltarea de teste ale cerintelor pentru
a verifica testabilitatea
o Obs. Aceste tehnici pot fi utilizate in mod conjugat sau individual
Revizuiri ale cerintelor
o Pe perioada formularii definitiilor cerintelor sunt necesare revizuiri
regulate ale acestora
o In revizuiri trebuie implicat atat personalul de la client cat si cel de la
contractor
o Revizuirile pot fi formale (cu documente complete) sau informale. O
comunicare buna intre dezvoltatori, clienti si utilizatori poate rezolva
probleme inca din stadii incipiente
Verificari la revizuire
o Verificabilitate
o Intelegere
o Posibilitate de urmarire
o Adaptabilitate
Managementul cerintelor
o Def. Managementul cerintelor este procesul de gestionare a cerintelor in
schimbare in timpul procesului de inginerie a cerintelor si a dezvoltarii
sistemului
o Cerintele sunt in mod inevitabil incomplete si inconsistente
o Cerinte noi apar in timpul procesului pe masura ce necesitatile
economice (business) se modifica si se dezvolta o mai buna intelegere a
sistemului
o Puncte de vedere diferite pot avea cerinte diferite iar acestea sunt
deseori contradictorii
Modificarea cerintelor
o Prioritatea cerintelor diferitelor puncte de vedere se modifica in timpul
procesului de dezvoltare
o Clientii sistemului pot specifica cerinte dintr-o perspectiva economica,
care pot fi in conflict cu cerintele utilizatorilor finali
o Contextul economic si tehnic se schimba in timpul dezvoltarii sistemului
Cerinte durabile si volatile
 o Cerinte durabile. Cerinte stabile derivate din activitatea de baza a
organizatiei clientului. Exemplu: un spital va avea intotdeauna doctori,
tratamente, etc. Pot fi derivate din modelele domeniului
o Cerinte volatile. Cerinte care se schimba in timpul dezvoltarii sau utilizarii
sistemului. Exemplu: Intr-un spital - cerintele derivate din politica de
asigurare a sanatatii.
Planificarea managementului cerintelor
o In timpul procesului de inginerie a cerintelor trebuie planificate:
o Identificarea cerintelor-Cum se identifica cerintele in mod individual
o Un proces de management al schimbarilor-Procesul de urmat la analiza
unei schimbari la cerinte
o Politicile de urmarire-Cantitatea de informatii pastrata referitoare la
relatiile intre cerinte
o Instrumentul CASE suport-Instrumentul suport necesar pentru a gestiona
schimbarea cerintelor
Posibilitatea de urmarire
o Posibilitatea de urmarire este legata de relatiile dintre cerinte, de sursele
lor si de proiectarea sistemului
o Posibilitatea de urmarire a sursei-Legaturi de la cerinte la partile
interesate care le-au propus
o Posibilitatea de urmarire a cerintelor-Legaturi intre cerinte dependente
o Posibilitatea de urmarire a proiectarii-Legaturi de la cerinte la artefactele
proiectarii
Instrument CASE suport
o Memorarea cerintelor-Cerintele trebuie gestionate intr-un depozit de
date sigur si manevrabil
o Managementul schimbarilor-Procesul de management al schimbarilor
este un proces de tip flux de activitati pentru care se pot defini mai multe
stadii, iar fluxul de informatii intre aceste stadii poate fi partial
automatizat
o Managementul posibilitatii de urmarire-Extragerea automata a
legaturilor dintre cerinte
Managementul schimbarii cerintelor
o Trebuie aplicat tuturor schimbarilor propuse pentru cerinte.
o Stadii principale:
o Analiza problemei. Discutarea problemei aparuta la cerinte, verificarea
validitatii ei si propunerea de schimbari;
o Analiza schimbarii si costurilor ei. Evaluarea efectelor schimbarii asupra
altor cerinte;
 o Implementarea schimbarii. Modificarea documentului cerintelor si a
altor documente pentru a reflecta schimbarea. Recomandare:
minimizarea referintelor externe si modularizarea sectiunilor
documentului.
Puncte cheie
o Procesul ingineriei cerintelor include un studiu de fezabilitate,
identificarea si analiza cerintelor, specificarea cerintelor si
managementul cerintelor
o Identificarea si analiza cerintelor este un proces iterativ care implica
intelegerea domeniului, colectarea, clasificarea, structurarea, alocarea
de prioritati si validarea cerintelor
o Sistemele au mai multe parti interesate (stakeholders), care au cerinte
diferite
o Factorii sociali si organizationali influenteaza cerintele sistemului
o Validarea cerintelor se ocupa de verificari pentru validitate, consistenta,
completitudine, realism si verificabilitate
o Schimbarile procesului economic conduc inevitabil la modificari ale
cerintelor
o Managementul cerintelor include planificarea si managementul
schimbarilor
Modele ale sistemului
o Exprima cerintele sistemului intr-un mod mai tehnic
o Specificatiile sistemului sunt documentate utilizand un set de modele
pentru sistem
o Utilizeaza reprezentari grafice care descriu: Procesul economic &
Problema ce trebuie rezolvata && Sistemul ce trebuie dezvoltat
o Punte importanta intre procesele de analiza si de proiectare
Modelarea sistemului
o Modelarea sistemului ajuta analistul in intelegerea functionalitatii
sistemului, iar modelele sunt utilizate in comunicarea cu clientii
o Diferite modele prezinta sistemul din perspective diferite: Perspectiva
externa: contextul sistemului & Perspectiva comportamentala:
comportamentul sistemului && Perspectiva structurala: arhitectura
sistemului, arhitectura datelor
Tipuri de modele
o Un model al sistemului este o abstractizare a sistemului si nu o
reprezentare a acestuia
o Abstractizarea simplifica in mod deliberat sistemul si elimina detaliile
o Tipurile de modele se bazeaza pe diferite abordari ale abstractizarii: Ex:
 o Modelul fluxului datelor (Data-flow) se concentreaza pe fluxul datelor si
pe transformarile functionale suferite de acestea, fara a intra in detalii
referitoare la structura datelor
o Modelul entitate-relatie-atribut (Entity-relationship-attribute)
documenteaza structurile datelor sistemului si nu functionalitatea
acestuia
Tipuri de modele
o Modelul procesarii datelor : modul de procesare a datelor in diferite
stadii
o Modelul compozitiei : modul in care entitatile se compun din alte entitati
o Modelul arhitectural : principalele subsisteme si relatiile intre acestea
o Modelul clasificarii : organizarea entitatilor pe baza de caracteristici
comune
o Modelul stimul/raspuns : reactia sistemului la evenimente
Modelarea contextului
o Modelele contextului sunt utilizate pentru a ilustra contextul operational
al unui sistem-modeleaza ceea ce se afla dincolo de limitele/marginile
(boundaries) sistemului
o Decizia referitoare la plasarea marginilor sistemului poate fi afectata de
consideratii sociale si organizationale
o Modelele arhitecturale descriu sistemul si relatiile sale cu alte sisteme
Modelarea procesului
o Modelele procesului reprezinta procesul de ansamblu si procesele care
sunt suportate de sistem
o Se pot utiliza modele ale fluxului de date pentru a ilustra procesele si
fluxul de informatii de la un proces la altul
Modelarea comportamentului
o Modelele comportamentale sunt utilizate pentru a descrie
comportamentul general al sistemului
o Tipuri de modele comportamentale: Model al procesarii datelor-arata
modul de procesare a datelor pe masura ce acestea se deplaseaza prin
sistem & Model al masinii cu stari (state machine) – arata raspunsul
sistemului la evenimente
o Ambele modele sunt necesare pentru a descrie comportamentul
sistemului, deoarece ele arata sistemul din perspective diferite
Modelarea procesarii datelor
o Diagramele fluxurilor de date (data flow diagrams - DFDs) pot fi utilizate
pentru a modela procesarea datelor in sistem
o Acestea ilustreaza pasii procesarii sub forma de fluxuri de date in sistem
 o DFDs sunt componenta intrinseca a multor metode de analiza
o Sunt realizate cu notatii simple si intuitive, pe care clientii le pot intelege
usor
o Ilustreaza procesarea datelor end-to-end
Diagramele fluxurilor de date
o DFDs modeleaza sistemul din perspectiva functionala
o Urmarirea si documentarea datelor asociate unui proces este utila in
dezvoltarea intelegerii sistemului in ansamblu
o Diagramele fluxurilor de date pot fi utilizate si in ilustrarea schimbului de
date intre sistem si alte sisteme din contextul sau
Modelarea starilor si tranzitiilor (state machine)
o Se modeleaza comportamentul sistemului ca raspuns la evenimentele
externe si interne
o Modelele ilustreaza raspunsurile sistemului la stimuli, de aceea sunt
utilizate in special pentru modelarea sistemelor de timp real
o Modelele de stare si tranzitii sunt reprezentari de tip graf in care starile
sistemului sunt plasate in noduri iar evenimentele pe arce. La aparitia
unui eveniment sistemul face o tranzitie dintr-o stare in alta
o Diagrama de stare (statechart) este parte integrala a UML 1.4, fiind
utilizata pentru modelarea starilor si tranzitiilor in sistem
Statechart
o Permite descompunerea modelului in sub-modele
o Include o scurta descriere a actiunilor in forma do: descriere_actiune
o Poate fi completata cu tabele in care sunt descrise starile si stimulii
Structurarea modelelor de stari
o Necesara in modelele sistemelor mari, cu un numar mare de stari
posibile
o Super-stare
o Notiune ce incapsuleaza un numar de stari separate
o Reprezentata ca o singura stare intr-un model de nivel mai inalt
o Este expandata (detaliata) intr-o diagrama separata
o Ex. Super-starea “Operation” din diagrama anterioara
State machine diagram (SMD)
o In UML 2.0
o Descrie un comportament sau o trasatura comportamentala.
o Componente: Stari, Tranzitii intre stari, Declansatoare (triggers) pentru
tranzitii, Activitati realizate in cursul executiei tranzitiilor, Activitati
realizate pe durata fiecarei stari
o Stare-poate avea una sau mai multe regiuni
 o Regiune-set independent de stari si tranzitii
o Suport pentru concurenta
o Submasina cu stari – masina cu stari reutilizabila (Are referinte la puncte
de conectare care reprezinta canale de intrare si de iesire)
o SMDs pot fi organizate in ierarhii de tip generalizare/specializare
o Stare-descrie conditia unui obiect in termeni de: Atribute ale obiectului &
Comportamentul in care este angajat
o Formal: o stare modeleaza o perioada de timp in care se mentine
adevarata o conditie de invarianta
o Exemple de conditii de invarianta: Set de valori ale atributelor, Conditia
de a lucra la o activitate, Conditia de a astepta un eveniment
o Tipuri de stari: Simpla-nu contine alte stari & Compusa-contine una sau
mai multe masini cu stari, in regiuni separate && Submasina – contine o
submasina (specificatia punctelor de intrare si de iesire)
Modele semantice ale datelor
o Utilizate pentru a descrie structura logica a datelor procesate de sistem
o Un model entitate-relatie-atribut (ERA) reprezinta entitatile din sistem,
relatiile intre entitati si atributele entitatilor
o Modelul ERA este larg folosit in proiectarea bazelor de date. Poate fi
implementat utilizand baze de date relationale
o Nu exisa o notatie specifica oferita de UML. Se pot utiliza obiecte si
asocieri
Dictionare de date
o Dictionarele de date sunt liste cu toate numele utilizate in modelele
sistemului. Sunt incluse, de asemenea, descrieri ale entitatilor, relatiilor
si atributelor
o Avantaje: Ofera suport pentru gestionarea numelor si evitarea
duplicatelor & Pastreaza cunostinte organizationale care leaga analiza,
proiectarea si implementarea
o Multe CASE workbenches ofera suport pentru utilizarea de dictionare de
date
Orientare obiect
o Abordare a intregului proces de dezvoltare, adica:
o Exprimarea cerintelor sistemului utilizand un model obiectual;
reprezentarea OO atat a datelor cat si a procesarilor din sistem
o Proiectare utilizand obiecte
o Dezvoltarea sistemului intr-un limbaj de programare OO
Modele obiectuale
 o Modelele obiectuale descriu sistemul in termeni de clase de obiecte si
asocieri intre acestea
o O clasa de obiecte este o abstractizare referitoare la un set de obiecte,
continand atributele comune si serviciile (operatiile) oferite de fiecare
obiect
o Se pot realiza diferite modele obiect: Modele pentru mostenire, Modele
pentru agregare, Modele pentru interactiuni
o Sunt moduri naturale de reflectare a entitatilor din lumea reala
manipulate de sistem
o Entitati mai abstracte sunt mai dificil de modelat utilizand aceasta
abordare
o Identificarea claselor de obiecte este recunoscuta ca un proces dificil
care necesita o foarte buna intelegere a domeniului aplicatiei
o Clasele de obiecte ce reflecta entitatile domeniului sunt reutilizabile intre
sisteme
Modele pentru mostenire
o Organizeaza clasele de obiecte ale domeniului sub forma unei ierarhii
o Clasele din varful ierarhiei reflecta caracteristicile comune tuturor
claselor
o Clasele de obiecte mostenesc atributele si serviciile de la una sau mai
multe superclase; ele pot fi la rindul lor specializate functie de necesitati
o Proiectarea ierarhiei de clase poate fi un proces dificil daca se doreste
evitarea duplicarii in diferite ramuri ale ierarhiei
Modele obiectuale si UML
o UML este o reprezentare standard realizata de dezvoltatorii metodelor
de analiza si proiectare larg utilizate
o A devenit un standard eficient pentru modelarea OO (orientata obiect)
o Notatie:
o Clasele de obiecte sunt dreptunghiuri cu trei compartimente: nume,
atribute, operatii
o Relatiile dintre clasele de obiecte (numite si asocieri) sunt reprezentate
prin linii care leaga obiectele
o Mostenirea este referita ca generalizare si este reprezentata ascendent
in ierarhie
Mostenire multipla
o In loc de a mosteni atribute si servicii de la o singura clasa parinte, un
sistem ce suporta mostenire multipla permite claselor de obiecte sa
mosteneasca din mai multe superclase
 o Aceasta poate conduce la conflicte semantice in cazul in care atribute
si/sau servicii cu acelasi nume din diferite superclase au semantici
diferite
o Mostenirea multipla complica reorganizarea ierarhiei de clase
Agregarea obiectelor
o Un model de agregare arata cum clasele care sunt colectii sunt compuse
din alte clase
o Modelele de agregare sunt similare cu relatia “part-of” din modelele
semantice ale datelor
Modelarea comportamentului obiectelor
o Un model comportamental ilustreaza interactiunile dintre obiecte care
produc un anumit comportament al sistemului specificat ca un caz de
utilizare (use-case)
o Diagramele de secvente, diagramele de comunicare, diagramele de
interactiune (interaction overview) si diagramele de timp din UML 2.0
sunt utilizate pentru a modela interactiunile dintre obiecte
Metode structurate
o Metodele structurate incorporeaza modelarea sistemului ca o parte
inerenta a metodei
o Metodele definesc un set de modele, un proces pentru realizarea
acestor modele, reguli care trebuie aplicate modelelor si indrumari de
realizare a lor
o Instrumentele CASE ofera suport pentru modelarea sistemului ca parte a
unei metode structurate
Slabiciunile metodelor
o Nu modeleaza cerintele non-functionale ale sistemului
o De obicei nu includ informatii care sa specifice daca o anumita metoda
este potrivita pentru o problema data
o Pot produce prea multa documentatie
o Modelele sistemului sunt uneori prea detaliate si dificil de inteles de
catre utilizatori
CASE workbench-uri
o Un set coerent de instrumente destinat sa ofere suport pentru activitati
corelate ale procesului software, cum ar fi analiza, proiectare sau testare
o Workbench-urile pentru analiza si proiectare ofera suport pentru
modelarea sistemului atat in timpul procesului de inginerie a cerintelor
cat si in timpul celui de proiectare a sistemului
 o Aceste workbench-uri pot oferi suport pentru o metoda de proiectare
specifica sau pentru crearea mai multor tipuri diferite de modele ale
sistemului
Componente ale workbench-ului pentru analiza si proiectare
o Editoare de diagrame: Creare modele pentru obiecte, date si
comportament & Sunt, de asemenea, constiente de tipurile entitatilor
din sistem
o Instrumente pentru analiza si verificarea modelului-Proceseaza
artefactele proiectarii si raporteaza erorile si anomaliile
o Repozitoriu si limbajul de interogare asociat-Memorare/gasire artefacte
ale proiectarii si informatii asociate, in repozitoriul central
o Dictionarul datelor
o Instrumente pentru definirea si generarea de rapoarte-Genereaza
automat documentatia sistemului utilizand informatiile din repozitoriul
central
o Instrumente pentru definirea de forme-Specificare de formate pentru
ecran si pentru documente
o Traducatoare pentru import/export-Schimbul de informatii intre
repozitoriul central si alte instrumente de dezvoltare
o Instrumente pentru generare cod-Genereaza automat cod sau schelet
(skeleton) de cod utilizand artefactele proiectarii pastrate in repozitoriul
central
Puncte cheie
o Un model este o vedere abstracta asupra sistemului. Tipuri
complementare de modele ofera diferite informatii despre sistem
o Modelele pentru context arata pozitia unui sistem in contextul sau cu
alte sisteme si procese
o Modelele pentru fluxul de date pot fi utilizate pentru a modela
procesarea datelor intr-un sistem
o Modelele pentru stari si tranzitii modeleaza comportamentul sistemului
ca raspuns la evenimente interne sau externe
o Modelele semantice pentru date descriu structura logica a datelor care
sunt importate sau exportate de sistem
o Modelele obiectuale descriu entitatile logice ale sistemului, clasificarea si
agregarea lor
o Modelele pentru interactiuni arata interactiunile dintre actori si
obiectele sistemului pe care le utilizeaza
o Metodele structurate ofera un cadru (framework) pentru dezvoltarea de
modele ale sistemului
Arhitectura software
o Def. Proiectarea arhitecturala este procesul de proiectare pentru
identificarea subsistemelor ce compun un sistem si a cadrului pentru
control si comunicare intre subsisteme
o Iesirea acestui proces de proiectare este o descriere a arhitecturii
software
Proiectarea arhitecturala
o Etapa timpurie in procesul de proiectare a sistemului
o Reprezinta legatura dintre procesul de specificare si cel de proiectare
o Deseori realizata in paralel cu unele activitati de specificare
o Implica identificarea componentelor majore ale sistemului si a
comunicarii dintre acestea
Avantajele arhitecturii explicite
o Comunicarea cu partile interesate-Arhitectura poate fi utilizata ca
element central al discutiei de catre partile interesate in sistem
o Analiza sistemului-Face posibila analiza faptului ca sistemul isi poate
atinge obiectivele non-functionale
o Reutilizare pe scara larga-Arhitectura se poate reutiliza pentru o gama
larga de sisteme
Arhitectura si caracteristicile sistemului
o Performanta-Localizarea operatiilor critice si minimizarea comunicarii.
Utilizare de componente cu granularitate mare (large-grain rather than
fine-grain)
o Securitate-Utilizarea unei arhitecturi multi-nivel cu componentele critice
plasate in nivelele interioare
o Siguranta-Izolarea, intr-un numar mic de subsisteme, a caracteristicilor
critice din punct de vedere al sigurantei
o Disponibilitate-Includerea de componente redundante si de mecanisme
pentru toleranta la defecte
o Mentenabilitate-Utilizare de componente cu granularitate mica,
inlocuibile
Conflicte arhitecturale
o Utilizarea de componente cu granularitate mare imbunatateste
performanta dar reduce mentenabilitatea
o Introducerea de date redundante imbunatateste disponibilitatea dar
complica asigurarea securitatii
o Localizarea caracteristicilor legate de siguranta inseamna de obicei mai
multa comunicare si deci degradarea performantei
Structurarea sistemului
 o Descompunerea sistemului in subsisteme care interactioneaza
o Proiectul arhitectural este exprimat, in mod normal, ca diagrama bloc ce
prezinta o imagine de ansamblu asupra structurii sistemului
o Se pot dezvolta, de asemenea, modele mai specifice care prezinta modul
in care subsistemele partajeaza date, sunt distribuite si se interfateaza
Diagrame bloc
o Notatii: casete si linii
o Foarte abstracte-nu ilustreaza natura relatiilor intre componente si nici
proprietatile vizibile din exterior ale subsistemelor
o Totusi, utile pentru comunicarea cu partile interesate si pentru
planificarea proiectului
Decizii in proiectarea arhitecturala
o Proiectarea arhitecturala este un proces creativ, deci difera functie de
tipul sistemului ce este dezvoltat
o Totusi, exista o serie de decizii comune tuturor proceselor de proiectare
arhitecturala
Reutilizarea arhitecturii
o Sistemele din acelasi domeniu au deseori arhitecturi similare care
reflecta conceptele domeniului
o Liniile de productie de aplicatii sunt construite in jurul unei arhitecturi
nucleu cu variante care satisfac cerintele clientilor particulari
Stiluri arhitecturale
o Modelul arhitectural al unui sistem se poate conforma unui model
arhitectural generic (stil arhitectural)
o Cunoasterea acestor stiluri poate simplifica problema definirii
arhitecturilor sistemelor
o Totusi, majoritatea sistemelor mari sunt eterogene si nu urmeaza un
singur stil arhitectural
Modele arhitecturale
o Utilizate pentru a documenta un proiect arhitectural
o Modelul structural static care ilustreaza componentele majore ale
sistemului
o Modelul dinamic al procesului care ilustreaza structura de procesare a
unui sistem
o Modelul interfetelor care defineste interfetele sub-sistemelor
o Modelul relatiilor, cum ar fi modelul fluxului datelor, care ilustreaza
relatiile intre sub-sisteme.
o Modelul distribuirii care ilustreaza modul in care subsistemele sunt
distribuite pe calculatoare
Organizarea sistemului
o Reflecta strategia de baza care este utilizata pentru a structura sistemul
o Trei stiluri organizationale sunt larg utilizate: Stilul repozitoriu de date &
Stilul servicii si servere partajate (client-server) && Stilul masina
abstracta (sau multi-nivel)
Modelul repozitoriu
o Subsistemele trebuie sa schimbe date. Acest lucru se poate realiza in
doua moduri: Datele partajate sunt pastrate intr-o baza de date centrala
(repozitoriu) si pot fi accesate de catre toate subsistemele & Fiecare
subsistem pastreaza o baza de date proprie si transfera date in mod
explicit catre alte subsisteme
o Modelul repozitoriu este folosit in majoritatea cazurilor in care trebuie
partajate cantitati mari de date
Caracteristicile modelului repozitoriu
o Avantaje: Mod eficient de a partaja cantitati mari de date &
Subsistemele nu trebuie sa fie preocupate de modul in care sunt produse
datele si beneficiaza de management centralizat (ex. backup, security,
etc) && Modelul de partajare este publicat sub forma de schema a
repozitoriului
o Dezavantaje: Subsistemele trebuie sa realizeze un acord asupra
modelului datelor din repozitoriu. Acesta se stabileste in mod inevitabil
pe baza unui compromis & Evolutia datelor este dificila si costisitoare &&
Nu se pot defini domenii cu politici de management specifice &&& Sunt
dificil de realizat distribuiri eficiente
Modelul client-server
o Model de sistem distribuit care ilustreaza modul in care datele si
procesarile sunt distribuite pe un set de componente
o Set de servere de sine statatoare (stand-alone) care ofera servicii
specifice cum ar fi imprimare, management date, etc
o Set de clienti care apeleaza aceste servicii
o Retea ce permite clientilor sa acceseze server-ele
Caracteristicile modelului client-server
o Avantaje: Distribuirea datelor este evidenta & Utilizeaza in mod eficient
sistemele de retea. Pot necesita hardware mai ieftin && Simplu de
adaugat servere noi sau de actualizat (upgrade) serverele existente
o Dezavantaje: Nu exista un model partajat al datelor deci sub-sistemele
utilizeaza diferite organizari ale datelor. Schimbul de date poate fi
ineficient & Management redundant in fiecare server && Nu exista un
 registru central de nume si servicii – gasirea serverelor si a serviciilor
poate fi dificila
Modelul masina abstracta (multi-nivel)
o Utilizat pentru a modela interfatarea sub-sistemelor
o Organizeaza sistemul intr-un set de nivele (sau masini abstracte), fiecare
nivel oferind un set de servicii
o Suporta dezvoltarea incrementala a sub-sistemelor de pe nivele diferite.
Cand se schimba interfata unui nivel, doar nivelele adiacente sunt
afectate
o Totusi, structurarea sistemelor in acest mod este deseori artificiala
Stiluri de descompunere modulara
o Stiluri de descompunere a sub-sistemelor in module
o Nu exista o diferenta rigida intre organizarea sistemului si
descompunerea modulara
Sub-sisteme si module
o Un sub-sistem opereaza de sine statator, independent de servicile oferite
de alte sub-sisteme
o Un modul este o componenta a sistemului care ofera servicii altor
componente dar care in mod normal nu e considerata sistem separat
Descompunere modulara
o Un alt nivel structural, unde sub-sistemele sunt descompuse in module
o Tratam doua modele de descompunere modulara: Un model obiect in
care sistemul este descompus in obiecte care interactioneza & Un model
banda de asamblare (pipeline) sau flux de date (data-flow) in care
sistemul este descompus in module functionale care transforma intrarile
in iesiri
o Pe cat posibil, deciziile referitoare la concurenta trebuie amanate pana la
implementarea modulelor
Modele obiect
o Structureaza sistemul intr-un set de obiecte slab cuplate cu interfete
bine definite
o Descompunerea orientata obiect se ocupa cu identificarea claselor de
obiecte, a atributelor si a operatiilor acestora
o La implementare, sunt create atat obiecte din aceste clase cat si un
model de control utilizat pentru a coordona operatiile pe obiecte
Avantajele modelului obiect
o Obiectele sunt slab cuplate, deci implementarea lor poate fi modificata
fara a afecta alte obiecte
o Obiectele pot reflecta entitati din lumea reala
 o Limbajele OO sunt larg utilizate
o Totusi: Schimbarile la nivelul interfetelor obiectelor pot cauza probleme
& Entitati complexe ar putea fi greu de reprezentat sub forma de obiecte
Banda de asamblare orientata pe functii
o Transformarile functionale proceseaza intrarile pentru a produce iesiri
o Pot fi referite ca model “pipe and filter” (ca in UNIX shell)
o Variante ale acestei abordari sunt foarte raspandite. Cand transformarile
sunt secventiale avem de-a face cu un model secvential in loturi de
lucrari (batch sequential model) care este intens utilizat in sistemele de
procesare a datelor
o Nu sunt foarte potrivite pentru sistemele interactive
Avantajele modelului banda de asamblare
o Suporta reutilizarea transformarilor
o Organizare intuitiva pentru comunicarea cu partile interesate
o Simplu de adaugat noi transformari
o Relativ simplu de implementat fie ca sistem concurent fie ca sistem
secvential
o Totusi: Necesita un format comun pentru transferul datelor de-a lungul
benzii de asemblare & Suporta cu dificultate interactiunile bazate pe
evenimente
Stiluri de control
o Sunt destinate fluxului de control intre sub-sisteme. Difera de modelul de
descompunere a sistemului
o Control centralizat->Un sub-sistem are responsabilitatea de a controla,
porni si opri alte sub-sisteme
o Control bazat pe evenimente->Fiecare sub-sistem poate raspunde la
evenimente externe generate de alte sub-sisteme sau de contextul
sistemului
Control centralizat
o Un sub-sistem de control preia responsibilitatea gestionarii executiei
altor sub-sisteme
o Modelul “Call-return”->Model subrutina “top-down” in care controlul
porneste de la varful unei ierarhii de subrutine si parcurge ierarhia pana
la baza. Aplicabil sistemelor secventiale
o Modelul manager->Aplicabil sistemelor concurente. O componenta a
sistemului controleaza pornirea, oprirea si coordonarea proceselor altor
sisteme. Poate fi implementat in sistemele secventiale folosind
instructiunea “case”
Sisteme conduse de evenimente (event-driven)
 o Conduse de evenimente generate extern, pentru care temporizarea
evenimentului este in afara controlului sub-sistemelor care proceseaza
evenimentul.
o Doua modele principale pentru sistemele conduse de evenimente:
Model cu difuzare (broadcast). Un eveniment este difuzat tuturor sub-
sistemelor. Orice sub-sistem capabil sa trateze evenimentul o poate face
& Model condus de intreruperi (interrupt-driven). Utilizat in sistemele de
timp real, unde intreruperile sunt detectate de un handler de intreruperi
si transferate altor componente spre procesare
o Alte modele pentru sistemele conduse de evenimente includ
spreadsheets si sistemele de productie
Modelul cu difuzare (broadcast)
o Eficient la integrarea sub-sistemelor de pe calculatoare diferite dintr-o
retea
o Sub-sistemele isi inregistreaza interesul pentru anumite evenimente.
Cand acestea se produc, controlul este transferat catre sub-sistemele
inregistrate la evenimentul respectiv, care il pot astfel trata
o Politica de control nu este incapsulata in eveniment sau in rutina de
tratare (handler) mesaj. Sub-sistemele sunt cele care decid asupra
evenimentelor de interes pentru ele
o Totusi, sub-sistemele nu cunosc cand si daca un eveniment va fi tratat
Sisteme conduse de intreruperi
o Utilizate in sistemele de timp real, acolo unde este esential ca unui
eveniment sa i se raspunda “la timp”
o In sistem exista un set de tipuri cunoscute de intreruperi si rutine de
tratare (handler) definite pentru fiecare tip
o Fiecare tip este asociat cu o locatie de memorie si un comutator
hardware care realizeaza transferul la rutina corespunzatoare de tratare
o Permit raspuns rapid dar sunt complicat de programat si dificil de validat
Arhitecturi de referinta
o Modelele arhitecturale pot fi specifice unor domenii de aplicatii
o Doua tipuri de modele specifice domeniului: Modele generice:
abstractizeaza mai multe sisteme reale si incapsuleaza caracteristicile
principale ale acestor sisteme & Modele de referinta: sunt modele mai
abstracte, idealizate. Ofera o modalitate de informare despre clasa
sistemului si de comparare intre arhitecturi diferite
o Modelele generice sunt de obicei modele “bottom-up”; Modelele de
referinta sunt modele “top-down”
 o Modelele de referinta sunt derivate din studierea domeniului aplicatiei si
nu din sistemele existente
o Se pot utiliza ca baza pentru implementarea sistemului sau pentru a
compara diferite sisteme. Actioneaza ca standard fata de care sistemele
pot fi evaluate
o Modelul OSI este un model multi-nivel pentru sistemele de comunicare
Modelul de referinta CASE
o Servicii repositoriu de date->Memorare si management date
o Servicii pentru integrare date->Gestionarea grupurilor de entitati
o Servicii pentru management sarcini (tasks)->Definirea si punerea in
scena a modelelor de procese
o Servicii de mesagerie->Comunicare instrument-instrument si instrument-
context
o Servicii de interfata utilizator->Dezvoltarea interfetei utilizator
Puncte cheie
o Arhitectura software este cadrul (framework) fundamental pentru
structurarea sistemului
o Deciziile proiectarii arhitecturale includ decizii referitoare la arhitectura
aplicatiei, la distribuire si la stilurile arhitecturale ce vor fi utilizate
o Se pot dezvolta modele arhitecturale diferite, cum ar fi un model
structural, un model al controlului si un model al descompunerii
sistemului in sub-sisteme
o Modelele organizationale ale sistemelor includ modele repozitoriu,
modele client-server si modele masina abstracta
o Modelele pentru descompunere modulara includ modele obiect si
modele banda de asamblare
o Modelele controlului includ modele de control centralizat si modele de
control condus de evenimente
o Pentru a comunica arhitecturi specifice domeniului si pentru a evalua si
compara proiecte arhitecturale se pot utiliza arhitecturi de referinta
Arhitecturi generice pentru aplicatii
o Sistemele de aplicatie sunt destinate rezolvarii unei necesitati
organizationale
o Sistemele de aplicatii pentru activitati economice care au multe
elemente comune tind sa aiba arhitecturi comune care reflecta cerintele
aplicatiei
o O arhitectura generica este configurata si adaptata pentru a crea un
sistem care raspunde unor cerinte specifice
Utilizarea arhitecturilor pentru aplicatii
 o Ca punct de pornire pentru proiectarea arhitecturala
o Ca element de verificare in cursul proiectarii
o Ca modalitate de de organizare a activitatii echipei de dezvoltare
o Ca mod de evaluare a componentelor in vederea reutilizarii
o Ca vocabular pentru discutiile referitoare la tipuri de aplicatii
Tipuri de aplicatii
o Aplicatii de procesare date->Aplicatiile conduse de date care proceseaza
date in loturi de date fara interventia explicita a utilizatorului in cursul
procesarii
o Aplicatii de procesare tranzactii->Aplicatii centrate pe date care
proceseaza cererile utilizatorului si actualizeaza informatiile dintr-o baza
de date a sistemului
o Sisteme de procesare evenimente->Aplicatii in care actiunile sistemului
depind de interpretarea evenimentelor venite din contextul sistemului
o Sisteme de procesare limbaje->Aplicatii in care intentiile utilizatorului
sunt specificate intr-un limbaj formal care este procesat si interpretat de
sistem
Exemple de aplicatii
o Procesare date: Aplicatii pentru facturare & Aplicatii pentru state de
plata
o Procesare tranzactii: Aplicatii e-commerce & Aplicatii pentru rezervari
o Procesare evenimente: Procesoare de texte & Aplicatii de timp real
o Procesare limbaje: Compilatoare & Interpretoare de comenzi
Sisteme de procesare date
o Sisteme care sunt centrate pe date si in care bazele de date utilizate sunt
de cateva ordine de marime mai mari decat software-ul propriu-zis
o Datele intra si ies in loturi. Exemplu: Intrari: Un set de coduri client si
citirile de la un contor de energie electrica asociate & Iesiri: Un set
corespunzator de facturi, cate una pentru fiecare client
o Sistemele de procesare date au de obicei o structura de tip intrare-
proces-iesire
Intrare-proces-iesire
o Componenta intrare citeste date dintr-un fisier sau dintr-o baza de date,
verifica validitatea acestora si pune datele valide intr-o lista de asteptare
in vederea procesarii
o Componenta proces ia o tranzactie din lista de asteptare, executa
calculele si creaza o noua inregistrare cu rezultatele acestora
o Componenta iesire citeste aceste inregistrari, le formateaza
corespunzator si le scrie in baza de date sau le trimite la o imprimanta
Diagrame ale fluxurilor de date
o Arata cum sunt procesate datele pe masura ce ele se deplaseaza in
cadrul unui sistem
o Transformarile sunt reprezentate ca dreptunghiuri cu colturile rotunjite,
fluxurile de date ca sageti intre acestea si fisierele/depozitele de date ca
dreptunghiuri
Sisteme de procesare tranzactii
o Proceseaza cererile utilizatorului pentru extragerea de informatii dintr-o
baza de date sau pentru actualizarea bazei de date
o Din perspectiva utilizatorului o tranzactie este: Orice secveta coerenta de
operatii care satisface un scop.
o Exemplu -> cautarea programului zborurilor de la Londra la Paris
o Utilizatorii fac cereri asincrone pentru servicii care sunt apoi procesate
de un manager de tranzactii
Middleware de procesare tranzactii
o Middleware-ul de management tranzactii sau monitoarele de
teleprocesare gestioneaza comunicarea cu diferite tipuri de terminale
(ex. ATMs si terminale pentru numarare), serializeaza datele si le
transmit spre procesare
o Procesarea interogarii are loc in baza de date a sistemului iar rezultatele
sunt trimise inapoi, prin intermediul managerului de tranzactii, la
terminalul utilizatorului
Arhitectura sistemelor informationale
o Sistemele informationale au o arhitectura generica care poate fi
organizata pe modelul multi-nivel
o Nivelele includ: Interfata utilizator & Comunicarea cu utilizatorul &&
Extragerea de informatii &&& Baza de date a sistemului
Sistemele de alocare resurse
o Sisteme care gestioneaza o cantitate fixa dintr-o anumita resursa (ex.
bilete la meciuri de fotbal, carti intr-o librarie, etc.) si o aloca utilizatorilor
o Exemple de sisteme de alocare resurse: Sisteme de programari, in care
resursa alocata este o perioada de timp & Sisteme pentru biblioteci, in
care resursa gestionata sunt cartile si alte lucruri ce pot fi imprumutate
&& Sisteme pentru controlul traficului aerian, in care resursa alocata
este spatiul aerian
Arhitectura pentru alocare resurse(sisteme multi-levet), includ:
o O baza de date a resurselor
o Un set de reguli de alocare a resurselor
o Un manager de resurse
 o Un alocator de resurse
o Autentificarea utilizatorului
o Managementul interogarilor
o Componenta de livrare a resurselor
o Interfata utilizator
Implementarea sistemului multi-nivel
o Fiecare nivel poate fi implementat ca o componenta pe scara larga care
se executa pe un server separat. Acesta este modelul arhitectural cel mai
utilizat pentru sistemele bazate Web
o Pe o singura masina, nivelele intermediare sunt implementate ca un
program separat care comunica cu baza de date prin intermediul API-lui
acesteia
o Componentele cu granularitate fina din interiorul nivelelor pot fi
implementate ca servicii Web
Arhitectura de sistem pentru comert electronic (e-commerce)
o Sistemele pentru comert electronic sunt sisteme bazate Internet pentru
management de resurse, care accepta ordine electronice pentru bunuri
sau servicii
o De obicei sunt organizate utilizand o arhitectura pe mai multe straturi
(multi-tier) cu nivele ale aplicatiei asociate fiecarui strat
Sisteme de procesare evenimente
o Aceste sisteme raspund la evenimente produse in contextul sistemului
o Caracteristica cheie este ca momentul aparitiei evenimentului este
nepredictibil, astfel incat arhitectura trebuie organizata astfel incat sa
poata gestiona aceasta problema
o Multe sisteme comune, cum ar fi procesoarele de texte sau jocurile, sunt
sisteme de procesare evenimente
Sisteme de editare
o Sistemele de timp real si sistemele de editare sunt cele mai cunoscute
tipuri de sisteme de procesare evenimente
o Caracteristicile sistemelor de editare: Sisteme mono-utilizator & Trebuie
sa ofere raspuns rapid la actiunile utilizatorului && Organizate in jurul
unor tranzactii lungi, astfel incat trebuie sa includa facilitati de
recuperare si refacere
Componentele sistemelor de editare
o Sistemele de editare sunt in mod natural orientate obiect, incluzand
urmatoarele tipuri de obiecte:
o Ecran -> monitorizeaza memoria ecran si detecteaza evenimente
o Eveniment -> recunoaste evenimentele si le transfera spre procesare
 o Comanda -> executa o comanda utilizator
o Date editor -> gestioneaza structura de date a editorului
o Date auxiliare -> gestioneaza alte date cum ar fi stiluri si preferinte;
o Sistem de fisiere -> gestioneaza transferurile cu fisierele
o Afisare -> actualizeaza continutul ecranului
Sisteme de procesare limbaje
o Accepta un limbaj natural sau artificial ca intrare si genereaza o alta
reprezentare a acestui limbaj
o Poate include un interpretor pentru a actiona asupra instructiunilor
limbajului care sunt procesate
o Utilizat in situatiile in care cel mai simplu mod de a rezolva o problema
este de a descrie algoritmul sau datele din sistem
o Instrumentele meta-CASE proceseaza descrierile instrumentelor, regulile
metodelor, etc. si genereaza instrumente CASE
Componentele sistemului de procesare limbaj
o Analizor lexical
o Tabela de simboli
o Analizor sintactic
o Arborele sintaxei
o Analizor semantic
o Generator de cod
Puncte cheie
o Modelele generice pentru arhitecturile de aplicatii ne ajuta sa intelegem
si sa comparam aplicatii
o Clasele importante de aplicatii sunt: sistem de procesare date, sistem de
procesare tranzactii, sistem de procesare evenimente si sistem de
procesare limbaj
o Sistemele de procesare date opereaza in loturi si au o structura de tip
intrare-proces-iesire
o Sistemele de procesare tranzactii permit accesarea si modificarea de la
distanta, de catre utilizatori multipli, a informatiilor dintr-o baza de date
o Sistemele de procesare evenimente includ editoare si sisteme de timp
real
o Intr-un editor sunt detectate evenimentele de la interfata cu utilizatorul,
iar o structura de date interna este modificata corespunzator
o Sistemele de procesare limbaje traduc textele dintr-un limbaj in altul si
pot interpreta instructiunile specificate
Dezvoltare orientata obiect
 o Analiza, proiectarea si programarea orientate obiect sunt corelate dar
distincte
o Analiza (OOA) se ocupa cu dezvoltarea unui model obiectual al
domeniului aplicatiei
o Proiectarea (OOD) se ocupa cu dezvoltarea unui model orientat obiect al
sistemului care sa implementeze cerintele
o Programarea (OOP) se ocupa cu realizarea unui OOD utilizand un limbaj
de programare OO cum ar fi Java sau C++
Caracteristicile proiectarii OO
o Obiectele sunt abstractizari ale entitatilor lumii reale sau ale entitatilor
sistemului si se autogestioneaza
o Obiectele sunt independente si incapsuleaza informatii de stare si de
reprezentare
o Functionalitatea sistemului este exprimata in termeni de servicii oferite
de obiecte
o Obiectele comunica prin transfer de mesaje si nu prin date partajate
o Obiectele se pot distribui si se pot executa secvential sau paralel
Avantajele proiectarii OO
o Intretinere mai usoara. Obiectele pot fi intelese ca entitati de sine
statatoare
o Obiectele sunt componente potential reutilizabile
o In unele sisteme exista o corespondenta evidenta intre entitatile lumii
reale si obiectele sistemului
Obiecte si clase de obiecte
o Obiectele sunt entitati intr-un sistem software care reprezinta instante
ale entitatilor din lumea reala sau din sistem
o Clasele de obiecte sunt tipare (templates) pentru obiecte. Ele sunt
utilizate pentru a crea obiecte
o Clasele de obiecte pot mosteni atribute si servicii de la alte clase de
obiecte
Obiecte si clase de obiecte
o Un obiect este o entitate care are o stare si un set definit de operatii ce
opereaza asupra starii. Starea este reprezentata sub forma unui set de
atribute ale obiectului. Operatiile asociate cu obiectul ofera servicii altor
obiect (clienti) care solicita aceste servicii atunci cand necesita un calcul
o Obiectele sunt create conform unor definitii de clase de obiecte. O
definitie de clasa de obiecte serveste ca tipar pentru un tip de obiecte. Ea
include declaratii pentru toate atributele si pentru toate serviciile ce
trebuie asociate unui obiect din acea clasa
UML (Unified Modeling Language)
o In anii 1980 si 1990 au fost propuse mai multe notatii diferite pentru
descrierea proiectelor orientate obiect.
o UML este o integrare a acestor notatii
o UML descrie notatii pentru mai multe modele diferite ce pot fi produse
in cursul proceselor de analiza si proiectare OO
o UML este standardul de facto pentru modelarea OO
Comunicarea intre obiecte
o Conceptual, obiectele comunica prin transfer de mesaje
o Mesajul contine: Numele serviciului solicitat de obiectul apelant & Copii
ale informatiilor necesare pentru executarea serviciului si numele unui
element in care se pastreaza rezultatul serviciului
o In practica, mesajele sunt deseori implementate prin apeluri de
procedura: Nume = nume procedura & Informatii = lista de parametri
Exemple de mesaje
o Apelul unei metode asociata cu un obiect “buffer” care returneaza
urmatoarea valoare din “buffer”: v = circularBuffer.Get () ;
o Apelul unei metode asociata cu un obiect “termostat” care seteaza
temperatura ce trebuie mentinuta constanta: thermostat.setTemp (20) ;
Generalizare si mostenire
o Obiectele sunt membri ai claselor, care definesc tipuri de atribute si
operatii
o Clasele pot fi organizate in ierarhii de clase, in care o clasa (super-clasa)
este o generalizare a uneia sau mai multor clase (sub-clase)
o O sub-clasa mosteneste atribute si operatii de la super-clasa sa si poate
adauga metode si operatii proprii
o Generalizarea din UML este implementata ca mostenire in limbajele de
programare OO
Avantajele mostenirii
o Este un mecanism de abstractizare care poate fi utilizat pentru a clasifica
entitati
o Este un mecanism de reutilizare atat la nivel de proiectare cat si la nivel
de programare
o Graful mostenirii este o sursa de cunostinte despre organizarea
domeniului si a sistemului
Problematica mostenirii
o Clasele de obiecte nu sunt auto-continute; nu pot fi intelese fara a se
face referire la super-clasele lor
 o Proiectantii au tendinta de a reutiliza graful mostenirii realizat in timpul
analizei. Aceasta poate conduce la o ineficienta semnificativa
o Grafurile mostenirii din etapele de analiza, proiectare si implementare au
functii diferite si trebuie gestionate separat
Relatia de asociere in UML
o Obiectele si clasele de obiecte participa in relatii cu alte obiecte si clase
de obiecte
o In UML, o relatie de generalizare este indicata prin intermediul unei
asocieri
o Asocierile pot fi adnotate cu informatii care descriu asocierea
o Asocierile sunt generale, dar pot indica faptul ca un atribut al unui obiect
este un obiect asociat sau ca o metoda se bazeaza pe un obiect asociat
Obiecte concurente
o Natura obiectelor de entitati auto-continute le face potrivite pentru
implementare concurenta
o Modelul comunicarii intre obiecte prin transfer de mesaje poate fi
implementat direct daca obiectele sunt executate pe procesoare
separate intr-un sistem distribuit
Servere si obiecte active
o Server: Obiectul este implementat sub forma de proces paralel (server)
cu puncte de intrare ce corespund operatiilor obiectului. Daca nu exista
nici un apel catre el, obiectul se auto-suspenda si asteapta cereri pentru
servicii
o Obiect activ: Obiectul este implementat ca proces paralel, iar starea
interna a obiectului poate fi modificata prin operatii interne executate in
obiect si nu prin apeluri externe. Procesul ce reprezinta obiectul executa
continuu aceste operatii, deci obiectul nu se auto-suspenda
Fire de executie in Java
o Firele de executie din Java sunt o constructie simpla pentru
implementarea obiectelor concurente
o Firele de executie trebuie sa includa o metoda numita run() care este
lansata automat de catre sistemul Java runtime (JVM)
o Obiectele active includ in mod tipic o bucla infinita astfel incat sa se
execute continuu
Un proces de proiectare orientata obiect
o Procesele de proiectare structurate implica dezvoltarea mai multor
modele diferite ale sistemului
o Ele necesita un efort mare pentru dezvoltarea si intretinerea acestor
modele. Acest lucru poate fi prea costisitor pentru sistemele mici
 o Totusi, in cazul dezvoltarii sistemelor mari de catre echipe, diferite
modele dezvoltate in cursul proiectarii sunt un mecanism esential de
comunicare in si intre echipe
Stadiile procesului
o Evidentiaza activitatile cheie, fara a fi legat de un proces proprietar cum
ar fi RUP:
o Definirea contextului si a modului de utilizare a sistemului
o Proiectarea arhitecturii sistemului
o Identificarea principalelor obiecte din sistem
o Dezvoltarea modelelor de proiectare
o Specificarea interfetelor obiectelor
Contextul sistemului si modelele de utilizare
o Dezvoltarea intelegerii relatiilor dintre software-ul ce trebuie realizat si
contextul sau extern
o Contextul sistemului -> Un model static care descrie celelalte sisteme din
context. Se utilizeaza modelul unui subsistem ce reprezinta celelalte
sisteme din context. Slide-ul urmator ilustreaza sistemele din jurul
sistemului statie meteo
o Modelul utilizarii sistemului -> Un model dinamic care descrie modul in
care sistemul interactioneaza cu contextul sau. Interactiunile sunt
reprezentate cu cazuri de utilizare
Modelele cazurilor de utilizare
o Modelele cazurilor de utilizare sunt folosite pentru a reprezenta fiecare
interactiune cu sistemul
o Un model de cazuri de utilizare reprezinta caracteristicile sistemului sub
forma de elipse iar entitatile ce interactioneaza cu sistemul sub forma de
oameni schematici
Proiectare arhitecturala
o Odata stabilite interactiunile intre sistem si contextul sau, aceste
informatii sunt utilizate pentru proiectarea arhitecturii sistemului
o Pentru statia meteo este potrivita o arhitectura multi-nivel: Nivelul
interfata pentru manipularea comunicarilor & Nivelul colectarii datelor
pentru gestionarea instrumentelor && Nivelul instrumentelor pentru
colectarea datelor.
o Recomandare: In mod normal nu trebuie sa fie mai mult de 7 entitati
intr-un model arhitectural.
Identificarea obiectelor
o Identificarea obiectelor (sau a claselor de obiecte) este partea cea mai
dificila a proiectarii OO
 o Nu exista o 'formula magica' pentru identificarea obiectelor. Ea se
bazeaza pe abilitatea, experienta si cunoasterea domeniului de catre
proiectantii sistemului
o Identificarea obiectelor este un proces iterativ. Este putin probabil ca
aceasta sa se fie completa si corecta upa prima iteratie
Abordari ale identificarii obiectelor
o Utilizarea unei abordari gramaticale bazata pe o descriere a sistemului in
limbaj natural (utilizata in metoda Hood de proiectare OO)
o Fundamentarea identificarii pe lucrurile tangibile din domeniul aplicatiei
o Utilizarea unei abordari comportamentale si identificarea obiectelor pe
baza a cine participa la ce comportament
o Utilizarea unei analize bazata pe scenarii. Sunt identificate obiectele,
atributele si metodele necesare realizarii fiecarui scenariu
Obiecte noi si rafinarea obiectelor
o Utilizarea cunostintelor despre domeniu pentru a identifica mai multe
obiecte si operatii: Statiile meteo trebuie sa aiba identificator unic &
Statiile meteo sunt situate la distanta, deci defectiunile la instrumente
trebuie raportate automat. Rezulta ca sunt necesare atribute si operatii
pentru auto-verificare
o Obiecte active si pasive: In acest caz obiectele sunt pasive si colecteaza
date la cerere si nu in mod autonom. Aceasta introduce flexibilitate cu
pretul timpului de procesare necesar pentru controller
Modele de proiectare
o Modelele de proiectare arata obiectele si clasele de obiecte precum si
relatiile dintre aceste entitati
o Modelele statice descriu structura statica a sistemului in termeni de clase
de obiecte si relatii intre acestea
o Modelele dinamice descriu interactiunile dinamice dintre obiecte
Exemple de modele de proiectare
o Modele de subsisteme care arata gruparea logica a obiectelor in
subsisteme coerente
o Modele de secvente care arata secventele interactiunilor intre obiecte
o Modele de masini cu stari care arata modul in care obiectele individuale
isi modifica starea ca raspuns la evenimente
o Alte modele: modele ale cazurilor de utilizare, modele ale agregarilor,
modele ale generalizarilor, etc
Modele de subsisteme
o Arata organizarea proiectului software in grupuri de obiecte aflate in
relatii logice
 o Sunt reprezentate in UML sub forma de pachete sau de clase
stereotipate cu <<subsystem>> si care pot contine doua compartimente:
specificare si realizare
o Reprezinta modele logice. Organizarea reala a obiectelor in sistem poate
sa fie diferita
Modele de secvente
o Modelele de secvente arata secventele interactiunilor care au loc intre
obiecte:
o Obiectele sunt aranjate orizontal in zona superioara
o Timpul este reprezentat verical; modelele sunt citite de sus in jos
o Interactiunile sunt reprezentate sub forma de sageti etichetate; stiluri
diferite de sageti reprezinta tipuri diferite de interactiuni
o Un dreptunghi subtire pe directia timpului reprezinta o perioada de timp
in care obiectul este activ (i.e. este obiectul ce detine controlul)
Diagrame de stare
o Arata modul in care obiectele raspund la diferite cereri pentru servicii si
tranzitiile de stare declansate de aceste cereri. Exemplu: diagrama de
stare a statiei meteo:
o Daca starea obiectului este Shutdown atunci el va raspunde la un mesaj
Startup()
o In starea Waiting obiectul asteapta mesaje
o Daca primeste mesajul reportWeather() atunci sistemul trece in starea
Summarising
o Daca primeste mesajul calibrate() sistemul trece in starea Calibrating
o Se intra intr-o stare Collecting la primirea unui semnal de la un dispozitiv
de temporizare
Specificarea interfetelor obiectelor
o Specificarea interfetelor obiectelor permite ca obiectele si alte
componente sa fie proiectate in paralel
o Proiectantii trebuie sa evite detalierea reprezentarii interfetei, care
trebuie incapsulata in obiect
o Obiectele pot avea interfete multiple, acestea reprezentand puncte de
vedere diferite asupra metodelor oferite
o UML utilizeaza clase pentru a reprezenta interfete. Clasele sunt
stereotipate cu <<interface >> si nu au compartimentul de atribute
o O abordare alternativa este utilizarea unui limbaj de programare pentru
a descrie interfete. Avantajul este dat de facilitatile de verificare a
sintaxei de catre compilator
Evolutia proiectului software
 o Ascunderea informatiilor in obiecte (incapsularea) are ca rezultat faptul
ca modificarile facute unui obiect nu afecteaza in mod nepredictibil alte
obiecte
o Fie necesitatea adaugarii unor facilitati de monitorizare a poluarii la
statia meteo. Acesta analizeaza probe de aer si calculeaza cantitatile
diferitilor poluanti din atmosfera
o Citirile indicatorilor de poluare sunt transmise odata cu datele meteo
Procesul ICONIX pentru dezvoltarea de software
o Intre abordarea elaborata din RUP (Rational Unified Process) si
abordarea minimalista din programarea extrema (XP)
o Este condus de cazurile de utilizare (use case driven), ca si RUP, dar
elimina o mare parte din overhead-ul necesar acestuia.
o Este relativ redus si concentrat, ca XP, dar nu elimina analiza si
proiectarea
o Utilizeaza UML (Unified Modeling Language) dar pastreaza o focalizare
pe urmarirea si verificarea cerintelor
o Are ca rezultat un set concret, specific si usor de inteles de cazuri de
utilizare pe care echipa le poate folosi in efortul de dezvoltare
ICONIX
o Codul trebuie sa implementeze intocmai cerintele descrise in cazurile de
utilizare
o Descrierea generala initiala trebuie sa devina neambigua, completa si
riguroasa pentru ca pe baza ei sa poata fi produse o arhitectura buna si
solida, un proiect software robust si apoi, prin extensie, un cod care
implementeaza intocmai comportamentul cerut de utilizatori
o Analiza si proiectarea incep cu: Un prototip & O idee despre cum va arata
interfata utilizator && Un punct de plecare in identificarea scenariilor sau
cazurilor de utilizare ale sistemului
o Structura codului OO este definita de clase => sunt necesare una sau mai
multe diagrame de clase care sa defineasca clasele din sistem.
o Pentru fiecare clasa sunt definite: Un set complet de atribute (datele) &
Operatii (functiile software)
o In consecinta, trebuie identificate: Toate functiile software & Toate
datele necesare realizarii functiilor
o Diagramele de clase de la nivelul proiectarii: Un set foarte detaliat de
diagrame de clase la nivelul proiectarii. Aceste diagrame de clase sunt
pasul precedent codificarii. Clasele din aceste diagrame sunt in
corespondenta 1:1 cu clasele din codul sursa
 o Alocarea comportamentului -> deciderea, pentru fiecare functie, a clasei
care o va contine
o Diagrama de secvente -> suport ideal pentru a lua aceste decizii de
alocare a comportamentului
o Diagrama de secvente arata comunicarea prin transfer de mesaje intre
instantele obiectelor la momentul executiei. Fiecare mesaj invoca o
functie software a obiectului care il receptioneaza. De aceea acesta
diagrama este ideala pentru vizualizarea alocarii comportamentului
o In unele instrumente de modelare vizuala -> pe masura ce este desenata
diagrama de secvente, clasele din diagrama de clase sunt populate
automat cu operatiile corespunzatoare mesajelor
o Diagrama de robustete -> ocupa spatiul dintre cerinte si proiectul de
detaliu
o Analiza de robustete s-a dovedit a fi un ajutor important in trecerea de la
cerinte la proiect
o Diagrama de robustete a fost descrisa in specificatiile originale pentru
UML, dar definitia ei a fost plasata intr-un document colateral numit
Objectory Process-Specific Extensions (extensii specifice procesului
Objectory)
o Diagrama de secvente -> un set de obiecte ce participa intr-un scenariu
dat
o Avem nevoie de: O prima incercare de a identifica obiectele ce participa
la scenariu & O prima identificare a functiilor software ce vor fi realizate
in scenariu
o Procesul propus de Ivar Jacobson's este un proces care incorporeaza o
prima incercare, sau un proiect preliminar, al carei rezultat apare in ceea
ce numim diagrama de robustete
o Aceasta prima incercare este apoi rafinata intr-un proiect detaliat in
diagrama de secvente
o Analiza de robustete, care implica parcurgerea diagramei de robustete,
permite: Trecerea de la modelarea functionala la modelarea
comportamentala & Descoperirea de noi obiecte && Adaugarea de
atribute la clase pe masura ce se urmareste fluxul datelor &&&
Actualizarea si rafinarea textului cazului de utilizare
o Cazuri de utilizare bune: Descriu utilizarea sistemului in contextul
modelului obiect & F oarte explicite && Precise &&& Neambigue
o Scop specific: derivarea proiectului software din ele
Puncte cheie
 o Proiectarea OO este o abordare a proiectarii in care componentele au
stare proprie privata si operatii in general publice
o Obiectele trebuie sa aiba constructor si operatii pentru inspectarea starii.
Ele ofera servicii altor obiecte
o Obiectele pot fi implementate secvential sau concurent
o UML (Unified Modeling Language) ofera diferite notatii pentru definirea
diferitelor modele obiectuale
o In timpul procesului de proiectare OO sunt produse mai multe modele
diferite. Acestea includ modele statice si dinamice ale sistemului
o Interfetele obiectelor trebuie definite cu precizie utilizand, de exemplu,
un limbaj de programare cum ar fi Java
o Proiectarea OO ofera potential de simplificare a evolutiei sistemului
Modele de interfete utilizator
o Interfata batch (in loturi de lucrari): Una sau mai multe interfete ce
permit utilizatorilor sa preprogrameze cartele special formatate prin
gaurire, pe baza unui sablon specific recunoscut de calculator. Fiecare
cartela corespunde unei comenzi sau unei linii de cod. Asa numitele
cartele “job” erau utilizate pentru a dirija procesarea pachetului de
cartele. Cartelele erau citite intr-un cititor de cartele care furniza
calculatorului informatiile pentru procesare. & Problema acestui model
de interfata este lipsa de interactivitate cu calculatorul in timpul
procesarii cartelelor. La aparitia unei probleme la o cartela operatia
trebuia sa se opreasca pentru a se inlocui cartela gresita. Aceasta
conducea la reluari multiple pentru a pune programul la punct
o Interfata in mod linie de comanda (CLI): Afiseaza un prompter care indica
faptul ca sistemul este gata sa primeasca o intrare. Utilizatorul tasteaza o
comanda si o trimite spre procesare apasand de obicei tasta Enter.
Calculatorul proceseaza comanda si furnizeaza o iesire sub forma de text.
& O comanda poate, de asemenea, apela un fisier care contine o serie de
comenzi sau cod ce poate fi procesat. && Aduce interactivitate cu
calculatorul. &&& Dificil de retinut comenzile complexe. &&&& Un
limbaj de scripting, permite utilizatorilor sa creeze fisiere de comenzi ce
pot fi lansate ca atare
o Interfata text (TUI): Utilizeaza intreg ecranul pentru a executa diferite
operatii. & Ofera functionalitate si utilizabilitate superioara in
conducerea activitatilor
Proiectarea UI
o Proiectarea UI este o parte esentiala a intregului proces de proiectare a
software-lui
 o Interfata utilizator trebuie proiectata astfel incat sa fie potrivita cu
abilitatile, experienta si asteptarile utilizatorilor anticipati
o Deseori utilizatorii unui sistem il judeca mai curand dupa interfata decat
dupa functionalitate
o O interfata proiectata prost poate determina un utilizator sa faca greseli
catastrofice
o Proasta proiectare a a interfetei este unul dintre motivele pentru care
multe sisteme software nu au fost niciodata utilizate
Scopurile unui proiect bun
o Trebuie sa fie etic
o Trebuie sa aiba un scop
o Trebuie sa fie pragmatic
o Trebuie sa fie elegant
Principiile proiectarii UI
o Proiectarea UI trebuie sa tina cont de necesitatile, experienta si
capabilitatile utilizatorilor sistemului
o Proiectantii trebuie sa fie constienti de limitarile fizice si mentale ale
utilizatorilor (ex. memorie pe termen scurt limitata) si sa recunoasca
faptul ca acestia pot face greseli
o Principiile proiectarii UI stau la baza proiectarii interfetelor, dar nu toate
principiile sunt aplicabile tuturor proiectelor
o Familiaritate -> Interfata trebuie sa se bazeze pe termeni si concepte
orientate pe utilizator si nu pe concepte specifice sistemelor de calcul.
De exemplu, un sistem pentru birou trebuie sa utilizeze concepte ca
scrisori, documente, fisiere, si nu directoare, identificatoare de fisier, etc
o Consistenta -> Sistemul trebuie sa prezinte un nivel corespunzator de
consistenta. Comenzile si menu-urile trebuie sa aiba acelasi format,
punctuatia comenzilor sa fie similara, etc. Consistenta intre aplicatii: ex.
comenzile cu inteles similar exprimate in acelasi mod. Consistenta low-
level: ex. utilizarea acelorasi acceleratori ca cei definiti de sistemul de
operare. Consistenta high-level: ex. aceleasi operatii suportate de toate
tipurile de entitati din sistem
o Surpriza minima: Daca o comanda functioneaza intr-un mod cunoscut,
utilizatorul trebuie sa fie capabil sa prevada functionarea comenzilor
comparabile (conform cu modelul mental construit de utilizator in timpul
utilizarii aplicatiei)
o Recuperabilitate: Sistemul trebuie sa ofere un anumit grad de
flexibilitate fata de erorile utilizatorilor si sa permita acestora sa poata
recupera sistemul
 o Trebuie oferite facilitati de interactiune pentru diferite tipuri de
utilizatori: Ocazionali (necesita ghidare) vs. power users (necesita
acceleratori) & Utilizatori cu dizabilitati: ex. Utilizatori cu dificultati de
vedere => se va prezenta textul cu caractere de dimensiuni mari
Probleme de proiectare in UI
o In proiectarea sistemelor interactive trebuie adresate doua probleme:
Cum va fi furnizata calculatorului informatia de la utilizator? & Cum va fi
prezentata utilizatorului informatia produsa de calculator?
o Interactiunea cu utilizatorul ca si prezentarea informatiei pot fi integrate
prin intermediul unui cadru coerent, cum ar fi o metafora pentru
interfata utilizator
Stiluri de interactiune
o Manipulare directa
o Selectie din menu
o Completare formular
o Limbaj de comanda
o Limbaj natural
Interfete bazate Web
o Multe sisteme bazate Web au interfete bazate pe formulare (forms) Web
o Campurile formularelor pot fi menu-uri, casete preluare text, butoane
radio, etc
o In exemplul LIBSYS utilizatorii aleg dintr-un menu sursa la care se va face
cautarea si tasteaza fraza de cautare intr-o caseta de preluare text
Prezentarea informatiilor
o Prezentarea informatiilor se refera la prezentarea informatiilor produse
de sistem utilizatorilor acestuia
o Informatiile pot fi prezentate direct (ex. text intr-un procesor de texte)
sau pot fi transformate intr-o anumita forma de prezentare (ex. intr-o
anume forma grafica)
o Abordarea Model-View-Controller este o modalitate de a oferi suport
pentru prezentari multiple ale datelor
Prezentarea informatiilor
o Informatii statice: Initializate la inceputul unei sesiuni. Nu se modifica pe
durata sesiunii & Pot fi numerice sau textuale
o Informatii dinamice: Se modifica pe parcursul unei sesiuni iar modificarile
trebuie comunicate utilizatorului sistemului & Pot fi numerice sau
textuale
Prezentare analogica sau digitala
 o Prezentare digitala: Compacta -> ocupa putin spatiu pe ecran & Se pot
comunica valori precise
o Prezentare analogica: Usor de format o impresie la prima vedere asupra
valorii & Posibilitatea de a arata valori relative && Mai usor de vazut
valorile exceptionale
Vizualizarea datelor
o Se ocupa cu tehnicile pentru afisarea cantitatilor mari de informatii
o Vizualizarea poate revela relatiile dintre entitati si tendintele datelor
o Vizualizari posibile de date:
o Informatii meteo colectate de la mai multe surse
o Starea unei retele de telefonie sub forma unui set de noduri conectate
o Combinat chimic viziualizat sub forma de presiuni si temperaturi intr-un
set de rezervoare si conducte
o Un model molecular afisat in 3 dimensiuni
o Pagini Web afisate ca arbore hiperbolic
Afisarea culorilor
o Culoarea adauga o dimensiune suplimentara unei interfete si poate ajuta
utilizatorul sa inteleaga structuri complexe de informatie
o Culoarea poate fi utilizata pentru a evidentia: Evenimente exceptionale &
Anomalii && Similaritati
o Greseli obisnuite la utilizarea culorilor in proiectarea interfetelor:
Utilizarea culorii pentru a comunica un anumit inteles & Utilizarea
excesiva de culori
Indrumari de utilizare a culorilor
o Limitarea numarului de culori utilizate si folosirea lor consecventa
o Utilizarea unei schimbari de culoare pentru a ilustra o schimbare in
starea sistemului
o Utilizarea codificarii pe baza de culori pentru a oferi sprijin utilizatorilor
in realizarea activitatii curente
o Utilizarea codificarii pe baza de culori in mod bine gandit si controlat
o Atentie la imperecherea culorilor
Mesaje de eroare
o Proiectarea mesajelor de eroare este de importanta critica. Mesaje
proaste pot conduce la refuzarea sistemului de catre utilizator
o Mesajele trebuie sa fie politicoase, concise, consistente si constructive
o Cultura si experienta utilizatorilor trebuie sa constituie un factor
determinant in proiectarea mesajelor
Procesul de proiectare a interfetei utilizator (UI)
 o Proiectarea UI este un proces iterativ care implica o legatura stransa
intre utilizatori si proiectanti
o Activitati fundamentale ale acestui proces:
 Analiza utilizatorului. Intelegerea a ceea ce vor face utilizatorii cu
sistemul
 Prototiparea sistemului. Dezvoltarea unei serii de prototipuri in
vederea experimentarii
 Evaluarea interfetei. Experimentarea prototipurilor cu utilizatorii
Analiza utilizatorului
o Daca nu se intelege ce vor utilizatorii sa faca cu sistemul, atunci nu exista
o perspectiva realista a proiectarii unei interfete eficiente
o Analiza utilizatorului trebuie descrisa in termeni pe care ii pot intelege
atat utilizatorii cat ceilalti proiectanti
o Scenariile in care sunt descrise episoade tipice de utilizare sunt un mod
de a realiza aceste analize
Cerinte rezultate din scenariu
o Utilizatorii ar putea sa nu cunoasca termeni de cautare corespunzatori,
deci au nevoie de o metoda care sa-i ajute sa aleaga termeni
o Utilizatorii trebuie sa poata alege colectiile in care sa se realizeze
cautarile
o Utilizatorii trebuie sa poata realiza cautari si sa ceara copii ale
materialelor relevante
Intervievare
o Proiectare de interviuri semi-structurate bazate pe intrebari deschise
o Utilizatorii pot furniza astfel informatiile pe care ei le considera esentiale
si nu doar informatiile pe care inginerul s-a gandit sa le colecteze
o Interviuri in grup sau grupuri focalizate permit utilizatorilor sa discute
intre ei despre ceea ce fac
Etnografie
o Implica faptul ca un observator extern urmareste utilizatorii la lucru si ii
interogheaza verbal despre ceea ce fac
o Valoroasa deoarece multe sarcini ale utilizatorilor sunt intuitive si
acestora le este foarte dificil sa le descrie si explice
o Ajuta, de asemenea, in intelegerea rolului influentelor sociale si
organizationale asupra modului de lucru
Prototiparea interfetei utilizator
o Scopul prototiparii este de a permite utilizatorilor sa capete exeprienta
directa cu interfata
 o In lipsa acestei experiente directe, este imposibil de judecat
utilizabilitatea unei interfete
o Prototiparea poate fi un proces cu doua stadii: In primul stadiu se pot
utiliza prototipuri pe hartie & In cel de al doilea stadiu desenul este
rafinat si se dezvolta prototipuri automate din ce in ce mai sofisticate
Prototip pe hartie
o Parcurgerea scenariilor utilizand schite ale interfetei
o Prezentarea unei serii de interactiuni cu sistemul
o Prototipul pe hartie este o metoda eficienta de a afla reactiile
utilizatorului la propunerile pentru design-ul interfetei
Evaluarea interfetei utilizator
o Se pot realiza evaluari ale design-ului unei interfetei utilizator pentru a
vedea in ce masura corespunde modului de lucru potrivit
o Evaluarea totala este foarte costisitoare si nepractica pentru majoritatea
sistemelor
o In mod ideal o interfata ar trebui evaluata in raport cu specificatiile de
utilizabilitate. Totusi, aceste specificatii sunt rareori definite
Utilizabilitate
o Capaciatatea de a fi utilizabil
o Convenabil si practic de utilizat
o Bazata pe:
o Utilizabilitatea necesita concentrare pe utilizatori
o Oamenii utilizeaza produse software pentru a fi productivi
o Utilizatorii sunt persoane ocupate care incearca sa indeplineasca sarcini
o Utilizatorii sunt cei care decid daca un produs este usor de utilizat
Tehnici simple de evaluare
o Chestionare pentru feedback de la utilizator
o Inregistrare video a utilizarii sistemului si evaluarea ulterioara a proiectiei
o Extinderea codului cu operatii de colectare referitoare la utilizarea
facilitatilor si la erorile utilizatorului
o Adaugarea de cod care sa colecteze feedback on-line de la utilizator
Puncte cheie
o Principiile de proiectare a interfetei utilizator trebuie sa ajute in ghidarea
proiectarii interfetelor utilizator
o Stilurile de interactiune includ manipulare directa, sisteme de menu-uri,
completare formulare, limbaje de comanda si limbaj natural
o Afisarile grafice ar trebui utilizate pentru a prezenta tendinte si valori
aproximative. Afisarile digitale sunt utile atunci cand este necesara
precizie
 o Culorile trebuie utilizate cu economie si in mod consistent
o Procesul de proiectare a interfetei utilizator implica analiza utilizatorului,
prototiparea sistemului si evaluarea prototipului
o Scopul analizei utilizatorului este de a face proiectantii constienti de
modul in care utilizatorii lucreaza de fapt
o Prototiparea UI ar trebui sa fie un proces in doua stadii, cu prototipurile
elaborate in primul stadiu utilizate ca baza pentru prototiparea automata
a interfetei
o Scopurile evaluarii UI sunt de a obtine feedback despre cum sa fie
imbunatatit design-ul intefetei si de a evalua daca interfata indeplineste
cerintele de utilizabilitate
Dezvoltare rapida de software (RAD)
o Datorita contextelor economice in schimbare rapida, economia trebuie
sa raspunda la noi oportunitati si competitii.
o Acestea necesita software, iar dezvoltarea si livrarea rapida sunt deseori
cerintele cele mai critice pentru sistemele software.
o Mediul economic ar putea accepta insa software de calitate mai slaba
daca este posibila furnizarea rapida a functionalitatii esentiale.
Cerinte
o Datorita contextului in schimbare, este deseori imposibil sa se ajunga la
un set stabil si consistent de cerinte pentru sistem.
o De aceea, modelul cascada pentru dezvoltarea de software nu este
practic; singura cale de a livra software-ul rapid este utilizarea unei
abordari a procesului de dezvoltare bazata pe specificarea ierativa a
cerintelor.
Caracteristicile proceselor RAD
o Procesele de specificare, proiectare si implementare sunt concurente. Nu
exista specificatii detaliate iar documentatia de proiectare este
minimizata.
o Sistemul este dezvoltat intr-o serie de incremente. Utilizatorii finali
evalueaza fiecare increment si fac propuneri pentru incrementele
urmatoare.
o Interfetele utilizator ale sistemelor sunt dezvoltate de obicei utilizand un
sistem de dezvoltare interactiv.
Avantajele dezvoltarii incrementale
o Accelerarea firnizarii serviciilor pentru client. Fiecare increment
furnizeaza functionalitatea cu prioritate maxima pentru client.
o Angajarea utilizatorului in realizarea sistemului. Utilizatorii trebuie sa fie
implicati in dezvoltare, ceea ce inseamna ca sistemul are sanse mai mari
 sa le indeplineasca cerintele iar utilizatorii sunt mai angajati in raport cu
sistemul.
Probleme ale dezvoltarii incrementale
o Probleme de management-Este dificil de judecat progresul si de depistat
problemele deoarece nu exista documentatie care sa demonstreze ce s-a
realizat.
o Probleme contractual-Contractul normal include o specificatie; in lipsa
unei specificatii trebuie utilizate formate diferite de contract.
o Probleme de validare-Fata de ce se testeaza sistemul daca nu exista o
specificatie?
o Probleme de intretinere-Continua modificare tinde sa corupa structura
software-lui, facand ca modificarile si evolutia catre indeplinirea de noi
cerinte sa fie mai costisitoare.
Prototipare
o Pentru unele sisteme mari dezvoltarea iterativa incremetala poate fi
nepractica; aceasta este adevarat in special cand mai multe echipe
lucreaza in locatii diferite la acelasi proiect.
o Se poate utiliza prototiparea, in cadrul careia este dezvoltat un sistem
experimental ca baza pentru formularea cerintelor. Prototipul este
inlaturat atunci cand s-a obtinut acordul asupra specificatiilor sistemului.
Obiective conflictuale
o Obiectivul dezvoltarii incrementale este de a furniza utilizatorilor finali
un sistem functional. Dezvoltarea incepe cu acele cerinte care sunt cel
mai bine intelese.
o Obiectivul prototiparii este de a valida sau de a deriva cerintele
sistemului. Procesul de prototipare incepe cu cerintele cel mai putin
intelese.
Metode agile
o Insatisfactia creata de overhead-urile implicate in metodele de
proiectare a condus la crearea metodelor agile. Aceste metode: Se
concentreaza pe cod si nu pe proiect (design); Sunt bazate pe o abordare
iterativa a dezvoltarii software-lui; Sunt destinate sa furnizeze rapid
software functional si sa-l modifice rapid pentru a indeplini cerinte in
schimbare.
o Metodele agile se potrivesc probabil cel mai bine cu sisteme economice
de dimensiuni mici si mijlocii sau cu produse PC.
Probleme ale metodelor agile
o Poate fi dificil sa mentinem interesul clientilor care sunt implicati in
proces.
 o Membrii echipei ar putea fi nepotriviti cu implicarea intensa care
caracterizeaza metodele agile.
o Acolo unde exista multe parti interesate, ar putea fi dificila prioritizarea
modificarilor.
o Mentinerea simplitatii necesita munca in plus.
o Contractele ar putea fi o problema, la fel ca si in alte abordari ale
dezvoltarii iterative.
Programarea extrema
o Probabil cea mai cunoscuta si larg utilizata metoda agila.
o Programarea extrema (XP) are o abordare ‘extrema’ la dezvoltarea
iterativa.
o Noi versiuni pot fi construite de mai multe ori pe zi;
o Incrementele sunt furnizate clientului la fiecare 2 saptamani;
o Pentru fiecare versiune (build) se executa toate testele, iar versiunea
este acceptata doar daca trece cu succes aceste teste.
XP si principiile agile
o Dezvoltarea incrementala este realizata prin lansari mici si frecvente ale
sistemului.
o Implicarea clientului inseamna angajarea full-time a clientului alaturi de
echipa.
o Persoane, nu procese: prin programare in pereche, proprietate colectiva
si un proces care evita ore suplimentare de lucru.
o Suport pentru realizarea de modificari prin lansari regulate ale
sistemului.
o Mentinerea simplitatii prin refactorizare constanta a codului.
Scenariile de cerinte
o In XP, cerintele utilizator sunt exprimate sub forma de scenarii
“povestite” de utilizatori.
o Acestea sunt scrise pe cartele iar echipa de dezvoltare le divizeaza in
sarcini (task) de implementare. Aceste sarcini sunt baza estimarilor de
timp si de cost.
o Clientul alege scenariile ce vor fi incluse in urmatoarea lansare pe baza
prioritatilor si a estimarilor de timp.
XP si modificarile
o In mod conventional este recomandabil in ingineria software ca
proiectarea sa se faca astfel incat sistemul sa suporte usor modificari
ulterioare. Timpul si efortul investite in anticiparea modificailor sunt
recuperate prin reducerea costurilor ulterioare din ciclul de viata.
 o XP, totusi, sustine ca acest lucru nu merita facut deoarece nu toate
modificarile pot fi anticipate.
o In schimb, propune imbunatatirea constanta a codului (refactorizare)
astfel incat modificarile sa poata fi facute usor atunci cand sunt
implementate.
Testarea in XP
o Dezvoltarea testelor de la inceput.
o Dezvoltare incrementala a testelor pe baza scenariilor.
o Implicarea utilizatorului in dezvoltarea si validarea testelor.
o Automatizarea testarii pentru a executa testarea tuturor componentelor
la construirea fiecarei lansari.
Dezvoltarea testelor de la inceput
o Scrierea testelor inainte de cod clarifica cerintele ce trebuie
implementate.
o Testele sunt scrise ca programe (nu ca date) astfel incat pot fi executate
automat. Testul include o verificare ca s-a executat corect.
o Toate testele anterioare si testele noi sunt executate automat atunci
cand se adauga o noua functionaliate. Astfel se verifica faptul ca noua
functionalitate nu a introdus erori.
Programarea in pereche
o In XP programatorii lucreaza in perechi, stand impreuna pentru a
dezvolta codul.
o Aceasta ajuta la dezvoltarea unei proprietati comune asupra codului si
distribuie cunostintele catre intreaga echipa.
o Serveste ca un proces de revizuire informala deoarece fiecare linie de
cod este vazuta de mai multe persoane.
o Incurajeaza refactorizarea deoarece intreaga echipa poate beneficia de
aceasta.
o Masuratorile sugereraza ca productivitatea este similara cu cea a doua
persoane care lucreaza independent.
Dezvoltarea rapida a aplicatiilor (RAD)
o Metodele agile au avut parte de o atentie considerabila, dar exista si alte
abordari ale dezvoltarii rapide a aplicatiilor care au fost utilizate pentru
multi ani.
o Acestea sunt proiectate pentru dezvoltarea de aplicatii economice cu
foarte multe date (data-intensive) si se bazeaza pe programarea si
prezentarea informatiilor dintr-o baza de date.
Instrumente pentru medii RAD
o Limbaje de programare a bazelor de date
 o Generator de interfete
o Legaturi la aplicatii de birou (office)
o Generatoare de rapoarte
Generarea interfetei
o Multe aplicatii se bazeaza pe formulare complexe iar dezvoltarea
manuala a acestora este o activitate consumatoare de timp.
o Mediile RAD ofera sprijin pentru generarea de ecrane care include:
Definirea interactiva a formularelor utilizand tehnici “drag and drop”;
Legarea formularelor in cazul in care se specifica necesitatea prezentarii
unei secvente de formulare; Verificarea datelor completate in formulare,
daca sunt definite domenii/restrictii pentru valorile permise in campuri.
Programare vizuala
o Limbajele de scripting, cum ar fi Visual Basic, suporta programarea
vizuala in care prototipul este dezvoltat prin crearea unei interfete
utilizator din elemente standard si prin asocierea de componente cu
aceste elemente.
o Exista o biblioteca vasta de componente care ofera sprijin pentru acest
tip de dezvoltare.
o Acestea trebuie croite astfel incat sa fie potrivite cerintelor specifice
aplicatiei.
Probleme ale programarii vizuale
o Este dificil de coordonat dezvoltarea de software in echipa.
o Nu exista o arhitectura explicita a sistemului.
o Dependentele complexe intre parti ale programului pot conduce la
probleme de mentenabilitate.
Reutilizare cu COTS (Commercial, off-the-shelf)
o O abordare eficienta a dezvoltarii rapide este legarea si configurarea
sistemelor COTS existente.
o De exemplu, un sistem de management al cerintelor ar putea fi construit
utilizand: O baza de date pentru a memora cerintele; Un procesor de
texte pentru a captura cerintele si formatele de raportare; O tabela de
calcul (spreadsheet) pentru managementul urmaririi;
Documente compuse
o Pentru unele aplicatii se poate crea un prototip prin dezvoltarea unui
document compus.
o Acesta este un document cu elemente active (cum ar fi o tabela de
calcul) care permite realizarea de calcule de catre utilizator.
o Fiecare element activ are asociata o aplicatie care este invocata la
selectarea elementului.
 o Documentul compus este integratorul acestor aplicatii.
Prototiparea software-lui
o Un prototip este o versiune initiala a unui sistem utilizata pentru a
demonstra concepte si a incerca optiuni de proiectare.
o Un prototip poate fi utilizat in: Procesul de inginerie a cerintelor pentru a
ajuta la identificarea si validarea cerintelor; Procesul de proiectare pentru
a explora optiunile si a dezvolta un design pentru UI; Procesul de testare
pentru a executa teste back-to-back.
Beneficiile prototiparii
o Cresterea utilizabilitatii sistemului.
o O apropiere de cerintele reale ale utilizatorilor.
o Cresterea calitatii proiectului.
o Imbunatatirea mentenabilitatii.
o Reducerea efortului de dezvoltare.
Prototipuri
o Prototipurile “throw-away” trebuie eliminate dupa dezvoltare deoarece
nu sunt o baza potrivita pentru producerea sistemului deoarece: Este
imposibila reglarea sistemului astfel incat sa indeplineasca cerinte non-
functionale; In mod normal prototipurile nu sunt documentate; Datorita
modificarilor rapide, de obicei structura prototipului este degradata;
Prototipul probabil nu va indeplini standardele de calitate normale ale
organizatiei.
Puncte cheie
o O abordare iterativa a dezvoltarii de software conduce la livrarea mai
rapida a software-lui.
o Metodele agile sunt metode iterative de dezvoltare care au ca scop
reducerea overhead-ului de dezvoltare, astfel incat software-ul sa fie
produs mai rapid.
o Programarea extrema include practici cum ar fi testarea sistematica,
imbunatatirea continua si implicarea clientului.
o Abordarea testarii in XP este o calitate puternica in care testele
executabile sunt dezvoltate inainte de scrierea codului.
o Mediile RAD includ limbaje de programare a bazelor de date,
instrumente pentru generare de formulare si legaturi cu aplicatii de
birou.
o Un prototip “throw-away” este utilizat pentru explorarea cerintelor si a
optiunilor de proiectare.
 o La implementarea unui prototip “throw-away” se incepe cu cerintele cel
mai putin intelese; in dezvoltarea incrementala se incepe cu cerintele cel
mai bine intelese.
Reutilizarea software-lui
o In majoritatea disciplinelor ingineresti, sistemele sunt proiectate prin
compunere din componente existente care au fost utilizate in alte
sisteme.
o Ingineria software s-a focalizat mai mult pe dezvoltarea originala, dar
acum se recunoaste ca pentru a obtine mai rapid si la costuri mai mici un
software mai bun este nevoie sa adoptam un proces de proiectare bazat
pe reutilizarea sistematica a software-lui.
Inginerie software bazata pe reutilizare
o Reutilizarea sistemelor de aplicatii-Se poate reutiliza un intreg sistem de
aplicatie fie prin incorporarea sa fara modificari in alte sisteme (COTS
reuse) fie prin dezvoltarea familiilor de aplicatii.
o Reutilizarea de componente-Se pot reutiliza componentele unei aplicatii,
de la sub-sisteme la simple obiecte (tratata in cursul urmator).
o Reutilizarea de obiecte si de functii-Se pot utiliza componente software
care implementeaza un singur obiect sau functie bine definite.
Reutilizarea
o Desi reutilizarea inseamna pur si simplu reutilizarea componentelor unui
sistem, exista multe abordari diferite ce pot fi aplicate.
o Reutilizarea este posibila pe mai multe nivele, de la simple functii la
sisteme complete de aplicatie.
o Reutilizarea acopera intreaga arie a tehnicilor de reutilizare posibile.
Factori de planificare a reutilizarii
o Planul de timp al dezvoltarii software-lui.
o Durata de viata preconizata pentru software.
o Baza (background), competentele si experienta echipei de dezvoltare.
o Criticalitatea software-lui si cerintele sale non-functionale.
o Domeniul aplicatiei.
o Platforma de executie pentru software.
Reutilizare concept
o La reutilizarea componentelor de proiectare sau de program trebuie
urmate deciziile de proiectare facute de cel ce a dezvoltat componenta
originala.
o Aceasta ar putea limita oportunitatile de reutilizare.
 o Totusi, o forma mai abstracta de reutilizare este reutilizarea de concepte.
O abordare particulara este descrisa intr-un mod independent de
implementare iar o implementare este dezvoltata ulterior.
o Cele doua abordari principale ale reutilizarii de concepte sunt: Design
patterns; Generative programming.
Design patterns
o Un sablon de programare (design pattern) este un mod de a reutiliza
cunoastere abstracta despre o problema si solutia sa.
o Un sablon este o descriere a problemei si a esentei solutiei.
o Trebuie sa fie suficient de abstract pentru a fi reutilizat in diferite
contexte.
o Deseori sabloanele sunt bazate pe caracteristici ale obiectelor cum ar fi
mostenirea si polimorfismul.
Elementele unui sablon
o Nume-Un identificator sugestiv.
o Descrierea problemei.
o Descrierea solutiei-Nu un design concret ci un sablon (template) pentru o
solutie de proiectare care poate fi instantiat in diferite moduri.
o Consecinte-Rezultatele si compromisurile (trade-offs) aplicarii sablonului.
Sablonul Observer
o Nume-Observer.
o Descriere-Separa afisarea starii unui obiect de obiectul propriu-zis.
o Descrierea problemei-Utilizat cand sunt necesare afisari multiple ale
starii.
o Descrierea solutiei-Vezi slide-ul urmator ce contine descrierea UML.
o Consecinte-Nu sunt practice optimizarile pentru cresterea performantei
afisarii.
Reutilizare bazata pe generator
o Generatoarele de programe implica reutilizarea sabloanelor si
algoritmilor standard.
o Acestea sunt inglobate in generator si parametrizate de catre comenzile
utilizator. Programul este apoi generat automat.
o Reutilizarea bazata pe generator este posibila atunci cand se pot
identifica abstractizarile specifice domeniului si codul executabil ce la
corespunde.
o Se poate utiliza un limbaj specific domeniului pentru a compune si a
controla aceste abstractizari.
Tipuri de generatoare de programe
o Tipuri de generatoare de programe
 o +Generatoare de aplicatii pentru procesarea datelor economice;
o +Generatoare de parser-e si analizoare lexicale pentru procesarea
linbajelor;
o +Generatoare de cod din instrumente CASE.
o Reutilizarea bazata pe generatoare este foarte eficienta dar
aplicabilitatea sa este limitata la un numar relativ mic de domenii de
aplicatie.
o Este mai simplu de dezvoltat programe folosind generatoare decat
folosind alte abordari bazate pe componente ale reutilizarii.
Dezvoltare orientata pe aspecte
o Dezvoltarea orientata pe aspecte se adreseaza unei probleme majore din
ingineria software: separarea preocuparilor (concerns).
o Preocuparile (concerns) sunt deseori asociate cu elemente ce
traverseaza aplicatia (nu pur si simplu simplu cu functionalitatea
aplicatiei) – ex. toate componentele isi monitorizeaza operatiile proprii,
toate componentele trebuie sa pastreze securitatea, etc.
o Preocuparile traversante sunt implementate ca aspecte si sunt
intretesute dinamic intr-un program. Codul acestora este reutilizat iar
noul sistem este generat de catre tesatorul (weaver) de aspecte.
Cadre (frameworks) de aplicatii
o Framework-urile sunt proiecte de subsisteme formate dintr-o colectie de
clase abstracte si concrete si din interfetele dintre acestea.
o Subsistemul este implementat prin adaugare de componente care sa
completeze partile proiectului si prin extinderea claselor abstracte din
framework.
o Framework-urile sunt entitati reutilizabile de dimensiuni moderate.
Clase de framework-uri
o Framework-uri pentru infrastructura sistemelor-Sprijina dezvoltarea
infrastructurii sistemelor, cum ar fi comunicarile, interfetele utilizator si
compilatoarele.
o Framework-uri pentru integrarea middleware-lui-Standarde si clase care
sprijina comunicarea si schimbul de informatii intre componente.
o Framework-uri pentru aplicatii enterprise-Sprijina dezvoltarea tipurilor
specifice de aplicatii, cum ar fi sisteme de telecomunicatii sau sisteme
financiare.
Extinderea framework-urilor
o Framework-urile sunt generice si sunt extinse pentru a crea aplicatii sau
subsisteme mai specifice.
 o Extinderea unui framework implica: Adaugarea de clase concrete care
mostenesc operatii de la clasele abstracte din framework; & Adaugare de
metode ce vor fi apelate ca raspuns la evenimentele ce sunt recunoscute
de framework.
o Problema framework-urilor este complexitatea lor, ceea ce inseamna ca
este necesar mult timp pana la utilizarea lor eficienta.
Model-view controller
o Framework de infrastructura pentru proiectarea GUI.
o Permite prezentari multiple ale unui obiect si separarea interactiunilor cu
aceste prezentari.
o Framework-ul MVC implica instantierea mai multor sabloane de
programare.
Reutilizarea sistemelor de aplicatie
o Implica reutilizarea unor intregi sisteme de aplicatie fie prin configurarea
unui sistem pentru un anume context fie prin integrarea a doua sau mai
multe sisteme pentru a crea o noua aplicatie.
o Vom discuta doua abordari: Integrarea de produse COTS; & Dezvoltarea
liniilor de productie.
Reutilizarea produselor COTS
o COTS – sisteme comerciale (Commercial Off-The-Shelf).
o Sistemele COTS sunt de obicei sisteme complete de aplicatie care ofera o
interfata de programare a aplicatiilor - API (Application Programming
Interface).
o Construirea sistemelor mari prin integrarea de sisteme COTS a devenit o
strategie viabila de dezvoltare pentru unele tipuri de sisteme cum ar fi
sistemele de comert electronic (E-commerce).
o Beneficiul principal este oferit de dezvoltarea mai rapida a aplicatiei
insotita de obicei de costuri mai scazute de dezvoltare.
Decizii de proiectare cu COTS
o Care produse COTS ofera functionalitatea cea mai potrivita? Exista mai
multe produse similare ce pot fi utilizate.
o Cum se va face schimbul de date? Produsele individuale utilizeaza
structuri de date si formate proprii.
o Care dintre caracteristicile produsului vor fi utilizate? Cele mai multe
produse ofera mai multa functionalitate decat este necesara intr-un caz
particular. Trebuie interzis accesul la functionalitatea neutilizata.
Exemplu: produse COTS reutilizate
o De partea clientului, se utilizeaza programe standard pentru navigare
Web si pentru posta elecronica.
 o De partea serverului, o platforma pentru comert electronic (e-
commerce) trebuie integrata cu un sistem existent de gestionare ordine
si facturi.
o +Aceasta implica scrierea unui adaptor astfel incat cele doua sisteme sa
poata schimba date.
o +De asemenea, este integrat un sistem de posta electronica (e-mail)
pentru a genera mesaje pentru clienti. Aceasta necesita, de asemenea,
un adaptor pentru a primi date de la sistemul de gestionare ordine si
facturi.
Problemele integrarii de sisteme COTS
o Lipsa de control asupra functionalitatii si performantei-Sistemele COTS ar
putea fi mai putin eficiente decat par.
o Probleme de interoperabilitate a sistemlor COTS-Sisteme COTS diferite
pot fi bazate pe premize diferite, ceea ce conduce la dificultatea
integrarii lor.
o Nu exista control asupra evolutiei sistemului-Furnizorii si nu utilizatorii
de sisteme COTS controleaza evolutia acestora.
o Sprijin de la furnizorii de sisteme COTS-Furnizorii COTS ar putea sa nu
ofere suport pe toata durata de viata a produsului.
Linii de productie de software
o Liniile de productie de software sau familiile de aplicatii sunt aplicatii cu
functionalitati generice care pot fi adaptate si configurate pentru
utilizare in contexte specifice.
o Adaptatarea poate sa implice:
o +Configurare de componente si de sistem;
o +Adaugare de noi componente la sistem;
o +Selectare dintr-o biblioteca de componente existente;
o +Modificare de componente pentru a indeplini cerinte noi.
Specializarea liniilor de productie de software
o Specializarea platformei-Sunt dezvoltate versiuni diferite ale aplicatiei
pentru platforme diferite.
o Specializarea contextului-Sunt create versiuni diferite ale aplicatiei
pentru diferite contexte de operare (ex. tipuri diferite de echipamente
de comunicare).
o Specializare functionala-Sunt create versiuni diferite ale aplicatiei pentru
clienti cu cerinte diferite.
o Specializarea procesului-Sunt create versiuni diferite ale aplicatiei ca
suport pentru diferite procese economice.
Configurarea liniilor de productie de software
 o Configurarea la repartizare (deployment)-Este configurat un sistem
generic prin inglobarea cunoasterii despre cerintele clientului si procesul
economic. Software-ul propriu-zis nu este modificat.
o Configurarea la proiectare-Un cod generic comun este adaptat si
modificat conform cerintelor clientilor particulari.
Sisteme ERP
o Un sistem ERP (Enterprise Resource Planning) este un sistem generic
care ofera suport pentru procese economice comune cum ar fi trimitere
de ordine, facturare, manufacturare, etc.
o Acestea sunt larg utilizate in firme mari – ele reprezinta probabil cea ma
comuna forma de reutilizare de software.
o Nucleul generic este adaptat prin includerea de module si prin
incorporarea de cunostinte depre procesele si regulile economice.
Configurarea la proiectare
o Liniile de productie de software care sunt configurate in timpul
proiectarii sunt instantieri de arhitecturi de aplicatii generice.
o Produsele generice apar, de obicei, dupa mai multa experienta cu
produse specifice.
Arhitecturi pentru linii de productie
o Arhitecturile trebuie structurate astfel incat sa separe subsisteme diferite
si sa permita modificarea lor.
o Arhitectura trebuie, de asemenea, sa separe entitatile de descrierile lor.
Exemplu: Sistem pentru dispecerizare vehicule
o Un sistem de management resurse specializat al carui scop este de a
aloca resurse (vehicule) pentru a gestiona incidente.
o Adaptatarea include:
o +La nivelul UI, exista componente pentru necesitatile de afisare si de
comunicare ale operatorului;
o +La nivelul managementului operatiilor de I/E, exista componente care
trateaza autentificarea, raportarea si planificarea rutelor;
o +La nivelul managementului de resurse, exista componente pentru
localizarea si dispecerizarea vehiculelor, gestionarea starilor vehiculelor
si jurnalizarea (logging) incidentelor;
o +Baza de date include baze de date pentru echipament, vehicule si harti.
Dezvoltarea unei instante de produs
o Extragerea cerintelor partilor interesate-Utilizarea ca prototip a unui
membru existent al familiei.
o Alegerea celui mai potrivit membru al familiei-Gasirea membrului
familiei care indeplineste cel mai bine cerintele.
 o Re-negocierea cerintelor-Adaptarea cerintelor conform capabilitatior
software-lui.
o Adaptarea sistemului existent-Dezvoltarea de noi module si realizarea de
schimbari la membrul familiei.
o Livrarea unui nou membru al familiei-Documentarea caracteristicilor
cheie, utile in dezvoltarea ulterioara de noi membri.
Puncte cheie
o Avantajele reutilizarii sunt date de costuri mai scazute, dezvoltare mai
rapida de software si riscuri mai mici.
o Sabloanele de programare (design patterns) sunt abstractizari de nivel
inalt care documenteaza solutii de proiectare de succes.
o Generatoarele de programe se ocupa, de asemenea, cu reutilizarea de
software – conceptele reutilizate sunt inglobate in sistemul generator.
o Framework-urile pentru aplicatii sunt colectii de obiecte concrete si
abstracte care sunt proiectate pentru reutilizare prin specializare.
o Reutilizarea produselor COTS se ocupa cu reutilizarea de sisteme mari,
off-the-shelf.
o Problemele reutilizarii de COTS includ lipsa de control asupra
functionalitatii, performantei si evolutiei software-lui ca si probleme de
interoperare.
o Sistemele ERP sunt create prin configurarea unui sistem generic cu
informatii despre procesul economic al beneficiarului.
o Liniile de productie de software sunt aplicatii inrudite dezvoltate in jurul
unui nucleu comun de functionalitate partajata.
Dezvoltarea bazata pe componente
o Ingineria software bazata pe componente (CBSE) este o abordare a
dezvoltarii de software care se bazeaza pe reutilizarea de software.
o Aceasta a aparut datorita faptului ca dezvoltarea orientata obiect a esuat
in a suporta reutilizare eficienta. Clasele ce descriu obiecte singulare sunt
prea detaliate si specifice.
o Componentele sunt mai abstracte decat clasele de obiecte si pot fi
considerate furnizori de servicii de sine statatori.
Caracteristicile esentiale ale CBSE
o Componente independente specificate prin interfetele lor.
o Standarde de componente pentru a facilita integrarea componentelor.
o Middleware care ofera suport pentru inter-operabilitatea
componentelor.
o Un proces de dezvoltare angrenat in reutilizare.
CBSE si principiile de proiectare
 o In plus fata de beneficiile reutilizarii, CBSE este bazata pe principiile de
proiectare solide ale ingineriei software:
o +Componentele sunt independente si nu interfera intre ele;
o +Implementarile componentelor sunt ascunse;
o +Comunicarea se face prin interfete bine definite;
o +Platformele pentru componente sunt partajate si reduc costurile de
dezvoltare.
Problemele CBSE
o Componente
o O componenta ofera un serviciu, indiferent de locul unde se executa
aceasta sau de limbajul in care a fost programata
o +O componenta este o entitate executabila independenta care poate fi
compusa din unul sau mai multe obiecte executabile;
o +Interfata componentei este publicata si toate interactiunile se executa
prin intermediul acestei interfete publice;
Definitii ale conceptului de componenta
o Councill and Heinmann: -O componenta software este un element
software care se conformeaza unui model de componente si care poate fi
repartizata independent si compusa, fara a fi modificata, conform unui
standard de compunere.
o Szyperski: -O componenta software este o unitate de compunere cu
interfete specificate prin contract si cu dependente explicite de context. O
componenta software poate fi repartizata independent si este subiect
pentru compunere de catre terte parti.
Componenta ca furnizor de servicii
o Componenta este o entitate executabila independenta. Nu trebuie
compilata inainte de a fi utilizata cu alte componente.
o Serviciile oferite de o componenta sunt facute disponibile printr-o
interfata si toate interactiunile cu componenta au loc prin aceasta
interfata.
Interfetele unei componente
o Interfata oferita -Defineste serviciile care sunt oferite de componenta
altor componente.
o Interfata solicitata -Defineste serviciile care trebuie sa fie disponibile in
sistem astfel incat componenta sa se execute conform specificatiilor sale.
Componente si obiecte
o Componentele sunt entitati repartizabile.
o Componentele nu definesc tipuri.
o Implementarile componentelor sunt opace.
 o Componentele sunt independente de limbaj.
o Componentele sunt standardizate.
Modele de componente
o Un model de componente este o definitie de standarde pentru
implementarea, documentarea si repartizarea componentelor.
o Exemple de modele de componente: modelul EJB (Enterprise Java Beans)
& modelul COM+ (modelul .NET) && modelul de componente Corba
(Corba Component Model)
o Modelul de componente specifica modul in care trebuie definite
interfetele si elementele ce trebuie incluse in definitia unei interfete.
Suport middleware
o Un model de componente constituie fundamentul pentru middleware
care ofera suport pentru executarea componentelor.
o Implementarile modelului de componente ofera: Servicii de platforma
care permit componentelor scrise conform modelui sa comunice; &
Servicii orizontale care sunt servicii independente de aplicatie utilizate de
diferite componente.
o Pentru a utiliza serviciile oferite de un model, componentele sunt
repartizate intr-un container. Acesta este un set de interfete folosite
pentru a accesa implementarile serviciilor.
Dezvoltarea de componente reutilizabile
o Pentru a fi facute reutilizabile, componentele dezvoltate pentru o
aplicatie specifica trebuie, de obicei, generalizate.
o Este mai probabil ca o componenta sa fie reutilizabila daca ea este
asociata cu o abstractizare stabila a domeniului (business object).
o De exemplu, abstractizarile stabile de domeniu intr-un spital sunt
asociate cu scopul fundamental - medici, pacienti, tratamente, etc.
Dezvoltarea de componente reutilizabile
o Componentele destinate reutilizarii trebuie special construite prin
generalizarea componentelor existente.
o Reutilizabilitatea componentelor
o +Trebuie sa reflecte abstractizarile stabile ale domeniului;
o +Trebuie sa fie cat se poate de independente;
o +Trebuie sa publice exceptii in interfata componentei.
o Exista un targ intre reutilizabilitate si utilizabilitate-Cu cat interfata este
mai generala cu atat este mai mare reutilizabilitatea, dar complexitatea
este mai mare, ceea ce conduce la utilizabilitate mai scazuta.
Modificari pentru reutilizabilitate
o Eliminarea metodelor specifice aplicatiei.
 o Modificarea numelor pentru a le face mai generale.
o Adaugarea de metode pentru a extinde acoperirea.
o Tratarea exceptiilor trebuie sa devina consistenta.
o Adaugarea unei intefete de configurare pentru adaptarea componentei.
o Integrarea componentelor necesare pentru a reduce dependentele.
Componente derivate din sisteme legacy
o Sistemele legacy existente care indeplinesc functii economice utile pot fi
reimpachetate sub forma de componente pentru a fi reutilizate.
o Aceasta implica scrierea unei componente adaptor care implementeaza
interfetele oferite si solicitate si apoi accesarea sistemului legacy.
o Desi costisitoare, aceasta abordare poate fi mai ieftina decat rescrierea
sistemului legacy.
Componente reutilizabile
o Costurile de dezvoltare ale componentelor reutilizabile pot fi mai mari
decat costurile echivalentelor lor specifice. Aceasta majorare de costuri
trebuie sa fie inclusa in costurile organizatiei si nu in cele ale proiectului.
o Componentele generice pot fi mai putin eficiente din punct de vedere al
spatiului si pot avea timpi de executie mai mari decat echivalentele lor
specifice.
Procesul CBSE
o Cand se reutilizeaza componente, este esential sa se faca un compromis
intre cerintele ideale si serviciile reale furnizate de componentele
disponibile.
o Aceasta implica: Dezvoltarea unei schite a cerintelor; & Cautarea
componentelor si apoi modificarea cerintelor conform functionalitatilor
disponibile. & Reluarea cautarii pentru a afla daca exista componente
mai bune care satisfac cerintele revizuite.
Problematica identificarii componentelor
o Increderea. Furnizorul unei componente trebuie sa fie de incredere.
Altfel, in cel mai bun caz o componenta ar putea sa nu functioneze asa
cum este definita, iar in cel mai rau caz poate sa creeze probleme de
securitate.
o Cerintele. Grupuri diferite de componente vor satisface cerinte diferite.
o Validarea. Specificatiile componentei ar putea sa nu fie suficient de
detaliate pentru a permite dezvoltarea de teste cuprinzatoare. &
Componentele ar putea sa aiba si functionalitate nedorita intr-o anumita
aplicatie. Cum se poate testa faptul ca aceasta nu interfera cu aplicatia?
Exemplu: Esuarea lansatorului Ariane 5
 o In 1996, primul test de zbor al rachetei Ariane 5 s-a terminat cu un
dezastru atunci cand lansatorul a scapat de sub control la 37 de secunde
dupa decolare.
o Problema s-a datorat unei componente (sistemul inertial de navigare)
reutilizata dintr-o versiune anterioara a lansatorului, care a esuat
deoarece presupunerile facute atunci cand a fost dezvoltata componenta
nu au fost valabile si pentru Ariane 5.
o Functionalitatea care a esuat din aceasta componenta nu era necesara in
Ariane 5.
Compunerea componentelor
o Procesul de asamblare a componentelor pentru a crea un sistem.
o Compunerea implica integrarea componentelor intre ele si cu
infrastructura.
o Va trebui scris si cod de legatura (‘glue code’) pentru a integra
componentele.
Tipuri de compunere
o Compunere secventiala componentele sunt executate in secventa.
Aceasta implica compunerea interfetelor oferite de fiecare componenta.
o Compunere ierarhica in care una dintre componente apeleaza serviciile
alteia. Interfata oferita de o componenta este compusa cu interfata
solicitata de o alta.
o Compunere aditiva in care interfetele a doua componente sunt puse
impreuna pentru a crea o noua componenta.
Incompatibilitate de interfata
o Incompatibilitate de parametri in care operatiile au acelasi nume dar
sunt de tipuri diferite.
o Incompatibilitate de operatie unde numele operatiilor din interfetele
care se compun sunt diferite.
o Incompletitudine operatii unde interfata oferita de o componenta este
un subset al interfetei solicitata de o alta componenta.
Componente adaptor
o Adreseaza problema incompatibilitatii componentelor prin reconcilierea
interfetelor componentelor care trebuie compuse.
o Sunt necesare tipuri diferite de adaptoare functie de tipul de compunere.
o O componenta addressFinder si o componenta mapper pot fi compuse
prin intermediul unui adaptor care extrage codul postal dintr-o adresa si
il transfera componentei mapper.
Compunerea prin adaptor
 o Componenta postCodeStripper este adaptorul care faciliteaza
compunerea secventiala a componentelor addressFinder si mapper.
Semantica interfetei
o Pentru a decide daca interfetele compatibile sintactic sunt compatibile in
realitate trebuie sa recurgem la documentatiile lor.
o Fie o interfata pentru o componenta PhotoLibrary :
OCL (Object Constraint Language)
o OCL (Object Constraint Language) a fost proiectat pentru a defini
constangeri asociate cu modelele UML.
o Este fundamentat in jurul notiunii de specificare a pre si post conditiilor -
similar cu abordarea utilizata in limbajul Z.
Exemplu: Conditiile componentei PhotoLibrary
o Descrierea OCL asociata cu componenta PhotoLibrary spune ca:
o In biblioteca nu trebuie sa existe o fotografie cu acelasi identificator cu
cea care se adauga;
o Biblioteca trebuie sa existe – se presupune ca la crearea unei biblioteci i
de adauga un singur item;
o Fiecare intrare noua mareste dimensiunea bibliotecii cu 1;
o La extragerea utilizand acelasi identificator se obtine fotografia
adaugata;
o La cautarea in catalog folosind acelasi identificator se obtine intrarea in
catalog realizata pe baza lui.
Compromisurile compunerii
o La compunerea de componente pot sa apara conflicte intre cerintele
functionale si cele non-functionale si conflicte intre nevoia de a furniza
rapid sistemul si evolutia acestuia.
o Trebuie luate decizii cum ar fi:
o +Care compunere de componente este eficienta pentru furnizarea
cerintelor functionale?
o +Ce compunere de componente permite modificari ulterioare?
o +Care vor fi proprietatile emergente ale sistemului compus?
Puncte cheie
o CBSE este o abordare bazata pe reutilizare pentru definirea si
implementarea de componente slab cuplate in sisteme.
o O componenta este o unitate software ale carei functionalitati si
dependente sunt definite complet in interfetele sale.
o Un model de componente defineste un set de standarde pe care
furnizarii si utilizatorii de componente trebuie sa le respecte.
o In timpul procesului CBSE, procesele de inginerie a cerintelor si de
proiectare a sistemului sunt intretesute.
o Compunerea componentelor este procesul de legare a acestora pentru a
crea un sistem.
o La compunerea de componente reutilizabile trebuie scrise adaptoare
care sa reconcilieze interfetele componentelor.
o La alegerea componentelor trebuie considerate functionalitatile
necesare, cerintele non-functionale si evolutia sistemului.