MERL generator

In that case the MERL in Object2 to display the Name of Graph1 is:

There's an example of this in the Digital Watch project, where the LogicalWatch objects have decompositions to WatchApplication graphs. Since we want the name of a LogicalWatch object to be the name of its decomposition graph, we don't need any properties in the LogicalWatch object itself. Instead, we set the LogicalWatch object type to use an identifier generator like the above code. Similarly, the symbol for LogicalWatch can use a text element with a similar generator (or, indeed, just id).

Is Object1's name the same as Graph2's name, and creating an Object1 means you should also create the corresponding decomposition, Graph2? If so, there is a nice solution: what I described in my previous answer, plus that Object1's symbol has a text element with a generator id;1. The ;1 means to get the information not from the current element in MERL, but from one stack level further out. A symbol generator is called with the context of the graph then the object, so id;1 here will be the name of Graph2, and hence the name of Object1.

If that doesn't work, then you probably need to look a bit more at what you actually need in the modelling language and possible code generators. Certainly from the point of view of a code generator there isn't a need for Object2 to have a link to Object1 - your generator will have started from the top level, so it can simply get the name from the context stack with id;2 (assuming a stack of Graph1, Object1, Graph2, Object2), or then if it feels easier you could store the name of Object1 in a variable and use it later in Object2. The question then is more that why does the modeller need to see the name of Object1 in Object2 in Graph2. Generally that shouldn't be necessary: if I'm writing a function, I don't need (or want) to know the name of the calling function. We can have black box, grey box or white box components, with the difference as to whether the caller can see inside the callee, but never can the callee see inside the caller. 

I'd encourage you to think this through and aim for good modularization practices. I've seen too many bad examples to stay quiet on this :). Of course MERL is able to search through all graphs to find Object1:

But that's a different cost performance-wise as the number of graphs and objects grow. You can improve it somewhat by filtering to just graphs of the right type and avoiding performing the default sort on them: