Module program development of software modules. The work program of the training practice for the professional module "development of software modules for computer systems". Ensuring software completeness

The procedure for developing a software module.

1. studying and checking the specification of the module, choosing a programming language; (i.e., the developer, studying the specification, finds out whether he understands it or not, whether it describes the module sufficiently fully; then he chooses the programming language in which the module will be written, although the programming language can be the same for the entire software system)
2.selection of an algorithm and data structure (here it turns out whether any algorithms are known to solve the problem and if there is, then use it)
3.programming the module (writing the program code)
4. polishing the module text (editing existing comments, adding additional comments to ensure the required quality)
5.check the module (the logic of the module is checked, its work is debugged)

The following methods are used to control the software module:

- static check of the module text (the text is read from beginning to end in order to find errors in the module. Usually, in addition to the module developer, one or even several programmers are involved in such a check. It is recommended that errors found during such a check not be corrected immediately, but upon completion reading the module text)
- end-to-end tracking (the execution of the module is manually scrolled (operator by operator in the sequence that follows from the logic of the module) on a certain set of tests)
6. compilation of the module.

Structured programming.

By far the most popular programming technique is top-down structured programming.

Structured programming is the process of breaking down an algorithm step by step into smaller and smaller pieces in order to obtain elements for which specific prescriptions can be easily written.

Two principles of structured programming:

1. sequential detailing "from top to bottom"
2.the limitation of the basic set of structures for constructing algorithms of any degree of complexity

Structured programming requirements:

1. the program should be composed in small steps, thus, a complex task is broken down into fairly simple, easily perceived parts.
2.the logic of the program should be based on the minimum number of sufficiently basic control structures (linear, branching and cyclic structures)

The main properties and advantages of structured programming:

1.reducing the complexity of programs
2.the ability to demonstrate the correctness of programs at various stages of solving the problem
3.visibility of programs
4. simplicity of modification (making changes) of programs.

Modern programming tools should provide maximum protection against possible developer errors.

An analogy can be drawn here with the development of vehicle management methods. At first, safety was ensured through the development of traffic rules. Then came the road marking and intersection control system. And, finally, traffic interchanges began to be built, which, in principle, prevent the intersection of traffic flows of cars and pedestrians. However, the means used should be determined by the nature of the problem to be solved: for a country road, it is quite enough to observe a simple rule - "look at your feet and to the sides".

The basic idea of structured programming: the program should be a set of blocks, combined in a hierarchical tree structure, each of which has one input and one output.

Any program can be built using only three basic types of blocks:

1. functional block - a separate linear operator or their sequence;
2.branch - If
3.generalized loop - While type construct

It is essential that each of these structures has only one input and one output for control. Thus, the generalized operator has only one input and one output.

Structured programming is sometimes referred to as "no-GO TO programming". However, the point here is not in the GO TO statement, but in its erratic use. Very often, when implementing structured programming in some programming languages, the transition operator (GO TO) is used to implement structured constructs without diminishing the main advantages of structured programming. It is the "non-structural" jump operators that confuse the program, especially the jump to the operator located in the module text above (earlier) the jump operator being executed. Nevertheless, an attempt to avoid the branch operator in some simple cases can lead to too cumbersome structured programs, which does not improve their clarity and contains the danger of additional errors in the text of the module. Therefore, we can recommend avoiding the use of the jump operator whenever possible, but not at the expense of clarity of the program.

Useful cases of using the jump operator include exiting a loop or procedure by a special condition that "ahead of time" terminates the work of a given cycle or a given procedure, i.e. terminating the work of some structural unit (generalized operator) and thus only locally violating the structuredness of the program. Great difficulties (and the complication of the structure) are caused by the structural implementation of the reaction to emerging exceptional (often erroneous) situations, since this requires not only an early exit from the structural unit, but also the necessary processing of this situation (for example, the issuance of suitable diagnostic information). The exception handler can be at any level program structure, and it can be accessed from different lower levels. The following "non-structural" implementation of the response to exceptional situations is quite acceptable from the technological point of view. Exception handlers are placed at the end of one or another structural unit, and each such handler is programmed in such a way that, after finishing its work, it exits the structural unit at the end of which it is placed. The call to such a handler is made by the transition operator from the given structural unit (including any structural unit nested in it).

Generally speaking, the main thing in structured programming is the competent drawing up of the correct logical scheme of the program, the implementation of which by language means is a secondary matter.

J. Hughes, J. Michtom. A structured approach to programming. - M .: Mir, 1980. - p. 29-71.

V. Tursky. Programming methodology. - M .: Mir, 1981 .-- p. 90-164.

E.A. Zhogolev. Technological foundations of modular programming // Programming, 1980, no. - p. 44-49.

R.C. Holt. Structure of Computer Programs: A Survey // Proceedings of the IEEE, 1975, 63 (6). - p. 879-893.

G. Myers. Reliability software... - M .: Mir, 1980. - p. 92-113.

Ya Pyle. ADA is the language of embedded systems. M .: Finance and statistics, 1984. - p. 67-75.

M. Zelkovets, A. Shaw, J. Gannon. Principles of software development. - M .: Mir, 1982, p. 65-71.

A.L. Fuksman. Technological aspects of creating software systems. M .: Statistics, 1979. - p. 79-94.

Lecture 8. Development of a software module
The procedure for developing a software module. Structured programming and step by step detailing. Understanding pseudocode. Control of the program module.
8.1. The procedure for developing a software module.
When developing a software module, it is advisable to adhere to the following order:
studying and checking the specification of the module, choosing the language
programming;
choice of algorithm and data structure;
module programming;
polishing the module text;
module check;
compiling the module.
The first step in the development of a software module is largely a contiguous control of the program structure from below: by studying the specification of a module, the developer must make sure that it is clear to him and is sufficient for the development of this module. At the end of this step, a programming language is selected: although the programming language may already be predefined for the entire software system, nevertheless in some cases (if the programming system allows it) another language may be chosen that is more suitable for implementation. of this module(e.g. assembly language).
At the second step in the development of a software module, it is necessary to find out whether any algorithms are already known for solving the problem posed and or close to it. And if a suitable algorithm is found, then it is advisable to use it. The choice of suitable data structures that will be used when a module performs its functions largely predetermines the logic and quality indicators of the module being developed, so it should be considered as a very responsible decision.
At the third step, the text of the module is constructed in the selected programming language. The abundance of all kinds of details that must be taken into account when implementing the functions specified in the module specification can easily lead to the creation of a very confusing text containing a lot of errors and inaccuracies. Finding errors in such a module and making the required changes to it can be a very time-consuming task. Therefore, it is very important to use a technologically sound and practically proven programming discipline to construct the text of the module. For the first time, Dijkstra drew attention to this, formulating and substantiating the basic principles of structured programming. Many programming disciplines that are widely used in practice are based on these principles. The most common discipline is incremental refinement, which is discussed in detail in sections 8.2 and 8.3.
The next step in the development of the module is associated with bringing the text of the module to a complete form in accordance with the specification of the quality of the software. When programming a module, the developer focuses on the correct implementation of the module's functions, leaving incomplete comments and allowing some violations of the requirements for the program style. When polishing the text of the module, he should edit the existing comments in the text and, possibly, include additional comments in it in order to provide the required primitives of quality. For the same purpose, the text of the program is edited to meet stylistic requirements.
The module verification step is a manual verification of the internal logic of the module before debugging it (using its execution on a computer), implements the general principle formulated for the discussed programming technology, about the need to control the decisions made at each stage of software development (see Lecture 3). Module validation methods are discussed in Section 8.4.
And finally, the last step in the development of a module means completing the verification of the module (with the help of the compiler) and proceeding to the process of debugging the module.
8.2. Structured programming.
When programming a module, it should be borne in mind that the program must be understandable not only for a computer, but also for a person: both the developer of the module, and the persons who check the module, and textualists who prepare tests for debugging the module, and the PS maintainers who make the required changes to the module will have to repeatedly disassemble the logic of the module. In modern programming languages, there are enough tools to confuse this logic as much as you like, thereby making the module difficult for humans to understand and, as a consequence, make it unreliable or difficult to maintain. Therefore, it is necessary to take steps to select the appropriate language tools and follow a specific programming discipline. For the first time, Dijkstra drew attention to this and proposed to build a program as a composition of several types of control structures (structures), which can greatly increase the understanding of the logic of the program. Programming using only such constructs was called structural.
The basic constructs of structured programming are: follow, branch, and repetition (see Figure 8.1). The components of these constructions are generalized operators (processing nodes) S, S1, S2 and a condition (predicate) P. A generalized operator can be either a simple operator of the programming language used (assignment, input, output, procedure call operators), or a program fragment , which is a composition of basic structured programming control constructs. It is essential that each of these structures has only one input and one output for control. Thus, the generalized operator has only one input and one output.
It is also very important that these constructs are already mathematical objects (which, in essence, explains the reason for the success of structured programming). It is proved that for each unstructured program it is possible to construct a functionally equivalent (that is, solving the same problem) structured program. For structured programs, you can prove some properties mathematically, which allows you to detect some errors in the program. A separate lecture will be devoted to this issue.
Structured programming is sometimes referred to as "no-GO TO programming". However, the point here is not in the GO TO statement, but in its erratic use. Very often, when implementing structured programming in some programming languages (for example, in FORTRAN), the transition operator (GO TO) is used to implement structured constructs without compromising the main advantages of structured programming. It is the "non-structural" jump operators that confuse the program, especially the jump to the operator located in the module text above (earlier) the jump operator being executed. Nevertheless, an attempt to avoid the branch operator in some simple cases can lead to too cumbersome structured programs, which does not improve their clarity and contains the danger of additional errors in the text of the module. Therefore, we can recommend avoiding the use of the jump operator whenever possible, but not at the cost of clarity of the program.
Useful cases of using the jump operator include exiting a loop or procedure by a special condition that "ahead of time" terminates the work of a given cycle or a given procedure, i.e. terminating the work of some structural unit (generalized operator) and thus only locally violating the structuredness of the program. Great difficulties (and the complication of the structure) are caused by the structural implementation of the reaction to emerging exceptional (often erroneous) situations, since this requires not only an early exit from the structural unit, but also the necessary processing (exclusion) of this situation (for example, the issuance of a suitable diagnostic information). The exception handler can be at any level of the program structure, and it can be accessed from different lower levels. The following "non-structural" implementation of the reaction to exceptional situations is quite acceptable from the technological point of view. Exception handlers are placed at the end of one or another structural unit, and each such handler is programmed in such a way that, after completing its work, it exits the structural unit at the end of which it is placed. The call to such a handler is made by the transition operator from the given structural unit (including any nested structural unit).
8.3. Step-by-step detailing and the concept of pseudocode.
Structured programming provides guidelines for how the module text should be. The question arises how a programmer should act to construct such a text. Sometimes the programming of a module begins with the construction of its block diagram, which outlines the logic of its operation. but modern technology programming does not recommend doing this. Although the block diagrams make it possible to very clearly represent the logic of the module's operation, when they are encoded in a programming language, a very specific source of errors arises: more that psychologically it is quite difficult to maintain high level attention when re-examining it. An exception may be the case when a graphical editor is used to build block diagrams and they are formalized so that text in a programming language is automatically generated from them (as for example, this can be done in R - technology).
As the main method of constructing the text of the module, modern programming technology recommends step-by-step detailing. The essence of this method is to break down the process of developing a module text into a number of steps. At the first step, the general scheme of the module's operation is described in an observable linear text form (i.e., using very large concepts), and this description is not fully formalized and is focused on human perception. At each next step, one of the concepts is refined and detailed (we will call it refined), used (as a rule, not formally) in any description developed in one of the previous steps. As a result of this step, a description of the selected refined concept is created either in terms of the basic programming language (i.e., the module chosen for presentation), or in the same form as in the first step using new refined concepts. This process ends when all the refined concepts are ultimately expressed in the underlying programming language. The last step is to obtain the text of the module in the basic programming language by replacing all occurrences of the refined concepts with their given descriptions and expressing all occurrences of structured programming constructs using this programming language.
Step-by-step detailing is associated with the use of a partially formalized language to represent the specified descriptions, which is called pseudocode. This language allows the use of all structured programming constructs that are formalized, together with informal fragments in natural language to represent generic operators and conditions. The corresponding fragments in the basic programming language can also be specified as generalized operators and conditions.
The head description in pseudocode can be considered the external design of the module in the base programming language, which
the beginning of a module in the base language, i.e. the first sentence or title (specification) of this module;
section (set) of descriptions in the base language, and instead of descriptions of procedures and functions - only their external design;
informal designation of the sequence of operators of the module body as one generalized operator (see below), as well as informal designation of the sequence of operators of the body of each description of a procedure or function as one generalized operator;
the last sentence (end) of the module in the base language.
The appearance of a description of a procedure or function is similar. However, if you follow Dijkstra, it is better to present the descriptions section here with an informal designation, making its detailing in the form of a separate description.
Informal designation of a generalized operator in pseudocode is made in natural language by an arbitrary sentence that outlines its content. The only formal requirement for the design of such a designation is the following: this proposal must occupy one or more graphic (printed) lines in its entirety and end with a dot.
For each informal generalized operator, a separate description must be created that expresses the logic of its operation (detailing its content) using the composition of the basic structures of structured programming and other generalized operators. The title of such a description should be the informal designation of the detailed generic operator. The basic structures of structured programming can be represented in the following form (see Fig. 8.2). Here, the condition can either be explicitly specified in the base programming language as a boolean expression, or it can be informally represented in natural language by some fragment that outlines the meaning of this condition. In the latter case, a separate description should be created detailing this condition, indicating the designation of this condition (a fragment in natural language) as the title.
Rice. 8.2. Basic constructions of structured programming in pseudocode.
Rice. 8.3. Special cases of the transition operator as a generalized operator.
As a generalized operator on pseudocode, the above particular cases of the transition operator can be used (see Fig. 8.3). The sequence of exception handlers (exceptions) is specified at the end of a module or description of a procedure (function). Each such handler looks like:
EXCEPTION exception_name
generic_operator
ALL EXCEPTIONS
The difference between an exception handler and a procedure without parameters is as follows: after the procedure is executed, control returns to the operator following the call to it, and after the exception is executed, control returns to the operator following the call to the module or procedure (function), at the end of which ( which) this exception is placed.
It is recommended at each step of detailing to create a sufficiently meaningful description, but easily visible (descriptive), so that it is placed on one page of text. Typically, this means that such a description should be a composition of five or six structured programming constructs. It is also recommended to place nested structures with a shift to the right by several positions (see Fig. 8.4). As a result, it is possible to obtain a description of the logic of work in terms of clarity, which is quite competitive with block diagrams, but has a significant advantage - the linearity of the description remains.

DELETE RECORDS IN THE FILE BEFORE THE FIRST,

SATISFACTORY FILTER:

SET FILE BEGINNING.

IF REGULAR ENTRY SATISFIES

FILTER TO

DELETE REGULAR ENTRY FROM FILE.

ALL IF

BYE

IF RECORDS ARE NOT DELETED THEN

PRINT "ENTRIES ARE NOT DELETED".

PRINT "DELETED n RECORDS".

ALL IF

Rice. 8.4. An example of one step of detailing in pseudocode.

Dijkstra is sometimes credited with the idea of step-by-step detailing. However, Dijkstra proposed a fundamentally different method of constructing the text of the module, which seems to us to be deeper and more promising. First, along with the clarification of operators, he proposed to gradually (step by step) refine (detail) the data structures used. Second, at each step he proposed to create a virtual machine for detailing and, in its terms, to detail all the refined concepts for which this machine allows it to be done. Thus, Dijkstra proposed, in essence, detailing by horizontal layers, which is a transfer of his idea of layered systems (see Lecture 6) to the level of module development. This method of module development is currently supported by ADA language packages and object-oriented programming tools.
8.4. Control of the program module.
The following methods are used to control the software module:
static check of the module text;
end-to-end tracking;
proof of the properties of the program module.
When statically checking the text of a module, this text is read from beginning to end in order to find errors in the module. Usually, for such a check, in addition to the module developer, one or even several programmers are involved. It is recommended that errors detected during such a check should not be corrected immediately, but upon completion of reading the module text.
Tracking is one type of dynamic module control. It also involves several programmers who manually scroll through the execution of the module (operator by operator in the sequence that follows from the logic of the module) on a certain set of tests.
The next lecture is devoted to proving the properties of programs. It should only be noted here that this method is still very rarely used.
Literature for lecture 8.
8.2. E. Dijkstra. Notes on structured programming // W. Dahl, E. Dijkstra, K. Hoore. Structured programming. - M .: Mir, 1975 .-- S. 24-97.
8.3. N. Virt. Systematic programming. - M .: Mir, 1977 .-- S. 94-164.
Lecture 9. Proof of program properties
The concept of program justification. Formalization of program properties, Hoor's triad. Rules for setting properties of the assignment operator, conditional and compound operators. Rules for establishing the properties of a loop operator, the concept of a loop invariant. Completeness of program execution.
9.1. Justification of programs. Formalization of program properties.
To improve the reliability of software, it is very useful to provide programs with additional information, with the use of which you can significantly increase the level of control of the software. Such information can be specified in the form of informal or formalized statements that are tied to various fragments of programs. We will call such statements the rationale for the program. Informal rationales for programs can, for example, explain the motives for making certain decisions, which can greatly facilitate the search and correction of errors, as well as the study of programs while maintaining them. Formalized justifications allow one to prove some properties of programs both manually and to control (set) them automatically.
One of the currently used concepts of formal justification of programs is the use of the so-called Hoor triads. Let S be some generalized operator over the information environment IS, P and Q - some predicates (statements) over this environment. Then the notation (P) S (Q) is called Hoor's triad, in which the predicate P is called the precondition and the predicate Q is called the postcondition with respect to the operator S. The operator (in particular, the program) S is said to have the property (P) S (Q) if whenever before the execution of the operator S the predicate P is true, after the execution of this operator S the predicate Q will be true.
Simple examples of program properties:
(9.1) (n = 0) n: = n + 1 (n = 1),
(9.2) (n
(9.3) (n
(9.4) (n> 0) p: = 1; m: = 1;
WHILE m / = n DO
BYE
To prove the property of the program S, the properties of simple operators of the programming language are used (here we restrict ourselves to the empty operator and the assignment operator) and the properties of control structures (compositions), with the help of which a program is built from simple operators (we will restrict ourselves here to three basic compositions of structured programming, see Lecture eight). These properties are usually referred to as program verification rules.
9.2. Properties of simple operators.
For an empty operator, the following is valid
Theorem 9.1. Let P be a predicate over the information environment. Then property (P) (P) holds.
The proof of this theorem is obvious: an empty operator does not change the state of the information environment (in accordance with its semantics), therefore its precondition remains true even after its execution.
The assignment operator satisfies
Theorem 9.2. Let the IS information environment consist of the X variable and the rest of the RIS information environment:
Then the property
(Q (F (X, RIS), RIS)) X: = F (X, RIS) (Q (X, RIS)),
where F (X, RIS) is some single-valued function, Q is a predicate.
Proof. Let the predicate Q (F (X0, RIS0), RIS0) be true before the execution of the assignment operator, where (X0, RIS0) is some arbitrary state of the information environment IS, then after the execution of the assignment operator the predicate Q (X, RIS) will be true, so how X will get the value F (X0, RIS0) and the RIS state is not changed by this assignment operator, and therefore after executing this assignment operator in this case
Q (X, RIS) = Q (F (X0, RIS0), RIS0).
Due to the arbitrariness of the choice of the state of the information environment, the theorem is proved.
Example 9.1 is an example of the property of an assignment operator.
9.3. Properties of the basic structures of structured programming.
Let us now consider the properties of the main structures of structured programming: succession, branching and repetition.
The properties of succession are expressed by the following
Theorem 9.3. Let P, Q, and R be predicates over the information environment, and S1 and S2 be generalized operators with the properties
(P) S (Q) and (Q) S2 (R).
Then for the compound operator
S1; S2<.blockquote>
the property holds
(P) S1; S2 (R).
Proof. Let the predicate P be true for some state of the information environment before the execution of the operator S1. Then, by virtue of the property of the operator S1, after its execution, the predicate Q will be true. execution of statement S2. Consequently, after the execution of the operator S2, by virtue of its property, the predicate R will be true, and since the operator S2 terminates the execution of the compound operator (in accordance with its semantics), the predicate R will also be true after the execution of this compound operator, which was required to prove.
For example, if properties (9.2) and (9.3) hold, then it has
location and property
(n
The branching property expresses the following
Theorem 9.4. Let P, Q, and R be predicates over the information environment, and S1 and S2 be generalized operators with the properties
(P, Q) S1 (R) and (`P, Q) S2 (R).
Then for the conditional operator
IF P THEN S1 ELSE S2 ALL IF
the property holds
(Q) IF P THEN S1 ELSE S2 ALL IF (R).
Proof. Let the predicate Q be true for a certain state of the information environment before the execution of the conditional operator. If the predicate P is also true, then the execution of the conditional operator in accordance with its semantics is reduced to the execution of the operator S1. By virtue of the property of the operator S1, after its execution (and in this case, after the execution of the conditional operator), the predicate R will be true. If, before the execution of the conditional operator, the predicate P is false (and Q is still true), then the execution of the conditional operator in accordance with its semantics is reduced to the execution of operator S2. By virtue of the property of the operator S2, after its execution (and in this case - and after the execution of the conditional operator), the predicate R will be true. Thus, the theorem is completely proved.
Before moving on to the property of the repetition construct, it should be noted that it is useful for further
Theorem 9.5. Let P, Q, P1 and Q1 be predicates over the information environment for which the implications are valid
P1 => P and Q => Q1,
and let property (P) S (Q) hold for an operator S. Then property (P1) S (Q1) holds.
This theorem is also called the property weakening theorem.
Proof. Let the predicate P1 be true for some state of the information environment before the execution of the operator S. Then the predicate P will also be true (by virtue of the implication P1 => P). Therefore, by virtue of the property of the operator S, after its execution, the predicate Q will be true, and hence the predicate Q1 (by virtue of the implication Q => Q1). This proves the theorem.
The repetition property expresses the following
Theorem 9.6. Let I, P, Q, and R be predicates over the information environment for which the implications are valid
P => I and (I, `Q) => R,
and let S be a generalized operator with property (I) S (I).
Then for the loop operator
WHILE Q DO S EVERYTHING WHILE
the property holds
(P) WHILE Q DO S EVERYTHING YET (R).
The predicate I is called the invariant of the cycle operator.
Proof. To prove this theorem, it suffices to prove the property
(I) WHILE Q DO S EVERYTHING WHILE (I, `Q)
(by Theorem 9.5 on the basis of the implications in the conditions of this theorem). Let the predicate I be true for some state of the information environment before the execution of the cycle operator. If, in this case, the predicate Q is false, then the cycle operator will be equivalent to the empty operator (in accordance with its semantics) and, by virtue of Theorem 9.1, after the execution of the cycle operator, the statement (I , `Q). If, before the execution of the cycle operator, the predicate Q is true, then the cycle operator, in accordance with its semantics, can be represented as a compound operator S; WHILE Q DO S EVERYTHING WHILE
Due to the property of the operator S, after its execution, predicate I will be true, and an initial situation arises for proving the property of the cycle operator: predicate I is true before the execution of the cycle operator, but already for another (changed) state of the information environment (for which the predicate Q can either be true or false). If the execution of the cycle operator ends, then applying the method of mathematical induction, in a finite number of steps, we will come to a situation where the statement (I, `Q) will be true before its execution. And in this case, as was proved above, this statement will also be true after the execution of the loop operator. The theorem is proved.
For example, the loop operator from example (9.4) has the property
m: = m + 1; p: = p * m
EVERYTHING YET (p = n.!}
This follows from Theorem 9.6, since the invariant of this cycle operator is the predicate p = m! and the implications are true (n> 0, p = 1, m = 1) => p = m! and (p = m !, m = n) => p = n!
9.4. Completeness of program execution.
One of the properties of the program, which we may be interested in, in order to avoid possible errors in the SS, is its completeness, i.e. the absence of looping in it with certain initial data. In the structured programs we have considered, only the repetition construct can be a source of looping. Therefore, to prove the completeness of a program, it is sufficient to be able to prove the termination of a cycle operator. The following is useful for this.
Theorem 9.7. Let F be an integer function that depends on the state of the information environment and satisfies the following conditions:
(1) if the predicate Q is true for a given state of the information environment, then its value is positive;
(2) it decreases when the state of the information environment changes as a result of the execution of the operator S.
Then the execution of the loop operator
WHILE Q DO S ALL WHILE completes.
Proof. Let is be the state of the information environment before the execution of the cycle operator and let F (is) = k. If the predicate Q (is) is false, then the execution of the loop statement ends. If Q (is) is true, then by the hypothesis of the theorem k> 0. In this case, the S statement will be executed one or more times. After each execution of the operator S, according to the hypothesis of the theorem, the value of the function F decreases, and since before the execution of the operator S the predicate Q must be true (according to the semantics of the cycle operator), the value of the function F at this moment must be positive (according to the conditions of the theorem). Therefore, due to the integer value of the function F, the operator S in this loop can be executed more than k times. The theorem is proved.
For example, for the example of the cycle operator considered above, the conditions of Theorem 9.7 are satisfied by the function f (n, m) = n-m. Since before executing the loop operator m = 1, the body of this loop will be executed (n-1) times, i.e. this loop statement ends.
9.5. An example of proving a property of a program.
Based on the proven rules for program verification, it is possible to prove the properties of programs consisting of assignment operators and empty operators and using three main compositions of structured programming. To do this, by analyzing the structure of the program and using its predetermined pre- and postconditions, it is necessary to apply a suitable verification rule at each step of the analysis. If you use a repetition composition, you will need to choose a suitable loop invariant.
As an example, let us prove property (9.4). This proof will consist of the following steps.
(Step 1). n> 0 => (n> 0, p - any, m - any).
(Step 2). Occurs
(n> 0, p - any, m - any) p: = 1 (n> 0, p = 1, m - any).
By Theorem 9.2.
(Step 3). Occurs
(n> 0, p = 1, m - any) m: = 1 (n> 0, p = 1, m = 1).
By Theorem 9.2.
(Step 4). Occurs
(n> 0, p - any, m - any) p: = 1; m: = 1 (n> 0, p = 1, m = 1).
By Theorem 9.3, in view of the results of steps 2 and 3.
Let us prove that the predicate p = m! is a cycle invariant, i.e. (p = m m:=m+1; p:=p*m {p=m!}.!}
(Step 5). It takes place (p = m m:=m+1 {p=(m-1)!}.!}
By Theorem 9.2, if we represent the precondition in the form (p = ((m + 1) -1).!}
(Step 6). It takes place (p = (m-1) p:=p*m {p=m!}.!}
By Theorem 9.2, if we represent the precondition in the form (p * m = m.!}
(Step 7). There is a cycle invariant
(p = m m:=m+1; p:=p*m {p=m!}.!}
By Theorem 9.3, in view of the results of steps 5 and 6.
(Step 8). Occurs
(n> 0, p = 1, m = 1) WHILE m / = n DO
m: = m + 1; p: = p * m
EVERYTHING YET (p = n.!}
By Theorem 9.6, by virtue of the result of step 7 and bearing in mind that (n> 0, p = 1, m = 1) => p = m !; (p = m !, m = n) => p = n !.
(Step 9). Occurs
(n> 0, p - any, m - any) p: = 1; m: = 1;
WHILE m / = n DO
m: = m + 1; p: = p * m
EVERYTHING YET (p = n.!}
By Theorem 9.3, in view of the results of steps 3 and 8.
(Step 10). Property (9.4) holds by Theorem 9.5 by the results of steps 1 and 9.
Literature for lecture 9.
9.1. S.A. Abramov. Elements of programming. - M .: Nauka, 1982.S. 85-94.
9.2. M. Zelkovets, A. Shaw, J. Gannon. Principles of software development. - M .: Mir, 1982.S. 98-105.
Lecture 10. Testing and debugging software
Basic concepts. Test design strategy. Debugging Commandments. Offline debugging and testing of a software module. Complex debugging and testing of software tools.
10.1. Basic concepts.
Debugging a software system is an activity aimed at detecting and correcting errors in a software system using the processes of executing its programs. Testing a software system is the process of executing its programs on a certain data set, for which the result of application is known in advance or the rules of behavior of these programs are known. The specified dataset is called a test or just a test. Thus, debugging can be represented in the form of multiple repetitions of three processes: testing, as a result of which the presence of an error in the software system can be ascertained, finding the place of the error in software programs and software’s documentation, and editing programs and documentation in order to eliminate the detected error. In other words:
Debugging = Testing + Finding Errors + Editing.
In foreign literature, debugging is often understood only as a process of finding and fixing errors (without testing), the fact of which is established during testing. Sometimes testing and debugging are considered synonymous. In our country, testing is usually included in the concept of debugging, so we will follow the established tradition. However, the joint consideration of these processes in this lecture makes this discrepancy not so significant. It should be noted, however, that testing is also used as part of the FP attestation process (see Lecture 14).
10.2. Debugging principles and types.
The success of debugging is largely determined by the rational organization of testing. During debugging, it is found and eliminated mainly those errors, the presence of which in the software system is established during testing. As already noted, testing cannot prove the correctness of the PS, in best case it can demonstrate that there is an error in it. In other words, it cannot be guaranteed that by testing the software system with a practically feasible set of tests, it is possible to establish the presence of every error in the software system. Therefore, two tasks arise. The first is to prepare such a set of tests and apply the software to them in order to find as many errors as possible in it. However, the longer the testing process (and debugging in general) lasts, the higher the cost of the software becomes. Hence the second task: to determine the moment of completion of debugging the software system (or its separate component). A sign of the possibility of finishing debugging is the completeness of the coverage of the tests passed through the PS (i.e., tests to which the PS is applied) of many different situations that arise during the execution of PS programs, and the relatively rare manifestation of errors in the PS in the last segment of the testing process. The latter is determined in accordance with the required degree of PS reliability specified in its quality specification.
To optimize the test suite, i.e. To prepare a set of tests that would allow, for a given number of tests (or for a given time interval allotted for testing), to detect a larger number of errors, it is necessary, firstly, to plan this set in advance and, secondly, to use a rational planning strategy ( design) tests. Test design can begin immediately after the completion of the stage of external description of the software. There are different approaches to developing a test design strategy, which can be conditionally graphically placed (see Figure 9.1) between the following two extreme approaches. The left extreme approach is that tests are designed only on the basis of studying the specifications of the software system (external description, description of the architecture and specification of modules). In this case, the structure of the modules is not taken into account in any way, i.e. they are considered black boxes. In fact, this approach requires a complete enumeration of all input data sets, since when only a part of these sets are used as tests, some parts of the PS programs may not work on any test and, therefore, the errors contained in them will not appear. However, testing software systems with a full set of input data sets is practically impracticable. The right extreme approach is that tests are designed on the basis of studying the texts of programs in order to test all the ways of execution of each software program. If we take into account the presence of loops with a variable number of repetitions in programs, then there may be an extremely large number of different ways of executing SS programs, so that their testing will also be practically impracticable.
The optimal test design strategy is located within the interval between these extreme approaches, but closer to the left edge. It includes the design of a significant part of the tests according to the specifications, based on the principles: for each function or opportunity used - at least one test, for each region and for each boundary of change of any input value - at least one test, for each special case or for every exception specified in the specifications is at least one test. But it also requires the design of some tests and the texts of programs, based on the principle (at least): each command of each software program must work through at least one test.
The optimal test design strategy can be concretized on the basis of the following principle: for each program document (including program texts) included in the software system, their own tests should be designed in order to identify errors in it. In any case, this principle must be observed in accordance with the definition of software systems and the content of the concept of programming technology as a technology for developing reliable software systems (see Lecture 1). In this regard, Myers even defines different types testing depending on the type of program document on the basis of which the tests are built. In our country, there are two main types of debugging (including testing): stand-alone and complex debugging. Autonomous debugging means testing only some part of the program included in the software system, searching for and fixing errors fixed during testing. It actually involves debugging each module and debugging the pairing of modules. Comprehensive debugging means testing the software system as a whole, with the search and correction of errors recorded during testing in all documents (including texts of software systems) related to the software system as a whole. Such documents include the definition of the requirements for the software, the quality specification of the software, the functional specification of the software, the description of the software architecture and the texts of the software programs.
10.3. Debugging Commandments.
This section provides general guidelines for organizing debugging. But first, we should note a certain phenomenon that confirms the importance of preventing errors at the previous stages of development: as the number of detected and fixed errors in a software system increases, the relative probability of undetected errors in it also increases. This is due to the fact that with an increase in the number of errors detected in a software system, our understanding of the total number of errors made in it, and therefore, to some extent, of the number of errors still undetected, is also refined. This phenomenon confirms the importance of early error detection and the need for careful control of decisions made at every stage of software development.
Commandment 1. Consider testing a key task in software development, entrust it to the most qualified and gifted programmers; it is not advisable to test your own program.
Commandment 2. A good test is one for which there is a high probability of detecting an error, and not one that demonstrates the correct operation of the program.
Commandment 3. Prepare tests for both correct and incorrect data.
Commandment 4. Avoid non-reproducible tests, document them being passed through the computer; study the results of each test in detail.
Commandment 5. Connect each module to the program only once; never modify the program to make it easier to test.
Commandment 6. Skip again all tests related to checking the operation of any PS program or its interaction with other programs, if changes have been made to it (for example, as a result of fixing an error).
10.4. Debugging a module offline.
In standalone debugging, each module is actually tested in some programming environment, unless the program being debugged consists of only one module. This environment consists of other modules, some of which are modules of the program being debugged that have already been debugged, and some are modules that control debugging (debug modules, see below). Thus, during autonomous debugging, a program is always tested, built specifically to test the module being debugged. This program only partially coincides with the program being debugged, except for the case when the last module of the program being debugged is being debugged. As the debugging of the program progresses, more and more of the environment of the next debugged module will be made up of already debugged modules of this program, and when debugging the last module of this program, the environment of the debugged module will entirely consist of all the other (already debugged) modules of the program being debugged (without any) debugging modules, i.e. in this case, the program being debugged will be tested. This process of building up a debugged program with debugged and debugged modules is called program integration.
The debug modules included in the environment of the module being debugged depend on the order in which the modules of this program are debugged, on which module is being debugged and, possibly, on which test will be skipped.
During bottom-up testing (see Lecture 7), this environment will always contain only one debug unit (except for the case when the last unit of the program being debugged), which will be the head in the program under test and which is called the master (or driver). The leading debug module prepares the information environment for testing the module being debugged (that is, it generates its state required for testing this module, in particular, it can enter some test data), addresses the module being debugged and, after its completion, issues the necessary messages. When debugging one module, different master debug modules can be compiled for different tests.
In top-down testing (see Lecture 7), the environment of the module being debugged as debugging modules contains simulators of all modules that the module being debugged can access, as well as simulators of those modules that can be accessed by debugged modules of the program being debugged (included in this environment), but which are not yet debugged. Some of these simulators, when debugging a single module, may change for different tests.
In fact, the environment of the module being debugged in many cases can contain both types of debug modules for the following reasons. Both bottom-up and top-down testing have their advantages and disadvantages.
Benefits of bottom-up testing include
ease of preparing tests and
the ability to fully implement the unit test plan.
This is due to the fact that the test state of the information environment is prepared immediately before accessing the module being debugged (by the leading debugging module). The disadvantages of bottom-up testing are the following:
test data is prepared, as a rule, not in the form that is intended for the user (except for the case when the last, head, module of the program being debugged is being debugged);
a large amount of debugging programming (when debugging one module, you often have to compose many leading debugging modules for different tests);
the need for special testing of interface modules.
The advantages of top-down testing include the following features:
most tests are prepared in a user-friendly form;
in many cases, a relatively small amount of debugging programming (module simulators are usually quite simple and each is suitable for a large number, often all, tests);
there is no need to test the pairing of modules.
The disadvantage of top-down testing is that the test state of the information environment before accessing the debugged module is prepared indirectly - it is the result of applying already debugged modules to test data or data issued by simulators. This, firstly, makes it difficult to prepare tests, requires high qualifications of the test engineer, and secondly, it makes it difficult or even impossible to implement the full test plan of the module being debugged. This disadvantage sometimes forces developers to apply bottom-up testing even in the case of top-down development. However, some modifications of top-down testing, or some combination of top-down and bottom-up testing are used more often.
Proceeding from the fact that top-down testing, in principle, is preferable, let us dwell on the techniques that allow, to some extent, to overcome these difficulties. First of all, it is necessary to organize the debugging of the program in such a way that the modules carrying out data entry are debugged as early as possible - then the test data can be prepared in a form designed for the user, which will greatly simplify the preparation of subsequent tests. This input is by no means always carried out in the head module; therefore, it is necessary first of all to debug the chains of modules leading to the modules carrying out the specified input (compare with the method of purposeful constructive implementation in Lecture 7). Until the input modules are debugged, the test data is supplied by some simulators: they are either included in the simulator as part of it, or are injected by the simulator.
During downward testing, some states of the information environment, in which it is necessary to test the module being debugged, may not occur during the execution of the program being debugged for any input data. In these cases, it would be possible not to test the module being debugged at all, since the errors detected in this case will not appear during the execution of the program being debugged for any input data. However, it is not recommended to do this, since when the program being debugged changes (for example, when maintaining the software system), the information environment states that were not used for testing the debugged module may already arise, which requires additional testing of this module (and this could not be done with a rational organization of debugging if the module itself has not changed). To test the debugged module in these situations, sometimes suitable simulators are used to create the required state of the information environment. More often, they use a modified version of top-down testing, in which the debugged modules are pre-tested separately before being integrated (in this case, a leading debug module appears in the environment of the debugged module, along with simulators of modules that the debugged module can access). However, another modification of top-down testing seems to be more expedient: after the completion of top-down testing of the debugged module for achievable test states of the information environment, it should be tested separately for the remaining required states of the information environment.
A combination of upward and downward testing, which is called the sandwich method, is also often used. The essence of this method lies in the simultaneous implementation of both bottom-up and top-down testing, until these two testing processes meet on some module somewhere in the middle of the structure of the program being debugged. This method allows, with a reasonable approach, to take advantage of the advantages of both bottom-up and top-down testing and largely neutralize their disadvantages. This effect is a manifestation of a more general principle: the greatest technological effect can be achieved by combining top-down and bottom-up methods of developing FP programs. It is to support this method that the architectural approach to software development is intended (see lecture 7): a layer of skillfully developed and thoroughly tested modules greatly facilitates the implementation of a family of programs in the corresponding subject area and their subsequent modernization.
It is very important for offline debugging to test the pairing of modules. The fact is that the specification of each program module, except for the head one, is used in this program in two situations: firstly, when developing the text (sometimes they say: the body) of this module and, secondly, when writing a call to this module in others modules of the program. In either case, as a result of an error, the required compliance with the given module specification may be violated. Such errors need to be detected and eliminated. This is the purpose of testing the interface between modules. In top-down testing, pairing testing is performed along the way with each test that is skipped, which is considered the strongest advantage of top-down testing. During bottom-up testing, the address to the debugged module is made not from the modules of the program being debugged, but from the master debugger. In this regard, there is a danger that the last module may adapt to some "delusions" of the module being debugged. Therefore, when starting (in the process of program integration) debugging a new module, you have to test each call to a previously debugged module in order to detect inconsistency of this call with the body of the corresponding module (and it is possible that a previously debugged module is to blame for this). Thus, it is necessary to partially repeat the testing of a previously debugged module under new conditions, while the same difficulties arise as in top-down testing.
It is advisable to carry out autonomous testing of a module in four sequential steps.
Step 1. Based on the specification of the module being debugged, prepare a test for each possibility and each situation, for each boundary of the range of valid values of all inputs, for each range of data changes, for each range of invalid values of all inputs and each invalid condition.
Step 2. Check the text of the module to make sure that every direction of any branch will pass at least one test. Add missing tests.
Step 3. Make sure according to the module text that for each loop there is a test for which the loop body is not executed, a test for which the loop body is executed once, and a test for which the loop body is executed the maximum number of times. Add missing tests.
Step 4. Check in the text of the module its sensitivity to individual special values of the input data - all such values should be included in the tests. Add missing tests.
10.5. Complex software debugging.
As mentioned above, during complex debugging, the software system is tested as a whole, and tests are prepared for each of the software documents. Testing of these documents is carried out, as a rule, in the reverse order of their development (the only exception is testing the application documentation, which is developed according to an external description in parallel with the development of program texts; it is better to perform this testing after testing the external description). Testing with complex debugging is the application of software systems to specific data that, in principle, may arise from the user (in particular, all tests are prepared in a form designed for the user), but possibly in a simulated (and not in real) environment. For example, some input and output devices that are not available in complex debugging can be replaced by their software simulators.
Testing the PS architecture. The purpose of testing is to find a discrepancy between the description of the architecture and the set of software programs. By the time the testing of the PS architecture begins, the autonomous debugging of each subsystem should have already been completed. Errors in the implementation of the architecture can be associated primarily with the interaction of these subsystems, in particular, with the implementation of architectural functions (if any). Therefore, I would like to check all the ways of interaction between the subsystems of the PS. But since there may be too many of them, it would be desirable to test at least all the chains of execution of the subsystems without re-entering the latter. If the given architecture represents the PS as a small system of dedicated subsystems, then the number of such chains will be quite visible.
Testing external functions. The purpose of testing is to find discrepancies between the functional specification and the set of software programs. Despite the fact that all these programs have already been debugged autonomously, the indicated discrepancies may be, for example, due to the inconsistency of the internal specifications of the programs and their modules (on the basis of which the autonomous testing was carried out) with the external functional specification of the software system. As a rule, testing of external functions is performed in the same way as testing of modules in the first step, i.e. like a black box.
Testing the quality of the PS. The purpose of testing is to search for violations of the quality requirements formulated in the quality specification of the software system. This is the most difficult and least studied type of testing. It is only clear that not every primitive of software quality can be tested by testing (about assessing the quality of software, see the next lecture). The completeness of the PS is checked already when testing external functions. At this stage, testing of this quality primitive can be continued if it is required to obtain any probabilistic estimate of the PS reliability degree. However, the methodology for such testing still needs to be developed. Accuracy, robustness, security, time efficiency, to some extent memory efficiency, device efficiency, scalability and, in part, device independence can be tested. Each of these types of testing has its own specifics and deserves separate consideration. We will limit ourselves here only to their enumeration. The ease of application of the PS (a quality criterion that includes several quality primitives, see Lecture 4) is assessed when testing the documentation for the application of the PS.
Testing documentation for the application of the PS. The purpose of testing is to search for inconsistency between the application documentation and the set of software programs, as well as the inconveniences of using the software. This stage immediately precedes the connection of the user to the completion of the software development (testing the requirements for the software and attesting the software), therefore it is very important for the developers to first use the software as the user will do it. All tests at this stage are prepared solely on the basis of only the documentation for the application of the PS. First of all, the capabilities of the software should be tested as it was done when testing external functions, but only on the basis of the application documentation. Any obscure points in the documentation should be tested, as well as all examples used in the documentation. Further, the most difficult cases of application of the PS are tested in order to detect a violation of the requirements of the relativity of the ease of application of the PS.
Testing the definition of requirements for the PS. The purpose of testing is to find out to what extent a software system does not meet the stated definition of requirements for it. The peculiarity of this type of testing is that it is carried out by the purchasing organization or the user organization of the software system as one of the ways to overcome the barrier between the developer and the user (see Lecture 3). Usually this testing is performed using control tasks - typical tasks for which the result of the solution is known. In those cases when the developed software system should replace another version of the software system, which solves at least part of the tasks of the developed software system, testing is performed by solving common problems using both the old and the new software system with the subsequent comparison of the results obtained. Sometimes, as a form of such testing, they use experimental operation of the PS - a limited application of a new PS with an analysis of the use of the results in practical activities. In essence, this type of testing has much in common with testing a PS during its attestation (see Lecture 14), but it is performed before attestation, and sometimes instead of attestation.
Literature for lecture 10.
10.1. G. Myers. Reliability of software. - M .: Mir, 1980 .-- S. 171-262.
10.2. D. Van Tassel. Style, development, efficiency, debugging and testing programs. - M .: Mir, 1985 .-- S. 179-295.
10.3. J. Hughes, J. Michtom. A structured approach to programming. - M .: Mir, 1980 .-- S. 254-268.
10.4. J. Fox. Software and its development. - M .: Mir, 1985 .-- S. 227-241.
10.5. M. Zelkovits, A. Shaw, J. Gannon. Principles of software development. - M .: Mir, 1982 .-- S. 105-116.
10.6. Yu.M. Bezborodov. Individual debugging of programs. - M .: Nauka, 1982 .-- S. 9-79.
10.7. V.V. Lipaev. Testing programs. - M .: Radio and communication, 1986. - S. 15-47.
10.8. E.A. Zhogolev. Introduction to programming technology (lecture notes). - M .: "DIALOG-MGU", 1994.
10.9. E. Dijkstra. Notes on structured programming. // U. Dahl, E. Dijkstra, K. Hoore. Structured programming. - M .: Mir, 1975 .-- S. 7-13.
Lecture 11. Ensuring the functionality and reliability of the software tool
11.1. Functionality and reliability as mandatory criteria for the quality of a software tool.
In the previous lecture, we examined all the stages of software development, except for its certification. At the same time, we did not touch upon the issues of ensuring the quality of the PS in accordance with its quality specification (see lecture 4). True, while implementing the functional specification of the PS, we thereby discussed the main issues of ensuring the criterion of functionality. Having declared the reliability of the software system as its main attribute (see Lecture 1), we chose error prevention as the main approach to ensure the reliability of the software system (see Lecture 3) and discussed its implementation at different stages of software development. Thus, the thesis about the mandatory functionality and reliability of the software system as criteria for its quality was manifested.
Nevertheless, the quality specification of the software system may contain additional characteristics of these criteria, the provision of which requires special discussion. This lecture is devoted to these questions. Assurance of other quality criteria will be discussed in the next lecture.
Below, we discuss the provision of software quality primitives that express criteria for the functionality and reliability of the software.
11.2. Ensuring the completeness of the software.
Completeness of the PS is the general primitive of the quality of the PS for the expression of both the functionality and reliability of the PS, and for the functionality it is the only primitive (see Lecture 4).
The functionality of a software system is determined by its functional specification. The completeness of the PS as a primitive of its quality is a measure of how this specification is implemented in the given PS. Providing this primitive in its entirety means implementing each of the functions defined in the functional specification, with all the details and features specified there. All of the previously discussed technological processes show how this can be done.
However, in the specification of the quality of the software system, several levels of implementation of the software functionality can be defined: a certain simplified (initial or initial) version can be defined, which must be implemented in the first place, and several intermediate versions can also be defined. In this case, an additional technological task arises: the organization of increasing the functionality of the PS. It is important to note here that the development of a simplified version of the software system is not the development of its prototype. The prototype is being developed in order to better understand the conditions for using the future PS, to clarify its external description. It is designed for selected users and therefore may differ greatly from the required software system not only in the functions performed, but also in the features of the user interface. A simplified version of the required software system should be designed for practical use by any users for whom it is intended. Therefore, the main principle of ensuring the functionality of such a software system is to develop the software system from the very beginning in such a way as if the software system is required in full, until the developers deal with those parts or details of the software system, the implementation of which can be postponed. according to the specification of its quality. Thus, both the external description and the description of the PS architecture should be developed in full. You can only postpone the implementation of those software subsystems defined in the architecture of the developed software system, the functioning of which is not required in the initial version of this software system. The implementation of the software subsystems themselves is best done by the method of purposeful constructive implementation, leaving in the initial version of the software the appropriate simulators of those software modules, the functioning of which is not required in this version. A simplified implementation of some software modules, which omits the implementation of some details of the corresponding functions. However, from a technological point of view, such modules are best viewed as a kind of their imitators (albeit far advanced).
Due to the errors in the developed software system, the completeness achieved while ensuring its functionality (in accordance with the specification of its quality) may actually not be as expected. We can only say that this completeness has been achieved with a certain probability, determined by the volume and quality of the testing performed. In order to increase this probability, it is necessary to continue testing and debugging the software. However, the estimation of such a probability is a very specific task (taking into account the fact that the manifestation of the error in the PS is a function of the initial data), which is still awaiting corresponding theoretical studies.
11.3. Ensuring the accuracy of the software.
The provision of this primitive is associated with actions on values of real types (more precisely, with values that are represented with some error). To ensure the required accuracy when calculating the value of a particular function means to obtain this value with an error that does not go beyond the specified limits. Computational mathematics deals with the types of errors, methods of their estimation and methods of achieving the required accuracy (so-called approximate calculations). Here we will only pay attention to some structure of the error: the error of the calculated value (total error) depends
on the error of the calculation method used (in which we include the inaccuracy of the model used),
from the error in the presentation of the data used (from the so-called fatal error),
from the rounding error (inaccuracies in the execution of the operations used in the method).
11.4. Ensuring the autonomy of the software.
This quality primitive is provided at the stage of quality specification by making a decision on the use of any suitable basic software in the developed software or not to use any basic software in it. In this case, it is necessary to take into account both its reliability and the resources required for its use. With increased requirements for the reliability of the developed software system, the reliability of the basic software at the disposal of developers may turn out to be unsatisfactory, therefore, its use has to be abandoned, and the implementation of its functions in the required volume must be included in the software system. Similar decisions have to be made with strict restrictions on the resources used (according to the PS efficiency criterion).
11.5. Ensuring the stability of the software.
This quality primitive is provided by what is known as defensive programming. Generally speaking, defensive programming is used to improve the reliability of the PS when programming the module in a broader sense. As Myers argues, "Defensive programming is based on an important premise: the worst a module can do is accept incorrect input and then return an incorrect but plausible result." In order to avoid this, the text of the module includes checks of its input and output data for their correctness in accordance with the specification of this module, in particular, the fulfillment of the restrictions on the input and output data and the relationships between them specified in the module specification must be checked. If the check fails, a corresponding exception is raised. In this regard, fragments of the second kind are included at the end of this module - handlers of the corresponding exception situations, which, in addition to issuing the necessary diagnostic information, can take measures either to eliminate errors in the data (for example, to require their re-entry), or to weaken the effect of the error (for example , soft stop of the devices controlled by the PS in order to avoid their breakdown in case of an emergency termination of the program execution).
The use of defensive programming of modules leads to a decrease in the efficiency of the PS both in time and in memory. Therefore, it is necessary to reasonably regulate the degree of application of defensive programming, depending on the requirements for the reliability and efficiency of the software system, formulated in the quality specification of the software system being developed. The input data of the module being developed can come either directly from the user or from other modules. The most common use case for defensive programming is its application for the first group of data, which means the implementation of the stability of the software. This should be done whenever there is a requirement to ensure the stability of the software in the PS quality specification. Using defensive programming for the second group of inputs means trying to detect an error in other modules during the execution of a module under development, and for the output of a developed module, an attempt to detect an error in this module itself during its execution. In essence, this means a partial implementation of the error self-detection approach to ensure the reliability of the software, which was discussed in lecture 3. This case of defensive programming is used extremely rarely - only when the requirements for the reliability of the software are extremely high.
11.6. Ensuring the security of software.
There are the following types of software protection against information distortion:
protection against hardware failures;
protection from the influence of a "foreign" program;
protection against failures of "own" program;
protection against operator (user) errors;
protection against unauthorized access;
protection from protection.
Protection against hardware failures is currently not a very pressing problem (given the level of achieved reliability of computers). But it is still useful to know its solution. This is ensured by the organization of the so-called "double-triple miscalculations". For this, the entire data processing process, determined by the PS, is divided in time into intervals by the so-called "reference points". The length of this interval should not exceed half the computer's MTBF. A copy of the state of the memory changed in this process for each reference point is written into the secondary memory with a certain checksum (a number calculated as a function of this state) in the case when it will be considered that the processing of data from the previous reference point to this one (i.e. one "miscalculation") was done correctly (without crashing the computer). In order to find out, two such "miscalculations" are made. After the first "miscalculation", the specified checksum is calculated and stored, and then the memory state for the previous reference point is restored and the second "miscalculation" is made. After the second "miscalculation", the specified checksum is calculated again, which is then compared with the checksum of the first "miscalculation". If these two checksums match, the second miscalculation is considered correct, otherwise the checksum of the second "miscalculation" is also remembered and the third "miscalculation" is performed (with a preliminary restoration of the memory state for the previous reference point). If the checksum of the third "miscalculation" matches the checksum of one of the first two "miscalculations", then the third miscalculation is considered correct, otherwise an engineering check of the computer is required.
Protection against the influence of a "foreign" program refers primarily to operating systems or to programs that partially perform their functions. There are two types of this protection:
failure protection,
protection from the malicious influence of a "foreign" program.
When a multi-program mode of operation of a computer appears in its memory, several programs can be simultaneously in the execution stage, alternately receiving control as a result of arising interruptions (the so-called quasi-parallel program execution). One of these programs (usually: the operating system) deals with interrupt handling and multiprogramming. In each of these programs, failures (errors) can occur, which can affect the performance of functions by other programs. Therefore, the control program (operating system) must protect itself and other programs from such influence. To do this, the computer hardware must implement the following capabilities:
memory protection,
two modes of computer functioning: privileged and working (user),
two types of operations: privileged and ordinary,
correct implementation of interrupts and initial computer start-up,
temporary interruption.
Memory protection means the ability to programmatically set for each program areas of memory inaccessible to it. In the privileged mode, any operations can be performed (both ordinary and privileged), and in the operating mode, only ordinary ones. An attempt to perform a privileged operation, as well as to access protected memory in operating mode, causes a corresponding interrupt. Moreover, privileged operations include operations for changing memory protection and operating mode, as well as access to the external information environment. Initial power-up of the computer and any interruption should automatically enable privileged mode and override memory protection. In this case, the control program (operating system) can completely protect itself from the influence of other programs, if all points of transfer of control during initial power-up and interrupts belong to this program, if it does not allow any other program to work in privileged mode (when transferring control to any other the program will only turn on the operating mode) and if it completely protects its memory (containing, in particular, all its control information, including the so-called interrupt vectors) from other programs. Then no one will prevent it from performing any functions of protection of other programs implemented in it (including access to the external information environment). To facilitate the solution of this problem, a part of such a program is placed in permanent memory, i.e. inseparable from the computer itself. The presence of a temporary interrupt allows the control program to protect itself from looping in other programs (without such an interruption, it could simply lose the ability to control).
Protection against failures of "own" program is ensured by the reliability of this program, which is the focus of all programming technology discussed in this course of lectures.
Protection against user errors (in addition to input data errors, see ensuring the stability of the software system) is provided by issuing warning messages about attempts to change the state of the external information environment with the requirement to confirm these actions, as well as the ability to restore the state of individual components of the external information environment. The latter is based on archiving changes in the state of the external information environment.
Protection against unauthorized access is ensured by using secret words (passwords). In this case, each user is provided with certain information and procedural resources (services), the use of which requires the PS to present a certain password previously registered in the PS by this user. In other words, the user, as it were, "hangs a lock" on the resources allocated to him, the "key" of which only this user has. However, in some cases, persistent attempts can be made to break such protection, if the protected resources are of extreme value to someone. In such a case, you have to take additional measures to protect against hacking protection.
Protection against hacking of protection is associated with the use of special programming techniques in the software that make it difficult to overcome the protection against unauthorized access. The use of regular passwords is insufficient when it comes to an extremely persistent desire (for example, of a criminal nature) to gain access to valuable information. First, because the information about passwords used by a PS to protect against unauthorized access, the "cracker" of this protection can relatively easily get if he has access to this PS itself. Secondly, using a computer, it is possible to carry out a sufficiently large enumeration of possible passwords in order to find a suitable one for accessing the information of interest. You can protect yourself from such hacking as follows. The secret word (password) or just a secret integer X is known only by the owner of the protected information, and to check access rights, another number Y = F (X) is stored in the computer, which is uniquely calculated by the PS for each attempt to access this information upon presentation of the secret word. In this case, the function F may be well known to all PS users, but it has such a property that it is practically impossible to restore the word X from Y: with a sufficiently large length of the word X (for example, several hundred characters), this requires astronomical time. Such a number Y will be called the electronic (computer) signature of the owner of the secret word X (and hence of the protected information).
Another type of such protection is associated with the protection of messages sent over computer networks, deliberate (or malicious) distortion. Such a message can be intercepted at the "transshipment" points of the computer network and replaced by another message from the author of the intercepted message. This situation arises primarily when carrying out banking operations using a computer network. By substituting such a message, which is an order of the owner of a bank account to perform a certain banking operation, money from his account can be transferred to the account of the "cracker" of protection (a kind of computer bank robbery). Protection against such a breach of protection can be implemented as follows. Along with the function F, which determines the computer signature of the owner of the secret word X, which the addressee of the protected message knows (if only its owner is a client of this addressee), the PS defines another Stamp function, according to which the sender of the message must calculate the number S = Stamp (X, R ), using the secret word X and the text of the transmitted message R. The Stamp function is also considered well known to all PS users and has such a property that it is practically impossible to recover the number X from S, or to pick up another message R with the corresponding computer signature. The transmitted message itself (together with its protection) must have the form:
moreover, Y (computer signature) allows the addressee to establish the truth of the client, and S, as it were, bonds the protected message R with a computer signature Y. In this regard, we will call the number S an electronic (computer) seal. The PS defines one more function Notary, according to which the recipient of the protected message checks the truth of the transmitted message:
This makes it possible to unambiguously establish that the message R belongs to the owner of the secret word X.
Protection from protection is necessary in the event that the user has forgotten (or lost) his password. For such a case, it should be possible for a special user (PS administrator) responsible for the functioning of the protection system to temporarily remove the protection against unauthorized access for the owner of the forgotten password in order to enable him to fix a new password.
Literature for lecture 11.
11.1. I.S. Berezin, N.P. Zhidkov. Calculation methods, vol. 1 and 2. - Moscow: Fizmatgiz, 1959.
11.2. NS. Bakhvalov, N.P. Zhidkov, G.M. Kobelkov. Numerical methods. - M .: Nauka, 1987.
11.3. G. Myers. Reliability of software. - M .: Mir, 1980.S. 127-154.
11.4. A.N. Lebedev. Banking information security and modern cryptography // Information security issues, 2 (29), 1995.
Lecture 12. Software quality assurance
12.1. General characteristics of the quality assurance process for software tools.
As already noted in Lecture 4, the quality specification defines the main guidelines (goals), which at all stages of software development in one way or another affect the choice of a suitable option when making various decisions. However, each quality primitive has its own characteristics of such an influence, thus, ensuring its presence in the software system may require its own approaches and methods for developing the software system or its individual parts. In addition, the inconsistency of the quality criteria of the PS and the quality primitives expressing them was also noted: a good provision of any one of the PS quality primitives can significantly complicate or make it impossible to provide some other of these primitives. Therefore, an essential part of the process of ensuring the quality of software products consists of finding acceptable trade-offs. These trade-offs should be partially determined already in the PS quality specification: the PS quality model should specify the required degree of presence in the PS of each of its quality primitives and determine the priorities for achieving these degrees.
Quality assurance is carried out in each technological process: the decisions made in it, to one degree or another, have an impact on the quality of the software system as a whole. In particular, because a significant part of the quality primitives is associated not so much with the properties of the programs included in the software system, but with the properties of the documentation. Due to the noted inconsistency of the primitives of quality, it is very important to adhere to the selected priorities in their provision. But in any case, it is useful to adhere to two general principles:
first, it is necessary to ensure the required functionality and reliability of the PS, and then bring the remaining quality criteria to an acceptable level of their presence in the PS;
there is no need and may even be harmful to achieve a higher level of presence in the PS of any quality primitive than that defined in the PS quality specification.
Ensuring the functionality and reliability of the PS was discussed in the previous lecture. The following discusses the provision of other quality criteria for the FP.
12.2 .. Ensuring ease of use of the software tool
P-documentation of the software system determines the composition of user documentation
In the previous lecture, we have already discussed the provision of two of the five quality primitives (stability and security), which determine the ease of application of the PS.
P-documentation and informativeness determine the composition and quality of user documentation (see the next lecture).
Interoperability is ensured by creating a suitable user interface and appropriate implementation of exceptions. What is the problem here?
12.3. Ensuring the effectiveness of the software.
The effectiveness of the software system is ensured by making appropriate decisions at different stages of its development, starting with the development of its architecture. The choice of the structure and presentation of the data affects the efficiency of the SE (especially in terms of memory) especially strongly. But the choice of algorithms used in certain software modules, as well as the specifics of their implementation (including the choice of a programming language) can significantly affect the efficiency of a software system. At the same time, it is constantly necessary to resolve the contradiction between temporal efficiency and memory efficiency. Therefore, it is very important that the quality specification clearly indicates the quantitative relationship between the indicators of these primitives of quality, or at least set quantitative boundaries for one of these indicators. And yet, different software modules have different effects on the efficiency of the software system as a whole: both in terms of the contribution to the total costs of the software system in terms of time and memory, and in terms of the effect on different quality primitives (some modules can strongly influence the achievement of time efficiency and practically have no effect on memory efficiency, while others can significantly affect the overall memory consumption without having a noticeable effect on the operating time of the PS). Moreover, this influence (primarily in relation to temporary efficiency) in advance (before the end of the implementation of the PS) is far from always possible to correctly assess.
first, you need to develop a reliable software system, and only then achieve the required efficiency in accordance with the quality specification of this software;
to increase the efficiency of the software system, use, first of all, an optimizing compiler - this can provide the required efficiency;
if the achieved efficiency of the PS does not meet the specification of its quality, then find the most critical modules in terms of the required efficiency of the PS (in the case of time efficiency, this will require obtaining the distribution by the modules of the operating time of the PS by means of appropriate measurements during the execution of the PS); these modules and try to optimize them first by manually reworking them;
do not optimize the module if it is not required to achieve the required efficiency of the PS.
12.4. Ensuring maintainability.
C-documentation, informativeness and comprehensibility determine the composition and quality of the maintenance documentation (see the next lecture). In addition, the following recommendations can be made regarding the texts of programs (modules).
use comments in the text of the module that clarify and explain the features of the decisions made; If possible, include comments (at least in short form) at the earliest stage of the development of the module text;
use meaningful (mnemonic) and persistently distinguishable names (the optimal name length is 4-12 letters, numbers at the end), do not use similar names and keywords;
be careful when using constants (a unique constant must have only one occurrence in the module text: when it is declared or, in extreme cases, when the variable is initialized as a constant);
don't be afraid to use optional parentheses (parentheses are cheaper than mistakes;
place no more than one operator per line; to clarify the structure of the module, use additional spaces (indentation) at the beginning of each line;
avoid tricks i.e. such programming techniques when fragments of a module are created, the main effect of which is not obvious or hidden (veiled), for example, side effects functions.
Extensibility is provided by creating a suitable installer.
The structuredness and modularity make it easier to understand both the program texts and their modification.
12.5. Providing mobility.
Literature for lecture 12.
12.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.
12.3. D. Van Tassel. Style, development, efficiency, debugging and testing programs. - M .: Mir, 1985.S. 8-44, 117-178.
12.4. Software User Documentation / ANSI / IEEE Standard 1063-1987.
Lecture 13. Documenting software
13.1. Documentation created during software development.
When developing a software system, a large amount of various documentation is created. It is needed as a means of transferring information between software developers, as a means of managing software development and as a means of transferring information to users necessary for the application and maintenance of software. The creation of this documentation accounts for a large share of the cost of the PS.
This documentation can be broken down into two groups:
Software development management documents.
Documents that are part of the PS.
Software development management documents (process documentation) record the processes of software development and maintenance, providing connections within the development team and between the development team and managers - persons managing the development. These documents can be of the following types:
Plans, estimates, schedules. These documents are created by managers to predict and manage development and maintenance processes.
Resource usage reports during development. Created by managers.
Standards. These documents prescribe to developers what principles, rules, agreements they must follow in the process of developing software. These standards can be both international or national, and specially created for the organization, which is developing this software.
Work documents. These are the main technical documents that provide communication between developers. They contain a fixation of ideas and problems arising in the development process, a description of the strategies and approaches used, as well as working (temporary) versions of documents that should be included in the PS.
Notes and correspondence. These documents document various details of interaction between managers and developers.
The documents that make up the PS (product documentation) describe PS programs both in terms of their application by users, and from the point of view of their developers and maintainers (in accordance with the purpose of the PS). It should be noted here that these documents will be used not only at the stage of operation of the PS (in its phases of application and maintenance), but also at the development stage to manage the development process (together with working documents) - in any case, they should be checked (tested) for compliance with the PS programs. These documents form two sets with different purposes:
User documentation of the PS (P-documentation).
Substation support documentation (C-documentation).
13.2. User documentation of software tools.
User documentation of the software system (user documentation) explains to users how they should proceed in order to apply this software system. It is necessary if the PS involves any interaction with users. Such documentation includes the documents that the user is guided by when installing the PS (when installing the PS with the appropriate setting for the PS application environment), when using the PS to solve their problems and when controlling the PS (for example, when this PS interacts with other systems). These documents partially touch upon the issues of software support, but do not touch upon the issues related to the modification of programs.
In this regard, two categories of PS users should be distinguished: ordinary PS users and PS administrators. An ordinary user of the PS (end-user) uses the PS to solve his problems (in his subject area). This can be an engineer designing a technical device, or a cashier selling train tickets using a PS. He may not know many details of the computer or the principles of programming. The PS administrator (system administrator) manages the use of the PS by ordinary users and maintains the PS that is not related to the modification of programs. For example, it can regulate access rights to the PS between ordinary users, keep in touch with PS suppliers, or perform certain actions to keep the PS in working order if it is included as part of another system.
The composition of user documentation depends on the audiences of users to which this software is oriented, and on the mode of use of the documents. The audience here is understood as the contingent of PS users who need a certain PS user documentation. A successful user document essentially depends on the precise definition of the audience for which it is intended. User documentation should contain the information required for each audience. The mode of use of a document refers to the way that determines how the document is used. Typically, a user of large enough software systems requires either documents for studying PS (use in the form of instructions), or to clarify some information (use in the form of a reference book).
In accordance with the works, the following composition of user documentation for sufficiently large PS can be considered typical:
General functional description of the PS. Gives a brief description of the functionality of the PS. It is intended for users who need to decide how much they need this software.
Substation installation manual. Designed for system administrators. It should prescribe in detail how to install systems in a particular environment. It should contain a description of the machine-readable medium on which the PS is supplied, files representing the PS, and the requirements for the minimum hardware configuration.
Instructions for the use of PS. Designed for ordinary users. Contains the necessary information on the application of the PS, organized in a form convenient for its study.
Handbook on the use of PS. Designed for ordinary users. Contains the necessary information on the application of the PS, organized in a form convenient for the selective search for individual parts.
PS Management Guide. Designed for system administrators. It should describe the messages generated when the PS interacts with other systems and how to respond to these messages. In addition, if the MS uses system hardware, this document may explain how to maintain that hardware.
As mentioned earlier (see Chapter 4), user documentation development begins as soon as the external description is created. The quality of this documentation can significantly determine the success of the COP. It should be quite simple and user-friendly (otherwise, this PS, in general, should not have been created). Therefore, while drafts (sketches) of user documents are created by the main developers of the software, professional technical writers are often involved in the creation of their final versions. In addition, to ensure the quality of user documentation, a number of standards have been developed (see, for example,), which prescribe the procedure for developing this documentation, formulate requirements for each type of user documents, and determine their structure and content.
13.3. Software maintenance documentation.
The system documentation describes the software system from the point of view of its development. This documentation is necessary if the software system involves the study of how it is arranged (designed), and the modernization of its programs. As noted, maintenance is an ongoing development. Therefore, if it is necessary to modernize the substation, a special team of support developers is involved in this work. This team will have to deal with the same documentation that determined the activities of the original (main) software development team, with the only difference that this documentation for the maintainer development team will, as a rule, be foreign (it was created by another team). The development team-maintainers will have to study this documentation in order to understand the structure and development process of the upgraded software system, and make the necessary changes to this documentation, largely repeating the technological processes with which the original software was created.
The documentation for the support of the PS can be divided into two groups:
(1) documentation that defines the structure of programs and data structures of software systems and the technology for their development;
(2) documentation to help make changes to the OS.
The documentation of the first group contains the final documents of each technological stage of software development. It includes the following documents:
External description of the SS (Requirements document).
Description of the system architecture, including the external specification of each of its programs.
For each PS program - a description of its modular structure, including the external specification of each module included in it.
For each module - its specification and description of its structure (design description).
Module texts in the selected programming language (program source code listings).
Validation documents describing how the validity of each CA program was established and how the validation information was linked to the CA requirements.
Documents for establishing the validity of software systems include, first of all, documentation on testing (testing scheme and description of a set of tests), but may also include the results of other types of software testing, for example, proof of program properties.
The second group documentation contains
The system maintenance guide, which describes the known problems with the software, describes which parts of the system are hardware and software dependent, and how the development of the software is taken into account in its structure (design).
A common problem in maintaining a COP is to ensure that all of its views keep up (stay consistent) when the COP changes. To help this, the links and dependencies between documents and their parts must be captured in the configuration management database.
Literature for lecture 13.
13.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.
13.2. ANSI / IEEE Std 1063-1988, IEEE Standard for Software User Documentation.
13.3. ANSI / IEEE Std 830-1984, IEEE Guide for Software Requirements Specification.
13.4. ANSI / IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Description.
13.5. ANSI / IEEE Std 1008-1987, IEEE Standard for Software Unit Testing.
13.6. ANSI / IEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans.
13.7. ANSI / IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.
13.8. ANSI / IEEE Std 829-1983, IEEE Standard for Software Test Documentation.
Lecture 14. Certification of software tools
Purpose of software certification. Testing and assessing the quality of software. Types of tests and methods for assessing the quality of software.
14.1. Purpose of software certification.
PS certification is an authoritative confirmation of the PS quality. Typically, a representative (attestation) commission of experts, customer representatives and developer representatives is created for PS certification. This commission conducts PS tests in order to obtain the necessary information to assess its quality. By PS testing, we mean the process of carrying out a set of measures that investigate the PS suitability for its successful operation (application and maintenance) in accordance with the customer's requirements. This complex includes checking the completeness and accuracy of the software documentation, studying and discussing its other properties, as well as the necessary testing of the programs included in the software system, and, in particular, the compliance of these programs with the available documentation.
Based on the information obtained during the testing of the PS, first of all, it should be established that the PS performs the declared functions, and it should also be established to what extent the PS has the declared primitives and quality criteria. Thus, the assessment of the quality of the PS is the main content of the certification process. The performed assessment of the quality of the PS is recorded in the corresponding decision of the attestation commission.
14.2. Types of software tests.
The following types of PS tests are known for the purpose of PS certification:
testing of PS components;
system tests;
acceptance tests;
field trials;
industrial tests.
Testing of PS components is a check (testing) of the operability of individual PS subsystems. They are carried out only in exceptional cases by a special decision of the attestation commission.
System tests of a PS is a check (testing) of the PS as a whole. It can include the same types of testing as in complex debugging of software systems (see Lecture 10). It is carried out by the decision of the attestation commission, if there are doubts about the quality of debugging by the developers of the software system.
Acceptance tests are the main type of tests for PS certification. It is with these tests that the certification commission begins its work. These tests begin with a study of the provided documentation, including the documentation for testing and debugging software systems. If the documentation does not contain sufficiently complete results of PS testing, the certification committee may decide to conduct system tests of the PS or to terminate the certification process with a recommendation to the developer to conduct additional (more complete) PS testing. In addition, during these tests, developer tests can be selectively skipped, as well as user control tasks (see Lecture 10) and additional tests prepared by the panel to assess the quality of the certified software.
Field testing of a PS is a demonstration of a PS, together with the technical system that is controlled by this PS, to a narrow circle of customers in real conditions, and a careful observation of the behavior of the PS is carried out. Customers should be given the opportunity to set their own test cases, in particular, from exits to critical modes of operation. technical system, as well as with the call of emergency situations in it. These are additional tests carried out by the decision of the certification commission only for some PSs that control certain technical systems.
Industrial testing of PS is the process of transferring PS for permanent operation to users. It is a period of pilot operation of the aircraft (see lecture 10) by users with the collection of information about the features of the aircraft's behavior and its operational characteristics. These are the final tests of the PS, which are carried out by the decision of the certification commission, if insufficient complete or reliable information was obtained during the previous tests to assess the quality of the certified PS.
14.3. Methods for assessing the quality of software.
Assessment of the quality of the PS for each of the criteria is reduced to the assessment of each of the primitives associated with this criterion of the quality of the PS, in accordance with their specification, made in the quality specification of this PS. Methods for assessing the primitives of the quality of software systems can be divided into four groups:
direct measurement of indicators of a quality primitive;
processing of programs and documentation of PS with special software tools (processors);
testing of PS programs;
expert assessment based on the study of programs and documentation of the PS.
Direct measurement of quality primitive indicators is performed by counting the number of occurrences of characteristic units, objects, structures, etc., in a particular program document, as well as by measuring the operating time various devices and the amount of computer memory occupied when executing test cases. For example, some measure of memory efficiency might be the number of lines of program in a programming language, and some metric of time efficiency might be query response time. The use of any indicators for quality primitives can be defined in the quality specification of the software system. The method of direct measurement of indicators of a quality primitive can be combined with the use of testing programs.
To establish the presence of some quality primitives in the software, certain software tools can be used. Such software tools process texts of programs or software documentation in order to control any quality primitives or to obtain some indicators of these quality primitives. To assess the structuredness of PS programs, if they were programmed in a suitable structural dialect of the basic programming language, it would be enough to pass them through the structured programs converter, which carries out syntactic and some semantic control of this dialect and translates the texts of these programs into the input language of the basic translator. However, in this way at present it is possible to control only a small number of quality primitives, and even then in rare cases. In some cases, instead of software tools that control the quality of software systems, it is more useful to use tools that transform the presentation of programs or software documentation. Such, for example, is a program formatter that brings program texts to a readable form - processing of PS program texts with such a tool can automatically ensure the availability of an appropriate quality primitive in the PS.
Testing is used to assess some primitives of the quality of the PS. These primitives include, first of all, the completeness of the PS, as well as its accuracy, stability, security and other primitives of quality. In some cases, testing is used in combination with other methods to assess individual primitives of the quality of software systems. So, to assess the quality of documentation for the application of a software system (P-documentation), testing is used in combination with an expert assessment of this documentation. If, during complex debugging of the software system, a sufficiently complete testing was carried out, then the same tests can be used for attestation of the software system. In this case, the certification committee can use the test protocols carried out during complex debugging. However, even in this case, it is necessary to perform some new tests or at least re-run some of the old ones. If testing during complex debugging is deemed not complete enough, then more complete testing should be carried out. In this case, a decision can be made to test the components or system tests of the PS, as well as to return the PS to the developers for revision. It is very important that in order to evaluate the software by the criterion of ease of use, full testing was carried out (during debugging and attestation of the software) using tests prepared on the basis of the application documentation, and by the criterion of maintainability - by tests prepared for each of the documents proposed for maintenance. PS.
For the assessment of most of the primitives of the quality of the software, at present, only the method of expert assessments can be used. This method consists in the following: a group of experts is appointed, each of these experts, as a result of studying the submitted documentation, makes his own opinion on the possession of the PS with the required quality primitive, and then the assessment of the required PS quality primitive is established by voting of the members of this group. This assessment can be made both according to a two-point system ("possesses" - "does not possess"), and also take into account the degree of possession of the PS by this primitive of quality (for example, it can be made according to a five-point system). In this case, the group of experts should be guided by the specification of this primitive and an indication of the method of its assessment, formulated in the quality specification of the certified PS.
Literature for lecture 14.
14.2. V.V. Lipaev. Testing programs. - M .: Radio and communication, 1986 .-- S. 231-245.
14.3. D. Van Tassel. Style, development, efficiency, debugging and testing programs. - M .: Mir, 1985 .-- S. 281-283.
14.4. B. Shneiderman. Psychology of programming. - M .: Radio and communication, 1984 .-- S. 99-127.
Lecture 15 Object approach to software development
15.1. Objects and relations in programming. The essence of the object approach to software development.
The world around us consists of objects and the relationships between them. An object embodies a certain entity and has a certain state that can change over time as a result of the influence of other objects that are with the given in any relation. He may have internal structure: consist of other objects that are also among themselves in some relationship. Based on this, you can build a hierarchical structure of the world from objects. However, for each specific consideration of the world around us, some objects are considered indivisible ("point"), and depending on the goals of consideration, such (indivisible) objects can be taken at different levels of the hierarchy. The relationship connects some objects: we can assume that the union of these objects has some property. If a relation connects n objects, then such a relation is called n-ary (n-ary). At each place of the union of objects that can be connected by any specific relationship, there can be different objects, but quite definite (in this case they say: objects of a certain class). A unary relationship is called a property of an object (of the corresponding class). The state of an object can be studied by the value of the properties of this object or implicitly by the value of the properties of unions of objects associated with this or that relationship.
In the process of cognizing or changing the world around us, we always take into consideration one or another simplified model of the world (the model world), in which we include some of the objects and some of the relationships of the world around us and, as a rule, one level of the hierarchy. Each object with an internal structure can represent its own model world, which includes objects of this structure and the relations that connect them. Thus, the world around us can be considered (in some approximation) as a hierarchical structure of model worlds.
Currently, in the process of cognizing or changing the world around us, computer technology is widely used to process various kinds of information. In this regard, a computer (informational) representation of objects and relationships is used. Each object can be informationally represented by some data structure that reflects its state. The properties of this object can be set directly as separate components of this structure, or by special functions on this data structure. N-ary relations for N> 1 can be represented either in an active form or in a passive form. In the active form, an N-local relation is represented by some program fragment that implements either an N-local function (determining the value of a property of the corresponding union of objects), or a procedure that changes the states of some of them according to the state of the representations of the objects connected by the represented relation. In a passive form, such a relation can be represented by some data structure (which may also include representations of objects connected by this relation), interpreted on the basis of accepted conventions for general procedures that do not depend on specific relations (for example, a relational database). In any case, the relationship view defines some of the data processing activities.
When exploring the model world, a user can receive (or want to receive) information from a computer in different ways. In one approach, he may be interested in obtaining information about individual properties of objects of interest to him or the results of any interaction between some objects. To do this, he orders the development of one or another software system that performs the functions of interest to him, or some information system capable of providing information about the relations of interest to him, using the appropriate database. In the initial period of development of computer technology (with insufficiently high power of computers), such an approach to the use of computers was quite natural. It was he who provoked the functional (relational) approach to the development of software systems, which was discussed in detail in previous lectures. The essence of this approach consists in the systematic use of decomposition of functions (relations) to construct the structure of the PS and the texts of the programs included in it. At the same time, the objects themselves, to which the ordered and implemented functions were applied, were presented fragmentarily (to the extent necessary to perform these functions) and in a form convenient for the implementation of these functions. Thus, an integral and adequate computer representation of the model world of interest to the user was not provided: mapping it to the used SS could be a rather laborious task for the user, attempts to slightly expand the volume and nature of information about the model world of interest to the user. received from such substations, could lead to their serious modernization. This approach to software development is supported by most of the used programming languages, ranging from assembly languages and procedural languages (FORTRAN, Pascal) to functional languages (LISP) and logical programming languages (PROLOGUE).
With another approach to the study of the model world using a computer, the user may be interested in observing the change in the states of objects as a result of their interactions. This requires a fairly integral representation in the computer of the object of interest to the user, and the software components that implement the relations in which this object participates are explicitly associated with it. To implement this approach, it was necessary to build software that simulates the processes of interaction of objects (model world). With traditional development tools, this has proven to be a rather tedious task. True, programming languages have appeared that are specifically focused on such modeling, but this has only partially simplified the task of developing the required software systems. The object approach to the development of software systems most fully meets the solution of this problem. Its essence lies in the systematic use of the decomposition of objects in the construction of the structure of the PS and the texts of the programs included in it. In this case, the functions (relations) performed by such a PS were expressed through the relations of objects of different levels, i.e., their decomposition significantly depended on the decomposition of objects.
Speaking about the object approach, one should also clearly understand what kind of objects we are talking about: objects of the user's model world, their informational representation, program objects with the help of which the software system is built. In addition, one should distinguish between the actual objects (objects "passive") and subjects (objects "active").
15.2. Objects and subjects in programming.
15.3. Object and subjective approaches to software development.
Descartes noted that people usually have an object-oriented view of the world (in).
It is believed that object-oriented design is based on the following principles:
highlighting abstractions,
Access limitation,
modularity,
hierarchy,
typing,
parallelism,
stability.
But all this can be applied with a functional approach.
It is necessary to distinguish between the advantages and disadvantages of the general object approach and its particular case - the subject-oriented approach.
Advantages of a General Objective Approach:
Natural mapping of the real world to the structure of the PS (natural human perception of the capabilities of the PS, there is no need to "invent" the PS structure, but to use natural analogies).
The use of sufficiently meaningful structural units of the PS (an object as the integrity of non-redundant associations, information-strong modules).
Reducing the complexity of developing software systems by using a new level of abstractions (using a hierarchy of "non-programmatic" abstractions when developing software systems: classifying objects in the real world, the method of analogies in nature) as a new level of inheritance.
15.4. An object-based approach to the development of an external description and architecture of a software tool.
Object Oriented Design - A method using object decomposition; the object-oriented approach has its own conventions and offers a rich set of logical and physical models for the design of highly complex systems. ...
Object-oriented analysis (OOA) rendered the object approach. OOA is aimed at creating models that are closer to reality using an object-oriented approach; it is a methodology in which requirements are formed on the basis of the concepts of classes and objects that make up the vocabulary of the domain. ...
Features of object-oriented programming.
Objects, classes, object behavior, properties, events.
Literature for lecture 15.
15.1. K. Fuchi, N. Suzuki. Programming languages and circuitry VLSI. - M .: Mir, 1988.S. 85-98.
15.2. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.? -?
15.3. G. Booch. Object-oriented design with examples of application: per. from English - M .: Concord, 1992.
15.4. V.Sh. Kaufman. Programming languages. Concepts and principles. M .: Radio and communication, 1993.

PROFESSIONAL MODULE
"Development of software
modules of software
software for computer
systems "

MDK

System Programming
Applied programming

Goals and objectives of the module

know:
main stages of software development
provision;
basic principles of structural technology
and object oriented
programming;
basic principles of debugging and testing
software products;
methods and tools for the development of technical
documentation.

Goals and objectives of the module

be able to:
develop software code
modules in modern programming languages;
create a program according to the developed algorithm
as a separate module;
debug and test the program for
module level;
prepare documentation for software
funds;
use tools for
automation of documentation preparation;

Goals and objectives of the module

have practical experience:
development of an algorithm for the task and
implementation by means
computer-aided design;
development of software product code on
based on the finished specification at the level
module;
use of tools on
the stage of debugging a software product;
testing software
module for a specific scenario;

Professional competence

PC 1.1. Carry out the development of specifications for individual
component.
PC 1.2. Carry out the development of software product code
based on ready-made specifications at the module level.
PC 1.3. Debug program modules with
using specialized software.
PC 1.4. Perform testing of software modules.
PC 1.5. Optimize the program code of the module.
PC 1.6. Develop components for design and technical
documentation using graphic languages
specifications.

Interdisciplinary connections

Informatics and ICT;
Information Technology;
Computer systems architecture;
Basics of programming;
OS.

Study stages

Auditory lessons
Practical lessons
Independent work
Course project
Educational practice
Internship
Qualification exam (defense
portfolio)

Applied programming

Section 1. Basic principles of application development

Topic 1.1. Basic concepts
applied programming

Questions

Software classification
Software life cycle
Stages of program development
Documenting programs

What is programming?

Programming - in a broad sense
represents all technical
operations required to create
programs including requirements analysis and
all stages of development and implementation. V
in the narrow sense is coding and
testing the program within
some specific project.

What is software?

Software
is a general term for
"Intangible" (as opposed to physical)
components of a computing system.
In most cases, it refers to
programs running
computing system to
emphasize their difference from hardware
means of the same system.

What classes of software
you know?

systemic: operating systems; drivers
devices; various utilities;
for developers: programming environment;
translators and interpreters; CASE tools;
libraries of programs;
for end users: text
processors; spreadsheets; graphic
editors; solvers of mathematical problems;
training and monitoring systems;
computer games; applied programs.

What is the applied
program?

Application program (application
program) - any program,
contributing to the completion of the task,
assigned to the computer within the given
organization, and contributes directly to
implementation of this task.

What can be called a software system?

The software system presents
is a set of solutions to the set
different but related
tasks (OS, DBMS).
More highly specialized
programs are not called systems
(text editor, compiler, etc.)

Software life-cycle for the entire period of its existence
software systems,
starting from the development of the initial
the concept of this system and ending with it
obsolescence

Make a list of types of documents for
ensuring the software life cycle.

the principle of inclusion, which provides that
requirements for creation, functioning and development
Software is determined from the side of a more complex one,
the system that includes it;
the principle of systemic unity, which is
that at all stages of creation, functioning and
software development, its integrity will be ensured
links between subsystems, and
the functioning of the control subsystem;
development principle that software provides
the possibility of increasing and improving it
components and connections between them;

GENERAL PRINCIPLES OF PROGRAM CREATION

the principle of complexity, which
is that the software provides
the coherence of information processing, as
individual elements and for the entire volume
data in general at all stages of processing;
the principle of information unity, that is
in all subsystems, means of support and
software components use uniform
terms, symbols, legend and
presentation methods;

GENERAL PRINCIPLES OF PROGRAM CREATION

the principle of compatibility is that
language, symbols, codes and software tools
provision are agreed, provide
joint functioning of all
subsystems and keep an open structure
the system as a whole;
the invariance principle defines
invariance of software subsystems and components
to the processed information, that is, they are universal or typical.

Programming technologies are
proven strategies for creating
programs that are presented in the form of techniques
with information funds, descriptions
design procedures and design operations.
There is a technology for structural
programming technology
designing programs with rational
data structure, object-oriented programming technology,
technology visual programming.

TECHNOLOGIES AND PROGRAMMING PARADIGMS

Programming paradigms (concepts,
belief systems) are different
approaches to writing programs.
There are four main paradigms,
which describe most of today's
programming techniques: imperative,
rule-based applicative
and object oriented.

TECHNOLOGIES AND PROGRAMMING PARADIGMS

Imperative paradigm
This model stems from the specifics of the hardware
standard computer following instructions
(commands) sequentially.
The main type of abstraction used in this
paradigm are algorithms. Based on it, developed
many operator-oriented languages
programming.
A program in such a language consists of the sequence
operators, the execution of each of which entails
changing the value in one or more memory cells. V
In general, the syntax of such a language is:
Operator_1:
Operator_2:
...

TECHNOLOGIES AND PROGRAMMING PARADIGMS

Applicative paradigm
This paradigm is based on the consideration
the function that the program performs.
The question is: what function is needed
apply to the initial state of the machine (by
choosing an initial set of variables and
combining them in a certain way) so that
get the desired result?
Languages that emphasize this particular view of
calculations are called applicative, or
functional. The syntax of a language like
the rule looks like this:
Function_n (... function_2 (function_1 (data)) ...)

TECHNOLOGIES AND PROGRAMMING PARADIGMS

A rule-based paradigm
Languages based on this paradigm test
the presence of the necessary permitting condition and in the case of its
detections perform the appropriate action.
Program execution in a similar language is similar to
execution of a program written in an imperative language.
However, the statements are not executed in the same sequence as
which they are defined in the program. Execution order
determine the permitting conditions. The syntax of such languages
as follows:
permissive condition_1 -> action_1 permissive
condition_2 -> action__2
permissive condition_n -> action _n
Sometimes rules are written as “if action
permitting condition "when the performed action
is written on the left.

TECHNOLOGIES AND PROGRAMMING PARADIGMS

Object Oriented Paradigm
Complex data objects are built in this model.
For operations on them, a certain
limited set of methods. Created
objects can inherit properties of simpler ones
objects.
Thanks to this capability, object-oriented programs have a high
efficiency inherent in programs,
written in imperative languages. Possibility
developing various classes that use
limited set of data objects,
provides flexibility and reliability that
are characteristic of the applicative language.

Broadcast (compilation)
It is a method of translating programs written in
high-level languages, to equivalent
the machine language program used
computer.
After that, the interpreter built into
microprocessor hardware,
directly executes the translated to
machine code program. The advantage of this
method - very fast program execution
after the end of the broadcasting process.

BROADCASTING AND INTERPRETATION OF PROGRAMS

A translator is a language processor that
perceives programs on some source
language as input, and at the output
produces equivalent in functionality
programs, but already on another, the so-called
object language (which can also be
arbitrary level).
An assembler is a translator that has the source
language is symbolic representation
machine code (assembler), and object language
is a kind of machine language
any real computer.

BROADCASTING AND INTERPRETATION OF PROGRAMS

Compiler - a translator for which the source
is a high level language, and its object language
is close to the machine language of a real computer. it
either assembly language or some variant
machine language.
A linker (linker) is a translator
whose source language consists of programs in
machine language in movable form and tables
data indicating the points at which
the relocatable code must be modified,
to become executable. An object language consists of
ready to execute machine instructions. The task
linker is to create a single executable
program that uses consistent
addresses as shown in the table.

BROADCASTING AND INTERPRETATION OF PROGRAMS

The preprocessor (macroprocessor) is
a translator whose source language is
is an extended form of any
a high-level language (such as Java or
C ++), and the object language is standard
version of that language. Object program,
generated by the preprocessor, ready for
broadcasting and performing the usual
processors of the original standard
language

BROADCASTING AND INTERPRETATION OF PROGRAMS

Interpretation (software simulation)
This is a method when using a program
(interpreter) executed on
hardware computer created
machine language virtual computer
high level. The interpreter decodes and
executes each statement of the program on
high-level language in the relevant
sequences and produces output
the resulting data defined by this
program.

BROADCASTING AND INTERPRETATION OF PROGRAMS

Mixed implementation systems
First, the program is broadcast from its original
shapes into a shape more convenient to perform.
This is usually done by creating several
independent parts of the program, called
modules.
At the loading stage, these independent parts are combined
with a set of runtime support programs,
implementing software-simulated
(interpreted) operations. This leads to
creating an executable form of the program, operators
which are decoded and executed by their
interpretation.

ENVIRONMENT AND IMPLEMENTATION OF PROGRAMMING LANGUAGES

A programming environment is a collection of
tools used in development
software.
This set usually consists of a file
systems, text editor, editor
links and compiler. Additionally, he
may include a large number
instrumental complexes with
uniform user interface

Exercise

List and characterize the various
programming environment.

MINISTRY OF EDUCATION AND SCIENCE

DONETSK PEOPLE'S REPUBLIC

STATE PROFESSIONAL

EDUCATIONAL INSTITUTION

"DONETSK INDUSTRIAL AND ECONOMIC COLLEGE"

WORKING PROGRAMM

Educational practice UP.01

professional module PM.01 Development of software modules for computer systems

in the specialty 09.02.03 "Programming in computer systems"

Compiled by:

Volkov Volodymyr Aleksandrovich, teacher of computer disciplines of the qualification category "specialist of the highest category", State Public Educational Institution "Donetsk Industrial and Economic College"

The program was approved by: Vovk Pavel Andreevich, director of "Smart IT Service"


1. PASSPORT OF THE PRACTICE PROGRAM
2. RESULTS OF PRACTICE
3. STRUCTURE AND CONTENT OF THE PRACTICE
4. CONDITIONS FOR ORGANIZATION AND PRACTICE
5. CONTROL AND EVALUATION OF PRACTICE RESULTS

1 PASSPORT OF THE EDUCATIONAL PRACTICE PROGRAM UP. 01

1.1 Place of training practice UP.01

Practice program UP.01 of the professional module PM.01 "Development of software modules for computer systems" specialty 09.02.03 "Programming in computer systems » enlarged group 09.00.00 "Informatics and computer technology", in terms of mastering the main type of professional activity (VPA):

Development of software modules for computer systems and related professional competencies (PC):

	Develop specifications for individual components.
	Develop software product code based on ready-made specifications at the module level.
	Debug software modules using specialized software.
	Perform testing of software modules.
	Optimize the program code of the module.
	Develop components of design and technical documentation using graphical specification languages.

The program of educational practice UP.01 of the professional module PM.01 "Development of software modules for computer systems" can be used in additional professional education and vocational training workers for specialties 09.02.03 Programming in computer systems in the presence of secondary (complete) general education. No work experience required.

1.2 Goals and objectivestraining practice UP.01

In order to master the specified type of professional activity and the corresponding professional competencies, the student in the course of educational practice UP.01 must:

have practical experience:

development of an algorithm for the task and its implementation by means of computer-aided design;

development of software product code based on a ready-made specification at the module level;

use of tools at the stage of software product debugging;

testing the software module according to a specific scenario;

be able to:

to develop the code of the software module in modern programming languages;

create a program according to the developed algorithm as a separate module;

debug and test the program at the module level;

draw up documentation for software;

use tools to automate the execution of documentation;

know:

the main stages of software development;

basic principles of structured and object-oriented programming technology;

basic principles of debugging and testing software products;

methods and tools for the development of technical documentation.

1.3 Number of weeks(hours) to master the programtraining practice UP.01

Only 1.5 weeks, 54 hours.

2 RESULTS OF PRACTICE

The result of the training practice UP.01 of the professional module PM.01 "Development of software modules for computer systems" is the development of general competencies (GC):

	Name of the result of practice
	-
OK 2. Organize your own activities, choose standard methods and ways of performing professional tasks, evaluate their effectiveness and quality.
OK 3. Make decisions in standard and non-standard situations and be responsible for them.
OK 4. Search and use the information necessary for the effective performance of professional tasks, professional and personal development.
OK 5. Use information and communication technologies in professional activities.
OK 6. Work in a team and in a team, communicate effectively with colleagues, management, consumers.
OK 7. Take responsibility for the work of team members (subordinates), for the result of tasks.	-
	qualifications
OK 9. To navigate in the conditions of frequent changes in technologies in professional activities.

professional competencies (PC):

Professional activity		Name of the results of practice
Mastering the main type of professional activity		use of resources of local and global computer networks; management of data files on local, removable storage devices, as well as on disks of a local computer network and on the Internet; printing, duplication and copying of documents on a printer and other office equipment. monitoring in the form of a report for each practical work. qualification exam mod.
		literacy and accuracy of work in applied programs: text and graphic editors, databases, presentation editor; the speed of searching for information in the content of databases.
		accuracy and literacy of setting up e-mail, server and client software: the speed of information retrieval using Internet technologies and services; accuracy and literacy of entering and transmitting information using Internet technologies and services.
		literacy in the use of methods and means of protecting information from unauthorized access; correctness and accuracy Reserve copy and data recovery;
		literacy and accuracy of work with file systems, different formats files, file management programs;
		maintaining accounting and technical documentation.

3 STRUCTURE AND CONTENT OF THE PROGRAMEDUCATIONAL PRACTICE UP.01

3.1 Thematic plan

Competency codes

Professional module name

Amount of time, set aside for practice

(in weeks, hours)

Dates of the

PC 1.1 - PC 1.6

PM.01 "Development of software modules for computer systems"

1.5 weeks,

54 hours

3.2 Practice content

Activities	Types of jobs		Name of academic disciplines, interdisciplinary courses indicating topics, ensuring the performance of types of work	Number of hours (weeks)
"Mastering the main type of professional activity »	Topic 1. Introduction. Algorithms for solving problems. The structure of the linear algorithm. The structure of the cyclic algorithm. Algorithm of a subroutine (function).	Formed knowledge on the basics of creating special objects
	Theme2 . Wednesday Skratch (Scratch).	Formed knowledge on the basics of process automation tools Formed knowledge on the basics of animation effects to objects; use of hyperlinks and buttons; demo setup; presentation saved in different formats.	MDK.01.01 "System programming"
	Theme 3 ... Creation of a training program (lesson from the subject).	Formed knowledge on the basics of data analysis using processor functions	MDK.01.02 "Applied programming"
	Topic 4. Development of a game program.	Formed knowledge on the basics of calculating the final characteristics	MDK.01.01 "System programming"
	Topic 5. LabVIEW graphical programming language.	Formed knowledge of the basics of creating a processor test.	MDK.01.02 "Applied programming"
	Theme 6. Creating an application using LabVIEW.	Formed knowledge of the basics of user dialogue with the system	MDK.01.02 "Applied programming"
	Theme 7 Reusing a program fragment.	Knowledge of the operators and functions of the system has been formed.	MDK.01.02 "Applied programming"
	Theme 8 LabVIEW Workshop. Labor protection when working with a computer at the user's workplace.	Formed knowledge on the computation of elementary functions. Formed knowledge on labor protection.	MDK.01.02 "Applied Programming". OP 18 "Labor Protection"
	Theme 9 Conclusions. Drawing up a report on practice.	Analysis skills formed computer technology, problem solving Skills are formed.	MDK.01.01 "System programming" MDK.01.02 "Applied programming" MDK.04.01 "Office software"

4 CONDITIONS OF ORGANIZATION AND CONDUCT

EDUCATIONAL PRACTICE UP. 01

4.1 Documentation requirements, necessary for practice:

The work program of the training practice UP.01 of the professional module PM.01. "Development of software modules for computer systems" is part of the training program for mid-level specialists by the State professional educational institution "Donetsk Industrial and Economic College" in accordance with the state educational standard of secondary vocational education in the specialty 09.02.03 "Programming in computer systems", based on the curriculum for the specialty, the work program for the disciplines MDK.01.01 "System programming", MDK01.02 "Applied programming", guidelines for teaching and methodological support of the practice of students mastering educational programs of secondary vocational education.

4.2 Requirements for educational and methodological support of practice:

list of approved assignments by type of work, guidelines for students on the implementation of work, recommendations for the implementation of reports on practice.

4.3 Logistics requirements:

the organization of industrial practice requires the presence of classrooms and a laboratory.

Office equipment and workplaces:

seats according to the number of students (table, computer, chair);

teacher's workplace (table, computer, chair);

cabinet for storing teaching aids and information carriers;

tasks for an individual approach to training, organization independent work and exercises, student on the computer;

reference and methodological literature;

a set of system, application and training programs for PCs on optical and electronic media;

journal of instructing students on labor protection;

a set of teaching aids.

Technical training aids:

classroom board;

personal computer with licensed software;

laser printer;

educational PCs;
set of interactive equipment (projector, screen, speakers);
fire extinguishing means (fire extinguisher).

Office equipment and workstations of development tools: personal computers(monitor, system unit, keyboard, mouse), a set of educational and methodological documentation, software in accordance with the content of the discipline (shells of programming languages).

All computers in the classroom are united into a local network, have access to the network storage of information and have access to the Internet.

Communication equipment:

network adapters;

network cables;

WiFi wireless equipment.

Components for the installation of networks, equipment for installation.

4.4 List of educational publications, Internet resources, additional literature

Main sources:

Olifer V.G. Network operating systems: textbook for universities / V.G.Olifer, N.A.Olifer. - 2nd ed. - St. Petersburg: Peter, 2009,2008. - 668 p .:

E. Tanenbaum. OS. Development and implementation. SPb .: Peter, 2006 .-- 568 p.

Pupkov K.A. Mastering operating system Unix / K.A. Pupkov, A.S. Chernikov, N.M. Yakusheva. - Moscow: Radio and communication, 1994 .-- 112 p.

L. Beck Introduction to system programming - M .: Mir, 1988.

Grekul V.I., Denischenko G.N., Korovkina N.L. Design information systems/ Moscow: Binom, 2008 .-- 304 p.

Lipaev, V.V. Software engineering. Methodological foundations [Text]: Textbook. / V. V. Lipaev; State un-t - Higher School of Economics. - M .: TEIS, 2006 .-- 608 p.

Lavrischeva E. M., Petrukhin V. A. Methods and means of software engineering. - Textbook

Ian Somerville. Software Engineering, 6th edition .: Per. from English ―M. : Publishing house "Williams", 2002. ― 624 p.

Excel 2010: professional programming in VBA .: Per. from English - M .: LLC “I.D. Williams ”, 2012. - 944 p. : ill. - Parallel. tit. Eng

Fowler M. Refactoring: improving existing code. ― Per. From English ― SPb: Symbol-plus, 2003. ― 432 p.

Additional sources:

Volkov V.A. METHODOLOGICAL INSTRUCTIONS for the implementation of practical work in the discipline "System programming", Donetsk: DONPEK, 2015.

Volkov V.A. Methodical instructions for the implementation of the course project, Donetsk: DONPEK, 2015.

Internet- resources:

System programming [electronic resource] / Access mode: http://www.umk3.utmn.ru.

Software and Internet resources: http://www.intuit.ru

Discipline Literature - http://www.internet-technologies.ru/books/

Electronic textbook "Introduction to Software Engineering" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info

Electronic textbook "Programming technology" -http: //bourabai.kz/alg/pro.htm

4.5 Requirements for practice leaders from an educational institution and organization

Requirements for practice leaders from an educational institution:

engineering and teaching staff: graduates - teachers of interdisciplinary courses and general professional disciplines. Work experience in organizations of the relevant professional field is required.

Master of industrial training: the presence of 5-6 qualification categories with a mandatory internship in specialized organizations at least once every 3 years. Work experience in organizations of the relevant professional field is required.

5 CONTROL AND EVALUATION OF RESULTS

EDUCATIONAL PRACTICE UP. 01

Form of reporting on educational practice UP.01 - a report on practice, drawn up in accordance with the requirements of methodological recommendations.

results (mastered professional competencies)	Main factors result of preparation	Forms and methods control
PC 1.1. Carry out the development of specifications for individual components	Development of an algorithm for the task and its implementation by means of computer-aided design	Expert observation and assessment of the student's activity in the process of mastering educational program in practical classes, when performing work on educational and industrial practice.
PC 1.2. Develop software product code based on ready-made specifications at the module level.	Know the basic principles of structured and object-oriented programming technology. To develop the code of the software module in modern programming languages.
PC 1.3. Debug software modules using specialized software	Debug and test the program at the module level.
PC 1.4. Perform testing of software modules.	Create a program according to the developed algorithm as a separate module.
PC 1.5. Optimize the program code of the module	Development of software product code based on a ready-made specification at the module level.
PC 1.6. Develop components of design and technical documentation using graphical specification languages	Know the methods and tools for developing technical documentation. Draw up documentation for software tools. Use tools to automate paperwork.

The forms and methods of monitoring and evaluating learning outcomes should allow checking in students not only the formation of professional competencies, but also the development of general competencies and the skills that provide them.

results (mastered general competences)	Main indicators for assessing the result	Forms and methods of control and evaluation
OK 1. Understand the essence and social significance of your future profession, show a steady interest in it.	Demonstration of constant interest in the future profession; - the validity of the application of mastered professional competencies;	Expert observation and assessment in practical training when performing work on industrial practice;
OK 2. Organize your own activities, determine the methods and ways of performing professional tasks, evaluate their effectiveness and quality.	Substantiation of goal setting, selection and application of methods and methods for solving professional problems; Introspection and correction of the results of one's own work	Assessment in practical training during the performance of work; Observation during practice; Introspection
OK 3. Solve problems, assess risks and make decisions in non-standard situations.	The effectiveness of making decisions on standard and non-standard professional tasks for certain time; The effectiveness of the plan to optimize the quality of work performed	Interpretation of the results of observation of the student's activities in the process of completing tasks
OK 4. Search, analyze and evaluate the information necessary for setting and solving professional problems, professional and personal development.	Selection and analysis of the necessary information for a clear and quick implementation of professional tasks, professional and personal development	Expert assessment in the course of work; Self-control in the course of posing and solving problems
OK 5. Use information and communication technologies to improve professional activity.	the ability to use information and communication technologies to solve professional problems	assessment of assignments
OK 6. Work in a team and a team, ensure its cohesion, communicate effectively with colleagues, management, consumers.	Ability to interact with a group, teachers, industrial training master
OK 7. Set goals, motivate the activities of subordinates, organize and control their work with the assumption of responsibility for the result of assignments.	- introspection and correction of the results of one's own work and the work of the team	Observing the progress of work in a group in the process of practical training
OK 8. To independently determine the tasks of professional and personal development, engage in self-education, consciously plan professional development.	Organization of independent work to form a creative and professional image; Organization of work on self-education and improvement qualifications	Observation and evaluation in the process of industrial practice; Reflexive analysis (algorithm of student actions); Practice diary; Student portfolio analysis
OK 9. Be ready to change technologies in professional activity.	Analysis of innovations in the field of technological processes for the development and manufacture of garments	Assessment of solutions to situational tasks; Business and organizational learning games; Observation and assessment in practical training, in the process of industrial practice

The transition from informal to formal is essentially informal.

Lecture 8.

DEVELOPMENT OF THE SOFTWARE MODULE

The procedure for developing a software module. Structured programming and step by step detailing. Understanding pseudocode. Control of the program module.

8.1. The procedure for developing a software module.

When developing a software module, it is advisable to adhere to the following order:

· Study and verification of the module specification, choice of programming language;

· Choice of algorithm and data structure;

· Programming (coding) of the module;

· Polishing the text of the module;

· Checking the module;

· Compilation of the module.

The first step in the development of a software module is largely a contiguous control of the program structure from below: by studying the module specification, the developer must make sure that it is clear to him and is sufficient for the development of this module. At the end of this step, a programming language is selected: although the programming language may already be predefined for the entire software system, in some cases (if the programming system allows it) another language may be chosen that is more suitable for the implementation of this module (for example, assembly language).

At the second step in the development of a software module, it is necessary to find out whether any algorithms are already known for solving the problem posed and or close to it. And if a suitable algorithm is found, then it is advisable to use it. The choice of suitable data structures that will be used when a module performs its functions largely predetermines the logic and quality indicators of the module being developed, so it should be considered as a very responsible decision.

At the third step, the text of the module is constructed in the selected programming language. The abundance of all kinds of details that must be taken into account when implementing the functions specified in the module's specification can easily lead to the creation of a very confusing text containing a lot of errors and inaccuracies. Finding errors in such a module and making the required changes to it can be a very time-consuming task. Therefore, it is very important to use a technologically sound and practically proven programming discipline to construct the text of the module. For the first time, Dijkstra drew attention to this, formulating and substantiating the basic principles of structured programming. Many programming disciplines that are widely used in practice are based on these principles. The most common discipline is incremental refinement, which is discussed in detail in sections 8.2 and 8.3.

The next step in the development of the module is associated with bringing the text of the module to a complete form in accordance with the specification of the quality of the software. When programming a module, the developer focuses on the correct implementation of the module's functions, leaving incomplete comments and allowing some violations of the requirements for the style of the program. When polishing the text of the module, he should edit the existing comments in the text and, possibly, include additional comments in it in order to provide the required primitives of quality. For the same purpose, the text of the program is edited to meet stylistic requirements.

The module verification step is a manual verification of the internal logic of the module before debugging it (using its execution on a computer), implements the general principle formulated for the discussed programming technology, about the need to control the decisions made at each stage of software development (see Lecture 3). Module validation methods are discussed in Section 8.4.

And finally, the last step in the development of a module means completing the verification of the module (with the help of the compiler) and proceeding to the process of debugging the module.

8.2. Structured programming.

When programming a module, it should be borne in mind that the program must be understandable not only for a computer, but also for a person: both the developer of the module, the persons who check the module, and the testers who prepare tests for debugging the module, and the PS maintainers who make the required changes to the module are forced to will repeatedly analyze the logic of the module. In modern programming languages, there are enough tools to confuse this logic as much as you like, thereby making the module difficult for humans to understand and, as a consequence, make it unreliable or difficult to maintain. Therefore, it is necessary to take steps to select the appropriate language tools and follow a specific programming discipline. In this regard, Dijkstra proposed to build a program as a composition of several types of control structures (structures), which can greatly increase the understanding of the logic of the program. Programming using only such constructs was called structural.

Rice. 8.1. Basic control constructs of structured programming.

The basic constructs of structured programming are: follow, branch, and repetition (see Figure 8.1). The components of these constructions are generalized operators (processing nodes) S, S1, S2 and a condition (predicate) P. A generalized operator can be either a simple operator of the programming language used (assignment, input, output, procedure call operators), or a program fragment , which is a composition of basic structured programming control constructs. It is essential that each of these structures has only one input and one output for control. Thus, the generalized operator has only one input and one output.

It is also very important that these constructs are already mathematical objects (which, in essence, explains the reason for the success of structured programming). It is proved that for each unstructured program it is possible to construct a functionally equivalent (that is, solving the same problem) structured program. For structured programs, you can prove some properties mathematically, which allows you to detect some errors in the program. A separate lecture will be devoted to this issue.

Structured programming is sometimes referred to as "no-GO TO programming". However, the point here is not in the GO TO statement, but in its erratic use. Very often, when implementing structured programming in some programming languages (for example, in FORTRAN), the transition operator (GO TO) is used to implement structured constructs, which does not violate the principles of structured programming. It is the "non-structural" jump operators that confuse the program, especially the jump to the operator located in the module text above (earlier) the jump operator being executed. Nevertheless, an attempt to avoid the branch operator in some simple cases can lead to too cumbersome structured programs, which does not improve their clarity and contains the danger of additional errors in the text of the module. Therefore, we can recommend avoiding the use of the jump operator whenever possible, but not at the expense of clarity of the program.

Useful cases of using the jump operator include exiting a loop or procedure by a special condition that "ahead of schedule" terminates the work of a given cycle or a given procedure, that is, terminates the work of some structural unit (generalized operator) and thereby only locally violates the structure of the program. Great difficulties (and the complication of the structure) are caused by the structural implementation of the reaction to emerging exceptional (often erroneous) situations, since this requires not only an early exit from the structural unit, but also the necessary processing (exclusion) of this situation (for example, the issuance of a suitable diagnostic information). The exception handler can be at any level of the program structure, and it can be accessed from different lower levels. The following "non-structural" implementation of the reaction to exceptional situations is quite acceptable from the technological point of view. Exception handlers are placed at the end of one or another structural unit, and each such handler is programmed in such a way that, after finishing its work, it exits the structural unit at the end of which it is placed. The call to such a handler is made by the transition operator from the given structural unit (including any structural unit nested in it).

8.3. Step-by-step detailing and the concept of pseudocode.

Structured programming provides guidelines for how the module text should be. The question arises how a programmer should act to construct such a text. Often, the programming of a module begins with the construction of its block diagram, describing in general terms the logic of its operation. However, modern programming technology does not recommend doing this without suitable computer support. Although block diagrams make it possible to very clearly represent the logic of the module's operation, when they are manually coded in a programming language, a very specific source of errors arises: the mapping of essentially two-dimensional structures, such as block diagrams, to linear text representing the module contains the danger of distorting the logic of the module's operation. all the more so psychologically it is quite difficult to maintain a high level of attention when re-examining it. An exception may be the case when a graphical editor is used to build block diagrams and they are formalized so that text in a programming language is automatically generated from them (as, for example, it is done in R-technology).

As the main method of constructing the text of the module, modern programming technology recommends step by step detailing... The essence of this method is to break down the process of developing a module text into a number of steps. On the first

step describes the general scheme of the module in an observable linear text form (i.e., using very large concepts), and this description is not fully formalized and is focused on human perception. At each next step, one of the concepts is refined and detailed (we will call it clarified), in any description developed in one of the previous steps. As a result of this step, a description of the selected refined concept is created either in terms of the basic programming language (i.e., the module chosen for presentation), or in the same form as in the first step using new refined concepts. This process ends when all the refined concepts are clarification(i.e., will ultimately be expressed in the underlying programming language). The last step is to obtain the text of the module in the basic programming language by replacing all occurrences of the refined concepts with their given descriptions and expressing all occurrences of structured programming constructs by means of this programming language.

Step-by-step detailing is associated with the use of a partially formalized language to represent the specified descriptions, which is called pseudocode... This language allows you to use all structured programming constructs that are formalized, together with informal fragments in natural language to represent generic operators and conditions. The corresponding fragments in the basic programming language can also be specified as generalized operators and conditions.

· The beginning of a module in the base language, that is, the first sentence or heading (specification) of this module;

· Section (set) of descriptions in the base language, and instead of descriptions of procedures and functions - only their external design;

· Informal designation of the sequence of operators of the module body as one generalized operator (see below), as well as informal designation of the body of each description of a procedure or function as one generalized operator;

· The last sentence (end) of the module in the base language.

The appearance of a description of a procedure or function is similar. However, if you follow Dijkstra, it is better to present the descriptions section here with an informal designation, making its detailing in the form of a separate description.

Informal designation of a generalized operator in pseudocode is made in natural language by an arbitrary sentence that outlines its content. The only formal requirement for the design of such a designation is the following: this proposal must occupy one or more graphic (printed) lines in its entirety and end with a dot (or some other sign specially allocated for this).

Rice. 8.2. Basic constructions of structured programming in pseudocode.

For each informal generalized operator, a separate description must be created that expresses the logic of its operation (detailing its content) using the composition of the basic structures of structured programming and other generalized operators. The title of such a description should be the informal designation of the detailed generic operator. The basic constructs of structured programming can be represented in as follows(see fig. 8.2). Here, the condition can either be explicitly specified in the base programming language as a boolean expression, or it can be informally represented in natural language by some fragment that outlines the meaning of this condition. In the latter case, a separate description should be created detailing this condition, indicating the designation of this condition (a fragment in natural language) as the title.

Exit from repetition (loop):

Exiting the procedure (function):

Categories

Popular

Module program development of software modules. The work program of the training practice for the professional module "development of software modules for computer systems". Ensuring software completeness

Lecture 8. Development of a software module

8.1. The procedure for developing a software module.

8.2. Structured programming.

8.3. Step-by-step detailing and the concept of pseudocode.

8.4. Control of the program module.

Literature for lecture 8.

Lecture 9. Proof of program properties

9.1. Justification of programs. Formalization of program properties.

9.2. Properties of simple operators.

9.3. Properties of the basic structures of structured programming.

9.4. Completeness of program execution.

9.5. An example of proving a property of a program.

Literature for lecture 9.

Lecture 10. Testing and debugging software

10.1. Basic concepts.

10.2. Debugging principles and types.

10.3. Debugging Commandments.

10.4. Debugging a module offline.

10.5. Complex software debugging.

Literature for lecture 10.

Lecture 11. Ensuring the functionality and reliability of the software tool

11.1. Functionality and reliability as mandatory criteria for the quality of a software tool.

11.2. Ensuring the completeness of the software.

11.3. Ensuring the accuracy of the software.

11.4. Ensuring the autonomy of the software.

11.5. Ensuring the stability of the software.

11.6. Ensuring the security of software.

Literature for lecture 11.

Lecture 12. Software quality assurance

12.1. General characteristics of the quality assurance process for software tools.

12.3. Ensuring the effectiveness of the software.

Literature for lecture 12.

Lecture 13. Documenting software

13.1. Documentation created during software development.

13.2. User documentation of software tools.

Literature for lecture 13.

Lecture 14. Certification of software tools

14.1. Purpose of software certification.

14.2. Types of software tests.

14.3. Methods for assessing the quality of software.

Lecture 15 Object approach to software development

15.1. Objects and relations in programming. The essence of the object approach to software development.

15.2. Objects and subjects in programming.

15.3. Object and subjective approaches to software development.

15.4. An object-based approach to the development of an external description and architecture of a software tool.

Literature for lecture 15.

MDK

Goals and objectives of the module

Goals and objectives of the module

Goals and objectives of the module

Professional competence

Interdisciplinary connections

Study stages

Applied programming

Section 1. Basic principles of application development

Questions

LIFE CYCLE OF SOFTWARE

STAGES OF PROGRAM CREATION

STAGES OF PROGRAM CREATION

STAGES OF PROGRAM CREATION

STAGES OF PROGRAM CREATION

STAGES OF PROGRAM CREATION

STAGES OF PROGRAM CREATION

Questions

DOCUMENTATION OF PROGRAMS

DOCUMENTATION OF PROGRAMS

DOCUMENTATION OF PROGRAMS

DOCUMENTATION OF PROGRAMS

DOCUMENTATION OF PROGRAMS

DOCUMENTATION OF PROGRAMS

DOCUMENTATION OF PROGRAMS

Homework

GENERAL PRINCIPLES OF PROGRAM CREATION

GENERAL PRINCIPLES OF PROGRAM CREATION

TECHNOLOGIES AND PROGRAMMING PARADIGMS

TECHNOLOGIES AND PROGRAMMING PARADIGMS

TECHNOLOGIES AND PROGRAMMING PARADIGMS

TECHNOLOGIES AND PROGRAMMING PARADIGMS

TECHNOLOGIES AND PROGRAMMING PARADIGMS