Re: Haven't done anything real with OOP yet.
From: Gregory L. Hansen (glhansen_at_steel.ucs.indiana.edu)
Date: 10/28/04
- Next message: U-CDK_CHARLES\\Charles: "Re: beginner - stuck on data storage"
- Previous message: Daniel Parker: "Re: XP Requirement Analysis?"
- In reply to: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Next in thread: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Reply: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 28 Oct 2004 20:56:13 +0000 (UTC)
In article <F0bgd.4364$uQ4.3472@trndny08>,
H. S. Lahman <hsl@pathfindermda.com> wrote:
>Responding to Hansen...
>
>> Well, I found one on data structures and algorithms in C++ (title is about
>> the same), a $90, used, for $30. It got good reviews on Amazon, I figured
>> it was worth risking the money. It's probably not quite design, but the
>> sort of thing I should have, anyway.
>
>It will probably be of little help for OOA/D. Books with a specific
>OOPL in the title tend to be more about manipulating syntax than A&D.
>That is, they do a fine job of telling you how to express your design in
>the OOPL but they don't provide a lot of help in discovering the design
>itself.
Yeah, but searching and sorting and that sort of thing is still nice to
know.
>
>>
>> Also found a book on object oriented design in the library at work. Looks
>> like it starts with the specification, and goes through the design
>> process. It's about ten years old, but looks like just the sort of thing
>> I wanted.
>
>Age probably doesn't matter that much for OOA/D; in fact, it can be an
>advantage. An army of procedural developers converted to OO development
>in the late '80s and early '90s. Many of them leaped into OOPL code and
>mapped their procedural experience onto the OOPL. Unfortunately some of
>those people started writing books about OO in the late '90s.
>
>>>OK, I may have overstated the case. Even hard-core scientific
>>>applications can be OO because there is usually a lot of peripheral
>>>stuff to be handled (UI, algorithm selection, initialization, DB access,
>>>etc.) besides the solution algorithms. OO can be very useful as "glue"
>>>for such applications. However, the core algorithms would probably be
>>>in realized code done with procedural or functional methods.
>>
>>
>> Speaking of hard-core scientific applications, I was thinking about the
>> simulation of a temperature controller. A few objects seem pretty obvious
>> to define; the plant, the thermometer and electronics that make up the
>> temperature measurement, the control loop, and the voltage output to the
>> heater resistor. But each of those are also a function that could be
>> defined. You could give the plant object an input heat and elapsed time
>> and receive a temperature, or you could give the plant function an input
>> heat and elapsed time and receive a temperature. Either I don't know my
>> programming philosophies as well as I thought I did, or there's very
>> little difference in this case, except using classes for one and functions
>> with static variables for the other.
>
>I think the fourth sentence needs some work. B-)
>
>Actually, the temperature controller is probably a good candidate for
>OO. It is more akin to R-T/E development than something like operations
>research algorithms. Let's look at a couple of the objects you
>identified in your blitz...
Every peice would have their own set of parameters and state variables,
which could in principle all be contained in a structure whose pointer is
passed around. As objects I don't think they'd have a lot of member
functions, just a transfer function that returns some output when given an
input. Plus the usual maintenance like initializers, destructors, and
things that set the parameters like the setpoint or heat capacity.
>
>Plant. I assume this is the hardware that actually provides heating and
>cooling (e.g., an HVAC installation). Seems reasonable.
It's the thing whose behavior is to be controlled. In my case it's a
target cell filled with liquid helium-3, and we want to control the
temperature. The heating is done by an electrical resistor epoxied to the
back. But that doesn't really matter. Heat goes in, heat comes out, a
temperature is measured. The transfer function is an exponential.
>
>Thermometer. Somebody has to track the actual temperature, so this
>seems reasonable also. [I suspect the problem would only be interesting
>if there were multiple Thermometers in, say, a building and one had to
>get an average or something. That computation would probably be a
>responsibility of the container, such as a Building entity.]
>
>Electronics. This sounds like a surrogate for hardware associated with
>the Thermometer. One communicates with it by reading/writing registers
>but otherwise one really doesn't care about it. Could the register
>read/writes be encapsulated in the Thermometer methods? Probably.
The thermometer is a germanium resistor, it has an R(T). That's
converted to a voltage by a lock-in amplifier reading a bridge circuit,
the lock-in has a low-pass filter, so it's a little more than just a
multiplying factor. And the output is passed along to the computer.
I've thought of the whole set as a logical unit.
>
>Control Loop. For an OO reviewer the klaxons would be sounding here.
>This sounds very procedural or functional. That is, it sounds like a
>behavior responsibility rather than a entity. For example, it might be
>a logical behavior of something else, like Building.
The temperature controller. Implemented in a digital computer, in this
case. It calculates a heater output based on a temperature input. Or
really, a deviation of the temperature from the setpoint. An input of
zero means everything is fine.
It's really not treated any differently from the other components. An
error signal goes in, and a voltage comes out. Analyzing it would start
with a diagram like
____________ ________
setpoint ->( )-->| controller |--->| plant |---+-> temperature
^ | | |(target)| |
| |____________| |________| |
| _____________ |
-------<---| transducer |---<-----
|(thermometer)|
|_____________|
And each block could be given more detail. The controller has a
proportional term, integral term, derivative term, and a digital filter in
it.
>
>Resistor. I'm not sure where this comes in. Part of the heating
>mechanism or part of the temperature sensing mechanism? Either way, it
>seems like it is a bit too detailed for the level of abstraction of a
>temperature controller. To control temperature one extracts data from
>sensors, processes it, and, if necessary, sends a message to the Plant
>hardware. One should be able to abstract that at the level of Plant,
>Thermometer, and <something else> that owns the control loop.
In this case, the target is heated by current through a resistor. The
controller plus heater resistor should probably be considered a logical
unit, with the output being heat, even if the resistor is physically
closer to the target.
>
>Timer. Because of delays ("elapsed time") in the HVAC you need to have
>some sort of sampling policy for monitoring temperature. The
>conventional way to deal with this is an external timer (e.g., in the
>OS) that issues an event when the time has elapsed). This object would
>be a surrogate for that external facility.
Or in a simulation, each iteration represents some delta_t. The actual
control system has things happening on a lot of different time scales, and
there's a loop that checks the time, then checks whether the temperature
should be sampled, whether counters should be read and cleared, etc., and
calculates when is the next time each action should be taken. It's a
rather nice peice of procedural programming.
For a simulation, I thought it would be nice to have two time scales; a
"fast" time for the evolution of analog systems which are inherently
continuous, and then the sampling time of the control system. That would
allow exploring things like sampling rate versus stability. E.g. 0.01
seconds and 0.1 seconds.
>
>BTW, this is the sort of reasoning a development team applies after an
>initial object blitz. The blitz accepts candidates on a stream of
>consciousness basis without prejudice. Then each is evaluated to prune
>out those that are unnecessary (irrelevant to the problem in hand),
>duplicates, or inaccurate. That's when Electronics and Resistor
>probably go away. It is also where Control Loop gets paraphrased into
>Building (or whatever is having its temperature controlled).
Hmm... vocabulary mismatch, I think. The control loop is the logic that
determines an output given the input. The plant is the thing to be
controlled. But yes, I see what you mean.
>
>The next step would be to identify the relationships among them. This
>might lead to Timer making an appearance. For example, in answer to the
>question: who tells Thermometer to take a measurement? Building. OK,
>how does Building know when to do that? At this point one might have
>something like:
Well, I drew a picture above. And it's a loop, a feedback system, so the
controller's output will affect the controller's input. In this example,
each component has input from only one component and outputs to only one
component, and after initialization, and barring a deliberate disturbance,
all they would really do is pass data from one to the next. In that sense
it's probably a pretty boring or trivial example from an OOP point of
view. But it's a useful thing to do in an engineering sense. The goal is
a constant temperature, probably returning to the setpoint as quickly as
possible after a disturbance, but other conditions could be specified like
"no overshoot".
>
>[Timer]
> | 1
> | initializes
> |
>R1 |
> |
> | triggers
> | 1 1 monitored by R2
>[Building] ---------------------------------- [Thermometer]
> | 1 extract temperature from *
> | contained in
> |
> R3 |
> |
> | controls
> | 1
> [Plant]
>
>Note that the relationship roles already pretty much define what
>responsibilities the objects have in this simple example. [Timer],
>[Thermometer], and [Plant] are basically just surrogates for external
>hardware. They encapsulate all the register read/writes for the
>specific device driver protocols. All the intelligence of the
>application solution lies in [Building] and that isn't a whole lot:
>
>(1) Send Initialize message to Timer
>(2) Process Timer Event
> (2a) Extract current temperature values from Thermometers
> (2b) Compute average
> (2c) Compare to desired
> (2d) Send Off, Heat, or Cool message to Plant based on (2c)
> (2e) Go to (1).
>
>Depending on how complicated the [Plant] protocol is, the entire
>application might be less than two dozen executable statements. Because
>the OO solution has four classes, that solution will be a whole lot more
>verbose in LOC terms than the corresponding procedural solution because
>of the static declarations. But structurally it will be simpler from a
>maintenance viewpoint. For example, one will be able to substitute
>Thermometer hardware or even a new Plant without touching anything
>except the implementation of the relevant device driver (i.e., the class
>interfaces should be untouched by the substitution).
Plus it could be genuinely useful.
I guess that's that, then. I'll practice OOP by simulating a temperature
controller.
>
>Note that the introduction of [Timer] simplifies things because of its
>collaboration with [Building]. Each object has a very simple set of
>responsibilities that are triggered by what the other does. That
>handshaking effectively incorporates solution rules in the form of
>messages rather than code.
>
>For example, consider what happens when you discover you need your timer
>to trigger every five minutes but the OS event timer has a maximum
>elapsed timed of 4.2 seconds. [Timer] still sends the event after five
>minutes by setting/triggering the OS timer multiple times. But that is
>all hidden from the collaboration.
>
>One can achieve exactly the same level of encapsulation using SA/SD and
>a procedural language. But doing so will require a /lot/ of skill and
>discipline on the part of the developer. OTOH, most of it comes pretty
>much for free in an OO application just by getting the abstractions and
>relationships right in a static Class Diagram.
And suppose the target is connected by a weak thermal link to a
temperature-controlled heatsink, and I wanted to see how the response of
one would affect the other. I've already defined my objects. Create
another set and let the two plants source/sink some power to each other.
Then it's not quite such a trivial or boring example from an OOP
standpoint.
In practice we've tended to ignore the interaction because of the
different time scales. But in the latest runs the thermal time constants
were about the same, and the temperature had some structure to it on the
scale of a half hour, it wasn't just noise. But there wasn't time then
to analyze it in detail.
-- "Then they placed the ark of the Lord on the cart; along with the box containing the golden mice and the images of the hemorrhoids." -- 1 Samuel 6:11
- Next message: U-CDK_CHARLES\\Charles: "Re: beginner - stuck on data storage"
- Previous message: Daniel Parker: "Re: XP Requirement Analysis?"
- In reply to: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Next in thread: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Reply: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
