Pinned topic ADA Reverse Engineering
"#if (not OS = "IRIX64") and then (not OS = "SunOS") and then (not OS = "LINUX") then"
Has anyone run into this before? How do I get the code to reverse engineer with this # in it?
Re: ADA Reverse Engineering2012-01-25T15:00:47ZThis is the accepted answer. This is the accepted answer.Ada (never ADA ;-) does not specify a pre-processor but AdaCore's GNAT compiler comes with one (gnatprep) and I think that what those lines are.
I don't know if Rhapsody is aware of this - doesn't sound like it.
Such pre-processing is generally used to statically select build options during build time. The preference in UML-land is to dynamically switch in the required behaviour depending on the architecture you build and hence remove compilation options. So, you may have a base class and derive a "_IRIX64" class from it and a "_SunOS" class and a "_Linux" one + whatever the "#else" branch takes you to .
Given Rhapsody's Ada->UML engine doesn't seem to support it, I think I'd try a get the pre-processing down first outside Rhapsody and reverse in the result for whatever OS you currently need most. You can then refactor the UML as you need by hand.
Any decent Ada programmer will have limited the locations where pre-processing is necessary and hopefully even hidden it all within package bodies.
Re: ADA Reverse Engineering2012-01-25T15:07:12ZThis is the accepted answer. This is the accepted answer.
- martin.dowie 2700024BJT
SystemAdmin 110000D4XK1305 Posts
Re: ADA Reverse Engineering2012-01-25T15:12:06ZThis is the accepted answer. This is the accepted answer.I am an Ada programmer! ;)
The Ada language standards do not define any # pre-compiler directives. The Ada language does define the pragma keyword for compiler directives.
Some compiler vendors have products that can cope with a mixed C/C++ and Ada source code (e.g. http://www.ghs.com/download/whitepapers/ada_c++.pdf). So I am fairly certain that your customer is erroneously trying to reverse engineer C/C++ code using the Ada reverse engineering tool that is built into Rhapsody.
I suggest that your customer use Rhapsody in C/C++ to reverse engineer C/C++ code into a UML model. Obviously, the customer can continue to use Rhapsody in Ada to reverse engineer the Ada code. Then you could ask a Rhapsody technical specialist about how the models could be configured to reference each other (if required).
Re: ADA Reverse Engineering2012-01-25T15:39:12ZThis is the accepted answer. This is the accepted answer.Hi Colin, always good to see an Ada guy around! :-)
That link is interesting but notice it too side-steps pre-processors (doesn't even mention them), I guess perhaps it's the C/C++ 'translation units' that are interesting? Or perhaps it's just ignoring that topic.
You're right that it could be directives for the C preprocessor as well as GNAT's Ada preprocessor - only the OP will know if he really has Ada to hand or not.
NB: I did once work on an Ada (Ada83) project that used the C preprocessor first to generate the actual Ada code...just '#ifdef' type stuff no '#include' or '__LINE__' etc.
Re: ADA Reverse Engineering2012-01-25T16:00:21ZThis is the accepted answer. This is the accepted answer.In that case, my guess is that part of the build process is to run it through 'gnatprep' first, which will result in 'clean' Ada.
My next guess is that there are separate builds performed for each target (resulting in new code for each) or that there is a single build process that hides this...but still produces new code for each!
I'd do a quick search for "#if" just to see how many files are actually affected - if it's 1 to 2, you may be able to edit it yourself to obtain whichever target you need.
If there are a large number of files then I think you need to speak to your s/w team and get them to provide you with their "Build Process" document...they have got one right? ;-)
You could install the tools and follow the process yourself or get the s/w team to generate the 'clean' Ada for each target system.
Re: ADA Reverse Engineering2012-02-07T16:10:40ZThis is the accepted answer. This is the accepted answer.Thank you Martin I think your last post answered the question. It wasnt the answer that they wanted to hear but it was an answer the software people are working it now.
SystemAdmin 110000D4XK1305 Posts
Re: ADA Reverse Engineering2012-12-04T09:20:45ZThis is the accepted answer. This is the accepted answer.There may be stuff we can do to help. The simplest way is to clean up code prior to import. However, the bigger picture is important to understand. Just reversing is all very well but it's not the purpose of model-driven development since rarely does code stay static. Note that we have done a lot to be able to reverse engineer legacy Ada and then re-generate it from the model. This then opens up a whole host of additional capabilities, such as tracing to requirements and generating these into the code, maintaining code and model in sync etc. There are some significant new Ada reverse engineering options in Rhp 8.0 (and some options not visible in the GUI). If you get in touch then we might be able to help further. Also, I always encourage to log support requests. We can be quite reactive. Fraser Chadburn.
H9QT_jeff_kulick 270004H9QT1 Post
Re: ADA Reverse Engineering2013-04-22T21:01:03ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
i have a project where they would like to integrate about 500 ksloc of mixed Ada and C code. We are looking at Rhapsody for reverse engineering and was wondering if you reverse engineered C and Ada code would they still interoperate when regenerated by Rhapsody. The concerns are about 1- c-ada interfaces for legacy code, 2- interfaces between code generated by a state machine and legacy code, and 3- operating system interfaces (they are planning on using a real time red hat linux target os).
Fraz 2700024VMF2 Posts
Re: ADA Reverse Engineering2013-06-05T07:36:44ZThis is the accepted answer. This is the accepted answer.
- H9QT_jeff_kulick 270004H9QT
It sounds like a bit of knowledge transfer may be valuable to assess the options. There are certainly yes answers, but there are also more questions also to decide the best route, for example, what do you really want to achieve, what will you do with the model after RE, how much re-design is desired? If the objective of RE is only for documentation or code is just being tweaked then another option is to RE with visualization. Although there are differences this is supported in Ada now, as well as C (v8.0+). In visualization/code-centric development the code is not changed. C-Ada interfaces usually come down to pragmas. We did enhancements to the Ada RE rules to capture most of these and I have successfully harvested Ada code that interfaces with C code OK (1 tweak to a property was needed related to a single pragma). The C and Ada code would need to be RE'd separately. Note: A Rhapsody application can be built from several models and several builds can be set up from components in a single model (depends on separation of concern). This is usually set up via the component/configuration model. Also, a Rhapsody application doesn't have to use statemachines. One possibility might be to wrap the existing code and make use of ports/interfaces. Another option might be to get the Rhapsody build to include code that is not in the model. Even when RE-ing a single language (C, C++) then these questions come into play. Best to start with objectives to validate easiest route to the goal.