Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - kenty

Pages: [1]
1
Uml Process / Re: Showing synchronous I/O on state diagram
« on: May 11, 2007, 08:46:43 am »
Quote
Suppose I have a class which is in one of two states: "Waiting" and "Processing".  In the "Waiting" state, it is waiting for a synchronous I/O to complete (for example, it has called Windows "ReadFile" or socket library "Accept").  When the I/O completes, the call returns, and the object transitions to the "Processing" state, where it completes processing, and calls the I/O again, jumping back to the "Waiting" state.

How would I show this on a state diagram?  There doesn't seem to be an state transition corresponding to a "Return from Call".


jeshaw2 is right, have substates, ie "Ready", "Waiting" and "Processing".  The triggering event between "Waiting" and "Processing" are "Received Data" for when the system call returns and currently another triggering event called "Data Processed" which transitions from "Processing" to "Ready" when the processing is finished.  What you will find is that the "Data Processed" triggering event will probably have conditions (different triggering conditions, ie a boolean) and thus more substates are required (eg bad data, etc).  "Return from call" is simply modelled as a triggering event.

2
Uml Process / Re: Triggering events should be avail to all child
« on: December 26, 2006, 06:13:27 am »
Quote
Well, this is certainly a "horse of a different color". :)  I cannot speak with any authority on EA, there are others here in the forum better qualified than I.

However, I think your concern is more with with EA's unique interface than its interpretation of the UML2.1.  From what I can determine, the project browser is more concerned with the arrangement and distribution of UML diagramming elements than it is with the true anatomy and structural topology of an object.

I'll leave it to others wiser than I to continue with this thread.  Sorry I can not  be of more help.



This is about their intepretation of the UML specification and their intepretations of statecharts and not about their user interface.  The reason being that both TriggeringEventC SendSignalAction are different entities that is not common to the entire model.  In theory they should be exactly the same but in reality they are TriggeringEventC and State2.TriggeringEventC.  This makes traceability and triggering event usage problematic.

I know they are different because when I set a note on one of them, it is not reflected in the other.  This is because EA stores them as separate SendSignalAction in the database.  They should really be stored in the "parent" nodes (look at the diagram, I'm talking about the tree that the elements are stored in) and be made available to "children" nodes.  They should be "propagated" up if another "sibling" branch or parent branch should use the triggering events.  This would mean global triggering events would propagate upwards to the root node and be available to "children" nodes.

There are benefits to this approach.  For one, you are not repeating yourself.  Remember one of the basic principles of good coding, do not copy and paste.  Surely this applies to design and modelling.  Second, you will be able to have an inventory of events that affect the model in the correct place in the hierarchy of nodes.  Lastly, because of the above, it would make automation tasks a lot easier.

3
Uml Process / Re: Triggering events should be avail to all child
« on: December 24, 2006, 09:48:28 pm »
Quote
First off, the terms parent, sibling, child states are confusing to me as there are no generalization/specialization relationships involved in statemachines.  If, in your diagram, states A and B are nested in state C, then state C (according to Harel) is an abstraction of the paired states A and B, not a generalization of them.


Sorry, we got mixed up about child/sibling/parent relationship.  The usage of those terms is made in reference to how the state "ownership" relationships are ordered in EA in the Project Browser.  See the image below:



OK, I should have uploaded this image ages ago.  The problem that I have is that I feel that "TriggeringEventC" should be the same for the entire statemachine.  However, you cannot have substate machines access SendSignalAction that are in "parent" namespaces.  In this case TriggeringEventC exists in the State2 namespace AND the overall statemachine namespace.  Since I intended them to be the same triggering event, I cannot see why they cannot be the same SendSignalAction.

I hope this clears this up.


4
Uml Process / Re: Triggering events should be avail to all child
« on: December 21, 2006, 08:49:16 pm »
Quote
What makes them "exact"?  How can the "exact" same thing be in more than one place at a time?  By what method are they cloned?  I assume you have declared them as a signaling action in the various locations yourself?


OK, I'll make a clearer example.  Lets say I have a submachine state A that is part of a bigger statemachine.  This submachine state A has multiple concurrent regions A1 and A2.  Each of these has a submachine state.  The submachine states in each of these regions all respond to a "poll" triggering event.  They are concurrent regions because they are different subsystems.  Now, when this "poll" triggering event is created in the submachine state A's namespace, it is unreachable in concurrent region A1 and A2.  If I create the "poll" triggering event in the submachine states in the concurrent region, they are two different triggering events.  I can drag them "up" into submachine state A's namespace, but they are still different triggering events.  They are technically the same event but have different "instances".

Even if we did not have concurrent regions, if we have a triggering event named "poll" within a statechart, then all state transitions that are triggered by a "poll" triggering event should reference the same triggering event.  There is no reason why they should be different.

Quote
Used in what way?  Is the poll event signaled in all of these places?  What do you mean by the term "used"?  Do you mean "signaled" or "received"?


When I used the term "used", I meant that the triggering event was the trigger for a state transition (e.g. event[]/action).  Does it matter if the "poll" triggering event is signalled in all of these places?  Some subsystems in a concurrent region do not care about the "poll" triggering event and therefore do not have a state transition with the "poll" triggering event.  They therefore ignore it.

Quote
Created by whom?  If my understanding of the above is correct,  each of the "poll" triggers are in a different namespace?


This is the problem.  Should the triggering event's in a higher "namespace" be available in children "namespace"?  I say they should be available to all children "namespaces".

Quote
Created by whom?  How would EA know that if they are in different name spaces?


Namespaces should only prevent access to triggering events from different sibling branches, but not prevent access to triggering events from parents.


Quote
So you are asserting that substates inherit from parent states in a manner similar to class inheritance?  If you are saying  they should be created once in the parent, why haven't you done that?


There is no suggestion of "inheritence".  Tried creating triggering events in the parent, it doesn't work.  Triggering events created in a higher namespace do not appear in the triggering event list in a state transition specification in children namespaces.

5
Uml Process / Re: Triggering events should be avail to all child
« on: December 21, 2006, 03:40:35 pm »
The questions are: why does EA Model not do this and should it do this the way I have outlined.

6
Uml Process / Triggering events should be avail to all children
« on: December 20, 2006, 12:09:26 am »
The exact same triggering events are repeated in the statechart diagrams in EA Model.  For example, I have a "poll" triggering event that is used heavily in my model as a triggering event for transitions in different part of the model.  My model is a complicated model with many substate machines and concurrent regions.  However, within each substate machine, this "poll" triggering event is created as its own SendSignalAction.  This is the SAME event in the system created MULTIPLE times.  These should be created ONCE in the parent hierarchy and available to all children substates because the same event is triggering transitions throughout the entire system.  The SendSignalActions should also be usable by any state transitions even if it is dragged from a child substate machine into a higher parent substate machine.

7
Uml Process / Re: Should transition actions be able to create ev
« on: December 23, 2006, 06:24:03 am »
Quote
Statemodel newbie statement. :)  Isn't this question upside down?  ???

If a machine behaves according to a state model then aren't events the things that drive the transitions? Shouldn't the model respond to events rather then invoke them?

or did I miss the point.

bruce


You are correct that state machines respond to events but you missed the point.  I am talking about state machines generating events and what the consequences are.  The notation for a state transition is e [ b ]/a where
e = triggering event
b = boolean condition that must be true for the transition to take place (optional)
a = the action or activity to perform

According to Harel, a can be a single or multiple triggering events.  This is so that one part of the statemachine can affect the other.  This makes it easy for one concurrent region to affect another due to a response to certain external triggering events.  The danger being a really bad inifinite loop, which would mean the system would never settle into a state.

8
Uml Process / Re: Should transition actions be able to create ev
« on: December 22, 2006, 10:02:23 pm »
Quote
What about events which are external to the object being modeled?  EA would not necessarily be aware of those even though the subject model responds to them.


Sorry, I am not entirely sure what you are talking about.  If you mean: what about about external events causing an infinite loop because the originator of the external event responds to the reciprocal event.  Then yes, this is a problem.  

My solution to this is to make the statechart model larger so that it encompasses both systems in concurrent regions.  In the first concurrent region you have the statemachine that you are modelling/implementing.  In subsequent concurrent regions, you have the other statemachines that interact with your system.  These will be approximations based on your understanding of these systems, to be refined as you interact with it in real life.  Therefore instead of modelling your statemachine, you will also model its interaction with outside systems.

This solution may seem far fetched, but I see no reason why statecharts cannot model the "world" so to speak.  Technically speaking, the external system and the system you are modelling can be considered a single "system".

9
Uml Process / Should transition actions be able to create events
« on: December 20, 2006, 12:04:34 am »
According to Harel's original paper, the action that forms part of a transition can be a triggering event for another part of the system (pg 256 of "Statecharts: A visual formalism for complex systems").  This means that if a transition is occuring, the transition can generate triggering events to affect other parts of the system.  Extreme care must be taken so that infinite loops DO NOT occur because of this.  

An example of an infinite loop is shown below:



In this diagram, as soon as either eventA or eventB is triggered there will be an infinite loop.  This is because the triggering events generate the other triggering event as part of its transition action, which in turn affects the other concurrent region.  This very simple example is obvious to the naked eye, but cannot be detected using current automated tools.  Worst still, this may occur in more complicated projects which have many states, concurrent regions and triggering events.

EA Model only has a textual description as part of this field.  Perhaps this should be converted into a list of events so that we can accurately model this.  This is so that we can accurately tell where each triggering event is used.  Once we have this relationship then we can check for the above mentioned problem because we can then check for never ending event generation within the statechart.  This in itself is very useful because obviously an infinite loop as shown above is erronous and will cause extreme problems in an implementation.

10
Uml Process / Re: Many Initial States in Concurrent state machin
« on: November 12, 2006, 10:30:36 pm »
Received a reply from Sparx.  This is identified as a defect and will be addressed at some point.

11
Uml Process / Many Initial States in Concurrent state machine
« on: November 08, 2006, 07:43:07 pm »
When I validated a concurrent state machine I received warnings that having more than one Initial States were a statechart violation.  It accepted the first initial state but considered the rest as violations.

According to the UML standard: "A region can have at most one initial vertex." (pg 569 of ptc-06-04-02 - 2.1 Superstructure.pdf).  Since a concurrent state machine has multiple regions, we interpret this as: "A concurrent state machine has multiple regions, each having at most one initial vertex."

The book "UML 2.0 In a Nutshell" also supports this interpretation (Fig 8-8, pg 92).

Can the validation be fixed to recognise this part of the UML specification.

12
Uml Process / Trigger missing child element: Event
« on: November 08, 2006, 08:02:24 pm »
When I validate my statechart diagram, I get the following warning which I do not understand:

MVR020001 - warning (disconnected (Trigger)): disconnected is missing required child element: Event

Can anyone shed any light on what this actually means?  The transition in question just has a signal trigger called "disconnected".  If it is missing any other important specification than I'd like to know what because it seems to be a well formed UML transition.

Pages: [1]