Dataflow outputs and ParameterDirectionKind

[PaulL]

Here is a question I am pondering:

 

The UML specification defines ParameterDirectionKind (7.3.43 in the V2.4.1 superstructure specification, available at omg.org) for an operation defined on a class.  The description there is:

"ParameterDirectionKind is an enumeration of the following literal values:

• in Indicates that parameter values are passed into the behavioral element by the caller.

• inout Indicates that parameter values are passed into a behavioral element by the caller and then back out to the caller from the behavioral element.

• out Indicates that parameter values are passed from a behavioral element out to the caller.

• return Indicates that parameter values are passed as return values from a behavioral element back to the caller."

 

So, do we model the outputs of a LabVIEW class method (VI) with the "out"  or "return" direction?  I decided long ago to use "out" and never "return" for a number of reasons (some theoretical, some practical: "inout" does make sense, after all; many languages support only one return value, although this is a design choice), and I delete "void" for the return type in the operation prototype since I regard that as meaningless for LabVIEW.  I still think that is the best approach, but I'm not certain that I have the most rigorous explanation, and of course I could be wrong altogether.  Thoughts?

 

Paul

[MikaelH]

I'm using <out>

Sometimes I write it like this:

Isn't LabVIEW the best, that can return multiple "by value" return values!?!

 

[mje]

I decided long ago to use "out" and never "return" for a number of reasons (some theoretical, some practical: "inout" does make sense, after all; many languages support only one return value, although this is a design choice), and I delete "void" for the return type in the operation prototype since I regard that as meaningless for LabVIEW.  I still think that is the best approach, but I'm not certain that I have the most rigorous explanation, and of course I could be wrong altogether.  Thoughts?

 

I'm in a very similar school. I think "return" values are meaningless in LabVIEW, I use in/out/inout exclusively. Disclosure: my UML use isn't exactly rigorous, I use it for my own personal mapping of our projects, it's not used in official documentation or anything.

 

My usage of in/out is pretty basic, corresponding to control/indicator terminals. I don't think this needs any real explanation.

 

As for "inout", after a few iterations (including ditching it completely only to revive its use) I've managed to settle on only using this for terminal pairs which type propagation is guaranteed. The obvious example would be dynamic dispatch terminals, but there are other cases (explicit use of the PRTC primitive).

 

Random stream of thought that landed me here:

 

Take for example:

 

Foo(in MyClass_in:MyClass, out MyClass_out:MyClass)

 

(Pardon the pseudo code)

 

I don't like this for two reasons: it doesn't make it clear there's a type propagation between MyClass_in and MyClass_out, and it doesn't show the dynamic dispatch relationship.

 

My solution is the use the "inout" enumeration to show that indeed, there is a relationship between input and output:

 

Foo(inout MyClass:MyClass)

 

Here this implies a pair of terminals in LabVIEW, but still doesn't imply dynamic dispatch, as well as it shouldn't (again, PRTC comes to mind). So for DD I adopt the use of a <<Dynamic>> stereotype.

 

Thus the following three prototypes are indeed distinct:

 

<<Dynamic>> Foo(inout MyClass:MyClass)

<<Dynamic>> Foo(in MyClass_in:MyClass, out MyClass_out:MyClass)

Foo(in MyClass_in:MyClass, out MyClass_out:MyClass)

 

Now straight away, I admit this isn't ideal. One point I don't like is how my use of the single inout parameter maps to a pair of terminals in LabVIEW. I also realize propagation is not the intention of "inout". But I see no other way of for example, distinguishing a prototype function that has a pair of dynamic dispatch terminals, versus one that has a pair of class terminals, of which only the input is dynamic dispatch (see for example state machine implementations, or more recently the actor framework message core).

 

Can we extend/restrict the ParameterDirectionKind enumeration? I have not found a way to do so in the tool I use (UModel) and I'm honestly too much of an amateur with regards to UML to know. I'm thinking along the lines of XSL how I'd really like to apply a LabVIEW profile which mutates the enumeration to something like:

• in
  
• out
  
• dynamic_in
  
• dynamic_out
  
• prtc_in (?)
  
• prtc_out (?)
  

Nomenclature aside, I see a use for all six of them. Ideally I don't think inout and return apply in LabVIEW.

 

Also, while I don't mean to derail, in addition to the <<Dynamic>> stereotype, I also have ones for <<Reentrant>> and <<Property>>. I don't use property nodes but I recognize they exist and feel defining properties at the design level is important if the class indeed implements them. Still on the fence regarding a <<Deprecated>> stereotype.

[MikaelH]

Foo(in MyClass_in:MyClass, out MyClass_out:MyClass)

 

 

This looks nice, but should you really need to specify that the class method should have a class in/out value?

I don't see you adding the Error-In/Out data to all methods 

 

If you like to have code generation from the UML, I guess it does make sense to add the class in/out value since the method could be static.

But maybe it's better to always assume you're having the class in/out unless you wire.

<<static>> MethodName (...)

And maybe even:

<<static>><<Error Less>>  MethodName (...)<<static>><<Non Virtual>> MethodName (...)<<static>><<Non Dynamic Dispatch>> MethodName (...)

Cheers,

Mike

[mje]

 This looks nice, but should you really need to specify that the class method should have a class in/out value?

I don't see you adding the Error-In/Out data to all methods 

 

 

Hah, yeah. Error I/O omitted for the sake of brevity laziness. Declarations can be looooooooong when you start enumerating the terminals. Often to the point of where I don't see the point of a diagram at all:

 

 

Do you really think this would be readable if this diagram were anything but a simple class? Really? When 4+ terminals start to be listed in any method, classes takes up the whole width of a reasonably sized diagram. Have a class where most terminals on your 4x4 are used up? Good luck with that!

 

To be honest, I find myself using pseudocode more then UML class diagrams. I end up with something that looks like a mutant offspring of C++ and UML. It's faster and just as legible when looking at any individual class, but it does lose the ability to easily diagram class relationships.

 

I always specify class I/O because not all methods have both in and out, see the Message.lvclass hierarchy above as an example.

 

Anyways, really trying hard not to derail this. Sorry Paul! But I do believe the desire to use inout versus explicit in/out, as well as for example Mikael's desire to move class terminals to stereotypes are all related to the topic at hand: UML can be way too verbose to be useful as a diagram in my opinion, but I absolutely recognize the need for the verbosity. Perhaps these competing forces are why I find myself never really getting serious about UML...

[MikaelH]

I only add the important inputs and outputs to methods when they help me/others understand the design, but most often I leave them out of the class diagram.

I use them more often in the sequence diagram.

And regarding to: "You have to only use the 4x4x4 connector pane settings otherwise nobody can understand your code, and the world will go under", I just don’t get this.

I’ve always used 6x8x6, for all my classes and I love it

[PaulL]

Anyways, really trying hard not to derail this. Sorry Paul!

No worries!  It's a great extension of the discussion!

 

I don't model accessor methods, nor do I add the owning class terminal inputs and outputs or error cluster inputs and outputs to method references, since these are understood (and I'm not doing code generation), so the resulting UML diagrams are relatively simple but convey the information we need to know.  Consequently, I haven't thought about how to label inputs as dynamic, etc., but I could see this might become an issue for code generation.  Still, for the most part I think I would put that in the code generator logic and template.  (Every method on a class will have class terminals--dynamic terminals if the method on this class or its parent is abstract; also error terminals, except for accessor methods.)  Hence the input and output parameters in the method definition in the model are just those that are really of interest for the method.

[drjdpowell]

Not used UML myself, but it seems to me that the terminals of a VI are much better specified in this way (not that available UML tools will support this   ):

 

[PaulL]

Not used UML myself, but it seems to me that the terminals of a VI are much better specified in this way (not that available UML tools will support this   ):

parameters spsc.png

Well, I don't know how seriously this is intended, but I think it questions the point of doing software modeling at all.

 

At the risk of derailing my own thread, here are a few thoughts on why modeling is advantageous and, I think, essential for effective programming:

1) We want to be able to propose, analyze, and modify design approaches prior to implementing them.  (The underlying argument is that, apart from trivial or by-rote implementations, if we just start implementing code we will not likely achieve an optimal implementation immediately; on the other hand, careful analysis can result in better-designed applications.)

a) It is much faster and easier to do this in UML than in the development environment.

b) UML expresses relationships more effectively than the LabVIEW IDE can.  (LabVIEW's class view, for instance, does indicate inheritance relationships but it does not indicate in any fashion relationships between methods, nor other essential types of relationships, e.g., composition.)

2) Within a UML/SysML tool we can also model behaviors (e.g., state behaviors), and link all of these to other essential elements of software engineering (e.g., requirements, tests).

3) Of course, it is even better to be able to be able to create code from the model, but that is something I don't presently do (but would very much like to be able to do--without losing the other capabilities).

 

Paul

[drjdpowell]

Well, I don't know how seriously this is intended, but I think it questions the point of doing software modeling at all.

Oh, I didn’t mean to cast doubt on the use of modeling; just noting the handicaps of using tools designed for languages with an X=F(A,B,..) syntax.  It would be very nice if there where a UML tool that could interface with LabVIEW to present a class with all the methods as icons, with ctl-H bringing up the standard window showing terminals and descriptions.  Modeling before coding might be slower, as you’d had to create shell VIs with terminals and rough-draft icons, but at least this will save you time when it comes to actually coding.  And in return you get a much clearer visual diagram.

[MikaelH]

It would be very nice if there where a UML tool that could interface with LabVIEW to present a class with all the methods as icons, with ctl-H bringing up the standard window showing terminals and descriptions.

It looks like you haven't tried Symbio's UML Modeller ;-)

 

 

//Mike

[PaulL]

Oh, I didn’t mean to cast doubt on the use of modeling; just noting the handicaps of using tools designed for languages with an X=F(A,B,..) syntax.  It would be very nice if there where a UML tool that could interface with LabVIEW to present a class with all the methods as icons, with ctl-H bringing up the standard window showing terminals and descriptions.  Modeling before coding might be slower, as you’d had to create shell VIs with terminals and rough-draft icons, but at least this will save you time when it comes to actually coding.  And in return you get a much clearer visual diagram.

Oh, OK!  I misunderstood, then.

For myself, I don't mind UML's representation of methods.

[drjdpowell]

It looks like you haven't tried Symbio's UML Modeller ;-)

I have not. I should have a look 

[drjdpowell]

An experiment in crude pseudo-UML using the IDE (for a selection of classes, and subset of methods, in my current project):