Cursuri IP Prezentări

Arhitectura aplicaţiilor
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 1

Obiective
 Pentru a clarifica organizarea a două modele

fundamentale de sisteme de afaceri: sistemelor de
prelucrare a loturilor și a sistemelor de procesare a
tranzacțiilor.
 Pentru a descrie arhitectura abstractă a sistemelor
de management al resurselor.
 Pentru a explica cum editori generice sunt sisteme
de procesare a evenimentelor.
 Pentru a descrie structura sistemelor de procesare
a limbajului.

Principalele subiecte
 Sisteme de procesare a datelor

 Sisteme de procesare a tranzacțiilor
 Sisteme de procesare a evenimentelor
 Sisteme de procesare a limbajului

Arhitectura aplicațiilor generice
 Sistemele de aplicații sunt concepute pentru a

satisface o nevoie a unei organizații.
 Deoarece afacerile au multe în comun, de
asemenea și sistemele lor de aplicații tind spre o
arhitectură comună care reflectă cerințele
aplicațiilor.
 O arhitectură generică este configurată și
adaptată pentru a crea un sistem care
îndeplinește cerințele specifice.

Utilizări
 Ca un punct de plecare pentru proiectarea
arhitecturală.
 Ca o listă de verificare de proiectare.
 Ca o modalitate de organizare a activitățiilor
echipei de dezvoltare.
 Ca un mijloc de evaluare a componentelor în
vederea reutilizării.
 Ca un vocabular pentru tipuri de aplicatii.

Tipuri de aplicații
 Aplicații de procesare a datelor

• Aplicații bazate pe date, care procesează date în loturi, fără
intervenția explicită a utilizatorului în timpul procesării.
 Aplicații de procesare a tranzacțiilor
• Aplicații centrate pe date, care procesează cererile de utilizator
și actualizează informațiile în baza de date.
 Aplicații de procesare a evenimetelor
• Aplicații în care acțiunile sistemului depind de interpretarea
evenimentelor din mediul sistemului.
 Aplicații de procesare a limbajului
• Aplicații în care intențiile utilizatorilor sunt specificate într-un
limbaj formal care este procesat și interpretat de sistem.

Exemple de tipuri de aplicații
 Aplicații de procesare a datelor
• Sisteme de facturare;
• Sisteme de salarizare.
 Aplicații de procesare a tranzacțiilor
• Sisteme de e-commerce (comerț electronic);
• Sisteme de rezervare.
 Aplicații de procesare a evenimetelor
• Procesoare de text;
• Sisteme de timp real.
 Aplicații de procesare a limbajului
• Compilatoare;
• Interpretor de comandă.

Sisteme de procesare a datelor
 Sisteme care sunt centrate pe date, în care bazele

de date utilizate sunt de obicei cu grad de
magnitudine mai mare decât software-ul în sine.
 Datele sunt de intrare și ieșire în loturi:
• Intrare: un set de coduri clienți asociate cu citirile de
contor de energie electrică;
• Ieșire: un set corespunzător de facturi, câte una pentru
fiecare client.
 Sistemele de procesare a datelor au de obicei o
structură de intrare-procesare-ieșire.

Modelul intrare-procesare-ieșire

Intrare-procesare-ieșire
 Componenta de intrare citește datele dintr-un fișier

sau din baza de date, verifică valabilitatea sa și
adaugă în coada cu date valide pentru prelucrare.
 Componenta de procesare ia o tranzacție din
coada de intrare cu datele valide, efectuează
calculele și creează o nouă înregistrare cu
rezultatele.
 Componenta de ieșire citește aceste înregistrări, le
formatează corespunzător și le scrie în baza de
date sau le trimite la o imprimantă.

Diagrame de flux de date
 Arată modul în care datele sunt procesate în timp ce

trece printr-un sistem.
 Transformările sunt reprezentate ca dreptunghiuri
rotunjite, între ele fluxurile de date apari ca săgeți, iar
fișierele/datele sunt reprezentate în dreptunghiuri.

Diagrama de flux de date a grilei
de salarizare

Sisteme de procesare a tranzacțiilor
 Procesarea cererii utilizatorilor pentru obținerea

sau actualizarea informației din baza de date.
 Din perspectivă utilizator o tranzacție este:
• Orice secvență de operații coerentă care să satisfacă
un obiectiv;
• De exemplu – găsirea orarului de zboruri din Londra
către Paris.
 Utilizatorii fac cereri asincrone, care sunt prelucrate
de un manager de tranzacții.

Procesarea tranzacțiilor

Organizarea sistemului bancomat (ATM)

Procesarea tranzacțiilor intermediare
(middleware)
 Intermediarul de management a tranzacțiilor sau
monitorul de teleprocesare tratează comunicarea
cu diferite tipuri de terminale (de exemplu
bancomat și terminale numărătoare), serializează
și trimite datele pentru prelucrare.
 Procesul de interogare are loc în baza de date a
sistemului și rezultatele sunt trimise înapoi prin
managerul de tranzacție la terminalul utilizatorului.

Managmentul de tranzacție

Arhitectura sistemelor de informare
 Sistemele de informare au o arhitectura

generală, care poate fi organizate ca o
arhitectură stratificată.
 Straturi:
• Interfață utilizator
• Comunicații utilizator
• Regăsire informații
• Bază de date

Structura sistemelor de informare

Architectura LIBSYS
 LIBSYS, sistemul de bibliotecă, este un exemplu
pentru un sistem de informare.
 Strat de comunicații utilizator:
• Componentă de login;
• Manager de formular și de interogare;
• Manager de imprimare;
 Strat de regăsire informații:
• Căutare distribuite;
• Regăsire document;
• Manager de drepturi;
• Contabilitate.

Organizația LIBSYS

Sisteme de alocare a resurselor
 Sisteme care gestionează o cantitate fixă de

resurse (bilete de fotbal, cărțile într-o librărie etc.) și
să aloce această utilizatorilor.
 Exemple de sisteme de alocare a resurselor:
• Sistemul calendar: resursele alocate sunt perioade de
timp;
• Sistemul de bibliotecă: resursele sunt cărți și alte
obiecte de împrumutat;
• Sistemul de control a traficului aerian: resursa este
spațiul aerian.

Arhitectura sistemului de alocare a
resurselor
 Tot este un sistem stratificat, care include
următoarele straturi:
• O bază de date a resurselor;
• Un set de reguli care descrie modul în care sunt
alocate resursele;
• Un manager de resurse;
• Un manager de repartizare a resurselor;
• Un sistem de autentificare;
• Managerul de interogare;
• Componentă de livrare a resurselor;
• Interfață utilizator.

Straturile sistemelor de alocare a
resurselor

Implementarea sistemului stratificat
 Fiecare strat poate fi pus în aplicare ca o
componentă mare, care rulează pe un server
separat. Acesta este modelul arhitectural cel mai
frecvent utilizat pentru sistemele bazate pe web.
 Pe o singură mașină, straturile din mijloc sunt
implementate ca un program separat, care
comunică cu baza de date prin intermediul API
său.
 Componentele mici din straturi pot fi implementate
ca servicii web.

Arhitectura sistemului e-commerce
 Sistemele de e-commerce sunt sisteme de
management al resurselor bazate pe Internet, care
acceptă comenzi electronice pentru bunuri sau
servicii.
 Ele sunt de obicei organizate cu ajutorul unui
arhitectură multi-nivel cu straturi de aplicație
asociate cu fiecare nivel.

Sisteme de procesare a evenimentelor
 Aceste sisteme răspund la evenimentele din

mediul sistemului.
 Caracteristica lor cheie este că momentul
evenimentului este imprevizibil, deci arhitectura
trebuie să fie organizat ca să le trateze.
 Multe sisteme comune, cum ar fi procesoare de
cuvinte, jocuri etc., sunt sisteme de procesare a
evenimentelor.

Sisteme de editare
 Sisteme de timp real și sistemele de editare sunt

cele mai comune tipuri de sisteme de procesare a
evenimentelor.
 Caracteristici:
• Un utilizator;
• Trebuie să ofere un răspuns rapid la acțiunile
utilizatorului;
• Organizate pentru tranzacții lungi, astfel pot include
facilități de recuperare.

Componentele sistemelor de editare
 Sistemele de editare sunt în mod natural orientate pe
obiecte:
• Monitor (Screen) – monitorizează memoria de ecran și
detectează evenimentele;
• Eveniment (Event) - recunoaște evenimentele și le trece în
vederea prelucrării;
• Comandă (Command) - execută o comandă utilizator;
• Editorul de date (Editor Data) - gestionează structura datei;
• Date auxiliare (Ancillary data) - gestionează alte date, cum ar
fi stiluri și preferințe;
• Sistemul de fișiere (File system) - gestionează fișier de
intrare și ieșire (I/O);
• Afișare (Display) - actualizează ecranul.
Arhitectura sistemului de editare
Fi l e System
Save
Open
A nci l l ary data Edi tor data
A nci l l ary Edi ti ng

commands commands
Command
Di spl ay
Interpret
Update
Event
Process
Screen
Refresh

Sisteme de procesare a limbajului
 Acceptă ca intrare un limbaj natural sau artificial și
generează o altă reprezentare a acestei limbi.
 Poate include un interpretor, care acționează pe
instrucțiunile din limbajul care este în curs de procesare.
 Folosit în situațiile în care cel mai simplu mod de a
rezolva o problemă este de a descrie un algoritm sau de
a descrie datele de sistem.
• Instrumente meta-case procesează descrierile a
instrumentelor, normele metodelor etc și instrumente de
generare.

Sistem de procesare a limbajului

Componente de procesare a limbajului
 Analizor lexical (Lexical analyser)

 Tabela de simboluri (Symbol table)
 Analizor de sintaxă (Syntax analyser)
 Arbore de sintaxă (Syntax tree)
 Analizor semantic (Semantic analyser)
 Generator de cod (Code generator

Modelul de flux de date a unui compilator

Modelul depozitar al unui compilator

Puncte cheie
 Modelele generice de arhitecturi de aplicații ne ajută

să înțelegem și să comparăm aplicațiile.
 Clasele importante de aplicare sunt: sisteme de
procesare a datelor, sisteme de procesare a
tranzacțiilor, sisteme de procesare a evenimentelor
și sisteme de procesare a limbajului.
 Sistemele de prelucrare a datelor funcționează în
modul lot și au o structură de intrare-procesare-
ieșire.

Puncte cheie
 Sistemele de procesare a tranzacțiilor permit accesarea
și modificarea informației într-o bază de date; acest
lucru este posibil de la distanță și de mai mulți
utilizatori.
 Sistemele de procesare a evenimentelor includ editori
și sisteme în timp real.
 Într-un editor sunt detectate evenimentele de interfață
utilizator și este modificată structura de date (in-store).
 Sistemele de procesare a limbajului traduc textul de la
o limbă la alta și pot interpreta instrucțiunile specificate.

Proiectare orientata pe obiecte

Obiective
 Explicarea modului în care un design
software poate fi reprezentat ca un set de
obiecte care interacționează si gestionează
propriile lor operațiuni de stare
 Descrierea activităților în procesul de
proiectare orientat pe obiect
 Introducerea diferitelor modele care pot fi
folosite pentru a descrie un design orientat
pe obiect
 Aratarea modului în care UML poate fi folosit
pentru a reprezenta aceste modele
Subiecte acoperite
 Obiecte si clase de obiecte
 Un proces de design orientat pe obiecte
 Evolutia design-ului

Dezvoltarea obiectelor orientate
 Analiza, proiectarea si programarea obiectelor
orientate, sunt legate, dar distincte.
 OOA se ocupă cu dezvoltarea unui model de obiect
al domeniului de aplicare.
 OOD se ocupă cu dezvoltarea unui model de sistem
orientat pe obiect pentru a pune în aplicare cerințele.
 OOP este preocupat de realizarea unui OOD
folosind un limbaj de programare OO , cum ar fi
Java sau C ++

Caracteristicile OOD
 Obiectele sunt abstractizări ale lumii reale sau
entități de sistem și de gestionare înșași .
 Obiectele sunt independente și încapsulează
informații de stat și de reprezentare .
 Funcționalitatea sistemului este exprimată în termeni
de servicii de obiecte .
 Zonele de date comune sunt eliminate. Obiectele
comunica prin mesaje de trecere.
 Obiectele pot fi distribuite și se pot executa
secvențial sau în paralel.

Interactiunea obiectelor
o1: C1 o3:C3 o4: C4

state o1 state o3 state o4
ops1() ops3 () ops4 ()
o2: C3 o6: C1 o5:C5

state o2 state o6 state o5
ops3 () ops1 () ops5 ()

Avantajele OOD
 Intreținere mai ușoară . Obiectele pot fi
înțelese ca entități de sine stătătoare.
 Obiectele sunt componente potențial
reutilizabile.
 Pentru unele sisteme , poate exista o
cartografiere evidenta din entități din lumea
reală pentru obiectel de sistem.

Obiectele și clasele de obiecte
 Obiectele sunt entități dintr-un sistem
software care reprezintă cazuri din lumea
reală și entități de sistem.
 Clase de obiecte sunt modele pentru
obiecte.
 Ele pot fi folosite pentru a crea obiecte .
 Clasele de obiecte pot moșteni atribute și
servicii de la alte clase de obiecte .

Obiectele și clasele de obiecte
Un obiect este o entitate care are o stare și un set definit de operații
care operează pe această stare . Starea este reprezentata ca un set de
atribute obiect . Operațiunile asociate cu obiectul, furnizeaza
serviciile altor obiecte ( clienți) care solicită aceste servicii când
este necesar un anumit calcul .
Obiectele sunt create în funcție de unele definiții de clasă obiect . O

definiție de clasă obiect servește ca model pentru obiecte . Acesta
include declarații ale tuturor atributelor și serviciilor care ar trebui
să fie asociate cu un obiect din acea clasă .

Limbajul de modelare unificat
 Mai multe notații diferite pentru a descrie modele
orientate obiect au fost propuse în anii 1980 și 1990.
 Limbajul de modelare unificat este o integrare a
acestor notații .
 Acesta descrie notații folosite pentru diferite modele
ce pot rezulta din analiza și proiectarea OO.
 Aceasta este acum un standard de facto pentru
modelarea OO.

Clasa de obiecte angajat (UML)
Emplo yee
name: string
address: string
dateOfBir th: Date
employ eeNo: integer
socialSecurity No: string
depar tment: Dept
manager: Employ ee
salar y : integer
status: { current, left, retired}
taxCode: integer
. ..
j oin ()
leave ()
retire ()
changeDetails ()

Comunicare obiect
 Conceptual , obiectele comunică prin schimb de
mesaje .
 Mesaje
• Numele serviciului solicitat de obiectul apel;
• Copii ale informațiilor necesare pentru a executa serviciul
și numele unui titular pentru rezultatul serviciului .
 În practică , mesajele sunt adesea puse în aplicare
prin apeluri de proceduri
• Nume = Numele procedurii ;
• Informatii= Lista de parametri.

Exemple de mesaje
// Apeleaza o metodă asociată cu un buffer
// obiect care returnează valoarea următoare
// in buffer
v = circularBuffer.Get () ;
// Apeleaza metoda asociata cu un

// obiect termostat care stabileste
// temperatura care trebuie mentinuta
thermostat.setTemp (20) ;

Generalizarea și moștenirea
 Obiectele sunt membri de clase care definesc
tipurile de atribute și operații
 Clasele pot fi aranjate într-o ierarhie de clasă în
cazul în care o clasă ( super- clasă ) este o
generalizare a uneia sau mai multor alte clase ( sub-
clase)
 O sub- clasă moștenește atributele și operațiunile
din super- clasa sa și poate adăuga metode sau
atribute proprii noi .
 Generalizarea în UML este implementata ca
moștenirea în limbajele de programare OO .

O ierarhie generalizata
Employee
Manager Programmer
budgetsControlled proj ect

progLanguages
dateAppointed
Proj ect Dept. Strateg ic

Manager Manager Manager
proj ects dept responsibilities

Avantajele moștenirii
 Este un mecanism de abstractizare ce poate
fi folosit pentru a clasifica entități
 Este un mecanism reutilizabil atât pentru
nivelului de programare cat si design
 Graficul de moștenire este o sursă de
cunoaștere organizațională cu privire la
domenii și sisteme.

Probleme cu moștenire
 Clasele de obiecte nu sunt de sine
stătătoare, ele nu pot fi înțelese fără a face
referire la super- clasele lor.
 Designerii au tendința de a refolosi ierarhiile
create în timpul analizei . Poate duce la
ineficiențe semnificative .
 Graficele de moștenire, de analiză ,
proiectare și implementare au funcții diferite
și ar trebui menținute separat

Asociatii UML
 Obiectele și clasele de obiecte participă în relații cu
alte obiecte și clase de obiecte .
 În UML , o relație generalizată este indicată de o
asociație.
 Asociațiile pot fi adnotate cu informații ce descriu
asocierea .
 Asociațiile sunt generale , dar pot indica faptul că un
atribut al unui obiect este un obiect asociat sau că o
metodă se bazează pe un obiect asociat .

Un model de asociere
Employ ee Depar tment

is-member-of
is-managed-by
manages
Manager

Obiecte concurente
 Natura ca obiecte entități de sine stătătoare
le fac potrivite pentru punerea în aplicare
concomitent .
 Modelul - de mesaje de comunicare obiect
poate fi implementat direct dacă obiectele
sunt difuzate pe procesoare separate, într-un
sistem distribuit

Servere și obiecte active
 Servere .
Obiectul este implementat ca un proces paralel ( server) cu
puncte de intrare corespunzătoare de a se opune
operațiunilor. Dacă nu se fac apeluri la aceasta, obiectul
însuși și așteaptă suspendă pentru cererile suplimentare
pentru serviciu .
 Obiecte active
Obiectele sunt implementate ca procese paralele și a
statului de obiect interne pot fi modificate de obiectul în
sine și nu doar prin apeluri externe

Obiecte transponder active
 Obiectele active pot avea atributele lor
modificate prin operațiuni , dar poate, de
asemenea sa le actualizeze în mod autonom
cu ajutorul operațiunilor interne
 Un obiect Transponder difuzează poziția
unei aeronave . Poziția poate fi actualizată
cu ajutorul unui sistem de poziționare prin
satelit . Obiectul actualizează periodic poziția
de triangulație de la sateliți .

Un obiect transponder activ
class Transponder extends Thread {
Position currentPosition ;
Coords c1, c2 ;
Satellite sat1, sat2 ;
Navigator theNavigator ;
public Position givePosition ()

{
return currentPosition ;
}
public void run ()

{
while (true)
{
c1 = sat1.position () ;
c2 = sat2.position () ;
currentPosition = theNavigator.compute (c1, c2) ;
}
} //Transponder

Java threads
 Threads in Java este un construct simplu
pentru punerea în aplicare a obiectelor
concurente
 Threads-urile trebuie să includă o metoda
numita run() și acest lucru este pornit prin
sistemul de run-time Java
 Obiectele active includ în mod tipic o buclă
infinită , astfel încât acestea sunt
întotdeauna efectuarea calculului .

Un proces de proiectare obiect
orientat
 Procesele de proiectare structurate implică
dezvoltarea unui număr de modele de
sisteme diferite.
 Ei au nevoie de o mulțime de eforturi pentru
dezvoltarea și întreținerea acestor modele și,
pentru sistemele mici , acest lucru nu poate
fi cu cost-eficient .
 Cu toate acestea , pentru sistemele mari
dezvoltate de grupuri diferite modelele de
proiectare sunt un mecanism de comunicare
esențial.
Etapele procesului
 Subliniază activitățile cheie , fără a fi legat de

nici un proces de proprietate , cum ar fi RUP
• Definirea contextului și modurile de utilizare a
sistemului;
• Proiectarea arhitecturii sistemului;
• Indentificarea principalelor obiecte de sistem;
• Elaborarea modelelor de proiectare ;
• Precizați interfețele obiect.

Descrierea sistemului de vreme
• Un sistem de cartografiere de vreme este necesar pentru a genera hărți

meteorologice în mod regulat folosind date colectate de la stații meteo la
distanță și alte surse de date , cum ar fi de observatori meteo , baloane și
sateliți . Stațile meteorologice transmit datele lor la un calculatorul din zona
lor, ca răspuns la o cerere de la acea masina.
• Sistemul informatic din acea zona validează datele colectate și le

integrează cu datele din surse diferite . Datele integrate sunt arhivate și ,
folosind date de la această arhivă și o bază de date cu harti digitalizate sunt
create un set de hărți meteo locale . Harta poate fi tipărita pentru a fi
distribuita sau pot fi afișate într-un număr de formate diferite.

Contexte și modele de utilizare a
sistemului
 Dezvolta o înțelegere a relațiilor dintre software fiind
proiectat și mediul său extern
 Contextul sistem
• Un model static ce descrie alte sisteme din mediul
înconjurător. Foloseste un model de subsistem pentru a
arăta alte sisteme . În urma prezentarii ,sistemele din jurul
sistemului de stație meteo.
 Model de utilizare a sistemului
• Un model dinamic care descrie modul în care sistemul
interactioneaza cu mediul său . Utilizeaza cazuri pentru a
arăta interacțiunile.

Arhitectura stratificata
Datadisplay layer whereobjectsare

concerned with preparing and
« subsy stem» presenting the data in a human-
Data display readable form
Data archiving lay er where obj ects

« subsy stem» areconcernedwithstoringthedata
Data archiving for future processing
Dataprocessinglayer whereobjects
« subsy stem» are concerned with checking and
Data processing integ rating the collected data
Data collection lay er where obj ects

« subsy stem» are concerned with acquiring data
Data collection from remote sources

Subsistemele din sistemul de cartografiere de
vreme
« subsy stem»
Data collection « subsy stem»
Data display
Observer Satellite
User
User Map
inter
interface
face display
Comms
Weather Map
Map printer
station Balloon
« subsy stem» « subsy stem»

Data processing Data archiving
Data
Data
Data Data storage
storage
checking integ ration
Map store Data store

Modele de utilizare
 Modelele de utilizare sunt folosite pentru a
reprezenta fiecare interacțiune cu sistemul
 Un model de utilizare prezintă caracteristicile
de sistem ca elipse și entitatea care
interacționează ca o figură băț.

Cazuri folosite pentru stația meteo
Star tup
Shutdown
Repor t
Calibrate
Test

Descrierea cazurilor folosite
System Weather station
Use-case Report
Actors Weather data collection system, Weather station
Data The weather station sends a summary of the weather data that has been
collected from the instruments in the collection period to the weather data
collection system. The data sent are the maximum minimum and average
ground and air temperatures, the maximum, minimum and average air
pressures, the maximum, minimum and average wind speeds, the total
rainfall and the wind direction as sampled at 5 minute intervals.
Stimulus The weather data collection system establishes a modem link with the
weather station and requests transmission of the data.
Response The summarised data is sent to the weather data collection system
Comments Weather stations are usually asked to report once per hour but this
frequency may differ from one station to the other and may be modified in
future.

Design arhitectural
 După interacțiunile dintre sistem și mediul său au
fost înțelese , să utilizați aceste informații pentru
proiectarea arhitecturii sistemului.
 O arhitectură stratificată așa cum sa discutat în
capitolul 11 este adecvata pentru stația meteo.
• Strat de interfață pentru manipularea comunicațiilor ;
• Strat de colectare a datelor de gestionare a
instrumentelor;
• Instrumente strat de colectare a datelor .
 In mod normal, nu ar trebui sa fie mai mult de 7
entități într-un model arhitectural

Arhitectura statiei meteo

Indentificare obiect
 Identificarea obiectelor (sau claselor de
obiecte ) este partea cea mai dificilă in
proiectarea orientata pe obiecte.
 Nu există nici o " formulă magică " pentru
identificarea obiectelor . Ea se bazează pe
calificare , experienta si cunoasterea
domeniul de proiectare de sistem ;
 Identificarea obiect este un proces iterativ .
Este putin probabil sa primeasca dreptul
prima data
Abordări de identificare
 Utilizați o abordare gramaticală bazată pe o
descriere în limbaj natural a sistemului ( de la
metoda OOD Hood ).
 Bazati identificarea pe lucruri tangibile din domeniul
de aplicare
 Utilizați o abordare comportamentală și identificarea
obiectelor sa fie bazata pe ce participă si in ce
comportament .
 Utilizați o analiză pe bază de scenarii . Sunt
identificate obiectele, atributele și metodele din
fiecare scenariu.

Descrierea statiei meteo
O stație meteo este un pachet de instrumente software controlate ,
care colectează date , efectuează unele procese a datelor și
transmite aceste date pentru prelucrare ulterioară. Instrumentele
includ termometre de aer și de la sol , un anemometru , un vânt cu
palete , un barometru și un ecartament de ploaie
Datele sunt colectate periodic .
Atunci când o comandă este eliberata pentru a transmite datele

meteo, statia meteo proceseaza si optimizeaza datele colectate.
Datele optimizate sunt transmise calculatorului pentru
cartografiere când primește o cerere.

Clasele de obiecte ale statiei
meteo
 Termometru la sol , Anemometru , Barometru
• Obiectele domeniului de aplicare care sunt obiecte " hardware " legate
de instrumentele din sistem.
 Statia meteo
• Interfața de bază a stației meteo cu mediul său . Prin urmare, reflectă
interacțiunile identificate în modelul de cazuri folosite .
 Date meteo
• Încapsulează datele sintetizate din instrumentele.

Clasele de obiecte ale statei
meteo
WeatherStation WeatherData
identifier airTemper atures

groundT emper atures
repor tWeather ()
windSpeeds
calibrate (instruments)
windDirections
test ()
pressures
star tup (instruments)
rainfall
shutdown (instruments)
collect ()
summarise ()
Ground Anemomet er Baromet er

thermomet er pressure
windSpeed
temper ature windDirection height
test () test ()
test ()
calibrate () calibrate ()

Alte obiecte și obiecte rafinament
 Utilizați cunoștințele din domeniu pentru a identifica

mai multe obiecte și operații.
• Stațile meteorologice ar trebui să aibă un identificator unic ;
• Stațile meteorologice sunt situate la distanță astfel eșecurile de
instrumente trebuie să fie raportate în mod automat . Prin
urmare, atributele sunt necesare operațiuni de auto- control.
 Obiective pasive sau active
• În acest caz , obiectele sunt pasive și colectează datele la
cerere , mai degrabă decât în mod autonom . Aceasta introduc
flexibilitate în detrimentul timpul procesului de control.

Modele de proiectare
 Modelele de proiectare arata obiectele si
clasele de obiecte și relațiile dintre aceste
entități.
 Modelele statice descriu structura statică a
sistemului în termeni de clase de obiecte și
relații .
 Modelele dinamice descriu interacțiunile
dinamice dintre obiecte .

Exemple de modele de design
 Modele subsistem care arată grupările logice de
obiecte în subsisteme coerente.
 Modele de secvență care arată secvența
interacțiunilor obiectului.
 Modele de mașini de stare care arată modul în care
obiectele individuale schimba starea.
 Alte modele include cazuri utilizate de modele ,
modele de agregare , modele generalizare , etc.

Modelele subsistemului
 Arată modul în care este organizată
proiectarea în grupuri de obiecte legate
logic.
 În UML , acestea sunt afișate folosind
pachete - un constructor de încapsulare .
Acesta este un model logic . Organizarea
efectivă a obiectelor din sistem pot fi diferite .

Subsisteme meteo
« subsy stem» « subsy stem»
Inter face Data collection
CommsController WeatherData
Instrument
WeatherStation Status
« subsy stem»
Instruments
Air
thermometer RainGauge Anemometer
Ground
thermometer Barometer WindVane

Modele de secventa
 Modelele de secvență arată succesiunea
interacțiunilor dintre obiecte care are loc.
• Obiectele sunt aranjate orizontal în partea de
sus.
• Timpul este reprezentat vertical pentru
modelele care se citesc de sus în jos.
• Interacțiunile sunt reprezentate de săgeți
etichetate , diferite stiluri de săgeți reprezintă
diferite tipuri de interacțiuni.
• Un dreptunghi subțire în linia de viata a unui
obiect reprezintă timpul atunci când obiectul
este obiectul de control în sistem.

Secventa de colectare a datelor
:CommsController :WeatherStation :WeatherData
request (repor t)
acknowledge ()
repor t ()
summarise ()
send (repor t)
reply (repor t)
acknowledge ()

Diagrame de stare
 Arată modul în care obiectele răspund la diferite
cereri de servicii și tranzițiile de stat declanșate de
aceste cereri.
• Dacă obiectul de stare este Shutdown() atunci răspunde la un
mesaj de Starup( );
• În starea de așteptare obiectul este in așteptare de alte mesaje ;
• Daca reportWeather ( ) trece la rezumarea de stare ;
• Daca calibrare ( ) sistemul se mută într-o stare de calibrare ;
• O stare de colectare este introdusa atunci când este primit un
semnal de ceas.

Diagrama satiei de meteo
Operation calibrate ()
Calibrating
calibration OK
star tup () test ()

Shutdown Waiting Testing
shutdown () transmission done test complete
Transmitting
clock collection
done repor tWeather ()
weather summary
complete
Summarising
Collecting

Interfata obiectului specificat
 Interfețele obiectelor trebuie să fie specificate, astfel
încât obiectele și alte componente pot fi proiectate în
paralel .
 Designeri ar trebui să evite proiectarea reprezentari
interfetei , dar ar trebui să ascundă acest lucru în
obiectul în sine .
 Obiectele pot avea mai multe interfețe care sunt
puncte de vedere cu privire la metodele prevăzute .
 UML folosește diagrame de clase pentru
specificarea interfeței , dar Java poate fi de
asemenea utilizata .

Interfata statiei meteo
interface WeatherStation {
public void WeatherStation () ;
public void startup () ;

public void startup (Instrument i) ;
public void shutdown () ;

public void shutdown (Instrument i) ;
public void reportWeather ( ) ;
public void test () ;

public void test ( Instrument i ) ;
public void calibrate ( Instrument i) ;
public int getID () ;
} //WeatherStation

Evolutia Design-ului
 Ascunderea informațiilor privilegiate in obiect e
înseamnă că modificările aduse unui obiect nu
afectează alte obiecte într-un mod imprevizibil .
 Facilitatea monitorizarii poluării se adaugă la stațiile
meteorologice . Acestea esantioneaza aerul si
calculeaza suma diferitilor poluanti din atmosfera.
 Informatiile despre poluare sunt transmise cu datele
meteo.

Modificarile necesare
 Adauga o clasă obiect numit Calitatea
aerului , ca parte a WeatherStation
 Adăugați operații reportAirQuality la
WeatherStation . Modifica software-ul de
control pentru a colecta informatii despre
poluare.
 Adauga obiecte reprezentând instrumente de
monitorizare a poluării

Monitorizarea poluarii
WeatherStation
Air quality
identifier
NOData
repor tWeather () smok eData
repor tAirQuality () benz eneData
calibrate (instruments)
test () collect ()
star tup (instruments) summarise ()
Pollution monitoring instruments
NOmeter SmokeMeter
BenzeneMeter

Puncte cheie
 OOD este o abordare pentru a proiecta astfel încât
componentele de proiectare au propriile lor stari si
operatii.
 Obiectele trebuie să aibă operațiuni de constructor și
de inspecție . Ele oferă servicii altor obiecte .
 Obiectele pot fi implementate secvențial sau
concurent
 Unified Modeling Language prevede diferite notații
pentru definirea diferitelor modele de obiecte .

Puncte cheie
 O serie de modele diferite pot fi produse în
timpul unui proces de proiectare orientat pe
obiecte. Acestea includ modele de sistem
statice și dinamice.
 Interfețele obiect ar trebui să fie definite cu
precizie folosind de exemplu, un limbaj de
programare ca Java .
 Proiectarea orientata pe obiecte poate
simplifica evolutia sistemului.

Proiectare software-ului în timp real

Obiective
 Explicarea conceptului de sistem în timp real
și de ce aceste sisteme sunt implementate
de obicei ca și procese concurente
 Descrierea unui proces de proiectare a
sistemelor în timp real
 Explicarea rolului pe care îl au sistemele de
operare în timp real
 Introducerea arhitecturilor generice de
procese pentru sistemele de monitorizare,
control și achiziție de date

Subiecte abordate
 Proiectare de sisteme
 Sisteme de operare în timp real
 Sisteme de control și monitorizare
 Sisteme de achiziție de date

Sisteme în timp real
 Sisteme care își monitorizează și
controlează mediul
 Inevitabil sunt asociate cu componente
hardware
• Senzori: Colectează date din mediul lor;
• Actuatoare: Modifică mediul sistemului;
 Timpul este critic.Sistemele în timp real
TREBUIE să răspundă în anumiți timpi
specificați

Definiții
 Un sistem în timp real este un sistem software în
care funcționarea corectă depinde de rezultatele
produse de către sistem și de momentul în care
aceste rezultate au fost produse
 Un sistem în timp real soft este un sistem a cărui
operații sunt degradate dacă rezultatele nu sunt
produse conform cerințelor de timp.
 Un sistem în timp real hard este un sistem a
cărui operații sunt incorecte dacă rezultatele nu
sunt produse conform cerințelor de timp.

Sisteme stimul/răspuns
 Fiind dat un stimul, sistemul trebuie să producă un
răspuns într-un timp specificat.
 Stimuli periodici. Stimuli care au loc la intervale
predictibile de timp
• De exemplu , un senzor de temperatură poate fi interogat
de 10 ori pe secundă.
 Stimuli aperiodici. Stimuli care au loc la intervale
nepredictibile de timp
• De exemplu , o eroare de alimentare a sistemului poate
declanșa o întrerupere care trebuie să fie procesată de
sistem.

Considerații arhitecturale
 Din cauza cerințelor de timp create de diferiți
stimuli/răspunsuri sistemul trebuie să permită
comutarea rapidă între diferite programe de tratare a
stimulilor.
 Cerințele de timp a diferiților stimuli sunt diferite deci
o buclă secvențială simplă nu este de obicei
adecvată.
 Sistemele în timp real sunt așadar proiectate ca și
procese cooperative care au un executiv în timp real
pentru a controla aceste procese.

Model al unui sistem în timp real

Procese senzor/actuator

Elemente ale sistemului
 Procese pentru controlul senzorilor
• Colectează informații de la senzori.Pot amortiza
informația colectată ca și răspuns la un stimul
 Procesor pentru date
• Procesează informația colectată și modifică
răspunsul sistemului.
 Procese pentru controlul actuatoarelor
• Generează semnale de control pentru
actuatoare.

Programare în timp real
 Sistemele în timp real hard trebuie să fie
programate în limbaj de ansamblare pentru a
asigura respectarea termenelor .
 Limbajele cum ar fi C permit scrierea de
programe eficiente dar nu au constructori
care suporta concurență sau resurse
comune.

Java ca și un limbaj în timp real
 Java suportă o concurență ușoară(fire de execuție și
metode sincronizate) și poate fi folosit pentru unele
sisteme în timp real soft.
 Java 2.0 nu este potrivit pentru programare în timp
real hard dar acuma există versiuni în timp real de
Java care adresează probleme cum ar fi
• Imposibilitatea de a specifica timpul de execuție a firelor;
• Diferite sincronizări pentru diferite mașini virtuale;
• Colectarea incontrolabilă a deșeurilor;
• Imposibilitatea de a afla mărimea cozii pentru resursele
partajate;
• Imposibilitatea de a accesa hardware-ul sistemului;
• Imposibilitatea realizării unei analize de timp sau spațiu.

Proiectarea sistemului
 Proiectarea componentelor software și
hardware în asociere cu sistemul. Funcții
partiționate fie hardware sau software.
 Deciziile de proiectare ar trebui sa fie făcute
pe baza cerințelor non-funcționale ale
sistemului.
 Partea hardware aduce o performanță mai
buna dar o dezlvoltare mai lungă și
posibilități de modificare mai puține.

Procesul de proiectare a sistemelor T-R
 Identificarea stimulilor care trebuie să fie
procesați și răspunsurile necesare acestor
stimuli.
 Pentru fiecare pereche de stimul răspuns
trebuie identificate constrângerile de timp.
 Partajarea stimulilor și a răspunsurilor în
procese concurente.Un proces poate fi asociat
cu fiecare clasă de stimuli și răspuns.

Procesul de proiectare a sistemelor T-R
 Proiectarea de algoritmi pentru procesarea
fiecărei clase de stimuli și răspuns.Acești
algoritmi trebuie să respecte cerințele de
timp date.
 Proiectarea unui alocator care să asigure
aceea că procesele sunt pornite în timp util
pentru a satisface timpul limită.
 Integrare folosind un sistem de operare în
timp real

Constrângeri de timp
 Pot necesita simulări și experimente extinse
pentru a asigura că acestea sunt satisfăcute
de sistem.
 Pot însemna aceea că unele strategii de
proiectare cum ar fi programarea orientată
pe obiect nu pot fi folosite.
 Pot obliga să se folosească sisteme de
programare de nivel de bază pentru motive
de performanță.

Modelarea sistemelor în timp real
 Efectul unui stimul într-un sistem în timp real poate
provoca tranziții dintr-o stare în alta.
 Automate cu stări finite pot fi folosite pentru
modelarea sistemelor în timp real.
 Automatele cu stări finite au o lipsă de structură,
chiar și sisteme mai simple pot avea un model mai
complex
 UML (Unified modelling language) include notații
pentru stările modelului de automat
 Vezi Capitolul 8 pentru mai multe exemple de stări a
modelurilor de automate.

Modelul de stări a unei pompe de
benzină

Sisteme de operare în timp real
 Sistemele de operare în timp real sunt sisteme de
operare specializate care administrează procesele
într-un STR.
 Responsabile pentru administrarea proceselor și
alocarea resurselor(procesor și memorie).
 Pot avea la baza un kernel standard care este
neschimbat sau modificat pentru o aplicație
particulară.
 Nu includ în mod normal facilități cum ar fi
administrarea de fișiere.
14
Componente ale sistemului de
operare
 Ceas în timp real
• Aduce informații pentru alocarea proceselor .
 Gestionator de întreruperi
• Administrează cereri aperiodice către sistem.
 Alocator
• Alege care este următorul proces care va fi rulat.
 Administrator de resurse
• Alocă resursele de procesor și memorie.
 Dispecer
• Pornește execuția proceselor.

Componente ale sistemelor non-stop
 Manager de configurații
• Responsabil pentru reconfigurarea dinamică a sistemului
sofware și hardware.Modulele hardware pot fi schimbate
și software-ul îmbunătățit fără ca sistemul să fie oprit.
 Manager de erori
• Responsabil pentru detecția erorilor software și hardware
umând să aleagă rezolvări automate pentru a asigura
aceea că sistemul își continuă activitatea.

Componente ale sistemului de
operare în timp real

Prioritatea proceselor
 Procesul unui anumit tip de stimul trebuie câteodată
să aibă prioritate.
 Prioritate la nivel de întrerupere prin care prioritatea
cea mai mare este alocată procesului care dorește
un timp de răspuns cât mai rapid.
 Prioritate la nivel de ceas alocată proceselor
periodice.
 Pe lângă aceste niveluri de prioritate se pot atribui și
altele.

Tratarea întreruperilor
 Controlul este transferat automat către o locație
predeterminată de memorie.
 Această locație conține o instrucțiune de salt către o
rutină de tratare a întreruperilor.
 Alte întreruperi sunt oprite , întreruperea este tratată
iar controlul este returnat către procesul întrerupt.
 Rutinele de tratare a întreruperilor TREBUIE să fie
scurte, simple și rapide.

Tratarea periodică a proceselor
 În majoritatea sistemelor în timp real există mai
multe clase de procese periodice fiecare având
diferite perioade(timpul dintre execuții),timpi de
execuție și termene limită(timpul până la care
procesul trebuie să fie terminat).
 Fiecare bătaie a ceasului intern generează o
întrerupere care pornește administratorul de procese
pentru procesele periodice.
 Administratorul de procese selectează un proces
gata de execuție.

Administrarea proceselor
 Preocupat cu administrarea setului de procese
concurente.
 Procesele periodice sunt executate la
momente prestabilite de timp.
 Sistemele de operare în timp real se folosesc
de ceasul intern pentru a determina momentul
execuției unui proces ținând cont de:
• Perioada procesului - timpul dintre execuții.
• Termenul procesului -timpul până la care
procesul trebuie să fie terminat.

Administrarea proceselor în timp real

Schimbarea proceselor
 Alocatorul alege următorul proces care va fi
executat de procesor.Alocarea procesului
depinde de o strategie care poate lua în
considerare prioritatea procesului
 Administratorul de resurse alocă memorie și
un procesor pentru procesul ce va fi executat.
 Dispecerul ia procesul din lista de procese
gata de executie si îl incarcă intr-un procesor
urmând să îl pornească.

Strategii de planificare
 Planificare non-preemptivă
• Odată ce un proces este planificat petru execuție rulează
până la terminare .
 Planificare preemptivă
• Execuția unui proces poate fi oprită dacă un proces cu
prioritate mai mare dorește resursele.
 Algoritmi de planificare
• Round-robin;
• Rate monotonic;
• Shortest deadline first.

Sisteme de monitorizare și control
 Clasă importantă de sisteme în timp real.
 Verifică în mod constant senzorii și iau
măsuri care depind de valoarea acestora.
 Sistemele de monitorizare examinează
senzorii și raportează valorile lor.
 Sistemele de control iau valorile senzorilor și
controlează actuatoare hardware.

Arhitecturi generice

Sistem de alarmă antifurt
 Un sistem este necesar pentru monitorizarea
senzorilor de la uși și ferestre pentru a
detecta prezența intrușilor în clădire.
 În momentul în care un senzor indică o
spargere sistemul pornește luminile și sună
la poliție automat.
 Sistemul ar trebui să funcționeze fără a fi
conectat la o sursă de curent.

Sistem de alarmă antifurt
 Senzori
• Senzori de mișcare,senzori pentru ferestre și uși;
• 50 senzori de ferestre, 30 senzori de uși și 200 de
detectoare de mișcare;
• Senzori pentru căderea tensiunii.
 Acțiuni
• Când un intrus este detectat poliția este sunată automat;
• Luminile sunt pornite în camerele cu senzori activi;
• O alarmă sonoră este pornită;
• Sistemul comută automat către o sursă de rezervă când o
cădere de voltaj are loc.

Procesul de proiectare a unui
sistem în timp real
 Identificarea stimulilor și a răspunsurilor asociate
 Definirea constrângerilor de timp asociate cu fiecare
stimul și răspuns.
 Alocarea funcțiilor sistem către procese concurente.
 Proiectarea de algoritmi pentru procesarea stimulilor
și generarea de răspunsuri.
 Proiectarea unui sistem de planificare care asigură
aceea că fiecare proces va fi planificat pentru ca să
își satisfacă termenul.

Stimuli care vor fi procesați
 Căderi de tensiune
• Generate aperiodic de către un monitor de
circuit.În momentul în care se întâmplă aceasta
sistemul trebuie să comute pe alimentarea de
rezervă într-un timp de maxim 50 ns.
 Alarmă intrus
• Stimul generat de către senzorii sistemului.
Răspunsul este să se sune la poliție,să se
pornească luminile și alarma sonoră.

Cerințe de timp

Procesele sistemului de alarmă antifurt

Building_monitor process 1
class BuildingMonitor extends Thread {
BuildingSensor win, door, move ;
Siren siren = new Siren () ;

Lights lights = new Lights () ;
Synthesizer synthesizer = new Synthesizer () ;
DoorSensors doors = new DoorSensors (30) ;
WindowSensors windows = new WindowSensors (50) ;
MovementSensors movements = new MovementSensors (200) ;
PowerMonitor pm = new PowerMonitor () ;
BuildingMonitor()
{
// initialise all the sensors and start the processes
siren.start () ; lights.start () ;
synthesizer.start () ; windows.start () ;
doors.start () ; movements.start () ; pm.start () ;
}

Building monitor process 2
public void run ()
{
int room = 0 ;
while (true)
{
// poll the movement sensors at least twice per second (400 Hz)
move = movements.getVal () ;
// poll the window sensors at least twice/second (100 Hz)
win = windows.getVal () ;
// poll the door sensors at least twice per second (60 Hz)
door = doors.getVal () ;
if (move.sensorVal == 1 | door.sensorVal == 1 | win.sensorVal == 1)
{
// a sensor has indicated an intruder
if (move.sensorVal == 1) room = move.room ;
if (door.sensorVal == 1) room = door.room ;
if (win.sensorVal == 1 ) room = win.room ;
lights.on (room) ; siren.on () ; synthesizer.on (room) ;

break ;
}
}

Building_monitor process 3
lights.shutdown () ; siren.shutdown () ; synthesizer.shutdown () ;

windows.shutdown () ; doors.shutdown () ; movements.shutdown () ;
} // run
} //BuildingMonitor

Sisteme de control
 Un sistem de alarmă antifurt este în primul
rând un sistem de monitorizare.Colectează
date de la senzori dar nu realizează control
în timp real a actuatoarelor.
 Sistemele de control sunt similare dar
sistemul trimite semnale de control către
actuatoare.
 Un exemplu de sistem de monitorizare și
control este un sistem care monitorizează
temperatura și care pornește sau oprește
încălzirea.
Sistem care controlează temperatura

Sisteme de achiziție de date
 Colectează date de la senzori pentru procesare si
analiză.
 Procesele de colectare de date și cele de procesare
pot avea perioade și termene diferite.
 Colectare datelor poate fi mai rapidă decât
procesarea ex. Colectarea datelor despre o explozie
 Amortizoarele circulare sau inelare sunt un
mecanism pentru a amortiza diferențele de viteză.

Arhitecturi pentru achiziție de date

Colectarea de date dintr-un reactor
 Un sistem care colectează de la un set de
senzori care monitorizează fluxul de neutroni
dintr-un reactor nuclear.
 Datele sunt plasate într-un tampon inelar
pentru o procesare ulterioară.
 Amortizorul inelar este implementat ca și un
proces concurent astfel colecția și procesele
de procesare pot fi sincronizate.

Monitorizarea fluxului reactor

Amortizor inelar

Excluderi mutuale
 Procesele producător colectează date și le
adaugă la tampon.Procesele consumator culeg
datele din tampon și fac elementele disponibile.
 Producătorii cât și consumatorii trebuie să fie
mutual excluși în a avea acces concomitent la
aceleași resurse.
 Amorizorul trebuie să oprească procesele să
adauge date atunci când este plin și procesele
să culeagă date atunci când este gol.

Ring buffer implementation 1
class CircularBuffer
{
int bufsize ;
SensorRecord [] store ;
int numberOfEntries = 0 ;
int front = 0, back = 0 ;
CircularBuffer (int n) {
bufsize = n ;
store = new SensorRecord [bufsize] ;
} // CircularBuffer

synchronized void put (SensorRecord rec )
throws InterruptedException
{
if ( numberOfEntries == bufsize)
wait () ;
store [back] =
new SensorRecord (rec.sensorId, rec.sensorVal) ;
back = back + 1 ;
if (back == bufsize)
back = 0 ;
numberOfEntries = numberOfEntries + 1 ;
notify () ;
} // put
synchronized SensorRecord get () throws InterruptedException
{
SensorRecord result = new SensorRecord (-1, -1) ;
if (numberOfEntries == 0)
wait () ;
result = store [front] ;
front = front + 1 ;
if (front == bufsize)
front = 0 ;
numberOfEntries = numberOfEntries - 1 ;
notify () ;
return result ;
} // get
} // CircularBuffer

Puncte cheie
 Corectitudinea unui sistem în timp real depinde nu
numai de ceea ce face cât și de rapiditatea cu care
reacționează.
 Un sitem general în timp real implică asocierea
proceselor cu senzori și actuatoare.
 Arhitecturile sistemelor în timp real sunt de obicei
proiectate ca și un număr de procese concurente.

Puncte cheie
 Sistemele de operare în timp real sunt
responsabile pentru procese și administrarea
resurselor.
 Sistemele de monitorizare și control
interoghează senzori și trimit semnale de
control către actuatoare.
 Sistemele de achiziții de date sunt de obicei
organizate conform unui model producător
consumator.

Proiectarea interfețelor utilizator

Obiective
 Propunerea unor principii generale de proiectare
pentru proiectarea interfețelor utilizator
 Explicarea diferitelor stiluri de interacțiune și
utilizarea lor
 Explicarea alegerii între prezentarea grafică și cea
textuală a informațiilor
 Explicarea principalelor activități ale procesului de
proiectare a interfeței utilizator
 Introducerea atributelor de utilitate și a abordărilor
evaluării sistemului.

Subiecte tratate
 Probleme de proiectare
 Procesul de proiectare a interfeței utilizator
 Analiza utilizatorului
 Prototiparea interfeței utilizator
 Evaluarea interfeței

Interfața cu utilizatorul
 Interfețele cu utilizatorul trebuie să fie
proiectate pentru a se potrivi abilităților,
experienței și așteptărilor anticipaților săi
utilizatori.
 Utilizatorii sistemului judecă adesea un sistem
pentru interfața sa mai degrabă decât pentru
funcționalitatea sa.
 O interfață prost concepută poate provoca un
utilizator în a face erori catastrofale.
 Proiectarea slabă a interfeței utilizator este
motivul pentru care majoritatea sistemelor
software nu sunt utilizate niciodată.
Factorii umani în proiectarea
interfeței
 Memorie pe termen scurt limitată
• Oamenii pot reține instantaneu aproximativ 7 elemente de
informație. Dacă le prezinți mai mult decât atât, ei sunt
mai predispuși în a face greșeli.
 Oamenii fac greșeli
• Când oamenii fac greșeli și sistemele funcționează greșit,
mesajele și alarmele nepotrivite pot spori stresul și, prin
urmare, probabilitatea la mai multe greșeli
 Oamenii sunt diferiți
• Oamenii au o gamă largă de capacități fizice. Proiectanții
nu trebuie să se orienteze după capabilitățile lor proprii.
 Oamenii au preferințe diferite de interacțiune
• Unii preferă grafica, alții textul.

Principii de proiectare UI
 Proiectarea UI trebuie să țină cont de
nevoile, experiența și capabilitățile
utilizatorilor sistemului.
 Proiectanții ar trebui să fie conștienți de
limitările fizice și mentale ale oamenilor(ex.
memoria pe termen scurt limitată) și trebuie
să recunoască că oamenii fac greșeli.
 Principiile de proiectare UI stau la baza
proiectării interfețelor, deși nu toate
principiile sunt aplicabile pentru toate
modelele.
Principiile de proiectare a
interfeței utilizator
Principiu Descriere
Familiaritatea Interfața trebuie să utilizeze termeni și concepte care sunt trase
utilizatorului din experiența oamenilor care vor utiliza mai mult sistemul.
Consistența Interfața trebuie să fie consistentă în aceasta, pe cât posibil, astfel
încât operațiile comparabile să fie activate în același mod.
Surpriza minimă Utilizatorii nu trebuie să fie surprinși de comportamentul unui
sistem.
Recuperabilitatea Interfața trebuie să includă mecanisme pentru a le permite
utilizatorilor să se refacă de pe urma erorilor.
Ghidarea Interfața trebuie să ofere un feedback semnificativ atunci când
utilizatorului erorile apar și să ofere facilități de ajutor ale utilizatorului
dependente de context.
Diversitatea Interfața trebuie să ofere facilități corespunzătoare de
utilizatorului interacțiune pentru diferite tipuri de utilizator de sistem.

Principii de proiectare
 Familiaritatea utilizatorului
• Interfața trebuie să se bazeze pe termeni și concepte
adaptate aplicațiilor utilizatorului mai degrabă decât pe
concepte specifice de calcul. De exemplu, o rețea de
birou trebuie să utilizeze concepte precum scrisori,
documente, dosare etc. și nu directoare, indicatori de
fișier etc.
 Consistența
• Sistemul trebuie să afișeze un nivel corespunzător de
consistență. Comenzile și meniurile trebuie să aibă
același format, punctuația comenzilor trebuie să fie
similară etc.
 Surpriza minimă
• Dacă o comandă funcționează într-un mod cunoscut,
utilizatorul trebuie să fie capabil să prevadă funcționarea
comenzilor comparabile.
Principii de proiectare
 Recuperabilitatea
• Sistemul trebuie să ofere un anumit grad de flexibilitate
față de erorile utilizatorilor și să permită acestora să poată
recupera sistemul. Poate include: facilitatea de anulare,
confirmarea acțiunilor distructive, ștergeri „soft” etc.
 Ghidarea utilizatorului
• Trebuie oferită asistență în utilizarea sistemului prin
sisteme „help”, manuale online etc.
 Diversitatea utilizatorului
• Trebuie oferite facilități de interacțiune pentru diferite tipuri
de utilizatori. De ex. utilizatorilor cu dificultăți de vedere li
se va prezenta textul cu caractere de dimensiuni mari.

Probleme de proiectare în UI
 În proiectarea sistemelor interactive trebuie adresate
două probleme:
• Cum va fi furnizată calculatorului informația de la
utilizator?
• Cum va fi prezentată utilizatorului informația produsă de
calculator?
 Interacțiunea cu utilizatorul ca și prezentarea
informației pot fi integrate prin intermediul unui cadru
coerent, cum ar fi o metaforă pentru interfața
utilizator.

Stiluri de interacțiune
 Manipulare directă
 Selecție din meniu
 Completare formular
 Limbaj de comandă
 Limbaj natural

Stiluri de interacțiune
Stiluri de Principalele Principalele dezavantaje Exemple de
interacțiune avantaje aplicații
Manipulare Interacțiune rapidă și Poate fi greu de implementat. Jocuri video
directă intuitivă Potrivit numai în cazul în care Sisteme CAD
Ușor de învățat există o metaforă vizuală pentru
sarcini și obiecte.
Selecție din Evită erorile de Lentă pentru utilizatorii Majoritatea
meniu utilizator experimentați. sistemelor de uz
Necesită o scriere Poate deveni complexă în cazul în general
mai puțină care există mai multe opțiuni în
meniu.
Completare Date simple de Ocupă mult spațiu pe ecran. Controlul
formular intrare Cauzează probleme în cazul în care stocurilor,
Ușor de învățat opțiunile utilizatorului nu se Prelucrarea
Verificabil potrivesc cu câmpurile de formular. creditelor de nevoi
personale
Limbaj de Puternic și flexibil Greu de învățat. Sisteme de
comandă Gestionarea slabă a erorilor. operare, Sisteme
de comandă și
control
Limbaj Accesibil Necesită mult scris. Sistemele de
natural utilizatorilor Sistemele de înțelegere a limbajului regăsire a
ocazionali natural sunt nesigure. informației
Ușor de extins

Interfețe utilizator multiple

Interacțiunea în sistemul LIBSYS
 Căutarea documentului
• Utilizatorii trebuie să fie capabili să folosească
facilitățile de căutare pentru a găsi documentele
de care au nevoie.
 Solicitarea documentului
• Utilizatorii solicită ca un anume document să fie
livrat pe mașina lor sau la un server pentru
imprimare.

Interfețe bazate Web
 Multe sisteme bazate Web au interfețe
bazate pe formulare(forms) Web.
 Câmpurile formularelor pot fi meniuri, casete
preluare text, butoane etc.
 În exemplul LIBSYS utilizatorii aleg dintr-un
meniu sursa la care se va face căutarea și
tastează fraza de căutare într-o casetă de
preluare text.

Formular de căutare LIBSYS

Prezentarea informațiilor
 Prezentarea informațiilor se referă la
prezentarea informațiilor produse de sistem
utilizatorilor acestuia.
 Informațiile pot fi prezentate direct (ex. text
într-un procesor de texte) sau pot fi
transformate într-o anumită formă de
prezentare(ex. într-o anume formă grafică)
 Abordarea Model-View-Controller este o
modalitate de a oferi suport pentru prezentări
multiple ale datelor.


Model-view-controller

 Informații statice
• Inițializate la începutul unei sesiuni. Nu se
modifică pe durata sesiunii.
• Pot fi numerice sau textuale.
 Informații dinamice
• Se modifică pe parcursul unei sesiuni iar
modificările trebuie comunicate utilizatorului
sistemului.
• Pot fi numerice sau textuale.

Factori de afișare a informațiilor
 Este utilizatorul interesat de informații precise sau
de relații între date?
 Care este frecvența de modificare a informațiilor?
Trebuie ca modificarea să fie comunicată imediat?
 Utilizatorul trebuie să răspundă printr-o acțiune la o
modificare?
 Există o interfață de manipulare directă?
 Informația este textuală sau numerică? Valorile
relative sunt importante?

Prezentări alternative ale informațiilor
Jan Feb Mar April May June
2842 2851 3164 2789 1273 283 5
4000
3000
2000
1000
0
Jan Feb Mar April May June

Prezentare analogică sau digitală?
 Prezentarea digitală
• Concisă – ocupă puțin spațiu pe ecran;
• Valorile precise pot fi comunicate.
 Prezentarea analogică
• Ușoară în a obține o impresie a valorii „dintr-o
privire”;
• Posibilă să arate valorile relative;
• Ușoară în a vedea valorile de date excepționale.

Metode de prezentare

Afișarea de valori relative

Vizualizarea datelor
 Se ocupă cu tehnicile pentru afișarea cantităților
mari de informații.
 Vizualizarea poate revela relațiile dintre entități și
tendințele datelor.
 Posibile vizualizări ale datelor:
• Informații meteo colectate de la mai multe surse;
• Starea unei rețele de telefonie sub forma unui set de
noduri conectate;
• Combinat chimic vizualizat sub formă de presiuni și
temperaturi într-un set de rezervoare și conducte;
• Un model molecular afișat în 3 dimensiuni;
• Pagini web afișate ca arbore hiperbolic..

Afișarea culorilor
 Culoarea adaugă o dimensiune suplimentară
unei interfețe și poate ajuta utilizatorul să
înțeleagă structuri complexe de informație.
 Culoarea poate fi utilizată pentru a evidenția
evenimente excepționale.
 Greșeli obișnuite la utilizarea culorilor în
proiectarea interfețelor:
• Utilizarea culorii pentru a comunica un anumit
înțeles;
• Utilizarea excesivă de culori.

Principii de utilizare a culorilor
 Limitarea numărului de culori utilizate și
folosirea lor consecventă.
 Utilizarea unei schimbări de culoare pentru a
ilustra o schimbare în starea sistemului.
 Utilizarea codificării pe bază de culori pentru
a oferi sprijin utilizatorilor în realizarea
activității curente.
 Utilizarea codificării pe bază de culori în mod
bine gândit și controlat.
 Atenție la asocierea culorilor.

Mesaje de eroare
 Proiectarea mesajelor de eroare este de o
importanță critică.
Mesajele de eroare slabe pot conduce la
refuzarea sistemului de către utilizator.
 Mesajele trebuie să fie politicoase, concise,
consistente și constructive.
 Cunoștința și experiența utilizatorilor trebuie
să constituie un factor determinant în
proiectarea mesajelor

Factori de proiectare în formularea
mesajelor
Factor Descriere
Contextul Pe cât posibil, mesajele generate ar trebui să reflecte contextul curent al utilizatorului.
În măsura în care este posibil, sistemul ar trebui să fie conștient de ceea ce face
utilizatorul și ar trebui să genereze mesaje care sunt relevante pentru activitatea lor
curentă.
Experiența O dată ce utilizatorii încep să se familiarizeze cu sistemul ei devin iritați de lungile
mesaje „semnificative”. Cu toate acestea, începătorilor le sunt greu de înțeles scurtele
declarații concise ale unei probleme. Ar trebui să ofere ambele tipuri de mesaj și să
permită utilizatorului să controleze concizia mesajului.
Nivelul de Mesajele trebuie să fie adaptate competențelor utilizatorilor precum și experienței lor.
competență Mesajele pentru diferite clase de utilizatori pot fi exprimate în moduri diferite în funcție
de terminologia cu care este familiar cititorului.
Stilul Mesajele trebuie să fie mai degrabă pozitive decât negative. Trebuie să folosească mai
degrabă modul de adresare activ decât pasiv . Nu trebuie să fie jignitoare sau să încerce
să fie amuzante.
Cultura Pe cât posibil, proiectantul de mesaje ar trebui să fie familiarizat cu cultura tării unde
este comercializat sistemul. Există diferențe culturale distincte între Europa, Asia și
America. Un mesaj potrivit pentru o cultură ar putea fi de neacceptat pentru altă
cultură.

Erori ale utilizatorilor
 Să presupunem că o asistentă tastează
greșit numele unui pacient.

Proiectare bună și proastă a
mesajelor

Procesul de proiectare a UI
 Proiectarea UI este un proces iterativ care
implică o legătură strânsă între utilizatori și
proiectanți.
 Cele 3 activități fundamentale ale acestui
proces sunt:
• Analiza utilizatorului. Înțelegerea a ceea ce vor
face utilizatorii cu sistemul;
• Prototiparea sistemului. Dezvoltarea unei serii
de prototipuri în vederea experimentării;
• Evaluarea interfeței. Experimentarea
prototipurilor cu utilizatorii.

Procesul de proiectare

Analiza utilizatorului
 Dacă nu se înțelege ce vor utilizatorii să facă
cu sistemul, atunci nu există o perspectivă
realistă a proiectării unei interfețe eficiente.
 Analiza utilizatorului trebuie descrisă în
termeni pe care îi pot înțelege atât utilizatorii
cât și alți proiectanți.
 Scenariile în care sunt descrise episoadele
tipice de utilizare sunt un mod de a realiza
aceste analize.

Scenariu al interacțiunii cu
utilizatorul
Jane este o studentă a Studiilor Religioase și lucrează la un eseu

pe arhitectura indiană și cum a fost aceasta influențată de
practicile religioase. Pentru a o ajuta să înțeleagă acest lucru, ea
ar dori să acceseze unele imagini cu detalii notate pe clădiri dar nu
poate găsi nimic în biblioteca ei locală.
Ea se apropie de bibliotecar pentru a discuta despre nevoile ei și

acesta îi sugerează unii termeni care ar putea fi folosiți în căutare.
De asemenea, el îi mai sugerează unele biblioteci din New Delhi și
Londra care ar putea avea acest material, astfel ei se conectează
la biblioteca de cataloage și fac unele căutări folosind acești
termeni. Ei găsesc unele materiale sursă și fac o cerere de
fotocopii a imaginilor cu detaliu arhitectural pentru a fi postate
direct la Jane..

Cerințe rezultate din scenariu
 Utilizatorii ar putea să nu cunoască termenii
de căutare corespunzători, deci au nevoie de
o metodă care să-i ajute să aleagă termenii.
 Utilizatorii trebuie să poată alege colecțiile în
care să se realizeze căutările.
 Utilizatorii trebuie să poată realiza căutări și
să ceară copii ale materialelor relevante.

Tehnici de analiză
 Analiza tehnicilor
• Modelează pașii implicați în realizarea unei
sarcini.
 Interviuri și chestionare
• Întreabă utilizatorii despre activitățile pe care ei
le realizează.
 Etnografie
• Observă utilizatorii în timp ce lucreaza.

Analiza ierarhică a sarcinilor

Intervievare
 Proiectare de interviuri semi-structurate
bazate pe întrebări deschise.
 Utilizatorii pot furniza astfel informațiile pe
care ei le consideră esențiale și nu doar
informațiile pe care inginerul s-a să le
colecteze.
 Interviurile în grup sau grupurile focalizate
permit utilizatorilor să discute între ei despre
ceea ce fac.

Etnografie
 Implică faptul că un observator extern
urmărește utilizatorii la lucru și îi
interoghează verbal despre ceea ce fac.
 Valoroasă deoarece multe sarcini ale
utilizatorilor sunt intuitive și acestora le este
foarte dificil să le descrie și explice.
 Ajută, de asemenea, în înțelegerea rolului
influențelor sociale și organizaționale asupra
modului de lucru.

Înregistrări etnografice
Controlul traficului aerian implică un număr de control „suite” unde
suitele sectoarelor adiacente spațiului aerian de control fizic sunt situate
unul lângă altul. Zborurile într-un sector sunt reprezentate de benzi de
hârtie care sunt montate în cuiere de lemn într-o ordine care reflectă
poziția lor în sector. Dacă nu există suficiente sloturi pe cuiere(adică
atunci când spațiul aerian este foarte ocupat), controlorii răspândesc
benzile de pe birou în fața cuierelor.
În timp ce observam controlorii , am observat că acești controlori
regulat aruncau o privire la benzile de cuiere în sectorul adiacent. Le-
am comunicat și lor acest lucru și i-am întrebat de ce au făcut acest
lucru. Au răspuns că, în cazul în care controlorul adiacent are benzi pe
biroul lui, atunci acest lucru ar însemna că ar avea o mulțime de zboruri
între sectorul lor. Prin urmare, ei au încercat să crească viteza
aeronavelor din sectorul „spațiu curat” pentru aeronava sosită.

Concluzii pe baza etnografiei
 Controlorii trebuie să vadă toate zborurile
dintr-un sector. De aceea trebuie avitate
afișări derulante în care dispar din vedere
avioanele din partea superioară sau din cea
inferioară.
 Interfața trebuie să aibă modalități de a le
comunica controlorilor câte zboruri există în
sectoarele adiacente astfel încât ei să-și
poată planifica activitatea din sector.

Prototiparea interfeței utilizator
 Scopul prototipării este de a permite
utilizatorilor să capete experiență directă cu
interfața.
 În lipsa acestei experiențe directe, este
posibil de judecat posibilitatea de utilizare a
unei interfețe.
 Prototiparea poate fi un proces cu doup
stadii:
• În primul stadiu se pot utiliza prototipuri pe
hârtie;
• În al doilea stadiu desenul este rafinat și se
dezvoltă prototipuri automate din ce în ce mai
sofisticate.
Prototip pe hârtie
 Parcurgerea scenariilor utilizând schițe ale
interfeței.
 Prezentarea unei serii de interacțiuni cu
sistemul.
 Prototipul pe hârtie este o metodă eficientp
de a afla reacțiile utilizatorului la
propunerilepentru design-ul interfeței.

Tehnici de prototipare
 Prototipare bazată pe script
• Se dezvoltă o serie de scripturi și ecrane
utilizând schițe de interfață.
 Programare vizuală
• Se utilizează un limbaj proiectat pentru
dezvoltarea rapidă a software-ului, cum ar fi
Visual Basic. Vezi capitolul 17.
 Prototipare bazată pe internet
• Utilizarea unui browser web și a unor scripturi
asociate.

Evaluarea interfeței utilizator
 Se pot realiza evaluări ale proiectării unei
interfețe utilizator pentru a vedea în ce
măsură corespunde modului de lucru.
 Evaluarea totală este foarte costisitoare și
nepractică pentru majoritatea sistemelor.
 În mod ideal o interfață ar trebui evaluată în
raport cu specificațiile de utilitate. Totuși,
aceste specificații sunt rareori definite.

Atribute de utilitate
Atribut Descriere
Ușurința de învățare Cât timp îi ia unui utilizator nou să devină productive cu
sistemul?
Viteza de operare Cât de bine se potrivește răspunsul sistemului cu locul de
practică al utilizatorului?
Puterea Cât de torelant este sistemul la erorile utilizatorului?
Recuperabilitatea Cât de bun este sistemul la refacerea de la erorile
utilizatorului?
Adaptabilitatea Cât de strâns este sistemul legat de un singur model de
lucru?

Tehnici simple de evaluare
 Chestionare pentru feedback de la utilizator.
 Înregistrare video a utilizării sistemului și
evaluarea ulterioară a proiecției.
 Extinderea codului cu operații de colectare
referitoare la utilizarea facilităților și la erorile
utilizatorului.
 Pregătirea codului care să colecteze
feedback online de la utilizator.

Rezumat
 Principiile de proiectare a interfeței utilizator trebuie
să ajute în ghidarea proiectării interfețelor utilizator.
 Stilurile de interacțiune includ manipulare directă,
sisteme de meniuri, completare formulare, limbaje
de comandă și limbaj natural.
 Afișările grafice ar trebui utilizate pentru a prezenta
tendințe și valori aproximative. Afișările digitale sunt
utile atunci când este necesară precizie.
 Culorile trebuie utilizate cu economie și în mod
consistent.

Rezumat
 Procesul de proiectare a interfeței utilizator implică
analiza utilizatorului, prototiparea sistemului și
evaluarea prototipului.
 Scopul analizei utilizatorului este de a face
proiectanții conștienți de modul în care utilizatorii
lucrează defapt.
 Prototiparea UI ar trebui să fie un proces în stadii, cu
prototipurile pe hârtie în primul stadiu utilizate ca
bază pentru prototiparea automată a interfeței.
 Scopurile evaluării UI sunt de a obține feedback
despre cum să fie îmbunătățit design-ul interfeței și
de a evalua dacă interfața îndeplinește cerințele de
utilitate.
Dezvoltare rapidă de software

Obiective
 Explicarea modului în care un proces iterativ,
de dezvoltare incrementală duce la o livrare
mai rapidă a unui software util
 Discutarea despre esența metodelor ”agile”
de dezvoltare
 Explicarea principiilor și practicilor de
programare extremă
 Explicarea rolului prototipului în procesul
software

Subiecte acoperite
 Metode agile
 Programare extremă
 Dezvoltare rapidă a aplicațiilor
 Prototipuri software

Dezvoltare rapidă de software
 Din cauza schimbărilor rapide a mediilor de
afaceri, întreprinderile trebuie să răspundă la
oportunități noi și la competiție.
 Necesită software, iar dezvoltarea rapidă și
livrarea sunt de multe ori cerințe critice
pentru sistemele software.
 Companiile pot fi dispuse să accepte
software de calitate inferioară dacă este
posibilă livrarea rapidă a funcționalității
esențiale.

Cerințe
 Din cauza mediului în schimbare, este
adesea imposibil să se ajungă la un set
stabil, coerent de cerințe ale sistemului.
 Prin urmare, un model de dezvoltare
cascadă este impracticabil și o abordare a
dezvoltării bazate pe caietul de sarcini
iterativ și de livrare este singura modalitate
de a livra software rapid.

Caracteristicile proceselor RAD
 Procesele de specificare, proiectare și implementare
sunt concurente. Nu există nicio specificație
detaliată și documentația de proiectare este
minimizată.
 Sistemul este dezvoltat într-o serie de incrementări.
Utilizatorii finali evaluează fiecare creștere și fac
propuneri pentru incrementări ulterioare.
 Interfețele utilizator ale sistemului sunt de obicei
dezvoltate cu ajutorul unui sistem de dezvoltare
interactiv.

Un proces de dezvoltare iterativ

Avantajele dezvoltării incrementale
 Livrare accelerată de servicii pentru clienți.

Fiecare creștere furnizează cea mai
prioritară funcționare clientului.
 Angajamentul utilizatorului cu sistemul.
Utilizatorii trebuie să fie implicați în
dezvoltare, ceea ce înseamnă că este mai
probabil ca sistemul să îndeplinească
cerințele lor și utilizatorii sunt mai angajați în
sistem.

Probleme cu dezvoltarea incrementală
 Probleme de management
• Progresul poate fi greu de judecat și problemele greu de
găsit deoarece nu există nicio documentație pentru a
demonstra ceea ce s-a făcut.
 Probleme contractuale
• Contractul normal poate include o specificație; fără o
specificație trebuie să fie utilizate diferite forme de
contracte.
 Probleme de validare
• Fără o specificație, împotriva a ce este sistemul testat?
 Probleme de mentenanță
• Schimbarea continuă tinde să modifice structura software,
făcând-o mai costisitoare la schimbare și evoluare pentru
a face față noilor cerințe.

Crearea de prototipuri
 Pentru unele sisteme mari, dezvoltarea
iterativă incrementală și livrarea pot fi
imposibile; acest lucru este valabil mai ales
atunci când mai multe echipe lucrează pe
diferite site-uri.
 Crearea de prototipuri poate fi folosită în
cazul în care un sistem experimental este
dezvoltat ca bază pentru formularea
cerințelor. Acest sistem este dat la o parte
atunci când au fost convenite specificațiile
sistemului.
Dezvoltarea incrementală și crearea de
prototipuri

Obiective contradictorii
 Obiectivul dezvoltării incrementale este de a
livra un sistem funcțional pentru utilizatorii
finali. Dezvoltarea începe cu acele cerințe
care sunt cel mai bine înțelese.
 Obiectivul creării prototipului este de a valida
sau obține cerințele de sistem. Procesul de
creare a prototipului începe cu acele cerințe
care nu sunt bine înțelese .

Metode agile
 Nemulțumirea față de cheltuielile implicate în
metodele de proiectare a dus la crearea de metode
agile. Aceste metode:
• Se axează mai degrabă pe cod decât pe proiectare;
• Se bazează pe o abordare iterativă a dezvoltării de software;
• Au ca scop livrarea rapidă de software funcțional și evoluarea
rapidă a software-ului pentru a satisface cerințele în schimbare.
 Metodele agile sunt probabil cele mai potrivite
pentru sistemele de afaceri mici / mijlocii sau
produse PC.

Principiile metodelor agile
Principle Description
Principle Description
Customer involvement The customer should be closely involved throughout the
Customer involvement The customer should be closely involved throughout the
development process.
development Their
process. Theirrole
role is provide
is provide and and prioritise
prioritise new new
system requirements andand
system requirements to toevaluate
evaluate thethe iterations
iterations of the system.
of the system.
Incremental delivery The software is developed in increments with the customer
Incremental delivery The software is developed
specifying in increments
the requirements to be included inwith
each the customer
increment.
specifyingThe
People not process the requirements
skills to be
of the development teamincluded in each and
should be recognised increment.
exploited. The team should be left to develop their own ways of
working without prescriptive processes.
People not process The skills of the development team should be recognised and
Embrace change
exploited.Expect
The the teamsystem requirements to change and design the system
should be left to develop their own ways of
so that it can accommodate these changes.
working without
Maintain simplicity
prescriptive processes.
Focus on simplicity in both the software being developed and in
the development process used. Wherever possible, actively work
Embrace change Expect theto system requirements
eliminate complexity from thetosystem.
change and design the system
so that it can accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and in
the development process used. Wherever possible, actively work
to eliminate complexity from the system.

Probleme cu metodele agile
 Păstrarea interesului clienților implicați în proces
poate fi dificilă.
 Membrii echipei pot fi nepotriviți pentru implicarea
intensă care caracterizează metodele agile.
 Prioritizarea schimbărilor poate fi dificilă în cazul în
care există mai multe părți interesate.
 Menținerea simplității necesită muncă suplimentară.
 Contractele pot fi o problemă ca și în alte abordări
ale dezvoltării iterative.

Programarea extremă
 Probabil cea mai cunoscută și cea mai
utilizată metodă agilă.
 Extreme Programming (XP) are o abordare
"extremă" pentru dezvoltarea iterativă.
• Noile versiuni pot fi construite de mai multe ori
pe zi;
• Incrementările sunt livrate clienților la fiecare 2
săptămâni;
• Toate testele trebuie efectuate pentru fiecare
versiune și versiunea este acceptată doar dacă
testele sunt realizate cu succes.

Ciclul de eliberare XP

Practici de programare extremă 1
Incremental planning Requirements are recorded on Story Cards and the Stories to be
included in a release are determined by the time available and
their relative priority. The developers break these Stories into
development ÔTasksÕ.
Small Releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent and
incrementally add functionality to the first release.
Simple Design Enough de sign is carried out to meet the current requirements
and no more.
Test first development An automated unit test framework is used to write tests for a new
piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code con tinuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.

Practici de programare extremă 2
Pair Programming Developers work in pairs, checking ea ch otherÕs work and

providing the support to always do a good job.
Collective Ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers own all the
code. Anyon e can chang e anything.
Continuous Integration As soon as work on a task is complete it is integrated into the
whole system. After any such integration, all the unit tests in the
system must pass.
Sustainable pace Large amounts of over-time are not considered acceptable as the
net effect is often to reduce code qua lity and medium term
productivity
On-site Customer A representative of the end -user of the system (the Customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.

XP și principiile agile
 Dezvoltarea incrementală este sprijinită prin
intermediul unor update-uri de sistem mici și
frecvente.
 Implicarea clientului înseamnă angajamentul full-
time al clientului cu echipa.
 Oamenii nu procesează prin programare pereche,
proprietate colectivă și un proces care să evite multe
ore de lucru.
 Imbunătățirea proiectului prin update-uri regulate.
 Menținerea simplității prin refactorizarea constantă a
codului.

Cerințe posibile
 In XP, cerințele utilizatorilor sunt exprimate
ca scenarii sau povestiri ale utilizatorului.
 Acestea sunt scrise pe cartonașe, iar echipa
de dezvoltare le descompune în sarcini de
implementat. Sarcinile sunt baza pentru
estimarea calendarului și a costurilor.
 Clientul alege noile cerințe pentru a fi incluse
în următoarea versiune bazată pe prioritățile
lor și pe estimările calendarului de lucru.

Cartonașul pentru documentul de
descărcare
Downloading and printing an article
You
First, you select the article that you want from a displayed list.
then have to tell the system how you will pay for it - this can either
be through a subscription, through a company account or by credit
card.
After this, you get a copyright form from the system to fill in and,
when you have submitted this, the article you want is downloaded
onto your computer .
You then choose a printer and a copy of the article is printed.
You
tell the system if printing has been successful.
If the article is a print-only article, you canÕ
t keep the P DF version
so it is automatically deleted from your computer .

XP și schimbarea
 Ințelepciunea convențională în ingineria
software este de a proiecta pentru schimbare.
Se merită să petreci timp și efort pentru
anticiparea schimbărilor deoarece aceasta
reduce costurile mai târziu în ciclul de viață.
 XP, cu toate acestea, susține că acest lucru nu
este util deoarece schimbările nu pot fi
anticipate în mod credibil.
 Mai degrabă propune îmbunătățirea constantă a
codului (refactoring) pentru a face modificări mai
ușor atunci când trebuie să fie implementate.

Testarea în XP
 Dezvoltarea prin testare inițială.
 Dezvoltarea prin testare incrementală pe
baza scenariilor.
 Dezvoltarea și validarea prin testare cu
ajutorul utilizatorului.
 Hamurile de testare automate sunt folosite
pentru a rula toate testele componente de
fiecare dată când o nouă versiune este
construită.

Cartonașe cu sarcini pentru
documente descărcare
Task 1: Implement principal workf low
Task 2: Implement article catalog and selection
Task 3: Implement payment collection
P ayment may be made in 3 different ways. The user

selects which way they wish to pay . If the user
has a library subscription, then they can input the
subscriber key which should be checked by the
system. Alternatively , they can input an organisational
account number. If this is valid, a debit of the cost
of the article is posted to this account. Finally
, they
may input a 16 digit credit card number and expiry
date. This should be checked for validity and, if
valid a debit is posted to that credit card account.

Descrierea testului de caz
Test 4: Test credit card validity
Input:
Astring representing thecredit card numberand two integers representing
the month and year when the card expires
Tests:
Check that all bytes in the string are digits
Check that the month lies between 1 and 12 and the
year is greater than or equal to the current year .
Using the first 4 digits of the credit card number ,
check that the card issuer is valid by looking up the
card issuer table. Check credit card validity by submitting the card
number and expiry date information to the card
issuer
Output:
OK or error message indicating that the card is invalid

Dezvoltarea prin testare inițială
 Scrierea testelor înaintea codului clarifică
cerințele care trebuie implementate.
 Testele sunt scrise mai degrabă ca
programe decât ca date, astfel încât să
poată fi executate în mod automat. Testul
include o verificare că s-a executat în mod
corect.
 Toate testele anterioare și noi sunt rulate
automat atunci când este adăugată o nouă
funcționalitate. Se verifică astfel că noua
funcționalitate nu a introdus erori.
Programarea pereche
 In XP, programatorii lucrează în perechi, stând
împreună pentru a dezvolta cod.
 Acest lucru ajută să dezvolte proprietatea comună a
codului și să răspândească cunoștințe în echipă.
 Aceasta servește ca un proces informal de revizuire
întrucât fiecare linie de cod este privită de mai multe
persoane.
 Incurajează restructurarea codului ca întreaga
echipă să beneficieze de aceasta.
 Măsurătorile sugerează că productivitatea de
dezvoltare prin programare pereche este similară cu
cea a doi oameni care lucrează în mod independent.

Dezvoltare rapidă a aplicațiilor
 Metodele agile au primit multă atenție, dar
alte abordări pentru dezvoltarea rapidă a
aplicațiilor au fost folosite de mulți ani.
 Acestea sunt concepute pentru a dezvolta
aplicații de afaceri cu multe date și se
bazează pe programarea și prezentarea
informațiilor dintr-o bază de date.

Instrumente de mediu RAD
 Limbaj de programare pentru baze de date
 Generator de interfață
 Link-uri către aplicații de birou
 Generatoare de rapoarte

Un mediu RAD

Generarea interfeței
 Multe aplicații sunt bazate pe formulare complexe și
dezvoltarea manuală a acestor formulare este o
activitate consumatoare de timp.
 Mediile RAD includ suport pentru generarea de
ecran prin:
• Definirea unui formular interactiv utilizând tehnici de drag
and drop;
• Formular de legătură în care este specificată secvența
formularelor care trebuie prezentate;
• Formular de verificare în care mărimea permisă a
câmpurilor este definită.

Programare vizuală
 Limbajele de scriptare cum ar fi Visual Basic
suportă programare vizuală unde prototipul
este dezvoltat prin crearea unei interfețe
utilizator cu obiecte standard și componente
asociate acestora
 Există o bibliotecă mare de componente
pentru a sprijini acest tip de dezvoltare
 Acestea pot fi adaptate pentru a se potrivi cu
cerințele specifice aplicației

Programare vizuală cu reutilizare
Menu component
Date component
File Edit Views Lay out Options Help
General
12th January 2 000 Index
Range checking
3.876
script
User prompt
component +
Draw canvas script
component
Tree display
component

Probleme cu dezvoltarea vizuală
 Dificil de a coordona dezvoltarea în echipă.

 Nu există o arhitectură explicită a sistemului.
 Dependențe complexe între părți ale
programului pot cauza probleme de
mentenanță.

Reutilizarea COTS
 O abordare eficientă pentru dezvoltarea
rapidă este de a configura și conecta
sistemele existente.
 De exemplu, un sistem de management al
cerințelor poate fi construit folosind:
• O bază de date pentru memorarea cerințelor;
• Un procesor de text pentru a capta cerințele și a
forma rapoarte;
• O foaie de calcul pentru managementul
trasabilității.

Documente compuse
 Pentru unele aplicații, un prototip poate fi creat prin
dezvoltarea unui document compus.
 Acesta este un document cu elemente active (cum
ar fi o foaie de calcul) care permit calcule de
utilizator.
 Fiecare element activ are o aplicație asociată care
este invocată atunci când este selectat acest
element.
 Documentul în sine este integratorul pentru diferite
aplicații.

Conexiunile aplicației
Compound document
Text 1 Table 1 Text 2 Text 3 Sound 1
Table 2 Text 4 Sound 2 Text 5
Word processor Spreadsheet Audio play er

Crearea prototipului software
 Un prototip este o versiune inițială a unui
sistem utilizat pentru a demonstra concepte
și pentru a încerca opțiuni de proiectare.
 Un prototip poate fi utilizat în :
• Procesul de inginerie al cerințelor pentru a ajuta
la obținerea și validarea cerințelor;
• In procesele de proiectare pentru a explora
opțiunile și pentru a dezvolta un design UI;
• In procesul de testare pentru a rula teste back-
to-back.

Beneficiile prototipurilor
 Imbunătățirea utilizării sistemului.
 O mai bună apropiere de nevoile
utilizatorilor.
 Imbunătățirea calității design-ului.
 Imbunătățirea mentenabilității.
 Reducerea efortului de dezvoltare.

Testarea back to back
Test data
Sy stem Application
prototy pe sy stem
Results
comparator
Difference
repor t

Procesul dezvoltării de prototipuri

Prototipuri “throw-away”
 Prototipurile ar trebui distruse după
dezvoltare deoarece acestea nu sunt o bază
bună pentru un sistem de producție:
• Poate fi imposibilă reglarea sistemului pentru a
satisface cerințele non-funcționale;
• Prototipurile sunt în mod normal
nedocumentate;
• Structura prototipului este de obicei degradată
datorită schimbării rapide;
• Prototipul probabil nu va respecta organizarea
normală a standardelor de calitate.

Puncte cheie
 O abordare iterativă a dezvoltării de software
conduce la o livrare mai rapidă a software-ului.
 Metodele agile sunt metode iterative de dezvoltare
care au ca scop reducerea timpului dezvoltării și așa
software-ul se produce mai repede.
 Programarea extremă include practici cum ar fi
testarea sistematică, îmbunătățirea continuă și
implicarea clientului.
 Abordarea la testarea în XP este un punct forte
particular în care testele executabile sunt dezvoltate
înainte de scrierea codului.

Puncte cheie
 Mediile de dezvoltare a aplicațiilor rapide
includ limbaje de programare pentru baze de
date, instrumente pentru generarea
formularelor și link-uri către aplicații de birou.
 Un prototip “throw-away” este utilizat pentru
a explora cerințele și opțiunile de proiectare.
 La implementarea unui prototip “throw-away”
se începe cu cerințele întelese mai puțin; în
dezvoltarea incrementală, se începe cu
cerințele cel mai bine înțelese.

Reutilizarea Software

Obiective
 Explicarea beneficiilor reutilizării software, precum și câteva

probleme de reutilizare a acestuia
 Discuție pe câteva metode de implemantare a reutilizării
software
 Explicarea cum modelele reutilizate pot reprezenta modele
sau pot fi incluse in generatoarele de programe. Discuție
asupra reutilizarea COTS
 Descrierea dezvoltării de produse software

Subiecte acoperite
 Mediul de refolosire
 Modele de design
 Generator bazat pe reutilizare
 Structura aplicațiilor
 Sistemul de reutilizare al aplicațiilor

Reutilizarea software
 În majoritatea disciplinelor de inginerie, sistemele sunt

construite prin combinarea componentelor existente care au
fost folosite deja în alte sisteme.
 Inginerii software s-au axat mai mult pe dezvoltarea proprie de
soft, dar este bine cunoscut faptul că pentru a obține soft de
calitate, mult mai rapid, la un preț scăzut, trebuie să adoptăm
un proces de dezvoltare bazat pe reutilizarea sistematică a
softului.

Ingineria software bazată pe reutilizare
 Sisteme de aplicații reutilizate
• Întregul sistem de aplicații poate fi reutilizat prin integrarea acestuia în
alte sisteme fără a aduce schimbări (reutilizarea COTS) sau
dezvoltând alte aplicații din aceeași familie.
 Componente / părți reutilizate
• Componentele unei aplicații, de la sub-sisteme până la simple obiecte
pot fi reutilizate. (Capitolul 19)
 Obiecte și funcții reutilizate
• Componentele software care implementează un singur obiect sau
funcție bine definit pot fi reutilizate.

Avantajele reutilizării software 1
Creșterea dependabilității Softul reutilizat, cel care a fost folosit și testat pe sisteme funcționale,
trebuie să fie mai sigur decât noile programe. Utilizarea inițială a
softului scoate la iveală orice greșeală de design și implementare.
Acestea sunt corectate, astfel reducându-se numărul de eșecuri când
softul este refolosit.
Risc redus de dezvoltare Dacă softul există, există mai puțină incertitudine în costul reutilizării
softului decât in costl dezvoltării acestuia. Acesta este un factor
important pentru managementul unui proiect , pentru că reduce
marginile de eroare în estimarea costului softului. Aceasta este
îndeosebi adevărată când componetele software mari ca și subsisteme
sunt refolosite.
Eficiența utilizării specialiștilor În loc ca specialiștii să facă aceeași muncă în diferite proiect, aceștia pot
dezvolta soft reutilizabil care încapsulează cunoștințele lor.

Avantajele reutilizării software 2
Standarde de conformitate Unele standarde ca și standardele de interfața cu utilizatorul, pot fi
implementate ca un standard de componente reutilizabile. De exemplu,
dacă meniurile din interfața utilizator sunt implementate folosind
componente reutilizabile, atunci toate aplicațiile prezintă același format
de meniu utilizatorilor. Utilizarea standardului interfața cu utilizatorul
îmbunătățesc dependabilitatea, utlilizatorilor le va fi mai greu să facă
greșeli când se află într-o interfață comună,
Dezvoltare rapidă Lansarea unui sistem pe piață cât mai repede posibil, este de multe ori
mai importantă decât costul global al dezvoltării acestuia. Reutilizarea
softului poate accelera producția deoarece, ambele, dezvoltarea și
timpul de realizare trebuie reduse.

Problemele reutilizării software 1
Creșterea costurilor de În cazul în care codul sursă al unui sistem software reutilizat sau o
mentenanță coomponentă a acestuia nu este disponibilă, atunci costul de
mentenanță poate să crească pe măsură ce incompatibilitatea
elementelor reutilizate din sistem crește cu schimbările sistemului.
Lipsa de suport Setul de instrumente CASE poate să nu suporte dezvoltarea utilizând
metora reutilizării. Poate fi dificil sau imposibil de integrat astfel de
instrumente cu o librărie de sistem. Procesul software acceptat de
aceste instrumente poate să nu fi util de această dată.
Sindromul Not-invented-here Uneori unii ingineri software preferă să rescrie componente așa cum
ei consideră că pot imbunătății noile componente reutilizabile.
Aceasta este făcută pe de o parte cu încredere, iar pe de altă parte cu
gândul că scrierea de cod propriu este mult mai competitivă decât
reutilizarea acestuia de la alți programatori.

Problemele reutilizării software 2
Crearea și menținerea unei Popularea unei componente reutilizată dintr-o librărie și asigurarea
componente de librărie dezvoltatorilor ca pot folosi această librărie este destul de scumpă.
Tehnicile noastre curente pentru clasificare, catalogare și preluarea
componentelor software sunt imature.
Găsirea, înțelegerea și adaptarea Componentele software trebuie să se găsească în librării, trebuie înțelese și
componentelor reutilizabile uneori adaptate muncii dintr-un nou mediu. Inginerii trebuie să fie destul
de încrezători în găsirea unei componente în librărie înainte ca ei să
înceapă să caute, ceea ce este un proces obișnuit în procesul de dezvoltare.

Mediul de lucru al reutilizării
 Deși reutilizarea este de multe ori mai simplă, decât reutilizarea
componentelor unui sistem, există totuși mai multe abordări
pentru a putea folosi reutilizarea.
 Reutilizarea este posibilă la un interval de nivele din simple
funcții la sisteme complete de aplicații.
 Mediul de lucru al reutilizăriii are o arie de acoperire pentru
toate tehnicile de reutilizare posibile.

Mediul de lucru al reutilizării
Design
patterns
Aspect-oriented
Component Application software development
Frameworks product lines
COTS
Component-based Legacy system integrations Program
development wrapping generators
Configurable
vertical applications
Service-oriented
Program
systems
libraries

Abordarea reutilizării 1
Modele de design Abstracții generice care apar între aplicații ce sunt reprezentate ca modele de
design. Ele arată obiecte și interacțiuni abstracte și concrete.
Dezvoltare bazată pe componente Sistemele sunt dezvoltate prin integrarea componentelor (colecții de obiecte)
conforme cu o compmonentă model standard. (Capitolul 19)
Modele de aplicație Colecții de clase abstracte și concrete care pot fi adaptate și extinse pentru a
crea noi sisteme de aplicații
Legacy system wrapping Mostenirea sistemelor (Capitolul 20) poate fi “înfășurată” prin definirea unui
set de interfețe și oferind acces la aceste moșteniri de sistem prin intermediu
acestora.
Sisteme orientate pe servicii Sistemele sunt dezvoltate prin crearea de legături comune care pot fi furnizate
în exterior.

Abordarea reutilizării 1
Application product lines Tipul unei aplicații este generalizat în jurul unei arhitecturi comune, așadar ea
poate fi adaptată în diferite direcții pentru diferiți clienți
COTS integration Sistemele sunt dezvoltate prin integrarea altor sistemelor de aplicații deja
existente.
Configurable vertical applications Un sistem obișnuit / comun este proiectat conform cu cerințele unui grup
specific de clienți.
Program libraries Biblioteci de clase și funcții care implementează conceptul de abstractizare sunt
disponibile pentru reutilizare.
Program generators Un generator de sistem conține cunoștințe din diferite tipuri de aplicații și poate
genera sisteme sau fragmente de sisteme din acel domeniu
Aspect-oriented software Componentele comune sunt tipărite în diferite locuri în aplicație în momentul
development când programul este compilat.

Reutilizarea factorilor de planificare
 Graficul de dezvoltare software.

 Durata de viață așteptată asoftware-ului.
 Experiența, cunoștințele și aptitudinile echipei de dezvoltare
 Ușurința de dezvoltare a softului, precum și cerințele non
funcționale.
 Domeniul aplicației.
 Platforma pe care softul va rula.

Reutilizarea conceptului
 Atunci când vom reutiliza un program sau componente de design, va
trebui să urmăm deciziile de design folosite de autorul acestor
componente.
 Aceasta poate limita oportunitățile de reutilizare.
 Oricum, o formă mai abstractă de reutilizare este reutilizarea
conceptului când o anumită abordare este descrisă în mod independent
de punere în aplicare și apoi se trece la dezvoltarea acesteia.
 Cele două mari abordări în reutilizarea conceptului sunt:
• Componentele de design;
• Programarea generativă.

Componentele de design
 O componentă de design este un mod de reutilizare a unei

cunoștințe abstracte legată de o problemă și soluția sa.
 Un model este o descriere a unei probleme și esența soluției
sale.
 Trebuie să fie destul de abstract pentru a fi refolosit în diferite
setări.
 Modele de multe ori se bazează pe caracteristicile obiectelor
cum ar fi moștenire și polimorfism.

Elementele modelului
 Nume
• Un identificator de model semnificativ.
 Descrierea problemei.
 Descrierea soluției.
• Nu un design concret ci un model pentru o soluție de design care
poate fi instanțiată în diferite moduri.
 Consecințe
• Rezultatele și compromisurile de aplicare a modelului.

Afișaje multiple
50
D
A
C 25
A B C D
B 0
Subj ect
Observer 1 A: 40 Observer 2
B: 25
C: 15
D: 20

Modelul Observator
 Nume
• Observator.
 Descriere
• Separă afișarea stării unui obiect de el însuși.
 Descrierea problemei
• Folosit atunci când este necesară afișarea mai multor stări
 Descrierea soluției
• Vezi slide-ul cu descrierea UML.
 Consecințe
• Optimizările pentru îmbunătățirea performanței de afișare nu sunt practice

Modelul Observator

Reutilizarea bazată pe generator
 Generatoarele de programe implică reutilizarea modelelor
standard și algoritmi.
 Acestea sunt încorporate în generator și parametrizate prin
comenzi de utilizator. Un program este apoi generat automat.
 Reutilizarea bazată pe generator este posibilă atunci când
abstracțiuni de domeniu și de legătură la cod executabil pot fi
identificate.
 Un limbaj specific domeniului este folosit pentru a compune și a
controla aceste abstracțiuni.

Tipuri de generatoare de programe
 Tipuri de generatoare de program:
• Generatoare de aplicații pentru procesarea datelor de afaceri;
• Parser si analizor lexical generatoare pentru procesarea limbajului;
• Generatoare de cod în instrumentele CASE;
 Reutilizarea bazată pe generatoare este foarte eficientă din punct de
vedere al costului dar aplicabilitatea este limitată la un număr relativ mic de
domenii de aplicare.
 Este ușor pentru utilizatorul final să dezvolte programe folosind
generatoare, comparativ cu alte abordări bazate pe componente de
refolosire.

Refolosirea prin generarea programului
Application
Program gener ator Generated pr ogram
description
Application domain
Database
kno wledge

Dezvoltare orientată pe aspect
 Dezvoltarea orientată pe aspect abordează o problemă majoră din
ingineria software – separarea de preocupări
 Preocupările sunt de multe ori nu numai asociate cu funcționalitatea
aplicației, dar sunt cross-cutting: Ex. Toate componentele își pot monitoriza
propriile operații, toate componentele trebuie să mențină politica de
securitate, etc.
 Preocupările cross-cutting sunt implementate ca aspecte și sunt integrate
dinamic în program. Procuparea legată de cod este aceea de refolosire, iar
noul sistem este generat de către integrator.

Aspect-oriented development
Aspect 1 Aspect 2
Generated code
Input source code
Aspect <statements 1>
<statements 1> Weaver Aspect 1
j oin point 1
<statements 2>
<statements 2>
Aspect 2
j oin point 2
<statements 3>
<statements 3>

Arhitectura aplicației
 Arhitectura aplicației este un design de sub-sisteme format

dintr-o colectie de clase abstracte și concrete și interfețele
dintre acestea.
 Sub-sistemul este implementat prin adăugarea de componente
pentru a completa părți ale designului și prin instanțierea
claselor abstracte în structură.
 Arhitecturile sunt de cele mai multe ori entități largi care pot fi
refolosite.

Structura claselor
 Infrastructura de sistem
• Sprijină dezvoltarea de infrastructuri de sisteme, cum ar fi
comunicațiile, interfețe utilizator și compilatoare.
 Arhitectura de integrare Middleware
• Standarde și clase care suporta comunicația și schimbul de informații
între componente
 Arhitectura de aplicare Enterprise
• Sprijină dezvoltarea unor tipuri specifice de aplicații, cum ar fi
telecomunicațiile sau sisteme financiare

Extinderea arhitecturilor
 Arhitecturile sunt generice si sunt extinse pentru a crea o aplicație sau un
subsistem mai precis.
 Extinderea unei arhitecturi implică:
• Adăugarea de clase concrete care moștenesc operațiile din clasele abstracte
în noua arhitectură;
• Adăugarea metodelor care sunt răspunzătoare de evenimeintele recunoscute
de arhitectură.
 Problema cu arhitecturile este complexitatea acestora, ceea ce înseamnă
că este nevoie de o lungă perioadă de timp pentru a le utiliza în mod
eficient.

Controlerul model-view
 Reprezină cadrul de infrastructură a sistemului pentru

interfetele utilizator (GUI).
 Permite multiple prezentări ale unui obiect și interacțiuni
separate cu aceste prezentări.
 Platforma MVC implică instanțierea unui număr de modele (așa
cum s-a discutat mai devreme, în conceptul de refolosire)

Model-view-controller
User Controller state view modification View state

inputs messages
Controller methods View methods
Model queries
Model edits and updates
Model state
Model methods

Refolosirea sistemelor de aplicații
 Implică reutilizarea unui întreg sistem de aplicații, prin

configurarea unui sistem pentru un mediu anume sau
fie prin integrarea a două sau mai multe sisteme
pentru a crea o nouă aplicație.
 Două abordări intervin aici:
• Integrarea produselor COTS;
• Dezvoltarea liniei de produse.

Reutilizarea produselor COTS
 COTS - Commercial Off-The-Shelf systems.
 Sistemele COTS sunt de obicei sisteme de aplicații complete
care oferă un API (Application Programming Interface).
 Construirea de sisteme mari prin integrarea sistemelor COTS
este în momentul de față o strategie de dezvoltare viabilă
pentru unele tipuri de sisteme cum ar fi sistemul de comerț
electronic.
 Cheia beneficiilor este dezvoltarea rapidă și ieftină de aplicații.

Alternative de design COTS
 Care din produsele COTS oferă cea mai apropiată funcționalitate?
• Pot exista mai multe produse similare care pot fi utile.
 Cum vor fi datele schimbate?
• Produse individuale folosesc structurile de date și formatele proprii
 Care caracteristică a produsului va fi utilizată?
• Cele mai multe produse au mai multe funcționalități decât este nevoie.
Trebuie să limităm accesul la funcționalitățile care nu sunt folosite.

Sistem electronic de achiziții publice
Client
Web browser E-mail sy stem
Ser ver
E-commerce Ordering and

Adaptor
sy stem invoicing sy stem
E-mail sy stem Adaptor

Reutilizarea produselor COTS
 Pe partea de client, programele standard de browser web și e-mail

sunt cele utilizate
 Pe partea de server, o platformă de comerț online trebuie integrată
cu un sistem existent de ordonare / repartizare.
• Acest lucru implică scrierea unui adaptor care să permită schimbul de
date între cele două.
• De asemenea este integrat și un sistem de e-mail pentru generarea de
email-uri către clienti. Acesta necesită la randul său un adaptor care să îi
permită recepționarea de date de la sistemul de comandă și facturare

Probleme de integrare a sistemelor COTS
 Lipsa de control asupra funcționalității și performanțelor
• Sistemele COTS pot fi mai puțin eficiente decât par
 Probleme de inter-operabilitate la sistemele COTS
• Sisteme COTS diferite pot reda ipoteze diferite, ceea ce conduce la faptul că
integrarea este dificilă.
 Nu avem control la evoluția sistemului
• Vânzătorii COTS controlează evoluția și nu utilizatorii
 Cuport din partea furnizorilor de COTS
• Furnizorii COTS pot să nu ofere suport pe durata de viață a produsului

Linii de produse software
 Liniile de produse software sau familiile de aplicații sunt aplicații cu
funcționalitate generică pe care o putem adapta și configura pentru
utilizare într-un anumit context.
 Adaptarea poate implica:
• Configurația componentelor și a sistemului;
• Adăugarea de noi componente la sistem;
• Selectarea unei componente deja existente dintr-o librărie;
• Modificarea unei componente pentru a îndeplini anumite cerințe

Specializarea produsului COTS
 Platformă specializată
• Diferite versiuni de aplicații sunt dezvoltate pentru diferite platforme.
 Mediu de lucru specializat
• Diferite versiuni de aplicații sunt create pentru a fi utilizate în anumite medii
de lucru. Ex. Diferite tipuri de echipamente de comunicare.
 Funcționalitate specială
• Diferite versiuni de aplicații sunt create pentru clienți cu cerințe diferite.
 Procese speciale
• Diferite versiuni de aplicații sunt construite pentru a suporta diferite procese
de lucru.

Configurația COTS
 Configurarea timpului de implementare
• Un sistem generic este configurat prin integrarea cunoștințelor despre
cerințele sistemului și procesele ce urmează să le execute sistemul.
 Configurarea timpului de proiectare
• Un cod generic comun este adaptat și schimbat în funcție de cerințele
unor anumiți clienți.

Organizarea sistemului ERP
Configuration
planning tool
Generic ERP sy stem

Configuration
database
Sy stem database

Sistemele ERP
 Un sistem ERP (Enterprise Resource Planning) este un sistem
generic care suportă procese comune de lucru, cum ar fi
comandă și facturare, fabricație, etc.
 Sunt foarte folosite în marile companii - ele reprezintă probabil
cea mai comună formă de reutilizare software.
 Miezul generic este adaptat prin includerea de module și prin
încorporarea cunoștințelor a proceselor și normelor de afaceri.

Configurarea timpului de proiectare
 Produsele software de linie care sunt configurate în timpul

proiectării sunt instanțieri de arhitecturi de aplicații. (Chapter 13)
 Produsele generice apar de regulă după experiența cu alte
produse specifice.

Arhitectura liniilor de produse
 Arhitecturile trebuie să fi structurate în așa fel încât să poată fi
separate în subsisteme diferite și să poată fi modificate.
 Arhitectura ar trebui să separe entitățile cu descrierile lor și
nivelele superioare din acestea mai degrabă prin descrierea
accesului în sistem și nu în mod direct..

Sistem de management al resurselor
User i nterface
User Resource Query

authenti cati on del i very management
Resource Resource pol i cy Resource

management control al l ocati on
Transacti on management
Resource database

Mijloace de transmitere
 Un sistem specializat de management al resurselor în cazul în care obiectivul său
este acela de a aloca resurse trebuie să manipuleze evenimentele apărute.
 Adaptarea include:
• La nivelul utilizator, există componente pentru afișarea operării dar și pentru
comunicații.
• La nivelul de management intrare/ieșire, există componente pentru localizarea
mijloacelor de transmitere, gestionarea stării mijloacelor de transmitere, precum și
autentificarea accidentală.
• Baza de date include echipament, mijloace de transmitere și schema bazei de date.

Un sistem de transmisie
User i nterface Comms system

i nter face
Operator Map and route Repor t Query

authenti cati on pl anner generator manager
Vehi cl e status Inci dent Vehi cl e Equi pment Vehi cl e

manager l ogger despatcher manager l ocator
Transacti on management Inci dent l og

Equi pment
database
Vehi cl e database Map database

Dezvoltarea instanței de produs
Renegotiate
requirements
Elicit Choose
stakeholder closest-fit
requirements family member
Adapt existing Deliver new
sy stem family member

Dezvoltarea instanței de produs
 Obținerea cerințelor părților interesate
• Utilizarea unui membru de familie existent ca și prototip
 Alegerea celui mai apropiat membru al familiei
• Gasește membrul din familie care întrunește cel mai bine cerințele
 Rediscutarea cerințelor
• Adaptează cerințele ca necesar la capabilitățile softului
 Adaptarea unui sistem existent
• Dezvoltă un nou modul și aplică schimbările pentru membrul familiei
 Livrarea noului membru al familiei
• Documentează caracteristicile noului membru pentru o dezvoltare următoare

Puncte cheie
 Avantajele reutilizării implică costuri mai mici, dezvoltare mai rapidă a
softului, precumși riscuri mai mici de eșec.
 Modele de proiectare sunt abstracțiuni la nivel înalt, care documentează cu
succes soluții de proiectare.
 Generaorul de program
 Generatoarele de program sunt de asemenea folosite ăn reutilizare:
conceptele de reutilizare sunt încorporate într-un sistem generator.
 Modelele de aplicații sunt colecții de obiecte abstracte și concrete care au
fost special dezvoltate pentru reutilizare.

Puncte cheie
 Refolosirea COTS se referă la reutilizarea sistemelor mari, sisteme gata
de utilizare.
 Problemele legate de reutilizarea COTS includ lipsa de control a
funcționalității, lipsa performanței și evoluției, dar și probleme de inter
operabilitate.
 Sistemele ERP sunt create prin configurarea unui sistem generic cu
informații despre activitatățile clienților.
 Liniile de produse software sunt legate de devoltarea aplicațiilor în jurul
unui miez comun de funcționalitate partajată.

Ingineria software bazată pe
componente (ISBC)

Obiective
 Pentru a explica faptul că ISBC este
preocupată cu dezvoltarea componentelor
standartizate și integrarea lor în aplicații
 Pentru a descrie componentele și modelele
de componente
 Pentru a arăta principalele activități în
procesul ISBC
 Pentru a discuta abordări despre compoziția
componentelor și problemele care pot
apărea

Subiecte acoperite
 Componente și modele de componente
 Procesul ISBC
 Compoziția componentelor

Dezvoltarea bazată pe
componente
 Ingineria software bazată pe componente
(ISBC) este o abordare a dezvoltării software
care se bazează pe reutilizarea software-
ului.
 A apărut din eșecul dezvoltării orientate pe
obiecte pentru a sprijinii reutilizarea eficientă.
Clasele de obiecte unice sunt prea detaliate
și specifice.
 Componentele sunt mult mai abstracte decât
clasele de obiecte și pot fi considerate a fi
furnizoare de servicii de sine stătătoare.
Necesitățile ISBC
 Componente independente specificate de
interfețele acestora.
 Standarde ale componentelor pentru a
facilita integrarea acestora.
 Middleware care oferă suport pentru
interoperabilitatea componentelor.
 Un proces de dezvoltare orientat pe
reutilizare.

ISBC și principiile de proiectare
 În afară de beneficiile reutilizării, ISBC este
bazată pe principiile de proiectare ale
ingineriei software:
• Componentele sunt independente deci nu
interferează între ele;
• Implementările componentelor sunt ascunse;
• Comunicarea se face prin interfețe bine definite;
• Platformele componentelor sunt comune și
reduc costurile de dezvoltare.

Problemele ISBC
 Încrederea în componentă – cum se poate avea
încredere într-o componentă fără cod sursă?
 Certificarea componentei - cine va certifica calitatea
componentelor?
 Predicția proprietăților emergente – cum pot fi
prezise proprietățile emergente ale compoziției
componentelor?
 Compromisuri ale cerințelor – cum facem analiza
compromisului dintre caracteristicile unei
componente și o alta?

Componentele
 Componentele oferă un serviciu fără a ține
seama unde se execută componenta sau
limbajul ei de programare
• Componenta este o entitate executabilă
independent care poate fi formată din unul sau
mai multe obiecte executabile;
• Interfața componentei este publicată și toate
interacțiunile sunt prin interfața publicată;

Definiții ale componentei
 Councill și Heinmann:
• O componentă software este un element software care
este conform cu un model al componentei și poate fi
implementată independent și alcătuită fără modificări
conforme cu un standard de compoziție.
 Szyperski:
• O componentă software este o unitate a compoziției, cu
interfețe specificate contractual și numai cu dependențe
de context explicite. O componentă software poate fi
implementată independent și este sub rezerva
compoziției terțelor părți.

Componenta ca furnizor de
servicii
 Componenta este o entitate independentă,
executabilă. Aceasta nu trebuie să fie
compilată înainte de a fi folosită cu alte
componente.
 Serviciile oferite de o componentă sunt puse
la dispoziție printr-o interfață și toate
interacțiunile componentei au loc prin acea
interfață.

Caracteristicile componentei 1

Caracteristicile componentei 2
Deployable To be deployable, a component has to be se lf-contained and

must be able to operate as a stand-alone entity on some
component platform that implements the component model.
This usually means that the component is a binary component
that does not have to be compiled befo re it is deployed.
Documented Components have to be fully docu mented so that potential
users of the component can decide whether or not they meet
their needs. The syntax and , ideally, the semantics of all
component interfaces have to be specified.

Interfețele componentei
 Interfață de aducere
• Definește serviciile care sunt furnizate de
componentă către alte componente.
 Interfață de cerințe
• Definește serviciile care specifică ce servicii
trebuie să fie puse la dispoziția componentei
pentru a executa după cum se specifică.

Interfețele componentei
Requir es int er face Pr ovides int er face

Defines the services Defines the services
from thecomponent’s Component that are provided
environment that it by the component
uses to other components

Componentă colectoare de date
Requir es int er face Pr ovides int er face
addSensor
removeSensor
sensorManagement
star tSensor
Data collector stopSensor
sensorData testSensor
initialise
repor t
listAll

Componenete și obiecte
 Componentele sunt entități dislocabile.
 Componentele nu definesc tipuri.
 Implementările componentelor sunt opace.
 Componentele sunt independente de limbaj.
 Componentele sunt standardizate.

Modelele componentelor
 Un model de componentă este o definire a
standardelor implementării componentei,
documentație și implementare.
 Exemple de modele ale componentelor
• EJB model (Enterprise Java Beans)
• COM+ model (.NET model)
• Corba Component Model
 Modelul componentei specifică modul în care ar
trebui definite interfețele și elementele care ar trebui
să fie incluse în definirea unei interfețe.

Elementele modelului unei
componente
Customisation
Naming
convention
Composition Documentation
Interface Specific Meta-data Evolution

Packaging
definition inter faces access suppor t
Usage Deploy ment

Interfaces
information and use
Component model

Suport middleware
 Modelele componentelor sunt baza middleware-
urilor care oferă suport pentru componentele de
executare.
 Implementările modelului de componentă oferă:
• Servicii de platformă care permit componentelor scrise
conform modelului de a comunica;
• Servicii orizontale, care sunt servicii de aplicații
independente folosite de diferite componente.
 Pentru a utiliza serviciile oferite de un model,
componentele sunt implementate într-un container.
Acesta este un set de interfețe folosite pentru a
accesa implementările de servicii.

Serviciile modelului de
componentă
Horizontal services
Component Transaction Resource

management management management
Concurrency Persistence Security
Platform services
Inter face Exception Component

Addressing
definition management communications

Dezvoltarea componentei pentru
reutilizare
 Componentele dezvoltate pentru o anumită

aplicație, de obicei, trebuie să fie
generalizate pentru a le face reutilizabile.
 O componentă este cel mai probabil să fie
reutilizabilă dacă este asociată cu o
abstracțiune a domeniului stabil (obiect de
afaceri).
 De exemplu, într-un spital, abstracțiunile
domeniului stabil sunt asociate cu scopul
fundamental – asistente medicale, pacienți,
tratamente, etc..
Dezvoltarea componentei pentru
reutilizare
 Componente pentru reutilizare pot fi construite special prin
generalizarea componentelor existente.
 Reutilizarea componentei
• Ar trebui să reflecte abstracțiunile domeniului stabil;
• Ar trebui să ascundă reprezentarea stării;
• Ar trebui să fie independentă pe cât posibil;
• Ar trebui să publice excepțiile prin interfața componentei.
 Există un compromis între reutilizare și utilizare
• Cu cât este interfața mai generală, cu atât este mai mare
reutilizarea dar este apoi mai complexă și prin urmare mai
puțin utilizabilă.

Schimbări pentru reutilizare
 Elimină metodele specifice aplicației.
 Schimbă numele pentru a le face generale.
 Adaugă metode pentru a extinde acoperirea.
 Realizați consistent tratarea exceepțiilor.
 Adaugă o interfață de configurare pentru
adaptarea componentei.
 Integrează componentele necesare pentru a
reduce dependențele.

Componentele sistemului
moștenire
 Sistemele vechi existente care îndeplinesc o
funcție de afaceri utilă pot fi reambalate sub
formă de componente pentru reutilizare.
 Acest lucru implică scrierea unei
componente înveliș care implementează,
furnizează și necesită interfețe apoi
accesează sistemul moștenire.
 Deși costisitoare, aceasta poate fi mult mai
puțin costisitoare decât rescrierea sistemului
existent.
Componente reutilizabile
 Costul de dezvoltare al componentelor
reutilizabile poate fi mai mare decât costul
unor componente echivalente specifice.
Acest cost exagerat al reutilizabilității ar
trebui să fie mai degrabă costul unei
organizații decât al unui proiect.
 Componentele generice pot fi mai puțin
eficiente din punct de vedere al spațiului și
pot avea timpi de execuție mai mari decât
echivalentele lor specifice.

Procesul ISBC
 Când se reutilizează componente, este
esențial să se facă compromisuri între
cerințele ideale și serviciile efective prestate
de componentele disponibile.
 Aceasta implică:
• Dezvoltarea schiței cu cerințe;
• Căutarea componentelor apoi modificarea
cerințelor în funcție de funcționalitatea
disponibilă.
• Căutarea din nou pentru a găsi dacă sunt
componente mai bune care îndeplinesc
cerințele revizuite.
Procesul ISBC
Modify
Outline
Identify candidate requir ements
sy stem
components according to discovered
requir ements
components
Compose
Architectur al Identify candidate
components to
design components
create sy stem

Procesul de identificare al
componentei
Component Component Component

search selection validation

Probleme la identificarea
componentei
 Încredere. Trebuie să puteți avea încredere în
furnizorul unei componente. În cel mai bun caz o
componentă de neîncredere poate să nu
funcționeze cum a fost prezentată; în cel mai rău
caz, poate crea o bresă în securitatea
dumneavoastră.
 Cerințe. Diferite grupuri de componente vor
satisface cerințe diferite.
 Validare.
• Specificațiile componentei pot să nu fie suficient de
detaliate pentru a permite executarea de teste complete.
• Componentele pot avea funcționalități nedorite. Cum
puteți testa că aceasta nu va interfera cu aplicația
dumneavoastră?
Eșecul lansatorului Ariane
 În 1996, la primul test de zbor al rachetei Ariane 5 s-
a terminat cu un dezastru când lansatorul a scăpat
de sub control la 37 de secunde după decolare.
 Problema a survenit din cauza unei componente
reutilizate de la varianta precedentă a lansatorului
(Sistemul de navigație interțial) care a eșuat din
cauza ipotezelor făcuteș; la momentul realizării
componentei, aceasta nu a ținut pentru Ariane 5.
 Funcționalitatea care a eșuat în această
componentă nu era necesară în Ariane 5.

Compunerea componentei
 Procesul de asamblare a componentelor
pentru a crea un sistem.
 Compunerea implică integrarea
componentelor între ele și cu infrastructura
componentei.
 În mod normal, trebuie scris “cod de lipire”
pentru integrarea componentelor.

Tipuri de compunere
 Compunere secvențială în cazul în care
componentele compuse sunt executate în secvență.
Aceasta implică compunerea interfețelor de aducere
pentru fiecare componentă.
 Compunere ierarhică în cazul în care o componentă
apelează la serviciile alteia. Interfața de aducere a
unei componente este compusă cu interfața de
cerințe a alteia.
 Compunere aditivă în cazul în care interfețele a
două componente sunt puse împreună pentru a crea
o nouă componentă.

Tipuri de compunere
A A
A B
B B
(a) (b) (c)

Incompatibilitatea interfeței
 Incompatibilitatea parametrului în cazul în
care operațiile au același nume dar sunt de
tipuri diferite.
 Incompatibilitatea operației în cazul în care
numele operațiilor din interfețele compuse
sunt diferite.
 Incompletitudinea operației în cazul în care
interfața de aducere a unei componente este
un subset a interfeței de cerințe al altei
componente.
Componente incompatibile
string location(string pn)

phoneDatabase (string command)
string owner (string pn)
addressFinder
string proper ty Ty pe (string pn)
display Map (string postCode, scale)

mapDB (string command)
mapper printMap (string postCode, scale)

Componentele adaptorului
 Adresează problema incompatibilității
componentei prin reconcilierea interfețelor
componentelor care sunt compuse.
 În funcție de tipul de compoziție sunt
necesare diferite tipuri de adaptor.
 Un adressFinder și o componentă mapper
pot fi compuse printr-un adaptor care ia
codul poștal de la o adresă și îl trimite la
componenta mapper.

Compunerea printr-un adaptor
 Componenta postCodeStripper este
adaptorul care facilitează compunerea
secvențială a componentelor addressFinder
și mapper.
address =ad dr essFinder.location (phon enu mber ) ;

postCode = pos C t d
oe St rpi pe .rgetPostC d
oe (address) ;
map pe .rdisplay Map(postCod e, 10000)

Adaptor pentru colectorul de date
sensorManagement addSensor
star t removeSensor
star tSensor
stop
sensor Adapter Data collector stopSensor
sensorData testSensor
getdata initialise
repor t
listAll

Semantica interfeței
 Trebuie să vă bazați pe documentația
componentei pentru a decide dacă
interfețele care sunt compatibile din punct de
vedere sintactic sunt realmente compatibile.
 Luați în considerare o interfață pentru o
componentă bibliotecă foto:
public void addItem (Identifier pid ; Photograph p; CatalogEntry p hotodesc) ;

public Photograph retrieve (Identifier pid) ;
public CatalogEntry catEntry (Identifier pid) ;

Compoziția bibliotecii foto
getImage
addItem Image
adaptor Manager
Photo retrieve
Library
catEntry getCatalogEntry
User
Inter face

Documentația bibliotecii foto
“Această metodă adaugă o fotografie la bibliotecă și

asociază identificatorul fotografiei și descriptorul
catalogului cu fotografia.”
“ce se întâmplă dacă identificatorul fotografiei este deja

asociat unei fotografii din bibliotecă?”
“este descriptorul fotografiei asociat cu intrarea
catalogului precum și fotografia ex. dacă șterg
fotografia, șterg de asemenea și informațiile de
catalog?”

The Object Constraint Language
 Object Constraint Language (OCL) a fost
proiectat pentru a defini constrângeri care
sunt asociate cu modelele UML.
 Este bazat în jurul noțiunii specificației
condiției pre și post – similar cu abordarea
utilizată în Z așa cum este descrisă în
capitolul 10.

Descriere formală a bibliotecii foto
-- The co ntext keyword na mes the co mponent to which the conditions apply
context addIte m
-- The precondit io ns spe cify what m us t be true before exe cu tion of addIte m
pre: PhotoL ibrary.libSize() > 0
PhotoL ibrary.retrieve(pid ) = unll
-- The postco nd ti ion s specify w ha t is true after execution

post: lib Size () = libSize ()@pre + 1
PhotoL ibrary.retrieve(pid ) = p
PhotoL ibrary.ca tE ntry(pid) = p hotodesc
context delete
pre: PhotoLibrary.retr ieve(pid) < > null ;
post: PhotoLibrary.retr ieve(pid) = null

PhotoL ibrary.ca tE ntry(pid) = P hotoL ibrary.ca tE ntry(pid)@pre
PhotoL b
i rary.libSize() = lib Size()@pre - 1

Condițiile bibliotecii foto
 Așa cum se specifică, OCL asociat cu componenta
Biblioteca Foto afirmă că:
• Nu trebuie să existe o fotografie în bibliotecă cu același
identificator ca și al fotografiei ce urmează să fie
adăugată;
• Biblioteca trebuie să existe – presupunem că crearea
bibliotecii adaugă un singur element la ea;
• Fiecare intrare nouă crește dimensiunea bibliotecii cu 1;
• Dacă reluați utilizând același identificator atunci primiți
fotografia pe care ați adăugat-o;
• Dacă căutați în catalog folosind identificatorul, atunci
primiți intrarea de catalog pe care ați creat-o.

Compromisuri ale compoziției
 Când compuneți componente, puteți găsi conflicte
între cerințele funcționale și cele nefuncționale, și
conflicte între nevoia de livrare rapidă și evoluția
sistemului.
 Trebuie să luați decizii ca:
• Ce compoziție de componente este eficientă pentru
livrarea cerințelor funcționale?
• Ce compoziție de componente permite pentru schimbarea
viitoare?
• Care vor fi proprietățile emergente ale sistemului
compus?

Colectarea de date și generarea de
rapoarte
(a) Data Data Repor t

collection management generator Repor t
Data
(b) Data base
collection Repor t

Puncte cheie
 ISBC este o abordare bazată pe reutilizare pentru
definirea și implementarea componentelor slab
cuplate în sisteme.
 O componentă este o unitate software a cărei
funcționalitate și dependețe sunt complet definite de
interfețele sale.
 Un model de componentă definește un set de
standarde pe care furnizorii de componente și
producătorii ar trebui să-l urmeze.
 În timpul procesului ISBC, procesele ingineriei de
cerințe și proiectării de sistem sunt intercalate.

Puncte cheie
 Compoziția componentei este procesul de
“cablare” a componentelor împreună pentru
a crea un sistem.
 Când realizați componente reutilizabile, în
mod normal trebuie să scrieți adaptoare
pentru a reconcilia diferite interfețe ale
componentei.
 Când alegeți compoziții, trebuie să luați în
considerare funcționalitatea necesară,
cerințele nefuncționale și evoluția sistemului.

Dezvoltarea sistemelor critice

Obiective
 Pentru a explica ce este toleranța la erori și
cum evitarea defectelor contribuie la
dezvoltarea unor sisteme fiabile
 Pentru a descrie caracteristici ale proceselor
software de încredere
 Pentru a introduce tehnici de programare
pentru evitarea defectelor
 Pentru a descrie mecanismele de toleranţă
şi utilizarea lor de diversitate şi redundanţă

Subiecte abordate
 Procesele de încredere
 Programare sigură
 Toleranţă la defecte
 Arhitecturi tolerante la defecte

Fiabilitate Software
 În general, clienții se așteaptă ca toate
programele software să fie de încredere. Cu
toate acestea, pentru aplicații non-critice, ele
pot avea unele erori de sistem.
 Unele aplicaţii, au totuşi cerinţe de înaltă
fiabilitate şi tehnicile de inginerie software
speciale pot fi folosite pentru a realiza acest
lucru.

Realizarea fiabilităţii
 Evitarea defectului
• Sistemul este astfel conceput incat eroarea facută de om este evitată şi
astfel defectele sistemului sunt reduse la minim.
• Procesul de dezvoltare este organizat astfel încât defectele din sistem
sunt detectate şi reparate înainte de livrare la client.
 Detectarea defectului
• Tehnicile de verificare și validare sunt folosite pentru a
descoperi și a elimina defectele dintr-un sistem înainte de
a fi implementat.
Toleranţa la defect
• Sistemul este proiectat astfel incat defectele din software-
ul livrat să nu ducă la defectarea sistemului.

Diversitate și redundanță
 Redundanță
• Păstrați mai mult de 1 versiune a unei componente critice
disponibile, astfel încât, dacă unul nu reușește, atunci o
copie de rezervă este disponibilă.
 Diversitate
• Furnizează aceeaşi funcţionalitate în moduri diferite astfel
încât acestea să nu se defecteze în acelaşi mod.
Cu toate acestea, adaugand diversitate și
redundanță adaugă complexitate și acest lucru
poate crește șansele de eroare.
 Unii ingineri susțin că V & V simplă și extinsă este o
cale mai eficientă pentru fiabilitatea software-ului.

Exemple diversitate și redundanță
 Redundanţă. Unde disponibilitatea este

critică (de ex. în sistemele de e-commerce),
companiile pastreaza de obicei servere de
backup şi comută la acestea automat dacă
apare o defecţiune.
 Diversitate. Pentru a oferi rezistență
împotriva atacurilor externe, diferite servere
pot fi implementate folosind diferite sisteme
de operare (de exemplu, Windows și Linux)

Software Fault-free
 Metodele actuale de inginerie software permit
producerea de software fiabilă, cel puțin pentru
sistemele relativ mici.
 Software fault-free este un software care respectă
specificaţia sa. Asta nu înseamnă că este un
software care va efectua întotdeauna corect, pot
apărea erori de specificaţie.
 Costul de producţie al unui astfel de software este
foarte mare. Este rentabil numai în situaţii
excepţionale. Este mai ieftin să accepte adesea
defectele de software și să plătească pentru
consecințele acestora decât să cheltuiască
resursele pe dezvoltarea de software fără defecțiuni.

Dezvoltare de software fără
defecte
 Procese software de încredere
 Administrare de calitate
 Specificație formală
 Verificarea statică
 Testare puternică
 Programare sigură
 Informaţii protejate

Costurile de îndepărtare a
defectului

Procesele de încredere
Pentru a asigura un număr minim de defecte
software, este important a avea un proces
software repetabil bine definit.
 Un proces repetabil bine definit este unul
care nu depinde în întregime de aptitudinile
individuale; mai degrabă poate fi adoptat de
persoane diferite.
 Pentru detectarea erorilor, este clar că
activitățile de proces ar trebui să includă un
efort considerabil dedicat verificării și
validării.
Caracteristicile procesului de
încredere
Documentate: procesul ar trebui să aibă un model de proces definit care
stabilește activitățile în proces și documentația care trebuie să fie
produse în timpul acestor activități
Standardizate: Un set cuprinzător de standarde de dezvoltare software care
definesc modul în care software-ul este produs și documentat
trebuie să fie disponibil.
Auditabile: Procesul ar trebui să fie ușor de înțeles de către oameni în afară
de participanții de proces care pot verifica faptul ca standardele
procesului sunt urmate și să facă sugestii pentru imbunatatirea
proceselor.
Diverse: Procesul ar trebui să includă activități de verificare și de
validare redundante și diverse.
Robust: Procesul ar trebui să poată recupera de la eșecuri activități
individuale de proces.

Activități de validare
 Cerințe de inspecții.
 Cerinţele de management.
 Verificarea modelului.
 Inspectia design-ului si a codului
 Analiza statică.
 Test de planificare şi de gestionare.
 Managementul configurației, discutat în
capitolul 29, este de asemenea esențial.

Programare sigură
 Utilizaţi concepte şi tehnici de programare
care contribuie la evitarea defectului şi
toleranţă la defect
• Design pentru simplitate;
• Protejarea informațiilor de accesul neautorizat;
• Minimizarea utilizarii construcțiilor de
programare nesigure.

Protecţia informaţiilor
 Informațiile ar trebui să fie expuse numai acelor părți
ale programului care au nevoie sa le acceseze.
Aceasta implică crearea de obiecte sau tipuri de
date abstracte care mențin starea și care furnizează
operațiunile pe această stare.
 Astfel se evită defecțiunile pentru trei motive:
• probabilitatea de corupție accidentala de informații este redusă;
• informația este înconjurata de "firewall-uri, astfel că
problemele sunt mai putin probabil raspandite in alte parti
ale programului;
• cum toate informațiile sunt localizate, avem mai puține
sanse de a face erori și comentatorii au mai multe sanse
de a găsi erori.

O specificație în Java
in trfeace ue
Q u{ e
p bli
u c v d o pi(Ou ject
tb o) ;
p bli
u c v d o move
r i e (O ject
b )o;
p bli
u c t isn iez ) ;(
} // Q ue e u

Declarație de semnal în Java
c as
l s g Snl i a{
st ai ct u plbi cfin la ni rt e =d ;1
st ai ct u plbi cfin la ni at m r b =2e ;
st ai ct u plbi cfin la ni gt r en e3= ;
p bli
u c t isngSt
i a te ;
}

Programare sigură
 Defecțiunile unor programe sunt, de obicei o
consecință a programatorilor care fac
greșeli.
 Aceste greșeli apar deoarece oamenii pierd
evidența relațiilor dintre variabilele de
program.
 Unele construcții de programare sunt mai
predispuse la erori decât altele, astfel
evitându-se utilizarea lor se reduc greșelile
de programator.
Programare structurată
 Propusă pentru prima dată în 1968 ca o abordare de
dezvoltare care face programele mai ușor de înțeles
și care să evite erorile de programator.
 Programare fără ‘Go to’.
 Buclele ‘while’ şi declarţiile ‘if’ singurele declaraţii de
control
 Design de sus în jos.
 O dezvoltare importantă, deoarece a promovat
gândire și discuții despre programare.

Construcţii predispuse la erori
 Numerele în virgulă mobilă
• Inerent imprecise. Imprecizia poate duce la comparații invalide.
• Pointerii
• Pointerii care referă la zone de memorie greșită pot
corupe date. Alias-urile pot face programele greu de
înțeles şi de schimbat.
 Alocare de memorie dinamică
• Alocarea run-time poate provoca overflow de memorie.
 Paralelism
• Poate duce la erori de sincronizare subtile din cauza
interacțiunii neprevăzute dintre procesele paralele.
 Recursivitate
• Erori de recursivitate pot provoca overflow de memorie.

Construcţii predispuse la erori
 Întreruperi
 Întreruperile pot cauza o terminare subită a programului şi pot
face un program dificil de înţeles.
 Moştenire
• Codul nu este localizat. Acest lucru poate duce la un
comportament neașteptat atunci când sunt făcute
schimbări şi apar probleme de înţelegere.
Aliasing
• Utilizarea mai multor nume pentru a referi aceeași
variabilă de stare.
Matrice nemărginite
• Poate apărea o depăşire a zonei de defecţiuni.
 Prelucrare implicită de intrare
 O acțiune de intrare care are loc, indiferent de intrare.

Tratarea excepţiilor
 O excepție program este o eroare sau un eveniment
neașteptat, cum ar fi o pană de curent.
 Construcţiile de tratare a excepţiilor permit
evenimente care urmează a fi tratate fără a fi nevoie
de o verificare continuă a detectării excepţiilor.
 Pentru utilizarea de construcţii de control normale
pentru detectarea excepţiilor este nevoie să fie
adăugate mai multe declaraşii suplimentare în
program.

Excepții în Java 1
cl ass SensorFai lure E

xcept oi n extends Excepti on {
SensorFail ureE cep x iont (Stri ng mg) {s

super (msg) ;
Al ar m. act vi at e(msg) ;
}
} // SensorFa lureException
i

Excepții în Java 2
class Sensor {
int readV al () thro ws S ensorFailureExce pt ion {
try {
int theValue = DeviceIO. re ad Integer ( ) ;
if ( th eValue < 0)
throw ne w eSnsorFailureException ( "S ensor failure" ) ;
return theV alue ;
}
ca tch (deviceIO Except io n e)
{
throw ne w eSnsorFailureException (“ Sensor read error ”) ;
}
} // read Va l
} // Sensor

Un controler de temperatură
 Excepții pot fi folosite ca o tehnică de programare
normală și nu doar ca o modalitate de recuperare de
la defecte.
 Să considerăm un exemplu de un controler de
congelator care mentine temperatura congelatorului
într-un interval specificat.
 Comută o pompă de refrigerare ”on - off”.
 Declanșează o alarmă când temperatura maximă
permisă este depășită.
 Folosește excepții ca o tehnică de programare
normală.

Controler Congelator 1
cl ass FreezerContro lel r {

Sensor t em Se p n sor = ew n Snsor
e ( );
Dial et m pDial = ew n ial D () ;
float reezerT
f m
ep = te mpS nsor.
e read V a (l );
final loat
f d angerTe m p= fo (l at) -18.0 ;
final ol ng cool in g T mi e (long)
= 20 000.0 ;
publ ic void ru n() thro w s Int erruptedExce p toin{
try { Pum .pswitchI t (Pum .pon) ;
do {
if (reezerTem
f p te>m pDial .sett nig()
if (Pum .stp atus == Pu m p off)
.
{ Pum .pswitchI t (Pum .pon) ;
Thread.s eep l coo
( ingTime)
l ;
}
Controler Congelator 2
if ( reezerTem
f p > angerTem
d )p
throw ne w r eFezerT o HotExce pt ion () ;
freezerT e mp =te mpS e nsor. read Va l( ) ;
} while (t rue) ;
} / / try block
ca ch t (FreezerTooH toExcept ion f )
{ Alar m. act iv at e ( ) ; }
ca ch t ( nterruptedExcept
I io ne)
{
System.out .pr intln (“Thread exception”) ;
throw ne wInter rupted Except ion ( ) ;
}
} / /run
} / / Fre ezerCont roller

Toleranţa la defect
 În situații critice, sistemele software trebuie să fie

tolerante la defect.
 Toleranța la defect este necesară în cazul în care
există cerințe mari de disponibilitate sau în cazul în
care costurile de eroare din sistem sunt foarte mari.
 Toleranța la defect înseamnă că sistemul poate
continua să funcţioneze, în ciuda eșecului software.
 Chiar dacă sistemul a fost dovedit a fi conform cu
specificațiile sale, acesta trebuie să fie, de
asemenea, tolerant la defect pentru ca pot exista
erori de specificație sau validarea poate fi incorectă.

Acţiuni de toleranţă la defect
 Detectarea defectelor
• Sistemul trebuie să detecteze că a avut loc un defect (o stare incorectă
în sistem).
 Evaluarea pagubelor
• Părțile stărilor sistemului afectate de defect trebuiesc detectate.
 Recuperarea defectului
• Sistemul trebuie să restabilească starea la una de siguranță.
Repararea defectului
Sistemul poate fi modificat pentru a preveni repetarea
defecțiunii. Multe defecte de software sunt trecătoare,
acest lucru fiind de multe ori inutil.

Detectarea defectului si evaluarea
pagubelor
 Prima etapă a toleranței la defecte este de a

detecta faptul că un defect (o stare eronată
de sistem) a avut loc sau va avea loc.
 Detectarea erorilor implică definirea unor
constrângeri care trebuie să dețină pentru
toate stările şi verificarea stării împotriva
acestor constrângeri.

Constrângeri de stare la pompa
de insulină
// Doza de insulină care trebuie sa fie distribuita trebuie să fie î

// Decât zero și mai mică decat unele doze unice maxime definite
insulin_dose >= 0 & insulin_dose <= insulin_reservoir_contents
// Cantitatea totală de insulină distribuită într-o zi t

// Mică sau egală cu o doză zilnică maximă definită
cumulative_dose <= maximum_daily_dose

Detectarea defectelor
 Detectarea defectelor preventiv
• Mecanismul de detecţie a erorilor este inițiat
înainte de schimbarea de stare. În cazul în care
este detectată o stare eronată, schimbarea nu
se face.
 Detectarea defectelor retrospectiv
• Mecanismul de detecţie a erorilor este iniţiat
după ce starea sistemului a fost schimbată .
Acest lucru este utilizat atunci când o secvență
de acțiuni corecte duce la o stare eronată.

Type system extension
 Detectarea erorilor preventivă implică într-
adevăr extinderea sistemului de tip prin
includerea constrângeri suplimentare, ca
parte a definiţiei tip.
 Aceste constrângeri sunt implementate prin
definirea unor operații de bază din cadrul
unei clase.

PositiveEvenInteger 1
class Posit iveEvenInteger {
int val =0 ;
Posit vi eEvenInteger (int n) hro

t ws N u emircException
{
if (n < 0 | n% 2 = 1)
=
throw ne w um N reci Exception () ;
else
va l= n ;
}// PositiveEv en nteger

I

PositiveEvenInteger 2
public void assign int ( n) t hrow s um
N reicException
{
if (n < 0 | n% 2 = =
1)
throw ne w umN reicException () ;
else
va l= n ;
} / / a ss gn
i
int to nteI ge r( )
{
return val ;
} / / ot In et ger
boolean qua e sl Posit

( iveEvenInteger n)
{
return (val == .va
n )l ;
} / / e quals
} / /PositiveEv en

Evaluarea pagubelor
 Analiza de stare judeca gradul de defectare
cauzat de o eroare de sistem.
 Evaluarea trebuie să verifice care părți ale
spațiului de stari au fost afectate de
defectiune.
 În general, pe baza "funcțiilor de validitate",
pot fi aplicate elementelor de stare pentru a
evalua dacă valoarea lor este într-un interval
permis.

Matrice robust 1
cl ass Robu tsArray {
// Checks that all the obj ects n

i an a ray
r foobject s
// conform to so m e def n
i ed onstrai
c nt
boolean [] checkState ;
Checkable Ob ect
j [] theR boustArr ay ;
RobustArray (C ehckab el Object [] th eArr ay)

{
checkSta et = ewn bo ean
ol t [he Ar ray.length] ;
theR boustArray = heArray
t ;
} / /Rob u
s Array
t

Matrice robust 2
public void assessD ama ge () th ro ws Arr ay Dam agedE xception
{
boolean hasBeen Dam aged = f alse ;
for (int = i 0; i <this .the RobustAr ray.len gth ; i ++)

{
if ( ! heRob
t us tArray [i] .check () )
{
checkSta e t i][ = rtue ;
hasBeen Dam aged = t rue ;
}
else
checkSta te i][ = af sl e ;
}
if (hasBe enDam age d)
throw ne w rArayD ama gedExce pt ion ( ) ;
} / /assessD ama ge
} / / R obustArray

Tehnici de evaluare daune
 Sumele de control sunt utilizate pentru
evaluarea daunelor în transmisia de date.
 Pointerii redundanţi pot fi folosiţi pentru a
verifica integritatea structurilor de date.
 Cronometre watchdog pot verifica procesele
non-terminale. În cazul în care nu apare nici
un răspuns după un anumit timp, se
presupune că este o problemă.

Repararea defectului
Forward recovery
• Aplicați reparații la o sistem de stări stricat.
 Backward recovery
• Restaurarea stării sistemului la o stare de siguranță
cunoscută.
 Forward recovery este, de obicei aplicație specifică
- cunoștințele de domeniu sunt necesare pentru a
evalua posibilele corecții stare.
 Backward recovery este mai simplă. Detaliile privind o
stare sigură sunt menținute și astfel se înlocuiește
starea sistemului stricat.

Forward recovery
 Corupția de codificare a datelor
• Tehnicile de codificare a erorilor care adaugă redundanță
datelor codificate pot fi folosite pentru repararea datelor
stricate în timpul transmisiei.
Pointeri redundanţi
• Când pointerii redundanţi sunt incluşi în structuri de date
(de exemplu, liste cu două sensuri), o listă stricata poate fi
reconstruită în cazul în care suficienţi pointeri sunt corecţi
• Adesea folosit pentru repararea bazelor de date
și sistemelor de fișiere

Backward recovery
 Tranzacțiile sunt o metodă utilizată frecvent
de backward recovery. Modificările nu se
aplică până când evaluarea este completă .
Dacă apare o eroare, sistemul este lăsat în
starea anterioară tranzacției.
 Punctele de control periodice permit

sistemului să revină într-o stare corectă

Procedura de sortare în siguranţă
 O operație de sortare monitorizeaza propria execuție

și evaluează dacă sortarea a fost executată corect.
 Bazată pe identificarea și tratarea excepțiilor.

Sortare sigură 1
class SafeSort {
st atic ovid sor t ( in t [ ] tarr

i n ay, int order ) thro ws S or tErro r
{
int [] copy = new int [in at rray. length] ;
// copy he
t input a ray
for (int i= 0 ;i < intar ray.length ; i++)

copy [i] = ni at rray [i] ;
try {
Sort .bubblesor t ( intar ray, intar ray.len gt h, orde )r ;

Sortare sigură 2
if (orde r== Sr toasc . ending)

for (int i= 0 ;i <= intarray .length 2- i++) ;
if ( ntar
i ray [ i] > nti array [i+1])
throw ne w oStrError () ;
else
for (int i= 0 ;i <= intarray .length 2- i++) ;
if ( ntar
i ray [ i+1] >intar ray [ i ])
throw ne w oStrError () ;
} / / try block
ca ct h (SortEr ror e )
{
for (int i= 0 ;i < intar ray.length ; i++)
intar ray [ i ]= copy [i] ;
throw ne w oStrError (" Array n ot sort ed" ) ;
} / /catch
} / / so tr
} / /S a feSor t

Arhitectura toleranţei la defect
 Programare defensivă nu poate face față defectelor
care implica interactiunile dintre hardware și
software-ul.
 Neînțelegerile privind cerințele pot însemna că
verificările și codul asociat sunt incorecte.
 În cazul în care sisteme au cerințe mari de
disponibilitate, poate fi necesară o arhitectura
specifică pentru a sprijini toleranța la defect.
 Acest lucru trebuie să tolereze defectele atât
hardware cât și software.

Toleranţa la defect hardware
 Depinde de redundanță triplă-modulară (TMR).
 Există trei componente identice care primesc
aceeași intrare și ale căror ieșiri sunt comparate.
 Dacă o ieșire este diferită, aceasta este ignorată și
se presupune defectarea unei componente.

Fiabilitatea hardware cu TMR
A1
Output
A2
compar ator
A3

Selecție de ieșire
 Comparatorul de ieșire este o unitate de
hardware simplă.
 Compară semnalele de intrare și, în cazul în
care unul este diferit de celelalte, îl respinge.
 Comparatorul de ieșire este conectat la o
unitate de management de defect care
încearcă să repare unitatea defectă.

Arhitecturi software tolerante la
defect
 Succesul TMR oferă toleranță la defecte şi se

bazează pe două ipoteze fundamentale
• Componentele hardware nu includ defecte de design
comune;
• Componente se defectează la întâmplare și există o
probabilitate mică de defectare simultană a
componentelor.
 Niciuna dintre aceste ipoteze nu sunt adevărate
pentru software
• Nu este posibil, pur și simplu a se reproduce aceeași
componentă ca şi cum ar avea defecte de design
comune;
• Defectarea simltană a componentelor simultană este
practic inevitabilă. Sistemele de software trebuie să
fie diverse.
Diversitatea de proiectare
 Diferite versiuni ale sistemului sunt concepute și
puse în aplicare în moduri diferite. Acestea ar trebui
să aibă moduri diferite de defectare.
 Abordări diferite pentru a proiecta (de exemplu,
orientat pe obiect)
• Implementarea în diferite limbaje de programare
• Utilizarea de diferite instrumente și medii de
dezvoltare
• Utilizarea de diferiţi algoritmi în implementare.

Analogii software în TMR
 Versiunea-N de programare
• Aceeași specificație este pusă în aplicare de un număr
diferit de versiuni de echipe diferite. Toate versiunile de
evaluare simultane și majoritatea ieșirilor sunt selectate
cu ajutorul unui sistem de vot.Aceasta este
abordarea cea mai frecvent utilizată de exemplu
în multe modele de aeronave comerciale
Airbus.
 Blocuri de recuperare
• Un număr de diferite versiuni explicite ale aceleași
specificații sunt scrise și executate în secvență.

Versiunea-N de programare
Version 1
Input
Output
Version 2
comparator
Agreed
result
Version 3
Fault
manager
N-versions

Comparație ieșire
 Ca în sisteme hardware, comparatorul de
ieșire este o simplă bucată de software care
utilizează un mecanism de vot pentru a
selecta ieșirea.
 În sistemele în timp real, poate exista o
cerință ca rezultatele din diferite versiuni să
fie produse într-un anumit interval de timp.

Versiunea-N de programare
 Diferitele versiuni ale sistemului sunt
concepute și implementate de către echipe
diferite. Se presupune că există o
probabilitate scăzută ca vor face aceleași
greșeli.

Blocuri de recuperare
Try algorithm Test f or

1 success
Acceptance
Algorithm 1 Contin ue e xecution if
test
acceptance test succeeds
Signal e xception if all
algorithms fail
Acceptance test Retry
fails – r etry Re-test Re-test
Algorithm 2 Algorithm 3
Recovery blocks

Blocuri de recuperare
 Acestea forțează un algoritm diferit pentru a
fi utilizat pentru fiecare versiune, astfel încât
acestea reduc probabilitatea erorilor
comune.
 Testului de acceptare trebuie să fie
independent de calculele utilizate.
 Există probleme cu această abordare pentru
sistemele în timp real, din cauza funcționării
secvențiale a versiunilor redundante.

Probleme cu diversitatea de
design
 Echipele au tendința de a aborda problemele în
același mod.
 Erori caracteristice
• Diferite echipe face aceleași greșeli . Unele părți ale
implementării sunt mult mai dificile decât altele, astfel
toate echipele au tendința de a face greșeli în același loc;
• Erori specifice
• Dacă există o eroare în specificaţii, atunci acest lucru se
reflectă în toate implementările;
• Acest lucru poate fi abordat într-o anumită măsură, prin
utilizarea mai multor reprezentări de specificaţii.

Specificații dependență
 Ambele abordări ale software cu redundanță sunt
sensibile la specificatia erorilor. În cazul în care
specificaţia este incorectă, sistemul s-ar putea
defecta
 Este, de asemenea, o problemă cu hardware-ul, dar,
de obicei, specificaţiile software sunt mai complexe
decât specificații hardware și mai greu de validat.
 Acest lucru a fost abordată în unele cazuri, prin
dezvoltarea specificațiilor software separat de
aceeași specificație de utilizator
 .

Puncte cheie
 Fiabilitate într-un sistem poate fi realizată prin
evitarea erorilor, detectarea erorilor și toleranța la
erori.
 Utilizarea de redundanţă și diversitate este esențială
pentru dezvoltarea unor sisteme fiabile.
 Utilizarea unui proces repetabil bine definit este
importantă dacă defecțiunile dintr-un sistem trebuie
să fie reduse la minimum.
 Unele construcții de programare sunt în mod inerent
predispuse la erori - folosirea lor ar trebui evitată ori
de câte ori este posibil.

Puncte cheie
 Excepțiile sunt folosite pentru a sprijini
managementul erorilor în sistemele de
incredere.
 Cele patru aspecte ale programului tolerant
la defecte sunt: detectarea defectelor,
evaluarea pagubelor, recuperarea defectelor
și repararea acestora.
 Versiunea-N de programare și recuperarea
blocurilor sunt abordări alternative la
arhitecturile tolerante la defecte.
Evolutia Software-ului

Obiective
● Pentru a explica de ce schimbarea este
inevitabiă dacă vrem ca sistemele software
să rămână utile
● Pentru a discuta factori de cost de întreţinere
şi de întreţinere software
● Pentru a descrie procesele implicate in
evoluţia software
● Pentru a discuta o abordare a evaluării
strategiilor de evoluție pentru sistemele vechi

Subiecte Acoperite
● Evoluția dinamică a unui program
● Mentenanța software
● Evoluția proceselor
● Evoluția sistemului existent

Schimbarea Software
● Schimbarea software este inevitabilă
• Noi cerințe apar atunci când o aplicație software este
folosită;
• Schimbările mediului de afaceri;
• Erorile trebuie reparate;
• Sistemului sunt adaugate noi calculatoare sau
echipamente;
• Funcționarea sau fiabilitatea sistemului ar putea fi
îmbunătățite .
● O problemă cheie pentru organizații este sa
implementează și sa gestionarea schimbării in
sistemelor lor software existente .

Importanța evoluției
● Organizațiile investesc mulți bani în sisteme
software - ele sunt criticale pentru bunurile
afacerilor
● Pentru a menține valoarea acestor bunuri ele
trebuiesc schimbate și întreținute la zi.
● Majoritatea bugetului dedicat pentru software
de marile companii e dedicat în evoluția
softeareului actual decât să creeze unul nou

Modelul spiral al evoluției
Specification Implemention
Star t
Release 1
Operation Validation
Release 2
Release 3

Evoluția dinamică a programului
● Evoluția dinamică a programului e studiul
procesului unei schimbări de sistem
● După studii empirice majore, Lehman și
Belady propus că au existat o serie de "legi",
care se aplicau la toate sistemele de drept
cum au evoluat.
● Există observații sensibile decât legi ele sunt
aplicate sistemelor mari dezvoltate de
organizații mari. Poate mai puțin aplicabila în
America organizații mai mici

Legea lui Lehman’s

Aplicații ale legi lui Lehman’s
● Legile lui Lehman par a fi, în general, aplicabile

sistemelor mari, adaptate dezvoltate de organizații
mari.
• Confirmate în lucrări mai recente de Lehman cu privire la
proiectul FEAST
● Nu este încă clar pentru ce ar trebui modificat pentru
• Pachete mici de aplicații software
• Sisteme care încorporează un număr semnificativ de
componente COTS;
• Organizații mici
• Sisteme de mărime medie

Mentenanță software
● Modificarea unei aplicații după ce a fost pusă
în funcțiune.
● Mentenanță nu influențează în mod normal
schimbări majore în arhitectura sistemului.
● Schimbările sunt implementate prin
modificarea componentelor si adaugarea de
noi componente sistemului

Mentenanță este inevitabilă
● E foarte probabil ca cerințele sistemului să se
schimbe în timp ce e dezvoltat deoarece se schimba
și mediul. Așa ca un sistem livrat nu o să facă față
cerințelor
● Sisteme sunt între o legătură foarte strânsă cu
mediu. Când un sistem e instalat întrun mediu de
lucru acesta schimba mediul iar de aici rezultă
schimbarea cerințelor pentru sistem
● Sistemele trebuiesc întreținute dacă vor să fie
folosite în continuare în mediul de lucru

Tipuri de Mentenanta
● Mentenanta pentru a repara probleme in sistem
• In sistem au loc schimbari pentru a corecta deficientele
pentru a satisface nevoie cerute.
● Mentenanta pentru a adapta software-ul pentru un
mediu diferit de operare
• Schimbarea unui sistem pentru a putea opera in diferite
medii (computer, SO, etc.) de la implementarea initiala
● Mentenanta pentr a adauga sau modifica
functionalitatea sistemului
• Modificarea sistemului pentru a satisface noile cerinte.

Distributia efortului pentru
mentenanta
Fault repair
(17%)
Functionality
Software
addition or
adaptation
modification
(18%)
(65%)

Costul Mentenantei
● De regula costa mai mult decat costul dezvoltarii ( 2
* 100* depinde de aplicatie)
● Este afectat atat de factori tehnici cat si non-tehnici
● Crest ca si software atat cat este mentenanta.
Mentenanta corupte structura software ceea ce duce
la mentenanta mai dificila
● Varsta software poate avea costuri crescute. (ex.
limbaje invechite, compilatoare etc.)

Costuri Dezvoltare/mentenanta
Sy stem 1
Sy stem 2
450 $
0 50 100 150 200 250 300 350 400 500
Development costs Maintenance costs

Factorii costului de Mentenanta
● Stabilitatea echipei
• Costul mentenantei este reduc daca aceasi echipa e
implicata cu ea de ceva timp
● Responsabilitatea contractuala
• Developerii unui sistem poate sa nu aiba nici o
responsabilitate contractuala pentru mentenanta ceea ce
rezulta ca poate nu e nici un design pentru o viitoare
schimbare
● Calificarea echipei
• Echipa de mentenanta de multe ori este fara experienta si
au putina experienta in domeniu

Predictia Mentenantei
● Predictia mentenantei este concetrata cu evaluarea
carui parti cauzeaza probleme si are costuri de
mentenanta ridicate
• Schimbarea acceptata depinde de întreținere a
componentelor afectate de modificare;
• Schimbări de punere în aplicare degradează sistemului și
reduce mentenabilitatea sa.
• Costul Mentenatei depinde de numarul de schimbari si
costul schimbari depinde de mentenabiltiate

Predictia mentenabilitati
What par ts of the sy stem

willbethemostexpensive
Whatpar tsof thesystem are to maintain?
mostlikely tobeaffectedby
change requests?
Predicting
maintainability
What will be the lifetime

maintenance costs of this
Predicting sy stem Predicting sy stem?
changes maintenance
costs
What will be the costs of

How many change maintaining this sy stem
requests can be over the next y ear?
expected?

Schimbarea predictiei
● Prezicerea numărul de modificări necesită și
înțelegere a relațiilor dintre un sistem și mediul său
● Bine sistemele cuplate necesită modificări de fiecare
dată când este schimbat mediul.
● Factorii care influențează această relație sunt
• Numărul și complexitatea interfețelor sistemului;
• Numărul de cerințe de sistem în mod inerent volatile;
• Procesele de business unde sistemul este utilizat.

Metrici de complexitate
● Predicțiile de mentenabilitate pot fi făcute prin
evaluarea complexitatea componentelor sistemului.
● Studiile au arătat că cele mai multe un efort de
întreținere este cheltuit pe un număr relativ mic de
sistem.
● Complexitatea depinde de
• Complexitatea structuri de control;
• Complexitatea structuri datei;
• Obiect, metoda (procedura) si marimea modului.

Metrici de process
● Măsurători de proces pot fi utilizate pentru a
evalua mentenabilității
• Numărul de cereri de întreținere corectivă;
• Timpul mediu necesar pentru analiză de impact;
• Durata medie de a pune în aplicare o cerere de
schimbare;
• Numărul de cereri de schimbare restante.
● Dacă oricare sau toate dintre acestea este în
creștere, acest lucru poate indica o scădere
a mentenabilitatea.

Evolutia Procesului
● Procese de evoluție depinde de
• Tipul de software fiind menținută
• Proceselor de dezvoltare folosite;
• Abilitățile și experiența persoanelor implicate.
● Propuneri de modificare sunt driverul pentru
a evoluției sistemului. Schimbare de
identificare și evoluția continuă pe toată
durata de sistem.

Schimbare de identificare și evoluția
Change identification
process
New sy stem Change proposals
Software evolution
process

Procesul de evoluție de sistem
Change Impact Release Change Sy stem

requests anal y sis planning implementa tion release
Platform Sy stem
Fault repair
adaptation enhancement

Schimbare implementari
Proposed Requirements Requir ements Software

changes anal y sis upda ting de velopment

Cererilor de schimbare urgente
● Modificări urgente ar putea fi puse în
aplicare fără a trece prin toate etapele
procesului de inginerie software
• În cazul în care o defecțiune gravă de sistem
trebuie să fie reparate;
• Dacă modificările aduse mediului sistemului (de
ex, un upgrade sistem de operare) au efecte
neașteptate;
• Dacă există modificări de afaceri care necesită
un răspuns foarte rapidă (de ex, lansarea unui
produs concurent).

Reparații de urgență
Change Analy se Modify Deliver modified

requests sour ce code sour ce code sy stem

Sistemul de re-inginerie
● Re-structurare sau re-scriere o parte sau toate dintr-
un sistem de moștenire fără a schimba
funcționalitatea.
● Aplicabile în cazul în care unele, dar nu toate sub-
sistemele de un sistem mai mare necesită
întreținere frecventă.
● Re-ingineria implica adaugarea efort pentru a le face
mai usor de intretinut. Sistemul poate fi re-structurat
și re-documentat.

Avantajele re-ingineriei
● Reduce riscul
• Există un risc ridicat in new dezvoltarea de
software. S-ar putea fi probleme de dezvoltare,
probleme de personal și probleme de
specificație.
● Reduce costul
• Costul de re-ingineriei de multe ori semnificativ
mai mică decât costurile de dezvoltare software
nou.

Inainte si re-inginerie
Sy stem Design and New

specification implementation sy stem
Forward eng ineering
Existing Understanding and Re-engineer ed

softw are sy stem transf ormation sy stem
Softw are re-eng ineering

Procesul re-ingineriei
Original Program Modularised Original data

program documentation program
Reverse
eng ineering
Data
Source code Program re-engineering
translation modularisation
Program
structure
improvement
Structured Re-engineered
prog ram data

Activitatile procesului reingineriei
● Traducerea codului sursa
• Convertirea codului la un nou limbaj.
● Inginerie Inversa
• Analiza programului pentru a fi inteles;
● Imbunatatirea structuri programului
• Restructurarea automata pentru o intelegere mai usoara;
● Modularea programului
• Reorganizarea structuri programu;
● Re-ingineria datei
• Curatare si restructurare datei de sistem.

Abordari re-ingineresti
Automa ted pr ogram Program and da ta

restructuring restructuring
Automated sour ce Automa ted r estructuring Restructuring plus

code con version with man ual changes architectur al changes
Increased cost

Factori ai costului de re-inginerie
● Calitatea software-ului care urmează să fie
reproiectate.
● Sprijinul instrument disponibil pentru
reengineering.
● Gradul de conversie de date, care este
necesară.
● Disponibilitatea personalului de specialitate
pentru reengineering.
• Acest lucru poate fi o problemă cu sistemele
vechi pe baza de tehnologie care este folosit pe
scară largă nu mai este.

Evoluția sistemului existent
● Organizațiile care se bazează pe sistemele vechi
trebuie să aleagă o strategie de evoluție a acestor
sisteme
• Casarea sistemul complet și modifica procesele de
afaceri, astfel încât nu mai este necesar;
• Continuarea menținerea sistemului;
• Transformarea sistemului de re-inginerie pentru a
îmbunătăți mentenabilitatea acesteia;
• Înlocuiți sistemul cu un nou sistem.
● Strategia aleasă ar trebui să depindă de calitatea
sistemului și valoarea sa in afaceri.

Calitate de sistem și valoarea de
afaceri

Categorii sistemului existent
● Slabă calitate, valoare scăzută de afaceri
• Aceste sisteme ar trebui să fie casate.
● Valoare mica, valoare mare de afaceri
• Acestea aduc o contribuție importantă de afaceri, dar sunt
scumpe pentru a menține. Ar trebui să fie re-inginerie sau
înlocuit în cazul în care un sistem adecvat este disponibil.
● De înaltă calitate, valoare scăzută in afaceri
• Inlocuire cu COTS, Casare completa sau mentenanta
● De înaltă calitate, de mare valoare in afaceri
• Continuă în funcționare cu întreținerea normala a
sistemului.

Categorii sistemului existent
● Slabă calitate, valoare scăzută de afaceri
• Aceste sisteme ar trebui să fie casate.
● Valoare mica, valoare mare de afaceri
• Acestea aduc o contribuție importantă de afaceri, dar sunt
scumpe pentru a menține. Ar trebui să fie re-inginerie sau
înlocuit în cazul în care un sistem adecvat este disponibil.
● De înaltă calitate, valoare scăzută in afaceri
• Inlocuire cu COTS, Casare completa sau mentenanta
● De înaltă calitate, de mare valoare in afaceri
• Continuă în funcționare cu întreținerea normala a
sistemului.

Evaluarea valorii de afaceri
● Evaluare ar trebui să ia în considerare
puncte de vedere diferite
• Utilizatorii finali ai sistemului;
• Clienti de afaceri;
• Manageri de linie;
• Manageri IT;
• Manageri Seniori.
● Interviu diferitelor părți interesate și
strângerea rezultatelor.

Evaluarea calității sistemelor
● Evaluarea procesului de afaceri
• Cât de bine se procesul de afaceri susține
obiectivele actuale ale afacerii?
● Evaluării de mediu
• Cât de eficient este mediul sistemului și cat de
scump este de a menține?
● Evaluarea aplicatiei
• Care este calitatea sistemului de software de
aplicație?

Evaluarea procesului de afaceri
● Utilizați o abordare orientată spre punct de vedere și
de a căuta răspunsuri de la părțile interesate de
sistem
• Există un model de proces definit și este urmat?
• Face diferite părți ale organizației utiliza diferite procedee
pentru aceeași funcție?
• Cum a fost adaptat procesul?
• Care sunt relațiile cu alte procese de afaceri și sunt
acestea necesare?
• Este procesul sprijinit efectiv de aplicația software
moștenire?
● Exemplu - un sistem de comanda de călătorie poate
avea o valoare de afaceri scăzut din cauza utilizării
pe scară largă a comanda online.
Evaluarea de mediu 1

Evaluarea de mediu 2

Aplicarea Evaluari 1

Aplicarea Evaluari 2

Măsurarea sistemului
● Se poate colecta date cantitative pentru a
face o evaluare a calității sistemului de
aplicare
• Numărul de cereri de schimbare de sistem;
• Numărul de interfețe de utilizator utilizate de
sistem;
• Volumul de date utilizate de sistem.

Puncte cheie
● Dezvoltarea de software și evoluția ar trebui
să fie un singur proces iterativ.
● Legile lui Lehman descrie o serie de
perspective în evoluția sistemului.
● Trei tipuri de întreținere sunt de fixare bug,
modificarea software pentru un mediu nou și
punere în aplicare a noilor cerințe.
● Pentru sistemele personalizate, costurile de
întreținere depășesc, de obicei, costurile de
dezvoltare.

Puncte cheie
● Procesul de evoluție este determinată de
solicitări de modificare din partea părților
interesate de sistem.
● Reinginerie software este preocupata de re-
structurarea și documentarea software de a
face mai ușor pentru a se schimba.
● Valoarea de afaceri a unui sistem de moștenire
și calitatea acestuia ar trebui să determine
strategia evoluție care este utilizat.

Verificarea și validarea

Obiective
 Introducerea în ceea ce înseamnă verificarea și
validarea software-ului și prezentarea diferențelor
dintre acestea
 Descrierea procesului de inspecție al programului și
rolul său în V & V (Verificare și Validare)
 Explicarea analizei statice ca tehnică de verificare
 Descrierea procesului de dezvoltare software
„Cleanroom”

Subiecte incluse
 Planificarea verificării și validării
 Inspecții software
 Analiză statică automată
 Procesul de dezvoltare software „Cleanroom”

Verificare vs validare
 Verificarea:
„Construim produsul în mod corect?”
 Software-ul ar trebui să se conformeze
specificațiilor sale.
 Validarea:
„Construim produsul adecvat?”
 Software-ul ar trebui să facă ceea ce
utilizatorul într-adevăr cere.

Procesul V & V
 Este un întreg proces de viață - V & V
trebuie aplicate în fiecare etapă a procesului
software.
 Are două obiective principale
• Descoperirea defectelor într-un sistem;
• Evaluarea măsurii in care sistemul este utilizabil
și util sau nu, într-o situație operațională.

Obiectivele V & V
 Verificarea și validarea trebuie să
stabilească acea încredere că software-ul
este adecvat scopului.
 Acest lucru NU înseamnă că este complet
lipsit de defecte.
 Mai degrabă, trebuie să fie suficient de bun
pentru utilizarea prevăzută și tipul utilizării va
determina gradul de încredere de care este
nevoie.

Siguranța V & V
 Depinde de scopul sistemului, așteptările
utilizatorului și mediul de marketing
• Funcția software
• Nivelul încrederii depinde de cât de critic este
software-ul pentru o organizație.
• Așteptările utilizatorului
• Utilizatorii pot avea așteptări scăzute de la anumite
tipuri de software.
• Marketing environment
• Lansarea prematură a unui produs pe piață poate fi
mai importantă decât găsirea defectelor în program.

Verificarea statică și dinamică
 Inspecția software. Preocupată cu analiza

reprezentării statice a sistemului, cu scopul de a
descoperi probleme (verificare statică)
• Poate fi suplimentată de documente orientate pe
instrumente și analiză de cod
 Testare software. Preocupată cu exercitarea și
observarea comportamentului produsului (verificare
dinamică)
• Sistemul este executat cu testare de date și
comportamentul său operațional este observat

Verificarea statică și dinamică

Testarea programului
 Poate dezvălui prezența erorilor, NU absența
lor.
 Singura tehnică de validare pentru cerințele
non-funcționale ca, pe măsură ce software-ul
se execută, să i se poată urmări
comportamentul.
 Ar trebui utilizată în combinație cu verificarea
statică pentru a oferi o acoperire completă a
V & V.

Tipuri de testare
 Testarea defectului
• Teste concepute pentru a descoperi defectele sistemului.
• Un test de detectare a defectelor, ce are un rezultat
favorabil, indică prezența unor defecte în sistem.
• Prezentată în Capitolul 23
 Testarea validării
• Destinată pentru a arăta că software-ul își îndeplinește
cerințele.
• Un test reușit este unul care arată că cerințele au fost
implementate în mod corespunzător.

Testarea și depanarea
 Testarea defectelor și depanarea acestora sunt
procese distincte.
 Verificarea și validarea se referă la stabilirea
existenței unor defecte într-un program.
 Depanarea este preocupată de localizarea și
repararea acestor erori.
 Depanarea implică formularea unei ipoteze despre
comportamentul programului, apoi testarea acestor
ipoteze pentru a găsi eroarea de sistem.

Procesul de depanare

Planificarea verificării și validării
 Este necesară o planificare atentă pentru a
obține rezultate optime din procesele de
testare și inspecție.
 Planificarea trebuie începută încă de la
debutul procesului de dezvoltare.
 Planul ar trebui să identifice echilibrul între
verificarea statică și testare.
 Prin planificare se urmăreşte definirea unor
standarde pentru procesul de testare şi nu
descrierea testărilor produsului.

Modelul „V” de dezvoltare

Structura unui plan de testare software
 Procesul de testare.
 Urmărirea cerinţelor.
 Elementele testate.
 Planificarea testării.
 Procedurile de înregistrare ale testării.
 Cerinţele hardware şi software.
 Constrângeri.

Planul de testare software
Procesul de testare
O descriere a fazelor majore ale procesului de testare. Acestea ar putea fi cele descrise mai devreme
în acest capitol.
Urmărirea cerințelor
Utilizatorii sunt foarte interesați de îndeplinirea cerințelor sistemului, de aceea testarea trebuie
planificată – pentru ca toate cerințele să fie individual testate.
Elementele testate
Produsele procesului software care urmează a fi testate trebuie specificate.
Planificarea testării
Un program de testare generală și alocare de resurse pentru acest program. Acesta, în mod evident, e
legat de programul general de dezvoltare al proiectului.
Procedurile de înregistrare ale testării

Nu este suficientă doar simpla rulare a unor teste. Rezultatele testelor trebuie înregistrate sistematic.
Cerințele hardware și software

Această secțiune ar trebui să înființeze instrumentele software cerute și să estimeze utilizarea
hardware-ului.
Constrângeri
Constrângerile care afectează procesul de testare, ca lipsa de personal, ar trebui anticipate în această
secțiune.

Inspecția software
 Implică examinarea codului sursă de către oameni
în scopul descoperirii anomaliilor şi defectelor.
 Inspecţiile nu necesită rularea sistemului, deci pot fi
făcute înaintea implementării.
 Pot fi aplicate oricărei reprezentări a sistemului
(cerinţe, proiectare, date de configurare, date de test
etc.).
 S-a dovedit ca fiind o tehnică eficientă de detectare
a erorilor în programe.

Avantajele inspecţiei
 Mai multe defecte pot fi descoperite la o
singură inspecţie. La testare, un defect poate
masca un alt defect, aşa că sunt necesare
mai multe rulări.
 Atitudinea familiară față de un domeniu şi
cunoştinţele de programare ajută recenzorii
să recunoască uşor anumite tipuri de erori
care apar în mod frecvent.

Inspecţia şi testarea
 Inspecţia şi testarea sunt tehnici de verificare
complementare, nu opuse.
 Amândouă ar trebui utilizate pe parcursul procesului de
verificare şi validare.
 Inspecţiile pot verifica conformitatea cu specificaţiile
dar nu şi cu cerinţele reale ale utilizatorilor.
 Inspecţiile nu pot verifica caracteristici non-funcţionale
precum performanţa, uşurinţa la utilizare, etc.

Inspecțiile programului
 Abordare formală a recenziei documentului.
 Destinate în mod explicit pentru detectarea
defectului (nu corectarea lui).
 Defecte pot fi erori logice, anomalii în cod,
care ar putea indica o stare eronată (de
exemplu, o variabilă neinițializată) sau o
neconformitate cu standardele.

Precondițiile inspecției
 O specificație precisă trebuie să fie disponibilă.
 Membrii echipei trebuie să fie familiarizați cu
standardele organizației.
 Cod corect din punct de vedere sintactic sau alte
reprezentări corecte ale sistemului trebuie să fie
disponibile.
 O listă de verificare a erorilor ar trebui să fie pregătită.
 Managementul trebuie să accepte că inspecția va
crește costurile încă de la începutul procesului.
 Managementul nu ar trebui să folosească inspecții
pentru evaluarea personalului, și anume să descopere
cine face greșeli.
Procesul de inspecție

Procedura de inspecţie
 Prezentarea generală a sistemului echipei de
inspecţie.
 Codul şi documentaţia sunt distribuite încă
de la început echipei.
 Inspecţia are loc şi erorile descoperite sunt
notate.
 Se fac modificările care vor repara erorile
descoperite.
 Repetarea inspecţiei poate fi sau nu
necesară.

Rolul membrilor echipei de inspecţie
Autorul Programatorul sau proiectantul responsabil cu

producerea codului sau a documentului. Va repara
defectele descoperite la inspecţie.
Inspectorul Găseşte erorile, omisiunile şi inconsistenţele în

program sau document. Poate identifica şi alte
probleme în afara domeniului de aplicare al inspecției.
Cititorul Prezentă codul sau documentul la şedinţa de

inspecţie.
Secretarul Înregistreză rezultatele şedinţelor de inspecţie.
Moderatorul Gestionează procesul şi facilitează inspecţiile.

Raportează moderatorului şef rezultatele procesului.
Moderatorul şef Responsabil cu îmbunătăţirea procesului inspecției,

actualizarea listei de verificare, dezvoltarea
standardelor etc.

Lista de inspecţie
 Pentru conducerea inspecţiei se va utiliza o listă cu
erori des întâlnite.
 Lista de erori este dependentă de limbajul de
programare şi reflectă erorile caracteristice, ce sunt
susceptibile de a apărea în limbaj.
 În general, cu cât verificările de tip sunt mai slab
implementate, cu atât lista va fi mai lungă.
 Exemple: iniţializări, nominalizarea constantelor,
cicluri infinite, limitele tablourilor, etc.

Verificările inspecției - 1
Defecte de date Sunt toate variabilele programului inițializate înainte ca valorile lor să
fie utilizate?
Au fost declarate toate constantele?
Ar trebui ca limita superioară a tablourilor să fie egală cu dimensiunea
tabloului sau dimensiune -1 ?
Daca se folosește tipul string, este delimitatorul explicit atribuit?
Există posibilitatea de buffer overflow?
Controlul defectelor Pentru fiecare instrucțiune condițională, este pusă condiția corect?
Există certitudinea terminării buclelor?
Sunt instrucțiunile corect puse în paranteze?
În cazul instrucțiunilor alternative multiple (case), sunt toate cazurile
justificate?
Dacă un break este necesar după fiecare case, a fost acesta inclus?
Defecte de intrare/ieșire Sunt utilizate toate variabilele de intrare?

Le sunt atribuite o valoare tuturor variabilelor de ieșire, înainte ca
acestea să fie transmise?
Pot intrările neașteptate să cauzeze corupție?

Verificările inspecției - 2
Defecte de interfață Au toate funcțiile și metodele numărul corect de

parametri?
Se potrivesc tipurile parametrilor formali și efectivi?
Sunt parametrii puși în ordinea dorită?
Dacă componentele accesează memoria partajată, au
ele același model al structurii memoriei partajate?
Defecte de management de Dacă o structură legată este modificată, au fost

stocare reatribuite corect toate legăturile?
Dacă este folosită stocarea dinamică, a fost spațiul
alocat corect?
Dacă spațiul a fost dezalocat în mod explicit, mai este
acesta necesar?
Defecte de management al Au fost luate în considerare toate condițiile de

excepțiilor erori posibile?

Ritmul inspecţiei
 500 de linii/oră în timpul privirii de ansamblu.
 125 linii de cod sursă/oră în timpul pregătirii
individuale.
 90-125 linii de cod/oră la inspectare.
 Inspecţia este un proces costisitor.
 Inspecţia a 500 de linii de cod necesită
aproximativ 40 ore de muncă – în jur de
£2800.

Automatizarea analizei statice
 Analizoarele statice sunt ustensile software
care prelucrează surse text.
 Ele parcurg codul programului şi încearcă să
descopere şi să aducă în atenția echipei de
verificare și validare, aceste potenţiale erori
 Sunt foarte eficiente în ajutorul inspecţiei –
totuşi sunt doar un supliment şi nu pot înlocui
inspecţia.

Teste la analiza statică
Defecte de date Variabile utilizate înainte de iniţializare
Variabile declarate, dar neutilizate
Variabile atribuite de două ori, dar cu prima
valoare nefolosită
Posibile depăşiri de margini la indicii de tablouri
Variabile nedeclarate
Defecte de control Cod la care execuţia nu poate ajunge

Cicluri infinite
Defecte de intrare/ieșire Variabile cu acceași valoare afișată de două ori,

fără nici o atribuire
Defecte de interfață Tipul greșit al parametrilor

Numărul greșit al parametrilor
Neutilizarea rezultatelor funcțiilor
Lipsa apelurilor funcțiilor și procedurilor
Defecte de management Pointeri neiniţializaţi

de stocare

Etapele analizei statice
 Analiza fluxului de control. Verifică ciclurile cu intrări
sau ieşiri multiple, caută cod la care execuţia nu
poate ajunge etc.
 Analiza utilizării datelor. Detectează variabilele
neiniţializate, variabilele declarate de două ori dar
fără a se fi intervenit la atribuire, variabilele
declarate dar neutilizate etc.
 Analiza interfeţelor. Verifică consistenţa declarării şi
apelului de funcţii şi proceduri, cât și utilizarea lor.

Etapele analizei statice
 Analiza fluxului informaţional. Identifică
dependenţele variabilelor de ieşire. Nu
detectează anomaliile în sine, dar scoate în
evidenţă informaţii pentru inspecţia de cod.
 Analiza căilor. Identifică căile de rulare prin
program şi delimitează instrucţiunile
executate pe acea cale. Din nou, este utilă în
procesul de inspecţie.
 Ambele etape generează o mare cantitate de
informaţii. Deci, trebuie utilizate cu grijă.
Analiza statică LINT
138 % ore m lint _ex.c
#include < sd
t io.h>
pr intar ray (Anar ray)
in t n Aarray ;
{ p r int f(“% ”d,Anarray) ; }
main ()
{
in t nAarray [5]; int ;i char c;
pr intar ra y(Anarray, ,i c) ;
pr intar ra y(Anarray) ;
}
139 %cc lin _t ex .c

140 %lint lint _ex.c
lint_ex.c(10): warning: c m ay be used e bfo er est

lint_ex.c(10): warning: i may be u se dbefore e st
pr intar ray: var ia ble # o fargs. int_ex
l .c(4) :: lint_ex.c 1 ( 0)
pr intar ray, arg. 1 used in cons si tently nt_ex.
li c(4) : : lint_ex. c(10)
pr intar ray, arg. 1 used in cons si tently nt_ex.
li c(4) : : lint_ex. c(11)
pr int f r eturns value which is a wl ays ignored

Utilizarea analizei statice
 Foarte valoroasă când limbajul utilizat este
mai slab tipizat (de exemplu, C) şi ca atare
multe erori trec nedetectate de compilator.
 Mai puţin eficientă pentru limbaje precum
Java care au o testare puternică a tipurilor şi
ca atare detectează multe erori în timpul
compilării.

Verificarea și metodele formale
 Metodele formale pot fi folosite când o
specificație matematică a unui sistem e
produsă.
 Ele sunt tehnici definitive de verificare
statică.
 Ele implică o analiză matematică detaliată a
specificației și pot dezvolta argumente
formale pe care un program le confirmă
specificațiilor sale matematice.

Argumente pentru metodele formale
 Producerea unei specificații matematice
necesită o analiză detaliată a cerințelor, deci
acest lucru poate duce la descoperirea unor
erori.
 Ele pot detecta erorile de implementare
înaintea testării, când programul este
analizat alături de specificații.

Argumente împotriva metodelor formale
 Necesită notații speciale ce nu pot fi înțelese

de experții în domeniu.
 Dezvoltarea unei specificații este foarte
costisitoare, dar mai costisitor este faptul de
a arăta ca programul întrunește specificațiile.
 Este posibil să se ajungă la același nivel de
încredere într-un program, cu un cost mult
mai avantajos folosind alte tehnici de
verificare și validare.

Dezvoltarea de „Cleanroom” software
 Numele derivă din procesul „Cleanroom”, prezent în
fabricarea semiconductorilor. Adică, se dorește
evitarea defectelor, mai degrabă decât eliminarea
acestora.
 Abordarea Cleanroom pentru dezvoltarea software-
ului se bazează pe:
• Dezvoltarea incrementală;
• Specificarea formală;
• Verificarea statică folosind argumente de corectitudine;
• Testarea statistică pentru a determina fiabilitatea
programului.

Procesul „Cleanroom”

Caracteristicile procesului „Cleanroom”
 Specificarea formală folosește un model de
tranziție între stări.
 Proces de dezvoltare incremental acolo
unde prioritățile utilizatorului cresc.
 Programare structurată – controlul limitat și
construcțiile de abstractizare sunt folosite în
program.
 Verificarea statică utilizează inspecții
riguroase.

Specificații formale și inspecții
 Modelul bazat pe condiție este o specificație
de sistem, iar procesul său de inspecție
verifică programul împotriva acestei model.
 Abordarea programării este definită astfel
încât corespondența dintre model și sistem
este clară.
 Argumentele matematice (nu dovezile) sunt
folosite pentru a spori încrederea în procesul
de inspecție.

Echipa procesului „Cleanroom”
 Echipa de specificații. Este responsabilă pentru
dezvoltarea și menținerea specificațiilor de sistem.
 Echipa de dezvoltare. Este responsabilă pentru
dezvoltarea și verificarea software-ului. Acesta nu se
execută pe parcursul dezvoltării.
 Echipa de certificare. Este responsabilă pentru
dezvoltarea unui set de teste statistice pentru a testa
software-ul după ce a fost dezvoltat. Modelele de
creștere a fiabilității determină când fiabilitatea este
acceptabilă.

Evaluarea procesului „Cleanroom”
 Rezultatele folosind procedeul Cleanroom au fost
foarte impresionante, cu puține defecte descoperite
în sistemele livrate.
 Evaluarea independentă arată că procesul nu este
mai scump decât alte abordări.
 Au fost mai puține erori decât într-un proces de
dezvoltare „tradițional”.
 Cu toate acestea, procesul nu este utilizat pe scară
largă. Nu este clar modul în care această abordare
poate fi transferată într-un mediu cu ingineri
software mai puțin calificați sau mai puțin motivați.

Concluzii
 Verificarea şi validarea nu sunt unul şi
acelaşi lucru. Verificarea arată conformitatea
cu o specificaţie pe când validarea arată
acoperirea nevoilor clienţilor.
 Este nevoie de un plan de testare pentru a
ghida procesul de testare.
 Tehnicile de verificare statică implică
examinarea şi analiza codului programului
pentru detectarea erorilor.

Concluzii
 Inspecțiile programului sunt foarte eficiente în
detectarea erorilor.
 Programul aflat în inspecție este verificat de o
echipă restrânsă pentru a localiza defectele
software.
 Instrumentele analizei statice pot descoperi anomalii
ale programului ce pot semnala defecte în cod.
 Procesul de dezvoltare „Cleanroom” depinde de
dezvoltarea incrementală, verificarea statică și
testarea statistică.

Testarea Software-ului

Obiectivele cursului
 De a intelege diferențele dintre conceptele
de verificare şi validare software
 De a descrie principiile testării sistem şi a
testării componentelor
 De a descrie strategii pentru generarea
testelor de sistem
 De a înţelege caracteristicile esenţiale ale
uneltelor folosite pentru automatizarea
testelor

Cuprins
 Testarea sistemului
 Testarea componentelor
 Proiectarea cazurilor de testare
 Automatizarea testelor

Procesul de testare
 Testarea componentelor
• Testarea componentelor individuale de program;
• De obicei este responsabilitatea dezvoltatorilor de
componente (cu unele excepţii pentru sistemele critice);
• Testele sunt derivate din experienţa dezvoltatorului.
 Testarea sistemului
• Testarea unui grup de componente integrate pentru a
crea un sistem sau sub-sistem;
• Este responsabilitate unei echipe de testare
independente;
• Testele sunt bazate pe specificaţiile sistemului.

Testarea defectelor
 Scopul testării defectelor este de a
descoperi defecte în programe
 Un test are succes atunci când determină
programul să aibă un comportament
anormal
 Testele arată prezenţa nu absenţa
defectelor

Scopurile procesului de testare
 Testarea de validare
• De a demonstra dezvoltatorului şi clientului
că sistemul software îndeplineşte cerinţele;
• Un test are succes dacă arată că sistemul se
comportă aşa cum s-a cerut.
 Testarea de defecte
• De a descoperi defecte în sistemul software
unde comportamentul este incorect sau ne-
conform cu specificaţiile;
• Un test are succes dacă provoacă sistemul
să se comporte incorect şi astfel expune un
defect în sistem.

Procesul de testare software

Politici de testare
 Doar testarea completă poate arăta că un program
nu are defecte, dar testarea completă este
imposibilă
 Politicile de testare definesc abordarea folosită în
selectarea testelor de sistem:
• Toate funcţiile accesate din meniuri trebuie
testate;
• Combinaţii ale funcţiilor accesate prin acelaşi
meniu trebuie testate;
• Acolo unde sunt introduse date de către
utilizator (tastare), toate funcţiile trebuie
testate cu intrări corecte şi incorecte.
Testarea Sistemului
 Implică integrarea componentelor pentru a crea
un sistem sau sub-sistem.
 Poate implica testarea unui increment ce va fi
livrat la client.
 Are două faze:
• Testarea de integrare – echipa de testare are
acces la codul sursă al sistemului. Sistem
este testat pe măsură ce componentele sunt
integrate.
• Testarea de versiune (release) – echipa de
testare testează sistemul complet ce va fi
livrat, privindu-l ca o cutie neagră.

Testarea de integrare
 Implică construirea sistemului din componente
şi testarea problemelor ce pot să apară din
interacţiunile componentelor.
 Integrare Top-down (de sus în jos)
• Dezvoltarea unui schelet al sistemului şi
popularea lui cu componente.
 Integrare Bottom-up (de jos în sus)
• Integrarea componentelor de infrastructură
şi adăugarea componentelor funcţionale.
 Pentru a simplica localizarea erorilor, sistemele
trebuie integrate incremental.

Testarea de integrare incrementală

Abordari de testare
 Validarea arhitecturii
• Testarea cu integrarea top-down este utila la descoperirea
erorilor în arhitectura sistemului
 Demonstrarea sistemului
• Testarea cu integrarea top-down permite demonstrarea
limitata a func†ionarii sistemului înca din fazele de început
 Testarea implementarii
• Deseori este mai simpla la testarea cu integrare bottom-up
 Observarea testelor
• Apar probleme în cazul ambelor tehnici. În general este
nevoie de cod extern pentru a observa testele

Testarea de versiune (release)
 Este procesul de testare a unei versiuni de
sistem care va fi distribuită la clienţi.
 Scopul principal este să crească încrederea
plătitorilor că sistemul îndeplineşte cerinţele.
 Testarea de versiune este de obicei o testare tip
“cutie neagră” sau o testare funcţională
• Este bazată doar pe specificaţiile de sistem;
• Testorii nu au cunoştinţe de implementare a
sistemului.

Testare tip “cutie neagră”

Propuneri pentru testare
 Propunerile de testare sunt idei pentru echipa de
testare care sa o ajute să aleagă teste care vor
descoperi defecte în sistem
• Alege date de intrare care forţează sistemul să
genereze toate mesajele de eroare;
• Alege date de intrare care provoacă depăşirea
unor buffer-e;
• Repetă aceleaşi date date de intrare sau
aceleaşi serii de câteva ori;
• Forţează generarea datelor de ieşire invalide;
• Forţează ca rezultatele unor calcule să fie prea
mari sau prea mici.

Scenariu de testare
 Un student din Scoţia studiază istoria Americii şi i s-a cerut să scrie un
eseu despre ‘Mentalitatea în America de Vest între anii 1840 şi 1880’.
Pentru acest lucru, trebuie să găsească surse din mai multe biblioteci.
Se autentifică în sistemul LIBSYS şi foloseşte căutarea pentru a
descoperi dacă poate accesa documente originale din acea perioadă.
Descoperă surse în diferite biblioteci din SUA şi aduce copii ale unora.
Totuşi, pentru un document, are nevoie de confirmare de la
universitatea în care studiază că este cu adevărat student şi că nu va
folosi articolul pentru scopuri comerciale. Studentul foloseşte sistemul
LIBSYS pentru a solicita o astfel de permisiune. Dacă i se acordă
permisiunea, documentul va fi trimis serverului oficial din biblioteca
universităţii şi va fi tipărit. Studentul primeşte un mesaj prin care i se
comunică faptul că va primi un e-mail când documentul tipărit poate fi
ridicat.

Teste de sistem
 Testarea mecanismului de login folosind date corecte şi
incorecte pentru a verifica dacă utilizatorii reali sunt acceptaţi
şi dacă utilizatorii falşi sunt respinşi.
 Testarea serviciului de căutare folosind diferite texte de căutare
după documente cunoscute pentru a verifica dacă sistemul de
căutare găseşte documentele dorite.
 Testarea serviciului de prezentare pentru a verifica faptul că
informaţiile şi documentele sunt afişate corespunzător.
 Testarea mecanismului de solicitare a permisiunii de download.
 Testarea răspunsului prin e-mail care indică faptul că un
document este disponibil.

Cazuri de utilizare
 Cazurile de utilizare pot fi baza pentru a
deriva testele pentru un sistem. Ele ajută
la identificare operaţiilor ce trebuie
testate şi ajută la realizarea cazurilor de
testare necesare.
 Din diagrama de secvenţă următoare, pot

fi identificate intrările şi ieşirile necesare
pentru teste.

Colectarea datelor meteo

Testele de performanţă
 O parte din testarea de versiune poate
implica testarea unor proprietăţi de
sistem, cum ar fi performanţa şi
fiabilitatea.
 Testele de performanţă de obicei implică

planificarea unor serii de teste unde
încărcarea sistemului este crescută până
când performanţele sistemului devin
inacceptabile.
Testarea la stres
 Solicită sistemul dincolo de încărcarea maximă
proiectată. “Stresarea” sistemului de obicei
provoacă defectele să apară.
 “Stresarea” sistemului testează comportamentul
la eşec. Sistemele nu trebuie să eşueze
catastrofic. Testarea la stres verifică pierderi
inacceptabile de servicii sau date.
 Testarea la stres este foarte relevantă pentru
sisteme distribuite care pot prezenta o
degradarea drastică a performanţei la încărcarea
reţelei.

Testarea componentelor
 Testarea componentelor (unit testing) reprezintă
procesul de testare a componentelor individuale
izolate.
 Este un proces de testare a defectelor.
 Componentele pot fi:
• Funcţii individuale sau metode dintr-un
obiect;
• Clase de obiecte cu câteva atribute şi
metode;
• Componente compuse cu o interfaţă definită
pentru accesarea funcţionalităţii.
Testarea claselor de obiecte
 Teste cu acoperire (covarage) completă a
unei clase implică
• Testarea tuturor operaţiilor asociate cu un
obiect;
• Setarea şi interogarea tuturor atributelor de
obiect;
• Testarea obiectului în toate stările posibile.
 Moştenirea face mai dificilă proiectarea
testelor pentru că informaţia ce trebuie
testată nu este localizată.

Interfaţa obiectului Staţie meteo
WeatherStation
identifier
repor tWeather ()
cali brate (i nstruments)
test ()
star tup (instruments)

Testarea staţiei meteo
 Trebuie să definim cazuri de testare
pentru metodele reportWeather, calibrate,
test, startup şi shutdown.
 Folosind un model de stare, se identifică
secvenţele de tranziţii de stare ce trebuie
testate şi evenimentele ce produc acele
tranziţii
 De exemplu:
• Waiting -> Calibrating -> Testing ->
Transmitting -> Waiting

Testarea Interfețelor
 Obiectivele sunt de a detecta erori datorate
interfețelor sau presupunerilor greșite despre
interfețe
 Acestea sunt importante mai ales pentru
dezvoltarea orientata pe obiecte deoarece
obiectele sunt definite de interfețele lor

Tipuri de Interfețe
 Interfețe de parametrii
• Datele sunt trimise de la o procedura la alta
 Interfețe cu memorie comuna
• Un bloc de memorie este folosit in comun de proceduri
sau functii
 Interfețe procedurale
• Sub-sistemul înglobează un set de proceduri pentru a fi
apelat de alte sub-sisteme
 Interfețe cu schimb de mesaje
• Sub-sistemele solicită servicii de la alte sub-sisteme

Erori ale interfețelor
 Utilizare gresita a interfeței
• Apare când o componenta cheamă altă componentă și
comite o eroare în utilizarea interfeței acesteia, de ex.
trimite parametrii într-o ordine gresită
 Neînțelegerea interfeței
• O componetă înglobează niște presupuneri incorecte
despre comportamentul componentei chemate
 Erori de sincronizare
• Componetele care interacționeaza operează la viteze
diferite si ca atare informația accesată poate fi expirată

Sfaturi la Testarea Interfetelor
 Testele vor fi proiectate astfel încât parametrii de
apel ai procedurilor sa fie alesi la marginea
intervalelor lor
 Parametrii pointer vor fi testati cu valori NULL
 Testele vor fi astfel proiectate ca sa forteze
componenta sa dea gres
 Se vor utiliza teste de stres în mecanismul de
schimb de mesaje
 La sistemele cu memorie comuna se va varia
ordinea în care componentele sunt activate

Proiectarea cazurilor de testare
 Scopul proiectării testelor este de a

crea o mulţime de teste care sunt
eficiente în testarea defectelor.
 Abordări de proiectare a testelor:
• Testare bazată pe cerinţe;
• Testare partiţionată;
• Testare structurală.

Testare bazată pe cerinţe
 Un principiu de bază în ingineria
cerinţelor este faptul că cerinţele trebuie
să poată fi testate.
 Testarea bazată pe cerinţe este o tehnică

de testare de validare în care se are în
vedere fiecare cerinţă şi se construieşte
un set de teste pentru acea cerinţă.

Cerinţe LIBSYS
• Utilizatorul trebuie să poată căuta în toate
bazele de date sau într-un subset din acestea.
• Sistemul trebuie să ofere instrumente de

vizualizare potrivite pentru ca utilizatorul să
citească documentele.
• Fiecare comandă trebuie să aibă alocat un

identificator unic (ORDER_ID).

Teste LIBSYS
 Iniţiază căutare pentru elemente care se
ştie că există sau că nu există, incluzând
o singură bază de date în căutare.

două baze de date în căutare.

mai mult de două baze de date în căutare.

Testare partiţionată
 De obicei datele de intrare şi datele de
ieşire se grupează în diferite categorii de
date.
 Fiecare din aceste categorii este o partiţie

de echivalenţă sau un domeniu în care
programul are un comportament
asemănător.
 Cazurile de testare trebuie alese din

fiecare partiţie.

Partiţionare a datelor
I nval i d i n pu ts Val i d i n pu ts
Sy s tem
O utp uts

Partiţionare a datelor

Testare structurală
 Uneori este numită testare tip “cutie
albă”.
 Construirea cazurilor de testare în funcţie

de structura programului. Sunt necesare
cunoştiinţe interne de program pentru a
identifica teste.
 Obiectivul este să fie testate toate

instrucţiunile programului (nu toate
combinaţiile de ramuri).

Structura unui sistem de testare

 Task managerul – managerizeaza rularea programelor de test. Acest
manager tine evidenta datelor de intrare, asteapta rezultatele si
programeaza facilitatile testate.
 Generatorul de date de test – genereaza date de test pentru
programul ce urmeaza a fi testat. Aceasta poate fi indeplinita ptin
selectarea unor date dintr-o baza de date sau prin utilizarea unor date
predefinite pentru generare de date aleatoare
 Oracol – genereaza predictii ale rezultatelor de iesire. Oracolul poate
fi reprezentat si de niste prototipuri de program. Trebuie rulat atat
Oracolul cat si programul de testat in paralel .

 Comparatorul de fișiere – compară rezultatele programelor de test cu
rezultatele precedente obținute.
 Generator de rapoarte – ofera un raport legat de generarea datelor si
de facilitațile testelor.
 Analizor dinamic – adaugă cod la program pentru a număra de câte
ori fiecare instrucțiune a fost executată. După testare, un profil de
execuție este generat arătând cat de des sunt folosite anumite
instrucțiuni.
 Simulator – diferite tipuri de simulatoare pot fi folosite aici.
Simulatoarele de interfața sunt scripturi ce simuleaza multiple posibile
utilizări ale unei persoane. Pot fi folosite inclusiv simulatoare pentru
gestionarea tranzacțiilor I/O.

Algoritmul de căutare binară
1
bottom > top while bottom <= top

5
elemArray [mid] != key

7 11
elemArray
elemArray [mid] > key elemArray [mid] < key
[mid] = key
8
12 13
14 10

Algoritmul de căutare binară
 Există totuși niște condiții ce trebuie puse în acest caz:
 vectorul trebuie să fie ordonat
 valoarea de pe prima pozitie trebuie sa fie diferita de
valoarea de pe ultima pozitie.

Automatizarea testării
 Testarea este o fază de proces costisitoare.
 Mediile de testare oferă o gamă de instrumente
pentru a reduce timpul necesar şi costurile totale
de testare.
 Sisteme cum ar fi JUnit suportă execuţia

automată a testelor.
 Mediile de testare sunt deseori greu de integrat

cu medii de proiectare şi analiză.

Concluzii
 Testarea poate arăta prezenta erorilor într-un
sistem; nu poate demonstra că nu au mai rămas
erori.
 Dezvoltatorii de componente sunt responsabili
de testarea componentelor; testarea sistemului
este responsabilitatea unei echipe separate.
 Testarea de integrare este testarea
incrementelor de sistem; testarea de versiune
implică testarea sistemului ce va fi livrat la client.
 Folosiţi experienţe pentru crearea cazurilor de
testare în testarea defectelor.

Concluzii
 Testarea partiţionată este o metodă de a
descoperi cazurile de testare – toate cazurile
dintr-o partiţie se comportă la fel.
 Testarea structurală se bazează pe analizarea

programului şi derivarea testelor din această
analiză.
 Automatizarea testării reduce costurile testării

prin folosirea unor unelete software în procesul
de testare.

Validarea
Sistemelor
Critice
Obiective
• Explicarea modului în care fiabilitatea
sistemului poate fi măsurată și cum modelele
de creștere a fiabilității pot fi utilizate pentru
predicția fiabilității.
• Pentru a descrie argumentele de siguranță și
modul în care acestea sunt folosite
• Pentru a discuta problemele de asigurare a
siguranței
Subiecte acoperite
• Validarea fiabilitatii
• Asigurarea sigurantei
• Evaluarea securitatii
• Cazuri de siguranță și fiabilitate
Validarea sistemelor critice
• Verificarea și validarea costurilor pentru sistemele critice
implică procese suplimentare de validare și analize decât
pentru sistemele non- critice :
o Costurile și consecințele eșecului sunt mari, deci este
mai ieftin găseşti și să elimini defectele decât să
plătească pentru eșecul sistemului;
o Este posibil sa aveti de facut un caz formal pentru
clienti sau pentru un regulator pentru care sistemul
îndeplinește cerințele sale fiabile. Acest caz de
fiabilitate poate necesita activități specifice de
verificare si validare pentru a fi efectuate.
Costurile de validare
• Din cauza activităților suplimentare implicate,
costurile de validare pentru sistemele critice sunt de
obicei mult mai mari decât pentru sisteme non-
critice .
• În mod normal, verificarea si validarea costă mai
mult de 50% din costurile totale de dezvoltare a
sistemului .
Fiabilitatea validării
• Fiabilitatea validării implică verificarea programului
dacă a atins sau nu nivelul necesar de fiabilitate.
• Acest lucru nu poate fi în mod normal inclus ca
parte a unui proces normal de testare a defectului,
deoarece datele pentru testarea defectelor sunt (
de obicei ) atipice de datele reale de utilizare.
• Prin urmare, măsurarea fiabilităţii necesită un set de
date special concepute care reproduce modelul
de intrări pentru a fi prelucrate de sistem.
Procesul de măsurare a
fiabilităţii
identifică Pregătirea
Testarea Calcularea
profilul testului pentru
sistemului fiabilităţii
operațional setul de date
Activităţi de validare a fiabilităţii
• Stabilirea profilului operațional pentru sistem.
• Construirea datelor de test care reflectă
profilul de funcționare.
• Testarea sistemului și observarea numărului
de eșecuri.
• Calculați fiabilitatea după statistica unui
număr semnificativ de eșecuri care au fost
observate.
Testarea statistică
• Testare Software pentru fiabilitate, mai degraba
decat detectarea defectelor.
• Măsurarea numărului de erori permite
fiabilitatea software-ului să fie prezis. Rețineți că
, din motive statistice, mai multe erori care sunt
permise în caietul de sarcini de fiabilitate
trebuie să fie induse.
• Un nivel acceptabil de fiabilitate ar trebui să fie
specificat, iar software-ul testat și modificat
până când se ajunge la nivel de fiabilitate
necesar.
Problemele de măsurare a fiabilităţii
• Profilul operaţional
o Profilul operaţional nu poate fi o reflectare exactă
de utilizare reala a sistemului.
• Costurile ridicate a datelor de testare
o Costurile pot fi foarte mari în cazul în
care datele de testare pentru sistem nu pot fi
generate automat.
• Statistici inexacte
o Aveți nevoie de un număr semnificativ statistic de
eșecuri pentru a calcula fiabilitatea, dar sistemele
extrem de fiabile rareori vor eșua.
Profiluri operaţionale
• Un profil de exploatare este un set de date de
testare a căror frecvență se potrivește cu frecvența
actuală a acestor intrări de la modul „normal” de
utilizare a sistemului. O potrivire strânsă este
necesară altfel fiabilitatea măsurată nu va fi
reflectată în utlizarea actuală a sistemului.
• Acestea pot fi generate din datele reale colectate
de la un sistem existent sau depinde de ipotezele
facute despre modul de utilizare a sistemului.
Un profil operaţional
Number of
inputs
...
Input classes
Generaţia profilului
operaţional
• Ar trebui generate automat ori de câte ori este
posibil.
• Generaţia profilului operaţional este dificilă pentru
sistemele interactive.
• Pot fi foarte uşoare pentru intrări „normale” dar is
dificile de spus pentru intrările „puţin probabile” şi să
se creeze date de testare pentru ele.
Predicţia de fiabilitate
• Un model de creştere este un model matematic de
schimbare a sistemului de fiabilitate care este testat
iar erorile sunt eliminate.
• Este folosit ca mijloc de predicţie a fiabilităţii de
extrapolare a datelor actuale
o simplifică testul de planificare şi negocierea cu
clienţii.
o Se poate anticipa atunci când testarea va fi
completă şi demonstrată clienţilor că va fi sau nu
atinsă creşterea fiabilităţii.
• Predicţia depinde de utilizarea testării statistice
pentru a măsura fiabilitatea unei versiuni a
sistemului.
Creşterea de fiabilitate
pas cu pas
Reliability
(ROCOF)
t1 t2 t3 t4 t5
Time
Urmărirea creşterii
fiabilităţii
• Modelul de creştere este simplu dar nu reflectă în
mod normal, realitatea.
• Fiabilitatea nu creşte neapărat cu schimbarea sa,
aceasta poate introduce noi defecte.
• Rata de creştere a fiabilităţii tinde să încetinească
cu timpul deoarece sunt descoperite frecvent noi
defecte care sunt ulterior scoase din program.
• Un model aleator de creştere poate fi, in cazul în
care modificările de fiabilitate sunt în continuă
schimbare, o reflectare mai precisă a modificărilor
reale de fiabilitate.
Creşterea aleatoare a
fiabilităţii
Note dif ferent r eliability
improvements
Reliability
(ROCOF) Fault r epair ad ds ne w fault
and decreases reliability
(increases ROC OF)
t1 t2 t3 t4 t5
Time
Creşterea modelului de
selecţie
• Au fost propuse mai multe modele de creştere a
fiabilităţii.
• Nu există nici un model de creştere de
aplicabilitate.
• Fiabilitatea trebuie sa fie măsurată şi datele
observate ar trebui să fie incluse pe mai multe
modele.
• Modelul cel mai adecvat poate fi apoi folosit
pentru predictia de fiabilitate.
Predicţia de fiabilitate
Reliability
= Measur ed r eliability
Fitted r eliability
model curv e
Requir ed
reliability
Estimated Time
time of reliability
achievement
Asigurare de securitate
• Asigurarea securităţii şi măsurarea fiabilităţii sunt
destul de diferite:
o În limitele de eroare de măsurare a fost atins un
nivel necesar de fiabilitate
o Cu toate acestea, măsurarea cantitativă de
securitate este imposibilă. Asigurarea securității
este în cauză cu stabilirea unui nivel de încredere
în sistem.
Siguranță de încredere
• Încrederea în securitatea unui sistem poate varia
de la mic la mare.
• Încrederea este dezvoltată prin:
o Experienţa trecutului cu compania care a
dezvoltat programul.
o Utilizarea proceselor de încredere şi procesele de
activităţi orientate spre securitate.
o Extinse verificări şi validări inclusiv ambele tehnici
de validare statice şi dinamice.
Comentarii de siguranţă
• Recenzie pentru corectarea functiei dorite.
• Recenzie pentru structura de întreţinut, uşor de
înţeles.
• Revizie pentru verificarea algoritmului si
proiectarea de structură de date împotriva
caietului de sarcini.
• Revizie pentru verificarea codului cu algoritmul şi
proiectarea de structură de date.
• Revizuirea caracerului adecvat al sistemului de
testare.
Recenzie de orientare
• Software-ul să fie făcut cât mai simplu posibil.
• Utilizarea tehnicilor simple pentru dezvoltarea de
software, evitarea erorilor de construcție ca
pointerii și recursivitatea.
• Utilizați informațiile ascunse să localizeze efectul de
orice corupere de date.
• Utilizarea adecvată a tehnicilor tolerante.
Argumente de siguranță
• Argumentele de siguranta sunt destinate sa arate
ca sistemul nu poate ajunge in stare nesigura.
• Acestea sunt mai slabe decat corectitudinea
argumentelor care trebuie sa arate ca specificatia
sa este conforma cu codul de sistem.
• Acestea sunt in general bazate pe dovezi de
contradictie
o Se presupune ca se poate ajunge in stare nesigura
o Arata ca acest lucru este contrazis de codul program
• Un model grafic al argumentului de siguranta poate

fi dezvoltat.
Construcția unui
argument de siguranță
• Stabilirea conditiior de iesire in conditii de siguranta
pentru o componenta sau un program
• Incepand de la sfarsitul codului, parcurgeti codul
pana identificati toate traseele care duc la iesirea
din cod.
• Consideram ca starea de iesire este falsa.
Cod de livrare insulină
cu rentDos
r e= co m puteI ns ulin ( );
// Sa ety f check - ad ust j u
c rentDos
r ei f necessary
// i f ates t m ent 1
if (prev ous i Dose == )0
{
if (curr entD se o > 16)
cu rentDos
r e= 16 ;
}
el se
if (curr entD se o > (prev ous
i Dose * 2) )
cur rentDose = revpoi u sDose * 2 ;
// i f ates t m ent 2
if (currentDose < inimum m os
D e)
cu rentDos
r e= 0 ;
el se if ( ur c rentDose > xDos m a e)
cu rentDos
r e= maxDose ;
admini sterInsul in (curren Dt se) o ;
Modelul argumentului de
siguranta
Overdose
administer ed
administerInsulin
currentDose > Pre-condition

maxDose for unsafe sta te
or
Contr adiction
currentDose >= mini mumDose and

currentDose <= maxDose
Contr adiction Contr adiction
currentDose =
currentDose = 0
maxDose
assign assign
if statement 2 currentDose =
currentDose = 0
not e xecuted maxDose
if statement 2 if statement 2
then branch else branch
executed executed
Programul traseelor
• Nici o ramura de instructiune if nu este executata
o Se poate executa daca CurrentDose este >=
minimumDose si <= maxDose.
• Apoi ramura de instructiune if este executata
o currentDose = 0
• Else ramura de instructiune if este executata
o currentDose = maxDose
• In toate cazurile, prima conditie contrazice conditia
ca doza administrata este mai mare decat
maxDose.
Procesul de asigurare
• Procesul de asigurare implica definrea unui proces
de incredere si de a asigura ca acest proces este
urmat in timpul dezvoltarii sistemului.
• Utilizarea unui proces in conditii de siguranta este
un mecanism care reduc sansele ca erorile sa fie
introduse in sistem.
• Accidentele sunt evenimente rare, astfel incat
testarea nu va gasi toate problemele.
• Cerintele de siguranta sunt uneori cerinte care nu
pot fi demonstrate prin testare.
Procesul de activitati
legate de siguranta
• Crearea unui pericol de logare si a sistemului de
monitorizare
• Numirea inginerilor de siguranta pentru proiect
• Utilizarea extensiva a sigurantei clientilor
• Crearea unui sistem de certificare de securitate
• Configurarea managementului in detaliu
Analiza riscurilor
• Analiza riscurilor implica identificarea riscurilor si
cauzele lor
• Ar trebui sa existe trasabilitatea clara impotriva
pericolelor identificate prin analiza lor pentru
actiunile intreprinse in timpul procesului pentru a se
asigura ca aceste riscuri sunt acoperite.
• Un jurnal de risc poate fi folosit pentru a urmari
pericolele pe parcursul procesului
Riscurile de intrare
Haza rd Log. Pag e 4 : P rinted 20 .02.20
System : Ins ulin Pum p Sys tem F ile: Ins ulin Pum p/Safe ty/Ha z ardLog
Sa fety Engineer: James Bro wn Log v er s ion: 1/3
Id entified Haz a rd Ins ulin ov erdo se de liver ed to pa tie nt
Id entified by Jane Williams
Cr iticality c la s s 1
Id entified r isk High
Fau lt tr ee identified YE S Date 24 .01.99 Loca tion Ha z ard L og,
Page 5
Fau lt tr ee creato r s Jane Williams a nd Bill S mith
Fau lt tr ee che c ked YE S Date 28 .01.99 Che c ke r James Bro wn
Sys te m sa fe ty des ign requ ir e m n

e ts
1. The sys tem s ha ll inc lud e se lf-tes ting s oftw are that will test the senso r
sys tem, th e c lock a nd th e ins ulin delivery sys tem.
2. The self-che c king s oftw are s hall be exe cuted on c ep er minute
3. In th e e vent of th e self-ch e cking software discov ering a fa ult in a ny of th e
sys tem co mpon ents , a n a udible w ar ning s ha ll be is s ue d a nd the pum p
displa y should indic ate th e n ame of the com pone nt where th e fault ha s
be e n discovere d .T h ed elivery of in su lin shou ld be s u sp end ed.
4. The sys tem s ha ll inc or pora te a n overrid e system tha t allo ws the s ystem
user to modify th e c om pute d do se of ins ulin th at is to be d elivere d by the
sys tem.
5. The am ount of ove rr id e s hould be limited to b e no gre ater tha n a p re -s et
va lue that is s et wh en th e system is configur ed by medica l s taff.
Timpul de verificare a
sigurantei
• In timpul executarii programului, controalele de
siguranta pot fi incorporate ca afirmatii, sa verifice
ca programul sa execute intr-o maniera sigura de
tip „plic”.
• Afirmatiile pot fi incluse ca fiind comentarii. Codul
poate fi generat automat pentru a verifica aceste
afirmatii.
Administrarea de insulina
static void ad ministe rInsulin () throws SafetyExceptio n {
int m axIncrements = InsulinP ump.m axD ose / 8 ;

int increme nts = InsulinP u m
p .currentDose / 8 ;
// assert currentDose <= In su linPum p.max Dose
if ( Insulin Pum p.currentDos e > InsulinPu mp.maxD ose)

throw ne w S a fetyExce ption (Pum p.dose High );
else
for (int i= 1; i< = inc re ments; i++)
{
genera te Signal () ;
if ( i > m axIncreme nts)
throw ne w S a fetyExce ption ( Pump.in co rrectIncrem ents );
} // for loop
} //administerInsulin
Evaluarea securitatii
• Evaluarea securitatii are ceva in comn cu
evaluarea sigurantei.
• Este destinata pentru a demonstra ca sistemul nu
poate intra intr-o stare (una nesigura) ci sa
demonstrese ca acesta poate face ceva.
• Cu toate acestea, exista diferente
o Problemele de securitate sunt accidentale;
problemele de securitate sunt deliberate.
o Problemele de securitate sunt mai generale –
multe sisteme sufera de aceleasi probleme;
Problemele de siguranta sunt mai ales legate de
domeniul de aplicare
Validarea de securitate
• Validare pe baza de experienta
o Sistemul este revizuit si analizat impotriva mai multor
tipuri de atacuri, care sunt cunoscute de echipa de
validare.
• Validare pe baza de instrument
o Diverse instrumente de securitate, cum ar fi
verificarea parolei sunt utilizate pentru a analiza
sistemul de operare.
• Echipele de validare
o Obiectivul unei echipe este sa sparga securitatea
sistemului pentru a simula atacuri asupra sistemului
• Verificarea formala
o Sistemul este verificat impotriva unor specificatii
oficiale de securitate.
Lista de verificare a
securitatii
1. Au toate fisierele create in aplicatie permisiunile de
acces necesare? Permisiunile de acces gresite pot
duce la aceste fisiere e catre utilizatori neautorizati.
2. Oare sistemul poate anula in mod automat sesiuni de
utilizator dupa o perioada de inactivitate? Sesiunile
care sunt lasate active pot permite accesul neautorizat
prin intermediul unui computer nesupravegheat.
3. In cazul in care sistemul este scris intr-un limbaj de
programare fara a fi verificat, exista situatii in care
memoria poate fi exploatata? Memoria poate permite
atacatorilor sa trimita codul de siruri de caractere la
sistem si apoi sa-l execute.
4. In cazul in care parolele sunt stabilite, sistemul verifica
daca parola este „puternica”. Parolele constau in
amestecul de litere, numere si semne de punctuatie si
nu sunt intrari de dictionar normale. Ele sunt mai dificil
de spart decat parolele simple.
Cazuri de siguranta si
fiabilitate
• Cazurile de siguranta si fiabilitate sunt structurate in
documentele prezentate detaliat de argumente si
dovezi care dovedesc ca a fost atins un nivel
necesar de siguranta sau fiabilitate.
• Acestea sunt cerute in mod normal de
reglementare inainte ca un sistem sa fie certificat
pentru utilizarea operationala.
Cazul sistemului de
siguranta
• Acum este o practica normala pentru un caz de
siguranta formala necesara pentru toate sistemele
critice bazate pe calculatoare ex. Sistemle de
semnalizare feroviara, controlul traficului aerian, etc.
• Un caz de siguranta este:
o Un set de documente cu dovezi care ofera un
argument convingator si valabil ca un sistem este in
mod adecvat in conditii de siguranta pentru o cerere
data intr-un anumit mediu.
• Argumentele, intr-un caz de siguranta si fiabilitate se pot
baza pe dovezi formale, proiectarea ratiunii, dovezile de
siguranta etc. Procesul de factori poate fi, de
asemenea, inclus.
Componentele unui caz
de siguranta
Componenta Descriere
Descrierea sistemului O prezentare generala a sistemului si o
descriere a componentelor sale critice.
Cerinte de siguranta Cerintele de siguranta din caietul de
sarcini ale sistemului
Analiza pericolelor si a riscurilor Documentele descriu pericolele si
riscurile care au fost identificate si
masurile luate pentru a reduce
riscurile.
Analiza de proiectare Un set de argumente structurate care
justifica de ce proiectarea este sigura
Verificare si validare O descriere a procedurilor V & V
utilizate pentru planul de testare a
sistemului. Rezultatele sistemului
V&V
Componentele unui caz
de siguranta
Componenta Descriere
Rapoartele de revizie Inregistrarea tuturor comentariilor de
proiectar si siguranta
Competentele echipei Dovezi ale competentei echipei
implicate in sistemele de securitate
legate de dezvoltare si validare.
Procesul de QA Inregistrari ale proceselor de asigurare
a calitatii efectuate in timpul
dezvoltarii sistemului
Schimbarea proceselor de Inregistrarea tuturor modificarilor
management propuse, masurile luate si justificarea
sigurantei acestor modificari.
Cazuri de securitate asociate Trimiterile la alte cazuri de securitate
care pot afecta acest caz de siguranta.
Structura argumentului
Dovezi
Dovezi <<ARGUMENT>> Cerere
Dovezi
Argumentul pompei de
insulina
• Cerere
o Doza maxima calculata a unei pompe de insulina nu va depasi
maxDose.
• Dovezi
o Argumentul de siguranta pentru pompa de insulina (figura 24.7)
o Testarea setului de date pentru pompa de insulina
o Raportul de analiza statica pentru programul pompei de insulina
• Argumentul
o Siguranta argumentului prezentat arata ca doza maxima de
insulina care poate fi calculata este egala cu maxDose.
o In testele de 400, valoarea de doza a fost calculat corect si
niciodata nu a depasit maxDose
o In general, este rezonabil sa se presupuna ca afirmatia este
justificata.
Ierarhia cererii
Pompa de insulina nu va livra o
singura doza de insulina care
este nesigura
maxDose este
Doza unica maxima maxDose este o
configurat corect
calculata de pompa doza sigura pentru
atunci cand
programului nu va utilizatorul de
pompa este
depasi maxDose pompa de insulina
configurata
In mod normal, Daca programul

doza maxima esueaza, doza
calculata nu va maxima calculata nu
depasi maxDose va depasi maxDose
Puncte cheie
• Fiabilitatea de masurare se bazeaza pe exercitarea
sistemului, folosind un profil operational – un set de
intrari simulate, care se potrivesc cu folosirea
actuala a sistemului.
• Cresterea modelarii fiabilitatii este preocupata de
imbunatatirea modelarii fiabilitatii unui sistem
software care este testat iar defectele sunt
eliminate.
• Siguranta argumentelor sau dovezile sunt o
modalitate de a demonstra ca nu poate sa apara
o conditie periculoasa.
Puncte cheie
• Este important sa avem un proces de incredere
pentru dezvoltarea de sisteme de siguranta critice.
Procesul ar trebui sa includa identificarea
pericolelor si monitorizarea activitatilor.
• Validarea de securitate poate implica analiza
bazata pe experienta, pe baza de instrumente de
analiza sau utilizarea unei “echipe” pentru a ataca
sistemul.
• Cazurile de siguranta pot colecta impreuna dovezi
ca un sistem este in siguranta.

Cursuri IP Prezentări

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cursuri IP Prezentări

Încărcat de

Drepturi de autor:

Formate disponibile

Arhitectura aplicaţiilor

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 1

 Pentru a clarifica organizarea a două modele

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 2

 Sisteme de procesare a datelor

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 3

 Sistemele de aplicații sunt concepute pentru a

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 4

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 5

 Aplicații de procesare a datelor

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 6

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 7

 Sisteme care sunt centrate pe date, în care bazele

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 8

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 9

 Componenta de intrare citește datele dintr-un fișier

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 10

 Arată modul în care datele sunt procesate în timp ce

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 11

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 12

 Procesarea cererii utilizatorilor pentru obținerea

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 13

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 14

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 15

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 16

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 17

 Sistemele de informare au o arhitectura

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 18

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 19

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 20

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 21

 Sisteme care gestionează o cantitate fixă de

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 22

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 23

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 24

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 25

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 26

 Aceste sisteme răspund la evenimentele din

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 27

 Sisteme de timp real și sistemele de editare sunt

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 28

A nci l l ary data Edi tor data

A nci l l ary Edi ti ng

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 30

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 31

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 32

 Analizor lexical (Lexical analyser)

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 33

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 34

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 35

 Modelele generice de arhitecturi de aplicații ne ajută

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 36

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 13 Slide 37

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 14 Slide 1

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 14 Slide 3

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 14 Slide 4

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 14 Slide 5

o1: C1 o3:C3 o4: C4

o2: C3 o6: C1 o5:C5

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 14 Slide 6

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 14 Slide 7

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 14 Slide 8

Obiectele sunt create în funcție de unele definiții de clasă obiect . O