Converting an Activity Diagram to an OOP Pattern

[cirrusio]

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)

[MikaelH]

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.

[David_Staab]

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.

[cirrusio]

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:

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

[MikaelH]

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

[cirrusio]

Better??  Sheesh...

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

m

[MikaelH]

Don't forget to add an attribute in the SEQ class called: Steps:STEP[] or Steps:STEP 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

[cirrusio]

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

[Intaris]

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