Role information modeling in programming

Foreword

This article was published in the journal Educational Technologies in 2010. Since, in my opinion, learning programming is no less important than programming itself, I decided to adapt it for Habr. In it, I tried to answer the question "Why?". I hope it will be useful not only for novice programmers, but also already venerable gurus. If I could interest you, please welcome under cat.

Short disposition

So, let's define for a start what role-based information modeling is. By role-based information modeling (RIM), we will understand information modeling in which the formulation of a problem for the development of a model and / or its subsequent analysis is carried out from the points of view of people acting in various social roles. Such a methodology requires developers to be able to identify problems and set tasks, highlight the main and minor properties of objects necessary for building models, be able to solve assigned tasks using various tools, including software, predict and evaluate the results of their work.

Source of the problem

When programming, we often act in one role - the developer , and the process of learning any programming language is based on this position. With this approach, some language constructs (for example, comments) seem superfluous at first glance and do not require proper attention. The RIM technique allows to reveal in a new way the purpose of individual programming language tools, to emphasize their importance for a competent solution of the task. The prominent Dutch scientist Edsger V. Dijkstra noted: “The one who thinks that the products of programmers are the programs they write are deeply mistaken. The programmer is obliged to create credible solutions and present them in the form of convincing arguments, and the text of the written program is only accompanying material to which this evidence applies. ”
We illustrate the above with an example. Let it be necessary to write a double factorial calculation program for an odd number n using recursion. Recall that the dual factorial is the product of all natural numbers of the same parity as n , up to n inclusive.
One solution to this problem will be the following program in the Pascal language (of course, I know that the program will not work for n> 21, however, without breaking the generality, it can be used as an example):

 program oddfactorial;
 uses crt;
 var n: integer;
 function F (n: integer): longint;
 begin
	 if n = 1 then F: = 1
	 else 
	 if n = 3 then F: = 3
	 else F: = n * F (n-2);
 end;
 begin
	 ClrScr;
	 repeat
		 Readln (n);
	 until odd (n);
	 Write (F (n));
	 Readln;
 end.

Diagnostics

From the point of view of the developer, this program completely solves the task, however, if we analyze the solution from the user's point of view, the proposed option will need to be improved.
Indeed, if we compile the program and run it for execution, then the user will be treated with a “black box” process: the input program reads numbers until an odd number is entered and the calculated answer is output. Naturally, the input and output of the program should contain instructions for the user:

 program oddfactorial;
 uses crt;
 var n: integer;
 function F (n: integer): longint;
 begin
	 if n = 1 then F: = 1
	 else 
	 if n = 3 then F: = 3
	 else F: = n * F (n-2);
 end;
 begin
	 ClrScr;
	 repeat
		 Write ('Please enter an odd number to calculate double factorial:');
		 Readln (n);
	 until odd (n);
	 Write ('Dual factorial for a number', n, 'is equal to');
	 Write (F (n));
	 Readln;
 end.

Thus, the role of the user helps us to focus attention on the correct design of data input and output, which is not always obvious.
')

There is no limit to perfection

Now consider the third role - a third - party developer . The need for such a role is due to the fact that large projects require the coordinated actions of a large number of developers. For a third-party developer, the most important requirement for the program is its comprehensibility, which can be achieved by adhering to several programming styles that are not obvious to young programmers.
The concept of one style is to use understandable variable names. According to the Hungarian notation, for example, the variable name must contain information about it, first of all about its type: the variable name pszLicFileContents indicates that it is a pointer (p), to a fixed-size string (sz), its name is encoded in the name of the variable pbContent LPBYTE, the bVerified variable is of type bool.
However, strict typing cannot always be effectively replaced by artificial means, and the maintenance of these artificial means does not always justify the effort expended. Modern approaches suggest that variables should be named solely by the meaning: SelectedIndexInTable, OpenedFileName.
Making the source code of the program also improves its clarity. The Pascal programming language allows for the enumeration of program statements in one line with delimiters ";" and ".", However, it is obvious that such a record is incomprehensible and difficult to understand. In the examples we have given, the blocks for defining variables, cycles, input and output operators are indented. There are programming languages, for example, Python, which do not allow the program to run without the correct code design.
In addition, comments help to significantly improve the clarity of the code. It is recommended to comment in detail on each object and all public methods of the program or module object, as well as variables, if any, plus mandatory comments for internal methods and variables, as well as inside functions, it is necessary to comment on particularly complex and important points. There is an approach that suggests, before writing a function, describe its behavior in detail in the comment:

 {The getlines function reads the lines entered from the keyboard, writes them to the str array and returns the number of lines read}
 function getlines (var str: array of string): integer;
 var
	 i: integer;  {Line count}
 begin
	 i: = 0;  {Initializing the counter}
 {Until the end of the file is reached, we read the next line and increment the counter}
	 while not eof (input) do
	 begin
		 Readln (str [i]);
		 inc (i);
	 end;
 {Return the number of rows read}
	 getlines: = i;
 end; 

It should be noted that supporters of commenting on the source code have opponents who claim that comments implicitly push the developer to write an incomprehensible code (after all, there is an explanation in the comments). This statement seems reasonable enough, however, since the level of preparation of developers is different, the best way out of the current dilemma will be a symbiosis of clear code and comments for the most complex parts of the program.
Following the above approaches, the text of the program from the example proposed by us should be modified as follows:

 program oddfactorial;
 uses crt;
 var n: integer;
 {The DoubleFactorial function considers double factorial from the number n given to it}
 function DoubleFactorial (n: integer): longint;
 begin
 {The first two conditions are taken from the definition of double factorial}
	 If n = 1 then DoubleFactorial: = 1
	 else 
	 If n = 3 then DoubleFactorial: = 3
 {Recursive function call}
	 else DoubleFactorial: = n * DoubleFactorial (n-2);
 end;
 begin
	 ClrScr;
	 repeat
		 Write ('Please enter an odd number to calculate double factorial');
                 Readln (n);
	 until odd (n);  {Input of numbers continues until an odd number is entered}
	 Write ('Dual factorial for a number', n, 'is equal to');
	 Write (DoubleFactorial (n));
	 Readln;
 end. 

Thus, the use of role-based information modeling in teaching programming makes it possible to identify possible problems already at the stage of developing a model for solving a problem, to take a broader look at the possibilities of programming language constructs, to focus the attention of developers on the competent design of the program code and care for the user.

PS

Naturally, most of those reading Habr will say that all this was known without me. I also thought so, until I got to check the olympiad tasks of the city stage. I was struck by the negligence in the design of the code of the majority of participants - the programs worked on the principle of the black box. Only by the name of the file and the number of the task was it possible to determine what should be given to the input: a file, a sequence of numbers or letters. I understand that for Olympiad tasks, first of all, speed and correctness are important, but when the principle “works and ok” takes up and in ordinary programming, then it’s time to think.
We after all criticize programs with a bad interface, inconvenient design of dialogs, etc. And this, in my opinion, is the result of a technocratic approach to development, they say, “all users are stupid by definition”.
In my article, I tried to summarize the principles of ROME, which teach you to look at your product from different angles. I hope for someone they will be useful.