When, What, Why create system and software models Roger L. Costello March 26, 2018

Contents When to model? What to model? Why model? Does modeling lead to more dependable software?

When to model? For any given problem, ask: Is formalism necessary? Is the problem sufficiently intricate that it can’t be addressed by informal thinking? If so, then model the problem. That said, most people underestimate the intricacy of problems, so modeling should be applied more broadly. Model whenever anything but the lowest levels of dependability is required of the software.

What to model? The Principle of Partiality says that Alloy models should be created for those parts of a problem that merit the cost of formalization. Which parts merit the cost of formalization? This is a general engineering question of where to invest effort to mitigate risk or produce better outcomes. Model requirements, specifications, designs, and code. Modeling is done for a purpose, such as getting assurance on a design, requirements, generating code, generating tests, etc. That purpose will dictate which aspects to focus on (i.e., which parts merit formalizing).

Traditional software development approaches use specification and design notations that do not support rigorous analysis, as well as programming languages that are not fully defined or that defeat automated analysis. Traditional approaches depend on human inspection and testing for validation and verification. Strong approaches also use testing but employ notations and languages that are amenable to rigorous analysis, and they exploit mechanical tools for reasoning about properties of requirements, specifications, designs, and code.

Why model? Does modeling lead to more dependable software? I created an Alloy model I then implemented the software Just because the model is rock-solid, doesn't necessarily mean the ensuing software implementation will be rock-solid. Right? I might do a lousy job implementing it.

Two reasons the software is likely to be more dependable than if you hadn’t created a model You can show that each code module meets its model specification. If you have a clear and simple model, then it’s more likely that the implementation will be straightforward and the credibility of more low cost and incomplete analysis such as testing will be higher.