Re: Activity diagram

Date view Thread view Subject view Author view Attachment view

From: Shashank (
Date: Fri 14 May 2004 - 06:11:07 BST

Hello Martin,

Martin Jung wrote:

> Hello all,
> Chris Britton wrote:
> [...]
> > There is nothing stopping an activity diagram being used at either the
> > business object level (to analyze business processes) or at the
> > implementation level. When doing analysis at the business object level
> > you should probably ignore the physical flow of objects around the
> > system. When doing activity analysis at the implementation object level,
> > the objects don't move. So in either case, activity diagrams don't need
> > to show object movement.
> As the UML specification puts it (UML 2.0, omg ptc/03-08-02) an
> ObjectFlow models the flow of values to or from objects. Im my opinion,
> this is only a specification of a logical data flow, which should be
> part of any software design, regardless of the level of abstraction.
> Stating that from a certain activity there exists data flow to an
> abstract object (however it may later be realized) or stating that from
> such an object there exists data flow to a certain activity does not
> involve movement of objects - however realized - but movement of
> information.
> If I understand your notion of business object level/implementation
> object level correctly, you would want to show information flow in the
> activities and therefore use object flow.
> The UML 1.5 specification has a definition of object flow that sounds
> like real (ohysical) objects being moved around, but I still think that
> only data flow/ information flow is meant.
> In summary, I would understand the activity data flows as a model of
> information flow, regardless of how this is later realized, be it using
> CORBA objects passed around or be it using serialized forms of data sent
> from A to B.
> > I suggest that what's missing in UML is the concept of levels of design
> > and the ability to show how objects at one level map to objects at
> > another level. Although I called them implementation objects they too
> > still map to multiple objects - an object in the database and probably
> > an object in every tier.
> If you mean different levels of abstraction by levels of design I would
> agree that the support of UML could be better.
> One can use the UML to model different levels of abstraction, but the
> mappings or rather the transformation rules between the different levels
> are still hard to model in UML itself.
> MDA probably takes the steps in the right direction in building high
> level models and tranforming these by stepwise refinements to models
> very close to the implementation.

Should not Swimlanes be used effectively, in Activity diagram, to handle, with
may be a small note attached in the scenario mentioned.

Cause seems like showing an object (being used or passed :may be an abstraction
but actually data encapsulated getting passed) is an distraction while modeling
an activity?

I agree we can always find some scenario, wherein showing an object flow is an
easy an obvious way to enable understanding in an intuitive way.

But another interesting question is "Is there any tool, analysis tool may be,
where we can feed class model and activity diagram for analysis to figure out
design flaw or something missing?". Like in Activity diagram showing an object
flow, but in class diagram no relationship is mentioned among the classes
involved in that particular activity.

> Best regards,
> Martin Jung
> --
> Martin Jung
> PGP public key ID: 0x3F2D0402.
> To remove yourself from this list please mail
> with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view