VSTS 2010 Architecture: [Part One] Model Project

In my last post, I began talking about the logical structure of the VSTS 2010 Architecture product. I now want to start drilling into the various areas I outlined in that post. In this post, I want to start going deeper in the "Team Collaboration" area, specifically talking about some details around the new project type we've created, currently called ( amazingly enough ), the "Modeling Project".

This new modeling project will be container for modeling data, diagram files, and any other artifacts that you'd like to store ( such as Word docs for instance ). The new project can be inserted into any existing or new solution you would like to create, and can sit happily along with your other projects ( C# / VB / Web, etc. ), and can be version controlled just like any other project.

Let me give you taste of some of the details.

Modeling Project

In the 2010 CTP, you will see a new project template when you go to create a new project in Visual Studio, as seen in the figure below.

Clicking on the OK button results in a new modeling project inside the Visual Studio Solution Explorer:

Inside the "ModelDefinition" folder is a file called "ModelDefinition.uml". In the 2010 CTP, this file holds all the data that will represent the various UML models you will be creating later on. Let's take a look at the file right after project creation:

Obviously, an XML file whose root element is the "modelStoreModel". I'll come back to this in a moment. I want to first start to point out the changes to the file after adding one Logical Class diagram and dropping one class element on that diagram. Let's do that now.

Right click on the root of the ModelingProject2 project node, like so:

You'll be presented with the following dialog:

Let's just take the defaults, hit the "Add" button. Now our modeling project looks like this:

Now let's add one class element to the new diagram, by clicking on the "Class" tool in the Toolbox, and then dropping onto the active diagram we just created. ( See this post for other tips on how to "lock" the tool box items in order to drop many items at once ).

So now the diagram looks like this, after saving all:

Now let's look at the changes in the ModelDefinition.uml file:

You'll notice that the only thing that has changed is the addition of the class information, plus some encapsulating xml elements that I'll discuss in a later post. The bit that I want to emphasize right now is that the data found in the ModelDefinition.uml file is *only* data about the model elements themselves, and not about how those elements are presented on a diagram. You will see no positional information, no information about color, or even information that this particular element is present on the LogicalClassdiagram1 diagram. Complete separation of model data and presentation data is maintained at all times.

In the CTP bits, no matter how many model elements you create in the various UML diagrams we have in the product, you will only see this one file getting bigger and bigger in size on disk. This is *not* how we will ship. For every package element, a new file will be created and stored on disk in the ModelDefinition folder. The idea here is that this will help mitigate the likelihood of merge conflicts that can occur, once the modeling project has been version controlled. It will certainly mitigate that problem much better than everything going into one file!

So where is the presentation information housed? The diagram files themselves.

Team Collaboration

So why do I lump this new Modeling Project into the "Team Collaboration" area in my first post in this series? Because this new project will be one of the primary ways of sharing the data associated with your new models with the rest of your development organization via the version control system currently deployed.

You will of course be able to share your models with others via printing, emailing of copied diagram elements, etc., but being able to check those models into source control right along and next to the rest of the source that make up your system will be a significant productivity aid.

But what will happen if one of your developers does not have the 2010 Architecture box installed on their box? Will the solution that contains one of these modeling projects load? Will that developer be able to view the diagrams? The answer to all those questions is *yes* . The only thing the developer without the Architecture box will not be able to do is change the data behind the models they are viewing. The will be able to load the modeling project, double click and view the diagrams, select elements, look at their properties, zoom in and out on the diagram, etc. They just can't change or add model data.

Summary

The new modeling project in 2010 Architecture will house all the relevant artifacts associated with your models. It will hold the data for the models themselves, the diagrams that visualize that data, as well as other artifacts you find important enough to house inside the same project, such as word documents, power point slides, etc. That modeling project can then be version controlled and shared with the rest of your team.