Qual è il modo più robusto ed estensibile per rappresentare un contratto nel codice? [chiuso]

Question

Qual è il modo più robusto ed estensibile per rappresentare un contratto nel codice? [chiuso]

#1 da (2 voti)
#2 da (2 voti)
#3 da (2 voti)

0

Mi piacerebbe trovare o creare una sintassi per esprimere a livello di programmazione i contratti aziendali, e sto cercando un modo robusto, flessibile e resistente al futuro per farlo.

Un client dovrebbe essere in grado di aggiungere un punto di negoziazione di tipi diversi al contratto.

Un esempio di un punto di negoziazione booleano:

"C'è una penalità di pre-pagamento?" (Sì / no)

Anche se quanto sopra è certamente fattibile, sembra più difficile descrivere le relazioni tra i punti di negoziazione in modo astratto.

Alcuni esempi:

$ 600 viene pagato dal "Cliente A" per l'ispezione.
L'importo di cui sopra è pagato da "Cliente B" se la condizione Y (informazioni che avrebbero dovuto essere divulgate prima dell'ispezione non sono state divulgate).

Alcune altre funzionalità possibili:

I campi virtuali vengono calcolati in base ai valori numerici degli altri campi.

Note:

Sembra certamente che XML o forse lo schema JSON siano possibili candidati per la descrizione di quanto sopra. Ma sono aperto ad altre opzioni.

link

Grazie mille,

language-design xml json dsl

posta Nathan Lippi 23.09.2014 - 23:55

fonte

3 risposte

Leggi altre domande sui tag language-design xml json dsl

Design pattern per modificare lo stato e notificare gli altri modificatori senza un loop I compiti semplici devono essere divisi in funzioni separate? [duplicare]

score 2 · Answer 1

Il modo più comunemente accettato è quello di utilizzare un Business Rules Engine di qualche tipo.

Naturalmente, se sei disposto a pubblicare il tuo BRE e hai solo bisogno di una lettura del linguaggio di markup da usare, immagino che XML sia buono come qualsiasi altro. È gerarchico, ha spazi dei nomi ed è improbabile che diventi presto obsoleto. Dal momento che è probabile che non stiamo parlando di gigabyte di markup qui, è improbabile che la tassa sulla fascia d'angolo sia un vero problema.

score 2 · Answer 2

A livello di sintassi, XML o JSON andrebbero bene. Ma questo è un po 'facile. La sfida è definire cosa può andare nelle regole. Adotterei un approccio standard alla modellazione di oggetti: quali sono le entità che devi rappresentare e quali sono i loro attributi e relazioni? Quando lo sai, codificarlo in XML è facile.

score 2 · Answer 3

Il problema più grande è il enorme insieme di ipotesi che salti così facilmente.

Prendi il tuo esempio: "$ 600 è pagato da Client A per l'ispezione"

USD o altro dollaro?
Pagato quando?
A chi?
Ciò che conta come ispezione?
Si tratta di un pagamento obbligatorio, o si verifica solo se A sceglie di effettuare l'ispezione?
Sono consentite più ispezioni, in caso affermativo, è questo per ispezione?

Il tuo DSL dovrà affrontare tutta questa complessità. Per i contratti in inglese , gli avvocati hanno già sviluppato metodi per risolvere tali problemi e persino prevenirli esaminando i progetti di contratto.