Come modellare le dipendenze tra i campi in forme molto complesse

8

Dobbiamo creare un'applicazione web che verrà utilizzata come modulo di domanda per più prodotti assicurativi (15 in totale). Questo modulo di domanda sarà simile a un wizard di moduli, che si estenderà su più pagine, a seconda del prodotto compreso tra 4 e 10.

Il totale complessivo di tutti i diversi elementi (input, caselle di selezione) che il modulo renderà è circa 250, ma anche il prodotto più complesso non ne userà più di 170. Il meno complesso richiede ancora circa 80 elementi.

Non vogliamo creare 15 diversi moduli di domanda, uno per prodotto, vogliamo avere un singolo modulo di domanda che verrà utilizzato da tutti i prodotti.

Ora come puoi immaginare, gli elementi hanno molte dipendenze tra di loro. Un valore inserito in un campo può far apparire o sparire un altro campo o set di campi (sulla pagina corrente o su una o più pagine successive). Alcune altre dipendenze basate sui valori inseriti:

  • il valore di un elemento è richiesto o meno
  • i valori possibili per le caselle di selezione verranno modificati
  • i vincoli di validazione verranno modificati

Come puoi immaginare, la modellazione è molto complessa. La domanda è: quale strumento consiglieresti per modellare (e documentare) tutti questi elementi, le dipendenze tra loro e i vincoli di validazione? Come faresti la modella? Non parliamo del modello dati in questo caso. Questo modello farà parte delle specifiche di ciò che deve essere fatto e come riferimento dopo il completamento del progetto. Modificando il modello i moduli di domanda non verranno automaticamente modificati.

Alcune delle cose che vorremmo poter fare facilmente:

  • guarda quali elementi un certo elemento dipende da
  • vedi tutti gli elementi inclusi nel modulo per determinati prodotti
  • vedi gli elementi richiesti per un determinato prodotto
  • definisce le regole di convalida per ciascun elemento
  • definisce vari attributi per ciascun elemento

Limitazione: i nostri product manager e proprietari di prodotti sono quelli che realizzeranno la modellazione.

    
posta Marius Burz 19.12.2014 - 21:05
fonte

3 risposte

1

Per un progetto complesso simile abbiamo implementato un interprete nel business-layerer con formule per "isValid" e "isVisible" per ogni elemento form

Per l'interprete abbiamo usato UML-s Object Constraint Language che è stato progettato una volta per questo scopo.

Sfortunatamente quasi nessuno parla "uml-ocl" quindi trovare qualcuno per mantenere le regole è difficile.

Se dovessimo farlo di nuovo, sceglieremmo un linguaggio più comune come js / vb-script per l'interprete

    
risposta data 22.12.2014 - 09:02
fonte
1

Una combinazione di strumenti potrebbe aiutare a gestire la complessità. Mi piace iniziare con un approccio strutturato ma descrittivo (distinto da un approccio altamente formalizzato) che è facile per gli umani con cui interagire. I PM devono essere constrongvoli con i fogli di calcolo e può essere utile per distribuire le dipendenze in formato tabulare.

  1. Es. una tabella per le dipendenze del campo x del prodotto.
  2. Una seconda tabella potrebbe incapsulare le interazioni tra i campi (campo x campo). Le celle intersecanti potrebbero inizialmente contenere testo descrittivo.

Come primo passo ciò potrebbe esporre problemi con la logica e / o identificare opportunità per semplificare la logica.

E anche se i PM possono allontanarsi direttamente dalla programmazione web, utilizzare una tecnologia lato client moderna ed espressiva per costruire il "linguaggio" della propria applicazione. Strumenti come angular.js aiutano a concentrarsi su ciò che i componenti fanno e riducendo al minimo il codice rumore. La giusta tecnologia web dovrebbe anche fornire un buon supporto per i test.

    
risposta data 24.12.2014 - 06:57
fonte
0

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?

Abbiamo avuto un progetto simile. Forme molto complesse e molte.

  • La carta originale si forma
    • Il nostro obiettivo era rendere le pagine web esattamente come loro
  • Excel
    • Specifiche dei dati dello schermo-elemento-elemento
    • nome elemento dati (molto importante durante la codifica) tipo, lunghezza, formattazione, regole generali
  • Enterprise Architect
    • Progettazione della classe di base tramite UML.

Enterprise Architect (EA)

Ecco un link.

Qualificatore: sono passati alcuni anni dall'ultima volta che l'ho usato. Uno strumento complesso Grande curva di apprendimento. Conoscenza UML molto buona richiesta per risultati precisi; ci sono metadati dietro tutto . Pertanto, la funzionalità di EA è ampia, profonda, enigmatica e talvolta bizzarra.

EA integra i suoi artefatti molto bene. Ma la conoscenza collettiva degli strumenti UML e EA dei nostri team non era sufficiente a renderlo uno strumento end-to-end soddisfacente. Nota che il nostro obiettivo non era quello di usarlo in quel modo. Anche così, meglio non usare (alcuni aspetti) dello strumento piuttosto che usarlo male.

Ogni sviluppatore lo ha usato per progettare classi per il suo modulo assegnato (o una sua sezione). L'analista di business l'ha usato per creare diagrammi del caso d'uso. Non l'ho usato per l'analisi dei requisiti perché i moduli cartacei, i dati dei moduli e il processo erano ben stabiliti e fatti prima di adottare EA.

Non abbiamo mai dovuto sfruttare questo strumento completo che aveva la promessa di integrazione dall'analisi dei requisiti al codice reale. Gli sviluppatori hanno appreso quanto basta per creare la rudimentale classe e i diagrammi di sequenza richiesti per l'approvazione del go-code di gestione. Ed era chiaro per me che anche quando ho generato la shell di codice dai diagrammi delle classi era troppo difficile (cioè la mancanza di una conoscenza approfondita di UML), troppo scomodo, anche noioso per mantenere EA in sincronia con lo sviluppo del codice. Quindi, non appena abbiamo iniziato a scrivere codice, i diagrammi UML sono diventati molto rapidamente obsoleti e ignorati.

I diagrammi di buona sequenza sono di valore inestimabile per comprendere l'interazione di classe e l'istanziazione di oggetti. Una bella mappa di alto livello durante la codifica.

Attenzione

La progettazione del dominio aziendale completa e (appropriatamente) completa è la FAR più importante di qualsiasi strumento. PTS pensa solo a quanto universalmente & $; $ & # il nostro codice era eccetto per il molto raro periodo in cui abbiamo fatto un buon modello di business. Potrei scrivere pagine e pagine.

    
risposta data 23.12.2014 - 19:39
fonte

Leggi altre domande sui tag