Cómo modelar las dependencias entre campos en formas muy complejas

8

Tenemos que crear una aplicación web que se utilizará como formulario de solicitud para múltiples productos de seguros (15 en total). Este formulario de solicitud será similar a un asistente de formulario, se extenderá a lo largo de varias páginas, dependiendo de qué producto se encuentre entre 4 y 10.

El total general de todos los elementos diferentes (entradas, cuadros de selección) que el formulario procesará es alrededor de 250, pero incluso el producto más complejo no utilizará más de 170 de ellos. El menos complejo todavía requiere alrededor de 80 elementos.

No queremos crear 15 formularios de solicitud diferentes, uno por producto, queremos tener un solo formulario de solicitud que será utilizado por todos los productos.

Ahora, como puedes imaginar, los elementos tienen muchas dependencias entre ellos. Un valor ingresado en un campo puede hacer que otro campo o conjunto de campos aparezca o desaparezca (en la página actual o en las siguientes páginas). Algunas otras dependencias basadas en valores ingresados:

  • el valor de un elemento es obligatorio o no
  • se cambiarán los valores posibles para los cuadros de selección
  • las restricciones de validación serán cambiadas

Como puedes imaginar, modelar esto es muy complejo. La pregunta es, ¿qué herramienta recomendaría para modelar (y documentar) todos estos elementos, las dependencias entre ellos y las restricciones de validación? ¿Cómo harías el modelado? No hablamos en absoluto del modelo de datos en este caso. Este modelo formará parte de las especificaciones de lo que debe hacerse y como referencia después de la finalización del proyecto. Al cambiar el modelo, los formularios de solicitud no se cambiarán automáticamente.

Algunas de las cosas que nos gustaría poder hacer fácilmente:

  • vea de qué elementos depende un elemento determinado
  • vea todos los elementos incluidos en el formulario para ciertos productos
  • ver los elementos requeridos para un determinado producto
  • defina reglas de validación para cada elemento
  • defina varios atributos para cada elemento

Limitación: nuestros gerentes de productos y propietarios de productos son los que harán el modelado.

    
pregunta Marius Burz 19.12.2014 - 21:05

3 respuestas

1

Para un proyecto complejo similar implementamos un intérprete en la capa de negocios con fórmulas para "isValid" e "isVisible" para cada elemento de formulario

Para el intérprete usamos el Lenguaje de restricción de objetos de UML, que una vez fue diseñado para ese propósito.

Desafortunadamente, casi nadie habla "uml-ocl", por lo que encontrar a alguien para mantener las reglas es difícil.

Si tuviéramos que volver a hacerlo, elegiríamos un lenguaje más común como js / vb-script para el intérprete

    
respondido por el k3b 22.12.2014 - 09:02
1

Una combinación de herramientas podría ayudar a administrar la complejidad. Me gusta comenzar con un enfoque estructurado pero descriptivo (a diferencia de un enfoque altamente formalizado) con el que es fácil para los humanos interactuar. Los PM deben sentirse cómodos con las hojas de cálculo y pueden ser útiles para las dependencias de diseño en formato tabular.

  1. Por ejemplo, una tabla para las dependencias del campo x del producto.
  2. Una segunda tabla puede encapsular las interacciones entre los campos (campo x campo). Las celdas que se cruzan pueden contener inicialmente texto descriptivo.

Como primer paso, esto puede exponer problemas con la lógica y / o identificar oportunidades para simplificar la lógica.

Y mientras que los PM pueden alejarse de la programación web directamente, use una tecnología del lado del cliente moderna y expresiva para construir el "lenguaje" de su aplicación. Las herramientas como angular.js ayudan a fomentar el enfoque en lo que hacen los componentes y minimizan el código de ruido. La tecnología web correcta también debería proporcionar un buen soporte de prueba.

    
respondido por el psorenson 24.12.2014 - 06:57
0
  

La pregunta es, ¿qué herramienta recomendaría para modelar (y documentar) todos estos elementos, las dependencias entre ellos y las restricciones de validación? ¿Cómo harías el modelado?

Tuvimos un proyecto similar. Formas muy complejas, y muchas de ellas.

  • Los formularios originales en papel.
    • Nuestro objetivo era hacer que las páginas web se vieran exactamente como ellas
  • Excel
    • Especificación de datos del elemento de formulario de pantalla
    • nombre del elemento de datos (muy importante durante la codificación) tipo, longitud, formato, reglas generales
  • Enterprise Architect
    • Diseño de clase básico a través de UML.

Enterprise Architect (EA)

Aquí hay un enlace.

Calificador: han pasado algunos años desde la última vez que lo usé. Una herramienta compleja. Gran curva de aprendizaje. Muy buen conocimiento de UML requerido para resultados precisos; hay metadatos detrás de todo . Por lo tanto, la funcionalidad de EA es amplia, profunda, enigmática y, a veces, peculiar.

EA integra muy bien sus artefactos. Pero el conocimiento colectivo de la herramienta de UML y EA de nuestros equipos fue insuficiente para convertirlo en una herramienta satisfactoria de extremo a extremo. Tenga en cuenta que nuestro objetivo no era utilizarlo de esa manera. Aun así, es mejor no usar (algunos aspectos) de la herramienta que usarla mal.

Cada desarrollador lo usó para diseñar clases para su forma asignada (o sección de la misma). El analista de negocios lo utilizó para crear diagramas de casos de uso. No lo usé para el análisis de requisitos porque los formularios en papel, los datos del formulario y el proceso estaban bien establecidos, y se realizaron antes de que adoptáramos EA.

Nunca pudimos aprovechar esta herramienta integral que prometía la integración desde el análisis de requisitos hasta el código real. Los desarrolladores aprendieron solo lo suficiente como para crear los diagramas rudimentarios de clase y secuencia necesarios para la aprobación del código de acceso de la administración. Y me pareció evidente que incluso cuando generaba un shell de código a partir de los diagramas de clase era demasiado difícil (es decir, la falta de conocimiento detallado de UML), demasiado incómodo, demasiado tedioso para mantener a EA sincronizado con desarrollo de código. Entonces, tan pronto como comenzamos a codificar los diagramas UML, muy rápidamente quedaron obsoletos y fueron ignorados.

Los buenos diagramas de secuencia son invaluables para comprender la interacción de clase y la creación de instancias de objetos. Un buen mapa de alto nivel cuando se codifica.

Advertencia

Un diseño de dominio empresarial competente y (apropiadamente) completo es MUCHO más importante que cualquier otra herramienta. Obtengo PTS solo pensando en qué tan universal & * $ & # fue nuestro código, excepto en el muy raro momento en que hicimos un buen modelo de negocio. Podría escribir páginas y páginas.

    
respondido por el radarbob 23.12.2014 - 19:39

Lea otras preguntas en las etiquetas