More restrictive bindings

We don't have rules in bindings that require things like that - they tend to be tricky because they make it impossible to build a legal graph without going through some illegal states. E.g. if object type A must be related to a B and a C, creating a new A makes the graph illegal.

As you say, those kind of rules are best handled by a checker generator. That way the user can choose when to run it. For instance, you can run the generator called "Checkings" in any graph. It lists all objects without any relationships, and all objects with empty properties. It's defined in the supertype of all graph types, Graph; you can see it from any Generator Editor with Generator | Change Graph Type... | Graph. (You'd probably define your own checking generators in the appropriate graph type, though.)

As I mentioned elsewhere, if you want you can also make a particular symbol display a warning message or icon of some kind, if a particular rule isn't fulfilled. E.g. in the symbol for your type A you could put a text element "Please connect to a B", with a generator condition source: "do .B {'x'}" and the condition string left blank -- i.e. the warning text is only shown if the generator produces no x's, because there are no B's connected. You'd have a similar element for C's.

Of course, if you build warning symbols for every possible case, you'll end up with models that for much of the time look like the cockpit display of a 747 in free fall -- so many warnings that they're no longer useful, and the modeler will just ignore them. If domain knowledge already tells the modeler than A should be connected to B and C, you probably don't need a warning symbol for it. Try thinking instead of how best to make the modeling language work like the modelers' understanding of the problem domain, so using it is natural.

Another hint is "convention over configuration": rather than requiring a B and a C connected to every A, consider what would be the default B and C, and build your code generator to assume those in cases where B or C is missing. (Obviously this isn't always possible, but surprisingly often it is.) This keeps models small, which is a major factor in making them easy to understand, build and maintain. It also helps with evolution: if you change your mind as to the default B, one person (you) updates the generator in one place - rather than every modeler updating every B in every model.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
newbie01 Members Profile Send Private Message Find Members Posts Add to Buddy List Contributor Joined: 19.Aug.2010 Points: 11	Post Options Post Reply Quote newbie01 Report Post Thanks(0) Quote Reply Posted: 22.Sep.2010 at 03:18
	Regarding the Graph Tool (bindings, constraints, etc.), is there a way to specify that a particular object type must be in a relationship with, say, 2 other object types? So, this would not fall under the "at most" rules under the Constraints tab (there's no "at least" option), but even more than that I want to go "through" the relationship to the other object it's attached to. Is this possible or is this something you'd do in a checker generator?

stevek Members Profile Send Private Message Find Members Posts Add to Buddy List MetaCase Joined: 11.Mar.2008 Points: 643	Post Options Post Reply Quote stevek Report Post Thanks(0) Quote Reply Posted: 22.Sep.2010 at 11:02
	We don't have rules in bindings that require things like that - they tend to be tricky because they make it impossible to build a legal graph without going through some illegal states. E.g. if object type A must be related to a B and a C, creating a new A makes the graph illegal. As you say, those kind of rules are best handled by a checker generator. That way the user can choose when to run it. For instance, you can run the generator called "Checkings" in any graph. It lists all objects without any relationships, and all objects with empty properties. It's defined in the supertype of all graph types, Graph; you can see it from any Generator Editor with Generator \| Change Graph Type... \| Graph. (You'd probably define your own checking generators in the appropriate graph type, though.) As I mentioned elsewhere, if you want you can also make a particular symbol display a warning message or icon of some kind, if a particular rule isn't fulfilled. E.g. in the symbol for your type A you could put a text element "Please connect to a B", with a generator condition source: "do .B {'x'}" and the condition string left blank -- i.e. the warning text is only shown if the generator produces no x's, because there are no B's connected. You'd have a similar element for C's. Of course, if you build warning symbols for every possible case, you'll end up with models that for much of the time look like the cockpit display of a 747 in free fall -- so many warnings that they're no longer useful, and the modeler will just ignore them. If domain knowledge already tells the modeler than A should be connected to B and C, you probably don't need a warning symbol for it. Try thinking instead of how best to make the modeling language work like the modelers' understanding of the problem domain, so using it is natural. Another hint is "convention over configuration": rather than requiring a B and a C connected to every A, consider what would be the default B and C, and build your code generator to assume those in cases where B or C is missing. (Obviously this isn't always possible, but surprisingly often it is.) This keeps models small, which is a major factor in making them easy to understand, build and maintain. It also helps with evolution: if you change your mind as to the default B, one person (you) updates the generator in one place - rather than every modeler updating every B in every model.