In this blogpost, we argue that developing code should be replaced by developing models and writing contracts as part of those models. Our argument is that humans can understand models of reality (even complex ones), but they cannot understand programming code beyond a certain point of complexity. This non-understanding of program code leads to huge IT-failures.
The price of software you don’t understand
A recent study in The Netherlands alone, showed that large IT-projects issued by Dutch government resulted in an annual loss of 5 billion euro’s (which was about the same as the annual national deficit at that time). We can probably all come up with examples of IT-projects that have failed miserably in the past, and we will probably also be able to come up with examples that will fail miserably in the future. Let’s just face some facts: software is hard to write, it’s also hard to read, and domain experts (people who will use the software) cannot validate software correctness. Non-validated software can be hazardous, especially when reliability and safety issues are at stake. These risks can be financial, legal, health related, system critical etcetera. What can we do about this?
Tests are not sufficient
Software is a means to an end; the end being a product (an artifact) satisfying the needs of end users. Software is the stuff that makes the product work. Validating a software product means that we have to establish that the product will always work (under given circumstances). Validated software reduces risk. Current validation practice, however, boils down to testing the software. To quote the famous Dutch computer scientist Edsger W. Dijkstra: “testing can only prove the existence of bugs, but not their non-existence”. Software that is validated by testing is always a risk (and if the testing is not done rigorously, the risk will be considerable). Risk-sensitive software seriously deserves our special attention.
Models as code
Most programmers usually start writing programs (after initially having gathered requirements in some way) in languages like java, c or python, and they develop trust in those programs afterwards by testing them. We claim that there is a better way, namely by first developing models of the software, before developing code. A conceptual model is a design of a software system that is independent of any software architecture or programming language. The reason is simple: unlike software, models can be validated. Once you’ve found the goals and critical success factors (functional and nonfunctional) of end users of the software system, you can put them into a conceptual model that can be understood both by the business (domain experts, end users) and by the software developers. Once you have validated the correctness of the model, you translate the model to code. Preferably automatically (compile!). If you can trust your compiler, then you can also trust the code. This is the starting point for a new way of systematically developing software systems.
Is this a new idea? Certainly not. In the 90’s, the OMG had introduced the Model-Driven Approach (MDA) to develop software. The basic idea was that by compiling models from UML, you could generate Java code. Was the MDA is success? Yes and No: the idea was great, but the execution a failure, mainly because the UML models as a starting point were insufficient. In particular, UML class diagrams are notorious for bad semantics and ambiguities. Is there a way to remedy this situation? In other words: are we now equipped to revisit the MDA and to really start doing the job of validating software by first validating the models on which they are based? The answer is yes, and Contracts11 is one of the companies that has established that it can be done.
ACE, a semantic programming language
What constitutes a good conceptual modelling language for software products? A good modelling language should be easy to read and to write. It should also be expressive enough to capture all your (non)functional needs. The models should be understandable by both the business (domain experts, end users) and software developers. The modelling language should be sufficiently precise and unambiguous to offer a basis for compilation to code. At Contracts11, for example, we have designed a structured natural language that satisfies the above-mentioned criteria of a good modelling language for software. The language is called OLE (Objects, Logic and English) and was later augmented with the concept of Contract, establishing the ACE language (Automated Contracts in English). ACE can be read by both the business and by software developers, and be compiled to code (SQL, Datalog, Solidity). Hence, if you can trust the correctness of your ACE model, you can trust the correctness of your code. In this sense, a language like ACE is a high-level programming language, that defines the semantics of a lower-level executable program. Contracts11 coins this kind of programming as “semantical programming”. So, how do you go about to write correct models?
Contracts in business processes
Key to writing good models for software are the concepts of “business process” and “contract”. Data only makes sense when you know the context in which the data is used. Logicians have known this for a long time, and in terms of software systems, the context in which the data is used, is the business process. Hence: no data, without a business process. So, we start from a business process, which can be modelled by, e.g., BPMN (Business Process Modeling and Notation), the state of the art in business process modelling. Hence, the BPMN model serves as the context in which we define the data. The BPMN model tells us how the data will be used. As Wittgenstein said: “Don’t ask for the meaning, ask for the use”. We must now try to locate the minimal set of data that is needed to support the business process. How do we find this data? The connection between process and data is a so-called contract. Contracts are written as an agreement between the initiating party of an activity of the process and the receiving party of that activity (the recipient consumes/uses the result of the activity). The input has to comply with a so-called pre-condition, and the result has to comply with a post-condition. By analyzing the constituents of a contract, one can see just what kind of data is involved in writing the pre- and post-conditions of that contract. So, from the business process, together with the contracts that tell how to handle the activities inside a process, one gets a complete overview of the data that is necessary to correctly run the process. Contract specifications can be written, for example, in the high-level ACE language, which can be validated by all stakeholders involved (domain experts, end users, and software developers).
Validating a model
How can you validate a model? In Design Science, developers use the so-called Design Cycle (also known as the Regulative Cycle) to systematically debug models and prototype versions of products. After running the cycle a number of times, the model will constantly be improved by the feedback offered (both by domain experts, end users, and software developers) to eventually converge to a stable model, i.e. a model that has been accepted by all stakeholders involved. This end model has been accepted by all stakeholders as the conceptual blueprint of the desired software system. By definition, we have thus obtained a validated model. By employing the Design Cycle in this way, we have actually constituted a process of Agile Modelling.
Towards better software systems
We think that the only way in which we will ever be able to write software systems that we can trust, is by first placing our trust in models of a software system that we can understand and that we can systematically validate. By modelling a system as a process governed by contracts defined by pre- and post-conditions, and by employing agile techniques, we can arrive at a complete and validated conceptual blueprint of a software system. This blueprint can then be compiled to actual software. This is what we mean by Semantic Programming.
Want to know more? Contact us at email@example.com
Herman Balsters, PhD & Henk Doornbos, PhD - Contracts11.com