V
------------ Forwarded Message ------------
From: "Vladimir E. Zyubin" <[email protected]>
To: List Manager <[email protected]>
Subject: Re: SOFT: OOP as a panacea (was OPC etal. vs CORBA)
Hello List,
On Friday, August 16, 2002, 8:00:24 PM, richard higginbotham wrote:
LM> Vladimir:
>> The short answer is you can try the approach, but you lose flexibility
>> of the algorithm. Consider a set of valves and tubes with a complex
>> topology. What is the rules to structurize (to construct a class
>> hierarchy) in OO? Where are the objects? I personally see only
>> functions... as well as the developer. etc.
LM> OOP should make perfect sense to anyone involved with processes. We talk
LM> about unit operations, we talk about the different pieces that make up a
LM> unit (valves, motors, etc.). We collect all these pieces together when
LM> we talk about them. We identify them with groups such as "distilation
LM> column" or "boiler" which are made up of other smaller pieces. Then we
LM> group those together to form a plant. Its done without even needing to
LM> think about it. Then we talk about the functionality of the equipment.
LM> The chiller feeds the water to the cooling coils. When running the
LM> chiller opens these valves and starts those pumps. In python, that would
LM> be like: class Chiller():
LM> def Start():
LM> InletValve.open()
LM> Pump.start()
Really, the "open" method is unique for every valve.
Short explanation: because of safety we shell check a condition of safe execution of the function (method) "open". No need to say, that the same brand and type of the valves do not guarantee the same conditions of safe execution.
The conditions are depended on the _topology_ (on the place of the valve in system).
I.e. "open" methods are different, therefore we have to have an unique class for every valve, therefore OOP is an incorrect method for the class of tasks (it does not provide complexity reduction).
We see in the system an object, but we ought to see a function. And it is our fault. The valves that are looked like the same and (ever sometimes) work like the same... these valves execute _different_ functions.
Moreover brand and the type of the valves (and therefore the "open"|"close" algorithms) can change... the functions - never. What is the essence we ought to choose for the basement of
algorithm in out circumstances? Object?
I personally choose functions.
LM> For a good look at how to partition a control system in a OO way take a
LM> look at the structure of a valve in APT. Its a siemens product,
LM> originally Texas Instruments, thats been around for a long time. Theres
LM> a base class for a valve that other particular types of valves inherit
LM> from ( such as a single out put, single feed back valve- VSS). The
LM> "complexity" of OO design is shielded from the user by using "Devices"
LM> that aren't generally user modifiable. What does a valve do? It
LM> generally opens and closes. All that can be incorperated into an object
LM> easily enough and it makes perfect sense to say " Open(myvalve) ". All
LM> the "functions" that can act upon a valve are associated with the valve
LM> "type" or class in this instance. The standard OO methologies and
LM> benefits apply even in controls. The only time I've ever seen problems
LM> is when the programer didn't understand OOP. *That* is a valid concern,
LM> but another topic in itself.
Alas, I had no chance to work with APT... Nevertheless I dare to assume that there is no conceptually unknown to me.
What we ought to keep in mind: there are different classes of tasks. OOP is not a panacea. It has limits of usage... The criterion is
polymorphism. And I have the contrary view - the programmer who try to use OOP everywhere didn't understand OOP.
Please have a look at the UML (Unified Modelling Language). What is interesting there? Heheh...
First. The UML is a top of programming, an advanced technique approved in practice..
Second. Despite of the very promising name it is a set of _several_ languages. Ten or so... For every class of tasks the UML provides a special language. For the tasks with polymorphism the UML
provides booch-like means (OOP), for control algorithms the UML provides an other means where you can easily recognise SFC-like behaviours.
Hgm.
Though I can assume the case where OOP is applicable: in SCADA-systems that provides the commands like "open|close valve" only,
whithout any checking, when the algorithm is in the operator head... Unsafe fool-friendly systems. IMO.
Best regards,
Vladimir mailto:[email protected]
( Previous thread: "http://www.control.com/1026151806/index_html":http://www.control.com/1026151806/index_html )
From: "Vladimir E. Zyubin" <[email protected]>
To: List Manager <[email protected]>
Subject: Re: SOFT: OOP as a panacea (was OPC etal. vs CORBA)
Hello List,
On Friday, August 16, 2002, 8:00:24 PM, richard higginbotham wrote:
LM> Vladimir:
>> The short answer is you can try the approach, but you lose flexibility
>> of the algorithm. Consider a set of valves and tubes with a complex
>> topology. What is the rules to structurize (to construct a class
>> hierarchy) in OO? Where are the objects? I personally see only
>> functions... as well as the developer. etc.
LM> OOP should make perfect sense to anyone involved with processes. We talk
LM> about unit operations, we talk about the different pieces that make up a
LM> unit (valves, motors, etc.). We collect all these pieces together when
LM> we talk about them. We identify them with groups such as "distilation
LM> column" or "boiler" which are made up of other smaller pieces. Then we
LM> group those together to form a plant. Its done without even needing to
LM> think about it. Then we talk about the functionality of the equipment.
LM> The chiller feeds the water to the cooling coils. When running the
LM> chiller opens these valves and starts those pumps. In python, that would
LM> be like: class Chiller():
LM> def Start():
LM> InletValve.open()
LM> Pump.start()
Really, the "open" method is unique for every valve.
Short explanation: because of safety we shell check a condition of safe execution of the function (method) "open". No need to say, that the same brand and type of the valves do not guarantee the same conditions of safe execution.
The conditions are depended on the _topology_ (on the place of the valve in system).
I.e. "open" methods are different, therefore we have to have an unique class for every valve, therefore OOP is an incorrect method for the class of tasks (it does not provide complexity reduction).
We see in the system an object, but we ought to see a function. And it is our fault. The valves that are looked like the same and (ever sometimes) work like the same... these valves execute _different_ functions.
Moreover brand and the type of the valves (and therefore the "open"|"close" algorithms) can change... the functions - never. What is the essence we ought to choose for the basement of
algorithm in out circumstances? Object?
I personally choose functions.
LM> For a good look at how to partition a control system in a OO way take a
LM> look at the structure of a valve in APT. Its a siemens product,
LM> originally Texas Instruments, thats been around for a long time. Theres
LM> a base class for a valve that other particular types of valves inherit
LM> from ( such as a single out put, single feed back valve- VSS). The
LM> "complexity" of OO design is shielded from the user by using "Devices"
LM> that aren't generally user modifiable. What does a valve do? It
LM> generally opens and closes. All that can be incorperated into an object
LM> easily enough and it makes perfect sense to say " Open(myvalve) ". All
LM> the "functions" that can act upon a valve are associated with the valve
LM> "type" or class in this instance. The standard OO methologies and
LM> benefits apply even in controls. The only time I've ever seen problems
LM> is when the programer didn't understand OOP. *That* is a valid concern,
LM> but another topic in itself.
Alas, I had no chance to work with APT... Nevertheless I dare to assume that there is no conceptually unknown to me.
What we ought to keep in mind: there are different classes of tasks. OOP is not a panacea. It has limits of usage... The criterion is
polymorphism. And I have the contrary view - the programmer who try to use OOP everywhere didn't understand OOP.
Please have a look at the UML (Unified Modelling Language). What is interesting there? Heheh...
First. The UML is a top of programming, an advanced technique approved in practice..
Second. Despite of the very promising name it is a set of _several_ languages. Ten or so... For every class of tasks the UML provides a special language. For the tasks with polymorphism the UML
provides booch-like means (OOP), for control algorithms the UML provides an other means where you can easily recognise SFC-like behaviours.
Hgm.
Though I can assume the case where OOP is applicable: in SCADA-systems that provides the commands like "open|close valve" only,
whithout any checking, when the algorithm is in the operator head... Unsafe fool-friendly systems. IMO.
Best regards,
Vladimir mailto:[email protected]
( Previous thread: "http://www.control.com/1026151806/index_html":http://www.control.com/1026151806/index_html )
