Category Archives: Users

This is the general user of EA – they may be a BA, Developer, Tester – each will have an interest in what it can do to help them do their work

Global replace leads to EA Installation Inspector V2

For the first time in so many years of using EA I had the need to do a global text search and replace – one of my clients wanted to rename something!  Now I knew that EA did not provide anything as standard, however a quick look on the sparx community site to find an addin from Helmut Ortmann that does just want I needed – ho_Replace.  I was set and my task was done within minutes – thank you Helmut.

However, as you can probably guess it didn’t stop there.  As reading on the download page there was a comment regarding a problem with installing the tool.  Although I had installed without a problem I thought I’d run my Installation Inspector to check the entries only to discover it wasn’t listed. So how does EA know about it?

I quickly discovered that EA not only looks for AddIns declared in HKCU\Software\Sparx Systems\EAAddins, but also in HKLM\Software\Wow6434Node\Sparx Systems\Addins, a location my tester wasn’t checking.  So to help those looking for these extra AddIns I’ve modified the code, which now checks both HKCU and HLKM locations.

EA Installation Inspector V2 Screenshot

EA Installation Inspector V2 Screenshot

Also, as I often find that the line is longer than the screen I’ve added a pop-up form which displays the detail for a single entry, making it much easier to read.

EA Installation Inspector V2 Pop-Up

EA Installation Inspector V2 entry detail Pop-Up

For those who have downloaded already may be worth updating to ensure you can see the other stuff.

I’ve also been thinking about adding a facility to change the target DLL file – not least as I find that during testing of existing installed AddIns with VS it doesn’t update the DLL location as required.  Is this something of interest to others? Are there other functions that would help when developing/testing AddIns?

I have updated the entry on the sparx community site – where you can download this new release.


eaForms – is there a need for a simple EA client to help get people on board?

You may have seen, if you’ve reviewed information about our eaForms product, that one of the key reasons for the AddIn was to help overcome some of the issues we have experienced when trying to get people to use EA.  We have found that there are a set of people that I refer to as “reluctant users”, and from whom you may want them to contribute to the project by:

  • Providing Information – adding new packages/elements
  • Reviewing, editing or generally providing feedback
  • Approving items in the project

Needless to say, some of these people are just not be interested, whilst some may be willing to provide this information in a document or spreadsheet.  The former is the biggest challenge whilst the second will involve potentially time consuming, error prone work in harvesting the required content. Furthermore, if I’m the person doing the work, and not gaining any real insights into the project, I really don’t feel it’s good use of my time.  Yes there are tools to help (here’s a plug for eaDocX – it can readily import information from Excel; I wrote the Excel part following years of using VBA to get Excel content into EA – and it really does help!), but although a great help wouldn’t it be better if the creator of the information was able to work directly with EA?

When trying to introduce EA into a project I am sure we have all witnessed a mixed range of responses from those who:

  • see it, understand what EA offers and just can’t wait to get started

to those who:

  • aren’t interested, don’t understand why “another tool” and certainly don’t want to have to learn a new tool, and don’t have the time and will find any excuse to avoid meetings/trainings – the worst of the “reluctant users”. And unless remaining in their job depends explicitly on using EA they won’t, and it’s yours truly who will be picking up the pieces to ensure the completeness of the project.

So with eaForms we aim to help by reducing the perceived complexity of using EA, making it easier for users to get on board by reducing barriers to entry, and importantly, with the help of the local project experts, ensure that the editing forms meet the specific needs for the project and its users.

For an example Use Case form we only included the information our BA required using simple controls to help with the data input.  Also in hiding tagged values and using dropdown lists to limit input values to a pre-defined list we made it clearer what information was needed and any choice restrictions that should be applied.

eaForms AddIn Use Case form for our Business Analyst

eaForms AddIn Use Case form for our Business Analyst

We were thinking about our reluctant user’s and wondered whether it was possible to use the same form definitions we create with eaForms, but instead of within an AddIn use them within a simple standalone client that would.  In taking this approach, we could remove the need for the user to open EA and potentially, further reduce the barriers to using EA.

To test the idea we have produced a simple prototype client (illustrated below), with minimal menu options; we only offer – open and close an EA project, edit an existing element selected from a project browser and add/delete elements using editing forms defined to meet your project needs.

eaForms prototype client with same Use Case form

eaForms prototype client with same Use Case form

Using this client the user sees a much simplified interface and no longer needs to open EA and potential be confused or intimidated by the great range of options.  Remember our aim is to get users on-board quickly, so we hope that our eaForms client will provide either the new or reluctant user with a means to be included directly in the project work within minutes.  To be clear this is not a substitute for most EA users and is certainly not a powerful feature rich client but provides a simple means to capture important information into our EA projects without the existing EA users having to convert documents (Yippee!).

With the flexibility of eaForms the element editing forms can be tailored to meet users needs by project users.  They may include simple or complex controls, richer “gadgets” and action buttons to perform project specific task plus the ability to drive consistency of data input through value selection rather than free data text.

NB: Before I continue, there will be many, including myself, who feel users need to overcome their resistance to learning some UML and get to grips with EA.  But as we all know we don’t live in an ideal world, and have to adapt. So if our client provides a means to ensure that those that should be involved with our projects are, then we must surely increase the likelihood that we will have better projects.

Now it is my turn to ask you a question. We have a very small sample set of customers and hence we are interested your views. As a reader of this post it is more than likely that you are a committed EA user, so no need for this client, you are not the target audience (although eaForms may be of interest), however you may work with people that you would like to be users.

  • Who are they? What are their roles?  What tools do they use when they should be using EA?
  • What would they need for a tool?
  • Would providing them with a simpler client help them better understand the value of EA and hopefully lead them down the path to becoming a real committed EA user? Would having a simple client help you, if only to reduce all the harvesting that you may have to do!
  • Does the concept of a simple client make sense?

These are just some of the questions we are asking ourselves, there are many more we should probably be looking at and with that in mind are keen to get your feedback on this idea.  Please add a comment to this post or send us an email at eaforms(at)

I look forward to hearing from you.

Many thanks



Accessing your favourite tool from within EA

I’m not sure if this is just me, but there are a few things that frustrate me when working within a tool such as EA.

  1. Firstly, there is often more information I want to view at the same time than is possible because I just don’t have enough screens! There is a potential solution to this.
  2. Secondly, is when I want to do a related task using a different tool, so need to switch context. This is frustrating especially when I have my head down producing stuff and I just want to press a button.  This may be unique to me but the need to switch to another tool, which is more about the need to go back to windows and select the program, open it and establish context etc

So is there a way to improve the situation by having the tools I want operate within the context of EA?  Let’s do a little exploration to check out what EA provides and see if it can help me.

1. EA Tool menu

First up, in looking at the tools menu there are shortcuts which start an external application, albeit in it’s own window but at least it is just a single click.

I think the standard installation comes pre-configured with a few tools:

  • MS Paint
  • ODBC sources
  • System information

And you can add any application to the EA tools menu.

EA tool menu - add your own tool

EA tool menu – add your own tool

To add an application you use the “Tools | Customize | Tools tab” to configure the application. You need to provide:

  • A command – the application you want to run
  • Arguments – and EA supplies a range of parameters that can be set and passed to the external application
  • Initial directory – this can be set but doesn’t appear to have any dynamic options.

As an example I use IrfanView for doing a lot of image manipulations. So I can add a new tool item to support my access to this tool within my working context.

Configure EA tool menu item to open IrfanView with clipboard

Configure EA tool menu item to open IrfanView with clipboard

You see I have set the application, however there are no parameters available from EA that make sense within the context of the IrfanView arguments. However, the reason I want to open IrfanView from within EA is usually to manipulate an image, hence if I assume that I have saved my desired image to the clipboard with EA (ctrl+B) and then add an IfranView argument “/clippaste” it will open with the current clipboard contents all ready for editing.

Although this is no major advance it does improve productivity when producing help documentation!

2. Using the EA parameters

So what applications could benefit from the arguments that are available from EA.  I needed to think about this as it wasn’t clear what applications other than something specifically written to work with EA would attribute meaning to the arguments – initial and final thought was that this is only useful for applications you write.  I am sure there are some really good examples, however none come to mind so I’ll just illustrate a simple application to demonstrate the use.

Below is the code for a simple console application which takes EA arguments, opens an instance of EA with the project file name provided and prints the name of the current package.

==== Code starts =====

class Program
public static void Main(string[] args)
// the arguments from EA will be the project name – which may have spaces so need to be wrapped in “‘s
// command line input
// arg 1 – EA project full path filename ($f)
// arg 2 – name of calling application ($F)
// arg 3 – current package ID ($p)
// arg 4 – current package GUID ($P)
// arg 5 – ID of associated diagram  ($d)
// arg 6 – GUID for associated diagram ($D)
// arg 7 – CSV of ID’s for all selected elements in current diagram ($e)
// arg 8 – CSV of GUID’s for all selected elements in current diagram ($E)

Console.WriteLine(“Number of command line parameters = {0}”, args.Length);
foreach( string a in args)
//            Console.Write(“Press any key to continue . . . “);
//            Console.ReadKey(true);

// open EA

Console.WriteLine(“\r\nProject file = ” + args[0]);
Console.WriteLine(“Openning EA, please be patient!”);
EA.Repository EAR = new EA.RepositoryClass();
EAR.OpenFile(args[0]); // open EA

// now just use one of the arguments to do some processing
int packID = Convert.ToInt32(args[2]);
if (packID != 0)
Console.WriteLine(“Package ID = {0}”, packID);
EA.Package p = EAR.GetPackageByID(packID);
Console.WriteLine(“Name of current package = {0}”, p.Name);
Console.Write(“Press any key to continue and close EA “);

===== code ends =====

So with the application written I use the EA customise to add my application to the tools menu.

EA Console Tool - example of an application that can handle EA arguments

EA Console Tool – example of an application that can handle EA arguments

And when run from my tools menu the output is as shown below.

Example output from the EA Console Tool test application

Example output from the EA Console Tool test application

As such this is an example that doesn’t do a lot other than illustrated that the mechanism works.  It is possible to call an external application and pass it information within the current user context – I repeat the current user context – as this is where the value will come.

A brief recap

In looking at accessing external tools I have reviewed how to existing tools as well as a custom tool.

In the case of the existing 3rd party tools, unless they are written specifically for EA, it is unlikely they can do much, although the ability to open my graphics application with the clipboard presented is really useful, and I am sure with some creativity there are some excellent use cases.

In the case that we have a custom application then we have a greater degree of freedom limited only by the application.  It provides the user with the ability to initiate some action within their current context.  I know I need to think about potentially other applications for this use case.


But can we bring our application closer?

In both these instances the access to out application is a manual process.  The user initiates the application.

In our custom application example we saw how the information provided to open a new instance of EA can be used to perform some operations.  Of course, our application could be used stand alone, i.e. without being called by EA, but in that instance we wouldn’t have the contextual information which was my starting point.

One downside is that our application runs as a separate entity and to access EA requires us to create a new instance, with the inherent start up time lag.  So is there a better way of adding functionality to EA as well as integrating with 3rd party tools.  The simple answer is yes – EA provides an AddIn framework which can address the shortfalls of working at “arms length” and I’ll come back to that in a future post.

In the meantime, I hope that this post has been interesting and at least made you think about how you use other tools with EA.  If you have any specific use cases that haven’t been covered please feel free to share your requests, ideas..



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="">
    <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.

Simplifying the Element Properties Editor to make EA more accessible

For those presented with Enterprise Architect (EA) for the first time I can imagine that they could well be pretty confused, unless they have been introduced to EA with training that is tailored to their specific needs.  They need to be taught to ignore all the stuff that can get in their way by guiding them carefully in a structured way.

Like many tools rich functionality often comes at a cost, such as lots of menus and options which don’t add value to those users focusing on a single task area.

Many tools start life to address a small number of problems and, with a limited view of the world into which they will be deployed, no doubt strongly influenced by the developers own background. As the tool develops,  new requirements drive their expansion but in doing so it carries with it the baggage of history.  This is not a criticism but an observation.

This is a challenge for any tools developer. The ability to produce a product that meets the wide range of the users requirements, whilst ensuring that the product is accessible and usable. And this only becomes more challenging with time as users ask for more.

We know that over the last decade EA has grown in many different directions, with a large number of features and a high  degree of flexibility.  And it must be pretty rare for anybody to want all of them – in any case a steep learning curve; I’m still learning having used EA for a long time hence this site!

So if say you are Business Analyst(BA) without a strong technical background or tools background where do you start. I know from experience that introducing the tool to new users who have never used modelling tools before it can be confusing and there is a degree of resistance since they already have a solution be in Word, Excel or just a piece of paper.

If the new user is able to adopt a positive approach, we introduce them to diagrams and its toolboxes and then a few elements and so all is fine until they see the Element Properties editor and then a few questions are usually asked:

  • Why all this information?
  • What does this mean?
  • What do I fill in here?
  • That isn’t relevant at this stage of the project?
  • Can I only view the stuff I need?

Now one aspect of EA is that the properties editor is very generic and as such has more items that often needed for the job at hand.  Of course, having a generic editor has the benefits of familiarity across all elements, however for our BA they are unlikely to be doing this other stuff.

So our BA has the task of capturing the initial Use Cases and we want them to be captured in EA, otherwise we will have a further task of importing them and the classic problems with knowledge in multiple tools.  So if we want them to use EA how do we make EA accessible?

It was one of my colleagues who made the suggestion that wouldn’t it be useful to have the option to provide a simplified editor, specific to the element type, which would allow the essential basic information to be input.  And with the option to access the normal detailed property editor as and when needed (if at all). So that’s just what I’ve done.

I’ve started with a Use Case Properties Editor (UCPE), not least as my colleague is a very experienced BA who could provide the requirements.  So when a user double clicks on their newly added Use Case Element in a diagram they are presented with a specific dialog – as illustrated below a screenshot of partially edited form.

EX Use Case Edit Form

Screen shot of simplified Use Case editor

As you can see this form provides the basic information the BA may wish to entry including constraints and Use Case specific attributes, plus there is the option to link to relevant actors in the model – as illustrated in the screenshot below. (Default values for the non-displayed items can be configured so that sensible values are specified.)

Select Actor Dialog

Select actor from tree view of available actors

Edit Actors form

Screen shot of pop-up dialog to allow editing of actor properties

So now rather than deal with the choices of what to fill in on the detailed element properties window a user can use the UCPE, and if needed just press the “Detail” button to switch to the normal EA editor.

This is just the start and other edit forms could be available for other elements, and configured to meet the needs of users working in specific areas. The screenshots are based on my initial test version and this will no doubt grow with new requirements.  If you are interested in these ideas do let me know as it will help me in moving forward with this development.


There is so much more to Tagged Values than I thought

For years I’ve used the tagged values within EA.  However, for some reason I have always assumed that they were just used for strings and a few other basic types for storing numbers.  However,  this is not the case.  As I was reviewing the user guide for some related information the other day, I was surpised but delighted to discover that there is so much more, with support for a much wider range of tagged value types, with some really useful functionality.

Without repeating the detail (that’s in the manual – “Tagged Value Types”) the support for types goes way beyond the basic string, integer and other number formats to much more complex and functionally richer items including:

  • String based items (Directories, Filenames, URLs)
  • Date
  • Selection from Pre-defined reference data e.g. Authors, Phases, Roles
  • Reference to element or elements within the model
  • Checklists
  • Custom Tagged Value types that are defined using a template and can help validate data entry
  • and finally the ability to use an “AddIn” to respond to the tagged value broadcast event and hence provide an open ended ability to interprete what is stored, the actions etc

For these complex types suitable context sensitive dialogues are presented to support the setting of the tagged value.  Furthermore, each of these types can be set to apply to element types and/or stereotypes – the screenshot below illustrates a range of different typed tagged values for an element; in this case a class.

Examples of typed tagged values

Creating tagged values can be done using the “Settings |UML Types | Tagged Value Types” – remember to check the syntax in the user guide for specifying the “Type” , “Values”,  etc – the following screenshot illustrates a tagged value that will reference a Requirement element which has a stereotype “test”.

Creating a new typed tagged value

Typed tagged values can also be created through templates or MDG – so a bit more reading to do on this when I need to use them.

As Tagged Values are stored as reference data they can be exported to /imported from other model. The screenshot below illustrates the menu selections used to export the data –  note that a further dialog will appear where you select “UML Types | Property Types”Menus to export reference data

Now of course with this new knowledge I can immediately think if only I’d known about these before.   In particular, in setting up a model for a project I’ve found it useful to preset tagged values to ensure consistency, and the wider range of types would have been really useful.  Plus the ability to use an AddIn provides a means to “validate” actions, and much more.

Well this new found discovery just highlights how much exists within EA.  And in case you haven’t clocked all this stuff before – check out the user guide section on “Tagged Value Types” – really worth a read!

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%\”, 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 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  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

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