I'm starting on a piece of software that will include dealing with probability distributions.
I'm trying to design it using class diagrams, and ran into a design issue which I've extracted out here (not coding it up just yet).
I've got two random variable instances, X and Y. They have a Probability, which I've subclassed as P(X) and P(Y) from Probability.
Should I have a "probability of" association going from the variable instances to the probability values? Or is this a redundancy in my design?
Thinking in terms of actual code, I think I'd only have an association between P(X) values and my X instances... would this mean it is the association with the superclass Probability that is redundant?
If so, I would have an unspecified number of associations for an unspecified number of Random Variable instances... though that might actually be what my code would look like. Would not having these associations in the diagram and only having an association with the superclass "Probability" suffice to describe my system?
My reasons for expressing this in UML (responding to comment below): I suppose I could express my probabilities as merely a function on some objects and store this in some sort of map... then have some function that ensures invariance that the sum of all probabilities sums up to 1 etc... then I could add more data and have to revisit and rework my whole map... which would affect joint distributions... and so on and so forth adding complexity and making any sort of procedural approach quite messy. Not that a procedural approach wouldn't work, but I really want a clear, object-oriented picture of the software I'm going to build. Class diagrams seem like a pretty good tool to do this. I want to think of each distribution as an objects, not something generated procedurally.
Overview
You do not need the "Probability Of" associations from "Y" to "P(Y)" or "X" to "P(X)". They are redundant.
Your "Probability Of" class or object represents an association. Leave the associations form this class to an object.
Sometimes an operation, method or association, can also be represented or conceptualized as a Class or as an instance of a class (a.k.a. "Variable").
Long Boring Extended Answer
Modeling Objects, classes, and associations, maybe be a little cumbersome.
You have a variable that will have some value at some time.
Object Diagram 1 (Incomplete)
...............
..+---------+..
..| 5 |..
..+---------+..
...............
Since, UML was designed to model programs, you need to specify its type, in this case, your value is not a full object, just a floating point number.
Object Diagram 2 (Incomplete)
...............
..+---------+..
..| Float |..
..+---------+..
..| 5 |..
..+---------+..
...............
If it was more complex values, you may use properties, methods, and other UML features, but, by the moment, this is not the case.
There could be other values, for the same concept or variable, example:
Object Diagram 3 (Incomplete)
............................
..+---------+..+---------+..
..| Float |..| Float |..
..+---------+..+---------+..
..| 5 |..| 3.1416 |..
..+---------+..+---------+..
............................
..+---------+..+---------+..
..| Float |..| Float |..
..+---------+..+---------+..
..| -55.12 |..| 0 |..
..+---------+..+---------+..
............................
Each one of the value may have several other values that represent the probability.
Therefore, there is an association between each original value, and the probability values.
Let's model some object examples.
Object Diagram 4 (Incomplete)
....................................
..+---------+..........+---------+..
..| Float |..........| Float |..
..+---------+..........+---------+..
..| 5 +-------+--+ -444 |..
..+---------+.......|..+---------+..
....................|...............
....................|..+---------+..
....................|..+ Float |..
....................|..+---------+..
....................+--+ 0 |..
....................|..+---------+..
....................|...............
....................|..+---------+..
....................|..| Float |..
....................|..+---------+..
....................+--+ +1 |..
.......................+---------+..
....................................
There could be more examples for each original value, and its probability values, but, it could be very complicate to represent them.
Let's change this example Object Diagram to a more conceptual Class Diagram.
You have a class diagran that represents a variable, or can be instantiated by a variable. In some moment of time, you will store the value of that variable.
And, let's call it ´X´.
Class Diagram 5 (Incomplete)
..................
..+------------+..
..| X: Float |..
..+------------+..
..................
Remember that ´X´ represents or has a single value, at a time, but, it can change.
Now, there can be several probability values for ´X´. Let's represent all of them with a single class box, instead of many.
And, call them ´PX´ without the parentheses, because they cannot be used as variable or class names in UML.
Class Diagram 5 (Incomplete)
........................................
..+------------+........+------------+..
..| X: Float |........| PX: Float |..
..+------------+........+------------+..
........................................
Since, this pair of values are related, let's add a line to represent the association.
Class Diagram 5 (Incomplete)
........................................
..+------------+........+------------+..
..| X: Float +--------+ PX: Float |..
..+------------+........+------------+..
........................................
But, for each value of ´X´ can be several values of ´PX´, let's add a diamond to indicate it.
There are cases when there is a one-to-one association, but, this case is one-to-many association.
Class Diagram 6
........................................
..+------------+...../\.+------------+..
..| X: Float +----< >+ PX: Float |..
..+------------+.....\/.+------------+..
........................................
The diamond is drawn near the box that represent the "many" values.
Let's add an optional label to explain the goal of the association.
And, an arrow to indicate how to apply this arrow.
Class Diagram 7
........................................
..........<<..Probability Of............
..+------------+...../\.+------------+..
..| X: Float +----< >+ PX: Float |..
..+------------+.....\/.+------------+..
........................................
Summary
There can be several kinds of associations, you use the "inheritance" association, that does not apply to your case.
Object Diagrams are good for specific examples and have values, and does not use variables frecuently.
Class Diagrams are conceptualizations, and usually have variables or properties, and use values only for initial values, or constants.
Many UML developers, skip Object Diagrams, and use Class Diagrams, directly to represent some scenario. Altougth, Object Diagrams, still are useful.
"Object Diagrams" are represented with rounded boxes, Class Diagrams use sharp corners. I could not represent them well with the ASCII examples.
The background dots does not appear in an UML diagram, I just use it, to highlight the diagrams.