Strumenti (migliori pratiche?) Per lo sviluppo guidato da modelli?

StackOverflow https://stackoverflow.com/questions/262279

Domanda

Sviluppo di software guidato da modelli.

A quanto ho capito, aumenta il livello di astrazione del progetto per riflettere meglio il dominio in cui il software tenterà di eseguire. Questo è molto da dire in una sola frase.

La comunicazione tra gli esperti del dominio (cliente) e gli sviluppatori è cruciale per far funzionare questa metodologia. Quello che voglio sapere è se esiste una suite di strumenti o un insieme di migliori pratiche che aiuteranno nella spinta iniziale di MDSD? Una volta definito il dominio, che ne dici di mappare quel modello su un ORM (o qualsiasi altra cosa)?

Mi sto solo immergendo nel regno di MDSD e DSL in modo da valutare eventuali idee o commenti costruttivi.

È stato utile?

Soluzione

Se stai sviluppando su piattaforme Microsoft, potresti provare anche Oslo. C'è una bella panoramica qui: http: // www.pluralsight.com/community/blogs/aaron/archive/2008/11/03/introducing-quot-oslo-quot.aspx

Ecco un sacco di link da Chris Sells: http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic= 2197

Non sono ancora pronto per equiparare Domain Driven Design a Model Drive Development.

Potresti anche voler dare un'occhiata a Model Driven Architecture (OMG MDA) per una prospettiva, anche se probabilmente non c'è molto da fare sul tuo.

Un grosso problema in Model-driven-tutto ha a che fare con la provenienza delle competenze che derivano dalle implementazioni dai modelli e dal livello di manutenzione (e debugging). Il mio test sui libri disponibili sarebbe come rendere comprensibile la pipeline e quanto bene si possa capire il percorso dalla modellazione alla distribuzione e viceversa.

Altri suggerimenti

se stai programmando in .net dovresti leggere " Applicare design e schemi basati su dominio " di Jimmy Nielsson. Ha anche una sezione su ORM (NHibernate), SOA e iniezione di dipendenza.

In ogni caso dovresti dare un'occhiata a " Domain Driven Design " di Eric Evans. È un classico in cui è possibile trovare informazioni preziose su modelli e best practice per la progettazione guidata dal dominio

Dichiarazione di non responsabilità: sono uno sviluppatore di applicazioni aziendali. La seguente visione è certamente modellata dalle mie esperienze in trincee dell'IT aziendale. Sono consapevole che esistono altri settori di sviluppo del software. Soprattutto nello sviluppo di sistemi industriali e / o integrati il ??mondo potrebbe apparire diverso.

Penso che MDSD sia ancora troppo legato alla generazione del codice.

La generazione del codice è utile solo quando il codice contiene molto rumore e / o è molto ripetitivo. In altre parole, quando il tuo codice non può concentrarsi principalmente sulla complessità essenziale, ma è inquinato da complessità accidentale.

A mio avviso, la tendenza nelle attuali piattaforme e framework è esattamente quella di rimuovere la complessità accidentale e lasciare che il codice dell'applicazione si concentri sulla complessità essenziale.

Quindi queste nuove piattaforme / framework tolgono molto vento dalle vele del movimento MDSD.

Le DSL (testuali) sono un'altra tendenza che cerca di consentire il solo focus sull'essenziale complessità. Sebbene le DSL possano essere utilizzate come fonte per la generazione di codice, non sono principalmente legate alla generazione di codice. I DSL (in particolare i DSL interni) fondamentalmente lo lasciano aperto per essere interpretato / eseguito in fase di esecuzione. [la generazione del codice di runtime è nel mezzo].

Quindi, anche se i DSL sono spesso citati insieme a MDSD, penso che siano davvero un'alternativa a MDSD. E dato l'attuale clamore, prendono anche lo slancio dal movimento MDSD.

Se hai raggiunto l'obiettivo di rimuovere definitivamente la complessità accidentale dal tuo codice (so che questo è fittizio), sei arrivato a un modello testuale del tuo problema aziendale. Questo non può essere ulteriormente semplificato!

Le caselle e i diagrammi piacevoli non offrono un'altra semplificazione o elevazione del livello di astrazione! Possono essere utili per la visualizzazione, ma anche questo è discutibile. Un'immagine non è sempre la migliore rappresentazione per comprendere la complessità!

Inoltre, lo stato attuale degli strumenti coinvolti in MDSD aggiunge un altro livello di complessità accidentale (pensate: sincronizzazione, diffusione / fusione, refactoring ...) che sostanzialmente annulla l'obiettivo finale della semplificazione!

Guarda il seguente modello ActiveRecord, come illustrazione della mia teoria: 

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

Non penso che questo possa essere più semplificato. Anche qualsiasi rappresentazione grafica con caselle e linee non sarebbe una semplificazione e non offrirebbe più comodità (pensate a layout, refactoring, ricerca, diffing ...).

L'MDD può essere davvero complesso o relativamente semplice.

Se vuoi automatizzare la trasformazione dai tuoi vari modelli (ad esempio in UML) per programmare e fare ingegneria di andata e ritorno e tutto il resto, puoi ottenere alcuni strumenti piuttosto fantasiosi.

o

Puoi disegnare i modelli e costruire il codice più o meno a mano, usando una trasformazione unidirezionale (da modello a codice).

L'idea di costruire prima un modello è una best practice consolidata. Viene spesso chiamato " design " ;. I problemi sorgono quando le persone confondono il design con le specifiche. Il modello di ciò che sarà costruito non è una specifica di programmazione. È un'astrazione che può essere utilizzata per valutare la correttezza, definire casi di test, scrivere specifiche, ecc.

Non devi modellare tutto. Puoi avviare MDD disponendo di un modello di dati, indipendente da qualsiasi implementazione specifica.

  1. Disegni il tuo modello usando UML.

  2. L'UML viene trasformato in definizioni di classe.

  3. Si utilizza un livello ORM (o ODBMS) per mappare i propri modelli su un tipo di archiviazione.

Non hai bisogno di molto di più di questo. Quello che devi fare è concentrarti sull'ottenere il modello prima di affrontare troppi altri problemi.

I problemi di solito derivano da tutti i tipi di ottimizzazione prematura che si verificano durante lo sviluppo del software. I primi passi nel design fisico RDBMS. I primi passi nella progettazione di pagine Web e l'utilizzo di questo per guidare il modello di dati. I primi passi nella definizione dell'architettura del server e nell'allocazione dell'archiviazione.

Dovresti leggere questo eccellente documento sulle migliori pratiche MDSD, da Markus Voelter: http: //www.jot.fm/issues/issue_2009_09/column6.pdf

Per quanto riguarda l'opzione MDSD / DSL, l'ecosistema EMF ( https://www.eclipse.org / modelling / emf / ) fornisce molti elementi utili:

  • implementare metamodelli ed editor di modelli (EMF)
  • implementa gli editor di modelli (EMF, Sirius, Xtext ...)
  • gestire la collaborazione e la scalabilità (EMF-Transaction, CDO)
  • implementa le regole di validazione del modello (EMF-Validation)
  • implementare generatori di codice (Acceleo, Xtend / Xpand, Mwe ...)
  • implementa generatori di documenti (pxDoc, m2doc ...)

Un'opzione interessante per ridurre l'investimento in strumenti può essere anche l'uso di un modellatore UML estensibile e definire i propri profili UML e strumenti personalizzati in cima al modellatore riutilizzato (l'elenco precedente è ancora adeguato se il tuo modellatore UML è basato sull'implementazione di UML2 / EMF).

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top