INTRODUCERE

Apariia sistemelor informaionale a permis realizarea

sistemelor de comutaie pe baz de program nregistrat.
Datorit avantajelor oferite, productorii de sisteme de
comunicaie s-au orientat definitiv ctre aceast soluie care
permite:
- controlul centralizat asupra ntregului sistem;
- schimbri funcionale i de configuraie ale
sistemului prin folosirea unei proceduri simple care
implic, n general, doar modificarea unor
instruciuni din programul nregistrat;
- adaptarea uoar a sistemului la servicii noi,
introduse n reeaua de telecomunicaii.
De-a lungul timpului, comanda cu program nregistrat a
cunoscut o evoluie condiionat de stadiul de dezvoltare al
tehnicilor i tehnologiilor incorporate n realizarea sa practic,
precum i de nivelul conceptual (de principiu) atins pe baza
experienei anterioare. Astfel, iniial, introducerea comenzii
cu program nregistrat a vizat doar nlocuirea logicii cablate a
sistemelor
electromecanice
de
comunicaie,
restul
componentelor rmnnd neschimbate.
Odat cu apariia sistemelor electronice de comutaie,
dorina de tipizare a orientat productorii ctre conceptul de
program generic, identic pentru toate realizrile din aceeai
generaie. Pe baza acestui program se executau toate
operaiile legate de prelucrarea apelurilor, de identificarea i
diagnosticarea deranjamentelor i de administrarea
sistemului prin intermediul diverselor activiti incorporate, de
exemplu observarea traficului deservit de sistem.
Cu toate c programul generic era acelai, situaia real
n care funciona (configuraia reelei de acces, planul de
adresare etc.) se deosebea de la un sistem de comunicaie
la altul. Pentru a oferi flexibilitatea din acest punct de vedere,
sistemele de comunicaie au fost dotate cu o baz de date n
3

care se nscriau informaiile cu caracter particular precum:

configuraia legturilor cu mediul exterior (linii de abonat,
jonciuni etc.), relaiile dintre componentele comandate,
planul local de adresare.
n timp, apariia cu o dinamic important de noi funcii
ndeplinite de programul generic, a condus la mrirea
corespunztoare a memoriei de nregistrare a programului.
Deoarece, n general, o anumit aplicaie utilizeaz doar o
parte din funciile oferite de programul generic, volumul
necesar de memorare a devenit ne justificat de mare (din
punct de vedere financiar i tehnic). Pentru a corecta
aceast deficien, urmtoarea generaie de sisteme de
comunicaie a fost nzestrat cu variante ale programului
generic complet, care conin doar funciile cerute de situaiile
concrete deservite.

CAPITOLUL 1
PROIECTAREA SOFTWARE-ULUI DE COMUTAIE
1.1. Cerine n proiectarea software-ului de comutaie
Proiectarea software-ului de comutaie este condiionat
de un ansamblu complex de cerine de cele mai multe ori
contradictorii. Aceste cerine in n principal de preteniile
clienilor ce vor fi abonai la respectivul sistem i de obiective
urmrite de viitorii proprietari i / sau administratori
(operatori) ai acestuia.
Criteriile principale dup care se orienteaz cei interesai
n achiziionarea i exploatarea de sisteme de comunicaie
sunt: satisfacerea cerinelor tehnice (capacitate, servicii
disponibile), costul ciclului de via alctuit din trei
componente; costul investiiei, costul dezvoltrii, costul
ntreinerii i posibilitile oferite de mbuntire i
introducere de noi servicii prin care se asigur creterea
beneficiului. Pe baza acestor criterii, care sunt n majoritate
de ordin financiar, se ia n final decizia asupra sistemului
care trebuie s fie achiziionat.
Cost
dezvoltare
2
Cost
investiie

Capacitate

Figura 1.1. Comparaie ntre costurile de dezvoltare a dou

sisteme de comutaie.
Relaia dintre costul investiiei i costul dezvoltrii
reprezint un factor important de care trebuie s in cont
att proiectantul ct i achizitorul unui sistem de comutaie.
5

n acest sens, figura 1.1. prezint dou posibiliti de

variaie n timp a costului de dezvoltare a dou sisteme de
comutaie identice din punct de vedere al performanelor
tehnice. Comparnd cele dou variante se desprinde
concluzia c dei prima variant (1) este mai ieftin din punct
de vedere al costului iniial, cheltuielile ulterioare de
dezvoltare dau ntietate celei din urm (2). Salturile mai
mari n costurile de investiie apar la creterea capacitii
peste anumite praguri, creteri ce impun aciuni cu pre mai
ridicat (de exemplu produse de adugare a unui alt
procesor). Pentru a oferi soluii atractive, proiectarea unui
sistem de comutaie trebuie s urmreasc ca aceste limite
s fie ct mai avansate, iar depirea lor s se fac cu
investiii ct mai mici.
Costul ntreinerii este un alt factor important, care este
urmrit de beneficiar i care trebuie avut n vedere n etapa
de proiectare. El se reflect n activitile de operare,
administrare i meninere a sistemului n stare de funcionare
(mentenabilitatea sistemului).
Pentru obinerea unor cheltuieli reduse de operare i
administrare, furnizorul sistemului trebuie s ofere:
- manuale clare i complete, care sunt absolut
necesare instruirii personalului uman,
- interfee om-main "prietenoase", cu o gam de
mesaje adecvate i lipsite de ambiguitate,
- procedee de dezvoltare, care s implice ct mai
puin operatorul att n modificrile de hardware ct
i n cele de software.
Pentru realizarea unor cheltuieli reduse de depanare sunt
necesare metode simple i rapide de readucere n serviciu a
componentelor intrate n avarie. n acest fel, precum i prin
nzestrarea fiecrei componente hardware sau software cu
toleran la defeciunile din jur, iar a sistemului cu posibiliti
de reconfigurare, disponibilitatea este meninut n limitele
acceptate de abonai.
6

n ultim instan, amortizarea cheltuielilor ciclului de

via i obinerea de beneficii depind de interesul clienilor de
a utiliza un anume sistem de comutaie. Din acest motiv,
proiectarea sistemelor de comutaie trebuie s urmreasc i
satisfacerea preteniilor viitorilor abonai. Acetia doresc, n
principal, uniformizarea modului de folosire a serviciilor
indiferent de tipul comutatorului accesat, satisfacerea
cererilor de serviciu la prima ncercare (disponibilitatea
sistemului din punct de vedere al utilizatorului) i
promptitudine n servire (de exemplu: recepionarea imediat
a tonului de disc, satisfacerea apelului din prima ncercare
etc.).
Satisfacerea complet a utilizatorilor unui sistem de
comutaie conduce n general la investiii nejustificat de mari.
Acest impas este depit dac modul de funcionare al
sistemelor de comutaie creeaz clienilor impresia c
exigenele lor sunt respectate, c fiecare terminal are control
complet asupra resurselor acestora. Atingerea acestui
obiectiv, presupune reformularea cerinelor de care trebuie
s in seama activitatea de proiectare: cerine de timp real
i cerine de timp partajat.
1.2. Suportul software-ului de comutaie
n orice tip de activitate, spiritul i materia se
condiioneaz reciproc; spiritul organizeaz i controleaz
materia, iar materia este cea care ofer suportul existenei
spiritului. n cazul software-ului de telecomunicaii, (i nu
numai), suportul este constituit dintr-un cod pentru a-l scrie, o
memorie pentru a-l nmagazina i un procesor pentru a-l
executa. De modul n care este conceput codul i este
organizat memoria, precum i de viteza de execuie a
instruciunilor (viteza procesorului) depinde n mare msur
satisfacerea cerinelor amintite n paragraful anterior.
7

1.2.1. Viteza procesorului

n general, procesoarele (microprocesoarele) execut un
program ce este format prin nlnuirea mai multor
instruciuni. Instruciunea este constituit dintr-o secven
specific de operaii de baz, numite i cicluri-main, M, ca
de exemplu:
- ncrcarea
(extragerea)
codului
operaiei
(instruciunii);
- citirea unui operand (dac operaia o cere);
- executarea operaiei;
- scrierea rezultatului (dac operaia o cere).
Un ciclu-main format din mai multe perioade (cicluri)
de ceas, T, (numite i stri), poate fi prelungit la nevoie prin
inserarea unor stri WAIT. Execuia unei instruciuni (un
ciclu-instruciune) va nsemna deci o succesiune de cteva
cicluri-main, care presupun fiecare la rndul lui
parcurgerea mai multor cicluri de ceas.
Operaiile de citire i scriere vizeaz att memoria
extern ct i dispozitivele de intrare / ieire cu care este
echipat configuraia n care lucreaz microprocesorul.
Figura 1.2. prezint structura general a unei instruciuni
specifice microprocesoarelor Z 80.

T1

T2

T3

T4

T1

T2

T3

T1

T2

T3

Ciclu main
M1 (extragere
cod operaie

M2 (citire
din memorie

M3 (scriere
n memorie

Ciclu
ceas

(Ciclu) Instruciune

Figura 1.2. Structura general a unei instruciuni Z 80.

8

Aplicaia 1.1.
n general, instruciunile unui procesor presupun mai
multe cicluri main. Considernd c un microprocesor
execut n rulare trei tipuri de instruciuni de 1, 2 i 4 cicluri
main, care apar n programe cu probabilitile p(1) = 0,7,
p(2) = 0,2 i respectiv p(4) = 0,1, s se determine durata
medie a unei subrutine de 100 de instruciuni. Se precizeaz
c durata ciclului main este de 1 microsec.
Valoarea duratei ciclului main reprezint unul din
principalii factori de care depinde viteza de execuie a
programelor. n cazul sistemelor de comutaie, aceast
dependen, care se face simit n numrul de apeluri ce pot
fi prelucrate ntr-un anumit interval, i determin pe
proiectani s se orienteze ctre utilizarea de procesoare
rapide. Ele ofer n prezent durate ale ciclului main de
ordinul zecimilor i sutimilor de microsec.
Aplicaia 1.2.
S se determine valoarea maxim a numrul mediu de
apeluri prelucrabile ntr-o or de un sistem de comutaie
uniprocesor tiind c:
- prelucrarea unui apel necesit execuia a 100 de
instruciuni;
- fiecare instruciune presupune executarea a 5
cicluri main;
- un ciclu main dureaz 0,1 microsec;
- 0,05% din ciclurile executate ntr-o or sunt
rezervate activitilor de ntreinere.
n realitate, serviciile oferite de un sistem de comutaie se
difereniaz n raport cu numrul de cicluri main necesare
fiecruia (de exemplu: aducerea unui apel n starea de
convorbire poate implica 5 000 de cicluri main n cazul
unui post particular i 20 000 de cicluri main n cazul unui
9

post public). Din acest motiv, stabilirea capacitii de

prelucrare (BHCA - Busy Hour Call Attempt) a unui sistem de
comutaie se face utiliznd diverse modele matematice sau
programe de simulare.
Aplicaia 1.3.
S se determine valoarea maxim a numrului mediu de
apeluri prelucrabile ntr-o or de un sistem de comutaie
uniprocesor tiind c:
- sunt 3 categorii de apeluri: de 1 000, 2 000 i 4 000
de cicluri main;
- apelurile aparinnd celor 3 categorii au
probabilitile de apariie: p(1) = 0,7, p(2) = 0,2 i
p(3) = 0,1;
- un ciclu main dureaz 0,1 microsec;
- nu se rezerv timp pentru alte activiti.
Indicaie de rezolvare: se va folosi media sumei unui
numr aleator de variabile aleatorii sau distribuiile
multinominale.
Aplicaia 1.4.
Realizai un program care
prezentat n aplicaia precedent.

simuleze

situaia

1.2.2. Organizarea memoriei

Respectarea n ansamblu a cerinelor impuse unui sistem
de comutaie face ca, din punct de vedere al organizrii
memoriei, proiectarea s se orienteze ctre partajarea
acesteia n dou componente: memoria fix i memoria
variabil. n funcie de volumul celor dou componente i de
raportul dintre ele, soluia aleas satisface anumite cheltuieli
de investiie, ofer anumite performane .a.m.d.
Memoria fix reprezint memoria minim necesar
prelucrrii apelurilor de ctre un sistem de comutaie. Ea
10

conine programul generic i pri din baza de date a

sistemului de comutaie, precum i informaiile de rutare i de
stare a apelurilor. Fiind absolut necesar, costul memoriei
fixe se regsete evident n costul iniial al oricrui sistem de
comutaie.
Memoria variabil conine informaii referitoare la
caracteristicile apelurilor generate de abonai (durate, rate de
apelare, utilizare servicii suplimentare etc.) i ale
echipamentelor incorporate n sistem. Tendina de
amplificare a memoriei variabile n orice situaie de
dezvoltare a sistemului de comutaie, face ca ea s
influieneze, prin costul su, cheltuielile generale de
dezvoltare.
n ultimii ani, costul memoriilor a sczut semnificativ. Cu
toate acestea, obinerea unei capaciti minime de memorare
rmne nc un obiectiv important al proiectrii, deoarece
software-ul cu care sunt dotate sistemele actuale de
comutaie a crescut substanial. Optimizarea memoriei se
obine n general prin utilizarea larg a buclelor [do...while,
for, ...) n cazul programrii i a compresiei informaiei n
cazul bazelor de date. Aceste tehnici prezint ns i
dezavantajul c structura programului i a bazei de date
devine dificil de modificat n vederea includerii de noi
caracteristici i tipuri de servicii.
1.2.3. Conceperea codului i programului
Stabilirea instruciunilor, ce alctuiesc codul main,
precum i implementarea programului, pe baza cruia sunt
ndeplinite activitile unitilor de comand din sistemele de
comutaie, depind deopotriv de o serie de factori, dintre
care cei mai importani sunt:
- viteza procesorului utilizat,
- capacitatea de memorare,
- complexitatea programului,
11

- constrngerile de timp real.

Interdependena acestor factori este att de strns nct
deciziile i soluiile propuse trebuie ntrite cu grij.
Aplicatia 1.5.
S se compare din punct de vedere al duratei i al
memoriei alocate, dou variante de implementare a unui
ciclu de explorare pentru 1 000 de terminaii ale unui sistem
de comutaie (tabelul 1.1). Terminaiile sunt repartizate n
vederea explorrii n grupe de cte 8. Fiecare instruciune se
desfoar pe durata unui ciclu main.
Rezolvare: Conform coninutului (date i rezultate) din
tabelul 1.1, prima variant este mai avantajoas din punctul
de vedere al necesarului de memorie (utilizeaz de
aproximativ 40 de ori mai puin memorie dect cealalt
alternativ), dar cea de-a doua variant este n schimb mai
simpl i de trei ori mai rapid (sunt necesare doar 250
cicluri fa de 751).
Tabelul 1.1 Variante de realizare a programului de explorare
Varianta l
Varianta II
fixeaz contor la 125; exploreaz rndul (1);
exploreaz
rndul nregistreaz rezultatul
(contor),
nregistreaz explorrii; exploreaz
rezultatul
explorrii; rndul (2); nregistreaz
Adresa1:
decrementeaz contor, rezultatul explorrii;
testeaz contor, dac exploreaz rndul(125);
contor 0 salt la adresa nregistreaz rezultatul
2; n caz contrar salt la explorrii.
adresa 1.
Rezultate:
Numr de
6
250
instruciuni
Numr de
751
250
cicluri
12

Observaie: exemplul, prezentat ca aplicaie, pune n

eviden importana deosebit pe care o are faza de
proiectare a programului. n aceast faz trebuie s se
urmreasc stabilirea unei soluii optime, prin considerarea a
dou obiective cu efecte contrarii: meninerea capacitii sub
o limit acceptabil din punct de vedere economic i
creterea numrului de activiti desfurate n timp real la
valori suficient de mari, care garanteaz realizarea unor
sisteme de comutaie performante.
O alt cale de optimizare a software-ului const n
definirea unor instruciuni i conceperea unor procesoare
dedicate sistemelor de comutaie. n acest caz, pot fi
ndeplinite activiti specifice, precum permutarea ciclic a 8
bii din interiorul unui cuvnt de 24 de bii (ntlnit n cadrul
procesului de stabilire a cilor de comunicaie prin reeaua
de conexiune), ntr-un numr de cicluri main mult redus
fa de cazul utilizrii unui calculator de uz general.
Tehnicile de optimizare a software-ului, descrise mai sus,
au ca obiectiv obinerea unei soluii tehnico-economice
avantajoase care s necesite un volum acceptabil de
memorare i capaciti satisfctoare de procesare n timp
real. Testarea soluiilor i ajustarea lor pn la forma final se
realizeaz, n general, prin simulri ce urmresc, n principal,
stabilirea capacitii de prelucrare n timp real a variantelor
analizate.
1.3. Software clasic de comutaie
Un software de comutaie (i nu numai) este alctuit, n
principal, din dou componente: programul i baza de date.
Programul cuprinde toate instruciunile logice necesare
ndeplinirii funciilor unui sistem de comutaie. Fiind proiectat
pentru a funciona n orice context el se mai numete i
program generic. Aceast flexibilitate este asigurat prin
faptul c informaiile relative la echipamentele i utilizatorii
13

specifici unui anumit sistem sunt nregistrate n baza de date

proprie a acestuia.
1.3.1. Programul generic
Programul generic ndeplinete o serie de funcii
referitoare la:
- prelucrarea apelurilor generate de abonaii proprii
sau adresate lor, precum i a diferitelor servicii pe
care sistemul l ofer abonailor,
- ntreinerea sistemului - asigurarea i meninerea
strii de funcionare a sistemului n ansamblu i pe
componente,
- administrarea sistemului - prin implicare n
procesele de nnoire (updating) i observare
(monitorizare) a sistemului respectiv.
Din punct de vedere organizatoric, programul generic
este alctuit dintr-un ansamblu de module program care
ndeplinesc funcii specifice. Coordonarea activitii acestor
module revine n sarcina unui program principal care le
apeleaz conform unui anumit plan, n funcie de necesiti.
Pentru a comunica ntre ele, modulele utilizeaz locaii de
memorie comune i circuite tampon (buffer).
1.3.1.1. Prelucrarea apelurilor
Sarcina principal pe care trebuie s o ndeplineasc un
program generic const n stabilirea la cerere a unei ci de
comunicaie ntre doi utilizatori. n cazul unui apel local,
realizarea acestei sarcini presupune:
1. detectarea unei cereri de serviciu;
2. interpretarea informaiei de numerotare;
3. alertarea prii chemate;
4. stabilirea conexiunii propriu-zise;
5. taxarea;
14

6. eliberarea conexiunii.
Memoria
cererilor de
serviciu
Interfee de
abonat

Programe
de cutare

Numr
terminal
chemtor

Program
control
execuie

Program
pregtitor

Memoria
terminalului
Caracteristicile
terminalului

Baz
de date

Figura 1.3. Iniializarea programului-pregtitor.

Cele ase activiti sus menionate reprezint funciile de
baz utilizate n procesul de prelucrare a apelurilor, avnd n
vedere c extensiile lor sunt utilizate i n satisfacerea
celorlalte servicii oferite de sistemul de comutaie (apel
distant, teleconferin, apel n ateptare etc.)
Componenta software a funciilor de prelucrare a
apelurilor este reprezentat de un ansamblu de programe
care coordoneaz diverse activiti. Astfel, pentru detectarea
cererilor de serviciu se utilizeaz programele de cutare
care, periodic, pe durata a aproximativ 100 msec exploreaz
toate jonciunile (pentru depistarea eventualelor apeluri
distante) i toate liniile de abonat (pentru depistarea
eventualelor apeluri locale). n cazul liniilor de abonai,
detectarea unui apel este urmat de nscrierea numrului
15

terminalului corespunztor ntr-o locaie din memoria tampon

a cererilor de servicii (figura 1.3.).
Memoria tampon a cererilor de servicii este trecut
periodic n revist de ctre programul de control al execuiei
care, dac detecteaz o nou cerere, activeaz un nou
program
pregtitor
oferindu-i
numrul
terminalului
corespunztor (aflat n stare de apel). Programul pregtitor
are ca obiectiv conectarea terminalului la un receptor de
cifre. Iniial, programul pregtitor creeaz o structur de date
temporar, numit memorie terminal, care este completat
prin copierea informaiilor necesare aflate n baza de date a
sistemelor de comutaie (de exemplu: modalitatea de
transmitere a informaiei de numerotare (impulsuri sau
DTMF), identitatea terminaiei la care este conectat
terminalul etc.). Baza de date conine nregistrri permanente
ale abonailor indexate dup numrul corespunztor al
terminalului.
Stare;
Temporizri;
Vitez explorare;
Adrese de legtur.
Terminaii;
Traseu prin reea.

Blocul de
control
Conexiuni
fizice

Informaii interne
speciale

Figura 1.4. Organizarea unei nregistrri de apel.

n continuare, programul pregtitor activeaz o
nregistrare de apel, care este o structur de date alctuit
din trei seciuni, aa cum se prezint n figura 1.4., i anume:
1. seciunea "bloc de control" care conine informaii
referitoare la:
- starea (faza) curent a apelului,
16

temporizatoarele - supravegheaz expirarea

unor intervale prestabilite de timp referitoare la
anumite faze de prelucrare a apelului, cum sunt
de exemplu recepia cifrelor de numerotare sau
operaia de desfacere a conexiunilor la sfritul
apelului,
- viteza de explorare - variaz n funcie de faza
de apel (de exemplu recepia cifrelor necesit o
vitez de sondare mult mai mare dect detecia
deconectrii),
- adresele de legtur pentru o comunicaie cu
alte nregistrri de apel sau cu alte blocuri de
memorie (de exemplu cu memorii terminal).
2. seciunea "conexiuni fizice" - nmagazineaz
informaii referitoare la identitile terminaiilor precum
i ale conexiunilor stabilite n sistemul de comutaie
pentru satisfacerea apelului n cauz.
3. seciunea "informaii interne speciale" - reprezint o
zon de lucru rezervat programelor generice. n
plus, aceast seciune mai cuprinde att adresele
abonailor implicai n apel, ct i informaia de taxare.
n nregistrarea de apel selectat, programul pregtitor
nscrie adresa de legtur la memoria terminal i identitatea
echipamentului de linie corespunztor (figura 1.5.). Urmeaz
apoi gsirea unui receptor de cifre n repaus i unei ci de
legtur prin reeaua de conexiune ntre acesta i terminal.
Cea din urm aciune se desfoar pe baza informaiilor de
stare coninute n harta reelei.

17

nregistrare
de apel

Identitate
echipament
de linie

Program
pregtitor

Traseul
selectat

Adres de
legtur

Memorie
terminal

Memorie
receptor

Harta
reelei

Figura 1.5. Conectarea receptorului de cifre.

Harta reelei este o baz de date ale crei nregistrri
conin informaii referitoare la strile de repaus (liber) sau de
angajare (ocupat) ale traseelor (drumurilor) prin reea.
Selectarea, respectiv eliberarea, unui traseu conduce la
reactualizarea coninutului din harta reelei, adic la
modificarea informaiei de stare referitoare la traseul
respectiv (anume la toate elementele implicate n acest
traseu).
Un receptor de cifre reprezint o entitate cu o
component hardware, care const dintr-o memorie tampon
de numere, i o component software, constituit dintr-un
program de decodificare a informaiei de numerotare
recepionat n interfaa liniei de abonat. Angajarea sa de
ctre un program pregtitor presupune ca cel din urm s
memoreze datele asociate receptorului ntr-un segment de
memorie temporar a crui adres de nceput (de legtur)
o nscrie n nregistrarea de apel.
n procesul de achiziionare i prelucrare de date ce
nsoete tratarea unui apel s-a optat pentru utilizarea de
segmente de memorie temporare n dorina ca nregistrrile
18

de apel s aib dimensiuni constante i ct mai mici. n acest

fel, restul informaiilor, ce nu sunt necesare pentru toate
funciile implicate n prelucrarea unui apel, sunt memorate
separat, n segmente care n momentul n care nu mai sunt
necesare sunt reintegrate n memoria neutilizat a
sistemului. Pentru o comunicare rapid ntre diversele
structuri de date ce corespund aceluiai apel, legturile
dintre acestea sunt bidirecionale (figura 1.6.).

Adres de
legtur

Adres de
legtur

Figura 1.6. Structuri de date dublu nlnuite.

Prin conectarea receptorului de cifre la terminal,
programul pregtitor i ncheie activitatea, programul de
control al execuiei iniiind programul de decodificare a
informaiei de numerotare. Pentru o corect recepie a
cifrelor, ciclul de sondare al acestui program trebuie s fie
rapid, n mod normal de 10 msec. Cifrele recepionate sunt
colectate ntr-o seciune a memoriei tampon de numere, care
este asociat nregistrrii de apel pe tot parcursul strii de
numerotare (figura 1.7.).

19

Interfee

Programe
decodificare

Memoria
numerelor
cifre

Program
control
execuie

Program
analiz
numr

Baz
de
date

nregistrare
de apel

Informaii
de rutare, identitate
terminaie, etc.

Figura 1.7. Activiti legate de recepia numrului.

Pe msur ce cifrele sunt nscrise n memoria numerelor,
programul de control al execuiei activeaz programul de
analiz al numrului care, n cazul unui numr valid, extrage
din baza de date identitatea terminaiei de destinaie i
informaiile de rutare pe care le depune n nregistrarea de
apel. Cunoaterea identitii destinaiei d posibilitatea
testrii strii acesteia. n cazul n care aceasta este n repaus
urmeaz cutarea a trei ci de comunicaie: una ntre
terminaia "surs" i terminaia "destinaie", a doua ntre
generatorul tonalitii de revers apel i terminaia surs i a
treia ntre generatorul curentului de sonerie i terminaia
destinaie. Este evident c depistarea celei dinti dintre cele
trei ci de comunicaie este decisiv pentru continuarea
cutrii celorlalte dou.

20

Program
control
execuie

Program
de
avertizare

Program
de sondare

Linie
destinaie
Linie
surs

Terminaii

Generator
curent de
sonerie

Harta
reelei

Generator
audio
revers apel

Figura 1.8. Activiti legate de avertizarea abonailor.

Dup gsirea cilor, marcate n harta reelei, programul
de analiz a numrului se finalizeaz, iar programul de
control al execuiei activeaz programul de avertizare.
Acesta stabilete efectiv cile de avertizare (curent de
sonerie i tonalitatea de revers apel) i iniiaz un program
de supraveghere, ce urmrete detecia rspunsului la
partea chemat sau deconectarea la partea chemtoare
figura 1.8.).
Terminaii

Program
de sondare

Program
control
execuie
Program
conector

Numr
terminal
Memoria
rspunsurilor

Harta
reelei

Figura 1.9. Activiti legate de rspunsul abonatului chemat.

21

La detectarea rspunsului, programele de sondare

nscriu numrul terminalului chemat ntr-o memorie a
rspunsurilor (figura 1.9.). n continuare, programul de
avertizare este dezactivat i sunt iniiate alte module program
care stabilesc calea de convorbire ntre cele dou terminaii.
ntruct apelul a intrat ntr-o stare relativ stabil, o bun parte
din segmentele de memorie temporar sunt eliberate. Pentru
sesizarea deconectrii, programele de sondare rmn active,
iar atunci cnd acest evenimente se petrec, intervin
programele de taxare i deconectare, ce duc n final la
trecerea terminaiiior n stare de repaus i la eliberarea
nregistrrii de apel, ea devenind disponibil altor solicitri.
1.3.1.2. Funcii de ntreinere i administrare
Principala activitate a programului generic ine de
prelucrarea apelurilor. Cu toate acestea, n majoritatea
cazurilor, segmentul destinat acestei activiti reprezint doar
20 % din totalul setului de instruciuni cuprinse n programul
generic. Restul coninutului este destinat funciilor de
ntreinere i administrare a sistemului de comutaie. Aceste
funcii urmresc meninerea n limite prescrise a parametrilor
de funcionare ai sistemelor de comutaie i realizeaz
activitile urmtoare:
Depistarea i depanarea defectelor - funcii
complementare ce au ca sarcin identificarea,
semnalarea i analizarea situaiilor de avarie, cu
scopul stabilirii cauzelor ce le-au determinat, precum
i remedierea automat a defeciunilor n cazurile n
care acest lucru este posibil. n cazul componentelor
hardware, activitile amintite se materializeaz, de
exemplu, n stabilirea unitii defecte i comutarea
sistemului pe o unitate de rezerv, pus la dispoziie
de redundana sistemului.
22

Controlul suprasarcinilor - evalueaz gradul de

ncrcare a sistemului de comutaie. Pe baza
informaiilor oferite de aceast component a
programului generic, funciile de prelucrare a
apelurilor acioneaz n sensul meninerii stabilitii n
funcionare a sistemului, chiar i n condiii severe de
lucru, cnd volumul de prelucrri n timp real i traficul
deservit ating valorile limit.
Verificrile curente - reprezint un ansamblu de
programe destinate depanrii "din mers" a softwareului unui sistem de comutaie. n principal, ele se
ocup cu recuperarea segmentelor pierdute de
memorie, precum blocurile de memorie temporar i
nregistrrile de apei disprute din evidenele listelor
de structuri de date active sau n repaus i asistarea
programelor de redresare a programelor de prelucrare
a apelurilor ajunse n situaii neateptate.
Redresarea sistemului - funcia ce este activat atunci
cnd o cauz major a afectat sistemul de ansamblu.
Amploarea aciunilor ntreprinse de aceste funcii
variaz de la caz la caz, nivelul maxim reprezentnd
rencrcarea complet a programului generic. Pentru
a evita aceast soluie extrem, n urma creia toate
apelurile n curs de desfurare sunt ntrerupte,
activitile de redresare a sistemului urmeaz o
anumit ierarhie, n care cel mai sczut nivel de
amploare este cel care are efecte negative minime
pentru clienii sistemului. Astfel, de exemplu,
redresarea sistemului poate debuta cu reiniializarea
unui bloc de memorie care conine date invariabile.
Dac aceast aciune nu a restabilit funcionarea
sistemului, atunci funciile de redresare trec succesiv
prin urmtoarele niveluri de amploare, pn ce
activitatea de refacere d rezultatele dorite. Pentru a
evita atingerea unor niveluri crescute de amploare,
23

funciile de redresare ale sistemului colaboreaz cu

restul funciilor de ntreinere. n acest fel, pe lng
ajutorul oferit de cele din urm, funciile de redresare
sistematic primesc i o serie de indicatori utili pentru
evaluarea gradului de degradare a sistemului i pentru
stabilirea deciziei dac se trece sau nu la urmtorul
nivel de amploare.
Efectele generate de atingerea ultimului nivel de
amploare pot fi limitate dac rencrcarea programului
generic afecteaz doar apelurile aflate n faza transmiterii.
Acest lucru este posibil deoarece imaginea software a unui
apel n stare de convorbire se limiteaz doar la o nregistrare
de apel, iar detectarea sfritului de convorbire (deschiderea
buclei la una dintre pri) se realizeaz prin programe de
cutare identice cu cele n care terminaiile sunt n repaus.
Funciile administrative ofer operatorului suportul
desfurrii activitilor respective. Printre acestea se pot
enumera: observarea traficului real, care este util ingineriei
de trafic, modificarea informaiilor curente din locaiile bazei
de date i inspectarea memoriei de lucru.
1.3.2. Organizarea bazei de date
A doua component major a software-ului de comutaie
o reprezint baza de date. Prin intermediul acestei
componente, programul generic, proiectat n scopul deservirii
unei arii largi de aplicaii, se integreaz ntr-un anumit
context particular.
Baza de date a unui sistem de comutaie conine
informaii referitoare la utilizatorii i echipamentele acestora.
a) Pentru fiecare utilizator, baza de date cuprinde, n
principal:
- numrul de telefon,
- identitatea (adresa) terminaiei la care este
conectat linia,
24

- serviciile la care are acces,

- jonciunile utilizabile n cazul legturilor distante,
- cile de rutare i informaiile de taxare.
b) n privina echipamentelor, baza de date furnizeaz
programului generic structura hardware a sistemului de
comutaie. Descrierea structurii n cauz ia n considerare o
serie de elemente precum:
- numrul de cadre (repartitoare),
- numrul de circuite din acestea,
- adresele prin care software-ul le poate accesa,
- dimensiunea memoriei de lucru,
- configuraia reelei de conexiune.
Din punct de vedere organizatoric, baza de date se
structureaz sub forma unei ierarhii de liste nlnuite. Prin
adoptarea acestei soluii, se economisete memorie, o
anumit informaie fiind nscris ntr-o unic locaie de
memorie. Pentru a permite accesul la orice informaie din
baza de date, fiecare nod al unei liste este o structur de
date (practic, un tabel), care, pe lng diverse informaii,
conine i adresele de legtur (pointer-i) la structurile de
date subordonate (figura 1.10.).
Structur
master

Structur
de date

Nivel 1

Structur
de date

Structur
de date

Structur
de date

Nivel 2

Nivel 3

Figura 1.10. Liste nlnuite de structuri de date.

25

Vrful ierarhiei este ocupat de o structur maser

(structur primordial) care este nmagazinat ntr-o locaie
fix a memoriei. Pentru restul structurilor ce sunt accesate,
pornind de la adresele cuprinse n structura master,
localizarea lor n memorie nu este unic, ele putnd fi
transferate n funcie de necesiti (de exemplu: modificarea
numrului de cmpuri cuprinse ntr-o structur de date) prin
realocare de memorie. Pentru a se pstra integritatea listei,
adresa de legtur coninut n structura de date superioar
trebuie reactualizat.
2
4
Numr 1
chemat 3
0
0
8

Translator
Subtranslator Adres
2410XXX2411XXX2412XX
X2413XXX2414XXX......

Subtranslator
2413XXX
......006007008....

Sufix

Localizare
terminaie

Figura 1.11. Identificarea terminaiei abonatutui chemat.

Cutarea unei informaii nregistrat n baza de date se
face parcurgnd listele de sus n jos. Pentru aceasta,
programul generic acceseaz structura master, ca s extrag
de aici, pe baza unui anumit criteriu, adresa urmtoarei
structuri. De exemplu, figura 1.11. prezint schematic modul
de organizare a unui segment din baza de date, care ofer
identitatea terminaiei corespunztoare numrului abonatului
chemat. Astfel, pe baza primelor 4 cifre din numr, se
extrage din primul tabel adresa tabelului urmtor din care, pe
baza restului de cifre, se extrage identitatea terminaiei
cutate. Reprezentarea tabelelor subtranslatoare din figura
26

1.11. are un caracter pur didactic; n realitate, tabelele au o

singur coloan, sufixul dup care se face cutarea
constituind adres de indexare.
1.4. Software de comutaie telefonic
Software-ul utilizat n prezent n majoritatea sistemelor de
comutaie este rezultatul unui efort constant de cretere a
eficienei care a urmrit prelucrarea a ct mai multe apeluri
ntr-un timp ct mai scurt, utiliznd ct mai puine resurse.
Parametrul major care condiioneaz aceast problem de
optimizare l constituie legtura dintre capacitatea i costul
sistemului.
Variantele timpurii de software de comutaie au fost
proiectate pentru a satisface n principal centralele telefonice
care ofereau un numr restrns de servicii. Odat cu
dezvoltarea de noi servicii, software-ul s-a modernizat
urmnd, ns, n general, aceleai principii.
1.4.1. Arhitectura software
Arhitectura unui software curent de comutaie poate fi
reprezentat ca n figura 1.12. Activitile unui sistem de
comutaie sunt iniiate, n principal, de evenimentele ce
survin la terminaiile de intrare ale acestuia. Sesizarea
acestor este n sarcina programelor de intrare care, pentru
corecta lor interpretare (a cifrelor, a ridicrii / coborrii furcii
etc.), lucreaz n timp real (10 msec sau 100 msec pe ciclu).
Reciproc, programele de ieire sunt destinate celuilalt sens
de comunicare: de la sistemul de comutaie ctre ieirile
acestuia (tot terminaii). Tampoanele de intrare / ieire au
rolul de a intermedia schimbul de date ntre medii software
ce lucreaz la viteze diferite (viteza de lucru a procesoarelor
ce execut programele de intrare / ieire este, de obicei, mai
mic dect a procesoarelor dedicate programelor interne).
27

Programe de intrare
Tampoane de intrare

Program
pregtitor

Program
analiz
numr

Program
avertizare linii
abonat
Program
semnalizare
jonciune

Program
de
conectare

Program
de
deconectare

Tampoane de ieire
Programe de ieire

Figura 1.12. Reprezentarea conceptual a arhitecturii

software-ului de comutaie.
Din punct de vedere al limbajului de programare,
software-ul de comutaie utilizeaz conceptele de clas,
funcii membre, obiecte motenite etc. (vezi limbajul C++). n
acest sens, pentru o anumit activitate (de exemplu: analiza
numrului) se definete o clas specificndu-se variabilele
de lucru folosite i funciile implicate.
Pe baza acestor clase, ori de cte ori trebuie iniiat o
activitate se creeaz (instaniaz) un obiect care are acces la
toate funciile clasei printe, doar variabilele personale de
lucru ocupnd o locaie de memorie distinct. Astfel,
desfurarea simultan a mai multor activiti de aceeai
natur implic doar multiplicarea locaiilor de memorie
necesare variabilelor de lucru, funciile membre rmnnd
unicat. Atunci cnd un obiect i nceteaz existena, locaia
de memorie aferent este disponibilizat (eliberat) pentru
alte utilizri.
Pentru a putea controla echipamentul hardware asociat
activitilor sale, un obiect are control direct asupra
28

interfeelor cu sistemul de comutaie prin intermediul funciilor

membre ale clasei. Tot prin intermediul funciilor membre, un
obiect are acces la memoria comun temporar i la
nregistrrile de apel i poate nscrie direct date n
tampoanele de ieire.
1.4.2. nlnuirea programelor
nlnuirea programelor tip modul din cadrul unui
software de comutaie urmeaz o anumit disciplin bazat
pe conceptele de nivel de prioritate i nivel de ntrerupere.
Toate modulele cuprinse n programul generic sunt
caracterizate printr-un anumit nivel de prioritate. Pe baza
acestui atribut, programate se clasific n categorii
prefereniale.
Detector de disponibiliti
+
Control prin operator

Baza de timp

Program cablat de control ntreruperi

A
Centru de
control
general

C
Centru
de
control

B
Aciuni
stare de
urgen

E
Salvare
program

D
Salvare
apeluri

G
Teste
speciale

H/I
Intrri
Ieiri

Program
principal
A
B

F
Uniti
periferice

Restart
sau
restaurare

C
D
Restaurare

ntreruperi de ntreinere

Programe
prelucrare
ntreruperi apeluri i
periodice ntreinere

29

Figura 1.13. Planul de nlnuire a programelor.

Numrul categoriilor prefereniale difer de la o aplicaie
la alta. Figura 1.13. prezint un exemplu de plan de
nlnuire a programelor difereniate n 5 categorii: A, B, C, D
i E. Categoria A are nivelul de prioritate cel mai nalt, iar E
are nivelul cel mai sczut. n momentul cnd mai multe
programe cer a fi executate, programul principal l activeaz
pe cel cu cea mai mare prioritate. Adoptnd aceast politic,
programele cu prioritate superioar (de exemplu programe
de analiz a numrului) vor rula mai frecvent dect cele cu
prioritate inferioar (de exemplu programe de conectare la
un generator de tonaliti), ceea ce este i de dorit.
n numeroase situaii este necesar execuia unor
programe ce nu sufer amnare. Aceste programe, numite
ntreruperi, opresc temporar execuia programului curent, i
desfoar activitile dup care repun n activitate
programul sistat din locul n care s-a oprit. n general, aceste
intervenii, nu perturb desfurarea programelor ntrerupte
dect prin introducerea unor ntrzieri suplimentare n
execuia tor. Totui, atunci cnd situaia o cere, intervenia
unei ntreruperi poate duce chiar la abandonarea
programelor n curs de desfurare.
Activitile desfurate de ntreruperi se difereniaz prin
importana lor. Din acest motiv este necesar ca i
ntreruperile s prezinte diverse grade de prioritate. n acest
fel, se evit ca o ntrerupere inferioar s ntrzie sau s
sisteze temporar o ntrerupere de importan vital. n figura
1.13. se prezint modul de clasificare a ntreruperilor de
ntreinere (A, B, C, D, E, F, G) i a ntreruperilor periodice (H
i I).
ntreruperile de nivel A sunt sub controlul operatorului
uman, fiind destinate interveniilor de depanare sub
supravegherea acestuia. Nivelul B este compus din aciunile
de urgen prin intermediul crora, n mod automat, se
analizeaz i se ncearc s se restabileasc buna
30

funcionare a sistemului ajuns ntr-o faz critic. Celelalte

niveluri, C - G, sunt destinate aciunilor de corectare a
diverselor disfuncionaliti hardware de mai mic amploare.
Nivelurile H i I cuprind activiti ce trebuie desfurate la
momente precise. Aceste ntreruperi se ocup cu procesele
de intrare/ieire (de exemplu: programele de cutare) i sunt
coordonate de impulsurile generate de baza de timp (T= 5
msec) a sistemului.
1.4.3. Deficienele software-ului
de comutaie telefonic
Adoptarea principiilor de proiectare prezentate mai sus
conduce la un software de comutaie fragmentat n module
program, a cror funcionare se nlnuie temporar conform
evoluiei unui apel telefonic (figura 1.14.). Aceste module
program trebuie s dein informaii detaliate relative la
comportarea procesului n fazele luate n considerare (de
exemplu: programul pregtitor trebuie s cunoasc tipurile
de semnalizri ce le poate recepiona, temporizrile relative
la ridicarea / coborrea furcii etc.) i la hardware-ul pe care-l
are la dispoziie.
Soluia asamblrii unui software de comutaie din astfel
de module program conduce, n general, la programe de
dimensiuni considerabile. Din acest motiv, proiectarea este
nsoit de o susinut activitate de optimizare a codului, n
vederea obinerii unei ocupri acceptabile de memorie a unei
operri eficiente. ns acest obiectiv este atins printr-o
puternic specializare a modulelor program, acestea oferind
pe ansamblul sistemului o prelucrare eficient a serviciilor
pentru care au fost proiectate. Creterea eficientei de
prelucrare este pltit prin ngreunarea procesului de
dezvoltare a software-ului de comutaie n vederea
introducerii unor noi servicii.
31

Programe de intrare
Tampoane de intrare

Serviciu
nou
Program
pregtitor

Program
analiz
numr

Program
avertizare linii
abonat

Program
de
deconectare

Program
de
conectare

Program
semnalizare
jonciune
Tampoane de ieire
Programe de ieire

Figura 1.14. Efectul introducerii unui nou serviciu.

Figura 1.14. prezint implicaiile produse de introducerea
unui nou serviciu (apel n ateptare sau teleconferin)
asupra structurii unui program modular pentru prelucrarea
apelurilor. Includerea unui nou modul program, care este
dedicat unui serviciu nou, implic modificri ale modulelor
program din amonte (de exemplu programul pregtitor, ...) i
de pe acelai nivel (programul de avertizare linie abonat, ...);
aceste modificri au scopul armonizrii n funcionare a
ansamblului existent cu noul modul. n plus, modulul program
destinat noului serviciu trebuie s cunoasc modul de
funcionare a modulelor aflate pe acelai nivel sau n aval.
Toate modificrile sus menionate conduc la creterea
conectivitii, adic a interdependenei dintre modulele
program. Acest lucru face ca schimbarea caracteristicilor
32

unui anumit serviciu s necesite revizuiri n mai multe

module program. O asemenea activitate complex de
schimbare favorizeaz apariia unor disfuncionaliti, motiv
pentru care orice modificare trebuie s fie nsoit de
testarea amnunit a integritii ntregului sistem.
Tendinele actuale i previziunile legate de dezvoltarea
serviciilor pun n eviden creterea numrului i
complexitii acestora (transmisii de date, imagini video,
calcul cooperant, de asisten medical etc.).
Pentru a evita activitile dificile i costisitoare de
integrare a noilor cerine n cadrul unor arhitecturi software
de genul celei analizate, proiectanii i realizatorii de sisteme
numerice de comutaie au dezvoltat un nou model de
software de comutaie ale crui principale coordonate sunt
prezentate n Capitolul 2.

33

34

CAPITOLUL 2
SOFTWARE-UL MODERN DE COMUTAIE
2.1. Noiuni i termeni din domeniul software-ului
modern de comutaie
Ritmul alert, de diversificare a serviciilor i de modificare
a caracteristicilor acestora, a orientat activitatea de
proiectare a software-ului de comutaie ctre identificarea
unor soluii care s ofere flexibilitate ct mai mare la aceste
schimbri. Aceast flexibilitate trebuie s considere att
serviciile viitoare, puse la dispoziie abonailor, ct i cerinele
ulterioare pe care deintorii sistemelor de comutaie le vor
manifesta n dorina unei operri, ntreineri i administrri
superioare a acestora i, nu n ultimul rnd, s urmreasc
ndeplinirea tuturor acestora n condiii tehnico-financiare i
de eficien convenabile.
Cutarea unei arhitecturi "ideale", care s ofere un grad
nalt de flexibilitate, ia in considerare un ansamblu complex i
dinamic de factori dintre care cei mai importani sunt
urmtorii:
mediul de procesare (n general, varianta distribuit
primeaz asupra celei centralizate),
dependena de tipul serviciului a echipamentului
hardware i a structurilor de date (se urmrete a fi
eliminat aceast dependen),
gradul de modularizare (cu ct este mai accentuat, cu
att mai uoar devine definirea pentru fiecare tip de
modul a unei interfee simple de testare ct i
suplimentarea serviciilor; preul modularizrii excesive
l constituie ns degradarea eficienei sistemului),
interdependena dintre servicii (trebuie minimizat).
Astfel de probleme cu grad nalt de dificultate se pot
rezolva adoptnd metodologiile elaborate n cadrul
domeniului de cercetare cunoscut ca ingineria software. n
35

cazul aplicaiilor de uz general, acest cadru de lucru i-a

demonstrat calitile oferind software de nalt calitate n
condiii de cretere a productivitii. Utilizate i n cazul
sistemelor de comutaie, metodologiile ingineriei software
trebuie completate cu tehnici de optimizare, care sa
corecteze rezultatele iniiale, ineficiena din punct de vedere
al timpului de execuie i al volumului de memorie utilizat, n
vederea obinerii unei soluiei finale, care s rspund tuturor
cerinelor impuse unui software de comutaie.
2.2. Elementele ingineriei software
Ingineria software s-a dezvoltat ca urmare a necesitii
de a crea un cadru organizat de concepere a software-ului
care s asigure produse de calitate n condiii superioare de
productivitate. Aa cum se precizeaz i n figura 2.1.,
ingineria software a redus substanial efortul de dezvoltare
(~50%) i de ntreinere (~75%) fa de procedeele
premergtoare.
15 Specificare
Proiectare,
65 Integrare,
Testare cod
20

ntreinere

1:1

2:1

30
60

4:1

% din totalul activitii

10
% din totalul activitii

Experien anterioar

Rezultat

Figura 2.1. Beneficiile ingineriei software

fa de experiena anterioar.

36

Aceste rezultate s-au obinut prin perfecionare continu

i aplicare susinut a trei categorii de concepte, ce sunt
prezentate n paragrafele urmtoare.
2.2.1. Structura software-ului
Experiena acumulat de-a lungul timpului a artat c
modul de concepere are o influen major asupra
caracteristicilor unui software de comutaie. Astfel,
flexibilitatea atinge cote presupunnd fracionarea softwareului n funcii componente de mic ntindere, a cror
activitate comun se bazeaz pe legturi minime de
interdependen. Funciile de mic ntindere, sub 1 000 de
instruciuni, sunt avantajoase deoarece ele sunt uor de
scris, de corectat, de verificat sau de modificat.
De exemplu, pentru sondarea strii unei linii se poate
crea o funcie care returneaz o variabil boolean (DA / NU)
ce semnaleaz "nchiderea" sau "deschiderea" buclei.
Aceast funcie poate fi activat de o alt funcie (printe)
care se ocup cu identificarea buclelor nchise. n acest caz,
interfaa dintre cele dou funcii este constituit de schimbul
de informaii dintre acestea: ntr-un sens, argumentul furnizat
funciei copil de ctre funcia printe (este vorba de
identitatea liniei), iar n cellalt sens, valoarea ntoars
(returnat) de ctre funcia copil spre funcia printe.
Un alt concept important legat de structura software-ului
l constituie capacitatea programului de a face abstracie de
modul de reprezentare a informaiei n bazele de date
aferente. Dispunnd de aceast nsuire, un software de
comutaie i micoreaz sensibilitatea la modificrile
ulterioare ce vor afecta structurile bazelor de date cu care
intr n contact.
O soluie care asigur abstractizarea sus menionat o
constituie intercalarea ntre program i structura de date a
unui subsistem de administrare a bazei de date. Prin
37

intermediul acestei componente, funciile au acces la

informaii, fr s se mai fie necesar cunoaterea modului
n care acestea sunt reprezentate n baza de date curent.
2.2.2. Metodologia de dezvoltare
Un factor important care influeneaz decisiv calitatea
software-ului l constituie metodologia de dezvoltare a
acestuia. Aceast metodologie se refer, n principal, la
tehnicile propriu-zise de programare-dezvoltare i la modul
de organizare a echipei de proiectare.
De-a
lungul
evoluiei
generale
a
sistemelor
informaionale, dar i a evoluiei particulare a sistemelor de
comutaie cu program nregistrat, s-au experimentat diverse
tehnici de programare-dezvoltare de software. Elaborate
iniial n mod empiric, aceste tehnici au urmat un proces
evolutiv n care dorina fundamentrii teoretice a condus
ctre soluii tot mai performante, att din punct de vedere al
calitii software-ului, ct i ai timpului alocat dezvoltrii sale.
n prezent, printre tehnicile de dezvoltare aplicate cu
succes se numr i cea a dezvoltrii de sus n jos.
Realizarea unui ansamblu software ierarhizat bazate pe
aceast tehnic presupune c dezvoltarea sa ncepe din
vrful ierarhiei i continu cu abordarea succesiv a
nodurilor din nivelurile ierarhice inferioare.
Din punct de vedere software, fiecare nod al ierarhiei
reprezint o funcie (un modul program) care, nainte de a fi
integrat n ansamblu, trebuie s fie temeinic verificat.
Astfel, n cazul adoptrii n proiectarea software-ului a
principiului diviziunii funcionale, funciile printe sunt testate
naintea funciilor subordonate.
n privina modului de organizare a echipei de proiectare,
acesta a progresat continuu pe baza experienei i a studiilor
ntreprinse n aceast direcie. Un astfel de studiu ntreprins
de IBM a demonstrat, de exemplu, eficacitatea organizrii de
38

tipul echip cu programator ef. O astfel de echip este

alctuit din specialiti n diverse domenii software, selectai
n funcie de obiectivul urmrit. Dintre ei se desemneaz
programatorul ef, lui revenindu-i sarcina de a coordona
activitatea echipei subordonate.
2.2.3. Mijloace de dezvoltare
Creterea continu a complexitii activitilor legate de
definirea funciilor i de transpunerea lor n plan software a
fcut necesar dezvoltarea unor mijloace (unelte = tools),
care s ofere un suport de desfurare eficient a acestora.
"Uneltele" cele mai utilizate n ingineria software-ului de
comutaie sunt:
limbajul de specificare i descriere,
diagrama de secvene ale mesajelor,
limbajele de nivel nalt.
A. Limbajul de specificare i descriere, SDL
n 1976, CCITT a pus la dispoziia proiectanilor de
software pentru comutaie un limbaj (formal) de specificare i
descriere, SDL, (Specification and Description Language).
Acest "limbaj" este recomandat att pentru specificarea
funcionalitii unui sistem de comutaie ("ce are de fcut"),
ct i pentru descrierea detaliat, la nivel logic, a funciilor
propriu-zise ("cum se face").
Prelund diferite concepte i metode dezvoltate n cadrul
teoriei automatelor cu stri finite, limbajul SDL permite
descrierea de structuri i procese prin intermediul unor
cuvinte cheie i / sau a unor simboluri grafice.

39

Concept
Sistem
Bloc
Canal

SDL/GR

Figura 2.2. Concepte SDL pentru reprezentarea

grafic a structurii unui sistem.
Astfel, pentru prezentarea structurii unui sistem, limbajul
ofer conceptele de sistem, bloc i canal a cror
reprezentare grafic, SDL/GR (Graphic Representation),
este coninut n figura 2.2. n dorina de a oferi mai multe
niveluri de detaliere, blocurile pot fi descompuse, la rndul
lor, n sub-blocuri i canale. Pentru aceast operaiune,
limbajul SDL pune la dispoziie dou noiuni specifice:
sub-structur - pentru a specifica modul de alctuire a
unui bloc cu structur intern,
despicare - pentru a descrie modul n care un canal
legat la bloc se despic n interiorul acestuia n mai
multe canale.
Limbajul SDL permite i descrierea sub form de text,
SDL/PR, (Phrase Representation) a structurii unui sistem,
cteva forme de sintax pot fi folosite:
a) pentru definirea unui sistem:
SYSTEM [nume];
[definiii semnale]
[definiii canale] [definiii blocuri]
ENDSYSTEM [nume];
b) pentru definirea unui bloc:
BLOCK [nume];
[definiie proces] [definiie sub-structur]
ENDBLOCK [nume];
40

c) pentru definirea unui canal:

CHANNEL [nume] FROM [nume bloc / ENV] TO [nume
bloc / ENV] WITH list semnale];
(ENV specific legtura cu exteriorul sistemului;
environment).
d) pentru definirea unei despicri:
SPLIT [nume canal despicat] INTO [list canale];
e) pentru declararea de sub-blocuri:
SUBBLOCKS [list cu numele blocurilor incluse];
f) pentru declararea canalelor dintr-o anumit structur:
CHANNEL [list cu numele / identitatea canalului];
g) pentru definirea unei sub-structuri:
SUBSTRUCTURE [numele blocului a crui structur este
descris];
[declarare sub-blocuri coninute]
[declarare canale coninute]
[definirea despicrilor]
[definirea blocurilor]
[definirea canalelor]
END SUBSTRCTURE [numele blocului a crui structur
a fost descris];
h) pentru declararea semnalelor:
SIGNAL [list semnale]
Observaie: declararea unui semnal se rezum la nume
sau poate include i tipurile de date transportate.
Conform listei de mai sus, instruciunile prin care se
reprezint structura unui sistem se mpart n dou categorii:

41

definiii reprezint o descriere complet a

entitilor (sistem, bloc, ...) asupra crora se
rsfrng,
- declaraii reprezint doar o enumerare a acestor
entiti.
Dei par a fi redundante, declaraiile i gsesc aplicare
n numeroase situaii, i anume atunci cnd introducerea
unor entiti (blocuri, canale, ...), n descrierea SDL textual,
precede definirea acestora.
Aplicaia 2.1.
S se prezinte n limbaj SDL/PR sistemul descris prin
intermediul limbajului SDL/GR n figura 2.3. Notaiile
ncadrate n paranteze drepte reprezint denumirile
semnalelor transmise pe canalele corespunztoare.
A
B1

C1[S1]

C11

B21
C21[S21]

C12
B22
B2

C3
C22[S22]

B3

Figura 2.3. Sistem definit cu ajutorul limbajului SDL.

Rezolvare:
SYSTEM A;
SIGNAL S1,S21,S22;
CHANNEL C1 FROM B1 TO B2 WITH S1;
CHANNEL C3 FROM B2 TO B3 WITH S21, S22;
BLOCK B1
ENDBLOCK B1;
BLOCK B3;
42

BLOCK B2;
SUBSTRUCTURE B2;
SUBBLOCK B21,B22;
CHANNEL C11, C12, C21, C22;
SPLIT C1 INTO C11,C12;
SPLIT C3 INTO C21,C22;
BLOCK B21;
ENDBLOCK B21;
BLOCK B22;
ENDBLOCK B22;
CHANNEL C11 FROM ENV TO B21 WITH S1;
CHANNEL C12 FROM ENV TO B22 WITH S1;
CHANNEL C21 FROM B21 TO ENV WITH S21;
CHANNEL C22 FROM B22 TO ENV WITH S22;
ENDSUBSTRUCTURE B2;
ENDBLOCK B2;
ENDSYSTEM A;
Descrierea complet a unui sistem presupune
prezentarea att a structurii ct i a modului de funcionare a
componentelor sale. n cazul limbajului SDL, pentru definirea
unitiilor funcionale (dinamice) se utilizeaz conceptul de
proces.
Un proces reprezint un automat extins cu numr finit de
stri, care este ataat unui bloc fr structur intern. Un
bloc poate dispune de mai multe procese. Aceast
flexibilitate a gruprii proceselor (unul sau mai multe n
acelai bloc) este oferit pentru a satisface diversele
necesiti de proiectare. Procesele se pot grupa n blocuri ce
asigur aceleai activiti, realizndu-se astfel minimizarea
numrului lor. O aciune n sens opus, anume segmentarea
pe mai multe blocuri, permite o implementare eficient a
proceselor complexe.

43

Sistem

B1

B2

B3

B31

P2

B32

P322

P322

proces

Figura 2.4. Exemplu de reprezentare grafic

a componenei la nivel de proces.
Apartenena proceselor la blocuri se reprezint ca n
cazul particular precizat n figura 2.4. n funcie de necesiti,
fiecare proces se poate descompune n servicii, care
reprezint i ele tot nite automate extinse cu stri finite. Dar
spre deosebire de procese, care se preseaz unei execuii
paralele, serviciile aparinnd aceluiai proces nu au aceast
libertate, deoarece unul singur dintre acestea se poate afla,
la un moment dat, n execuie.
Deseori, pe parcursul descrierii unui proces pot aprea
pri identice. n acest caz, pentru a simplifica modul de
descriere a procesului, aceste pri comune pot fi incluse
ntr-o procedur definit o singur dat. Reprezentarea
grafic a unei organizri n servicii i proceduri a unei
structuri ipotetice este oferit n figura 2.5.

44

B1
P11

B2
P12

S21

S22
P11

procedur
serviciu

Figura 2.5. Exemplu de reprezentare grafic a unei

organizri n servicii i proceduri.
Un proces (sau serviciu) este alctuit din stri i tranziii
ntre stri. O stare reprezint o anumit situaie n care
procesul este suspendat n ateptarea unui semnal de intrare
(stimul).
Un semnal este o secven de informaii destinat unui
proces. Semnalele pot fi de origine hardware sau software.
Semnalele pot fi externe, cnd comunicaia are loc ntre
procese localizate n blocuri distincte, sau interne n caz
contrar.
C1[S1]

R1[S1]

P31
R2[S31]
P32

C2[S2]
R2[S32, S33]

Figura 2.6. Exemplu de utilizare a rutelor

cuprinse ntr-un bloc.
45

Cile de comunicaie din interiorul unui bloc se numesc

rute. Aceste rute leag procesele la alte procese sau la
canalele conectate la blocul corespunztor (figura 2.6.).
Dac, de exemplu, procesul P31 este descompus n dou
servicii, atunci structura sa intern se reprezint ca n figura
2.7.
P31
R1

RS1

S311

S312

RS2

R2

Figura 2.7. Exemplificarea rutelor n interiorul

unui proces compus din servicii.
Tranziia este o succesiune de aciuni care nsoete
trecerea unui proces dintr-o stare n alta, ca rspuns la o
intrare (stimul) anumit. De exemplu, un proces de
prelucrare apeluri aflat n starea LIBER va tranzita n starea
NUMEROTARE, activnd un generator de ton (prin trimiterea
unui semnal de ieire), i se va pregti pentru recepia
cifrelor, atunci cnd va fi stimulat de semnalul de ANGAJARE
(corespunztor acionrii furcii de comutaie la deschiderea
aparatului chemtor).
Principalele simboluri utilizate n descrierile grafice ale
procesoarelor sunt prezentate n figura 2.8. Semnificaiile
unora dintre acestea au fost deja precizate, rmnnd ca n
continuare s fie explicate i celelalte:

46

DECISION: definete mai multe variante ce pot fi urmate

pe parcursul unei tranziii funcie de rspunsul obinut n
urma verificrii unor condiii.
TASK: definesc orice activiti care se desfoar pe
parcursul unei tranziii ce nu este nici decizie, nici ieire.
SAVE: ofer o metod de punere n rezerv a unui semnal,
cnd procesul se afl ntr-o anumit stare. n acest fel, se
poate amna prelucrarea semnalului pn se ndeplinesc i
alte condiii.
CONNECTOR: este o etichet unic util n cazul n care
un proces este descris pe mai multe pagini.
PROCEDURE: orienteaz parcurgerea descrierii ctre o
procedur precizat n apel.
RETURN: revenirea n punctul de unde procedura a fost
iniiat.
CREATE REQUEST: creeaz o nou instan a procesului
precizat n apel.
STOP: ncheie existena instanei corespunztoare.
Simbol

Denumire
STATE
INPUT
TASK
OUTPUT
DECISION
SAVE
CONNECTOR
PROCEDURE CALL
RETURN
CREATE REQUEST
STOP

Semnificaie
Stare
Intrare
Aciune
Ieire
Decizie
Rezerv pe durata tranziiei
Conector
Procedur de apel
Revenire din procedur
Creaz o instan a unui proces
Finiseaz o instan a unui proces

Figura 2.8. Principalele simboluri SDL.

B. Diagrama de secvene ale mesajelor, MSC
Descrierea funcionrii unui sistem se poate realiza i
prin intermediul diagramelor de secvene ale mesajelor, MSC
47

(Message Sequence Chart). O diagram MSC conine

schimburile de mesaje ntre diversele componente
structurale ale unui sistem. Pentru asigurarea compatibilitii
ntre cele dou limbaje, componentele luate n considerare n
cadrul diagramelor MSC trebuie descrise la nivel static
(structur, ci de comunicaii, semnale, ...) sub form SDL.
Interfa
A
B
B1

S1

S2
S3

S4
B2

Descriere SDL

Interfa
A
S1

B1

Interfa
B

S5
S6

S4

Interfa
B

B2
S2
S3

Descriere MSC

Figura 2.9. Exemplu de diagram MSC.

O diagram MSC se prezint sub forma exemplului din
figura 2.9. Conform acesteia, liniile verticale corespund
diverselor componente (instane) ale modelului (sistem, bloc,
proces, mediu), iar liniile orizontale (eventual oblice)
corespund evenimentelor legate de comunicarea ntre
componentele modelului (semnalul emis sau recepionat,
ruta sau canalul utilizat) sau de iniierea / expirarea unor
temporizatoare. Modul de ordonare pe vertical a liniilor
orizontale trebuie s respecte cronologia evenimentelor luate
n considerare.
Principalele simboluri utilizate n reprezentrile MSC
compatibile LDS sunt prezentate n figura 2.10.
48

Simbol

Denumire
ACTION

Semnificaie
Activitate intern a unei
componente

CONDITION

Stare a unui ansamblu de

componente

COREGION

Interval de timp n care ordinea

evenimentelor nu este strict

MESSAGE

Schimb de informaii ntre dou

componente ale modelului
Creare dinamic a unei instane a
unui proces (serviciu)

PROCESS
CREATION

Finisarea unei instane a unui

proces (serviciu)

STOP

Dezactivarea unui temporizator

TIMER RESET

Iniializarea unui temporizator

creat de o instan a unui proces

TIMER SET

Epuizarea timpului urmrit de

temporizator

TIMER TIMEOUT

Figura 2.10. Principalele simboluri ale reprezentrilor MSC.

C. Limbaje de nivel nalt
Tot din categoria mijloacelor de dezvoltare a software-ului
fac parte i limbajele de nivel nalt. Aceste limbaje au fost
concepute i perfecionate pentru a oferi un cadru mult mai
eficient de programare n comparaie cu limbajele de
asamblare (productivitatea programrii n limbaje de nivel
49

nalt este cu cteva ordine de mrime mai mare dect n

cazul limbajelor de asamblare).
Faptul c, iniial, software-ul de comutaie era scris n
limbaj de asamblare, se datora necesitii de a face
economie de memorie i de timp real de execuie. Ulterior
ns, o serie de factori au orientat definitiv proiectarea de
software ctre utilizarea limbajelor de nivel nalt (CHILL, C+
+). Astfel, scderea preului la memoriile semiconductoare a
eliminat restriciile severe legate de dimensiunea memoriei,
iar nzestrarea compilatoarelor cu posibiliti de optimizare a
codului generat a permis obinerea de programe cu un nivel
de eficien acceptabil.
Ingineria software presupune un ansamblu complex de
activiti. Pentru a se putea desfura n condiii optime,
activitile de rutin care nu in de conceperea, dezvoltarea i
verificarea unui produs software s-au automatizat fiind
ndeplinite de software-uri specializate, cum sunt:
- biblioteca de programe (support library)
nmagazineaz documentele ce aparin la diverse
proiecte de dezvoltare software. Prin documente se
neleg att codurile main ct i fiierele surs.
- administratorul bibliotecii de programe (program
librarian) este interfaa dintre echipa de proiectare
i biblioteca de programe. n aceast ipostaz,
administratorul nfptuiete o serie de funcii
precum: ntreinerea integritii bibliotecii astfel nct
coduri aflate n faza de dezvoltare s nu se
suprapun accidental peste produse finalizate;
nlesnirea controlrii planului de dezvoltare a
produselor software; asigurarea revenirii la etape
anterioare de proiectare.
n prezent, ingineria software dispune de mijloace
deosebit de performante care integreaz mijloacele de
dezvoltare prezentate mai sus. n acest fel, proiectarea se
realizeaz utiliznd, de exemplu, limbaj SDL, iar trecerea n
50

cod surs i generarea de cod main revin n exclusivitate

mediului integrat de lucru.

2.3. Procesarea distribuit

Mediul de procesare reprezint un alt factor important ce
caracterizeaz o anumit arhitectur software. Funcie de
numrul de procesoare implicate i de modul de lucru al
acestora, procesarea se poate desfura serial sau paralel.
Procesarea serial presupune c la un moment dat un singur
procesor se afl n execuie, iar procesarea paralel se
ntlnete n configuraiile n care mai multe procesoare
funcioneaz simultan desfurnd activiti n comun.
Iniial, software-ul de comutaie a utilizat un mediu de
procesare serial. Odat cu creterea volumului de activiti,
viteza de execuie a procesoarelor a devenit ns
insuficient. Ca urmare, o soluie a fost creterea vitezei de
execuie care, ns, implic costuri superioare de fabricaie
i, n plus, este limitat din punct de vedere fizic.
Pentru a depi aceste piedici, s-a trecut la producerea
de software-uri de comutaie ce lucreaz n mediu de
procesare paralel. Aceast soluie ofer rezultate
superioare, mai ales atunci cnd se adopt principiul
diviziunii funcionale a proceselor software. Aceast
diviziune, ce asigur operarea unui sistem ntr-un mediu
distribuit, trebuie ns corelat cu o minimizare a
comunicaiilor (interdependen redus). Altfel, este posibil
ca un sistem distribuit s funcioneze sub capacitatea unui
sistem echivalent cu procesare serial.
2.4. Modelul optim al arhitecturii software

51

Cercetrile efectuate n vederea realizrii unui model

optim de arhitectur software trebuie s in seama de
ansamblul conceptelor ce au fost prezentate pe parcursul
capitolelor 1 i 2. n principal, aceste concepte se refer la:
- procesarea paralel (distribuit),
- sisteme distribuite,
- diviziune funcional, interdependen redus,
ingineria software,
- abstractizarea informaiei.
Att baza de plecare, prin complexitatea sa, ct i
cerinele impuse, prin diversitatea lor, conduc la obinerea
mai multor soluii n problema identificrii unei arhitecturi
software ideale. Una dintre aceste soluii este prezentat n
continuare, la modul principial.
2.4.1. Structura modelului
Un model ideal de arhitectur software pentru comutaie
se poate prezenta ca n figura 2.11.
Procesorul
de servicii

Comenzi

OS
Mesaje

Stri

Rspunsuri
Date

Procesorul
de semnalizri
OS

Date Administratorul Date

bazei de date

Procesorul
de activiti

OS

OS

Date

Semnale

Interfaa cu
periferia

Rspunsuri

OS
HW1 52
......... HWn

Aciuni

Figura 2.11. Exemplu de arhitectur software de comutaie.

n acest caz, structura conine cinci procesoare
specializate pe diverse funcii. Procesoarele i ndeplinesc
funciile n urma stimulrii reciproce, fr ns ca aciunile
implicate de o anumit funcie s fie realizat n cooperare.
Comunicaia ntre procesoare se realizeaz prin intermediul
unor tampoane de mesaje. Informaia permanent a structurii
software este nmagazinat ntr-o unic baz de date i este
accesat de procesoare, prin intermediul administratorului
acesteia. Fiecare component a structurii dispune de o
main i de un sistem de operare ce i sunt proprii (software
prin care se administreaz i se execut programele).
Amnunte suplimentare legate de cele cinci procesoare sunt
prezentate n paragraful urmtor.
2.4.2. Interfaa cu periferia
Interfaa cu periferia reprezint unicul procesor care
comunic direct cu componentele hardware ale sistemului de
comutaie, asigurnd astfel independena total a celorlalte
procesoare fa de caracteristicile hardware ale acestuia. De
aceste caracteristici trebuie s in cont doar interfaa cu
periferia, singura component a software-ului care difer
obligatoriu de la o familie de sistem de comutaie la alta.
Funciile principale ndeplinite de interfaa cu periferia
sunt: manevrarea hardware-ului sub controlul procesorului
de activiti i explorarea terminaiilor (linii sau trunchiuri).
Manevrarea hardware-ului presupune, n principal, recepia
comenzilor de aciune n format logic, convertirea lor n
aciuni fizice concrete i ntiinarea procesorului de activiti
cu succesul / insuccesul aciunii ntreprinse. Astfel, de
exemplu, procesorul de activiti poate cere interfeei cu
53

periferia s conecteze un generator de curent de sonerie la o

linie trimindu-i acesteia, n format logic, identitile liniei i a
generatorului, precum i "coordonatele" ci de legtur ntre
acestea. Pentru a le converti n informaii concrete, proprii
hardware-ului deservit, interfaa cu periferia are nevoie de
informaiile permanente ce i sunt furnizate de administratorul
bazei de date. Dup ce informaia s-a concretizat, interfaa
cu periferia trece la aciune, realiznd conexiunile cerute,
iniiind temporizrile necesare i genernd tensiunile
corespunztoare echipamentului hardware n cauz. Dup
ce toate operaiile legate de respectiva aciune s-au nfptuit,
procesorul de activiti este informat de succesul / insuccesul
aciunii ntreprinse.
Explorarea (scanarea) terminaiilor este a doua funcie
important a interfeei cu periferia. Deoarece terminaiile pot
fi de diverse tipuri, interfaa cu periferia i stabilete modul
de explorare, de la caz la caz, pe baza informaiilor nscrise
n baza de date. Pe msur ce semnalele electrice sunt
recepionate de la echipamentele hardware, interfaa cu
periferia le convertete n semnalizri. n acest mod,
activitile fizice cum sunt "ridicarea" sau "coborrea" furcii
de comutaie a terminalului telefonic, devin semnalizri de
genul ANGAJARE / ELIBERARE ("deschiderea aparatului"
(off-hook) sau respectiv "nchiderea aparatului" (on-hook);
impulsurile electrice sau semnalele bitonale de numerotare
sunt la rndul lor convertite n format binar nainte de a fi
transmise procesorului de semnalizri.
2.4.3. Procesorul de semnalizri
Procesorul de semnalizri este specializat n activitile
de interpretare a semnalizrilor provenite de la interfaa cu
periferia i de generare a mesajelor logice corespunztoare
ctre procesorul de servicii. Interpretarea semnalizrilor se
face funcie de informaiile de stare primite de la procesorul
54

de servicii i de datele permanente intermediate de

administratorul bazei de date. n urma interpretrii,
procesorul de semnalizri genereaz masaje pe baza crora
procesorul de servicii stabilete n ce stare se gsete
terminalul n cauz. Lanul comunicrilor se nchide prin
informarea procesorului de semnalizri cu noua stare a
terminalului.
Ca exemplu, se poate considera situaia n care un
terminal este angajat ntr-o conexiune. n acest caz, din
punct de vedere al procesorului de servicii, terminalul se
gsete n starea logic "conversaie"; aceast stare este
semnalat i procesorului de semnalizri. Din punctul de
vedere al interfeei cu periferia, terminalul se afl n starea
fizic "furca ridicat" (off-hook). Coborrea furcii va fi
sesizat de interfaa cu periferia care va genera
semnalizarea: on-hook. Ca urmare, procesorul de
semnalizare iniiaz un temporizator cu ajutorul cruia
interpreteaz informaia primit. Astfel, dac temporizarea
expir nainte de recepia unui off-hook, atunci se decide c
s-a cerut o deconectare i se informeaz procesorul de
servicii. n caz contrar, se consider c a fost o btaie n
furc (o manevr accidental), care poate avea sau nu o
semnificaie pentru procesorul de servicii.
2.4.4. Procesorul de servicii
Dup cum i spune i numele, procesorul de servicii
controleaz modul de desfurare al serviciilor. Pentru a fi
degrevat de amnuntele legate de activitile concrete
implicate n satisfacerea diverselor servicii, procesorul de
servicii are n vedere doar latura abstract (logic) a
acestora. n acest mod, un serviciu devine pentru procesorul
de servicii un proces care evolueaz n funcie de mesajele
primite de la procesorul de semnalizri i genereaz comenzi
n format logic, ce sunt transmise procesorului de activiti.
55

Informaiile de stare relative la un anumit serviciu

(proces) sunt memorate n baza de date a sistemului. Cu
ajutorul acestora, procesorul de servicii decide ce activiti
trebuie s desfoare un serviciu atunci cnd procesul de
semnalizri trimite un mesaj nou.
2.4.5. Procesorul de activiti
Procesorul de activiti traduce comenzile abstracte (de
genul: conecteaz un generator de ton de disc la terminalul
X) primite de la procesorul de servicii, n serii de aciuni care
trebuie ndeplinite de interfaa cu periferia. Pentru a realiza
cu succes aceast intermediere, procesorul de activiti
trebuie s dein anumite informaii relative la protocoalele
de uz intern adoptate n cadrul sistemului respectiv. Pe baza
acestor informaii, cererile de activitate formulate de
procesorul de activiti devin concrete n ceea ce privete
comanda resurselor hardware, rmnnd abstracte doar n
privina modului de acionare al acestora.
Comunicarea dintre procesorul de servicii, procesorul de
activiti i interfaa cu periferia este bidirecional. n acest
mod, sistemul este nzestrat cu o reacie invers, care
permite verificarea modului n care sunt materializate
comenzile. Astfel, absena unui rspuns indic apariia unei
probleme, pentru a crei rezolvare, se poate reformula
cererea original sau se poate genera o comand de
abandonare a activitilor iniiate i de dezactivare a
componentelor hardware implicate.
2.4.6. Administratorul bazei de date
n principal, administratorul bazei de date are rolul de a
intermedia accesul celorlalte procesoare la baza de date a
sistemului. Deinnd toate detaliile relative la activitile de
preluare din baza de date, precum i de nregistrate n
aceasta, administratorul bazei de date permite celorlalte
56

procesoare s acioneze, fcnd abstracie de modul de

structurare a informaiei. Astfel, o aciune de acces /
nregistrare informaie, ntreprins de un anumit proces, se
rezum doar la o cerere n acest sens.
La baza de date a sistemului poate avea acces i
operatorul uman. n acest caz, administratorul bazei de date
este nzestrat cu o interfa specializat, prin intermediul
creia se pot desfura aciuni de genul: actualizarea
informaiei relative la utilizatori i componentele sistemului,
modificarea caracteristicilor i serviciilor, supravegherea
activitii procesoarelor din sistem, evaluarea gradului de
utilizare al procesoarelor i a memoriei.
Revenind la figura 2.11. se observ c fiecrui procesor i
este dedicat un sistem de operare, OS (Operating System).
Prin sistem de operare se nelege un ansamblu de
programe care coordoneaz activitile unui procesor i
schimburile de mesaje ale acestuia cu restul procesoarelor
din sistem. n plus, un sistem de operare asigur i
independena software-ului de maina gazd.
Aplicaii
Sistemul
de operare
Main
fizic

Figura 2.12. Poziia sistemului de operare

n cadrul unei arhitecturi software.
Aceast independen se creeaz prin interpunerea
sistemului de operare ntre aplicaiile componentelor ce
57

alctuiesc software-ul de comutaie i maina gazd (figura

2.12.).
Astfel, software-urile devin portabile, adic pot lucra pe
diverse configuraii concrete (cu procesare serie sau
paralel), fr a fi necesar modificarea lor.
Sistemele de operare pot oferi i afte funcii. Printre
acestea se pot enumera: monitorizarea traficului, observarea
gradului de utilizare a mainii gazd i introducerea de
programe elaborate local n ansamblul software-ului cu care
este nzestrat sistemul, verificarea i decuplarea acestora n
cazul n care se constat o degradare a calitii serviciului n
cauz.
n concluzie, arhitectura unui software de comutaie
depinde de un ansamblu complex de factori ce in att de
progresele tehnologice i conceptuale nregistrate n
domeniile
adiacente
(proiectarea
i
producerea
componentelor electronice, ingineria software, ...), ct i de
obiectivele asumate.
n cazul modelului prezentat, principalele obiective au
fost:
- creterea semnificativ a vitezei de lucru i a
capacitii unui sistem de comutaie;
- portabilitatea software-ului;
- simplificarea metodologiei de dezvoltare i testare a
software-ului.
Aceste obiective au fost atinse, n principal, prin:
- utilizarea unui mediu distribuit de procesare;
- eliminarea
dependenei
software-ului
de
infrastructura hardware concret i de modul de
prezentare a informaiei;
- modularizarea software-ului;
- reducerea interdependenei ntre module.
2.5. Evaluarea produselor software
58

Analiza, proiectarea, implementarea, testarea i

ntreinerea aplicaiilor software ce sunt utilizate n diferite
domenii de activitate, de la operaiuni bancare i pn la
funcionarea sistemelor n timp real din industria nuclear
sau aerospaial, reprezint un intens efort de inteligen
asistat de unul organizatoric i financiar; aceste eforturi sunt
de dimensiuni apreciabile i aflate ntr-o continu cretere,
ca pondere n totalul resurselor umane i materiale utilizate.
n vreme ce tehnica de calcul devine din ce n ce mai
performant ca urmare a utilizrii tehnologiilor de vrf (prin
miniaturizare i ieftinire), la elaborarea i ntreinerea
aplicaiilor software, n special a celor complexe, resursele
consumate ajung s reprezinte 70 - 80 % din costul total al
sistemului (hardware i software) i chiar cu posibilitatea de
cretere pn la 90 % n unele cazuri.
2.5.1. Parametrii evalurii software-ului
Volumul mare al activitii necesare pentru a dezvolta i
ntreine programele (i deci implicit nivelul nalt al costurilor
asociate), justific interesul din ce n ce mai larg pentru
asigurarea unei caliti corespunztoare aplicaiilor precum i
minimizarea costurilor de elaborare a acestora. Sunt utilizate
metode i instrumente adecvate analizei n detaliu a
cerinelor software i de elaborare sau testare a programelor,
ce asigur un minimum de erori admisibile i o productivitate
ct mai mare.
Aceste aspecte specifice ce nsoesc elaborarea
programelor, au determinat renunarea la conceptul de
programare "artistic", dup instinct i imaginaie i au dat
natere unor ncercri de abordare sistemic a problematicii
elaborrii aplicaiilor, conducnd n mod firesc la formularea
unor noi concepte, principii, metode i instrumente de
construire a programelor, cunoscute i sub denumirea de
inginerie software. Ingineria software urmrete n esen
59

rezolvarea unor probleme specifice legate de analiza,

proiectarea, implementarea, testarea i ntreinerea
programelor i anume:
- Stabilirea etapelor i a sub-etapelor prin care trece
secvenial un produs software pe durata ciclului su
de via, definirea coninutului acestor sub-etape
precum i a parametrilor de demarcare ntre subetapele i etapele succesive.
- Abordarea formal prin elaborarea unor metode
riguroase i a unor instrumente asociate acestora,
destinate asistrii proiectrii produsului software.
Ele trebuiesc adaptate diferitelor sub-etape din
ciclul de via ale unui program, diferitelor tipuri de
programe precum i complexitii variate a
programelor ce se realizeaz.
- Elaborarea unor proceduri clare de organizare i
conducere a diferitelor activiti legate de realizarea
programului (calitate, performan). Obiectivul final
al ingineriei software este trecerea de la o activitate
de elaborare a programelor, n care domin stilul
artizanal, de intuiie i improvizaie, de creaie tip
"art a programrii" la o activitate sistematic care
s asigure - aa cum am mai subliniat - nalta
calitate a programelor i un cost ct mai sczut al
elaborrii i ntreinerii acestora. Ingineria software
se refer la utilizarea n mod riguros, sistematic i
cu profesionalism a unor metode i instrumente
software adecvate, avnd n vedere anumite
obiective i principii de baz.
- Rentabilitatea economic a procesului de
dezvoltare software este un criteriu din ce n ce mai
impus de ctre managerii financiari, reprezentnd
un aspect critic al activitii de dezvoltare a
proiectelor. n definitiv, obiectivul final al oricrei
companii
interesate
n
dezvoltarea
i
60

comercializarea produsului su informatic a fost i

va rmne profitul. n concurena slbatic de pe
pia unde se nfrunt "montri sacri" precum
Microsoft, IBM, Sun si n care sunt aruncate n lupt
resurse materiale i umane de proporii uriae
interesul este lansarea pe pia ct mai repede i la
costuri sczute a unor aplicaii ct mai performante
care s le "bat" pe cele ale concurenei. Prin
urmare "fereastra de lansare" - intervalul dup care
un nou produs risc s piard piaa datorit
concurenei unor versiuni mai evoluate, se
ngusteaz n mod dramatic, evolund n timp de la
civa ani n trecut la doar un an sau chiar cteva
luni n prezent. Aceste presiuni permanente din
partea managerilor financiari, oblig echipele de
programatori s aplice noi metode de producie, ct
mai moderne.
Ciclul de via al produsului software poate fi exprimat
prin procentul de timp alocat fiecrei etape din procesul de
dezvoltare. Un exemplu tipic ar fi urmtorul:
- Analiza cerinelor: 7 %
- Elaborarea specificaiilor pentru programe: 12 %
- Proiectarea programelor: 21 %
- Implementarea programelor: 20 %
- Instalarea i testarea programelor: 40 %
Pentru a nvinge concurena, produsele trebuie s coste
ct mai puin, s fie de calitate i s apar pe pia ct mai
repede. Acest obiectiv se poate atinge doar printr-o abordare
organizat, planificat, a procesului de dezvoltare. Unul din
primii pai realizai atunci cnd se ia decizia de elaborare a
unui nou program este evaluarea calitativ i cantitativ a
acestuia pentru a stabili n mod corect necesarul de resurse
umane, materiale i de timp. Iat n continuare o descriere a
celor mai recente metode de evaluare, impuse pe scar
larg. Atenia se va concentra n special asupra metodelor de
61

evaluare dimensional i funcional, acestea fiind cel mai

des utilizate datorit performanelor lor.
2.5.2. Metode de evaluare
Produsul software poate fi evaluat n mod direct fie
indirect. Prin evaluarea direct a procesului de inginerie
software se nelege determinarea costurilor i a eforturilor
asociate. Ea presupune calculul numrului liniilor de cod
(LOC - lines of code) scrise, determinarea vitezei de
execuie, a dimensiunii memoriei, precum i a numrului de
defecte raportat ntr-un anumit interval de timp.
Evaluarea indirect a produsului reprezint n fapt o
analiz a funcionalitii, calitii, complexitii, eficienei,
fiabilitii, ntreinerii i multor altor caracteristici.
Costul i efortul necesar pentru a dezvolta software,
calculul numrului de linii de cod (LOC) precum i alte
estimri directe sunt relativ uor de estimat iniial. Totui,
calitatea i funcionalitatea sau eficiena i ntreinerea sunt
mult mai dificil de evaluat i pot fi msurate doar n mod
indirect. Metodele de evaluare ale produsului pot fi descrise
dup cum urmeaz:
Evaluarea productiv se concentreaz asupra
rezultatelor finale ale procesului de inginerie software;
Evaluarea calitativ ofer o indicaie a ct de aproape
este produsul software de cerinele implicite i
explicite ale clientului;
Evaluarea
tehnic
evideniaz
mai
degrab
caracteristicile produsului software (ex.: complexitatea
logic, gradul de modularizare) dect procesul prin
care acesta a fost dezvoltat;
Evaluarea dimensional este utilizat pentru a
"colecta" evalurile directe ale rezultatelor i calitii
procesului de inginerie software;
Evaluarea funcional ofer o evaluare indirect;
62

Evaluarea orientat pe resursele umane ofer

informaii asupra modului n care programatorii
dezvolt un produs software precum i asupra
percepiei eficienei instrumentelor i modelelor de
dezvoltare.
n continuare vom face o abordare detaliat a dou dintre
metodele de evaluare expuse ce sunt mai frecvent utilizate
de ctre casele de soft.
2.5.2.1. Metoda evalurii dimensionale
Evaluarea dimensional a produsului software reprezint
o estimare direct a acestuia precum i a procesului prin
care el este dezvoltat. Dac un manager de proiect menine
nregistrri simple, poate fi creat un tabel cu datele ordonate
dup criteriul dimensiunii. Pentru fiecare proiect, datele
dimensionale uzuale sunt:
efortul estimeaz necesarul de resurse umane i se
msoar n programatori-pe-lun sau programatoripe-an;
KLOC (Kilo Lines of Code) - mii de linii de cod;
valoarea este exprimarea bnesc a efortului;
pagini de documentaie;
numrul de erori raportate de utilizatori ntr-o perioad
de timp (de pild un an).
numrul de programatori care au lucrat la dezvoltarea
produsului software.
Din datele primare coninute ntr-un astfel de table, poate
fi realizat o evaluare a productivitii i una a calitii,
orientate dimensional, pentru fiecare proiect n parte:
Productivitatea = KLOC / Programatori-pe-lun
Calitatea = Numr de erori / KLOC
63

n completare, pot fi calculai ali parametri interesani:

Cost = Valoare / KLOC
Documentaie = Pagini de documentaie / KLOC
Utilizarea parametrilor dimensionali (KLOC, efort, etc.)
este controversat i ei nu sunt universal acceptai ca
reprezentnd cea mai bun metod de evaluare a procesului
de dezvoltare software. Controversa se nvrte n jurul
utilizrii liniilor de cod LOC ca mrime principal. Susintorii
variabilei LOC afirm c aceasta este un artefact al tuturor
proiectelor de dezvoltare software i poate fi uor calculat,
c multe modele de estimare utilizeaz LOC sau KLOC ca
date de intrare principale i c exist deja o literatur imens
(plus date asociate) dedicat LOC. Pe de alt parte,
opozanii reclam c variabila LOC este dependent de
limbajul de programare, c LOC poate penaliza programe
bine proiectate dar scurte, c nu se poate asocia uor
limbajelor neprocedurale i c utilizarea ei n estimare
necesit un nivel de detaliere care poate fi dificil de obinut
(ex: managerul de proiect trebuie s estimeze numrul de
linii de cod ce trebuie produse cu mult nainte ca analiza i
proiectul programului s fi fost ncheiate).
2.5.2.2. Evaluarea funcional
Parametrii ce caracterizeaz din punct de vedere
funcional produsul software reprezint o evaluare indirect a
acestuia i a procesului prin care el este dezvoltat. Evitnd
calculul LOC, parametrii funcionali se concentreaz asupra
"funcionabilitii" sau "utilitii" programului. Acest tip de
evaluare a fost propus pentru o abordare prin msurarea
productivitii, numit metoda scorului funcional. Scorul
funcional (SF) este obinut utiliznd o relaie empiric bazat
pe estimri calculabile ale domeniului de informaie al
produsului precum i pe evaluri ale complexitii aplicaiei.
64

Valorile domeniului de informaie se definesc n urmtorul

mod:
Numrul de intrri a utilizatorului: fiecare intrare a
utilizatorului care furnizeaz aplicaiei date distincte
orientate ctre aceasta este luat n calcul. Intrrile
vor trebui distinse de interogri, care sunt calculate
separat.
Numrul de ieiri a utilizatorului: fiecare ieire ctre
utilizator, care furnizeaz acestuia informaii orientate
ctre aplicaie, este luat n calcul. n acest context
termenul "ieire" se refer la rapoarte, ecrane, mesaje
de eroare, etc. Datele individuale ale unui raport nu
sunt calculate separat.
Numrul de interogri a utilizatorului: o interogare este
definit ca o intrare on-line ce are drept rezultat
generarea unui rspuns imediat al aplicaiei sub forma
unei ieiri on-line. Fiecare interogare distinct este
luat n calcul.
Numrul de fiiere: fiecare fiier logic de tip "master",
cum ar fi o colecie logic de date care poate fi parte a
unei baze de date largi sau a unui fiier individual,
este luat n calcul.
Numrul de interfee externe: toate interfeele citibile
de ctre main (fiiere de date pe band sau disc
dur) care sunt utilizate pentru a transmite informaii
ctre alt sistem sunt luate n calcul.
Odat ce datele de mai sus au fost colectate, un indice
de complexitate este asociat fiecrui calcul. Organizaiile
care utilizeaz metoda scorului funcional dezvolt criterii
pentru a stabili faptul dac o anumit intrare este simpl,
medie sau complex. Bineneles, determinarea complexitii
este un proces relativ subiectiv. Pentru a calcula scorul
funcional, este utilizat urmtoarea relaie:
65

SF = totalul-de-calcul * 0,65 + 0,01 * SUM (Fi),

(2.1.)

unde
totalul-de-calcul este suma rezultatelor pariale obinute prin
ponderarea valorilor domeniului de informaie.
Valorile constante din ecuaia de mai sus precum i
factorii de influen care sunt aplicai calculului domeniului de
informaii sunt determinai empiric.
Valorile de ajustare a complexitii (F i, I = 1...14) se
determin evalund influena a 14 factori:
1. Necesit sistemul back-up i recovery?
2. Sunt necesare faciliti de comunicaii de date?
3. Sunt necesare funcii de procesare distribuit?
4. Este criteriul performanei critic?
5. Va rula sistemul ntr-un mediu operaional utilizat
intens?
6. Necesit sistemul intrri de date n regim on-line?
7. Necesit sistemul de intrri de date n regim on-line,
ca procesul de introducere al datelor s aib loc pe
ecrane sau prin operaiuni multiple?
8. Sunt fiierele actualizate on-line?
9. Sunt intrrile, ieirile i interogrile complexe?
10. Este procesul intern complex?
11. Este codul proiectat astfel nct s fie reutilizat?
12. Sunt conversia i instalarea programului incluse n
design?
13. Este sistemul proiectat pentru instalri multiple n
organizaii diferite?
14. Este aplicaia proiectat astfel nct s faciliteze
modificarea i uurina n utilizare din partea
beneficiarului?
Fiecare factor este evaluat cu o not de la 0 la 5, avnd
semnificaiile:
0 Nu influeneaz;
1 Incidental;
66

 2 Moderat;
3 Mediu;
4 Semnificativ;
5 Esenial.
Odat ce scorul funcional a fost calculat, el este utilizat
ntr-o manier asemntoare cu metoda LOC ca o msur a
productivitii, a calitii i a altor atribute ce definesc
programul:
Productivitatea = SF / Programatori-pe-lun
Calitatea = Numr Defecte / SF
Costul = Valoare / SF
Documentaia = Pagini de Documentaie / SF
Evaluarea pe baza scorului funcional a fost conceput
iniial pentru a putea fi utilizat n sistemele de informaii
pentru afaceri. Totui, extinderea propus ulterior, denumit
scor caracteristic (SC), poate permite aplicarea acestei
metode i n cazul programelor din domeniul sistemelor
inginereti, i de telecomunicaii. Scorul caracteristic este
adecvat descrierii aplicaiilor n care complexitatea
algoritmilor este nalt. Aplicaiile n timp real, de control al
proceselor precum i cele orientate spre obiecte au tendina
de a avea o complexitate algoritmic mare i sunt prin
urmare potrivite evalurii prin metoda scorului caracteristic.
Pentru a calcula acest scor valorile domeniului informaional
sunt din nou contorizate i ponderate. Spre deosebire de
calculul scorului funcional, scorul caracteristic ia n
considerare nc un domeniu de informaie (algoritmi), iar
valorile de ponderare sunt fixe. Valoarea scorului
caracteristic final se obine din ecuatia:
SC = totalul-de-calcul * 0,65 + 0,01 * SUM (Fi),

(2.2.)

De remarcat c scorul caracteristic ia n considerare o

nou dimensiune a soft-ului, i anume algoritmii. Inversarea
unei matrici, decodificarea unui ir de bii sau tratarea unei
67

ntreruperi sunt toate exemple de algoritmi. Trebuie de

asemenea remarcat c scorul caracteristic i cel funcional
semnific acelai lucru, i anume "funcionalitatea" sau
"utilitatea" furnizate de ctre software. n fapt, amndou
evaluri au drept rezultat aceeai valoare a SF-ului n situaia
calculului ingineresc convenional sau a aplicaiilor de tip
gestiune a informaiilor. Pentru sistemele n timp real, mult
mai complexe, scorul caracteristic este adesea cu 20 35 %
mai mare dect cel calculat prin utilizarea n exclusivitate a
scorului funcional. Utilizarea scorului funcional - sau a celui
caracteristic - este controversat.
Susintorii ideii susin c SF (SC) este independent de
limbajele de programare, aceasta fcndu-l ideal pentru
aplicaii scrise n limbaje convenionale i neprocedurale. Ei
susin de asemenea c el este bazat pe date ce se presupun
a fi cunoscute mult anterior n evoluia proiectului, fcnd SF
(SC) mult mai atractiv ca estimare. Pe de alt parte,
oponenii ideii declar c metoda necesit puin
prestidigitaie i c realizarea calculului se face n parte pe
baza unor date mai degrab subiective dect obiective; ei
mai cred c informaiile pot fi dificil de strns "dup ce
evenimentele au avut loc" i c SF (SC) nu are o semnificaie
fizic direct - el este doar un simplu numr.
2.5.2.3. Tehnici de decompoziie
Oamenii au dezvoltat o abordare natural n rezolvarea
problemelor: dac problema ce urmeaz a fi rezolvat este
prea complicat, avem tendina s o divizm ntr-o serie de
sub-probleme pn cnd ajungem la un nivel la care subproblemele pot fi soluionate. Rezolvm apoi pe rnd fiecare
dintre sub-probleme n sperana c soluiile pot fi combinate
pentru a forma o soluie global. Estimarea proiectului
software este o form de rezolvare a problemei, iar n
majoritatea cazurilor, problema ce trebuie rezolvat (ex:
68

dezvoltarea unei estimri de efort i cost pentru un proiect

software) este mult prea complex pentru a fi considerat ca
un tot ntreg. Din acest motiv descompunem problema, o
redefinim ca pe o colecie de sub-probleme cu o
complexitate mai redus i deci, sperm, mai "rezolvabile".
Anterior am definit liniile de cod i scorul funcional drept
date iniiale de la care pornindu-se poate fi calculat
productivitatea. Datele LOC i SF sunt utilizate n dou
moduri pe parcursul estimrii proiectului software:
ca variabil de estimare ce este utilizat pentru a
"dimensiona" fiecare element al software-lui;
msurtori de baz colectate de la vechile proiecte i
utilizate n conjuncie cu variabilele de estimare pentru
a dezvolta estimrile de efort i cost.
Estimrile LOC i FP sunt tehnici de estimare distincte.
Totui amndou au un numr de caracteristici comune.
Managerul de proiect ncepe prin a prezenta o descriere
sintetic a funciei finale a software-lui i, pornind de la
aceast declaraie, ncearc s descompun proiectul
viitorului produs informatic n mici subfuncii care pot fi
estimate fiecare individual. Variabila de estimare LOC sau
SC este apoi calculat pentru fiecare sub-funcie.
Msurtorile de baz ale productivitii (ex: LOC /
programatori-pe-lun sau SC / programatori-pe-lun) sunt
apoi aplicate celei mai potrivite variabile de estimare i este
derivat efortul sau costul subfunciei. Estimrile subfunciei
sunt combinate n scopul de a furniza o estimare global
pentru ntregul proiect. Tehnicile de estimare LOC i SC
difer la nivelul de detaliere necesar pentru decompoziie.
Atunci cnd LOC este utilizat ca variabil de estimare,
decompoziia funcional este absolut esenial i este
adesea dus la nivele considerabile de detaliere, deoarece
datele cerute pentru estimarea scorului funcional sau mai
mult macroscopice, nivelul de decompoziie atunci cnd SC
este utilizat ca variabil de estimare este considerabil mai
69

puin detaliat. Ar trebui de asemenea luat n considerare

faptul c LOC este estimat direct n timp ce SC este
determinat indirect prin estimarea numrului de intrri, ieiri,
fiiere cu date, interogri i interfee externe ct i a celor 14
valori de ajustare a complexitii descrise anterior.
Independent de variabila de estimare care este utilizat,
managerul de proiect ofer n mod uzual un domeniu de
valori pentru fiecare funcie descompus n subfuncii.
Utiliznd date istorice sau intuiia (atunci cnd orice alt
metod d gre), managerul de proiect estimeaz o valoare
LOC sau SC pentru fiecare funcie, n cazul cel mai optimist,
cel mai probabil i cel mai pesimist. O indicaie implicit a
gradului de incertitudine este furnizat atunci cnd este
specificat o gam de valori.
Se calculeaz apoi o valoare ateptat pentru LOC i SC.
Valoarea ateptat pentru variabila de estimare E poate fi
calculat printr-o mediere a estimrilor LOC sau SF n
cazurile optimist (a), probabil (m) i pesimist (b).
De exemplu, estimarea E = (a + 4m + b) / 6 d cea mai
mare credibilitate estimrii celei mai probabile (m) i
urmeaz o distribuie de tip beta a probabilitii. Presupunem
c exist o foarte mic probabilitate ca LOC curent sau
rezultatele SF s se afle n afara intervalului definit de
valorile estimate n cazul optimist sau pesimist. Utiliznd
tehnici statistice standard putem calcula estimrile. Totui, va
trebui notat c o abatere bazat pe date incerte (estimate)
trebuie utilizat judicios. Odat ce valoarea ateptat E
pentru variabila de estimare a fost determinat, sunt utilizate
productivitile LOC i SC. La acest moment, managerul de
proiect poate aplica una sau dou abordri diferite:
1. Valoarea variabilei de estimare total pentru toate
subfunciile poate fi multiplicat cu productivitatea
medie corespunztoare acelei variabile de estimare.
De exemplu, dac presupunem c este estimat un
scor funcional total de 310 SF i c productivitatea
70

este calculat pe baza relaiei SF / programatori-pelun avnd valoarea 5,5, atunci efortul total al
proiectului este:
Efort = 310 / 5,5 = 56 programatori-pe-lun
2.

Valoarea variabilei de estimare pentru fiecare

subfuncie poate fi multiplicat printr-o valoare
ajustat a productivitii bazat pe nivelul de
complexitate estimat pentru fiecare subfuncie.

71

BIBLIOGRAFIE
1. Niculescu Grazziela. Tehnici i sisteme de comutaie.
Bucureti, Editura Matrix Rom: 2007.
2. tefnescu Ion. Proiectarea logic a sistemelor
decizionale hardware i software. Aspecte de baz.
Bucureti, Editura Matrix Rom: 2006.
3. .. .
, -: 2006.
4. Rdulescu Tatiana. Reele de telecomunicaii.
Bucureti, Editura Thalia: 2005.
5. .. . , : 2003.
6. .. .
, -: 2003.
7. Niculescu Grazziela. Analiza i modelarea sistemelor de
comunicaii. Bucureti, Editura Matrix Rom: 2002.
8. Rdulescu Tatiana. Ingineria software orientat pe
obiecte. Bucureti, Editura Matrix Rom: 2000.

72

Cuprins
INTRODUCERE

Capitolul 1. Proiectarea software-ului

de comutaie
1.1. Cerine n proiectarea software-ului de comutaie
1.2. Suportul software-ului de comutaie
1.2.1. Viteza procesorului
1.2.2. Organizarea memoriei
1.2.3. Conceperea codului i programului
1.3. Software clasic de comutaie
1.3.1. Programul generic
1.3.1.1. Prelucrarea apelurilor
1.3.1.2. Funcii de ntreinere i administrare
1.3.2. Organizarea bazei de date
1.4. Software de comutaie telefonic
1.4.1. Arhitectura software
1.4.2. nlnuirea programelor
1.4.3. Deficienele software-ului
de comutaie telefonic

5
7
8
10
11
13
14
14
22
24
27
27
29
31

Capitolul 2. Software-ul modern de comutaie

2.1. Noiuni i termeni din domeniul
software-ului modern de comutaie
2.2. Elementele ingineriei software
2.2.1. Structura software-ului
2.2.2. Metodologia de dezvoltare
2.2.3. Mijloace de dezvoltare
2.3. Procesarea distribuit
2.4. Modelul optim al arhitecturii software
2.4.1. Structura modelului
2.4.2. Interfaa cu periferia
2.4.3. Procesorul de semnalizri
73

34
35
36
37
38
50
50
51
52
53

2.4.4. Procesorul de servicii

2.4.5. Procesorul de activiti
2.4.6. Administratorul bazei de date
2.5. Evaluarea produselor software
2.5.1. Parametrii evalurii software-ului
2.5.2. Metode de evaluare
2.5.2.1. Metoda evalurii dimensionale
2.5.2.2. Evaluarea funcional
63
2.5.2.3. Tehnici de decompoziie
BIBLIOGRAFIE

54
55
55
57
58
61
62
67
71

74