Crearea Unui Sistem de Telefonie Mobila In Baza Tehnologiei Corba

CUPRINS

Întroducere 7

1. Ce trebuie de știut pentru a opera cu CORBA 9

1.1. Limbajul IDL 9

1.2. Ce prezintă baza Client-Server 23

1.3. Cum se creează CORBA-aplicații 26

2. Implementarea în rețeaua de telefonie mobilă 31

3. Emularea in Delphi 5.5 a interacțiunii sota-telefon în baza tehnologiei CORBA 33

3.1. Prezentarea proiectului 33

3.2. Sota 33

3.3. Telefonul 34

3.4. Interacțiunea sotă-telefon 35

4. PARTEA ECONOMICĂ 38

4.1. Etapele cercetării științifice 38

4.2. Planificarea rețea pentru crearea softului 38

4.3. Calculul economic 43

5. PROTECȚIA MUNCII LA ÎNTREPRINDERE 46

5.1. Aprecierea pericolului și soluționarea problemelor de protecție a mediului ambiant 46

5.2. Calcularea protecției “legare la nul” 50

5.3. Securitatea antiincendiară 51

5.3.1. Cauzele apariției incendiilor 52

5.3.2. Mijloacele de stingere a incendiilor 53

5.3.3. Securitatea antiincendiară în sălile de calcul 54

5.3.4. Măsurile profilactice de luptă cu cauzele incendiului în sălile de calcul 55

5.4. Analiza condițiilor de muncă și factorii dăunători și periculoși la locul de muncă 58

5.4.1. Cerințele securității tehnice la începutul lucrului 60

5.4.2. Cerințele securității tehice în timpul lucrului 60

5.4.3. Cerințele ergonomice privind locul de muncă 60

Concluzii 63

Bibliografia 64

Anexa 1. ” Textul fișierelor pentru aplicația client” 66

Anexa 2. “Textul fișierelor pentru aplicația server de obiecte CORBA” 70

Anexa 3. “Textul fișierelor cu modulul CORBA pentru aplicația server” 75

Anexa 4. “Codul obiectului CORBA” 81

Întroducere

Orice construcție are nevoie mai întâi de o bază. Aceasta nu e teoremă ci o axiomă. Și pentru că de cum a fost pusă baza depinde viitorul construcției, proiectului, iedei sau în genere viitorul, este nevoie de a avea și folosi o informație: necesară, corectă, utilă, completă și la timp. Din acest punct de vedere, pot spune că Informația este ca o materie primă. Atunci Tehnologia Informațională este modul și forma informației. Dacă DNK, de exemplu, conține informație, atunci în rezultatul unei tehnologii informaționale sau modului de citire/înscriere, prelucrare și transportare a acestei informații primim orice organism cât de complex. În acest context, domeniul tehnologiilor informaționale pretinde a fi o baza logică.

Deci, specia umană, dotată cu rațiune, odată cu dezvoltarea tehnologiilor microelectronice, dezvoltă și capitolul corespunzător din TI în scopul îmbunătățirii parametrilor: viteza, calitate-cantitate și alți parametri secundari specifici. Astfel apar noi algoritmi de procesare a informației, care ținând cont de progresul tehnicii de calcul, tind a fi superiori celor precedenți și în același timp a satisface cerințele și standardele.

Astfel, o tehnologie nouă modernă, trebuie să asigure:

accesibilitate și menținerea tuturor standardelor posibile (sau cele mai răspândite în scopul interacțiunii dintre soft-hardul diferitor producători);

viteză – calitate;

independență de platformă;

implementarea în rețea;

procesarea unui volum mare de informație și securitatea ei;

cost redus, cheltuieli minime, instalare rapidă;

durată maximă de funcțiune cu posibilitate de autocontrol și autoreglare; rezolvarea rapidă a problemelor apărute din cauza progresului și/sau din cauza defectelor hard-soft posibile.

Lider și posesor al acestor calități, ca de altfel și a altor, neenumerate aici, este tehnologia CORBA

Despre CORBA. CORBA (Common Object Request Broker Architecture) prezintă o tehnologie orientată pe obiecte pentru crearea și menținerea sistemelor programate ramificate. Termenul “tehnologie” include arhitectura sistemei și standardele pentru interfețele programate între componentele ei aparte. Arhitectura OMA (Object Management Architecture) a fost publicată în 1992 și de atunci a suferit doar mici modificări. Standardele se dezvoltă activ și se completează în fiecare an.

Cu dezvoltarea CORBA conduce OMG (Object Management Group), care numără mai mult de 800 companii industriale și de calculatoare. Documentele elaborate de ei (standardele și descrierile lor) sunt deschise în Internet pentru toți doritorii.

Deosebirea profitabilă CORBA de alte tehnologii este implementarea în baza ei a independenței de infrastructură, de protocoale de rețea, sisteme de operare, limbaje de programare și de producătorii limbajelor de programare. Deviza OMG: “Tehnologia pe obiecte, capabilă să unească tot pământul”.

Arhitectura de bază este ORB (Object Request Broker) prezintă un component de program (un set de demoni/servisuri și/sau biblioteci dinamice) ce joacă rolul de intermediar între interacțiunea sistemelor aparte. CORBA doar descrie standardul la Broker, de realizarea lui se ocupă diferite firme de programe. Dintre cei mai cunoscuți brokeri – Visibroker (Borland/Inprice), Orbix (Iona), M3 (BEA), ORB+(HP).

Cu ajutorul servisurilor Brokerul de cereri obiect ia asupra lui funcții principale ca menținerea securității, urmărirea tranzacției la integritate, găsirea obiectului necesar, sincronizarea timpului, mecanismul licență, etc.

Pentru descrierea standardelor a fost creat un limbaj special IDL (Inteface Definition Language).

Alt limbaj popular CORBA – OMG-UML (Unified Modelling Language) este folosit la descrierea și cercetarea programelor sistem ramificate cu ajutorul diagramelor speciale.

CORBA este folosit activ mai ales din momentul standardizării protocolului IOOP (Internet Inter ORB Protocol), cu ajutorul cărui componentele pot interacționa prin Internet. Prin acest protocol mai interacționează și noduri, în care sunt instalați Borkeri ai diferitor producători.

CORBA devine tehnologia lider în domeniul programelor de legătură sau moddleware.

1. Ce trebuie de știut pentru a opera cu CORBA

1.1. Limbajul IDL

Folosind obiectele și componentele a apărut necesitatea de a crea un așa limbaj de programare, care va putea descrie orice obiect sau component. Și această descriere trebuie să fie aceiași pentru toate platformele. Programiștii au răspuns la această întrebare cu limbajul de descriere a interfețelor IDL (Interface Description Language). Astăzi, de dezvoltarea IDL se ocupă OMG (Object Management Goroup), care mai urmărește tehnologia CORBA și limbajul UML.

IDL este nu pur și simplu limbaj, ci și un instrument, cu ajutorul căruia se poate salva metainformația despre obiecte, adică datele despre cum el este construit. Sunt cunoscute cazuri când IDL se folosește pentru descrierea contractelor – parametrilor tehnici, ce permit câtorva grupe independente să lucreze în același timp asupra diferitor părți ale unui proiect. Deși codul sursă IDL servește ca “materie primă” din care compilatoarele lui generează coduri sursă în unul din limbajele de nivel înalt. Acest proces îl vom numi translare. Procesul tipic de creare a aplicațiilor bazate pe obiecte se împarte în: descrierea obiectelor în IDL, translarea lor în unul din limbajele de programare, adăugarea stratului business-logic și compilarea codurilor sursă primite în module gata de lansare.

Înainte de a face cunoștință cu însăși limbajul IDL, translarea și construcția lui, să concretizăm unii termeni cu care vom opera în continuare:

Modul – un bloc definit cu un nume, care leagă logic construcțiile limbajului IDL; modulul se mai poate porecli ca pachet (package) în limbajul Java sau spațiu de nume (namespace) în limbajul C++;

Interfață – set de atribute și operații ale obiectului, cu ajutorul cărora consumatorul se poate adresa obiectului;

Atribut – descrie o oarecare calitate a obiectului; se poate de comparat cu variabilă internă a unei clase;

Operație – îndeplinește operații, legate de destinația funcțională a obiectului; se poate compara cu metoda clasei.

Comentariile. Copia perfectă a comentariilor în C++.

Exemplu:

/* acest text se omite de compilator pentru că el este comentat */

… textul dat va fi luat drept cod sursă

// rândul dat se va omite

Identificatori – sunt niște nume cu care lucrează progmamatorul. Acestea pot fi nume de interfețe, de module, de atribute, de operații etc. Pentru orice compilator IDL identificatorul este o succesiune de litere și cifre, și semnul sublinierii ‘_’. Dar toți trebuie să înceapă cu un simbol literal. Datorită unor specializări, diferite IDL compilatoare reacționează diferit la încălcarea acestei reguli.

Daca vom scrie, de exemplu:

attribute Object #x;

attribute Object &_x;

attribute Object 3x;

atunci compilatorul IDL2JAVA, din setul Inprise VisiBroker va genera mesajul că simbolurile găsite nu corespund cu cele așteptate. Dar idltojava din JDK 1.2 va spune, că este o greșeală sintactică, și se va “îneca” îndată după primul rând cu eroare.

Compilatorul IDL nu face deosebire dintre majuscule și minuscule, deci numele complet diferite:

attribute string MyName;

attribute string MYNaME;

vor fi recunoscute ca unul și același nume, și evident se va genera mesajul de eroare ce va declara că se încearcă de a redenumi identificatorul MyName. Faptul dat se justifică prin aceea că translând fragmentul dat în diferite limbaje de programare, unele din ele ce nu fac deosebirea dintre registrul caracterelor, nu vor putea deosebi numele între ele.

Numele poate începe cu simbolul ‘_’. Dar foarte des la translarea IDL (să zicem în Java), compilatorul singur adaugă în fața identificatorilor primiți aceste simboluri de subliniere, pentru a evita conflicte între nume, și identificatorii ce încep cu ‘_’ pot da naștere erorilor. Drept exemplu compilatorul idl2java din VisiBroker “nu vede” diferența dintre două nume ce se deosebesc doar prin sublinierea în față, și

void getSomething(in Object param);

void _getSomething(in Object param);

va genera eroarea despre încercare de a redenumi numele getSomething. Alte compilatoare pot reacționa altfel.

Cuvinte cheie sau set rezervat de cuvinte IDL. Aici registrul caracterelor este important. Deci Module în loc de module va genera eroare.

Tab. 1.

IDL cuvinte rezervate:

Literali. În IDL deosebim literali booleeni, simbolici “înguști” ți “largi”, de număr întreg, de număr cu virgulă mobilă, de număr cu virgulă fixă, și te tip string.

Lteral bulean e cel mai simplu. Se folosește în operații de tip boolean și poate primi valoarea TRUE sau FALSE.

Const boolean flag = TRUE;

Literal simbolic. Se folosesc acolo unde figurează tipul char și wchar. După tradiția , împrumutată din C și C++, literalii simbolici sunt incluși între ghilimele unare (‘ ’). Dimensiunea simbolului simplu – 8 biți, și descrie simboluri în diapazonul 0 până la 255 din tabelul standard de caractere ISO Latin-1 (8859-1). Tot aici se mai includ și caracterele de serviciu și cele ce indică constantele numerice.

Tab. 2.

Caractere ce nu se afișează:

(continuare) Tab. 2.

\ooo și \xhh permit de a reprezenta simbolul ca numărul lui corespunzător din tabelul de caractere în formă octală și hexadecimală. De obicei compilatorul IDL, în timpul translării, convertește codurile hexadecimale de acest fel în simboluri.

Când un bait pentru păstrarea informației simbolice nu e de ajuns, sunt folosite simbolurile “largi”, ce conțin mai mult de 8 biți. Tabelele acestor simboluri pot varia de la o platformă la alta. De aceea adăugând un literal cu caractere “largi” va trebui să nu ieșim din limitele standardului ISO Latin-1 (8859-1).

Literal întreg poate fi decimal, octal sau hexadecimal. Literalii decimali se consideră o succesiune de cifre, dar dacă succesiunea începe cu zero, atunci compilatorul ia numărul ca număr octal. Cei hexadecimali pot conține toate cifrele și literele latine de la A la F. Dar astfel de literali se încep cu perechea 0x sau 0X.

Literali în virgulă mobilă pot fi compuși din număr întreg și partea fracționară despărțiți prin sin simbolul punct (.). De asemeni pot fi scriși și în format științific adică de despărțit mantisa numărului de ordinea lui prin litera E.

1426E+13

0.785e-137

Literali cu virgulă fixă sunt prevăzuți în IDL pentru calcule financiare. Ei constau din puși între ghilimele unare (‘ ’). Dimensiunea simbolului simplu – 8 biți, și descrie simboluri în diapazonul 0 până la 255 din tabelul standard de caractere ISO Latin-1 (8859-1). Tot aici se mai includ și caracterele de serviciu și cele ce indică constantele numerice.

Tab. 2.

Caractere ce nu se afișează:

(continuare) Tab. 2.

\ooo și \xhh permit de a reprezenta simbolul ca numărul lui corespunzător din tabelul de caractere în formă octală și hexadecimală. De obicei compilatorul IDL, în timpul translării, convertește codurile hexadecimale de acest fel în simboluri.

Când un bait pentru păstrarea informației simbolice nu e de ajuns, sunt folosite simbolurile “largi”, ce conțin mai mult de 8 biți. Tabelele acestor simboluri pot varia de la o platformă la alta. De aceea adăugând un literal cu caractere “largi” va trebui să nu ieșim din limitele standardului ISO Latin-1 (8859-1).

Literal întreg poate fi decimal, octal sau hexadecimal. Literalii decimali se consideră o succesiune de cifre, dar dacă succesiunea începe cu zero, atunci compilatorul ia numărul ca număr octal. Cei hexadecimali pot conține toate cifrele și literele latine de la A la F. Dar astfel de literali se încep cu perechea 0x sau 0X.

Literali în virgulă mobilă pot fi compuși din număr întreg și partea fracționară despărțiți prin sin simbolul punct (.). De asemeni pot fi scriși și în format științific adică de despărțit mantisa numărului de ordinea lui prin litera E.

1426E+13

0.785e-137

Literali cu virgulă fixă sunt prevăzuți în IDL pentru calcule financiare. Ei constau din partea întreagă și fracționară despărțiți de punctul decimal, și sunt evidențiați cu litera d sau D. Astfel de literali vor fi folosiți împreună cu tipul fixed. Dar, deși aceste elemente ale limbajului sunt descrise în specificația CORBA V2.2, nu li s-a găsit realizarea în compilatoarele IDL. Cel puțin nici VisiBroker for Java 3.3, nici utilita idltojava din JDK 1.2 nu lucrează cu virgulă fixă.

Literali string. Ei prezintă rânduri, ce conțin simboluri, care sunt permise și în literalii simbolici, în afară de simbolul ‘\0’. Deși VisiBroker și idltojava din JDK prelucrează corect acest simbol, C și C++ cu prezența simbolului nul în rând nu stă bine. Aceasta și este pricina excluderii.

Pentru prevenirea erorilor de compilare, ce pot fi primite în urma translării codului sursă, compilatorul IDL convertește toate codurile hexadecimale în octale.

Preprocesarea. Pentru setarea condițiilor de compilare și stabilirea unor opțiuni compilatoarele IDL folosesc preprocesarea, bazată pe directivele descrise de standardul ANSI C++. Programiștii în C și C++ aici se simt ca peștii în apă. Cei ce nu cunosc aceste limbaje, au nevoie de consultarea literaturii corespunzătoare. În preprocesarea IDL sunt prezente mai multe tipuri speciale a directivei

#pragma.

#pragma ID

#pragma prefix

#pragma version

#pragma hint

Ele au sens doar pentru specialiștii CORBA.

Vizibilitatea numelor. Orice nume IDL este vizibil în acel bloc, unde este descris. În calitate de astfel de bloc poate fi, descrierea modulelor sau interfețelor. Pentru trimiterea la cel mai global bloc, se poate folosi numele lui urmat de dublu două puncte :: sau nu urmat de nimic. Dar va fi mai frumos, dacă întotdeauna ‘::’ se va adăuga înaintea blocurilor, care nu sunt incluse nicăieri. Astfel se va evidenția că numele menținut – este cel mai bătrân în ierarhia blocurilor incluse. De exemplu, pentru a face trimitere la numele Iu, descris în IDL fișierul de mai jos:

interface Upper

{

typedef string Iu;

};

se poate scrie:

::Upper::Iu

sau

Upper::Iu

În așa stil de creare a numelor complicate depline, compilatorului I se arată explicit cum să găsească numele corespunzător. Totodată se rezolvă conflictul între aceleași nume dar descrie în interiorul diferitor blocuri.

De exemplu:

Interface One

{

typedef float nameConflict;

};

interface Other

{

typedef float nameConflict;

};

În cazul dat avem nevoie de detalierea numelor pentru adresarea către ele:

::One::namConflict;

sau

::Oher::nameConflict;

Tipuri de date simple sunt pentru descrierea atributelor obiectelor și parametrilor operațiilor lor, pentru constante, pentru primirea noilor tipuri, mai complicate.

Deosebim tipurile de date:

boolean (păstrează adevăr sau nu adevăr: TRUE sau FALSE);

Simbolice (simbolurile obișnuite pe 8 biți de tip char sau simbolurile “largi” de tip wchar). În procesul transmiterii datelor de tip simbolic prin rețea, aceste date pot fi convertite astfel încât să li se schimbe modul, dar valoarea rămânând aceiași. Așa situații pot apărea între calculatoarele ce au diferite codificări (encoding);

Tipurile întregi – short, long, long long, cît și derivatele lor fără semn cu prefixul unsigned. După cum se vede, astfel de tipuri pot memora doar numere întregi. (de menținut că în IDL tipul int lipsește);

Tipurile de numere în virgulă mobilă: float (corespunde IEEE-numărului cu virgulă mobilă cu unică precizie), double (corespunde IEEE-numărului cu virgulă mobilă cu dublă precizie) și long double (corespunde IEEE-numărului cu virgulă mobilă cu dublă precizie extinsă). O informație mai amplă referitor la numerele cu virgulă mobilă IEEE se poate găsi în documentul “IEEE Standard for Bnary Floating-Point Arihtmetic”, ANSI/IEEE Standard 754-1985;

Tipurile speciale se folosesc în cazuri deosebite. Ele sunt două: octet și any. Primul servește pentru ca în procesul de schimb de date, cifrele pe sisteme se 8 biți în timpul transmiterii să nu fie modificate. Tipul octet este o bună alternativă a tipului char în cazul când se transmite un număr mic.

Tab. 3.

IDL diapazonul de memorie rezervat pentru tipul de date întregi:

Pentru a descrie un câmp ce va putea primi valori de orice tip, permis în IDL, există any. Acest tip este des folosit în CORBA.

Constantele. Se încep cu cuvântul cheie const urmat de tipul constantei, numele ei, simbolul de atribuire ‘=’ și valoarea ce poate conține literali și/sau operanzi matematici. Constantele pot fi de tip: întreg, simbolic (obișnuit sau “larg”), cu virgulă mobilă, string (cu simboluri obișnuite sau “largi”) și boolean.

Litealii au fost descriși mai sus, însă operanzii matematici trebuie de-i explicat.

Operațiile binare sunt:

| – bit cu bit “sau”;

^ – bit cu bit “sau exclisiv”;

& – bit cu bit “și exclusiv”;

>> -bit cu bit permutare la dreapta cu umplerea biților eliberați cu zerouri; diapazonul permutării: 0 până la 63 poziții inclusiv;

<< – bit cu bit permutare la stânga cu umplerea biților eliberați cu zerouri; diapazonul permutării: 0 până la 63 poziții inclusiv;

+ – adunare aritmetică;

– – scădere aritmetică;

* – înmulțire aritmetică;

/ – împărțire aritmetică;

% – restul de la împărțirea aritmetică;

Operațiile unare efectuează setarea semnului negativ (-) și pozitiv (+) al numărului, cât și completarea acestui număr cu până la doi (~).

Operațiile unare (+-), și cele binare (* / + -) pot fi folosite la definirea constantelor, unde iau parte cifre cu virgulă mobilă și fixă. Iar operațiile unare (+ – ~) și binare (* / % + – << >> & | ^) pot fi aplicate doar asupra numerelor întregi.

Exemplu:

const short sConst = 1124;

const double dConst = 2.f * 3.14 * 1.234E+13;

const wstring wsConst = “rând larg”;

const long long llConst = (1000000 >> 4) % 7;

Tipuri ce pot fi construite și șabloane. Dar mai întâi de toate ar trebui să definim cuvântul cheie typedef fără de care IDL nu ar mai fi avut rost.

typedef – împrumutat din C, C++, descrie noi tipuri, sau mai bine zis, atribuie tipurilor existente nume alternative, ce permite de a folosi pseudonime comode. Cu ajutorul lui se mai pot defini și alte construcții ale IDL.

Tipuri ce pot fi construite. Aici se atribuie structuri, uniuni discriminate, și enumeratoare.

Structura – servește la denumirea tipului ce va memora un set de date de tipuri diferite:

struct < numele structurii >

{

< lista componentelor >

};

< lista componentelor > este lista componentele cărei sunt despărțite prin punct și virgulă, și care sunt combinație din numele tipului și identificatorul. Numele tipului poate fi orice tip de bază IDL cât și tip definit de programator. Se permite de a folosi matrice cu numărul de elemente definit.

Exemplu de structură cu două câmpuri, primul de tipul definit în program, altul – matrice cu numere în virgulă mobilă.

struct Our

{

MyType field;

Float coefficients[10];

};

În cazuri mai complicate se poate defini cu ajutorul typedef:

typedef struct tagOurStruct

{

MyType field;

Float coefficients[10];

} TheStructure;

Aici se creează structura de tipul tagOurStruct și totodată se definește și pseudonimul TheStruct.

Uniuni discriminate. Aici programatorii în pascal vor găsi ceva cunoscut. Aceste uniuni sunt dotate cu cuvântul cheie “switch” și posedă element – discriminator, ce determină care set unional se va folosi. Astfel obiectul, primit în rezultatul compilării uniunii discriminate, e capabil ca în diferite momente de timp să păstreze informația despre tipuri diferite. Principalul e ca în timpul descrierii tipurilor unionale cu ajutorul IDL să se ia în vedere toate variantele de tipuri necesare. Exemplu:

union < numele uniunii > switch (< tipul discriminatorului >)

{

< lista elementelor din care se va alege >

};

Aici < tipul discriminatorului > poate fi simbol, număr întreg, boolean sau enumerator: char, wchar, short, unsigned short, long, long long, unsigned long, unsigned long long, boolean, enum.

< lista elementelor din care se va alege > este mai complicată. Fiecare element e compus din cuvântul cheie case urmat de o expresie constantă, după care se pun două puncte și în sfârșit descrierea tipului dorit. În timpul înscrierii în uniune a unei informații, uniunea primește tipul ce corespunde cu tipul informației ce trebuie de o salvat. Totodată și se memorizează discriminatorul. De aceea, dacă va fi o încercare de citi valoarea de sub tipul, diferit de cel memorizat, se va genera excepția org.org.CORBA.BAD_OPERATION. Însă pentru programatori există o scăpare, care în IDL se numește cuvânt cheie default. Acest cuvânt se include în uniune , dar numai o singură dată.

union MyTYpe switch (short)

{

case 13: short alfa;

case 0x0C << 3: long beta;

default arr alphabet;

};

În cazul dat, MyType are discriminator de tip short. Numerele ce urmează după case prezintă valoarea discriminatorului. Doar de ele depinde care tip va fi ales. Dacă valoarea discriminatorului este 13, atunci sub numele alfa se va păstra valoarea short. Iar pentru discriminatorul 0X0C << 3 (valoarea acestei constante evident este 96), valoarea memorizată va fi de tip long și va avea numele beta. Valoarea inițială pentru tăcere (default), va avea tipul arr, la care se va putea adresa pe numele alphabet.

Uniunile discriminate se pot descrie și prin typedef:

typedef union tagMyTYpe switch (char)

{

case ‘a’: short alfa;

case ‘b’: long beta;

default arr alphabet;

} TheUnion;

În cazul dat se creează un nou tip – uniune tagMyType și pseudonimul lui TheUnion.

Enumeratorul. Este cel mai simplu și cunoscut tip ce poate fi construit. Este vorba de un set de elemente ce limitează alegerea. Vor vi alese doar acele elemente, descrise în acest tip. În procesul translării în alt limbaj de programare, fiecărui element al enumeratorului i se atribuie o valoare numerică unică, începând cu zero. Schema generală a enumeratorului este:

enum < nume enumerator >

{

< lista elementelor >

};

În calitate de elemente sunt identificatori despărțiți prin virgulă.

enum Semaphore {red, yellow, green};

Analog, se descrie și prin typedef:

typedef enum tagSemaphore

{red, yellow, green} TheEnumeration;

Tipul șablon. Aici se referă rândurile (stringuri), succesiunile și numerele în virgulă fixă.

Rânduri. Acestea în IDL, după cum se observă, nu sunt tipuri de bază. Ele pot fi pe 8 biți (string) și largi (wstring). Primul poate conține orice simboluri de tip char cu excepția null. Al doilea tip de rând conține toate simbolurile incluse în tipul de bază wchar, și se termină cu simbolul null. Dacă rândurile simple “înguste” sunt destinate mai mult pentru codările locale, atunci cele “largi”, de regulă, se folosesc în programe internaționale.

Lungimea rândului poate fi limitată cât și nelimitată. Limitarea (bounded) se aseamănă cu aceea a matricelor de caractere. Exemplu:

typedef wstring <28> boundedString;

În parantezele unghiulare se indică dimensiunea rândului în caractere. Cele nelimitate conțin atâtea simboluri, de câte este nevoie.

typedef string unboundedString ;

De menționat că descrierea tipului rând se efectuează cu ajutorul cuvântului typedef.

Succesiunile se aseamănă mult rândurilor. Deosebirea constă în posibilitatea păstrării datelor de alte tipuri. Succesiunile pot fi de dimensiune limitată sau nelimitată. Ce-i drept, în descrierea succesiunii parantezele unghiulare sunt prezente tot timpul. În ele se scrie tipul datelor ce vor fi memorate (pentru succesiunea nelimitată) sau tipul datelor cu dimensiunea succesiunii, despărțite prin virgulă. Exemplu de primul tip:

typedef sequence unboundedSequence;

Exemplu de tip de succesiune cu limitare:

typedef sequence<float,100> boundedSequence;

Avantajul succesiunilor este că doar ele permit includerea recursivă:

typedef sequence< sequence <float,100> > recursedSequence;

De atras atenția: între ghilimelele de închidere trebuie de lăsat spațiu, pentru ca compilatorul să nu le ia drept operator și eroarea va fi foarte interesantă.

Numere cu virgulă fixă. Tipul de date fixed prezintă un număr decimal cu virgulă fixă, ce poate conține până la 31 cifre.

Alte tipuri. Aici se referă tipul matrice și nativ. Tipul matrice se definește prin typedef, după care se scrie tipul, identificatorul urmat de dimensiunea acestei matrice. Se permit matrice multidimensionale.

typedef double someArray[100][100];

Încă un tip interesant native se conține în specificația OMG IDL. El servește pentru introducerea tipurilor noi de date, realizate în alt limbaj de programare, diferit de IDL. De exemplu:

native NonIDLType;.

va spune compilatorului că undeva este tipul NonIDLType, realizat într-un mod neânțeles de el, dar pentru el totuși va trebui de realizat interfața necesară. Programatorilor în Java le este cunoscut cuvântul native. El descrie obiecte, realizate în limbaje de programare de nivel înalt, cu respectarea legilor JNI (Java Native Interface).

Un mic exemplu cu tipul native:

Module SomeModule

{

native MyTypeMadeInCPlusPlus;

typedef MyTypeMadeInCPlusPlusnativeTypeArray[3][3];

};

Cuvântul cheie native indică compilatorului IDL, că undeva este tipul MyTypeMadeInCPlusPlus realizat în limbajul C++, și dorim să-l folosim. După așa descriere, MyTypeMadeInCPlusPlus poate fi folosit la fel ca și orice alt tip IDL.

Excepții. În IDL există o construcție specială, de descriere a excepțiilor. Descrierea tipului – excepție coincide cu descrierea structurilor, deosebirea minimală fiind schimbarea cuvântului struct cu exception:

exception < numele structurii >

{

< lista componentelor >

};

< lista componentelor > este lista componentele cărei sunt despărțite prin punct și virgulă, și care sunt combinație din numele tipului și identificatorul. Numele tipului poate fi orice tip de bază IDL cât și tip definit de programator. Se permite de a folosi matrice cu numărul de elemente definit , unde numărul definit este obligatoriu.

Exemplu

. . .

typedef long nativeTypeArray[3][3];

. . .

exception my

{

string what;

nativeTypeArray sa;

};

. . .

De menționat că majoritatea excepțiilor standarde CORBA sunt scrise în IDL.

Interfețe. Interfața poate fi moștenită de la alte interfețe; moștenirea poate fi multiplă. În IDL interfețe pe lângă operații și atribute mai pot fi descrise constante și excepții.

De obicei, când în rezultatul compilării IDL se generează descrierile obiectelor, fiecare interfață se transformă într-un obiect aparte. În următoarea versiune de specificare CORBA se plănuiește să se permită generarea unei clase de odată pentru câteva interfețe.

Descrierea interfețelor poate fi deplină sau plănuită (forward). Se permit mai multe descrieri plănuite.

Descrierea forward se face atunci, când este nevoie de a se adresa la o interfață care încă nu a fost declarată. Pentru a primi această descriere, e nevoie doar de cuvântul cheie interface și numele ei.

interface < numele interfeței >;

La descrierea deplină, după nume urmează două puncte și numele interfeței părinte:

interface < numele interfeței > [ : < nume interfață părinte 1 > . . . [ , < nume interfață părinte n >]. . .]

{

. . .

< descrierea tipurilor, constantelor, excepțiilor, atributelor și operațiilor>

. . .

};

În interiorul interfeței se scriu elementele IDL, care sunt permise în interiorul interfeței. Noile tipuri, constantele și excepțiile au fost explicate deja, au rămas atributele și operațiile.

Atributele sunt componente ale claselor, care păstrează niște valori. Ele se descriu astfel:

[readonly] attribute < tipul atributului > < numele atributului >;

Modificatorul nedeclarat readonly înseamnă că valoarea atributului descris nu poate fi schimbată, numai citită. Dacă readonly lipsește, atunci în orice moment valoarea păstrată de atribut poate fi înlocuită, la fel ca și în cazul unei variabile obișnuite.

Operația este completarea logică a atributelor. Cu ajutorul operațiilor se execută o oarecare porțiune predefinită de cod a obiectului. Se descriu operațiile astfel:

{oneway void | < tipul ce trebuie întors > } < numele operației >

({ in | out | inout } < parametru > . . . [,{ in | out | inout } < parametru > . . .)

[raises ( < numele excepției > . . . [, < numele excepției >] . . .)];

Astfel de declarație necesită lămurire. Dacă se descrie o operație ce trebuie să întoarcă o valoare, atunci în partea stângă de nume se descrie tipul valorii ce se va întoarce. Excepție fac doar operațiile ce sunt descrise ca oneway, ele trebuie să întoarcă tipul void, adică nu întorc nici o valoare. Cuvântul cheie oneway indică că la chemarea operației, programa nu așteaptă până ce această operație se va termina, ci continuă execuția. Parametrii pot fi de intrare (in) de ieșire (out) sau combinați (inout). Dacă operația poate genera excepții, atunci ele trebuie să fie enumerate în paranteze și prin virgulă după cuvântul cheie rasies.

Exemplu concret de descriere a interfeței și corpul ei:

Interface interfaceDeclaration

{

typedef long ArrayType[3][3];

const short SomeError = 0xFF;

exception SomethingWrong

{

string whatHappend;

ArrayTypeerrors;

};

attribute ArrayType matrix;

unsigned long returnCode(in boolean flag);.

}

Descrierea modulului. Modulul este cel mai “în vârstă” unitate a limbajului IDL. El servește pentru gruparea tipurilor, interfețelor, etc., legate logic între ele. El constă din nume.

module < nume modul >

{

. . .

< corpul modulului >

. . .

};

Iată că am ajuns la bun sfârșit. Se poate adăuga că s-a atras atenția la compilatoarele mai des întâlnite și mai populare ca:

idltojava din pachetul Java 2 s corporației Sun Microsystems;

idl2java din pachetul VisiBroker al companiei Inprice;

idl din pachetul OrbixWeb al firmei IONA Technologies.

O altă cauză ar fi aceea că versiunile de probă OrbixWeb și VisiBroker pot fi primite prin http://www.iona.com și http://www.inprice.com, iar Java 2 cu setul de utilite în genere se răspândește gratis.

Încă câteva cuvinte despre arhitectura tie. În programarea orientată pe obiecte modernă există două moduri de creare a noilor obiecte: moștenirea și agreația. În primul caz noul obiect moștenește calitățile și metodele de la obiectul părinte, adăugând la ele pe-ale sale. În principiu obiectul nou ia componenta părintelui ca pe a sa proprie, pe când în cazul agreației avem un alt mod mai complicat. Aici obiectul nou creat păstrează trimiterea la un alt obiect funcțiile cărui le va folosi. La adresarea către aceste funcții, obiectul creat face cerere prin trimiterea existentă către obiectul părinte care și face lucrul de bază. Astfel de viziune este primită în modelele obiect Microsoft COM și DCOM. În CORBA ea se numește tie.

1.2. Ce prezintă baza Client-Server

Luând în considerație că aplicațiile CORBA sunt foarte asemănătoare cu aplicații de tipul Client-Server, voi încerca să descriu baza acestor aplicații în MIDAS (Multitier Distributed Application Servicies Suite). Astfel voi putea generaliza și totodată voi avea motive de a evidenția cuvintele spuse mai sus despre aceea că ideologia CORBA nu e construită pe tradiționalul Client-Server, dar este foarte apropiată de el.

Deci, reieșind din aceia că, creatorii componentelor MIDAS au mers după principiul “programatorul nu trebuie să se implice în complexitatea internă a tehnologiei date”, întrebarea “Dar cum aceasta lucrează?” este de prisos. Mai mult ca atât: cu cât mai bine sunt ascunse detaliile realizării produsului, cu atât mai bine. Dar, totuși, pentru cei ce vor să pătrundă în sensul tehnologiei, explicăm. Sistema de tipul acesta este compusă din trei straturi. Ultimul strat, unde se găsește serverul BD și mai jos de el, nu va fi precăutat – el este tradițional. Vom vorbi despre cele două rămase: stratul client și stratul business-logic (pentru ambele trebuie de instalat biblioteca MIDAS.DLL).

Stratul-client. Acesta este primul nivel – client. El conține interfața, compusă din componentele vizuale VCL, care lucrează cu datele (data-aware components). Este foarte asemănător cu crearea BD cu ajutorul instrumentelor tradiționale Borland Delphi și C++Builder folosind componentul – data source. Deosebirea se ascunde în componentul păstrării și prelucrării setului de date. În cazul ne-MIDAS este vorba de componentul table sau de componentul îndeplinirii SQL query. Dar în cazul aplicației cu împărțiri multiple (multibloc), componentele acestei clase sunt trecute pe nivelul următor, intermediar, nivelul business-logic, care se află între clienții sistemei. În locul lor, pe stratul client apar alte două componente: TClientDataSet și componentul legăturii cu serverul la distanță.

TClientDataSet – component foarte interesant. El servește ca un fel de cache pentru datele primite de pe serverul îndepărtat. Acest component este atât de multifuncțional, încât ușor poate prelucra datele și din tabela “planară”, ce se află într-un fișier de pe disc. Universalitatea componentului se mai confirmă și prin faptul că este moștenitorul clasei TDataSet, care la fel conține un șir de componente de păstrare și prelucrare a datelor. Din punct de vedere MIDAS, TClientDataSet este interesant pentru că el face, cu ajutorul unei interfețe speciale IappServer, legătura cu module de date îndepărtate.

Componentul legăturii cu serverul la distanță răspunde de legătura dintre programa-client și stratul business-logic. În Delphi 5 astfel de componente sunt patru. Fiecare efectuează legătura diferit. De exemplu, componentul TDCOMConnection pentru a transmite sau a primi datele folosește tehnologia Microsoft DCOM, atunci când TSocketConnection – secretele și protocolul TCP/IP. Dacă business-logica e bazată pe CORBA, atunci pentru legături e prevăzut componentul TCORBAConnection, protocol de comutație al cărui este IIOP. TWebConnection – component nou în Delphi 5 – organizează “pomparea” datelor cu ajutorul popularului Internet – protocol HTTP. Deci, MIDAS propune legături pentru toate cazurile vieții. Încă un component, TOLEnterpriseConnection, nu-l includem în lista de sus – el servește doar pentru compatibilitatea între versiunile anterioare MIDAS.

Stratul business-logic. A scrie aplicația-client e doar o jumătate de lucru. Important e a organiza funcționarea stratului intermediar, pentru că anume aici are loc procesarea cererilor, primite de la aplicații – client de la distanță. Aici se execută serverul de aplicații, condus de interfața IAppServer.

Din punct de vedere al programatorului, stratul intermediar este doar un modul de date la distanță (Remote Data Module), crearea cărui e foarte asemănătoare cu generarea modulului de date tradițional, folosind Delphi sau C++Builder. Un modul de date la distanță este un component, bazat pe tehnologia COM/DCOM, cu un anumit set de COM – interfețe.

În tehnologia MIDAS sunt module de date la distanță de trei feluri: Remote Data Module, MTS Data Module și CORBA Data Module. Primul asigură relații cu clienții pe protocoalele DCOM, TCP/IP, și HTTP. Al doilea, după cum se poate vedea din denumire, este analog primului, dar folosește posibilitățile serverului de tranzacții Microsoft Transaction Server. Ultimul, asigură realizarea business-logica în conformitate cu tehnologia CORBA.

Procese interne.

Așadar:

Utilizatorul lansează aplicația-client, care încearcă să stabilească legătura cu serverul de aplicații; dacă serverul de aplicații nu a fost lansat, el se lansează; aplicația-client primește interfața IAppServer de la server.

Programul – client cere date de la serverul de aplicații sau toate o dată sau un mic set.

Serverul de aplicații se conectează la BD (dacă conexiunea nu a fost stabilită anterior) de la care primește datele pentru client, pe care le împachetează și le transmite programei-client.

Aplicația-client despachetează datele, și într-un mod oarecare le afișează utilizatorului.

După ce utilizatorul modifică datele, programa-client le salvează în protocol.

Pentru modificarea datelor, protocolul este împachetat în pachet de date, ce urmează a fi transmise serverului de aplicații.

Serverul despachetează protocolul și încearcă să modifice datele în BD; dacă între timp datele au fost schimbate de un alt utilizator, atunci serverul va încerca să acordeze datele schimbate de primul utilizator cu cele existente deja sau va salva doar datele ce nu pot fi reînnoite; numai după aceasta datele salvate se întorc aplicației-client.

Aplicația-client sau aruncă modificările imposibile, sau încearcă să le corecteze, după care mai ”roagă” serverul încă o dată să introducă modificările deja corectate.

Aplicația-client își reînnoiește datele, cerând de la server setul nou.

1.3. Cum se creează CORBA-aplicații

Deci, am făcut câțiva pași în lumea Tehnologiilor Informaționale, și am atras atenția la CORBA. De ce este nevoie pentru a scrie aplicații în baza acestei tehnologii? În primul rând trebuie de învățat a descrie obiectele, folosind limbajul IDL.

În al doilea rând instalăm VisiBroker for Java, VisiBroker for C++ sau Delphi. Aceste pachete pot fi primite de pe Web-serverul companiei Inprice, în calitate de versiuni de testare. Mai mult ca atât, VisiBroker este inclus în pachetele JBuilder, C++Builder și Delphi de corporația Borland/Inprice. Și încă un plus în alegerea acestor pachete: există versiuni pentru diferite sisteme de operare, una din care este și Linux.

Instalarea VisiBroker are loc automat, deci, probleme în legătură cu aceasta nu trebuie să apară. Pachetul modifică cheile reestrului Windows, modifică fișierul serviciilor și variabilele mediului. Trebuie doar de memorizat că variabila PATH trebuie să indice la subcatalogul bin al catalogului unde a fost instalat VisiBroker.

Configurarea. Mai întâi de toate, este nevoie să ne clarificăm cu termenul “domen virtual” și cu modul în care îl înțeleg creatorii CORBA – sistemelor. Domen virtual – este unul sau mai multe calculatoare, logic conectate în scopul realizării anumitei sarcini. Domen virtual este denumit astfel, deoarece pentru administratorul de rețea el nu există, dar există numai din contul unor reguli stabilite de utilizator. De exemplu, în VisiBroker acesta este un oarecare port dedicat. Astfel, domen virtual, îl putem socoti o subrețea a rețelei de bază.

Când proiectarea se petrece nu pe un singur calculator, ci în rețea, pot fi de folos unele modificări suplimentare. Este vorba de variabilele de mediu:

OSAGENT_PORT (default are valoarea 14000) servește la adaptarea domenelor virtuale în cadrul rețelei locale.

VBROKER_ADM – catalogul de sistem; de obicei acesta este subcatalogul adm al catalogului principal, unde e instalat VisiBroker. Servește pentru păstrarea informației despre interfețe, demonului de activare a obiectelor Smart Agent, și este locul principal de păstrare a fișierelor de configurare.

Setarea manuală a acestor variabile se petrece doar în Unix; în Windows, valorile lor se păstrează în reestrul de sistem în formă de chei, care la dorință pot fi modificate cu ajutorul utilitei vregedit, ce aparține pachetului VisiBroker.

Valoarea OSAGENT_PORT e importantă, când dorim să izolăm unele calculatoare din aceiași rețea. Mai mult ca atât, modificând această valoare, se pot împărți obiectele de pe server deja în funcțiune, cu versiuni diferite. Astfel, neschimbând valoarea OSAGENT_PORT, la cererea aplicației-client se face trimitere la obiectul poate cu versiunea mai veche care e în stadia de a comite erori, și care “la nimereală” l-a ales utilita Smart Agent. Dar, dacă, de exemplu, în rețeaua locală portul standard este 14000, iar versiunii noi a CORBA-obiectelor i-am setat valoarea variabilei OSAGENT_PORT pe 14500, atunci aplicațiile nu vor “atinge” obiectele în domenul de bază, iar ultimele nu vor căuta în domenul virtual creat. Pentru comparație putem face asemănarea cu schimbarea frecvenței postului de radio, unde emițătorul și receptorul lucrează pe aceiași frecvență stabilită și nu amestecă altor stații receptive sau de emisie setate pe o altă frecvență.

Un moment principal – organizarea interacțiunii CORBA-aplicațiilor, ce se află în rețele locale diferite, dar legate una cu alta (deloc nu e o rarietate, mai ales pentru companii mai avansate în sensul topologiei rețelelor). În VisiBroker căutarea obiectelor, și balansarea rezistenței rețelei, o execută utilitele Smart Agent lansate in aceste rețele. De aceia, pentru ca aceste utilite să poată face legătura fără obstacole, în catalogul descris de variabila de mediu VBROKER_ADM, trebuie să existe fișierul agentaddr. Acest fișier va conține în fiecare rând numele sau IP-adresa calculatorului, unde a fost lansat Smart Agent. Redactând această listă, formăm topologia legăturilor obiectelor. Numele și locul fișierului agentaddr poate fi modificat cu ajutorul variabilei de mediu OSAGENT_ADDR_FILE.

Acum putem începe să lucrăm cu CORBA.

Ordinea de acțiuni. Creând CORBA-aplicații trebuie de reținut, că modelul dat diferă de cele tradiționale – programe monolite – și chiar de sistemele client-server, deși cu ultimul are ceva comun. Legătura obiectelor CORBA și clienților e greu de-o numit aplicație ca atare. Astfel de sisteme se aseamănă cu pânza de păeangen, unde totul e încrucișat: clientul in orice moment poate deveni server, și utilizatorul nu mai poate înțelege, cu care server de obiecte el lucrează în momentul dat. Iar daca proiectul a fost îndeplinit excelent, userul poate să nu simtă chiar unele stopări sau pene. Tactica, folosită de tehnologia CORBA este: de a se conecta la serverul necesar, de a-i folosi funcțiile, de a se deconecta de la serverul dat. Și astfel de cicluri atomare pot exista sute. O schemă asemănătoare a fost adaptată și în Microsoft COM+. Pentru compararea tacticii descrise mai sus se poate aduce exemplul cu mecanicul auto: când are nevoie, chei și șurubelnițe, atunci le ia în conformitate cu necesitatea, iar instrumentul nenecesar deja, îl pune la locul lui înapoi – nu e necesar să le țină pe toate în mână (facem comparație cu aplicațiile monolite – toate funcțiile sunt incorporate). Mai mult ca atât, în orice moment mecanicul poate folosi instrumentul împrumutat de la coleg; piuliței de 13 îi este tot una cu a cui cheie a fost rotită, important e ca dimensiunea să coincidă.

Ordinea acțiunilor în cadrul creării programelor în baza tehnologiei CORBA poate fi:

analiza orientare-pe-obiect și modelarea;

descrierea obiectelor;

crearea serverului;

crearea clientului;

ajustarea obiectelor.

Analiza orientare-pe-obiect și modelarea. Tehnologia CORBA e creată pentru așa sisteme, ce trebuie să lucreze nu un an, de aceea anume o analiză și o modelare bună pot garanta că în viitorul apropiat aplicațiile nu vor fi supuse unor schimbări radicale.

În principiu, pentru a pune la cale modelul, este nevoie de un creion și câteva foi de hârtie. Dar pentru ca ideile să fie înțelese și de specialiști, trebuie de le documentat. Pentru IDL-descriere a modelului există pachetul Rational Rose, îndreptat spre crearea UML-modelelor (Universal Model Language).

Construind modelul viitorului obiect, trebuie de știut, că orice obiect CORBA poate moșteni de la CORBA::Object, de aceea noile obiecte întotdeauna pot privilegia de funcțiile acestei clase mai superioare. E de dorit, totuși, de creat un părinte intermediar, care va fi un obiect cu unele funcții de bază. Aceasta va ușura modificările globale în viitoarea sistemă: in orice etapă de realizare și exploatare se va putea adăuga tuturor obiectelor funcții noi doar modificând descrierea părintelui intermediar (aceasta și este “puterea” orientării-pe-obiecte).

Încă un moment, ce ține de ordinea de executare: de evidențiat în modelul gata obiectele atomare, independente, ele și vor candida să fie primele create și ajustate la sistem.

Descrierea și translarea obiectelor. Modelul gata conține obiecte (mai bine zis “clase”), care se descriu cu ajutorul limbajului IDL. Aceasta este nevoie nu numai pentru translarea în codurile sursă de bază pentru un limbaj de programare concret, ci și pentru adăugarea ulterioară a IDL – descrierilor în repozitariul interfețelor.

Despre translare. În fiece versiune VisiBroker există compilatorul său IDL: în VisiBroker for C++ – idl2cpp, în VisiBroker for Java – idl2java etc. Primul în baza IDL descrierilor generează codurile sursă în limbajul C++ și fișierele antet ce se includ, pe când al doilea face descrierea classelor în limbajul Java și structura pachetelor de nume.

Deci, presupunem că avem descrierea unui oarecare obiect, care prezintă un părinte abstract pentru componentele sistemului. Astfel îl și voi numi – AbstractComponent. Mai presupunem că fiecare component trebuie să întoarcă descrierea sa textuală pe scurt, măcar și pentru aceea ca administratorul de sistem să-l aleagă din lista obiectelor pe cel mai potrivit. În afară de aceasta, la cererea programului, componentul trebuie să întoarcă o oarecare interfață, cu ajutorul cărei clientul ei va putea primi o informație suplimentară de nivel inferior: de exemplu în ce categorie se află obiectul, care este modelul lui logic.

Operația următoare îi atribuie obiectului un identificator unic, care poate fi cheie de căutare în baza de date a obiectelor:

fail component.idl

#pragma prefix “tehnologii.utm”

module AbstractComponent

{

// informația de descriere a unei interfețe oarecare

// pentru a primi informația despre component

interface ComponentInfo;

interface ServiceProvider

{

// componentul întoarce rândul cu descrierea sa

// prescurtată

string getDescription();

// operația de primire a informației despre

// component în codul mașină

ComponentInfo getComponentInfo();

// operația de atribuire componentului unui

// identificator unic

void setUniqueID(in long id);

};

};

Dacă erori în IDL n-au fost comise, în rezultat pe disc vor apărea fișiere: drept exemplu patru pentru C++, puțin mai multe pentru Java, care se vor găsi în cataloage cu o structură complicată etc.

Crearea serverului. Server – programul ce prezintă o oarecare interfață, obiectele la distanță în cazul CORBA. Serverele CORBA se pot activa desinestătător, fiind lansate de administratorul de sistem sau la încărcarea sistemului de operare. Programatorul poate înregistra serverele CORBA cu ajutorul unor utilite, după care un demon special va urmări cererile de intrare a programei client și va activa serverele necesare automat. Cu acest scop în VisiBroker for C++, Delphi există OAD (Object Activation Daemon), în VisiBroker for Java – OADJ.

Așadar, a scrie un serve nu este greu. Schematic procesul de lucru al serverului de tip CORBA se poate descrie în câțiva pași:

inițializarea brokerilor de cereri obiect (ORB);

inițializarea adaptorilor de obiect;

crearea exemplarului obiect – CORBA;

exportarea exemplarului creat;

trecerea în regimul de așteptare a cererilor.

Crearea clientului. Aplicația ce joacă rolul de client pentru obiect e mult mai simplă decât aplicația server. Dar și aici există o succesiune de acțiuni:

inițializarea ORB;

primirea legăturii la exemplarul CORBA-obiect;

folosirea obiectului

Inițializarea ORB e la fel ca și în cazul creării serverului.

2. Implementarea în rețeaua de telefonie mobilă

Voi elabora un model soft în baza tehnologiei CORBA care va fi implementat în telefoanele mobile și stațiile radio “sote”. Acesta va emula emiterea-recepționarea lor în interacțiunea obiectelor CORBA. Schimbul de date între aparate se face prin intermediul protocolului standard CORBA IIOP cu folosirea radiocanalului.

Astfel de logică este comodă pentru că serviciile providerului cu toată “gospodăria” lui de telefonie mobilă nu este altceva decît o mare rețea de calculatoare, unde există serverul principal (pultul de administrare și baza de date principală), routere (sotele), și terminalele client (telefoanele). Pentru a vedea schematic funcționarea a unui astfel de sistem, mai jos este alcătuită o schemă ce descrie operațiile de bază (vezi Fig.1.).

Fig. 1. Schema bloc a sistemului de telefonie mobilă.

Schema funcțională a sistemului. Sistemul funcționează astfel: administratorul pornește aplicația consolă de sistem, ce efectuează inițializarea internă și setează parametrii sotelor. Sistemul dă nume sotelor cu care va lucra administratorul, și le permite de a deservi clienții. Din acest moment sistemul permite abonentilor să sune, să primească/transfere conturi. Iar administratorul poate efectua operațiile descrise în Fig.2.

Fig. 2. Funcțiile administratorului.

Sotele se conectează independent de sistem, dar își efectuează funcțiile numai după semnalul de comandă. Până atunci se află în regim de așteptare.

Fig. 3. Funcțiile sotei.

Telefoanele celulare în sistem nu sunt cele mai intelectuale. Scopul lor de de a emite semnal radio în continuu: cu date de primire/trimitere sau de test, cu care verifica dacă a ieșit din zona de acoperire. Telefonul mai servește ca pult de introducere a numerelor altor abonenți, cît și text.

Fig. 4. Funcțiile telefonului.

3. Emularea in Delphi 5.5 a interacțiunii sota-telefon în baza tehnologiei CORBA

3.1. Prezentarea proiectului

Proiectul realizat este compus din următoarele părți:

sotă – program ce îndeplinește funcția de sotă sau router. (vezi codul în Anexa 2.)

telefon – program ce îndeplinește funcșiile terminalului. (vezi codul în Anexa 1.)

interacțiunea sotă-telefon cu ajutorul obiectelor CORBA (vezi codul în Anexa 4.)

Pentru a emula interacțiunea sotă-telefon, am creat interețe grafice corespunzătoare cu elemente de vizualizare a parametrilor principali: pentru sotă – informația despre numărul de clienți conectați la moment, informația despre ID-ul ei, informația despre datele ce sunt transferate; pentru telefon – informația dacă telefonul este în rețea sau nu e în zona de acoperire, vizionarea numărului de telefon, avertizarea despre un sunet sau un nou mesaj SMS, însăși mesajul SMS.

În stare normală de funcțiune, interfața grafică a sotei și telefonului este prezentată în Des.1.

3.2. Sota

La lansare sota se testează la defecte hard, după care, dacă testul a trecut, lansează softul. Softul ce ține de deservirea clienților, este o copie a obiectului CORBA (vezi Anexa 3.), care este lansată în regim multiuser. După aceasta sota este gata de a deservi clienții. În caz de una sau mai multe cereri, obiectul CORBA generează evenimentul sau evenimentele respective de creare a unei sau mai multe legături. Numărul de evenimente va fi echivalent cu cifra “Clients”de pe forma respectivă din Des.1. În caz de rupere a legăturii din partea clientului, se generează automat evenimentul la fel ca și în cazul conexiunii.

Cifra ce indică numărul clienților, se schimbă la fel. Apăsând pe butonul “Hide Statistics” putem ascunde această cifră. Pentru a reveni la inițial, se mai apasă încă o dată pe același buton, care acum are denumirea “Show Statistics”.

Forma poate fi minimizată, apăsând butonul “_”, sau închisă, ceea ce va duce la deconectarea sotei, acționând butonul “x”.

Dacă este necesitatea de a vedea mesajele transmise de clienți, care încă nu au fost primite de destinatar, se acționează butonul “+”. În rezultat se va deschide o a doua formă, ce va conține un tabel cu datele respective.(vezi Des.2). Numele sotei este un număr unic, care se generează la lansarea programului. El este vizibil de asemeni în această formă, după denumirea ei: “MyID”.

Butonul cu denumirea “Button1” aici are funcția de redesenare a tabelului, dar conținutul denumirii lui nu a fost schimbat din cauza că în primul rând programul este doar un prototip pentru testare, și în al doilea rând – el joacă aici un rol secundar.

3.3. Telefonul

Lansând programul “Phone”, pe ecran apare forma telefonului. Dacă telefonul este în zona de acoperire, adică în rețeaua locală a fost lansată cel puțin o sotă, atunci forma telefonului va coincide cu cea din Des.1. În caz că nu a fost găsit nici un obiect la distanță ce corespunde cererii (Pot exista în aceeași rețea mai mulde obiecte de același fel, dar pe porturi diferite. În cazul nostru, obiectul “Cell” este setat pe portul 14000.), pe ecranul telefonului, va apărea informația respectivă (vezi Des. 3a.). Deci în rețea, telefonul va indica “IN NETWORK” și semnalele de test se vor supraveghea de clipirea unei regiuni în colțul dreapta sus de culoare verde (ca și la telefoanele adevărate). În caz că rețeaua dispare, telefonul imediat indică “NO NETWORK” urmat de clipirea de culoare galbenă.

Fiecare telefon are un număr care în cazul nostru se generează automat la lansarea programului. Numărul generat se poate vedea acționând tasta “UID” (vezi Des.1.). După aceasta telefonul va lua forma din Des.3b. La dorință, numărul poate fi schimbat, după care se apasă butonul “Ok”.

Pentru a trimite un mesaj altui telefon, se acționează butonul “SMS” (Des.1.). Va apărea forma din Des.3c. În câmpul “To UID” se crie numărul telefonului cărui îi este destinat mesajul, iar în câmpul “Messg “ se scrie însăși mesajul. Datele se transmit după apăsarea butonului “SEND”. Dacă telefonul cu numărul dat nu este acum conectat la rețea, mesajul rămâne în stivă, și poate fi văzut de “administrator” în tabelul respectiv. În cazul nostru, l-am inclus în tabelul din Des.2. Dacă telefonul cui i-a fost transmis mesajul intră în rețea, imediat este avertizat de primirea unui mesaj, și este șters din stivă apoi scris în memoria telefonului. Avertizarea are loc prin schimbarea ritmcă a culorii telefonului. Mesajul poate fi citit apăsând tasta “ALO” (Des.1.), după care apare fereastra din Des.3d.

3.4. Interacțiunea sotă-telefon

În rețea sau în cazul nostru pe calculator trebuie să fie lansată utilita OAD (Object Activation Daemon) și Visibroker Smart Agent, ambele se instalează automat cu pachetul Borland/Inprice.

OAD e răspunzător de activarea obiectului, în caz că el a fost solicitat. Pentru comparație se poate spune că activează serverul. O astfel de tactică este convenabilă pentru că obiectul este lansat doar la necesitate, și deci folosește resursele rațional.

Visibroker Smart Agent se ocupă de căutarea obiectului, de securitate.

Însăși interfața obiectului, în cazul dat “Cells” a fost descrisă în IDL (Anexa 4).

Această interfașă este incorporată în programul “Cell” sau cu alte cuvinte în sotă. Forma obiectului inclus în Delphi este dată în Des.4. Deci, după cum am spus mai sus, la lansarea programului “sotă”, în rețea este deschis portul 14000 pe care e setat obiectul nostru, și care prezintă o rețea virtuală. Astfel de rețele virtuale într-o rețea fizică pot exista mai multe, mai precis câte porturi avem la dispoziție. La adresarea către obiect (evident, setările pentru OAD și Visibroker Smart Agent sunt corespunzătoare), brokerul caută obiectul și daemonul îl lansează. În cazul nostru, programul “sotă” îl lansez manual, pentru ca să nu mă depărtez de simularea sotei din rețeaua telefonică mobilă actuală, dar în genere se poate de economisit și aici resurse. Dacă avem mai multe rețele, atunci în fiecare trebuie de lansat câte un Visibroker Smart Agent. Astfel la cererea unui obiect, server poate deveni orice calculator, posibil foarte îndepărtat sau chiar cel client. În cazul telefoniei mobile, astfel se poate face roamingul, ce dă posibilitate de căutare în alte rețele.

Clientul primește interfața obiectului, pe care o folosește.

Lansând mai multe programe “sotă” și respectiv mai multe “telefoane” primim o rețea de telefonie mobilă, unde tehnologia CORBA ușurează sau mai bine spus ea asupra ei o mulțime de rutine și deschide larg porțile în lumea păinghinișului ce leagă o mulțime de stații, cu diferite sisteme și standarde.

Programul sistemului ce este descris aici nu pretinde a fi scos pe piață pentru a funcționa în condiții reale, pentru că este simplificat, dar însăși baza lui este gata. În interacțiunea sotă-telefon la fel sunt omise un șir de detalii, ca de exemplu transmiterea vocii, verificarea locului de aflare a clientului etc., însă aceasta de acum ține mai mult de gradul de intelectualitate a sistemului, și nu de modul de funcționare a lui.

4. PARTEA ECONOMICĂ

4.1. Etapele cercetării științifice

În general efectuarea lucrărilor de cercetare științifică include următoarele etape:

Lucrările pregătitoare. La această etapă se face cunoștință cu direcțiile și natura lucrărilor de cercetare științifică, studierea experienței anterioare în domeniile corespunzătoare de cercetare și motivarea tehnico-economică preventivă. Etapa se încheie cu întărirea sarcinii tehnice.

Prelucrarea teoretică a temei. Aici se efectuează alegerea și motivarea direcției alese de cercetare și metodele de rezolvare a problemelor formulate, elaborarea ipotezelor de lucru, calculele teoretice, elaborarea metodicii cercetărilor experimentale.

Faza experimentală. La etapa dată se efectuează proiectarea, implementarea, depanarea și montarea machetei. Etapa se finalizează cu efectuarea experimentelor, prelucrarea datelor obținute și verificarea lor cu rezultatele cercetărilor teoretice.

Faza perfecționării teoretice. La această etapă se realizează un șir de lucrări ce țin de corectarea părții teoretice în conformitate cu rezultatele obținute din experiență.

Faza finală. Etapa se caracterizează prin generalizarea rezultatelor cercetărilor efectuate, se elaborează darea de seamă pentru lucrarea de cercetare științifică, se determină eficacitatea reală a ei. Etapa se finalizează cu acordarea și întărirea rezultatelor cercetării la consiliul tehnico – științific.

Pentru cercetarea unor probleme complicate se utilizează o metodă complexă, care se bazează pe analiza în complex a proceselor și scopurilor din problema pusă. Metoda mai presupune și elaborarea unui scop, necesită determinarea fluxurilor de intrare și de ieșire a informației, introducerea criteriilor de optimizare. Realizarea acestei metode este imposibilă fără cunoașterea informaticii, modelării matematice. Mai ales sunt importante metodele de modelare, care permit studierea proceselor complexe într-un regim de analiză preliminară.

4.2. Planificarea rețea pentru crearea softului

Proiectele tehnologice contemporane sunt caracterizate de următoarele particularități:

tehnica nouă utilizată este foarte complexă și este construită utilizând ultimele elaborări științifice.

accelerării vitezei de elaborare a proiectelor.

proiectele referitoare la complexele tehnicii de calcul și softului sunt supuse uzurii morale foarte rapide.

necesitatea proiectării de sistemă la elaborarea softului și sistemelor tehnice.

Toate acestea au dus la necesitatea de creare a noi metode de planificare. Una din aceste metode prezintă modelarea procesului de elaborare, adică prezentarea legăturilor și caracteristicilor lucrărilor în procesul elaborării proiectului.

Metodele tradiționale de planificare presupun utilizarea celor mai simple modele de construirea a diagramelor de tip consecutive și ciclice.

Dar în asemenea diagrame nu este posibil de a prezenta legăturile dintre niște lucrări, de unde rezultă imposibilitatea de a afla cât de importantă este lucrarea dată pentru executarea scopului final. Pot apărea diferite întârzieri în timp legate de porțiuni de interconectare a lucrărilor, care sunt complicat de prezentat în diagrame. De obicei, în procesul dirijării, se culege informația despre lucrările efectuate și aproape nu se culege și nu se prezintă informația referitor la prognoza finisării lucrărilor viitoare. De aceia e imposibil de a prognoza rezultatele diferitor variante de soluționare la modificările planului inițial de lucru. Este de asemenea complicat de a reflecta și dinamica lucrărilor, de a corecta toată diagrama în legătură cu schimbarea termenilor de efectuare a unei lucrări. Deci e necesar ca să nu schimbăm termenul de efectuare a întregului complex de lucrări.

Neajunsurile de acest tip în mare parte sunt excluse de către sistemele de planificare și dirijare în rețea utilizate în prezent.

Sistemele de planificare și gestiune în rețea prezintă un complex de metode grafice și de calcul, metode de control și de organizare, care asigură modelarea, analiza și reconstruirea dinamică a planului de executare a proiectelor complexe.

Sistemul de planificare și gestiune în rețea este o metodă cibernetică creată pentru gestiunea cu sisteme dinamice complexe cu scopul asigurării condiției de optim pentru careva indicatori. Așa indicatori, în dependență de condițiile concrete, pot fi:

timpul minim pentru elaborarea întregului complex de lucrări;

costul minim al elaborării proiectului;

economia maximală a resurselor.

Particularitățile sistemului de planificare și gestiune în rețea în general sunt următoarele:

se realizează metoda proiectării de sistem la rezolvarea problemelor de organizare a gestiunii proceselor;

se utilizează modelul informațional-dinamic special (graful-rețea) pentru descrierea matematico-logică a procesului și calculul automat (conform algoritmului) a parametrilor acestui proces (durata, costul, forțele de muncă, etc.);

se utilizează sisteme de calcul pentru prelucrarea datelor operative pentru calculul indicatorilor și primirea rapoartelor analitice și statistice necesare.

Documentul de bază în sistemul de planificare și gestiune în rețea este graful-rețea (modelul rețea), care prezintă modelul informațional-dinamic, în care sunt prezentate legăturile și rezultatele tuturor lucrărilor, necesare pentru atingerea scopului final.

Graful planului în rețea reprezintă un model dinamic informativ, care reflectă legăturile și rezultatele tuturor operațiilor necesare pentru atingerea scopului final al elaborării. Graful planului în rețea ne răspunde la următoarele întrebări:

ce trebuie să facem;

cît timp e necesar;

cine să execute;

care e dependența lucrărilor efectuate acum și aici de cele efectuate atunci și acolo.

Graful de rețea se construiește, folosind următoarele elemente de bază:

Lucrul – procesul sau acțiunea, care trebuie să fie îndeplinită pentru atingerea unui scop. Lucrările au nevoie de un anumit timp. Lucrul poate fi de caracter real (însăși procesul de muncă) și de caracter fictiv (legătura logică între lucrări).

Evenimentul – înregistrează momentul săvârșirii lucrului.

Drumul rețelei – orice consecutivitate a lucrărilor în care evenimentul final al unei lucrări coincide cu evenimentul inițial al lucrării următoare.

În timpul alcătuirii grafului planului în rețea la nivelul salariaților responsabili este convenabil de a alcătui în primul rând, lista evenimentelor și operațiilor lucrărilor, apoi reprezentarea grafică a grafului (se anexează).

În proiectul meu, pentru a cheltui timpul util, am inclus doi lucrători (A și B) care vor lucra paralel la unele etape de operații ce pot fi executate independent.

Tab. 4.

Operațiile necesare pentru elaborarea programului.

Notă:

C – calculator închiriat printr-un acord

S – calculator special închiriat

Recomand de a distribui versiunea beta (cu timp de funcționare redus). Astfel cei ce vor testa tehnologia propusă pot încerca posibilitățile noii oferte și să comunice despre problemele apărute sau despre noile facilități care ar îmbunătăți lucrul.

4.3. Calculul economic

Evaluarea prețului. Este destul de problematic de a evalua eficiența economică a programului elaborat din cauza peții de soft nestabilizate, lipsa softului de elaborare licențiat etc. Toate calculele sunt orientate pe piața curentă, prețurile fiind influențate de timp într-o mare măsură. Pentru elaborarea softului propus în această lucrare în timp redus și la un preț redus la prima etapă este angajat un programator, la a doua etapă și a treia – doi programatori.

Standardul CORBA elaborat de OMG asigură compatibilitatea pe diferite platforme. Anume din aceste considerente el este ales pentru proiect. Deoarece softul necesar este accesibil gratis (sau practic gratis), costul lui nu se va lua în considerație. La evaluarea costului programului se ia în considerare costul lucrului unui programator pe ore, cum și a costului de folosire (închiriere) a tehnicii respective de calcul.

La prima fază avem nevoie doar de un programator. În decurs de 12 zile el efectuează următoarele operații: formulează problema, studiază tehnologiile în acest domeniu, studiază programele soft analogice, studiază necesitățile peții pentru care se elaborează softul, definește scopurile principale ale programului și posibilitățile, caută softul necesar.

Costul unei ore de lucru a unui programator este de 5 lei (daca in țările civilizate este minimum 5$ ora, apoi în Moldova patrioții prețuiesc în valuta națională). Ziua lucratoare se consideră de a fi egală cu 8 ore, atunci cheltuielile vor fi de 40 lei pe zi numai pe salariu. Costul arendei a unui calculator special este de 15 lei pe oră, nespecial – 10 lei pe oră, deci 120 sau 80 de lei pe zi corespunzător. În 7 zile ale primei etape avem astfel de cheltuieli (ne orientăm după datele din Tab. 4):

(7*40)+(0.5*80) =320 lei

Primul termen aici și în continuare va prezenta cheltuielile pe salariu, al doilea – pe arenda calculatorului.

În faza II lucrează 2 programatori în paralel. Primul este conducător și efectuează următoarele operații: configurarea serverului, elaborarea aplicației server, coordonarea cu partea aplicație. A doilea programator efectuează următoarele operații: elaborarea clientului, coordonarea cu partea server. Apoi partea client și server va fi încorporată într-un program unic. Pentru implementarea interfeței grafice și asamblarea variantei finale avem nevoie doar de un programator.

Evaluăm cheltuielile (vezi Tab. 4):

Cheltuieli pe salariu:

(2*5+8)*40=720 lei

Cheltuieli pe arendă:

2*5*80+3.5*80+4.5*120=1130 lei

In total: 1850 lei

La etapa III doi programatori efectuează astfel de operații: citirea codului, căutarea greșelilor, redactarea codului într-o formă mai citabilă.

După ce se oferă beta versiune programului pentru testarea publică, programatorii părții server și client efectuează următoarele operații: testarea pe alt hard, analiza informației primite în procesul testării externe, corectarea codului. Evaluăm cheltuielile totale la etapa III (după Tab. 4)

Cheltuieli pe salariu (faza III):

(2*4+6)*40=480 lei

Pe arendă (faza III):

(2*3+3)*80+(2*1+1)*120=1080 lei

În total (faza III) – 1560 lei

Cheltuielile de salariu în total pentru toate trei faze:

320+720+480=1520 lei.

Calculăm defalcările în fondul social

(31%) – 520.8 lei

Deci cheltuielile totale pentru elaborarea și implementarea softului constituie:

320+1850+1560+520.8=4810.8=4251 lei

Evaluarea eficacității. Analiza peții ne dă posibilitatea să împărțim cumpărătorii potențiali în câteva categorii.

Prima categorie – instituțiile de învățământ. Au nevoie de acest soft pentru instruire.

A doua categorie – organizațiile comerciale.

A treia categorie – persoane fizice: studenți, programatori etc.

Softul elaborat se va vinde:

pentru instituții de învățămînt – 50 lei

pentru organizații comerciale – 100 lei

pentru pesoane fizice – 70 lei.

În primul an se prognozează vânzări în volum de: 15 programe prima categorie, 20 programe pentru organizații comerciale, 50 de programe pentru persoane fizice.

În total venitul estimat:

15*50+20*100+50*70=6250 lei

Beneficiul estimat

6250-4251=1999 lei.

Coeficientul normal de eficiență este Eh=0.2.

Timpul de recuperare în acest caz este de Trec=1/E=1/0.2=5 (ani)

În cazul nostru coeficientul de eficiență este de Ecalc=1/Trec

Trec=Ctot/B, unde Ctot – cheltuielile totale, B – beneficiul

Trec=4251/1999=2.13

Erec=1/2.13=0.47>0.2 Deci coeficientul de eficiență în cazul dat e mai mare decît coeficientul normal, ceea ce confirmă eficiența economică de elaborare a softului precăutat.

5. PROTECȚIA MUNCII LA ÎNTREPRINDERE

5.1. Aprecierea pericolului și soluționarea problemelor de protecție a mediului ambiant

Viața actuală este de neânchipuit fără calculatoare, dar odată cu exploatarea lor este nevoie de a fi la curent și cu factorii respectivi ce se răsfrâng negativ asupra sănătății.

În multe țări, îndeosebi în cele cu nivelul de trai mai scăzut, predomină tehnica învechită, mult dăunătoare pentru sănătate.

Fiecare profesie este însoțită de un set specific de boli. Chiar prima, prin care trecem mai toți este profesia de școler – urmată de scolioz, adică înclinarea coloanei vertebrale. Iar după absolvirea instituției de învățământ, odată cu alegerea profesiei, alegem și pachetul respectiv de înbolnăviri. Căpitanul corabiei maritime, de exemplu, care stă ore în șir în cabina de comandă alături de volan, pentru romantica călătoriilor îndelungate se răsplătește cu tromboflebit, dilatarea venelor varicoz, reumatism. Cosmonautului îi “luminează” – boala oaselor, minerului – boli respiratorii etc. Profesiile legate de calculatoare, nu sunt o excepție:

Cum s-a stabilit, mous-ul poate “mușca”. Această boală, mai mult e caracteristică pentru cei ce se ocupă de grafica pe calculator.

Dintâi mâna se încordează, apoi de la degete până la cot se simte o durere, iar după aceasta mâna amorțește.

Se efectuiază un șir de exerciții cu mâna; se fac pauze între durate lungi de încordare.

Psihologii au depistat o nouă boală: computeromania sau dependența de Internet, de jocuri, de unele produse soft, etc.

Ochi umflați, roșii, grad înalt de oboseală.

Se consultă psihologul respectiv și se urmează cursul necesar de tratament.

Radiația primită îndeosebi de la monitoare, câmpul electrostatic, câmpul electromagnetic dau complicații la sistemul cardiovascular, dăunează sarcinii, micșorează imunitetul. După un timp îndelungat la calculator, sperma își coboară activitatea. Însă, totuși modelele noi de hard, în comparație cu cele vechi, treptat reduc daunele asupra activității organismelor vii.

Standardele internaționale TCO 95, TCO 99 existente și aplicate în practică, ca de altfel și alte standarde în prezent tind a limita și minimiza câmpurile, iradierile și descompunerile chimice produse de tehnica respectivă de oficiu.

Iradieri ionizate reprezintă iradierea electro-magnetică cu o capacitate de ionizare a moleculelor. Dacă se provoacă ionizarea moleculelor organismului uman, atunci legăturile între molecule se distruge și ca rezultat apar diferite boli. Capacitatea de ionizare o au următoarele particule: X- iradieri, fluxul de electroni, substanțele radioactive.

În cazul monitoarelor cel mai semnificativ tip de iradiere ionizată este – iradiere, care însă este foarte mică, de obicei nu depășește normele biologice. Celelalte tipuri de iradieri pot fi neglijate deoarece greu pot fi depistate. – iradierea apare în urma ciocnirii electronilor cu atomii substanței luminofore sau cu atomii ecranului din sticlă.

Iradierea ionizată asupra omului poate provoca următoarele acțiuni:

locale – acțiuni de scurtă durată cu doze mari, care aduce la traume locale: îmbolnăvirea pieii, pierderea pieii, pierderea unghiilor, defectarea oaselor, cancer;

totale – reprezintă iradieri îndelungate cu doze mici, aduce la îmbolnăvirea sângelui (leucemie).

Pentru a micșora iradierea ionizată a monitoarelor moderne, pe suprafața lor se aplică o foaie metalică străvezie, care atenuează fluxul de iradiere. O altă cale de apărare împotriva iradierii ionizate este procurarea unui ecran protector, care se instalează pe monitor și are același efect ca și foaia metalică străvezie.

Câmpul electrostatic apare pe ecranul monitorului este rezultatul bombardării permanente a monitorului cu fascicolul de electroni emis de catod. Astfel sarcina electrică, case se acumulează pe suprafață monitorului, formează câmpul electrostatic. Fenomenul electrizării statice este legat și de starea aerului din mediu. În condiții normale aerul se caracterizează cu proprietăți izolatorii înalte, însă sub acțiunea razelor solare și celor cosmice, radiației materialelor radioactive a scoarței pământului și a altor factor ionizatori, moleculele neutrale a aerului se ionizează, formând ioni pozitivi și negativi – purtători ai sarcinii electrice. Dacă intensitatea câmpului electric, format de materialele, de dispozitivele de curent continuu și de obiectele, care ușor se electrizează, este mare, atunci ionii liberi obțin energie cinetică suficientă pentru a forma ioni noi la ciocnirea lor cu moleculele neutre. În urma ionizării aerul își pierde proprietatea sa de izolator (devine conductibil) și descărcarea electrică latentă se transformă într-o descărcare sferică, adică are loc o străpungere electrică a aerului.

Descărcarea electricității statice poate provoca o explozie, incendiu și alte accidente. Influența sistematică a câmpului electrostatic de intensitate înaltă asupra corpului omului poate duce la unele dereglări funcționale a sistemului central nervos, a sistemului cardio-vascular și a altor organe.

Din aceste motive, intensitatea maxim-admisibilă a câmpului electric la locurile de muncă este normată:

Tab. 5.

Intensitatea maxim-admisibilă a câmpului electric la locurile de muncă

Măsurile principale de micșorare a intensității câmpului electric la locul de muncă sunt:

îndepărtarea surselor a câmpurilor electrostatice din zona personalului care deservește aparatura;

ecranarea sursei câmpului sau a locului de muncă;

utilizarea neutralizatorilor de sarcini electrice statice;

umezirea materialului care se electrizează;

schimbarea materialelor, care ușor se electrizează cu materiale ce nu se electrizează;

alegerea suprafețelor care contactează conform condițiilor de electrizare minimă;

modificarea procesului tehnologic în așa mod ca să se micșoreze nivelul de electrizare;

alegerea materialelor și suprafețelor care greu electrizează alte corpuri sau le electrizează cu sarcini de polaritate diferită;

instalarea în toate încăperile, unde se află oameni, a podelelor care conduc curentul electric.

În calitate de măsură de protecție individuală a omului de la electricitatea electrostatică poate servi încălțămintea ce conduce curentul electric, albituri, halat, etc. adică tot ce asigură legătura electrică a corpului omului cu pământul.

Câmpul electromagnetic. Influența câmpurilor electromagnetice de mare intensitate asupra omului constă în absorbția de către țesuturile corpului uman a energiei, însă influența principală îi revine câmpului electric. Nivelul de influență a câmpurilor electromagnetice asupra omului depinde de frecvență, de puterea emisiei, de durata acțiunii, de regimul de emisie (prin impulsuri sau continuu), și de asemenea de proprietățile individuale ale organismului.

Influența câmpului electric de frecvență joasă provoacă dereglări în activitatea funcțională a sistemului cardio-vascular, și chiar la schimbări privind componența sângelui.

Influența câmpului electromagnetic de frecvență înaltă se reflectă sub forma efectului termic, care duce la ridicarea temperaturii corpului, la supraîncălzirea locală a țesuturilor corpului și a organelor cu o termoreglare slabă. Ca rezultat unii lucrători suferă din cauză insomniei, simt dureri în regiunea inimii, dureri de cap, ușor obosesc.

Pentru a micșora puterea de emisie a sursei câmpului electromagnetic pot fi utilizate următoarele mijloace tehnice:

utilizarea unui astfel de regim de lucrul, în care dispozitivul lucrează cu o putere mai mică decât cea proiectată;

lichidarea locurilor de emisie suplimentară;

micșorarea undelor reflectate prin ajustarea sarcinilor, etc.

Alegerea corectă a regimului de lucru a personalului și a utilajului permite micșorarea prezenței omului în zona de acțiune a câmpurilor electromagnetice.Se efectuiază un șir de exerciții cu mâna; se fac pauze între durate mari de încordare.

5.2. Calcularea protecției “legare la nul”

Legarea la nul este o măsură de protejare a omului de electrocutare prin deconectarea strictă și în viteză a rețelei în caz de apariție a tensiunii pe carcasă (străpungerea izolării). Deconectarea strictă se efectuează, dacă curentul de scurt circuit format prin fază și firul nul este destul de mare pentru ca declanșatorul să funcționeze corect.

Scopul calculării instalației “legarea la nul” – determinarea secțiunii firului nul, care satisface condiția funcționării protecției maximale de curent. Valoarea protecției se determină după puterea instalației electrice proiectate (exploatate).

Curentul de scurtcircuit trebuie să depășească valoarea protecției conform cerințelor (pentru siguranțe Is.c. ≥ 3 In, unde In – curentul nominal al siguranței). Modul de calculare este următorul:

Se calculă rezistența circuitului “faza – nul”:

;

unde: Rf – rezistența activă a firului fazic, Ohm;

Rn – rezistența activă a firului nul, Ohm;

Xc – rezistența inductivă a rețelei “faza – nul” și pentru rețelele cu tensiune joasă (până la 1000 V) și firele din cupru și aluminiu, deci Xc este foarte mică (Xc = 0).

Rezistențele active se calculă după formula:

; ;

unde Lf, Sf, Ln, Sn – lungimea și secțiunea firului fazic și nul corespunzător;

–rezistența electrică specifică: pentru cupru, Cu0.018 Ohm * (mm / m);

pentru aluminiu Al = 0.028 Ohm * (mm / m);

Deoarece materialul din care s-a confecționat cablul (firul) este cupru, lungimea firului de fază = 400 m, iar secțiunea firului = 16 mm vom obține următoarele calcule:

;

Pentru lungimea firului nul Ln = 400 m și secțiunea firului = 10 mm vom obține:

;

curentul de scurt-circuit calculat în A:

;

unde Zt – rezistența transformatorului.

Pentru tensiunea U = 380 V și Zt / 3 = 0.0354 Ohm (din tabel) obținem următoarele calcule:

Se compară Is.c. cu In: dacă Is.c. ≤ 3 In pentru siguranță atunci se aleg conductoare de o secțiune mai mare și calculul se repetă.

Deoarece In este egal cu 63 A obținem:

Rezultă că, curentul de scurtcircuit depășește valoarea cerințelor obiectului protecția muncii (pentru siguranțe) sînt respectate.

5.3. Securitatea antiincendiară

Incendiu se numește procesul necontrolat de ardere în afara unui loc de ardere special amenajat, ce aduce daune materiale.

În cadrul oricărei organizații, sau întreprinderi trebuie să existe mijloace de anunțare, de apel rapid la serviciile orășenești antiincendiare în cazul apariției incendiului. Pentru obiectele de o importanță majoră sau periculoase, este recomandată posibilitatea legăturii telefonice directe cu secția antiincendiară orășenească. Semnalizarea antiincendiară se execută cu ajutorul diferitor sisteme. Pentru a anunța despre incendiu se utilizează legătura telefonică, legătura radio, sirena, semnalizarea cu ajutorul clopotelor etc. Mijloacele de anunțare despre incendiu trebuie să fie disponibile toate 24 ore.

Semnalizarea incendiului se execută de diferite sisteme. Cel mai simplu și mai des utilizat este semnalizatorul manual, care se activează prin apăsarea butonului. Așa semnalizatoare se instalează pe scări, în paliere și sînt vopsite în culoarea roșie.

În timpul de față larg se utilizează semnalizatoarele automate, care conform principiului de lucru se împart în cele termice, de fum, combinate și optice.

Semnalizatoarele termice de acțiune maximă acționează la deformarea unei plăci bimetalice, la încălzirea ei până la 60, 80, 100 °C în dependență de reglaj.

În semnalizatoarele termice semiconductoare, în calitate de elemente sensibile sânt termorezistențele, din cauza cărora se schimbă curentul în rețea la încălzirea lor.

Termosemnalizatoarele diferențiale reacționează la ridicarea rapidă a temperaturii (la 30°C timp de 7 secunde), iar în calitate de element sensibil se folosește elementul la încălzirea căruia apare termo-FEM.

În semnalizatoarele de fum în calitate de element sensibil se utilizează camera de ionizare, în care sub acțiunea izotopului radioactiv (plutoniu-239) apare un curent de ionizare. Apariția fumului în cameră mărește consumul de raze ceea ce cauzează micșorarea curentului de ionizare.

În semnalizatoarele combinate se folosește interconectarea semnalizatorului de fum cu cel termic. La camera de ionizare se mai conectează în plus încă o termorezistență.

Semnalizatoarele combinate reacționează atât la apariția fumului, cât și la schimbarea temperaturii. Semnalizatoarele optice reacționează la razele ultraviolete ale spectrului flăcării, deoarece elementul sensibil reprezintă contoarele de fotoni. Semnalizatoarele de diferite tipuri pot controla suprafețe de la 15 până la 100 m2.

Semnalizatoarele de fum și cele combinate nu se instalează în încăperi umede și prăfuite, sau în încăperi în care se conțin vapori de acizi, baze, sau unde temperatura este mai mare decât 80 °C, deoarece în așa locuri poate avea loc acționarea falsă ale semnalizatoarelor.

5.3.1. Cauzele apariției incendiilor

Procesul de ardere este posibil în cazul când este prezentă substanța arzătoare, sursa de aprindere și oxidantul, care în cele mai dese cazuri este oxigenul, ce se conține în aer. La reducerea concentrației oxigenului din aer până la 12-14% arderea majorității substanțelor se oprește. Procesul de ardere este posibil și în lipsa oxigenului – deoarece hidrogenul, stibiul și unele metale ard în clor. Unele substanțe (turba, cărbunele, funinginea, cârpele uleioase), numite piriforme pot să se!autoinflameze la contactul cu aerul. Auto-aprinderea acestor substanțe are loc în urma proceselor chimice, termice sau microbiologice. Substanțele se încălzesc sub acțiunea căldurii ce vine din afară, ce se elimină în timpul reacțiilor chimice, și de asemenea în rezultatul acțiunii micro-organismelor.

În procesul de producție, incendiul poate apare în urma unor cauze de ordin electric sau ne electric. La cauzele de ordin ne electric se referă:

funcționarea proastă a instalațiilor de producție și dereglarea procesului tehnologic; comportarea iresponsabilă sau ne atentă cu focul (fumatul, lăsarea fără supraveghere a dispozitivelor de încălzire);

construcția incorectă sau dereglarea sistemului de ventilare;

autoinflamarea materialelor.

La cauzele de ordin electric se referă:

scurtcircuitul;

supraîncărcarea conductoarelor;

rezistența mare de trecere;

scânteierea;

electricitatea statică și descărcarea fulgerului;

arcul electric ce apare în timpul sudării electrice și în timpul operațiilor greșite cu aparatajul de comutare;

instabilitatea tensiunii electrice din rețea – ca rezultat se aprind unele circuite integrate din calculator, sau monitor, etc.

5.3.2. Mijloacele de stingere a incendiilor

Cel mai răspândit mijloc de stingere a incendiilor este apa, ce posedă o capacitate termică enormă și o temperatură mare de vaporizare, ceea ce permite de a lua căldura din focarul incendiului. În același timp apa nu poate fi folosită pentru stingerea soluțiilor ușor inflamabile (benzina, gaz lampant, ulei mineral), deoarece din cauza greutății relative mari, ea se adună sub aceste soluții și împrăștiindu-se ușor și rapid măresc considerabil suprafața de ardere. De asemenea, se interzice stingerea cu apa a substanțelor ce elimină reagenți inflamabili (carbid de calciu, silitra) la contactarea lor cu apa.

Pentru stingerea instalațiilor electrice sub tensiune, apa nu poate fi folosită fără măsuri speciale de protecție a oamenilor de la atingerea curentului electric prin getul de apa. În clădiri, în locuri special rezervate, se instalează scuturi antiincendiare, ce conțin unele rechizite necesare pentru stingerea focului: robinet de presiune, țeava elastică, în unele locuri nisip, găleți, topoare și alte instrumente de distrugere a pereților.

O mare răspândire au căpătat mijloacele automate de detectare și stingere a incendiului. Principiul de funcționare a acestora, în majoritatea cazurilor, se bazează pe prezența unor țevi în interiorul cărora se află apă sub presiune, și niște dopuri din materiale ce se topesc ușor, introduse în aceste țevi. La ridicarea temperaturii în încăpere, dopurile se topesc și apa din țevi sub acțiunea presiunii stropește focul.

O modalitate efectivă în prevenirea incendiilor, minimizarea daunelor și reducerea jertfelor omenești este familiarizarea muncitorilor, copiilor și a populației în întregime cu regulile de comportare în situații de incendiu, modalitățile de stingere a focului, normele elementare de prevenire a incendiului.

5.3.3. Securitatea antiincendiară în sălile de calcul

Pentru a analiza nivelul securității incendiare a locurilor de muncă, a zonelor de producție, a sălilor de calcul se folosește următoarea clasificare :

1) Clasificarea materialelor de construcție și construcțiilor după nivelul de inflamabilitate:

ne inflamabile;

greu inflamabile;

inflamabile;

2) Clasificarea construcțiilor după nivelul rezistență la incendiu (limita nivelului de rezistența la incendiu – timpul în ore din momentul începerii incendiului până la momentul apariției crăpăturilor).

3) Clasificarea încăperilor după RCIE ("Regulile de Construcție a Instalațiilor Electrice"):

cu pericol de explozie;

cu pericol de inflamare.

Criteriile de apreciere:

Conținutul de substanțe inflamabile;

Regimul termic de prelucrare.

4) Clasificarea proceselor de producție după pericolul incendiar:

cu pericol de explozie;

cu pericol de explozie și inflamare;

cu pericol de inflamare;

fără pericol de inflamare;

Conform primei clasificări (clasificarea materialelor de construcție și construcțiilor după nivelul de inflamabilitate) sala de calcul este ne inflamabilă deoarece sînt prevăzute multe măsuri de prevenire a incendiului cum ar fi: sisteme de semnalizare, podele din metal, mese metalice, pereții în sala de calcul se acoperă cu substanțe ne arzătoare.

După clasificarea a doua (clasificarea construcțiilor după nivelul rezistență la incendiu), de obicei sălile de calcul se află în clădiri construite sau din beton armat sau coteleț (pentru instituțiile de învățământ). Ambele materiale de construcție au o rezistență la incendiu mare – pereții în sala de calcul se acoperă cu substanțe ne arzătoare.

După clasificarea a treia (după Regulile de Construcție a Instalațiilor Electrice), luând în considerație conținutul mic de substanțe inflamabile și regimul termic de prelucrare, sălile de calcul pot fi caracterizate – cu pericol mic de inflamare.

Sălile de calcul după pericolul incendiar a proceselor de producție se referă la categoria celor cu pericol de inflamare ceea ce se explică prin faptul, că în încăpere se găsesc substanțe inflamabile: de obicei, aceste săli sînt echipate cu utilaj care conține masă plastică, care totuși arde. Trebuie însă de menționat, în ultimul timp masa plastică utilizată la fabricarea tehnicii de calcul are o astfel de componență chimică, care nu arde sau care se autostinge după primele secunde de ardere. În sala de calcul de obicei lipsesc așa atribute cum ar fi : covoare, obiecte din lemn, dulapuri cu cărți, etc. Reiese că, cu toate că pericolul de inflamare există, el este foarte mic.

Securitatea antiincendiară poate fi asigurată prin măsuri de profilaxie antiincendiară și prin respectarea regulilor de prevenire a incendiului. Noțiunea de profilaxie antiincendiară include un complex întreg de măsuri, necesare pentru preîntâmpinarea apariției incendiului sau reducerea urmărilor lui.

5.3.4. Măsurile profilactice de luptă cu cauzele incendiului în sălile de calcul

Măsurile de eliminare a cauzelor incendiilor și exploziilor se divizează în:

măsuri tehnice;

măsuri de exploatare;

măsuri organizatorice;

măsuri de regim.

La măsurile tehnice se referă – respectarea normelor antiincendiare la construcția clădirilor, sistemului de încălzire, sistemului de ventilare, la alegerea și montarea echipamentului electric, sistemele paratrăsnet.

La măsurile de exploatare se referă – exploatarea corectă a utilajului de producere, instalațiilor de compresie, cuptoarelor și a altor dispozitive de forță și a utilajului electric; menținerea corectă a încăperilor, a clădirilor și a teritoriului întreprinderii.

La măsurile organizatorice se referă – studierea regulilor antiincendiare de către personalul întreprinderii, sau organizației, editarea instrucțiunilor și placatelor necesare.

La măsurile de regim se referă – interzicerea sau impunerea unor restricții de utilizare a focului deschis, fumatului, a lucrărilor de sudare în anumite locuri.

La proiectarea și construcția clădirilor și încăperilor, (în particular a sălii de calcul), de asemenea trebuie să se respecte măsurile antiincendiare:

protecția construcțiilor de lemn (dacă sînt) se realizează prin îmbibarea cu substanțe

chimice ne inflamabile (antipirene), acoperirea cu vopsele refractare;

pentru limitarea extinderii incendiului se fac obstacole antiincendiare: pereți, bariere, uși, porți, ferestre. Toate acestea trebuie îndeplinite din materiale ne arzătoare.

Măsurile active de luptă cu incendiile în sălile de calcul:

izolarea locului de ardere de aer cu ajutorul substanțelor solide (nisip, pături, etc.);

răcirea focarului până la unele temperaturi stabilite, care se face cu ajutorul apei, însă apa are restricții la stingerea substanțelor inflamabile, instalațiilor electrice, etc., de aceea mai des se folosește bioxidul de carbon, care în reacție cu aerul micșorează temperatura până la -78 C;

reducerea vitezei petrecerii reacției chimice în flacără – în acest scop se folosesc prafurile;

distrugerea mecanică a flăcării în rezultatul acționării asupra ei a unui get puternic de gaz sau apa.

Pentru stingerea focului în sălile de calcul se utilizează extinctoarele cu CO2 și praf, care posedă o viteză mare de stingere, timp îndelungat de acțiune, posibilitate de stingere a instalațiilor electrice, eficacitate înaltă de luptă cu focul.

Reieșind din normele securității antiincendiare, pentru o sală de calcul cu suprafața de 100 m˛ sînt necesare următoarele mijloace primare de stingere a incendiului:

un extinctor de CO2 de tip OU-5 sau OU-8, cu ajutorul căruia se poate stinge flacăra de pe diferite materiale și instalații electrice (până la 1000 V);

un extinctor de spumă chimică (OHP-10) sau un extinctor de spumă (OVP-5 sau OVP-10) pentru stingerea materialelor solide și lichidele inflamabile (în afara de instalațiile sub tensiune);

pâslă sau asbest (1X1; 2X1,5; 2X2 m).

Sălile de calcul trebuie să fie echipate cu semnalizatoare incendiare – pentru semnalizarea apariției incendiului. În calitate de semnalizatoare incendiare pentru sălile de calcul se utilizează semnalizatoarele de fum fotoelectrice de tip IDF-1 sau DIP-1.

În dependență de înălțimea podului (3 m) și aria podelei (40 m.), după norme este suficientă prezența a trei semnalizatoare pentru toată încăperea. Aceste dispozitive se caracterizează printr-o viteză mare, sensibilitate înaltă și care funcționează după principiul difuziunii căldurii de către particulele de fum.

Avantajul acestor semnalizatoare constă în lipsa inerției, controlul unei suprafețe mari. Neajunsul lor este posibilitatea acționării false și costul ridicat.

Toate sistemele, care utilizează curent electric – dispozitivele de repartizare, aparatele de măsură, sistemele de siguranță și alte aparate electrice trebuie să fie montate pe suporturi care nu ard (marmor, textolit, asbest, etc.).

Măsurarea rezistenței izolației circuitului electric trebuie să se execute în fiecare an în încăperile cu mediul normal, iar în încăperile cu umiditate înaltă, cu exces de gaze și aburi – nu mai rar de 2 ori pe an.

Suportul metalic, carcasele echipamentelor electrice și electronice, de asemenea țevile metalice, prin care trece sârmele electrice, trebuie să fie conectate la pământ.

În gospodăria obiectelor electrice deseori se utilizează acumulatoarele, încărcarea cărora se însoțește de emisia gazelor și aburilor explozive și periculoase pentru sănătatea omului. Din aceste motive acumulatoarele trebuie instalate în încăperi aparte, bine izolate de celelalte, cu o ventilare corespunzătoare.

Aceste măsuri sînt mai mult valabile pentru acumulatoarele produse până în anul 1990.

Astăzi acumulatoarele, care se utilizează la alimentarea calculatoarelor, sînt proiectate și fabricate după alte tehnologii mai avansate, și încărcarea lor nu se mai însoțește de emisia gazelor și aburilor explozive și periculoase.

În caz de incendiu trebuie să fie prevăzută posibilitatea evacuării rapide a oamenilor. Căile de evacuare trebuie să asigure evacuarea tuturor oamenilor, care se află în încăperile întreprinderii într-un timp foarte scurt.

Numărul ieșirilor de evacuare din încăperi și de la fiecare etaj trebuie să se stabilească în corespundere cu ГОСТ 2.09.02-85, și să fie nu mai puțin de două ieșiri.

5.4. Analiza condițiilor de muncă și factorii dăunători și periculoși la locul de muncă

Analiza condițiilor de lucru și aprecierea factorilor dăunători se apreciază conform cerinților și standardelor elaborate special de comisiile pentru Tehnica Securității care sunt ca criterii de bază pentru anliza condițiilor la locul de lucru. Analiza se efectuiază conform STAS 12.1 05 .

Tab. 6.

Standartizarea și caracteristica factorilor pentru tehnica securității la locul de muncă

Parametrii necesari ai microclimei în încăperile de producție se asigură prin diferite metode. Pentru menținerea normelor aflării substanțelor dăunătoare în aer la locul de muncă se iau măsuri spre izolarea izvoarelor de substanțe dăunătoare, limitarea timpului de aflare a oamenilor în încăperile cu conținutul atmosferic dăunător, folosirea tehnologiilor avansate pentru micșorarea conținutului de substanțe dăunătoare în aer, etc.

Una din tehnicile folosite în procesul de producție pentru eliminarea substanțelor dăunătoare din aerul zonei de lucru este venilarea. Sistemele de ventilare asigură parametrii necesari ai microclimei în aerul zonei de lucru. Ventilarea este divizată în două categorii în dependență de natura acestea: venilarea naturală și artificială.

La ventilarea artificială schimbul de aer se efectuază cu ajutorul ventilatorului prin sistemele de canale cu aer. Reeșind din principiul de lucru al ventilatorului, ventilarea artificială se clasifică în următoarele categorii: de tragere, de extragere, de tragere-extragere. În sistemele de ventilare artificială aerul tras în încăpere de lucru poate fi uscat, umezit, răcit. Adică parametrii aerului tras, la ventilarea artificială pot fi schimbați.

În prezent pentru asigurarea normativelor de ventilare a aerului zonei de lucru sunt folosite dispozitive de condiționare a aerului. Cu ajutorul dispozitivului de condiționare aerul poate fi uscat, umezit, ozonat, deodorat, răcit sau încălzit.

Conform normativelor sanitare-igienice fiecărui lucrător trebuie de-asigurat de la 20 m3/h pînă la 30 m3/h. Raportul între volumul încăperii și numărul de persoane, care lucrează în această încăpere, nu terbuie să fie mai mic decît 20m3 . În lipsa substanțelor dăunătoare în încăpere, dacă volumul de aer pentru un lucrător e mai mare de 40m3, normativele de ven+tilare nu sunt reglamentate.

Deoarecesala laboratorului catedrei întră în categoria I- raportul volumului de aer din laborator și numărul de persoane care se află în laborator în timpul lucrărilor este mai mic decît 20m3 pentru o persoană, aerul zonei laboratorului trebuie ventilat. Volumul de aer care trebuie să fie tras trebuie să fie în diapazonul de la 20m3/h pentru o persoană pînă la 30m3/h. Deci trebuie de ales un așa tip de dispozitiv de condiționare care ar asigura cerințele expuse mai sus.

Un așa tip de aparat poate servi dispozitivul de tip BK-1000, care are următorii parametri tehnici:

volumul de aer tras –1000m3/h;

tensiunea de alimentare – 220V, 50 Hz.

5.4.1. Cerințele securității tehnice la începutul lucrului

Pînă la începutul propriu-zis a lucrului practic în laborator, studenții sunt obligați să studieze locul de lucru: dislocația dispozitivelor aflate sub tensiune, a întrerupătoarelor de curent, caracteristica tehnică a utilajului, instrucțiunile de exploatare a dispozitivelor folosite la efectuarea lucrărilor de laborator. Trebuie de studiat principiul de lucru a echipamentului și metodele de operare inofensive în timpul lucrului.

5.4.2. Cerințele securității tehice în timpul lucrului

Este interzisă cuplarea echipamentului la rețea fără permisiunea persoanei responsabile de lucrări. Cuplarea în rețea a echipamentului care în timpul efectuării lucrării de laborator nu este folosit.

Studenții neatestați de lector nu sunt admiși la lucrări de laborator.

În procesul efectuării lucrării de laborator se interzice categoric:

abaterea de la subiect cît și atragerea altora;

părăsirea locului de lucru lăsînd utilajului sub tensiune;

efectuarea lucrului de reparație a utilajului aflat sub tensiune.

Dacă în procesul de lucru apar cazuri ieșite din comun (miros de izolație arsă, fum, etc.) utilajul se decuplează urgent de la rețea, informînd despre acseata dirigintele de lucrări sau responsabilul de laborator.

5.3.4. Cerințele ergonomice privind locul de muncă

Ergonomica și estetica procesului de producere sunt părți componente ale culturii procesului de producere, adică complexului măsurilor de organizare a muncii îndreptate spre crearea condițiilor de lucru prielnice.La baza ridicării culturii de muncă stau cerințele organizării științifice a procesului de muncă. Cultura procesului de muncă poate fi atinsă prin organizarea corectă a procesului de muncă și a relațiilor între coloboratori, organizarea locurilor de muncă, transformarea estetică a mediului înconjurător. Pentru crearea condițiilor de muncă plăcute este necesar de a considera particularitățile psihofiziologice a omului și condițiile igienice generale.

Iluminarea rațională a încăperilor de lucru stă la baza ridicării eficacității de lucru, preîntîmpină oboseala generală și a văzului, crează condiții psihologice optimale și determină dispoziția bună. Iluminarea naturală suficientă crează simțul de legătură directă cu mediul inconjurător. Este necesar de subliniat acțiunea biologică binevenită a razelor solare. Deaceea este necesar de amplasat locurile de muncă în așa mod încît ele să nimerească în zona atingerii razelor solare. În dependență de condițiile de muncă și partucularitățile lucrului îndeplinit, pentru iluminarea artificială pot fi folosite instalațiile de iluminat, generale și locale, cu o anumită caracteristică de lumină. Lămpile de lumină directă au fost folosite limitate din cauza creării umbrelor abrupte. Lămpile de lumină reflectată pot fi folosite în cazuri cînd este necesitatea de a lumină omogenă și slabă. Lămpi de lumină semireflectată ce sunt echipate cu abajur din sticlă mată, care posedă proprietăți de a dispersa lumina se află pe masa de lucru. În calitate de instalație de iluminat general este recomandabil de folosit lămpi cu lumina dispersată. Lămpile de iluminare locală trebuie să fie mobile și la necesitate să asigure shimbarea direcției luminii. Fiecare loc de muncă, indiferent de amplasarea lui față de ferestre trebuie să aibă și instalație de lumină locală. Este recomandabil de folosit lămpi luminiscente, spectrul luminii cărora aproape coincide cu cel al luminii naturale. Pentru a exlude reflectarea razelor directe ale luminii de pe ecranul monitorului instalațiile de iluminare se aranjază pe ambele părți de la locul de muncă, paralel cu direcția văzului operatorului, și peretele cu ferestre (Fig.6)

Fig. 6. Amplasarea instalațiilor de iluminat general față de locurile de muncă ale operatorilor

1 – ferestre; 2 – instalațiile de iluminat; 3 – locul de muncă;

O astfel de amplasare a instalațiilor de iluminat permite de a le conecta consecutiv în dependență de mărimea iluminatului natural și exclude iritarea ochilor de către linii alterate de lumină și umbră, care apare la amplasare lor paralelă.

Oformare cu culori a încăperilor și înverzirea lor nu numai micșorează tensiunea nervoasă dar și permanent susține buna dispoziție a lucratorilor și inspirația creativă în lucru.

Culoarea încăperilor de lucru influențează esențial asupra iluminării, stării psihofiziologice a omului, ansamblului arhitectutal al încăperii. Este cunoccut că nuanțele întunecate au proprietatea de a consuma o parte mare a luminii și prin aceasta micșorează iluminarea încăperii. Pentru oformarea cu culori a încăperilor se propune de a folosi în primul rînd acele culori care reflectă cel puțin 40-50% de lumină care cade pe o suprafață. Culorile pentru oformare a încăperilor trebuie să fie alese în conformitate cu condițiile climaterice.Culorile galben-verzi și verde-albastru influențiază în mod liniștitor, pe cînd culorile albastru deschis, albastru, violet pot influența în mod depresiv. La oformare cu culori a încăperilor trebuie de luat seamă de amplasarea ferestrelor, particularitățile arhitecturale ale încăperilor. Pentru asigurarea condițiilor de lucru optimale, oformarea cu culoare trebuie să fie alese ținînd cond de culorile monitorului. În cazul paletei monocrone, peretele înaintea operatorului trebuie să fie vopsite cu culoarea verde deshisă sau bej, iar în cazul paletei colorate – culoarea bej.

Un rol important îl joacă organizarea locului de muncă, care trebuie să satisfacă cerințele comoditații a efectuării lucrului și economisirii energiei și a timpului operatorului și utilizării raționale ale suprafetelor de lucru. Este necesar de stabilit zonele de atingere a mîinelor operatorului de display-ul, imprimantă și alte dispozitive periferice.Zonele date sunt stabilite pe baza datelor antropometrice ale corpului uman, permit de a amplasa corect elementele de dirijare.

Mișcările lucrătorului trebuie să fie de așa fel, ca grupurule de mușchi ale lui vor fi încărcate omogen, iar mișcările neproductive vor fi excluse.

Locurile de muncă trebuie să fie aranjate tot în conformitate cu cerințele comodității lucrului și optimizării mișcării. Locul de muncă de obicei este constituit dintr-un birou, scaun, o poliță pentru literatura profesională des folosită. Distanțele între componentele menționate trebuie să fie optimale, care nu limitează mișcările și în acelaș timp nu provoacă mișcări de prisos.

Concluzie

Realizările tezei de licență au fost obținute pe baza aplicării cunoștințelor teoretice și practice primite în cadrul cursului universitar de “Sisteme de operare”, “Programarea paralelă”, “Curs special”, “Interfețe și protocoale de rețea”, “Baze de date și cunoștințe”, “Rețele de calculatoare” și de fapt într-o oarecare măsură și toate celelalte cursuri. O a doua sursă foarte bogată în informații este Internetul, resursele cărui le studiez și aplic, și care în rezultatul căutărilor mi-a deschis noi orizonturi. Nu în ultimul rând vreau să menționez că un izvor nesecat de informații sunt colegii și prietenii ce activează în același domeniu.

A fost analizat principiul de funcționare a rețelei de telefonie mobilă: structura sistemului, modul de interacțiune între componentele lui, funcțiile componentelor principale. S-a atras atenția mai mult la bazele implementării în rețea pentru a crea un prototip, fiind că rețelele viitorului vor semăna mult cu cele de telefonie mobilă existente. Astfel, incorporând standardul CORBA, care este fondat și menținut de mai bine de 800 companii, care este creat nu pentru un an – doi și care este independent de platformă, am încercat să unesc posibilitățile acestor două rețele.

Programul a fost creat în Delphi, care este un mediu adaptat în promovarea a astfel de tehnologii ca CORBA. Interfața obiectului a fost descrisă în limbajul IDL. Eu cred că aceste pachete și produse soft, au perspectivă în viitor.

Efectuând această lucrare, simt că am mai acumulat câteva unități de experiență în domeniul respectiv. Au apărut noi interese, noi idei, noi propuneri. În acest context, vreau să menționez ca profesorii UTM nu degeaba și-au dat stăruința. Deci cred că sunt mândru că activez în domeniul “Tehnologii Informaționale”.

Bibliografia

I. Lungu, Gh. Sabau, “Sisteme informatice și baze de date”, București, 1994.

Object Management Group, “Object Management Architecture Guide”, OMG Document Number 92.11.1, September 1, 1992.

Object Management Group, “The Common Object Request Broker: Architecture and Specification”, OMG Document Number 91.12.1. Revision 1.1. December 1991.

Object Management Group, “The Common Object Request Broker: Architecture and Specification”, OMG Document Number 93.xx.yy, Revision 1.2. Draft 29 December 1993.

Object Management Group, “The Common Object Request Broker: Architecture and Specification”, Revision 2.0. July 1995.

R. Mihalca, A. Tataru., “Realizarea produselor program. Metode si tehnici de analiză si proiectare structurată”, București, Scripta 1994.

Sorin Tudor, “Tehnici de programare”, București, Teora 1995.

“Teach Yourself CORBA In 14 Days”, http://tk.cv.ua/unix/en/books/other/teach-corba-14/

T. Zacon, I. Costaș, T. Leahu, T. Bragaru, “Proiectarea sistemelor informatice. Metodica elaborarii proiectelor de diploma”, Chișinău, 1995 ASEM.

А. Цимбал, «Вопросы создания CORBA-приложений», http://interface.ru/borland/corba2.htm.

Дмитрий Рамодин, “IDL – заклинания эпохи распределенных вычислений”, http://www.webmagazine.ru/pcworld/1999/06/index.htm.

Kalinichenko L.A., “SYNTHESIS: a language for specification, design and programming of the heterogeneous interoperable information resource environments. IPI RAS”, September 1995, p. 105.

Kalinichenko L.A., “A Complementary Architecture Integrating Industrial and Semantic Interoperation Environments. Proceedings of the International Conference on Object-Oriented Programming and Technology EastEurOOPe’93”, Bratislava, November 1993.

Калиниченко Л.А., “Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния”, СУБД, # 1, 1996 г.

Калиниченко Л.А., Когаловский М.Р., “Стандарты OMG: Язык определения интерфейсов IDL в архитектуре CORBA”, СУБД, # 2, 1996 г.

М.Аншина, «Увлекательное путешествие с CORBA 3: по широким просторам распределенных приложений», http://www.osp.ru/os/1999/05-06/07.htm.

М.Аншина, «Симфония CORBA», http://www.osp.ru/os/1998/03/70.htm.

“CORBA – Архитектура распределенных объектов”, Serverul companiei Epsylon Technologies (www.demo.ru), http://www.citforum.ru/database/articles/corba.shtml.

“Интероперабельность брокеров в стандарте CORBA”, http://www.osp.ru/dbms/1996/03/.

«Язык определения интерфейсов IDL» (rtf – *.zip), http://www.corba.ru/idl_demo.zip.

http://www.corba.ru

http://www.inprice.ru

http://www.omg.org

Anexa 1.

Textul fișierelor pentru aplicația client

{fișierul proiectului PPhone.dpr}

program PPhone;

uses

Forms,

Phone in 'Phone.pas' {Form1};

{$R *.RES}

begin

Application.Initialize;

Application.CreateForm(TForm1, Form1);

Application.Run;

end.

{fișierul cu codul sursă Phone.pas}

procedure TForm1.SpeedButton1Click(Sender: TObject);

begin

Form1.Close;

end;

procedure TForm1.Timer1Timer(Sender: TObject);

begin

count:=count+1;

Shape15.Brush.Color:=clScrollBar;

{–––––––––––-}

case count of

0: Label2.Caption:='Scaning';

1: Label2.Caption:='Scaning.';

2: Label2.Caption:='Scaning..';

3: Label2.Caption:='Scaning…';

end;{case}

{–––––––––––-}

if count = 4 then begin

try

CorbaConnection1.Close;

Form1.CorbaConnection1.Open;

ClientDataSet1.ProviderName:='';

ClientDataSet1.Active:=false;

except

on E: Exception do begin

if E.Message='NO_IMPLEMENT' then begin

label1.caption:='NO NETWORK';

Shape15.Brush.Color:=clYellow;

end;{if}

end;{on E:}

end;{except}

{–––––––––––-}

if Form1.CorbaConnection1.Connected then begin

label1.caption:='IN NETWORK';

ClientDataSet1.ProviderName:='DataSetProvider1';

ClientDataSet1.Active:=true;

{**********}

if ClientDataSet1.Fields[0].AsInteger=id then begin

smsmsg:='Sender: '+ClientDataSet1.Fields[1].AsString+' MSG: '+ClientDataSet1.Fields[2].AsString;

timer2.enabled:=true;

ClientDataSet1.Edit;

ClientDataSet1.Delete;

ClientDataSet1.ApplyUpdates(-1);

end;

if send then begin

ClientDataSet1.Edit;

ClientDataSet1.Fields[0].AsInteger:=StrToInt(FieldTo);

ClientDataSet1.Fields[1].AsInteger:=id;

ClientDataSet1.Fields[2].AsString:=FieldM;

ClientDataSet1.ApplyUpdates(-1);

send:=false;

end;

{**********}

Shape15.Brush.Color:=clGreen;

end;{if}

{–––––––––––-}

count:=0;

end

end;

procedure TForm1.FormCreate(Sender: TObject);

begin

count:=0;

sms:=false;

send:=false;

randomize;

id:=Random(10000);

end;

procedure TForm1.SpeedButton4Click(Sender: TObject);

begin

Panel1.Visible:=true;

Panel1.Caption:=IntToStr(id);

end;

procedure TForm1.SpeedButton5Click(Sender: TObject);

begin

timer2.enabled:=false;

Form1.Color:=clBtnFace;

ShowMessage('SMS at '+ smsmsg);

end;

procedure TForm1.Timer2Timer(Sender: TObject);

begin

sms:=not sms;

if sms then Form1.Color:=clLime;

if not sms then Form1.Color:=clBtnFace;

end;

procedure TForm1.SpeedButton8Click(Sender: TObject);

begin

if Edit1.Text<>'' then id:=StrToInt(Edit1.Text);

Edit1.Visible:=false;

Panel1.Visible:=false;

end;

procedure TForm1.SpeedButton7Click(Sender: TObject);

begin

Edit1.Visible:=true;

Edit1.Text:=IntToStr(id);

end;

procedure TForm1.SpeedButton6Click(Sender: TObject);

begin

Panel2.Visible:=true;

Label4.Caption:='From: '+ IntToStr(id);

end;

procedure TForm1.SpeedButton9Click(Sender: TObject);

begin

FieldTo:=Edit2.Text;

FieldM:=Edit3.Text;

Panel2.Visible:=false;

send:=true;

end;

end.

Anexa 2.

Textul fișierelor pentru aplicația server de obiecte CORBA

{fișierul proiectului PCell.dpr}

program PCell;

uses

Forms,

Cell in 'Cell.pas' {Form1},

PCell_TLB in 'PCell_TLB.pas',

CORBACell in 'img\CORBACell.pas' {Cells: TCorbaDataModule} {Cells: CoClass},

CellInfo in 'CellInfo.pas' {Form2};

{$R *.TLB} {CORBA}

{$R *.RES}

begin

Application.Initialize;

Application.CreateForm(TForm1, Form1);

Application.CreateForm(TForm2, Form2);

Application.Run;

end.

{fișierul cu cod sursă Cell.pas (forma 1 din 2)}

unit Cell;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,

StdCtrls, ActnList, Buttons, StdActns, ExtCtrls, ComCtrls, jpeg, Menus,

Gauges;

type

TForm1 = class(TForm)

Panel1: TPanel;

Image1: TImage;

SpeedButton1: TSpeedButton;

SpeedButton2: TSpeedButton;

SpeedButton3: TSpeedButton;

Label3: TLabel;

Label1: TLabel;

Timer1: TTimer;

Gauge1: TGauge;

SpeedButton4: TSpeedButton;

SpeedButton5: TSpeedButton;

procedure SpeedButton4Click(Sender: TObject);

procedure SpeedButton3Click(Sender: TObject);

procedure SpeedButton2Click(Sender: TObject);

procedure SpeedButton1Click(Sender: TObject);

procedure FormShow(Sender: TObject);

procedure Timer1Timer(Sender: TObject);

procedure FormCreate(Sender: TObject);

procedure SpeedButton5Click(Sender: TObject);

private

{ Private declarations }

PhonesCount: Integer;

Times: Integer;

ID: Integer;

public

{ Public declarations }

procedure SetUp;

procedure UpdateCount(Incr: Integer);

procedure SetID(ID: Integer);

end;

var

Form1: TForm1;

implementation

uses CellInfo, CORBACell;

{$R *.DFM}

procedure TForm1.SetUp;

begin

Form1.DoHide;

Form1.DoShow;

end;

procedure TForm1.UpdateCount(Incr: Integer);

begin

PhonesCount:=PhonesCount+Incr;

Label1.Caption:=IntToStr(PhonesCount);

end;

procedure TForm1.SpeedButton4Click(Sender: TObject);

begin

Form1.SetUp;

end;

procedure TForm1.SpeedButton3Click(Sender: TObject);

begin

Form1.WindowState:=wsMinimized;

end;

procedure TForm1.SpeedButton2Click(Sender: TObject);

begin

Form1.Close;

end;

procedure TForm1.SpeedButton1Click(Sender: TObject);

begin

Label1.Visible:=not Label1.Visible;

Label3.Visible:=not Label3.Visible;

if label1.visible = true then SpeedButton1.Caption:='Hide Statistics' else

SpeedButton1.Caption:='Show Statistics';

end;

procedure TForm1.FormShow(Sender: TObject);

begin

Panel1.Visible:=false;

Times:=0;

Label1.Caption := '0' ;

Timer1.Enabled:=true;

end;

procedure TForm1.Timer1Timer(Sender: TObject);

begin

Times:=Times+5;

Gauge1.Progress:=Times;

if times > 100 then begin

Timer1.Enabled:=false;

Panel1.Visible:=true;

end;

end;

procedure TForm1.FormCreate(Sender: TObject);

begin

Randomize;

ID:=Random(2147483646);

end;

procedure TForm1.SpeedButton5Click(Sender: TObject);

begin

Form2.Visible:= not Form2.Visible;

Form2.Caption:='MyID: ' + IntToStr(ID);

Form2.ClientHeight:=Form1.ClientHeight;

Form2.ClientWidth:=Form1.ClientWidth;

Form2.Left:=Form1.Left;

Form2.Top:=Form1.Top;

end;

end.

{fișierul cu cod sursă Cellinfo.pas (forma 2 din 2)}

unit CellInfo;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,

Db, DBTables, Grids, DBGrids, StdCtrls;

type

TForm2 = class(TForm)

Button1: TButton;

DataSource1: TDataSource;

Table1: TTable;

DBGrid1: TDBGrid;

procedure Button1Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

procedure UpdateCountID(Incr,ID: Integer);

end;

var

Form2: TForm2;

implementation

{$R *.DFM}

procedure TForm2.Button1Click(Sender: TObject);

begin

Table1.Refresh;

DBGrid1.Refresh;

end;

end.

Anexa 3.

Textul fișierelor cu modulul CORBA pentru aplicația server

{fișierul proiectului CORBACell.pas}

unit CORBACell;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,

ComObj, VCLCom, StdVcl, DataBkr, CorbaRdm, CorbaObj,

PCell_TLB, Db, DBTables, Provider;

type

TCells = class(TCorbaDataModule, ICells)

DataSource1: TDataSource;

Table1: TTable;

DataSetProvider1: TDataSetProvider;

procedure CorbaDataModuleCreate(Sender: TObject);

procedure CorbaDataModuleDestroy(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Cells: TCells;

implementation

{$R *.DFM}

uses CorbInit, CorbaVcl, Cell;

procedure TCells.CorbaDataModuleCreate(Sender: TObject);

begin

Form1.UpdateCount(1);

end;

procedure TCells.CorbaDataModuleDestroy(Sender: TObject);

begin

Form1.UpdateCount(-1);

end;

initialization

TCorbaVclComponentFactory.Create('CellsFactory', 'Cells', 'IDL:PCell/CellsFactory:1.0', Icells, TCells, iMultiInstance, tmMultiThreaded);

end.

{cell type library din fișierul Pcell_TLB}

unit PCell_TLB;

// ************************************************************************ //

// WARNING

// ––-

// The types declared in this file were generated from data read from a

// Type Library. If this type library is explicitly or indirectly (via

// another type library referring to this type library) re-imported, or the

// 'Refresh' command of the Type Library Editor activated while editing the

// Type Library, the contents of this file will be regenerated and all

// manual modifications will be lost.

// ************************************************************************ //

// PASTLWTR : $Revision: 1.88.1.0.1.0 $

// File generated on 30.04.01 4:10:35 from Type Library described below.

// ************************************************************************ //

// Type Lib: D:\VCell\PCell.tlb (1)

// IID\LCID: {2038E635-3CD8-11D5-B709-004095117000}\0

// Helpfile:

// DepndLst:

// (1) v1.0 Midas, (C:\WINDOWS\SYSTEM\MIDAS.DLL)

// (2) v2.0 stdole, (C:\WINDOWS\SYSTEM\STDOLE2.TLB)

// (3) v4.0 StdVCL, (C:\WINDOWS\SYSTEM\STDVCL40.DLL)

// ************************************************************************ //

{$TYPEDADDRESS OFF} // Unit must be compiled without type-checked pointers.

interface

uses Windows, ActiveX, Classes, Graphics, OleServer, OleCtrls, StdVCL, SysUtils, CORBAObj, OrbPas, CorbaStd, MIDAS;

// *********************************************************************//

// GUIDS declared in the TypeLibrary. Following prefixes are used:

// Type Libraries : LIBID_xxxx

// CoClasses : CLASS_xxxx

// DISPInterfaces : DIID_xxxx

// Non-DISP interfaces: IID_xxxx

// *********************************************************************//

const

// TypeLibrary Major and minor versions

PCellMajorVersion = 1;

PCellMinorVersion = 0;

LIBID_PCell: TGUID = '{2038E635-3CD8-11D5-B709-004095117000}';

IID_ICells: TGUID = '{2038E63A-3CD8-11D5-B709-004095117000}';

CLASS_Cells: TGUID = '{2038E63C-3CD8-11D5-B709-004095117000}';

type

// *********************************************************************//

// Forward declaration of types defined in TypeLibrary

// *********************************************************************//

ICells = interface;

ICellsDisp = dispinterface;

// *********************************************************************//

// Declaration of CoClasses defined in Type Library

// (NOTE: Here we map each CoClass to its Default Interface)

// *********************************************************************//

Cells = ICells;

// *********************************************************************//

// Interface: ICells

// Flags: (4416) Dual OleAutomation Dispatchable

// GUID: {2038E63A-3CD8-11D5-B709-004095117000}

// *********************************************************************//

ICells = interface(IAppServer)

['{2038E63A-3CD8-11D5-B709-004095117000}']

end;

// *********************************************************************//

// DispIntf: ICellsDisp

// Flags: (4416) Dual OleAutomation Dispatchable

// GUID: {2038E63A-3CD8-11D5-B709-004095117000}

// *********************************************************************//

ICellsDisp = dispinterface

['{2038E63A-3CD8-11D5-B709-004095117000}']

function AS_ApplyUpdates(const ProviderName: WideString; Delta: OleVariant;

MaxErrors: Integer; out ErrorCount: Integer; var OwnerData: OleVariant): OleVariant; dispid 20000000;

function AS_GetRecords(const ProviderName: WideString; Count: Integer; out RecsOut: Integer; Options: Integer; const CommandText: WideString; var Params: OleVariant; var OwnerData: OleVariant): OleVariant; dispid 20000001;

function AS_DataRequest(const ProviderName: WideString; Data: OleVariant): OleVariant; dispid 20000002;

function AS_GetProviderNames: OleVariant; dispid 20000003;

function AS_GetParams(const ProviderName: WideString; var OwnerData: OleVariant): OleVariant; dispid 20000004;

function AS_RowRequest(const ProviderName: WideString; Row: OleVariant; RequestType: Integer; var OwnerData: OleVariant): OleVariant; dispid 20000005;

procedure AS_Execute(const ProviderName: WideString; const CommandText: WideString;

var Params: OleVariant; var OwnerData: OleVariant); dispid 20000006;

end;

TCellsStub = class(TAppServerStub, ICells)

public

end;

TCellsSkeleton = class(TAppServerSkeleton)

private

FIntf: ICells;

public

constructor Create(const InstanceName: string; const Impl: IUnknown); override;

procedure GetImplementation(out Impl: IUnknown); override; stdcall;

published

end;

// *********************************************************************//

// The Class CoCells provides a Create and CreateRemote method to

// create instances of the default interface ICells exposed by

// the CoClass Cells. The functions are intended to be used by

// clients wishing to automate the CoClass objects exposed by the

// server of this typelibrary.

// *********************************************************************//

CoCells = class

class function Create: ICells;

class function CreateRemote(const MachineName: string): ICells;

end;

TCellsCorbaFactory = class

class function CreateInstance(const InstanceName: string): ICells;

end;

implementation

uses ComObj;

{ TCellsStub }

{ TCellsSkeleton }

constructor TCellsSkeleton.Create(const InstanceName: string; const Impl: IUnknown);

begin

inherited;

inherited InitSkeleton('Cells', InstanceName, 'IDL:PCell/ICells:1.0', tmMultiThreaded, True);

FIntf := Impl as ICells;

end;

procedure TCellsSkeleton.GetImplementation(out Impl: IUnknown);

begin

Impl := FIntf;

end;

class function CoCells.Create: ICells;

begin

Result := CreateComObject(CLASS_Cells) as ICells;

end;

class function CoCells.CreateRemote(const MachineName: string): ICells;

begin

Result := CreateRemoteComObject(MachineName, CLASS_Cells) as ICells;

end;

class function TCellsCorbaFactory.CreateInstance(const InstanceName: string): ICells;

begin

Result := CorbaFactoryCreateStub('IDL:PCell/CellsFactory:1.0', 'Cells',

InstanceName, '', ICells) as ICells;

end;

initialization

CorbaStubManager.RegisterStub(ICells, TCellsStub);

CorbaInterfaceIDManager.RegisterInterface(ICells, 'IDL:PCell/ICells:1.0');

CorbaSkeletonManager.RegisterSkeleton(ICells, TCellsSkeleton);

end.

Anexa 4.

Codul obiectului CORBA

{codul CORBA IDL}

#include "Midas.idl"

module PCell

{

interface ICells;

interface ICells: Midas::IAppServer

{

};

interface CellsFactory

{

ICells CreateInstance(in string InstanceName);

};

};

{codul MIDL}

[

uuid(2038E635-3CD8-11D5-B709-004095117000),

version(1.0),

helpstring("PCell Library")

]

library PCell

{

importlib("MIDAS.DLL");

importlib("STDOLE2.TLB");

importlib("STDVCL40.DLL");

[

uuid(2038E63A-3CD8-11D5-B709-004095117000),

version(1.0),

helpstring("Dispatch interface for Cells Object"),

dual,

oleautomation

]

interface ICells: IAppServer

{

};

[

uuid(2038E63C-3CD8-11D5-B709-004095117000),

version(1.0),

helpstring("Cells Object")

]

coclass Cells

{

[default] interface ICells;

};

};

{însăși interfata ICells}

[

uuid(2038E63A-3CD8-11D5-B709-004095117000),

version(1.0),

helpstring("Dispatch interface for Cells Object"),

dual,

oleautomation

]

interface ICells: IAppServer

{

};

{însăși obiectul Cells}

[

uuid(2038E63C-3CD8-11D5-B709-004095117000),

version(1.0),

helpstring("Cells Object")

]

coclass Cells

{

[default] interface ICells;

};

Schema bloc a funcționării sistemului de telefonie mobilă.