(FC-Devel) RE: Features & diagrams

[duane.griffin@paradigm.co.nz]

Hi Andrezej,

> 2. Lately I have read some materials about UML. As far as I have noticed
> you plan to be as UML correct as possible. Personally I am disappointed
> with UML. Of cource it uses a buzzword "Object orientation". But it does
> not provide certain elementary tools needed for development. I would
> prepare the following list of such tools. standard object oriented
> diagram state-transition diagram requirements tracking (at later stage)
> requirements association with CASE objects (at later stage).

I am a little confused as to what you mean by standard object 
oriented diagram. UML has got standard class diagrams showing 
inheritence, aggregation, etc., etc. Which type of diagram did you 
mean? What sort of things would be represented on it?

>  - differentiation of key and non-key data (in a meaning of Entity
> Relationship Diagram - I have found it in no CASE object diagram  !!!)
> on Object/Class Symbol,

First, sorry if I am telling you what you already know, but OO 
designs do not necesarily map particularly well to relational 
databases. Not only do OO models not usually distinguish 
between key and non-key data, they may not actually have 'key 
data'. Each instance of a class (object) is usually considered to be 
a distinct, individual entity, even if they have exactly the same data.
Links to other objects are represented directly, not using foreign 
keys as would be typical in an ERD.

>  - differentiation of inheritance (commonly used),

Do you mean differentiating between public, private and protected 
inheritence? If so then I think that UML may already have it, Booch 
certainly did.

>  - balancing of message data elements/attributes with
> minispecification of service and Object/Class data elements/attributes

That would be a very useful sort of feature to have, and maybe you 
could also tie it in with code generation/reverse engineering in 
terms of checking assumptions, doing semi-automated design 
validation, etc.

>  - generation of Entity-Relationship Diagram (???)
>  - generation of Data Flow Diagram (???)
>  - generation of inherited keys for data (ref to Entity Relationship
> Diagrams)

I am not sure how you would go about mapping a class diagram 
(etc) to ERD & DFD diagrams, or why you would want to 
particularly. You might be able to generate ERD diagrams by 
mapping data elements to fields, adding seperate entities for each 
sub-class, generating & linking to keys automagically (64 bit 
random numbers generated upon object creation? Some 
combination of process specific info, unique class name & time 
stamp?). DFD diagrams could be one process per method I guess, 
data stores and external entities being objects, data flows 
representing the sources of information used in methods. Not all 
this info (especially the data flows that weren't parameters to the 
method) would be accessable though. I'm not sure that doing this 
sort of thing would be good in general, as you would be mixing two 
quite different design processes, with confusing and lossy results.

> - assigning of decomposition hierarchy: class/object --->
> State-Transition-Diagram (useful for oject life cycle, switching
> systems, message processing etc).

That sounds very useful.

>     class/object ---> Class/Object diagram (I have not
> used it yet but I see that I could do it for certain decomposition of a
> system)

Sorry, what is the difference between these two diagrams?

>    state ---> state transition diagram

This would be a very useful decomposition to have.

>    state ---> Class/Object

Hmm, if by Class/Object you mean an object interaction diagram, 
then I would certainly agree. I forget what they are called in UML, 
isn't there a couple of types of them?

Cheers,
Duane Griffin.

Duane Griffin
Paradigm Technology Limited
Phone +64-4-495-1010
Facsimile +64-4-499-7762
Level 13, Paxus House.
79 Boulcott Street, Wellington.
NEW ZEALAND