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.