Prototype this Or useful functionality faster than a cup of coffee

    Today I want to talk about the capabilities of rapid prototyping implemented in the Ultima Businessware platform . I will show how to quickly sketch out the implementation of the trivial process (there will be slides!), I will tell you how to reduce development time and improve the scalability of the development process. Well, at the same time, I’ll walk a little through all the small “goodies” of the system about which I mentioned in previous articles. For details - please, under cat.



    Rapid Prototyping


    In general, the term arose as the name of a method or function of a development environment that made it possible to obtain a graphical interface with ready-made buttons in a relatively short time.
    In my practice, this only allowed usability tests and a fix before a lot of code was 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 the ability to account for something and somewhere in the system. Accounting implies that there are operations of receipt and expenditure of this something somewhere.

    Actually, for simple situations, the prototyped solution has sufficient functionality, and for more complex ones it allows you to distribute the processes of developing the interface and business logic. Moreover, even in complex business processes, the user can start entering data at the very early stages of development.

    To understand how prototyping works, you first need to understand the concept of describing data structures of a subject area.
    Without going into details (more details are in the excerpt from the documentation ), all structures belong to the following classes:
    • Directories
      Contain “static” information. For example, goods, offices, warehouses.
    • Link tables
      Contain information about many-to-many relationships between different directories
    • Documents and tabular parts
      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 table section lists various attributes. For example, how much, how much and what goods we sold.
    • Summary
      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’s still not clear, try reading the documentation . Or just see what happens next.

    In turn, the structure of the subject area is described as a set of types of directories, types of documents, types of decoupling tables and totals interacting via scripts - special classes in C #.
    The type of directory or document defines the internal structure of the corresponding object. Each type of directory or document corresponds to a class in C # for storing one unit of data.
    Now we can state what rapid prototyping is in our platform:
    Rapid prototyping - the ability to automatically generate full-featured forms of data editing based on the description of metadata with access control, editing appearance in run-time and other functions.

    For directories and documents, the forms of the list of records and editing of the record are available. For the results, a report construction form. Decoupling tables are available through editing forms of the corresponding directory entries.
    Even if you are already confused - no big deal. Let's move on to practice and everything will become clear!

    Step-by-step until the monitor is blinded


    Let's implement the canonical example of "accounting for bags 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 dumped into the warehouse simply in the “load”. Bags come in several sizes. It is necessary at every moment of time to know where (in which warehouse) how many and which bags are lying. Who when issued or accepted bags.

    From the statement of the problem, it is clear that we need a reference book of bags with sizes, a directory of warehouses, a summary of “leftovers of bags,” and a document processing the bags with the tabular part “bags”, which will describe two operations — receipt and consumption. We assume that there are few different bags (say up to 10), so it’s enough to make a flat list.

    Go. We are creating a new type of directory (in order not to litter pictures, I made an animated gif):



    I will not create a directory of warehouses, but I will use what is in the basic solution:



    Now we will create the result of “the remains of the bags” (a small digression - the main language in the system is English , I omit translations into Russian as insignificant for this task)



    The platform automatically generates all read-only fields.
    So until now, I have only entered Bags / 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 receipts and expenses of the bags. Moreover, in each parish there may be bags of several sizes. Create the tabular part of the bags:



    The simplest tabular part. It has only two fields - a link to the bag and quantity.
    Now we will describe the document with this tabular part (the tabular part of the same type can be used in several documents or several times in one).



    In the created document in the header there is only a warehouse with (or on) which goods will be issued or received. A document has two states (in our terminology - a subtype) that determine how this document affects the outcome.
    Voila: after three minutes of clicking with 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 configure their own columns. The form has all the settings, groupings and filters for any columns. Similarly with the docs:



    Distribution of rights occurs on separate subtypes, all settings also work.

    By the way. You can filter or select columns not only from the properties of the corresponding object, but also from the ones associated with it.

    In the example with the document, the “Author” column contains the username that is specified in the user directory. Similarly, you can display the name of the office in which the warehouse is located and so on.

    However, until we created the result. Here you have to pick up the keyboard and show how the programmer differs from the admin.

    You need to write this program:

    foreach(var r indocument.Bags)
    {
          transactions.Add(new BagsStockTransaction
          {
                 BagID = r.BagID,
                 StoreID = document.StoreID,
                 Quantity = r.Quantity,
                 Amount = 0
         });
    }
    

    And similarly for the flow with the opposite sign:



    Go through the lines and for each of them generate a posting based on the total remaining bags.
    Now, after the arrival and expenditure of the bags, we can use the ready-made report design form and twist the data in it as you like:



    Total


    It took me 5 minutes 32 seconds to complete all the operations.
    As a result, we have: an absolutely usable interface.

    Unfortunately, I can’t put all the documentation in one article, so I omitted the details like localizing properties, didn’t show forms for rights management and so on. The main thing is that now you can enter data. If more complex logic is required, it is easily finalized, and most importantly, now you can simultaneously engage in the development of screen forms, web services, integration tests and other business logic. And each of the developers will have tools to verify their work.

    By the way - at this moment only 10 lines of code are written, in which it is quite difficult to make a mistake - and that’s all. No more programming, nothing needs to be done, and, as a consequence of Murphy’s laws, there are no errors!

    And this is one more reason, on the basis of which, we argue that the cost of supporting Ultima solutions is lower than that of competitors. Even if you include the hourly cost of a specialist in the analysis.

    Also popular now: