>>but I am creating an object model (because I don't seperate data from code) and in the end I get both ,
>Yes, but IMHO u start from what seems to be more close to a
>logical data model. I just re-looked the first 4 diagrams of
>your lecture, and they remind me more a ER diagram than a
>OOA one.

I know I said I will not react to this - but decided it would be more fun of I would :)

I know the diags. in the lecture look more like ER diagrams than any OO notation - and there is a simple reason for that, I used a traditional
case tool to draw them - that doesn't change the idea the diags represent
look at the following fig. u see there an excerpt from one of the figures in the lecture and its representation in 3 notations, most other methodologies express it with similar notations as well (e.g. using Martin-Odell notation will look a little different - but I don't know too much about thier methodolegy)
this way the transition to the underlying RDBMS (VFP) is easier

I did not discuss OLH (Object Life-History) diagrams as these are used
when creating the "frame-work" of base/project base reusable classes (maybe this is a matter for another lecture :) )

dooing OOAD instead of traditional AD is better IMHO,because u get both
a good idea on the DB structure and relation and a good idea for
the prototyping

Arnon