(FC-Devel) RE: Features & diagrams

[duane.griffin@paradigm.co.nz]

> > 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?
> 
> --------------------------------------------------------------------------
> -- -----------------------------------------------------------------------
>     I mean something like Coad-Yourdon diagram
> which I have found most useful for my purposes.
> 
> --------------------------------------------------------------------------
> -- -----------------------------------------------------------------------

Wouldn't this be equivalent to a normal static class diagram? I 
forget the proper term for them. Thats the one showing classes, 
inheritence, aggregation, etc. I can't remember them both well 
enough to list all the things that might be different, but I think 
subject areas & messages might be two? I think that subject area 
type delineations might be able to be made in other UML models. 
For that matter it is often nice to have a number of diagrams, each 
one concentrating on a specific area (i.e. a subject area). You can 
put the same object on different diagrams, so you would put them 
on inter-related diagrams at a high level of abstraction to show 
linkage. As for message passing, that is covered comprehensively 
in different UML models (the dynamic object models, from memory).

Damn, I should really try to download a UML spec! If anyone else 
is interested it looks like you can get it from here: 
http://www.rational.com/uml/index.jtmpl

> --------------------------------------------------------------------------
> -- --------------------- In practical application I prefer to have my own
> key designed for the object/process of the application. In database
> application it makes life easier while genereting Entity-Relationship
> diagram (feature supported by System Architect Case and strictly speaking
> (or writing) quite useful.
> 
> But I agree that it might be my personal feeling.
> --------------------------------------------------------------------------

Hmm, yes I guess it would certainly be useful if you had to 
translate your class design into a RDB format. It's not something I 
have really needed myself, but what do other people think?

> > 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?).
> --------------------------------------------------------------------------
> -- ----------------------------- Sorry I am afraid that it would not work
> in database design and it would not be a good solution in a couple of
> cases of cooperation processes design (for example telecommunication
> applications - SSN7 etc.)
> --------------------------------------------------------------------------
> --

You mean the ERDs & DFDs generated would be far from optimal? 
I think I would agree with you :) Do you think that it is possible to 
get a good generic ERD & DFD generation routine without 
embedding database specific info like key definitions into the OO 
design? We could have a stab at it, but I would vote to put it on the 
post v1.0 list myself. It would be interesting, but could get tricky. 
Of course if we were embedding key info, etc. that would be a 
different story...

> Sorry, what is the difference between these two diagrams?
> --------------------------------------------------------------------------
> -- --------------------------- Not diagram into diagram but class/object
> into diagram.

Right, but how would that be useful? Classes can't generally be 
decomposed into class diagrams in my experience. AFAIK UML 
doesn't support it, and neither do many (any?) other major OO 
methodologies. IMHO that is one of the problems of OO design, it 
doesn't lend itself to a hierarchical structure terribly well. What 
would the benefits of such an approach be, and what would it 
actually mean to say a class decomposes into this set of classes, 
relationships, etc?

> P. S.
> I must write that it is very interesting to discuss things with people
> with different experience. I must rethink some your comments.

Yeah, I agree. I haven't had that much ERD/DFD modelling 
experience, and none with mixed ERD/DFD & OO designs.

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