BasicPI

I decided to do Precentation the easy way. I simply add a “PrecentationOf” attribute that by default is blank. The Dictionary can track multiple items with the same name, so we just add a note to classes that are a precentation of something else. And then we just use the existing property to create a virtual class. BSA will expect that one version exist with a blank precentation field. As of now this is manual, but I can add more automation later.

It is UMLClass, Data Table and ModbusTable that will need this capability to visualize snips of the original table. This was a simple solution, but I think it will work well. I can also add a filter on the Dictionary to not list precented objects or simply list as sub-list of the original. This also means that I need a diagram with the original class for now – will look into creating some objects directly in the Dictionary later.

As we use the objects for Coding the compiler will see that this is a precented object and look for the original. The compiler will also check that we only have one original object of each name, but nothing will prevent the user from entering free names during design.

BSA has been something I have worked on on/off for the last 3+ years, but some of the concepts has been in my head for close to 40 years. This is not the first CASE tool I build or work with. This first release will target object and data modelling – UML class and ER Diagrams simply because I need these parts for my own work. Currently I want to complete the dictionary and the precentation issues because this is the reason I can’t use other modelling tools – they either cost to much or is less usable on some of the more important concepts in modelling,

Step 1 – Data modelling

Step 2 – Code Generator/Compiler

Step 3 – HMI

Step 4 – PLD

PLD will be the hardest part to complete as it is a lot of details that will need a bit of try and fail. On Data Modelling, HMI and Code Generation I have experience from other CASE tools, but PLD is very new and non-tested concept. Everyone knows it is possible to code with graphical tools, but many also know that this way of coding tend to be slow and limited. Rather than increase coding speed you end up decreasing it because of limitations in the tool – this is why PLD will take some time to get right. That said the combined power of data modelling and HMI is a alone a big win in BSA.

Stay tuned and thanks for the patience with my english skills 🙂

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!