Formalization of the software module development using matrix forms

Abstract

  The article considers the formalized approach to develop a multi-user document exchange system based on a matrix form of data representation. The multi-stage development of modular software by several participants is presented as basic process. The algorithmic implementation of information flows in the context of software development is presented. The document life cycle model is described using the UML diagrams. The considered algorithm contains a hierarchical document flow structure with the subordination of some documents to others. According document flow the participant interaction model of software development process is considered. The model of administrative document flow includes the following roles (owners): the product development manager; the customer representative; the developer; the tester. As a result, the presented matrices fully describe the graph of the considered document flow process. The formalized approach based on the matrix form of representation can be used as input data for multi-user systems' algorithmization in solving modular software design problems.

Keywords

• 1  Matrix form
• document
• module

1. Introduction 

Nowadays, many software design methods (software) are developed and unified approaches for different categories are established [ 1 ]. One of the features of modular design is the possibility of using formalized approaches. Let us consider a similar approach the matrix form of representation of multiuser systems [ 2 ], such as document exchange. The representation of information flows passing through the document management system (DMS) is formalized in the form of a visual graph model [ 3 ].

2. The matrix form of data presentation 

As a basic, consider the process of software module developing with the following tasks: module developing, its testing and accepting as an element of common software package [ 4 ]. Moreover, checking the accepted task adequacy and verification is carried out as well as the developed software module is archived at the final stage of development.

Supposed the forms F1...F8 are documents used in simulated process: F1 – development assignment form; F2 - form of the task approval document; F3 - assignment to the developer; F4 - development report; F5 - test report; F6 - notice of test results; F7 - notice of development results (claim letter); F8 acceptance certificate.

Supposed the actions A1...A4 are procedures performed on the documents for changing states in the simulated process: A1.1...1.7 – document creation; A2 - document approval; A3.1…3.2 – document sending; A4 –archiving.

Supposed the performers P1…P4 are performers of action in simulated process: P1 – product development manager; P2 - customer representative; P3 – developer; P4 - software tester (Figure 1:).

In the framework of specified paths there are three document flow scenarios. According to three document flow scenarios let us build a document flow matrixes. Performers in different scenarios are highlighted differently. At the first step the product development manager issues a development task and the customer's representative approves it.   Table 1   The document flow matrix. Step 1 

The product development manager issues a development order to the developer. Further, the developer issues a report based on his work results.

The developer sends a development report to the tester. Depending on the development results tester he issues the test report with possible notices and forward it.       F5 

F6 

F7  F5 

F6 

F7         

According to the first scenario, the report is approved by the product development manager. In the second scenario, the developer issues a new development report with adjustments (and the previous step is repeated). The second scenario is bold italic highlighted in the matrix.

3. Document lifecycle model in document management system 

Based on the obtained scenarios, let us consider an algorithmic implementation of the information flows in the context of software development. The algorithmic implementation is presented in the form of UML diagrams (Figure 2:).

According to this model, software development includes the following:

F6  P4    P4    F6 

If the customer's requirements are satisfied, the customer accepts the development results and the product development manager archives its. If there are any notices (the third scenario begins) the customer forms claim letter and sends it to the product development manager.

In the case of the first scenario, the project is archived. In the case of the third scenario, the product development manager produces an updated development task and sends it to the developer (then the third step is repeated). The third scenario is underscore highlighted.

Setting the task for software development. A task for software development is formed.

 The development mark is entered into the project documentation registration log. The service note for the specific module development is drawn up.

 After drawing up the development assignment it is agreed with the customer.  The development task is sent for correction in case the customer has any corrections.  After (possible) adjustment, the task is passed to the developer to create a software module.  The developer creates the module algorithms and issues the development report based on work results.

 The source modules text is added to the set of documents.

 The developed software module is sent for testing and corresponding record is made in the documentation/

 If the test is successful, the module is sent to the customer verification. If not, it is submitted to the developer for correction.

 The final development report is generated in a form suitable for the archiving in case the customer has no comments. If there are any comments the task is sent for re-approval with the product development manager.

The considered algorithm contains a hierarchical document flow structure with the subordination of some documents to others [ 5 ]. Documents based on orders, administrative notes or instructions retain their link. Also, this algorithm assumes the new document release notification as well as the ability to track the development process (journal) for persons involved in the development process. In general, the layout is consistent with the ideas of building a document management system.

According document flow the participant interaction model of software development process is considered (Figure 3:).

The model of administrative document flow includes the following roles (owners): the product development manager; customer representative; developer; tester.

The product development manager is responsible for the formation of main development assignment agreed with customer representative. Firstly, the product development manager carries out approval at the customer representative taking into account software comments and requirements. Responsible performers are assigned for certain tasks. After agreement with the customer representative, the product development manager gives the development assignment to programmer.

During the development the process is controlled by organizing a time control system. Programmers return results of each software module in the form of development reports. After the modules are developed they are sent for testing.

Testing determines the module suitability for operation and the high-quality performance of all the required functions. Programmers responsible for development submit development reports for testing. The tester combines modules into single software package and tests software. If the test is successful and no customer comments the project modules are archived and the final project is put into operation by the customer.

This diagram describes the normal development scenario without comments. Scenarios with notice are described by a similar model. If the module does not pass the test, it is sent for revision [ 6 ].

The project is submitted for approving with the customer in case of successful test. If there are comments the product development manager issues a new development assignment. The final project’s modules are archived and the final project is put into operation by the customer in case of comments absences.

Thus, the presented matrices fully describe the graph of the considered document flow process. The formalized approach based on the matrix form of representation can be used as input data for multi-user systems' algorithmization in solving modular software design problems.

4. References 

References

[1] A. M. Langer , Guide to Software Development, Designing and Managing the Life Cycle ( 2012 ) 354. Springer London.

[2] B. Molnár , A. Benczúr , "Modeling Information Systems from the Viewpoint of Active Documents" , Vietnam Journal of Computer Science 2 ( 4 ) ( 2015 ) 229 - 241 .

[3] M. Yu . Krukovskiy, Graph model of composite workflow , Mathematical Machines and Systems 1 ( 120 ) ( 2005 ) 136 .

[4] M. V. Poskonin , A. O. Kalinin , I. V. Kovalev , M. V. Saramud , Optimization of electronic document management systems by means of encoding and visualization of stored data in the integrated development environment , MATEC Web of Conferences 226 04021 ( 2018 ). DOI: 0 .1051/matecconf/201822604021.

[5] I. Paramonova , "Electronic Document-Management Systems: A Classification and New Opportunities for A Scientific Technical Library" , Scientific and Technical Information Processing 43 ( 3 ) ( 2016 ) 136 - 143 .

[6] I. V. Kovalev et al., J. Phys.: Conf. Ser. 1679 052037 ( 2020 ).