Cosa ne pensi dello sviluppo software basato su modelli?

Question

Sono davvero interessato a sapere cosa ne pensi dello sviluppo software basato su modelli per Java e/o .NET.

Fa risparmiare tempo?Migliora la qualità?

Answer 1

Sto utilizzando MDSD in un progetto con IBM Rational Rhapsody per C++.Il modello è abbastanza vicino a UML, quindi non abbiamo realmente un linguaggio specifico del dominio.Ma direi comunque di usare MDSD.Dalla mia esperienza, ci sono molti vantaggi con MDSD:

a) L'utilizzo di MDSD aiuta a portare un'architettura SW a un livello sofisticato.Lavori sempre a un livello molto astratto, pensando al quadro generale.Il software di codifica Cowboy di solito manca di una buona architettura, perché uno sviluppatore è bloccato nei dettagli.Con MDSD, vedo una tendenza nel mio lavoro a risolvere problemi con classi di dimensioni adeguate, modelli carini o semplicemente codice migliore.

b) La documentazione del quadro generale del SW tende ad essere migliore con MDSD.Naturalmente, ci sono strumenti che generano automaticamente un diagramma di classi dal tuo codice.Ma questi diagrammi sono composti da 1000 classi e non si vede l'aspetto che interessa.Con MDSD disegni specificamente un aspetto del sistema e lo stesso diagramma viene utilizzato anche per generare una parte del codice.

c) La modellazione aiuta a gestire la complessità intrinseca del sistema.Direi che alcuni sistemi sono semplicemente troppo complessi per essere costruiti senza il supporto della progettazione assistita da computer.Nessuno progetterebbe una CPU senza l’aiuto di enormi strumenti SW.Usa SW per aiutarti a scrivere SW ancora più complessi.

d) L'uso di MDSD aiuta ad aderire alle linee guida sullo stile di codifica.Non esiste modo migliore per ottenere uno stile di codice coerente che lasciare che il codice venga generato da un set di regole.

Naturalmente ci sono anche alcuni aspetti negativi dell’MDSD:d) Se hai un modello, vuoi che ogni riga di codice provenga da quel modello.E potrebbe essere difficile includere librerie esterne in un progetto.Quindi o convivi con il fatto che il tuo sistema è basato su componenti esterni o reinventi la ruota per inserirlo nel tuo modello.

e) Gli strumenti di modellazione potrebbero soffrire di problemi nell'utilizzo degli strumenti di controllo delle versioni.Il codice sorgente è solitamente più semplice da unire rispetto a un diagramma del modello.Ciò costringe un team a passare dal flusso di lavoro copia-modifica-unione a un flusso di lavoro blocca-modifica-unione.

Answer 2

MDA è un concetto un po’ sovraccarico.A volte significa trasformare UML o un altro tipo di diagrammi in codice eseguibile.Non ho mai visto questo funzionare bene con gli strumenti disponibili al giorno d'oggi.Di solito fa sì che i progetti ottengano risultati molto velocemente e quindi provochino un incubo di manutenzione perché gli strumenti disponibili non supportano realmente grandi team che lavorano su diagrammi visivi e perché le persone iniziano a lavorare sui diagrammi oltre che sul codice generato.

Ho visto qualcosa che somigliava molto al design basato sul dominio chiamato MDA, se intendi che sono assolutamente d'accordo :-)

Answer 3

Ronzio.

Ciò in cui credo, OTOH, è la modellazione in fase di esecuzione.Invece di generare codice, mantieni attivo il modello in fase di esecuzione e lascia che la tua applicazione sia un interprete runtime di questi modelli.

Non so se questo è stato fatto per Java.Per Smalltalk vedere Magritte, che viene utilizzato in Seaside.

Answer 4

Penso che sia preferibile.Questo è ciò che stavo cercando di insinuare questa domanda su MVC-ARS anziché su MVC.L'ARS (Azione/Rappresentazione/Stato) è contenuto nel modello in base alla progettazione e impedisce il sovraccarico del controller o della vista.

Answer 5

Lo sviluppo di software basato su modelli non riguarda solo MDA, esiste una serie di altri approcci tra cui l'approccio, forse più popolare, dei linguaggi specifici del dominio.

Certo, il codice è un modello "a", ma catturare un modello di livello superiore in un DSL è un modo ancora più conciso per esprimere lo stesso intento.La chiave è Sempre generare il codice dal modello anziché consentire la modifica indipendente del codice generato.

Sono disponibili numerosi strumenti e molto materiale pubblicato, inclusi casi di studio, per spiegarti come costruire i tuoi generatori se non sei soddisfatto dell'acquisto di un generatore standard.Probabilmente questo ti dà più controllo rispetto a lavorare con un linguaggio di programmazione generico.

Answer 6

Sembra sicuramente carino, ma devo ancora vederlo implementato in modo praticamente funzionante.

Lo tengo così:Il Codice è il modello.In questo modo il tuo modello e il tuo codice sono sempre aggiornati :-)

Answer 7

Giusto per aggiungere due libri che ho trovato utili per comprendere MDA: come affermato sopra, si tratta di un argomento ampio.

• MDA Distilled - Principi di architettura basata su modelli.(Mellor)
• MDA nella vita reale:Risoluzione dei problemi aziendali con l'architettura basata su modelli (Guttman)

Non è necessario leggere tutto il Guttman per farsi un'idea poiché i casi di studio diventano noiosi, ma l'introduzione è stata piacevole da leggere.

Answer 8

MDA di solito rende difficile l'integrazione delle regole aziendali all'interno del livello lato server, poiché la mappatura della vista del modello è gestita dal codice generato e vengono forniti hook funzionali come risponditori di eventi.

Ancora non ho visto uno strumento MDA così potente come lo erano Forté (o UDS, ora morto) + Express.Immagino che un MDA con le funzionalità Forté più un modello migliore per ottenere un livello di servizio indipendente (come i modelli ActiveRecord o EntityTransactionManager) sarebbe un'app killer per qualsiasi piattaforma.

Il problema con l'applicazione effettiva che mira all'approccio MDA a tre livelli è che questi sono terribilmente difficili da impostare e adattare a requisiti specifici.Basti pensare alle tariffe ABAP e SAP