Hi Bob,
The intention of the current implementation is to allow the user to go from
a [non-concurrent composite state] to a [concurrent composite state] and
vice versa by adding or deleting regions.
IMHO this is a nice feature - the user often draws a composite state with
various contents, then discovers that he needs concurrency.
IIRC, if this does not work anymore, then that is regression.
PS: I will not be able to read email until Sunday night.
Regards,
Michiel
----- Original Message -----
From: "Bob Tarling" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, May 02, 2008 11:44 AM
Subject: Re: [argouml-dev] There have to be at least two composite substates
in a concurrent composite state.
Okay, I'll continue the enforcement but manage it elsewhere. I simply
had no view of my own as I'm not so familiar with usage of this
diagram.
Should I enforce as it tries to at the moment or should I also enforce
so that there is never zero composite states.
e.g. On creation of the composite state automatically create 2 inner
composite states and refuse to delete inner composite states if there
are only 2 left (or an attempt to do so deletes the parent). Which is
best or still allow zero?
Bob.
2008/5/2 Michiel van der Wulp <[EMAIL PROTECTED]>:
Hi Bob,
> The well formedness rule - "There have to be at least two composite
> substates in a concurrent composite state" - seems to be enforced by
> the application rather then by crtics.
>
Yes, the WFR for 2 regions in a concurrent state is enforced.
This to make it transparent for the user. The user is kept unaware of
the
regions as separate entities in the UML model.
BTW: Otherwise it would be very hard to implement: How would ArgoUML
have
to react if there were only one? Think about the common user's usecase of
drawing regions.
We (the creator of concurrent states and me) decided on this strategy to
reach a solution that is user-friendly (and implementable).
> It surprised my to find that the button to create a new Concurrent
> Region on a Composite State actually creates 2 if there are currently
> zero.
>
Yes, that is a consequence of this line of thought.
> So should I make my job easier by removing the enforcement of this
> rule or should I make this enforcement better by managing it in the
> model subsystem?
>
Please, improve this enforcement.
This one is for usability.
> The enforcement doesn't fully enforce as it currently allows zero
> composites, is that good or bad? Possibly it's a balance between
> enforcement and critics?
>
Err.. that must be a bug. How did you do that?
Please note that the former checkmark for concurrency on the composite
state proppanel is intentionally removed!
I see some simularity with swimlanes in an activity diagram, but there
the
pool is not drawn first (and independently), so it differs.
Regards,
Michiel
----- Original Message ----- From: "Bob Tarling" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, May 02, 2008 3:03 AM
Subject: [argouml-dev] There have to be at least two composite substates
in
a concurrent composite state.
>
>
>
> The well formedness rule - "There have to be at least two composite
> substates in a concurrent composite state" - seems to be enforced by
> the application rather then by crtics.
>
> As you probably know its my opinion that we should seek some balance
> to enforce or hint different rules where it really aids the user to
> get the design right first time.
>
> So here is one to discuss.
>
> It surprised my to find that the button to create a new Concurrent
> Region on a Composite State actually creates 2 if there are currently
> zero.
>
> There is also the nasty hack to delete the remaining one if we get
> down to just one (that probably won't work under all circumstances).
>
> So should I make my job easier by removing the enforcement of this
> rule or should I make this enforcement better by managing it in the
> model subsystem?
>
> The enforcement doesn't fully enforce as it currently allows zero
> composites, is that good or bad? Possibly it's a balance between
> enforcement and critics?
>
> Bob.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.23.7/1409 - Release Date:
> 1/05/2008
8:39
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.7/1409 - Release Date: 1/05/2008
8:39
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
