Il principiante si è preoccupato dello strumento CASE

Ho avuto un successo misto con gli strumenti CASE. Sono d'accordo sul fatto che dovresti avere dei dubbi sul risparmio di tempo in questione.

L'unico punto in cui funzionava bene era un dispositivo incorporato: lo abbiamo sviluppato in Rhapsody (proveniva da I-Logix, poi da Telelogic, poi da IBM). La stessa funzionalità è stata trasferita da un dispositivo ThreadX a un dispositivo VxWorks a un dispositivo Linux con una buona velocità, anche se ciò potrebbe essere dovuto al framework "agnostico della piattaforma" di Rhapsody piuttosto che a CASE.

Say I have a UML model which I built a VS solution from. Now, I want to rename a class method to something else; will this mean having to update the UML model first and then rebuilding the code? Is this how case tools normally work?

Non c'è "Normalmente". C'è ingegneria unidirezionale - diagramma per codice. C'è un ciclo di lavoro di andata e ritorno - diagramma per reindirizzare al diagramma per ulteriori modifiche.

I like the Domain Driven Design way of project structure - Infrstructure, Services, Model, etc. I doubt very much this tool will do that.

Perché ne dubiti? La maggior parte degli strumenti UML e CASE descrive questa architettura a strati molto, molto bene.

I'm concerned that this tool's data layer code might not be a nice to integrate in the UoW pattern, repositories, etc. This I will need to verify when I get a closer look at the generated code.

Buon approccio. I framework hanno grandi vantaggi rispetto agli strumenti. Attenersi al framework più dello strumento.

I like to use TDD/BDD for building my code, and using a CASE tool looks like it will make this difficult.

Perchè lo dici? Si documentano le informazioni BDD nello strumento e si genera del codice.

Scrivi casi di test e verifica il codice. I test falliscono, quindi aggiusti il diagramma e correggi il codice.

Sembra che lo strumento CASE possa farlo molto bene.

Il problema con la programmazione attraverso le immagini è il problema della "densità".

È più difficile mettere i dettagli del livello della linea di codice in un'immagine piuttosto che nel testo.

Il testo è denso, ma manca di panoramiche visive.

La programmazione in Immagini è sparsa ma offre una buona panoramica.

Per alcune classi di problemi, può essere efficace. Non saprai se il tuo problema è il punto debole della programmazione in immagini finché non lo provi.

"CASE" è una parola di quattro lettere. Se stai cercando argomenti contrari, ti consiglio i primi due capitoli di UML Distilled di Martin Fowler.

Dicofidatideltuoistintosuquesto.Ilpericoloèchetupossacostruireunprogettousandoqualchemostruosità,ediventaunincubodimanutenzione.

eta:laragioneprincipaleperusareglistrumentiCASEèrenderelacomunicazione/documentazionepiùsemplice*,nonperrisparmiaretemponellosviluppodell'applicazione.

*validoperalcunedefinizionidi"più semplice".

Sono molto scettico sugli strumenti CASE e sulla generazione di codice grafico in generale. Ho visto molti strumenti CASE arrivare con molto clamore, solo per essere in gran parte abbandonati. Hanno un bell'aspetto nelle demo per la gestione non tecnica, ma la demo mostra solo la produzione iniziale di un'applicazione banale. Per costruire un sistema reale, tutti i requisiti utente devono essere rappresentati in una lingua. L'uso di uno strumento CASE non riduce la complessità dei requisiti. Tutto ciò che uno strumento CASE può fare è fornire un linguaggio diverso per la creazione del sistema: un linguaggio proprietario minimamente testato con documentazione limitata e una piccola comunità di utenti.

Spesso il tono di vendita è che tutti gli oggetti, lo schema e altri artefatti possono essere generati da un singolo diagramma. Ma la duplicazione tra questi artefatti non dovrebbe essere presente, perché la lingua e il quadro sono insufficientemente potenti.

Usando il testo, possiamo sia consegnare che ricevere informazioni molto più rapidamente di quanto possiamo tramite i diagrammi. Utilizzare uno strumento CASE per creare software è come provare a scrivere un romanzo a figura intera in forma di fumetto.

Ho avuto un successo misto.

Nella mia esperienza, la maggior parte degli strumenti CASE va bene in una direzione: dal modello al codice in un colpo solo. Tendono ad essere peggio nel mantenere i due sincronizzati. Se stai utilizzando qualcosa di non standard da un piccolo venditore per un dominio specifico, è più probabile che accada "incidenti".

La mia esperienza è anche che, se sono utili, sono utili sia in casi piccoli che in casi più grandi. Se stanno offrendo un processo, perché non giocare con esso per mezz'ora, generare un modello simile in linea di principio a quello che stai cercando di fare, quindi apportare modifiche su entrambi i lati e vedere cosa succede?

Ho avuto lo stesso problema perché UML stava sprecando il mio tempo e ritardando il mio progetto non appena il codice generato doveva essere cambiato. Sono passato a Omondo e non ho più questo problema. EclipseUML Omondo funziona solo con Java, questo non è uno strumento MDA ma fa quello che dice.