Como modelar as dependências entre campos de formas muito complexas

Temos que criar um aplicativo da web que será usado como um formulário de pedido para vários produtos de seguros (15 no total). Este formulário de inscrição será semelhante a um assistente de formulário, ele se estenderá por várias páginas, dependendo do produto entre 4 e 10.

O total geral de todos os diferentes elementos (entradas, caixas de seleção) que o formulário renderizará é de cerca de 250, mas mesmo o produto mais complexo não utilizará mais de 170 deles. O menos complexo ainda requer cerca de 80 elementos.

Não queremos criar 15 formulários de inscrição diferentes, um por produto, queremos ter um único formulário de inscrição que será usado por todos os produtos.

Agora, como você pode imaginar, os elementos têm muitas dependências entre eles. Um valor inserido em um campo pode fazer com que outro campo ou conjunto de campos apareça ou desapareça (na página atual ou nas páginas seguintes). Algumas outras dependências baseadas nos valores inseridos:

o valor de um elemento é obrigatório ou não
os valores possíveis para caixas de seleção serão alterados
as restrições de validação serão alteradas

Como você pode imaginar, modelar isso é muito complexo. A questão é: qual ferramenta você recomendaria para modelar (e documentar) todos esses elementos, as dependências entre eles e as restrições de validação? Como você faria a modelagem? Não estamos falando sobre o modelo de dados neste caso. Este modelo fará parte das especificações do que precisa ser feito e como referência após a conclusão do projeto. Ao alterar o modelo, os formulários de inscrição não serão alterados automaticamente.

Algumas das coisas que gostaríamos de poder fazer facilmente:

ver em quais elementos um determinado elemento depende
veja todos os elementos incluídos no formulário para determinado produto
veja os elementos necessários para um determinado produto
definir regras de validação para cada elemento
definir vários atributos para cada elemento

Limitação: nossos gerentes e proprietários de produtos são os que farão a modelagem.

— Marius Burz
fonte

Não sei o que você quer dizer com "o que" em "o que você recomendaria", mas provavelmente faria sentido definir algum tipo de ontologia primeiro para simplificar as questões para os modeladores. Casos concretos serão conduzidos por regras de inferência. Como bônus, você terá agrupamentos significativos de widgets de entrada.

— Roman Susi

@RomanSusi obrigado por apontar isso, acabou de atualizar a pergunta #

— Marius Burz

Ah, como aprendi recentemente, a recomendação de ferramenta é offtopic aqui, consulte a Central de Ajuda programmers.stackexchange.com/help/on-topic . Além disso, percebido agora, não está claro em sua pergunta se o seu sistema deve permitir a edição de produtos ou se é feito apenas uma vez no estágio de coleta de requisitos.

— Roman Susi

@RomanSusi é apenas parte das especificações e como referência. Eu não diria que é apenas durante o estágio de coleta de requisitos, com tanta complexidade que isso também será usado como referência. Não estou realmente pedindo a ferramenta sozinha, mais como como você faria e o que você usaria para fazê-lo.

— Marius Burz

Você já tentou / estudou o LimeSurvey? Qualquer outra ferramenta de pesquisa on-line também funcionaria. Os pontos de bónus para você se você pode simplesmente usá-lo diretamente, em vez de rolar a sua própria ferramenta de ...

Respostas:

Para um projeto complexo semelhante, implementamos um intérprete na camada de negócios com fórmulas para "isValid" e "isVisible" para cada elemento do formulário

Para o intérprete, usamos a linguagem de restrição de objeto da UML, que foi projetada para esse fim.

Infelizmente, quase ninguém fala "uml-ocl", por isso é difícil encontrar alguém para manter as regras.

Se tivéssemos que fazer isso novamente, escolheríamos uma linguagem mais comum, como js / vb-script, para o intérprete.

— k3b
fonte

Isso já faz parte da implementação, se bem entendi. Não estou dizendo que usar o código para documentação está errado, na maioria das vezes é o que realmente conta a história, mas para escrever o código, você já precisa ter as especificações e ter tudo bem documentado. Esse é o contexto da questão.

— Marius Burz

Eu contestaria a noção de que você exige tudo documentado e especificado antes de poder escrever o código. Esse é exatamente o tipo de projeto que pode ser facilmente realizado com uma abordagem iterativa, com o cliente examinando o progresso e realizando alterações regularmente. Descrever o que precisa ser feito quando houver um formulário parcialmente implementado à sua frente é muito mais fácil do que tentar determinar quais serão todos os requisitos com antecedência.

— Jules

@jules: Eu concordo totalmente, especialmente que regras de validação / visibilidade não triviais não podem ser especificadas com antecedência. Eles precisam ser adotados ao longo do tempo. No entanto, uma linguagem específica do domínio para a definição de validade / visibilidade pode ser especificada e implementada com antecedência. O intérprete do idioma específico do domínio pode ler e executar as regras legíveis por humanos para validação / visibilidade. Não há mais necessidade de atualizar o código se as especificações mudarem. Esta especificação deve evoluir com o tempo

— k3b

Uma combinação de ferramentas pode ajudar a gerenciar a complexidade. Eu gosto de começar com uma abordagem estruturada, mas descritiva (diferente de uma abordagem altamente formalizada), que é fácil para os humanos interagirem. Os PMs devem se sentir confortáveis com as planilhas e pode ser útil organizar as dependências no formato tabular.

Por exemplo, uma tabela para as dependências do produto x campo.
Uma segunda tabela pode encapsular as interações entre os campos (campo x campo). As células que se cruzam podem conter inicialmente texto descritivo.

Como primeira passagem, isso pode expor problemas com a lógica e / ou identificar oportunidades para simplificar a lógica.

E enquanto os PMs podem evitar a programação da Web diretamente, use uma tecnologia moderna e expressiva do lado do cliente para criar a "linguagem" do seu aplicativo. Ferramentas como angular.js ajudam a incentivar o foco no que os componentes fazem e a minimizar o código de ruído. A tecnologia da web correta também deve fornecer um bom suporte de teste.

— psorenson
fonte

A questão é: qual ferramenta você recomendaria para modelar (e documentar) todos esses elementos, as dependências entre eles e as restrições de validação? Como você faria a modelagem?

Tivemos um projeto semelhante. Formas muito complexas, e muitas delas.

Os formulários originais em papel
- Nosso objetivo era fazer com que as páginas da Web se parecessem exatamente com elas
Excel
- Especificação de dados do elemento de formulário de tela
- nome do elemento de dados (muito importante durante a codificação) tipo, comprimento, formatação, regras gerais
Arquiteto Empresarial
- Design de classe básica via UML.

Arquiteto Corporativo (EA)

Aqui está um link.

Qualificador: já faz alguns anos desde a última vez que o usei. Uma ferramenta complexa. Grande curva de aprendizado. É necessário um conhecimento UML muito bom para resultados precisos; há metadados por trás de tudo . Assim, a funcionalidade do EA é ampla, profunda, enigmática e às vezes peculiar.

A EA integra seus artefatos muito bem. Mas o conhecimento coletivo das ferramentas UML e EA de nossas equipes era insuficiente para torná-lo uma ferramenta de ponta a ponta satisfatória. Observe que nosso objetivo não era usá-lo dessa maneira. Mesmo assim, é melhor não usar (alguns aspectos) da ferramenta do que usá-la mal.

Cada desenvolvedor o usou para projetar classes para o formulário designado (ou seção). O analista de negócios o usou para criar diagramas de casos de uso. Não o utilizou para análise de requisitos, porque os formulários, dados e processo do papel estavam bem estabelecidos - e foram feitos antes da adoção do EA.

Nunca conseguimos aproveitar essa ferramenta abrangente que tinha a promessa de integração da análise de requisitos ao código real. Os desenvolvedores aprenderam apenas o suficiente para criar os diagramas rudimentares de classe e sequência necessários para a aprovação do código de gerenciamento. E ficou claro para mim que mesmo quando eu gerava o shell de código a partir dos diagramas de classes, era muito difícil (ou seja, falta de conhecimento detalhado da UML), muito inconveniente e entediante demais para manter a EA sincronizada com o desenvolvimento do código. Assim que começamos a codificar, os diagramas UML rapidamente se tornaram obsoletos e foram ignorados.

Os bons diagramas de sequência são inestimáveis para entender a interação de classe e a instanciação de objetos. Um bom mapa de alto nível ao codificar.

Atenção

Um design de domínio comercial competente e (adequadamente) completo é MUITO mais importante do que qualquer ferramenta. Recebo o PTS pensando em como universalmente nosso código era, exceto pelo muito raro momento em que fizemos um bom modelo de negócios. Eu poderia escrever páginas e páginas.

— radarbob
fonte

Como você disse, esta é uma ferramenta muito poderosa, já a temos na verdade. Isso é algo com o qual os desenvolvedores de software mais experientes podem trabalhar, mas não é algo para nossos gerentes / proprietários de produtos. Eu acho que, na verdade, é bastante incomum encontrar PM / PO que possa funcionar com ele, como você mesmo disse, a curva de aprendizado é bastante generosa.

— Marius Burz