Hi Matt,
I don't mean to be overly dogmattic but UML is not a process, its only a modeling language. Design and development processes use UML as a communication tool. Perhaps the conceptual misunderstanding is causing some of your confusion.
For business process modeling I usually depend upon "Business Modeling with UML" by Eriksson and Penker (OMG Press/Wiley). It has provided me with a much clearer idea of the principles of process modeling.
Fundamentally, a goal is symbolizes a desired state of a resource. Goals are achieved by processes and can be expressed by rules, almost like a post-condition. A goal object is usually drawn at the top of a process diagram and has a <<achieve>> dependency.
A supplying object is a resource that participates in a process. It is not consumed or refined. They are usually shown at the bottom of a diagram, below the <<process>> with a <<supply>> dependency.
Input objects are like supply objects except that they are consumed or refined. They can be stereotyped as <<physical>>, <<abstract>>, <<people>>, or <<information>>. They usually appear on the left side of the diagram in relation to the <<process>> and are connected to the <<process>> with a dependency.
The <<uses>> stereotype is worthless in my opinion. It is far to general to communicate anything of value. For instance, a <<process>> uses resources, but <<supplies>> takes care of the situation just fine. A <<process>> can also use a subprocess, but <<controls>> seems to fit the bill more concisely.
hope this helps.
-- dave
