LabVIEW Development Best Practices Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Converting an Activity Diagram to an OOP Pattern

Solved!
Go to solution

Re: Converting an Activity Diagram to an OOP Pattern

Hmmmmm....revisiting what I have put up above, I realize that my "subsequence classes" are actually just creational patterns to a certain extent.  And for that matter, the pattern in question would probably be the prototype pattern described in the GOF's book.  But it's kind of odd given that everything is by value rather than reference; kind of gums up the original design pattern.  I wonder if there is a cleaner way to do this.... (i.e. get rid of the SUB class and just replace with a generic creational pattern)

0 Kudos
Message 11 of 19
(1,162 Views)

Re: Converting an Activity Diagram to an OOP Pattern

I wouldn't let Seq inheirt from Step, but that's just me.

But if you can say: "A sequence is a kind of Step" then the inheritance is okay.

Aggregate.png

0 Kudos
Message 12 of 19
(1,162 Views)

Re: Converting an Activity Diagram to an OOP Pattern

Mikael, the point of the pattern he used is to treat the Sequence like a Step. That is, give it the same interface as Step but design its methods to execute a macro of steps/sequences. So yes, saying "a sequence is a kind of step" is prerequisite to using this pattern. It can be very powerful for reconfiguration and extension of an existing sequence or execution framework.

0 Kudos
Message 13 of 19
(1,162 Views)

Re: Converting an Activity Diagram to an OOP Pattern

Mikael,

This is the definition of the composition pattern. 

So, I think in my final design I will get rid of the SUB class (representing subsequences) and have no inheritance of the sequence class.  Combining the composition pattern with the builder pattern, I get something like this:

Generic Sequence Class.jpg

The sequence builder shows up as a dependency - it is used by the method Init SEQ from Builder in the SEQ class.  The code is pretty straight forward in this iteration and the API much cleaner.  I will post it when I get a chance and you all can tell me what you think.

Matt

Message was edited by: mtat76

Message 14 of 19
(1,162 Views)

Re: Converting an Activity Diagram to an OOP Pattern

Yes, using inheritance to create design solution is perfectly okay (e.g. the Decorate Design patterns https://decibel.ni.com/content/message/35117#35117 )

In some solutions (especially when I made my TestStand Light software), I have a base Step class everything is inheriting from.

Here is example of how I used the  composite design pattern http://goop.endevo.net/GDS/videos/DesignPatterns/.

Of course using a referenced based design makes the composite pattern easier since the SEQ can have the STEP object direct in its attribute and don't need to use the LV Base object.

But wait, now I see that it looks like the STEP aggregates the SEQ, that's not the Composite pattern I know!

Cheers,

Mike

0 Kudos
Message 15 of 19
(1,162 Views)

Re: Converting an Activity Diagram to an OOP Pattern

Generic Sequence Class.jpg

Better??  Sheesh...

I will have to take a look at the rest later.  Thanks, Mikael.

m

0 Kudos
Message 16 of 19
(1,162 Views)

Re: Converting an Activity Diagram to an OOP Pattern

Don't forget to add an attribute in the SEQ class called: StepsSmiley FrustratedTEP[] or StepsSmiley FrustratedTEP depening on the multiplicity ( 1 , 0..* , 1..* ).

BTW you might want to try GDS's UML editor that will generate the labVIEW code for you(http://www.symbio.com/goop/) ;-)

The free version supports up to 20 classes.

//Mike

0 Kudos
Message 17 of 19
(1,162 Views)

Re: Converting an Activity Diagram to an OOP Pattern

Thanks, Mike.  I am just trying to show the overarching design and have left some of the details to the imagination (such as multiplicity).  I think the free version of the GSD will not work for me given that with these patterns I generally have considerably more than 20 classes (obviously not shown here). 

Matt

0 Kudos
Message 18 of 19
(1,162 Views)

Re: Converting an Activity Diagram to an OOP Pattern

I like this thread.

I have recently been mulling over a similar construct and was wondering why nobody has done it before.  Turns out i just need to read better. .  Especially the "Execution of steps may occur over multiple calls" appeals to me as composite objects are (almost) unbounded in complexity and associated execution time, splitting them into atomic sub-actions has a lot of benefits regarding responsiveness.

I note also that the choice of "Add" " retrieve" methods and so on are present only in the Composite Interface (Seq), and not the base component (Step)).  I too prefer this approach but was wondering if anyone has any counter-arguments?

Shane

0 Kudos
Message 19 of 19
(1,162 Views)