Programarii in C

3

Cuprins

Capitolul 1. Compilarea, decompilarea i obscurizarea programelor C#

1. Obiective ............................................................................................................................... 9 2. Structura general a unui program C# ................................................................... 10 2.1. Clase ............................................................................................................................ 10

2.2. Clase statice i membri statici .......................................................................... 11 2.3. Cmpuri constante ................................................................................................ 13 2.4. Structuri .................................................................................................................... 14 2.5. Trimiterea argumentelor prin referin ...................................................... 16 2.6. Operaiile de boxing i unboxing ..................................................................... 16 2.7. Enumeraii ................................................................................................................ 17

3. Compilarea, decompilarea i obscurizarea codului .......................................... 18 3.1. Compilarea. Limbajul Intermediar Comun ................................................. 18 3.2. Decompilarea. Programul .NET Reflector .................................................... 19 3.3. Compilarea n modurile Debug i Release ................................................... 23 3.4. Obscurizarea codului. Dotfuscator ................................................................. 29

4. Aplicaii ................................................................................................................................ 30 Capitolul 2. Stilul de scriere a codului. Tratarea excepiilor. Interfaa grafic cu utilizatorul

1. Obiective ............................................................................................................................. 35 2. Stilul de scriere a codului ............................................................................................. 35

2.1. Acoladele ................................................................................................................... 36 2.2. Standarde de programare .................................................................................. 37 2.3. Convenii pentru nume ....................................................................................... 39

3. Tratarea excepiilor ........................................................................................................ 42 3.1. Tratarea excepiilor pe firul de execuie al aplicaiei ............................. 46

4. Interfaa cu utilizatorul ................................................................................................. 47 4.1. Proiectarea comenzilor i interaciunilor ................................................... 47 4.2. Considerente practice .......................................................................................... 48 4.3. Profilurile utilizatorilor ...................................................................................... 50

5. Interfaa grafic cu utilizatorul n Microsoft Visual Studio .NET ................. 51 6. Elemente de C# ................................................................................................................ 58

6.1. Clase pariale ........................................................................................................... 58 6.2. Proprieti. Accesori ............................................................................................. 59 6.2.1. Accesorul get ................................................................................................. 60 6.2.2. Accesorul set .................................................................................................. 61

Florin Leon (2012). Aplicatii de ingineria programarii in C#, Tehnopress, Iasi, ISBN 978-973-702-909-6http://florinleon.byethost24.com

4

6.2.3. Aspecte mai complexe ale lucrului cu proprieti ................................ 62 7. Aplicaii ................................................................................................................................ 65 Capitolul 3. Reutilizarea codului cu ajutorul DLL-urilor

1. Obiective ............................................................................................................................. 69 2. Bibliotecile legate dinamic .......................................................................................... 69 3. Crearea DLL-urilor n C# .............................................................................................. 70

3.1. Legarea static ........................................................................................................ 72 3.2. Legarea dinamic................................................................................................... 72 3.3. Depanarea unui DLL ............................................................................................. 74

4. Grafic n C# ...................................................................................................................... 75 5. Aplicaii ................................................................................................................................ 77 Capitolul 4. Documentarea unui proiect. Fiiere de ajutor

1. Obiective ............................................................................................................................. 81 2. Crearea de fiiere de ajutor ......................................................................................... 81

2.1. Crearea de fiiere HLP ......................................................................................... 81 2.2. Crearea de fiiere CHM ........................................................................................ 86

3. Activarea unui fiier de ajutor prin program ....................................................... 88 3.1. Process.Start ............................................................................................................. 88 3.2. HelpProvider ........................................................................................................... 88 3.3. Help .............................................................................................................................. 89

4. Generarea automat a documentaiei API ............................................................ 90 5. Comentariile ...................................................................................................................... 92 6. Lucrul cu fiiere n C#: ncrcare, salvare ............................................................. 95 7. Aplicaii ................................................................................................................................ 96 Capitolul 5. Diagrame UML

1. Obiective .......................................................................................................................... 105 2. Diagrame principale ale UML .................................................................................. 105

2.1. Diagrama cazurilor de utilizare .................................................................... 105 2.2. Diagrama de clase............................................................................................... 107 2.2.1. Dependena ................................................................................................. 107 2.2.2. Asocierea ...................................................................................................... 108 2.2.3. Agregarea i compunerea ..................................................................... 110 2.2.4. Motenirea ................................................................................................... 110 2.2.5. Metode abstracte i virtuale ................................................................. 112 2.2.6. Interfee ........................................................................................................ 113 2.2.7. Trsturi statice ........................................................................................ 113 2.3. Diagrame de activiti....................................................................................... 114 2.4. Diagrama de secvene ....................................................................................... 117

3. Altova UModel ................................................................................................................ 118


5

3.1. Diagrama de clase............................................................................................... 119 3.1.1. Generarea de cod ......................................................................................... 120 3.1.2. Crearea diagramei unui proiect existent ........................................... 125 3.1.3. Aranjarea automat a elementelor din diagrame .......................... 128

3.2. Celelalte diagrame .............................................................................................. 128 4. Aplicaii ............................................................................................................................. 128 Capitolul 6. Arhitectura MVC

1. Obiective ........................................................................................................................... 131 2. Introducere. Arhitectura cu trei straturi ............................................................ 131 3. Arhitectura MVC ............................................................................................................ 133 4. Arhitectura MVP ............................................................................................................ 135

4.1. Variante de actualizare a Vizualizrii ......................................................... 136 5. Aplicaii ............................................................................................................................. 138

Capitolul 7. ablonul de proiectare Metoda Fabric

1. Obiective .......................................................................................................................... 151 2. ablonul creaional Metoda Fabric ..................................................................... 151 3. Exemplu de implementare ....................................................................................... 152 4. Motenirea i polimorfismul .................................................................................... 154

4.1. Polimorfismul ...................................................................................................... 154 4.2. Clase abstracte ..................................................................................................... 154 4.3. Interfee .................................................................................................................. 155 4.4. Membri virtuali ................................................................................................... 156 4.5. Clase sigilate i membri sigilai .................................................................... 158 4.6. nlocuirea unui membru cu ajutorul cuvntului cheie new .............. 159 4.7. Accesarea clasei de baz cu ajutorul cuvntului cheie base ............. 160

5. Aplicaii ............................................................................................................................. 161 Capitolul 8. abloanele de proiectare Singleton i Prototip

1. Obiective .......................................................................................................................... 167 2. ablonul creaional Singleton .................................................................................. 167

2.1. Exemplu de implementare ............................................................................. 168 3. ablonul creaional Prototip .................................................................................... 169

3.1. Exemplu de implementare ............................................................................. 170 4. Aplicaii ............................................................................................................................. 172

Capitolul 9. ablonul de proiectare Faad

1. Obiectiv ............................................................................................................................. 185 2. Scop i motivaie ........................................................................................................... 185 3. Aplicabilitate .................................................................................................................. 186 4. Analiza ablonului ........................................................................................................ 187


6

5. Exemplu de implementare ....................................................................................... 188 6. Aplicaie ............................................................................................................................ 190

Capitolul 10. ablonul de proiectare Proxy

1. Obiectiv ............................................................................................................................. 193 2. Scop i motivaie ........................................................................................................... 193 3. Aplicabilitate .................................................................................................................. 194 4. Analiza ablonului ........................................................................................................ 195 5. Exemplu de implementare ....................................................................................... 196 6. Aplicaii ............................................................................................................................. 197

Capitolul 11. ablonul de proiectare Comand

1. Obiective .......................................................................................................................... 211 2. Scop i motivaie ........................................................................................................... 211 3. Aplicabilitate .................................................................................................................. 214 4. Analiza ablonului ........................................................................................................ 215 5. Exemplu de implementare ....................................................................................... 216 6. Aplicaie ............................................................................................................................ 218

Capitolul 12. Evaluarea vitezei de execuie a unui program

1. Obiective .......................................................................................................................... 231 2. Metoda DateTime.......................................................................................................... 231 3. Pointeri n C# ................................................................................................................. 232 4. Metoda PerformanceCounter ................................................................................... 234

4.1. Metode de accelerare ........................................................................................ 235 5. Metoda Stopwatch ........................................................................................................ 236 6. Compilarea JIT ............................................................................................................... 236 7. Aplicaii ............................................................................................................................. 238

Capitolul 13. Testarea unitilor cu NUnit

1. Obiectiv ............................................................................................................................. 243 2. Testarea unitilor ....................................................................................................... 243 3. Utilizarea platformei NUnit ...................................................................................... 244 4. Aplicaii ............................................................................................................................. 249

Capitolul 14. Rapoarte de testare

1. Obiective .......................................................................................................................... 253 2. Testarea unei ierarhii de clase ................................................................................ 253 3. Aplicaie ............................................................................................................................ 256

Referine .................................................................................................................... 263


7

Cuvnt nainte

n anul 2001 am nceput s predau laboratoarele de Ingineria programrii la Facultatea de Automatic i Calculatoare de la Universitatea Tehnic Gheorghe Asachi din Iai. La acel moment, n unele faculti de profil din Romnia, aceste laboratoare se concentrau pe programare vizual Windows, astfel nct n primii ani coninutul s-a axat pe programare folosind Borland C++ Builder i Microsoft Visual Studio cu Microsoft Foundation Classes (MFC). Pe lng aspectele de programare vizual, am prezentat nc de pe atunci chestiuni legate de modularizare, utilizarea DLL-urilor, crearea aplicaiilor COM, tratarea excepiilor, realizarea de fiiere de ajutor (help), diagrame UML i evaluarea vitezei de execuie a programelor. n anul 2003 am introdus limbajul C# pentru partea de programare a laboratoarelor, limbaj de care m-am ataat nc de la apariia sa, n 2002, i pe care am continuat s l utilizez de atunci pentru toate proiectele de programare de natur profesional sau personal. Din 2008, odat cu rescrierea cursurilor de Ingineria programrii, am modificat i laboratoarele, adugnd o parte substanial legat de proiectarea i testarea aplicaiilor. Astfel, un laborator trateaz abloane arhitecturale, cinci se refer la abloane de proiectare i dou la testarea unitilor. Laboratoarele, n forma lor actual, constituie rezultatul experienei acumulate n timp, ncercnd s ofer o viziune practic asupra problemelor complexe legate de realizarea produselor software comerciale.

Sunt recunosctor tuturor studenilor pentru semnalarea neclaritilor i erorilor strecurate n laboratoare. De asemenea, mulumesc studenilor Veridiana Mrtic, Simona Scripcaru, Liudmila Tofan, Florin Alexandru Hodorogea i Alexandru Gologan pentru observaiile asupra versiunii preliminare a acestui ghid.


Florin Leon Aplicaii de ingineria programrii n C#

8


9

Capitolul 1

Compilarea, decompilarea i obscurizarea programelor C#

1. Obiective 2. Structura general a unui program C# 3. Compilarea, decompilarea i obscurizarea codului 4. Aplicaii

1. Obiective

Aplicaiile de ingineria programrii nu se doresc a fi, n primul rnd,

aplicaii de programare n C#. Din pcate, programe complexe la standarde comerciale nu se pot termina n dou ore, deci problemele vor avea o natur academic surprinznd ns chestiuni ce se pot regsi n aplicaiile din industrie i care trebuie rezolvate n principal la standarde nalte de calitate.

Accentul principal al prezentului ghid cade pe proiectarea programelor, folosind de exemplu abloane de proiectare, pe modul cum se gndete i se scrie un program, pe testare i pe crearea diverselor tipuri de documente aferente.

Vom utiliza limbajul C# pentru c este un limbaj modern, special destinat dezvoltrii rapide de aplicaii. Cnd vom considera necesar, vom prezenta i noiuni de programare n C#, mai ales n primele trei capitole. Ca mediu de dezvoltare, vom ntrebuina Microsoft Visual Studio 2005.

Obiectivele primului capitol sunt urmtoarele:

1. Prezentarea modului de organizare a unui program C# care conine clase, structuri i enumeraii. Discutarea diferenelor dintre tipurile referin (clase) i tipurile valoare (structuri);

2. Precizarea diferenelor de compilare n modurile Debug i Release; 3. Descrierea posibilitilor de decompilare a aplicaiilor .NET i de

protejare a acestora prin obscurizarea codului.



10

2. Structura general a unui program C#

O soluie C# const dintr-unul sau mai multe proiecte. Proiectele constau dintr-unul sau mai multe fiiere. Fiierele pot conine zero sau mai multe spaii de nume (engl. namespaces). Un namespace poate conine tipuri precum clase, structuri, enumeraii, dar i alte namespace-uri. Mai jos este prezentat un schelet al unui program C# alctuit din aceste elemente. using System; namespace MyNamespace { class MyClass { } struct MyStruct { } enum MyEnum { } class MyMainClass { static void Main(string[] args) { // nceputul programului propriu-zis } } }

2.1. Clase

Clasa este cel mai important tip de date n C#. n urmtorul exemplu, se definete o clas public avnd un cmp, o metod i un constructor. De remarcat terminologia utilizat pentru o variabil membru, cmp, deoarece termenul proprietate reprezint un alt concept C# pe care l vom discuta n capitolul 2.



11

n exemplul de mai jos, problema este definirea unui cmp public. Conform teoriei programrii orientate obiect, toate cmpurile trebuie s fie private iar accesul la ele s se fac prin metode publice.

public class Person { // Cmp / Field public string name; // !!! cmp public, nerecomandat // Constructor public Person() { name = "nedefinit"; } // Metod / Method public void ChangeName(string newName) { name = newName; } } class TestPerson { static void Main() { Person person1 = new Person(); Console.WriteLine(person1.name); person1.ChangeName("Ion Popescu"); Console.WriteLine(person1.name); } }

2.2. Clase statice i membri statici

O clas static nu poate fi instaniat. Deoarece nu exist instane ale

clasei, apelarea unei metode dintr-o clas static se realizeaz folosind numele clasei nsei. De exemplu, dac avem o clas static numit UtilityClass care conine o metod public numit MethodA, aceasta este apelat n modul urmtor: UtilityClass.MethodA();



12

O clas static poate fi utilizat ca o modalitate convenabil de a grupa o serie de metode care opereaz asupra unor parametri de intrare i nu au nevoie de cmpuri ntruct nu au stare intern. De exemplu, n mediul .NET, clasa static System.Math conine metode care realizeaz operaii matematice, fr a avea nevoie s memoreze sau s acceseze alte date n afara argumentelor cu care sunt apelate.

Mai jos este prezentat un exemplu de clas static avnd dou metode care convertesc temperatura din grade Celsius n grade Fahrenheit i viceversa. public static class TemperatureConverter { public static double CelsiusToFahrenheit(string temperatureCelsius) { // conversia argumentului din string n double double celsius = Convert.ToDouble(temperatureCelsius); // conversia din grade Celsius n grade Fahrenheit double fahrenheit = (celsius * 9 / 5) + 32; return fahrenheit; } public static double FahrenheitToCelsius(string temperatureFahrenheit) { double fahrenheit = Convert.ToDouble(temperatureFahrenheit); double celsius = (fahrenheit 32) * 5 / 9; return celsius; } } class TestTemperatureConverter { static void Main() { Console.WriteLine("Selectati directia de conversie"); Console.WriteLine("1. Din grade Celsius in grade Fahrenheit"); Console.WriteLine("2. Din grade Fahrenheit in grade Celsius"); Console.Write(":"); string selection = Console.ReadLine(); double f, c = 0;



13

switch (selection) { case "1": Console.Write("Introduceti temperatura in grade Celsius: "); f = TemperatureConverter.CelsiusToFahrenheit(Console.ReadLine()); // se afieaz rezultatul cu 2 zecimale Console.WriteLine("Temperatura in grade Fahrenheit: {0:F2}", f); break; case "2": Console.Write("Introduceti temperatura in grade Fahrenheit: "); c = TemperatureConverter.FahrenheitToCelsius(Console.ReadLine()); Console.WriteLine("Temperatura in grade Celsius: {0:F2}", c); break; default: Console.WriteLine("Selectati un tip de conversie"); break; } // ateapt apsarea tastei ENTER Console.ReadLine(); } }

Deseori, se utilizeaz clase nestatice cu membri statici n locul

claselor statice. n acest caz, membrii statici pot fi apelai chiar i naintea crerii unor instane ale clasei. La fel ca mai sus, membrii statici sunt accesai cu numele clasei, nu al unei instane. Indiferent cte instane ale clasei sunt create, pentru un membru static exist ntotdeauna o singur copie. Metodele statice nu pot accesa metode i cmpuri nestatice din clas.

Cmpurile statice se folosesc n general pentru a stoca valori care trebuie cunoscute de ctre toate instanele clasei i pentru a pstra evidena numrului de obiecte care au fost instaniate.

2.3. Cmpuri constante

Un cmp constant este static n comportament (nu poate fi modificat) i de aceea aparine tot tipului i nu instanelor. Prin urmare va fi accesat tot cu numele clasei, ca i cmpurile statice.



14

public class Car { public const int NumberOfWheels = 4; public static void Drive() { } // alte cmpuri i metode nestatice } // utilizare din exteriorul clasei Car.Drive(); int i = Car.NumberOfWheels;

2.4. Structuri

n C#, structurile sunt versiuni simplificate ale claselor. De obicei, ele ocup mai puin spaiu n memorie i sunt potrivite pentru tipurile de date de dimensiuni mici, utilizate frecvent. Diferena cea mai important ntre structuri i clase este faptul c structurile sunt tipuri valoare iar clasele sunt tipuri referin.

Cnd se creeaz o instan de tip valoare, se aloc n memoria stiv un singur spaiu pentru pstrarea valorii instanei respective. n acest mod sunt tratate tipurile primitive precum int, float, bool, char etc. Compilatorul creeaz automat un constructor implicit care iniializeaz toate cmpurile cu valorile implicite ale tipurilor acestora, de exemplu tipurile numerice cu 0, bool cu false, char cu '\0' iar cmpurile de tip referin (instane ale altor clase) cu null. Pentru structuri nu se poate declara un constructor implicit (fr parametri), ns se pot declara constructori cu parametri, care s iniializeze membrii cu valori diferite de cele implicite. Dezalocarea instanelor se face automat cnd acestea ies din domeniul lor de definiie.

La alocarea instanelor de tip referin, se memoreaz att referina obiectului n stiv, ct i spaiul pentru coninutul obiectului n heap. Managementul memoriei este fcut de ctre garbage collector.

S considerm urmtoarea situaie: structura MyPoint i clasa MyForm. MyPoint p1; // p1 este alocat cu valorile implicite ale membrilor p1 = new MyPoint(); // nu are efect aici, reseteaz valorile membrilor MyForm f1; // se aloc referina, f1 = null f1 = new MyForm(); // se aloc obiectul, f1 primete referina acestuia



15

n primul caz, se aloc un singur spaiu n memorie pentru p1. n al doilea caz, se aloc dou spaii: unul pentru obiectul MyForm i unul pentru referina lui, f1. De aceea, dac vrem s declarm un vector de 1000 de puncte, este mai avantajos s crem o structur dect o clas, deoarece astfel vom aloca mai puin memorie.

Dac vrem s copiem obiectele: MyPoint p2 = p1; MyForm f2 = f1;

p2 devine o copie independent a lui p1, fiecare cu cmpurile lui separate. n cazul lui f2, se copiaz numai referina, astfel nct f1 i f2 pointeaz ctre acelai obiect.

Fie metoda urmtoare, apelat cu argumentele p1 i f1: Change(p1, f1): void Change(MyPoint p, MyForm f) { p.X = 10; // p este o copie, instruciunea nu are efect asupra lui p1 f.Text = "Hello"; // f i f1 pointeaz la acelai obiect, f1.Text se schimb f = null; // f este o copie a referinei f1, instruciunea nu are efect asupra lui f1 }

Pentru o compatibilitate ct mai bun cu mediul .NET, Biblioteca MSDN recomand utilizarea structurilor numai n urmtoarele situaii:

Tipul reprezint o valoare unitar, similar cu un tip primitiv (int, double etc.);

Dimensiunea unei instane este mai mic de 16 octei (deoarece la transmiterea ca parametru n metode se creeaz o nou copie pe stiv);

Tipul este immutable (metodele nu modific valorile cmpurilor; cnd se dorete schimbarea acestora se creeaz un nou obiect cu noile valori);

Operaiile de boxing (mpachetare) i unboxing (despachetare), prezentate n seciunea 2.6, sunt rare.



16

2.5. Trimiterea argumentelor prin referin

Trimiterea argumentelor prin referin se realizeaz cu ajutorul cuvintelor cheie ref i out. Astfel, modificrile fcute asupra parametrului n metoda apelat se vor reflecta asupra variabilei din metoda apelant. Un argument trimis ca ref trebuie iniializat mai nti. Un argument trimis cu out nu trebuie iniializat n metoda apelant, ns metoda apelat este obligat s i atribuie o valoare. class RefExample { static void Method(ref int i) { i = 44; } static void Main() { int val = 0; Method(ref val); // val este acum 44 } }

class OutExample { static void Method(out int i) { i = 44; } static void Main() { int val; Method(out val); // val este acum 44 } }

Revenind la exemplul cu structura MyPoint i clasa MyForm, fie

metoda urmtoare, apelat cu argumentele p1 i f1: Change(ref p1, ref f1): void Change(ref MyPoint p, ref MyForm f) { p.X = 10; // se modific p1.X f.Text = "Hello"; // se modific f1.Text f = null; // f1 este distrus }

2.6. Operaiile de boxing i unboxing

Aceste operaii permit ca tipurile valoare s fie tratate drept tipuri referin, dup cum se poate vedea n figura 1.1.



17

Boxing (mpachetare) int i = 123; // tip valoare object o = i; // tip referin (boxing)

Unboxing (despachetare) int i = 123; object o = i; int j = (int)o; // tip valoare (unboxing)

Figura 1.1. Operaiile de boxing i unboxing

Vom utiliza aceste operaii n capitolul 3.

2.7. Enumeraii

O enumeraie este alctuit dintr-o mulime de constante. Enumeraiile pot avea orice tip integral cu excepia lui char, tipul implicit fiind int. Valoarea implicit a primului element este 0, iar valorile succesive sunt incrementate cu 1. De exemplu: enum Days { Sun, Mon, Tue, Wed, Thu, Fri, Sat };

n aceast enumeraie, Sun este 0, Mon este 1, Tue este 2 i aa mai departe. Enumeratorii pot avea iniializatori care suprascriu valorile implicite. De exemplu: enum Zile { Lun = 1, Mar, Mie, Joi, Vin, Sam, Dum };

Aici secvena de elemente pornete de la 1 n loc de 0. Urmtoarele instruciuni sunt valide:



18

int x = (int)Zile.Lun; // x = 1 Zile z1 = Zile.Mar; // z1 = Mar Zile z2 = (Zile)3; // z2 = Mie string s = z2.ToString(); // s = "Mie"

Modificarea valorilor unei enumeraii ntr-o nou versiune a unui program poate cauza probleme pentru alte programe ce folosesc codul respectiv. De multe ori valorile din enum sunt utilizate n instruciuni switch, iar dac noi elemente sunt adugate enumeraiei, se va activa cazul default. Dac ali dezvoltatori depind de acel cod, ei trebuie s tie cum s trateze noile elemente adugate.

3. Compilarea, decompilarea i obscurizarea codului

3.1. Compilarea. Limbajul Intermediar Comun

Limbajul Intermediar Comun (engl. Common Intermediate Language, CIL), cunoscut i sub denumirea de Limbajul Intermediar Microsoft (engl. Microsoft Intermediate Language, MSIL) este limbajul de nivelul cel mai sczut al platformei .NET. MSIL a fost numele utilizat pentru limbajul intermediar pn la versiunea 1.1 a platformei .NET. ncepnd cu versiunea 2.0, limbajul a fost standardizat iar denumirea standardului este CIL.

Compilarea i execuia unui program .NET se realizeaz n dou etape, dup cum se prezint n figura 1.2.

Figura 1.2. Etapele compilrii i execuiei unui program .NET



19

n timpul compilrii limbajelor .NET, codul surs este transformat n cod CIL i nu direct n cod executabil de ctre procesor. CIL reprezint un set de instruciuni independent de sistemul de operare i de procesor, care poate fi executat n orice mediu pe care este instalat platforma .NET, de exemplu motorul de execuie (runtime-ul) .NET pentru Windows, sau Mono pentru Linux.

Compilarea la timp (engl. just-in-time compilation, JIT) are loc n momentul execuiei efective a programului i presupune transformarea codului CIL n instruciuni executabile imediat de ctre procesor. Conversia se realizeaz gradat n timpul execuiei programului, iar compilatorul JIT efectueaz o serie de optimizri specifice mediului de execuie.

Avantajul principal al platformei .NET este interoperabilitatea dintre diferite limbaje de programare. De exemplu, un proiect scris n Visual Basic poate fi apelat fr modificri dintr-un proiect C#.

3.2. Decompilarea. Programul .NET Reflector

Deoarece codul intermediar este standardizat, este relativ simpl transformarea invers, ntr-un limbaj de nivel nalt precum C#. Un astfel de decompilator este .NET Reflector, pe care MSDN Magazine l-a numit unul din utilitarele obligatorii pentru un dezvoltator .NET. Programul este folosit deseori de ctre programatori pentru a nelege structura intern a bibliotecilor .NET pentru care codul surs nu este disponibil. S considerm urmtorul program simplu: public class Program { static void Main(string[] args) { string[] s = new string[] { "Hello, ", "World!" }; for (int i = 0; i < s.Length; i++) Console.Write(s[i]); Console.WriteLine(Environment.NewLine + "ok"); // NewLine pentru Windows este "\r\n" } }

Dup compilare, assembly-ul rezultat (n acest caz fiierul exe) se deschide n .NET Reflector. Programul permite navigarea prin namespace-uri, clase i metode. Cu click-dreapta se deschide un meniu din care se poate selecta opiunea de decompilare (engl. disassemble), ca n



20

figura 1.3. Din combo-box-ul din bara de instrumente se alege limbajul n care s se realizeze decompilarea.

Figura 1.3. Programul .NET Reflector

Iat rezultatele decompilrilor n mai multe limbaje: C#



21

Visual Basic

Managed C++

Delphi



22

CIL



23

3.3. Compilarea n modurile Debug i Release

Dei majoritatea optimizrilor se realizeaz n momentul compilrii JIT, chiar i compilatorul C# poate efectua analize ale codului i unele simplificri n vederea creterii vitezei de execuie. Compilarea n mod Debug este destinat facilitrii procesului de descoperire a erorilor i de aceea codul generat urmeaz mai fidel structura codului surs. n modul Debug, compilatorul JIT genereaz un cod mai uor de depanat, ns mai lent.

n schimb, compilarea n mod Release poate introduce optimizri suplimentare. Aceste opiuni pot fi controlate din mediul Visual Studio, astfel: View Solution Explorer Project Properties Build. n modul Release, opiunea Optimize code este activat.

De asemenea, n View Solution Explorer Project Properties Build Advanced Output, se precizeaz crearea sau nu a unui fiier pdb (program database) care conine informaii ce fac legtura ntre codul CIL generat i codul surs iniial, utile n special n faza de Debug.

n continuare, vor fi prezentate unele diferene de compilare n mod Debug (prima imagine, de sus), respectiv Release (a doua imagine, de jos).



24

a) Declararea variabilelor n locul n care sunt utilizate.

Interesant este faptul c aceste optimizri nu apar ntotdeauna. De exemplu, o metod simpl cum ar fi urmtoarea nu va fi optimizat, dei principiul este acelai ca mai sus. public void Locals() { int i; for (i = 0; i < 3; i++) DoSomething(); for (i = 2; i < 5; i++) DoSomething(); }



25

b) Transformarea buclelor while n bucle for



26

c) Eliminarea iniializrilor cu null

d) Eliminarea variabilelor neutilizate



27

e) Optimizarea iniializrilor n constructor



28

f) Optimizarea blocurilor switch

Prin urmare, programatorul nu trebuie s fac optimizri, mai ales cnd acestea scad claritatea codului. Singurele optimizri recomandate sunt acelea care scad complexitatea unui algoritm cu cel puin o clas, de



29

exemplu de la O(n2) la O(log n) sau O(n). n rest, compilatorul face oricum transformri ale codului, adaptate mediului de execuie existent. Eventualele optimizri manuale pot conduce n cel mai ru caz la secvene nestandard care nu sunt recunoscute de compilator i care pot scdea de fapt performanele aplicaiei.

Codul pregtit pentru livrarea comercial trebuie ntotdeauna compilat n modul Release.

3.4. Obscurizarea codului. Dotfuscator

Codul obscurizat (engl. obfuscated) este un cod foarte greu de citit i de neles. Deoarece prin decompilare orice program .NET devine de fapt open-source, obscurizarea este una din modalitile prin care se poate pstra secretul asupra codului aplicaiilor realizate.

Visual Studio include un astfel de instrument, numit Dotfuscator Community Edition care are o serie de limitri fa de versiunea Professional. Printre cele mai importante sunt criptarea irurilor de caractere, comprimarea assembly-urilor obscurizate i diferite scheme de redenumire. Nu este un instrument infailibil, ns este util pentru aplicaiile de importan medie.

Dotfuscator Community Edition poate fi pornit din mediul Visual Studio din meniul: Tools Dotfuscator Community Edition.

Mai nti se ncarc assembly-ul dorit, iar din tab-ul Rename se pot selecta namespace-urile, tipurile i metodele care se doresc redenumite, implicit toate. Apoi se ruleaz proiectul apsnd butonul Build (figura 1.4).

Figura 1.4. Instrumentul Dotfuscator

Rezultatul va fi un nou assembly, cu numele interne schimbate.



30

S considerm urmtorul exemplu. n stnga este programul iniial iar n dreapta codul dezasamblat dup obscurizare. public class AddingNumbers { public int AddTwo(int a, int b) { return a + b; } public int AddThree(int a, int b, int c) { return a + b + c; } } class Program { static void Main(string[] args) { int x = 1, y = 2, z = 3; AddingNumbers an = new AddingNumbers(); int r1 = an.AddTwo(x, y); Console.WriteLine(r1); int r2 = an.AddThree(x, y, z); Console.WriteLine(r2); } }

public class a { public int a(int A_0, int A_1) { return (A_0 + A_1); } public int a(int A_0, int A_1, int A_2) { return ((A_0 + A_1) + A_2); } } class b { private static void a(string[] A_0) { int num = 1; int num2 = 2; int num3 = 3; a a = new a(); Console.WriteLine(a.a(num, num2)); Console.WriteLine( a.a(num, num2, num3)); } }

4. Aplicaii

4.1. Realizai un program de tip consol n care s creai cte o metod pentru fiecare din situaiile de mai jos. Compilai programul n mod Debug cu Debug Info full, respectiv Release cu Debug Info none.

Variabile locale nefolosite: int a = 4; int b = 3; double c = 4; bool ok = false; Console.WriteLine(ok);



31

Ramuri ale expresiilor condiionale: int b = 3; double c = 4; bool ok = false; if (b < 3) if (c > 3) ok = true; Console.WriteLine(ok);

Cod imposibil de atins:

if (true) Console.WriteLine("ok"); if (false) Console.WriteLine("false"); else Console.WriteLine("true"); return; Console.WriteLine("finished");

Expresii aritmetice:

int a = 2 + 4 + 5; double b = 9 / 5.0 + a + 9 + 5; b++;

Instruciuni goto (nerecomandate, deoarece afecteaz calitatea structurii codului):

int b = 10; if (b < 20) { Console.WriteLine("true"); } else { goto After; } After: Console.WriteLine("goto");



32

bool a = (b < 4); if (a) { goto C; } Console.WriteLine(1); C: Console.WriteLine(2);

Apelarea metodelor din obiecte (pentru aceasta creai o clas Test cu o metod MyMethod):

Test t = new Test(); int a = t.MyMethod(); Console.WriteLine(a);

De observat decompilarea urmtoarei secvene n mod Release: ce elemente i pstreaz numele chiar n absena fiierului pdb? Care sunt numele implicite date de .NET Reflector pentru diferite tipuri de date?

int integer = 3; double real = 3.14; bool boolean = true; Console.WriteLine("Integer: " + integer); Console.WriteLine("Real: " + real); Console.WriteLine("Boolean: " + boolean); NumberForTestingOnly t = new NumberForTestingOnly(); Console.WriteLine("Test object: " + t.ReturnDouble(4)); public class NumberForTestingOnly { public int ReturnDouble(int par) { return par * 2; } }



33

Not: dei de multe ori termenii argument i parametru se folosesc ca sinonime, exist o diferen ntre aceste noiuni. n exemplul anterior:

ReturnDouble(int par) par este parametru; t.ReturnDouble(4) 4 este argument.

4.2. Creai un program cu 3 clase, fiecare clas cu 4 metode i obscurizai-l utiliznd instrumentul Dotfuscator. Pentru a vedea rezultate interesante, cteva metode din aceeai clas trebuie s aib aceeai semntur cu excepia numelui, iar celelalte s aib semnturi diferite. Instaniai obiecte de aceste tipuri i apelai metodele corespunztoare.



34


35

Capitolul 2

Stilul de scriere a codului. Tratarea excepiilor. Interfaa grafic cu utilizatorul

1. Obiective 2. Stilul de scriere a codului 3. Tratarea excepiilor 4. Interfaa cu utilizatorul 5. Interfaa grafic cu utilizatorul n Microsoft Visual Studio .NET 6. Elemente de C# 7. Aplicaii

1. Obiective

Obiectivele capitolului 2 sunt urmtoarele:

Sublinierea importanei unui stil unitar de scriere a codului ntr-o

firm care dezvolt produse software; Descrierea standardului de scriere a codului pe care l vom utiliza n

ghidul de aplicaii de ingineria programrii; Explicarea modalitilor de tratare a excepiilor n C#; Prezentarea unor aspecte legate de dezvoltarea de aplicaii cu

interfa grafic; Prezentarea modului de lucru cu proprieti C#.

2. Stilul de scriere a codului

Unul din scopurile urmrite la scrierea programelor trebuie s fie ntreinerea ulterioar a codului, adic facilitarea modificrilor i completrilor viitoare, foarte probabil de ctre persoane diferite dect autorul iniial. De asemenea, unele studii au artat c dup 6 luni de la scrierea unui program, acesta i apare la fel de strin autorului ca i un program scris de altcineva.

Unul din aspectele principale ale codului uor de ntreinut este posibilitatea de a gsi anumite buci de cod i de a le modifica fr a afecta celelalte seciuni. Claritatea este esenial. Altfel, n cazul programelor de



36

mari dimensiuni, aa cum sunt majoritatea situaiilor n cazul produselor software comerciale, n locul lucrului efectiv pentru adugarea de funcionaliti se va pierde timpul ncercndu-se s se gseasc poriunile relevante de cod care trebuie modificate. Formatarea codului poate simplifica nelegerea structurii semantice sau poate cauza confuzie. Poate chiar ascunde defecte greu de depistat, de exemplu: bool error = DoSomething(); if (error) Console.WriteLine("Eroare"); Environment.Exit(1); /// !!!

Nu conteaz ct de bine este proiectat un program; dac prezentarea sa arat neglijent, va fi neplcut de lucrat cu el.

2.1. Acoladele

Exist dou modaliti principale de plasare a acoladelor. Stilul Kernighan i Ritchie este bazat pe dorina de a afia ct mai

multe informaii ntr-un mod compact: int KernighanRitchie() { int a = 0, b = 0; while (a != 10) { a++; b--; } return b; }

Acest stil poate fi folosit la prezentri de cod sau n situaii n care spaiul disponibil pentru afiarea codului este redus, de exemplu ntr-un material tiprit.

Stilul extins sau stilul Allman este recomandat de Microsoft pentru limbajul C#:


Capitolul 2. Stilul de scriere a codului. Tratarea excepiilor. Interfaa grafic cu utilizatorul

37

int Extended() { int a = 0, b = 0; while (a != 10) { a++; b--; } return b; }

Avantajul principal al acestuia este claritatea, deoarece blocurile de cod sunt evideniate prin alinierea acoladelor. Este stilul pe care l vom utiliza n acest ghid de aplicaii.

2.2. Standarde de programare

Muli programatori fr experien industrial, dei foarte buni, refuz la nceput aplicarea unor standarde impuse. Dac programul este corect, ei nu neleg de ce trebuie aliniat altfel sau de ce trebuie schimbate numele variabilelor sau metodelor.

Este important de avut n vedere faptul c nu exist un stil perfect, deci rzboaiele privind cea mai bun formatare nu pot fi ctigate. Toate stilurile au argumente pro i contra. Majoritatea firmelor serioase de software au standarde interne de scriere a programelor, care definesc regulile pentru prezentarea codului. Aceste standarde cresc calitatea programelor i sunt importante deoarece toate proiectele livrate n afara organizaiei vor avea un aspect ngrijit i coerent, de parc ar fi fost scrise de aceeai persoan. Existena mai multor stiluri distincte ntr-un proiect indic lipsa de profesionalism.

Faptul c un programator crede c stilul su propriu este cel mai frumos i cel mai uor de neles nu are nicio importan. Un stil care unui programator i pare n mod evident cel mai bun poate reprezenta o problem pentru altul. De exemplu: using System . Windows . Forms; namespace LabIP { public class HelloWorld:System . Windows . Forms . Form { public HelloWorld ( ) { InitializeComponent ( ); }



38

protected override void Dispose ( bool disposing ) { if( disposing ) { if( components != null ) { components . Dispose ( ); } } base . Dispose ( disposing ); } static void Main ( ) { Application . Run ( new HelloWorld ( ) ); } private void button1_Click ( object sender , System . EventArgs e ) { string STRING = "Hello World!"; display ( STRING ); } private void display ( string STR ) { MessageBox . Show ( STR , ":-)" ); } } }

Acest program nu a fost aliniat aleatoriu, ci folosind opiunile din

mediul Visual Studio: Tools Options Text Editor C# Formatting. n acelai mod, stilul personal al unui programator poate prea la fel de ciudat altuia.

Beneficiile adoptrii unui stil unitar de ctre toi membrii unei organizaii depesc dificultile iniiale ale adaptrii la un stil nou. Chiar dac nu este de acord cu standardul impus, un programator profesionist trebuie s se conformeze. Dup ce va folosi un timp stilul firmei, se va obinui cu el i i se va prea perfect natural.

n prezentul ghid de aplicaii vom utiliza un standard bazat pe recomandrile Microsoft pentru scrierea programelor C#.

Este bine ca regiunile de program s fie delimitate cu ajutorul cuvntului cheie region, de exemplu: #region Fields private DateOfBirth _dob; private Address _address; #endregion

Dac toate seciunile unei clase sunt delimitate pe regiuni, pagina ar trebui s arate n felul urmtor atunci cnd toate definiiile sunt colapsate:



39

2.3. Convenii pentru nume

Cheia alegerii unor nume potrivite este nelegerea rolului construciilor respective. De exemplu, dac nu putem gsi un nume bun pentru o clas sau pentru o metod, ar fi util s ne ntrebm dac tim ntr-adevr la ce folosete aceasta sau dac chiar este necesar s existe n program. Dificultile la alegerea unui nume potrivit pot indica probleme de proiectare.

Un nume trebuie s fie:

Descriptiv: Oamenii i pstreaz deseori percepiile iniiale asupra unui concept. Este important deci crearea unei impresii iniiale corecte despre datele sau funcionalitile unui program prin alegerea unor termeni care s descrie exact semnificaia i rolul acestora. Numele trebuie alese din perspectiva unui cititor fr cunotine anterioare, nu din perspectiva programatorului;

Adecvat: Pentru a da nume clare, trebuie s folosim cuvinte din limbajul natural. Programatorii au tendina s utilizeze abrevieri i prescurtri, ns acest lucru conduce la denumiri confuze. Nu are



40

importan faptul c un identificator este lung ct vreme este lipsit de ambiguitate. Denumirea st nu este o alegere potrivit pentru conceptul numarStudenti. Regula de urmat este: trebuie preferat claritatea fa de laconism. Excepiile sunt contoarele de bucle, de exemplu clasicul for (int i = 0; i < length; i++). Acestea de multe ori nu au o semnificaie de sine stttoare, sunt construcii specifice (idiomuri) ale limbajelor evoluate din C i de obicei se noteaz cu o singur liter: i, j, k etc.;

Coerent: Regulile de numire trebuie respectate n tot proiectul i trebuie s se conformeze standardelor firmei. O clas precum cea de mai jos nu prezint nicio garanie de calitate:

class badly_named : MyBaseClass { public void doTheFirstThing(); public void DoThe2ndThing(); public void do_the_third_thing(); }

Pentru descrierea tipurilor de nume, exist n englez o serie de termeni care nu au un echivalent exact n limba romn:

Pascal case: Primul caracter al tuturor cuvintelor este o majuscul iar celelalte caractere sunt minuscule, de exemplu: NumarStudenti;

Camel case: Pascal case cu excepia primului cuvnt, care ncepe cu liter mic, de exemplu: numarStudenti.

Pentru denumirea conceptelor dintr-un program C#, vom adopta

conveniile din tabelul 2.1.

Tabelul 2.1. Convenii pentru denumirea conceptelor dintr-un program C#

Concept Convenie Exemple Namespace-uri Pascal case namespace LaboratorIP Clase Pascal case class HelloWorld

Interfee Pascal case precedat de I

interface IEntity

Metode Pascal case void SayHello() Variabile locale Camel case int totalCount = 0; Variabile booleene Prefixate cu is bool isModified;



41

Concept Convenie Exemple Parametrii metodelor

Camel case void SayHello(string name)

Cmpuri private 1 Camel case precedat de underscore

string _address;

Proprieti 2 Pascal case Address Constante, cmpuri readonly publice 3

Pascal case const int MaxSpeed = 100;

Controale pentru interfaa grafic 4

Camel case precedat de tipul controlului

buttonOK checkBoxTrigonometric comboBoxFunction

Excepii Pascal case cu terminaia Exception

MyException PolynomialException

1 Pn la versiunea Visual Studio 6.0, programatorii utilizau n C++ notaia maghiar a lui Simonyi pentru variabile, care indica i tipul acestora, de exemplu nAge pentru int. Pentru variabilele membru se folosea prefixul m_, de exemplu m_nAge. Pentru limbajul C#, Microsoft nu mai recomand utilizarea acestor notaii. Pentru cmpurile private exist cteva avantaje la prefixarea cu underscore:

cmpurile clasei vor avea o notaie diferit de variabilele locale; cmpurile clasei vor avea o notaie diferit de parametrii metodelor, astfel

nct se vor evita situaiile de iniializare de genul this.x = x, unde this.x este cmpul iar x este parametrul metodei;

n IntelliSense, la apsarea tastei _ vor aprea grupate toate cmpurile.

Avantajul utilizrii acestei convenii se manifest mai ales n situaii precum aceea de mai jos: private int description; // ortografie corect public Constructor(int descripton) // ortografie incorect pentru "description" { this.description = description; // ortografie corect n ambele pri, cmpul rmne 0 }

2 Proprietile vor fi detaliate n seciunea 6.2. 3 n mare, tot ce e public ntr-o clas trebuie s nceap cu liter mare 4 Aceast notaie are avantajul c, dei numele sunt mai lungi, sunt lipsite de ambiguitate. Exist i stilul prefixrii cu o abreviere de 3 litere, de exemplu btn pentru Button, ckb pentru CheckBox etc. Pentru controale mai puin uzuale, semnificaiile prefixelor nu mai sunt evidente: pbx, rdo, rbl etc.



42

3. Tratarea excepiilor

Tratarea erorilor se fcea n C prin returnarea unei valori, de obicei int, care semnifica un cod de eroare. De exemplu, dac o funcie trebuia s deschid un fiier, ea putea ntoarce 0 dac totul a funcionat normal, respectiv codul de eroare 1 dac fiierul nu exista. n funcia apelant, programatorul trebuia s trateze codul returnat: int err = OpenFile(s);

Cu toate acestea, programatorul era liber s apeleze funcia direct, OpenFile(s), fr a mai testa valoarea returnat. Programul putea fi testat cu succes, deoarece fiierul exista, ns putea s nu mai funcioneze dup livrare.

Majoritatea funciilor Windows API returneaz un cod dintr-o list cu sute de valori posibile, ns puini programatori testeaz aceste valori individual.

Tratarea excepiilor a aprut pentru a da posibilitatea programelor s surprind i s trateze erorile ntr-o manier elegant i centralizat, permind separarea codului de tratare a erorilor de codul principal al programului, ceea ce face codul mai lizibil. Astfel, este posibil tratarea:

tuturor tipurilor de excepii; tuturor excepiilor de un anume tip; tuturor excepiilor de tipuri nrudite.

Odat ce o excepie este generat, ea nu poate fi ignorat de sistem.

Funcia care detecteaz eroarea poate s nu fie capabil s o trateze i atunci se spune c arunc (throw) o excepie. Totui, nu putem fi siguri c exist un caz de tratare pentru orice excepie. Dac exist o rutin potrivit, excepia este tratat, dac nu, programul se termin. Rutinele de tratare a excepiilor pot fi scrise n diverse feluri, de exemplu examineaz excepia i apoi nchid programul sau re-arunc excepia.

Structura blocurilor try-catch pentru tratarea excepiilor este urmtoarea:



43

FuncieApelat { ... if (condiii) throw ... ... } FuncieApelant { ... try { FuncieApelat(); } catch (Exception e) // catch fr parametru dac nu intereseaz detaliile excepiei { // cod pentru tratarea excepiei, care prelucreaz parametrul e } ... }

Codul care ar putea genera o excepie se introduce n blocul try. Excepia este aruncat (throw) din funcia care a fost apelat, direct sau indirect. Excepiile care apar n blocul try sunt captate n mod normal de blocul catch care urmeaz imediat dup acesta. Un bloc try poate fi urmat de unul sau mai multe blocuri catch. Dac se execut codul dintr-un bloc try i nu se arunc nicio excepie, toate rutinele de tratare sunt ignorate, iar execuia programului continu cu prima instruciune de dup blocul (sau blocurile) catch.

n C#, tipul trimis ca parametru este de obicei Exception: try { FunctieApelata(); } catch (Exception ex) { ... }



44

De cele mai multe ori, ne intereseaz proprietatea Message (de tip string) a unui astfel de obiect, care arat cauza erorii. Textul respectiv este precizat n funcia care arunc excepia. private void FunctieApelata(int a) { if (a == 0) throw new Exception("Argument zero"); } private void FunctieApelanta() { FunctieApelata(0); }

Dac excepia nu este tratat, va aprea un mesaj de atenionare cu textul dorit (figura 2.1).

Figura 2.1. Mesaj de excepie

Mesajul de eroare trebuie preluat n program n blocul catch:

private void FunctieApelanta() { try { FunctieApelata(0); } catch (Exception ex) { // ex.Message este "Argument zero" } }



45

Programatorul i poate defini propriile tipuri de excepii, n cazul n care are nevoie s trimit informaii suplimentare privind excepia. Acestea trebuie ns derivate din clasa Exception: public class MyException: Exception { public int _info; // informaie suplimentar // n constructor se apeleaz i constructorul clasei de baz public MyException(int val) : base() { _info = val; } }

Utilizarea acestui tip se face astfel: throw new MyException(3);

Dup un try pot exista mai multe blocuri catch. Ele trebuie dispuse

n ordinea invers a derivrii tipurilor, de la particular la general: try { FunctieApelata(x); } catch (MyException myex) { ... } catch (Exception ex) { ... }

Alt ordine nu este permis, eroarea fiind descoperit la compilare: A previous catch clause already catches all exceptions of this or a super type ('System.Exception').



46

3.1. Tratarea excepiilor pe firul de execuie al aplicaiei

Uneori pentru a fi siguri c nu am lsat vreo excepie netratat,

putem trata global toate excepiile aprute pe firele de execuie ale aplicaiei, n maniera descris n continuare: static class Program { static void Main() { // Adugarea unui event handler pentru prinderea excepiilor // din firul principal al interfeei cu utilizatorul Application.ThreadException += new ThreadExceptionEventHandler(OnThreadException); // Adugarea unui event handler pentru toate firele de execuie din appdomain // cu excepia firului principal al interfeei cu utilizatorul AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException); Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MyForm()); // MyForm este fereastra principal a programului } // Trateaz excepiile din firul principal al interfeei cu utilizatorul static void OnThreadException(object sender, ThreadExceptionEventArgs t) { // Afieaz detaliile excepiei MessageBox.Show(t.Exception.ToString(), "OnThreadException"); } // Trateaz excepiile din toate celelalte fire de execuie static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e) { // Afieaz detaliile excepiei MessageBox.Show(e.ExceptionObject.ToString(), "CurrentDomain_UnhandledException"); } }



47

4. Interfaa cu utilizatorul

Interfaa cu utilizatorul permite acestuia s interacioneze cu aplicaia. Exist dou tipuri principale de interfee:

interfa cu utilizatorul de tip caracter (engl. character user

interface, CUI); interfa cu utilizatorul de tip grafic (engl. graphical user interface,

GUI).

Un exemplu de interfa de tip caracter este interfaa la linia de comand a sistemului de operare MS-DOS. Cnd se folosete o astfel de interfa, n general utilizatorul trebuie s memoreze i s tasteze comenzi text. De aceea, interfeele de acest tip pot fi mai dificil de utilizat i necesit o oarecare pregtire a utilizatorului. O interfa grafic ncearc s simplifice comunicarea. Graficele reprezint obiecte pe care utilizatorul le poate manipula i asupra crora poate efectua aciuni. Deoarece utilizatorul nu trebuie s tie un limbaj de comand, o interfa grafic bine proiectat este mai uor de folosit dect o interfa de tip caracter.

4.1. Proiectarea comenzilor i interaciunilor

Dac ierarhia de comenzi trebuie s se integreze ntr-un sistem de interaciuni deja existent, trebuie mai nti studiat acesta.

Se stabilete o ierarhie iniial de comenzi care poate fi prezentat utilizatorilor n mai multe moduri: o serie de opiuni dintr-un meniu, o bar de instrumente (toolbar) sau o serie de imagini (icons).

Apoi, aceast ierarhie se rafineaz prin ordonarea serviciilor din fiecare ramur a ierarhiei n ordinea logic n care trebuie s se execute, cele mai frecvente servicii aparrnd primele n list.

Limea i adncimea ierarhiei trebuie proiectate n aa fel nct s se evite suprancarea memoriei de scurt durat a utilizatorului. De asemenea, trebuie minimizat numrul de pai sau de aciuni (apsri ale mouse-ului, combinaii de taste) pe care trebuie s le efectueze acesta pentru a-i ndeplini scopul.

Interaciunile cu factorul uman pot fi proiectate pe baza urmtoarelor criterii:



48

coerena: se recomand utilizarea unor termeni i aciuni cu semnificaii unice, bine precizate i care se regsesc n mod unitar n tot sistemul;

numrul mic de pai: trebuie s se minimizeze numrul de aciuni pe care trebuie s le ndeplineasc utilizatorul;

evitarea aerului mort (engl. dead air): utilizatorul nu trebuie lsat singur, fr niciun semnal, atunci cnd ateapt ca sistemul s execute o aciune. El trebuie s tie c sistemul execut o aciune i ct din aciunea respectiv s-a realizat;

operaiile de anulare (engl. undo): se recomand furnizarea acestui serviciu datorit erorilor inerente ale utilizatorilor;

timpul scurt i efortul redus de nvare: de multe ori, utilizatorii nu citesc documentaia, de aceea se recomand furnizarea n timpul execuiei a unor soluii pentru problemele aprute;

aspectul estetic al interfeei: oamenii utilizeaz mai uor un produs software cu un aspect plcut.

Se recomand folosirea de icoane i controale similare celor din

produsele software cu care utilizatorul este familiarizat. Dac are de-a face cu acelai aspect exterior, acesta i va folosi cunotinele anterioare pentru navigarea prin opiunile programului, ceea ce va reduce i mai mult timpul de instruire.

4.2. Considerente practice Elementele interfeei grafice trebuie s fie coerente, adic s aib

stiluri, culori i semnificaii similare n toat aplicaia. Un tabel centralizat de cuvinte cheie poate ajuta la alegerea textelor sau etichetelor de ctre proiectanii interfeei care lucreaz la acelai sistem. Aceast tabel conine lista de cuvinte folosite n toat interfaa i care nseamn aceeai lucru peste tot.

O interfa clar este uor de neles. Metaforele utilizate trebuie s fie n acord cu experiena utilizatorilor n legtur cu obiectele din lumea real pe care le reprezint. De exemplu, icoana unui co de gunoi poate reprezenta o funcie de gestionare a fiierelor nedorite (gen Recycle Bin): fiierele pot fi introduse n co, unde rmn i pot fi regsite pn cnd coul este golit. Erorile trebuie identificate imediat folosind un mesaj inofensiv. Utilizatorul trebuie s-i poat repara o greeal ori de cte ori este posibil acest lucru iar documentaia programului sau manualul de utilizare trebuie



49

s l ajute n acest sens. Mesajele critice trebuie folosite numai atunci cnd utilizatorul trebuie avertizat c unele date pot fi pierdute sau deteriorate dac nu acioneaz imediat. Chiar dac nu sunt probleme, furnizarea informaiilor despre starea sistemului face interfaa mai prietenoas. Totui, aceste mesaje pot deveni suprtoare dac sunt folosite prea des. Pot fi afiate i mesaje despre cursul unei aciuni sau despre timpul dup care se va termina o activitate. Dac o aciune dureaz aproximativ 6-8 secunde, se poate folosi un indicator de tip clepsidr. Pentru activiti mai lungi de 8 secunde, se pot folosi indicatoare de tip procentaj sau timp rmas. Utilizatorii trebuie s aib de asemenea posibilitatea ntreruperii sau anulrii acestor aciuni de durat. Mesajele sonore trebuie n general evitate deoarece pot fi suprtoare, distrag atenia iar semnificaia sunetelor poate depinde de contextul cultural al utilizatorilor.

Culoarea joac un rol important n proiectarea unei interfee grafice. Folosirea corect a culorilor face interfaa clar i uor de navigat. Totui, dac nu sunt folosite cu atenie, culorile pot distrage atenia utilizatorului. Culorile pot fi utilizate pentru a identifica prile importante ale interfeei. Prea multe culori strlucitoare fac textul dificil de citit. Trebuie de asemenea evitat un fundal complet alb i nu trebuie folosite mai mult de 4 culori ntr-o fereastr. Interpretarea culorilor este foarte subiectiv. Poate depinde de asociaii culturale, psihologice i individuale. Deci, n general, cel mai bine este s folosim culori subtile i neexagerate. Utilizatorii presupun de multe ori c exist o legtur ntre obiectele de aceeai culoare, aa c trebuie s fim ateni s nu folosim aceeai culoare pentru obiecte fr legtur. Culorile nu trebuie s fie singura surs de informaii deoarece unii utilizatori nu pot distinge anumite culori, iar alii pot avea monitoare care nu suport o gam larg de culori.

Ca i culorile, icoanele pot pune n valoare o interfa grafic, dac sunt folosite corect. Icoanele bine proiectate ofer utilizatorului un mod accesibil de comunicare cu aplicaia. Exist cteva elemente de care trebuie s inem seama la proiectarea acestora:

un stil i o dimensiune comun pentru toate icoanele dau interfeei

un aspect coerent; desenele ajut utilizatorul s recunoasc metaforele i s-i

aminteasc funciile;



50

conturarea icoanelor cu negru le face s ias n eviden din fundal; icoanele pot fi afiate n trei mrimi: 48 x 48, 32 x 32 i 16 x 16

pixeli; acestea trebuie s fie uor de recunoscut chiar i atunci cnd sunt afiate la dimensiunea de 16 x 16 pixeli;

dei o icoan poate fi accentuat prin culoare, ea trebuie s poat fi recunoscut i n varianta alb-negru.

Icoanele bine proiectate i comunic funciile cu claritate i cresc utilizabilitatea interfeei, ns o icoan neclar poate deruta utilizatorii i poate crete numrul de erori. Putem folosi etichete text pentru a ne asigura c semnificaia unei icoane este clar. Cteodat este cel mai bine s folosim imagini tradiionale deoarece utilizatorul este familiarizat cu ele. O icoan bine proiectat trebuie s poat fi distins cu uurin de celelalte icoane din jurul su, iar imaginea trebuie s fie simpl i potrivit contextului interfeei.

Corpurile de liter (font-urile) utilizate ntr-o interfa grafic nu

trebuie amestecate. Ca i n cazul culorilor, prea multe font-uri pot distrage atenia utilizatorului.

4.3. Profilurile utilizatorilor

Pentru a crea o interfa grafic utilizabil, trebuie s cunoatem profilul utilizatorului, care descrie ateptrile i nevoile acestuia. Un mod potrivit de a determina profilul utilizatorului este prin observare la locul su de munc. Poate fi folositoare sugestia ca utilizatorul s gndeasc cu voce tare atunci cnd lucreaz cu prototipul unei interfee.

Aproape ntotdeauna va exista un procent de utilizatori nceptori iar interfaa trebuie s aib grij de acetia. De exemplu, putem asigura alternative la acceleratori (combinaii de taste pentru anumite funcii) i putem preciza shortcut-urile n opiunile meniurilor.

Profilurile utilizatorilor se ncadreaz n general n trei categorii:

Utilizatorul comod dorete s foloseasc interfaa imediat, cu foarte puin antrenament. Acest tip de utilizator prefer utilizarea mouse-ului, atingerea sensibil a ecranului sau stiloul electronic. Navigarea simpl este important deoarece utilizatorul comod nu ine minte ci complicate. Afiarea unei singure ferestre la un moment dat simplific navigarea. Pentru a face o interfa grafic accesibil unui utilizator de acest tip, ea trebuie s se bazeze pe



51

recunoaterea unei icoane, mai degrab dect pe amintirea a ceea ce reprezint icoana. Acest lucru se poate realiza prin folosirea unei multitudini de grafice i de opiuni n meniuri;

Utilizatorul rapid dorete un timp de rspuns ct mai mic, aa nct trebuie evitate prea multe redesenri ale ferestrelor. Acest tip de utilizator prefer n general s foloseasc tastatura i mai puin mouse-ul. Utilizatorii de acest tip au n general timp pentru instruire i sunt dispui s renune la faciliti n favoarea vitezei. Acceleratorii le permit s lucreze mai repede;

Utilizatorul energic este de nivel avansat i are experien cu interfeele grafice. Acesta nu i dorete o instruire de durat i se ateapt s foloseasc interfaa imediat. Deoarece este sigur pe sine i i place s exploreze, trebuie ntotdeauna asigurat o opiune de anulare (engl. undo). Alte trsturi pe care le ateapt sunt schimbri limitate ale modului de afiare, multitasking i posibilitatea particularizrii i individualizrii aspectului interfeei grafice.

5. Realizarea programelor cu interfaa grafic cu utilizatorul n Microsoft Visual Studio .NET

Cnd este creat un nou proiect C# de tip Windows Application, n

mijlocul ecranului (figura 2.2), apare un formular (Form) fereastra principal a programului, n care se vor aduga diverse componente de control: butoane, text-box-uri etc.

n partea din stnga a ecranului exist o bar de instrumente (View Toolbox sau Ctrl+Alt+X) din care se aleg cu mouse-ul componentele ce trebuie adugate n fereastr.

Pentru adugarea unei componente, programatorul va face click cu mouse-ul pe imaginea corespunztoare din toolbox, apoi va face click n formular, n locul unde dorete s apar componenta respectiv. Odat introduse n fereastr, componentele pot fi mutate, redimensionate, copiate sau terse. n dreapta este o fereastr de proprieti (View Properties Window sau F4). De aici, fiecrei componente folosite i se pot modifica proprietile, adic aspectul exterior, aa cum va aprea n program, sau caracteristicile funcionale interne. De asemenea, se pot selecta evenimentele corespunztoare componentei care vor fi tratate n program.



52

Figura 2.2. Mediul de dezvoltare Microsoft Visual Studio

n continuare, vor fi prezentate cteva componente de control folosite practic n orice program Windows. Pentru fiecare component, vor fi amintite unele proprieti i metode uzuale. Pentru o descriere mai amnunit, se recomand consultarea documentaiei MSDN.

Application

Clasa Application ncapsuleaz o aplicaie Windows. Clasa conine metode i proprieti statice pentru managementul unei aplicaii, cum ar fi metode pentru pornirea i oprirea programului, prelucrarea mesajelor Windows i proprieti corespunztoare informaiilor despre aplicaie.

Se poate observa c n scheletul de program creat implicit de mediul de dezvoltare, n metoda Main() este pornit programul pe baza clasei corespunztoare ferestrei principale: Application.Run(new MainForm());



53

Form

Clasa System.Windows.Forms.Form corespunde unei ferestre standard. O aplicaie poate avea mai multe ferestre una principal, cteva secundare i cteva ferestre de dialog.

Unele proprieti:

Icon icoana care apare n bara de titlu a ferestrei; FormBorderStyle nfiarea i comportamentul chenarului, de

exemplu, dac fereastra poate fi redimensionat; Text titlul ferestrei, care apare n bara de titlu i n taskbar; StartPosition locul unde apare fereastra pe ecran; Size dimensiunea (nlimea i limea ferestrei); de obicei se

stabilete prin redimensionarea ferestrei cu mouse-ul, n procesul de proiectare.

Cteva evenimente:

Load, Closed pentru diverse iniializri n momentul crerii

ferestrei sau prelucrri n momentul nchiderii acesteia;

n general, pentru tratarea unui eveniment n C#, este selectat mai nti obiectul de tipul dorit (la noi fereastra), apoi n fereastra de proprieti se alege tab-ul de evenimente i se identific evenimentul cutat.

Figura 2.3. Editarea proprietilor componentelor



54

Dup un dublu-click, ca n figura 2.3, se va crea automat o nou metod vid corespunztoare evenimentului, iar utilizatorul va trebui numai s scrie n corpul funciei comenzile dorite.

Button

Clasa System.Windows.Forms.Button corespunde unui buton. Cteva proprieti i evenimente:

Text textul nscris pe buton; Click funcia executat cnd butonul este apsat.

Label

Clasa System.Windows.Forms.Label nscrie un text undeva n fereastr. Una din proprieti:

Text textul nscris.

TextBox

Clasa System.Windows.Forms.TextBox corespunde unei csue de editare de text. Cteva proprieti i evenimente:

Text textul din csu (de tip string); Multiline textul poate fi introdus pe o singur linie (false) sau pe

mai multe (true); ScrollBars indic prezena unor bare de derulare (orizontale,

verticale) dac proprietatea Multiline este true; Enabled componenta este activat sau nu (true / false); ReadOnly textul poate fi modificat sau nu de utilizator (true /

false); CharacterCasing textul poate aprea normal (Normal), numai cu

litere mici (Lower) sau numai cu litere mari (Upper); TextChanged evenimentul de tratare a textului n timp real, pe

msur ce acesta este introdus.



55

ComboBox

Clasa System.Windows.Forms.ComboBox corespunde unui combo-box, care combin un text-box cu o list. Cteva proprieti i evenimente:

Text textul din partea de editare; Items lista de obiecte din partea de selecie, care se poate introduce

i prin intermediul ferestrei de proprieti; SelectedIndex numrul articolului din list care este selectat (0

primul, 1 al doilea, etc., 1 dac textul din partea de editare nu este ales din list);

TextChanged, SelectedIndexChanged evenimente de tratare a schimbrii textului prin introducerea direct a unui nou cuvnt sau prin alegerea unui obiect din list.

MenuStrip

Clasa System.Windows.Forms.MenuStrip corespunde meniului principal al unei ferestre. Mod de folosire:

se introduce o component de acest tip n fereastr; se editeaz meniul, direct n fereastr sau folosind proprietile; pentru separatori se introduce n cmpul Caption un minus ( ); literele care se vor a fi subliniate trebuie precedate de &; pentru implementarea metodei de tratare a unei opiuni din meniu se

va face dublu-click pe aceasta (sau pe evenimentul Click n fereastra de proprieti).

Timer

Clasa System.Windows.Forms.Timer ncapsuleaz funciile de temporizare din Windows. Cteva proprieti i evenimente:

Tick evenimentul care va fi tratat o dat la un interval de timp; Interval intervalul de timp (n milisecunde) la care va fi executat

codul corespunztor evenimentului Tick; Enabled indic dac timer-ul e activat sau nu (true / false).



56

string

Este o clas care permite lucrul cu iruri de caractere. Exist operatorul +, care permite concatenarea irurilor:

string str1 = "Microsoft "; string str2 = "Word"; str1 = str1 + str2; // sau str1 += str2; => str1 == "Microsoft Word"

Clasa conine multe proprieti i metode utile, dintre care amintim:

int Length lungimea irului; int IndexOf(...) poziia n ir la care apare prima dat un caracter

sau un subir; string Substring(...) returneaz un subir; string Remove(int startIndex, int count) returneaz irul rezultat

prin tergerea a count caractere din ir, ncepnd cu poziia startIndex;

string[] Split(...) mparte irul n mai multe subiruri delimitate de anumite secvene de caractere.

O metod static a clasei este Format(...), care returneaz un ir de

caractere corespunztor unui anumit format. Sintaxa este asemntoare cu cea a funciei printf din C. De exemplu: double d = 0.5; string str = string.Format("Patratul numarului {0} este {1}", d, d * d);

Acelai rezultat s-ar fi putut obine astfel:

str = "Patratul numarului " + d.ToString() + " este " + (d * d).ToString();

Orice obiect are metoda ToString(), care convertete valoarea sa

ntr-un ir. Pentru obiecte definite de programator, aceast metod poate fi suprascris.

Dac n exemplul de mai sus d = 0.72654 i dorim s afim numerele numai cu 2 zecimale, metoda Format i dovedete utilitatea (figura 2.4).



57

string str=string.Format("Patratul numarului {0:F2} este {1:F2}", d, d*d); MessageBox.Show(str);

Figura 2.4. Mesaj cu numere formatate

StringBuilder

Majoritatea programatorilor utilizeaz de obicei clasa string cnd opereaz cu iruri de caractere. n cazul concatenrii unor iruri, folosirea clasei StringBuilder aduce o important cretere de performan. S considerm urmtorul bloc: string listaNumere = ""; for (int i=0; i


58

programator. Dac nu se dorete utilizarea unui

Documents

Programarii in C