The ORM Foundation

With the changes to Fact Types in through v16, I find it much easier to re-position and rotate Fact Types. Combined with Flip Vertical, Flip Horizontal, and Add/Remove Text Arrow, I find I can quickly get Fact Types in the orientation I want with readable text.

The are some "decorations" I associate with Fact Types, like role constraints (e.g. exclusive or), associativity constraints (e.g. acyclic strong intransitive). I also frequently use note text to annotate Objects and Fact Types. When I move the Object or Fact Type with which these items are associated, they do not move with it. If I forget to select them before I move the Objects or Fact Types, they get left behind.

It would be nice to find a way to anchor the constraints and notes to the things they are associated with. I realize the end points of the constraints can be anchored--I mean the symbol in the center.

Within the constraints of Visio, I am not sure how realistic any of those ideas are, especially when I might be asking for something like "always anchor them except when I don't want them to be anchored"--one of those mind-reader features.

I will also point out that due to this being Visio and a drawing tool, building a relationship requires the use of no fewer than six shapes (two objects, a fact type, two connectors, and a uniqueness constraint). This makes it laborious to create relationships quickly. That is the limitation of using Visio instead of NORMA in VisualStudio--I understand that.

If I think of other things, I will post them.

Hi Roger,

Thanks for your next great suggestion. It will take me a little while to figure the best way, or even a way, of doing that.

I think you may have put your finger on the biggest challenge-- how to get it not to do it when that's not what you really wanted... But I'm hopeful. I've gone ahead and posted v16, however, so the improvements you requested earlier are available. Thanks again,

 Best regards,

Andy

Andy,

In APRIMO, I allow the user to "lock" a role, which has the effect, when moving that fact type, of retaining the length and direction of each connector (either constraint or role connector) by also moving the constraint or the attached object type. This make it really easy to lay out a small section of the diagram and lock its internal roles, then whenever you drag any of its parts you drag the lot. It works like grouping, but better.

I also have vertical-only and horizontal-only locking, but those are less useful.

Clifford Heath.

That is an interesting idea. So locking a role rigidifies the roles, connectors, and objects creating a unit that moves together. That's kind of what I was trying to describe, but sounds like an interesting approach to doing it and solves some of the problems my naive description would introduce.

Very nice!

How hard would it be to make objectification a right-click option on a fact type instead of being a distinct shape? When I am developing a model, I often go from Fact Type to Objectified Fact Type, and sometimes back again. Having to replace the shape, name it, and move the connectors, constraints, etc. reminds of this idea every time.

I am unclear how hard this would be, but if all Fact Types were objectified Fact Types under the covers, and it was just a matter of showing or hiding the geometry and maybe recomputing some of the dimensions and other things, it might be possible.

Hi Roger,

Thanks for your suggestion re objectification. I'll return to it after I grapple with the earlier one.

For the moment, suffice it to say that it's basically impossible without introducing very weird and unpleasant shape behaviour, if you try to do it with just shape-sheet formulae. But I think there's probably a way to do it using other means. I'll definitely give it a try. And, I'll keep you posted. Thanks again,

Best regards,

Andy

Hi Roger,

I've attached a solution to the "I forgot to select that external constraint" problem. An explanation of what it does is included in the file.

It may leave out some objects you use, but it does include all the external constraints in the stencil. However, don't test it with the "Asymmetric Transitive" constraint, as the name of that one was misspelled in the earlier stencils (but will be corrected in v17).

Please see what you think of this approach. Let me know how it might be improved. (BTW, I'm going to see if the Frequency Constraint can be relaxed internally, to accept any length of text-note...) Thanks,

Best regards,

Andy

Intentional or not, I found that click-dragging a shape will never include the neighboring constraints, but click then click-drag will. This gives me the option, with a little practice, to decide if I want to move just the shape I clicked, or the shape and its attached constraints.

I'd have to play with it a bit to see if it really makes using the stencil easier or harder.

What have others thought on your side?

 Hi Roger,

Thanks for the feedback. No, I'd not intended that click-dragging would not include the other, automatically selected constraints. But really, I'm not sure whether one naturally does click-dragging or not, in Visio... I'm thinking probably not, speaking for myself at least, because I tend to wait for visual clue that the shape has been selected, before I start dragging it... and unless I let up the button after clicking, and before dragging, I don't get that visual clue (at least, not for quite a while)...

 But you are right, the jury needs to decide whether this makes it easier or harder to use the stencil... But here's some testimony in favor:

-- It does not seem to interfere at all in text-entering, whether on fact types or object types...

-- which leaves not so many other reasons why you'd select a fact type, after having connected constraints and whatnot to it: viz., to move it, or delete it... (do any others occur to you?) ...and in either of those cases, if you've selected half or more of the things the constraint is connected to, you probably want to move or delete the constraint along with them...

But I'm very interested, of course, in what the Roger Cass and other juries will decide. Please play around with it, give it a while, but be frank. 

   As for other reactions, I've only had one, and it was simply, "Takes a bit of getting used to." And I think that's true: it's a completely new feature, not in any ORM tool I've used. So, we're just not used to the tool doing that much with a single click of our mouse-button. But we can acclimate, no?

  BTW, I'm working on a second version, which eliminates, as far as I can see, the unexptected behaviors caused by version 1's simpler selection-criteria. The price is that it works just a smidge slower. But after all, we're talking a small fraction of a second, at most, even on a slow machine... so not a big problem. In fact, that slightly delayed reaction makes the automatic selections seem just a little less jarring, in my opinion :-) I'll post this after I get one last thing coded...

Cheers

Andy

Roger,

Here's version 2 as promised. It gets rid of the (relatively rare) intances of unexpected behavior I'd noticed. (One case that I'd cited as unexpected turned out to be just Visio behaving normally, viz. if you click on a seleced shape it un-selects it.)

    However, also unexpected was the behavior you noted, with click-dragging. (Interestingly, click-dragging works as expected if you're click-dragging the last of a series of two or more selected (with Shift down).) And I've realized that about half the time, if I want to drag something I just click-drag it -- rather than click, release, and click-drag.

   Which sorta defeats the whole purpose, if the latter was to allow the modeler to model with even less attention needed to the tool's manipulation. So, this unforeseen (and unavoidable, I believe) click-drag behavior with the automatically selected constraints, seriously mitigates the usefulness of this whole solution, IMHO. Seems like adding some lightning and thunder but no rain :-)  Any further thoughts on it?

   I think that unless I get a lot of demand, this interesting experiment will remain just that. In the meantime, I'm getting onto your following request.

Cheers,

Andy

I am in agreement with you that the inconsistency of the interaction depending on click-drag or click, click-drag, while interesting, would be so obscure that it would cause more confusion than benefit.

I am impressed you figured out a way to do it. Clearly not just a Shape Sheet thing. Thanks for giving it a try.

Hi Roger,

 I'm attaching a taste of my first stab at an objectification solution. I hope you can find some time to try it out and see if you like it, and what could be improved.

Regards,

Andy

I tried all the things I could think of off the top of my head, and it worked perfectly.

I think this would be an enormously useful addition to the stencil. In fact, it made me think that there only needs to be one Fact Type shape: an n-ary adjustable, rotatable, and objectifiable Fact Type.

Incredible work--thanks for creating it.

You're very kind, Roger. Glad you like the improvement. You'd be surprised, as I was, at how many things that you previously asked me to do were crucial prerequisites for this improvement. So, thanks again for all your suggestions.

   Version 17 is up and available.

Best regards,

Andy

I did note one thing about my previous comment that I think was too ambitious at the moment. The way the n-ary Fact Type shape works today, there are dozens of connection points that hang around even when the Fact Type is configured to have a small number of Roles. This makes it awkward to try to connect things to the shape if it is anywhere near another shape, particularly another n-ary Fact Type shape.

So while I still think it would be great to only have one underlying shape for all Fact Types (and the varieties of Fact Types in the stencil are just pre-configurations of that one shape), unless there is a way to "deactivate" the unnecessary connection points, I don't think it is practical. To date, I have not had a need for a Fact Type with more than 3 Roles, but I occasionally change from a binary to a tertiary Fact Type and vice versa while doing facilitated modeling sessions. Doing so without the use of the n-ary shape requires adding a new shape, then moving all the text, connectors, and constraints to the new shape--which turns into "let's watch Roger fiddle with Visio" for a few moments. It's hard to keep a room full of senior business leaders focused during those times--"pay no attention to the man behind the computer!"

With that idea set aside for a moment, I think the new "objectifiable" Fact Type shape is simply terrific!