[Uml-devel] bug

[Jonathan Riddell]

> > > > I have never seen such a thing in UML books. Do you really think this
> > > > is necessary? I mean if it is possible to have multiple transition, why
> > > > is there fork/join/branch/merge?
> > >
> > > well... the forj/join is a different beast: those are to represent
> > > different threads of execution --> to go to activities which are supposed
> > > to happen in "parallel" (fork) or to synchronize the execution at the end
> > > of two activities (join)
> > >
> > > s for branch/merge.. yes.. I suppose you are right:
> > > All you can achieve with multiple transitions can be represented with a
> > > branch (actually, I think this is the clearer way to do it).. I just
> > > think that having the transitions directly from the activities could save
> > > some work.
> > >
> > > UML says that activities can have more than one outgoing transitions as
> > > long as they are differentiated by conditions (if [condition a]
> > > transition 1, if [condition b] transition 2, else transition 3 )
> > > which is precisily what branches do ... again, it would be only for
> > > convencience... but it's up to you if you want to accept this.
> >
> I think it was no good idea to allow multiple outgoing associations from an
> activity. I've never seen this in any literature, but what I've seen is that
> an object is used inside an activity diagram which transports information
> from one to an other activity. But we haven't implemented the occurence of an
> object in an activity diagram, so we should not allow multiple outgoing an
> ingoing associations from and to activities. I think, the idea of the
> singularity of associations is well founded. The designer should use the
> branche/merge and fork/join elements to model. Otherwise you have no
> mechanism to check in what case you use the one and in what case you use the
> other association.

Do you have an opinion on multiple outgoing associations in state
diagrams?

Jonathan