Why we view a domain model as a tree

Why we view a domain model as a tree

  • Comments 9

In some feedback to my last posting, there was a question about why we visualized a domain model as a tree, with the point that this seemed inappropriate for some domain models. This is an interesting question, and warrants a more public response. So, here goes.

  • The visualization is a tree view of a graph of classes (actually  tree views of two graphs - the inheritance and relationship graphs). In the tool you have a good deal of control over how you want to view the graph as a tree.
  • The tree views certainly enables the expand/collapse and automated layout, both things which we wanted in the tool
  • But, perhaps most importantly, it is the case that many of the behaviours required in a designer and other tools implemented using code generated from the domain model, require one to walk the graph as a tree (and often in different ways). Examples include: deletion behaviour, how a model appears in an explorer, how it gets serialized in XML, how constraint evaluation cascades through a model, and so on. We have also found that although the trees required for each of these can be subtly different, they all seem to be some variation on some common, core tree. So we have chosen to make one tree central in the visualization, and have editing experiences for defining variants from this. At the moment, the only variant supported is the definition of deletion behavior.
  • Trouble's me this.

    I'm spending a lot of time and effort on studying DSL as implemented in VS2005. Both personally and as an organisation I have a lot of vested interest in both UML and Visual Studio.

    I wonder how difficult analysis of seperation of concerns, coupling, and robustness analysis (after Jacobson) might be if you have to arrange the types as a tree from the outset.

    What if you pick the wrong class as the base of the tree (I'm thinking relationship trees here)? Would this create a similar situation to fragile base class in inheritance trees?

    How do you deal with ring relationships (e.g A-B, B-C, C-A)? if A is the root of the tree then B and C will both be children. And C will be a child of B, and B a child of C, then the next children will both be A's, and so on forever.

    In support I like the navigability of tree's, most UML tools use trees for model navigation, and Microsoft have a history of this in both tools and documentation.


  • 1. This designer is focused on defining the domain model, i.e. the concepts of a DSL, which is equivalent to a metamodel in UML/MOF parlance. We're not advocating that this be used to define visualize the definition of any class model.
    2. The designer actually gives you a tree view on what is underneath the covers a graph. In fact, although there is one primary tree view, there are other trees which one can define as diffs off this for puproses such as controlling deletion of objects and links in an object graph, for viewing that object graph in an explorer, for deciding how that object graph gets serialized in XML and so on. There is an editing experience for changing the tree view, changing roots, swapping parent and child, and so on.
    3. There is a notion of Use node which allows one to break cycles. It means 'in this tree view X should be regarded as a child here'. You can then go to the definition node for X to find out what it's children are in the tree view. You can change which node the definition hangs off.
    4. It's the fact that in a designer (and other tools that use the domain model, I suspect) there are many places wher you need to navigate the graph as a tree, and depending on the purpose navigate according to different trees, that we've gone this route.
  • Thanks for the clarification, as with anything new it's sometimes hard to see the wood for the trees.

    It does lead me to a couple of other questions.

    Most people who use UML have never looked at its Metamodel. The one for UML 1.4 was reasonably straight forwards, but in the run-up to UML 2.0 it all became a bit too abstract for me, so I havn't been back. The tools you are exposing at the moment (I infer from above) are the metamodeling tools. Does this imply that in general users of DSL in VS2005 will need to be aware of this metamodel, or will VS2005 come with a comprehensive set of predefined DSL's filling all the cells of Jack Greenfields software factory schema grid.

    Secondly, how fragmented do you feel DSL's will become? Do you expect that in most cases the VS supplied DSL will suffice, or do you see companies, departments and even projects regulally creating of extending DSL's.

    While I have my own interests and aims I'm attempting to blog my views and commentary on the UML/DSL debate and modelling in general at http://questintime.blogspot.com, which airs my opinions more comprehensively
  • Fred

    I've answered your questions in another post: http://blogs.msdn.com/stuart_kent/archive/2005/01/31/363681.aspx
  • In some feedback to my last posting, there was a question about why we visualized a domain model as a tree, with the point that this seemed inappropriate for some domain models. This is an interesting question, and warrants a more public response. So

  • In some feedback to my last posting, there was a question about why we visualized a domain model as a tree, with the point that this seemed inappropriate for some domain models. This is an interesting question, and warrants a more public response. So

Page 1 of 1 (9 items)