eaForms – a few new features that make my life easier

We have just released a new version of eaForms which, apart from a few maintenance items, has added 2 functions that I wanted to make my life a little easier, and hence I think could be of use to you.

The first relates to the use of the Genfile element field and the element linked files collection. The Genfile field is mainly used in class elements to store the source file which is linked to the class for example through a code import or code generation.  When you press F12  the filename in this field is used to select the file that is opened in an editor window.

Whereas the linked files is an element collection that can contain details of local files and web addresses.  Although we should aim to keep as much stuff as possible in the model this isn’t possible for all items, so having a reference that we can use to access the relevant item is useful.  So for these “file references” we have added the ability, within eaForms, to double click on the item whether it be a textbox containing the Genfile field or a listview of linked files, and using either the default windows associated program or an application configured in settings open the file (this can also be used to execute files if required). You can also use the context menu for textbox items as shown in the screenshot below.

Open file specified in Genfile from context menu

Open file specified in Genfile from context menu

The great thing is the ability to use a stereotyped element e.g. which contains details of the item plus the relevant filename so that you can directly open the file from within EA.

The second addition is really an experiment based on our observations of the increasing use of scripts.  We have added action buttons that will execute scripts either to

  • Save the element and then run a script
  • Run a script, and conditionally, on the result of the script, save the element or leave the form open

Furthermore, to avoid the risk that the script may not be available to the user we have embedded the script within the eaForm definition, and importantly it is the form designer who is responsible for checking it out!  As with any script related operations the uses are possibly myriad, although there are some restrictions.

Now, although these features only save seconds they can enhance the user experience or it may ensure important checks are made without the user needing to think.

If you’re new to eaForms then go to EA Workplace to download a copy to try

Do you have seemingly simple tasks you perform repeatedly that could be included as an eaForm capability?  Let us know what you need.


Your use of EA – feedback from survey

Thank you to all those who have taken the time to complete my survey.

I have now closed the survey (see my previous post) which was completed by nearly 20 people.  To some extent the level of response is no surprise as anybody looking at the forums and blogs will tend to see the same interested people.  I had hoped to get a few more to improve the statistical integrity but trust it will paint a useful, if rough picture.  In this post when I’ve added my own comments I put them in italics, so hopefully they are clear.

I found the results have been very interesting and personally I was surprised to see how much use was made of EA other than want I tend to call the front end stuff – “requirements and modelling”.  If we start by looking at the roles of the respondants, we do it is skewed towards the front end with no users who I would describe in the more downstream roles, although that may only be a reflection of their job name rather than their true role.  I guess there are many “Jack of all trades

Respondants roles

Respondants roles

Then we looked at use of EA within the organisation.

Use of EA within our team and organisation

Use of EA within our team and organisation

What we see is that it is usually more than a single person using EA and where used, its use is moderate.  My interpretation is that in those organisations who have committed to use EA, we see some use beyond the team although this is not the case for all and it is purely just for the team.

When we look at the key deliverables, this started to surprise me as not only did it include those expected:

  • Requirements
  • Business and functional analysis
  • Architecture
  • Designs
  • Reporting  – both HTML and Word

But some interesting items that implied serious technical use downstream

  • Database design
  • Desktop applications
  • Embedded software

When we look at our level of EA expertise we see that it is higher than those within their teams and organisation.  No surpise as I guess those reading the blogs and seeing this survery are those most interested EA.

EA Expertise

EA Expertise

Now the survey gets in a more specific.  The next question related to learning EA and getting information.

How do we learn about EA?

How do we learn about EA?

The responses were interesting in that indicate that stuff is OK, but from the comments there is clearly scope for improvement.  One problem I see is that EA is big, really big, and it’s potential use is so great it is a hard nut to crack.  To gain valuable use of EA requires either true committment from one or more users in a team, or well designed training and guidance – or probably both.    The comments also highlighted a lack of resources.  I know if you look around the forums it is the same few individuals (probably you) who contribute (which I trust you enjoy doing!). In fact, EXploringEA probably wouldn’t exist if EA was well documented with tutorials, examples, and other readily available training material covering all topics of potential interest.

When we look at the most important features  of EA we see that at the top of the list are the front end stuff reflecting the roles of the respondants.

Most important feature

Most important feature

Then if we look at allthe features that are used.

Use of EA features

Use of EA features

If we look at those areas that are only sometimes or never used we would start to take out:

  • Team management tools
  • Model simulation
  • Execution analyser
  • QA
  • Maintenance

Now if this was a true reflection of EA usage it would be a concern.  The ability to have a single repository of information throughout the project, tracking from the requirements and design to the implementation and testing is highly desirable.  Furthermore, having accurate information downstream to support ongoing maintenance is essential.  I can only guess that a some stage of the project information is moved to other tools which are then used moving forward to support the product during it’s lifecycle – let’s hope!

What I can gather from comments is that there are some really useful features of EA.  There were comments for most areas, especially those in the areas where there is not a high use. Here is a subset:

  • Database – “Great for quick re-engineering “
  • Automation  – – “deploying and operating something in addition to EA is something they usually do not want.” Reflecting the challenge associated with using AddIns.
  • Project management – “I think it can be a good alternative to never-updated projects created in Microsoft Project, but its UI is too technical for the minds of PMs, and therefore may never gain popularity”.    No surpise that PM’s don’t want to change.  I developed an EA addin for MS Project but found that project managers weren’t really interested in using EA, so a I then produced an addIn for MS Project that accesses EA but still not much interest.  If I was in their shoes why would I change, what more am can I gain. One further point is that the project management capabilities within EA look great for managing say a development team but do not cater for the broader business project management, planning and reporting; nor should they!
  • Team management – “I haven’t or hardly found any well-developed use case and user story scenarios models at my clients. Because of this, testing features are of no value for them, until they understand why an up-to-date model with detailed requirements and scenarios are important” Interesting in that I think a lack of real detailed examples really is a limiter.  If there were real world examples which were well crafted and could be mapped to current working practices it would be great.  I guess that the problem here is that this would be valuable intellectual property and hence nobody is able to provided… Anybody have ideas on what could be done?
  • Maintenance – “Roadmapping works well. Trick is to have as-is and to be changes at the start end end of change dependency diagram.” It was great to see this comment as it really implies somebody is doing the right thing and managing the work from requirements to deployment and ongoing maintenance.

What is missing from EA?

The comments included:

  • Better Excel support – I will start with this as I have a personal investment in eaXL and see that this can do a lot – perhaps we haven’t communicated enough detail (!), so let us know what is needed and you never known.  And, now Sparx have their own Excel tools.
  • Intergration with other tools – notably publishing tools to make information available to a wider audience.  Although HTML is available organisations how their own preferred tools.
  • “Stop changing the UI in every release”
  • “A streamlined report/template editing facility, which enables manual editing, with a great UI, such as those you can find in visual query builders.”

Final feedback

I think I can summarise a sense of the feedback from one of the final comments:

“Great tool – but I think it tries to expand its scope too much”

Also in trying to do so much “some features need to be sharpened” – which apparently comes from a domain expert indicating that in adding some features they were not accurate in meeting the real need.

So there we have it.  For me, I’ve had some interesting reading which has generated some ideas for furture exploring and posts.  In the meantime, I’d like to thank those who took the time to contribute to the survey, and trust that you find this feedback useful.




Let me know about your use of EA

In EXploringEA I’m always keen to look into stuff that may be useful.  I have a view that there is so much in EA that I really don’t know about or fully understand (and this could be the same for you).  Of course, it is difficult to document such a powerful tool in a way that makes the product fully accessible to all (I have some ideas, but not the mandate or resource!). I know I’ve suffered many times from some small detail being missed, or inferred from a previous topic that I may have skipped, in my eagerness to play and subsequently spend hours trying to get something working!

There is plenty to discover, for example from the various forums, however there must be people out there doing some interesting stuff that is never reported and could go well beyond my expectations. Of course, the problem for anybody,especially under time pressures, is getting to know about stuff that may be useful to them when it is needed.

Having focused on scripting for a few months (not finished as I’m still exploring a few areas) I’ve been thinking about some other areas that I don’t fully understand, with a view to putting together some experiments to look into more stuff that I hope is potentially useful. I have my candidates list but, following a couple of recent posts I’ve had some useful feedback which has pointed me into some interesting, but not conclusive, directions.

In thinking about some of the areas to explore I get a sense that I am missing something.  Much of my experience of using EA has been with the front end tasks – requirements capture, modelling, analysis and design; if I look at user guide I’ve not even  got half way through!

So I am curious to get a fuller understanding of what and how EA is really used.  And, with this in mind, there is no better way than to ask you, EA users.  So my idea is to conduct a short survey, where you can help let me know how you use EA, what you think it does well, and probably most importantly areas that you would expect it to do better.

I’ve tried to make it easy with tick boxes.  I am not asking for detail,  but have provided space if you wish to add any comments that you think would highlight the value or issues with EA, so that I can just get a better understanding of what is being achieved with EA – what it does as doesn’t do this could be a help to me and others.

This anonymous survey is now available at How to use EA survey.   I’ll leave it there for about a few weeks, to give an opportunity to as many as possible.  Then I’ll consolidate the data and share a summary of the result in a future post, so you can see what our little world is doing with this great tool.

I am sorry that I cannot offer any incentives other than I will share a summary of the results in a future post, and the hope that I will continue to post information that may be useful to somebody.

And, of course, hopefully be inspired by you to explore other areas and application of EA.

Thanks for your help.


Automatic testing of EA AddIns

This post was inspired by a post on the Sparx forum a couple of weeks ago which was asking about automated testing for AddIns. This got me thinking about what can and can’t be done in EA using scripts and/or code, and what else may needed to perform the task.

The problem with testing is often that you need to emulate the actions of the user through a windows UI, and this is the case that was highlighted.  Without interaction through the EA UI AddIn Broadcasts events are not fired, and hence our AddIn would be outside of the processing  loop.

If we look at an example.  Say we have an AddIn which adds an attribute to every new class that is created.  To test this functionality we need to manually add our new class element through the EA UI.

So any solution we develop requires us to be able to replicate the manual interaction with the EA UI, perform the required sequence of tests, and then check the results to verify that our AddIn worked correctly.

Fortunately there are test tools that will emulate user inputs for windows application. So keen to validate my proposed solution I set to work:

  1. Create a small test AddIn – that simply added an attribute to each new class added (probably not a real use case but at least it’s easy to do an very visible}
  2. Use a test tool to emulate the manual process of adding  a new class element (and hopefully ensure our AddIn received the required events!)
  3. Run a script that could verify our new class element had its attribute added. I was planning on using EA scripts to do this, but as I’ll detail below I ended up using an external script to access the automation API to access the model and perform the checks.

So now for the detail and results of my experiment.

1. Create an AddIn

To check the process I needed a test AddIn – which I called TestingChecker, that responds to the OnPostNewElement event, which is fired by EA when a user adds a new element. Here is the code stripped of all error handling code

Function EA_OnPostNewElement(Repository As EA.Repository, Info As EA.EventProperties) As Boolean
Dim myElementID As Long = Info.Get(0).Value
Dim myElement As EA.Element = Repository.GetElementByID(myElementID)
    myElementID = Info.Get(0).Value
    myElement = Repository.GetElementByID(myElementID)
    If myElement.Type = "Class" Then
       Dim et As String = myElement.Type
       ' add an attribute
        Dim a As EA.Attribute = Nothing
        a = myElement.Attributes.AddNew("NewAttribute", "")
        a.Name = "New Attribute"
     End If
   Return True
    End Function
End Class

Nothing special here, so I assume you are happy with this and it’s operation so no further comment.

2. Testing the UI

I hadn’t used windows test tools for decades so had to reacquaint myself with what tools were available.  A quick trawl around the Internet and there were plenty to chose from, but which? Many required the writing of scripts, whilst others promised more features including the power of recording a users input which could be replayed.

So with the aim of minimising my effort, I downloaded a trial copy of one of the more powerful products and set about “recording”  my inputs to EA.  However, I found it very frustrating with the tools ability to select the correct UI items.  When the recorded scripts were replayed I found that they weren’t as good as I had hoped, and failed to select items correctly.  Hence the tool failed to perform the required tasks. I suspect the recording process relies on mouse location rather than correctly identifying controls, or the challenge with identifying the EA controls..  So rather than spend more time trying to work around these issues I decided to jump in and write the scripts myself.

Based on that decision I downloaded AutoIt (a freeware toolset).  The information on this tool stated it could perform the required control selection and provide the required user inputs.

Tools needed:

A few notes relating to the AutoIt tools.

The AutoIt Full Installation download includes all the tools required although it only contains a lite version of SciTE and I read it is recommended that you download the full version of SciTE.

You use SciTE that you use to create your scripts with AutoIt Window Info tool to get information that you need from your application under test e.g. control details. You can compile, build, run you scripts from the SciTE tools options, and if you needed can access the Koda GUI Form designer from the same menu.

In the SciTE help file, amongst other useful information, is a simple Notepad automation tutorial which was sufficient to get me started – I would suggest you work through the tutorials to gain familiarity with the tools.  Also for those interested there are several more tutorials.

Following the inevitable trials and errors I was able to write scripts that could select controls and perform the required actions.

To make it easier for testing I set up EA to use a default model (so didn’t need to specify when running EA) whose initial content was:

Initial Model Content

Initial contents of test EA model

Using the AutoIt script I produced a simple function that will:

  • run EA – opening default model
  • add a single class element
  • close the EA file
  • close EA
Func AddStuff2EA()
$PID = Run("C:\Program Files (x86)\Sparx Systems\EA\EA.exe")
WinWaitActive("WinTextCheck - Enterprise Architect")
; get focus on EA
$Res = ControlFocus("WinTextCheck - Enterprise Architect","",2)
;Send("^M") - want to send cntrl+M but there seems to be an issues - the following code found on wbe
; http://www.autoitscript.com/forum/topic/125359-solved-send-ctrlm-leaves-ctrl-pressed-in-some-way/
Send("{LCTRL down}")
Send("{m down}")
Send("{m up}")
Send("{LCTRL up}")
WinWaitActive("New Element","") ; wait for dialog to present
Send("Class 1") ; enter name of new class
ControlClick("New Element","Save",1) ; save the class dialog
; close EA
$Closed= ProcessClose($PID)

This code could be improved and clearly if you were in production mode, where you needed to add lots of elements and other stuff, you would restructure with a proper design!

Running this script and inspecting the model we can see that the class element has been added together with the attribute added by my AddIn.

Model Contents after adding New Class

Model Contents after adding New Class

3. Checking the results

Now I want to have a means to check the results automatically, checking that the model has the required contents.

My initial approach was to use EA scripts which could be initiated by through the UI, however a combination of issues meant that I changed my approach. The issues were:

  1. Accessing the relevant scripts within the EA UI – one of the issues I did find using AutoIt was the ability to access a specific script; I guess that is more I need to explore in the the tool to do this accurately.
  2. Ensure that the scripts were present in the test model
  3. Wanting any checking to be independent of the creation scripts.
  4. AutoIt scripts could interact with COM and hence allow me to access the automation API

So with that decision made I created a simple script that would interact with EA, using the normal automation API, to open the test EA model and check that both the new element and its attribute had been added to our model. The code for this function below:

  • Opens an instance of EA
  • Looks for the element I have added
  • Checks that the AddIn has created the attribute for this element
Func CheckCreated()
$EARep = ObjCreate("EA.Repository")
$F = $EARep.OpenFile("C:\Users\adrian\Documents13 EA Related\WinTestChecks\WinTextCheck.eap")
Local $Models = $EARep.Models ; we only have one model
Local $Model = $EARep.Models.GetAt(0)
Local $Packages = $Model.Packages
$NumPackages = $Packages.Count
; now do the check for package "Package1" with "Class 1"
For $i = 0 to $NumPackages-1
	$P = $Packages($i)
	$N = $P.Name
	if $N = "Package1" Then
 		$Elements = $P.Elements
		 $NumElements = $Elements.Count
		 for $j = 0 to $NumElements -1
			   $Element = $Elements($j)
			   $ElementName = $Element.Name
			  if $ElementName = "Class 1" Then
 				   $Attributes = $Element.Attributes
				    $NumAttributes = $Attributes.Count
				    For $k = 0 to $NumAttributes - 1
					     $Attribute = $Attributes($K)
					     $AttributeName = $Attribute.Name
					     if $AttributeName = "New Attribute"  Then
						       ConsoleWrite("Attribute found" & @CRLF)
						       ConsoleWrite("Closing EA" & @CRLF)
						       ConsoleWrite("====== Checks complete ======" & @CRLF)
						       return true
ConsoleWrite("Closing EA" & @CRLF)
$EARep = 0
$EARep = ""
ConsoleWrite("====== Checks complete ======" & @CRLF)
return False

This did the trick (once again a piece of test code so for the real world would expect to see something a little more refined!)

Final script

Having got the separate parts working I created a script that calls these functions plus including some code to output results to a log file as illustrated below:

#include "AddStuff2EA.au3"
; Script Start - Add your code below here
ConsoleWrite("Starting EA test" & @CRLF)
AddStuff2EA(")) ; we add a class to EA
ConsoleWrite("Checking EA model" & @CRLF)
 ; log file
	$myfilename = 	"C:\Users\adrian\Documents\testingChecking.txt"
	$FSO = objCreate("Scripting.FileSystemObject")
	If $FSO.FileExists($myFileName) Then
  ; we want to open with append
		  $FileObject= $FSO.OpenTextFile ($myFileName, 8, True)
  		$FileObject = $FSO.CreateTextFile ($myFileName)
   ;Create new file (or replace an existing file)
   $FileObject.WriteLine("New log entry.. " & _NowTime())
$CheckIt = CheckCreated() ; call function to check that the class we added PLUS the work done by the AddIn has been completed successfully
If $CheckIt  Then
	  ConsoleWrite("Item found" & @CRLF)
	  $FileObject.WriteLine("Item found")
	  ConsoleWrite("Item NOT found" & @CRLF)
	  $FileObject.WriteLine("Item NOT found")
ConsoleWrite("xxxxx All done xxxxxx" & @CRLF)

If we now run this script we can see the output in the Console window.

Running test script within script editor

Running test script within script editor

We can see the outcome was successful but not that friendly.

What next?

This code was written as proof of concept to check capability rather than for production use. Furthermore, the scripts would need to be modified to:

  • Create (or copy a clean copy of) the initial EA model to ensure the same base
  • Handle the EA model names – and not rely on setting the model as default
  • Add other tests for the specific target AddIn

One useful feature of AutoIt is its capability to create a GUI interface, and thus for the execution of regression tests we could produce an application that was a little more friendly.

A useful tutorial “learning to script with AutoIt” includes a brief introduction to using the GUI functions.  In addition,and included with the AutoIt download, is a GUI Builder tool (Koda) which can help produce the GUI scripts.

Also AutoIt can be used compile the scripts into an executable, which can eliminate complexity that may be associated with running the tests for those without knowledge of AutoIt.

So to test this, and using Koda to help design to UI, I created a GUI application with my existing test scripts providing most of the functionality.  This simple GUI application is illustrated below.

AutoIt based GUI Tester presents a friendly test tool

AutoIt based GUI Tester presents a friendly test tool

Nothing fancy but straightforward to use.  A much more sophisticated application could be developed if required.  The plus is that the user simply starts a simple windows executable.


In this post I have explored the ability to automatic test EA AddIn.  Using AutoIt scripts to emulate the user input as well as interact with the EA automation API I have demonstrated that this is possible.

I found AutoIt straightforward to use and was impressed by its features.  Also it is a plus that it is freeware.

I hope that this post is of interest to those working with AddIns (as well as other areas) and would welcome your comments or feedback.


What are the hot EA topics?

I’m taking a few weeks off, so I’m in holiday mode enjoying the sun and reducing my time in a dark room of computers, but although I won’t be doing many experiments I had it in mind that one job I should do is to review my list of candidate experiments ready for me return.

Every time I look at my list (infrequently), I get a sense that there is so much in EA and however much I explore there will always be more.  I guess this is no surprise as the tool evolves to meet users needs faster than I can explore, so my candidate list is just a guide to some of the areas I could explore when I next get idle.

Hot topics

I would guess that there are 3 hot topics:

  • Scripting _ If I look back over the last 6 months I’ve spend at lot of time looking at scripting. And judging by what seems to me an increasing number of queries on scripting on the Sparx automation forum I guess this could be considered a hot topic.
  • AddIns – There continues to be a steady stream of issues with AddIns and from the questions raised indicate more people are developing their own AddIns (my advert – we can help with AddIn developments!) as well as more being added to Sparx own list.
  • Documentation and reporting –  I have noted an increasing number of questions relating to producing documentation/reports in a variety of formats.

How accurate my observations is unclear so I may have missed a major topic; it would be interesting if there were statistics available (Sparx are there?).  What do you think I have missed?

Some of the topics that I don’t see much (or I’ve just missed) that were on my list are:

  • Application development
  • Model transformations

Perhaps that’s because those using fully understand.

What else for my list?

In starting to review my candidate list what came to mind was a post on the Sparx forum on testing AddIns last week.  It prompted me to think about what we use EA for?

We know that EA could be used throughout the development cycle whether modelling, analysis, design, coding, testing and maintenance. (I could possibly add project management but I guess that this will be a small number of users, not least based on the level of interest we have received for our MS Project and TeamPulse AddIns!)

From my experience the majority of users fall into the first 3 categories – modelling, analysis and design.  I think this observation is further supported by the topics covered at EA user Group meetings I have attended. Yes, there are a few well documented exceptions such as embedded code development but not much else.

Does this mean that like other tools I can think of such as Microsoft Word, EA is positioned by a few key features, and even though it continues to evolve the major use remains the same.  If we think about Word most users only use a small number of the product features; there are power users who can demonstrate some amazing stuff that can be done, however this requires awareness and knowledge of how to perform the task, and all too often users don’t go looking. It was this thinking that was part of the reasoning behind EXploringEA, the opportunity to go where others have not gone before…

So are there parts of EA that we are failing to use that could make our developments easier? better? quicker? cleaner? more maintainable? ….

It was the post on testing AddIns that reminded me that one of my goals with EXploringEA was to be able to fully understand the viability of managing the whole software lifecycle from product concept to its ongoing maintenance within EA. I had a vision that one tool containing the “knowledge” would help the overall process and its management.

Yes, there will be a need to call other tools – compilers, linkers, database tools, documentation tools … but no major distraction and if EA could truly be the kingpin to manage our world, would our developments be better?  or am I just trying to push all into a “box” which is just not the right size for the problem in hand?  And if there are too many other tools with which we need to interact are we just complicating the process?

So is my desire to manage and orchestrate the development in a clear and clean way getting in the way of a realistic development process? I hold my hand up and say I don’t use EA for the majority of my coding but somehow wish I could, and maintenance that’s another story.

So imagine that EA were the primary tool for our developments, with a few associated specialist programmes to do the detail, how would each of us feel whether we be business analysts, project managers, developers, coders, testers, supporters?

This approach raises a lot of issues, but for the moment here are a few questions:

  • Is EA only suitable for the modelling, analysis, design?
    • Is it sufficient and able to perform these tasks?
    • Is it viable to use EA in other areas such coding, testing, maintenance and if so what reliance is there on other tools? (Just seen the draft agenda for the EA User group meeting in London – with a talk on using EA for Full Project Lifecycle,  which could shed some more light on this)
    • Can we use it to produce all the documentation that we need, not only for our up front design activities but documents that meet the needs of testers, supporters and maintainers?
  • In  what areas are there are good case studies? (I need to look out for some, and if you have one let me know if I can add a link to it to help others?)
  • What additional tools are needed to support general purpose windows development?
  • And always – what questions should I be asking and I haven’t?

I also mustn’t forget to ask again – what are the hot EA topics?

I hope that is thought provoking – it has got me thinking – but then with the sun on the terrace …

I’ll be back soon.




eaForms – using the eaForms action buttons !!

A couple of weeks ago I outlined my view on the usefulness of lists when editing EA elements. In that post I illustrated the ability to add buttons to an eaForm which could be used to initiate some action such as adding a property.  By providing buttons that initiate action we provide a means to perform the task with minimal context switch and hence minimal effort.

SimpleClassForm illustrating use of buttons

A Simple Class Form illustrating the use of buttons

If we look at this example form we see standard buttons to Save or  Cancel our element editing. We also see buttons which allow us to Add… properties to our element. For example,

Adding an attribute presents simple dialog within context of open element

Adding an attribute presents simple dialog within context of open element

our Add Attribute button will present an attribute form within the context of our already open form – no switching just a single button push.

We have a range of other buttons which cwe can use to add element properties (often they are are specific to the relevant element type) – for example:

  • Add a tagged value
  • For Use Cases we have add Actor, Pre-/Post-condition
  • For Classes we have add Attributes/Operations

We also have a Detail button that can be added to the form and will save updates to the current element then open the element using the standard EA properties editor; a button we feel is useful for the experienced EA user who may at some time wish to switch for an instant.

Create related note or element

In my experience in addition to editing element properties the other may task is to add stuff – notes or new elements related to my current element, so we have added buttons that assist with this task. The example below illustrates a add a linked element button – which when pressed presents the user with a dialogue to enter basic information about the element and its relationship to the current element.

Add linked element to our current element

Add linked element to our current element

Button options include both linking and / or owning the element.

Also, although not a button, within eaForms we offer the related element control which allows the designer to specify a desired connection between the element that the user is editing and another element (optionally with a specific stereotype) and with a specified connector type.

Script buttons

During recent work we have seen the benefit of scripting and have been working with some “experimental” buttons within eaForms that will not only save or potentially save an element but also run a script.  At present we have included 2 script buttons:

1. Save and run script after save – which will save updates to the element and then execute a predefined script, performing some post saving action.  For example, we could add an entry to a file to indicate that an element has been approved or some other project relevant event.

2. Run script and conditionally save the element or remain in edit – this button runs a script and depending on the outcome will either save any element updates or stay in editing mode, without saving any updates, and so presents the user with making any relevant modifications or preventing them saving updates that do not confirm to some project specific standards.  By proving the option to perform pre-saving checks we can help ensure the integrity of the project.

In providing these button options we recognised the potential for issues with scripts.  The first is which script to use and where it is located, so we decided to include the script within the eaForms definition.  So if we look at a very simple form with a script button and its control definition we see the script code can be edited – this script adds an entry to a file

A script button and its definition

A script button and its definition

The second issue is the operation of the script – in our early release we have limited the scripts to VBScript and further do not support INC’s – and hope that is not too restrictive.  We have found that most of what we would see as needed is readily available within the existing windows environment e.g. the use of the File System Objects.  We will review this in due course.

Finally, are there other script buttons that would help. Do we want to include a “Run Script” button that performs a task without doing any pre-defined action?

At present these script buttons are at an early stage and the use cases may be a bit vague but part of the reason for including them was to see if they help the user or other aspects of model quality – which is part of the aim with eaForms


In this post I have outlined the use of buttons within eaForms –  from the simple add properties to the more powerful buttons with scripts that provide the user with the flexibility to do their own thing.

As always hope this is of interested and welcome your questions and feedback.


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)exploringea.co.uk

I look forward to hearing from you.

Many thanks



eaForms – using lists to access element and related information

Each EA element has a range of collections which contains information about the element or related “things”.  Just a quick look and you will see a range of collections associated with each element, for example:

  • Attributes
  • Methods
  • Connectors
  • Diagrams
  • Elements
  • EmbeddedElements
  • Requirements
  • TaggedValues
  • Files
  • Metrics
  • Realizes
  • Resources
  • Efforts
  • Risks
  • Issues
  • Tests

Depending on your role and/or stage in a project you may be interested in some or none of these bits of information.  But as a collection of relevant information it can be useful to have a view of them during your work.  To access most of these items with EA you will often need to make a menu selection.   However, as we may use some of them frequently wouldn’t it be useful if we could see them without this need for additional user input.  When developing eaForms it was our view that having visibility of the required information at the same time would be useful when adding or editing elements;   the ability to see the information at a glance plus the ability to add a new item using an action button was our vision.

So with eaForms we have provided a list control whose data source can be set to display a wide range of collections.  Furthermore, within these lists we have added the ability to select and open the related item for example with Use Cases (Actors, Pre/Post conditions), Classes(Attributes and operations) as well as requirements and other related items for which we can interpret the target item (at present we have added what we see as the useful stuff).  This allows the user to work within the context of the current opened element to view and edit the related information.

As an example, let us start with a look at a simple requirements form were we have included a list of linked items:

Simple requirements form list related items

Simple requirements form list related items

We can double click on an item in this list to open the relevant  item – in our example another requirement (we can drop down into other elements as required)

Opening a related item

Opening a related item

As a more complex example let us look at the Use Case form below – which includes linked actors, pre-/post-conditions, tagged values and linked items

Use Case example with several lists

Use Case example with several lists

To this form we can add action buttons to this form – as modified below – where we also illustrate adding on a new post condition within the current element editing context

Use case example with action button - to add a new post-condition

Use case example with action button – to add a new post-condition

Of course, what you place on your eaForms is up to you, that was the core idea behind eaForms. The ability to adapt the editing forms to match both the needs of your project and the users working on the project is key.  With eaForms you not only select the content but also define the layout and its presentation (look and feel) to meet your specific needs.  Having lists is one of those features that can help present the information in a better way for you.

I hope they provide you with the information you need.  Feel free to let us have your wish lists of additions.



Scripting follow up on case #6 – prevent execution of script on AddCode – solved??

When researching information for my recent scripting experiments one of the posts I came across highlighted an issues that when adding the script code using the Script Control addcode method the script would execute. The post cited was a simple script:

 sub main
  MsgBox("main executed")
 end sub

I had also observed a few cases myself but it appeared inconsistent.  Now I’ve come back to look at the problem, by just looking at the code with fresh eyes the solution was obvious, wasn’t it?

If I step back to the early 1970’s using basic interpreters, I entered the subroutines/functions then added a line to specify what routine to call. At which point the code would run. So if we look at the code example we see the subroutine plus a line “main” which I can only imagine is saying run “main”.  A quick check with my EA Script Tester AddIn, and yes this appears to solve the issue.  I removed the last line i.e. “main” and the AddCode just adds the code without running, and the run does as we expect.   And to check, putting “main” at the end and the script runs immediately on adding the code as well as when requested to run.  BTW: I’m not sure that is what was referred to as the solution, which referenced needing to strip out the calls; however I felt it was worth checking out so I understand the rules.

Now just as I am cautious and curious I ran a few more tests. I started with a script that included a few subroutines.  Ignoring setting parameters and any required objects the basic code consists of:

 result = myScriptControl.Run("NAME OF SUBROUTINE TO RUN")

So if I create a new script, as below, which has several subroutines I performed a few tests.

sub main
end sub
sub A
end sub
sub B
 msgbox ("B")
end sub
  1. Running the code as illustrated it ran twice.
  2. I then removed the last line (“main”) and it only runs with the .run method is set.   Worth noting that you can specify any subroutine name and it will run accordingly. But don’t forget that if the subroutine has parameters you need to configure and set the parameters object as the second argument of the run call as well as set up any dependent objects.
  3. I added calls to the subroutines between them and yes it does execute on loading .  In testing it looks like all the code is loaded and then executed.
  4. Finally, I added one or more of the subroutine names at the end of the script and as I would expect it would run them in the defined sequence.

In practice, when running EA scripts either in an AddIn or external program, to ensure the code isn’t executed when added we need to strip out any lines containing a reference to a subroutine in our script that are NOT contained within a function or subroutine otherwise they will instruct the script control to execute upon adding code.  This was included in the initial post and although it may be a challenge not sure there is anything else – it’s the way the “interpreter” works and I guess for backwards compatibility will always work.

Of course, we could want this behaviour – in fact I can see a case where some subroutines run to initialise “stuff” before a call is made to a specified subroutine – up to the designer/user.

Having looked at a lot of documents on scripting in windows during my recent experiments I can’t recall any reference to the behaviour outlined above, although there are references to a distinct lack of documentation about the script control in general and perhaps this is the real issue!!

I hope this is useful, and if there are other “script funnies” I’d be interested to here.


PS: This was the issue highlight in my test Case #6 if you are interested.

Scripting follow up on case #7 – can a script call a running EA AddIn

Calling a running AddIn from a script was has been a really interesting issue – read the original post for the background to this use case – and with some useful observations from my associated post on the Sparx Forum.

I have explored further, and not quiet managed a workaround, and as outlined in this post do not expect a viable practical solution, but in the spirit of sharing my findings and coming to this conclusion, here is an outline of my experiments.

A test DLL

To help work discover what goes on with an EA AddIn, I produced a small AddIn(DLL) – called DLLTester.  It’s main purpose was to be a very simple, normal EA AddIn with the added benefit that I could use it capture relevant system information that could help in investigating “the issue”.

EA and scripter do not share a DLL

Thanks to Geert who pointed out what appeared to be a very simple solution.  Based on windows documentation and various posts it looked like our AddIn DLL code would only be loaded a single time by the EA, process and if subsequent instances were required, they would share the same code. This would mean that static data would be shared across the different instances.  So if during the initial load we store a reference to our AddIn as a static variable, it could be retrieved by all subsequent instances as required.

In my initial test, I run EA and my AddIn loaded (the initialisation worked fine).  I then create a new object in the script (see code below).  And based on the premise that there is only a single copy of the DLL loaded, I would expect the code to be the same as the already loaded AddIn DLL, and hence the static data would already be initialised, and readily available as a reference to the required DLL.

Set myDLL= CreateObject("DLLTester.DLLTester")
Set myAddInRef = myDLL.getRef()

However this was not to be – I found that the static variable retrieved by my script was not set, and hence the was not the same code.  Upon further inspection, using Process Explorer  (see from the screen shot below), I found that EA and its Scripter engine exist in different processes (see PID) and hence their DLL’s are clearly different.

Both EA and SSProfile32 have a copy of the DLL

Both EA and SSProfile32 have a copy of the DLL

The fact that they are different processes not only prevents an elegant solution but dare I say a practical safe solution at all,  unless we start looking at using interprocess communication(?). Now even with my early background in writing operating system software (RSX, VMS – I am that old!) and that one of the key people behind both those operating systems and windows (Dave Cutler) which could suggest a common approach to the windows internals, I still wasn’t encourage to explore, perhaps another time.  So I think I’ll have to park the idea that we can implement case #7 “call an Addin from a script” for the moment.

However, before finishing, and purely out of interest I was keen to have a quick look at what I may be able to find. So here are a few things I did.

Looking for more information about the EA copy of the DLL.

Never one to give up I reckoned there was a means to get more information.  As we know that the parent of our Script control is EA, and the required DLL was a child of EA,  so we should be able to trace back and get some information. The steps I followed are:

  1. Get out process ID
  2. Get the process ID of our parent – EA
  3. Get information about the modules that EA had loaded

1. Get our process ID

To start with we need to know who we are, by which I mean what process are we.  Using some code I found stackoverflow (see below) I was able to get the process ID of the script control.  Basically, the method used creates a child process, we then inspect its parent id which is us, the script control.

Function MyProcessID ()
 MyProcessID = 0 ' Initially assume failure
 Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
 If objWMIService Is Nothing Then Exit Function ' for Guest and super-limited accounts
 Set objWshShell = CreateObject("WScript.Shell")
 Set objChildProcess = objWshShell.Exec ( """%ComSpec%"" /C pause" ) ' Fork a child process that just waits until its killed
 Set colPIDs= objWMIService.ExecQuery ( "Select * From Win32_Process Where ProcessId=" & objChildProcess.ProcessID,, 0 )
 For Each objPID In colPIDs 
 MyProcessID = objPID.ParentProcessId ' Return child's parent Process ID, i.e. my PID
 Call objChildProcess.Terminate() ' Terminate our temp child
 End Function MyProcessID

2. Get the process ID of EA

With the process ID of the script control we can easily get the process ID of the parent i.e.EA using the following code:

 Function getparentid(pid)
 Dim parentid 
 parentid = 0
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
 Set colItems = objWMIService.ExecQuery("Select * from Win32_Process Where ProcessID = " & pid)
 For Each objItem in colItems
 if objItem.ProcessID = pid then
 parentid = objItem.ParentProcessID
 end if
 getparentid = parentid
 end function

3. Find EA loaded module information

Using the process ID of EA we can get information about the EA process and specifically look for modules it has loaded; this should include our target AddIn DLL.

This is where life started to get a little more difficult, in that I was unable to work out how to do this using VBScript, so I had to resort to some real coding to access the required system information.  For simplicity of testing, I added the code to my DLLTester using functions that would return details for loaded modules as needed.

Below is a snippet from one test function.  Using the the process id (pid) of EA as the input it iterates through the modules, finding our target (“DLLTester”) and the outputs the required information.

 Process p = Process.GetProcessById(pid);
 MessageBox.Show("Process " + p.Id + " Module count = " + p.Modules.Count);
 foreach(ProcessModule module in p.Modules) {
 answer += "\r\n.." + module.FileName;
 al.Add("\r\n.." + module.FileName);
 if (module.FileName.Contains("DLLTester"))
   myDLL = module;
   String moduleInformation = "Module information for " + module.ToString();
   moduleInformation += "\r\n Module name: " + module.ModuleName;
   moduleInformation += "\r\n Base address: " + module.BaseAddress.ToString();
   moduleInformation += "\r\n Entry point address: " + module.EntryPointAddress.ToString();
 moduleInformation += "\r\n Memory size: " + module.ModuleMemorySize;
 moduleInformation += "\r\n File name: " + module.FileName;

This worked fine.  If we ignore the cross process nature of our initial use case, and the real risk it could cause a crash or 2,  would it be possible to obtain more information, for example a reference to our module which we could use.  Well I explored a range of classes, for example:

But after an hour or so I had more information but nothing that provided me with a usable object. So I have to acknowledge that my lack of detailed knowledge of the windows internals probably means I won’t solve this and so for the time being I will gracefully going to step back from this challenge. However, if anybody does have a practical solution I’d be really interested but somehow I don’t expect one to exist (there’s a challenge!).

Before I end what I did discover during this experiment were a few useful items that may be of interest to others:

  • If you want to use get the list of DLL from the modules in a process there was a change at .Net 4 which means that managed DLL’s are no longer included in the list of modules – see stackoverflow for more information.
  • Then if you are using .Net 3.5 you may see that VS does not load your modules in debug mode. This is due to an assumption that the default framework is .Net 4.  To resolve this you need to place a configuration file name EA.exe.config in the EA.exe program directory (on my system C:\Program Files (x86)\Sparx Systems\EA) whose contents are:
 <startup useLegacyV2RuntimeActivationPolicy="true">
 <supportedRuntime version="v2.0.50727"/>
 <supportedRuntime version="v4.0"/>

Useful tools include:

  • System internals – I’ve used these a lot over the years.  In this experiment I used – Process Explorer – worth checking through, as are  the other tools as there are a range of utilities that may be useful at some time.
  • OleView – an OLE/COM Object Viewer, which is provided in the Microsoft Windows Kits and could well have already installed on your system if you are running VS – also check through this directory for other useful tools (e.g. Orca for checking any msi’s you create)

Well I know this is not really about EA but more about windows programming, but then I’ve found that more than half the issues with producing an EA AddIn is about windows!

Until the next time.

Have fun EXploringEA.