Come si pianifica l'architettura di un'applicazione prima di scrivere qualsiasi codice? [chiuso]

Una cosa con cui faccio fatica è pianificare l'architettura di un'applicazione prima di scrivere qualsiasi codice.

Non intendo raccogliere requisiti per restringere ciò che l'applicazione deve fare, ma piuttosto pensare in modo efficace a un buon modo per tracciare la classe complessiva, i dati e le strutture di flusso, e iterare quei pensieri in modo da avere un piano credibile di azione in mente prima ancora di aprire l'IDE. Al momento è tutto facile aprire l'IDE, creare un progetto vuoto, iniziare a scrivere bit e bob e lasciare che il design "cresca" da lì.

Immagino che UML sia un modo per farlo, ma non ho esperienza con esso, quindi sembra un po 'nebuloso.

Come si pianifica l'architettura di un'applicazione prima di scrivere qualsiasi codice? Se UML è la strada da percorrere, puoi consigliare un'introduzione concisa e pratica per uno sviluppatore di applicazioni piccole?

Apprezzo il tuo contributo.

Trovo davvero che la prima volta che scrivi su carta o lavagna sia davvero cruciale. Quindi passa a UML se lo desideri, ma niente batte la flessibilità di disegnarlo a mano all'inizio.

Considero quanto segue:

1. cosa dovrebbe fare il sistema, cioè qual è il problema che il sistema sta cercando di risolvere
2. chi è il cliente e quali sono i suoi desideri
3. con cosa il sistema deve integrarsi
4. ci sono aspetti legacy che devono essere considerati
5. quali sono le interruzioni dell'utente
6. eccetera...

Quindi comincio a guardare il sistema come una scatola nera e:

1. quali sono le interazioni che devono avvenire con quella scatola nera
2. quali sono i comportamenti che devono verificarsi all'interno della scatola nera, ovvero cosa deve accadere a quelle interazioni affinché la scatola nera mostri il comportamento desiderato a un livello superiore, ad esempio ricevere ed elaborare i messaggi in arrivo da un sistema di prenotazione, aggiornare un database ecc. .

Quindi questo inizierà a darti una visione del sistema che consiste in varie scatole nere interne, ognuna delle quali può essere ulteriormente scomposta nello stesso modo.

UML è ottimo per rappresentare tale comportamento. Puoi descrivere la maggior parte dei sistemi usando solo due dei tanti componenti di UML, vale a dire:

• diagrammi di classe e
• diagrammi di sequenza.

Potresti aver bisogno anche di diagrammi di attività se c'è un parallelismo nel comportamento che deve essere descritto.

Una buona risorsa per imparare UML è l'eccellente libro "UML Distilled" di Martin Fowler ( link Amazon - disinfettato per gli script kiddie link nazis là fuori (- :). Questo libro offre una rapida occhiata alle parti essenziali di ciascuno dei componenti di UML.

Oh. Quello che ho descritto è più o meno l'approccio di Ivar Jacobson. Jacobson è uno dei tre amigos di OO. Infatti UML è stato inizialmente sviluppato dalle altre due persone che formano i Tre Amigos, Grady Booch e Jim Rumbaugh

Dovresti assolutamente dare un'occhiata a Code Complete di Steve McConnell e in particolare al suo capitolo in regalo sul "Design in Construction"

Puoi scaricarlo dal suo sito web:

http://cc2e.com/File.ashx?cid=336

Se stai sviluppando per .NET, Microsoft ha appena pubblicato (come e-book gratuito!) L' Application Architecture Guide 2.0b1 . Fornisce un sacco di ottime informazioni sulla pianificazione della tua architettura prima di scrivere qualsiasi codice.

Se fossi disperato, mi aspetto che potresti usarne grossi pezzi per architetture non basate su .NET.

Premetto che mi occupo principalmente di sviluppo web in cui gran parte dell'architettura è già decisa in anticipo (WebForms, ora MVC) e la maggior parte dei miei progetti sono ragionevolmente piccoli, sforzi di una sola persona che richiedono meno di un anno. So anche che avrò un ORM e un DAL per gestire rispettivamente il mio oggetto di business e l'interazione dei dati. Recentemente, sono passato a utilizzare LINQ per questo, gran parte del "design" diventa progettazione e mappatura del database tramite il designer DBML.

In genere, lavoro in modo TDD (test driven development). Non passo molto tempo a lavorare sui dettagli architettonici o di design. Raccolgo l'interazione complessiva dell'utente con l'applicazione tramite storie. Uso le storie per elaborare l'interaction design e scoprire i componenti principali dell'applicazione. Eseguo molte lavagne durante questo processo con il cliente, a volte catturando dettagli con una fotocamera digitale se sembrano abbastanza importanti da mantenere la forma del diagramma. Principalmente le mie storie vengono catturate in forma di storia in un wiki. Alla fine, le storie vengono organizzate in versioni e iterazioni.

A questo punto di solito ho un'idea abbastanza buona dell'architettura. Se è complicato o ci sono pezzi insoliti - cose che differiscono dalle mie normali pratiche - o sto lavorando con qualcun altro (non tipico), creerò un diagramma (di nuovo su una lavagna). Lo stesso vale per le interazioni complicate: posso progettare il layout della pagina e scorrere su una lavagna, conservarlo (o catturarlo tramite fotocamera) fino a quando non ho finito con quella sezione. Una volta che ho un'idea generale di dove sto andando e cosa deve essere fatto prima, inizierò a scrivere i test per le prime storie. Di solito, questo dice: "Va bene, per farlo avrò bisogno di queste classi. Inizierò con questo e deve farlo." Quindi inizio allegramente TDDing e l'architettura / design cresce dalle esigenze dell'applicazione.

Periodicamente, mi ritroverò a voler scrivere di nuovo alcuni bit di codice o pensare "questo ha davvero un odore" e rifattorizzerò il mio progetto per rimuovere la duplicazione o sostituire i bit puzzolenti con qualcosa di più elegante. Per lo più, mi preoccupo di ridurre la funzionalità seguendo i buoni principi di progettazione. Trovo che usare schemi conosciuti e prestare attenzione ai buoni principi mentre procedi funzioni abbastanza bene.

http://dn.codegear.com/article/31863

Uso UML e trovo che la guida sia piuttosto utile e facile da leggere. Fammi sapere se hai bisogno di qualcosa di diverso.

UML è una notazione. È un modo per registrare il tuo progetto, ma non (secondo me) per fare un progetto. Se hai bisogno di scrivere delle cose, consiglierei UML, però, non perché sia ​​il "migliore" ma perché è uno standard che altri probabilmente sanno già leggere, e batte inventando il tuo "standard".

Penso che la migliore introduzione a UML sia ancora UML Distilled , di Martin Fowler, perché è conciso, fornisce indicazioni pratiche su dove usarlo e chiarisce che non è necessario acquistare l'intera storia di UML / RUP per farlo essere utile

Fare design è difficile e non può essere catturato in una sola risposta StackOverflow. Sfortunatamente, le mie capacità di progettazione, così come sono, si sono evolute nel corso degli anni e quindi non ho una fonte a cui posso fare riferimento.

Tuttavia, un modello che ho trovato utile è l'analisi della robustezza (google per questo, ma c'è un'introduzione qui ). Se hai i tuoi casi d'uso per ciò che il sistema dovrebbe fare, un modello di dominio di ciò che sono coinvolti, allora ho trovato l'analisi della robustezza uno strumento utile per connettere i due e capire quali devono essere i componenti chiave del sistema .

Ma il miglior consiglio è leggere ampiamente, pensare bene e fare pratica. Non è un'abilità puramente insegnabile, devi davvero farlo.

Non sono abbastanza intelligente da pianificare in anticipo più di un po '. Quando pianifico in anticipo, i miei piani vengono sempre sbagliati, ma ora ho passato n giorni in cattivi piani. Il mio limite sembra essere di circa 15 minuti sulla lavagna.

Fondamentalmente, lavoro il meno possibile per scoprire se sto andando nella giusta direzione.

Guardo il mio progetto alla ricerca di domande critiche: quando A fa B a C, sarà abbastanza veloce per D? In caso contrario, abbiamo bisogno di un design diverso. A ciascuna di queste domande si può rispondere con un picco. Se le punte sembrano buone, allora abbiamo il design ed è ora di espanderlo.

Codice in modo da ottenere un valore reale per il cliente il prima possibile, in modo che un cliente possa dirmi dove devo andare.

Poiché sbaglio sempre le cose, mi affido al refactoring per aiutarmi a metterle a posto. Il refactoring è rischioso, quindi devo scrivere unit test mentre procedo. Scrivere unit test dopo il fatto è difficile a causa dell'accoppiamento, quindi scrivo prima i miei test. Rimanere disciplinato su queste cose è difficile e un cervello diverso vede le cose in modo diverso, quindi mi piace avere un amico che codifica con me. Il mio compagno di programmazione ha un naso, quindi faccio la doccia regolarmente.

Chiamiamolo "Extreme Programming".

"Lavagne bianche, schizzi e post-it sono strumenti di progettazione eccellenti. Strumenti di modellazione complicati tendono a distrarre più che illuminare." Da Practices of an Agile Developer di Venkat Subramaniam e Andy Hunt .

Non sono convinto che possa esserci nienteessere pianificato in anticipo prima dell'attuazione. Ho 10 anni di esperienza, ma è stato solo in 4 aziende (inclusi 2 siti in una società, che erano quasi agli opposti polari), e quasi tutta la mia esperienza è stata in termini di osservazione di colossali cluster ****** ** s si verificano. Sto iniziando a pensare che cose come il refactoring sia davvero il modo migliore per fare le cose, ma allo stesso tempo mi rendo conto che la mia esperienza è limitata e potrei semplicemente reagire a ciò che ho visto. Quello che mi piacerebbe davvero sapere è come ottenere la migliore esperienza in modo da poter arrivare a conclusioni appropriate, ma sembra che non ci siano scorciatoie e richiede solo molto tempo per vedere le persone che fanno le cose sbagliate :(. I mi piacerebbe davvero provare a lavorare in un'azienda in cui le persone fanno le cose per bene (come dimostrano le implementazioni di prodotti di successo),

Mi permetto di differire: UML può essere utilizzato per l'architettura dell'applicazione, ma è più spesso utilizzato per l'architettura tecnica (framework, diagrammi di classe o sequenza, ...), perché è qui che questi diagrammi possono essere più facilmente sincronizzati con lo sviluppo .

L'architettura dell'applicazione si verifica quando si prendono alcune specifiche funzionali (che descrivono la natura ei flussi delle operazioni senza fare ipotesi su un'implementazione futura) e le si trasformano in specifiche tecniche.

Tali specifiche rappresentano le applicazioni necessarie per l' implementazione di alcune esigenze aziendali e funzionali.

Pertanto, se è necessario elaborare diversi portafogli finanziari di grandi dimensioni (specifica funzionale), è possibile determinare che è necessario dividere tale specifica di grandi dimensioni in:

• un dispatcher per assegnare quei calcoli pesanti a diversi server
• un programma di avvio per assicurarsi che tutti i server di calcolo siano attivi e in esecuzione prima di iniziare a elaborare quei portfolio.
• una GUI per poter mostrare cosa sta succedendo.
• un componente "comune" per sviluppare gli algoritmi di portfolio specifici, indipendentemente dal resto dell'architettura dell'applicazione, al fine di facilitare i test unitari, ma anche alcuni test funzionali e di regressione.

Quindi, fondamentalmente, pensare all'architettura dell'applicazione è decidere quale "gruppo di file" è necessario sviluppare in modo coerente (non è possibile sviluppare nello stesso gruppo di file un launcher, una GUI, un dispatcher, ...: essi non sarebbe in grado di evolversi allo stesso ritmo)

Quando l'architettura di un'applicazione è ben definita, ciascuno dei suoi componenti è solitamente un buon candidato per un componente di configurazione , cioè un gruppo di file che può essere versionato come un tutto in un VCS (Version Control System), il che significa che tutti i suoi file saranno etichettati insieme ogni volta che è necessario registrare un'istantanea di quell'applicazione (di nuovo, sarebbe difficile etichettare tutto il sistema, ciascuna delle sue applicazioni non può essere in uno stato stabile allo stesso tempo)

Faccio architettura da un po '. Uso BPML per perfezionare prima il processo aziendale e poi utilizzo UML per acquisire vari dettagli! Il terzo passo generalmente è ERD! Quando avrai finito con BPML e UML, il tuo ERD sarà abbastanza stabile! Nessun piano è perfetto e nessuna astrazione sarà al 100%. Pianifica il refactoring, l'obiettivo è ridurre al minimo il refactoring il più possibile!

Cerco di suddividere il mio pensiero in due aree: una rappresentazione delle cose che cerco di manipolare e cosa intendo farne.

Quando cerco di modellare le cose che sto cercando di manipolare, mi viene in mente una serie di definizioni di articoli distinte: un sito di e-commerce avrà uno SKU, un prodotto, un cliente e così via. Avrò anche alcune cose non materiali con cui sto lavorando: un ordine o una categoria. Una volta che ho tutti i "nomi" nel sistema, creerò un modello di dominio che mostri come questi oggetti sono correlati tra loro: un ordine ha un cliente e più SKU, molti SKU sono raggruppati in un prodotto, quindi sopra.

Questi modelli di dominio possono essere rappresentati come modelli di dominio UML, diagrammi di classe e ERD SQL.

Una volta individuati i nomi del sistema, passo ai verbi, ad esempio le operazioni che ciascuno di questi elementi esegue per eseguire il commit di un ordine. Questi di solito si mappano abbastanza bene per utilizzare i casi dai miei requisiti funzionali: il modo più semplice per esprimerli che ho trovato è la sequenza UML, i diagrammi di attività o di collaborazione o i diagrammi di corsia.

È importante pensare a questo come a un processo iterativo; Farò un piccolo angolo del dominio, quindi lavorerò sulle azioni e poi tornerò indietro. Idealmente avrò tempo per scrivere codice per provare le cose mentre procedo - non vuoi mai che il design vada troppo avanti rispetto all'applicazione. Questo processo di solito è terribile se pensi di costruire l'architettura completa e definitiva per ogni cosa; in realtà, tutto ciò che stai cercando di fare è stabilire le basi di base che il team condividerà in comune durante lo sviluppo. Stai principalmente creando un vocabolario condiviso da utilizzare per i membri del team mentre descrivono il sistema, non stabilendo la legge su come deve essere fatto.

Mi trovo ad avere problemi a pensare completamente a un sistema prima di codificarlo. È troppo facile dare solo un'occhiata superficiale ad alcuni componenti che solo in seguito ti rendi conto che sono molto più complicati di quanto pensavi fossero.

Una soluzione è solo provare davvero tanto. Scrivi UML ovunque. Segui ogni lezione. Pensa a come interagirà con le altre tue classi. Questo è difficile da fare.

Quello che mi piace fare all'inizio è fare una panoramica generale. Non mi piace UML, ma mi piace disegnare diagrammi che ottengano il punto. Quindi comincio a implementarlo. Anche mentre sto solo scrivendo la struttura della classe con metodi vuoti, spesso vedo cose che mi mancavano in precedenza, quindi aggiorno il mio design. Mentre sto codificando, mi renderò conto che devo fare qualcosa di diverso, quindi aggiornerò il mio design. È un processo iterativo . Il concetto di "prima progettare tutto e poi implementarlo" è noto come modello a cascata, e penso che altri abbiano dimostrato che è un cattivo modo di fare software.

Prova Archimate.