This test diagram shows some of the automated lines used in BSA. As you draw diagrams you also need to use line (or links) between the symbols to create a diagram. But it is important to remember that we are NOT making drawings, we are creating a specification where the lines are translated to source code later – and the worst thing you can do is to create a tool where the user end up fiddling with lines to get the diagrams to look pretty. If you do that you slow down the programming speed of the developer, so lines must MUST be automated. They should look ok from start and the user should not need to do anything but fix their end-points.
I worked on CASE tools in the past that was horrible as you spent hours fixing diagrams to look nice. The next version was better with regards to lines as they automated more. I have accidentally been working on some of the worst nightmares of CASE tools. Their concepts and ideaes was good, but they created dinosouruses. That is what we used to call the old CASE tools – dinosouruses. They did a few things good and the rest was non-functional and at the end they did not deliver on productivity. CASE tools as an idea have been around since early 80ts, but to day no-one have managed to break the barrier of making a CASE tool go into the main stream of development due to (1) price, (2) lack of automation or lack of feature support, and (3) lack of integration with 3rd generation programming languages. It will always be (1) a need for assembly, (2) a need for C/C++ or similar – old fashined, low level languages that are hard to replace if they are needed. A modern tool should build on that and extend, not replace lower layer tools. This is a core concept in BSA.
I keep repeating this because BSA is not easy to create and it is very easy to go wrong on features that end up slowing down the user rather than increasing productivity. And for a tool of this category to be successfully it must be available (as in low cost) and have a none-questioned productivity gain on development alone with no show stoppers. Many users give a sod about documentation, software-architecture, increased quality, 100% automated testing and such. These are often low priority compared with the capability to deliver and maintain a working product. And even thos companies that require increased quality often can’t afford the tools that could help them out. A price tag of 10k – 100k per developer is usually a blocker for availability.
Back to lines – BSA will automate the lines – the user should never need to manipulate line drawing. But, that’s the theory and then we need to deal with the dinosourus effect – the exceptions – it would be stupid not to give the user the option to manipulate lines manually as well. The way this is planned is that the user can select between several line automation techniques or simply take over and draw a manual polyline if automation do not deliver the required line.
Getting lines correct to make it easy to sit back with nice looking diagrams is an important win. The next step is to move diagrams into documents like Software Architecture and automate as much of the doc task as possible. While many probably will use BSA itself as doc, it is still those amoung us that like to see a nice web page or an old, fashoned document in Word, PDF or openOffice/liebreOffice etc.
BSA is capable of letting the user draw hes own diagrams with hes own symbols. That is what you see above. The diagram engine still have some work in progress, but it is coming on. I used the last days to port an old Line Calculator over with great success, but I need to focus on my first release which is HMI design.
Thanks for reading and stay tuned…