Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » Papyrus and Amalgam(Synergy)
Papyrus and Amalgam [message #499379] Sat, 21 November 2009 15:50 Go to next message
Ioan Salau is currently offline Ioan SalauFriend
Messages: 69
Registered: July 2009
Location: Toronto
Member

I attended Papyrus presentation session at Eclipse Modeling Day in Toronto and I noticed that Papyrus scope somehow overlaps with Amalgam scope. I have been told that Amalgam project may have some difficulties as the lead of the projects stepped down.
Anyway, I really liked the idea of Amalgam to focus on DSL Toolkit and provide an integrated framework to build and use DSLs not necessary based on UML with Profiles but using GMF/XText/Acceleo/M2M. On the other hand, Papyrus plan is to focus more on UML with Profiles.
Is there any plan for Papyrus to eventually take over the Amalgam idea to build a framework similar with Amalgam/DSL Toolkit?

Thanks,

Ioan
Re: Papyrus and Amalgam [message #499530 is a reply to message #499379] Mon, 23 November 2009 09:29 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
I don't know about this Eclipse project technological orientation but it seems to me that targeting UML profiles and not DSL is the right choice.

Don't forget that Microsoft has just stopped its Oslo project which has been merged with SQL teams and no more large investment are planned into this DSL modeling approach.

Omondo is also totally opposed to DSL because it is a major draw back on the adoption of a common and powerful metamodel (e.g. EclipseUML2). Generating specific DSL serialization with EMF makes it impossible to reuse this model. UML is a common language for the entire community, and adding profiles with stereotype make the model even more accurate for specific industries without loosing interoperability.

The next step would be to change the graphical presentation depending on stereotypes or profiles and not to change the entire underlying metamodel !!

Vlad,
Omondo
Re: Papyrus and Amalgam [message #499574 is a reply to message #499379] Mon, 23 November 2009 11:38 Go to previous messageGo to next message
Raphael Faudou is currently offline Raphael FaudouFriend
Messages: 105
Registered: July 2009
Senior Member
Hi Ioan,

it is in the scope of MDT Papyrus to support both profile-base and
DSL-based editors.
regards
raphaël

Ioan a écrit :
> I attended Papyrus presentation session at Eclipse Modeling Day in
> Toronto and I noticed that Papyrus scope somehow overlaps with Amalgam
> scope. I have been told that Amalgam project may have some difficulties
> as the lead of the projects stepped down. Anyway, I really liked the
> idea of Amalgam to focus on DSL Toolkit and provide an integrated
> framework to build and use DSLs not necessary based on UML with Profiles
> but using GMF/XText/Acceleo/M2M. On the other hand, Papyrus plan is to
> focus more on UML with Profiles. Is there any plan for Papyrus to
> eventually take over the Amalgam idea to build a framework similar with
> Amalgam/DSL Toolkit?
> Thanks,
>
> Ioan
Re: Papyrus and Amalgam [message #499577 is a reply to message #499530] Mon, 23 November 2009 11:53 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Vlad,

Comments below.

Vlad Varnica wrote:
> I don't know about this Eclipse project technological orientation but
> it seems to me that targeting UML profiles and not DSL is the right
> choice.
Yes, yes, anything that isn't directly and exclusively using UML is
bad. We know your view on this.
>
> Don't forget that Microsoft has just stopped its Oslo project which
> has been merged with SQL teams and no more large investment are
> planned into this DSL modeling approach.
I'm sure the Olso folks are disappointed.
> Omondo is also totally opposed to DSL because it is a major draw back
> on the adoption of a common and powerful metamodel (e.g. EclipseUML2).
And that's a problem why?
> Generating specific DSL serialization with EMF makes it impossible to
> reuse this model.
That's complete rubbish. The OMG defines MOF and XMI serialization
based on MOF models. That's how UML itself is defined...
> UML is a common language for the entire community,
So is MOF.
> and adding profiles with stereotype make the model even more accurate
> for specific industries without loosing interoperability.
As we found out at the modeling days, the use of the UML APIs is
extremely complicated and gets in the way of writing clear templates.
Needing to pull profile information is even worse.
>
> The next step would be to change the graphical presentation depending
> on stereotypes or profiles and not to change the entire underlying
> metamodel !!
You're certainly entitled to your opinion, but it's unlikely to sway
anyone. In any case, we're talking here about providing a reusable
technology layer that would be specialized by Papyrus to support UML but
could also be specialized to support Ecore, XSD, BPMN and any number of
those horrible non-UML.
>
> Vlad,
> Omondo


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Papyrus and Amalgam [message #499605 is a reply to message #499577] Mon, 23 November 2009 14:23 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Ed and Raphael,

My conviction is that too many models are decreasing project productivty Sad

Imagine that you have a DSL project, an UML project or a BPMN project. All this project are not compatible and this is like totally different projects even if they are used inside the same project.
This multiple models using multiple metamodels are an incredible waste of time breaking compatibility.

UML should map all project information to the meta model at the biginning of the modeling cycle and even map business rules using constraints, web service by expanding the state or activity diagrams and add SOA directly in the class diagram etc..

UML can integrate DSL using UML profiles or BPMN using State/Activity diagrams using an agile methodology therefore I like UML Very Happy

Vlad,
Omondo
Re: Papyrus and Amalgam [message #499652 is a reply to message #499605] Mon, 23 November 2009 15:39 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Vlad,

Comments below.

Vlad Varnica wrote:
> Ed and Raphael,
>
> My conviction is that too many models are decreasing project
> productivty :(
> Imagine that you have a DSL project, an UML project or a BPMN project.
> All this project are not compatible and this is like totally different
> projects even if they are used inside the same project. This multiple
> models using multiple metamodels are an incredible waste of time
> breaking compatibility.
Most people hold the conviction that you need to right tool for the
right job and that one-size-fits-all reasoning is questionable at best.
>
> UML should map all project information to the meta model at the
> biginning of the modeling cycle and even map business rules using
> constraints, web service by expanding the state or activity diagrams
> and add SOA directly in the class diagram etc..
It's a tough sell to argue this perspective and unfortunately this type
of over zealous promotion of UML is what tends to give modeling a bad
reputation, particularly in North America. UML has simply not delivered
on this promise.
>
> UML can integrate DSL using UML profiles or BPMN using State/Activity
> diagrams using an agile methodology therefore I like UML :d
All this reminds me of Dilbert where the porcupine's solution to all
problems is "We must stick them with quills! It's the only way!" I
suppose it's human nature to behave in this way...
> Vlad,
> Omondo
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Papyrus and Amalgam [message #499669 is a reply to message #499530] Mon, 23 November 2009 16:31 Go to previous messageGo to next message
Ioan Salau is currently offline Ioan SalauFriend
Messages: 69
Registered: July 2009
Location: Toronto
Member

Vlad Varnica wrote on Mon, 23 November 2009 04:29
I don't know about this Eclipse project technological orientation but it seems to me that targeting UML profiles and not DSL is the right choice.

Don't forget that Microsoft has just stopped its Oslo project which has been merged with SQL teams and no more large investment are planned into this DSL modeling approach.

Omondo is also totally opposed to DSL because it is a major draw back on the adoption of a common and powerful metamodel (e.g. EclipseUML2). Generating specific DSL serialization with EMF makes it impossible to reuse this model. UML is a common language for the entire community, and adding profiles with stereotype make the model even more accurate for specific industries without loosing interoperability.

The next step would be to change the graphical presentation depending on stereotypes or profiles and not to change the entire underlying metamodel !!

Vlad,
Omondo


Hi Vlad,
Although I do see your point allow me to disagree with you. UML2 and DSL are totally opposite as scope, yet each one provides usefull tools to achieve your scope. In my vision of MDSD Workbench, UML2 is only yet another graphical concrete syntax for my abstract syntax domain model, while the DSL can provide alternative concrete syntaxes (textual or graphical). Depending on who is your target market, different concrete syntax may be the best way to simplify the process. I have hard time to imagine how can you model efficiently complex expressions with UML2, but I can see how easy is to model a sequence flow or class diagram.
Also, I do not understand how using EMF will somehow limit your interoperability. That's why you have QVT M2M, any time you can translate between EMF model to UML2 or even to other models invented or not invented yet. The most important thing is to capture information in a formal way, rather then get stuck into the flavours of metamodling. EMF migth not be perfect for everything, but so far it helped me a lot and I think is a great project with a huge support from open source and commercial community.
In the end, is not you who can decide what is the best for my project, is not even me or Ed Merks, but the end customer of my project.

Regards,

Ioan

Re: Papyrus and Amalgam [message #499694 is a reply to message #499574] Mon, 23 November 2009 18:25 Go to previous messageGo to next message
Ioan Salau is currently offline Ioan SalauFriend
Messages: 69
Registered: July 2009
Location: Toronto
Member

Raphael Faudou wrote on Mon, 23 November 2009 06:38
Hi Ioan,

it is in the scope of MDT Papyrus to support both profile-base and
DSL-based editors.
regards
raphaël




Hi Raphaël,
I understand that MDT Papyrus will support DSL-based editors, however the Amalgam project defined specific roles (i.e. Toolsmith, Modeler etc) and each one would get a different set of tools. Even though Amalgam packages many existing EMF-based tools, there are some plugins/features developed under Amalgam project. Are you going to extend current Amalgam project or is going to be different Papyrus plugins/features for DSL based editors? The reason I am asking, I want to know if I should use Amalgam project or wait for Papyrus DSL based plugins. And the statement on Papyrus web site that initially Papyrus is going to focus on UML2 does't sound appealing for me Smile

Thanks,

Ioan
Re: Papyrus and Amalgam [message #499735 is a reply to message #499694] Mon, 23 November 2009 21:33 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Ioan,

The main difference between us is that we make technological decisions based on our personal convictions while an integrator make decision based on project demands and then sell days of integration/consulting.
Too many models and meta models are not productive, that's a definitive no go for DSL, BPMN etc...

btw, if you find a customer who wants to pay hundreds of days of consulting/integrations and not to finish the modeling stage project in just few days then I fully understand your post.
I would certainly do the same as you if I was working for an integrator or for an end customer Smile

Vlad
Omondo

Re: Papyrus and Amalgam [message #499740 is a reply to message #499735] Mon, 23 November 2009 21:56 Go to previous messageGo to next message
Ioan Salau is currently offline Ioan SalauFriend
Messages: 69
Registered: July 2009
Location: Toronto
Member

Vlad Varnica wrote on Mon, 23 November 2009 16:33

The main difference between us is that we make technological decisions based on our personal convictions while an integrator make decision based on project demands and then sell days of integration/consulting.



I do have personal convictions as well; I just don't let them blind me when I choose the right approach for my customers. I leave this task to religious prophets. Anytime, you can find pros and cons to use a certain technology, therefore claiming that only one way is the right way just doesn't sound right.

Vlad Varnica wrote on Mon, 23 November 2009 16:33


Too many models and meta models are not productive, that's a definitive no go for DSL, BPMN etc...




The number of models/metamodels doesn't matter ... If you have only one big fat model/metamodel, how is this easier to handle? Usually, the complexity comes from your business domain and all you have to do is try to simplify as much as possible but no more than that Smile

Vlad Varnica wrote on Mon, 23 November 2009 16:33


btw, if you find a customer who wants to pay hundreds of days of consulting/integrations and not to finish the modeling stage project in just few days then I fully understand your post.




This is quite a statement. Why do you think that the only way to implement a product using EMF and not OmondoUML2 is to rip off the customers? I certainly don't plan for such thing, EMF modeling is quite easy and for sure it doesn't take hundreds of billable days to finish modeling stage. Also, on my vision, once you finish the modeling stage, the project is pretty much finished as well.

Vlad Varnica wrote on Mon, 23 November 2009 16:33


I would certainly do the same as you if I was working for an integrator or for an end customer Smile

Vlad
Omondo




I am sure you would do, just don't assume I do the same Smile


Regards,

Ioan

[Updated on: Tue, 24 November 2009 06:17]

Report message to a moderator

Re: Papyrus and Amalgam [message #499818 is a reply to message #499740] Tue, 24 November 2009 09:48 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Quote:
The number of models/metamodels doesn't matter ... If you have only one big fat model/metamodel, how is this easier to handle? Usually, the complexity comes from your business domain and all you have to do is try to simplify as much as possible but no more than that Smile


This is exactly what should not be done !! The more models the more complexity and needs for transformation. I have seen a merge of projects being stuck for more than 200 days just trying to merge models and multiple projects. We have done the job in 10 minutes with a very big model Shocked

UML modeling has failed because of multiples models and transformation. It is not time to run away to another technology (e.g. DSL ) but be responsible and assume our mistakes (e.g. UML profiles developed since 2002 at the OMG). It is always the same old story saying that "it failed so I leave immediately and start something new". This is when it fails that the job start and that the technology is getting mature !!

Quote:
I certainly don't plan for such thing, EMF modeling is quite easy and for sure it doesn't take hundreds of billable days to finish modeling stage. Also, on my vision, once you finish the modeling stage, the project is pretty much finished as well.


EMF is not easy and could become a nightmare if you don't invest a lot of time. We needed more than 24 months just to train young engineer to use EMF the right way. D
o you have 24 months ? I don't think so therefore the best is to immediately call an EMF consultant at the beginning of the project because your project will certainly fail without him.

Once the modeling stage is finished you have about 70% of your code. You still need to add manually 30%. The problem I see is that if you add the code manually to change classifiers then you can not generate again your code from EMF. Again, don't forget to ask because what you think is easy is certainly not !! Your team manually codding should also understand where to code because the EMF code generation is sometimes very complex and add hundred of classifiers. This is a good approach to divide object of your project but the complexity is increasing.

For example within Omondo a developer is not allowed to code alone before 18 months and understanding the full architecture. Even after the initial EMF model is so complex that we never 100% certain where are going all the calls and why ? This is the advantage of code generation and also the main disadvantage.
Re: Papyrus and Amalgam [message #499914 is a reply to message #499818] Tue, 24 November 2009 14:09 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Vlad,

Comments below.

Vlad Varnica wrote:
> Quote:
>> The number of models/metamodels doesn't matter ... If you have only
>> one big fat model/metamodel, how is this easier to handle? Usually,
>> the complexity comes from your business domain and all you have to do
>> is try to simplify as much as possible but no more than that Smile
>
>
> This is exactly what should not be done !!
So you keep asserting, but reality flies in the face of this...
> The more models the more complexity and needs for transformation.
You keep talking about transformations as a bad thing, but a guy has to
wonder what you imagine people doing with their models. Make a pretty
picture from it and then stare at that? In the end models are used to
do something useful. They're analyzed or interpreted or something is
generated from them. For example, I define a modeling of XML Schema so
I can read, write, and manipulate schema instances. How exactly will
profiled UML help with this task?
> I have seen a merge of projects being stuck for more than 200 days
> just trying to merge models and multiple projects.
Merging seems to be another one of your obsessions. I'm not sure why.
> We have done the job in 10 minutes with a very big model 8o
> UML modeling has failed because of multiples models and transformation.
UML's complexity hasn't helped nor has over zealous promotion. And, as
I said earlier, I'm not sure what you expect people to do with their
models. Transforming them is often the entire reason for their existance.
> It is not time to run away to another technology (e.g. DSL ) but be
> responsible and assume our mistakes (e.g. UML profiles developed since
> 2002 at the OMG).
I don't believe the mistake lies in exploring technologies other than UML.
> It is always the same old story saying that "it failed so I leave
> immediately and start something new". This is when it fails that the
> job start and that the technology is getting mature !!
UML is very good for some things, perhaps even for a great many things,
but it's not ideal for all things. Anyone who argues otherwise will be
met with skepticism at best...
>
> Quote:
>> I certainly don't plan for such thing, EMF modeling is quite easy and
>> for sure it doesn't take hundreds of billable days to finish modeling
>> stage. Also, on my vision, once you finish the modeling stage, the
>> project is pretty much finished as well.
>
>
> EMF is not easy and could become a nightmare if you don't invest a lot
> of time.
Yet you need to use it to use UML. There's no avoiding that...
> We needed more than 24 months just to train young engineer to use EMF
> the right way. D
Your vacuous assertions are so tiresome...
> o you have 24 months ? I don't think so therefore the best is to
> immediately call an EMF consultant at the beginning of the project
> because your project will certainly fail without him.
I appreciate the advertisement for my paid services, but experience
tells me there are a great many successful projects that have never paid
a dime for consulting. Sometimes they're successful without ever having
asked a newsgroup question. Perhaps you should be less inclined to
project your failures onto others.
>
> Once the modeling stage is finished you have about 70% of your code.
> You still need to add manually 30%. The problem I see is that if you
> add the code manually to change classifiers then you can not generate
> again your code from EMF.
Hello? It's a merging generator. We do this ourselves constantly.
> Again, don't forget to ask because what you think is easy is certainly
> not !! Your team manually codding should also understand where to code
> because the EMF code generation is sometimes very complex and add
> hundred of classifiers.
That depends on the complexity of the model, not the complexity of the
generator.
> This is a good approach to divide object of your project but the
> complexity is increasing.
This is another one of those ungrammatical sentences from which meaning
cannot be derived.
> For example within Omondo a developer is not allowed to code alone
> before 18 months and understanding the full architecture. Even after
> the initial EMF model is so complex that we never 100% certain where
> are going all the calls and why ? This is the advantage of code
> generation and also the main disadvantage.
It should come as no surprised that life is a trade-off of pros and cons.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Papyrus and Amalgam [message #595058 is a reply to message #499577] Mon, 23 November 2009 14:23 Go to previous message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Ed and Raphael,

My conviction is that too many models are decreasing project productivty :(

Imagine that you have a DSL project, an UML project or a BPMN project. All this project are not compatible and this is like totally different projects even if they are used inside the same project.
This multiple models using multiple metamodels are an incredible waste of time breaking compatibility.

UML should map all project information to the meta model at the biginning of the modeling cycle and even map business rules using constraints, web service by expanding the state or activity diagrams and add SOA directly in the class diagram etc..

UML can integrate DSL using UML profiles or BPMN using State/Activity diagrams using an agile methodology therefore I like UML :d

Vlad,
Omondo
Re: Papyrus and Amalgam [message #595069 is a reply to message #595058] Mon, 23 November 2009 15:39 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Vlad,

Comments below.

Vlad Varnica wrote:
> Ed and Raphael,
>
> My conviction is that too many models are decreasing project
> productivty :(
> Imagine that you have a DSL project, an UML project or a BPMN project.
> All this project are not compatible and this is like totally different
> projects even if they are used inside the same project. This multiple
> models using multiple metamodels are an incredible waste of time
> breaking compatibility.
Most people hold the conviction that you need to right tool for the
right job and that one-size-fits-all reasoning is questionable at best.
>
> UML should map all project information to the meta model at the
> biginning of the modeling cycle and even map business rules using
> constraints, web service by expanding the state or activity diagrams
> and add SOA directly in the class diagram etc..
It's a tough sell to argue this perspective and unfortunately this type
of over zealous promotion of UML is what tends to give modeling a bad
reputation, particularly in North America. UML has simply not delivered
on this promise.
>
> UML can integrate DSL using UML profiles or BPMN using State/Activity
> diagrams using an agile methodology therefore I like UML :d
All this reminds me of Dilbert where the porcupine's solution to all
problems is "We must stick them with quills! It's the only way!" I
suppose it's human nature to behave in this way...
> Vlad,
> Omondo
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Papyrus and Amalgam [message #595091 is a reply to message #499574] Mon, 23 November 2009 18:25 Go to previous message
Ioan Salau is currently offline Ioan SalauFriend
Messages: 69
Registered: July 2009
Location: Toronto
Member

Raphael Faudou wrote on Mon, 23 November 2009 06:38
> Hi Ioan,
>
> it is in the scope of MDT Papyrus to support both profile-base and
> DSL-based editors.
> regards
> raphaël


Hi Raphaël,
I understand that MDT Papyrus will support DSL-based editors, however the Amalgam project defined specific roles (i.e. Toolsmith, Modeler etc) and each one would get a different set of tools. Even though Amalgam packages many existing EMF-based tools, there are some plugins/features developed under Amalgam project. Are you going to extend current Amalgam project or is going to be different Papyrus plugins/features for DSL based editors? The reason I am asking, I want to know if I should use Amalgam project or wait for Papyrus DSL based plugins. And the statement on Papyrus web site that initially Papyrus is going to focus on UML2 does't sound appealing for me :)

Thanks,

Ioan
Re: Papyrus and Amalgam [message #595093 is a reply to message #499694] Mon, 23 November 2009 21:33 Go to previous message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Ioan,

The main difference between us is that we make technological decisions based on our personal convictions while an integrator make decision based on project demands and then sell days of integration/consulting.
Too many models and meta models are not productive, that's a definitive no go for DSL, BPMN etc...

btw, if you find a customer who wants to pay hundreds of days of consulting/integrations and not to finish the modeling stage project in just few days then I fully understand your post.
I would certainly do the same as you if I was working for an integrator or for an end customer :)

Vlad
Omondo
Re: Papyrus and Amalgam [message #596051 is a reply to message #595093] Mon, 23 November 2009 21:56 Go to previous message
Ioan Salau is currently offline Ioan SalauFriend
Messages: 69
Registered: July 2009
Location: Toronto
Member

Vlad Varnica wrote on Mon, 23 November 2009 16:33
> The main difference between us is that we make technological decisions based on our personal convictions while an integrator make decision based on project demands and then sell days of integration/consulting.


I do have personal convictions as well; I just don't let them blind me when I choose the right approach for my customers. I leave this task to religious prophets. Anytime, you can find pros and cons to use a certain technology, therefore claiming that only one way is the right way just doesn't sound right.

Vlad Varnica wrote on Mon, 23 November 2009 16:33
> Too many models and meta models are not productive, that's a definitive no go for DSL, BPMN etc...


The number of models/metamodels doesn't matter ... If you have only one big fat model/metamodel, how is this easier to handle? Usually, the complexity comes from your business domain and all you have to do is try to simplify as much as possible but no more than that :)

Vlad Varnica wrote on Mon, 23 November 2009 16:33
> btw, if you find a customer who wants to pay hundreds of days of consulting/integrations and not to finish the modeling stage project in just few days then I fully understand your post.


This is quite a statement. Why do you think that the only way to implement a product using EMF and not OmondoUML2 is to rip off the customers? I certainly don't plan for such thing, EMF modeling is quite easy and for sure it doesn't take hundreds of billable days to finish modeling stage. Also, on my vision, once you finish the modeling stage, the project is pretty much finished as well.

Vlad Varnica wrote on Mon, 23 November 2009 16:33
> I would certainly do the same as you if I was working for an integrator or for an end customer :)
>
> Vlad
> Omondo


I am sure you would do, just don't assume I do rip off my customers like you do with yours :)


Regards,

Ioan
Re: Papyrus and Amalgam [message #596059 is a reply to message #596051] Tue, 24 November 2009 09:48 Go to previous message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Quote:
> The number of models/metamodels doesn't matter ... If you have only one big fat model/metamodel, how is this easier to handle? Usually, the complexity comes from your business domain and all you have to do is try to simplify as much as possible but no more than that Smile


This is exactly what should not be done !! The more models the more complexity and needs for transformation. I have seen a merge of projects being stuck for more than 200 days just trying to merge models and multiple projects. We have done the job in 10 minutes with a very big model 8o

UML modeling has failed because of multiples models and transformation. It is not time to run away to another technology (e.g. DSL ) but be responsible and assume our mistakes (e.g. UML profiles developed since 2002 at the OMG). It is always the same old story saying that "it failed so I leave immediately and start something new". This is when it fails that the job start and that the technology is getting mature !!

Quote:
> I certainly don't plan for such thing, EMF modeling is quite easy and for sure it doesn't take hundreds of billable days to finish modeling stage. Also, on my vision, once you finish the modeling stage, the project is pretty much finished as well.


EMF is not easy and could become a nightmare if you don't invest a lot of time. We needed more than 24 months just to train young engineer to use EMF the right way. D
o you have 24 months ? I don't think so therefore the best is to immediately call an EMF consultant at the beginning of the project because your project will certainly fail without him.

Once the modeling stage is finished you have about 70% of your code. You still need to add manually 30%. The problem I see is that if you add the code manually to change classifiers then you can not generate again your code from EMF. Again, don't forget to ask because what you think is easy is certainly not !! Your team manually codding should also understand where to code because the EMF code generation is sometimes very complex and add hundred of classifiers. This is a good approach to divide object of your project but the complexity is increasing.

For example within Omondo a developer is not allowed to code alone before 18 months and understanding the full architecture. Even after the initial EMF model is so complex that we never 100% certain where are going all the calls and why ? This is the advantage of code generation and also the main disadvantage.
Re: Papyrus and Amalgam [message #596070 is a reply to message #499818] Tue, 24 November 2009 14:09 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Vlad,

Comments below.

Vlad Varnica wrote:
> Quote:
>> The number of models/metamodels doesn't matter ... If you have only
>> one big fat model/metamodel, how is this easier to handle? Usually,
>> the complexity comes from your business domain and all you have to do
>> is try to simplify as much as possible but no more than that Smile
>
>
> This is exactly what should not be done !!
So you keep asserting, but reality flies in the face of this...
> The more models the more complexity and needs for transformation.
You keep talking about transformations as a bad thing, but a guy has to
wonder what you imagine people doing with their models. Make a pretty
picture from it and then stare at that? In the end models are used to
do something useful. They're analyzed or interpreted or something is
generated from them. For example, I define a modeling of XML Schema so
I can read, write, and manipulate schema instances. How exactly will
profiled UML help with this task?
> I have seen a merge of projects being stuck for more than 200 days
> just trying to merge models and multiple projects.
Merging seems to be another one of your obsessions. I'm not sure why.
> We have done the job in 10 minutes with a very big model 8o
> UML modeling has failed because of multiples models and transformation.
UML's complexity hasn't helped nor has over zealous promotion. And, as
I said earlier, I'm not sure what you expect people to do with their
models. Transforming them is often the entire reason for their existance.
> It is not time to run away to another technology (e.g. DSL ) but be
> responsible and assume our mistakes (e.g. UML profiles developed since
> 2002 at the OMG).
I don't believe the mistake lies in exploring technologies other than UML.
> It is always the same old story saying that "it failed so I leave
> immediately and start something new". This is when it fails that the
> job start and that the technology is getting mature !!
UML is very good for some things, perhaps even for a great many things,
but it's not ideal for all things. Anyone who argues otherwise will be
met with skepticism at best...
>
> Quote:
>> I certainly don't plan for such thing, EMF modeling is quite easy and
>> for sure it doesn't take hundreds of billable days to finish modeling
>> stage. Also, on my vision, once you finish the modeling stage, the
>> project is pretty much finished as well.
>
>
> EMF is not easy and could become a nightmare if you don't invest a lot
> of time.
Yet you need to use it to use UML. There's no avoiding that...
> We needed more than 24 months just to train young engineer to use EMF
> the right way. D
Your vacuous assertions are so tiresome...
> o you have 24 months ? I don't think so therefore the best is to
> immediately call an EMF consultant at the beginning of the project
> because your project will certainly fail without him.
I appreciate the advertisement for my paid services, but experience
tells me there are a great many successful projects that have never paid
a dime for consulting. Sometimes they're successful without ever having
asked a newsgroup question. Perhaps you should be less inclined to
project your failures onto others.
>
> Once the modeling stage is finished you have about 70% of your code.
> You still need to add manually 30%. The problem I see is that if you
> add the code manually to change classifiers then you can not generate
> again your code from EMF.
Hello? It's a merging generator. We do this ourselves constantly.
> Again, don't forget to ask because what you think is easy is certainly
> not !! Your team manually codding should also understand where to code
> because the EMF code generation is sometimes very complex and add
> hundred of classifiers.
That depends on the complexity of the model, not the complexity of the
generator.
> This is a good approach to divide object of your project but the
> complexity is increasing.
This is another one of those ungrammatical sentences from which meaning
cannot be derived.
> For example within Omondo a developer is not allowed to code alone
> before 18 months and understanding the full architecture. Even after
> the initial EMF model is so complex that we never 100% certain where
> are going all the calls and why ? This is the advantage of code
> generation and also the main disadvantage.
It should come as no surprised that life is a trade-off of pros and cons.


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:Papyrus and Amalgam
Next Topic:How can I enter satisfies relations from model elements to requirements?
Goto Forum:
  


Current Time: Thu Mar 28 12:04:37 GMT 2024

Powered by FUDForum. Page generated in 0.04870 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top