Our next step was to more formally define the classes and their relationships, using the graphical notation. We went through several iterations on this process.

• We started out identifying a "LivingObject" class. We decided that a LivingObject knew whether it was alive (live attribute) and what it's position was in the ocean. We also decided that it would need to know how to be eaten (beEaten service).
• Being eaten, we decided, involved more than setting live to dead. It also meant removing oneself from the ocean, so the LivingObject needed to know about the ocean.
• Not all LivingObject's eat, at least in our simulation. Plants, for example, just get eaten. We created Plant and Fish subclasses of LivingObject.
• Then we decided that Fish should know how to move and eat, but Plants didn't really need to know more than any other LivingObject. So, we renamed LivingObject to LivingOrganism.
• We added our queue (OceanQueue) to keep track of simulation time and to track which fish can eat. We decided that OceanQueues would know how to activate, which would involve telling all of their fish to activate. They would also keep track of simulation time.
• Fish should also know who they eat (food attribute).
• When Fish activate, we decided, they would move then eat, if there happened to be something that the Fish considered food at the position it was at -- but only if the Fish were alive.
• But what is to prevent a Fish from eating something that was already dead? We could have the fish query the food object, to see if it was alive, but that doesn't make sense if the food has been eaten. We decided that we would have an Ocean which would keep of its occupants. Oceans would be informed when something died (so that it would no longer be an occupant of the ocean), and oceans would inform LivingOrganisms if something which it considers food is available (isFood:at:at:).
• LivingOrganisms now also have to know about their ocean so that they could tell the ocean when they had passed on.
• But now there was a real problem. We had two collections of ocean organisms: the Ocean's occupants (for living or dead) and the OceanQueue's fish (to tell them each to move and eat). Clearly, these should be mergeable, but the OceanQueue's job was really an artifact of this being a simulation, not really part of the problem domain. So while it wasn't the cleanest design, we had a good rationalization for leaving it that way.