Skinner's Blog : UML

Custom Toolbox Items

camerons — Thu, 22 Oct 2009 22:52:48 GMT

[NOTE: This post is part of a blog series, the start of which is here.]

When defining layer diagrams for your organization, or various other modeling concepts and diagrams that you want to make available to your team, you can of course simply check in those diagrams to your version control system, such as Team Foundation Server. But another mechanism we have enabled in the product that can easily be overlooked is the ability to create custom toolbox items from existing diagrams ( UML or Layer ), and then make those available through the VSIX mechanism also new in Visual Studio 2010.

In this post, I’m going to walk you through the steps needed to create a couple different custom toolbox items. ( I’ll talk about the new VSIX capabilities in another post. )

Let’s create a Layer Diagram ( I discuss the basics of what the Layer Diagram is about here ) that can be used as the pattern for a new toolbox item that will appear whenever a Layer Diagram is present in the VS document well.

1) Select the “Architecture->New Diagram…” menu item.

2) Select the “Layer Diagram” in the Add New Diagram dialog, and give the diagram the “PresentationLayer” name:

3) If you are following along exactly, this will prompt you for the name of a new modeling project. Let’s give the project the name of “CustomToolBoxItems”:

Cool. Now the new layer diagram and modeling project show up inside Visual Studio.

What we’re going to do now is replicate a layer diagram that is found in the second edition of the Patterns & Practices Architecture Guide. Specifically, the layer diagram described in Chapter 6: Presentation Layer Guidelines.

4) Create the following layer diagram:

Tips & Tricks, plus a Beta2 BUG ALERT:

I cut a quick video to include with this post to show a couple of suggestions / tips on how to quickly build the diagram above, as well as call out some funky behavior in the Beta2 build that has since been corrected. Here’s that video.

One thing I failed to mention in the video is that you can navigate in and out of nested layers by holding the Shift-> to get the tab to go to inner layers, and Shift-< to go to containers.

5) Save the PresentationLayer.layerdiagram

At this point, you need to create a directory in your %userprofile%\my Documents\Visual Studio 2010 directory.

6) Start a command prompt and cd to %userprofile%\my Documents\Visual Studio 2010

7) Create a directory called “Team Architecture”

8) cd into the “Team Architecture” directory and create another directory called “Custom Toolbox Items”

9) Copy your “PresentationLayer.*” files from your modeling project to the “Custom Toolbox Items” directory.

Here’s an image of my command line actions of steps 5-9:

Ok, we’re almost there. Before we exit Visual Studio, do take notice of the current toolbox window, which should look something like this:

10) Exit and then restart Visual Studio, and create a new modeling project.

11) Create a new layer diagram

Once the new layer diagram is visible, your toolbox should look something like this:

At this point, you can select the “PresentationLayer” toolbox item and drop into your new layer diagram. You should see the exact same diagram that we created in the step 4!

Now this is great, but we also give you the ability to control how these new toolbox items are displayed and organized. Enter the .tbxinfo file.

12) Create a file called “MyCustomItems.tbxinfo” in the “Custom Toolbox Items” directory we created in step 8.

13) Open that file in Visual Studio, and paste the following code:

<?xml version="1.0" encoding="utf-8" ?>
<customToolboxItems xmlns="http://schemas.microsoft.com/visualstudio/2010/TeamArchitect/CustomToolboxItems">
<customToolboxItem fileName="PresentationLayer.layerdiagram">
    <displayName>
      <value>Presentation Layer Pattern</value>
    </displayName>
    <tabName>
      <value>Patterns & Practices</value>
    </tabName>
    <image>
      <bmp fileName="cloudservice.ico"/>
    </image>
    <f1Keyword>
      <value>PLayerHelp</value>
    </f1Keyword>
    <tooltip>
      <value>Create the Presentation Layer As mentioned In Pattern And Practices' Architecture Guidance v2</value>
    </tooltip>
</customToolboxItem>
</customToolboxItems>

Once you save that file, exit Visual Studio, open a modeling project and open a layer diagram, you’ll see the following:

NOTE:

As you play around with these custom tool box items, it is possible that you’ll start to see toolbox items from past experiments. If you start to see things your aren’t expecting, right click in the toolbox and select “Reset Toolbox”:

That’s it! You can experiment with adding more custom toolbox items created by using layer diagrams, and you can do the exact same thing with any of the UML diagrams as well. This is a great way to get started with Design Patterns or any other template you’d like to make more accessible with your engineering team.

Enjoy!

Cameron

[NOTE: This post is part of a blog series, the start of which is here.]

UML Request For Information

camerons — Tue, 16 Dec 2008 10:21:39 GMT

As you undoubtedly know by now, Microsoft joined the OMG a couple months back. Our own Steve Cook has been representing Microsoft at a number of OMG meetings, the latest occurring last week in Santa Clara. Coming out of that last meeting is a new Request For Information ( RFI ) for UML, found here. An OMG RFI is basically a formal request designed to elicit feedback around a particular issue. In this case, about UML itself, how you use it today, how you'd like to use it, etc. For example, here are some questions in that RFI:

For what purposes does your organization currently use UML?
What parts of UML do you use (e.g. what diagrams)?
What is preventing your organization from getting more value from UML?
For what purposes would your organizations like to use UML in the future?

This RFI is targeting any and all users of UML, or people who are looking to use UML in the future. Please take the time to review this RFI and respond if at all possible. The gist of this RFI is "Hey folks, how can the OMG make the UML better?"

If you are not interested in sending a formal response to the OMG, then at least send some comments to me.

Thanks!

Cameron

The UML Model Explorer

camerons — Mon, 01 Dec 2008 12:23:46 GMT

In the VSTS 2010 Architecture product, we've added another toolwindow to VS designed to help you understand and manipulate the UML models that you will be building. The UML Model Explorer ( that's what we're currently calling it, but that can certainly change :) ) is a WPF component that represents the UML Package hierarchy of your models. "Models" in this context refer to the contents of the Modeling projects you have created and added to the current solution. The root node or nodes of the UML Model Explorer are UML packages representing those Modeling Projects.

For example, in the image below, I have created two Modeling Projects, "My First Modeling Project" and "My Second Modeling Project". You'll notice that the UML Model Explorer has two corresponding nodes in the tree.

You might immediately be asking yourself "What's up here? Why show this same information in two tree controls?" The reason will become more clear as I continue on, but it is worth pointing out right now that the UML Model Explorer is a "logical" view over you models. The Solution Explorer is showing you the "physical" view of how those models are contained and persisted. Keep that in mind as you read on.

As I mentioned earlier, every time you create a Modeling Project, a new node will be displayed in the UML Model Explorer. That node is actually a UML package named after the Modeling Project, and serves as the root package for all modeling elements that will be serialized into the Modeling Project. Creating a Modeling Project is the only way to create a root node in the UML Model Explorer.

In the VSTS 2010 CTP, any and every element created under one of these roots is stored in the ModelDefinition.uml file found the Modeling project. In the current bits, we actually create a .uml file for every UML package created. When you intially create a Modeling Project, the UML Package that represents that project is persisted on disk in the ModelDefinition.uml file you see in the project. Every model element created in that package, except new Packages, will be stored in that same file. if you create a new Package, an additional .uml file will be created to store the data behind that package, and all its contents.

Let me drive this all home with some examples, and at the same time show some of the additional capabilities of the UML Model Explorer.

Adding Elements

I want to add a class to the "My Second Modeling Project" model. I can do that by right-clicking on that node in the UML Model Explorer, and select Add->Class.

Each time I do that, a new class will appear underneath the "My Second Modeling Project" node.

To name the class, I hover over the current name, double-click, which allows me to rename the element. ( By the time we RTM, upon adding the new class, the tool will automatically put you in rename mode, as 99% of the time, that's what you will most likely be doing after adding an element in this manner. )

Below is an image of the explorer after adding a few elements. Notice, in small light-grey text is a label that indicates what type of element the node represents.

The types of elements that can be added depend on the node you right click on. So far, I've been right-clicking on the Package node that represents the root of my model. If I right click on the class or interface element, I can add UML Attributes or Operations as well.

Here's what the explorer looks like after adding a couple Operations and Attributes:

Adding elements directly to the UML Model Explorer is great, but that is not the only way to add elements of course. As you drop new elements on diagrams, you will see those elements represented as you would expect.

For example, I'm going to create a new Logical Class Diagram in the "My First Modeling Project" project by right clicking on that project node in the Solution Explorer, selecting Add->New Item..., which brings up the "Add New item dialog", where I select "Logical Class Diagram", give it a name, and hit "OK".

I now have a blank class diagram in the document well, and my project has a new file inserted into it:

Now I drop two classes on that diagram and create a UML Association between them. Like so:

Now over in the UML Model Explorer, you'll see the two new classes underneath the "My First Modeling Project" node. You'll also notice the Association relationship also being represented:

But how did the tool know to create those new elements underneath the "My First Modeling Project" when dropping them on the diagram we just created?

By default, whenever creating any type of UML diagram in a Modeling Project, that diagram's "Linked Package" property is set to the UML package associated with the project itself. That property is used when dropping new elements to figure out what UML package the new elements should be directly contained by. So in this example, that property is set to "My First Modeling Project", as seen below:

Let's drive this home with a more complicated example, and point out a couple more features of the system while we're at it.

First, I'm going to create three new UML Packages underneath the "My First Modeling Project" node, the results shown below:

Now remember when I mentioned that creating a new package would result in a new .uml file being added to the Modeling Project? Take a look at the Solution Explorer, and the "My First Modeling Project" node. You'll notice three new .uml files added to that project, one for each new package I added ( again, the first uml file was already there ):

Now I'm going to create three new class diagrams and associate them with the newly created packages. I do that by right clicking on the "My First Modeling Project" project node in the Solution Explorer, select "Add->New item...", select "Logical Class Diagram", and hit "OK" three times. Here's what my Solution Explorer looks like when done ( red square pointing out the new diagram files added to the project ):

I associate "LogicalClassdiagram1" to the "One" package my setting that diagram's "Linked Package" property appropriately:

I do the same thing for the rest of the diagrams, pointing "LogicalClassdiagram2" to the "Two" package, and "LogicalClassdiagram3" to the "Three" package.

Now I drop a new class onto each of the new diagrams. The UML Model Explorer looks like this:

Paste By Reference and Element Delete

One of the great things that the UML Model Explorer makes very easy is the ability to represent the same model element on numerous diagrams, simply by dragging the element from the explorer onto the diagram. Let me show you what I mean.

I am going to drag "Class1" onto the three class diagrams I just finished creating. Here's the result:

Class1 is now represented on all three diagrams.

NOTE

You'll notice in the image above that Class1 is represented on the diagrams with an elided name. Hovering over the element will show the fully qualified name. You can also widen the element to see the full name:

The reason for this is due to the fact that the diagram this shape is being displayed does not represent the same package that the model element is in. In this case, the LogicalClassDiagram3 represents the "Three" package, not the "My First Modeling Project" package which Class1 is directly owned by.

There is still only one "Class1" element in the UML Model Explorer. If I add an operation to Class1 via the UML Model Explorer, that operation will immediately be displayed in the Class1 on each diagram. This is because the shapes on each of those diagrams is essentially a view into the model data that is Class1. Changing the Class1 model data, which is exactly what changing that data in the Model Explorer does, results in the views of that data also changing.

And of course, adding a new Attribute to any of the Class1 shapes ( also called "Presentation Elements" ) results in the Class1 model data being updated, which updates all the other shapes, and so on.

Dragging from the UML Model Explorer is the most straight forward way of creating "references" back to the model data, but so is copying a shape and selecting "Paste By Reference" in the context menu.

Now deleting one of the shapes results in the shape being deleted, *not* the model element itself. So if I delete Class1 from LogicalClassDiagram1, nothing happens except that shape is removed from that diagram. Class1 is still present in the UML Model Explorer.

If I right click on Class1 and select "Delete", the model data is destroyed, along with all the shapes representing that element:

Summary

I hope that gives you a good taste of what the UML Model Explorer is all about. They key takeaway that I'm hoping you'll walk away with is that the UML Model Explorer is the logical view of the model repository contained by the Modeling Project. It represents data that can be displayed across numerous diagrams. That data can be manipulated directly via the explorer or through manipulation of presentation elements.

By the time we RTM, we hope to have a number of other facilities plugged into the UML Model Explorer, such as:

Ability to represent Diagrams directly in the explorer
Double click elements in the explorer will navigate to the diagram that element is represented on. If represented on many diagrams, you will be presented with a dialog allowing you to select which diagram to navigate to.
Support for moving elements between packages inside the explorer
Filtering of the explorer

As usual, would love to hear your feedback!

RadioTFS Broadcast

camerons — Thu, 16 Oct 2008 18:15:15 GMT

I had the opportunity to sit with the guys at RadioTFS and talk about the good stuff coming in the Architecture Edition in VSTS 2010. Check it out!

Microsoft joins the OMG

camerons — Thu, 11 Sep 2008 02:45:57 GMT

Today we've announced the fact that Microsoft has joined the OMG. Please see the press release here.

We're very excited about making this step. We are very interested in participating in future efforts that further the effectiveness of the UML as a collaboration and communication vehicle used throughout an organization. Our own Steve Cook will be participating in next weeks OMG meeting in Orlando.

This move is one of many in Microsoft's push to make modeling and model-driven technologies more prevalent to a broader range of people. In this particular case, the need for our tooling to interop in a much more direct way via the industry standard that is UML will be a great boon for our current and future customer base.

We've already released an early CTP that shows the start of this effort, and if you attend next month's PDC, you'll see a whole lot more! I will be giving a talk entitled:

"Rosario": A Sprint with the Next Version of Microsoft Visual Studio Team System

where I will be showing many of the great things we will be delivering Team System all-up, including the latest bits around our UML and visualization designers.

Hope to see you there!

DSL + UML = Pragmatic Modeling

camerons — Wed, 25 Jun 2008 08:33:41 GMT

There has been some speculation in the press recently around Microsoft's commitment to DSLs now that we are planning on supporting five UML 2.1 diagrams in the Rosario release ( Class, Use Case, Component, Sequence, and Activity diagrams ). Specifically, some articles have been written in a way to lead the reader towards a perception that Microsoft is moving away from DSLs and towards UML. Not at all correct! I wanted to take a moment and set the record straight on this, and start a broader conversation.

Let me first start by making one thing very clear: Microsoft is very committed to our DSL strategy, and in particular to the DSL toolkit that ships as part of the VS SDK. In fact, our UML designers are built on top of that toolkit.

I believe that supporting both approaches to modeling gives developers and Architects alike the "right tool for the right job". For those folks who want to analyze and design their architecture using a standard notation that does not imply an implementation decision, use some UML diagrams. UML is great for describing higher level concepts and for defining the initial glossary that can be used to describe the concepts necessary to facilitate broader communication. For those folks who have decided on an implementation strategy, and do not want to be encumbered by the more general nature of the UML to describe that implementation choice, use DSLs.

In the coming months, you will very likely hear me or others on the team talk about using UML at the "logical" layer and DSLs at the "physical" layer. We are really trying to promote a clean separation between the two approaches, while at the same time, attempt to maintain an understanding of how one can inform the other, and vice versa. In this way, we are hoping to more cleanly support the understanding and intent behind the models at each layer.

So this is not a "DSL vs. UML" conversation. This is a "DSL + UML" conversation. And more importantly, this is about meeting our customers where they are and giving them tools that allow them to get to where they need to be.

The true innovation in this space is going to be how we can seamlessly connect the two approaches, and how we can make modeling more central to a broader range of people.

Stay tuned. :)

Cameron