BasicPI

SDL (Specification and Description Language) was at one point considered as a UML diagram add-on, but UML went in a different direction. I am used to SDL from Telecom and use an abstracted version (simplified) because I liked the state engine concept added to normal flow charts – so why did I bother with UML State diagrams on top of SDL? The answer is that UML State diagrams are superier on showing information flow on the higher level, while SDL is superior then dealing with executable logic on lower levels. The two methods complement each other well. In the example below I have drawn a diagram – UML State Diagram at left and SDL at right where the SDL part actually is the executable flow chart inside the UML block at left.

PLD (Plain Logic Diagram) is a Flow chart with some abstracted SDL added as well as UML State diagrams added. It is a bit of work before we can start generating code, but my previous experince with SDL is that a common user need about 5 minutes to learn reading the diagrams. We actually used these diagrams as a specification on some systems and they are great as we did not have a single dispute over functionality – the only issue at the time was that drawing these diagrams without a specialized tool is to time consuming. BSA will change that!

Changing UML State is straight forward – just use ToolMake to add a new property and change the default settings + a few lines of code to add the header change I also added. This is a compromise on my earlier Connection Point – I decided to change the default to Free and implement Free as no CP’s shown for now. I have already changed Start and Exit symbols and that is basically most of what I need right now – the next step is to change Flow lines. This means I keep existing functionality (for now), but change default behavior only.

I keep praising ToolMaker, the utility I decided to make som time back. It is a simple table driven aproach to change properties and the generated code automatically make the usable in diagrams and set up the editor for them. This is also a lesson learned because the amount of work they have saved me is increadible due to the watse number or properties.

Another tool I really start to like is the Copy function that allows me to copy diagrams into emails and documents (below) – I still have work to do on Clipboard and Print, but I am using the Copy function daily now. In the end I decided to only convert text and background colors on a hard-coded scheme (for now).

I wanted to draw some simple, high level UML State diagrams using PLD and while it worked I also used far more time than I expected. This was in many ways a big failure with regards to the objectives I have set, so I need to do some re-thinking.

In this first diagram I use Connection Points (CP) to draw lines. The issue is that links in this case only goes between CP’s and from left to right. As the CP positions are automated it becomes close to impossible to have straight, nice lines and as the diagrams grows this becomes messy and we start using more and more time on making diagrams look pretty. More important is that real diagrams is very limited if you draw only top-down or left-right + I ended up removing the automated event/method names as well. All in all I managed to draw the diagram I wanted, but I concluded that I had achieved the opposite of what I wanted – I ended up using a lot of time fiddling with lines – lesson learned!

This next diagram is the same, but here I switched to Free drawing to avoid the CP’s. In this case the diagram is cleaner, I can easily make lines straight  and notice the added lines that goes back or use other edges. A State Diagram show flow of events/info between objects and visualizing the below using CP’s that only was Top-Left or Left-Right simply did not work well,

So, how do we move forward? Some of you will recall that we started with simple lines and changed to using CP’s. The arguments was that CP’s visualized what events that was available and also visualized mandatory events etc (mandatory must be implemented) – so yes going back to pure lines will add some work as we need another method to specify events and methods.

The name labes are the easy ones – I currently let CP’s control displaying of labels (event names or method names), but I will move that to the lines itself anyway. It is also possible that I can allow user to move CP’s themselves or simple not show the CP’s once they are connected. Moving a CP is a bit difficult as current mouse click is connect, but lets see. On the other hard I also want to be able to connect to the same method on several edges without having CP positions forcing my hand. What I will miss is the functionality where you just use your mouse, click on a CP and connect to another CP as having to select the Flow tool is extra work, but now I am just being pouty 🙁

As for getting things right – we have the compiler that can pick up if flow lines are properly terminated or not, but the nice think is that we can chose to not care about thos details as we design as it is an implementation issue.

Just for the record – PLD cover UML State Diagrams, SDL (Specification and Description Language) as well as basic flow charts. PLD is a merge of those modelling techniques. Your diagrams can be what you want them to be + design is an important task of SW engineering, so having nice, precentable diagrams are a must.

Another issue I need to dig into is flow of events vs flow of data. I had a need to differ the two for illustrative purposes. And I also need an option to use a single line for multiple events on high level diagrams – this can be a special, thicker line where the user can drill down to see details. All in all – this had to be expected – adjustments as we start using the tool.

The UML State Diagram below illustrates an Actuator that regulate on Position, Speed and Torque, but is input data here Events, Data or both? Also the diagram show event name three times. In this case the gray names should be hidden as the Start Terminal carry the event name. I am not sure I need to differ between Data and Event as Event carry parameters and can carry new info in parameters or be a trigger to read a table.

Just for the record below is the clipboard version of the diagram that can be Pasted into any doc.

BSA uses the terminology “Module” for an independent sub-project that can be anything you want from a Windows executable, to library or Embedded Image. The content is up to the developer. I just added a menu to create new modules and I am not 100% sure about the result in the visual dictionary. I lack a method to visualize what module I work on for one, but using the same folder visualization for everything makes it confusing what is what. I will need to work a bit on this.

I probably should hide empty folders as well + add separate icons to folders. Content do have separate Icons. As we start to store a repository in separate files we might also need a file/folder directory – not sure.

It is also a question if I should show content as Module->Diagram->Content and how I should apply folders as we might expect large modules.

In my first clipboard example I borrowed some code that copied a UserControl “as is” to the clipboard. If you study that code you will notice that it performs two steps:

• Create a bitmap from a UI Control
• Copy Bitmap to Clipboard

As the Canvas I use is dark theme background and the UserControl have grid lines and controls that is not part of the diagram that comes out a bit grim, so what I do next is to create a Canvas, copy symbols I need to the Canvas and then create a bitmap from this Canvas. In my case that is basically a copy of the code I used for Print/Preview.

• Create new Canvas
• Copy graphics you want to new Canvas
• call canvas.Arrange()
• Create a bitmap
• Copy bitmap to clipboard and voila…

This gives me a solution to copy a diagram, change background/colors and copy that to the clipboard. The result can be seen below.

I still need to convert some colors correctly – or more correctly set up a editable conversiontable between light and dark theme since I use dark theme on screens and print and clipboard is light color themes.

The Property Editor is great and almost work as an inline editor, but as I work with visual content line names and text I keep looking at the diagram as I type, not at the Property Editor so adding a full inline editor is on my list of ToDo. Inline editing is straight forward as we only activate an edit box in the diagram, but it is a bit of work as this needs to be specialized per visual symbol. The graphics engine have a design layer to support inline editing – the select markes you see (yellow dots) use that layer. This allows me to add other inline editor tools as well later.

I wanted to add a simple Ctrl+C to copy a diagram to clipboard and as with printing I found an option to copy a UserControl “as is” with a few lines of code. The result is not exactly great, but it makes me think I should be able to do this more controlled rather easy.

Actual code is listed below and original article that provided this example is here.

It is nice to finally use BSA’s modeling capabilities on projects myself. I actually use it to reverse engineer a large PLC project written in Siemens SCL, as well as using it on BSA. Commercial tools in acceptable price range simply don’t have the precentation capabilities that I need + using BSA myself I also get a first hand experience on what needs improving.

I am very happy with the dictio0nary at left, but as the number of objects within a module grow I basically need a package & folder option to organize them. I was thinking about using “Module” as a package, but I think I need something within the module to split things up and improve overview. BSA itself is a good example on why we need that.

Beta 0.3 (shown above) is now consistent so I can start using it, but it still have anoying bugs and limitations. Improving the dictionary is one, completing print/preview another and copy to clipboard is also needed. Performance was fixed with removal of the old document tree, so BSA is now very fast to work with.

Property Editor was “ok”, but became much nicer as I added inline editing on tables. I will need an undo system and automatic backup system. I am still using a single file, but I am considering splitting the saved project into (1) a module content list and (2) a file for each diagram. I have used XML as saved format, but might want to replace that with JSON or some other format that is more GIT friendly. Multi-user is wanted, but I consider doing that through GIT only and focus on GIT integration.

As for the package/folder issue on the dictionary – we can add folders very easy as a precentation on all levels. Package needs more thinking because I nee a need to extend class diagrams with packages. It is possible I should use Modules as package and add a free folder option so we can organize content as we want – not sure – this one need a bit thinking and maybe try and fail.

At one point I implemented a “document” – basically a tree with all the content in the diagrams and details about each object. You can see an example at left below. As the project grows, so does this tree and the full tree start to take time loading as this is based on a standard WPF component. This was an issue with Forms and MFC (Native C++) as well, so it is not just a WPF issue – loading big trees take time and if you need to maintain info in it the visual tree become a slug slowing down your app – or in this case it slows down BSA as we load and do operations that changes content in the tree. Solution ? In this case I just remove the tree because it was mostly a debug thing – the Dictionary is much lighter and have taken over anyway.

You might remember I wrote about performance issues earlier and this document tree was the cause of them. I accidentally updated the tree while loading making loading slow, and now I realize that any change causing this tree to be updated slow down operations – so for now I simply remove it – If I want it back I will need to implement partial load. This is a visual precentation so rather than loading the full tree I can loan only the visual parts. But, I don’t see the need for this after I implemented the visual Dictionary. And the worst is that I knew this because I have had this issue several times – the proper solution is called “partial load”. I have my custom Tree component used in Dictionary that support this. WPF is capable of handling very big trees very fast, but loading them is slow – so you load only the visual parts as you need them. DataGridView have an excellent callback for this.