Christian Klugsherz wrote:Until now all is clear :-)
I presume those mean
Earlier, you wrote:. . .
"Température des gaz BP\n après surchauffe interne\n et avant compression", . . .
"Température des gaz HP\n en fin de compression\n (Cloche du compresseur)", . . .
"Pression du début de condensation\n (Mesure HP Manifod)", . . .
"Pression de fin de condensation\n (Mesure HP Manifod)", . . .
"Température Départ Eau Captage",
. . .
Where HP=haut pression=high pressure and BP=bas pression=LP=low pressure. Are you building a steam engine for a ship or something?
Gas pressure (LP) after internal superheating and before compression
Gas pressure (HP) at the end of the compression [cycle] (compressor's collection chamber)
Pressure at start of condensation [cycle] (HP manifold)
Pressure at end of condensation [cycle] (HP manifold)
Temperature of water exiting condenser
Campbell Ritchie wrote: if you can say that a method does nothing with any instances, it can be static.
Campbell Ritchie wrote:any formulae used to calculate the figures for the graph you showed in the screenshot.
Christian Klugesherz wrote:
So to my example, manipulating a list of object: measureL = new ArrayList<Measure>(); through method, "updateAllMeasureListElem()"
Considering the method "updateAllMeasureListElem()" using only public methods of the individual class "Measure"
"updateAllMeasureListElem()" has to be considered as static , and for sense declared in the class "Measure"
Christian Klugesherz wrote:
Since I have started this topic, I have started to train in UML.
I will start to consider my problem in a different way .
Person 1: Tell me what you want to do.
Person 2: I want to use a for-loop to iterate over this list of Strings that I want to convert to numbers, then I want to add all of them up to get another number.
(demonstrates with an example)
Person 1: Oh, so you want to get the sum of all the numbers from 1 to 100, for example?
Person 2: Yes!
Person 1: Well, why didn't you say so in the first place?
Person 2: Didn't I do that? I thought that's what I did!
Person 1: No, you told me HOW you wanted to do it, not WHAT you wanted to do.
Person 2: I see...
That is the simplest description. You will have to make it bigger than that:-
A heat pump cools off a cool area and heats up a warm area.
As long as you aren't using some sort of Peltier effect, you should be able to create a more complicated desccription:-
A heat pump cools off a cool area and heats up a warm area. It does that by evaporating a fluid in the cooler area and condensing it in the warmer area.
Apart from the gas, I have not yet mentioned any of the parts of the circuit. No valves, sensors, or anything. Now you write such descriptions, gradually adding details. You will eventually get to describing things like valves and pressure sensors.
A heat pump cools off a cool area and heats up a warm area. It does that by evaporating a fluid in the cooler area and condensing it in the warmer area. The heat pump forces a gas under pressure into part of its circuit where it condenses and releases latent heat of vaporisation. The fluid passes into another part of its conduit which allows where the pressure is nower, and evaporates, taking latent heat of vaporisation from its surroundings.
So the code would be searchable. When you need to look for the particular place in the code, you type in 'pressure' and you find it within seconds, which wouldn't be a case of 'P', unless you rely on method name where this formulae might laying in. After all, if the code is meant to be read only by the specific field experts only, might it is easier the way you say. But personally prefer code more explicit rather than abbreviations and comments along with them.
Piet Souris wrote:So, why would one choose to use other names for these variables?
So do you need to model the operator? How many sensors are there per pump? Where are these sensors? Do all these sensors measure temperature and pressure? Or do some measure only temperature or pressure?
Christian Klugesherz wrote:. . . An operator will measure on different Head-Pump's locations, Pressure(P)/ Temperature(T)/..
So you mean the program calculates the enthalpy at three locations in the heat pump? We are still not yet at the stage of T₀ or T₁.
All these Measures (M0,M1,M2) will be entered in the program, and the program has to revert with the corresponding Enthalpy(H0,H1,H2)
For the time being, let's say it is roughly approximated. It doesn't really matter what formula you use: guess a formula. We can work out how to get figures from the diagram later.
--> Either roughly approximated, but preferable by picking the value with the mouse on "Enthalpy image"
How do you know you even need an answer to that question? How do you know you need that List? I am not convinced you need either. Work out the measures for one pump, and when you have that working, you can consider multiple pumps. You need to program one step at a time. You also need to realise that there is an inverse correlation between amount of work done and amount of code written. The more work you do thinking, the less code you will actually write. The less work you do thinking, the more time you will have to write code. So somebody who writes 500 lines in a day has probably done less work than somebody who writes 100 lines.
To my original question: . . . Where to put (certainly badly named : "updateAllMeasureListElem()") . . .
Maybe there is such a thing as an enthalpy value, and that can be calculated from temperature and pressure, and the actual enthalpy varies depending on the constituent(s) of the gas. Maybe you can have a calculateEnthalpy() method which takes temperature and pressure as parameters. If that method neither uses nor alters any instance fields, then it is a 1368 in the most dubious classification of methods known to modern science. In which case it might well be static. As an alternative, make an Enthalpy object which takes temperature and pressure in its constructor and has enthalpy as a field. Make all the fields final, and make the class final. Give it getXXX methods (3 of them) and no setXXX methods. If the fields are all double type (or Double), then you will have created an immutable class, which has all sorts of advantages. Override the toString equals and hashCode methods.
. . . My RAT KINGs 2
By sense "Measure" is not an "Enthalpy": --> so no Inheritance . . .
Ça ne fait rien
Merci à tous :-)
Your UML for an Enthalpy class will be very simple. And it will not change if you change the method of entering the enthalpy. It will however change if you add a volume field to the Enthalpy objects.
. . . PS: Relative to UML, my goal is just to have some basics, in order to represent in a nice form the approach of reality
Christian Klugesherz wrote:
So I will try to explain :
A heat-pump is composed of different elements
a list of all these elements
Also, I can add, new individual items, and combine later, in order to simulate any Head Pump.
(The other name of performance = COP)
Finally, to compute performance, == feed Class cCop, you have to pick the Measure values (Pressure, Temperature) on a real Head Pump.
You are not ready to think about enumerations (they are not called that; they are enums or enumerated types). Get one measurement point working and then it will be easy to create more, and you can decide whether to put them into Lists, arrays or whatever.
Christian Klugesherz wrote:. . . M0,M1,M2, M3, ... are representing the measure points chosen from enumeration.
. . . "Il n'y a pas de quoi" . . .
Junilu Lacar wrote:Instead, it has a single method that gets all the information it needs to do its job from external sources. This is not an object, it's simply a function masquerading behind the accoutrements of a class.