Re: Know any good OOA/D book

On Nov 23, 2:24 pm, "A.G.McDowell" <mcdowe...@xxxxxxxxxxxx> wrote:
In article <cIWOGgi2d1Id-pn2-ES3E8kcS9O5q@ecs1>, Lee Riemenschneider
<newsu...@xxxxxxxxxxx> writes

On Sat, 22 Nov 2008 16:34:53 UTC, Daniel Parker
<danielapar...@xxxxxxxxx> wrote:
On Nov 20, 4:24ÿpm, "Lee Riemenschneider" <newsu...@xxxxxxxxxxx>
wrote:
On Thu, 20 Nov 2008 18:27:24 UTC, "and.wyso...@xxxxxxxxx"<and.wyso....@gmail.
com> wrote:
I wish to learn OOA/D and am looking for a few good books that are
covering the basics of the subject.
Also looking for something about the Shlaer-Mellor methodology.

(trimmed)

Anonymous opinions aren't a good source for choosing a technology.
Read some books or papers; if the technology interests you, try it
out. Get some advice from discussion groups, but be aware that
discussion groups targetting the technology are more likely to have
experts and less "I tried that ONCE and discarded it because it wasn't
a silver bullet" opinions without rebuttal.

I wish that wasn't so. I wish that we knew enough about software
development that I could state a claim about it and people competent in
the field could confirm or dismiss it regardless of background, as if it
was a mathematical proof. Oh well.

"Agile Software Development", by Robert C. Martin, does a pretty good
job of defining and justifying a number of principles which are common
to O-O technologies regardless of development methodology.

Agreed. A number of good books have been recommended in this thread,
but as it's often better to start with one, this would be a good
choice for the OP.

I second the advice given elsewhere to acquire language specific advice.
If your language is Java (and perhaps if it is not) then "Effective
Java", by Bloch will be immensely valuable to you.

I also heartily agree with the recommendation of "Writing Effective Use
Cases" by Cockburn. Actually, this will tell you virtually nothing about
O-O as such, but that's not the point. It will tell you an enormous
amount about gathering, communicating, and analysing requirements. If
you ever got what you wanted and then found that it wasn't quite what
you needed, in any field, you need to read this book.

Also agreed.

I have been aware for some time of projects that have used Shlaer-Mellor
and executable UML. I talked to an area that has been touted as one of
the success stories of one of the commercial products in the area, and I
have (independently) heard a technical sales talk from the company
selling this a tool. Serious use of this tool requires you not only to
use UML as a programming language, but also to rewrite or extend what
amounts to a compiler to suit the needs of your particular project. The
resulting overhead is bearable only in special cases (such as if you can
persuade a government to pay your development costs).

In my areas - finance, telco - I've never heard of any projects that
used executable XML, and since this is 1990's hype, I don't think I
ever will. Within enterprises, there is a big wish to move away from
custom coding to tools and standards, but executable XML is nowhere in
the picture.

-- Daniel


.

Quantcast