Zurück zu Willert.de

Repository Layout

Rhapsody Model or Codegeneration topics

Repository Layout

Postby Ursanio » October 11th, 2013, 2:05 pm

Hello guys,

Wasn't really sure where to put the question, so I will post it here...

my problems is as follows:
we have at least 10 developers working simultaneously with Rhapsody and RXF framework. The question now is, how to
organize the repository on a versioning system (we use Team Foundation Server), so that it will handle all those
concurrently working developers?

I have seen that if more people are working on the same Rhaposdy project, things might get hard to merge back (it is possible through
Diff Merge, but it is really inpractical and far from the "ease" of merging directly source files).

I have gone through the IBM's Team Colaboration Guide (which is more of a high level document, at least to me) and came
up with some proposals to solution.
One solution is, that there are several project files, each responsible for specific DOMAIN, and one overal project where
other packages (from domain projects) are included (in specific components).

So the story on a repository shall look like this

Model organization by domains

Every domain (i.e.: security, I/O, measurement...) is a standalone rpy.

Project is another rpy that has several components that include packages as reference from the domain rpys.

(SCC) picture::

MAIN
|-> DOMAINS
| |-> SECURITY
| |->securiry_rpy
| |->*.cmp; *.sbs
| |->security.rpy
| |->CONSOLE
| |->console_rpy
| |->console.rpy
|->PROJECTS
| |->Project_A
| |->Bootloader_CMP
| |->security.sbs (REF) //added to model from SECURITY Domain and part of the Bootloader_CMP
RELEASES
| |->V1
| |->DOMAINS
| |->PROJECTS

This way a single developer can develop a domain model independently from other developers.
After the first release the SCC branch is created and all the fixes are done on this branch.
The main branch is used to develop another product or new features...

There are other models of colaboration, which might be even better. If there are any other suggestions
I would appriciate any answer.

(I have been playing around also with the posibility of several models that represent our logical entity of a product (there are 5 entities)
and a single project which included component of those projects. But this still has a problem of several developers concurently working
on the same thing).


best regards
Uros
Ursanio
 
Posts: 9
Joined: October 2nd, 2013, 9:40 am

Re: Repository Layout

Postby fsjunior » October 16th, 2013, 2:12 pm

Hi Ursanio.

In my company we work with only two developers on the same project. So, I don't know if my solution will fit to you.

We use a SVN repository manager and TamTamSVN SCC tool. The TamTam have some anoying bugs with Rhapsody, but we can work with it.

I don't know how Team Foundation Server works, but with TamTam the only (?) possible way to manage the code is with file locking. This means that there is no possibility to two developers change the same file, as to a developer change it, he will need to acquire lock of this file. In the default configuration of Rhapsody (I think that can be changed) this means that we have to lock an entire package to modify it, as Rhapsody in the default configuration creates files per packages.

In this way, maybe I misunderstood what you said, but I think that there is no need to make several projects only to organize things in SCC tool. In my company, a project means an executable or a library. Also, all projects have only one top level package which contains all other packages from this project. Other top level packages are only references to other top-level packages of another library projects.

Ergh.. Is hard to explain that. Maybe an example can help:


LibraryProject
|-> libProject package
||-> Internal libProject Package 1
||-> Internal libProject Package 2
||-> Internal libProject Package 3


ExecutableProject
|->exeProject package
||-> Internal exeProject Package 1....
|->libProject package (reference - cannot be changed directly here)
........

This is working very well here. In the executable project, we only generate the exeProject package and in the compilation time we link with previously generated code of LibraryProject. This reduces not only the compilation time, but reduces the time of the code generation.

So, backing to SCC, how we work: our job scheduling works in a way that the two developers will not work on the same package (or even in the same project!). We made several small packages per project with 3 our 4 classes and one or two diagrams in each package. In this way we can work together in the same project with very easy merges in the most time.

But, how I said, this work well with my case with two developers. With 10 developers working on the same project I don't know if will fit. But maybe I can give you some idea. :)

Regards (and sorry for my english),
fsjunior
 
Posts: 19
Joined: March 22nd, 2013, 8:15 pm

Re: Repository Layout

Postby Ursanio » October 17th, 2013, 12:06 pm

Hi fsjunior,

first of all thanks for your reply.

What you have written makes sense. So if I understand correctly you take a Component from Library Project and
include it in the Executive Project. This way you link both projects together and then you are free to use library
packages in the execution project? Or am I wrong?

My idea was to have domain projects, that can execute (to run unit tests on in) and when components, packages
and classes are ready we introduce them (by reference) in the Product Project. This project has its own component
that relies on components from domains.

That way the domains are encapsulated from the rest of the project and included when needed.

best regards

Uros
Ursanio
 
Posts: 9
Joined: October 2nd, 2013, 9:40 am

Re: Repository Layout

Postby fsjunior » October 18th, 2013, 5:55 pm

Hi Uros!

I don't take a component from a library project. I take a package. I don't know if its the usual way of doing this, but at least it works.

I'll try to explain more in deep my scenario:

My project (.rpy) have usually two components and two top level package. One component is for the release code (lets call it Release), that can be a library or a executable. Another component is for unit testing (Test). The two top level package works more or less in the same way: one is actually code of the library/executable and the other is the package which runs the unit test (note: in my case, I use a self-made library for unit testing).

So, in the Release component, I select to generate only the code that will be released. In the Test package, the code to be generated is the test+release.

I don't include components directly because, IMHO, in practice, the components works only for a configuration of how to generate and compile codes works. Lets try an example:

Lets suppose a system that will have and executable and it will use a library. Lets cal exeFoo and libBar. In Rhapsody, it will be:

Project libBar
Components->
Release (generates libBar)
Test (generates libBar and test)
Packages->
libBar (all release code will be modeled here.)
test

Project exeFoo
Components
Release (generates _only_ exeFoo)
Test (generates _only_ exeFoo and test)
Packages->
exeFoo (all release code of exeFoo will be modeled here.)
test
libBar (ref) (this is the trick: I include the libBar package model here; but this is only a reference. If I need to change it, I need to change it in libBar project)

So, In this case, to effectively use the model to generate code and then compile, I generate the code in both Release components of the two projects, and then I compile it and do a manual linking to generate the exe file.

I think that what you said is conceptually more or less what I do. Maybe a domain for you is something like a library for me. But, only for practical reasons (I prefer to manual link the compiled objects), I do not include a library component into another project.

Well, as I said: I don't know if doing this like I do is unusual, but at least it works (and is easy :)).
fsjunior
 
Posts: 19
Joined: March 22nd, 2013, 8:15 pm

Re: Repository Layout

Postby Ursanio » October 21st, 2013, 9:06 am

Hi fsjunior,

yes, I think we have pretty much the same idea on our mind. Well, my idea was to link also the components. I have to try if this works...

So, In this case, to effectively use the model to generate code and then compile, I generate the code in both Release components of the two projects, and then I compile it and do a manual linking to generate the exe file.

What do you mean, by manual linking? Do you have your own makefile that links object files from both projects? So you use the Rhapsody's
make file only for the compilation of both projects?

I will extent my question with another topic. Do you have experience with introducing external files in the project, ao that those files are introduced
into the Rhapsody's makefile and are build into library there (without the Willert Framework and any additional Rhapsody's objects/classes)?

I have to say, that you have confirmed me in my idea. I will go with my domains' (libraries') concept and see where that brings me (us).

Best Regards,
Uros
Ursanio
 
Posts: 9
Joined: October 2nd, 2013, 9:40 am

Re: Repository Layout

Postby fsjunior » October 21st, 2013, 4:30 pm

Hi Uros!

Ursanio wrote:What do you mean, by manual linking? Do you have your own makefile that links object files from both projects? So you use the Rhapsody's
make file only for the compilation of both projects?

More or less. I use Eclipse integration and I configure the linking manually directly in Eclipse. The makefile is automatically generated by Eclipse, but I configure the linking options (and other compiler options) manually in Eclipse.

This is more a "hacker" way than a "model" way, but, again, this works in my case.

Ursanio wrote:I will extent my question with another topic. Do you have experience with introducing external files in the project, ao that those files are introduced
into the Rhapsody's makefile and are build into library there (without the Willert Framework and any additional Rhapsody's objects/classes)?

Do you say, reverse enginering an entire library or only a few files?

Ursanio wrote:I have to say, that you have confirmed me in my idea. I will go with my domains' (libraries') concept and see where that brings me (us).

Best Regards,
Uros

Nice! :)

Post here if it works for you! :)


Regards,
fsjunior
 
Posts: 19
Joined: March 22nd, 2013, 8:15 pm

Re: Repository Layout

Postby Ursanio » October 22nd, 2013, 9:50 am

Hi fsjunior,

To reply, I have started another Forum tread: "Do you say, reverse enginering an entire library or only a few files?" under reverse engineering
section.

Do you say, reverse enginering an entire library or only a few files?


When I put the "animal" to life, I will most certainly post the results.

Best Regards

Uros
Ursanio
 
Posts: 9
Joined: October 2nd, 2013, 9:40 am


Return to Modelling with Rhapsody

Who is online

Users browsing this forum: No registered users and 3 guests

cron