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

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 formularios, abarcará varias páginas, según el producto entre 4 y 10.

El total general de todos los elementos diferentes (entradas, cuadros de selección) que representará el formulario es de 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 la (s) siguiente (s) página (s)). Algunas otras dependencias basadas en valores ingresados:

el valor de un elemento es obligatorio o no
los valores posibles para cuadros seleccionados serán cambiados
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 estoy hablando del modelo de datos en absoluto en este caso. Este modelo será 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:

ver de qué elementos depende un determinado elemento
ver todos los elementos incluidos en el formulario para cierto producto
ver los elementos requeridos para un determinado producto
definir reglas de validación para cada elemento
definir varios atributos para cada elemento

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

— Marius Burz
fuente

No estoy seguro de qué quiere decir con "qué" en "qué recomendaría", pero probablemente tendría sentido definir primero algún tipo de ontología para simplificar las cosas para los modeladores. Los casos concretos serán conducidos por reglas de inferencia entonces. Como beneficio adicional, tendrá agrupaciones significativas de widgets de entrada.

— Roman Susi

@RomanSusi gracias por señalar eso, acabo de actualizar la pregunta

— Marius Burz

Ah, como aprendí recientemente, la recomendación de herramientas no es un tema aquí, consulte el Centro de ayuda programmers.stackexchange.com/help/on-topic . Además, notado ahora, no queda claro a partir de su pregunta si su sistema debería permitir la edición de productos o si se hace solo una vez en la etapa de recopilación de requisitos.

— Roman Susi

@RomanSusi es solo una parte de las especificaciones y como referencia. No diría que es solo durante la etapa de recopilación de requisitos, con tanta complejidad que esto también se utilizará como referencia. Realmente no pido solo la herramienta, más bien cómo lo harías y qué usarías para hacerlo.

— Marius Burz

¿Has probado / estudiado LimeSurvey? Cualquier otra herramienta de topografía en línea también funcionaría. Puntos de bonificación para usted si simplemente puede usarlo directamente en lugar de rodar su propia herramienta ...

Respuestas:

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

Para el intérprete utilizamos el lenguaje de restricción de objetos UML-s que alguna vez fue diseñado para ese propósito.

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

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

— k3b
fuente

Esto ya es parte de la implementación si lo entiendo correctamente. No digo que usar el código para la documentación sea incorrecto, la mayoría de las veces es lo que realmente cuenta la historia tal como es, pero para escribir el código ya necesitas tener las especificaciones y tener todo bien documentado. Ese es el contexto de la pregunta.

— Marius Burz

Discutiría la idea de que necesita todo lo documentado y especificado antes de poder escribir el código. Este es exactamente el tipo de proyecto que puede llevarse a cabo fácilmente con un enfoque iterativo, con el cliente examinando el progreso y retroalimentando los cambios de forma regular. Describir lo que debe hacerse cuando hay un formulario parcialmente implementado frente a usted es mucho más fácil que tratar de determinar cuáles serán todos los requisitos por adelantado.

— Jules

@jules: estoy totalmente de acuerdo, especialmente que las reglas de validación / visibilidad no triviales no se pueden especificar de antemano. Tienen que ser adoptados con el tiempo. Sin embargo, se puede especificar e implementar de antemano un lenguaje específico de dominio para la definición de validación / visibilidad. El intérprete de Domain-specific_language puede leer y ejecutar las reglas legibles por humanos para validación / visibilidad. No hay más necesidad de actualizar el código si las especificaciones cambian. Esta especificación debería evolucionar con el tiempo

— k3b

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

Por ejemplo, una tabla para las dependencias de producto x campo.
Una segunda tabla podría encapsular las interacciones entre campos (campo x campo). Las celdas que se cruzan inicialmente pueden contener texto descriptivo.

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

Y si bien los PM pueden evitar la programación web directamente, utilice una tecnología moderna y expresiva del lado del cliente para desarrollar el "lenguaje" de su aplicación. Herramientas como angular.js ayudan a fomentar el enfoque en lo que hacen los componentes y minimizar el código de ruido. La tecnología web adecuada también debería proporcionar un buen soporte de prueba.

— Psorenson
fuente

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?

Teníamos 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 vean exactamente como ellas
Sobresalir
- Especificación de datos de elemento de forma de pantalla
- nombre del elemento de datos (muy importante durante la codificación) tipo, longitud, formato, reglas generales
Arquitecto Empresarial
- Diseño de clase básica a través de UML.

Arquitecto empresarial (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. Se requieren muy buenos conocimientos de UML para obtener 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 herramientas 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 usarlo 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 formulario asignado (o sección del mismo). El analista de negocios lo usó para crear diagramas de casos de uso. No lo usé para el análisis de requisitos porque los formularios en papel, los datos de los formularios y el proceso estaban bien establecidos, y se hicieron antes de adoptar EA.

Nunca pudimos aprovechar esta herramienta integral que tenía la promesa de integración desde el análisis de requisitos hasta el código real. Los desarrolladores aprendieron solo lo suficiente como para crear los diagramas de secuencia y clase rudimentarios necesarios para la aprobación del código de gestión. Y era evidente para mí que incluso cuando generaba código shell a partir de los diagramas de clase era demasiado difícil (es decir, falta de conocimiento detallado de UML), demasiado inconveniente, demasiado tedioso para mantener EA sincronizado con el desarrollo del código. Tan pronto como comenzamos a codificar los diagramas UML rápidamente se volvieron obsoletos y fueron ignorados.

Los buenos diagramas de secuencia son invaluables para comprender la interacción de clase y la instanciación de objetos. Un buen mapa de alto nivel al codificar.

Advertencia

El diseño competente y (apropiadamente) completo del dominio comercial es MUCHO más importante que cualquier herramienta. Recibo PTS solo pensando en cuán universalmente era nuestro código * * $ & # excepto por el muy raro momento en que hicimos un buen modelo de negocio. Podría escribir páginas y páginas.

— radarbob
fuente

Como dijiste, esta es una herramienta muy poderosa, ya la tenemos. Esto es algo con lo que los desarrolladores de software más experimentados pueden trabajar, pero no es algo para nuestros gerentes / propietarios de productos. Creo que en realidad es bastante raro encontrar PM / PO que podría funcionar con él, como usted mismo lo dijo, la curva de aprendizaje es bastante generosa.

— Marius Burz