Hi Vincenzo,
This is not a trivial question. Yes, but the OCL will be clumsy. EA might not handle it well.
There is an excellent example of something similar in EA itself. Consider the «table» stereotype of Class elements. If a «table» has any attributes, at least one of them must have the «column» stereotype.
Actually, this example differs from yours in three important ways, which is why I chose it.
First:
EA implements this internally, so you don't see an OCL constraint, nor do you get to (easily) manipulate the various stereotypes directly. If you drag a Table element onto a diagram EA simply stereotypes a Class element for you. When you invoke various dialogs relating to the Table EA provides customized dialogs, and once again handles the stereotypes. EA even allows you to hide the «column» stereotype of attributes, though not for other feature stereotypes. [Yes, I've submitted this as an issue. No answer yet...]
Note that you can do a lot of this yourself through the automation interface. Use the MDG Add-in events and it will work fine. Strong medicine for sure, but it can pay off if you do this more than a few times.
Second:
In an EA «table» every attribute must be a «column».
Third:
In the case of tables and columns the condition would read a bit differently, something like 'If a «table» may have no attributes; all attributes it does have must have the «column» stereotype.'
This distinction - that the containing stereotype can be valid if there are no attributes - is sometimes important. If (and only if) it applies in your case make sure you allow for it. [For example, in high level design it may be allowable for your «persistent» elements to have no attributes (and thus no «primaryKey» features). But when you get closer to the implementation phase you are going to need to ensure that each «persistent» has at least one «primaryKey» defined. Your OCL (or other approach, see above) should handle this kind of thing gracefully.
HTH, David
