Monthly Archives: March 2013

Results from my initial experiments of coding from EA

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:

  1. They work – and there is a good feel factor encouraging more use of the tool
  2. 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:

NB: Sparx have tutorials, white papers, resource booklets – all with good information but in different places on their website so often not easy to find!

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:

  1. Created a simple windows application in VS-2010
  2. Create a package and imported the source code
  3. Created build and debug scripts
  4. Tested – OK
  5. 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)
  6. 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

  1. Checking my code flows etc
  2. 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.

Debug Script For EAAddIn

Debug Script For EAAddIn

So to run a debug session:

  1. Ensure that there are no instances of EA running
  2. Start an instance of EA (lets call it EA1) and open the AddIn model with the scripts, source code, etc
  3. 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.
  4. Run the testing instance of EA(EA2) and take a not of its Process ID
  5. In the Model instance of EA (EA1) start the debug script which will want to “Attach to process”
  6. When requested select the EA process with the process ID for EA2
  7. 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.


What next?

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

Advertisements

Using EA to debug an EA AddIn

Resolved all my initial VEA configuration issues and very pleased to have got going, not only with exploring the Sparx demos, but also with my own applications.

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 EA AddIn.  Not least as it would help me 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.  The key thing to remember is that one instance of EA is running as any other application that could be debugged, in this case from another instance of EA.

So the first step is to configure the Debug setup within the Execution Analyzer.  The set up I used is as illustrated in the screenshot below – the key point is that the debugger will need to “Attach to process” – this will be the EA instance in which the AddIn will be running.

Debug Script For EAAddIn
Debug Script For an EA AddIn

So before we start there will be 2 instances (EA Processes) of EA running.

  • EA1 – which will be the instance that is running the Analyzer
  • EA2 – the instance in which we will run the AddIn under test

So to run a debug session:

  1. Ensure that there are no instances of EA running – ensures that you don’t get mixed up with the different process
  2. Start an instance of EA (this will be) and open the AddIn model with the scripts, source code, etc for the Execution Analyzer
  3. 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) – Note: EA1 should be the only instance running.
  4. Start another instance of EA(EA2) that will execute the AddIn and take a note of its Process ID
  5. In the Model instance of EA (EA1) start the debug script which will want to “Attach to process”
  6. When requested select the EA process with the process ID for EA2
  7. You are now in a position to debug your AddIn using the EA1 instance – using source code and setting breakpoints, recording information to produce sequence diagrams etc

With respect togetting it going that’s all I needed to do – the next steps are down to the developer and what information they seek to find.

It is worth remembering that the execution of code using the Analyzer is very, very much slower than normal.  First time I didn’t think and it took ages to capture information for my AddIn.  So it is important to be selective about the areas in which you are working and the information you are trying to capture. At least there is probably time to get a cup of coffee when doing a run!

Have fun

Adrian

Documentation – what should it be?

In the last few days I’ve been trying to understand and use EA’s Visual Execution Analyzer (VEA)  and at times have struggled.   To get an overview I checked out Sparx’s video and immediately on trying to replicate it failed, so consulted the user manual and white papers which, unfortunately, didn’t provide the answers I needed.  In many ways I found that the level of information was either too vague or too detailed (and not the right details).  I did solve some issues by searching on the Internet but as a last resort I’ve had to raise a support ticket with Sparx who I hope will provide the information I need.

I will add that its not that EA is significantly different  (worse) than other development products that I have used, it just happens to be the one I’m exploring at the moment.  On the plus side I got a relatively quick intial response from Sparx and worth remembering that I still have several long standing queries to other vendors who have not yet even acknowldge my requests!

This episode (which I must add isn’t an isolated issue) made me think about the topic of documenting software and the challenge it presents for all involved – the developers, the marketeers, the uses, the supporters.. . What documentation is needed, by whom and when.  And this adds the dimension of the documentation that is needed throughout the whole life cycle of the software.

Some 30 years ago, in previous lives,  when I asked for documentation there was usually plenty available, it arrived in a very structured form with different levels of documents with index documents to help ensure that you could identify the correct document to access the information required.  Needless to say the manuals could easily occupy a whole bookshelf!  And perhaps I’m looking through rose tinted glasses or just that I was younger, brighter etc it also seemed that more accessible and digestible.

If I step back from a specific product, I need to ask whether, in general, products have got that more complicated? There are certainly more features, but is it more that the approach to development and the associated tasks of documenting have changed.

In our new world as soon as we can’t find something we tend to google it and hope that somewhere out there the information we need is returned by our particular selection and sequence of words; the response may reference the vendors documentation but more often than not the answer (if found at all) is elsewhere.

  • What does this say about the state of documentation?  If the user can’t find the information they need will they remain a user?  Will they seek alternative products?
  • What confidence would you have that there is real knowledge about the product?
  • And more so, as the manager responsible would you be happy making an investment in the product?

This episode (which I must add isn’t an isolated issue) made me think about the topic of documenting software and the challenge it presents for all involved – the developers, the marketeers, the uses, the supporters.. . What documentation is needed, by whom and when.  And this adds the dimension of the documentation that is needed throughout the whole life cycle of the software.

To start with I can’t recall coming across many technical authors in recent times, they exist but I guess a lot of documentation is now done by the developers, who undertstand the product in detail before the start.  The argument for using a technical author is that they are usually not very familiar with the product so they check it out, ask questions and get the information they need to produce documentation for the different types of users.

One of the ideas I had in my mind in exploring the VEA and its code engineering in EA in general, is that as a development tool EA could improve on other IDEs. In particular, it could pull together the knowledge of a product in one place from its initial concepts through to the working code, test results and beyond capturing information throughout its life.

With information captured and maintained within EA (“objects” and the “relationships” between them) it would be possible to extract the information as and when needed to meet a specific purpose.  This does assume that all the relevant information is added into the model – in my experience this is the biggest  challenge. A whole range of documents could be produced in a variety of formats – whether as we see now – Word, Excel or HTML or in a form that we haven’t even seen yet such as an intelligent voice based interrogation and summary system that would engage in a discussion with the user and providing the information they need and possibly providing a personalised guided tour through the product as if an expert were sitting beside you. And dare I say that will probably be the best answer to the question I have raised but back to today.

Of course, EA is only a tool and although it provides the foundation it would need supporting systems and probably some other tools/extensions to fully streamline the associated tasks. But we can use this as the vision, and work with this in mind.

I also worry that in a world which is increasingly living with disposable products will we consider our software in the same light? If so what about the software that is built using other software, is there a danger that we are building on shaky foundations?  Will we become dependent on the quality of tools that can reverse engineer and extract knowledge from the products we use, to protect us from a lack of documentation.  But in the meantime how can we document to the level that secures our future?  Do we have to specify a best before date on our software so that those who exist in the wider ecosystem can manage their risk?

So for the documentation – what are the drivers – here are some example needs:

  • Information needed by those working and managing the development – this set of users will have varying needs from feature capture, analysis, and design coupled with the management of those tasks in a structure manner
  • Information needed by the user –  who is usually paying for the product, so that they can gain the real benefit of the product, and hopefully communicate positively to others in turn may become customers?
  • Information for those tasked with ongoing support – they may not be those initially involved with the developed, so how do we ensure that the relevant information is captured; needless to say there are a lot of design decisions which could get lost in the process and be significant in the future.  As an aside one of the statistics I remember well is the fact that 80% of the cost of software is its maintenance so if the information isn’t available then that cost could rise.

Can these be realised with using EA?  Probably!

Some good stuff I’ve found using EA is its ability to help with:

  • Capturing information and share the ideas
  • Managing the requirements
  • Supporting the analysis
  • Producing the initial code generation for the classes
  • Reverse engineering code into a model to get information that is not available in documentation!
  • Producing documentation in the different formats needed by the different stakeholders.

And with its open interface EA

  • Enables the transfer of data in and out, and hence provides some protection if for any reason you need to extract data in the future
  • Provides a framework for extensions that can be used to bridge the gap between the tool and specialist needs.

These were both key factors for me selecting the product over a decade ago.

Now before we get carried away by the product we should remember that the biggest challenge is not the tool but the people and the systems associated with its use, but that’s a topic for another day.

So not sure I’ve answered the original question but rather provided some random thoughts and highlighted some of the challenges that face any tool that will be of use to others developing, supporting, using and managing product development.

And so for me now, back to exploring EA and try to understand what exists, what works and how it works.  Have fun.

Starting on the End 2 End development exploration

At last after a couple of months of heavy work on the day job I have had the chance to do some playing with EA.

As set out one of the areas I have been keen to explore further is how I can better use EA to help me in the development of my applications.  So far my use has been very much in the Requirements and Analysis phase with, in some case, the definition of Classes and basic code generation to get me started.

In those instances that I have tried to use it beyond these phases I get to the point that managing the 2 entities of my code and the model becomes a task in its own right.  Yes I can keep the code synced with the model to ensure that the Class documentation remains accurate however it appears from what I have read in various sources that I should be able to go much further.  So what can I do and is it reasonable that it can be done.

Well my initial review this week hasn’t been too encouraging, not least I have found the documentation a bit lacking for the newcomer.  The thought that you have to be an expert before starting to use the tool negates the need for examples and user mauals – well I’ll try and perservere as I’m confident that by doing so I’ll learn more.

One positive note is that I have used the “Import binary module” within the Code Engineering area and it work great in helping me get some useful information from a interface DLL.  So when you need to verify that the documentation and the interface provided by a DLL is accurate and complete perhaps a few minutes spent importing the classes / interfaces into EA could be helpful.