Working Smart in How You Apply What You ve Learned

Working Smart in How You Apply What You've Learned

Mathematically based techniques, such as model-based specification, are called formal methods. As with any rigorous technique, you might not want to apply it to every use case. And you might not even want to apply the full technique. So, let's see if we can put things in perspective and look at ways to apply what you've learned in a sensible manner, namely:

• Prioritize where you apply model-based specification

• Stick to numeric problems

• Or, forget everything else and just use three simple rules!

Prioritize Where You Apply Model-Based Specification

The first suggestion is to prioritize where you apply model-based specification. A good approach to applying this technique would be to triage use cases based on riska function of frequency of use and criticality of the use caseand apply it to high-risk use cases. A low-tech, visual approach to the triage of use cases is a "Boston Matrix" with the horizontal axis representing frequency of use and vertical axis representing use case criticality (see Figure 5.14).^[14] Each use case is assigned to one of four quadrants as shown below, with high-risk use cases receiving the most attention. The upper-right quadrant represents those use cases that are both frequently used and critical in nature, and where the biggest bang for the buck from applying failure analysis via model-based specification will come from.

^[14] Additional techniques for helping to triage use cases based on frequency of use and criticality are provided in Part 2, "Software Reliability Engineering." Part 1, "Quality Function Deployment (QFD)," provides help in the use of QFD to prioritize use cases by business drivers in general.

Figure 5.14. Boston Matrix-style approach to triaging use cases based on frequency of use and criticality.

Stick to Numeric Problems

All the examples in this chapter have been ones where the model was numeric in nature (e.g., models of money, widgets in stock, and rates of flow). Numeric problems probably provide the biggest "bang for the buck" application of model-based specification. First, there are many, many problems that can be stated numerically; after all, numerical computation is the birthplace of computing. Most applications, even if not predominantly numerically oriented, are likely to have some component that is numeric in nature. And second, applying this technique to numeric models is as easy as it gets, requiring little more than simple algebra.^[15] So the combination of the wide range of problems to which it can be applied, coupled with ease of learning and ease of use, makes the application of model-based specification to the numerical component of use cases a high ROI proposition, especially when the cost of failure is high.

^[15] Model-based specification of non-numeric problems requires models using sets and relations; fairly simple ideas from set theory but they are more difficult.

The Absolute Least You Need to Know: One Fundamental Lesson and Three Simple Rules

If, prior to reading this book, your only exposure to preconditions and postconditions has been via the use case literature, this chapter may be a bit like as they say"drinking from a fire hose." So if you are thinking this is way too complicated, let me leave you with one fundamental lesson and three simple rules that anyone can use on absolutely any use case anytime. Period.

As I noted previously, mathematically based techniques like this are called formal methods. I coined the term Blue Collar Formal Methods to capture the idea that for many formal methodse.g., model-based specificationthere is often a less rigorous application of the method that provides benefit without necessarily getting into all the math. It's like there is a fundamental lesson to be learned from the formal method, but when learned you can use that lesson without the math itself.

What would a Blue Collar version of this technique look like? Do you remember that at the start of this chapter I made the comment "If you look at your favorite book on use cases you are likely to find use cases with preconditions but no postconditions (the significance of which will make sense later)…". Do you see the significance now? If preconditions are calculated from a postcondition to preserve an invariant, what sense does it make to have a precondition without a postcondition or an invariant?

Here then is the fundamental lesson that model-based specification teaches:

Preconditions, postconditions and invariants work as a team. They travel as a trio. If you see one without the others, something is missing! Remember, the team that plays together stays together.

Here are three simple rules for applying that fundamental lesson:

1. When you write or see a lone precondition for a use case, your first thought should be, "Hmm…I wonder what happens if it fails?". Ask yourself what postcondition it is associated with and what hazard (violated invariant) it prevents the postcondition from causing. Yes, you intuitively know that precondition is needed, but take some time to try and identify why it's needed and the consequence of its failure. Remember: the precondition is part of a trio; find the rest of the team.

2. Postconditions are where the action is at in the use case, describing the output produced and state changed. And it is precisely when you are generating outputs and changing state that bad things can happen. When you write or see a lone postcondition, ask yourself, "I wonder what hazard this postcondition poses (violated invariant) and what precondition could prevent it?" Think team. Think trio.

3. Start thinking in terms of what must always be true about a use case (i.e., its invariants). A good way to identify invariants is to think about what can go wronghazard identificationthen work backwards from the hazard to identify what needs to stay right to prevent it. And once you have identified an invariant look for operations whose postconditions could violate it, then apply rule #2.

Finally, for failure analysis and test design these rules need to be applied at the operation level (i.e., to the individual steps that make up the use case).

That's it. Math aside, that is the heart of model-based specification condensed into one fundamental lesson and three simple rules that reflect the tight coupling between preconditions, postconditions, and invariants: something not readily evident from the use case literature, but something you need to know!