BasicPI

The following diagram is an example of a Class and an associated Diagram – see text below picture:

In BSA a Class and a Diagram can be the same as they can precent different aspects of the same object. A Class itself is only an overview of an object, but a Class Diagram adds inheritance and associations showing relations to other classes. The PLD Diagram visualize logics connected with methods and events that is not shown in a Class Diagram. The above, simple example illustrate some of this.

Here we create an object that can send an email to a customer. You see the simple PLD logic at right and a definition of the class “Customer” hidden inside the diagram “Customer”. This is fully legal. Notice that the content of Class “Customer” is the same as variables, methods and events in the diagram.

I will return a bit to the nitty gritty details on how this links together – I have a draft that I will implement today and then I need to test it a bit. But, the real test comes as I start activating the code generators – which is the next phase coming very soon.

I needed to consolidate PLD a bit around calls to sub-diagrams and functions, so I added a new diagram symbol and a new function call symbol. These overlap a bit, but the diagram symbol show a different diagram being used as a sub-diagram. If you double-click on that you will navigate tothat diagram. The signals in/out are connected to methods and events on the diagram. Name will be maintained automatically to be syncronized and you have a new context menu that allow you to link to a different diagram or create a new.  The diagram can be drawn rather freely as the editor will not check rules and integrity – that is what the compiler will do. This is rather important as it offers a designer the option to do fast hight level drafting and worry about executable details as the design matures. The incomung signals can display methods and events used if required. The function call uses a specific method in a diagram. You can do the same by using a diagram, so it’s a bit up to you.

I need to add in Classes in the diagram linking, but after that it is only testing/bug-fixing before the Beta will be released.

The diagram below illustrates some challenges we have in BSA – how does things glue together ? The small diagram have a single class “Customer”, a small state diagram and a Data Table – all providing different part of an application.

Class as an example is a declaration of a “datatype” with attributes, methods and events. Data Table is an actual instance of a class or loose data stored at an exact location, a state diagram on the other hand visualize the logic behind methods and events in a class. You do not need to have a 1:1 between diagrams and class names etc, but if the names are the same they will be treated as an representation of each other.

A class definition is global for the module and as discussed before we can visualize data using presentations – which is needed on some physical classes due to their volumious content. If you create a diagram “Customer” that will be a different visualization of a class “Customer” where PLD show executable logic and the class show content and associations to other classes in you model.

These links are currently free text with no rules attached. That will change later as the compiler get activated – for now I will create navigation links between a state “Customer” and a diagram “Customer” and class “Customer” + links between member/events and terminals. It is straight forward to do, but to get it correct I will need to start using names correctly “diagram1.start1” etc which is a pain, but I will see how it works out – This has been long-time coming and is one of the issues that has caused me some trouble, but I think it will work out. To shorten name I could allow usage of full name as well as adding a “using” definition – simply a list of content used in a diagram, but this again have a different issue.

These things will not be written in stone – the reality is that we need to see what works and what does not and evolve as we go – this also means that these early Beta releases migh include non-backward compatible changes – I will try to avoid that, but it must be expected to some degree before we reach maturity.

The diagram below show two sub-diagrams. Sub_Diagram1 is a standard function call while Sub-Diagram2 have multiple input signals each connected to a specific method in the diagram. Both are legal drawings “as is”, but they have conflicting precentation needs. In “Sub_Diagram1” is is natural to assume that we call a function “Sub_Diagram1”, while on Sub-Diagram2 we call “Sub_Diagram2.<method>” – what method can be visualized on the input line.

Earlier I had a seperate function call that I removed, so it’s possible to bring that back – I removed it because visualization was identical with a sub-diagram. Another possibility is to make a rule that unless you specify a method you actually call “Sub_Diagram1()” – this will work, but how do I then specify what diagram “Sub_Diagram1” is located on? This is the same as with C++ or C#, you need to specify “class.function” one way or another – so do we. I am not concluding, but I need to look into this one and see what notation that works and not.

Copy & Paste is finally working as they should. BSA allows you to draw duplicated tags, but the compiler will raise it as an error, so paste do not change tag names like the “Start_68” below (yet) – I am not sure I want it to either because design and coding are different tasks and we need to support both. I lack handling of versions as well – we need an option to handle multiple versions of a diagram, but that is not critical now – I was mostly interested in Copy&Paste because it was very annoying not to be able to do it.

My November/December release is running a bit late, but the list of what I want to have implemented/fixed is getting shorter. I need to convince myself that I have a properly working modeling tool and while I started on class diagrams, state diagrams and PLD sneaked in adding to the scope – but, it makes sence. The main thing remaining is sub_diagram to diagram linking + error fixing. I am surpriced about some of the bugs I find – or more correctly – how little things are tested – this is one of the reasons I need to get this on the road.

The diagram below is an “abstracted SDL” – or simplified SDL if you like – it is a flowchart with SDL heritage that is a very good way of writing a visual specification assuming you have a tool that support it. This is at core in PLD. This exact example send a message and wait for responce. It performs an operation that in this case send a message out, PLDState will wait until a selected event happens etc. The direction and bar colors on operations and events is just presentation issues – in fact this is only a drawing tool as we speak as parameters for code generation is missing yet.

Events are key to PLD! The example above use a SDLState that “Wait for an event”, but you can add this event tree to any symbol that has multiple events. The event symbol will only accept one input line and pick an available event from the connected symbol – in this case a PLDState that list the events it is waiting for.

This last diagram use a switch symbol to indicate that we select one of many conditions. Unlike PLDState that will wait for an event this executes directly without delay and is an elegant way of drawing complex if/selections. This is modified SDL behavior and a very effective way to draw a complex if, elseif or switch.

One of the reasons I call this “PLD” is because it is a graphical language with heritage from Flow-Charts, SDL and UML, but it is a separate standard so we get to find symbols and ways to precent them. Nothing is written in stone yet as it comes down to what works and what does not.

PLDState and PLDSwitch is very similar in the sence they have a dynamic event/condition list – the difference is that state will wait until one is true, while switch will not as it is designet to make a selection “now”. Other symbols can use the same tree, but events will be a static list base on availble events.

One of the upcoming features is the capability to import C/C++ code into a BSA project – correction I only want to be able to read C/C++ so I can set up the BSA Repository to generate code that uses an external C/C++ library. This is one of many important features as you integrate high-level to an actual platform. Looking for existing projects that does this I found several targeting C# so I plan to re-use one of those. This will enable an user to import existing libraries into BSA and use them.

The process is fairly simple – you run a CPParser that read your source code or header files and generate some kind of repository “AST” – you then run an internal import converting the info we need into our own Repository. This function will be added as soon as the modelling release is out in Beta.

I am also looking for similar libraries for other languages, but it will obviously also be possible to define this manually.

I am experimenting a bit with C++/PScript coding in PLD and you can see the mock-up below where I create 3 math functions.

The diagram is named “Math” so the functions are Math.Pow2, Math.Abs and Math.Sin – two of them in C++ and one in PScript. Assuming the target is C++ you can add C++ scripts using the Assign block. This is handy then you want to just add a few lines of code in C++ directly. PScript does the same in a generic way, but on the low level functions you will need to use C++ a bit. My first target is C++/STM32.

My first comment is that – yes it is possible to write target source code, but it is not a nice way to code as is. The editor I use is ok for text, but not for source code so I will need to change this. My plan is (1) to add a more decent editor for sourc code – double click to open an editor or something – (2) add an import function and support external functions so you can write target language code in your IDE and just include it from BSA. But, these changes will be for later.

Another issue is that Math will be a large library – the actual library will be an include, but I would like to be able to create this or similar in BSA- and yes I can. Looking on the picture above you will see that I run out of diagram space. This is the one drawback with diagrams – they take visual space. So in short – I need a sub-diagram option or “partial diagram” – simply an option to create a new diagram as an extension of a previous one so I get the “Math” prefix on all functions. The simple solution is to create a new diagram and call it “Math” and then let BSA auto-detect this being parts of the same diagram. Diagram name in BSA is the same as Class or Namespace in C++/C#.

It is a few things on the modeling level that need fixing before I have a release:

• Annoying line errors. Diagram lines are sometimes a bit off and you don’t see it before you copy or re-load a diagram. This must be fixed.
• A consolidation of tools available in PLD.
• Listing known errors.
• Implement Copy function.
• Add partial diagrams.
• Fix select function to be consistent.
• Fix internal diagram to diagram links.

That’s it – after that I release a Beta and start on C++/STM32 code generation. Next is adding HMI back in and supporting C#. The plan is to support C#/WPF for HMI and C++/STM32. I need to start somewhere and these are the two that is easiest to implement for me.