Re: Object Oriented Analysis

I would strongly recommend Michael Jackson's "Problem Frames" as a counterpoint to the below - not that I'm criticizing OOA, merely suggested that analysis needn't involve objects per se. Jackson's approach uses domains and predicates, and is a very good read, just rigorous enough but not enough formality to scare off those unacquainted with formal methods.

I'll also recommend his other book (much smaller and lighter reading): "Software Requirements and Specifications: A Lexicon of Practice, Principles, and Prejudices."

• Eric

"Laconic2" <laconic2_at_comcast.net> wrote in message news:1Mydnc0TIee51ejdRVn-gw_at_comcast.com...
> The recent discussions of the relational model, OTLT and Pizza among
others,
> led me to haul out my copy of "Object Oriented Analysis" by Coad and
> Yourden.
>
> My impression is that OOA is a jewel. It captures the best of Information
> Modeling, including Entity Relationship Diagrams and Semantic Data
> Modeling. It also captures the power and subtlety of Object Oriented
> Programming Languages and Knowledge Based Systems. It produces a
synthesis
> that allows one to learn about the problem domain and the system's
> responsibilities from both points of view: data requirements and
processing
> requirements.
>
> The most important point, in this forum, is that it doesn't present the
> same image of OOP as the object oriented apologists in here do. There IS
> time to learn what the subject matter experts know, at least insofar as it
> impacts the problem domain and the system's responsibilities. You WILL
know
> what the entities are, and you can create a separate table for each of
them.
> There is no sufficient reason not to.
>
> And you will know a whole lot about what can be encapsulated in your
objects
> as well.
>
> If the problem domain and the system's responsibilites change over time,
> you can change the system accordingly.
>
> This is completely orthogonal to the discussions held in here. Neither
> object bashing nor declaring the data centric view passe are relevant.
>
>
>
>
>
Received on Thu Apr 08 2004 - 17:32:27 CEST