TFS2010 Object Model - Anatomia di un Work Item
Scritto da
Massimo Bonanni
il
mercoledì 16 febbraio 2011
Linguaggio:
•
Framework:
•
Livello: 200
Download pdf
In quest'articolo cominceremo ad esplorare il pilastro di TFS
che si occupa della gestione dei WorkItem.
Esaminiamo, per cominciare, in maniera dettagliata come è
strutturato un WorkItem e quali classi concorrono alla sua
definizione all'interno dell'Object Model messoci a disposizione da
TFS.
Nei prossimi articoli ci occuperemo, invece, della gestione dei
WorkItems in termini di ricerca, inserimento e modifica.
L'object model di TFS mette a disposizione la classe WorkItem
(contenuta nel namespace
Microsoft.TeamFoundation.WorkItemTracking.Client nell'assembly
Microsoft.TeamFoundation.WorkItemTracking.Client.dll) per contenere
tutte le informazioni relative ad un WorkItem.
Ricordiamo che la struttura di un WorkItem può cambiare da
progetto a progetto poiché il template utilizzato può essere
diverso (il template Scrum ha dei campi che hanno nome diverso e
valori diversi rispetto al template MSF Agile).
Per questo motivo, come vedremo tra poso, la classe WorkItem è
molto versatile ed in grado di variare ciò che si può memorizzare
al suo interno in base al template utilizzato.
Nella seguente figura è riportato il diagramma delle classi di
un WorkItem:
Come possiamo vedere il WorkItem espone una serie di proprietà
alcune delle quali sono di tipo scalare mentre altre sono
collection di vario genere.
La proprietà Fields (di tipo FieldCollection) contiene l'elenco
dei campi (di classe Field) definiti nel template e che possono
essere valorizzati dall'utente.
La classe Field espone tutta una serie di proprietà che definiscono
completamente il template del campo del WorkItem:
Le più interessanti sono:
- AllowedValues: contiene l'elenco dei
valori ammissibili per il campo. Si tratta di una collezione di
stringhe che definisce i possibili valori che il campo può
assumere;
- FieldDefinition: contiene le
caratteristiche del campo come il tipo (String, Boolean, etc.,
etc.), dove il campo può essere utilizzato, il testo di help e via
dicendo;
- HasAllowedValuesList: indica se il campo ha
una lista di valori ammissibili o meno. Ad esempio un campo data
non ha una lista di valori ammissibili, mentre il campo "assegnato
a" avrà l'elenco degli utenti tra i valori ammissibili;
- IsEditable: indica se il campo è modificabile
o meno nello stato in cui si trova il workitem;
- IsRequired: indica se il campo è obbligatorio
o meno;
- Name: nome del campo;
- OriginalValue: valore del campo al precedente
salvataggio;
- ProhibitedValues: elenco dei valori non
permessi per il campo;
- Status: stato del campo;
- Value: valore del campo (di tipo object).
Grazie alla proprietà Fields, i campi che definiscono la
struttura di un workitem sono facilmente estendibili aggiungendone
di nuovi.
Esistono, comunque, dei campi, definiti "core", frequentemente
presenti in un workitem e definiti nell'enumerazione CoreField:
Per questi campi, la classe WorkItem espone delle proprietà
(alcune di sola lettura) che consentono un rapido accesso agli
stessi.
Ad esempio, per il campo CoreField.CreatedDate (che è un campo che
viene automaticamente valorizzato quando si crea il workitem), la
classe WorkItem espone la proprietà di sola lettura
CreatedDate.
Se proviamo ad analizzare come, internamente, è implementata
questa proprietà otteniamo:
Di fatto, quindi, il workitem contiene una collezione Item di
oggetti che rappresentano, proprio i suddetti campi "core".
La proprietà Attachments della classe WorkItem contiene l'elenco
degli attachment collegati al WorkItem in termini di oggetti di
classe Attachment.
La proprietà Links e WorkItemLinks contengono, rispettivamente,
la collezione di oggetti che definiscono il generico collegamento a
un elemento e il collegamento ad un altro workitem.
Infine la proprietà Type definisce la tipologia del WorkItem (ad
esempio Task all'interno del template MFC Agile).
Anche in questo caso la classe WorkItemType prevede dei campi
standard (come descrizione, nome, etc., etc.) ma anche la
possibilità di estendere questi con una collezione (Fields) di
oggetti FieldDefinition.
La classe WorkItem espone anche una serie di metodi interessanti
per gestire correttamente il workitem stesso ed in particolare:
- Copy: permette di creare una copia del
workitem;
- GetNextState: recupera lo stato in cui
il workitem si verrebbe a trovare a causa di un'azione dell'utente
(passata per argomento). Un esempio di azione è
"Microsoft.VSTS.Actions.Checkin";
- IsValid: verifica la validità del workitem in
base agli eventuali valori dei campi impostati;
- Open: apre il workitem per la modifica. Quando
è eseguito questo metodo (a meno che il workitem non sia stato
appena creato o già aperto) viene eseguito un round-trip
verso il server di TFS per recuperare la storia dei workitem.
- PartialOpen: apre il workitem per la modifica
senza eseguire il round-trip verso il server. In questo caso si
hanno a disposizione solo i dati dell'ultima versione e non la
storia del workitem. E' l'ideale quando non si devono fare
modifiche che dipendono dalla storia del workitem.
- Reset: annulla tutti I cambiamenti eseguiti
dall'ultimo salvataggio.
- Save: invia tutti I dati del workitem
modificati al server.
- SyncToLatest : sincronizza il workitem con
l'ultima versione presente sul server.
- Validate: esegue la validazione del workitem
in base ai valori inseriti nei campi. Nel caso in cui il workitem
abbia dei campi il cui valore non è ammesso, Il metodo li
restituisce in un array di oggetti Field (in realtà l'array è un
ArrayLIst di Object, ma internamente ci sono delle istanze di
Field).
Riferimenti
[1] Team Foundation Server Architecture: http://msdn.microsoft.com/en-us/library/ms252473.aspx
[2] Extending Team Foundation: http://msdn.microsoft.com/en-us/library/bb130146.aspx
[3] Team Foundation Server 2010 SDK: http://code.msdn.microsoft.com/TfsSdk
[4] Team Foundation Server Team Blog: http://blogs.msdn.com/b/team_foundation/
Tags: TFS,Team Foundation Server