Some operations in the AADL meta-model java classes should also be declared in the uml/ecore meta-model.

[dblouin]

There are useful operations (e.g.: for unit conversion or to get the property values of a component) that are declared in the Java classes of the meta-model but are not declared in the ecore / uml models. This is important because some tools such as the Eclipse OCL interpreter will not be able to call these operations if they are not declared in the meta-model. We need these operations when we want to get property values from component and perform unit conversions in OCL when checking AADL models. Operations declared in Java classes such as NumberValue, UnitLiteral and NamedElement, are particularly useful for us. In addition, it could be nice to perform a complete review of the Java class to determine which operations should be added to the meta-model.

[juli1]

Hi Dominique, In fact, the ecore meta-model is generated from UML. In order to edit the UML meta-model, you need the UML editor from TOPCASED. Then, to generate the ecore meta-model from UML, you need to generate the ecore/emf meta model from Eclipse/Juno. So, to summary:

• Editing the UML meta-model requires the UML editor from topcased
• Generating the ecore meta-model from UML requires Eclipse/Juno

As the EMF/ecore meta-model is generated from UML, it would be better that you submit a patch for the UML meta-model. My suggestion would be to send on this bugtrack the proposed patch for the UML meta-model so that everybody can have a look before commiting. This is especially important because only few people are used to this type of modification and making errors can have major impacts that are difficult to track.

In the meantime, if you need any clarification/help/support, do not hesitate to add comments on this bugtrack, the more we document and share information about it, the best !

Also, some information about the files related to the meta-model can be found here : https://wiki.sei.cmu.edu/aadl/index.php/Updating_the_Meta-Model

[juli1]

Hello,

Any feedback about the edition of the meta-model ? Shall we keep this bug open or can we close it ?

[dblouin]

Yes keep it open please. I did not have time to do it yet.

Thanks.

Le 30/01/2013 03:55, Julien a écrit :

Hello,

Any feedback about the edition of the meta-model ? Shall we keep this bug open or can we close it ?

— Reply to this email directly or view it on GitHub https://github.com/osate/osate2-core/issues/147#issuecomment-12871618.

Dominique BLOUIN

Ingénieur de Recherche / Research Engineer

Université de Bretagne Sud Lab-STICC / CNRS UMR 3192

Centre de Recherches BP92116 / 56321 LORIENT Cedex Tel:0297874616 / Fax:0297874527

http://www.labsticc.fr/

[dblouin]

Hi,

I have done the changes to the UML meta-model and regenerated the ecore model and its corresponding code. I have created a patch file. How can I send you the patch?

Thanks.

[juli1]

Send it by e-mail, that will be fine.

Thanks,

[juli1]

Hi Dominique,

I reviewed your patch and would need some clarifications :

1. In AADLConstructs.uml, you add a getAllSubcomponents method. Can you explain/justify why we need it ?
2. In AADLInfrastructure, you add a getPropertyValues method. Can you also explain the reason for introducing it ?
3. What are the change in the Propeties metamodel ? From the patch, the complete file is replaced and it is difficult to distinguish changes from the existing code base.

As changes to the meta-model would be an exception and not a regular/routine operation, we are very careful/conservative about changing it. So, in addition, we should not add merged metamodel in the patch. For that reason, once we agreed on the changes, I will apply the file on the meta model and re-generate the files by myself to ensure that the process is fully reproducible.

Thanks again for your time and support,

[dblouin]

Hi,

These changes in the meta-model are very minor but are still needed for us. They consists of declaring in the meta-model operations that for most of them were already in the Java classes of the meta-model. These operations must be declared in the ecore meta-model for being able to call them from the Eclipse OCL interpreter. Somehow the interpreter looks for the declaration of operations in the ecore model before it can call them. We could implement everything in OCL but that would result in duplicating the logic that is already implemented in OSATE. The operations that I added to the meta-model are:

1. ComponentImplementation.getAllSubcomponents(), already in the meta-model Java class.
2. NamedElement.getPropertyValues( propertySet : String, property : String ), new, but very useful to retrieve property values from OCL. Again, we do not want to duplicate the complex property lookup algorithm.
3. NumberValue.getScatedValue(), already in the meta-model Java class.
4. NumberValue.getScatedValue( target : UnitLiteral), already in the meta-model Java class.
5. NumberValue.getScatedValue( target : String ), new, but very useful to perform units conversion from OCL from a string identifying the unit literal.
6. UnitLiteral.getAbsoluteFactor( target: UnitLiteral ), already in the meta-model Java class.

I think that other useful operations already implemented in the Java class could also be added to the meta-model, but we would need someone to perform that code review.

Once you have made the changes in the meta-model and have regenerated the code, the operations that were not already in the Java classes will need to be implemented in Java code. Besides, I have also removed the existing operations from the Java classes so that they are re-generated in the EMF "operations" classes. I then copied the previous implementation of the operations to the operations classes.

The getPropertyValues() operation is a little more tricky. What we need
is a means to obtain a property definition from a property set and property definition name, so that getSimplePropertyValue or getPropertyValueList methods can be used. This is achieved by a new method on AadlUtil that itself makes use of a property lookup service class. The instance of this service class is created at startup by plugin "org.osate.xtext.aadl2.properties.ui". The service delegates the job to the OSATE GetProperties class. This is done to avoid cycle dependencies between the model and property ui plugins, and to ensure that all property definitions of the workspace are visible by using GetProperties.

Thanks,

D.

Le 18/02/2013 21:12, Julien a écrit :

Hi Dominique,

I reviewed your patch and would need some clarifications :

1. In AADLConstructs.uml, you add a getAllSubcomponents method. Can you explain/justify why we need it ?
2. In AADLInfrastructure, you add a getPropertyValues method. Can you also explain the reason for introducing it ?
3. What are the change in the Propeties metamodel ? From the patch, the complete file is replaced and it is difficult to distinguish changes from the existing code base.

As changes to the meta-model would be an exception and not a regular/routine operation, we are very careful/conservative about changing it. So, in addition, we should not add merged metamodel in the patch. For that reason, once we agreed on the changes, I will apply the file on the meta model and re-generate the files by myself to ensure that the process is fully reproducible.

Thanks again for your time and support,

— Reply to this email directly or view it on GitHub https://github.com/osate/osate2-core/issues/147#issuecomment-13740581.

Dominique BLOUIN

Ingénieur de Recherche / Research Engineer

Université de Bretagne Sud Lab-STICC / CNRS UMR 3192

Centre de Recherche BP92116 / 56321 LORIENT Cedex Tel:0297874616 / Fax:0297874527

http://www.labsticc.fr/

[juli1]

Hi Dominique,

Thanks again for all these clarifications. It gives is the reason for these changes so that we can trace each change with each requirements. As we are very conservative about the meta-model, I will try also to reproduce the re-generation of the ecore meta-model by myself and regenerate the Java code.

I will let you know when this is done so that we can close the bug.

Regards,

[juli1]

Hi Dominique,

I integrated the changes to the UML meta model and regenerate the ecore meta-model. I did not commit the new generated code. Before doing it, I would like to double-check with you that the updated ecore meta-model looks ok for you. Once I get your confirmation, I will update the java code that corresponds to the new ecore meta model.

Thanks again for your time and help,

Regards,

[dblouin]

Hi Julien,

That looks fine to me.

Thanks!

Le 20/02/2013 23:00, Julien a écrit :

Hi Dominique,

I integrated the changes to the UML meta model and regenerate the ecore meta-model. I did not commit the new generated code. Before doing it, I would like to double-check with you that the updated ecore meta-model looks ok for you. Once I get your confirmation, I will update the java code that corresponds to the new ecore meta model.

Thanks again for your time and help,

Regards,

— Reply to this email directly or view it on GitHub https://github.com/osate/osate2-core/issues/147#issuecomment-13859341.

Dominique BLOUIN

Ingénieur de Recherche / Research Engineer

Université de Bretagne Sud Lab-STICC / CNRS UMR 3192

Centre de Recherches BP92116 / 56321 LORIENT Cedex Tel:0297874616 / Fax:0297874527

http://www.labsticc.fr/

[juli1]

Hi Dominique,

That sounds ok - I will then try to commit the rest of the code today. As I do not apply the patch directly and rather tried to reproduce it, I might miss something. In case, if I forgot something, please open a new bug.

Thanks,

Regards,

[juli1]

Hi Dominique, Code regenerated from the new ecore meta-model has been committed. I close this report, please open new issue in case I missed something.

Thanks again for your help regarding this issue.