Book a Demo

Author Topic: to PIM or not to PIM  (Read 6208 times)

SomersetGraham

  • EA User
  • **
  • Posts: 376
  • Karma: +1/-0
    • View Profile
to PIM or not to PIM
« on: March 30, 2010, 07:18:38 pm »
Hi all
I am starting a new project and I know that the implementation language will be C++ and will use the QT framework. I intentd to follow the Iconix process.
My question - is it worth the trouble to develop an PIM and the transform this to my C++/QT PSM
Graham
Using V12

deefer

  • EA User
  • **
  • Posts: 98
  • Karma: +0/-0
    • View Profile
Re: to PIM or not to PIM
« Reply #1 on: March 30, 2010, 10:27:11 pm »
Does anybody have experience with PIM and PDM in "C" language (no OO support)?
Is it worth to draw a OO PIM class diagram and then to do the PDM "C" transformation? Does anybody have hints on how to do it ?
Thanks
Davide

pocketom

  • EA User
  • **
  • Posts: 97
  • Karma: +0/-0
    • View Profile
Re: to PIM or not to PIM
« Reply #2 on: March 31, 2010, 12:19:30 am »
Hi, I use it for PIM -> PSM (C#) -> PSM (SQL2005). It#s useful e.g. to write the documentation only once - in the PIM. Therefore of course I don't use a rough model, I design concrete business objects in my PIM (using only basic types). These are transformed then individually to specific PSMs. I can imagine that this works pretty well for all OO transformations, but into a non OO language? In C++ you would need to generate structs as far I can remember... But, give it a try, you can modify the transformation rules as you like it ;-)





Sunshine

  • EA Practitioner
  • ***
  • Posts: 1353
  • Karma: +121/-10
  • Its the results that count
    • View Profile
Re: to PIM or not to PIM
« Reply #3 on: March 31, 2010, 02:59:58 pm »
PIMs are useful when you are trying to get to grips with the basics such as classes, operations and attributes without having to worry about the implementation technologies. If you want to transform that to C++ then you'll need to create a C++ transform which you could do relatively easily by copying C# and modifying it. If you've never done it before give yourself 3 or 4 days to get your head around it and get it working. If you need a database as well then you'll start reaping the rewards as you can then generate DDL from the same PIM. If you are keen you can also generate other parts of the application stack from the PIM as well. Usually people start off at the database and work up to a point where they resort to manual implemenation.

Contary to a previous remark in another reply you would map classes on to C++ classes not struct. You would however map classes to struct in C.

On the PIM to C programming language front again you'll need to create your own transformation PIM to C model. Do people still use C programming language - I stopped about 20 years ago? Anyway suggest starting with the C# transformation and customise that. I've not tried the C code generation before so I've just experimented with it. It doesn't seem to generate code using struct for classes like the old C++ to C cross compilers so it looks like it needs some work there. If you have lots of time to play with the transformations and code generation then its probably worth going through the learning exercise so you can re-use it on future projects. However, I think you'll spend a lot of time doing the customisation and if the pressure is on the project you'll end up abandoning it so its probably not worth starting it.

In summary if you are prepared to invest time and effort in customising the transformations and you can foresee using the transformations in the future on other projects doing customisation with EA is probably worth the investment of time. Otherwise don't bother with PIMs as it can be very time consuming customising transformations and code generation to C and C++.

Hope that helps.
Happy to help
:)

KP

  • EA Administrator
  • EA Expert
  • *****
  • Posts: 2919
  • Karma: +55/-3
    • View Profile
Re: to PIM or not to PIM
« Reply #4 on: March 31, 2010, 03:50:05 pm »
Quote
Do people still use C programming language - I stopped about 20 years ago?
Sure, mostly for embedded applications where there is limited space and a small executable is needed. I last programmed in C about 8 or 9 years ago but you can be a C programmer in any language if you put your mind to it ;)
« Last Edit: March 31, 2010, 03:51:35 pm by KP »
The Sparx Team
[email protected]

mrf

  • EA User
  • **
  • Posts: 311
  • Karma: +0/-0
    • View Profile
Re: to PIM or not to PIM
« Reply #5 on: March 31, 2010, 03:58:21 pm »
And to derail the post even more, for systems programming there really is no better option. As far as I understand the performance overheads induced by C++'s virtual function tables (and the general mash that was tacked on to support late binding) cripples performance to the point where JIT compiled languages actually perform better (in specialised cases of course).

We were talking about the merits of several languages today in the office and came across this quote (relating to Java's performance), which I think hits the nail on the head:

Quote
Together these suggest that it is possible that no amount of data will alter peoples' beliefs, and that in actuality these "speed beliefs" probably have little to do with java, garbage collection, or the otherwise stated subject. Our answer probably lies somewhere in sociology or psychology. Programmers, despite their professed appreciation of logical thought, are not immune to a kind of mythology.

- http://scribblethink.org/Computer/javaCbenchmark.html
Best Regards,

Michael

[email protected]
"It is more complicated than you think." - RFC 1925, Section 2.8

deefer

  • EA User
  • **
  • Posts: 98
  • Karma: +0/-0
    • View Profile
Re: to PIM or not to PIM
« Reply #6 on: March 31, 2010, 05:53:09 pm »
Thanks for the replies...
On the use of "C", please take a look at the most popular languages worldwide for March 2010
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

For the sake of the discussion, my approach would be to design a OO PIM (to promote the portability of the project) and then to do the mapping to structs and "C" modules manually (as said, I guess the automation process would be too frustrating) in a PDM part of the model (I'd create classes stereotyped as "struct" with only attributes for structs and classes with only operations for "C" modules, although the whole process needs a strong customization because of the lack of OO support of C).

Another possibility is to enable the OO support of the C code generator, so that the pointer to the data of the class is supplied to every class function (as implicitly done in C++), although the private and protected scope modifier is not handled (every member will be public, so encapsulation is lost). For some classes I guess this would be the best approach.

Other suggestions are very welcome.
Thank you
Davide

Sunshine

  • EA Practitioner
  • ***
  • Posts: 1353
  • Karma: +121/-10
  • Its the results that count
    • View Profile
Re: to PIM or not to PIM
« Reply #7 on: April 02, 2010, 10:26:27 am »
To continue derailing the post;
Quote
And to derail the post even more, for systems programming there really is no better option. As far as I understand the performance overheads induced by C++'s virtual function tables (and the general mash that was tacked on to support late binding) cripples performance to the point where JIT compiled languages actually perform better (in specialised cases of course).

mmh? Having programmed in C++ between 1990-2001 in real-time environments where micros seconds or less counted, I'd have to disagree about C++ having crippled performance. As usual the skill is with the programmer to be able to write code that can perform and there are a few tricks in the use of the particular language and the use of  compiler switches. I have to say having compared similarly written programs in different languages in the past I've never come across a JIT compiled language that can out performed compiled C++. However I concede I don't know every language but I'd be interested in what JIT language outperformed C++.
As regards to nothing being better than C for performance I'd have to disagree again. On the odd occasion I've had to resort to assembler to squeeze the last drops of performance out of a processor as even C couldn't do it. So I suppose when it comes down to it assembler is better for performance than C :). However its not the most productive language to use. If you are using an OO design paradigm in a real-time or systems programing environment then I would suggest considering C++ and incorporating either C or Assembler in the parts where extra performance is required, this way you get the best of both worlds.

Since we've wandered onto to the topic of performance I think its appropriate to list the following quotation to provide some food for thought.

"Its easier to get a working system to perform than to get a performing system to work"
Happy to help
:)

Christhonie

  • EA Novice
  • *
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Re: to PIM or not to PIM
« Reply #8 on: April 10, 2010, 01:53:34 am »
Hi Davide,

We do multiple transforms from our PIMs to generate business objects and DTOs (some applying our own frameworks, wrapping classes in other classes, (de)marshaling code to/from the classes), XSDs and WSDLs.  

The key is to develop your own "flavour" of a PIM that can address the needs of all target platforms/outputs.  So you are on the right track to think of an OO PIM, as that will be rich enough in meta data to generate both target PSMs.  

I suggest that you do not contaminate your PIM with PSM specific constructs, i.e. rather than using "struct" stereotypes use something like "message" to denote message classes , generating classes in C++/C#/Java and struct in C.  Your PIM should, as the name states, be platform independent.  We also make extensive use of tags within the PIM to add the required meta data to guide the PSM transform in performing their functions.

That said, it is a mission to develop these transforms.  We have invested months in writing our own transforms.  And the template framework in EA is the most pathetic design I have seen in my life; i.e. try to do an arithmetic operation on values, loops, etc..  I suggest you make use of the Automation Interface to add functionality.  We use Win32 code as C# add-ins cannot run on Linux.  We have even included a caching layer in the add-in to speed up access to elements and connectors, as EA calls the DB for every a single property is being accessed.  We now get an over 2000% speed improvement.

Hope this helps.
Chris