End-to-end development with EA – Part 1

Spurred on by the information from last weeks EAUG meeting that Sparx use EA to develop their own code rather than the traditional IDE’s, I really thought it was about time to check out how much of an end-to-end development can be done within EA, and in particular when I had to dip out and use other tools.  An experiment that has been on the list for so long that I thought I’d spend a few hours to  just take a look, and see what I could do in that time.


As described below, the outcome of my brief experiment has been to develop code, build and debug two very simple applications – a console “hello world” type application and a windows form application. The only task that I wasn’t able to do within EA was the creation of the MSBUILD project files.  It may be that this can be done – but not clear from the documentation – so one of the investigations for part 2.

NB: The experiment has been to check out the process rather than write some outstanding code, so both applications are trivial and the code illustrated does not include any error checking not has it been thoroughly tested!

Before proceeding it is assumed that the reader is familiar with EA and I will only be highlighting stuff that is particularly pertinent.

Building a simple console application

The steps involved were:

  1. Create a package – in which to locate the relevant element (I also created a working diagram on which to put classes and scribble notes)
  2. Create a class – which had to i) be stereotyped “Module” and ii) have a method Main()
  3. Generate the code from EA – (Select the class and press <F11>)
  4. Edit the code – in my case adding a MsgBox (code illustrated below)
  5. Create a Build script within EA’s Execution Analyser
  6. Create a Debug script within EA’s Execution Analyser

Of course, in doing this there are some important points to note – it is very easy to miss something small and spend an age looking for the problem (well that’s software)

So I’ll now go through the steps, outlining some of the important, but not all the details.

Creating the “Hello main module”

This is simply a class (stereotype <<module>>) with a single operation (Sub Main).  When created you generate the code using the code engineering | generate code  (<F11>) – ensuring that you set the language (VB.NET) and a suitable path.

Then open the source file (F12) and edit the code – this is what my trivial application looks like:

Public Module Hello
Public Sub Main()
MsgBox("Hello, World!") 
End Sub
End Module

The Build Script

To be able to build the code in EA you will need to create a suitable build script.  There are in fact a few steps involved here which I will cover. Within EA this is under the Analyser section  – to access the Execution Analyser (shift + <F12>)

Using the Execution Analyser I added a package script to my package and configured the build commands – see screenshot below (detail also provided later where you can see the full line) :

In some more detail there are a few things to note:

  • The default directory uses an alias – this is configured in the “Settings | Local directories and  paths” – the screenshot below illustrates the setting for this alias.

This is really useful for keeping the paths portable, however I have learnt that the path for the source files are hardcoded into the element (“Genfile”) and so it is essential that you set up the alias before you do your code engineering.  Of course, if you import source code I don’t think it does a substitution of the path with an alias on import so the “Genfile” field may needed editing (something I should probably check as I’m not sure of all the rules).

The detail of the script in my example is:

call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\vsvars32.bat"
msbuild Hello.vbproj
  • The 1st line sets up the environments for the build tools – I just used the Visual Studio (VS) environment batch file, which is probably over the top in terms of what is needed but is quick!  This file may be in a different location on your machine – so check before assuming where it is!
  • The 2nd line builds the VB project using the project file which I had to generate outside of EA – see below – the location of this file is in the default directory.

Creating the MSBUILD Project file

There are three ways of building the (VB) code.

  1. Use the VBC compiler directly – this worked fine but when thinking about creating larger projects I anticipate that it may get a little complicated, so shelved it.
  2. Use the VS solution file – my thinking is that if you are using VS (devenv) then why use EA for your development.
  3. Use MSBUILD – this provides the richness needed to build larger applications in a structured manner whilst remaining clear of VS, so the selected solution.  MSBUILD is a very powerful tool – I’ve spent many hours exploring its capabilities and can say that it’s not for the faint hearted, but then again once configured for a specific setup it can be edited for a wide range of applications.

Below is the project file for the example for my Hello console app:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">x86</Platform>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
    <Import Include="Microsoft.VisualBasic" />
    <Compile Include="hello.vb" />
  <Import Project="$(MSBuildToolsPath)\Microsoft.VisualBasic.targets" />

The easy way to get started, other than copy the above – making sure you change the GUID and filenames etc … – is to create a simple VS project and use this as a starter.  You will then need to remove stuff that is not required or relevant to a basic build.  In fact I used VS to create the initial Property Groups, and now just reuse these for many projects – BUT don’t assume you can ignore it as if you make changes to the type of application you are generating they will need changing!  Worth noting that the Property Groups define the output files – and so are relative to the root location in this example.

The rest of the file will needs reviewing / modifying to reflect the specific application for example the ItemGroups with the imports and Compile and the key files.

If you are moving out of the safety of VS then you really need to spend the time learning about MSBuild. I have made numerous notes during my days of learning – although it was similar to tools I used in the distant past it’s different!

Building the “hello” application

Having configured the build script and called project file, building the application is initiated by selecting (checkbox) of the desired package script and using the Execution Analyser Build command (Ctrl + Shift + F12) – see screenshot below

Assuming all has been configured correctly then you should see a “Build succeeded”
message in the “System Output | Build”  tab – if not at least there should be some messages that could help resolve the problem.  In my case, a simple typo!

Setting up the Debugger

Although my example application does very little, it is instructive to run the debugger to check out the process.

To use the debugger a script will need to be configured within the Execution Analyser.  Selecting the appropriate package script and make the relevant additions under the Debug section as outlined in the screenshot below (but with you alias, paths, executable)HelloWorldDebugScript

The following must be set:

  • Required debugger – e.g. Microsoft.NET
  • Default directory – this is set to the root of my code tree
  • Application path – path from the “Default directory” to the application AND including the application file name e.g. Hello.exe

Debugging your application

With the code built and the debug script configured it is simply a case of setting breakpoints and starting the debugger.

Open the required source file (e.g. Hello.vb) and set a break point by simply clicking on the grey left hand border at the desired line (a red dot should appear).

Then press <F6> to start the debugger.

The EA debugger operates in a similar, but different, manner to the MS debugger, so beware that shortcut keys are different.  And there you are the application that you have code and built within EA is now running.

It is worth noting that the execution analyser has some really useful features that can be used with the debugger some of which I have covered in a previous post  and in which I list other information / tutorials that I found useful.

Extending to a windows application

Having got a basic console application working the next test was to check out the generation of a windows application.  For this example, I planned to use MS Windows form library and create the form/controls programmatically – no wizards/VS type tools involved.

To test the capability I added a simple create form function – see commented code below – to my Hello.vb code, and made a call to the code in the “Main” function.

    Public Sub CreateMyForm()
        ' Create a new instance of the form. 
        Dim form1 As New Form()
        ' Create two buttons to use as the accept and cancel buttons. 
        Dim button1 As New Button()
        Dim button2 As New Button()

        ' Set the text of button1 to "OK".
        button1.Text = "OK"
        ' Set the position of the button on the form.
        button1.Location = New Point(10, 10)
        ' Set the text of button2 to "Cancel".
        button2.Text = "Cancel"
        ' Set the position of the button based on the location of button1.
        button2.Location = New Point(button1.Left, button1.Height + button1.Top + 10)
        ' Make button1's dialog result OK.
        button1.DialogResult = DialogResult.OK
        ' Make button2's dialog result Cancel.
        button2.DialogResult = DialogResult.Cancel
        ' Set the caption bar text of the form.   
        form1.Text = "My Dialog Box"

        ' Define the border style of the form to a dialog box.
        form1.FormBorderStyle = FormBorderStyle.FixedDialog
        ' Set the accept button of the form to button1.
        form1.AcceptButton = button1
        ' Set the cancel button of the form to button2.
        form1.CancelButton = button2
        ' Set the start position of the form to the center of the screen.
        form1.StartPosition = FormStartPosition.CenterScreen

        ' Add button1 to the form.
        ' Add button2 to the form.

        ' Display the form as a modal dialog box.

        ' Determine if the OK button was clicked on the dialog box. 
        If form1.DialogResult = DialogResult.OK Then
            ' Display a message box indicating that the OK button was clicked.
            MessageBox.Show("The OK button on the form was clicked.")
            ' Optional: Call the Dispose method when you are finished with the dialog box.
            ' Display a message box indicating that the Cancel button was clicked. 
            MessageBox.Show("The Cancel button on the form was clicked.")
            ' Optional: Call the Dispose method when you are finished with the dialog box.
        End If
    End Sub 'CreateMyForm

To build this code required a few additions to the project file to import the relevant windows libraries within the relevant ItemGroups as illustrated below:

    <Import Include="Microsoft.VisualBasic" />
	<Import Include="System" />
    <Compile Include="hello.vb" />
    <Reference Include="System.Drawing" />
    <Reference Include="System.Windows.Forms" />

With those modification done it was a case of rebuilding the application (ctrl + shift + F12) and then it is all ready for debugging.

It was as easy as that.


This simple experiment has illustrated how to build both a console and a windows forms application using EA as the build and debug environment.

So here are some of my observations to date:

  • EA provides a framework into which the design, analysis and development can exist – a real plus in keeping information aligned
  • The VEA analyser has some really useful stuff – and I can imagine that this will be really useful with some checking out complex projects
  • For those not used to writing project files it may not be suitable, certainly not for the faint hearted – I’ve written quite a few and still don’t get it correct 1st time (or 2nd…) but the I’m also of an age when I am used to getting involved in the grubby details of compiling, linking and all that command line stuff from the 70’s – age does have some benefits!

Things I will explore/review

  • Could I manage the build project files with EA – using the “Tools | Customize” options I have included Notepad++ so can just jump to the editor from EA – perhaps that’s good enough but does leave the build files outside of EA (in the same way that the source files remain external once generated… )
  • The feasibility of doing end to end development with much larger and complex programs – it may be great for team working or not, how does it compare with other tools – I’ve used the analyser with a large AddIn and it worked fine if a bit slow, and I’m sure that there is more to explore here
  • In a broader sense the ability to tie in all the testing and extend the end point to support on going maintenance – with the aim that all the information throughout the lifecycle could be kept in an EA repository.  Is that realistic?  Is that desirable?
  • The ability to generate the windows form dialogs from EA – to date I’ve written my own libraries that convert an EA UI form to windows forms/controls – does EA hold any secrets that would streamline this process

So in wrapping up.  Although with these initial tests EA works I’m not sure how practical it will be, not least if you are tied to other tools it is always difficult to change unless there is a compelling reason to make the change.  For example, I can see that if you are working with client based applications then the VS wizards are useful.  Also if you like the features of edit and run mode that can operate with the VS debugger this is another difference.  But I think this is only the start and I’m keen to understand more.

So the questions that probably needs to be asked is  “Does EA have some really compelling features that would make a change from Visual Studio or similar IDE’s to EA as the development platform?”

With that thought I’ll publish this post.


1 thought on “End-to-end development with EA – Part 1

  1. Pingback: Sparx, Enterprise Architect, Class diagram quick start | Automate your world

Comments are closed.