Compararea programelor

De-a lungul anilor s-a scris foarte mult software, drept care la un moment dat s-a impus aproape de la sine ierarhizarea programelor destinate soluționării aceleiași probleme. În acest scop s-a trecut la compararea programelor. Astfel au apărut articole destinate comparării diferitelor programe, din care amintesc aici:

• Kenneth E. FITZGERALD  - Comparison of Some FORTRAN Programs for Matrix Inversion, JOURNAL OF RESEARCH of the Notional Bureau of Stondards - B. Mathematical Sciences,
• Vol. 78B, No. 1, January-March 1974, pp.15 - 33Comparison of several sorting algorithms în http://warp.povusers.org/SortComparison/ 
• Keshav BISWA, Bishal JAMATIA, Deepjyoti CHOUDHURY, Pallabi BORAH  - Comparative Analysis of C, FORTRAN, C# and Java Programming Languages, Keshav Biswa et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 7 (2) , 2016, pp. 1004 -1007

Oricare dintre noi care dorește să facă același lucru, trebuie:

• să aibă câteva programe destinate soluționării aceleiași probleme, fie folosind același algoritm, fie cu algoritmi diferiți, fie toate scrise în același limbaj de programare, fie scrise în diferite limbaje de programare, dar de fiecare dată trebuie precizate toate elementele care definesc contextul analizei, ca să se știe exact despre ce este vorba;
• să dispună de textele sursă corecte și complete care să fie lansate în execuție fără dificultăți și care prin mici ajustări să permită rularea  a nenumărate seturi de date de test și înregistrarea automată a numărului de iterații și a duratelor de execuție;
• să existe suficiente seturi de date de test  ca diversitate și ca diimensiune a problemelor de rezolvat care să permită evidențierea atât a virtuților, cât și a carențelor programelor care fac onbiectul analizei; seturile de date de test se constituie într-un lanț care se rulează continuu pentru fiecare program sau dacă este posibil, se rulează o singură dată pentru toate programele care fac obiectul analizei;
• să existe o prezentare de detaliu a fiecărui set de date de test, cu caracteristicile sale de bază precum număr de articole, ordine de mărime, mod de dispunere, tipuri de date, valori caracteristice, frecvnețe de apariție a unor valori, astfel încât să se vadă dacă performanțele programelor depind de structurile interne ale seturilor de date, de diferențele dintre ele;
• ca tabelele care rezultă după execuție trebuie să fie sistematizate cu date despre programe și caracteristicile măsurate, astfel încât în continuare să fie aplicate metode statistice care să permită concluzionări semnificative, credibile și mai ales utile pentru soluționarea altor probleme concrete în viitor.

În vremurile de demult am avut și eu oarece preocupări pe probleme de analiză comparată a unor programe, pe care am continuat-o și mai recent, după cum se va vedea:

• Ion IVAN - Analiza statistica a programelor - 1, Revista de statistica, vol. 29, nr.4, 1980, pg.11-16
• Ion IVAN - Analiza statistica a programelor - 2, Revista de statistica, vol. 29, nr.5, 1980, pg.22-34
• Ion IVAN, Romulus ARHIRE- Analiza statistica pentru performantele sistemelor de progame (I), Revista Romana de Statistica, vol. 30, nr. 4 1981, pg. 21 - 28
• Ion IVAN, Romulus ARHIRE - Analiza statistica pentru performantele sistemelor de progame (II), Revista Romana de Statistica, vol. 30, nr. 6, 1981, pg. 43 - 52.
• Ion IVAN , Alexandru BALOG, Tudor BARON - Analiza comparata a modelelor de fiabilitate software , Lucrarile Simpozionului International de Informatica Economica, Bucuresti, mai 1993, Editura Centrul Editorial Tipografic ASE, pg. 131 - 134
• Ion IVAN, Iulian RADULESCU - Analiza comparata a complexitatii entitatilor text generate prin tehnici de programare, Editura ASE, Bucuresti 2006, 164 pg, ISBN 973-594-754-4

La un moment dat chiar am propus la un curs un șablon după care să se facă analiza comparativă a calității:

ANALIZA COMPARATA A CALITATII APLICATIILOR DE.....(rezervare bilete, instruire on-line, comert electronic, e-banking, e-educatie, ERP, management resurse umane, evidente contabile...) 

(abstract)

Se selecteaza aplicatiile de .... realizate de firmele.....

Se stabilesc caracteristicile de calitate a aplicatiilor de....

Se construiesc indicatori pentru evaluarea calitatii.

Se masoara nivelurile caracteristicilor de calitate pentru aplicatiile de ....

Se ierarhizeaza aplicatiile de..... dupa un indicator agregat.

1. Aplicatii de ...... 

Se descriu cerintele de prelucrare ale aplicatiilor de ....

O aplicatie de .... are ca obiectiv.....

Se adreseaza unui grup tinta format din ....

Datele de intrare sunt....

Rezultatele furnizate de aplicatia de... sunt....

Prelucrarile se refera la:

- introducerea de optiuni...

- selectarea prelucrarilor

- selectarea modalitatilor de plata

- selectarea structurii rezultatelor

- ..............

- definirea modalitatilor de acces

Pentru fiecare aplicatie se precizeaza:

- adresa web

- cine a realizat-o

- cum se acceseaza, restrictii de autentificare

- ce probleme rezolva.

Se construieste un tabel asemeni celor in care se prezinta detalii comparative pentru telefoanele mobile realizate de diferiti producatori.

Se prezinta criterii de alegere a aplicatiei pentru..... in raport cu cerintele utilizatorilor.

Cu tehnologiile din ziua de azi, nu există nicio problemă de a face analize foarte complexe, inclusiv folosind criterii agregate de ierarhizare, astfel încât să se știe cu exactitate care este produsul software cel mai convenabil a fi utilizat. Totul este să fie definit cu claritate maximă un obiectiv și atât.  Compararea programelor este o problemă care permite obținerea de avantaje multiplicate, mai ales la aplicațiile web accesate de milioane de clienți, așa cum sunt cele de magazine electronice sau de rezervări online dar și în cazul tranzacțiilor bancare.

(22 decembrie 2017)

Regruparea calculelor

Regruparea calculelor este o modalitate de a reduce numărul ciclurilor mașină. În secvența:
s1=0;
for(i=0;i <n; i++) s1+=x[i];
s2=0;
for(i=0;i <n; i++) s2+=x[i]*x[i];
s3=0;
for(i=0;i  <n; i++)  s3+=x[i]*x[i]+x[i];
sxy=0;
for(i=0;i  <n; i++) sxy+=x[i]*y[i];
prin regruparea intr-o singura structura repetitiva, devine:
s1=0;
s2=0;
s3=0;
sxy=0;
for(i=0;i <n; i++)
            {
             s1+=x[i];
             s2+=x[i]*x[i];
             s3+=x[i]*x[i]+x[i];
             sxy+=x[i]*y[i];
             }
Dacă numărul de cicluri variază se vor găsi modalități de  a face ceea ce trebuie și de a rezolva problema.
Dacă se consideră secvența:
s1=0;
for(i=0;i <n; i++) s1+=x[i];
s2=0;
for(i=0;i <m; i++) s2+=x[i]*x[i];
și dacă m= n+2, atunci sevența inițială prin  optimizare devine;
s1=0;
s2=0;
for(i=0;i <n; i++)
            {
             s1+=x[i];
             s2+=x[i]*x[i];
             }
s2+=x[n]*x[n] + x[n+1]*x[n+1] ;
și se vede că se țin sub control numărul de repetări ale instrucțiunii for() care apare o singură dată, ceea ce la o analiză atentă este un lucru benefic. Regruparea de calcule presupune ca secvențele să fie independente între ele, ceea ce se întâlnește destul de des în programe.

(023 decembrie 2017)

Factorul de blocare

Factorul de blocare este legat de modul în care se dispun articolele în fișiere. Există două noțiuni:
- articolul logic;
- înregistrarea la nivel fizic.
Se citește o cantitate de informație de lungime fixă numită înregistrare la nivel fizic. Programatorul definește articolul unui fișier funcție de datele cu care lucrează. Articolul definit de programator are o lungime dată de suma lngimilor câmpurilor ce-l compun. Dacă lungimea articolului așa cum este definit de programator este cu mici diferențe cam aceeași ca lungimea articolului fizic, se memorează un articol logic în ceea ce se scrie în fișier. Rezultă că numărul de operații de scriere dat de numărul de articole la nivel fizic, este egal cu numărul de articole pe care programatorul este interesat să le scrie în fișier.
Dacă articolul definit de programator este foarte mic, el are posibilitatea să pună acele articole, mai multe într-un articol și să facă o singură scriere pe suport. Acel număr maxim de articole care încaă intr-un articol fizic se numește factor maxim de blocare. De exemplu, dacă articolul fizic are 1024 bytes și articolul definit de programator are 300 bytes, factorul de blocare este 3, căci maximul 3 articole definite de programator încap într-un articol la nivel fizic și mai rămân neutilizați 124 bytes. dacă programatorul vrea să scrie 600 de articole ce corespund celor 600 de elemente ale unei colectivități de care se ocupă programul său, la nivel fizic se vor scrie grupe de câte 3 articole logice. Deci la nivel fizic se vor executa 200 de operații de scriere ceea ce e mare lucru comparativ cu programul în care corespondența este de 1 la 1, adică un articol de 300 de bytes se scrie în cei 1024 ai articolului fizic și cele 600 de articole se vor scrie unul câte unul.
Fiecare sistem de calcul, fiecare sistem de operare are tabele cu factorii de blocare și programatorii eficienți nu lasă lucrurile la voia întâmplării nici în ziua de azi.

(023 decembrie 2017)

Gestionarea conversiilor de tip

Gestionarea conversiilor de tip este importantă pentru că ele ascund în spate conversii de tip. Sunt compilatoare care gestionează ele acest lucru.
În secvența:
INTEGER A,B,C,D,X
REAL I, K
A=2.
B=3
C=18.
D=32
I=100
K=D/15+C/22.
X=K
au loc destul de multe conversii. Dacă nu se dispune de compilator care să festioneze el însuși conversiile se produc următoarele conversii:
- constanta 2. este de tip real și se face conversie spre întreg pentru a se face inițializarea variabilei A; programatorul care știe despre ce este vorba cu siguranță ar fi scris din prima A=2, 2 fiind de tip întreg ca variabila A;
- la fel se întâmplă și la inițializarea C=18. fiind necesară o conversie;
- variabila I este de tip real are o reprezentare internă care diferă de cea a constantei 100 care este de tip întreg, fiind necesară și în acest caz conversie de la întref spre real;
- în expresia K=D/15+C/22. tipul dominant este cel real și de aceea înainte de a se face evaluările se fac conversii a tot ceea ce este de tip întreg spre tipul real;
- conversie se face și de la real spre întreg să se evalueze expresia X=K.
Chestiuni neînsemnate uneori duc la volume foarte mari de cicluri mașină și numai programatorii care știu limbaje de asamblare își dau seama ce și cum la nivelul acestor chestiuni de finețe.

(023 decembrie 2017)

Reducerea apelurilor

Reducerea apelurilor de funcții și de proceduri este benefic dacă și numai dacă are un rol de a compensa creșterea lungimii programului prin creșterea numărului de instrucțiuni din secvențe similare, care au justificat regruparea în subrutine.
Trebuie spus că la apelul unei subrutine, oricare ar fi tipul ei, se produc niște lucruri, care se concretizează prin cicluri mașină.
Într-un program fortran dacă se dorește să se calculeze patru medii aritmetice vom proceda astfel:
- scriem un subprogram de calcul pentru media aritmetică;
- apelăm subprogramul de patru ori schimbând parametrii:
- subprogramul realizează transferul de parametrii;
- subprogramul efectuează returnarea rezultatului;
- subprogramul efectuează reansfer la instrucțiunea următoare.
Probabil, pentru a evita salturile din apelator în subprogram și din subprogram în apelator, este mai rezonabil să se încorporeze inteligent instrucțiunile de calcul ale mediilor direct în apelator.Dacă voi scrie fără a apela subprograme, textul va fi:
             DIMENSION X(100), Y(100), Z(100), WW(100)
             INTEGER I, N
             INTEGER MEDX,MEDY,MEDZ,MEDW
             REAL SUMX, SUMY, SUMZ, SUMW
C          INITIALIZARI NUMAR COMPONENTE
C          INITIALIZARI SERII DE DATE
             SUMX=0
             SUMY=0
             SUMZ=0
             SUMW=0
........................................
             DO 50 I=1,N
             SUMX=SUMX+X(I) 
             SUMY=SUMX+Y(I) 
             SUMZ=SUMX+Z(I) 
50         SUMW=SUMX+W(I)
             SUMX=SUMX
             MEDX=SUMX /N
             MEDY=SUMY /N
             MEDZ=SUMZ /N
             MEDW=SUMW /N
..................................
C          INSTRUCTIUNI DE SCRIERE  A REZULTATELOR

Se observă că textul sursă este mai lunguț, dar nu conține niciun apel prin CALL și nico revenire în apelator prin RETURN, dar dacă mai se ține seama că suprobramele s-ar încărca în segmente diferite, salturile intersegment au un număr de cicluri mașină înfiorător de mari, lucru demonstrat în toate manualele de prezentare a limbajelor de asamblare, care se respectă și care intră în astfel de detalii.
Dacă ar fi să calculăm media folosind un subprogram acesta va avea forma:
C          SUBPROGRAM DE CALCUL MEDIE ARITMETICA
             SUBROUTINE MEDIA (X, N,XMED)
             DIMENSION X(N)
             INTEGER I
             REAL    SUM
             SUM=0
             DO 10  I=1,N
10         SUM=SUM+X(I)
             XMED=SUM/FLOAT(N)
             RETURN
             END
În acest text sursă variabilele X, N,XMED se numesc parametrii formali. Programul apelator va conține instrucțiunile:
             DIMENSION X(100), Y(100), Z(100), WW(100)
             INTEGER I, N
             INTEGER MEDX,MEDY,MEDZ,MEDW
             REAL SUMX, SUMY, SUMZ, SUMW
C          INITIALIZARI NUMAR COMPONENTE
C          INITIALIZARI SERII DE DATE

........................................
             CALL  (X, N,XMED)
             CALL  (Y, N,YMED)
             CALL  (Z, N,ZMED)
             CALL  (W, N,WMED)
..................................
C           INSTRUCȚIUNI DE SCRIERE MEDII: 
C           XMED,YMED, ZMED, WMED
Sunt situații unde așa ceva nu este rentabil. Programatorul va face evaluările astfel încât ceea ce obține să fie un program cât de cât eficient dacă a obține un program optim este prea pretențios. În celelalte limbaje tot cam așa stau lucrurile deși multe dintre proceduri se scriu direct nemaifiind necesară o instrucțiune de tip CALL ca pe vremuri, dar tot se produc salturi  necondiționate  la apel și la revenire chiar dacă sunt intersegment sau intrasegment tot hulitele  salturi necondiționate sunt.

(05 decembrie 2017)

Înjumătățirea repetărilor

Înjumătățirea repetărilor este un mod de a optimiza și eficiența se vede foarte clar, prin reducerea volumului de prelucrări dat în cicluri mașină care însoțesc repetările instrucțiunii for().

Secvența:
int n, i;
int a[100];
int sa=0;
..............
for(i=0; i < n; i++) sa+=a[i];
.......................

conține n repetări ale instrucțiunii for().

Dacă numărul de repetări n este un număr par, n=2*k este mult mai eficientă secvența:

int n, n, i;

int a[100];

int sa=0;

k=n/2;

..............

for(i=0; i < n; i++) 

    {

     sa+=a[i];

     sa+=a[k+i];

      }

.......................

căci instrucțiunea for() are un număr de execuții înjumătățit. Pentru a elimina restricția aceea legată de faptul că n trebuie să fie număr par se construiește o formă generală a secvenței care are devine:

int n, n, p,i;

int a[100];

int sa=0;

k=n/2;

p=n%2;

..............

for(i=0; i < n; i++) 

    {

     sa+=a[i];

     sa+=a[k+i];

      }

if(p)  sa+=a[n-1];

.......................

Sunt multe situațiile în care acest mod de lucru este benefic, mai ales în calculele statistice unde se lucrează cu serii de date de aceeași lungime și cu fiecare serie se fac anumite calcule, care presupun traversarea termen cu termen a fiecărei serii, calculele fiind independente în raport cu termenii.
Înjumătățirea repetărilor duce la creșterea vitezei de rulare a întregului program, ceea ce este benefic și nu presupune un efort prea mare din partea programatorilor, căci instrucțiunea for(0 la numărătoare este una singură, dar ea include mai multe expresii a cărăr evaluare are caracter repetitiv, ceea ce înseamnă multe cicluri mașină, deci timp în plus.

(023 decembrie 2017)

Eliminarea duplicării de cod

Eliminarea duplicării de cod are efecte foarte bune asupra volumului de calcule, căci un rogram va arăta cu toeastă optimizare pe text sursă este efectuată îngrijit și complet. Totul se vede în cazul în care din start secvențele sunt scrise așa cum sunt descriși pașii algoritmului și programatorul vede că nu există dependențe între ele.

Secvența:

int n, i;

int a[100];

int b[100];

int c[100];

int d[100];

int sa=sb=sc=sd=0;

..............

for(i=0; i < n; i++) sa+=a[i];

for(i=0; i < n; i++) sb+=b[i];

for(i=0; i < n; i++) sc+=c[i];

for(i=0; i < n; i++) sd+=d[i];

.......................

conține de patru ori același număr de repetări executate independent pentru calculul celor patru sume, ceea ce aplicând o modalitate de a concentra toate calculele intermediare într-un bloc va duce la secvența:

int n, i;

int a[100];

int b[100];

int c[100];

int d[100];

int sa=sb=sc=sd=0;

..............

for(i=0; i < n; i++) 

       { 

        sa+=a[i];

        sb+=b[i];

        sc+=c[i];

        sd+=d[i];

        }

.......................

care este mult mai elegantă, iar din punct de vedere al volumului de calcule mult mai eficientă, căci lipsesc cele patru instrucțiuni for(), care sunt înlocuite de o singură astfel de instrucțiune.
În secvența:
int i, s=0;
................
s=0;
for(i=0; i < n; i++) sa+=a[i];
.............................
a doua inițializare cu zero a variabilei s nu se justifică dacă nu s-a mai lucrat cu aceasta până la electuarea acelei însumări repetitive.
Ori se va scrie secvența:
int i, s=0;
................
for(i=0; i < n; i++) sa+=a[i];
.............................
ori secvența de instrucțiuni:
int i, s;
................
s=0;
for(i=0; i < n; i++) sa+=a[i];
.............................
Eliminarea duplicării de cod vizează fie concentrări de secvențe, fie instrucțiuni puse în program neglijent care se văd de la o poștă că sunt în plus, pentru că fac același lucru de două sau mai multe ori.

[]

{ }

<

>

{ }

<

>

(04 decembrie 2017)

Criterii de optim

Criteriile de optim sunt importante căci de la ele pornește totul.  Astfel de criterii sunt:
- maximizrea dimensiunii problemei de rezolvat;
- maximizarea nivelului calitatii agregate a produsului software;
- maximizrea  fiabilității produsului software;
- maximizrea preciziei rezultatelor;
- maximizarea  flexibilitățiiin structurii cheilor în procesul de regăsire;
- maximizrea gradului de satisfacție al utilizatorului;
- maximizrea nivelului de secutitate al produsului software;
- maximizrea productivității echipei de dezvoltare;
- maximizrea  gradului de acoperire prin testare a ramurilor produsului software;
- maximizarea gradului de generalitate a probelelor de rezolvat;
- maximizrea duratei etapei de utilizare;
- maximizarea gradului de ocupare a masivelor definite static;
- maximizarea elementelor care asigură continuitatea în interfețe;
- minimizarea costului de construire a unui produs software;
- minimizarea costului calității produsului software;
- minimizarea duratei tranzacției;
- minimizarea duratei procesului de mentenanță;
- minimizarea lungimii efectului de ondulană;
- minimizarea necesarului de memorie;
- minimizarea lungimii produsului software;
- minimizarea ciclurilor mașină;
- minimizarea duratei de realizare a produsului;
- minimizarea complexității programului;
- minimizarea volumului de date necesar pentru regăsire;
- minimizarea  numărului de fișiere utilizate în program;
- minimizarea  numărului de încărcări/descărcări de pe server;
- minimizarea expresiilor logice din selectarea articolelor;
- minimizarea volumului de variabile de tip static;
- minimizarea numărului de apeluri de proceduri;
- minimizarea numărului de instrucțiun return executate;
- minimizarea numărului de instrucțiuni de salt necondiționat;
- minimizarea volumului de instrucțiuni prin duplicare de cod;
- minimizarea  volumului de conversii de tip;
- minimizarea listelor de parametrii.
Procesul de optimizare este în cazul produselor software de o mare complexitate și tot timpul trebuie găsit un echilibru, căci se urmărește de regulă satisfacerea mai multor criterii de optim simultan, ceea ce este deosebit de dificil de obținut. Este rezonabil să se extragă o submulțime de criterii și acestora să li se dea note, iar după aceea să li se calculeze coeficienții de importanță și criteriile să fie agregate folosind acele ponderi, care din timp în timp trebuie recalculate.
Criteriile  de optim sunt dorințe intime ale oricărui programator, dar punerea în operă este anevoioasă că programatorul nu face ce vrea el și are nenumărate constrângeri de care trebuie să țină seama. Uneori deși îmi propusesem să scriu cel mai fain program din câte existau pe planetă, beneficiarul, dar și șefii veneau cu biciușca și mă mânau de la spate și nu numai că uitam de visul meu frumos, dar o mai și zbârceam. Lucrul cel mai urât este să știi unde ai greșit și să nu ai cum să-ți îndrepți greșeala dintr-o mie de motive, care mai de care mai obiective, indispensabile, presante și imposibil de controlat.

(023 decembrie 2017)

Eliminarea subexpreiilor comune

Eliminarea subexpreiilor comune nu se explică prea bine în cuvinte, ci trebuie venit cu un exemplu. Se consideră expresia:

se vede acolo că o subexpresie notată de mine cu s se repetă

Dacă o înlocuim, expresia e devine:

Complexitatea primei expresii include:
- operanzii diferiți e, a, b, c,  3, 1, 2,4, numărul lor fiind de 8;
- operatorii diferiți sunt  =, +, *. -, /, pow numărul lor fiind 6;
- complexitatea C a expresiei este C = 8 * log2 8 + 6 * log2 6 =39,51  .
Dacă este eliminată subexpreis comună, atunci cele două expresii s și e concuc la:
- operanzi utilizați e, a, b, c, s,  3, 1, 2,4, numărul lor fiind de 9;
- operatorii diferiți sunt  =, +, *. -, /, pow numărul lor fiind 6;
- complexitatea C a expresiilor este C = 9 * log2 9 + 6 * log2 6 = 44,04 , ceea ce înseamnă că eliminarea subexpresilor comune cu complexitatea calculată luând diversitatea operanzilor și operatorilor nu este profitabilă.
Dacă însă se ține seama de operanzii și operatorii care apar efectiv în expresia inițială, se observă că:
- variabila a apare de 4 ori;
- variabila b apare de 4 ori;
- variabila c apare de 4 ori;
- variabila e  apare o dată;
- constanta 1 apare o dată;
- constanta 3 apare o dată;
- constanta 2 apare o dată;
- constanta 4 apare o dată;
- operatorul de atribuire apare o singură dată;
- operatorul de împărțire /, apare o singură dată;
- operatorul de adunare +, apare de 10 ori;
- operatorul de scădere, apare de 2 ori;
- operatorul de ridicare la putere pe care l-am notat pow, apare de 12 ori;
- operatorul de înmulțire *, apare de 2 ori.
Rezultă că expresia e are  17 operanzi și 28 de operatori ceea ce conduce la o conplexitate calculată de C = 204,075.
În cazul în care se optimizează prin înlocuirea subexpresiei comune se identifică frecvențele:
- variabila a apare  o singură dată;
- variabila b apare  o singură dată;
- variabila c apare   o singură dată;
- variabila e  apare o dată;
- variabila e  apare de 5 ori;
- constanta 1 apare o dată;
- constanta 3 apare o dată;
- constanta 2 apare o dată;
- constanta 4 apare o dată;
- operatorul de atribuire apare 2 ori;
- operatorul de împărțire /, apare o singură dată;
- operatorul de adunare +, apare de 4 ori;
- operatorul de scădere, apare de 2 ori;
- operatorul de ridicare la putere pe care l-am notat pow, apare de 3 ori;
- operatorul de înmulțire *, apare de 2 ori.
Cele două expresii au 13 operanzi și 14noperatori. Complexitatea C  după eliminarea subexpresiilor comunie este C =  13 * log2 13 + 14 * log2 14 = 101,398 care este la jumătatea complexității expresiei inițiale, ceea ce arată că eliminarea subexpresiilor comune este benefică duratei de execuție a unui program, știut fiind faptul că reducerea numărului de cicluri mașină este foarte  importantă.
Eliminarea subexpreiilor comune reprezintă o modalitate specială de a arăta că programatorul performează cu adevărat, chiar dacă viteza de calcul este acum amețitoare și n-ar mai conta o reducere cu 3-% să zicem a numărului de cicluri malșină. Numai că de aici se adună ceva, de dincolo mai se aducă și altceva și tot așa se construiește non-performanța unei aplicații dată de viteza redusă per global de a obține un rezultat complet.

(03 decembrie 2017)

Eliminarea invarianților

Eliminarea invarianților se impune din cauză că apar în mod nejustificat în secvențe repetitive construcții care  de la o iterație la alta nu aduc nimic nou. Este vorba de instrucțiuni care se execută repetitiv, deși execuția lor o singură dată este suficientă.

În secvența:

sum=0;

sump=0;

sumc=0;

for(i=0; i <n ;  i++) {

                             sum+=x[i];

                             sump+= x[i] * x[i];

                             sump=0;

                             sumc+= x[i] * x[i] * x[i];

                             sumc=0;

                            }

După eliminarea invarianților secventa devine:

sum=0;

for(i=0; i <n ;  i++) {

                             sum+=x[i];

                             sump+= x[i] * x[i];

                             sumc+= x[i] * x[i] * x[i];

                             

                            }

Construcția:

for(i=0; i <n ;  i++) {

                             a=0:;

                             b=0;

                             c=0;

                             

                            }

devine:

a=0;

b=0;

c=0;

sau

a=b=c=0;

În programe sunt multe locuri unde apar invarianți. Programatorii trebuie să fie atenți că atunci când li se analizează programele de către alții este foarte greu să justifice de ce inițializează aiurea o variabilă simplă. Lucrurile sunt și mai rușinoase dacă acea variabilă intră într-o expresie care se execută repetat, anulând în acest fel sensul secvenței unde se implementează structura repetitivă.

Secvența:

for(i=0; i <n ;  i++) {

                             sum+=x[i];

                             sum0;                             

                            }

ori era scrisă pur și simplu:

sum=0; ori s-ar fi scris corect:

 sum0;  

for(i=0; i <n ;  i++) {

                             sum+=x[i];                                                       

                            }

Apar riscuri de a greși mai ales când programatorul nu definește variabile grupat, nu face inițializări grupar și nu scrie secvențe de prelucrare cât mai omogene. Eliminarea invarianților presupune introducerea de variabile simple care se inițializează fără rost în cadrul structurilor repetitive, lucru greu de argumentat de către programatorul care crede că are și el un oarece statut de meseriaș.

(03 decembrie 2017)

Eliminarea codului mort

Eliminarea codului mort este o operație de care programatorul ar trebui să fie preocupat pentru că unele compilatoare o execută rapid și el se va mira că ceva lipsește în execuția lui.
Dacă va scrie secvența:

if(5>7) { a=13;
                b=20;
                 c=-1;
             }
             else {
               a=-1;
                b=140;
                c=12;
                }
evident că secvența:
             { a=13;
                b=20;
                 c=-1;
             }
nu se va executa niciodată, deci este codul mort din program.
În secvența:
   int a = 10;
   int b = 15;
   int c=31;
   e = a * b + (c / 2 -1);
   if (0) {
     printf("%d\n", a);
     printf("%d\n", b);
     printf("%d\n", c);
     printf(" a= %d\n", a);
     printf(" b= %d\n", b);
     printf(" c= %d\n", c);
     printf(" e= %d\n", e);
   }
expresia ce se evaluează la instrucțiunea if(0) duce pe ramura fals, deci acele imprimări nu vor fi executate niciodată, adică never, cum zicem noi chinezii. Dacă ar fi fost if(-1) sau if(1110003) s-ar fi tipărit, dar așa este viața când în loc de o expresie din greșeală s-a scris acolo acel nevinovat zero.
Tot ce nu se execută niciodată se numește cod mort. Se introduc din greșeală secvențe de acest fel și ele încarcă nejustificat programul, deci trebuie eliminate sau trebuie făcute corecții căci este posibil ca programatorul să fi greșit o expresie relațională și să fi ieșit altceva decât a vrut el să scrie în realitate. Eliminarea codului mort este cel mai ușor de realizat. Codul mort nu influențează execuția unui program, ci o alterează.

(023 decembrie 2017)

în lucru acum

Optimizarea programelor

Optimizarea programelor a fost o temă care m-a obsedat din studenție. Mi-am zis, când făceam Cercetări operaționale, că dacă se optimizează rații de calorii pentru vaci, dacă se face programare numere întregi pentru sortimente de strunguri și autoturisme, de ce nu s-ar face și optimizarea programelor. Atunci nu era ca acum să dai pe internet pe Google un search cu software și optimization ca să apară nenumărate articole. Atunci am găsit în Communicațion of the ACM  articolul referit prin:
Donald E. KNUTH - Structured Programming with go to Statements, ACM Journal Computing Surveys 6, no. 4, 1974, pg. 268–301.
Și de atunci a început aventura mea cu optimizarea programelor.
Am studiat.
Am scris porgrame cu optimizări în ele.
Am scris articole.
Am coordonat lucrări de diplomă.
Am coordonat lucrări la sesiuni științifice.
Am scris și o carte.
Am coordonat și o teză de doctorat.
Cu alte cuvinte, era să fiu dat afară de la grădiniță pentru cât am insistat pe acest subiect, pe care îl consider excepțional și care în viitor va face diferența cîci în cloud computing nu se va lucra decât numai cu lucrări performante, care fac totul perfect și se demonstrază că altceva mai bun nu există.
Ca să arăt că nu bat câmpii exemplific cu:

• Ion IVAN, Catalin BOJA - Practica optimizarii aplicatiilor informatice ,Editura ASE, Bucuresti, 2007, 479 pg, ISBN 978-973-594-932-7
• Ion IVAN, Adrian PIRVULESCU - Atribuirea de ponderi pentru criteriile de optimizare a aplicatiilor informatice, Revista Romana de Statistica, vol. 54, nr. 2, 2005, pg. 21 - 31
• Ion IVAN, Sergiu COMAN, Alexandru BALOG - Tehnici de evaluare a efectelor optimizarii de programe (1), Revista de Statistica, vol.32, nr. 1, 1983 pg. 27 - 33
• Ion IVAN, Sergiu COMAN, Alexandru BALOG - Tehnici de evaluare a efectelor optimizarii de programe (2), Revista de Statistica, vol. 32, nr. 4, 1983, pg. 46 - 50
• Ion IVAN, Eugen DUMITRASCU, Daniel MILODIN, Dragos PALAGHITA - Optimum Criteria for Developing Defined Structures , Informatica Economica, vol. 12, nr. 2, 2008, pg. 43 - 54, ISSN 1453-1305
• Ion IVAN, Catalin BOJA -Optimizarea bicriteriala a software, Informatica Economica, vol. 10, nr. 1, 2006, pg. 17 - 24, ISSN 1453-1305
• Ion IVAN, Catalin BOJA -Optimizarea empirica a software, INFORMATICA ECONOMICA, vol. 9, nr. 2, 2005, pg. 43 - 50
• Ion IVAN, Cristian CODREANU - Optimizarea programelor Assembler, Informatica Economică, vol. 2, nr. 2, 1998, pg. 26 - 37
• Ion Ivan, Gheorghe Nosca, Otilia PÎrlog - The optimization of the software quality cost using neural networks, The 4th International Symposium of Economic Informatics Information Technology, Bucharest, May 6-9, 1999, INFOREC Printing House, pp. 177 Ă˘â‚Źâ€œ 180, ISBN 973-98508-5-5
• Ion IVAN, Adrian VISOIU, Mihai DOINEA - Image Processing Oriented to Security Optimization, Journal of Information Technology and Communication Security, The 2nd International Conference on Security for Information Technology and Communication, 19 - 20 November 2009, Bucharest Romania, ASE Publishing House Romania, pp. 31 - 38, ISBN 978-606-505-283-3
• http://www.ionivan.ro/teaching16600-procomp-10optimizare.php

Deci problema este deosebit de vastă, suculentă, inepuizabilă și sursă de soluții originale, drept care va dăinui peste veacuri, atât timp cât lumea vă căuta să-i fie din ce în ce mai bine. Optimizarea programelor este un lucru deosebit căci de acest proces epinde fundamental performanța oricărei aplicații, căci între o aplicație online rapidă și una mai lentă, diferența este acum de milioane de USD, la cât de mulți clienți fac trab=nzacții cu o aplicație de acest tip.

(23 decembrie 2017)

Lista aplicațiilor informatice

Lista aplicațiilor informatice este necesară pentru a vedea care sunt diferențele între ceea ce s-a făcut în informatică de-a lungul anilor.

Calculul de salarii.

Gestiunea mijloacelor fixe.

Gestiunea stocurilor.

Evidența bonurilor de consum.

Evidența de personal.

Gestiunea conractelor.

Centralizarea factutilor.

Gestiunea livrărilor.

Gestiunea calității.

Planificarea producției.

Calulul  capacitate.

Croirea optimă a barelor

Croirea optimă a reperelor dreptunghiulare.

Optimizarea rațiilor de consum.

Optimizarea producției.

Ordonanțarea producției.

Urmărirea producției.

Lansarea producției.

Urmărirea producției.

Controlul calității producției.

Rezervări  camere hotel.

Achiziții  bilete pentru...

Calcul deviz cheltuieli.
Optimizarea rutelor de transport.
Optimizarea amestecurilor de produse petroliere.

Calculul eficienței economice la...

Sistem expert pentru...

De când Internetul s-a răspândit peste tot au apărut aplicații care utilizează resursele acestuia.

Magazin electronic pentru...

Campul universitar al...

Plăți taxe și impozite.

Achiziții online bilete pentru...

Achiziționarea online de acțiuni pe bursă.

Rezervări online camere hotel.

Atribuire online de joburi.

Aplicație de e-Learning pentru...

Aplicație B2B pentru ...

Comandă online proiect de arhitectură.

Management întreprindere virtuală.

Management de documente.

Gestiunea intrărilor și ieșirilor în organizație.

Elaborare joc online.

Optimizare trasee turistice.

Prezentare locuri pitorești.

Scriere bloguri specializate.

Elaborare ziare online.

Elaborare cărți online.

Elaborare reviste științifice online.

Elaborare albume online cu fotografii tematice.

Testare online a cunoștințelor.

Reconstituire  online clădiri dărâmate.
Optimizarea online a alegerii unui credit bancar.
Programarea online la clinică.
Gestiunea online pacienților.
Utilizarea cardurilor de sănătate.
Asigurarea online de călătorie.
Achiziționarea online de suplimente.

Creare online cataloage roduse de...

Creare online cataloage  de materiale.

Creare online cataloage  filatelice

Muzeul virtual de .....

Expoziția virtuală de ....

Catalog online cu muzică.

Prezentare și vizonare filme online.

Crearea de arhivă pentru...

Accesarea online a arhivei de documente literare.

Accesarea online a arhivei de documente istorice.

Accesarea online a arhivei de manuscrise ...
Teleconferință online cu SKYPE multiplu.
Vot online.
Semnare petiție online.
Rețele de socializare.
Grupuri de lucru online.
Dezvoltare online de open source.
Evaluare online a proiectelor.
Emitere și transmitere de documente oficiale online semnate electronic.
Notar electronic.
Emitere cerfiticate online.
Optimizarea  online a traficului.
Plăți electronice.

Toate acestea au în față fie aplicație informatică pentru... fie subsistem informatic pentru .... fie soluție informatică pentru... fie bază de date pentru...

În timp această listă se va îmbogăți și cu alte aplicații pe măsură ce vor fi identificate. Este o certitudine că Lista aplicațiilor informatice este în continuă creștere din moment ce nici 5% din ceea ce aare nevoie societatea nu este realizat prin produse software.

(26 noiembrie 2017)

Optimizarea transporturilor

Optimizarea transporturilor a fost, este și va fi o problemă în care informatica are multe de spus. Optimizarea transporturilor a fost o provocare în anii de început ai informaticii pentru că la transportul:
- sfeclei de zahăr către fabricile de prelucrare se punea minimizarea cheltuielilor de transport;
- produselor petroliere prin conducte se punea scăderea costurilor contaminării;
- materialelor de construcție se punea problema rutelor optime prin alegerea de străzi;
- mărfurilor de același tip produse de fabrici prin plan cu costuri de transport minime.
În realitate a defini o problemă de transport înseamnă a specifica:
- sursele de unde pleacă produsele;
- numărul de tipuri de produse;
- cantitățile de produse pe fiecare tip;
- destinațiile pe tipuri de produse;
- tipurile de mijloace de transport;
- definirea de rute imposibile prin costuri infinite;
- costurile unitare de transport pe tip de produs și tipul  mijlocului de transport.
Ceea ce se învață la școală la Cercetări operaționale și era implementat prin programul TRANSPOR - numeci atât era permis la un moment dat să fie lungimea numelui de fișier cu text sursă, implementa un caz particular de problemă de transport definită prin:
- N sursede unde pleacă produsele;
- un singur tip de produse;
- cantitățile care pleacă de la surse;
- M destinații unde trebuie să ajungă produsele;
- un singur tip de mijloace de transport;
- cantitățile de la sursăt egale cu cantitățile de la destinație;
- definirea de rute imposibile prin costuri infinite;
- costurile unitare de transport.
Mi-a plăcut teza de doctorat elaborată de Dorina MOANȚĂ, coordonată de profesorul Eugen ȚIGĂNESCU, intitulată  Modelarea cibernetico-economica a sistemelor de transport, susținută în  ASE București, în anul 1998, care avea 194 pagini. Autoarea tezei Dorina MOANȚĂ, a mai publicat articolul SOME ASPECTS ON SOLVING A LINEAR FRACTIONAL TRANSPORTATION PROBLEM  în revista JAQM - Journal of Applied Quantitative Methods, vol.2, nr.3, 2007, pg. 343 -348. Tot ea a scris și o carte despre problema de transport tridimensională care mi-a fost oferită cu autograf și în care autoarea a făcut o generalizare care a introdus încă o dimensiune în problema de transport în afara dimensiunii cantităților și dimensiunii costurilor.
În vremurile de demult, pentru a optimiza trebuiau date:
- sursele și cantitățile totale;
- destinațiile și cantitățile totale;
- costurile unitare de transport de la o sursă la destinațiile reale.
Unde nu se specificau costuri se considerau costuri infinite și acolo nu se transporta nimic căci nu exista rută de transport. Produsul software afișea:
- costul minim de transport;
- cantitățile optime de transportat indicând sursa și destinația;
- unele date tehnice privind rulările efectuate.

Am lucrat cu produsul TRANSPOR de la calculatorul FELIX C-256 făcut în Franța ani în șir și chiar mi-a fost util, nu numai la disciplina de Programe aplicative unde am lucrat 1.000 de ani și am încheiat în 1992. Mulți programatori s-au dat în bărci redescoperind roata prin a scrie câte un program propriu să-ți rezolve problemele lor de transport cu iz local, de parcă algoritmul din cărți avea o implementare la Cuca Măcăii, alta la Oarja și cu totul alta la Chiajna sau Ghimpați. Ca exercițiu de programare merită încercat, dar nu mai mult de atât. Știind că se lucrează cu matrice rare și că acestea sunt foarte drăguțe dacă sunt reprezentate prin structuri dinamice, o aventură n-ar strica având o bibliotecă de funcții care traversează astfel de matrice cu așa reprezentări. Și dacă este bal, bal să fie, se vor face și calcule legate de volumul de prelucrări și de necesarul de memorie, ca tacâmul să fie complet.

Am o poveste cu o implementare proastă a problemei de transport care funcționează perfect dar fără reoptimizări.

Era vorba de transportul sfeclei de zahăr.

Se producea zahăr în Ț fabrici de ani de zile cu un anumit cost de transport.

Fiind transport cu tractoare și remorci și un singur tpodus, unuia i-a venit ideia să implementeze o optimizare, dar fiind superficial n-a ținut seama de o situație reală.

S-a obținut soluția optimă.

Au început transporturile. Din întâmplare s-au efectuat transporturile cu costuri unitare peste medie.  O fabrică de zahăr a avut probleme tehnologice și și-a întrerupt producția pentru o lună. Sfecla nu așteaptă și a fost preluată de alte fabrici numai că trasportul s-a făcutcu:

- tractorul până la vagoane de tren, încărcare, descărcare, ăncărcare;

- trenul, descărcare, încărcare în remorci;

- tractorul la fabrică, descărcare și pus pe banda transportoare.

Așa că soluția așa-zisă optimă prin realctualizare s-a dovedit catastrofală. Morala: înainte de optimizare simplistă trebuie analiză realistă, altfel totul se compromite.

Acum problema de transport este și mai importantă căci firmele de curierat rapid folosesc și problema ruceacului dar și rute optime.

(25 noiembrie 2017)

Vectorizarea masivelor multidimensionale

Vectorizarea matricelorm este o terminologie cam vrutală prin care s=a căutat o mai bună utilizare a memoriei interne a unui calculator în vremurile de demult când memoria atât internă, cât și memoria externă era o mare problemă. Un calculator IBM 360 considerat de top  prin  august 1969 avea memorie de 4096 Kb și de aici trebuie pornită orice discuție legată de dimensiunea oricărei probleme de rezolvat cu calculatorul. Un sistem de ecuații de maximum 30variabile  și  30 ecuații însemna definirea unei matrice  

DIMENSION A(30,30) 

în FORTRAN ocupa 30 * 30 * 4 bytes adică 3,515 Kb. La un program de adunare a două matrice, fiecare având 100 linii și 100 de coloane se vor defini în programul FORTRAN 

DOUBLE PRECISION A(100,100), B9100, 100), C(100,100)

necesarul de memorie va fi de 234,375 adică aproximativ 235 Kb, adică 23% din disponibilul de memorie al calculatorului. Calculele se fac riguros și destul de exact, dar tot în acea memorie de 1024 Kb trebuie să încapă pe lângă date și programul rezultat după editarea de legături în forma executabilă. Deci în niciun caz nu va fi vorba de dezmățul de memorie care este acum când un calculator modest are memorie RAM de 4 Gb echivalentul a 16.384 de calculatoare IBM 360 din 1969. 

Această situație a impus vectorizarea, adică un procedeu de a face economie de memorie.

În vremurile de dinainte de 1980 despre alocarea de memorie se știa clar că este numai statică. Limbajul ALGOL 67 amintea ceva de blocuri, de alocare și de dealocare dar nu am avut cunoștință de implementări complete ale limbajului acesta. 

În condițiile implementării limbajelor FORTRAN și COBOL era mare deosebire între conceptele de:

- memorie alocată, adică modul cum au fost definite variabilele în program;

- memorie utilizată, adică tot ce se inițializa și se folosea sub controlul instrucțiunilor executabile.

Într-un program FORTRAN se definea un masiv tridimensional

DIMENSION X(20,10,30) 

și se inițializau constantele N cu 10, M cu 15 și H cu 7.

În secvența:

     DO 30 I=1, N

     DO 30 J=1, M

     DO 30 I=K, 7

30 X(I,J,K) = I + K * J

este inițializată numai o parte din masivul tridimensional, ceea ce înseamnă că restul de memorie este nefolosit. Se falculează  gradul de ocupare G = N*M*K / (20*10*30) În cazul concret G = 0,175 adică nu nivel foarte mic.

Dacă se lucrează cu masi.ve având mai multe dimensiuni pentru a calcula exact poziția unui element în masiv formulele arată că trebuie date niște constante. La masivul bidimensional este necesar să se știe cât a fost alocat numărul de coloane ca valoare numerică. Dacă se lucrează cu masive unidimensionale această restricție dispare și lumea preferă să lucreze cu masive unidimensionale. Vectorizarea, acest termen care nu prea există în limba română și preluat brutal din engleză, înseamnă a pune în corespondentă elementele unui masiv bidimensional cu elementele unui masiv unidimensional și a lucra cu masivul unidimensional efectuând tot felul de operații ca și cum s-ar lucra cu masivul bidimensional.

Dacă se consideră un masiv bidimensional

DIMENSION A(10,10)

se inițializează N=5, M=5, se inițializează cumva numai primele 5 linii și primele 5 coloane pentru a calcula suma elementelor de pe diagonala principală se scrie secvența:

     S=0     

     DO 30 I=1, N*M

30 S = S + X(I + (M-1))

Avem bgijă ca să scriem o secvență de vectorizare de forma:

DIMENSION A(10,10), X(100)

...............

      K=1

      DO 30 I=1, N

      DO 30 J=1, M

      X(K) = A(I,J)

30  K=K+1

Discuțiile legate de avantajele vectorizării sunt lungi și avantajele din acele vremuri făceau diferența la apelul de subprograme unde parametrii formali arătau cu mult mai bine decât în cazul în care se scriau masive multidimensionale însoțite de niște constante care dădeau amri bătăi de cap programatorilor care doreau să facă metenanță atunci când cu lucrau cu constante simbolice definite undeva la începutul programului principal în blocuri COMMON sau de folosirea lui EQUIVALENCE.

DIMENSION X(100), B(10,10)

EQUIVALENCE (B(1),X(1))

Pune în corespondență X(10 cu B(1,1), X(2) cu B(2,1)....X(100) cu B(10,10). Se ține seama de regula după care se face linearizarea. Sunt limbaje unde linearizarea se face coloană de coloană, iar altele linearizarea se face linie de linie. Aici am presupus linearizarea coloană după coloană.

Rste o vectorizare la nivel de zone de memorie alocate static, lucru diferit de vectorizarea aceea care ține seama numai de ceea ce s-a inițialozat.

(25 noiembrie 2017)

Mijloacele fixe

Mijloacele fixe sunt deosebit de importante și informatica are suficiente elemente ca să-i ajute pe decidenți în legătură cu acestea, pentru a menține fabrica la linia de plutire cel puțin și nu prin mijloacele fixe să o comande la înapooiere, iar ceva mai târziu la dispoziție.

În vremurile de demult aplicațiile de gestiune a mijloacelor fixe evidențiau:

- datele tehnice ale fiecărui mijloc fix;

- prețul de achiziție;

- ceva despre amortizări;

- detalii privind produsele și operațiile realizate pe ele;

- date despre reparațiile capitale;

- ceva despre reparațiile generate de defectările accidentale;

- date despre randamente pe tipuri de operații;

- date despre modificările aduse în timp.

Este rezonabil ca rapoartele obținute de la aplicația de mijloace fice să ajute pe decident să:

- cumpere noi utilaje;

- transfere utilaje:

- dea la casat utilaje;

- le schimbe destinațiaadauge senzori de achiziție date;

- integreze în roboți;

- ceară actualizări de prețuri;

- analizeze randamentele;

- scoată din uz forțat;

- calcul de capacitate;

- accelereze amortizarea;

- creșterea fiabilității;

- îmbunătățească adăugând noi dispozitive;

- integreze în alte linii de producție.

Există tentașia de a supraevalua terenuri dar mai ales clădiri motivele sunt de o bizarerie totală. Am cunoscut fabrici:

- unde se lucra cu strunguri care fuseseră amortizate în urmă cu 30 de ani;

- care țineau parcuri de mașini puse în conservare, dar care niciodată nu se vor refolosi;

- pentru care echipamentele în conservare erau sursă de furtișaguri;

- la care vândutul la fie vechi era inacceptabil datorită marilor difernțe dintre trecut și fierul vechi. Folosirea aplicației de mijloace fixe numai și numai pentru contabilitate este un lucru pe jumătate făcut bine. Cealaltă jumătate se referă la:

- alegerea momentului de înlocuire optimă;

- identificarea locurilor înguste pe fluxul tehnologic din motive de fiabilitate;

- stabilirea acelor rezerve de unde au loc creșteri ale producției.

Acum când achizițiile de date sunt puternice este posibil ca aplicația de mijloace fixe să ofere mult mai multe informații, inclusiv să stabilească unde se poziționează fabrica din punct de vedere al progresului tehnic. În momentul în care un utilaj are randament de 100 de repere pe oră și un altul mai nou are randament de 300 de aceleași repere pe oră și consumuri de energie cu 50% mai mici iar rebuturile scat de la 10% la 3% deja un model adecvat va arăta decalajul în ani, adică va măsura rămânerea în urmă, să zicem cu 15 ani, ceea ce este îngrozitor.

Era la Uzinele 23 august în 1970 o secție de producție uitată de lume care păstra în geamuri acele x-uri de hârtie albă de la camuflajele de bombardament din războiul care se terminase de 25 de ani.

(23 noiembrie 2017)

Programarea producției

Programarea producției este aplicația de cea mai mare complexitate pentru orice sistem informatic pentru că ea include baze de date despre:

- utilajele existente în fabrică;

- produsele care se fabrică;

- gamele de operații;

- materiile prime;

- stocuri de subansamble;

- muncitori;

- sortimentul planificat;

- utilitățile necesare;

- cheltuielile implicate;

- stocurile de materii prime;

- stocurile de produse finite;

- documentații ale reperelor;

- SDV-uri;

- furnizori și contracte;

- clienți și contracte.

A avea un program de producție înseamnă a oferi la începutul fiecărui schimb fiecărui muncitor ceea ce are de făcut.

A avea un program de producție înseamnă a avea materiile prime în stoc atunci când sunt solicitate pentru a fi la dispoziția muncitorului executant.

A avea un program de producție înseamnă a avea utilaje operaționale pe durata procesului de producție definit pe un interval de timp specificat.

A avea un program de producție înseamnă a avea muncitorii operaționali pe intervalul de producție specificat.

A avea un program de producție înseamnă a dispune de utilități căci fără energie electrică de exemplu orice program de producție este o himeră.

A avea un program de producție înseamnă a dispune de resurse la momentul cerut și a avea un nivel de disciplină foarte ridicat pentru că orice abateri de la termenele incluse în soluția optimă înseamnă sabotarea procesului de optimizare și reluarea calculelor care în final conduc la soluții optime, dar cu mult mai proaste decât soluțiile empirice, bazate pe experiența cotidiană.

A avea un program de producție înseamnă a  dispune de resurse imense care să permită:

- popularea bazelor de date;

- actualizarea bazelor de date;

- respectarea programelor zilnice de producție;

- derularea de activități stabile;

- culegerea de date în timp real;

- a avea capacitatea de a amortiza efectele riscurilor.

Aplicația de programare a producției este acompamiată de aplicații de:

- planificare a producției;

- lansare a producției;

- urmărire a producției;

- stocarea și livrarea producției.

Acum se vorbește despre ERP-uri acică Enterprise Resource Planning, dar când ajungem la discuții legate de spre ce și cum este tărășenia cu programarea producției mulți vorbesc despre aspecte caricaturale. Îmi dau seama de cum stau lucrurile doar din faptul că mi se spune că aplicația de programare a producției se implementează în cel mult două săptămâni. Voi demonstra aici și acum ce înseamnă bazele de date necesare programării producției.

Baza de date a produselor finite înseamnă atâtea articole câte roduse finite diferite se execută în fabrică, produse despre care trebuie cunoscute:

- codul unic de produs;

- denumire produs;

- cod documentație;

- date tehnice;

- niveluri caracteristici de calitate;

- standard de realizare;

- codul gamei de operații;

- loc de stocare;

- loc de producție;

- cantitate planificată;

- cantitate realizată;

- preț planificat;

- preț efectiv;

- legăturile cu subansamblele de pe primul nivel de descompunere a arborescenței.

Mai sunt multe alte câmpuri ceea ce duce la o lungime a articolelor foarte mare, iar efortul de a culege din diferite locuri aceste informații impun forțe deosebite pentru a realiza popularea bazei de date într-un timp decent, rezonabil și operațional.

Baza de date a reperelor înseamnă a defini articolul cu câmpuri de descriere completă pentru identificare, pentru operații de prelucrare, pentru echipamente necesare, pentru SDV-uri, meserii care trenuie folosite pentrun operații, durată medie de realizare și toate acele detalii din care orice om să se lămurească ce are de făcut pentru a face reperul cu pricina, inclusiv aspecte legate de mod de stocare, de procedurile de verificare a calității și multe, multe altele. Și pentru descrierea reperelor sunt necesare forțe imense ca procesul de pregătire al populării bazei de date să nu dureze 1.000 de ani.

Baza de date a subansamblelor înseamnă  a derula un proces cmplex din care să rezulte reperele și subansambleme utilizate, ordinea de asamblare, cine face , unde se face, cât durează și multe, multe altele. Și pentru descrierea subansamblelor sunt necesare forțe imense de specialiști care să cunoască procesele de asamblare pentru a reconstitui graful GANTT care la extremitatea din dreapta au produsul finit, ca procesul de pregătire al populării bazei de date să nu dureze 1.000 de ani.

Baza de date a legăturilor înseamnă a stabili arcele dintre repere și subansamble ca să se obțină prin parcurgerea de jos în sus - implozie, la produsul finit. Cine a făcu în facultate Structuri de date și a lucrat cu arbori oarecare știe ce înseamnă adresele nodurilor și cum se gestionează ele. Nodurile sunt aici reperele sau subansamblele. Reperele sunt frunzele din structura arborescentă.

Baza de date a utilajelor înseamnă foarte mult efort căci utilajele au foarte multe date tehnice, sunt foarte diferite și pentru a calcula capacitățile lor sunt algoritmi extrem de sofisticați. Se înregistrează detalii privind reparațiile și întreruperile tehnologice.

Baza de date a muncitorilor înseamnă a ști multe despre muncitor de la date de identificare, calificare, experiență și disponibilitatea sa de a lucra anumite operații și de a folosi anumite utilaje.

Baza de date a materialelor înseamnă a avea date despre caracteristici de identificare, caracteristici tehnice, loc de stocare, furnizor, stocuri existente și foarte multe alte lucruri deosebit de necesare programării producției.

Baza de date a gamei de operații înseamnă a avea exact ordinea de derulare a operațiilor, acel graf hamiltonian, fiind deosebit de important pentru problemele de ordonanțare în care se iau în considerare M produse, N mașini și K operații de prelucrare și asablare.

Baza de date a rețetelor de fabricație înseamnă a avea descrierea amestecurilor de materii prime și a derulării proceselor de producție, de regulă din chimie sau alte industrii unde se produc amesteruri.

Baza de date a operațiilor înseamnă descrieri complete și complexe a datelor de identificare, a utilajelor pe care se realizează, calificarea muncitorului, durate, mențiuni de pregătire, riscuri, poza reperului, SDV-urile necesare și foarte multe altele.

Baza de date a calendarului înseamnă a cunoaște zilele de lucru, a zilelor când nu se lucrează, a specificațiilor de lucru pe schimb ți multe altele care să arate cu rigurozitate și realism care este fondul de timp când se lucrează în fabrică, șa fiecare loc de muncă. Se înregistrează acolo și duratele de întreruperi tehnologice.

Baza de date a contractelor înseamnă a ști care sunt furnizorii, ce materiale oferăm, cantitățile, eșalonări, unde se stochează, cine răaspunde și multe, multe altele.

Actualizările acestor baze de date se face în timp real și calitatea acestora determină 100% calitatea soluției care este fie o defalcare, fie o ordonanțare, care sunt lucruri absolut diferite.

Am avut o experiență nu prea fericită cu completarea fișelor tehnologice pentru utilajele unei fan=brici de motoare electrice, când am adus 400 de studenți să treacă datele din fișe în foi de programare. Au lucrat aceștia cam o săptămână, nu au făcut decât 20% din ce trebuia căci restul nu era pregătit. Problema de ordonanțare acolo a murit.
Programarea producției este piatra unghiulară a oricărui sistem informatic adevărat, dar cine reușește să o implementeze, cu siguranță că-și asumă riscuri imense dacă cel putțin 95% din ceea ce se întâmplă acolo în producție nu merge perfect, adică perfect, fără nicio abatere. Numai 5% este îngăduit să meargă nu în dorul lelii, ci cu mici diferențe absolut accidentale.

(23 noiembrie 2017)

Gestiunea de stocuri

Gestiunea de stocuri a rămas acum tot la stadiul de acum 1.000 de ani, deși achizițiile de date, senzorii și toate cele ar fi trebuit să schimbe radical concepția și percepția legată de stocuri. Nici acum nu se calculează de nicio sămânță costul stocării, așa cum nici acum 50 sau 40 de ani în urmă nu se făceau calcule pentru stocare, căci niciunde nu se țin separat cheltuielile de stocare detaliate. Cât privește optimizarea de stocuri deja problema este cât casa, ceea ce se resimte în toată economia cât este ea de piață, căci carențele de la gestiunea stocurilor se resfrânge mai ales în comerțul cu amănuntul unde moralitatea este zero.

În era cartelelor perforate gestiunea stocurilor însemna cartele cu:

- cod material,

- denumire material,

- unitate de măsură,

- cantitate contractată,

- intrări, 

- ieșiri,

- preț unitar,

- cod depozit,

- nume furnizor,

- cod contract,

- cod depozit.

Situațiile obținute de la calculator vizau:

- calcul stocuri finale;

- valori stocuri pe depozite;

- materiale fără mișcare;

- grad de îndeplinire a aprovizionării;

- rupturile de stoc;

- stocurile materialelor critice.

Când au apărut bazele de date, articolele s-au îmbunătățind incluzând și dinamica stocurilor, ceea ce a permis o evidențiere mult mai detaliată a comenzilor, a aprovizionării, a dificultăților cu asigurarea stocurilor și multe alte elemente, inclusiv distribuirea pe persoane a sarcinilor. Dacă au fost definite baze de date pentru bonuri de consum, pentru lansarea comenzilor de aprovizionare, pentru contracte și pentru produse, toate calculele de stocuri și de planificare din contracte aveau o singură sursă și anume planul de producție anual. Pornind de la planul de producție se calcula necesarul de materiale bazat pe consumurile specifice. De la cantitățile necesare se efectuau contractele cu beneficiarii și tot așa. Eșalonarea aprovizionărilor depindea de planul defalcat al producției pe lună, spre exemplu. În vremurile de demult stocurile se calculau simplu, pornind de la cantitatea de produse finite, transpunându-se în algoritmi ceea ce se făcuse manual zeci și zeci de ani. experiența era cea care domina procesele de stocare, căci se știa:

- cantitatea de aprovizionat;

- durata de la moentul de lansare a comenzii la momentul sosirii materialului;

- riscurile care apar și soluții de avarie;

- abordările deterministe fiind la ele acasă.
Acum cu achizițiile de date se crează serii de timp cu evoluțiile stocurilor consemnând modificările la momentele acre apar, cu toate datele de identificare, fără tastări de date, ci prin cântăriri și numărări electronice. Cât despre costuri, evident, ele se vor măsura cu precizie căci trebuie știute acre sunt cheltuielile cu manipulările, cu chiriile, cu energia, cu ambalarea, cu menținerea ambientului și cu mentenanța. Orice altă abordare duce la situații neplăcute căci codificarea neclară face ca aprovizionările să fie repetate pentru aceleași materiale și stocurile să fie nejustificate să nu mai vorbim de imobilizările financiare.
Știu o fabrică de utilaje care la privatizare s-a vândut pe nimic, dar cel ce a cumpărat-o, băiat deștept, știa că stocurile de materii prime erau imense, iar cuprul, bronzul și altele asemenea au făcut business-ul lui foarte-foarte rentabil, iar alții, fraieri au rămas cu buza umflată, că nu-și vindeau țara. Numai că deșteptul avusese acces la gestiunea stocurilor ținută pe un FELIX C-256 și el a știut să interpreteze stocurile fără mișcare și expresia lor valorică. La el nici terenurile și nici clădirile nu valorau mare brânză.

(23 noiembrie 2017)

Programele de optimizare

Programele de optimizare au marcat foarte interesant istoria informaticii românești pentru că:

- erau necesare produse software care să implementeze algoritmii de optimizare;

- se urmărea maximizarea dimensiunii problemei de rezolvat;

- dintr-o mulțime de algoritmi era selectat acela care permitea atingerea unui obiectiv;

- transpunerea de algoritmi de cercetări operaționale presupuneau artificii;

- din start programatorii și-au dorit să realizeze programe generale, pentru biblioteci;

- testarea programelor de optimizare presupune utilizarea de exemple din cărți;

- unele programe de optimizare au zone care nu sunt testate din lipsa exemplelor;

- restricțiile de memorie sunt extrem de dure, iar volumul de calcule este și el dur.

Problema de programare liniară are mai mulți algoritmi și au fost implementări interesante și spectaculoase, iar mie mi-a plăcut foarte mult prin anii '80 că realizatorii lor propuneau și niște inegalități care permiteau calculul dimensiunii maxime a problemei de rezolvat, știut fiind faptul că în acele vremuri capacitatea memoriei interne era o mare problemă, adică o teribilă restricție.

Voi lua acum un alt exemplu, nu o procedură de optimizare și un subprogram pentru calcului produsului a două matrice.

Procedura va avea necesita definirea următorilor operanzi:

- o matrice A[M][N];

- o matrice B[N][K];

- o matrice rezultat C[M][K];

- variabilele de control i, j, k;

- variabila de lucru Cij unde se calculează suma de produse.

Dacă procedura în format executabil ocupă L bytes, matricele A, B, C și variabila  Cij sunt de tip float, iar variabilele de control i, j, k, m, n sunt de tip int, iar disponibilul de memorie al calculatorului este de DISP bytes, restricția pe care o construim este:

(M * N + N * K + M * K + 1) * 4 + 12 < DISP

unde:

- M * N *4 dimeniunea matricei A exprimată în bytes; 

-  N * K * 4 dimeniunea matricei B exprimată în bytes; 

- M * K * 4 dimeniunea matricei A exprimată în bytes;  

-  1  * numărul de bytes ocupați de variabila Cij; 

- 6 * 2 = 10 bytes ocupați de variabilele i, j, k m, n, h.

După același raționament se calculează restricțiile pentru orice program de optimizare, lucru deosebit de important când se scriau astfel de programe. Acum când se lucrează la nivel de Gb astel de restricții ne permit să constatăm câte zeci de mii de linii și câte zeci de mii de coloane au matricele cu care dorim să lucră, ceea ce este extrem de confortabil în zilele noastre. Nu am spus nimic de lungimile de la segmente care în vremurile de demult aveau aportul lor în a crește sau din contră în a reduce performanțele programelor dacă definirea de variabile era multisegment.

Chestiunile dure apăreau și în ceea ce priveau volumul de operații de prelucrare  exprimat grosier ca număr de instrucțiuni executabile. Pentru secvența de calcula aprodusului de două matrice volumul de prelucrări V este dat de relația:

V = n * m * 2 *( 1 + h) instrucțiuni.

Am folosit termenul grosier pentru a arăta că nu țin seama cât de diferite sunt instrucțiunile for() de cele de calcul și de atribuire. Cel pai riguros ar fi dacă s-ar lucra ca număr de cicluri mașină.

Pachetele de programe de optimizare în care apar iterații trebuie să conțină multe elemente dintre care limitarea duratei maxime disponibile, preciziei și a numărului de iterații sunt esențiale. În plus, ele trebuie să permită afișarea:

- datelor inițiale;

- soluției optime;

- erorii de calcul;

- numărului de iterații;

- situațiilor speciale de întrerupere.Acum au intrat în zona banalului aceste programe de optimizare, lumea căutând să le folosescă mai ales în simularea de situații cu postoptimizări și parametrizări. De asemenea, am văzut niște aplicații de optimizare multicriterială cu implementări interesante în acele vremuri, prin agregări care reduceau tot la o banală optimizare. N-am insistat, căci de prea multe ori am văzut aplicat algoritmul simplex la probleme care se pretau la programare în numere întregi. Una este să se optimizeze producția de cutii de conserve unde rotunjirea este nesemnificativă și alta este să se optimizeze cu simplex producția de autorurisme care rotunjire devine catastrofală la o adică.
Programele de optimizare au reprezentat parte din mitologia istoriei programării pentru că implementările în care numărul de variabile și numărul de restricții dacă depășeau ordinul miilor deveneau ceva de domeniul fantasticului.

(23 noiembrie 2017)

Evidența contabilă

Despre produsele software dedicate evidenței contabile este de vorbit mult, chiar prea mult, dar de zis nu ai ce prea zice pentru că:

- există prea multe produse dedicate acestui subiect;

- soluțiile sunt de un primitivism obscen;

- toate fac cam aceleași lucruri;

- salturile de la o generație la alta sunt minuscule;

- abordările nu încorporează noile tehnologii;

- achizițiile de date nu prea se văd;

- prea multe au un singură persoană dezvoltator;

- lipsește marea aplicație de contabilitate  în cloud.

Îmi aduc aminte că am văzut de-a lungul istoriei informaticii făcându-se contabilitate cu:

- aritmometrul pe foi clasice de documente contabile;

- mașina de facturat eletromecanică și zgomotoasă;

- cu IBM 360 și FELIX C 256 având intrări pe cartele;

- pe PC-uri la posturi de lucru individuale și cu CD;

- în rețea intranet cu software dedicat contabilității;

- în rețea cu software pe abonament. 

Orice discuție am avut cu specialiștii care realizaseră unele dintre produsele software de contabilitate a avut răspunsuri dintre cele mai ciudate atunci când al discutat despre matricea de corespondențe și despre lanțul de înregistrări valide. De asemenea răspunsul ferm și negativ dacă produsele respective permit ținerea contabilității de către nespecialiști, m-au dezamăgit profund. Prin 1969 - 1970 m-am ocupat la lucrarea mea de diplomă de construirea unui limbaj destul de apropiat de limbajul natural, cu definiri BNF pentru contabilitate. Sunt sigur că între timp s-au înregistrat progrese remarcabile și citirea cărții verzi de la MFP din strada Apolodor 17 ar duce precis la o interfață prietenoasă care să permită contabilitatea la ei la firmă a celor care nu au studii de contabilitate. Contabilii autorizați ar trebui să se ocupe de cu totul altceva decât să introducă în disperare facturi, bonuri și alte ciudățenii și apoi prin comenzi abracadabrante ale unor produse software ermetice să permită obținerea a tot felul de bilanțuri,, balanțe și a celorlalte daravere cerute de fisc, chestii care la urma urmei ar trebui trimise online cu semnătură electronică pentru că suntem în anul de grație 2017. Probabil o astfel de soluție se va înregistra în anul 2300 al erei noastr desigur, iar eu voi fi oale și ulcele ca și voi.
Evidența contabilă  este exemplul al dezvoltării economiei de piață haotice în producția de software în care risipa de muncă vie și tot ce zicea prietenul nostru Karl Marx se adevereșt, căci inflația de produse software contabile duce la efecte dezastruase asupra celor care-și dedică timpul să realizeze acest tip de produse și să intre cu ele pe o piață de software suprasaturată.

(23 noiembrie 2017)