What I've gotten so far about AssociationClass is that it isn't about programming, it's about modeling, e.g. with UML. I'm seeing here an answer to a question that I'd never ask. Let me elaborate in hopes that someone will explain that I'm wrong.

To me, the workflow monitors thing would go this way:

I'm implementing a WorkFlow system. I have monitors monitoring things (stages?). When a monitor goes off it should generate a task from a task factory. (I'm assuming from Peter's text that the task generated by the factory is a function of the monitor. Wish I had  his code.)
So I've got code in Monitor that does that:

 monitorFires
   Task_Factory generateTask: self

Now it evolves that depending on the stage, which I suppose is an instance variable in the Monitor, I need a different task created for generateSpecificTask. So I need to look up the monitor based on stage:

 monitorFires
   self taskFactory generateTask: self

where Peter tells me that taskFactory is a function of the class of the stage ''and' the class of the monitor. (I note in passing that this seems suspicious, in that things depending on the classes of other things is a danger signal, but I'm going with it.) So I build a dictionary in each monitor class mapping from stage class to taskFactory class:

 taskFactory
   ^self class taskFactoryDictionary at: stage class

on the class side, possibly in a Class Instance Variable (another danger sign):

 taskFactoryDictionary
   Task_Factory_Dictionary isNil ifTrue: [self initTaskFactoryDictionary].
   ^Task_Factory_Dictionary

 initTaskFactoryDictionary
   ^Dictionary new
     at: First_Stage put: First_Stage_Factory;
     at: Second_State put: Second_Stage_Factory;
     yourself

Now, I'm having trouble believing that these are the requirements, but if they were, and understanding them only as well as I now do, I might refactor from the first case, with one factory, to this one, with one per stage class per monitor class.

''[I also had trouble believing these were the requirements in this instance. But they are. --PeterMerel]''

I could imagine an alternative structure for representing this information, ala a relational table, factoryTable, with fields Monitor_Class, Stage_Class, Factory_Class, key fields Monitor_Class and Stage_Class. Then the Factory_Class is answered by:

 taskFactory
   ^self taskFactoryRecord factoryClass

 taskFactoryRecord
   ^self factoryTable
     detect: [ :each | each monitorClass = self class 
       and: [each stageClass = stage class]]

[Now I'm guessing, having written this, that my factoryTable may be what Peter et al would call an associative array?]

And now I can ask the question that is answered "AssociationClass".

Ron: "What is the generic name for the object representing the relationship between monitor, stage, and factory?"

Peter: "We call that an AssociationClass, and in UML we draw it thusly."

Have I got it right? If not, can you fix me? (For that matter, if so, can you fix me?) --RonJeffries
  
----
I'd just call it a map or table of some sort.  UML uses the phrase AssociationClass for something else. -- MichaelFeathers

Bummer. Then I still don't get it! Guess I'll look in the book.  --rj

''Fwiw, I think you get it just fine, Ron. But maybe I'm mistaken and this feature of UML, without which I pragmatically would not do, is, as Michael insists, useless. I remain to be convinced of this, and I honestly wouldn't much care if UmlDistilled or the ThreeAmigos themselves thought otherwise. YMMV.'' --PeterMerel