BasicPI

This shows BSA Table editors in use -I need to use them a little myself to verify if they are ok – I admit it is a bit confusing to have description in the table and then have to edit it as a property. But, the mini tekst editor is actually great. DataType is only a tekst string – you can write anything you want – same with name. I don’t think I want any automation restricting you here, but I will need a BSA Compiler that check rules – etc if names are unique and if DataType is known.

This leads me to a more complex editor – the one I need for assign statements, Parameters, Relations etc – I have decided to start with an easy concept of an editor where you write small snippets of logic with the dame concept – you write whatever you want and the compiler verifies the content. I can always consider more automated concepts later, but I think it would be an error to rule out text editors.

Tables are objects with their own methods and events, so the example below grab events from tables and process them. This is the same as adding a start label with the event name as the PLDFlow link will need to be connected to an Event and a Method and convert data between them. Event comes with parameters and so does Methods, so the PLDFlow will need to take the input event parameters and create the method parameters.

I could have done this in my previous example as well – taking the PLDFlow directly from the OK button, but this is your choice – sometimes it is convenient to use start labels. PLDFlow will allow you to select available events in the scope – if you drag from a Start symbol the selection is whatever is selected in the start symbol. If you drag from a component the selection is the exit events of that component. Notice that the line with Arrows are PLDFlow while the lines with “forks” are Data Relations. I will change colors to make it more obvious that they are different. Table is one of the few objects that can use both Data Relation and PLD Flow.

SQL Databases also support Triggers (same as events) and Stored Procedures etc. BSA will support these at some point allowing import and definition of those. But, this is not primarely a data modelling tool, so it’s a bit down on the list.

This creates a question – with table supporting events and methods as any other object – do I actually need the specialized Select, Fetch, Update and Delete?

This diagram have no input flow to Table – which is ok because Methods and Events are either Mandatory, Optional or Static. An Object with no Mandatory Methods do not need an input PLDFlow – that said it could benefit from a Timer connected to Select in this case.

Mandatory Methods/Events are those who MUST be used. The BSA Compiler will issue an error if these are missing. Optional means you can chose wherever to implement them or not, meaning they must have a default implementation. Static Events cannot be overrided by user – in this case you have decided that the event shall call a specific method. Only events can be Static.

As for Select, Fetch, Update and Delete – these also have a filter part, so yes I do need them.

BSA contains two techniques to model data. One is classic ER Diagrams and the second UML Class Diagrams. Class diagrams provide an object oriented approach that will go well with languages like C++, C# and Java, but a class is basically only a definition of a new datatype that you can declare as a variable using ER Diagrams. Tables in ER Diagrams represent actual, physical data structures with variables. This is how BSA will need to use the two techniques and the current scope focus on ER Diagrams. It might be incorrect of me to use terms like “ER Diagrams” and “UML Class Diagrams” because at the end of the day I tailor the modelling techniques to what I need them to be to support an executable specification.

Each diagram name must be unique and as you draw a table on a diagram the diagram name + table name form an unique, global name that can be accessed from anywhere.

This example show a simple Customer Table, an associated form to edit it’s content and the logic of what happens if you press the OK button. Both Tables, Forms and the components you add have multiple events you can activate with the PLD Start symbol, but I only show one event processed here for the purpose of illustrating BSA at use.

To be formal I should probably call the event “Form_Customer.Button_OK.LeftMouseUP” or something, but I want to look into default naming to simplify diagrams, so if I use the name “OK” on the button and as no other object on the diagram uses that name – “OK” should be ok – local name scope. I need to work a bit on the details here, but I am reaching a point where I can generate code. And once I start generating code I will probably also need to adjust BSA to cover details I have not seen yet.

Another observation is that the forms and logic shown above can be auto-generated from the Table definition – simply adding a Wizard that provide a default diagram you can change afterwards. This capability is worth gold if you do heavy database modeling and want to quickly test your model. Keep in mind that the “Table” here can be anything from a real SQL Table, to a XML file, RAM table etc.

The one thing I am a little unsure about is binding of events from the Table to the Form – I think I will like to avoid creating a “source” in the edit fields and force “Fetch” to convert data in the current entry to fields on the screen (or other data entries) – this way I leave the user full manual control and avoid auto-magic that don’t always work. The complete diagram can be see below.

I think this will work out just fine – and sorry for the dotted flow lines – that is a bug 🙁

One complicating factor here is that Select, fetch and Update hide the executable details – you will have to click on each bog to see actual code in form of properties. This means that while it is easy to follow logic it is more difficult to see actual code and find bugs – so I need to work on that a bit as I address the debugger later.

BSA is coming together, but it is a complex tool and lot of things that needs to work properly. I am currently focusing on classic database modelling, Forms and Modbus in the first release that probably only will target C#. It is more or less exactly 1 year since I started on this task with WPF so progress have been good, but it is still a lot of work to be done.

Now as I know why I have a performance issue and know the solution it is also possible to make a compromize. I need to address performance, but I can live with what I have for a while. The issue is that it is easier to experiment with functionality using XAML, so I can make it functional before optimizing performance – you need around 50+ properties before you notice the performance issue anyway.

The reason I can make this compromize is because the real property list is an internal list that do not care about the property editor, so all I need to do is to make the new, optimized with an identical interface later and voila… lets move on…

This picture is the old one that had performance problems. The new one is not so impressive yet, but it’s performance is far better. I ended up doing the exact same from code as I did from XAML finding out that it was far faster and allowed me to do some smarter code. At the end of the day WPF (or should I say GPU) are capable of handling large tables, but you need to be aware that IO between CPU and GPU can be a bottleneck. So at 1000 entries it still started to get unacceptable slow. The solution is obvious – since I now coded the grid I could also focus on the visual parts only and update the grid as I scroll – basically creating a virtual grid to be able to handle large amounts of data.

The problem started as I added several properties to the grid and noticed that it became slow, so I added 1000 and was shocked about XAML performance. I am not confident that coding it in C# will be better then all details are added, but I can add smarter code. I only update those that are visual and text strings (as an example) I only display and create the editor as I need them – I also only create a single editor because I can only edit one field at the time anyway – the later is important for solving the huge memory leakage I detected.

The drawback is all the extra work I am forced to do, but this is engineering for you – sometimes you need to redo things because of unexpected challenges.

Looking at the examples above I also need to consider the end result – the embedded mini word processor is great, but it makes the property list long. The same with the attribute table expanded – and as each attribute have it’s own description with mini editor this really takes over the property list. The result all in all is very functional, but this is a very important part of the tool so we need to be critical and look for improvement options. One details is how I collapse a description – another is to avoid expanding multiple attributes unless I want to – I could also move tables and descriptions to separate pages – this is the upside og not using XAML as I can easier do more smart systems.