Visual Studio Team System 2010: Primo Contatto

Navigation

Home

Visual Studio Team System 2010: Primo Contatto

Questo articolo ripercorre alcuni miei appunti e le prime impressioni di utilizzo di Visual Studio Team System 2010. Sto usando un progetto di esempio per analizzare il prodotto prima di portare la nostra famosa applicazione Estates Management sotto VSTS 2010.

Visual Studio Team System venti-dieci (come viene chiamato affettuosamente) porta con se molte novità sia per la versione Architect che per la versione Tester. Non meno numerose sono le nuove funzionalità della parte Team Foundation Server.
Da quello che si evince dalle conferenze stampa la parte più importante delle novità riguarda l’edizione Architect, sia per quanto riguarda le modalità di lavoro del team ovvero una maggiore singergia fra i componenti, sia per quanto rigurda l’introduzione di strumenti di modellazione UML che si aggiungono agli attuali DSL.

Democratize: everybody has a chance to play

Quello che accade spesso oggi, anche nei progetti che ho seguito personalmente, è la quasi totale divisione dei compiti fra architetti e gli altri membri del team: solitamente all’inizio della progettazione gli architetti si chiudono in una stanza e producono una serie di diagrammi architetturali. E’ vero che già oggi, se questi diagrammi sono prodotti con la Architect Edition, è possibile implementare le componenti applicative partendo dal diagramma e grazie alle estensioni dei power tools è possibile creare progetti di tipo ASP.NET, Windows e class library arrivando alla solution completa dei progetti e delle reference fra di essi. Per esempio, partendo dal diagramma seguente è possibile implementare con un solo colpo di mouse l’applicazione ASP.NET, l’applicazione windows client e le due dll rappresentate in questo estratto del diagramma completo.

Si veda il post completo sui Power Tools.

L’interazione fra il diagramma applicativo e il codice reale è presente anche nella configurazione delle applicazioni: sul client windows e sull’applicazione web, per proseguire con l’estratto del nostro esempio, la configurazione effettuata dagli architetti sui Settings & Constraint si riflette sulle effettive configurazioni presenti all’interno dei rispettivi file .config.

In Visual Studio Team System 2010 la sincronizzazione e quindi la collaborazione fra il “disegno” e il codice reale (e quindi fra Architect e Developer) viene effettuata a più livelli. Ad esempio il nuovo Layer Diagram consente di visualizzare le varie componenti applicative nei layer definiti per l’applicazione. L’architetto e/o il developer possono così avere una rappresentazione più concreta di quali elementi sono compresi in quali layer.

Ecco un esempio di Layer Diagram per una applicazione di esempio:

Nella toolbox ci sono solo Layer e Dependency che consentono di definire i layer applicativi e i flussi delle chiamate fra layer. Si può partire da zero oppure da una applicazione esistente (ad esempio da diagramma dei namaspace, più avanti) trascinando un namespace e portandolo sul layer effettivo. Si può fare poi Show Dependency per vedere le dependency fra le classi dei namespace rappresentati nel diagramma senza dover ricreare i percorsi. Con questo diagramma quindi possiamo rappresentare velocemente i vari componenti applicativi suddividendoli nei layer logici e verificare su una applicazione esistente quali sono le interazioni fra le classi.

Il flusso delle chiamate definisce anche le regole di chiamata fra layer: ad esempio, se il Presentation Layer ha un flusso possibile solo con il Business Layer, non dovremmo permettere allo sviluppatore di fare una reference verso il Data Access Layer e utilizzare direttamente le classi di accesso ai dati. Tramite la funzione Validate All è possibile eseguire questi controlli senza dover analizzare il codice. In pratica si controlla che le classi reali non facciano chiamate che non sono permesse dalle dependency: trovo questo strumento importantissimo per effettuare verifiche sulle applicazioni esistenti e per rappresentare graficamente una applicazione esistente ricavandone le idee architetturali che spesso non sono state documentate (forse ho avuto sfiga, ma nei progetti esistenti su cui ho messo le mani a posteriori, la documentazione è sempre stato un problema..non so se capita anche a voi J). Si possono anche impostare regole di compilazione per MSBuild per evitare una compilazione che non rispetti le corrette chiamate fra layer. E’ possibile fare queste verifiche anche sul Build Server (quindi anche senza Visual Studio) inserendo un tag <validate Include=”diagramma.Layer”> che punta al diagramma da controllare. E’ un FxCop per Architect J.

I diagrammi si possono Copy&Paste ovunque oppure esportare (stanno decidendo dove: sembra Visio di sicuro) per creare documentazione elettronica senza sforzo.

Il layer diagram è accessibile anche dal codice e vice versa, ovvero è possibile conoscere la posizione del codice che sto vedendo rispetto ai layer oppure scendere nel dettaglio di una classe (nel codice della classe) partendo dalla rappresentazione nel layer diagram.

UML

Un’altra novità di rilievo della versione Architect è il supporto a UML che in molti hanno lamentano nella versione 2005 e 2008 di Visual Studio Team System Architect Edition. L’idea è poter approcciare la definizione dell’architettura Top-Down oppure Bottom-Up.

Se si guarda la soluzione dall’altro, sono disponibili 5 designer UML (almeno secondo le previsioni attuali) per rappresentare il livello logico di una applicazione; se invece si guarda la soluzione dal basso, restano più che validi i DSL che, essendo più concreti e più specializzati, aderiscono meglio alla rappresentazione reale. L’idea è quindi non abbandonare DSL, ma creare la formula magica: UML + DSL == Better Code. La cosa interessante e che i diagrammi sono “agganciabili” ovvero si può partire dal diagramma logico in UML (ad esempio il sequence diagram) per scendere nel codice reale con un semplice click del mouse. Ad una modifica del codice reale, supponiamo per effettuare una chiamata ad una nuova classe, il sequence diagram si aggiorna per rappresentare questa interazione.

Per quanto riguarda UML (2.0 e 1.1) è importante comprendere la connessione rispetto ai DSL che stanno sotto. Addirittura, i designer UML sono stati creati con il DSK Toolkit. Quindi i DSL tool esistono ancora e anzi ne viene incoraggiato l’utilizzo per modellare il proprio dominio creando i DSL custom.

Hanno deciso di “tornare” a UML perchè è quello che la gente usa. La prima versione di VSTS puntava invece a rappresentare in modo aderente alla realtà del progetto l’applicazione, i logical datacenter e il deploy relativo. Probabilmente non saranno 100% standard perchè nessuno lo è: cercheranno di coprire i livelli (come sapete il supporto allo “standard” UML viene indicato come compliance ad un determinato livello)

Nella prima versione (2010) ci saranno questi 5 diagrammi UML:

1. Use Case

2. Component

3. Activity

4. Class

5. Sequence

Tutti questi strumenti hanno una migliore integrazione con il codice: ad esempio sto scrivendo o analizzando questo pezzo di codice e posso sapere in che punto mi trovo rispetto ai diagrammi.

Resta l’idea che non viene consigliata una modalità (fra top-down o bottom-up): ognuno si può muovere come preferisce rispetto al suo modo di lavorare.

Rapporto con Visio: Visio è il prodotto più usato al mondo per far modeling UML quindi sarà possibile importare i diagrammi.

Top Down Approach (parto con UML)

Il nuovo Model Explorer Windows consente di vedere e gestire i vari modelli. I diagrammi UML si aggiungono alla solution: ognuno ha una estensione diversa gestita anche da TFS per centralizzare i diagrammi e gestirne il versioning.

Ecco qualche screen-shot dei designer UML.

1) Use Case

a. Actor e i vari Use Case

b. Si connettono (association) gli actor ai vari use case

c. Si possono fare le include di un uc in un altro uc

2) Activity Diagram

a. Descrrive il flusso dei dati (i processi): si mettono gli step e si connettono in sequenza

b. Nel Model Explorer si vedono le componenti degli altri diagrammi per poter creare legami fra di essi.

3) Sequence Diagram

a. Si può fare reverse engineer dal codice

b. Si disegnano le seguenze

c. Il diagramma resta sincronizzato con il codice (come vedremo più avanti), quindi a fronte di una nuova chiamata scritta nel metodo, il diagramma presenta un nuovo passo all’interno della sequenza

4) Component Diagram

a. I Component non rappresentano elementi fisici (potranno poi essere DLL o EXE o composizioni di questi, ma a questo livello non ci interessa)

b. Si mettono poi le interfacce e si connettono i vari componenti sempre utilizzando le informazioni del Model Explorer.

5) Logical Class Diagram

a. Lavora con il Class Diagram .NET che rappresenta il fisico

b. Si trascinano gli elementi definiti negli altri diagrammi

c. Si definiscono le operazioni e gli attributi

d. Si torna nel .sequence e si legano le “cose reali”

e. Si possono fare “cose ereditate” (e il designer mostra il tutto)

In questo ultimo digramma si vede l’interfaccia di pagamento derivata nel sistema di pagamento specifico per l’applicazione.

Botton Up (parto dal codice)

L’idea è che quasi sempre ci sono cose già fatte: anche quando si parte con un progetto nuovo magari ci sono esempi fatti o pezzi già pronti realizzati per prova o altri componenti esistenti da utilizzare.

Il diagramma con estensione.dgml consente di iniziare a comprendere una applicazione esistente. Per creare il diagramma in modo semplice si utilizza l’Architecture Explorer che mostra tutte le classi nella solution divisi per componente e namespace. Ad esempio, partendo da questa situazione esistente nella solution

E trascindando le classi di un namespace (volendo anche tutte le classi della solution) si ottiene la rappresentazione delle classi e l’interazione fra di esse all’interno di questo

E si ottiene questo

A parte una inutile ragnatela, pensiero che colpisce subito appena il diagramma viene rappresentato, basta prendere una classe, cliccarci sopra e iniziare ad esplorare le interazioni fra le classi in modo semplice e intuitivo: pensate sempre a cosa vorrebbe dire entrare nel codcie di ogni classe e di ogni metodo per vedere quali sono le chiamate effettuate, e ancoara più difficile, sapere da quali componenti viene chiamata la classe in oggetto: da sempre l’object explorer ci può dare una mano, ma vedere graficamente “la ragnatela” è decisamente più semplice e intuitivo.

Da questo diagramma si possono far partire diversi Analyzer che analizzano appunto il diagramma stesso per individuare, ad esempio, i riferimenti circolari, piuttosto che le dipendenze fra le chiamate; quest’ultimo individua le classi (volendo raggruppatoe per namespace) e le chiamate effettuate. Ecco un esempio:

Diventa più semplice capire l’applicazione esistente, vederne i dettagli (da ogni classe si può andare a visualizzare il codice, vedi prossima immagine), analizzare le dipendenze e le eventuali anomalie sulle chiamate senza dover per forza vedere il codice (che magari è stato scritto in sanscrito J).

Il dettaglio di ogni classe dentro il namespace e il codice è visibile facendo un semplice doppio click.

Quest’ultima immagine non ha molto senso; era assolutamente chiaro cosa volesse dire andare a vedere il codice con un doppio click, ma averla inserita ci consente di capire che facendo ancora una volta una semplice operazione con il mouse possiamo generare il Sequence Diagram (a partire da qualunque metodo).

Questo il Seguence Diagram del metodo createNewOrderButton_Click

Se nell’approccio Top-Down il Sequence Diagram era la base di partenza per poi scrivere il codice, avendo una applicazione esistente è facile percorrere il percorso inverso.

E’ ottima questa sincronizzazione (e forma di reverse engineering) anche per imparare a creare Sequence Diagram: ad esempio metto una chiamata ad un’altra classe nel codice e vedo come avrei dovuto fare il Sequence Diagram. E’ ovvio che sarebbe bene fare il contrario, il sequence diagram nasce proprio per rappresentare i flussi in modo astratto dal codcie, ma avere entrambe le possibilità è sicuramente un plus.

Ovviamente dal sequence diagram si può tornare codice del metodo rappresentato.

Dal Sequence Diagram si può anche produrre il Class Diagram e sincronizzarlo oppure effettuare una Create Method per aggiungere un metodo reale alla classe rappresentata.

Per questa prima parte direi che è tutto. Ci sentiamo presto per vedere le novità sulla parte tester, build, manual testing e le novità della parte di gestione del progetto come work-item gerarchici.

Molte informazioni che trovate in questo mio articolo e alcuni screenshot arrivano direttamente dai video che sono stati pubblicati nella Team System Week Videos di fine settembre 2008: http://channel9.msdn.com/posts/VisualStudio/Visual-Studio-Team-System-2010-Week-on-Channel-9/.

Allego anche tutti i miei post sulla versione 2005 e 2008 di VSTS/TFS come puntatori che spero siano utili

Architect.

• http://blogs.devleap.com/rob/archive/2005/12/29/6428.aspx

• http://blogs.devleap.com/rob/archive/2007/10/15/visual-studio-team-system-2008-architect-power-tools.aspx

• http://www.devleap.com/document.aspx?id=3837

• http://blogs.devleap.com/rob/archive/2006/09/24/14243.aspx

• http://blogs.devleap.com/rob/archive/2006/01/27/6584.aspx

• http://blogs.devleap.com/rob/archive/2005/12/29/6428.aspx

• http://blogs.devleap.com/rob/archive/2005/09/12/5706.aspx

Developer e Tester

• http://blogs.devleap.com/rob/archive/2008/09/10/vsts-2008-sp1-web-test.aspx

• http://blogs.devleap.com/rob/archive/2007/08/21/visual-studio-2008-for-mobile-dev-e-non-solo.aspx