none
Is it possible to do round trip UML Class to code in VS2010 Architecture Modelling tools? RRS feed

  • Question

  • If I start from a UML class diagram, I can generate code from it - but I don't seem to be able to modify the generated code and then update the model.  Is the model to code generation seems to only one way.  It seems that the only way to do round tripping is via the Class Designer - i.e. in a .cd file; but if I generate a UML Class diagram then view it in the .cd file, the class diagram relationships don't show clearly.

     

    Can you clarify the expected functionality for a UML class diagram?


    Best Regards Sina
    Sunday, December 26, 2010 11:59 PM

Answers

  • First, it's worth noting that there's more than one way of generating files from UML. One way is the Generate Files menu item. The other uses the solution explorer's Custom Tool generation mechanism, just like files generated from .resx. The latter mechanism makes it easier to generate many files from one model, and to regenerate the files when the model changes. See How to Generate Files from a UML Model, sticking with the method described in that topic.

    As to why the UML code generation facilties are different from .cd: The .cd files are intended to represent the code directly: one class in the code = one class in the diagram. It's easy to define a round-trip mechanism because no information is lost either way. 

    But the idea with UML is to allow developers to focus more on the overall ideas in the design. As I mentioned above, the mapping between a high-level view and the classes in the code is much more dependent on the project you're working on. So the round-trip approach is much less useful.


    - Alan -MSFT
    Monday, January 10, 2011 9:22 PM

All replies

  • (I'm sorry for the slow reply, Sina. The holiday period....)

    You're right, we don't support round-trip development for UML diagrams.

    We're expecting that people will use the UML diagrams more to describe the principal ideas in a design, rather than the detail.

    For example, you might use class diagrams to represent the main business concepts in a design - Customer, Product, Catalog, and so on. The idea is to sketch the principal ideas that the architecture needs to represent, so that they can be debated more easily before you develop or change the code.

    In a high-level diagram like that, you might have, say, an association between Customer and Product representing the idea that a customer can order a product. But in the code, there are lots of different ways that might be implemented - as a relation in a database, or as pointers between objects, or as a cross-reference in XML, and so on - typically more than one way in any implementation.

    Because everyone's implementation is different, it would be difficult for Visual Studio to pick out the interesting abstractions automatically. That would tend to result in lots of very detailed class diagrams that are just pictures of the code. And although we provide a way of turning UML class diagrams into code, it is really only intended to be a starter kit - we're expecting people will customize the generation templates to suit their own projects.

    Hope this helps.


    - Alan -MSFT
    Monday, January 10, 2011 5:17 PM
  • This implies that the UML diagramming tools in VS2010 are not meant for model driven development - they were designed more with documentation in mind than actual starting point for the development.

    We as an orgnisation, are counting on the use of VS2010 - TFS combo. with the understanding that the UML diagramming offered by the Ultimate edition of VS2010 would provide the tool set necessary for the design life cycle.  But from what you're saying we really need to have a different tool set if we want to implement model driven development - this to include Architecture designs that is kept up to date as the code base changes in time.

    Right?


    Best Regards Sina
    Monday, January 10, 2011 5:29 PM
  • Well, it seems to work pretty well for MDD - and more flexibly so than many tools. We create a lot of our code from models. 

    The trick is to decide that the models are the master source for any aspect of the design that you use them for.  We always recommend generating code that can be easily combined with code from other models, and with hand-written code. In C#, it's usual to generate partial classes for this reason. In this approach, you never touch the generated code by hand. It's a discipline that works well. I've found it also tends to be much more flexible than the round-trip approach and makes it easier to use the class diagrams for higher-level abstractions - very much the MDD idea.

     


    - Alan -MSFT
    Monday, January 10, 2011 6:00 PM
  • OK - so I understand with the partial class feature of C# this may work well - although as you say you still have to think/care about modularity of the generated code - with agile modelling in mind whereby you want to prove your model with code, you're very much into the realm of iterating you model, generating code, implementing the methods in an incremental way - this use case doesn't lend itself well to the way the UML diagram to code mechanism is perceived in VS2010's current implementation.  

    The question is, when round tripping functionality already exists in another paradigm within VS2010 ( Class Designer .cd files) why make the UML code generation capabilities different?

     


    Best Regards Sina
    Monday, January 10, 2011 8:56 PM
  • First, it's worth noting that there's more than one way of generating files from UML. One way is the Generate Files menu item. The other uses the solution explorer's Custom Tool generation mechanism, just like files generated from .resx. The latter mechanism makes it easier to generate many files from one model, and to regenerate the files when the model changes. See How to Generate Files from a UML Model, sticking with the method described in that topic.

    As to why the UML code generation facilties are different from .cd: The .cd files are intended to represent the code directly: one class in the code = one class in the diagram. It's easy to define a round-trip mechanism because no information is lost either way. 

    But the idea with UML is to allow developers to focus more on the overall ideas in the design. As I mentioned above, the mapping between a high-level view and the classes in the code is much more dependent on the project you're working on. So the round-trip approach is much less useful.


    - Alan -MSFT
    Monday, January 10, 2011 9:22 PM