In the last blog post, I talked about how the design workflow should only require one blog post. After planning how I was going to write it, I discovered there was a lot of explanation to do. Therefore, I will be splitting it into two parts: one about the structural diagrams and one about the behavioural diagrams; today we will just worry about the structural ones.
By structural, I mean how the program for DotSlashGarden will be written. This being said, the design workflow is more about the software than the hardware.
In
object-oriented programming (OOP), one thing that a programmer writes are the
classes. These classes describe the parts of the program, or, as one might say, its structure. Classes are represented in UML using
class diagrams (surprising, no?). These diagrams have the name at the top, the variables in the middle, and the functions in the bottom. The stuff in the middle, the
member variables, describe the information about the class. The
member functions describe what the class can do. They are called members because they belong to the class. After each member, there is a colon and a word which declares what
type it is. A class diagram for the parts of the hydrogarden are shown in Fig.1.
 |
| Fig.1 - A class diagram for the HydrogardenObjects |
You may notice a symbol prepended to each member. The (-) symbol means the member is private and only the class it belongs to can access it. The (#) symbol means it is protected and only its class or its friends can access it (seriously,
friend is a keyword in C++). The (+) symbol is public, therefore anyone can access it.
Programmers restrict access to certain members because it makes the program more stable and less likely to do something weird. Besides, if a program did not have to abide by rules, we would get the singularity, which is a different conversation entirely. If you want to know more about restricting members, you can do so
here.
If we focus our attention back to Fig.1, one may notice that the member functions fulfill the use cases established in the
elaboration phase. There are a couple of things to note in this diagram:
- Lack of a webcam class and separation of the pump class
I determined that because the webcam will be using
different software than the one I will be creating, there is no need to model it in this diagram.
As for the pump class, I decided that it was its own entity and things would be simpler if it became its own class.
- Arrows and lines with the circuit class
The three circuit classes at the bottom (
CircuitpH,
CircuitNutrient, and
CircuitLevel) have an arrow pointing to the
Circuit class because they are derived from it. Although each type of circuit is different, they have many things in common, such as they have input and output pins. The
Circuit class, which is called the
base class, contains these members. By deriving classes from the base class, I can reuse code because the information in the base class will be present in the derived classes. The
Circuit class is called an
abstract class because one would not be able to make an instance (or
object, as it is called) because it is not actually a real thing. This is much like the fact that a colour, such as green, is not a thing, but you can have something that is the colour, such as a leaf. An abstract class is illustrated with italics.
There is also a dashed line with a corner-folded box. This is a comment box and it says that the pin of the various circuits will be declared as external, or global, variables. This is used to simplify the configuration of the objects made from these classes. The rationale behind this will became more clear in the next blog post.
In the
Pump and
Light classes, there something in brackets with the name ExitStatus and is of type boolean. First of all, a boolean is a type of variable that is either true or false (1 or 0). This variable is used to tell the Reporter what to report. For example, if the Light.TurnOn(bool *ExitStatus) member is called, but the light is already on, ExitStatus would equal 1. When the Reporter sees this, it will recognize that an error has occurred and write about it in its log file. If the light was off, ExitStatus would be 0 and nothing major would happen. You can read more about exit status here.
The next diagram is also a class diagram, and it is about the HydrogardenInterface. You can see it in Fig.2.
 |
| Fig.2 - A class diagram for the HydrogardenInterface |
This class uses a pattern called the façade pattern, which means that it acts like an interface for the HydrogardenObjects (just as an aside, after typing these long-winded, over-explaining names a few times, I realize I will need to change them later). If you look at its member functions, you will see that it contains all of the use-case-satisfying, member functions from what it manages. This means that, instead of using the various hydrogarden parts individually, other classes must use the HydrogardenInterface to change the hydrogarden's state.
The next diagram, still a class diagram, shows what the Scheduler and Commander classes will look like. They are shown in Fig.3 and Fig.4.
 |
| Fig.3 - A class diagram for the Scheduler |
Both of the previously mentioned classes are responsible for enforcing the automation of this project. They are created based on what mode the program is running in, manual or daemon. Because of this, only one of them will be present at any given time.
Scheduler is used when the program is in
daemon, or automatic, mode. Therefore, it understands when and how to turn things on and off. As said by the comment boxes, the times are assigned by the so-called external variables and
Scheduler will retrieve the current time from an outside function.
 |
| Fig.3 - A class diagram for the Commander |
|
Commander is much like
Scheduler, except it does not fret about time, which is a feature I am sure all of us would want. Anyways, it provides a menu that the user can use to control the hydrogarden manually.
The last class diagram is of the
Reporter, which is Fig.4. This class has functions that log the activities of DotSlashGarden. These functions outline predefined events that may occur during its operation. Although there is the chance that something may happen that was not allocated for, this would be a bug, which are difficult to predict except in their existence.
 |
| Fig.4 - A class diagram for the Reporter |
The sole member variable of this class, RunMode, contains the mode of the program, manual or daemon. This information is used to determine whether to post notifications to stdin (standard input, which would probably be a console window) or the log file. Imagine if you were trying to use DotSlashGarden manually and, in order to see output from it, you had to look in a log file, and, in order to see future output, you needed to refresh it every so-often. This would be an absolute pain and, therefore, sending notifications to stdin would be easier. Simultaneously, if the program was running by itself, you would not want it to be outputting to the console, with no one ever to read it. This is why the RunMode variable exists.
The other type diagram that I drew for the structural diagrams is a deployment diagram. It shows what hardware will be used, the components of the hardware, and the interaction between the individual parts. This diagram is embodied in Fig.5.
 |
| Fig.5 - A deployment diagram for DotSlashGarden |
The top half of the diagram shows the devices I decided upon in the inception phase as abstract nodes, except for the hydrogarden of course. The bottom half shows the actual devices that have more familiar names, such as laptop and Internet. Inside these nodes, there are other, smaller boxes; these are called components. The lines between components and devices show how the work gets done in DotSlashGarden. For example, if I wanted to access the hydrogarden through my laptop, I would use SSH and the Internet to connect with the Raspberry Pi. From there, I would start an instance of garden and that would allow me to control the hydrogarden.
Supposedly, pictures are worth a thousand words, but, with my pictures, a thousand words accompany them. In the next blog post, I will talk about behavioural diagrams, explain more diagrams, and reveal how the software works.
No comments:
Post a Comment