I’ve had a successful and interesting play with starting to use EAs code engineering capabilities with a particular focus on using the Analyzer. So before I forget some of the interesting stuff I’ll jot down some of my observations that may be of use to others going down the same route.
Running the demos
With anything new it makes sense to start with the examples that are provided by the vendor as one would hope that:
- They work – and there is a good feel factor encouraging more use of the tool
- Illustrate some of the good stuff that the tool – once again enhancing its value
So what have I done over the last week:
- Worked through some of the VEA examples (C++ native and C# .NET) – build, debugged and analyzed
- Tested the analyzer with a simple VB.NET windows application
- Tested the analyzer with an EA Add-In with EA – and that was really magic
So I’ll go through my observations in turn:
Before you start
Checked out the product demonstration videos:
Get the resource booklets:
- Model driven development and Visual execution analysis – from the community site and more up to date reflecting changes in menus
- “Visual Execution Analyzer in Enterprise Architect” – the original paper on the VEA and but is now a bit out of date but still worth a read
- Also UML Code Engineering may be of interest
And don’t forget the Help and/or user guide to check details (most problems arise as some of the detail is missed!)
Working through some of the Sparx examples
I started by viewing the webinar and then aimed to work through the VEA booklet to test the examples provided. I was already familiar with basic code engineering both forward and reverse engineering of code, having used this before to either produce a basic source file from the classes I had developed or capturing information from existing code to aid with its documentation. Hence, I assumed it would go smoothly and I must say that most worked as expected. So what were the Gotcha’s:
- Location of source code – If you import the source code and then subsequently move the code the link between the source and model is lost, hence when you try to view the source code it’s no longer there. This is because on the initial source code import EA stores the filename in the field “Genfile” of the class as a static value i.e.. is not updated. The answer is either to reimport the code (something that can lead to a bit of a mess unless you are careful – I know!) or modify Genfile directly to reflect the new location – may be worth including an alias (ID) in the path which can be modified if the code is moved again. I did the later and used eaDocX to facilitate the work by outputting the relevant classes and their GenFile field to a spreadsheet, editing the GenFile path and importing the modified worksheet and thus resolving the issue. Clearly the easy option for avoiding this situation is not to move the source code after you import.
- Don’t forget spaces in pathnames can be an issue – when setting up any local directories it could be that spaces are present in paths – beware as when VEA runs a script it should be considered as a command line operation and be formatted correctly within quoted (“) strings e.g. “%MSVS%\devenv.com”, otherwise the command is not recognised by the command line interpreter correctly.
- Failure to build – having got the source code linked and set up the “Local directories” to set the IDs used in the examples (VEA for the source code files and MSVS for devenv.com) I thought it would all just work, wrong! The short story is that on some operating systems (in my case Windows 7) User Access Control (UAC) operates which means that some applications require administrator priveleges to run, one of these being devenv.com. So with EA running as a normal user on my system, when I initiated the build the return status was OK however nothing happened. By setting EA to run as administrator (if unsure how to change see EA help for information) it all just worked as per the video (it took me a little while to get here because I assumed that I would be prompted as and when needed – I wasn’t!)
So no groundbreaking issues but a bit frustrating – so with that done I was able to explore the VEA examples. I could use EA as my debugger, able to access normal features of an IDE such as breakpoints, variables etc with the added options such as recording information that could subsequently be converted into sequence diagrams (just remember that EA uses F6 not F5!! )
My own test application
The next check was to build and test a simple windows application of my own (in VB.NET) and see how that worked. Basically no real problems:
- Created a simple windows application in VS-2010
- Create a package and imported the source code
- Created build and debug scripts
- Tested – OK
- Adding a new class within EA and generating/editing code from EA worked however the source file wasn’t added to the VS project file so needed to edit this manually (could have done by switching to VS but wanted to see what can be done within VS)
- Tested – OK
There is a short write up of this as a PDF if you are interested: – HowToBuildASimpleApplicationToUseWithTheVEA
Testing an EA AddIn
As my day job often involves writing AddIns I was curious to check out if and how EA could be used to test an AddIn. Not least would it help with
- Checking my code flows etc
- Producing better documentation to help with ongoing support
I was pleasantly surprise when this worked. Although I did experience and I am still exploring a couple of issues with building my AddIn from within EA (I don’t think this is an EA issue), the debugger worked fine.
I configured the debug script as illustrated in the screenshot below.
So to run a debug session:
- Ensure that there are no instances of EA running
- Start an instance of EA (lets call it EA1) and open the AddIn model with the scripts, source code, etc
- Check the process ID of this instance of EA – (I used the Process monitor within the sysinternals suite to get the process ID and monitor my system) – EA1 – it should be the only instance running.
- Run the testing instance of EA(EA2) and take a not of its Process ID
- In the Model instance of EA (EA1) start the debug script which will want to “Attach to process”
- When requested select the EA process with the process ID for EA2
- You are all set to start setting breakpoints, recording information to produce sequence diagrams etc
Worth remembering that the execution of your AddIn will be very, very much slower than normal, so factor this into any tests you propose (often time to get a cup of coffee when doing a run!) i.e. small tests only.
So a pleasingly successful result from my initial tests. I now want to explore the analyzer further – probably back to re-reading the booklets and check out what I’ve missed and what I’ve still to do. I do know that I want to:
- Get the Profiler working with a .NET application – so far it worked for native applications but not for my windows app etc
- Test the use of the simulator and see how I would use this in my work
- Review the various diagram generation options with a view to understanding how they would help with documenting my applications
- Look at making changes to the applications from within EA and understanding limitations etc e.g. when adding a class, sync the code, management of the project file..
- Explore what the VS MDG offers
- And of course explore using with other languages – Java – this may be some time off yet!
So until next time have fun with EA