Firstly - what you are asking seems rather
dynamic. Method calls are modeled in sequence and collaboration diagrams
with messages between objects (with static operations being messages to the
class object and not an instance of the class).

I suspect you are really asking how do I express these relationships in a class
diagram though. In the first case you are right the best way indicate
this is with a dependency. But remember that a dependency doesn't mean a class calls
static operations on another class - it just means that one class of object
depends on the other, and that changes to the other's interface or structure is of interest
to the first (or more obviously: one class depends on another). Modeling
actual methods calls can only be done in an interaction diagram.

In the second situation, if you have a static
member variable in Class A of type B you would represent this as a normal
association, where the role specifier is either underlined or prefixed with a
dollar sign to indicate that this is a static member and not an instance
member.

If you don't have a static member variable, and
instead instantiate and manage the object instance's lifecyce in the context of
one static method call, then you could just draw a second dependency to Class B
and attach a note to it, indicating why it was different. Personally I
wouldn't do it that way, but rather indicate any wierdness in a note, or most
likely in an interaction diagram.

Remember the class diagram can only show structure
and structural relationships between the things in your application, and not
dynamic things.