Clint Edmonson

@George Perry: I recommend repesenting the admin user interface as a separate UI layer and giving it the same dependencies on BL and data layers, if that's how you intend to code it.

@pet1202: For some reason the link to the original file was dropped. It's there now.

Hi Saumitra,

• If you want to model an external framework, simply draw it as it's own layer and draw in it's dependencies with the other layers that consume it. The lines might start to draw over top of other layers so you'll have to lay it out on screen to show it as cleanly as possible.
• The layer diagram is not UML compliant and at this point there is no support for associating layers with the UML model elements.  However, you can associate any layer with the physical elements in solution explorer (projects, namespace folders, and project files). Simply drag and drop them onto the layer they belong to. You can then start working with the architecture validation tooling. I stopped short of showing this becuase I wanted to focus on the UML tooling. You can find a great starting tutorial here: http://bit.ly/a1fjdq

Hi Saumitra,

• It's not that I haven't used the same actors. My example simply stopped short of creating designs that involve them all. But you are correct - as iterations progress and designs are created, more of the actors from the analysis will show up in the design model. If these two diverge, it's likely that the use cases are not driving design and implementation during your iterations. Having said that, unless you're following a "model as documentation" strategy, maintaining tight synchronization should not be a primary worry. If you are, I recommend integrating design steps/states into your work items pipeline. Also, using two different modeling projects is NOT the only way to do modeling. It's simply the way I was brought up. I've met teams that use a single modeling project and avoid any worry about design divergence and teams that use separate modeling projects for their layers and/or subsystems.
• All diagrams and almost every model element can be associated with a work item via a right-click menu. This would let you use work items to link all the artifacts for a feature with full traceability.

Good catch Andrej. You are correct. The arrow should point from the extension towards the use case it extends from. In the Store Manager use case diagram in the Analysis Model, the direction of the <<extends>> relationship needs to be reversed.

It's a third party tool called Vista Switcher: http://www.ntwind.com/software/vistaswitcher.html