Alternate Image in Diagrams
For communication with higher level audience you can change default images in the VSTA 2010 diagrams.
Getting App Arch Guid Knowledge in VSTS2010 – Part3 Create Diagrams from Code
The (experimental) journey of getting App Arch Guid Knowledge in VSTS2010 with Edward continuous…
previous steps…
- The VSTA Layer Diagram and the P^P App Arch Guide 2.0.
- Blueprints: Visual Studio 2010 CTP
In this step as promised in part 1 ‘Create Diagrams from Code’.
I used VSTemplate and the IWizard interface for the first solution, but now we have the Blueprints available in VSTS2010 we better can use that functionality to create the diagrams. For this post it actually doesn’t matter what you use as long as you can access the Visual Studio automation object model [DTE].
The steps you have to take.
- Get and Load the Model and Diagram.
- Get the Store and start a transaction.
- Create the shape.
- Create the ModelElement and associate it with the shape.
- Add the combination to the design surface [diagram].
- Add child's [nested shapes] if necessary.
- create the dependencies.
- commit the transaction.
- save the model and diagram.
In more detail.
Step 1. Get and Load the Model and Diagram.
1: LayerModel layerModel = LoadModel(dte.ActiveDocument.FullName);
2:
3:
4: private LayerModel LoadModel(string fileName)
5: {
6: LayerModel currentLayerModel = null;
7: Store store = new Store();
8: Type[] modelTypes = new Type[]
9: {
10: typeof(CoreDesignSurfaceDomainModel),
11: typeof(LayerDesignerDomainModel)
12: };
13: store.LoadDomainModels(modelTypes);
14: using (Transaction t = store.TransactionManager.BeginTransaction("Reading diagram"))
15: {
16: currentLayerModel = LayerDesignerSerializationHelper.Instance.LoadModelAndDiagram(store, fileName, fileName + ".DIAGRAM", null, null);
17: t.Commit();
18: }
19: return currentLayerModel;
20: }
line number 1 is the calling method to the loadmodel function and as you can see i open / load the current in visual studio activated document, you can grab any diagram file. the first thing to look for [using reflector] are the modeltypes when loading a different kind of model. because i not only want add modelelements but also want to control the place of the shape on the design surface i have to loadmodelanddiagram. the .diagram file has knowledge of the position and the .layer file of the modelelements.
Before I forget it the usings are a bit tricky in this ctp. you have to add a reference to “microsoft.visualstudio.modeling.sdk.10.0” and “microsoft.visualstudio.modeling.sdk.diagrams.10.0” [and some more]. the problem is that these aren’t visible in the add reference dialogbox. so, you have to add these manually by adding them in the csproj file.
1: <Reference Include="Microsoft.VisualStudio.Modeling.Sdk.10.0, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
2: <Reference Include="Microsoft.VisualStudio.Modeling.Sdk.Diagrams.10.0, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
the other references […teamarchitect.layerdesigner and …teamarchitect.layerdesigner.dslpackage] you need can be found in ..\..\program files\microsoft visual studio 10.0\common7\ide\privateassemblies\
Step 2. get the store and start a transaction.
1: Store store = layerModel.Store;
2: using (Transaction t = store.TransactionManager.BeginTransaction("Draw diagram"))
and now we can start to create shapes and place them on the designsurface.
Step 3 and 4. Create the shape, modelelement and combine them.
1: LayerShape layerShape = new LayerShape(store, null);
2: Layer layer = (Layer)store.ElementFactory.CreateElement(Layer.DomainClassId);
3: layer.Name = name;
4: layerShape.Associate(layer);
set some visual properties of the shape, you can completely tweak the looks of the shape.
1: layerShape.AbsoluteBounds = new RectangleD(0.5, 0.5, 7, 2.375);
2: layerShape.FillColor = Color.DarkOrange;
repeat this for all the layers you want to create… and after that
Step 5 and 6. Add them to the Model and Diagram and – or create nestedchilds.
1: diagram.NestedChildShapes.Add(layerShape);
2: layerShape.NestedChildShapes.Add(uiProcessComponentsShape);
3: LayerHasChildLayers child = new LayerHasChildLayers(PresentationPair.LayerPart, uiComponentsPair.LayerPart);
You have to tell the Model and the Diagram that they are nested… if you tell it only to the Diagram [visual layout] they look like if they are nested but in the Layer Diagram Explorer you can see they aren’t.
Step 7. Create the dependencies.
1: DependencyFromLayerToLayer dep = new DependencyFromLayerToLayer(PresentationLayer, CrossCuttingLayer);
Step 8 and 9. Commit transaction and Save the Model and Diagram.
1: t.Commit();
2: }
3: SerializationResult result = new SerializationResult();
4: LayerDesignerSerializationHelper.Instance.SaveModelAndDiagram(result, layerModel, dte.ActiveDocument.FullName, diagram, dte.ActiveDocument.FullName + ".DIAGRAM");
Conclusion.
There is one big drawback with this solution. Because I load the model and diagram from a file, change it and save it back to the two files, Visual Studio recognizes that they are changed outside the IDE and popup a message [two times] if you want to reload it. Not something you want. A solution for this could be the Backplane. Edward did some early investigations around the backplane last year and the layer diagram is connected to the Backplane [not all VSTA diagrams are]. So, that would solve the reload problem. But, that’s something for another post… first Merry Christmas and a Happy New Year everyone, till next year..!
How To Collect Data from the Application Diagram to create WSSF Service Models
Post #02 of a collection of posts with some more technical details about the creation of richer implementations with Visual Studio Team Architect.
This is post 1: How To Fire a Guidance Package Recipe from the Implement Application Feature of Team Architect.
[Dynamic System, Lorenz attractor]
First you have to understand System Definition Model (SDM).
SDM is part of the overall Dynamic Systems Initiative (DSI) from Microsoft.
The Dynamic Systems Initiative (DSI) is a commitment from Microsoft and its partners to help IT teams capture and use knowledge to design more manageable systems and automate ongoing operations, resulting in reduced costs and more time to proactively focus on what is most important to the organization. The System Definition Model (SDM) is a key technology component of the DSI product roadmap that provides a common language, or meta-model, that is used to create models that capture the organizational knowledge relevant to entire distributed systems.
Quote from System Definition Model Overview White Paper.
Dynamic Systems Initiative also contains ideas like Application Lifecycle Management, Microsoft Infrastructure Optimization Model and the just released V2 version of the Design For Operations Models [full name: Visual Studio Team System Management Model Designer Power Tool].
Often you here the term Service Modeling Language (SML) in relation with SDM, the SML Insight blog gives some explanation.
The model-based management functionality in Windows Server 2008 is based on Microsoft's System Definition Model (SDM) version3, which provided the basis for the Service Modeling Language (SML) proposal and submission to the World-Wide Web Consortium SML Working Group.
I'm curious how the DSI initiative and SDM / SML are going to evolve with Oslo and with that how Team Architect is going to evolve, a nice subject for another post.
Anyway, SDM is an XML-based meta-language for distributed systems.
The SDM structure behind Team Architect.
You can split the SDM structure behind Team Architect's Distributed System Designers in two parts. One XML part responsible for the loading, structuring and displaying systems, endpoints and resources in the Distributed System Designers, the <DesignData> element [MSDN link]. The other part holds all SDM relevant information, building blocks as SDM objects, relationships, and optional additions to objects such as settings, flows, and constraints, which also has <DesignData> elements.
Best explained with an empty Application Diagram file.
The ROOT Node still named after the codename "Whitehorse", I like that ;-)... next you have a one <Solution> node with a <DesignData> element, contains information about the solution, and one <SdmDocument> with two <DesignData> elements. The first is information for the Deployment diagram the second for the design-surface, this one will contain sub-systems when we add shapes on the design surface. [see XML below]
When we add an WebService shape to the design surface we will get an extra <SdmDocument> element which contains beside <DesignData> all the configuration.
adding an endpoint to the Service will give you this XML.
So, although the structure looks a little bit overwhelming , it's easy to understand and basically you can say that there are models which contains models [The "designsurface"model has "application"models and an "application"model got "endpoints"models which also have types], all the models got <DesignData> and are described in a separate node which contains settings / properties.
Distributed System Designers Reader
Now, you only have to make some kind of Distributed System Designers Reader which collects this information for you. I made a object model [see image] and a factory method [with many XML readers] which loads the model. [started to change that to LINQ]
This last step, actually the complete post, needs to be done when you use VS2005 or VS2008 for Rosario it's much easier [see this post, Rosario Team Architect Exposed, Getting Information Out Off the Designers].
Anyway, next post generate Service Models which uses this object model.