Un esperto di dominio dovrebbe creare diagrammi di classe?

In realtà dipende dal livello di dettagli nei diagrammi delle classi e dal modo in cui vengono utilizzati.

Una distinzione importante che deve essere fatta: una classe UML non è (necessariamente) uguale a una classe di linguaggio di programmazione. Denota i concetti di dominio che possono essere implementati in molti modi diversi (o non del tutto).

Definire questi concetti è un lavoro per gli esperti del dominio. Il formato specifico in cui lo faranno non ha importanza, purché sia sufficientemente chiaro (questa è la parte difficile). Quindi, può essere una descrizione verbale o, come nel tuo caso, un diagramma UML.

Ora il fatto è che questi diagrammi UML prodotti dagli esperti di dominio non sono necessari e il più delle volte non deve essere utilizzato come blueprint per il codice . Sono lì solo per consentire al team di sviluppo di comprendere il dominio aziendale. Quindi, se ritengono che sia necessario, gli sviluppatori (inclusi gli architetti di sistema) creano un modello diverso che prende in considerazione anche la limitazione tecnica che non è nota all'esperto del dominio. Inoltre, il formato di quel modello non è particolarmente importante. Può essere un altro modello UML, ma può anche essere una combinazione di codice e documentazione di progetto.

Esempio:

Considerare un sistema di software bancario. In questo caso l'esperto di dominio è qualcuno che ha esperienza nel settore bancario. Il suo compito è quello di comunicare i requisiti aziendali al team di sviluppo e può scegliere di farlo modellando il flusso di documenti utilizzato dalla banca. Ora, il fatto è che questi documenti (nella forma in cui appaiono stampati e compilati a mano) sono in genere estremamente non normalizzati e contengono lotti di dati ridondanti sparsi su forme diverse. Il modello prodotto dall'esperto del dominio può contenere tutte queste ridondanze, ma il modello implementato dallo sviluppo in genere lo eliminerà dove necessario. Tuttavia, entrambi i modelli hanno avuto il loro utilizzo nel processo di sviluppo.

Is it normal for a domain expert to do class diagrams?

Se un esperto di dominio esegue diagrammi di classe nel senso tradizionale ^* , la risposta è "assolutamente no". Dovresti resistere il più possibile, a vantaggio di tutti.

Sono stato in una situazione del genere in una start-up molti anni fa, in cui un esperto di dominio molto strong ha cercato di mappare una soluzione aziendale in termini molto tecnici. Il problema era che piuttosto che spiegare gli aspetti commerciali che il team doveva affrontare, ha fornito molti dettagli tecnici di una soluzione che ha costruito in passato. Alla fine abbiamo deciso che avrebbe dovuto spiegarci cosa fare invece di come per farlo, e insieme abbiamo reso il progetto un successo.

L'analista di business per il mio team attuale fa esattamente la stessa cosa :) Non direi che sia comune, ma è un difetto tipico per qualcuno con un background tecnico che si è evoluto in un analista di business / esperto di dominio.

Ci sono molti modi per modellare un dominio, dai diagrammi UML alle parole su una lavagna, ai disegni su un pezzo di carta. La cosa importante non è l'aspetto del modello ma ciò che trasmette . Tieni inoltre presente che la modellazione del dominio è lavoro collaborativo e implica la conversazione tra l'esperto di dominio e i tecnici. Un ambiente in cui l'esperto di business produce tutti i modelli (per non parlare dei modelli tecnici di basso livello) da solo e li impone alla squadra di sviluppo mi sembra alquanto disfunzionale.

Is it normal for a domain expert (not a developer or technical profile) to do class diagrams?

NO, non è la solita cosa da incontrare, tuttavia ci sono sempre alcune eccezioni.

L'esperto di domini può costruire diagrammi UML per catturare i processi di business e gli attori coinvolti in esso. Questo probabilmente sarebbe il miglior documento utile che possono essere pronti per l'architetto del progetto e l'intero team. Perché, avere un documento di documentazione di 80-150 pagine è difficile da comprendere e visualizzare leggendo. In altre parole, il flusso di lavoro aziendale, il flusso di dati e i processi decisionali dovrebbero essere acquisiti da quella persona.

Tuttavia, il diagramma di classe dettagliato richiede conoscenze tecniche set di DDD (progettazione basata sul dominio) o Modellazione orientata agli oggetti con una buona comprensione di Diagramma di classe .

Ci sono un paio di cose nella descrizione dello scenario che non mi fa bene.

• I diagrammi di classe stanno acquisendo solo una parte della complessità del dominio. Si concentrano sulla struttura statica e ignorano gli aspetti comportamentali. Scommetto che il diagramma di classe assomiglia molto anche a un modello di dati. UML non è intrinsecamente cattivo, ma si concentra solo sul diagramma di classe ... lo è.
• "Devono solo implementare il modello" ... :-( ciò che sembra terribilmente sbagliato è che probabilmente manca la conversazione attorno al modello di dominio. Driven Design implica un processo di profonda comprensione condivisa del dominio e la situazione che stai descrivendo sta consentendo agli sviluppatori di codificare senza comprendere il dominio.

Che tipo di modellizzazione dovrebbe usare? Il processo di creazione di un modello dovrebbe essere collaborativo , nel senso che dovrebbe esserci una conversazione e 2-4 persone che disegnano modelli su una lavagna, o che li schizzano su un pezzo di carta o che scrivono storie di utenti, o rapidamente test di codifica (normalmente in un ciclo di feedback rapido). In questo modo, la modellazione non è il dovere di una singola persona. Di conseguenza, la tecnica di modellazione utilizzata dovrebbe essere quella che consente un dialogo migliore, ovvero una comprensione condivisa e la massima quantità di feedback dall'esperto del dominio.

Personalmente ho avuto esperienze positive concentrando le esplorazioni di dominio sul flusso di Eventi di dominio piuttosto che sulla struttura statica delle classi. I modelli tendono ad essere completamente comportamentali, consentendo una comprensione più rapida dell'intero quadro.

I modelli UML (e modelli ERD) hanno tipi. Il tipo concettuale (tipo logico) e il tipo fisico. Il tipo fisico è ciò che viene sintonizzato e implementato. Il modello fisico è guidato dal modello concettuale. UML offre al modellatore la possibilità di specificare grandi dettagli in modo conciso ed è utile per entrambi i tipi di modelli.

Se il modellatore sa cosa stanno facendo, il modello prodotto potrebbe rappresentare una specifica corretta. Se quella specifica è qualificata per essere un modello fisico o no, beh, questa è una storia diversa e dipende da diversi fattori.

Quando si crea un modello logico, la purezza dei requisiti catturati può essere accidentalmente sacrificata. Il modellatore può produrre un modello logico non puro quando lui / lei documenta i requisiti dell'utente nel modello logico, ad esempio, quando risolve una relazione m-m. Sebbene valido, il requisito originale è ora perso a meno che la nuova classe risultante sia ben documentata. Esistono molte situazioni simili che potrebbero comportare specifiche non tracciabili come l'assunzione delle chiavi primarie. L'altra cosa è che gli utenti, in generale, potrebbero non essere in grado di rivedere il diagramma UML. Quindi il diagramma UML non può sostituire la documentazione delle specifiche dei requisiti utente. Ciò si traduce in più lavoro in corso.

Per riassumere, puoi fare in modo che i modelli logici acquisiscano i requisiti, ma dovresti:

1. Avere uno standard concordato per documentare i requisiti utente all'interno del progetto.

2. Identifica chiaramente ruoli e responsabilità nel progetto.

3. Differenzia i requisiti che raccolgono i risultati dalla progettazione fisica.

4. Verifica che i requisiti degli utenti siano tracciabili e che gli utenti possano verificare ciò che hanno detto all'analista di business.