Re: Activity diagram



Date view Thread view Subject view Author view Attachment view

From: Martin Jung (Martin.Jung@informatik.uni-erlangen.de)
Date: Thu 13 May 2004 - 10:32:25 BST


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.

Best regards,

Martin Jung

-- 
Martin Jung

PGP public key ID: 0x3F2D0402. http://www.keyserver.net

Date view Thread view Subject view Author view Attachment view