Aged not outdated remarks on the meaning and importance of behaviour

About the difference: Yes I meant what I wrote. This is the root cause of the birth of Object-Oriented Analysis (OOA).

Here are the references:

Grady Booch: Object oriented design Second edition p: 16-20

http://www.amazon.com/Object-Oriented-Analysis-Applications-Addison-Wesley-Technology/dp/020189551X/ref=sr_1_7?ie=UTF8&s=books&qid=1241502775&sr=1-7

Here is the summary from Booch’s book:

Actually, this is a trick question, because the right answer is that both views are important: the algorithmic view highlights the ordering of events, and the object-oriented view emphasizes the agents that either cause action or are the subjects upon which these operations act.` However, the fact remains that we cannot construct a complex system in both ways simultaneously, for they are completely orthogonal views. We must start decomposing a system either by algorithms or by objects, and then use the resulting structure as the framework for expressing the other perspective. Our experience leads us to apply the object-oriented view first because this approach is better at helping us organize the inherent complexity of software systems, just as it helped us to describe the organized complexity of complex systems Object-oriented decomposition yields smaller systems through the reuse of common mechanisms, thus providing an important economy of expression. Object-oriented systems are also more resilient to change and thus better able to evolve over time, because their design is based upon stable intermediate forms. Indeed, object-oriented decomposition greatly reduces the risk of building complex software systems, because they are designed to evolve incrementally from smaller systems in which we already have confidence. Furthermore, object-oriented decomposition directly addresses the inherent complexity of software by helping us make intelligent decisions regarding the separation of concerns in a large state space.

 and

Peter Coad: Object Oriented Analysis  chapter 1.3. Analysis Methods (p: 18 -36) 

http://www.amazon.com/Object-Oriented-Analysis-Yourdon-Computing/dp/0136299814/ref=sr_1_1?ie=UTF8&s=books&qid=1241502828&sr=1-1

If all this is completely new for you, I suggest to you to read Coad’s book completely and first half of  Booch’s book.

As Peter Coad in his book strongly emphazises here we face a paradigm change. The glue in paradigm is that you cannot mix to paradigms. In his class training Peter Coad used as an example of two paradigms digital and mechanical watch. The point is that you have to choose -in good and bad. You cannot have both or even a mix.

To conclude this I enclose a short email from Peter Coad from 1995:

   Issue 34

Category: Use-Case

Title: “Use-Cases Considered Harmful When…

Date: Tuesday, December 3, 1996

Dear Friend,

A “use-case” describes how an actor interacts with other people and with automated systems, to achieve some business purpose. Use-cases are a helpful way of specifying functional requirements (use simple statements; state requirements from a user’s perspective; establish system context; define who is interacting with whom) For each use-case, one works out dynamics with scenarios. Each scenario is a time-ordered sequence of object interactions, showing what it takes to carry out a use-case (or a variation within a use-case).

How do object models fit into all of this? Object models provide a stable organizational framework (that is to say, problem-domain classes), so changes in use-cases or features can be more graciously accommodated.

It’s very important to make this point:

Use-Cases Considered Harmful … when used to drive an object model’s shape.

Perhaps it’s even a bit silly to write that. After all, if I made the statement:

Functional Specs Considered Harmful … when used to drive an object model’s shape

Nearly everyone would agree (with the exception of die-hard data-flow diagrammers and hard-core functional-spec writers ;-).

Allowing use-cases to be the driving force in shaping effective object models is a major mistake [1,2]. Far too often the resulting object models look like data flow diagrams, dressed in object notation. (When you see an object model and can classify its classes into controllers, function blobs, and data blobs, you know you are in trouble!)

A Better Way

A better way? Here’s a recommended approach:

  1. With your client, develop a list of features (desired outcomes, things your client will “vote with his wallet” to get).
  2. With your client, prioritize your features into three major categories: A (must have), B (nice to have), C (next time).
  3. With your client, group related features together. These groupings are use-cases, defined at an appropriate level of abstraction.
  4. With your client, create an initial object model, from classes named in the use-cases and features.
  5. With your client, proceed feature-by-feature and:
    1. Work out dynamics with scenarios.
    2. Establish responsibilities, along the way.
    3. And, at times, discover additional classes of objects, ones you had not previously considered.

When someone hands me a book of use-cases, do I use them? Definitely. When someone hands me a book of functional requirements, do I use them? Definitely. How? In both cases, I use such sources of content, not for insights on how to shape an effective object model.

Pete

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: