Come progettare e progettare un'applicazione web Java/Java EE? [chiuso]

Ci sono diverse cose che ti servono per i documenti di progettazione dell'architettura. Non è un compito facile, ma puntelli a cogliere l'occasione. Poiché questa è una domanda così grande, speriamo che questi link possano iniziare e che tu possa perfezionare le domande dopo aver bagnato i piedi.

Metodologia

La metodologia che usi influenzerà le attività che svolgi per prime. Waterfall è una metodologia popolare ma obsoleta. Una metodologia più recente è Agile che ha diverse facce. Mio preferito è Scrum Agile per lo sviluppo di software di qualsiasi dimensione.

Diagrammi

Diagrammi sono uno dei modi più potenti per rappresentare il sistema nel suo complesso e come singoli componenti. Il tipo di diagrammi creati dipende dal sistema. Di solito ci sono diagrammi di struttura, diagrammi di comportamento, diagrammi di interazione e tonnellate di altri. Questi diagrammi mostrano i pezzi del sistema nel suo complesso, ogni layout fisico componenti e / o layout logico, flusso di comunicazione, flusso di procedura, ecc..

Documentazione

La documentazione è proprio come sembra, documenti e documenti che hanno descrizioni di progetto, Ambito, casi utente, diagrammi di sequenza e qualsiasi altro documento che descrive il progetto o parti del progetto.

Esaminare il sito di modellazione agile che spinge per la modellazione "appena sufficiente". Hanno alcune grandi linee guida tra cui un "processo di modellazione agile" completo dalla raccolta dei requisiti a progettazione / sviluppo.

Http://www.agilemodeling.com /

Http://www.agilemodeling.com/essays/amdd.htm

Http://www.agilemodeling.com/essays/agileArchitecture.htm

Http://www.agilemodeling.com/essays/agileAnalysis.htm

Http://www.agilemodeling.com/essays/agileDesign.htm

Per quanto riguarda gli strumenti, amo il paradigma visivo. È relativamente economico (rispetto ad altri strumenti). Ci sono una varietà di strumenti di modellazione gratuiti (Google è tuo amico), ma nessuno si confronta con il Paradigma visivo, e per un po ' che costa, ne vale la pena. Se il mio datore di lavoro non pagasse i soldi, lo comprerei da solo... :)

Dai un'occhiata all'architettura pulita di Robert Martin (aka Uncle Bob). Ecco una rapida panoramica. Usando questo approccio, sarai in grado di rinviare dettagli come Spring o Hibernate a un secondo momento e concentrarti maggiormente sulla logica di business. O anche migrare da Spring a Java EE senza toccare la logica aziendale e applicativa. Avrai anche un'applicazione testabile conforme ai principi SOLID, senza troppi sforzi aggiuntivi.

Ho appena creato un'applicazione in questo modo e devo dire che sono molto felice con esso. Potrei facilmente portarlo su un'applicazione desktop o mobile o scambiare il modulo di archiviazione. Dettagli a seconda della politica va un lungo cammino. Promuove anche il pensiero in un modo API e, se applicato correttamente, rende i moduli molto riutilizzabili.

Martin si spinge fino a dire che dettagli come i framework sono fastidiosi e non fanno parte della tua architettura. Penso che appartengano all'architettura, ma solo a un altro livello. Spesso si desidera includere framework in una fase iniziale per essere in grado di produrre una fetta sottile di un'applicazione funzionante da demo ai propri utenti. O quando conosci i tuoi quadri in anticipo e non c'è discussione su di loro, come nel mio caso. Ma potresti considerarlo come architetture software separate, quando combinate insieme creano l'architettura dell'applicazione.

Maggiori dettagli

1. Prima di intraprendere la codifica ottenere i requisiti di business verso il basso. Crea un elenco completo delle funzionalità richieste, schermate di esempio (se disponibili), diagrammi dei casi d'uso, regole aziendali ecc. Questa è la fase in cui gli analisti aziendali e gli sviluppatori faranno domande sui requisiti dell'interfaccia utente, sui requisiti di integrazione dei livelli di dati, sui casi d'uso, ecc. Anche dare la priorità alle caratteristiche in base al business obiettivi, tempi di esecuzione e iterazioni necessari per l'implementazione.

2. Preparare un documento di specifiche tecniche basato sulla specifica funzionale. Il documento sulle specifiche tecniche dovrebbe riguardare: Scopo del documento: ad esempio, questo documento enfatizzerà la funzionalità del servizio clienti. Panoramica: Questa sezione copre fondamentalmente informazioni di base, ambito, eventuali inclusioni e / o esclusioni, documenti di riferimento, ecc. Architettura di base: discute o fa riferimento alla linea di base documento di architettura. Risponde a domande come Sarà in scala? Questa prestazione può essere migliorata? È estensibile e / o manutenibile? Ci sono problemi di sicurezza? Descrivere le sezioni verticali da utilizzare nelle prime iterazioni e i concetti che devono essere dimostrati da ciascuna sezione. Ecc. Ad esempio quali paradigmi MVC [model-1, model-2 ecc.] dovremmo usare? Dovremmo usare Struts, JSF e Spring MVC ecc. Dovremmo usare un delegato aziendale per disaccoppiare il livello intermedio con il cliente tier? Dovremmo usare AOP (programmazione orientata agli aspetti) ? Dovremmo usare l'iniezione di dipendenza? Dovremmo usare le annotazioni? Abbiamo bisogno di internazionalizzazione? Ecc. Ipotesi, dipendenze, rischi e problemi: evidenziare tutte le ipotesi, dipendenze, rischi e problemi. Ad esempio elenca tutti i rischi che puoi identificare. Progettare alternative per ogni requisito funzionale chiave. Discutere anche il motivo per cui una particolare alternativa di design è stato scelto rispetto agli altri. Questo processo incoraggerà gli sviluppatori analizzare le possibili alternative di progettazione senza dover saltare alla soluzione ovvia, che potrebbe non essere sempre la migliore. Logica di elaborazione: discutere la logica di elaborazione per il livello client, il livello intermedio e il livello dati. Se necessario aggiungere diagrammi di flusso di processo. Aggiungere eventuali condizioni pre-processo e / o condizioni post-processo. Diagrammi UML per comunicare il progetto ai colleghi sviluppatori, progettisti di soluzioni, architetti ecc. Di solito sono necessari diagrammi di classe e diagrammi di sequenza. L'altro diagrammi possono essere aggiunti per eventuali casi particolari. Diagramma grafico di stato: utile per descrivere il comportamento di un oggetto in diversi casi d'uso Diagramma attività: utile per esprimere operazioni complesse. Supporta e incoraggia il comportamento parallelo. Attività e diagramma grafico di stato sono utili per la modellazione del flusso di lavoro con programmazione multi thread. Diagrammi di collaborazione e sequenza: utilizzare un diagramma di collaborazione o sequenza quando si desidera esaminare il comportamento di più oggetti all'interno di un singolo caso d'uso. Se si desidera esaminare un singolo oggetto su più casi d'uso, utilizzare il grafico di stato. Diagrammi oggetto: i diagrammi oggetto mostrano istanze anziché classi. Sono utili per spiegare in dettaglio alcuni oggetti complicati come l'evidenziazione delle relazioni ricorsive. Elencare i nomi dei pacchetti, i nomi delle classi, i nomi dei database e i nomi delle tabelle con una breve descrizione della loro responsabilità in una forma tabellare.

3. Preparare un documento standard di codifica per l'intero team di promuovere coerenza ed efficienza. Alcune pratiche di codifica possono degradare le prestazioni ad esempio: Uso inappropriato della classe String. Usa StringBuffer invece di String per calcolare mutazioni intensive. Codice in termini di interfaccia. Ad esempio, potresti decidere che LinkedList è la scelta migliore per alcune applicazioni, ma in seguito decidere ArrayList potrebbe essere una scelta migliore. Approccio errato di ArrayList list = nuovo ArrayList(); Approccio giusto alla lista lista = nuovo ArrayList(100); Impostare la capacità iniziale di un raccolta appropriata (ad esempio ArrayList, HashMap ecc.). Per promuovere la coerenza, definire gli standard per i nomi delle variabili, i nomi dei metodi,l'uso della registrazione, le posizioni delle parentesi graffe ecc.
4. Preparare un documento di revisione del codice e modelli per l'intero team. Diamo un'occhiata ad alcuni degli elementi che la revisione del codice dovrebbe coprire: Dichiarazione di variabile corretta: ad esempio istanza contro variabili statiche, costanti ecc. Problemi di prestazioni: ad esempio Utilizzare ArrayList, HashMap ecc. filo-problema di sicurezza. Problemi di memoria: ad esempio, istanziazione impropria di oggetti invece di riutilizzo di oggetti e pool di oggetti, non chiusura di risorse preziose in un blocco finale, ecc. Le classi API Java come SimpleDateFormat, Calendar, DecimalFormat ecc. non sono thread safe, dichiarare le variabili in JSP non è thread safe, memorizzare le informazioni sullo stato in Struts action class o servlet multi-threaded non è thread safe. Gestione degli errori: ad esempio, Re-throwing exception senza nesting original eccezione, metodi EJB che non generano eccezioni EJB per eccezioni di sistema, ecc. Uso di standard di codifica: ad esempio non usare framework, Sistema.out è usato al posto di log4j ecc. Problemi di progettazione: nessun riutilizzo del codice, nessuna chiara separazione delle responsabilità, uso non valido dell'ereditarietà per ottenere il riutilizzo del metodo, servlet che eseguono l'accesso diretto JDBC invece di utilizzare classi DAO (Data Access Objects), codice HTML in azioni Struts o classi servlet, servlet utilizzati come classi di utilità piuttosto che come controller di flusso ecc. Documentazione del codice: ad esempio nessun commento, nessun file di intestazione ecc. Chiamata setAutoCommit all'interno di transazioni gestite da container, binario O "|" usato al posto di logico O"//", basandosi su pass-by-reference nelle chiamate remote EJB, ResultSet non chiuso su eccezioni, metodi EJB non gettando EJBException per eccezioni di sistema ecc.
5. Preparare ulteriori documenti guida facoltativi secondo i requisiti che devono essere condivisi dal team. Ciò promuoverà la coerenza e gli standard. Per esempio: Linee guida per la creazione di ambiente di sviluppo J2EE. Linee guida per il sistema di controllo di versione (CVS, VSS, ecc). Linee guida per le fasi di distribuzione, le impostazioni dell'ambiente, gli obiettivi formica ecc. Linee guida per la modellazione dei dati (eventuali standard aziendali). Linee guida per la gestione degli errori. Linee guida per la progettazione dell'interfaccia utente. Documento di panoramica del progetto, documento di processo di sviluppo software ecc.

C'è un buon post sul blog di @tom su reflectoring.io {[2] } Ho letto di recente che può aiutare. Mi ha aiutato!

Una lista di controllo per l'impostazione di un'architettura software basata su Java

Ecco l'elenco degli argomenti di alto livello discussi,

• Stile di architettura
• Preoccupazioni di back-end
• Preoccupazioni di frontend
• Problemi operativi
• Preoccupazioni per lo sviluppo

Grazie

Ho modificato un nuovo libro su Spring, Hibernate e Data Modeling che risponderà alla tua query sull'aspetto di progettazione di un'applicazione Web Java EE. In genere un'applicazione Web Java EE ha 5 livelli: client, presentazione, servizio aziendale, accesso ai dati e risorsa(entità). Il libro si concentra su come progettare e sviluppare ciascuno di questi livelli prendendo esempi di tutte le relazioni di modellazione dei dati utilizzando Spring e Hibernate. Come download viene fornita un'intera applicazione Web dove si troverebbe informazioni sulla gestione di ogni relazione di scenario di modellazione dei dati.

Diamo un'occhiata a una semplice entità autonoma. Per gestire l'entità, devono essere progettati metodi come creare, leggere, aggiornare, eliminare e trovare tutti i record. Quindi, se andiamo dal basso verso l'alto, la creazione dell'entità costituisce il primo passo. Successivamente guardiamo il Repository che ha metodi descritti sopra. Più in alto arriva il livello di servizio aziendale e quindi il controller di riposo a molla che è basato su JSON. Il compito rimanente comporta codifica della pagina JSP e chiamate jQuery AJAX al controller REST.

Puoi trovare maggiori informazioni sul libro qui