The ORM Foundation

In our company I have managed to successfully introduce NORMA as a sketching tool, even if not directly a model-management tool. However, due the use as a sketching tool, we have a need to copy parts of sketches from one .ORM file to another. Is there any way to cut and paste object types, fact types and constrains, other than directly editing the xml?

Hello,

It would help us to give you better advice if you tell us a bit more about how you are using NORMA "as a sketching tool".

In the meantime, I hope that the following suggestions are of help.

Ken

==========================

Just Diagrams

If you just want to create ORM diagrams, then you might also consider the Visio Stencils in the Library: http://www.ormfoundation.org/files/folders/visio_stencils/default.aspx

In NORMA, if you right-click on the drawing surface of a model page, you will see a "copy image" option which copies the whole page.

If you just want part of a page, then you can use a tool like Snagit to make .jpg's or .png's of selected parts of the NORMA diagrams which you can then paste into another program such as Word.

Merging models

About 9 months ago, I discussed this with Matt and here is a summary of what he said:

Option 1: If you have the group feature enabled, then you can the fact types that you want to copy into a group put all the fact types into a single group and then drag the group from one model to another. The object-types and (non-external) constraints will be moved along with the fact types. This may cause changes in the diagram layout.

Option 2: The XML way:

2.1 Choose one of the files as a "primary" file.
2.2 Open the file as XML
2.3 Copy the contents of the following sections from the secondary file to the primary file:

orm:ObjectTypes
orm:Facts
orm:DataTypes
orm:Constraints

You can also copy the diagrams across.

However, with this option, you will have to "manually" reconcile the shared data types sections.

The aim is to end up with only one of each data type in the primary file.
So you will need to delete any duplicates-after replacing references to the data type id (which is a guid) with the duplicate data type id that you want to keep.

Cross-model drag drop was enabled in the December 2010 release and is detailed in the 'General Use' section of the readme.

I don't currently support dragging whole diagrams, but you just create a diagram in the target model and drag from the other (after a select-all on the diagram). It is easiest if you put the windows for the two documents in different tab groups in VS (right click on the file tab to create new tab groups).

As Ken says, you can also create a group and drag the elements across, but you won't get any shapes this way. If you're using this mostly for graphical display anyway, then you'll want the shapes.

The merge is pattern-based, so dragging MyEntity twice will match the same entity type. However, if you drag MyEntity and rename it to MyOtherEntity in the target model, then dragging again will not recognize that these elements are the same shape. Doing change and import history--including recognizing renamed items as copied from the original items--is a significant work item that hasn't been done yet.

-Matt

Thank you! That did *exactly* what I wanted it to do and hoped it would do. Apparently at the end of the workweek I was not creative enough to try dragging and dropping rather than cutting and pasting.

To answer the important question: we sketch out conceptual models in NORMA and then use the automated verbalizations and sample sentences to check with our business specialists that the concepts are correctly modeled. We do not consider the conceptual model as it is in NORMA to be the definitive model though; it then gets re-evaluated (and possibly reworded) for implementation as datastructures in our software and for conceptual description in our documentation. The use of NORMA rather than the Visio stencils allows us *much* speedier entry of the models, as well as an affordance for learning the more subtle constraints that can be expressed with ORM. The latter is especially important as I am the only one using it in our office with any formal training in ORM (well, NIAM and a bit of FCO-IM to put not too fine a point on it). However, due to the fact the we treat the .orm files as sketchpads rather than as part of our software development artefacts, in a fashion quite similar to our use of whiteboards, we have recognized the need for cross-model imports of (parts of) models; we may not necessarily model the entire conceptual space in NORMA, but we may want to bring in already-modeled bits. Which is exactly the use-case that Matthew's cross-model drag and drop supports perfectly.

Many thanks for your feedback.

a.vanleeuwen:

as well as an affordance for learning the more subtle constraints that can be expressed with ORM. The latter is especially important as I am the only one using it in our office with any formal training in ORM

For the last few months I have looking at the possibility of developing a series of short "show and tell" videos to cover both ORM and NORMA. However, I have been working with ORM for 20 years so I have forgotten much of what it is like to go up the ORM learning curve.

So, it would help a lot if you could post a note about the topics that you feel would help to speed up the learning process of ORM in general and NORMA in particular.  At this stage, what I'm looking for is two short lists of "points to be learned". (one list for ORM & one list for NORMA). The topics on each list should be in the sequence that you think would be most helpful for newcomers.

Thanks again for your feedback.

Ken

Note that while cross-model drag-and-drop is a very valuable and necessary feature in NORMA, I have seen numerous anomalies, specifically with NORMA bringing across many more objects than I selected, and where these conflict with the names, types, etc, of objects in the target model, simply changing the originals with no warning nor stopping for confirmation or accepting the details of the merge. This is a trap especially if you have customised basic types used in identification patterns, for example.

I would much prefer NORMA to retain my original versions of object definitions unless I specifically select alternative definitions, and not to bring across consequential or linked facts willy-nilly.

Hi Clifford,

Nothing is done willy-nilly here. NORMA first performs a directional copy-closure in the source model. If a fact type is pulled, all of its entity types are pulled. If an entity type is pulled, so are its identifying fact type(s), internal constraints, and supertypes. If you have formal derivation rules, any object types and fact types used in the derivations are also pulled.

Note that the closure is directional. For example, pulling an element in a group will pull the group and the reference to the element, but will not pull all elements in the group. However, pulling the group as a primary selection will bring all of the referenced elements. Similarly, pulling a fact type will bring across all of its object types, but pulling an object type will not bring all role players.

Having matching reference mode patterns generally helps the merge.

The matching is inentional, so you can bring across an object type, then another related fact type, then another, etc. You should not need to answer any questions about matches as you copy elements across incrementally, and you would probably be very surprised as to how many questions you would have to answer even in basic scenarios.

If you have a specific example that is causing you problems, please share, but there isn't much more I can answer when you're painting with this broad of a brush.

-Matt

PS You can always use a third model if you want to merge more carefully.

• Pull from the source model into a new empty model.
• Check the object types for items already in your target model (the Model Browser window is useful for a thorough review).
• If you want to make sure they match the identification schemes in your target model, then pull from the target to the temporary model.
• Once you've clean up in your isolated environment, drag your original selection from the intermediate model into your target model.

Matt, I'm sorry for implying that there was no solid plan in your merge approach; of course it's entirely systematic. I've just been bitten by it a number of times now, even when I thought I knew what I was doing, and it's in the nature of "being bitten" that I wasn't aware of what exactly had happened until later... so I can't describe why it was a problem. I just wish I had more control; that instead of the drop forcing a merge through, I got a dialog enumerating all the things that were about to happen (especially changes to existing objects; additions are expected and are not usually a problem), and at least allow me to review and cancel the whole thing.

Thanks for the advice on using an interim empty model, that will help a lot!