I'd like to know the scenarios LabVIEWers use uml or why they are interested in it. We already have a graphical representation of our code, do we really need to model it graphically? Please fell free to post whatever you want to tell about your own experience with LabVIEW and uml.
Here is my personal experience:
Mainly I use uml to model and document state machines. I did use 'bubble-and-arrow' in the past using MS ppt or OpenOffice Draw, until I wanted to do it more professional and embraced the uml notation and finally used uml tools.
The most important situations for uml usage in my career are when I need to communicate with SW-developers of other companies. Using uml is signaling that one is a professional software developer and not just cowboy-coding. A signal to developers, managers and customers alike. I also judge other developers by this (so don't try to impress my with a flowchart).
The other (personally more inspiring) issue is the philosophical approach in the uml specs itself. As an example, as SW devolopers we talk about levels of abstractions.
We know a lot of specific code that does peform abstarctions, such as when you design an architecture, a framework and the like that can be reused in different circumstances. Same situation when you try to make a bundle of reusable SubVIs from the scratch. Even more, when you try to model good LVOOP classes. This isn't an ivory-tower search for truth, but means of better productivity because it might take more effort in the first project but you already gain the benefit in the next project.
So independent of what we do (even outside the scope of software), how is it possible to be more effective? What are the means we can abstract a from a concrete piece of work and put that knownledge, VIs, wisdom, experience to safe work/money in the next project?
We use UML primarily to design our implementations.
For each software component (after we create a top-level component diagram and a deployment diagram for the high-level view) we create a statemachine diagram, a class diagram, and an interaction diagram (for signal-based behavior) for more complex systems. We use many of the other UML diagrams, but these are the ones we rely on most frequently. We model our design both in terms of logical structure and in terms of behavior.
Note that LabVIEW itself can only depict (after the fact) generalization relationships. It offers no facility whatever to show composition, for example.
[We also use SysML to model requirements and show traceability to test cases and design elements. We can export the test procedures (called scenarios) to a test application, execute these, and record the results.]
We find it is far more efficient to do the design correctly in the first place than to rework the code to fit a good design later, and a good design results in much better code (more efficient, easier to read, less repetition). This is especially important when one uses, as we do, common code that we generalize for particular applications.
We find it is also orders of magnitude faster to make changes to the UML model than to the code, so it is even more important to create a model first.
Once we implement the code, if we find we must make changes, we update the model as well. This ensures that the model can serve as both an interface definition, where appropriate, and a design guide for someone who wants to understand the design.
Our code matches the package structure in UML, and at each level at which we check in a package in UML we create a project library (.lvlib file). At the moment in 2010 I am creating packed libraries for each of the project libraries, which I think will help us control and build the software components much more efficiently.
I found some time to look at SysML. Seems really useful for general engineering. I'm waiting for a project that starts from scratch to try it in a real-world app.
Thanks for bringing it to my attention.
Today I was modelling on a real world app that has a complex interacting hardware typical for system integration. Can't share the details of the app, but my new ways of applying uml to solve this kind of problem. I used a Composite Structure Diagram:
In the example provided here I how an DAQ PCI card plugged into a PC. To the top I depict that the behavior of the DAQmx card is abstracted in the DAQmx drivers. Of importance is, that DAQmx_Drivers is of metaclass 'Class'. So in a ClassDiagram I use the same class and fill it with properties and operations to my needs.
Above is just a very simple example, in the real app it's much more complex. I use ports on the DAQ_Card for my other electronic connections (DI, DO Counters, AI and AO) which in term connect to other devices that are controlled by the PC as well through other bus systems. Some of them are interfaced by LabVIEW code that I have to write on my own, this is where the <<abstraction>> is really useful.
So at the end I have the Components of my hardware and their interconnection as well as a relationship the code segments (classes) that control/describe their behavior.