Re: Haven't done anything real with OOP yet.
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 10/29/04
- Next message: H. S. Lahman: "Re: pattern languages"
- Previous message: Debbie Craft: "Re: Just say no to threads [Was: Software architecture]"
- In reply to: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Next in thread: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Reply: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 29 Oct 2004 17:11:21 GMT
Responding to Hansen...
>>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.
True, as I eventually pointed out.
>
>
>>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.
OK, then Plant is more like what I assumed for Building and the Resistor
is what I was thinking of as the HVAC hardware. I think it might be
clearer, though, when one gets to control actions to think in terms of
Cell and Resistor as separate entities. Plant is a bit ambiguous about
whether it includes the resistor or not.
>
>
>>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.
OK. But that just says that Thermometer has to do something more
complicated than returning a memory location's value when getTemperature
is invoked. One of the nice things about abstraction is that it allows
one to hide such details via encapsulation (in this case method
implementation) from the Big Picture. So the electronics is important
to the way the temperature is computed in Thermometer but not to how the
temperature is controlled in Plant.
>
>
>>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.
Is this controller hardware or software? If software, is it part of the
proposed application or already realized (e.g., provided by the vendor)?
This is important because if there is a physical entity in the problem
space, it should be abstracted to be responsible for the algorithm if
you have to write it. However, if you don't have to provide the
algorithm, then all one has is two message transfers to the outside
world: the measured temperature goes out and the computed voltage comes in.
Let's assume it is software you have to provide as part of the
application, even if it is embedded. It is still basically a single
algorithm that computes a voltage from a temperature deviation. If
there is physical controller hardware where the algorithm lives, then I
agree that needs to be abstracted as an entity and it will have a method
to compute the voltage.
OTOH, if there is no such obvious entity in the problem space (i.e., it
is just conceptually a convenient place to put the computation in a
block diagram like yours above as you think about the design), then I
would probably put it in Cell (or Resistor). Without that behavior
there are no obvious responsibilities for Cell, yet it seems to be
pretty central to thinking about the problem.
Doing this sort of thing in known as anthropomorphizing. It is common
in all software development but has been raised to a semi-artform in OO
development. Since one is usually abstracting inanimate entities, it is
kind of a stretch to attribute them with doing things. At the same time
software is replacing operations that would be performed by people less
efficiently. So we map those control functions that people would
normally perform onto the inanimate entities as if the entities were
people. Therefore one tends to look for entities one has already
abstracted when seeking to assign behavior responsibilities rather than
creating an abstraction that really just represents a person's activities.
>
>
>>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.
OK, this is what I was envisioning with HVAC. It is a surrogate for the
hardware that actually provides heat.
Given the nature of the simulation, I would probably put the computation
os a new temperature in here. (More precisely, the computation of the
hardware value the Thermometer electronics provides that needs to be
massaged into a temperature value by Thermometer per the above.) The
resistor is doing the heating so it is logical that power and heat
transfer calculates would be here.
>
>
>>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.
OK, that's a bit more complicated. Note, though, that this just changes
the responsibilities of Timer. It now encapsulates a polling loop and
the rest of the algorithm. It generates an event to trigger temperature
sampling, etc. for an iteration. Eventually a Reset event comes back
that tells it the adjustments have been made and it starts polling
again. And...
>
> 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.
The simulation adds some additional requirements. I suspect you will
need a separate Timer instance for each time scale. One simulates the
actual control sampling while the other simulates the hardware reaction
times. Fortunately both periods can be trivially parameterized for What
If scenarios.
[Note that simulation probably introduces some other complexities. It
would probably be very helpful if the processing were event-based, which
means object state machines and at least one EventQueue object lurking
around somewhere. To deal with the two time scales, you will probably
need at least some concurrency because both Timers are probably going to
have to poll. None of these things is relevant for OOA solutions but
they would be introduced in OOD elaboration. (I am a translationist, do
I only do OOA models. B-))]
>
>
>>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.
Yes, I misinterpreted the semantics of your objects. It is a common
problem in email problem descriptions. That's why I tend to be a tad
verbose. B-) (Of course, being retired may also have something to do
with it.) At least that makes it easier to identify the semantics
mistmatches, as in this case.
>
>
>>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".
I could argue this is quintessential OOA/D. B-) The feedback loop is
implemented purely in terms of message traffic and in OOA/D messages are
separated from the methods that respond. One-input-to-one-output can be
mapped to peer-to-peer collaboration, which is crucial to OO development
because it eliminates the hierarchical implementation dependencies that
plagued functional decomposition hierarchies. And data passing is what
OOA/D messages are all about. (At the subsystem level good OO practice
gets quite anal about this with very constrained interface models that
are essentially pure by-value data transfers.)
However, the complexity you are attributing to the controller algorithm
gets back to the point I made awhile back that OO isn't very helpful for
pure algorithmic stuff. Note that almost everything in the algorithm
will be contained in two methods: one in Resistor to compute the new
temperature as F(last temperature, voltage, elapsed time) and one in
Cell to compute a new voltage as F(temperature delta, elapsed time).
That algorithm can have arbitrary complexity and OO isn't helping at all
with that complexity because it is all hidden in two methods. For
example, I can envision the application having ~200 executable
statements of which 190 were in those two methods.
>>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.
Things are more complicated than I originally though, but I think for
the original we would have something akin to:
R1 resets 1
+----------------------------- [Timer]
| | 1
| resets |
| | R4
| |
triggers | | triggers
1 | R3 heated by 1 | 1
[Cell] ------------------------ [Resistor]
1 | 1 attached to 1 |
monitored by | monitors |
| |
| R2 |
| R5 |
[Thermometer] -----------+ |
| * * extracts temperature from |
| updates |
| |
+----------------------------------------------------+
For the simulation [Resistor] computes the new temperature whenever it
is triggered by the timer instance for analog. The other timer instance
triggers Cell to get the temperature and compute a new voltage for Resistor.
Given this configuration, I would expect the changes would be:
(1) Add a [Heatsink] class. It would compute the heat drain as
F(voltage, temperature, elapsed time).
(2) Add a 1::1 relationship between [Resistor] and [Heatsink].
(3) modify the [Resistor] computation to account for power drained to
the heatsink.
(4) reorganize the messages. The analog Timer would send a message to
Heatsink instead of Resistor. Heatsink would compute the drain and then
send a message to Resistor to trigger computation of the temperature
increase.
Note that most of the change lies in the new [Heatsink] class with its
computation of the power drain. The change to [Resistor] in (3) is
trivial; it just decrements the amount of power it already calculates by
the amount [Heatsink] calculated before finishing the computation. The
sequencing of operations is handled by just reorganizing the messages at
the UML Interaction Diagram level. All of the triggering mechanisms for
the simulation remain exactly the same, as does the simulation of the
voltage computation.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH
- Next message: H. S. Lahman: "Re: pattern languages"
- Previous message: Debbie Craft: "Re: Just say no to threads [Was: Software architecture]"
- In reply to: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Next in thread: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Reply: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
