Compartilhar via

Why we view a domain model as a tree

  • Artigo

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.

Comments

  • Anonymous
    January 25, 2005
    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.


  • Anonymous
    January 27, 2005
  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.

  • Anonymous
    January 30, 2005
    The comment has been removed

  • Anonymous
    January 31, 2005
    Fred

    I've answered your questions in another post: http://blogs.msdn.com/stuart_kent/archive/2005/01/31/363681.aspx

  • Anonymous
    May 30, 2008
    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

  • Anonymous
    June 05, 2008
    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