The team identified the following tasks as necessary to complete this story:
- Design the user experience
- Implement the user interface
- Design the domain model in UML
- Implement the domain model with unit tests
- Bridge together the domain model and user interface
In this way, the team set up two roughly parallel tracks: user-facing and domain modeling. I was scheduled to meet with a group yesterday morning to mentor them through the initial domain modeling step, but we ended up postponing this for two reasons: team members encountered unexpected complications in the asset pipeline we wanted to use, and the user experience ideas were not yet sketched in sufficient detail to ensure that we were safe to move forward.
This morning, two of the technical team and I cleaned a large section of whiteboard and began our UML process. I suggested that we start with use case analysis. In our discussion, I discovered that both of these students are also in the department's Software Engineering class, where they had recently had an introduction to UML, so we did not need to start from first principles. We sketched six use cases.
I explained that it was common to do dynamic modeling next, and that the static models would fall from this. They were both familiar with sequence diagrams and were eager to use them, but I explained that I prefer communication diagrams—especially when I'm not quite sure where I am going. We started with a Village object and began to talk through the use cases to determine the behaviors. We added an object, showed a message, removed the message, added another object, added a new message, removed it, and added another, ... and then I realized that this was the wrong tool for the job. Our conversations were good, but our notation was just getting in the way of the exploration.
It hit me that we needed CRC Cards.
|Use cases relevant to our feature|
It hit me that we needed CRC Cards.
One of the two students had taken Advanced Programming with me during a semester when we used CRC cards, but he was rusty; the other had never heard of them. I gave a primer and made a template to show the class, responsibility, and collaborators sections and their purpose. We got a stack of orange index cards, put them in the middle of a mid-sized table, each grabbed a pen, and got to work. I showed how once again we could start with the concept of Village, and we marked that it maintained a list of idle villagers. From here emerged our Villager class, which we marked as having a status of "idle" or "farming."
Something seemed wrong, so I stopped the discussion there and looked over the cards. We were defining attributes, not responsibilities. Starting again from scratch, I explained that we wanted to focus on the messages that were passed among objects, not the internal representations. This led us to a nice small set of seven classes that fell out of our conversation.
We picked up the cards and moved back to the whiteboard, where we designed an initial class diagram. This is mostly their work, with my prodding them to consider only the public details for now. The most interesting interaction described in the cards is between Clock and Farm: a farm generates food based on elapsed time and the number of workers. As we talked about it, I pointed out that it sounded like the Observer design pattern: as the clock ticks, it notifies listeners, and they react as they need to. I showed them how to sketch that architecture and identify the pattern using collaboration notation, as I picked up from Holub on Patterns years ago.
|CRC Cards for the first feature|
At the conclusion of the session, the two students expressed confidence that they could continue this process with the next feature on the backlog. Notably, they mentioned being confident that they could do it and that they could involve other members of the team. It's a sharp team, and I look forward to seeing how these "big ideas" get disseminated across the group.