Says Fowler (p. 132): "Forks and joins must match. In the simplest case, this means that every time you have a fork, you must have a join that joins together the threads started by that fork. (This rule comes from the fact that the activity diagram is presently a form of state diagram)." There are two points I am missing here, and in particular wrt the phrase in bold: (1) How can we view an activity diagram as a form of state diagram? There are so many syntactic differences, let alone the semantic ones. (2) presently? What does "presently" mean? Is it that activity diagram won't be a form of state diagram at some point in the future? Maybe I'm totally missing the point. I would appreciate it if somebody could shed some light here. Thanks, Panagiotis.
Panagiotis , Activity Diagrams refer to "what needs to be done first".This means you are finding out parallel processes in your system.While doing this you are informing which activity or real-world process is being performed.This is nothing but the "state of doing something".This would be a starting point for your to draw a more-detailed state diagram. When you show "Receive Items" at an activity, it is in some state presently.After sometime the state of this activity may change to "Item Received". Hope this helps, Sandeep
posted 19 years ago
Panagiotis, I am not convinced by the explanation I gave in my previous post.Am trying once again.Please let me know your views on this. (1) How can we view an activity diagram as a form of state diagram? There are so many syntactic differences, let alone the semantic ones. Activity Diagrams is a variant of State Diagrams.In State Diagrams we talk in terms of state of an object, where as in Activity Diagrams we talk in terms of state of System as a whole.In both State Diagrams and Activity Diagrams, we show states in the box(ellipse or whatever!). There is one interesting fact about State Diagrams.A State may or may not be associated with an activity.For example the Waiting, Cancelled or Delivered states in Figure 8-2 does not have an associated activity with it.Transition to these states takes place when an event associated with an action is triggered. Also, the State Diagram in Figure 8-5 shows concurrent(parallel) states for an object.The superstate which contains the associated substates ensures that there is one starting point (fork) from it.When all the substates transitions are complete, it meets the other end of the boundary of the superstate (join).After the concurrent substates meet at the join, the Order can only be in one state.This diagram has marked resemblance with the Activity Diagram shown in Figure 9-3 where you have a fork which is a starting point of two concurrent processes and a join which is the end of the concurrent process. (2) presently? What does "presently" mean? Is it that activity diagram won't be a form of state diagram at some point in the future? You are right - Sometimes, Activity Diagrams may not be a form of State Diagrams.Martin mentions about some exceptions, just after the quote you picked up from the his book. The most noticeable exception is to the rule that the join marks the end of all incoming states.In Activity Diagrams, this means if a fork has a Conditional Thread which evaluates as false, this thread has to be considered as finished as far as the join is concerned,although that thread has never been executed.Thus a conditional feature in Activity Diagrams disallows a parallel process to occur.Unlike Activity Diagrams, the State Diagrams doesnot have a Conditional Thread feature specified by guard, by which it can disallow a concurrent process.It is in this respect, State Diagrams may differ Activity Diagrams. Hope this makes sense. Thanks, Sandeep [This message has been edited by Desai Sandeep (edited June 02, 2001).]
Paper jam tastes about as you would expect. Try some on this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop