The following diagram shows the (only) class of objects in our system: an object called “Hops”. This has attributes of HBU’s, Alpha acid (%) and Weight (oz). There are three operations which correspond to the attributes. These three operations are used to derive one attribute from the other two.
At the analysis level we don’t say much about the GUI, events, frames, panels, applets, browsers and networks. Those are all vehicles for an implementation. Here we are trying to capture the problem succinctly and accurately.
The following diagram shows how the entry of attributes leads to state changes and the computation of one given the other two. The essential state transitions occur when an attribute value is set. This dynamic model is vague, and only represents the barest minimum of requirements.
Initially, no attribute is know – all three are unknown. One is set, reducing the unknowns to two. When a second attribute is set, the third can be computed. Once all three are known, a change in one will lead to computation of the one “least recently changed.”
For example, first you set HBU’s and then set Alpha acid. The model computes weight. If you adjust the HBU’s or alpha acid, the weight is recomputed from your entry of HBU’s and alpha acid. If you adjust the weight, HBU’s (the least recently entered) are computed from weight and alpha acid.
This diagram shows the interfaces and data flows. Pretty trivial: a user (actor) interacts with the hops model. We can design any appropriate interface, as the requirements impose no specific type of solution. More complex situations may impose a number of interfaces or other details.