Book a Demo

Author Topic: Reverse Engineering Forms from Visual Basic 6  (Read 7594 times)

sbarkeruk

  • EA User
  • **
  • Posts: 31
  • Karma: +0/-0
    • View Profile
Reverse Engineering Forms from Visual Basic 6
« on: November 10, 2004, 03:43:48 am »
Have created a simple project in VB6 in order to test out the reverse engineering capabilities for the trial version of EA.

The reverse engineering process reads everything fine (classes and forms), but the type for imported forms gets set to Class. Is there a way to have this so that they are imported as forms instead (or Screen, or whatever the UML equivalent is)?

Should I always use the Component Model diagram to do this reverse engineering process? It seems that this is the only place it is allowed (which I suppose is logical).

Also, if I then proceed to generate code for the above project that I have just reverse engineered, all code is generated as .cls files instead of both .cls and .frm. Am I expecting too much here (i.e. is it possible to have forms generated or are these only for documentation purposes)?

Simon

TrtnJohn

  • EA User
  • **
  • Posts: 176
  • Karma: +0/-0
    • View Profile
Re: Reverse Engineering Forms from Visual Basic 6
« Reply #1 on: November 10, 2004, 12:08:51 pm »
Don't get confused by names.  In UML a class is a general element.  It can represent Forms or UserControls in VB.  You can use your own stereotype to denote the difference in the diagram.  Classes should really appear in your logical view.

Also, I would not get too focused on the reverse/forward engineering aspect of the program.   This feature is really just a time saver.  Don't fall into the trap of thinking UML will write your code for you.  That really doesn't happen.

sbarkeruk

  • EA User
  • **
  • Posts: 31
  • Karma: +0/-0
    • View Profile
Re: Reverse Engineering Forms from Visual Basic 6
« Reply #2 on: November 11, 2004, 12:58:02 am »
Thanks for the interest in my question and the prompt reply.

I am aware (from my academic use of Rational Rose - 5 years ago!!) that UML does not create functionality, only the basic template for properties, methods, etc.

However, I suppose I am just wondering if it is possible to specificy somewhere that a particular logical view class should be converted as (in VB6 terminology) a class, form, module or other. This would save a bit of copying/pasting in VB6.

sbarkeruk

  • EA User
  • **
  • Posts: 31
  • Karma: +0/-0
    • View Profile
Re: Reverse Engineering Forms from Visual Basic 6
« Reply #3 on: March 31, 2005, 12:57:35 am »
I am comparing Rational Rose and EA side by side to see which one we may consider purchasing.

However, when reverse engineering from Rose, all of the Modules, Class Modules and Forms are imported correctly and the correct stereotypes are assigned. In addition, all references (COM) and Components are also added to the model (but not the diagram of course), including everything as simple as the VBA reference, etc.

But in EA it is quite a simplified conversion and no stereotypes are determined fo you. Also no references are added to the model. This is far too basic.

So how do I modify the above model to make sure that any future code generation (or synchronisation) will correctly create/update *.cls, *.mod and *.frm files (as opposed to all being created as *.cls)??

Also, does anyone have an example model that I can run that would create such a project (To prove that the same can be achieved in EA)? I would like to be able to correctly create the following in VB6 from a model:

a) Types.
b) Enumerations.
c) ActiveX Exe/Dll projects (as well as Standard EXE).
d) Fixed length strings within a Type (e.g. 'As String * 60', instead of just 'As String').
e) A 2, 3 or n-tier project from the model.
f) Have EA also create the vbp file instead of me having to add each class to a new project.

... and before someone says this is not part of UML standard, all of the above CAN be done with Rational Rose!

:)

Thanks in advance.

thomaskilian

  • Guest
Re: Reverse Engineering Forms from Visual Basic 6
« Reply #4 on: March 31, 2005, 07:29:03 am »
So if everything can be done with RR why the interest in EA?

sbarkeruk

  • EA User
  • **
  • Posts: 31
  • Karma: +0/-0
    • View Profile
Re: Reverse Engineering Forms from Visual Basic 6
« Reply #5 on: March 31, 2005, 07:42:52 am »
I am still in the early stages of evaluating both (then possibly Visio Professional also) and there are issues with each (RR may be able to do the above, but there are several seperate issues with it, such as clashes with my Source Code repository, diagramming issues and poor telephone support infrastructure).

I would like to choose EA mainly due to cost, but need to get over at least some (if not all) of the above issues first. Am hoping that someone can help me out here so that I can join the EA bandwagon.

I am just wanting to know if the above CAN be done in EA (even if it requires a lot of initial setup, such as Templates)?

sbarkeruk

  • EA User
  • **
  • Posts: 31
  • Karma: +0/-0
    • View Profile
Re: Reverse Engineering Forms from Visual Basic 6
« Reply #6 on: March 31, 2005, 11:55:41 pm »
Does anyone from Sparx development team have any thoughts on this?

thomaskilian

  • Guest
Re: Reverse Engineering Forms from Visual Basic 6
« Reply #7 on: April 01, 2005, 12:22:35 am »
You'll likely have to wait for next week since it's already start or the weekend in Australia  ;D
I have not played around much with code engineering, so I can't give an answer.

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Re: Reverse Engineering Forms from Visual Basic 6
« Reply #8 on: April 03, 2005, 04:22:59 pm »
I don't look at the VB6 code engineering very often, but when reverse engineering it should import classes, and as for stereotypes, "Type" -> "struct", "Enumeration" -> "enumeration".  External elements aren't added to the model from your import.

When you import a source directory of Visual Basic 6, EA will by default import from .cls, .frm and .ctl file extentions.  This is configuarable from the VB Specifications page of the options dialog.

It depends on how you're generating what EA will do with the filenames.  If you are generating a package (Project | Source Code Engineering | Generate Package Source Code) there is an option to Auto Generate Files.  This will automatically generate the extention from what is set in the VB options page.  The option is also used as a default when setting the filename in a generation.

That option can actually be set on a per-class basis, the problem is that it the class level option is currently not being used.  (A bug that I discovered while writing this response and will be fixed soon.)

Having said all of that, it's not needed most of the time.  After reverse engineering the filename will still be set and that is the file that it will generate to/synchronise with.  You can also pre-set the filename of each of your classes in the properties dockable window.

a+b) Answered above by describing the stereotypes.
c) Not sure how this is done in VB6, but I suspect it has more to do with the project and is therefore belongs in f.
d) Looks like something that importer doesn't handle properly.
e) Not sure what you mean.
f) In the .Net and Java lands the equivalent to this is handled by our MDG addins, we don't have one for VB6, but you should be able to write one if you really need it.  (That really would be a lot of initial setup though)

No, it's not part of the UML standard.  The UML standard is designed to be extended.  That's why it's as useful as it is.

Just thought that it would be a good idea to mention that we don't generally do telephone support, but email and this forum seems to work very well.

Simon

sbarkeruk

  • EA User
  • **
  • Posts: 31
  • Karma: +0/-0
    • View Profile
Re: Reverse Engineering Forms from Visual Basic 6
« Reply #9 on: April 04, 2005, 02:41:46 am »
Thanks for the quick reply.

However, I am still having difficulties getting EA to use the correct file extension when generating the files. I followed your procedure to generate (Project | Source Code Engineering | Generate Package Source Code and checking Auto Generate Files option).

Despite setting up the appropriate stereotype in the model (e.g [Implementation]class, form, etc) these are still generated as *.cls files (form should be *.frm). I am able to do this with Rational Rose (so understand the theory), but not yet with EA. So am I missing something in my model properties here that prevents this from happening?

Also, it would be really nice (and put EA on a par with Rose) if during the Source Code Generation, the *.vbp file could also be generated. Currently it appears that it is a manual exercise to add these files to a project (unless you can tell me otherwise).

My comments on the points listed earlier in the thread are:

a) struct -> type. I am aware of this, but it would be nice to use the convention that the chosen language uses (VB uses type). So maybe when picking Visual Basic in the default language (in toolbar), perhaps other options should be filtered out as they are inapproriate?

b) OK with this now I think.

c) Again with Rose, it is possible to add a component and choose a stereotype for it (ActiveX EXE, Dll, Standard EXE, etc). So this generates the project file and sets up the correct settings within the project. Is this possible in EA?

d) Would be nice to include fixed length string lengths. This is especially important when reverse engineering, because essentially important detail is lost if this is not imported (Someone looking at the model will not realise that the string should be of a fixed length). Also when forward engineering there is a risk that this would then be overwritten (and the fixed length removed from code!!).

e) I was referring here to an application that consists of 2 or more components (built from 2 seperate VB projects but used together in the application). For example if I have a project for an ActiveX DLL server, then another project (the front end UI) reference this. Ideally (as in Rose), EA should detect this and ask if the referenced project also need to be imported in the same diagram. Or is there a quick and easy way to merge two models together as one?

f) I mentioned this above in my 3rd paragraph

I appreciate the comment on telephone support, and I think that what you have with email contact and forums is the best way. I certainly seem to get a better response from EA than I do with your competitors (Evaluating 4 different tools at the moment).

I am hoping that EA will be the tool that I end up recommending, but at the same time I need to ensure that it can do what I want without too much extra setup. Of course, I also need to ensure that it is not my inexperience with the tool that is the cause of my problems!!

Thank you for your time and patience and I await your response.

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Re: Reverse Engineering Forms from Visual Basic 6
« Reply #10 on: April 04, 2005, 04:55:33 pm »
You didn't read what I said about the auto generate option.  It will use the option for default file extention that is in the model.  If you have reverse engineered the files you are better off just doing a generate and letting EA synchronise with the file that you reverse engineered it from.

What is the appropriate stereotype?  There is no such thing.  Other tools may define stereotypes for things such as forms.  If EA doesn't use them in any way then they are hardly appropriate when modelling in EA.

Yes, it is a manual exercise to add the files that EA generates to a project.  EA doesn't touch components at all in reverse synchronising or generating.  As I see this that makes (c+e) irrelevant, possibly also (f) because there is nothing to set the information to and nothing to generate it from.

To show two different projects on the one diagram, import both of them into EA and drop Links of all of them onto a diagram.  Maybe import them both into different packages than the diagram and each class will show where it comes from.

I agree that VB Types would be better modelled with a stereotype of Type.  However, they aren't.  There are plenty of users out there with VB types modelled using a struct stereotype.  Therefore EA must use the struct stereotype for VB types.  It's not inappropriate, just perhaps unexpected.

My previous comment about the string lengths was not meant to say something anything beyond acknowledging that it is a current restriction.  I'm certainly not saying that it can't be fixed.  I've looked into what it would take to get the importer to import them.  It looks possible, but I haven't worked out the details yet.

I think part of the problem is that you are expecting EA to behave like Rose.  Rose does handle some things in code engineering that EA doesn't.   The vbp files are an example of this.  Other things EA just handles differently.  Ultimately, there will be some positives and negatives to whatever choice you make.

I hope that I've been a help.

Simon