How to model the dependencies between fields in very complex forms

We have to create a web application that will be used as an application form for multiple insurance products (15 in total). This application form will be similar to a form wizard, it will span across multiple pages, depending on what product between 4 and 10.

The grand total of all different elements (inputs, select boxes) that the form will be rendering is around 250, but even the most complex product will not use more than 170 of them. The least complex one still requires around 80 elements.

We do not want to create 15 different application forms, one per product, we want to have a single application form which will be used by all products.

Now as you can imagine, the elements have a lot of dependencies between them. A value entered in a field can make another field or set of field appear or disappear (on the current page or a following page(s)). Some other dependencies based on entered values:

value of an element is required or not
possible values for select boxes will be changed
the validation constraints will be changed

As you can imagine, modeling this is very complex. The question is, what tool would you recommend for modeling (and documenting) all these elements, the dependencies between them and the validation constraints? How would you do the modeling? Not talking about the data model at all in this case. This model will be part of the specifications of what needs to be done and as a reference after the completion of the project. By changing the model the application forms will not be automatically changed.

Some of the things we would like to be able to do easily:

see what elements a certain element depends on
see all elements included in the form for certain product
see required elements for a certain product
define validation rules for each element
define various attributes for each element

Limitation: our product managers and product owners are the ones who will do the modelling.

For a similar complex project we implemented an interpreter in the business-layerer with formulas for “isValid” and “isVisible” for every form-element

For the interpreter we used UML-s Object Constraint Language which was once designed for that purpose.

Unfortunately nearly nobody speaks “uml-ocl” so finding somebody to maintain the rules is difficuilt.

If we had to do that again we would choose a more common language like js/vb-script for the interpreter

A combination of tools might help manage the complexity. I like to start with a stuctured yet descriptive approach (as distinct from a highly formalised approach) which is easy for humans to interact with. PM’s should be comfortable with spreadsheets and it can be helpful to layout dependencies in tabular format.

Eg a table for product x field dependencies.
A second table might encapsulate the interactions between fields (field x field). The intersecting cells might initially contain descriptive text.

As a first pass this may expose issues with the logic and/or identify opportunities for simplifying the logic.

And while PMs might shy away from web programming directly, use a modern, expressive client side technology to build up the “language” of your application. Tools such as angular.js help encourage focus on what the components do and minimising noise code. The right web technology should also provide good test support.

The question is, what tool would you recommend for modeling (and documenting) all these elements, the dependencies between them and the validation constraints? How would you do the modeling?

We had a similar project. Very complex forms, and a lot of them.

The original paper forms
- Our goal was to make the web pages look exactly like them
Excel
- Screen-form-element data specification
- data element name (very important during coding) type, length, formatting, general rules
Enterprise Architect
- Basic class design via UML.

Enterprise Architect (EA)

Here is a link.

Qualifier: it’s been a few years since I last used it. A complex tool. Big learning curve. Very good UML knowledge required for precise results; there is metadata behind everything. Thus EA functionality is wide, deep, enigmatic, and sometimes quirky.

EA integrates its artifacts very well. But our teams’ collective UML and EA tool knowledge was insufficient to make it a satisfactory end-to-end tool. Note that our goal was not to use it that way. Even so, better to not use (some aspects) of the tool than to use it badly.

Each developer used it to design classes for his/her assigned form (or section thereof). The business analyst used it to create use-case diagrams. Did not use it for requirements analysis because the paper forms, form data, and process were well established – and done before we adopted EA.

We never got to leverage this comprehensive tool that had the promise of integration from requirements analysis to actual code. Developers learned only enough to create the rudimentary class and sequence diagrams required for management go-code-approval. And it was apparent to me that even when I generated code-shell from the class diagrams it was too hard (that is, lack of detailed UML knowledge), too inconvenient, too tedious to keep EA in synch with code development. So as soon as we started coding the UML diagrams very quickly became obsolete and were ignored.

Good sequence diagrams are invaluable for understanding class interaction and object instantiation. A nice high-level map when coding.

Warning

Competent and (appropriately) complete business domain design is FAR more important than any tool. I get PTS just thinking about how universally &*$&# our code was except for the very rare time we did a good business model. I could write pages and pages.

Filed under: softwareengineering - @ 20:39

Thẻ: dependencies, forms, modeling, web, web-applications

Thiết kế website giá rẻ

Danh mục

How to model the dependencies between fields in very complex forms