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

Maybe renaming sysml to syml11 would not bring much indeed and could harm cherry-picking. I have no strong opinion about that.
But putting the new stuff in sysml14 could still make sense to avoid confusion.

As for Java namespaces, some more arguments in favor of *not* using a new Java namespace:
-It would probably be quite cheap to get the "old" BDD & IBD editors up-and-running again very quickly on top of SysML 1.4,
 for the subset of SysML 1.4 (including deprecated stuff) corresponding to SysML 1.1.
 Basically, only support for Unit and Dimension would have to be redone to use the new Unit & QuantityKind predefined blocks, and handling of conjugated ports would have to be aligned with UML 2.5.
 The rest should work almost as-is.
 This would allow to decouple SysML upgrade and editor technology upgrade.
-We do have quite a lot of edit helper advices for restricting SysML to our particular usage context and to maintain complex inter-dependent model subsets consistent.
 During the migration/evaluation phase, we would have to duplicate them all and maintain both sets until we decide which version we will use for our version based on Mars.

As for (semantic) migration, it seems to me that the hardest part of the work is migrating flow ports & flow spec to use the new idioms, but since those concepts are supported as deprecated, there is no obligation to do that at load time
(and probably some wizard to help to migrate interactively after the fact would be better anyway, to not force migration away of those deprecated concepts if not desired). So I don't think the risk is big on that subject.

Best regards,

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

Hi,


I don’t really know; I guess this depends a lot on the progress we’ll be able to make for Mars
. Currently SysML 1.4 is planned to be a complete rewriting compared to SysML 1.1, so we don’t want to force one or the other (yet).


Having both at the same time may be useful as a first step, to let early adopters test the new one and still be able to use the stable one. I’m not sure what each user would do, and I don’t think anyone does, so let’s be safe and not mix everything up.

 

Once we are satisfied enough with the new version, we can consider changing the layout, deprecating the 1.1 version and so on. Until then, SysML14 is barely a first implementation of the profile itself, without any support of any kind, so it’s too early to even think about compatibility, migration and deprecation.

 

Also, moving SysML 1.1 to a different folder will not help merge/pick operations, and we still have to maintain both the Luna and Mars development branches; so that’s probably too early. Moving SysML 1.4 to a different folder would be fine though, but we should keep a separate namespace for now, and probably as long as we have to maintain (develop) both in Papyrus.

 

Regards,
Camille

__________________________

Camille Letavernier

+33 (0)1 69 08 00 59 - camille.letavernier@xxxxxx

CEA LIST - Laboratoire d'Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE)

Papyrus : http://www.eclipse.org/papyrus

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Alain Le Guennec
Envoyé : jeudi 15 janvier 2015 17:10
À : Papyrus Project list
Objet : 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.

----------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------

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. 


_______________________________________________
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


Back to the top