"Vedi praticamente nessuna traccia di SADT più": parola chiave è "virtualmente". I nostri concetti "moderni" come "coesione" e "accoppiamento" provengono per lo più da SADT [Edward Yourdon-Larry L.Contantine]. Ci sono anche riferimenti interessanti dalla letteratura software moderna alla vecchia letteratura SADT. Ad esempio, Kent Beck, nei suoi Patters attuazione Sezione Bibliografia del libro dice:
Edward Yourdan e Larry Constantine, progettazione strutturata, ... 1979.
Questo libro presenta l'equivalente delle leggi della fisica per il software design e motivi la discussione sugli aspetti economici dello sviluppo. [ Kent Beck, modelli di attuazione]
In che i libri Yourdan e Costantino dice che :
disegno strutturato è l'arte di progettare i componenti di un sistema e interrelazione tra tali componenti nel miglior modo possibile .
E Meilir Page-Jones afferma che:
- progettazione strutturata utilizza strumenti, soprattutto quelli grafici, per rendere i sistemi facilmente comprensibile. [Meilir Pagina-Jones-Guida pratica di Structured Systems Design]
E oggi nello sviluppo di software il nostro obiettivo è ancora lo stesso ...:-)
Perché il mondo ha abbandonato SADT?
Bene, abbiamo più cambiamenti rispetto all'industria della moda :-).
I sistemi che costruiamo oggi e i vincoli sono diversi rispetto a venti o più anni fa. Penso che quando iniziamo a sviluppare più sistemi "orientati ai dati", dove la complessità funzionale è meno preoccupante, le pratiche SADT come Diagrammi della struttura-Diagramma di flusso dei dati "hanno perso" la loro efficienza per alcuni sistemi ... Quindi lo stile orientato agli oggetti viene fornito con il proprio metodologie e rappresentazioni.
Ma i diagrammi di Entity-Relationship (ER) e il concetto di Data Dictionary sono ancora vivi.
Per una vista interessante punto di Yourdon controllare il suo blog: Watching “agile”...
interessante Yourdon rende ancora aggiornamento su strutturati materiali di design. Verificare: Modern Structured Analysis
Cosa ha sostituito SADT?
Beh ... Per i sistemi object oriented ..
Supponiamo di avere disegno guidato la responsabilità [in cui coesione e l'accoppiamento è ancora importante] per la ricerca di migliori componenti e le loro interconnessioni nei sistemi nostri. E UML generalmente ci offre un buon strumento di visione per trovare quei componenti e le relaizioni.
E ora capiamo che lo sviluppo del software è un'attività sperimentale. Dovremmo fare uno sviluppo iterativo e incrementale con requisiti evolutivi.
Sembra non esserci un "metodo" magico in cui possa essere seguito come una "ricevuta" per il successo.
Modeling in generale:
diagrammi-Models sono solo strumenti di pensiero.
Non è realistico per la progettazione di tutto il sistema su carta con UML o altro notations.Actually i nostri veri modelli sono "codice sorgente", che può essere eseguito e testato.
Ci sono alcuni tentativi come MDA (Model Driven Architecture) che cercano di produrre codice eseguibile dai modelli automaticamente: quindi dobbiamo solo modellare il sistema, quindi tutto verrà prodotto automaticamente. Ma ci siamo resi conto che anche questo non è realistico. Per ora è solo un sogno che alcuni venditori di strumenti vendono. Ora il nostro focus è più sulle lingue specifiche del dominio che è più pratico e realistico.
Grazie.Quello che mi manca di più in UML è che mentre è utile per descrivere ciò di cui un sistema "parla", quali parti diverse si vedono l'un l'altro e anche la sequenza di operazioni, ma è piuttosto difficile descrivere lo scopo di un sistema e come si raggiunge questo scopo. Attualmente sto affrontando il problema di descrivere proprio questo, e ho pensato che SADT non sarebbe stata una cattiva metodologia. Tuttavia non ci sono strumenti in giro e dovrei fare tutto il controllo controllando me stesso. –
Tuttavia, gli strumenti CASE presentano sempre limitazioni nella nostra cronologia di sviluppo del software. Molti di loro erano cattivi, e la maggior parte di loro è cattiva. Penso che il metodo che usi sia più importante dei tuoi strumenti. Il progetto è più importante del "metodo": l'obiettivo del metodo è rendere il tuo progetto un successo. le persone sono più importanti del progetto. Come membro del team di progetto dovresti essere felice mentre sviluppi il tuo software e il tuo utente dovrebbe essere felice mentre lo usa –