In one of the articles that just hit recently around our upcoming "Architectural Validation" feature in VSTS 2010 Team Architect, there was concern around how to "maintain all those diagrams" in context of the Architectural Validation or Layer Diagram feature. I wanted to shed a bit more light on how the association between your code and the diagram is made and maintained. We have not really discussed this nearly as much as we should, other than a quick "Map your physical assets..." comment I made in step five of this post.
Basically, I want to point out that the risk of the Layer Diagram and your source getting out of synch really depends on how you choose to use the tool.
- Association with artifacts can occur in the following ways
- Link to a single artifact e.g. a class
- Out of sync risk = medium high
- Depending on the number of deletes and renames, layers linked to classes can have stale links. However, these are shown as warnings and can be cleaned up quite easily.
- Link to a group of artifacts using a container e.g. namespace
- Out of sync risk = low
- Linking a layer to a namespace indirectly links the layer to all classes in the namespace. Validation will start at the namespace and process everything in it. This indirect link allows the validation to adjust to changes to individual classes rather well.
- Namespaces themselves do not change as often.
- Link to a group of artifacts using a query
- Out of sync risk = very low
- A query links to dynamic collection of artifacts. The query is evaluated every time you validate. Hence, like the namespace example above, changes to the results of the query are automatically factored in.
- Build time validation
- The integration with builds and check ins make this feature a lot more useful and bring it to the forefront of the development process. This also has the side benefit of forcing updates if they’re required.
Wow, last week was a whirlwind! Dave Mendlen and myself spent a lot of time with our friends in the press on both coasts, and everywhere in between, talking about the next release of Visual Studio and Visual Studio Team System, now officially called "Visual Studio 2010" and "Visual Studio Team System 2010". To see the general gist of what was discussed, check out this page on MSDN, and a Team System specific one here. But again, those links just give you the high level. I'd like to point out a few more details and resources that can round out your understanding of what we are doing around here.
Brian Harry, as usual, has a great post that dips a little more into the business aspects of what 2010 is all about. Check that out.
Gert Drapers has already spent a little time talking about the fact that in 2010, we will be merging the Database Edition and Developer Edition SKUs into one box. He titles the post as "Team Developer + Team Data = Team Developer", but I think it would have been better to title that one "Team Developer + Team Data = One Great Product!".
A lot of discussion has occurred around the modeling capabilities in 2010, specifically around what the next version of Architecture Edition will contain. I wanted to point out a few Channel9 videos that goes into a bit more detail, showing bits that will be in our next CTP. I did more of an overview discussion of what the product is all about, how we are actually supporting two major scenarios in the product ( what we are referring to as "Top Down" and "Bottom Up" modeling ). See that video here. That video tees up two follow on videos which have also been posted today by Suhail Dutta and Mark Groves, Program Managers on my team.
Suhail discusses the "Bottom Up" features of our tooling. Check it out here. Suhail does a great job talking about how to product can quickly view diagrams grouped by namespace, showing dependencies between those namespaces, and how the Architecture Explorer can be used to further refine the information being displayed. He shows how easy it is to create a Sequence Diagram from existing source, simply by right clicking in the VS code editor and selecting "Generate Sequence Diagram..."! He also describes some additional refinements to the Layer Diagram and how easy it will be to incorporate Architectural Validation ( a very hot topic as we spoke with the press! ) into your MSBuild processes.
Mark takes on the "Top Down" feature of the tool, which is really hiliting the five UML diagrams that will be shipping in the box in VSTS 2010. He also gives you the first peak at our Model Explorer ( a logical view of the entire modeling store ), as well as points out the addition of a new Modeling project that will house the UML data. Check this video out here.
Enjoy!
P.S. Oh, and one more thing. The plane ride out to the east coast was a bit more "exciting" than usual. We had to make an emergency landing in Chicago! Here's some news coverage, and here's a picture I took coming off the plane. Any emergency landing where *everyone* walks off safe and sound is a *great* landing in my book! :)
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!
For those of you planning on going to this year's PDC, if you register by Sept. 8th, you can save $200. Here's the link: http://microsoftpdc.com/registration/
Wanted to point out a couple of blogs that I would recommend checking out.
James Whittaker has finally started a blog. For those of you who don't know James, he's the crazed personality behind a few books ( How to Break Software, How to Break Software Security (with Hugh Thompson), How to Break Web Software (with Mike Andrews) ) and is currently an Architect on the team that brings you Visual Studio Team System Test Edition. He's always got a very interesting and informed take on all things relating to software quality.
Also wanted to point out Clemens Reijnen's blog. Clemens has been pushing out post after post on his experiences with the Rosario CTP bits of the Architecture Edition. Fantastic content, and just a fabulous early look at some of the possibilities we're trying to enable with the product. Clemens is a fantastic example of a customer who absolutely knows what they need in a product, and is engaging with the team to make sure we satisfy those needs ( Clemens, we can't do it all, but we're sure trying! :) ).
Check out his post on how he's added menu items to some of our new designers, created providers for our visualization capabilities ( code named "Progression" ), or how he's generating test cases out of Activity diagrams. Fantastic!!!
At TechEd2008 this year, the Rosario April CTP version of the VSTS Architecture Edition bits were demo'd during BillG's keynote by Brian Harry. Brian demonstrated the Architecture Explorer and the Layer Diagram. The Architecture Explorer is part of the April CTP, but the Layer Diagram did not make that CTP. I've received so many questions about that designer that I wanted to elaborate on the features of the diagram that you saw in the keynote, and describe the problem that diagram is out to help solve.
The Layer Diagram is designed to allow you to specify the various layers that make up your system's architecture. It is a way to describe what you believe your architecture is, and then provides you a way of discovering what it really is. :)
The diagram itself is very simple in notation, with only two main tools in the Layer palette, the "Layer" shape and the "Dependency" link. You can name those layers, describe allowed dependencies between those layers ( more on this later ), map your existing assets ( code, docs, what have you ) onto those layers, and validate that your architecture is conforming to the diagram.
Here's a very simple layer diagram that shows a typical system with a UI or Presentation, Business or Domain Logic, Data, and Logging layer:
Here is that same diagram "annotated" a bit, to describe some of the capabilities in the diagram:
There are a number of ways you can approach this diagram, below is one:
1. Create a new Layer diagram from scratch
2. Draw the various Layer shapes and name them appropriately
3. Use the Dependency connector to indicate the direction of allowed dependencies. As I mentioned in the annotated image, the lack of dependency links is also meaningful, in that you are indicating to the system that dependencies between two layers is not allowed.
4. Specify additional constraints per layer that you would like to see enforced. As an example, you will be able to indicate on a per layer basis what namespaces are allowed in that layer, and which are not allowed.
5. Map your physical assets to your specified layers. You map your assets ( code, documentation, entire projects or solutions ) via drag & drop from the Architectural Explorer and Solution Explorer. ( Later in the cycle, there will be more capabilities added around this step. )
6. Validate your architecture
This last step is where things get interesting. Steps 1-5 were all about specifying what you believe your architecture is and should be. Step 6 is all about telling you what it is.
But when does validation occur, and what do violations look like?
Validation can be done via a simple context menu gesture ( right click on the diagram and select "Validate" ), or as part of a check in policy, and as part of your build. The product will examine your Layer diagram ( you can have many by the way ), discover what assets are mapped and what constraints are being specified, and then analyze those assets with those constraints in mind.
A violation ( currently ), shows up in the Error window.
This should give you a better idea of what this diagram is all about, and you'll be able to take it for a test drive in our next CTP this fall.
Cheers,
Cameron
Kent Beck has written a great white paper talking about the importance of tooling in the Agile process. He discusses the importance to transparency during the process and how tools can help with that, but he raises a very interesting point about the need for tools to support rapid transitions between activities:
Rather than single-activity efficiency, tools need to support frequent transitions between activities. <snip>
Teams looking to apply the principle of flow need tools that support rapid transitions between activities. For example, using cards on a wall for planning has many disadvantages—the cards can’t be easily distributed to multiple locations, they are impermanent, and spatial information is easily lost. However, the one thing well supported by cards on a wall is transitions. A pair can be in the middle of coding(/analyzing/designing/testing), discover a new requirement out of scope for the current cycle, jot it on a card, and get back to coding without interrupting their development flow—elapsed time ten seconds. Even the quickest switch to another application is likely to take long enough to break their concentration
This resonated with me on a number of levels. Frequently, we discuss the need and desire to shorten release cycles, and talk about how Agile processes can help on that front, but rarely do we talk about the need to shorten the time during transition between tasks or activities. The obvious side effect of managing your transitions is more focused and concentrated time-on-task. Taken in the aggregate, this increase in time-on-task can be an enormous and positive gain to development productivity, both in speed to delivery and quality of that deliverable.
From a tooling and tool developer point of view, keeping this concept top of mind can lead to great results, from User Experience of various features sets to the feature sets themselves, and then of course to the act of creating and delivering those features.
Brian just posted about our new Hotfix information site on Code Gallery. This is a great way to keep informed of late breaking fixes as they become available, and the information is localized in 10 different languages. Point your RSS reader at this feed and you're good to go!
And for those of you not familiar with what a "Hot fix" is, or don't know the different between a "Hot fix" and a "Service Pack", check out this link, which describes in a bit of detail what these things are.
If there is ever a time to come to the PDC, this is the year to do it! Team Architect is planning on showing our latest wares, but so is the rest of the company. And if you are planning on attending, please be aware of the pre-con, which is also an event that will not disappoint. Check out Keller's post for details...
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
Ok folks, as I mentioned in a previous post, I'd like to discuss a few of the things I've been up to recently.
As some of you know, I came to Microsoft in June of 2005 to build and run the team that created what is now known as Visual Studio Team System 2008 Database Edition. By the end of November of 2006, we shipped that product. I'm very proud of what that team did and continues to do with that product. ( If you haven't been keeping up on the details, please see Gert's blog ). Breaking down the barriers between application developers and the database developers has been a passion of mine for quite some time, and the "Data Dude" product is doing a fantastic job of bridging the gap.
But I actually have another albeit older passion, which is all about using models to help manage the inherent complexity in software development. A long time ago, I was the CTO of a small company called Advanced Software Technologies ( ultimately bought by Embarcadero Tech ) that specialized in a UML design tool that was called GDPro ( "Graphical Designer Professional", later to be re-branded "Describe" after the Embarcadero acquisition ). That tool actually won a Jolt Productivity award in 2001, and a few other things.
Fast forward to 2007, and an opportunity opens up to run the team that builds Visual Studio Team System 2008 Architecture Edition. I couldn't resist, so by November 2007, I was running that team.
It has been a wild ride already, culminating recently into a lot of press around our bits demonstrated in Bill Gate's last TechEd keynote. Brian Harry demo'd some of the new Architecture Edition product, and blogged on it here. ( View the entire BillG keynote for all the details, or zip to around minute 42 to see Brian do his thing. High | Medium | Low bandwidth. )
You'll notice screen shots in Brian's post of the Layer Diagram and Architecture Explorer Diagrams. Those are examples of the new bits my new team is working on. Except for the Layer Diagram, you can test drive those bits by downloading the April Rosario CTP. It's a big download, but check out this post for tips on how to best manage it.
This team is incredibly excited, and can't wait to tell you all about all the new features we have cooking! It has been phenomenal to witness all the press around the new bits ( check this out, and this, oh and this, try this, just to point out a small smattering :) ).
The post marks the start of what I intend to be a fairly steady stream of discussions around this effort. My next post will be a discussion on our UML support and how important DSLs are to our ongoing modeling strategy.
Stay tuned!
Cameron
As you can tell, I have not blogged for way too long. There are some good reasons for that, and reasons that I will most certainly get into details in a future post ( oooh the suspense! :) ), but I wanted to make sure you folks were aware of the fact that the details for this year's PDC has now been posted here.
Please be sure to register as soon as possible, 'cause this year is most certainly going to be sold out quickly!
Come chat with the Visual Studio Team System group – December 5th
Join members of the Visual Studio Team System product group to discuss features available in Team Foundation Server, Team Suite, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new for these editions for Visual Studio 2008.
We will be holding two sessions:
Join the chat on Wednesday, December 5th, 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones
-and-
Join the chat on Wednesday, December 5th, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones
In the next version of VSTS ( code named "Rosario" ), we are planning on providing early looks at those bits through Community Technology Preview ( CTP ) releases in a VPC format initially ( first CTP was talked about here ). Nice thing about this is that you can try out the bits without fear of polluting your existing environment. One of the downsides of this approach however, is that the downloads tend to be on the large side, and a few customers have had trouble getting all the bits down in tact. Brian Keller has just written a great blog talking about how to deal with this. Please check this post out.
Cameron
I wanted to point out a post that Rob Caron put out a few weeks back that is worth mentioning, as it discusses some changes to the official names of the various Team System product lines, including DBPro. Check out this post for details. For DBPro, the official product name that we went to market with last year was "Visual Studio 2005 Team Edition for Database Professionals". That is changing during the Orcas delivery timeline to "Visual Studio Team System 2008 Database Edition". Again, check out Rob's post for reasoning and other details behind these changes.
But from here on out, you may hear us refer to DBPro with the more official "Database Edition" moniker, so wanted to make sure you were aware.
Regards,
Cameron
