a DSL for fastest datamodeling in uniface with customer participation

Author: ulrichmerkel@web.de (ulrich-merkel)

datamodel sprint_taric "sprint_taric is " entity TBL_Abg_Art "TBL_Abg_Art is a" { field ABG_SATZ_KOMP_ID "Abgabenart-Id (TARIC2)" format=CHAR(2) field DAT_START "Datum Gültigkeitsbeginn (TARIC2)" format=DATE field DAT_END "Datum Gültigkeitsende (TARIC2)" format=DATE field ABG_SATZ_KOMP_ANW_CODE "Code der Anwendbarkeit eines Abgabensatzes (TARIC2)" format=CHAR(1) field MASS_EINH_ANW_CODE "Anwendbarer Code der Maßeinheit (TARIC2)" format=CHAR(1) field WAEHR_EINH_ANW_CODE "Anwendbarer Code der Währungseinheit (TARIC2)" format=CHAR(1) field AKRONYM "Abkürzung (TARIC2)" format=CHAR(5) field KURZ_BESCHR "Kurztext (TARIC2)" format=VARCHAR2(100) keyfields="ABG_SATZ_KOMP_ID" } It occurs in most cases only at the beginning of a new (sub-)system implementation, but datamodeling in uniface is not the most liked job for uniface developers. It's just silly typing what is somewhere printed into IDF forms times and times again. With the use of a specific "domain specific language" (DSL) we specify the model into an easy-to-read textfile which will later generate the necessary artifacts to work with the uniface repository. With the DSL, we get an editor with a state-of-the-art support like "online error check", "text template support", "content assistant". These easy to understand textfiles can be maintained even by the customers themself saving the developers a lot of time. They can proof-read what is done and do their corrections in the same document. All the developer has to do is to process this document against the uniface repository which does not cost too much time. A short real-world use case with screencasts will demonstrate how we can boost datamodel generation in uniface and how the customers can play a more important role in maintaining the datamodel in the uniface repository. you can download the documentation and the screencasts of the sprint from www.uli-merkel.de as "130624 umeCIF1-Sprints-doc-and-screencasts.zip" (some 10 MB)

7 Comments

  1. They may not be so easy to read, but we do support CIF files for importing model information.


    Author: Theo Neeskens (tneeskens@itblockz.nl)
  2. Theo Neeskens said They may not be so easy to read, but we do support CIF files for importing model information.

    But CIF syntax is not documented and there is no supporting editor. This DSL makes even meaninful text files for non-IT personnel. In fact the DSL generates a CIF file to be loaded into uniface, at least as long as "CASE Load" will be supported in Uniface (afterwards, we have to find a handcrafted loader)


    Author: ulrich-merkel (ulrichmerkel@web.de)
  3. I agree with the 'type yourself to death' pains when defining a new model... I've taken a slightly different approach in the past - defining the entity in an XLS file, importing the XLS file into SQL server and doing a 'load-def' from SQL server to Uniface. Not sexy, sophisticated or particulary crafty - but it does 75-80% of the legwork for me.... Uli - I remember there being a 'case cookbook' years ago - I think it was updated to CIF 2.0 as well - although I haven't seen the title for a number of years...


    Author: Knut (knut.dybendahl@gmail.com)
  4. Hi Knut, you remembered it well: in 7.2 there was a "case bridge cookbook" (cbc.pdf) in the normal distribution set. But now this is no longer updated / maintained by CPWR: "We are not planning on publishing details on CIF or samples, it will be removed from the product in the future." One reason for going the DSL route was to ease the way documentation (Descriptions, Labels, Comments) is added to the uniface datamodel without the "retype the text into the IDF" and is fed back to the end-users for proof-reading and corrections. The beauty of the DSLs is that "the end-users" can play a more important role in application development: Model/Entity/Field Descriptions, Labels, Comments can be maintained by a simple text file which is easy to read and understand, can be transported by simple email, and can be processed in diff/merge. And all we as developers have to do is to load the information into the uniface datamodel, regenerate the DSL and pass it back to the end-users for proof-reading in the next iteration. Please download the complete pack from www.uli-merkel.de to see more use cases for the DSLs


    Author: ulrich-merkel (ulrichmerkel@web.de)
  5. An example for specifying labels (returned from the end users, not 100% correct because quotes in quoted strings): datamodel SPRINT_TARIC "Grundlagen TARIC" entity TBL_ABG_ART "TBL_Abg_Art [T23000]" { field ABG_SATZ_KOMP_ANW_CODE "Code der Anwendbarke" label="Code Anwendbarkeit" field ABG_SATZ_KOMP_ID "Abgabenart-Id (TARIC" label="Abgabenart-Id" field AKRONYM "Abkürzung (TARIC2)" label="Abkürzung" field DAT_END "Datum Gültigkeitsend" label="Ende Gültigkeit" field DAT_START "Datum Gültigkeitsbeg" label="Anfang Gültigkeit" field KURZ_BESCHR "Kurztext (TARIC2)" label="Kurzbeschreibung" maybe we find a better one field MASS_EINH_ANW_CODE "Anwendbarer Code der" label="Maßeinheit "CODE"" field WAEHR_EINH_ANW_CODE "Anwendbarer Code der" label="Währung "CODE"" } ****************** but it's much faster to correct the errors (the DSL based editor will assist us) and load the whole bunch as to type all the label infos into the uniface repository.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  6. I agree that filling the model is paintfull. A lot of click and mouse move. That's why in the CHUI times we did our own forms on the dictionnary. Rmemeber that the source are data in the database so you can use Uniface to create forms on the dictonnary. So our Mass Update form showed all fields with with their properties as records with their fields. Of course you have to be carefull to implement correct validation triggers to avoid putting garbage in the dictonnary.


    Author: daeneb (bertrand.daene@cgm.com)
  7. daeneb said Rmemeber that the source are data in the database so you can use Uniface to create forms on the dictonnary

    But it's still we, the developers, have to type all that stuff in. The trick with the DSL is: - let the customers do all the work, - have your DSL based editor to check for syntax-problems and solve these - and just load their modifications into the repository. If you have a look at the "sprint" screencasts from www.uli-merkel.de it's a matter of minutes to do so. The domain-experts do not have to learn uniface, they just have some easy to read textfile to process. If they like to have other keywords, it just takes minutes to change this.


    Author: ulrich-merkel (ulrichmerkel@web.de)