locked
How can I see namespaces/classes/methods grouped by layer? RRS feed

  • Question

  • The architecture explorer diagrams are great, but what is really cool is the layer rules validation at build time.  However, the layer digram indicates references, BUT does not visualize them.  Specifically, when I drag a namespace, class, query or whatever into the layer diagram to create a validation rule, PLEASE provide a way to see that visually on the graph and not have to refer to properities/other views.


    So, can you add an option for Visualize Code Relationsips --> Visulaize Call Dependency - By Layer

    Bob Hardister
    • Edited by BobHardister Wednesday, April 8, 2009 7:28 PM clarify feedback
    Wednesday, April 8, 2009 7:08 PM

Answers

  • Hi Bob,

     

    You ask some great questions and there’s a lot to work through so let me see if I can answer them all. If I don’t please let me know – this is the kind of feedback that helps us focus our efforts in the right places so I really appreciate your time.

     

    For your first response I have a question before I get to my comments: when you refer to looking at rules for a selected layer do you mean looking at the references (for example when I drag a namespace/project onto a layer I think of that as a reference)? That’s my assumption for the answers below.

    1.       We recently made a change to the Layer Explorer so that it shows all of the references on a diagram if you don’t select any shapes. While this should help with being able to view all of your references it’s not ideal for communicating that to others. For that you’ll need…

    2.       We’re also creating a set of APIs that would allow someone to write an extension that generates a report of the references on a layer diagram. This would be a better way to communicate all of the references on a given diagram, but we don’t have plans to ship that in the box.

     

    For your second response:

    1.       It’s a great idea and there’s no technical reason why it can’t be done. Unfortunately it’s a matter of logistics and timing – we have a fixed amount of time and resources to complete this release and this particular feature didn’t make the bar.

    2.       You’re absolutely right – there is a lot of overlap between diagrams created from the AE (what you’ve got) and layer diagrams (what you want). This overlap leads to some very interesting scenarios around refactoring that we haven’t had time to explore yet. The idea of being able to graphically refactor, as you suggested, is very compelling, and even if all it did was create a work item to represent the act of refactoring I still think there would be significant value. For now I would expect something along the lines of:

    ·         Create your layer diagram with the architecture you want and run validation.

    ·         From the diagram create work items to fix any violations you see (these can be at the level of granularity that suits your needs).

    ·         Suppress the error messages. This gives you a baseline (similar to how code analysis is used).

    ·         Run validation as part of your build – this will tell you if any new violations are checked in and they can be fixed as they are found.

    ·         As the work items you previously created are resolved you can remove the suppressions until you’re clean. You can view the related work items from the diagram too making it easy to find them.

     

    I hope this helps,

    Thanks,

    Ian

    • Marked as answer by BobHardister Monday, April 20, 2009 2:43 PM
    Thursday, April 16, 2009 9:56 PM
    Moderator
  • Hi Bob,

     

    Thanks for downloading the CTP and providing us with feedback. I’m really glad you like the layer diagram – we’re excited about what people are going to be able to do with it. We don’t have plans to visualize the references on the diagram (beyond the glyph you’re seeing that shows a layer has a reference), but we do have the Layer Explorer tool window. This window shows details for all references of selected layers, but not graphically. I’d love to get feedback describing why it does or doesn’t meet your needs.

     

    Thanks,

    Ian Bavey

    Dev Lead

    Team Architect

    Friday, April 10, 2009 9:54 PM
    Moderator

All replies

  • Hi Bob,

     

    Thanks for downloading the CTP and providing us with feedback. I’m really glad you like the layer diagram – we’re excited about what people are going to be able to do with it. We don’t have plans to visualize the references on the diagram (beyond the glyph you’re seeing that shows a layer has a reference), but we do have the Layer Explorer tool window. This window shows details for all references of selected layers, but not graphically. I’d love to get feedback describing why it does or doesn’t meet your needs.

     

    Thanks,

    Ian Bavey

    Dev Lead

    Team Architect

    Friday, April 10, 2009 9:54 PM
    Moderator
  • Hi Ian,

    I'm disapponited that the layer diagram will not vizualize the objects for which validation rules have been implemented.  It's great that you can setup the rules, but the Layer Explorer tools only let's you look at rules for the selected layer.  What we need is the ability to communicate all rules that have been implemented.

    So, do I need to a create screen shot for each layer (selected layer with the Layer Explorer displayed) that has rules so I can get a visual/report of the rules?

    What do you suggest is the best way to communicate and present the rules implemented?

    Thanks, Bob
    Bob Hardister
    Monday, April 13, 2009 10:20 PM
  • Hi Ian,

    I wanted to provide some further input as I feel there are some important issues here. Also, I have a question on each issue that I would appreciate if you could address:

    1.  Using the Architecture Explorer(AE) I can display a namspace diagram that visualizes the classes within their namespaces and shows the dependencies between them. Now I want to go on and be able to do is see the architectural layers from the Layer Diagram overlayed on this. Since the layers are created and maintained in the Layer Diagram, why can't they be visualized in the diagrams generated by the AE?

    2. There is an obvious overlap between the layer diagram and the diagrams generated with the AE: they display the same kinds of information - classes and dependencies.  In the digrams created by the AE, I can see the classes that belong to namespaces and the depedencies between classes within and across namspaces.  When I drag a namespace from the AE to the Layer Diagram, why can't they Layer Diagram display this information in the same way (classes within a namespace and depedencies between classes)?  This would be very helpful in the following use case:

    A. I use the AE to visualize my existing architecture
    B. I create (i.e. reverse engineer) a Layer Diagram (LD) from that
    C. (this is what I would like to do)--> Using point/drag/click on the LD itself I change the classes and their dependencies to what they "ought" to be. That is, on the LD I'm able to add, remove, change classes and dependencies at that level, which I can't do if I can't see them. Now the LD is a spec for code changes to improve the architecture.  I can assign work items for objects that changed in the LD to developers to make/complete the needed code changes
    D. The LD enforces my changes via the validation rules

    Regarding point C above: I know that I can accomplish something like this with the Layer Explorer, but this tedious and provides no overall visualization of all the changes/rules that I, as the architect, set up.

    I hope this additional input helps clarify our requirements. What I have described is consistent with the way I seen other things work in 2010. For example, with the sequence diagram.

    I would appreciate a reply to the questions above and any further thoughts you have this.

    Many Thanks!

    Bob
    Bob Hardister
    Tuesday, April 14, 2009 1:31 PM
  • Hi Bob,

     

    You ask some great questions and there’s a lot to work through so let me see if I can answer them all. If I don’t please let me know – this is the kind of feedback that helps us focus our efforts in the right places so I really appreciate your time.

     

    For your first response I have a question before I get to my comments: when you refer to looking at rules for a selected layer do you mean looking at the references (for example when I drag a namespace/project onto a layer I think of that as a reference)? That’s my assumption for the answers below.

    1.       We recently made a change to the Layer Explorer so that it shows all of the references on a diagram if you don’t select any shapes. While this should help with being able to view all of your references it’s not ideal for communicating that to others. For that you’ll need…

    2.       We’re also creating a set of APIs that would allow someone to write an extension that generates a report of the references on a layer diagram. This would be a better way to communicate all of the references on a given diagram, but we don’t have plans to ship that in the box.

     

    For your second response:

    1.       It’s a great idea and there’s no technical reason why it can’t be done. Unfortunately it’s a matter of logistics and timing – we have a fixed amount of time and resources to complete this release and this particular feature didn’t make the bar.

    2.       You’re absolutely right – there is a lot of overlap between diagrams created from the AE (what you’ve got) and layer diagrams (what you want). This overlap leads to some very interesting scenarios around refactoring that we haven’t had time to explore yet. The idea of being able to graphically refactor, as you suggested, is very compelling, and even if all it did was create a work item to represent the act of refactoring I still think there would be significant value. For now I would expect something along the lines of:

    ·         Create your layer diagram with the architecture you want and run validation.

    ·         From the diagram create work items to fix any violations you see (these can be at the level of granularity that suits your needs).

    ·         Suppress the error messages. This gives you a baseline (similar to how code analysis is used).

    ·         Run validation as part of your build – this will tell you if any new violations are checked in and they can be fixed as they are found.

    ·         As the work items you previously created are resolved you can remove the suppressions until you’re clean. You can view the related work items from the diagram too making it easy to find them.

     

    I hope this helps,

    Thanks,

    Ian

    • Marked as answer by BobHardister Monday, April 20, 2009 2:43 PM
    Thursday, April 16, 2009 9:56 PM
    Moderator
  • Hello Ian,

    Thank you for your excellent response. It certainly gives me something to work with.  I will experiment with the procedures you suggest and follow-up with more comments if needed.  Looking forward to the beta!

    Bob
    Bob Hardister
    Monday, April 20, 2009 2:46 PM