Composition of Problem Frames

Ivan Marsic • Rutgers University 144

3.4 Specifying Goals

The basic idea of goal-oriented requirements engineering is to start with the aggregate goal of the whole system, and to refine it by successive steps into a goal hierarchy. AND-OR refinements … Problem frames can be related to goals. Goal-oriented approach distinguishes different kinds of goal, as problem-frames approach distinguishes different problem classes. Given a problem decomposition into basic frames, we can restate this as an AND-refinement of the goal hierarchy: to satisfy the system requirement goal, it is necessary to satisfy each individual subgoal of each basic frame. When programmed, the program “knows” its goals implicitly rather than explicitly, so it cannot tell those to another component. This ability to tell its goals to others is important in autonomic computing, as will be seen in Section 9.3 below. State the goal as follows: given the states A=locked, B=lightOff, C=user positively identified, D=daylight Goal is the equilibrium state to be reached after a perturbation. Initial state: A ∧B, goal state: ¬A∧¬B. Possible actions: α—setOpen; β—setLit Preconditions for α: C; for β: D We need to make a plan to achieve ¬A∧¬B by applying the permitted actions. Program goals, see also “fuzzy” goals for multi-fidelity algorithms, MFAs, [Satyanarayanan Narayanan, 2001]. http:www.cs.yale.eduhomeselkin Michael Elkin The survey “Distributed approximation,” by Michael Elkin. ACM SIGACT News, vol. 36, no. 1, Whole Number 134, March 2005. http:theory.lcs.mit.edu~rajsbaumsigactNewsDC.html The purpose of this formal representation is not to automatically build a program; rather, it is to be able to establish that a program meets its specification. Chapter 3 • Modeling and System Specification 145

3.5 Summary and Bibliographical Notes

This chapter presents … I have seen many software-development luminaries gripe about software quality see [Jackson, 2001], Ch.12 Microsoft Word example. I feel that the situation is much more complex than ensuring quality. Software appeal depends on what it does functionality, how good it is quality, and what it costs economy. Different people put different weights on each of these, but in the end all three matter. Microsoft figured that the functionality they deliver is beyond the reach of smeller software vendors who cannot produce it at a competitive price, so they emphasized functionality. It paid off. It appears that the market has been more interested in low- cost, feature-laden products than reliability for the mass market kind of products. It worked in the market, thus far, which is the ultimate test. Whether this strategy will continue to work, we do not know. But the tradeoff between quality functionality economy will always be present. Also see the virtues if the “good enough” principle extolled here: S. Baker, “Why ‘good enough’ is good enough: Imperfect technology greases innovation—and the whole marketplace,” Business Week, no. 4048, p. 48, September 3, 2007. Online at: http:www.businessweek.commagazinecontent07_36b4048048.htm Comment Formal specifications have had lack of success, usually blamed on non-specialists finding such specifications difficult to understand, see e.g., [Sommerville, 2004, p. 116; Larman, 2005, p. 65]. The usual rationale given for avoiding rigorous, mathematically driven program development is the time-to-market argument—rigor takes too much time and that cannot be afforded in today’s world. We are also told that such things make sense for developing safety-critical applications, such as hospital systems, or airplane controls, but not for everyday use. Thanks to this philosophy, we can all enjoy Internet viruses, worms, spam, spyware, and many other inventions that are thriving on lousy programs. The problem, software ends up being used for purposes that it was not intended for. Many of-the- shelf software products end up being used in mission-critical operations, regardless of the fact that they lack robustness necessary to support such operations. It is worth noticing that often we don’t wear what we think is “cool”—we often wear what the “trend setters” in our social circle, or society in general, wear [Gladwell, 2000]. But, as Petroski [1992], echoing Raymond Loewy, observes, it has to be MAYA—most advanced, yet acceptable. So, if hackers let the word out that some technique is cool, it shall become cool for the masses of programmers. Bibliographical Notes Much of this chapter is directly inspired by the work of Michael Jackson [1995; 2001]. I have tried to retell it in a different way and relate it to other developments in software engineering. I