Monthly Archives: April 2013

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.

Adrian

Advertisements

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!