Sta definendo ogni metodo / stato per oggetto in una serie di diagrammi UML rappresentativi di MDA in generale?

Question

Sta definendo ogni metodo / stato per oggetto in una serie di diagrammi UML rappresentativi di MDA in generale?

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

5

Attualmente sto lavorando a un progetto in cui utilizziamo un framework che combina la generazione di codice e ORM insieme a UML per sviluppare software. I metodi vengono aggiunti alle classi UML e vengono generati in classi parziali dove "succede qualcosa". Ad esempio, una classe UML "Contenuto" potrebbe avere il metodo DeleteFromFileSystem (void). Quale potrebbe essere implementato in questo modo:

public partial class Content
{
    public void DeleteFromFileSystem()
    {
        File.Delete(...);
    }
}

Tutti i metodi sono progettati in questo modo. Tutto accade in queste gigantesche classi di dominio della bomba logica.

Questo è il modo in cui è fatto di solito MDA o DDD o simili? Per ora la mia impressione di MDA / DDD (che è stata chiamata da higherups) è che stordisce gravemente la mia produttività (tutto deve essere fatto in The Way) e che ostacola il lavoro di manutenzione dal momento che tutta la logica è legata, trincerata, intervallata nel citato bombe gigantesche.

Si prega di astenersi dall'interpretare questo come un rant - Sono solo curioso di sapere se questo è tipico MDA o una sorta di MDA estremo

Aggiorna

Riguardo all'esempio sopra, a mio parere, il contenuto non dovrebbe occuparsi dell'eliminazione come tale. Cosa succede se passiamo dallo storage locale ad Amazon S3, in tal caso dovremmo reimplementare questa funzionalità sparsa su più posti invece di un'unica interfaccia che possiamo fornire una seconda implementazione per.

.net uml mdd

posta Max 08.06.2011 - 16:38

fonte

4 risposte

Leggi altre domande sui tag .net uml mdd

Qual è il termine del settore per i programmi "guadagnare credito per affiliati" nei giochi iPhone / Android / etc? Le chiamate in proxy non funzionano come previsto

score 1 · Answer 1

DDD non richiede che una classe gestisca la propria memoria, infatti DDD ha il concetto di repository per gestire lo storage. Quello che stai facendo è che stai implementando Active Record e legando l'implementazione alla classe, piuttosto che nascondendola dalla classe.

score 0 · Answer 2

Sì, alcuni team modellano fino al livello dell'attributo e forniscono firme dettagliate del metodo. In realtà non seguo la parte della gigantesca bomba logica; c'è una logica inserita nelle classi di dominio che non dovrebbero esserci? L'esempio che fornisci non sembra inappropriato.

score 0 · Answer 3

Non hai bisogno di MDA per quel tipo di generazione di codice dello schema di classe UML. Il codice in tempo reale e la sincronizzazione del modello sono per me più appropriati. La MDA è più un tipo di modellazione di un livello più alto di astrazione e quindi di generazione di codice. Il codice è solo una spinta dall'alto verso il basso. Una volta generato, il codice non ha più alcuna relazione con il modello ed è impossibile tornare indietro. Il codice in tempo reale e la sincronizzazione dei modelli è più semplice e migliore di MDA.

score 0 · Answer 4

Penso che questo sia un problema nel modo in cui i tuoi strumenti generano codice. Se ti capisco bene, ti lamenti sul fatto che gli strumenti creano file sorgente di "classe parziale" per ogni singolo metodo (invece di un file sorgente per classe). Sono d'accordo che questo è piuttosto stupido e rende il risultato difficile da usare e da mantenere, ma questo non è tipico per MDA o DDD. In effetti, uno strumento non potrebbe farlo in altre lingue, ad es. Java, che non ammette file sorgente "di classe parziale".