In this phase, The main idea is about use cases. Use cases are basically anything that a user can do with a program. For example, in a web browser, one can load web pages. Use cases are very general and they solidify the functionality of the project.
Use cases can be represented in UML as a use case diagram. The use cases for DotSlashGarden are shown in Fig.1.
![]() |
| Fig.1 - The use case diagram for DotSlashGarden. |
Although these use cases are somewhat self-explanatory, there is a formal way to do them. However, this takes a lot of space, so I shall exclude it from this post. If you wish to see them, you may do so here. The only thing you may need to know about that document is, at the end of each use case, a type of notification is made announcing what occurred. This notification will become a log file that I can view in order to monitor the hydrogarden.
You probably noticed the stick figure with the name "Actor" below it. The actor represents what is interfacing with the program. Because the hydrogarden can be operated either by automatic or manual commands, the actor must represent both. Fig.2 is a visual depiction of this idea. This is perhaps a bit over-the-top, but I want to be crystal clear with my reasoning.
![]() |
| Fig.2 - A sequence diagram explaining Actor. |
![]() | ||||||||||||||
| Fig.3 - A chart matching requirements with use cases. |
REQ1: Turn on light
REQ2: Turn off light
REQ3: Monitor pH
REQ4: Monitor nutrients
REQ5: Monitor water level
REQ6: Aerate water
REQ7: Take photo
UC1: Check water level
UC2: Check pH level
UC3: Check nutrient level
UC4: Turn pump on
UC5: Turn pump off
UC6: Turn light on
UC7: Turn light off
UC8: Turn webcam on
UC9: Turn webcam off
As you can see, all requirements are matched with a use case, so we can now move on.
The last part of the elaboration phase is to create analysis classes. In object-oriented programming (OOP), classes are used to describe the various parts of the program. From these classes, one can propagate objects, which do the work of the program; however, this story is for another post. Analysis classes are the basic framework of the program and contain no code. They simply give a rough outline of the program, or, in this case, the program and the device.
Analysis classes are made with Class Responsibility Collaboration (CRC) cards. These cards consist of a class name, a description of its purpose, and lines showing how they work together. Fig.4 shows CRC cards in action.
![]() |
| Fig.4 - Analysis classes for DotSlashGarden |
In this diagram, one would see the typical classes one would expect, such as Light and Webcam, but there are also classes that are unfamiliar, such as the Mediator and Scheduler. These classes will be used to control the interactions in the program.
- Mediator - provides an interface for the physical hydrogarden parts. In other words, if you wanted to turn on the light, you would use the mediator to do that ( i.e. MyMediator.LightTurnOn() ) instead of accessing the light directly ( i.e. MyLight.TurnOn() would be protected ). This pattern decreases coupling and makes for uniform access.
- Scheduler - processes automated operations. This allows the hydrogarden to operate automatically
- Commander - processes manual commands. This allows the hydrogarden to handle user-defined, on-demand commands, which gives the user control.
- Reporter - creates notifications. The log file it creates can be used to see what the hydrogarden is doing.




No comments:
Post a Comment