MetaEdit+ Workbench questions

You can of course also reuse the modelling concepts themselves and their generators.

In MetaEdit+ constraints are expressed as data and integrated in the metamodel. Compared to OCL this capability simplifies metamodel creation, and avoids the performance problems associated with OCL.

Having a programming language to express something is natural when the range of possible constraints is unknown. MetaCase's experience over the last 15 years has shown that the actual useful set of constraints needed for modeling languages is rather small. The constraints can be better expressed using a set of constraint templates which can be parameterized with the desired values.

In MetaEdit+ places to specify constraints include:

• bindings: how metamodel elements (objects, relationships, roles, ports) can be connected, e.g. a Transition relationship has a From role connected to a State or Start State, and a To role connected to a State or Stop State.
• cardinality constraints: how many instances of roles are allowed in n-ary relationships, e.g. in single inheritance, an Inheritance relationship can have many Subclasses but only one Superclass.
• connectivity constraints: how many times a given object can be connected in specified types of relationships and roles, e.g. a Start State can only have one Transition leaving it.
• port constraints: what ports can be connected, e.g. an "Out" port can only be connected to an "In" port
• occurrence constraints: how many objects of a certain type may there be in a graph, e.g. only one "Start State" in a State Transition Diagram (4.5 and later).
• uniqueness constraints: prevent two objects in a graph having the same name, e.g. two States both called "Editing" (4.5 and later).
• explosions and decompositions: how models can be linked with submodels, e.g. a State in a State Transition Diagram can be decomposed into its own State Transition Diagram.
• global uniqueness: a given property of an object must have unique values over all instances of that object, e.g. in a UML Object Diagram, the Object Name of each Object might be unique, but the Class Name property would not be: there could be several Objects of the same Class.
• property value constraints: the set of legal values of a property can be expressed in a variety of ways, e.g. a selection from a list or by checking against a regular expression (4.5 and later).

The above constraints are checked at modeling time. So once a model element is created, changed or updated the model check is made immediately. In MetaEdit+ it is also possibility to have model correctness checking that is executed on request by running a model check. These can be defined using MetaEdit+'s reporting language or by using external programs (e.g. metrics tools etc) that access desgin models using the MetaEdit+ API.

There are three possibilities for code generation:

1. MetaEdit+ provides its own code generator definition tool, the Generator Editor, for making code generators based on any metamodel and for generating any programming language. This tool is directly integrated with the metamodel you made with MetaEdit+.
2. You can integrate your own generator or a 3rd party generator with MetaEdit+ by using the MetaEdit+ API. With the API, any program having .NET/Webservices/SOAP framework can read the model information from MetaEdit+.
3. The MetaEdit+ API product also includes the ability to export the models as XML. You could parse that XML and write whatever code generator you like based on it

In most cases the easiest way is to use the integrated Generator Editor. Often this can be made even easier by writing a thin layer of code on top of your existing components, to make the task of generation easier. This has the added benefit of making the generator less dependent on a particular version of the libraries and components you use.

do .Person
orderby :Surname, :FirstName
{  id; newline }

In 4.5, metamodels can also be exported as XML, including their symbols in SVG format.

Yes. You could perform such a model-to-model transformation in one of at least three ways:

1. by generating the desired XML with a report, then reading that in to create the lower-level models
2. by exporting XML from Graph Manager, or some other text format with a report, and manipulating that in an external program to create XML to import
3. by exporting XML or text, and reading that into an external program that makes calls back into MetaEdit+ via the API to create the lower-level models.

However, experience with this approach, whatever tool is involved and whatever export/transform/import method is used, shows this is normally a Bad Thing. Without knowing your exact plans, I won't say that your idea is bad, but let me state several ways in which people have "gone wrong" along a path like this.

1. Normally the idea is that each piece of data in the high-level language gets transformed to >1 piece of data in the low-level language (let's say 2 pieces). This is fine if you never (or rarely) look at the low-level language, and never (or very rarely) edit it. But if you edit it, you are now working with 2 pieces of data, but clearly they are not totally independent, since they could be produced from one piece. The idea of DSM is to come up with a minimal sufficient representation of systems, and this is the main reason for its 5-10x productivity increases: code or UML-based ways of building systems involve lots of duplication - the same information in several places.
2. Often people say next "and we want to be able to change the high-level models still, and have those changes reflected in the low level models". That means you are working with 1+2 pieces of information, and also that you need to come up with some way to propagate the changes down to the low-level models "correctly". "Correctly" here means: without destroying information manually added there; updating the automatically generated parts; creating new generated parts; updating manually added parts to reflect changes in the top-level models (e.g. if the manually added part refers to the name of an element originally from the high level model, and that element's name has now been changed).
3. And next people say "and we want to be able to change the low-level models, and have the high-level models update". This is even harder than 2). The only cases when it can really happen are where you don't really have a high level and low level, but two different representations at the same level. Even then, it can only really apply to the intersection of the sets of information recorded in the two different models. E.g. UML tools have one class in a model mapping to one class in the code. With sufficiently simple changes, a bit of luck and a following wind, the best UML tools today are capable of maintaining that simple mapping for the names of classes, attributes and operations. The actual code isn't kept in synch (it's not in the UML models), nor are say method calls in models kept in synch with actual calls made in the code (it could be done in theory, but in practice UML models only show a tiny fraction of the calls, so it's hard to know which ones to show automatically). The only way the synchronisation can be made "better" is by moving the two languages closer, e.g. allowing UML operations to contain the method body as text, or the code to show things like "Abstract class" as specially formatted comments (assuming the language generated doesn't have a direct representation of abstractness). Each move towards better synchronisation is thus a move away from having a higher level language and a lower level language.

The DSM solution is to turn the question on its head and ask "OK, you showed me a high-level modeling language that doesn't yet capture enough information to build full systems. And you showed me a low-level language and a transformation into it. Now tell me what extra information you want to put in the low-level models". (Note that here we're asking for information, most likely on a (problem) domain level, not for the actual representation of that information.) "Now let's look how we can extend or change the high-level modeling language to provide places to capture that information". (Sometimes this step may require a rethink of the modeling language, especially if it's been based on a language that somebody had already made.) "And finally, let's show how we now have all the information we need, and we can generate full code directly from the top model, using the information it originally captured and the new information we would otherwise have entered in the lower-level models." (Remember that there was only a certain amount of information to be added to the lower-level models, regardless of its representation or duplication into several places there. Since we would have been able to generate the initial lower-level models from the information in the initial higher-level models, added extra information, and then generated code, we can clearly expect to be able to generate full code. Whilst it's probably not the best way, you can think how the transformation of the high-level models to low-level models worked, and the transformation of the low-level models to code worked (with the extra information), and thus how you could generate the low-level models, add into them the extra information now recorded in the high-level models, then generate code from there as you would have done in the original scenario)

And you thought you asked a simple question! :-) Seriously though, I hope this helps you understand the issue in general. It's one of the main reasons why MDA is doomed to failure, at least in its current form of PIM *transform* -> PSM *add detail* *generate* -> code (or *transform* -> More Product Specific Model *add more detail* ...). The industry guru vote is already in on MDA, and it's a resounding "no thanks". Successful DSLs simply don't use this approach - think of SQL, for example. Whilst it would be possible to have C code generated from SQL (and I'm sure this has been done in some places) and edit it, it just leads to a greater set of things that need to have large amounts of expert work to build tools for the synchronisation, and more work for the users in learning and working in two different languages.

Summa summarum: if you can specify a transformation from a high-level language to a low-level language, and then have modellers add more detail, and then another transformation to code, you can look instead at the information that gets added by modellers, extend the high-level language to capture it, and merge the transformations into one. It makes life easier for the modellers (one language, one model, no round trip desynch) and much easier for the metamodellers (one language, single one-way non-updating transformation). Additionally you normally find a way to record the information into significantly fewer data elements in the higher level language.

An object of type A contains an object of type B (or alternatively several of them). Is it possible to use a conditional layout of type B within the representation of type A? E.g.

+------------------------+
|     Type A             |
| **********             |
| * Type B *             |
| **********             |
+------------------------+

1. ONE B IN AN A

Symbol element conditions in MetaEdit+ 4.0 and earlier can only refer to the object's own properties, not properties of an object in a property. Whilst later versions of MetaEdit+ will allow symbol element conditions to use reports to reach information almost anywhere in the model, in 4.0 there are two ways that you may be able to get what you want:

1.1 Report Identifier

You may be able to make B have a report identifier that reveals sufficient information about it for A's symbol elements' conditions. For instance, if A has a property myB that contains an object of type B, and B has list properties Colour (values 'red' or 'green') and Shape (values 'circle' or 'square'), you could make a report identifier for B like this:

:Colour; ' '; :Shape;

and in Type A's symbol put four conditional elements: a red square, with condition on myB being 'red square' etc. You can also pick up individual parts of B's information via wildcard conditions, e.g. redness from 'red *', squareness from '* square'.

1.2 A Inherits Bs Properties

You could consider making A a subtype of B. That way all of B's properties would be available to be used in conditions in the symbol for A.

2. SEVERAL Bs IN AN A

If you want several B's in one A then there are two ways, depending on what you want:

2.1 Big Transparent Object

If Type B representations can be moved around inside an A as independent elements, and possibly have relationships between themselves:

Make A a fairly dumb object type, whose symbol is a big rectangle with no fill (transparent), A's name at the top and lots of empty space. See http://www.metacase.com/blogs/stevek/images/usecase.gif for an example: the System object.

In this case A doesn't "know" the B's it contains. If you want that, I'd suggest that you make A have a decomposition that contains the B's. I've seen other modeling languages that have tried showing decomposition contents at the top level, and they generally lead to more work for the modeler and semantic inconsistencies. If the B's really are contained by A, then it's better to have them hidden at the top level, and detailed one level lower, where they can't so easily break the boundaries of their A to cross into the implementation details of another A. And of course visually it's better to keep diagrams less complex.

If you really want to have multiple A's, each visually containing and "knowing" its own B's, there are a couple of ways you could try. You can either make a separate collection property in A and add them there (accepting some duplication between the possibly getting out of synch , or draw relationships from A to each B it contains (probably making the role lines very light gray, so they aren't so visible. You can make them transparent, but that makes them hard to use). The relationship approach works nicely too in the cases when sometimes you want to show the B's inside a big A, and sometimes you'd rather have a little A and 'contains' relationships drawn down to each of its B's below it.

2.2 List of Bs in an A

If Type B representations are basically text, and in a regular format within an A:

Make A have a property "Bs", whose data type is Collection: TypeB. Add a Text element in A's symbol, and set its contents to be a report - e.g. this would produce the effect above (which of course is not exactly what you want):

do :Bs 
{   '**********'; newline;
    '* '; id; '*'; newline; /* ending star will not align nicely */
    ''**********'; newline; 
}

Most reports are a series of loops within loops, and you can refer to the current element on the stack of an outer loop using e.g. id;1; . The number says how many loops further out to go, and can be used with most simple commands like id, oid, type and :PropertyName.

Another possible use of variables is to store state that should persist between report runs, or to parameterise reports. A better solution then is to have that information as properties in the model, e.g. of the top level graph from which the report is run.

1. Have two object types, one which defines the object and its properties (you probably have this type already), and another which contains only one property, which is a reference to an object of the first type. Use the first when you define, and the second when you refer. You may have many instances of the second for each instance of the first, or then only one instance, which you reuse in many graphs. The latter helps you find where that object is used (Properties | Info).
2. Have one object type, and add a property 'Home graph' to it, referring to the graph itself. An instance can be reused in many graphs. Something like this approach is used in the Class object of the Java Example project - only classes in the right package (same name as this graph) are generated.

Decomposition:

Depending on the method in use one or several objects (e.g. a process in a data flow diagram) can be decomposed into a new diagram. This feature is usually known as decomposition or levelling as it forms a hierarchy of models.

In MetaEdit+ you can create decomposition structures in two ways:

1. Top-down, by selecting an existing object and making a new decomposition graph where you describe it in more detail.
2. Bottom-up, by selecting some existing objects and moving them and their relationships into a new decomposition graph, replacing them in the top graph with a new object.

The end result is the same: an object in the top graph has a decomposition graph describing it in more detail. Each object has zero or one decomposition graph, and this is the same wherever that object is used.

Explosion:

Each object in a graph can also be linked to other graphs via an explosion structure. Basically the explosion structure allows the selection of one object from the graph and the explosion of it to a new graph. An object can have a different set of explosions in each graph where it is used. Explosion always happens by first selecting one object, unlike decomposition where several can be selected. Explosion is often used between different graph types.

As with decomposition, explosion structures are also method dependent. An example of a explosion graph can be found from most object-oriented methods, in which an object or class in an object diagram can be further described in a state diagram by exploding it into a new graph.

However, if there really is no other way, MetaEdit+ (4.5 and later) does support making protected blocks in generated code. Users can hand-edit the generated code in that block, and regeneration will not overwrite those changes. Please see the documentation of the filename...merge...close and md5id...md5block...md5sum commands in the MetaEdit+ Workbench User's Guide, 5.3.5.