DQMH woes

[joerg.hampel]

---

@LVUser94 wrote:

Sorry for the long reply. I will keep you posted on what I find. As you said it is probably unlikely to be a DQMH bug, but the architecture is definitely getting in the way of debugging this.

---

I know that I find it hard myself to stand my ground without sounding dogmatic, elaborating usually helps others better understand our own reasoning. 

Thank you for taking the time to elaborate, it’s always interesting to hear fresh experiences and opinions. 

As for your project, Sam and Chris already gave valuable tips. I join them in their recommendations. 

[drjdpowell]

Do you guys have Antidoc diagrams from some of your real-world projects?  It would be interesting to compare them to the OP's diagram.  Also interesting if I, an outsider who does not use DQMH, can easily tell good architecture from bad.

[LVUser94]

---

@Taggart wrote:

---

@LVUser94 wrote:

I don't want to turn this into a rant against DQMH, but I have seen enough of it to decide I don't want to use it.

---

The code you encountered has some major problems based on the Antidoc diagrams you posted. I wouldn't let that turn you away from DQMH any more than encountering a bunch of spaghetti code would turn you away from LabVIEW.

Is it overkill for some situations? certainly. Just like buying a power screwdriver is overkill if you only need to tighten one screw, but if you already had the power screw driver you'd probably use it and it'd do a perfect job and probably be quicker.  Similarly, do you need a DQMH module if you just need a simple single loop app? certainly not. But if you know how to use it, there is no reason not to.

---

True, I have inherited a lot of spaghetti code too. The correct approach is having a proper mixture. Of course I use subVIs and my main VIs are just a collection of subVIs with minimal LabVIEW functions nodes. But my subVIs are usually only 2-3 or levels deep, after which the subVIs below that level are usually from vi.llb or other 3rd party VIs. But my subVIs tend to have non-trivial amount of code and be capable of being tested as a unit. That way you can get a well architected software that is easy to navigate (for maintenance purposes) and efficient. 

[LVUser94]

---

@Taggart wrote:

My advice would be to refactor it.

Decide what the dependency graph should look like.

Come up with some basic test you can run.

Then start changing broadcasts to requests and vice-versa.

Change them one at a time and test afterwards. 

Run Antidoc after each one as well just to make sure things are moving the direction that you want.

Not a quick fix, but should work.

May be quicker to rewrite it, but inevitably there's some corner-case logic somewhere that you'll miss that will mess you up and that will cost you a lot of time and make for unhappy customers.

---

Thanks for the advice. I agree with your analysis. But I am in a situation where the system has already been delivered and in use. I am just responsible for closing out some issues. 

[LVUser94]

---

@drjdpowell wrote:

Do you guys have Antidoc diagrams from some of your real-world projects?  It would be interesting to compare them to the OP's diagram.  Also interesting if I, an outsider who does not use DQMH, can easily tell good architecture from bad.

---

I was wondering about this too.

It is amazing that Sam and Chris could take a look at the one Antidoc diagram and reach that conclusion.

[Taggart]

The best way I have found it to use a tree structure. I find it works very well. There is a reason that Stephen and Allen chose that for Actor Framework. As evidenced by the diagram that was posted earlier, it is possible using DQMH to have messages flying all over the place. That makes debugging very hard and causes lots of issues with dependencies, in particular circular dependencies and circular messaging. Using a tree structure prevents circular dependencies and provides choke points for messages for debugging purposes.

To turn one of those antidoc diagrams to a dependency diagram is fairly once you know what to do. The green arrow that represents the requests is the same as a dependency arrow. It points to the thing being depended on. If A sends a request to B, then A depends on B.

The orange arrows with dashed lines that represents the broadcasts, goes in the opposite direction of a dependency arrow. If A is registered for a broadcast of B, then A depends on B.

Here is an example.

A much smaller project. Not a tree structure by any means. However there are no circular dependencies. If you start at any module and follow the green arrows and go against the orange, there is no way to get back to the starting point. The same is not true for the diagram that was posted previously in this post.

[drjdpowell]

---

@Taggart wrote:

Here is an example.

 .

---

Looking at this, I think the plotting algorithm inside Antidoc could be improved by arranging dependencies left to right if possible.  Here "Utilities UI" should be in a line with "Settings" and "Home UI", while "Ethernet IP" should be to the right of it, under "Order Handler".  That would be a much better diagram.

[Taggart]

Well I guess its a gamble. It's a matter of can you find the problem quicker than you can refactor it? Neither one seems to be trivial. However at least with the refactoring, there is a good place to start and clear direction. I guess there is no guarantee the refactoring will take care of the problem. It might, but even if it doesn't it should make it easier to find and fix the bug. And at the end of the day it will leave your code in a better state should future bugs pop up or enhancements need to be made. Long-term refactoring is probably the better choice. Short term, who knows?

Hindsight is always 20-20. You just gotta pick one and go with it.

[Olivier-JOURDAN]

---

@drjdpowell  a écrit :

---

@Taggart wrote:

Here is an example.

 .

---

Looking at this, I think the plotting algorithm inside Antidoc could be improved by arranging dependencies left to right if possible.  Here "Utilities UI" should be in a line with "Settings" and "Home UI", while "Ethernet IP" should be to the right of it, under "Order Handler".  That would be a much better diagram.

---

Not sure that arranging dependencies would be something easy or at least possible to do. I'm also wondering how it would behave on a larger diagram like the following one. 

Note that after displaying the general overview of module links, the documentation generated with Antidoc lists all modules with a diagram representing links between the module and the rest of the code. Examining that specific diagram should allow detecting circular dependencies.

One question could be, "should Antidoc detect those circular dependencies and generate a kind of architecture analysis report"? I don't know if it would be an interesting feature and how proprietary it would be compared to other features like supporting other public frameworks...
Open question...

[Taggart]

---

@Olivier-JOURDAN wrote:

Note that after displaying the general overview of module links, the documentation generated with Antidoc lists all modules with a diagram representing links between the module and the rest of the code. Examining that specific diagram should allow detecting circular dependencies.

One question could be, "should Antidoc detect those circular dependencies and generate a kind of architecture analysis report"? I don't know if it would be an interesting feature and how proprietary it would be compared to other features like supporting other public frameworks...
Open question...

---

To your first point, the smaller diagrams that just show an individual module and all its direct dependencies are useful, and would catch some, but not all circular dependencies. If you look at the original diagram here it has some large circular dependencies ie. A depends on B which depends on C which depends on D which depends on A. The smaller more targetted diagram probably wouldn't catch that.

To your second point, I think it could be very useful to alert users to circular dependencies. Although part of me says that someone who couldn't figure out that there are circular dependencies from the diagram probably isn't going to know why a circular dependency is bad or what to do to fix it. In that case, is it useful to point it out to them? I guess having the information is better than not having it. If you knew enough to be able to identify the circular dependency but just missed it, then it might be useful. I think I'm pretty good at picking them out but occasionally I miss something.

This might all just be me projecting because I find it rather trivial to look at one of those diagrams and find the circular dependencies. Maybe it's some skill I've built up over time that not everyone has.