Prev: SEO Optimization Software
Next: confused at associaton class in modeling library management system
From: Leslie Sanford on 9 Apr 2008 11:30

"David Cressey" wrote:
> "Leslie Sanford" wrote:

<snip>

>> when designing a class I decide what it needs to do,
>> and this goes hand in hand with what it needs to know in order to do it.
>> To me it's like working with algorithms (or behavior) and data structures
>> (or data). I can't say if one comes before the other.
>
>> Could be my head is stuck at the code level which is where I mainly live
>> and I don't understand what it is you're asking. In which case, I welcome
>> enlightenment/clarification.
>>
> Sorry. I don't know enough OO to provide enlightenment. I understand
> data pretty well.
>
> Perhaps you could tell me how you express "what a class has to do". This
> might be close to what I'm asking for when I say "how to you model
> behavior".

Well, I do it in code. Specifically at the class declaration. If a method
represents the means by which an object is sent a message, then I think it's
safe to say that the method name is also the name of the message. This name
should reflect what behavior occurs in response to the object receiving the
message. Using an example I posted in another thread:

// For fans of John Carpenter's first movie. :-)
class DarkStar
{
public:
void CancelBombDetonation();
};

Here DarkStar can receive a message to cancel bomb detonation. So what the
"class has to do" in response to this message is reflected in the message
name, i.e. cancel bomb detonation. Of course, there may be a reason why the
operation can't be carried out successfully, in which case an exception
should probably be thrown, but I'm going to ignore that for this discussion.

If we want to go further, we could specify the pre/post conditions of this
message. How strongly this can be expressed in code depends on the
programming language.

At any rate, for me, this is how it works. I don't use UML or any kind of
notation to design my classes. I do it in code. I may sit down and draw out
a state transition diagram for a class. But that's about it.




From: David Cressey on 9 Apr 2008 12:34

"Leslie Sanford" <jabberdabber(a)bitemehotmail.com> wrote in message
news:47fce12c$0$11322$4c368faf(a)roadrunner.com...
>
> "David Cressey" wrote:
> > "Leslie Sanford" wrote:
>
> <snip>
>
> >> when designing a class I decide what it needs to do,
> >> and this goes hand in hand with what it needs to know in order to do
it.
> >> To me it's like working with algorithms (or behavior) and data
structures
> >> (or data). I can't say if one comes before the other.
> >
> >> Could be my head is stuck at the code level which is where I mainly
live
> >> and I don't understand what it is you're asking. In which case, I
welcome
> >> enlightenment/clarification.
> >>
> > Sorry. I don't know enough OO to provide enlightenment. I understand
> > data pretty well.
> >
> > Perhaps you could tell me how you express "what a class has to do".
This
> > might be close to what I'm asking for when I say "how to you model
> > behavior".
>
> Well, I do it in code.

How well does this scale up?

> If we want to go further, we could specify the pre/post conditions of this
> message. How strongly this can be expressed in code depends on the
> programming language.
>
> At any rate, for me, this is how it works. I don't use UML or any kind of
> notation to design my classes. I do it in code. I may sit down and draw
out
> a state transition diagram for a class. But that's about it.

State transition diagram speakes to the question I was really asking.

A model doesn't have to be elaborate in order to be useful.

In data modeling, what is left out of the model sometimes makes the model
more useful for its intended purpose.



From: Miguel Oliveira e Silva on 9 Apr 2008 13:24
David Cressey wrote:

> (...)

> Sorry. I don't know enough OO to provide enlightenment. I understand data
> pretty well.
>
> Perhaps you could tell me how you express "what a class has to do".

In OO, a class is (or at least, it should be!) an Abstract Data Type
(possibly partial) implementation (an ADT is a type which is
completely defined by its public operations and their semantics).

Hence, the behavior of a class is specified by its ADT.

In a pure OO world one manages "data" *only* through the
operations (functions or methods, if you will) which are
applicable to it.


> This might be close to what I'm asking for when I say "how to you model
> behavior".

Contracts attached to ADTs:

- class invariants, and;
- method preconditions and postconditions.

For instance, the behavior of a generic class STACK could be
approximated by the following class (using Eiffel syntax):


-- This is a line comment!

deferred class STACK[E] -- a deferred class cannot be instantiated

feature -- exported to everyone

count: INTEGER is
-- Number of elements in STACK
deferred -- the body implementation is deferred to descendant classes!
end;

empty: BOOLEAN is
-- Is STACK empty?
do
Result := count = 0 -- no need to defer this implementation to descendants
end;

full: BOOLEAN is
-- Is STACK full?
deferred
end;

top: E is
-- STACK's last pushed element
require -- precondition
not empty
deferred
ensure -- postcondition
same_count: count = old count
end;

push(elem: E) is
require
not full
deferred
ensure
not empty;
one_more: count = old count + 1;
element_placed_in_the_top: top = elem;
correct_old_top: old empty or else under_top = old top
end;

pop is -- procedure (Eiffel promotes strict query/command separation)
require
not empty
deferred
ensure
not full;
one_less: count = old count - 1;
correct_new_top: empty or else top = old under_top
end;

feature {STACK} -- exported only to STACK itself

under_top: E is
-- Stack's pushed element before top
require
at_least_two_elements: count >= 2
deferred
ensure
same_count: count = old count
end;

invariant

(empty and count = 0) or (not empty and count > 0)

end -- STACK


As you can verify there are no explicit data declarations,
other than possible function arguments and results
(only operations, whose behavior is specified and depends
on each other).

This stack specification and construction is also not
linked to a possible (state based) internal representation
(array, linked list, or any other).
In OO, other than for object creation, a client of a
stack may rely only on this interface to manipulate
stacks (dynamic binding, together with subtype
polymorphism, allows us to put any object of a
type descendant of STACK, where a STACK is
expected.

Also, although a push message sent to a STACK object
carries a "data"(*) element of type E with it, the stack's
semantics does not depend, in any way, on the semantics
of such element (that is why we can use unbounded
parametric polymorphism in the stack class).

(*) is fact, in a pure OO world this is also an object
(an instance of a (partial) ADT implementation).

It is also important to note that in Eiffel contracts (invariants,
preconditions and postconditions) are inherited in descendant
classes, so a STACK descendant is *required* to obey
STACK's specification. Hence this (deferred) class defines
the behavior of all its possible descendants (STACK_ARRAY[E],
STACK_LINKED_LIST[E], etc.).

Best regards,

-miguel


From: Leslie Sanford on 9 Apr 2008 14:17

"David Cressey" wrote:
> "Leslie Sanford" wrote:
>> "David Cressey" wrote:

<snip>

>> > Perhaps you could tell me how you express "what a class has to do".
>> > This might be close to what I'm asking for when I say "how to you model
>> > behavior".
>>
>> Well, I do it in code.
>
> How well does this scale up?

I don't know. Probably not well. I write DSP code, specifically VST
synthesizers and effects. These use models of filters, envelopes,
oscillators, etc. If, for example, I decide to write a class representing
the state variable filter, it's going to be pretty clear how it should
behave, what methods it should have, etc. So my domain allows me to work
from the bottom up to some extent. I can work at the class declaration
level. Usually, I can mentally fit all the pieces together, or a simple
scribble showing the data flow through the objects is enough. This works for
me.

If I were thrown into a domain in which I needed to work at a higher level
of abstraction, I would probably need to use a more formal method. This
might require something like UML or whatever.

<snip>

>>I don't use UML or any kind of
>> notation to design my classes. I do it in code. I may sit down and draw
>> out a state transition diagram for a class. But that's about it.
>
> State transition diagram speakes to the question I was really asking.
>
> A model doesn't have to be elaborate in order to be useful.
>
> In data modeling, what is left out of the model sometimes makes the model
> more useful for its intended purpose.

Intersting. I look forward to reading other responses you get to this thread
and your replies.



From: Bob Badour on 9 Apr 2008 17:28
David Cressey wrote:
> "Leslie Sanford" <jabberdabber(a)bitemehotmail.com> wrote in message
> news:47fcd175$0$11371$4c368faf(a)roadrunner.com...
>
>>"David Cressey" wrote:
>>
>>>"Dmitry A. Kazakov" wrote:
>>>
>>>>David Cressey wrote:
>>>>
>>>>
>>>>>How does one model behavior?
>>>>
>>>>Behavior of what? Of the program, of a physical system?
>>>>
>>>>
>>>>>It would seem to me that, since conveying behavior from one object to
>>>>>another rests on messages, and since messages are made of data,
>
> that
>
>>>>>one needs a data model for the messaging system before one begins to
>>>>>come up with a bhavior model for a system of collaborating objects.
>>
>><snip>
>>
>>>>To your point about messages parameters.
>>>
>>>I didn't mention parameters. I don't know what you mean.
>>
>>As I understand it, sending an object a message at the code level means
>>invoking one of its methods. A method takes zero to many parameters, or
>>arguments. When you say that messages are made up of data, my point of
>
> view
>
>>translates that to meaning the arguments passed to methods, i.e. the
>>arguments are the data. Perhaps that's the impression Dimitry got as well.
>>
>
>
> I'm not really asking at the code level. I think a message specifies an
> operator, not a method.

Are you saying the message is a symbol? Operators are symbols.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: SEO Optimization Software
Next: confused at associaton class in modeling library management system