Problem
The problem is that programmers all over the world don't formalize their work in any way, explains Anatoliy Shalyto. The question is whether formalizing is even possible? Code is something that is written based on one's knowledge and experience. What's more, most non-programmers don't know much about programming languages, so what's the point?
"Recently, there was an article in the Kommersant newspaper on the legitimacy of software used in nuclear power plants. It mentioned that with the current software, no one can predict how the programs will behave under particular conditions, or when and which changes have ever been done to it. Also, there is no documentation for this software. Just think about it: it operates a nuclear reactor, and no one, save maybe for the developer who's not present on the plant, knows how the program works. And this is a situation common to most software throughout the world. While equipment is always designed, and only then created, there is often no design documentation for software. The Unified Modeling Language (UML) that was meant to promote standardization is rarely used: be it that everyone hurries, or the customer has no money for documentation, or the developer just doesn't have enough people to do it in time. The fun part is that sometimes, software is first meant to be used for three-four years, and then this span is prolonged to 25; yet, even in this case no one develops design documentation for it. If there's a need to change something in the software, programmers usually change the code as they see
fit and then show the result to the customer. And I feel sorry for the customers who then have to approve this software the same way as they do it with the corresponding equipment", comments the head of the Programming Technology Department.
What's more, sometimes it is hard for a programmer to understand his own code, let alone another's. To make understanding others' programs easier, one has to grasp how the other developers thought, what approaches and methods they used. To do that, one would need program design documentation. Thus, it would be possible to formalize and align the design specification, which is especially important in case of critical facilities. If few know, how the software on such objects work, what can we say about operation safety?
Solution
The solution lies in perceiving programming as engineering, not as some art, as they do it now. To achieve that, one can make use of the automatic control systems that are used in engineering sciences. This approach, proposed by Anatoliy Shalyto as early as in 1991, is called automata programming.
This implies not only using such mathematical abstractions as automatons, but a whole new programming technology that will allow creating systems with complex behavior. It is based on a new programming paradigm, where we see programs as automated objects consisting of control systems and the controlled objects, which can be both real and virtual. What's important is that be it customer, programmer, or engineer — they all would be able to read into the program's behavior. This will let other programmers better understand another's code when it's necessary to correct it.
"Before programming a system, one has to decide on its behavior. We propose to not write the code right from the start, but "draw plans" - describe the program's behavior in terms of conditions and transitions, and actions taken as result. Simply put, it is first important to describe what the program will do in a way that can be understood by anyone. When it has been drawn up, it will be time to write the code — manually or automatically", explains the method's author.
On paper, automata programming looks like drawing up graphs which explain how input actions launch transitions between conditions, and form output actions. To do that, one first creates design specifications as simple text, where it is written what the program has to do in accordance with the customer's intentions. Then it is necessary to define the corresponding designations for input and output actions, as well as information sources and receivers. As it is the developer who finalizes the design specification according to the State Standard, the customer can use the graphs to understand what the programmer wants to do, and make changes. The approved and standardized design specifications will be used to create the code. Regardless of how the automation is realized, manually or automatically, the programming of input and output signals' functions that have no complex behavior is done manually.
According to Anatoliy Shalyto, a program's quality depends more on understanding between the customer and developer on initial stages, than testing and verification. Surely, this approach implies that the customer is versed in software design documentation. Yet, this is still more clear and comprehensible than the program code. What's more, there are applications for modeling automata-based programs, where one can trace all the transitions from one conditions to another. Also, the design process is similar to that of robot design, which is easily understood by engineers.
"These are different ways of thinking: engineers' and programmers'. As of now, programming is not an engineering science, but applied mathematics, as we train "generalist" programmers. If they had engineering training, like in such fields as operating engines, power systems engineering and such, that would be engineering programming. Today's programmers were taught to work on the code right from the start. They've done it this way since they were kids, and now, on their fifth year at the university, some professor tells them to model software using UML. Surely, they find it hard to change their ways. What's more, most programmers are really self-assured, and use automatons, as well as any other mathematical abstractions, only when they think they need it. And what I am always saying is that they should always use them to describe programs with a complexbehavior, especially when their behavior depends on the program's previous history", concludes Anatoliy Shalyto.
The professor also shared about his acquaintance who works on software for a critical facility. Before creating the program, they first designed it. The transition graph had more than 300 nodes, though it could be split into several simpler interrelated graphs. Yet, describing the program's behavior in a single graph allowed to graphically show how the control system will work, and, given the program will be created automatically, it will behave strictly according to the design. And that makes it convenient and safe.
Automata-based programs have yet another advantage — most of their functions can be verified with the Model Checking method. Anatoliy Shalyto suggests that anyone who's interested in automata programming visits his website or addresses him personally on shalyto@mail.ifmo.ru.
