VSTA Layer Diagram and MEF– Does my Design Smell?
Did some playing with MEF and a Smelling Layer Diagram today… it turned out to be an interesting scenario.
Some background.
There are many anti-patterns, patterns which have been proven not to work well. Anti-patterns for buildings, for collaboration, for businesses, for code and for sure for design. Some are common, like cyclomatic dependencies between components, some are more specific for a company and even every designer has some anti-patterns made for himself. Every designer, application architect or anybody else involved in designing something knows them or should know them to make a better design and finally application. So, it would be interesting to get a notification when your design SMELLS according to those generic or specific Anti-Patterns, these kind of notifications would help the design, application, business, developers, testers, operations and even better would help the learning curve for new designers/ architects.
The problem, there are to many anti-patterns as a designer you want to pick your own selection or even make your own anti-pattern notification mechanism, giving notifications, warnings at design time not at build time but at design time so you can evolve your design to a really good one.
Now MEF comes insight, actually it came insight by me this morning on the metro to the office [have to go by public transportation since I did my car away last month]. During the ride I watched a webcast about MEF and decided… that’s really cool for this Anti-Pattern scenario. Great an Add-in based on MEF which validates, analyses your design according to several Anti-Patterns and with MEF in place people can add them at will.
The User Story
I created an Add-in, see image “LayerDiagramSmell”
This Add-in has adds a Menu-Item “does my design smell..?” to the diagram [in my scenario the Layer Diagram]
When you execute this command it checks your design at several Anti-Patterns… and shows his findings in the design. I only change the name in this implementation, but it’s very easy to change colors of lines, shapes and give notifications in the “Error List” [it’s just a pilot].
Now the designer/ architect can think, maybe I have to change this implementation….
The Implementation
I already explained the making of Add-in’s for diagrams in a previous post and MEF is really easy, here is some code…
1. add a reference to System.ComponentModel.Composition.
2. get the Smells binairies
var catalog = new AggregatingComposablePartCatalog();
catalog.Catalogs.Add(new DirectoryPartCatalog(@"C:\temp\Smells"));
var container = new CompositionContainer(catalog.CreateResolver());
container.AddPart(this);
container.Compose();
3. Create the Smell Classes.
Smell1 and Smell2 put there DLL’s in the “C:\temp\smells” directory which are loaded in the container and are executed [used for analyzing the diagram].I created them in the same solution but anyone who makes a class which implements the SmellInterface and puts the assembly in the Smells directory has his own Anti-Patterns analyzer.
4. implement some logic for analyzing the diagram, this is Smell2 and a really really basic implementation [It should be better for me not to post this kind of code, anyway… it works ]
[Export(typeof(ISmell))]
public class GetSmell : ISmell
{
public List<Layer> DoesThisSmell(LayerModel layerModel)
{
List<Layer> LayersThatSmell = new List<Layer>();
foreach (Layer item in layerModel.Layers)
{
foreach (var dependencyFrom in item.DependencyFromLayers)
{
if (item.DependencyToLayers.Contains(dependencyFrom))
{
LayersThatSmell.Add(item);
}
}
}
return LayersThatSmell;
}
}
5. And finally put the Anti-Pattern information back on the diagram.
List<Layer> LayersThatSmells = ModelElementsSmell.DoesThisSmell(loadedModel);
using (Transaction t = loadedModel.Store.TransactionManager.BeginTransaction("anaylis diagram"))
{
foreach (var item in LayersThatSmells)
{
item.Name = "THIS STINKS" + item.Name;
}
t.Commit();
}
SerializationResult result = new SerializationResult();
LayerDesignerSerializationHelper.Instance.SaveModelAndDiagram(result, loadedModel, _applicationObject.ActiveDocument.FullName, diagram, _applicationObject.ActiveDocument.FullName + ".DIAGRAM");
I know not enough information to reproduce this example, but I'm curious what you think of this scenario and for sure what are your Anti-Patterns…
More on this in the future….
VSTA 2010 – UML Profiles [make your own…]
Does anyone have seen that there is the capability to attach UML Profiles to the UML Diagrams in the new CTP..?
Just take a look at the property window of the component diagram or use case diagram or any other diagram and you can see that there are 3 out of the box ‘trial’ profiles available.
You can find this ‘profiles’ property on the design surface and after selecting one [or more] profiles you get a new property on the shape named ‘Stereotypes’ with values depending on the profile you selected.
That’s it for Profiles and Stereotypes in the VSTA diagrams. It doesn’t seem that valuable at first sight, but you can do magic with it.
UML Profiles
First a brief explanation of UML Profiles, better and less time consuming a copy-past from Wiki and OMG [a little bit more fuzzy than wiki].
A profile in the Unified Modeling Language provides a generic extension mechanism for customizing UML models for particular domains and platforms. Profiles are defined using stereotypes, tagged values, and constraints that are applied to specific model elements, such as Classes, Attributes, Operations, and Activities. A Profile is a collection of such extensions that collectively customize UML for a particular domain (e.g., aerospace, healthcare, financial) or platform (J2EE, .NET).
- Identifies a subset of the UML metamodel.
- Specifies “well-formedness rules” beyond those specified by the identified subset of the UML metamodel.
“Well-formedness rule” is a term used in the normative UML metamodel specification to describe a set of constraints written in UML’s Object Constraint Language (OCL) that contributes to the definition of a metamodel element. - Specifies “standard elements” beyond those specified by the identified subset of the UML metamodel.
“Standard element” is a term used in the UML metamodel specification to describe a standard instance of a UML stereotype, tagged value or constraint. - Specifies semantics, expressed in natural language, beyond those specified by the identified subset of the UML metamodel.
- Specifies common model elements, expressed in terms of the profile.
An UML Profile for VSTA.
Why do you actually want a profile? you can add additional information to the diagrams and shapes and use this extra information for everything you can think of, just for visualization and communication but also for generation and validation.
For example the component diagram is often used for visualizing the structure [components] of the solution and the interfaces between those components. as Scot Ambler writes:
UML component diagrams are great for doing this as they enable you to model the high-level software components, and more importantly the interfaces to those components. Once the interfaces are defined, and agreed to by your team, it makes it much easier to organize the development effort between subteams.
While in UML 1.1 a component referred to files, UML 2.x describes them more as a autonomous, encapsulated unit with interfaces [see UML basics: The component diagram] which gives us a wider view what we can describe with it. But thinking of subteams, development effort, autonomous, encapsulated unit and file structures we can make a useful profile for our solution structure. Some time ago I wrote something about Autonomous Develop Services for SOA Projects with Team Architect and Service Factory, it’s about in what way you want to have your solution structure to be sure development teams [subteams] don’t interfere with each other.
So, with the component diagram you can design your solution “autonomous, encapsulated units with interfaces”. With a profile attached to this diagram, which gives these units extra meaning according to the solution structure and what kind of units they are, we have valuable information how the solution should be structured, even more interesting we can make a ‘Solution Structure Generator’ for the component diagram.
Make your own
The UML Profiles in VSTA are XML files in the “C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\UmlProfiles” folder. this is the .NET Profiles profile file. Just copy your own “.Profile” file to this folder and it will appear in the combo box [after restarting VS].
When looking at the property window the structure gets really easy clear. I selected the .NET Profiles profile at the diagram [first yellow marker] and the .NET Assembly stereotype [yellow marker] can be used with components [next yellow marker] and this stereotype has some more properties [vertical yellow marker].
So, now we know how to make a profile… or actually add some additional information to a diagram. We can make it useful create a menuitem for the diagram with some functionality that takes this additional information and creates the solution structure for you.
foreach (Microsoft.VisualStudio.Uml.Classes.ProfileInstance pi in componentmodel.ProfileInstances)
{
if (pi.Name == "Project Structure")
{
foreach (var item in elm.AppliedStereotypes)
{
switch (item.Name)
{
case "Single":
Single(componentmodel);
break;
case "Partinoned":
Partinoned(componentmodel);
break;
case "Multiple":
Multiple(componentmodel);
break;
default:
break;
}
As you can see I used the same solution structure types as described in Chapter 3 – Structuring Projects and Solutions in Source Control of the TFS Guidance from the Patterns and Practices group. [ I still like the "Partinoned" solution structure ] .
_16f93727-aa12-4b78-a748-6b2d6d5257fd.gif "Bb668953_pponline(en-us,MSDN_10)")
and some code to create the projects…
foreach (ComponentProxy cp in componentmodel.ComponentProxies)
{
Microsoft.VisualStudio.Uml.Classes.Element elm = cp as Microsoft.VisualStudio.Uml.Classes.Element;
if (cp.AppliedStereotypes[0].PropertyInstances[3] != null)
{
projectype = cp.AppliedStereotypes[0].PropertyInstances[3].Value;
}
string projectTemplate = "";
Solution2 soln = (Solution2)vsApp.Solution;
System.IO.FileInfo fi = new System.IO.FileInfo(soln.FileName);
string solutiondirectory = fi.Directory.FullName ;
switch (projectype)
{
case "ASP.NET Web Application":
projectTemplate = soln.GetProjectTemplate("WebApplicationProject.zip", "csproj");
break;
Final Notes.
The profile and the use of the profile used in the ‘solution structure’ example has some value, although if you want to use it in the real world it would probably more complex with regeneration, versioning and that kind of things. But that we can add, by using a very simple mechanism, additional information to the diagrams is a very powerful extensibility mechanism. Scenarios like, using a Data Modeling UML Profile for logical modeling and upgrade this model to the physical level with the Entity Framework are very interesting and I need stereotypes for the Usecase diagrams to implement the estimation scenario.
More on this in the future…