Category Archives: Manager

Information for those working on a project which is using EA (or may use EA) and needs to understand what it can offer and its benefits

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 – 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)

I look forward to hearing from you.

Many thanks



More exploring scripts – looking at application interoperability

In my last post on scripting  I was looking at using scripts as part of customising EA.    When I finished the last post I was part way through my exploration of “Application Interoperability”. So let me continue, but I must warn you that in this post I won’t be covering too much that is unique to scripting, however it is nevertheless useful stuff that provides some groundwork for subsequent experiments into scripting.

Last time I looked at how a script can gain access to an application such as Excel which can operate as a COM server.  My next set of experiments looked into if and how scripts could interact with code that I’d developed outside of EA, for example, a windows application or from one of my own class libraries (DLL).

To provide a sense of what I was thinking about let me use a diagram to illustrate theses and other options I am exploring.  In the diagram I show EA and its repository together with several other components that may be treated within the current context as being “internal” to EA’s operating environment plus several components that clearly site “outside of the box”.   I have treated everything that EA knows about including any registered AddIns as being inside,  the others, which EA doesn’t know about, are outside.

To guide us through the experiments I have numbered the connections to represent each specific test; remember we are in the world of experimenting, so I am just illustrating capability, whether or not it is of any value is another story.

Overview of scripting scenarios to explore

Overview of scripting scenarios to explore

Overview of interoperability scenarios to explore

1. Calling my Class Library (DLL) from an EA script

This is a relatively straight forward case since it is just another example where we use our script to create an application object,  but in this case the object (DLL class) is one I created.  Of course, there are some rules, for example when we create our class library we must:

  • provide suitably accessible public methods
  • our library needs to be registered as a COM object so that Windows is aware of the class when our script wants to use it.

So here is the code for my class library – very simple.

 Public Class MyEACalledClass
 Public Sub New()
    MsgBox("Hello from my DLL")
 End Sub
 End Class

This class is compiled as a library and then registered for COM interop using regasm, this is the same way that we register an  EA AddIn – see my post One of our Addins is missing for more information.

And then within our EA model we can create a script that calls this class as illustrated in  the screen shot.  When the script runs we get the message box that we have in the class constructor.

Calling my own class library

Calling my own class library

So we have address case 1 – now into case 2.

(2) my DLL can access EA repository

We can extend the functionality of the class library (DLL) as we wish.  For example, we may want our library to perform some functions that involve interacting with the current EA repository.  To do this we simply need to:

  • Write the relevant EA code in our class library (linking with Interop.EA.dll)
  • At run time, we need the script to pass the current EA repository object to our class library

Below is a trivial example.  The setEAModel receives the current EA repository object which is stored locally and then the getEAModelInfo method interacts with EA and returns a value to the calling process, in our case as shown below a simple script.

Private myRepository As EA.Repository = Nothing
Public Sub setEAModel(pRepository As EA.Repository)
  myRepository = pRepository
End Sub
 Public Function getEAModelInfo() As String
 If myRepository IsNot Nothing Then
 Dim myInfoString As String = myRepository.ConnectionString
 Return myInfoString
 End If
 Return "No report"
 End Function

Here is an example script calling our class library and getting information back relating to the current repository.

Calling EA from our DLL

Calling EA from our DLL

Clearly we wouldn’t create a library to perform such a trivial task which can be done locally. However, there may be situations where you want other functions such as interacting with another application / service that cannot be done within a script, but doesn’t warrant the need to create an EA addin, and hence this could be an option.

 (3) / (4) Windows application using our class library and interacting with EA repository

The next 2 examples look at using a windows application as a EA client, firstly just accessing the EA repository and then accessing and running a script.

The first test case (3) of access our own DLL is purely windows and an everyday task for windows application developers, so no more on that.

As with any other windows application you need to ensure that you include the relevant library(s) that supports interoperating with EA ( Interop.EA.dll) which exists in the EA installation directory.  Then to connect to EA:

  1. Create a new EA.Repository object (e.g. myEARepository)
  2. Open your file( or EA server) using myRepository.OpenFile(filenamestring)
  3. Perform required functions as required.

If you are new to working with the EA API I would suggest getting a copy of Scripting Enterprise Architect by Thomas Kilian – it goes through most stuff that you may want to do when working with EA.  And if that isn’t sufficient then check out Sparx Systems Automation Forum

So why would we produce a windows application as an EA client? The simple reason is that you want to provide a client that performs specific functions that do not require the use of the EA UI, for example:

  • to reduce complexity for the user – I have developed clients that make it easy to work with an EA model, as illustrated below a very simple interface with an application that can be provided to new users or more specifically in my case to those resistant to starting to use EA
Example of an EA client

Example of an EA client

  • to provide interaction with a 3rd party application
  • to run automatically to perform some house keeping tasks on the repository – this allows the application to be scheduled with windows Task Scheduler.

BTW: In relation to working with EA I have found it really useful at time to produce a small windows application accessing EA as an external application.  I have developed a small template application which provides the basic infrastructure for interacting with EA, selecting and opening a repository and providing basic element functions that I continually reuse when testing stuff.

(5) Accessing and running EA script’s from the outside

For the final experiment today, I was looking at a means for an external windows application to make a call to EA, and for EA to run a requested script for us. For example, there can be scenarios when you want to run a script on an automatic basis.

As far as I can see EA doesn’t provide a means to open EA from a command line, run a script and close.  The nearest I can see is the Project Shortcut – which nearly fulfils the requirements except that it doesn’t appear to provide a means to run a suitable script of my choice.  Is there a mechanism?

Well in the meantime it looks like I will have to create an application that will open my repository and execute the scripts.  So how can this be done – well as I started I see it’s not a short answer so I’m going to dedicate my next post to that task, as well as look at possible interactions between EA Addins and EA scripts. I’m already writing it so won’t be long.

In the meantime I hope this was of interest.

Any queries about this or other scripting issues let me know as I could add them to my expanding list of scripting experiments.

All the best


Using eaForms to hide tagged values (and improve the quality of your model)

Tagged values are used extensively since they allow us to customise the information we store for our elements. So unlike pre-defined fields we can add them as we require to match the needs of our project. Also within EA we can specify the type and, for some types valid values.  So that’s all great.

Within EA, tagged values can be accessed in several ways. For example, they are available as a tab of the element properties editor or can be accessed via a separate tagged values window. However,  this does mean that the user needs to remember to switch to the relevant place to enter values.  And although there is often the option to set a default value, there is no check that a value has been entered by the user, and hence it may be that the value is a true reflection of the authors input.

We believe this leaves some room for errors and/or incomplete information when editing elements.  So in eaForms we have provided some features which we believe can help users when creating and editing elements.

  • For a start eaForms presents tagged value in the same way as other element fields, with all the same window controls – whether it be a text field, checkbox, rich text box, drop down list, etc – and hence can better reflect the type of input required and simplify data entry
  • The eaForms designer can set pre-defined values to help ensure consistency of values across the model
  • The eaForms designer can also mandate the need for a valid value and hence ensure that data is entered, which in turn can help drive completeness

Although simple these features not only hide some of the fiddly stuff associated with using tagged values, but also help improve the quality of the model.

To illustrate we have some sample screen shots below that show the use of different controls for tagged values.  (Note: these features can be applied across all elements, stereotypes and MDG’s)

Example eaForm showing the use of common windows controls for data entry

Example eaForm showing the use of common windows controls for data entry

On the left we have used several check boxes to capture choices. On the right is a rich text box used to allow them to provide more detailed information.  And on the top right we have a drop down where the user must select a value, no default value has been set and in the definition of the form we have flagged the field as mandatory.   If the user fails to enter a value they are reminded that it is required before they can save their edit.

Example of eaForm warning when required (mandatory) field value not set

Example of eaForm warning when required (mandatory) field value not set

And we must remember that our aim, as always, is to simplify the work of the user who has the knowledge that we need in our model.  So in removing the need to switch to a different place to enter information, by consolidating it all onto a single form in a consistent manner, we can help the user focus on the task in hand.

So just to recap – eaForms:

  • Treats tagged values in the same way as other element fields – easier for user to understand
  • Offers a range of different windows controls for editing including those that force a selection from pre-defined values
  • Allows fields to be flagged as mandatory to ensure completeness of content

Just one small aid to helping getting the job done – I hope you agree.

Click for more information on eaForms

Customising EA – a 2nd look at scripting

Following on from my last post in which I provided an overview of the ways that you can customise EA, I have spent some time exploring more of the capabilities of EA scripting. Although I’ve used VBA extensively I’ve rarely used scripting either within EA or in a windows environment so I was keen to see how much you could really do.

I start by assuming that most of the stuff I do when accessing an EA project model with an EA AddIn can be done with scripting, however I needed to check this out as well as look at some other areas which are needed to support potential EA related applications.  Hence, look at scripting and how to interact with the user, system and other applications.

The mindmap below illustrates my target list and I warn you I don’t get to the end in this post. But let’s start and look at what I found during my exploring so far:

Explore the capabilities of scripting for each of these areas?

Explore the capabilities of scripting for each of these areas?

Well, let’s start and look at what I’ve found so far  – basically items 1 .. 7  – where my aim for each is as follows:

  • User Interface – what can I do in providing the user with information and getting results back
  • Library access – what existing code exists that I can use and what capabilities does it offer

External access – can EA scripts interact with stuff outside of EA for example:

  • File access – can I read / write files?
  • Network access – what communication capabilities exist?
  • System access – what services exist?
  • Application interoperability- can I interact with other applications e.g. Office

I’ll now outline what I found and in a future posts look at the missing items as well as resolve some of my outstanding issues.

In each of the areas I’ve been testing using VBScript, and assume but not tested, that the functionality I outline is available with the other scripting engines; that may be a very bold statement!  Also you need to remember in writing the code it’s important to note that VBScript is not VB,  as I found out and I often needed to check the syntax.

1. EA model access

This is the area I expected all to work but wanted to check access to packages, elements, diagrams etc and that information can be exchanged between the script and EA projec. To do these tests I used the code samples provided in the EA manual and, with making relevant syntax changes, all seemed to work fine.  No surprises and none expected so that was a good start.

Key to the operation is access to the currently open repository through a predefined object “Repository”.  Methods are selectable using Intelli-sense with access to the help file for access to the EA Object Model reference material. All fine so far.

2. User Interface

For me the user interface is a key component,  so I was keen to understand what capabilities are available.  I half expected it to be a basic command line text interface but as you will see there is potential for much more.

To start with it is worth a moment looking at how a user will access scripts.  There are 2 basic mechanisms that I would expect to be used.

The scripting window access from Tools | Scripting which presents a list of the available scripts.  And either using the run button in the tool bar or context menu the user can run the script.

Running a script from the content menu

Running a script from the scripting list window

or from the context menu – in which case those scripts created for the relevant script group will be available i.e. if you create a script with a Diagram group then that script will only be available when working within a diagram.

Running a diagram script within the context of a diagram

Running a diagram script within the context of a diagram

So having got the script started in most cases there is a need to interact with the user whether asking questions, capturing data or presenting results.

To support this requirement EA provides a Session object which supports input, output and prompt methods which provide a basic capability e.g.

Session.Output “Some information for the user”

The prompt method can capture a result from user input.

Also provided with EA is a library of helper functions (EAScriptLib).  This is supplied as an MDG so if not present in your list of scripts then check your Settings | MDG Technologies to ensure that it has been enabled.

Enable the EAScriptLib

Enable the EAScriptLib

You then have a set of scripts functions available in several scripts in the EAScriptLib group.  You will need to look at the script source to see the available functions and usage information.

EA Script Library

EA Script Library

If you want to use any of the functions within these library files you will need to include the relevant library in your script e.g. !INC EAScriptLib.VBScript-Dialog before you can use it.

For example, a simple input box could be accessed as illustrated below.

EAScriptLib Input box

EAScriptLib Input box

When looking into other options I soon discovered there were more options.

For example, VBScript provides some standard functions such as

MsgBox(prompt[, buttons][, title][, helpfile, context])

I also found other functionality via the windows shell application object.  For example, using the BrowserForFolder to select a filename, and get its path.

Function BrowseForFile()
Dim shell : Set shell = CreateObject("Shell.Application")
Dim file : Set file = shell.BrowseForFolder(0, "Choose a file:", &H4000)
if (not file is nothing) then
BrowseForFile = file.self.Path
BrowseForFile = "No file selected"
end if
End Function

It soon became clear that it was possible to create quite sophisticated dialogs, although I found nothing as powerful as a custom form; perhaps I have missed something.

3. Libraries

As with most programming languages there are libraries of functions available for scripting, as you will have read I have already discovered a few. But when I started with VBScript I was unaware of the range of functions that were available and just a quick search on the Internet found many more.  For example, there are scripts covering most things that I needed including:

  • Hardware information
  • Messaging
  • Networking
  • Operating systems information
  • Security

Already we have seen that EA has its own Sparx provided EAScriptLib which provides some helper functions – see above for details.  Then there is the standard VBScript library ( see VBScript language reference at MSDN)  plus access there is access to a range of other application objects such as:

And with that I think I can do most of the tasks I need so onto a few tests.  A quick search provides examples for most of these.

4. File access

With the ability to interact with users and libraries available, accessing files should be straightforward.  And this was indeed the case. The function below worked fine –

Sub MakeHelloWorldFile (FileName)
'Create a new file in C: drive or overwrite existing file
Set FSO = CreateObject("Scripting.FileSystemObject")
If FSO.FileExists(FileName) Then
Answer = MsgBox("File " & FileName & " exists ... OK to overwrite?", vbOKCancel)
'If button selected is not OK, then quit now
If Answer <> vbOK Then Exit Sub
'Confirm OK to create
Answer = MsgBox("File " & FileName & " ... OK to create?", vbOKCancel)
If Answer <> vbOK Then Exit Sub
End If
'Create new file (or replace an existing file)
Set FileObject = FSO.CreateTextFile (FileName)
' and put some content into the file
FileObject.WriteLine "Time ... " & Now()
FileObject.WriteLine "Hello, World"
MsgBox "File " & FileName & " ... updated."
End Sub

With that I was happy that basic file functionality is available using the File System Object so left it there.

5. Network access

Next on the list was communication.  Perhaps a simple test to retrieve information from a web server, so try accessing a web page. Once again network access was straightforward using the HTTP request. For example, the few lines below were able to read a web page and output as text string.

Set o = CreateObject("MSXML2.XMLHTTP") "GET", "", False
' o.responseText now holds the response as a string.

Looking at script examples I found there is clearly I much more functionality readily available whether it be parsing the content, sending emails,..

6. System access

Next I looked at system access, and this was probably the biggest surprise to me. How much could I do from scripts in terms of accessing and manipulating system information? Well it turns out that you can do a lot, although I suspect that windows security will prevent normal users doing anything catastrophic (I hope so!).

My findings were that EA can happily run the scripts that access all types of system tasks using WScript or get information using the winmgmts objects.

For example, using the File system object you can create a batch file and then using the shell object run the batch file. e.g.

Set objShell = CreateObject("Wscript.Shell")"%comspec% /c C:\Users\adrian\Documents\mybatchfile.cmd")

This was clearly an area with plenty of functionality that would go far beyond the normal day to day needs of the EA user.  For those interested there is plenty to explore – I stopped myself as I suspect I could have spend hours or even days as I have only scratched the surface.

7. Application interoperability

So to the area of greatest interest to me – applications working together.

Having used VBA more than a decade ago to transfer information from Excel to EA my first task was to discover what could be done the other way round, then look further at the general capabilities for interacting with external applications.

With the knowledge that it was possible to create an application object with VBScript, and my experience of writing several EA AddIns for MS Office products applications, I was confident that I should be able to connect.  And this was the case .

For an external application that is available as a COM server you can create a reference to the server, and use that to interact with the relevant files. In the case of Excel this is done as follows:

Set objExcel = CreateObject(“Excel.Application”)

And the following lines illustrate how to create a workbook, adding some dummy data into the worksheet and setting some cell formatting.

dim strFileName
dim objExcel
dim objWorkbook
dim objRange
strFileName = "C:\Users\adrian\Documents\c1.xls"
Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True
Set objWorkbook = objExcel.Workbooks.Add()
' now makes visible and then puts some data into the sheet
objExcel.Visible = True
objExcel.Cells(1, 1).Value = "Name"
objExcel.Cells(1, 1).Font.Bold = TRUE
objExcel.Cells(1, 1).Interior.ColorIndex = 30
objExcel.Cells(1, 1).Font.ColorIndex = 2
objExcel.Cells(2, 1).Value = "Test value 1"
objExcel.Cells(3, 1).Value = "Test value 2"
objExcel.Cells(4, 1).Value = "Test value 3"
objExcel.Cells(5, 1).Value = "Test value 4"
Set objRange = objExcel.Range("A1","A5")
objRange.Font.Size = 14
Set objRange = objExcel.Range("A2","A5")
objRange.Interior.ColorIndex = 36
Set objRange = objExcel.ActiveCell.EntireColumn

For other MS Office applications (Word, Project, Powerpoint, Outlook) the approach should be very similar, although I have not tested all.  But what other applications?  Using Create object I assume that a script could connect to any application that provide a COM interface.  So I started Visual Studio and looked at the COM references are available.  There are 100’s on my system, however I suspect that not all are available and/or useful.  I did test with a few application objects and soon realised that I have a lot more exploring to do in this area.  Although, I suspect, purely for general interest as I’m not sure many of these applications will be useful with EA. I’ll find out.


Although there are still some areas, as listed on my mindmap, left to explore and I will get onto these in due course. However, as usual I’ve discovered some interesting stuff along the way which I want to explore further, and find some answers before moving onto the next  topic.  So I’ll leave it here for today, with some questions in my mind regarding application interoperability, and the promise that I’ll check out some more of the EA Scripting capabilities.

If you have experiences of scripting or questions feel free to add a comment.

Have fun EXploringEA



EA for project management?

I was prompted to write this post as I saw on the Sparx forum a suggestion for enhanced Gantt chart features and in that suggestion it asks for attributes such as costs and hours of various kinds – i.e. real project management attributes.

Interestingly sometime ago, following discussions with a friend who is a project manager, I wrote a small Add-In for EA to integrate with MS Project.  Needless to say, what I saw as the requirement wasn’t exactly what they had in mind.  Skipping a lot of the ensuing discussion it became clear that a real project manager was unlikely to be interested in using EA, instead they wanted to inspect and extract information from EA into their world. Outcome – I wrote an Add-In for MS Project that interacted with EA. So with both Add-Ins each type of user could work within the familiar context of their normal tool and get the information they sought from the other world.

In the last few weeks I’ve written another EA Add-In for a project management system – this time Team Pulse from Telerik.  Once again to capture useful information into a tool that meets the users needs.

In a previous post I looked at improving productivity with EA and at the time it was clear to me that no single tool could do all the tasks I wanted and the need for the Add-Ins I’ve mentioned above just adds further supports for this argument.

Since my improving productivity post I spend some time exploring EA’s workflow. Yet again a potential area to organise and manage stuff.  Before I started my understanding and experience of workflow systems were of tools that help in the management and movement of tasks through notifications, prioritisation, checking and automatic escalation as needed. But what I discovered in EA is very much a user-centric model where a person can run a script to check the status of tasks and act on them as they wish.  Not what I expected, but on looking further into workflow models this is an accepted model.  I see it can be really useful in assigning tasks, and getting status information and ideal for small teams managing their day to day work.  Take a look at the Sparx workflow scripting example which illustrates this model – but I see it  very much as a low-level detail level tool, requiring the users to set up appropriate scripts – so no out-of-the box solution – and run them.  Perhaps EA could have some scheduling – ideal for a little Add-In a script scheduling tool – anybody else want it?

So back to project management.  In the early 1980’s I was exposed to some project management training with all the formulas and metrics for estimating the work involved with developing software systems – which I promptly forgot at the time it really didn’t help us get the work done.   However, I’ve always intrigued by project management, not least as it fits in with my approach of keeping things in order and well structured .

My experiences of project managers has been varied, and whilst trying to keep clear of project managers for much of my working life, I was heavily encouraged to go through project management training by one of my managers.  The aim was to give me some insight into the challenges they face and I can say it was a bit strange spending a week as the only developer in a room of aspiring project managers!


I remain intrigued about the whole process but my view is that most plans are really guesses and, if they were accepted with that mindset it would be fine, however a problem is that management often view plans as cast in concrete statement.  If you put down the real estimate the project possibly wouldn’t even get off the ground.  But of course these figures wouldn’t be politically acceptable so the plan is re-worked and thereafter developers etc are set up to fail before they even start….

As a potentially interesting aside, I recently attended an interesting talk on Critical Chain Project Management which promises a completely different approach to management and especially the way that estimates are created, used and managed – perhaps there are some nuggets from that methodology that could be the link between analysts, designers, developers and the project managers.

So the idea of bringing stuff into EA and making it a project management tool is interesting. Would having estimates, costs, budgets etc within EA be useful?  Who would use them?  Dare I say, would the figures even be viewed and accepted.

At present,  the method I’ve used for managing tasks within EA is to use the Task element (you really need a first class element if you want to interact outside of EA ) together with suitable tagged values that hold the information.  Pretty easy stuff, and you could always add a profile/MDG to ensure that they are added correctly and with defined values to minimise user error.  Within these task elements linked to use case, issues, changes, requirements, or in fact any element you chose, possibly with a stereotyped connector, it is possible for a those interested in the “project management” attributes to get visibility. Perhaps even having a few scripts to present the reports they need.

The one big issue I have with EA is that it uses several different task items (element tasks, task elements and project tasks) and they are not related – so the tasks that are used to produce the Gantt chart is not the task that an analyst may use – why??? A real inconsistency. Perhaps the suggestion on the forum should include rationalising EA tasks to a single task element, so that all the features within EA that use them work together.  Then the use of task element tagged values, which are readily accessible could be used by both the EA user directly and the PM using MS Project or other linked project management tools.

Whatever happens in the future, I’m looking forward to seeing how my Team Pulse Add-In works with EA.  Further, as an agile tool, and the need to closer cooperation between the various parties, I imagine that the barriers between the two tools should be lower.  Although I also suspect that moving from two to one tool is still not an option.


eaForms – an element properties editor which can extend and enhance the EA experience

For the last few months I’ve been developing an EA Add-In which has taken longer than originally planned, hence my lack of time for other experiments.  As the project unfolded, we discovered more, expanded the idea, added more features (scope creep!), and then a few redesigns of the UI to provide users options. And even now we still have more ideas to explore.

All in all its taken a few months longer than planned.  I suppose I should believe my rule of thumb which is, when asked by a project manager how long will something take to do – take your first estimate and multiply the time by PI (3.14159265359….   – perhaps not to that level of precision!), and its the number you don’t want to believe, as it could well put you off starting the project at all.

So 2 months becomes 6 and I am now nearing the end of completing the initial phase of this new Add-In – eaForms.  I  had expected to be where I am now before my summer break in July, but instead spent much of my break coding albeit in the sun and must admit it was fun – especially learning more about what you can / can’t do with EA all the time.   I have lots of material from my discoveries for some posts on writing Add-Ins – hopefully I’ve get some time to write up soon.

So what is eaForms – simply it’s an Add-in that allows users to design and run alternative element properties editors.

The idea came from my work in trying to capture knowledge from people who had no knowledge (or interest) in modelling and when pushed to found EA too techie to use.  This led to confusion, frustration and often a bit of a mess for your’s truly to sort out. So why can’t they have something that is a bit more accessible.  They may still have to use EA and so accept that they will be using a modelling tool.  Also there is no getting away from them needing some training to cover the basics plus monitoring afterwards, but at least I could make life a little easier by removing some of the complexity for data entry/editing.  In addition, in doing this I could also help drive consistency by, for example, providing them with a defined set of values instead of a free form text box etc…  less mess for me:-)

eaForms operates in 2 modes:

In Designer mode – the EA user can configure a form, using the eaForms toolbox,  to produce a form that will be displayed for a specific Element type/stereotype combination (support is included for both core element as well as MDGs that are enabled at design time). The content, layout and appearance of this is up to the designer.  The form designer is free to produce forms of different shapes, sizes, colours and perhaps more importantly content using “controls” that go beyond that provided by the standard EA dialogs.  For example:-

  • Combobox (with options for user defined values, to restrict users selections)
  • Checkbox – to provide that quick “yes/no”, “true/false”, as well as other booleans
  • Related elements – with the ability to link to one or more other elements without dropping the current editing context
  • Listviews that display collections with some options to edit items in the list, once again without dropping the current editing context.

Plus built into the design is the ability to add further “gadgets” that as the need is identified.

As an example – here is the basic design of an eaForms in EA – drawn using EA’s drawing tools on an eaForms diagram


In User mode – the EA user, assuming eaForms is enabled, need do nothing.  When they edit an element for which there is a matching form available eaForms will present this instead of EA presenting its standard dialog – below is a screenshot for the form design above:


All in all no real magic but pretty useful.

Of course, for the experienced EA user the benefits are different.  They can produce forms that help them by bringing information together in a single place in the way that they want (I do this for classes, where I have a single form with the class information, its attributes and operations). And bearing in mind it only takes a few minutes to produce a form it can be time well spent, of course, for the artistic it’s easy to spend more time enhancing the look of the form!

Although we think this is a great tool it is important to remember eaForms is just another tool in the EA toolbox. It is an Add-In that can extend and enhance the users’ experience. Using EA still requires guidance from those responsible for the models. Our aim with eaForms is to help in making EA more accessible, reducing some barriers and helping ensure data consistency. Not for everybody but useful to the many.

We have more ideas on where we could go with eaForms and could just continue developing but probably better to let you play (and hopefully provide feedback).

We plan to start trialing eaForms soon – so watch this space.  In the meantime we have started with some short videos that demonstrate the product and its use which you can find on YouTube Channel.

Be back soon.


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!