Temă Inginerie Software Visual Studio Team System

Universitatea Politehnică București

Facultatea de Electronică, Telecomunicații și Tehnologia Informației

TEMĂ

Inginerie Software

Visual Studio Team System

Studenți:

Burlacu Oana

Ciolovan Alexandru

Sandu Cristina

Grupa: 442A

București 2015

Cuprins:

Noțiuni teoretice

1. 
   Descrierea arhitecturii Visual Studio Team System și a componentelor
   
   1. 
      Arhitectura
      
   2. 
      DSI, DSL și DSM
      
   3. 
      Sisteme de aplicație -Design Application Systems
      
   4. 
      Proiectarea centrelor de date logice -Design Logical Datacenters
      
   5. 
      Definirea și evaluarea implementării de sisteme de aplicații cu date logice -Define and evaluate deployment for application systems against logical datacenters
      
2. 
   Dezvoltare si testare
   
   1. 
      Descrierea rolului de Dezvoltator.
      
   2. 
      Utilizare Class Designer.
      
   3. 
      Version Control.
      
   4. 
      Test Driven Development.
      
   5. 
      Team Foundation Build.
      
   6. 
      Designul bazelor de date folosind Visual Studio Team Edition pentru Database Professionals.
      
3. 
   Descrierea componentelor si serviciilor din cadrul Team Foundation Server
   
   1. 
      Services (Core),
      
   2. 
      Version Control,
      
   3. 
      MSBuild
      
   4. 
      Data Warehouse
      
   5. 
      Reporting Services
      

Sandu Cristina Maria

Noțiuni introductive

În primul capitol am prezentat în sens restrâns aspectele teoretice ale lucrării, urmând ca în următoarele două capitole să prezentam aplicații ale mediului de dezvoltare Visual Studio.

Microsoft Visual Studio este un mediu de dezvoltare integrat (integrated development environment - IDE) de la Microsoft. Acesta poate fi folosit pentru a dezvolta aplicaţii consolă şi aplicații cu interfaţă grafică, aplicaţii de tip Windows Forms, site-uri web, aplicaţii web, servicii web ce sunt suportate platformele: Microsoft Windows, Windows Mobile, Windows CE,. NET Framework,. NET Compact Framework şi Microsoft Silverlight. Microsoft Visual Studio oferă editor, compilator/debugger și mediu de proiectare (designer) pentru mai multe limbaje de programare.

Visual Studio foloseste platforme de dezvoltare de software Microsoft, cum ar fi Windows API, Windows Store și Microsoft Silverlight.

Limbaje de programare incluse: Microsoft Visual C++, Microsoft Visual C#, Microsoft Visual Basic, Microsoft Visual Web Developer, Team Foundation Server. Visual FoxPro (eliminat în 2007), Visual SourceSafe (întrerupt începând cu Visual Studio 2008), Microsoft Visual J++/ Microsoft Visual J # (întrerupt începând cu Visual Studio 2008), Visual InterDev (înlocuit cu Microsoft Visual Web Developer).

Pe lângă aceste limbaje, Microsoft Visual Studio oferă suport și pentru alte limbaje, cum ar fi M, Python, Ruby. De asemenea, sprijină XML/XSLT, HTML/XHTML, JavaScript și CSS. Visual studio este oferit în mai multe variante: Express, Professional, Premium, Ultimate, Test Professional.

Visual Studio vizează în mod specific dezvoltatorii de aplicații Web, distribuite client-server. Acesta oferă toate instrumentele de care este nevoie pentru a crea și menține fiecare nivel al arhitecturii aplicatiei.

Multe dintre îmbunătățirile aduse produselor developer Microsoft existente au ca principalul scop simplificarea, crearea sau utilizarea componentelor ActiveX. Un set complet de instrumente este furnizat pentru a crea straturi de prezentare pe bază de HTML, un plus față de tradiționale instrumente de programare a aplicațiilor bazate pe Windows. Un set complet de instrumente de gestionare a datelor ajută la crearea de rutină și întreținerea bazelor de date care stau la bază.

Un al doilea obiectiv al Visual Studio este aplicația client-server. Aceeasi arhitectura de bază se aplică ambelor tipuri de aplicații. Aplicațile Corporate tind să se concentreze mai mult pe partea de bază de date a lucrurilor, însă, și Visual Studio Enterprise Edition contine chiar mai multe instrumente pentru crearea de baze de date pe scară largă și de procesare a tranzacțiilor aplicații.



Figura 1 Microsoft Visual Studio

Visual Studio Team System (VSTS) reprezintă o extensie Microsoft a arhitecturii Visual Studio. Aceasta cuprinde echipele de dezvoltare, cu roluri speciale și instrumentele pentru arhitecturi software, dezvoltatori specializați și testeri.

Visual Studio include un editor de cod precum și codul de refactoring. Debugger-ul integrat funcționează atât ca un program de depanare la nivel de sursă, dar și la nivel de mașină.

Visual Studio acceptă diferite limbaje de programare și permite editorului de cod și debugger-ului să sprijine aproape orice limbaj de programare, cu condiția să existe un limbaj specific. Limbajele de programare sunt: C, C ++ și C ++ / CLI (prin Visual C ++), VB.NET (prin Visual Basic .NET), C # (prin Visual C #), și F # (ca de Visual Studio 2010 ). Este un mediu suport pentru alte limbaje, cum ar fi M, Python, Ruby și printre altele este disponibil prin intermediul serviciilor lingvistice instalate separat.

1.Descrierea arhitecturii Visual Studio Team System

1.1.Arhitectura

Visual Studio nu are suport pentru orice limbaj de programare. IDE oferă trei servicii:

• 
  SVsSolution, care oferă posibilitatea de a enumera proiecte și soluții;
  
• 
  SVsUIShell, care oferă ferestre și funcționalitatea UI (inclusiv file, barele de instrumente și ferestrele de unelte);
  
• 
  SVsShell, care se ocupă cu înregistrarea VSPackages.
  

În plus, IDE este de asemenea responsabil pentru coordonarea și comunicarea între servicii. Toate editoarele, designeri, tipurile de proiecte dar și alte instrumente sunt puse în aplicare ca VSPackages.



Figura 2 Integrated Development Environment (IDE) în Visual Studio

Visual Studio folosește COM pentru a accesa VSPackages.Visual Studio SDK include, de asemenea, Managed Package Framework (MPF), care este un set de ambalaje gestionate în jurul interfețelor COM care permit pachetelor să fie scrise în orice limbaj compatibil CLI. Cu toate acestea, MFP nu furnizează toate funcționalitățile expuse de Visual Studio în interfețele COM. Serviciile pot fi apoi folosite pentru crearea de alte pachete, care aduc functionalitate în cadrul IDE Visual Studio.

Ca și suport pentru limbaje de programare, se adaugă un VSPackage, specific numit un serviciu limbă. Un serviciu de limbaj definește diferite interfețe care sunt puse în aplicare de VSPackage pentru a adăuga suport pentru diferite funcționalități. Functionalitățile care pot fi adăugate în acest fel includ o anumită sintaxă,

În cazul în care interfața este implementată, funcționalitatea va fi disponibilă pentru limbaj. Servicii de limbaj vor fi puse în aplicare pe o bază per limbaj. Implementările pot reutiliza codul de la analizorul sau compilator de limbaj. Servicile de limbaj pot fi puse în aplicare în cod nativ sau cod gestionat. Pentru codul nativ, pot fi folosite fie interfețelor COM native sau a cadrului Babel (parte din Visual Studio SDK), iar pentru codul gestionat, MFP include ambalaje pentru scrierea de servicii lingvistice gestionate.

Figura 3 Integrated Development Environment (IDE) în Visual Studio

Visual Studio nu include nici un sprijin de comandă a sursei, dar definește două modalități alternative de sisteme de control sursă pentru integrarea IDE. Un control sursa VSPackage poate oferi propria interfata personalizată a utilizatorului. În schimb, un plug-in de control sursă folosind MSSCCI (Microsoft Source Code Control Interface) oferă un set de funcții care sunt utilizate pentru a pune în aplicare diferite funcționalități a sursei, cu o interfață standard a utilizatorului Visual Studio. MSSCCI a fost folosit prima să integreze Visual SourceSafe cu Visual Studio 6.0, dar mai târziu a fost deschis prin intermediul Studio SDK Visual.

Visual Studio sprijină funcționarea în mai multe instanțe ale mediului (fiecare cu propriul set de VSPackages). Instanțele utilizează diferite registry hives pentru a stoca starea lor de configurare și sunt diferențiate prin APPID (ID Application) lor. Cazurile sunt lansate de un .exe APPID specifice, care selectează APPID, stabilește rădăcină și lansează IDE.

Diferitele ediții de produse ale Visual Studio sunt create folosind diferite AppIds. Produsele Visual Studio Express Editon sunt instalate cu propriile lor AppIds, dar produsele standard, profesionale și Team Suite împărtășesc același APPID.

Figura 4 Crearea unui nou proiect în Visual Studio

1.2. DSI, DSL și DSM

DSI –scurte noțiuni

Microsoft Visual Studio Team System Architecture Edition conține Distributed System Designers. Distributed System Designers este primul livrabil Dynamic Systems Initiative (DSI), care vizează îmbunătățirea proiectării și validarea sistemelor distribuite. Distributed System Designers oferă arhitectură software, arhitectură de infrastrucură, manageri de operațiuni și dezvoltatorilor capacitatea de a crește predictibilitatea succesului prin construirea anumitor soluții orientate spre servicii, care pot fi validate în mediile lor operaționale înainte de implementare.

SDM- scurte noțiuni

Distributed System Designers utilizează System Definition Model (SDM) ca metamodel de bază. SDM sprijină inițiativa Dynamic Systems (DSI), în simplificarea și automatizarea întreprinderilor de proiectare, implementarea și operarea cu sisteme distribuite.

SDM facilitează comunicarea între arhitecți de aplicații, dezvoltatori, și arhitecți de infrastructură, oferind următoarele beneficii:

• 
  Oferă un limbaj comun pentru a descrie designul și configurația pentru toate aspectele legate de un sistem distribuit.
  
• 
  Oferă abstracțiuni familiare care fac posibilă aplicare și de infrastructură pentru a comunica pe teren comun.
  
• 
  Face posibil, pentru dezvoltatorii, de a comunica cerințele aplicației în mediul run-time.
  
• 
  Face posibil pentru arhitecți de infrastructură să comunice aplicare cerințele run-time, de securitate, precum și de conectivitate care rezultă din politicile definite în mediul de implementare.
  

În Visual Studio Team System Architecture Edition, se poate utiliza Distributed System Designers pentru a defini aplicații, sisteme de aplicații de proiectare, și centre de date logice de design. Se poate evalua apoi implementarea pentru aceste sisteme de aplicare prin validarea lor împotriva modele centre de date. Se pot efectua aceste sarcini prin crearea și menținerea unui set de diagrame interdependente și documente care se bazează pe modelul sistemului.

DSL –scurte noțiuni

Un limbaj-domeniu specific este o notație, de obicei, grafică, care este proiectată pentru a fi utilizată cu un anumit scop. În schimb, limbajul, cum ar fi UML este de uz general. Într-un DSL, se pot defini tipurile de elemente, de model și relațiile lor, dar și modul în care acestea sunt prezentate pe ecran.

După ce este proiectat un DSL(domain-specific language), se poate distribui ca parte a unui studio de integrare extensie (VSIX) .



Figura 5 Domain Specific Language

Notația reprezintă doar o parte dintr-un DSL. Împreună cu notația, pachetul VSIX include instrumente unde utilizatorii pot aplica pentru a ajuta la editarea și generarea de materiale de la modelele lor.

Una din principalele aplicații ale DSL este de a genera un cod de program, fișiere de configurare, și multe altele. Mai ales în proiecte de anvergura și linii de produse, în cazul în care vor fi create mai multe variante ale unui produs, care generează multe dintre aspectele variabile ale DSL, atunci poate asigura o creștere mare de fiabilitate și o reacție foarte rapidă la cerințele schimbării. Acest asamblu este o prezentare în care sunt introduse operațiunile de bază ale creării si in acest sens se folosesc limbaje specifice domeniului în Visual Studio.

1.3. Sisteme de aplicație -Design Application Systems

În Visual Studio Team System Architecture Edition se pot urmări diferite fluxuri de lucru, atunci când sunt proiectate și evaluate sistemele de aplicare pentru implementare prin utilizarea de sisteme distribuite. Fluxul de lucru depinde de sarcinile pe care le efectuăm și de abordarea pe care o dorim să o utilizăm în proiectarea sistemelor.

Sarcini:

• 
  Sisteme de aplicație-Design Application Systems
  
• 
  Proiectarea centrelor de date logice-Design Logical Datacenters
  
• 
  Definirea și evaluarea implementării de sisteme de aplicații cu date logice-Define and evaluate deployment for application systems against logical datacenters
  

Sisteme de aplicație- Design Application Systems

Avem posibilitatea de a proiecta sisteme prin utilizarea unui top-down sau abordare de jos în sus. Putetem folosi o abordare de sus în jos atunci când dorim să proiecteze sisteme și alegem cum să le pună în aplicare. Această abordare va permite să amâne alegerea aplicațiile pe care dorim să le utilizăm în sisteme. Putem folosi o abordare de jos în sus atunci când știm aplicațiile pe care dorim să le utilizăm în sistemele noastre. Când utilizăm această abordare, mai întâi să definim aplicațiile pe care le vor include, mai târziu, în sistemele noastre. Putem utiliza, de asemenea, o combinație a acestor abordări în timpul procesului de proiectare.

Figura 6 prezintă modul în care un flux de lucru ar putea progresa prin procesul de proiectare a sistemului, în funcție de abordarea pe care o alegem.



Figura 6 Sistemul de proiectare flux de lucru prin utilizarea unei abordări de design de sus în jos sau de jos în sus abordare

Link: https://msdn.microsoft.com/en-us/library/ms181774%28v=vs.90%29.aspx#DD

Avem posibilitatea să proiectăm un sistem cerere la o abordare de sus în jos pornind de la System Designer. Putem începe prin crearea unei soluții de sisteme distribuite System Design. Acesta creează o soluție care conține o diagramă. Putem adăuga mai multe diagrame de sistem ca soluții.

1.4.Proiectarea centrelor de date logice-Design Logical Datacenters

Înainte de a putea defini și evalua implementarea unui sistem , soluția gasită trebuie să conțină o diagramă logică datacenter. Putem adăuga o diagramă logică datacenter existentă. De asemenea putem creea o soluție a sistemelor distribuite de logică șablon Datacenter Design. Acest șablon creează o soluție care conține o diagramă goală datacenter. Se pot adăuga mai multe diagrame de date logic pentru soluții.

Pe această diagramă datacenter, se poate crea o reprezentare parțială și abstractă al datacenter-ului fizic prin utilizarea Logic Datacenter Designer. Se poate efectua această sarcină prin glisarea servere-lor predefinite logice, obiectivelor, și zonelor din Toolbox. Servere logice reprezintă mediul run-time pentru care implementăm o aplicație. Zonele reprezintă, de obicei, granițele și regiunile de comunicare în centrul de date.

Sarcini în Datacenter Designer:

• 
  Conectareala servere. Aceste conexiuni descriu căi de comunicare în centrul de date logic.
  
• 
  Precizarea cerințelor hosting ale aplicaților și limita protocoalelor de comunicare. Se poate efectua această sarcină prin configurarea setărilor și constrângerile pe servere.
  

Figura 7 prezintă modul în care un flux de lucru ar putea progresa prin procesul logic de proiectare datacenter.



Figura 7 Modul în care un flux de lucru ar putea progresa prin procesul logic de proiectare datacenter.

Link: https://msdn.microsoft.com/en-us/library/ms181774%28v=vs.90%29.aspx#DD

1.5.Definirea și evaluarea implementării de sisteme de aplicații cu date logice-Define and evaluate deployment for application systems against logical datacenters

Putem defini și evalua implementarea unui sistem prin utilizarea Deployment Designer. Se poate începe definirea de implementare, prin crearea unei diagrame de implementare de la o diagramă sistem. Trebuie selectat o diagramă logică centru de date care reprezintă mediul de implementare țintă. Diagrama de desfășurare va reflecta schema logică a centrului de date care va fi selectată. Se pot crea mai multe diagrame de implementare pentru fiecare diagramă sistem.

Pe această diagramă de implementare, se specifică unde dorim să implementăm aplicațiile din sistem și legarea la serverele logice. Această sarcină se poate efectua prin glisarea acestei aplicații din fereastra System View, pentru servere. Sistemul afisează toți membrii sistemului radicular, inclusiv aplicațiile de la alte sisteme din sistemul de rădăcină.

După aplicații obligatorii, se validează diagrama de implementare. Acest lucru determină dacă există conflicte între setările și constrângerile privind aplicațiile și serverele care le găzduiesc. După validare, se generează un raport de implementare în format HTML pentru a documenta și rezolva aceste probleme. Visual Studio creează, de asemenea, o versiune XML a raportului de implementare, astfel încât se crează script-uri pentru implementarea de aplicații pentru servere fizice.

Figura 8 prezintă modul în care un flux de lucru ar putea progresa prin procesul de evaluare a implementării sistemului.



Figura 8 modul în care un flux de lucru ar putea progresa prin procesul de evaluare a implementării sistemului.

Link: https://msdn.microsoft.com/en-us/library/ms181774%28v=vs.90%29.aspx#DD

Ciolovan Ioan Alexandru

2. Dezvoltare si testare

2.1 Descrierea rolului de Dezvoltator.

Dezvoltatorii software intretin si imbunatatesc sistemele de support lucrand la operatiile interne ale computerelor,folosesc sisteme deja existente sau incorporeaza tehnologii noi pentru indeplinirea unor cerinte particulare.De asemenea acestia acopera partea de diagnosticare a problemelor intalnite si cea de scriere a codului corect in functie de sistemul de operare pentru a avea o eficienta cat mai buna.

Cerintele asignate dezvoltatorilor acopera o gama larga:

• 
  sa analizeze cerintele user-ilor;
  
• 
  cercetare,creare arhitectura si scriere de noi programe software;
  
• 
  testarea lor si gasirea problemelor daca exista;
  
• 
  dezvoltare pe programe existente;
  
• 
  creare de specificatii tehnice;
  
• 
  investigare de noi tehnologii care s-ar putea aplica mai bine pentru dezvoltarea unor aplicatii;
  
• 
  cercetare constanta in imbunatatirea cunostintelor tehnice
  

2.2 Utilizare Class Designer.

Visual studio Class Designer permite vizualizarea structurii claselor si a relatiilor dintre ele,creeaza clase noi folosind mediul de design visual,refactorizare usoara si rapida.

Class Dezigner-ul contine parti special proiectate pentru a ajuta dezvoltatorul sa refactorizeze codul,sa redenumeasca identificatori si sa suprascrie metode.Se pot genera automat noi clase, structuri sau se pot implementa interfete.

Acest instrument serveste,de asemenea,comunicarii deoarece permite transmiterea anumitor zone din cod colegilor.Diagramele pot fi printate sau salvate ca imagini ce se pot afisa si n pagini HTML sau pot fi introduce intr-o prezentare PowerPoint.

In imaginea de jos avem un exemplu de folosire a intrumentului:

Acest instrument este folosit datorita complexitatii si dificultatii crearii unui design software.A fost integrat incepand cu editia de Visual Studio 2005 si se poate lucre cu el in aceeasi maniera ca celalalte intrumente existente.

2.3 Version Control.

In dezvoltarea proiectelor,fie ca sunt mai sau mici este indicat sa se foloseasca version control-ul cat mai devreme deoarece acesta poate imbunatatii productivitatea si recuperarea datelor in cazul aparitiei unor probleme dificile.

La crearea unui nou proiect se poate alege ce versiune de control vrem sa folosim in cadrul lui : Team Foundation Version Control (TFVC) sau Git. 

Team Foundation Version este o versiune centralizata a sistemului.

Practic,membrii echipei au doar o versiune a fiecarui fisier pe masina lor de dezvoltare.Istoricul datelor este mentinut doar pe un server.Sucursalele sunt bazate pe o cale data si sunt create pe server.

Git este un sistem distribuit al controlului versiunii.Fiecare dezvoltator are cate o copie a intregii solutii pe masina lor de dezvoltare.Prin intermediul acestui intrument dezvoltatorii pot integra noi schimbari de cod in versiunea precedenta fara a fi nevoiti sa se conecteze la o retea si pot efectua operatii de control al versiunii cum ar fi istoric sau comparare cu o versiune anterioara.

2.4 Test Driven Development.

TTD este o tehnica avansata ce foloseste unitati de testare pentru a schita un design software cat mai bun.

Beneficii ale folosirii acestei tehnici:

-suita de unitati de testare ofera constant feedback pentru componentele care inca ruleaza;

-unitatiile de testare se comporta ca o documentatie care nu expira niciodata;

-test driven developmenet forteaza la analiza critica si design imbunatatit deoarece dezvoltatorul nu poate creea cod ce trebuie dat in productie pana nu intelege care ar trebui sa fie rezultatul dorit si cum sa-l testeze;

-reduce timpul alocat eliminarii bug-urilor;

2.5 Team Foundation Build.

TFB ofera functionalitatea unui laborator de tip “public build”si face parte din Team Foundation.Cu acest intrument se pot sincroniza sursele,complila aplicatii,rula unitati de testare asociate,analiza de cod,publicarea build-urilor pe un server,publicarea rapoartelor build-urilor.

TFB lucreaza cu un alte intruente ale Visual Studio Team System in timpul procesului de build,incluzand “version control”,”work item tracking”,intrumente de testare.

Arhitectura TFB

TFB interactioneaza perfect cu Team Explorer.Acesta asociaza build-urile cu ca o parte din proiectele echipei si lista ce defineste build-urile este afisata In Team Explorer in fisierul de Builds.

Prin intermediul Team Explorer putem efectua operatii ca “queuing a build”,adaugarea unui build intr-o coada de executie sau creare de “buid definitions”.

2.6 Designul bazelor de date folosind Visual Studio Team Edition for Database Professionals.

Folosind Visual Studio Team Edition for Database Professionals putem imprumuta concepte din Visual Studio Team System si le putem extinde pana la includerea echipelor de baze de date.Acest instrument ne ajuta la administrarea schimbarilor efectuate intr-o baza de date pentru a creste productivitatea echipei si pentru a imbunatatii atat colaborarea intre echipele de baze de date si intre restul organizatiei.

Avantaje oferite de acest intrument:

-admininstrarea obiectelor si schemelor bazei de date;

-ofera instrumente care ajuta la administrarea proiectelor de ce contin baze de date;

-ofera instrumente ce ajuta la testarea solutiilor uploadate.

Team Edition for Database Professionals necesita parcurgerea anumitor pasi,un proces ce se poate numi “ciclul vietii in dezvoltarea bazei de date”ce se imparte in urmatoarele etape:

• 
  stabilirea mediului de dezvoltare a proiectului
  

• 
  performanta izolata,dezvoltare iterativa
  

• 
  build-ul proiectului
  

• 
  publicare din mediul de dezvoltare
  

Exemplu de design al unei baze de date in Visual Studio:

Visual Studio Team Edition for Database Professionals ne ofera instrumente necesare pentru administrarea schimbarilor unei baze de date ce face parte dintr-o aplicatie ceea ce face ca acesta sa fie extrem de folositor,indiferent de marimea aplicatiei.

Burlacu Oana

3. 
   Descrierea componentelor si serviciilor din cadrul Team Foundation Server
   

3.1 Services-Servicii

Pe un server Team Foundation, putem vedea serviciile pe care le foloseste utilizatorii serverului Visual Studio Team Fondation si aplicatiilor Web Service unde Team Fundation Server este instalat. Team Fundation Server include o multime de servicii care lucreaza pe nivelele aplicatiei. Actualele servicii vor fi bazate pe caracteristicile Team Fundation instalat pe calculator.

Pentru a efectua aceasta procedura, trebuie ca utilizatorul sa fie membru pe grupul Team Foundation Administrators si membru al grupului Administrators pe serverul unde consola de administrare este instalata.

Pentru a vedea serviciile folosite de Team Foundation Server:

1. 
   Pe serverul Team Foundation, click Start-> Administrative Tools->Computer Management
   
2. 
   In panoul de navigare, Services and Application-> Services
   
3. 
   Log On As
   

3.2 Team Foundation Version Control(TFVC)

Team Foundation Version Control este o versiune centralizata a sistemului. Tipic, membrii echipei au o singuta versiune a fiecarui fisier in masina lor de proiectie. Istoric vorbind, datele sunt mentinute doar pe server. Ramurile sunt bazate si create pe server

TFVC accepta doua modele pentru o echipa care face schimbari

• 
  Serverul spatiului de lucru: Inainte sa se faca schimbari, membrii echipei publica fisierele de iesire. Majoritatea operatiilor cere proiectantilor sa fie conectati la server. Acest system faciliteaza urmarirea fluxurilor. Alte sisteme cu care lucreaza in acest scop sunt: Visual Source Safe, Perforce, and CVS
  
• 
  Localul spatiului de lucru: fiecare membru face o copie a ultimii versiuni a codului si lucreaza offline cat au nevoie. Proiectantii verifica in schimbarile lor si rezolva conflictele neesare. Alte sisteme lucreaza cu ele ca fiind o subversiune
  

3.3 MSBuild

Microsoft Build Engine, cunoscut ca si MSBuild, este o platforma de construire a managementului codului si face parte din .NET Framework. Visual Studio depinde de MSBuild, dar MSBuild nu depinde de Visual Studio. Visual Studio Application Lifecycle Management depinde de MSBuilder pentru a creste performanta constructiilor cu ajutorul Team Foundation Server.

MSBuilder este un instrument de construire care ajuta automat la procesul de creare a unui produs software, incluzand compilarea codului sursa, impachetarea, testarea, implementarea si crearea documentatiilor. Cu MSBuild, este posibil sa construm proiecte in Visual Studio si sa solutionam fara Visual Studio IDE instalat. MSBuilder este disponibil fara costuri. Inainte, acesta a fost utilizat impreuna cu .NET Frameworks; incepand cu noua versiune de Visual Studio 2013, el poate fi folosit instant impreuna cu Visual Studio. MsBuilder este o functie care a inlocuit utilitatea nmake, in urma ramanand in utilizare doar in proiectele vechi construite cu versiunile mai vechi ale Visual Studio.

MSBuild functioneaza in fisierele proiectului MSBuild care arata similar cu sintaxele XML, Apache Ant sau NAnt. Chiar daca sintaxa este bazata pe schema XML, structura fundamentala si operatiile sunt compatibile cu traditionalul utilitar Unix: specificatiile userului care vor fi utilizate(fisiere codului sursa) si rezultatele care vor fi(in aplicatie), dar utilitatea proprie decide ce sa faca si in ce ordine sa o faca.

MSBuild poate constri un proiect impotriva unui sustinut a versiunii Frameworkului .NET. Aceasta trasatura este numita “multitarget”. Orice constructie a unui proiect, poate marca doar o singura versiune a frameworkului la un moment dat.

Arhitectura MSBuild


Team Build



Visual Studio

TFS Targets and Tasks



Build-In Targets ans Tasks



MSBuild Engine


Conceptele de baza ale MSBuild

Proprietate - cheia/valoarea perechii care poate fi utilizata pentru configurarea constructiei.

Items – intrarile intr-o constructie de system care sunt grupate in colectii de itemuri bazate pe numele colectiilor definite de useri lor.

Tasks – o unitate a codului executabil de MSBuild performeaza operatiile atomice de construire

Targets - taskurile grupate impreuna intr-o particulara ordine permite sectiunile din procesul de build sa fie apelat de liniile de comanda

Rularea MSBuildului
Buidurile pot incepe in interiorul Visual Studio sau din linia de comanda. In mod implicit, iesirile sunt legate de linia de comanda sau de fereastra Visual Studio. Autentificarea la o alta iesire poate fi facuta prin customizarea implementarii interfetei de ILogger.

Setarea de detaliere poate fi utilizata pentru a furniza mai multe sau mai putine detalii: liniste, minimal, normal, detaliat, diagnostic .

Executia Targetului MSBuild

Figuraⁱ

Dependenta executiei

Targeturile au atributul de DependsOn care controleaza ordinea targeturilor. MSBuild pastreaza calea targeturilor executate pentru a preveni multiplele executii ale targetelor. Multe standard de targeturi sunt momentan goale si exista doar o dependenta a substituientilor. Punctele de extembilitate a Build-inului este provenit din existenta targeturilor supracomandabile. Aditionalele targeturi pot fi adaugate prin deciderea atributelor DependsOn.

Punctele extensibile

Targeturile Build-in User:

• 
  BeforeCompile, AfterCompile
  
• 
  BeforeBuild, AfterBuild
  
• 
  BeforeRebuild, AfterRebuild
  
• 
  BeforeClean, AfterClean
  

• 
  BeforePublish, AfterPublish
  
• 
  BeforeResolveReference, AfterResolveReferences
  
• 
  BeforeResGen, AfterResGen
  
• 
  Proprietatile supracomandabilelor DependsOn:
  
• 
  BuildDependsOn
  
• 
  CleanDependsOn
  
• 
  CompileDependsOn
  

Taskurile Build-In:

• 
  AL (Assembly Linker)
  
• 
  AspNetCompiler
  
• 
  AssignCulture
  
• 
  CallTarget
  
• 
  Copy
  
• 
  CreateItem
  
• 
  CreateProperty
  
• 
  Csc
  
• 
  Delete
  
• 
  Error
  
• 
  Exec
  
• 
  FindUnderPath
  
• 
  GenerateApplicationManifest
  
• 
  GenerateBootstrapper
  
• 
  GenerateDeploymentManifest
  
• 
  GenerateResource
  
• 
  GetAssemblyIdentity
  
• 
  GetFrameworkPath
  
• 
  GetFrameworkSdkPath
  
• 
  LC
  
• 
  MakeDir
  
• 
  Message
  
• 
  MSBuild
  
• 
  ReadLinesFromFile
  
• 
  RegisterAssembly
  
• 
  RemoveDir
  
• 
  ResGen
  
• 
  ResolveAssemblyReference
  
• 
  ResolveComReference
  
• 
  ResolveKeySource
  
• 
  ResolveNativeReference
  
• 
  SGen
  
• 
  SignFile
  
• 
  Touch
  
• 
  UnregisterAssembly
  
• 
  Vbc
  
• 
  VCBuild
  
• 
  Warning
  
• 
  WriteLinesToFile
  

Team Build Background

Team Foundation Build prevede functionalitatea construirii laboratorului de construire si partea lui din Visual Studio Team Fundation Server. Acesta este implementat ca o extensie a MSBuilderului si se construieste intr-un server independent furnizarea de consistent curat.

Build Type Files

Build Types consta in trei file continute intr-un folder denumit Build Type. Acestea inseamna:

• 
  TFSBuild.proj – scriptul primar pentru build
  
• 
  WorkspaceMapping.xml
  
• 
  TFSBuild.rsp
  

Build Types sunt gasite in folderul TeamBuildTypes in radacina controlului sursei. Fisierele trebuie cautate maual in interiorul proiectului si scoase afara pentru editare.

Team Build Lifecycle

Team Build, in mod implicit ruleaza targeturile EndToEndIteration. Targetul este gol, dar cauzeaza executie dependenta. Munca este facuta in primul rand in interiorul targetului Corelui. Punctele extensibile a targeturilor supracomandabile inainte si dupa targeturile Coreului.

Figuraⁱⁱ

Crearea si rularea buildurilor

Buildurile pot fi create in interiorul Visual Studio prin accesarea itemului meniului Build->New Team uild Type … Se pot adauga manual fisierele in controlul sursei. Buildul poate fi accesat de la Build->Build Team Project…sau prin tfsbuild.exe in linia de comanda. Logurile build sunt create in folderul picatura si legata la rapoartele buildului.

BuildLog.txt – iesirea totala a loggerului

ErrorsWaringsLog.txt – ieisre de eroare si de avertizare

Crearea si rularea noului Team Build Type

Concepte avansate:

Reflectarea targeturilor fisierelor externe

Customizarea datelor

Elementele de dupa date

Importarea fisierelor .targets(obiective)

Customizarea targeturilor care vor fi refolosite pot fi refectate in afara in fisierele .targets. Fisierele externe sunt include in tagurile Import. MSBuild si Team Build folosesc fisierele target care sunt incluse in fiecare fisier din proiect. Pe durata executiei un fisier extern se comporta ca un intreg continut care a fost substituit pentru tagurile import.

Itemurile si metadata

Itemurile care se comporta ca o colectie de obiecte in contrastul perechii nume-valoare a proprietatilor. Itemurile au metadata asociata cu fiecare membru al colectiei.

Binecunoscutul metadata – este fisierul generat automat si numele de fisier

Customizarea metadatei - Userul a creat si a asignat la timpul crearii itemului

Accesarea itemului ca vector (@), scalar (%) sau orice transformare

Personalizarea sarcinilor

Implementarea interfetei ITask

Poate deriva din coada de baza a codului Task

Compilat in interiorul dll pentru a fi facut disponibil in MSBuild

Referenta prin formularea UsingTask in fisierele proiectului

3.4 Data Warehouse-depozit de date

Team Fundation raportand depozitul este un deposit traditional de date constand dintr-o baza de date relationala organizata intr-o schema aproximativ stea si dintr-o baza de date OLAP construita in varful relatiei bazei de date. Urmatoarea diagram ne arata nivelele de arhitectura a depozitului de date a Team Fundation si retaiile dintre operatiile depozitelor, datele din deposit si rapoartele:

Figuraⁱⁱⁱ

Fiecare instrument sau plug-in in Team Fundation foloseste o baza de date relationala in Microsoft SQL Server 2005 pentru a stoca datele folosite de intrumentele utilizate zi-de-zi. Aceste relatii din baza de date sunt deobicei referite unui deposit operational. Acest deposit operational include:

• 
  Structura comuna a bazei de date(TfsIntegration si TfsActivityLogging)
  
• 
  Calea muncii elementelor din baza de date( TfsWorkItemTracking si TfsWorkItemTrackingAttachments)
  
• 
  Controlul sursei bazei de date(TfsVersionControl)
  
• 
  Construirea bazei de date a Team Foundation Build(TfsBuid)
  
• 
  Testarea bazei de date(TfsBuild)
  

Intr-un deposit de date putem avea magazine operationale create in a treia-parte a instrumentelor. La fel ca si In restul magazinelor operationale , schema unei relatii operationale este proiectata si optimizata de catre tranzactiile de process a datelor. Asa cum instrumentele si plug-inurile asigura performanta intr-o activitate, acestea scriu ultima informative in magazinul operational. Apoi, datele din magazinul operational sunt constant shimbate si actualizate, toate datele fiind curente.

Corectarea erorilor care blocheaza procesul de deposit de date

Schema conflictelor are loc atunci cand un set de attribute pentru domeniile raportate difera in jurul team projectului. Schema bloc a conflictelor actualizata va fi mutata intr-un deposit de date sau intr-un cub. Pentru a debloca procesul trebuie sa se corecteze toata schema conflictelor si sa se actualizeze rapoartele cu datele curente

Actualizarea datelor in warehouse sau cub la cerere

Rezolvarea unei probleme care are rapoartele cu datele neurcate: pentru a rezolva o problema cu rapoartele neactualizate sau care le lipseste date, trebuie sa procesam datele din depozitul de date manual. De asemea, putem depana erorile care apar in evenimentul vizualizarii unei aplicatii de tip server care este relatata procesului din depozitul de date.

Recrearea unei scheme si rebuiduirrea datelor din baza de date a depozitului

Rebuilduirea unui deposit de date sau a unui cub dupa mutare, restaurare, redenumire, sau esuarea datelor din serverul Team Fundation: pentru accesarea unui nivel inalt din rapoartele, trebuie rebuilduite datele din depozitul de date.

Modificarea frecventei de reimprospatare a datelor din depozitul de date sau cub

Schimbarea frecventei de reimprospatare sau a unui alt process de control din setarile depozitului de date sau a cubului: proprietatile implicite ale depozitului de date sunt setate atunci cand TFSul este instalat, dar se pot modifica mai tarziu proprietatile implicite pentru a corespunde cerintelor dorite. Doua proprietati care sunt cele mai solicitate sunt schimbarea frecventei cu care se poate actualiza datele si setarile de Securitate care controleaza accesul userilor in datele depozitului de date.

3.5 Reporting Services(SSRS-Servicii de raportare)

SQL Server Reporting Services prevede o rata plina de instrumente gata de folosit pentru a ajuta la crearea, lansarea si administarea organizarii. Serviciile de raportare includ caracteristici de programare care ne permit extinderea si personalizarea raportului de functionare.

Serviciile de raportare este un server bazat pe platforma de raportare care prevede cuprinzator raportul functionalitatii pentru o varietate a datelor surse. Acestea include un set complet de instrumente care administreaza, creaza si trimit rapoarte, si APIuri care permit developerilor sa integreze si sa extinda datele si procesul de raportare in aplicatiile personalizate. Instrumentele serviciilor de raportare lucreaza in Microsoft Visual Studio si sunt integrat complet in instrumentele si componentele SQLServer.

Cu ajutorul rapoartelor de servicii putem crea rapoarte interactive, tabulare, grafice sau sub forma de formular pentru relatii, multidimensional, sau bazate pe sursele datelor. Rapoartele includ o vizualizare bogata de date, incluzand diagrame, harti si linii. Se pot publica rapoarte, analiza procesului de raport, sau accesarea raportului la cerere. Se poate selecta dintr-o varietate larga de formate de vizualizari, exportul raportului unor aplicatii gen Microsoft Excel, si subscrierea rapoartelor publicate deja. Raportul care a fost creat poate fi vizualizat peste o conexiune bazata pe Web sau ca o parte a aplicatiei Microsoft Windows sau a siteul SharePoint. Se mai poate crea alerte sau rapoarte publicate in siteul Sharepoint si se pot primi mesaje prin mail atunci cand un raport se schimba.

Beneficiile folosirii instrumentelor datelor serverului SQL(SQL Server Data Tools) este acel comportament RDT(Raport Definition Language) care reduce iconitele grafice intr-o interfata(GUI). In acest mod, in schimbul scrierii codului, utilizatorul poate trage si lipi iconitele grafice intr-un format de raport SSRS pentru majoritatea aspectelor rapoartelor SSRS.

Rapoartele definite de RDL pot fi descarcate printr-o varietate larga de formate incluzand Exel, PDF, CVS, XML, TIFF si arhive HTML web,

Serverele SQL 2008 si 2012 SSRS pot construe rapoarte in Microsoft Word format. Rapoartele generoase ofera aditional formate de iesire.

Utilizatori pot interactiona cu direct cu serviciul Report Server Wer, sau prin intermediul Report Manager, o aplicatie web care interfateaza cu Raport Server web service. Cu Raport Manager, utilizatori pot vedea, subscribe si administra rapoartele atat de bine ca un administrator si mentine datele sursei si setarile de Securitate. Raport Manager poate trimite rapoarte SQL prin e-mail, sau sa le plaseze intr-un fisier de trimitere

Securitatea este un rol-bazat si poate fi asignat de un punct individual, asemenea unui raport sau datele sursei, un folder sau punct, sau un site larg. Rolul securitatii si drept sunt inhibate si pot fi supraincarcate.

Unul poate vedea raporturi RDL folosind standalone Report Server care vine cu Microsoft SQL Server, sau folosind controlul web ReportView Asp.NET , sau folosind controlul ReportViewer Windows Forms. Ultima variant permite rapoartelor sa fie incorporate direct intr-o pagina websau intr-o aplicatie .NET Windows. Controlul ReportViewerpoate procesa raporturi de:

• 
  Procesarea serverului, unde raportul este facut de Report Server
  
• 
  Procesarea locala, unde controalele trimit fisierele RDL chiar lui
  

SQL Server Reporting Services pot suporta si rapoarte ad hoc: proiectantul dezvolta o schema de raport si o anseaza pe serverul de rapoarte, unde utilizatorul poate allege fisierle/datele relevante si rapoartele generale. Utilizatorii pot descarca apoi rapoartele locale.

Bibliografie:

• 
  http://www.visualstudio.com/
  
• 
  http://www.microsoft.com/msj/0597/visualstudio97.aspx
  
• 
  https://msdn.microsoft.com/en-us/library/bb386044(v=vs.90).aspx
  
• 
  https://msdn.microsoft.com/en-us/library/fda2bad5(v=vs.90).aspx
  
• 
  https://msdn.microsoft.com/en-us/library/ms181774%28v=vs.90%29.aspx
  
• 
  https://msdn.microsoft.com/en-us/library/ee943825.aspx
  
• 
  D.Benage şi A. Mirza, Visual Studio 6, Teora, 2001
  
• 
  Harold Davis, Visual Basic pentru Windows .NET, Corint, 2004.
  
• 
  R.Grimes, Dezvoltarea aplicaţiilor cu Visual Studio .NET, Teora 2002.
  
• 
  Documentaţie Visual Studio şi MSDN, http://www.microsoft.com/vstudio şi http://www.microsoft.com/msdn
  
• 
  http://svn.haxx.se/users/archive-2004-02/0877.shtml Subversion Users Visual Studio 6.0
  
• 
  http://msmvps.com/gaidar/archive/2005/08/12/62473.aspx (cursuri Visual Studio, SQL Server)
  
• 
  http://www.math.uaic.ro/~mapetrii/POO/depozit/Curs7.pdf
  
• 
  http://en.wikipedia.org/wiki/SQL_Server_Reporting_Services
  
• 
  https://msdn.microsoft.com/en-us/library/bb630404.aspx
  
• 
  https://msdn.microsoft.com/en-us/library/ms244687(v=vs.90).aspx
  
• 
  https://msdn.microsoft.com/en-us/library/ms244706.aspx
  

i^http://blogs.interknowlogy.com/downloads/johnbowen/automatingBuilds/AutomatingBuildsLo.pdf

ii^http://blogs.interknowlogy.com/downloads/johnbowen/automatingBuilds/AutomatingBuildsLo.pdf

iii^ https://msdn.microsoft.com/en-us/library/ms244687(v=vs.90).aspx