rayb
asked on
OOAD: Reference and Educational Materials
I've been programming for nearly 17 years now, and have up to now been able to get away with performing very little analysis work and my designs have always come to me during experimentation and prototyping. Most of my applications up to this point have been rather trivial in size and complexity. I now find myself being moved into roles of greater responsibility for the overall analysis, design and management of larger and more complex projects.
I've started reading about object oriented analysis and design techniques and it seems like a great methodology to adopt, however where are the tools? Rational Rose had the Microsoft Visual Modeler included in the latest rev of Visual Studio, it has a lot of great features, but it doesn't seem stable enough to rely on for large projects.
So what I need is some pointers to online educational materials (or actual books) regarding the ooad process as well as some pointers to excellent ooad applications. Freeware would be ideal, (I don't think I'll be so lucky) but a fully functional demo would be great too. I'd like to mostly hear from anybody who is in a role similar to what I described above, however any input would be great.
Thanks,
-Ray
I've started reading about object oriented analysis and design techniques and it seems like a great methodology to adopt, however where are the tools? Rational Rose had the Microsoft Visual Modeler included in the latest rev of Visual Studio, it has a lot of great features, but it doesn't seem stable enough to rely on for large projects.
So what I need is some pointers to online educational materials (or actual books) regarding the ooad process as well as some pointers to excellent ooad applications. Freeware would be ideal, (I don't think I'll be so lucky) but a fully functional demo would be great too. I'd like to mostly hear from anybody who is in a role similar to what I described above, however any input would be great.
Thanks,
-Ray
A good book is "Object Modelling Technique"
from James Rumbaugh.
Look also for articles and books from Grady Booch and Edward Yourdon.
These three guys are the gurus in OO and the fathers of UML.
from James Rumbaugh.
Look also for articles and books from Grady Booch and Edward Yourdon.
These three guys are the gurus in OO and the fathers of UML.
my 2 cents :)
I was in your shoes a few years ago, moving into OOAD with OMT (prior to UML). I have probably about 120 hours of instruction on OOA, OOD and applying C++ to OMT.
We sort of created a hybrid model to fit our needs. If you follow OOA/OOD to the n-degree..you will have spent many many months doing conceptual design and modelling. We found that was too much with business needs/desires. Doing a good object model and then prototypeing it was the way to go..and interate the model from there. Also doing the object interaction diagrams was very useful to develop methods and attributes.
You also have to be careful of your implementation model. For examlpe VB does not support inheritance directly (though you kindof kludge it)..so a true object model would not fit.
C++ with COM had similar problems...you do thing more by aggregation/delegation (but that is changing with COM++).
I guess my bottom line advice is: Don't get too wrapped up in performing the pure tasks with appying reality check, you can iterate forever on an object model..cause there never is really a true correct way to do them.
I was in your shoes a few years ago, moving into OOAD with OMT (prior to UML). I have probably about 120 hours of instruction on OOA, OOD and applying C++ to OMT.
We sort of created a hybrid model to fit our needs. If you follow OOA/OOD to the n-degree..you will have spent many many months doing conceptual design and modelling. We found that was too much with business needs/desires. Doing a good object model and then prototypeing it was the way to go..and interate the model from there. Also doing the object interaction diagrams was very useful to develop methods and attributes.
You also have to be careful of your implementation model. For examlpe VB does not support inheritance directly (though you kindof kludge it)..so a true object model would not fit.
C++ with COM had similar problems...you do thing more by aggregation/delegation (but that is changing with COM++).
I guess my bottom line advice is: Don't get too wrapped up in performing the pure tasks with appying reality check, you can iterate forever on an object model..cause there never is really a true correct way to do them.
ASKER
In response to rmichels...
This is good advice...
Perhaps as I continue reading the materials that I have, this will become apparent, but, how do you know when you've analyzed and designed enough? I'm sure there is no RIGHT answer to this question, but still, how do you know when you've designed far enough? If you go only half way then your developers may follow your poorly thought out design and wind up painting themselves into a corner. Then on the other hand, if you take it too far, the developers may consider you to be too oppresive and stiffling their creativity.
-Ray
This is good advice...
Perhaps as I continue reading the materials that I have, this will become apparent, but, how do you know when you've analyzed and designed enough? I'm sure there is no RIGHT answer to this question, but still, how do you know when you've designed far enough? If you go only half way then your developers may follow your poorly thought out design and wind up painting themselves into a corner. Then on the other hand, if you take it too far, the developers may consider you to be too oppresive and stiffling their creativity.
-Ray
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Took me awhile to look through those titles, but they are quite good. Thanks.
-Ray
-Ray
ASKER
-Ray