Prototype this Or useful functionality faster than a cup of coffee
Today I want to talk about the possibilities of rapid prototyping, implemented in the Ultima Businessware platform . I will show how to quickly outline the implementation of the trivial process (there will be slides!), Tell you how you can reduce development time and improve the scalability of the development process. Well, at the same time I will walk a little bit on every small “plush” of the system about which I mentioned in previous articles. For details - please under the cat.
In general, the term originated as the name of a method or function of the development environment, which allowed for a relatively short time to get a graphical interface with ready-made buttons.
In my practice, it only allowed us to test usability and correct the situation before a lot of code is written.
In our practice (enterprise automation), situations often arise when it is necessary to “automate” small areas. What is called "bags in the corner." You just need to implement in the system the possibility of accounting for something and somewhere. Accounting implies that there are operations of the arrival and expenditure of this something somewhere.
')
Actually, for simple situations, a prototyped solution has sufficient functionality, and for more complex ones, it allows to distribute the processes of developing the interface and business logic. Moreover, even in complex business processes, the user can begin data entry at the earliest stages of development.
To understand how prototyping works, you first need to understand the concept of describing data structures of the domain.
Without going into details (for more details, see extracts from the documentation ) all structures fall into the following classes:
In turn, the structure of the domain is described as a set of types of reference books, types of documents, types of link tables and totals that interact through scripts — special classes in C #.
The type of the directory or document defines the internal structure of the corresponding object. Each type of directory or document is assigned a C # class for storing one unit of data.
Now we can formulate what rapid prototyping is in our platform:
For reference books and documents forms of the list of records and record editing are available. For totals - a form for building a report. Link tables are available through the editing forms of the corresponding directory entries.
Even if you are already confused - not scary. Let's move on to practice and everything will become clear!
Let's implement the canonical example of “bagging in the corner”.
The customer (warehouse manager) wants to keep records of packaging bags in warehouses. It is known that the bags are stored separately from the rest of the products, and the function of processing them is left at the warehouse simply in the “load”. Bags come in several sizes. It is necessary at every moment to know where (in which warehouse) how many and what bags lies. Who when issued or accepted bags.
From the formulation of the task it is clear that we will need a directory of sacks with dimensions, a directory of warehouses, a result of “bag residues”, and a document handling bags with a tabular part of “bags” that will describe two operations — arrival and expense. We assume that there are few different bags (say up to 10), so it’s enough to make a flat list.
Go. Create a new type of reference (so as not to litter the pictures, I made an animated gif):
I will not create a directory of warehouses, but I will use the fact that there is a basic solution:
Now we will create a summary of “bag remains” (a small digression - the main language in the system is English, I omit the Russian translations as irrelevant for this task)
All read-only fields are generated by the platform automatically.
So, so far I have only entered Bags / Bags, Capacity / Capacity, BagsStock / Remains of Bags, BagID / Bag, Store / Warehouse from the keyboard. Everything else is generated by the system.
We need to store information about the income and expenses of the bags. Moreover, in each parish there may be bags of several sizes. Create a tabular part of the bags:
The simplest tabular part. It has only two fields - a link to the bag and the number.
Now we will describe the document with this tabular part (the tabular part of one type can be used in several documents or several times in one)
In the created document in the header only the warehouse from (or to) which will be issued or received goods. The document has two states (in our terminology - subtypes) that determine how this document affects the result.
Voila: after three minutes of clicking the mouse, we can already create new bags and documents for receiving and consuming these bags!
Here, see for yourself:
You can distribute rights to users, they can customize their columns. The form has all the settings, groups and filters for any columns. Similarly with the documents:
Distribution of rights occurs on individual subtypes, as all settings work.
By the way. You can filter or select columns not only from the properties of the corresponding object, but also from those associated with it.
In the document example, the “Author” column contains the user name, which is listed in the user directory. Similarly, you can display the name of the office where the warehouse is located, and so on.
However, until we have created a result. Here you have to take the keyboard in hand and show how the programmer differs from the admin.
You need to write this program:
And likewise for consumption with the opposite sign:
Go through the lines and for each of them generate posting on the total remnants of the bags.
Now, after the receipt and expenditure of the bags, we can use the ready-made form for building the report and twist the data in it as you please:
It took me 5 minutes 32 seconds to do all the operations.
As a result, we have: an absolutely usable interface.
Unfortunately, I can not put all the documentation in one article, so I omitted details like the localization of properties, did not show the forms for rights management, and so on. The main thing is that now you can enter data. If you need more complex logic - it is easily refined, and most importantly, you can now simultaneously work on the development of screen forms, web services, integration tests and other business logic. And each of the developers will have the tools to test their work.
By the way - at this moment only 10 lines of code have been written, in which it is rather difficult to make a mistake - that's all. No more programming, no need to do anything, and, as a result of Murphy's laws, there are no mistakes!
And this is one more reason, based on which, we argue that the cost of supporting Ultima solutions is lower than that of competitors. Even if you include in the analysis the hourly cost of a specialist.
Rapid prototyping
In general, the term originated as the name of a method or function of the development environment, which allowed for a relatively short time to get a graphical interface with ready-made buttons.
In my practice, it only allowed us to test usability and correct the situation before a lot of code is written.
In our practice (enterprise automation), situations often arise when it is necessary to “automate” small areas. What is called "bags in the corner." You just need to implement in the system the possibility of accounting for something and somewhere. Accounting implies that there are operations of the arrival and expenditure of this something somewhere.
')
Actually, for simple situations, a prototyped solution has sufficient functionality, and for more complex ones, it allows to distribute the processes of developing the interface and business logic. Moreover, even in complex business processes, the user can begin data entry at the earliest stages of development.
To understand how prototyping works, you first need to understand the concept of describing data structures of the domain.
Without going into details (for more details, see extracts from the documentation ) all structures fall into the following classes:
- Directories
Contain “static” information. For example, goods, offices, warehouses. - Intermediate tables
Contain information about many-to-many links between different directories. - Documents and spreadsheets
Documents correspond to events in the subject area. For example sale, or purchase. Each document consists of a “header” - a set of fields and tabular parts. The tabular part contains an enumeration of various attributes. For example, how much, how much and what goods we sold. - Results
This object is the most difficult to understand, so I always explain it through analogies. Familiar with OLAP is a cube. There are measurements, variables. One dimension is temporary. For developers familiar with 1C, this is a register (albeit with a much more complex structure), and the last analogy is an account. If it is still not clear, try reading the documentation . Or just see what happens next.
In turn, the structure of the domain is described as a set of types of reference books, types of documents, types of link tables and totals that interact through scripts — special classes in C #.
The type of the directory or document defines the internal structure of the corresponding object. Each type of directory or document is assigned a C # class for storing one unit of data.
Now we can formulate what rapid prototyping is in our platform:
Rapid prototyping - the ability to automatically generate full-featured forms for editing data based on the description of metadata with access control, editing the appearance in run-time and other functions.
For reference books and documents forms of the list of records and record editing are available. For totals - a form for building a report. Link tables are available through the editing forms of the corresponding directory entries.
Even if you are already confused - not scary. Let's move on to practice and everything will become clear!
Step-by-step is not blind from the monitor
Let's implement the canonical example of “bagging in the corner”.
The customer (warehouse manager) wants to keep records of packaging bags in warehouses. It is known that the bags are stored separately from the rest of the products, and the function of processing them is left at the warehouse simply in the “load”. Bags come in several sizes. It is necessary at every moment to know where (in which warehouse) how many and what bags lies. Who when issued or accepted bags.
From the formulation of the task it is clear that we will need a directory of sacks with dimensions, a directory of warehouses, a result of “bag residues”, and a document handling bags with a tabular part of “bags” that will describe two operations — arrival and expense. We assume that there are few different bags (say up to 10), so it’s enough to make a flat list.
Go. Create a new type of reference (so as not to litter the pictures, I made an animated gif):
I will not create a directory of warehouses, but I will use the fact that there is a basic solution:
Now we will create a summary of “bag remains” (a small digression - the main language in the system is English, I omit the Russian translations as irrelevant for this task)
All read-only fields are generated by the platform automatically.
So, so far I have only entered Bags / Bags, Capacity / Capacity, BagsStock / Remains of Bags, BagID / Bag, Store / Warehouse from the keyboard. Everything else is generated by the system.
We need to store information about the income and expenses of the bags. Moreover, in each parish there may be bags of several sizes. Create a tabular part of the bags:
The simplest tabular part. It has only two fields - a link to the bag and the number.
Now we will describe the document with this tabular part (the tabular part of one type can be used in several documents or several times in one)
In the created document in the header only the warehouse from (or to) which will be issued or received goods. The document has two states (in our terminology - subtypes) that determine how this document affects the result.
Voila: after three minutes of clicking the mouse, we can already create new bags and documents for receiving and consuming these bags!
Here, see for yourself:
You can distribute rights to users, they can customize their columns. The form has all the settings, groups and filters for any columns. Similarly with the documents:
Distribution of rights occurs on individual subtypes, as all settings work.
By the way. You can filter or select columns not only from the properties of the corresponding object, but also from those associated with it.
In the document example, the “Author” column contains the user name, which is listed in the user directory. Similarly, you can display the name of the office where the warehouse is located, and so on.
However, until we have created a result. Here you have to take the keyboard in hand and show how the programmer differs from the admin.
You need to write this program:
foreach(var r in document.Bags) { transactions.Add(new BagsStockTransaction { BagID = r.BagID, StoreID = document.StoreID, Quantity = r.Quantity, Amount = 0 }); } And likewise for consumption with the opposite sign:
Go through the lines and for each of them generate posting on the total remnants of the bags.
Now, after the receipt and expenditure of the bags, we can use the ready-made form for building the report and twist the data in it as you please:
Total
It took me 5 minutes 32 seconds to do all the operations.
As a result, we have: an absolutely usable interface.
Unfortunately, I can not put all the documentation in one article, so I omitted details like the localization of properties, did not show the forms for rights management, and so on. The main thing is that now you can enter data. If you need more complex logic - it is easily refined, and most importantly, you can now simultaneously work on the development of screen forms, web services, integration tests and other business logic. And each of the developers will have the tools to test their work.
By the way - at this moment only 10 lines of code have been written, in which it is rather difficult to make a mistake - that's all. No more programming, no need to do anything, and, as a result of Murphy's laws, there are no mistakes!
And this is one more reason, based on which, we argue that the cost of supporting Ultima solutions is lower than that of competitors. Even if you include in the analysis the hourly cost of a specialist.
Source: https://habr.com/ru/post/256527/
All Articles