Da dove cominciare quando si fa un modello di dominio?

Question

Diciamo che ho fatto una lista di concetti che verranno utilizzate per disegnare il mio modello di dominio. Inoltre, ho un paio di casi d'uso, da cui ho fatto un paio di sistema diagrammi di sequenza.

Quando si disegna il modello di dominio, non so mai da dove iniziare:

1. Progettare il modello come credo che il sistema sia. Questo è, se io sto modellando un corpo umano, comincio con l'aggiunta dei concetti di classe di cuore, cervello, intestino, stomaco, occhi, testa, ecc.
2. Avvia progettando ciò che i casi d'uso hanno bisogno di ottenere fatto. Questo è, se ho un caso d'uso che è circa fare del corpo umano rondine qualcosa, mi piacerebbe prima richiamare i concetti di classe per bocca, gola, Stomatch, intestino, ecc.

L'ordine in cui faccio le cose è irrilevante? Direi che probabilmente sarebbe meglio per cercare di progettare dai concetti caso d'uso, in quanto sono generalmente ciò che si desidera lavorare con, non altri tipi di concetti che, anche se l'aiuto descrivere l'intero sistema ben, gran parte del tempo potrebbe nemmeno essere necessario per il progetto in corso. C'è un altro approccio che non sto prendendo in considerazione qui? Di solito come avvicina a questa?

Grazie

Answer 1

Mi piacerebbe iniziare con un disegno di un diagramma di classe con tutti i rapporti e implementare solo le classi che sono necessari in base ai requisiti della propria applicazione.

È possibile utilizzare un approccio anemico (attributi più getter e setter) per mantenere le cose semplici e di evitare la fase di scrittura logica di business nella stessa fase. Con un modello anemico, la logica sarebbe andato in un corrispondente classe di servizio. In questo modo si può considerare casi d'uso in seguito.

So che alcune persone non apprezzano questo modo di fare le cose ma aiuta con la manutenzione ed evita alcuni problemi di dipendenze.

risposta alla domanda di Elysium divorato seguente :

In termini di analisi, a partire da casi d'uso (cosa) e poi di procedere alla diagramma delle classi (come) suona come una buona regola. Personalmente, mi piacerebbe fare il diagramma di sequenza (quando e chi?) In seguito, come avresti bisogno di sapere tra i quali i processi / oggetti messaggi devono essere inviati.

Al di là che il mio introito su cose è che UML è semplicemente un modo per modellare un sistema / progetto e non una metodologia di per sé (a differenza Merise, RAD, RUP, Scrum, etc.). Non c'è niente di fermare qualcuno partendo con qualsiasi schema, purché abbiano le informazioni sufficienti per completarlo. Infatti, devono essere effettuati simultaneamente poiché ognuno dei diagrammi è una prospettiva diversa dello stesso sistema / progetto.

Quindi, tutto sommato, dipende da come si va su l'analisi. Durante i miei studi mi hanno insegnato l'approccio a cascata rigido, in cui si fa un'analisi completa dall'inizio alla fine prima di produrre un certo codice. Tuttavia, le cose possono essere diverse, in pratica, come l'imperativo potrebbe essere quello di produrre una domanda di lavoro nel minor tempo possibile.

Per esempio, mi è stato introdotto per la metodologia Scrum recentemente per un esercizio che prevede la creazione di un sito web dove le persone possono inviare le loro finzioni. Come c'era un vincolo di tempo e una visione chiara di ciò che dovrebbe essere raggiunto, abbiamo iniziato subito con un diagramma di classe ossa nude per rappresentare il modello di dominio . I casi d'uso sono stati poi dedotte da una serie di schermate finte avevamo prodotta.

Dalla memoria, le classi erano Story, capitolo, l'utente e ad una categoria. Quest'ultima classe è stata gradualmente eliminata a favore di una classe Tag più flessibile. Come ci si può immaginare, il diagramma delle classi completa del progetto esistente sarebbe molto più complessa a causa di applicazione di dominio guidato la progettazione e le specificità del linguaggio di programmazione Java.

Questo approccio potrebbe essere visto come sciatta. Tuttavia, un sito web come questo potrebbe facilmente essere fatto in un paio di settimane con un processo iterativo ed ancora essere ben progettato. Il vantaggio di un processo iterativo ha oltre l'approccio a cascata è che è possibile regolare continuamente i requisiti, come si va. requisiti frequente cambiamento è una realtà, come la gente spesso cambiare le loro menti e la possibilità di produrre un programma di lavoro dopo ogni iterazione permette di rimanere in corsa per così dire.

Naturalmente, quando si sta presentando un progetto a un cliente, un'analisi completa di diagrammi UML e alcune schermate di finte sarebbe preferibile in modo da avere un'idea di quello che stai offrendo. Questo è dove l'UML entra in gioco. Una volta che hai spiegato alcune delle convenzioni visive, un individuo dovrebbe essere in grado di capire gli schemi.

Per finire, se vi trovate in una situazione in cui si sta cercando di determinare ciò che un cliente vuole, è probabilmente una buona idea di costruire gradualmente un questionario si può portare con voi. Intervistare una persona è l'unico modo è possibile determinare quali concetti / funzioni sono realmente necessari per un'applicazione, e si dovrebbe aspettare di tornare al fine di chiarire alcuni aspetti. Un altro suggerimento sarebbe quello di fare qualche ricerca veloce sul web quando si è di fronte ad un soggetto che si importa familiarità con.

Nel vostro example, questo sarebbe quello di passare attraverso le nozioni di base di anatomia. Tra le altre cose, questo vi aiuterà a decidere ciò che il modello dovrebbe contenere e quali granularità dovrebbe avere (cosa dovrebbe essere considerato gruppo di organi? Come precisa ha bisogno di essere? Non solo gli organi devono modellato oppure dovrebbero essere scomposto in loro elettori come tessuti, cellule, la composizione chimica, ecc?).

Answer 2

Sia DDD, o no, mi sento di raccomandare con la determinazione della lingua onnipresente (UL) intervistando il proprietario del prodotto (s). Stabilire la comunicazione in un modo che vi farà e i proprietari del prodotto che parla la stessa lingua non solo aiutanti nella comunicazione, ma essere in grado di discutere il progetto in termini comuni tende ad aiutare il modello di dominio stesso definisce.

Quindi, la mia risposta è sostanzialmente quella di discutere, ascoltare e imparare. Software serve un bisogno. Comprendere il modello dal punto di vista degli esperti getterà le basi solide per l'applicazione.

Answer 3

Credo che il punto di partenza potrebbe essere qualunque cosa si sente logico e confortevole. E 'probabilmente meglio cominciare con i casi d'uso, come ti danno una chiara direzione e gli obiettivi, e vi aiutano a evitare situazioni YAGNI. Dato che si dovrebbe cercare di sviluppare un modello di dominio forte, non dovrebbe importa, come l'intera immagine del dominio è importante.

Answer 4

Vorrei condividere la mia esperienza per questo tipo di situazioni. Di solito inizio con la scrittura test e il codice. E cercare di coprire un capo all'altro caso d'uso. Questo mi dà abbastanza giusta idea circa problema e alla fine ho anche qualcosa di lavorare con me, che posso mostrare caso al mio cliente. Il più delle volte le storie successive costruire in cima a quello precedente, ma succede anche a me che le storie successive richiedono cambiamenti nel modello precedente mi si avvicinò con. Ma questo non mi impatto, come ho già una buona copertura di test. In questo modo mi si avvicinò con il modello che si adatta per il problema attuale, non il modello che mappa il mondo reale.

Answer 5

Si inizia con i requisiti aziendali che possono essere formalizzate o meno. Se formalizzata si usa diagrammi di casi.

Per esempio qui sono diagrammi caso d'uso per un app di e-commerce: http://askuml.com/blog/e-commerce/

http://askuml.com/files/2010 /07/e-commerce-use-case.jpg http://askuml.com/files/2010/07/ e-commerce-uso-case2b.jpg

Da questi casi d'uso, è possibile naturalmente dedurre le entità di business:. Prodotto, categoria di prodotti, carrello della spesa, ... che è iniziare a preparare i diagrammi di classe

Si tratta di buone pratiche in molte metodologie, ma anche questo è solo buon senso e naturale.

Answer 6

Risposta breve

Scegliere un caso d'uso, trarre qualche schema di collaborazione (e un diagramma delle classi) per realizzare il dominio oggetti coinvolti. Concentrato solo su quegli oggetti partecipato al fine di realizzare l'uso caso obiettivo. Scrivere test case TDD per impostare l'aspettativa e gradualmente modellare le vostre classi di dominio per soddisfare le aspettative. TDD è molto utile per capire i comportamenti attesi e aiuta a ottenere il modello di dominio più pulito. Vedrete il vostro evolvere dominio a poco a poco con le aspettative TDD.

Risposta lunga

La mia esperienza personale con DDD non è stato facile. Quello era perché non avevamo basi necessarie in primo luogo. La nostra squadra ha avuto molti punti deboli in diversi settori; requisiti non sono stati catturati correttamente e abbiamo avuto solo un rappresentante cliente che non molto efficiente (non coinvolto) era. Non abbiamo fatto un piano di rilascio adeguato e gli sviluppatori avuto una mancanza di Object Oriented concetti, principi migliori e così via. Il problema principale che abbiamo avuto è stato spendere così tanto tempo a cercare di capire la logica di dominio. Abbiamo delineato molti diagrammi di classe e non abbiamo mai avuto il modello di dominio a destra, così ci siamo fermati a fare questo e scoperto cosa è andato storto. Il problema era che abbiamo cercato troppo difficile da capire la logica di dominio e invece di comunicare che abbiamo fatto Ipotesi sui requisiti. Abbiamo deciso di cambiare il nostro approccio, abbiamo applicato TDD, abbiamo iniziato a scrivere il comportamento previsto e codificato modello il dominio a soddisfare le aspettative del TDD. A volte c'è rimasto bloccato casi di test TDD di scrittura, perché non abbiamo capito il dominio. Abbiamo subito parlato con il rappresentante del cliente e cercato di ottenere più input. Abbiamo cambiato la nostra strategia di rilascio; applicato la metodologia e il rilascio agile frequentemente in modo che abbiamo ottenuto reale feedback da parte dell'utente finale. Tuttavia, necessario per garantire l'aspettativa utente finale è stato fissato al giusto livello. Abbiamo riscritta in base al feedback, e in questo modo il modello di dominio evoluti gradualmente. Successivamente, abbiamo applicato modelli di progettazione per migliorare la riusabilità e manutenibilità. Il mio punto qui è che DDD da sola non può sopravvivere, dobbiamo costruire l'ecosistema che abbraccia il dominio, gli sviluppatori devono avere forti concetti OOP e dobbiamo apprezzare TDD e test di unità. Direi DDD si trova sulla cima di tutte le tecniche e le pratiche di OOP.