Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] About the migration to SysML 1.4
Hi Camille,

I can understand that the migration and the planned diagram editor refactorings are not trivial
(we are very aware - and very wary! - about that).

We do support the idea of clearly separating SysML1.1 and SysML1.4 and keeping both maintained until this is all stabilized.
But to that aim, why not reorganize slightly the repo and features to have something like that? :
plugins/
 core/
 uml/
 sysml11/
 sysml14/

... with sysml11 being just a renaming/move of the current sysml folder,
and with syml14 having the very same structure & java namespaces as sysml11, with just the new version of the profile,
and new diagram editors using the new diagram customization mechanisms (based on viewpoints I guess?).

That way, they would be even more clearly separated.
The only restriction would be that one cannot have SysML1.1 and SysML1.4 active in the same Eclipse configuration,
but that could be acceptable, couldn't it?
(and one could still have a single install of Papyrus with the two configurations available I think).

Those wanting to do legacy SysML1.1 would use the first configuration with the legacy set of SysML plugins active.
Those wanting to go SysML 1.4 would use the second configuration, whose org.eclipse.papyrus.sysml profile could contain both the static 1.4 and dynamic 1.1 SysML profiles.
I don't think having both at once in a single running instance of Papyrus would be that useful, or would it?

On Thu, Jan 15, 2015 at 4:34 PM, LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:

Hi Alain,

 


The main idea here is that the migration from the current version of SysML implemented in Papyrus to this new version is not trivial, and we may not have enough to do a complete, automatic and transparent migration (As UML is doing for each new version).

 

If we can’t complete this for Mars, at least we can guarantee that we’re not going to break anyone. Moreover, we’re currently investigating on a new method to implement SysML diagrams as customizations of existing UML Diagrams (Rather than extending them).

 

Since this introduces a lot of hazard, we want to have a clearly separated set of plug-ins, as well as a separate profile, so that users and tool providers can choose, at their own discretion, whether they want to migrate or not.

 

For the next versions, we will hopefully be able to simply update the SysML 1.4 profile and provide a transparent migration. Of course, this means that we will either have to keep the “14” suffix, or rename the packages, which is not a good thing in either case. So, we could change this suffix to something else (less version-specific), while still keeping it separate from the current SysML implementation.

 

When we’re confident enough with this new approach for SysML, we can refactor the SysML 1.1/2 plug-ins to only provide a dynamic profile, and deprecate the current SysML diagram plug-ins; but we’re not there yet

 

 

Regards,
Camille

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Alain Le Guennec
Envoyé : jeudi 15 janvier 2015 16:08
À : Papyrus Project list
Objet : [mdt-papyrus.dev] About the migration to SysML 1.4

 

Hi all,

 

I have some general remarks about the on-going work to migrate Papyrus to SysML 1.4,

which I think are important for advanced consumers of Papyrus that use the static SysML profile(s) extensively.

I could have raised them in bugzilla #440082, but maybe this needs a wider discussion.

 

I just saw in gerrit that SysML 1.4 support was implemented as a set of brand new plugins (model, edit, etc), and therefore new Java packages,

all prefixed by "org.eclipse.papyrus.sysml14" instead of good old "org.eclipse.papyrus.sysml"

I am a bit afraid of the consequences of this choice:

I don't like it very much that the profile version be encoded in the corresponding Java packages.

It will force all client code of the static profile to be updated (including Papyrus SysML diagram editors), even for those parts that haven't changed.

Do you imagine fixing all UML2-dependent code each time the UML2 project migrate to a new version of the UML standard?

Will this have to be done again if/when SysML 1.5 or 2.0 is released?

Wouldn't it be possible to adopt an approach to versioning more similar to what is done by the UML2 project?

 

I've also noticed that the two deprecated stereotypes (FlowPort and FlowSpecification) have been moved to their own sub-package in the profile.

Again, this will impact all client code to use classes from package "org.eclipse.papyrus.sysml14.deprecatedelements".

Moreover, section C3.2 of the SysML 1.4 specification does not mandate a separated package for those 2 stereotypes.

On the contrary, it states that those two stereotypes still belong to package Ports&Flows, like they always did.

Since they were kept as deprecated to ease migration, I would make sense to also leave them where they were in the Java namespace,

to ease Java code migration too, and just have them marked as @Deprecated to identify the risk of still using them.

 

I can understand that there are advantages to having different Java namespaces for two different versions of the static APIs,

if only to have both sets of classes available in a single class loader to write migration code in Java, for example.

But instead, the old version(s) of the profile could maybe be kept as dynamic profile(s), while only the most recent version would be static, with a constant Java namespace.

That way, in a context with both old and new stereotype applications, legacy ones could still be accessed as DynamicEObject,

and manipulated as usual via any mechanism based on dynamic EMF.

 

What do you think?

 

Best regards,

--

Alain Le Guennec, R&D Expert Engineer

SCADE System Project Manager

Esterel Technologies, a wholly-owned subsidiary of ANSYS, Inc.

 

 


_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev



--
Alain Le Guennec, R&D Expert Engineer
SCADE System Project Manager
Esterel Technologies, a wholly-owned subsidiary of ANSYS, Inc.
Tel: +33 5 34 60 90 55
----------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. 

Back to the top