Now I’ve got my CI server ready to build my project when I make a change and SonarQube installed and ready to tell me off for coding errors and test coverage, I can actually start planning to write some code.

I need to plan out my model. There have been sections in a couple of modules about this so I think it’s probably best to use the method taught at the OU – that should hopefully get me some brownie points. Basically I need to describe the product and then pull out nouns and noun phrases as class candidates.This should hopefully also get me some basic attributes for the classes to. So here it goes…

The system’s scheduler will kick off a process twice a day. In the morning the system will check a weather service for key pieces of data – did it rain overnight, if so, how much, is it predicted to rain today and if so, how heavy will it be? Using this weather forecast and history the system will be calculate whether the garden should be watered and for how long. If the system decides that the garden should be watered then it will send a request over the network to one or more nodes to open their valves for a set amount of time. The nodes will reply with a response containing a success or failure status and any errors if they occurred. The weather forecast, request to the nodes and response from the nodes will be saved into the database.

This process will be repeated in the evening to check whether the forecast was correct and no action is needed or whether the garden needs watering.

A web interface will be provided so that users can see a history of watering jobs, their status and any errors associated with them. Users will also be able to see charts displaying information regarding water usage and rain fall for set periods of time. Finally users will be able to initiate watering through the interface.

From the description we try and pull out some relevant nouns and decide if they are a possible class, attribute of a class or should be rejected.

  • System –  the whole system, out of scope
  • Scheduler – Possible class
  • Process – Possible class
  • Day – Event
  • Morning – Event – could be an attribute of process?
  • Weather service – Possible class
  • Pieces of data – Too vague
  • Weather forecast – Possible class
  • Weather history – Possible class
  • Rain – Possible attribute of weather forecast
  • Garden – out of scope
  • Request (to water) – Possible Class
  • Node – out of scope
  • Valve – Interface to which could be a possible class
  • Amount of time – attribute of RequestToWater
  • Response (from watering) – Possible class
  • Success or failure status – possible attribute of ResponseFromWatering
  • Error – possible attribute of ResponseFromWatering
  • Request to the node – duplicate of RequestToWater
  • Response from the node – duplicate of ResponseFromWatering
  • Database – Possible class (Data Access Object (DAO))
  • Evening – Event
  • Action – duplicate of RequestToWater?
  • Web interface – too abstract
  • Watering job – Same as process?
  • User – Possible class
  • Chart – Possible class
  • Water usage – Possible class
  • Rain fall – Possible class
  • Period of time – an attribute of a request for data?

The web interface is part of a later phase so we’ll disregard possible classes from there for the time being.

For our key domain I think we have…

Scheduler

  • Morning trigger time
  • Event trigger time

Weather Service

Weather Forecast

  • Probability of rain
  • Predicted temperature

Weather History

  • Did it rain?
  • Amount of rain
  • Average temperature

IrrigationRequest

  • Amount of time to water

IrrigationResponse

  • Success?
  • Error(s)

Process/Job

  • Time Started
  • Started manually or by the scheduler
  • Forecast
  • History
  • Request
  • Response

DAO

I think that looks like a good place to start. I’m sure I’ll need some more attributes and such. In addition to actually setting up the classes I want to get the architecture in place to do persistence tests in the build using a lightweight database like H2.