Come comunico questi vincoli al team di sviluppo?

Costruire il software nella
nuova era: Software Factories
e Visual Studio Team System
Lorenzo Barbieri
[email protected]
La necessità da cui partiamo:
IL “DOPPIO” RUOLO
DELL’ARCHITETTO
Non esiste un solo architetto...
Solution
Architect
Infrastructure
Architect
Sviluppo
IT Operations
...chi sviluppa...
Solution
Architect
Sviluppo
• Come progetto
sistemi
Infrastructure
che soddisfano le Architect
operational policies?
• Come comunico i requisiti
applicativi agli IT Pro?
• Come comunico le scelte
architetturali ai
developer? IT Operations
• Come mantengo
sincronizzati codice e
modelli?
...chi gestisce...
Solution
• Come descrivo le policy e
Architect
la configurazione?
• Come comunico questi
vincoli al team di
sviluppo?
• Come possiamo verificare
i sistemi prima di farne il
Sviluppo
deployment?
Infrastructure
Architect
IT Operations
...ci vogliono i tool appropriati!
Solution
Architect
Sviluppo
Manca un
linguaggio
comune...
Infrastructure
Architect
IT Operations
Service Modeling Language (SML) ovvero la nuova versione del:
SYSTEM DEFINITION MODEL
System Definition Model (SDM)
• E’ un modello formale che descrive un intero sistema
• Contiene tutte le informazioni che riguardano il deployment e
la gestione
?
• E’ un formato machine-readable, che cattura gli
intenti di sviluppatori e IT Pro
–
–
–
–
–
–
–
–
Topologia del sistema
Contraint imposti dagli sviluppatori
IT Policy
Direttive di installazione
Health model
Regole di monitoring
Service Level Agreement
Report
Applicazioni
Application
Hosts
Reti e OS
Hardware
?
Service Modeling Language
• SDM è un’iniziativa Microsoft.
• A fine Luglio 2006 Microsoft, BEA, BMC,
Cisco, Dell, EMC, HP, IBM, Intel e Sun
hanno creato SML, un linguaggio
standard per la definizione dei Servizi e
dei Sistemi.
• E’ attualmente in Draft, vedrà compimento
probabilmente in Visual Studio “Orcas”
Il primo passo:
VISUAL STUDIO TEAM
EDITION FOR SOFTWARE
ARCHITECTS
Distributed System Designer
Application Designer
System
Designer
Design e
configurazione
dei sistemi
Logical Datacenter
Designer
Architettura
delle
applicazioni
Class Designer,
Codice
il
Design,Descrive
sviluppo,
test, deployment di
un sistema nel
implementazione
datacenter
e
File Validazione
binari e
Report HTML e
correzione
risorse
copiati
XML per il
degli errori
in produzione
deployment fisico
Descrive il
datacenter dal
punto di vista
“logico”
Deployment
Designer
Deployment
Report
Questi modelli a volte non bastano... E poi...
...DOV’È UML?
I tre approcci di UML:
• UML come abbozzo (sketch)
–
–
–
–
Documentazione, discussione e condivisione di idee
Basso rigore formale
Selettività: focalizzazione solo su alcuni aspetti dell’applicazione
Bassa, se non nulla dipendenza dal tool di modellazione
• UML come progetto (blueprint)
–
–
–
–
Completezza
Alto rigore formale
Forward e reverse engineering
Forte dipendenza dal tool di modellazione
• UML come linguaggio di programmazione
– Diagrammi compilabili
– No forward e reverse engineering
– Fortissima dipendenza dal tool di modellazione
UML e la tecnologia Microsoft
• Il problema di UML è che è un linguaggio
di modellazione troppo generico, sfruttato
generalmente solo in minima parte.
• Visio Enterprise Architect (che fa parte di
MSDN Premium) è il tool per la
modellazione UML e anche per il reverse
engineering
Ma serve veramente?
• Molto spesso di UML si usano solo pochi e specifici
diagrammi:
– Use Case, Sequence e Collaboration diagram
– Diagrammi delle classi
• I diagrammi delle classi sono molto simili a quelli
ottenibili dal Class Designer di VS2005 (presente dalla
Standard in su):
– La differenza è che il Class Designer di VS2005 mappa
1:1 tutti i concetti di .NET (attributi, etc...) senza richiedere
strane estensioni, permettendo un round-trip completo
codice<->modello
– I diagrammi delle classi UML sono generici, e vanno estesi
per mappare i concetti specifici
Attenzione al BDUF
• Attenzione che se i modelli non servono in
pratica, rischiano di restare carta straccia.
• Molto spesso si tende a fare il Big Design
Up Front, disegnando modelli su modelli
che non verranno però più manutenuti.
• Il vantaggio dei designer di VSTS è di
essere completamente bidirezionali
La visione di Microsoft per il
Modeling
Our vision is to change the way developers perceive the value of
modeling. To shift their perception that modeling is a marginally useful activity
that precedes real development, to recognize that modeling is an important
mainstream development task and not an activity primarily focused on
documentation.
From: Visual Studio 2005 Team System Modeling Strategy and
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/vstsmodel.asp
FAQ
• Un modello rappresenta un set di astrazioni che supporta gli
sviluppatori in compiti ben definiti
• I modelli possono essere usati per aggregare informazioni da varie
fonti, e possono aiutare nel verificare la consistenza del sistema
• I modelli possono essere implementati attraverso un processo di
“compilazione”, dove il codice, i file di configurazione e tutti gli altri
artefatti possono essere generati automaticamente
Raccomandazioni:
•
Microsoft raccomanda di usare UML (o simili) per le seguenti attività:
–
–
–
–
•
Sketching
White boarding
Documentazione
Disegni e altri diagrammi che non generano direttamente codice
Raccomanda i Distributed System Designers e i Domain Specific
Languages per:
– Astrazioni precise dalle quali può essere generato il codice
– Disegni e altri diagrammi che servono per generare codice o altri diagrammi in
maniera automatica
•
Nessuno dei tool precedenti per descrivere in maniera dettagliata la logica
dei programmi (almeno per qualche anno ancora)
•
Fonte:
– http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnvs05/html/vstsmodel.asp
Andiamo oltre:
DOMAIN SPECIFIC
LANGUAGES
DSL: Cosa sono?
• Un Domain Specific Language, a differenza di un linguaggio
general-purpose, è progettato per essere utilizzato per compiere
uno specifico task in uno specifico dominio.
• I Domain Specific Language possono essere grafici, testuali,
descrittivi, etc...
• Alcuni DSL li usavamo da sempre, anche senza accorgercene:
–
–
–
–
Designer delle Windows Forms, VB1..VB6
Designer di ASP.NET, FrontPage
Tool WYSIWYG in genere che aiutano nello sviluppo
Regular Expression, file XML usati per scopi specifici, etc... Sono tutti
DSL senza rappresentazione “grafica”
• Quindi i DSL in generale sono formalismi che possono essere usati
“direttamente” per generare codice o altri elaborati.
DSL in Visual Studio
• Di default in Visual Studio vengono forniti una serie di
Designer che sfruttano la piattaforma fornita dai DSL
Modelling Tools:
– Class Designer (a partire dalla Standard)
– Application, System, Logical Datacenter e Deployment
Designers
• Tramite i DSL Tools (disponibili nel Visual Studio 2005 SDK
v4) è possibile creare i propri DSL che possono essere
utilizzati a partire da Visual Studio 2005 Standard
• Maggiori informazioni sui DSL Tools possono essere trovate a
partire da: http://msdn.microsoft.com/vstudio/DSLTools/
Ha senso crearsi i propri
designer?
Shape
Corona
members
Base
Group
property
label
Corona
playing
Corona
waiting
pause
begin
running
stop
R
0.1R
C
+v
0.1R
R
C
0.7CR
0v
Componenti del Designer
Toolbox
Explorer
Property
Browser
Validation
Drawing surface
with domain
specific notation
Esempio: Entity Designer
I DSL sono l’evoluzione della
specie...
Routine configuration
Creative construction
Wizards
Feature-based
configuration
scr1
scr2
scr4
scr5
matrix
scr3
scr6
[element type]
scr7
scr11
scr9
Graph-like language
(with user-defined elements)
scr8
rect
scr12
lower
Triang
shape
upper
Triang
format
symm
bounds checking
vect
C-like
array
Frtn-like
scr10
Path through a decision tree
Subtree of a feature tree
Subgraph of an
(infinite) graph
I DSL vanno creati ed usati
“ragionevolmente”
•
Per costruire un DSL bisogna conoscere molto bene un Dominio
– Non si può partire dal DSL!
– Il DSL può essere l’astrazione di un lavoro fatto e da ripetere N volte
•
A volte il Dominio è troppo “variabile” per giustificare l’investimento nel
creare un DSL
•
Possono essere usati per creare graficamente dei designer “comuni”:
–
–
–
–
•
WSDL
File di mapping
File di configurazione
Codice da riutilizzare spesso
I DSL non vanno “normalmente” usati per crearsi i propri linguaggi di
modellazione
– Si ricadrebbe nel BDUF
•
I DSL si sposano alla perfezione con le Software Factories
Software Factories
COSA SONO?
I problemi dello sviluppo
tradizionale
•
I problemi principali nel modo “tradizionale” di sviluppare software sono:
–
–
–
–
–
•
Il modo tradizionale è ancora molto artigianale:
–
–
–
–
•
Ogni progetto è trattato come un caso unico
Sistemi monolitici molto complicati
Livelli di astrazione troppo bassi
Immaturità del processo
Domanda di software molto superiore all’offerta
Basato sul lavoro
Tool e processi troppo generici
Troppi “casi unici” e troppo lavoro “manuale”
Riutilizzo minimo del lavoro già svolto
Il risultato sono:
–
–
–
–
Ore di straordinario
Bug
Problemi
Etc...
Una possibile soluzione
• Il modello delle Software Factories è una
possibile soluzione all’artigianato nel software.
• E’ un modello che si fonda sui concetti del Model
Driven Development (da non confondersi con la Model
Driven Architecture di OMG) e che promette una
“industrializzazione” dei processi software, migliorando
il riuso e le economie di scala.
• Nei processi attuali le uniche economie di scala
applicabili al software riguardano la produzione del
prodotto finito (CD, DVD, manuali, etc...) e non la sua
realizzazione.
Application Specific Integrated
Circuits (ASICs)
Cosa c’è alla base delle
Software Factories
Software
Product
Lines
Guidance in
Context
Architecture
Frameworks
Model
Driven
Development
Software Factories
• Si parla di Software Factories quando ci sono i quattro
elementi precedenti, chiamati anche “pilastri”
• Lo scopo di questi quattro pilastri è quello di migliorare la
produttività e la predicibilità durante il ciclo di vita del software
• Creare una Software Factory ha senso quando si devono
sviluppare una serie di soluzioni correlate e customizzabili per
i clienti specifici
– Non industrializzo un processo quando voglio una produzione
non di serie e con caratteristiche molto differenziate
– Industrializzo un processo quando voglio una produzione di
“serie” ma customizzabile
• Automobili con un listino molto variegato
• PC acquistati da un grosso produttore ma customizzabili
• Etc...
Software Product Lines
Estensibilità
Scope
Parti comuni
Variabilità
• “A Software Product Line is a set of software-intensive systems
sharing a common, managed set of features that satisfy the specific
needs of a particular market segment or mission and that are
developed from a common set of core assets in a prescribed way”
Paul Clements e Linda Northrop, 2002
Software Product Lines
• In pratica:
– Costruire nuove soluzioni assemblando soluzioni
parziali e/o configurando componenti generici
– Bisogna specificare e implementare solo se
feature univoche, basandosi su quelle già
presenti
– Se ben applicate riducono i tempi degli sviluppi
custom dal 40% all’80% rispetto ai metodi
tradizionali
• Per maggiori dettagli:
– http://softwareproductlines.com/index.html
Architecture Framework
• Si parla di Architecture Framework riferendosi a quel particolare
asset che identifica l’architettura sulla quale si basa tutta la
soluzione (“baseline architecture”.
• Generalmente si usa un Architecture Framework già pronto (Smart
Client, etc...) o lo si realizza sulla base del riuso di proprie classi,
risorse, bets practice, etc...
• Se fatto bene l’Architecture Framework permette di alzare
notevolmente il livello di astrazione e di ridurre il tempo necessario
all’implementazione della soluzione finale.
• In pratica:
– Definisco dei Viewpoint che identificano e separano i concetti
fondamentali
– Organizzo tool, processi e contenuto in base ai viewpoint
– Integro e collego le fasi del ciclo di vita, i componenti da usare e i livelli
di astrazione da impiegare
Cambia il processo di sviluppo
Asset
Development
creates
uses
Tools, Process,
Content
Requirements,
Defects
uses
creates
Product
Development
creates
uses
Products
Requirements,
Defects
uses
creates
Business
Come ricavo la SPL e l’AF?
•
•
DEVO già avere esperienza nello sviluppo di un sistema.
MAI partire da zero a sviluppare una SPL e un AF
•
Lo faccio solo se ho delle varianti:
–
CRM, ERP, etc...
Assets {1,2}
System 1
copy/paste
•
•
•
adapt
generalize
System 2
Assets {1,2,3}
customize
System 3
customize
Identifico gli asset dalle varianti
Adatto gli asset alle nuove varianti
Customizzo e applico tool, processi, etc..
per realizzare le singole varianti
adapt
System 4
customize
System 5
Assets {1..5}
Feature Model: Uno strumento
per gestire la configurazione
OrderManagement
Feature obbligatoria
OrderCapture
Payment
Tax
PayByBill
Invoice
Online
PayOnDelivery
Approval
CreditCard
Fulfillment
ShipmentCost
Printed
Shipping
PackageTrackingNo
Feature opzionali
«implies»
FrequentFlyer
Feature alternative
«implies»
ElectronicDelivery
PackageSlip
Esempio di “configuratore”
• E’ possibile costruirsi
un “configuratore” che
gestisca i nostri
Feature Model e
prepari in uscita la
descrizione per poter
creare la (o le)
Solution di Visual
Studio
Guidance in Context
• Non servono le Software Factories per avere della Guidance.
• Abbiamo già:
–
–
–
–
–
MSDN
I Blog
Libri
Articoli
Pattern & Practice:
•
•
•
•
Enterprise Library
Application Blocks
Libri
Etc...
• Il problema è che abbiamo TROPPE informazioni.
• Identificare nelle varie Guidance disponibili quello che ci serve
è quasi più dispendioso che sviluppare la nostra soluzione.
Guidance in Context
• La Guidance deve essere calata nel contesto
in cui stiamo lavorando.
• Non deve essere generica “bisognerebbe
fare così” ma deve essere concreta, con
istanze concrete e soprattutto deve essere
automatizzabile:
–
–
–
–
Wizard
Strumenti
Designer
Guidance legata al mio singolo
problema/contesto
Guidance Explorer
http://www.guidancelibrary.com/GuidanceExplorerBeta
Come evolve la Guidance
Designers
Abbiamo bisogno di tool che ci
aiutino nell’implementazione
Se riusciamo a generare
Frameworks
una serie di feature
precompilate diventano
Templates
Se riusciamo ad
automatizzarne l’applicazione
diventano
Patternssulla base
Una volta formalizzate
dell’esperienza diventano
Guidelines
GAX e GAT
• GAX e GAT ci permettono di costruire la Guidance
“tarata” per il nostro problema/dominio/tecnologia
specifica:
– Guidance Automation Extensions (GAX) estende
VS2005 con la capacità di eseguire i Guidance
Packages contenuti, ad esempio, nelle Software
Factories. I Guidance Packages permettono di
automatizzare una serie di task di sviluppo all’interno
dell’ambiente Visual Studio.
– Guidance Automation Toolkit (GAT) è un
particolare Guidance Package che permette agli
architetti di costruire un insieme riutilizzabile di Asset
che possono formare Software Factories, framework
e pattern.
GAT
• Cosa posso creare con il GAT
– Recipes - Recipes automate activities that developers would usually
perform manually, often by following a series of instructions.
– Actions Actions are atomic units of work called in a defined sequence
by recipes.
– Text Template Transformation Templates A Text Template
Transformation template consists of a combination of text and scriptlets.
Scriptlets are expressions in Visual Basic or C# that when run, return a
string that is directly inserted into the output stream of the template.
– Wizards Wizards are value gathering strategies used to gather values
from recipe arguments. Any recipe can have a wizard associated with it.
– Type Converters Type converters validate the value of a field and
convert them from their user interface representation to a type
representation
– Visual Studio Templates Visual Studio templates are written in XML
and are used by Visual Studio to create solutions or add one or more
projects or items to an existing solution.
Model Driven Development
• Il Model Driven Development nelle Software Factories è attuato
tramite i Domain Specific Languages e i designer grafici.
• L’idea alla base del Moden Driven Development è legata al fatto che
i modelli non servono solo come documentazione, ma come base
concreta per generare codice.
• I vantaggi di questo approccio:
– Aumenta il livello di astrazione – i modelli sono un ottimo
meccanismo gestire la complessità concentrandosi solo sugli aspetti
rilevanti al problema da risolvere
– Chiude il divario tra design e codice – grazie ai DSL è possibile
passare dai modelli al codice
• Un’altra possibile implementazione del MDD è la MDA (Model
Driven Architecture) di OMG, che però si basa su UML e sui concetti
di platform indipendent model e degli attuatori per passare alla
tecnologia specifica (Java, .NET, etc...)
SOFTWARE FACTORIES IN
PRATICA
Ciclo di vita di una Software
Factory
E praticamente...
• La nostra Software Factory alla fine non sarà
nient’altro che un “qualcosa” che creerà una (o più)
soluzioni in Visual Studio contenenti la base della
nostra applicazione, utilizzando il codice, le best
practices, i framework, etc... definiti in precedenza.
• E’ possibile andare oltre, ad esempio pensando
all’integrazione con Team Foundation Server:
– Branch da una serie di “building block”, così se li modifico
posso sfruttare le funzionalità di Merge
– Creazione automatica di una serie di WorkItem
– Creazione di Test, regole di Code Analysis, Team Build,
etc...
SOFTWARE FACTORIES GIÀ
PRONTE
Per non fare tutto da zero
• Esistono già delle Software Factory
“tecnologiche”:
–
–
–
–
–
Web Services Software Factory
Web Client Software Factory
Smart Client Software Factory
Mobile Client Software Factory
Ne usciranno tante altre...
• Aggregano Guidance, Application Block,
Framework e Best Practices esistenti
Per non fare tutto da zero
• Difficilmente troverete Software Factory
“applicative” già pronte perchè dipendono
molto dal VOSTRO contesto
• Probabilmente in futuro usciranno
Software Factory relative ad esempio
all’integrazione con prodotti specifici
Visual Studio Team System
LA PIATTAFORMA
INTEGRATA
Application Life Cycle
Management (ALM)
Business
Analyst
Operations, QA
and Help Desk
Web Clients and
XML Web
Services
Third-Party
IDEs
Visual Studio Team System
Visual Studio Team Suite
MSF Process and Guidance
Visual
Studio
Team
Explorer
Software
Architects
Application
Modeling
Infrastructure and
Deployment
Modeling
Software
Developers
Code Analysis
Performance
Tuning
Security Analysis
Software
Testers
Performance
Testing
Manual Testing
Test Case
Management
Database
Professionals
Database
Deployment
Database
Change Mgmt.
Database
Testing
Unit Testing
Code Coverage
Class Modeling
Visio and UML Modeling
Visual Studio Professional Edition
Load Test Agent
Visual Studio Team Foundation Server
Change Management
Reporting
Integration Services
Work Item Tracking
Project Site
Project Management
Visual
Studio
Industry
Partners
TEAM FOUNDATION SERVER
Team Foundation Server
Work Item
Tracking
Project
Management
Reporting
Version
Control
Build
Automation
Affidabilità della piattaforma
server
• Tutti i dati contenuti in Team Foundation
Server si appoggiano ad un DB SQL
Server 2005.
• Questo ci permette di gestire in maniera
molto semplice il backup e la
manutenzione del server.
Report sullo stato dei progetti
ACCEDERE A TEAM
FOUNDATION SERVER
Team Explorer
• E’ lo strumento usato per:
– Creare nuovi “team project”.
– Collegarsi a Team Foundation Server e configurarne i
settaggi, come i gruppi, la security, i process templates, e i
tipi di file sotto source control, sia a livello server, sia a
livello di singolo progetto.
– Aggiungere e modificare work items, documenti, e librerie
di documenti all’interno di un progetto.
– Creare, lanciare e salvare query sui work items.
– Gestire le Team Build.
• Se si dispone di Visual Studio 2005 si installa
all’interno del prodotto, altrimenti installa un “guscio” di
Visual Studio 2005 che conterrà solo il Team Explorer
Excel e Project
• Sono disponibili i “managed plug-in” per
Excel e Project (2003/2007) per:
– Connettersi a Team Foundation Server.
– Creare o modificare delle liste di Work Items, anche in modalità
disconnessa.
– Gestire le proprietà di ogni singolo work item.
– Sincronizzare le modifiche locali con quelle sul server.
Tracciatura completa delle attività
• La tracciabilità delle attività attraverso i
WorkItem è completa, dalla definizione dei
requisiti fino al codice, ai test e alle build
automatizzate.
Ambienti e piattaforme
supportate da TFS
Visual Studio 2005 Team System,
Professional e Standard
Visual Studio.NET 2003, VS 6.0, Delphi,
Sql Server Management Studio, TOAD
for SQL Server, Power Builder, ecc...
• Il Team Explorer di TFS si integra nell’ambiente di VS2005
• Bisogna installarlo dal CD di TFS
• Provider MSSCCI standard che si appoggia al Team Explorer
• Richiede il Team Explorer installato
Visual Studio.NET 2003
• Si può anche usare un prodotto di terze parti che emula completamente il
Team Explorer (TeamPlain for VS2003) http://www.devbiz.com/teamplain/
Qualsiasi ambiente di sviluppo su
Windows
• Se non supporta il provider MSSCCI si può usare il Team Explorer standalone da GUI o da riga di comando
Qualsiasi ambiente su qualsiasi
piattaforma
Direttamente attraverso il browser Web
• Si usa prodotto di terze parti (TeamPrise) utilizzabile da GUI o riga di
comando su tutte le piattaforme – www.teamprise.com
• Si usa prodotto di terze parti chiamato TeamPlain Web Access da
installare sul Team Foundation Server - http://www.devbiz.com/teamplain/
Altri plug-in
• Plug-in per Outlook:
– TeamLook
– Altri due plug-in disponibili gratuitamente
• Plug-in per Word per gestire i WorkItem
legati ai documenti:
– TeamWord
– TeamSpec
Domande?