Author Topic: refactoring/ moving operations to another class  (Read 5141 times)

KalpakD

  • EA User
  • **
  • Posts: 37
  • Karma: +0/-0
    • View Profile
refactoring/ moving operations to another class
« on: July 21, 2021, 12:16:59 am »
I have a operation in one class which I want to move to another class.
There is an activity diagram associated with this operation.
How do I move the operation and it connected activity diagram to another class?
thanks,

qwerty

  • EA Guru
  • *****
  • Posts: 12263
  • Karma: +346/-285
  • I'm no guru at all
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #1 on: July 21, 2021, 01:02:41 am »
Well, the operation cam simply be dragged in the browser. I seem to remember that call behavior and operation are linked via the guid, so that link should be kept. Else you would need to knot it once again via alt-l or the like.

q.

KalpakD

  • EA User
  • **
  • Posts: 37
  • Karma: +0/-0
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #2 on: July 21, 2021, 05:51:46 pm »
Yes, the dragging moved the activity diagram, but the code would not get generated for it.
So, simply created a new operation the destination class.
Then added a activity diagram and copy pasted the old group of action elements into it.
Code was created in the destination class file.
That is sufficient.
thanks,

qwerty

  • EA Guru
  • *****
  • Posts: 12263
  • Karma: +346/-285
  • I'm no guru at all
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #3 on: July 21, 2021, 08:01:07 pm »
Somehow I still have the feeling that you did not get the point with diagrams. Anyhow, if you can live with that so be it.

q.

KalpakD

  • EA User
  • **
  • Posts: 37
  • Karma: +0/-0
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #4 on: July 21, 2021, 11:16:24 pm »
If my process of code generation is wrong, pl point me to a suitable document to do it correctly.

Normally code runs on real world systems not UML.
So, if code generation is not part of final evolution of UML then I don't understand why this tool has code generation and differential pricing for various levels of code generations.
I could have happily continued with UML tools I already use to create models and extracted the text to paste as comments in program files.
I have been doing this for the embedded systems I have been developing.


qwerty

  • EA Guru
  • *****
  • Posts: 12263
  • Karma: +346/-285
  • I'm no guru at all
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #5 on: July 21, 2021, 11:52:01 pm »
A broad one. Just the fact that Sparx sells something it does not mean it's useful. Coding and modeling are two different worlds. And an architect's task is to build bridges between both. Those can be designed in many ways. You can use EA for generating code, but that of course is only half the truth (or less). Coders do not develop in UML tools, they use IDEs - for good reasons. Now the UML tool is excellent to lay the fundaments where coders can start building. Usually, without careful observation, they gallop off and never come back to the model itself. It's kind of tricky to get them maintaining the model (especially when they have to fiddle with moving messages in sequence diagrams). Well, it's a long story and to no end. Just to think you have a tool to generate code will shipwreck the next project.

q.

KalpakD

  • EA User
  • **
  • Posts: 37
  • Karma: +0/-0
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #6 on: July 22, 2021, 02:53:23 pm »
Firstly, thanks for the heads up on code quality.
But then I am aware no tool is really perfect, it takes time to improve.
I have grown up doing machine coding on hex pad.
And have always done some level of design, called flowcharts in the good old bad days.

Early compilers were also not perfect.
Assembly code generated had to be inspected and needed some level of code "tuning".
Even today sometimes optimization can be excessive and go haywire.

So, taking another view, long ago the world moved to 3D printing from a CAD model
Today the parts are usable as is. Even medical devices and aircraft components.
Effectively reducing the role of a fabricator/ machine operator.
Or blurring the lines between the designer and implementer.

We should also think the same way.
Right now, I will be happy to get all the text in an action element as a comment into the code file.
That will make the intent of the designer / architect far more obvious.
Especially the structure of code expected.
Thereby, getting as close to the final code as possible.
regards,

qwerty

  • EA Guru
  • *****
  • Posts: 12263
  • Karma: +346/-285
  • I'm no guru at all
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #7 on: July 22, 2021, 04:27:30 pm »
Since you spoke of 3D printing. I once built myself a printer from scratch (wood, aluminium, rods, etc. later refined with self-printed parts). So I know that 3D printing is some kind of progress, but into some different dimension. With different ways to fail. Just another way to fail better.

q.

KalpakD

  • EA User
  • **
  • Posts: 37
  • Karma: +0/-0
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #8 on: August 04, 2021, 07:04:12 pm »
Code quality seems to be a problem.
Arbitrarily, there is an "if" statement added though there is no decision element in the activity diagram.
And support takes too long to reply.

qwerty

  • EA Guru
  • *****
  • Posts: 12263
  • Karma: +346/-285
  • I'm no guru at all
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #9 on: August 04, 2021, 07:13:31 pm »
Code quality at Sparx? You have mistaken something here. YOU are the QA.

q.

P.S.: There is that meme about product prices: if you don't pay for the product, you are the product. Similarly, if you pay low prices you get low quality. So I shouldn't cry, should I?
« Last Edit: August 04, 2021, 07:16:02 pm by qwerty »

KalpakD

  • EA User
  • **
  • Posts: 37
  • Karma: +0/-0
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #10 on: August 06, 2021, 06:14:34 pm »
P.S.: There is that meme about product prices: if you don't pay for the product, you are the product. Similarly, if you pay low prices you get low quality. So I shouldn't cry, should I?

I don't understand your comment "...pay for the product...".
I paid the price of the edition that Sparx recommended for this feature.

Right I now I am worse off than the Visual Paradigm standard edition that I own.
In that I can get code for a class.
I can also export the complex activity diagrams and copy the text as comments into the code  file.
Whereas, with EA I cannot even link 2 activity diagrams.

qwerty

  • EA Guru
  • *****
  • Posts: 12263
  • Karma: +346/-285
  • I'm no guru at all
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #11 on: August 06, 2021, 06:22:58 pm »
The key is the "similarly". The price for EA is low (which is good on the one side) so its quality is low (the drawback).

q.

KalpakD

  • EA User
  • **
  • Posts: 37
  • Karma: +0/-0
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #12 on: August 08, 2021, 09:57:11 pm »
Then recommend a better version of EA or a better product.

qwerty

  • EA Guru
  • *****
  • Posts: 12263
  • Karma: +346/-285
  • I'm no guru at all
    • View Profile
Re: refactoring/ moving operations to another class
« Reply #13 on: August 09, 2021, 03:15:01 am »
Well, the term "better" depends. There are other products out there. All more pricey and all with a differnt set of flaws. I don't have a comparison. I just had been using Rational Rose and ArgoUML at around 2000. The first is now some IBM Java monster and the 2nd is still dead. Some colleagues have been using other products like Cameo or (forgot the name, started with A, didn't it?) which was/is standard in aeronautic industry. None of them in a price area I would afford for myself. EA is still the one-eyed amongst the blind. Or maybe the unicorn between all sorts of horses. Still, the price is what it makes my favorite. If there were affordable UML tools I'd be willing to test them. But to my knowledge there is nothing around. Anyhow, if we do not complain about bad quality, Sparx will continue to add marketing features rather than making a better tool.

q.