Monthly Archives: August 2013

Just another little frustration but who am I to point fingers

Not sure if you have ever experienced it but this week I spent a few hours wondering how the EA API really does work.

I was trying to:

  • create a diagram
  • add an element and related diagram object to it
  • add a child element to the initial element and place a related diagram object within the initial object – important to note that I wanted the object to be contained and on top of the 1st object.

Straightforward  I thought.  I’ve created masses of diagrams so didn’t think much about it.  To my surprise didn’t quite go as expected. Debugging the code and looking at data all was working fine until I did an update to the diagram object for the 2nd object, whereupon both position data was modified and the sequence (z-order) was set to match the owing element.

Well I don’t think I missed anything in the documentation so clearly there are some assumptions that are being made by EA – which are not presented – but hey we all do that with code.

Its documentation again.  In one of my latest projects I’ve been thinking about how to improve the documentation, not for others but just for myself.  Yes I have all the code – however this doesn’t always help during the development, especially as the produce evolves to cope with moving goalposts.  I try to use EA, starting with a “nice” model and syncing code as I progress.  This can work fine with small developments however as they grow and the specification and design changes, it can become a bit of a mess, and to be honest I can give up on trying to maintain the integrity of the code/mode. Perhaps I’m just lazy or too impatient keen to produce the deliverables.

But the need to understand the assumptions and constraints is vital in ensuring that I as the user of the API do the right thing and that the product (e.g. EA) fulfills its part to the “contract”.

Is this a matter for the QA authority to pick up on?

Many decades ago as a young developer I was working on a project where I was instructed that as part of the process we had to present all our code, when we thought it was completed, to the QA manager.  So following a peer review off I went for my first meeting with Dave (who turned out to be a very experienced developer). His role as the QA manager role was to review my code and documentation and ensue that not only he could understand it but anybody else who may have to work on the project could.  So it soon became clear on my 1st visit that my work was not done!

Sort of seems right  – but I know from subsequent projects in different companies its rare to have formal peer reviews let alone in-depth reviews by a QA authority (even if you could find  them!)

I’ve seen posts which highlight the need to review between different versions of code at the design level.  Yes we can do a code “diff” but translating this back to the UML is an interesting task.  Perhaps an ideal topic for a research student – or one of those project I’ll put on the list for when I retire.

Well back to my initial problem – I did find a solution by creating the elements and diagram objects within the package and only after the creation of the diagram object change their parents to become children of the desired object.  For those interested I’ve put a short note with code example here – “EXploringEA_EAHowTo_CreateDiagramObjectsForChildElements

Of course, the fact that product companies don’t provide all the documentation required for developers has led to a massive market in “How to books”.

For those working with the EA API  you can get a good introduction to its innards from the  books by Thomas Kilan (Inside EA and Scripting EA)  – they don’t have all the answers (but who does), however they cover the key stuff and provide a great background.

Well with that little diversion I’ve got to get back on track to my current project.

Adrian

 

Advertisements

Can you improve your productivity by using EA?

I start with a question which I have often asked myself when using tools since, as with time I often discover that a tool can offer so much more than may appear at face value.  This is certainly the case with EA.

When starting with EA it was its API that would provide access from other applications that was a key attraction (and protection) but it was several years before I started to take advantage of its capabilities.  It so happens in the last few years I have spent most of my working life writing AddIns so this is a facility for which I have some detailed knowledge!

So what more?  This was what I asked myself when working on my current project, developing yet another AddIn.  I was thinking that there are probably things within EA that would aid my productivity, if only the benefit of keeping information in a single place; an area that I have struggled with over the years, not least due to different working environments that have presented their own challenges.

As a lot of my developments are single user projects I typically run them using Excel – a list of tasks with descriptions, priorities and status; a simple format that works for me for many years, however could I bring this information into EA in a usable form and manage it as easily as Excel; filtering, sorting, reporting?

As an aside, one of my background development projects has been an AddIn that links EA and MS project – well 2 AddIns one for EA and one for MS Project with the aim that whether you are an EA user or MS Project user there is access to the information within the environment in which they normally operate. I’ll be writing a separate post on this in due course – with some of my observations of trying to match those 2 tools.

But one thing that did come out of this work was something I have come across when looking at the productivity issues – and this is the different ways in which “stuff” is represented.  In the case of EA models,  “task” stuff is implemented in different,  and to me incompatible,  ways; there are element tasks, task elements and project tasks. It would seem natural to me that they are similar and so would be implemented in a consistent manner, however this is not the case and leads to some challenges with consolidating the information.

Now coming back to the idea that I could bring my project / task information from Excel into EA.   looked at whether I could put my project stuff into EA (it’s not the practical moving from EA – I have AddIns that do that), it is more about where I would put the information and how it would provide the functionality I needed.  Well I tried many different things but without writing an AddIn none of them provided me with a compelling solution.  There are bits of EA that would allow me to manage tables of stuff, setting status, priorities etc but they are not part of the EA project stuff (!) and hence I’ve made the decision to pause i.e. I will continue to use Excel and as needed will use other AddIns to transfer information between the 2.

So no real change – no single tool – so perhaps my current solution is as good as it gets.  Perhaps one day I’ll write some code to better organise myself!

In the meantime, just putting out the idea out there and perhaps somebody has some useful insights.

Of course there are other areas of EA that do provide benefits and I continue to explore (and have fun) as time permits.