![]() |
Telelogic TAU (steve huntington) | ![]() |
Topic Title: Reverse Engineering Topic Summary: Created On: 29-Nov-2005 20:30 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Does Tau G2 support reverse engineering. I tried using the import but it only seems to model definitions. I do not see any graphical representations of the the software.
|
|
![]() |
|
![]() |
|
I'm having same problem about Reverse. Even though Tau supports Reverse Engineer, that's only creating class model.. no more than this.. |
|
![]() |
|
![]() |
|
There are 2 ways to do reverse engineering today:
1) Use 'File->Import' menu option and import header files only. This builds a data model. New functionality in TAU 2.6 is that it now automatically creates class diagrams showing a graphical presentation of the data. e 2) You can use the roundtrip engineering functionality of our C++ code generator, by creating file artifacts for the files you wnat to import. In Windows you can create these artifacts by dragging and dropping the files in a class diagram. This will import both data and behavior. The second approach currently has some limitations when it comes to the amount of C++ it understands. This will likely be improved in our upcoming releases. |
|
![]() |
|
![]() |
|
Hi,
Cherie, as to your initial question, for C++ you should get Class Diagrams created, one per Package when you used File->Import... We have not completed the work for Java, hopefully soon. In any case you can: a) create a blank Class Diagram b) drag and drop the desired classes onto it for visualization --or-- c) right-click on the diagram and select "Show Elements..." and choose the classes you want on the diagram. Yes we are planning to improve the C++ reverse engineering support in the next release. So hopefully this will help you in the future. <opinion> As far as getting anything more than a Class Model and Class Diagrams. I could spend hours explaining the complexities of understanding the dynamic behavior of hand-written C++ (or Java or C for that matter) but it basically comes down to this. It is impossible to determine from hand-written code anything more than the static dependencies (relationships, inheritance, file dependencies) without some significant "guesswork" by the tool. I think even then, the results will be less than satisfactory. So, why produce "incorrect" or "partial" diagrams that will give a poor view of the code? If anyone is expecting Statemachine Diagrams, Sequence Diagrams, or even Use Case Diagrams then you will be disappointed. If figuring out Statemachines from existing code is for all practical purposes impossible, then how would someone determine from nothing but source code the Use Case that it supports? I am interested in reading anyone's research in these areas, but after using, producing and selling source code visuaization tools for 25 years I am not sure that there is anything realistic to expect beyond static structures. </opinion> Greg ------------------------- Greg Gorman Vice President, Product Management Modeling and Test Products Telelogic AB |
|
![]() |
Telelogic TAU
» TAU/Developer
»
Reverse Engineering
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.