I know that. The problem is that professors at university never got to explain clearly the basic laws of thermodynamics, so when I read this...
http://en.wikipedia.org/wiki/Thermodynamics#The_laws_of_thermodynamics
...I still do not understand it.
They never got to explain clearly the concepts of entropy, work on the system (applied to the system) vs work by the system (applied to something else), and the boundaries of a thermodynamical system, so you can see input-process-output.
Entropy is sort of nonsensical. It was created because the First Law of Thermodynamics makes no statements about the direction of energy. The First Law states that the energy of a system is conserved. That's all fine and good but with the First Law alone, this means things like coffee cups shattering and perfectly reassembling themselves is completely possible. The reason that isn't possible is because energy from the cup is dissipated to the environment and it can't be returned -- entropy is like a measure of the inefficiency or random energy a system can lose. It's used in more complex Thermo problems when you lack enough state variables (pressure, temperature or volume) to predict the next state. Because you know the system will only gain entropy at state 1 you can calculate the current entropy and use it to get the entropy at state 2. I'm a little rusty on my Thermo (I've been working dynamics for the last 2 years and haven't touched the stuff so accept my disclaimer of fuzzy memory). I'm told the actual numerical meaning of Entropy makes very little sense unless you take a course in Quantum Mechanics.
Work by the system vs. Work on the system is more a personal preference than anything else. As long as you're consistently setting the boundaries of your system and analyzing them separately (not counting anything twice) then you're good to go. That's why teaching it is so problematic. There isn't a set down rule that [X] is how you define system boundaries. It's instead developed on a case-by-case basis in which you decide what definition is easiest for you to work in. For instance, let's say you need to simulate fueling from a tank. Because you're not designing the tank, and you're not concerned with the tank's effect on anything else, you make the inside of the tanks (The one holding fuel and the empty one you're fueling into) your system. Initially, it's closed off, and let's say there's a vacuum in the empty tank. You open the valve and immediately the pressure and temperature of both tanks changes. Volume is constant. But because we've limited the system to the internal volume of the tanks, we don't have to worry about the effect of things like the space environment (radiation, external vacuum, other structure, etc...), it's just a simply temperature and pressure problem (assuming we're working with a gas which allows us to assume it expands to fill the tank).
As far as coding goes, it often helps to define objects with some set number of inputs and outputs. If you're talking about a spacecraft then I'd break it down like so:
Inputs/Outputs
Fuel
Oxidizer
Oxygen
Nitrogen
Inerts (like Helium in propulsion systems)
Consumables (Water, Food, Batteries)
Inert Payload
Inert Passengers
You track the mass of each one of those. Your spacecraft is the system, so things like Inerts, Consumables, Payload and Passengers don't have any effect on the total mass (they can't leave the spacecraft unless something went seriously wrong). Fuel and Oxidizer leave the spacecraft in known quantities proportional to throttle setting and atmospheric pressure. Oxygen and Nitrogen are consumed in known quantities as well based on the number of people and the type of activity they're performing but they never leave the spacecraft. Instead they're converted into CO2, but for a simple system you can think of O2 and N2 as simply decreasing.
So if you want to get something small running, I'd leave it at that. Then you can go in and divide the system/spacecraft into smaller systems like CO2 generation and filtering, waste production, water recycling, etc... which will affect how quickly your inputs and outputs (really just the consumables because Oxygen and Nitrogen will be consumed constantly) are consumed.
