lock [Solved]Finding out how Modelio persists it's data

7 years 8 months ago #337 by porchrat
I couldn't find a section of the forum that I thought was more appropriate so I've put this thread in here. If this is the wrong spot then please could a mod move it to the appropriate area.

Hi all

Seems I just can't stop asking questions about Modelio. :P

I'm trying to figure out how Modelio persists it's data (I'm looking at moving some of my own data straight into Modelio projects). When I first was shown Modelio I was told that maybe it used some sort of SQL based system because it was affiliated with Hibernate. Upon doing a bit of my own research it seems that Modelio facilitates development of Hibernate mapping files but doesn't necessarily use Hibernate itself.

I briefly checked the user manual and couldn't find much in the way of references to how Modelio persists the projects. (makes sense after all it is a user manual and not development documentation).

I decided to download the source code and take a look and see if I couldn't find out more about data persistence that way but honestly, while I will continue to look at it if all else fails, I really don't know where to start.

Are there any people familiar enough with that particular aspect of the code that could point me in the right direction?
The topic has been locked.
7 years 8 months ago #339 by michaelp
I would tend to think it's somewhere in the C++ code, persisting everything into this single OFPX file through in-house code. I'd be interested to know more about this too, since interconnecting Modelio in a larger team ecosystem is not easy with a non-documented file format.

Michaƫl
Praxeme Institute
The topic has been locked.
7 years 8 months ago #340 by fpo
No problem, your question is at the right place: persistence is indeed part of the (C++) core. And of course no problem with asking as many questions as you feel you need to ask.

About your actual question:
Modelio doesn't use Hibernate to persist its data, but indeed a "homemade" solution entirely written in C++ (although some concepts of this solution are indeed similar to concepts found in database management) called OFP (which i think originally stand for Object File Persistence) which produce the ".ofpx" file. As a side note, it should be noted that OFP is now a pretty old part of the core (I think it has been around for about a decade now, which is way more than most piece of software I've encountered so far) and has proven quite reliable and efficient despite the overall complexity of the code. Said complexity is due partly to the complexity of the problems it solves, and partly to the fact that it had been coded using coding standards of the time, which have evolved quite a lot since then.

In the end, the information I guess you are looking for is that the model, or the biggest part of it anyway, is stored (at the moment, but this might change in the future) in the ".ofpx" file that you will find in your project's directory.
And I'm afraid there is no way to add any of your own data directly into this file without heavily hacking into the C++ part of Modelio (which I highly recommend to avoid!) if that was your goal.
Of course, if your goal is to store your own files "near" Modelio's data, then putting your files in the project's directory (or a sub directory of it so you can easily identify them) is absolutely valid.

[Those interested in the actual implementation can download the C++ source code and start around the FpClObject class, which is the "storage handler" used by all our model objects, but be warned that it is indeed old and complex code, using our specific internal terminology]
The following user(s) said Thank You: michaelp
The topic has been locked.
7 years 8 months ago #341 by fpo

michaelp wrote: [...]interconnecting Modelio in a larger team ecosystem is not easy with a non-documented file format.

There has been other threads about this, but it can be basically summed as the following:
A project needs several things to work (the strict minimum at the moment being the .ofpx file and the mda directory than can both be found in the project's directory, but this is planned to evolve to add more things) so our view is that the project's directory should be seen as the working unit of a project.

If team collaboration is needed on the model, then the use of the (commercial) Teamwork module is usually the best solution, as it integrates into Modelio and works using the SVN protocol.
The recommended way to handle resources outside the model itself is SVN of course, allowing to use the same SVN server/repository.

If this is not a valid solution for your case, then specific solution might be needed, in which case I advise you contact the Modeliosoft sales team for more informations (and continue posting questions on the forum of course!)
The topic has been locked.
7 years 8 months ago #345 by porchrat
Thank you for the informative response. My C++ knowledge is somewhere between "none" and "limited" so I'm not awfully keen on messing about with that code. :P

I will go and take a look at OFP. If I've read correctly so far something similar was used during the Objecteering days too.

What I have tried in the meantime is to use the XMI import functionality of Modelio to import my data into projects. While this approach does work (and sure saves me a massive amount of time) there doesn't seem to be a way to create entire pre-populated diagrams through the XMI import system. This leaves me having to manually create diagrams, which would unfortunately be impractical. I was hoping to cut out the middleman so to speak and write straight to the modelio project files themselves.

I think I'm going to have to look into how much can be achieved with module development for Modelio and see if maybe I can't create a workable solution to my problem that way.

On a connected note: Testing the aforementioned XMI import route I was able to push about 5000 classes into a single project and get them all into a single class diagram. I'm impressed with how Modelio stands up to that sort of thing. I'm used to modelling tools falling over or at least becoming so slow as to be unusable at that point. While Modelio did visibly slow it wasn't crippling.
The topic has been locked.
7 years 8 months ago - 7 years 8 months ago #347 by chm

porchrat wrote: This leaves me having to manually create diagrams, which would unfortunately be impractical. I was hoping to cut out the middleman so to speak and write straight to the modelio project files themselves.

I think I'm going to have to look into how much can be achieved with module development for Modelio and see if maybe I can't create a workable solution to my problem that way.


I agree, defining a module to create your diagrams would be a better (and way simpler) solution.

You should take a look at the developer API page for general infos about modules, and the documentation of diagram services for your diagram creation.

I guess i'll see you on the module developement section soon. :cheer:
The topic has been locked.
Moderators: chmcma
Time to create page: 0.055 seconds
^ Back to Top