Role-based information modeling in programming

Foreword

This article was published in the journal Educational Technologies for 2010. Since, in my opinion, teaching 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 to novice programmers, but also already venerable gurus. If I could interest you, please welcome under cat.

Brief disposition

So, let us first determine what role-based information modeling is. By role-based information modeling (RIM) we mean information modeling in which the formulation of the problem for the development of the model and / or its subsequent analysis is carried out from the point of view of people acting in various social roles. Such a methodology requires developers to be able to identify problems and set tasks, identify the main and secondary properties of objects needed to build models, be able to solve tasks using various tools, including software, to predict and evaluate the results of their work.

Source of problem

When programming, we often play 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) at first glance seem redundant and do not require proper attention. The RIM technique allows us to reveal in a new way the purpose of individual tools of the programming language, to emphasize their importance for the competent solution of the problem. Outstanding Dutch scientist Edsger W. Dijkstra noted: “The one who thinks that the products of programmers are the programs they write is deeply mistaken. The programmer is obliged to create credible decisions and present them in the form of convincing arguments, and the text of the written program is only supporting material to which this evidence applies. ”
We illustrate the above with an example. Let it be necessary to write a program for computing the double factorial for an odd number n using recursion. Recall that a double factorial is the product of all natural numbers of the same parity as n , up to n inclusive.
One of the solutions to this problem will be the following Pascal program (naturally, 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 perspective of the user , the proposed option will need to be finalized.
Indeed, if we compile the program and run it for execution, then for the user the process of working with it will be similar to communicating with the “black box”: the input program reads the numbers until an odd one is entered and gives a calculated answer at the 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 the double factorial:');
		Readln (n);
	until odd (n);
	Write ('Double factorial for the number', n, 'is equal to');
	Write (F (n));
	Readln
end.

Thus, the role of the user helps us to focus on the competent 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 coordinated actions of a large number of developers. For a third-party developer, the most important requirement for a program is its comprehensibility, which can be achieved by observing several programming styles that are not obvious to young programmers.
The concept of one style is to use friendly variable names. According to the Hungarian notation, for example, the name of the variable should contain information about it, primarily about its type: the name of the variable pszLicFileContents means that it is a pointer (p), to a string of a fixed size (sz), its type 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 maintaining these artificial means does not always justify the effort. Modern approaches propose to name variables exclusively in meaning: SelectedIndexInTable, OpenedFileName.
Designing the source code of the program also improves its clarity. The Pascal programming language allows the program operators to be listed on one line with the delimiters “;” and “.”, But it is obvious that such a record is incomprehensible and difficult to understand. In the examples we have indicated, variable definition blocks, loops, input and output operators are indented. There are programming languages, for example, Python, which do not allow a program to run without proper code design.
In addition, comments help greatly improve code clarity. 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, to describe its behavior in detail in a 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 counter}
begin
	i: = 0; {Initialization of the counter}
{Until the end of the file is reached, read the next line and increase 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 obscure code (there is an explanation in the comments). This statement seems reasonable enough, however, since the level of training of the developers is different, the optimal way out of the existing dilemma is a symbiosis of understandable code and comments for the most complex sections of the program.
Following the approaches listed above, the program text from the example we have proposed should be modified as follows:
program oddfactorial;
uses crt;
var n: integer;
{The DoubleFactorial function counts the double factorial of the number n passed to it}
function DoubleFactorial (n: integer): longint;
begin
{Первые два условия взяты из определения двойного факториала}
	if n = 1 then DoubleFactorial:= 1
	else 
	if n = 3 then DoubleFactorial:= 3
{Рекурсивный вызов функции}
	else DoubleFactorial:= n*DoubleFactorial(n-2);
end;
begin
	ClrScr;
	repeat
		Write('Введите, пожалуйста, нечётное число для вычисления двойного факториала');
                Readln(n);
	until odd(n); {Ввод чисел продолжается до тех пор, пока не будет введено нечётное число}
	Write('Двойной факториал для числа ',n,' равен ');
	Write(DoubleFactorial(n));
	Readln;
end.

Thus, the use of role-based information modeling in teaching programming allows you to identify possible problems already at the stage of developing a model for solving a problem, take a broader look at the possibilities of programming language designs, and focus developers on the competent design of the program code and caring 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 problems of the city stage. I was struck by the carelessness in the design of the code of most participants - the programs worked on the principle of a black box. Only by the name of the file and the task number was it possible to determine what needs to be submitted: a file, a sequence of numbers or letters. I understand that for olympiad tasks, speed of work and correctness are important, but when the principle of “working well” takes up and in everyday programming, then it’s time to think about it.
We scold programs with a poor interface, inconvenient dialog design, 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 briefly outline the principles of ROME, which teach you to look at your product from different angles. I hope for someone they will be useful.

Also popular now: