Documenting SharePoint Solutions with Whitehorse

I'm currently trying to document (via reverse engineering and a some manual efforts) a .NET application built on top of SharePoint using Whitehorse. Whitehorse is the codename for the Visual Studio 2005 SOA tools (or maybe it's the codename for all of the new graphical designers in VS2005 I can never get that straight). Anyways, we have a SharePoint solution that is made up of a gaggle of Web Parts, a domain and various service and utility classes. Rather than using the normal UML markup for documenting our architecture (which I've already started) I wanted to give VS2005 a run for it's money and see how easy (or hard) it's going to be to move toward this. UML is nice and works but being a Microsoft shop, we're moving towards the DSL approach where the model is the system and away from the UML documentation model where it's just a pretty picture but not reality. My end goal here is that if I document the current (ASP 1.1/SharePoint) system now and it (somewhat) reflects reality then moving to a 2.0 based system where the model is <strong>real</strong> and not just a disconnected set of bits, I get a model of a system that works to show what the migration path will be like. It would make it easier if I took a regular ASP.NET app to do this, but I figured let's really challenge the system (even though VS2005 won't be out til later this year and SharePoint won't support .NET 2.0 until at least 2006).

Anyways, using drag and drop it's easy to lay out a system with the new tools. You drag an ExternalDatabase onto the model and specify the connection, etc. This is all great as you can use the items from the toolbox. Only problem is that there's nothing I can use to represent a SharePoint site or system because it's a bit of a hybrid. It's UI <strong>and</strong> a data access component. There's a nice little wiget to drag a BizTalkWebService on the system (or just a regular ExternalWebService) but we're talking to SharePoint through the object model. What the heck do I use to represent this? A WebApplication? An ExternalDatabase? A GenericEndpoint? Anyone tried this or have some thoughts on modeling a solution where you're using various parts of Microsoft systems as essentially middleware?