subState to State transitions - mental block

[sargasso]

I'm a bit stumped here.  I don't even know whether I've got a problem or not or if I do whether to do something about it ..or not.

N.B. Hereafter, (NAP= that's not a problem, that's how the "boat" is required to be)

I have this set of things that fit into an organizational heirarchy (NAP). The heirarchy is structured and finite (NAP), in fact three levels only.  Each level can be in a defined and  organized  set of states, each level having the same states (NAP).

There are 4 states for the levels:

• proposed
  
• active
  
• obsolete
  
• notational
  

and a whole shipload of transition constraints. (NAP)

Thank you for your patience, here's the beginning of the problem.

"Proposed" has three substates:

• draft
  
• developmental
  
• ready
  

There is only one state transition, I am currently trying to flesh out proposed-->active.
One of the transition constraints is "only if substate = ("developmental" or "ready").  IOW, if the item is in substate "draft" then the proposed-->active transition is illegal.  This is again NAP (I could just show transitions between the two valid substates and "active")...

BUT
What I want to show is :
You can go from proposed-->active regardless of your substate, unless you are specifically prohibited! IOW, the real constraint at the state level is "!(substate = draft)".  This is fine today, BUT tomorrow the number of substates will change (they have done more than once already).

So, neither rendition ( subState--> state, or state --[Condition]--> state )is really giving me much joy.  

Any "good practice" advice? (Apart from the obvious, I lack both the flexibility and the plumbig tools.)  

bruce

[Paolo F Cantoni]

Hi bruce,

As I understand your problem, you need to decouple the guard that controls the transition from the current set of business rules, yes?

Why not do that?

The guard condition is named: isAllowedToTranstionFromProposedToActive

and the definition of what that means is held elsewhere.

If you're happy, in principle, with this solution, we can discuss where the detail should be kept...

HTH,
Paolo

[mikewhit]

One way would just to be to drop the concept of 'substate' in this context, and make 'draft' etc. states all on same level.

Then you could arrange all the transitions as you wished.

Probably merge 'ready' into 'proposed'.

Any easier ? Or does this thwart some other requirement?
Obviously it moves the issue round a bit.

Alternatively, just insist that substates of 'proposed' have to made 'ready' before they can become 'active' (etc.) - which makes a kind of sense since if they aren't 'ready', then ... they aren't ready.

I would have thought that one of the principles of having such a flow at all was to ensure that items were reviewed in some way before making a transition, hence readiness is a required condition to exit 'proposed'.

PS. "A nested sequential state diagram may have at most one initial state and one final state"

[«Midnight»]

Love it Paolo!

Now you could implement a «businessRule» class somewhere to reify the logic of the transformation.

David

[sargasso]

Hmm, all input gratefully acknowldged.

As I understand your problem, you need to decouple the guard that controls the transition from the current set of business rules, yes?
 
Why not do that?

Probably just sheer paranioa, hence the post, but

"A nested sequential state diagram may have at most one initial state and one final state"

, which is fine, but... 'tween the one(0001) intital state and the one(0001) final states, there exists an infite(&FFFF) set of occurences where we are somewhere twixt initial and final states (inclusive).

I think I'll go backand read the 1.5 spec and see if theeze wuz seemple then,  ... back shortly.

bruce

[sargasso]

implement a «businessRule» class somewhere to reify the logic of the transformation.

Yep! that is - (more or less) exactly - the requirement, wish I could have put it so succinctly!

bruce

[«Midnight»]

Yep! that is - (more or less) exactly - the requirement, wish I could have put it so succinctly!

bruce

And you will - which will be the model, of course.

But that still leaves:

...there exists an infite(&FFFF) set of occurences where we are somewhere twixt...

That would be the code.

Resolving this brutal dilemma is left to the reader as an exercise. [he said, gracefully copping out of the way]

David

[Paolo F Cantoni]

Love it Paolo!

Now you could implement a «businessRule» class somewhere to reify the logic of the transformation.

David

Couldn't (and didn't) put it better myself...  

Remember: modelling is arty farty and of no practical use whatsoever...

Paolo