Meer en meer krijgen we binnen software ontwikkeltrajecten de behoefte aan voorspelbaarheid, standaardisatie en snelheid. Het is niet voor niets dat Application Lifecycle Management (ALM) binnen de IT industrie steeds populairder wordt en de Microsoft ontwikkel tools steeds meer ondersteuning bieden voor op dat ALM. Eén van de aspecten hierbij is het op een zo eenduidige manier beschikbaar stellen van kennis aan het ontwikkelteam en het zoveel mogelijk wegnemen van handmatige, foutgevoelige en tijdrovende activiteiten. Microsoft heeft met haar Software Factories initiatief getracht invulling te geven aan de behoefte aan een geformaliseerde aanpak die helpt bij het identificeren, verzamelen, groeperen maar vooral bij het beschikbaar stellen van kennis, ‘proven practices’ en half fabricaten tijdens het software ontwikkelingsproces. Het is op dat vlak echter de laatste tijd stil geweest. Hierin is met de komst van “Feature Builder” verandering in gekomen.
Wat is Feature Builder?
Feature Builder is een Power Tool voor Visual Studio 2010 die helpt bij het ontwikkelen van Visual Studio Extensions. Visual Studio, en zeker Visual Studio 2010, is een omgeving die in hoge mate uitbreidbaar is. De extensibility architectuur Visual Studio 2010 is sterk verbeterd t.o.v. eerdere versies van Visual Studio en is gebaseerd op het Managed Extensibility Framework (MEF). Daarnaast is er een nieuw deployment formaat ontwikkeld, genaamd VSIX, dat het eenvoudiger maakt Visual Studio Extensions uit te rollen en te beheren. De Visual Studio Extensions die met behulp van Feature Builder ontwikkeld worden, noemt men Feature Extensions en zijn bedoeld om ontwikkelaars en/of architecten te helpen bij het standaardiseren en versnellen van hun softwareontwikkeling activiteiten. Feature Builder is eigenlijk zelf een Feature Extension die ontwikkelaars helpt bij het ontwikkelen van Feature Extensions!
Zoals we in figuur 1 kunnen zijn krijgen we na de installatie van Feature Builder de beschikking over twee nieuwe project templates. Op basis van deze templates wordt er binnen Visual Studio een complete Solution structuur aangemaakt die nodig is om Feature Extensions te ontwikkelen. We kunnen kiezen tussen twee soorten Feature Extensions, namelijk een “Standard” Feature Extension en een “Ultimate” Feature Extension. Met de eerste variant kunnen we Visual Studio Extensions bouwen die bestaan uit custom tools, code (generatie), templates en Process Guidance. “Standard” Feature Extensions kunnen gebruikt worden in Visual Studio 2010 Professional en alle hogere (duurdere) versies. “Ultimate” Feature Extensions bieden naast de onderdelen van een “Standard” Feature Extension ook de mogelijkheid om tools te maken die gebruik maken van het Modeling Platform in Visual Studio 2010 Ultimate. Denk hierbij bijvoorbeeld aan een Feature Extension die gebruik maakt van de UML diagrammen of daar zelf een uitbreiding op biedt. Ultimate Feature Extensions kunnen alleen gebruikt worden in Visual Studio 2010 Ultimate.
Figuur 1. Feature Builder Project Templates in Visual Studio 2010.
Process Guidance
Veel software ontwikkeling projecten vinden nog iedere keer zelf het wiel uit. Kennis die opgedaan wordt tijdens het project gaat verloren aan het einde van het traject en blijkt bovendien moeilijk overdraagbaar te zijn. We verwachten dat de opgedane kennis “automatisch” meegenomen wordt naar volgende projecten maar vaak blijkt dat dit niet het geval is, zeker niet als de samenstelling van het projectteam veranderd. Kortgezegd, kennis die aanwezig is bij individuen binnen de organisatie blijkt gewoon lastig toegankelijk te maken voor anderen. Feature Builder probeert dit probleem op te lossen door ons in staat te stellen kennis en proven practices beschikbaar te stellen binnen de Visual Studio IDE. Eén van de manieren waarop Feature Builder dit doet is m.b.v. Process Guidance.
Onder Process Guidance verstaan we een set aan elkaar gerelateerde “Actions” die samen de stappen vormen die we moeten uitvoeren om tot het beoogde resultaat te komen. Deze Actions kunnen aangevuld worden documentatie waarin beschreven wordt op welke manier de activiteit uitgevoerd dient te worden. Tussen de verschillende Actions in de Process Guidance zit een bepaalde volgordelijkheid en we kunnen voor iedere Action zogenaamde pre- en post condities definiëren die bepalen op welke momenten een Action al dan niet uitgevoerd kan worden. Deze condities bepalen de status van de Actions die kan variëren tussen “Enabled”, “Blokked” of “Completed”. Met behulp van deze Process Guidance kunnen we een gebruiker van de Feature Extension dus gecontroleerd door een bepaald proces en/of workflow leiden. Daarnaast kunnen we hem bij iedere stap die hij uitvoert voorzien van de op dat moment belangrijke informatie, standaarden en richtlijnen.
Iedere Feature Extension kent zijn eigen Process Guidance die samengesteld kan worden met behulp van een UML Activity diagram. Om het standaard UML Activity diagram binnen Visual Studio geschikt te maken voor het definiëren van Process Guidance, gebruikt Feature Builder UML Profiles waarmee het mogelijk wordt om uitbreidingen te maken op de standaard UML diagrammen. In figuur 2 kunnen we zien hoe we de Process Guidance voor een Feature Extension samenstellen. We zien dat we aantal stappen (“Actions”) hebben gedefinieerd in het Activity diagram en dat er een bepaalde volgordelijkheid is aangebracht tussen de Actions. Ook zien we dat het mogelijk is om te definiëren dat bepaalde Actions parallel uitgevoerd kunnen worden binnen de Feature Extension.
Figuur 2. Activity diagram waarbinnen de Process Guidance wordt gemodelleerd.
Nadat we klaar zijn met het samenstellen van de Process Guidance wordt bij het opslaan van het Activity diagram de benodigde code gegenereerd die de Process guidance op runtime aan de Feature Extension gebruiker toont. In figuur 3 zien we hoe de Process Guidance, zoals we die in figuur 2 gemodelleerd hebben aan de gebruiker wordt getoond in de “Guidance Workflow Explorer”. Dit nieuwe tool Window toont alle Actions uit de Process Guidance en geeft de status van de Actions aan door middel van een vierkantje voor de Action in de kleur groen, rood, of grijs. Actions die met groen worden aangegeven, kunnen op dit moment uitgevoerd worden, rode actions zijn niet uitvoerbaar en hebben de status “Blokked” en grijze Actions zijn afgerond. We zien dat stappen één en twee uit figuur 3 zijn afgerond. Stappen drie en vier hebben beiden de status “Enabled” omdat hun voorgangers afgerond zijn en ze parallel uitgevoerd mogen worden. Stap vijf heeft de status “Blokked” omdat deze stap pas uitgevoerd mag worden nadat stap drie in de Process Guidance afgerond is.
Figuur 3. De Guidance Workflow Explorer.
De status van een action kan worden veranderd door het checkboxje voor de action aan te passen. Dit is een handmatige handeling die de gebruiker van de Feature Extension zelf moet uitvoeren, het is echter ook mogelijk dit geautomatiseerd te laten doen d.m.v. zogenaamde “Conditions” die we later nog zullen bespreken.
Zoals al eerder is gezegd kunnen we aan iedere Action gedetailleerde informatie koppelen of de uitvoering van de Action. Deze informatie wordt vastgelegd in zogenaamde “Guidance Documents” dat eigenlijk gewone MS Word documenten en/of web pagina’s op het internet zijn. Zodra de gebruiker van de Feature Extension op een Action in de Guidance Workflow Explorer klikt wordt het bijbehorende Guidance Document getoond in de “Guidance Browser”. In figuur 3 zien we het Guidance Document, dat behoort bij stap één uit de Process Guidance.
Automation
Naast Process Guidance biedt een Feature Extension ook mogelijkheden voor Visual Studio Automation. Met behulp van deze Automation kunnen we bijvoorbeeld veel voorkomende en/of foutgevoelige ontwikkeltaken vereenvoudigen, versnellen of zelfs helemaal weg automatiseren. Denk hierbij bijvoorbeeld aan het opzetten van een complete Visual Studio Solution structuur, het genereren van source code op basis van een T4 template of het starten van een Build. De bouwblokken die we gebruiken bij het implementeren van Automation binnen een Feature Extension zijn “Feature Commands” en “Value Providers”.
Feature Commands
Alle acties die we automatisch willen laten uitvoeren, kunnen we zelf programmeren in een zogenaamde “Feature Command”. Een Feature Command is een normale .NET class die overerft van de “FeatureCommand” class uit de Feature Builder library. Een groot voordeel van Feature Builder is dat het gebruik maakt van Management Extensibility Framework (MEF). Hierdoor wordt het erg eenvoudig om een referentie te krijgen naar een aantal belangrijke Visual Studio services. In figuur 4 zien we een voorbeeld van een Feature Command. In dit geval voegt de Feature Command een nieuwe Solution Folder toe aan de actieve Visual Studio Solution. Het is duidelijk te zien hoe we met behulp van MEF een “Import” doen van de Visual Studio Service Provider die we vervolgens gebruiken om en referentie te verkrijgen naar de “DTE” instantie waarmee we in principe heel Visual Studio mee kunnen besturen.
Figuur 4. Voorbeeld van een Feature Command.
Feature Commands worden binnen een Feature Extension geactiveerd door zogenaamde “Launch Points”. Binnen Feature Builder kennen we vier soorten Launch Points, namelijk: “Visual Studio”, “Modeling”, “Link” en “Template” Launch Points. Met behulp van een Visual Studio Launch Point voegen we eenvoudig een custom menu item toe aan de standaard Visual Studio menu bar of aan items in de Solution Explorer. Met behulp van een Modeling Launch Point kunnen we een menu item toe voegen aan een Model Element in de standaard UML diagrammen van Visual Studio 2010. Let op, deze optie is alleen beschikbaar als we een Ultimate Feature Extension ontwikkelen! Met behulp van een Link LaunchPoint kunnen we een Feature Command activeren vanuit een Guidance Document dat getoond wordt in de Guidance Browser en een Template LaunchPoint gebruiken we als we een Feature Command willen uitvoeren vlak voor of vlak na de “Unfold” van een project template.
Net als bij het samen stellen van de Process Guidance zien we dat Feature Builder ook voor het toevoegen van Feature Commands en de koppeling daarvan met Launch Points gebruikt maakt van een DSL. Figuur 5 laat zien dat we gebruik maken van een Modeling Launch Point om een nieuw menu item toe te voegen met de caption “MyCustomMenu” aan het “Class” model element in het UML Class diagram. We kunnen ook zien dat dit Launch Point is gekoppeld aan het Feature Command “Show Message”. Als we de DSL opslaan wordt automatisch de benodigde code gegenereerd die er voor zorgt dat er een extra menu beschikbaar is op het Class element in het UML Class diagram. Dit menu item toont een MessageBox met daarin de boodschap die we gespecificeerd hebben bij het “Show Message” Feature Command.
Figuur 5. Feature Commands worden gekoppeld aan LaunchPoints.
ValueProviders
Een Feature Command heeft over het algemeen bepaalde informatie nodig om zijn taak te kunnen uit voeren. Zo heeft bijvoorbeeld de “AddSolutionFolder” Feature Command uit figuur 4, de naam nodig van de Solution Folder die aan de Solution dient worden toegevoegd. De manier om de naam van de Solution Folder te specificeren is door er een public property voor aan te maken op het Feature Command. Alle public properties op het Feature Command verschijnen namelijk automatisch in het Property Window van Visual Studio. In theorie is het daarmee mogelijk de property tijdens het ontwikkelen van de Feature Extension een “hard coded” waarde te geven. In de praktijk zullen we echter zien dat we dergelijke informatie op runtime willen bepalen en/of de gebruiker van de Feature Extension de mogelijkheid willen geven deze informatie zelf in te geven. Hiervoor kunnen we gebruik maken van “Value Providers”. Met behulp van een Value Provider kunnen we informatie verzamelen, door bijvoorbeeld de Feature Extension gebruiker een wizard te laten doorlopen, en deze informatie door te geven aan de Feature Command. In figuur 6 zien we dat de public property “FolderName” (van de Feature Command uit figuur 4) verschijnt in het Property Window van Visual Studio 2010. We zien dat we hier een “hard coded” waarde in kunnen geven (Value) of kunnen kiezen voor een Value Provider die bijvoorbeeld een Window toont waarop de gebruiker de naam van de Solution Folder kan invoeren.
Figuur 6. Property Grid met daarin de properties van Feature Command.
Conditions
We hebben eerder al gezien dat we aan alle Actions in de Process Guidance van de Feature Extension pre- en post “Conditions” kunnen toevoegen. Standaard (en impliciet) heeft iedere Action de “My predecessor must be complete” Condition wat betekent dat de Action pas de status “Enabled” krijgt als de voorgaande Action is afgerond. Ook voor Conditions geldt dat we deze relatief eenvoudig zelf kunnen schrijven. Als we meerdere Conditions toevoegen aan de lijst van pre-Conditions dan bepalen deze samen of de Action uitgevoerd mag worden of niet. Conditions die toegevoegd worden aan de post- Condition lijst bepalen gezamenlijk of aan alle voorwaarden is voldaan om de Action naar de status “Completed” te zetten.
‘Out of the box’ komt Feature Builder met een zeer beperkt aantal Feature Commands, Value Providers en Conditions. Meer Command, Providers en Conditions zijn te vinden in het “Feature Builder Contrib” project op Codeplex.
Overwegingen voor Feature Builder
Hierboven hebben we in een notendop gezien wat de mogelijkheden zijn van Feature Builder. Wat echter nog niet aan bod is gekomen, is de vraag: in welke situaties is het verstandig gebruik te maken van Feature Builder? Een veel gehoorde kanttekening bij het ontwikkelen van Visual Studio Extensions met bijvoorbeeld Feature Builder, is de angst voor het nemen van een ‘dependency’ op een tool van Microsoft die niet hetzelfde support model en/of gegarandeerde levensduur heeft als Visual Studio zelf. Feature Builder is ontwikkeld door de Visual Studio Product Group in samenwerking met Microsoft patterns & practices, is gebaseerd op de vele nieuwe extensibility mogelijkheden van Visual Studio maar heeft “slechts” de status van Power Tool. Hoe zeker zijn we er van dat Feature Builder ook nog beschikbaar is in de volgende versies van Visual Studio? Kunnen we de investering die we doen in het maken van Visual Extensions terug verdienen? Uiteraard zijn dit valide vragen en dienen we rekening te houden met dergelijke scenario’s, maar aan de andere kant…
Hoewel het in eerste instantie aantrekkelijk lijkt een Feature Extension te ontwikkelen die helemaal bol staat van Visual Studio Automation is dit waarschijnlijk niet de meest verstandige keuze. Het belangrijkste doel dat we met een Feature Extension proberen te bereiken is het vast leggen en op een eenvoudige manier beschikbaar maken van een werkwijze, kennis, proven practices en standaarden. Als we werkwijze hebben gedefinieerd en we hebben onze aanvullende kennis en richtlijnen vastlegt in de eerder genoemde Guidance Documents (Word document) dan is deze informatie ook vrij eenvoudig bruikbaar te maken zonder Feature Builder. Dit is juist één van de redenen om binnen Feature Builder te kiezen voor Word en web pagina’s als bron voor Guidance Documents. De investering die gemaakt dient te worden in bijvoorbeeld het verzamelen van kennis staat dus los van Feature Builder. Feature Builder biedt echter als voordeel dat deze informatie integreert in Visual Studio, beschikbaar komt op het moment dat dit nodig is en dat we de mogelijkheid hebben een aantal ontwikkelwerkzaamheden geautomatiseerd uit te laten voeren.
Ook dienen we er voor te zorgen dat we niet maandenlang aan een Feature Extension ontwikkelen die vervolgens één keer gebruikt kan worden op een project van twee weken. In dat geval is de investering in de Feature Extension waarschijnlijk niet te verantwoorden. Het is de kunst om de juiste mix te vinden tussen het leveren van guidance, automation, de investering die het kost om een Feature Extension te ontwikkelen en het resultaat dat er mee behaald wordt. Om deze reden is het waarschijnlijk verstandiger kleine Feature Extensions te ontwikkelen, die een (relatief) kleine investering vragen en snel een toegevoegde waarde aan het ontwikkelproces bieden. Feature Extensions zijn gewone VSIX packages en zijn daarom te beheren vanuit de Visual Studio Extension Manager. Hiermee behoren de beheerproblemen van Guidance Packages die velen van ons nog kennen uit de het tijdperk van de GAT/GAX tot het verleden!
Links:
Feature Builder download: http://visualstudiogallery.msdn.microsoft.com/en-us/396c5990-6356-41c0-aa20-af4c3e58c7ae
Feature Builder Contrib project: http://fbcontrib.codeplex.com/