First, Something Personal…
As some of you know, my main reason for building the EA sandbox to begin with, was primarily because I wanted to share my passion, which is EA. Reading through the posts in the past, they were written for very specific people in very specific situations, and sometimes I almost feel like going back and formalizing some of them – to bring them more fully in line with standards like ArchiMate. There’s always someone telling me that some view could be done better – and I do refine things over time but one of the things I often teach – is to make sure that views are telling a story, and get the story out there first, you can worry about the details later. Sometimes some of my posts may come across a little like i am preaching because sometimes my posts are also a vent for frustrations I am having to deal with. I apologize for that.
Some of you may know, in my long and distant past, I was a programmer, and that’s a passion that never goes away. When working with EA it often takes a long time to see the benefits of the things we do, but with programming its right there, with instant reward. I’ve avoided sharing scripts and being part of different communities because a lot of the scripts I have written could be done better – I know this, but I am not a programmer these days, and I just do not have time to build perfect code. So, this blog is a first – i am going to present some code and if there is sufficient interest in this kind of post, let me know, and I may just do it again. I am a bit nervous that i may get flack for this.
This is one of my first scripts I have written in jArchi – I’ve had it installed at home about two weeks now.
Why did I do this?
I needed a roadmap view – I work in a very complex environment with many projects and dependencies, and showing a roadmap is really important for my stakeholders. I dont like having to do this kind of thing by hand. End to end, this was under 8 hrs of fun coding, and i would trade 8 hours of fun coding, for 1 hr per month of boring work in PowerPoint, or any other tool. Within a year, this script pays for the effort in time saved.
What does it do?
When I execute this script, it creates a view named “YYYY-MM-DD: My Roadmap”. The contents of that view looks like this:
Its iterating through all my work packages in my model, sorting them by start date and if they are in this year puts them on this map. It works by looking for these properties:
What doesn’t it do
Right now, the script is restricted to showing a single year. Thats mostly because of the way I wrote the header code, with a little effort it could be rewritten to be multi year.
When there are a lot of work package elements this view may be a bit long, as its one work package per line. Later on if i find that I may well come and optimize the code a bit so i can have several on a single line.
How does it work?
Its reasonably commented, and without going through it line by line, there are some things its good to know. startOfYear & endOfYear effectively are establishing our scale. The getTime() method on a date saves us a lot of headaches that we would have in doing our math, because the calendar isn’t metric and months have different numbers of days. The function turns our date into a single number that can be used for scaling.
The positioning of each work package needs to be aligning to the topbar – we know how many pixels each month is – its set in the variable monthWidth. You can change this safely without breaking the script.
Graphically scaling I have an offset from the left (leftPadding) which is 10 pixels. So in graphical coordinates because I know I am doing 12 months, and my width for each month is 120, i know that my on screen coordinates need to start at 10 and end at 1450. I need to fit the dates of my work packages into that scale.
One pixel has to align with our units of time. to figure that out i created the variable oneTick:
(endOfYear – startOfYear) / (monthWidth*12)
To put this another way: The number of time units / the number of graphics units, gives us our scale. The final parts of that puzzle –
var calcX= leftPadding + ((elementStart-startOfYear) / oneTick);
var calcW= ((elementEnd-elementStart) /oneTick);
calcX is the calculated X position of the work package. calcW is the calculated width, which are needed when we create the objects, when we are doing the archimateView.add on the next line.
Summing it up
There’s some pretty good documentation for jArchi out there, and some really good code examples. I was really surprised how quickly this came together, which is good, because coding isn’t my job – I do this to save myself time!
I would be really happy to hear from anyone who wants to improve this script – when I get time, if the script proves useful I probably will. If anyone is interested in more blogs of this type let me know too. Thanks for your time!
Edit: I made a couple of improvements to this script after I published it, because I thought I had messed up. While I tried it with different data I noticed it wasn’t sorting properly. After investigation I discovered there was a work package with a badly formed date that was breaking my sort. I added code to check that I could convert dates before adding the work package to my list. I had never seen a date function return “NaN” (not a number) before..