Maintain stand-alone modules via version control

[jakobim]

Hello EA forum,

The situation so far:
We are developing a new product of which I am modeling the software layout right now. We have quite a number of modules (in the form of source code) that already have been implemented and should be reused in this project. Examples would be an abstraction layer for a multi-threading RTOS or a CAN stack.
As there have been no diagrams so far, I am also drawing diagrams for these modules (as components). As already stated, the modules can be reused, so the idea is to make these module diagrams available as stand-alone little EA projects, in which every module can be maintained and from which it can be imported into an actual project.

My current situation:
I encapsulated each module in a stand-alone little EA project and made them available via the version control system in EA and Subversion. It all works quite nicely, I can maintain each module separately, import these modules into an actual project, keep them up to date, check the history, etc.
Sadly I encountered quite a big problem on the last few steps to completion: I can’t draw connections BETWEEN modules, as they are “read-only” (and of course should be, as I don’t want to manipulate them in the actual project, just (re)use them). I understand that the actual problem is that drawn connectors are saved “in” their source interface or element, but it is kind of illogical, as I want to connect the imported modules on a higher logical level.

I hope my problem is understandable and somebody can provide a proper workaround or a different, more suited approach.

Thanks in advance,
jakobim

[Geert Bellekens]

Jacobim,

As you connect modules you should always have some sort of dependency hierarchy.
One modules depends on the other module, etc...
So if module A depends on module B then (A -->B) then that relation should be stored in module A.
Connecting on a "higher level" does not exist in my mind.
You might connect "instances" of your modules, but the modules themselves are either connected, or they are not.

Geert

PS. I think your approach with the version controlled modules is perfect

[jakobim]

Hello Geert,

First of all thanks for the fast reply and thanks for the compliment.

I thought about dependencies myself and while writing my reply I realized that you seem to be actually right: Let’s say the CAN stack depends on a RTOS. So this connection has to be stored inside the CAN stack module, as it clearly states that it needs an RTOS in order to be able to fulfill its task.
As I looked through the project diagrams again, I actually couldn’t find any example that does not fit this logic.

Though there are still a few things that disturb me:
There always will be some “project” dependent modules. In my case it is the board support package (or hardware abstraction layer), which is different for every project. So I have to store the connection information to the each and every BSP in the modules, rather than as a project based information.
The other thing I don’t like is that you have to manipulate the modules outside of their “maintenance project”. But it can’t be helped I guess.

But there still remains one big problem:
If I put a model branch inside of EA under version control, it only manages the package in form of a XML file. But for a stand-alone maintenance project it is compulsory to also have the EAP file as a “GUI” to edit the module.
So I have a version control disaster: I manage the actual module with EA and the “GUI project” externally with subversion. Now what happens if somebody forgets to commit the EAP file, or more generally the state of the two files does not match? Or somebody reverts via Subversion outside of EA to a previous version, in which the current modules are checked out, which actually aren’t etc. And we all know, this WILL happen sooner or later…
So my question is: How can I force the XML and EAP to always be an atomic commit? Are there any means inside EA to also store the EAP file? Or can I configure Subversion to do this in any way?

jakobim

[Geert Bellekens]

Jakobim,

There's no obligation to have an edit .eap for your shared modules. I have a similar situation where we have two main project which share a number of modules.
I just checkout the modules in whatever model I have open.

Of course once I've checked in the module I need to do a getlatest in the other model to make sure my latest changes are visible there.

If that is too much of a burden for you then you should consider putting the whole model (including all projects and shared modules) on a single shared database (RDBMS). In that case you always have an up-to-date model.

Geert

[Doug Blake]

.... So I have to store the connection information to the each and every BSP in the modules, rather than as a project based information....
jakobim

You could store a virtual BSP element in the reusable package without defining all its properties. Then when you import the package, the element is in place to define the board specific items. You know the interface to the BSP, but not its implementation.

[jakobim]

Hello everybody,
thanks for your replies.

@Geert:
You are right (, again!). I evaluated some other different approaches and discussed matters with a college and we came to the conclusion that the only proper solution is to keep the module diagram only as XML files (which are version controlled externally via subversion). Any other approach, sooner or later, leads to inconsistencies.
The actual project diagram is kept as an .EAP file and imports the XML modules.

@ Doug Blake:
Although I solved the problem otherwise, I’m eager to learn. But I don’t quite get what you mean, especially with “virtual”.
Do you mean to have a “default BSP” package that delivers the interfaces that are required, and inside the project diagram I fill this “shell” with the actual implementation? Could you maybe provide an example?

jakobim

[Doug Blake]

Yes jakobim, thats what I mean. Sorry I dont have any examples, it just seemed a possible way of accomplishing what you wanted.