BasicPI

To be able to precent classes I also need a working dictionary so I can make a reference to the original class. A first draft of the visual dictionary can be seen below. It is working well, with the exception that the “Data Model” folder get very large. The Functions folder will suffer the same, so I might need to add a grouping folder back – Diagram is exactly that. This is however minor as it is only visualization. In fact I am very happy with the Dictionary concept. What remains now is some additional code allowing us to specify that one class is only a precentation of a master object. Most aspects of the drawing engine is working very well, so I am not that far away from finally releasing a first version that only include the drawing/modelling engine.

The concept of precentation is that the model contain exactly one physical master object and that each diagram can make precentations of that master.

The small diagram below show a typical precentation issue. I have included the full BSASymbol to the left and added a “precented” BSASymbol to the right. In the precented version I drag in GID from a base object and only show “IsLink” because that is all that I want to see in the precented diagram. If I was to include the full BSASymbol everywhere the diagrams would be messy of very little help. The is why we have exactly one copy of BSASymbol in the dictionary that is “precented” on diagrams. In this case you might actually have objects that are not on any diagrams. This detail is missing from all UML tools and are actually very important in modelling. This will apply to class and data tables.

I need to rework BSA to support this by implementing a visual Dictionary and force every class to be a visualization of that entry. In reality I only force a master-link and add flags on visualized methods/events/attributes – it should be straight forward.

Loading performance was due to a bug in the XMl reading. Now it is lightning fast. Turned out I updated screen while loading.

I still am using a bit time as I load a Tree document at end, but as indicated before I can fix this.

The last performance issue is that I have an unexpected 2-3 sec delay as I create special symbols – this smells like a bug as well.

This is good because I was getting worried that WPF was not up for the task as number of diagrams and symbols grew, but it actually looks good.

It is several types of XML parsers on the marked, but as an embedded developer I often struggle with little RAM so I was forced to implement a SAX style parser.

Most parsers you find is DOM parsers that will load the entire XML document into memory and allow you to read/write as if it was a database. This is excellent if you have the space (RAM) for it.

A SAX parser will parse the syntax as bytes arrive and make callbacks to the host to parse content on the fly. I have been running SAX parsers on Arduino with as little as 500 bytes RAM.

Returning to the SAX parser in BSA I assume the parser itself is very fast, but that parsing of content is to slow. I need to find out because it is possible that I have implemented some time-consuming functions as I rebuild the saved model. I know for a fact that a SAX parser is very fast and faster than a DOM parser so I am a bit puzled – but I will find out.

It is a bit more fun to show SW as the UI on BSA starts to get operational. The diagram below is a high level draft of BSA itself and it has been saved and loaded. The tree to the left is the document showing the structure as a tree. This project consist of 3 diagrams and a total of 1888 XML lines, but it takes 9 seconds to load – this will be unacceptable as projects will grow very large. 50% of the problem is loading the tree to the left, the other 50% is the XML parser I use.

Moving forward I will avoid loading the tree and only load headlines that can be expanded by users – this is an old trick and I am aware that IO between CPU and GPU is a bottleneck. The XML load performance can be solved by using a non SAX parser – I think a more classic DOM parser will be faster in this case. But, I also have a GIT integration issue so I plan to make the file content more readable and split the project into multiple files. In that case we just load the head project and load more as the user open diagrams. Luckily this change is straight forward “as is”.

I seldom bother with performance before I have functionality in place, but this error will become functional. It is not much content in these diagrams and I can see performance dropping with size, so the tool will be useless unless I improve this.

One important issue is that I need to examine why my XML parser is slow before I make any change otherwise I might be stuck with the same problem in a new parser!

The storage format of BSA is a modified XML, modified for easy reading. But, it has so far been one file which will not scale if multiple persons edit a project as you end up merging a lot on XML in GIT. I am considering moving to a non-XML format, but the major issue here is performance on the XML parser that dissapoints me. Moving to dave each diagram as a seperate file does however have some advantages as this will go better with multiple people editing and using GIT.

This is an issue I need to investigate, but there will be a working GIT integration!

“Presentation” or “Logical/Conceptual View” is seldom added to modelling tools. The example below show a raw table with a lot of attributes, but as we use that we might want to present fake attribute or just a simplification of the raw table adapted to the current diagram. This is still the same physical table, just “presented” for the purpose added readability in a diagram. This will be supported in BSA – we need it otherwise the class sizs will be huge and diagrams useless.

BSA is coming together, but it’s a lot of work. PLD in full effect will take some time, but the UML support is close to finish. This is the bit I miss the most myself so I will release an early version that support the UML design part. What you see below is a simple class diagram. PLD and the compiler (Code Generator) will take some time yet, but that don’t stop us from using the design parts. I will primarely support UML Class Diagrams and UML State Diagrams (PLD). PLD have the building blocks from a UML state diagram mixed with elements of SDL (Specification and Description Language).