Comment concevoir et concevoir une application web Java/Java EE? [fermé]

Il y a plusieurs choses dont vous aurez besoin pour les documents de conception d'architecture. Pas une tâche facile, mais des accessoires pour saisir l'occasion. Comme il s'agit d'une si grande question, j'espère que ces liens peuvent vous aider à démarrer et que vous pouvez affiner les questions après vous être mouillé les pieds.

Méthodologie

La méthodologie que vous utilisez affectera les tâches que vous effectuez en premier. Waterfall est une méthodologie populaire mais obsolète. Une méthodologie plus récente est Agile qui a plusieurs visages. Mon le favori estScrum Agile pour le développement de logiciels de toute taille.

Les Diagrammes de

Les diagrammes sont l'un des moyens les plus puissants de représenter le système dans son ensemble et en tant que composants individuels. Le type de diagrammes que vous créez dépend du système. Il existe généralement des Diagrammes de Structure, des Diagrammes de comportement, des Diagrammes d'interaction et des tonnes d'autres. Ces diagrammes montrent les pièces du système dans son ensemble, chaque disposition physique des composants et / ou disposition logique, flux de communication, flux de procédure, etc..

Documentation

La documentation est comme ça sonne, les documents et les documents qui ont des descriptions de projet, la Portée, les cas d'utilisateur, les diagrammes de séquence et tout autre document qui décrit le projet ou des éléments du projet.

Parcourez le site de modélisation Agile qui pousse à la modélisation "juste assez". Ils ont d'excellentes directives, y compris un "processus de modélisation agile" complet, de la collecte des exigences à conception/développement.

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

En ce qui concerne les outils, j'aime le Paradigme Visuel. C'est relativement peu coûteux (comparé à d'autres outils). Il existe une variété de outils de modélisation gratuits (google est votre ami), mais aucun ne se compare à Visual Paradigm, et pour peu que cela coûte, cela en vaut la peine. Si mon employeur n'avait pas l'argent pour cela, je l'achèterais moi-même... :)

Jetez un oeil à l'architecture propre de Robert Martin (alias Oncle Bob). Voici un aperçu rapide. En utilisant cette approche, vous serez capable de reporter des détails tels que Spring ou Hibernate à une date ultérieure et vous concentrerez davantage sur la logique métier. Ou même migrer de Spring vers Java EE sans toucher à la logique de votre entreprise et de votre application. Vous obtiendrez également une application testable conforme aux principes SOLIDES, sans trop d'effort supplémentaire.

J'ai juste créé une application de cette façon et je dois dire que je suis très heureux avec elle. Je pourrais facilement le porter sur une application de bureau ou mobile, ou échanger le module de stockage. Détails en fonction de la politique va un long chemin. Il favorise également la réflexion de manière API et, lorsqu'il est appliqué correctement, rend vos modules très réutilisables.

Martin va jusqu'à dire que les détails comme les frameworks sont ennuyeux et ne font pas partie de votre architecture. Je pense qu'ils appartiennent à l'architecture, mais juste à un autre niveau. Souvent, vous voulez inclure des frameworks à un stade précoce pour être en mesure de produire une mince tranche d'une application de travail à démo à vos utilisateurs. Ou quand vous connaissez vos cadres à l'avance et qu'il n'y a pas de discussion à leur sujet, comme dans mon cas. Mais vous pouvez le considérer comme des architectures logicielles distinctes, lorsqu'elles sont combinées ensemble, créez votre architecture d'application.

Plus de détails

1. Avant de vous lancer dans le codage, réduisez les exigences de l'entreprise. Créez une liste complète des fonctionnalités demandées, des exemples de captures d'écran (si disponibles), des diagrammes de cas d'utilisation, des règles métier, etc. en tant que document de spécification fonctionnelle. C'est la phase où les analystes commerciaux et les développeurs poseront des questions sur les exigences d'interface utilisateur, les exigences d'intégration de niveau de données, les cas d'utilisation, etc. Priorisez également les fonctionnalités en fonction de l'entreprise objectifs, délais et itérations requis pour la mise en œuvre.

2. Préparer un document de spécification technique basé sur la spécification fonctionnelle. Le document de spécification technique devrait couvrir: Objet du document: par exemple, ce document mettra l'accent sur la fonctionnalité du service à la clientèle. Aperçu: Cette section couvre essentiellement les informations générales, la portée, les inclusions et/ou exclusions, les documents référencés, etc. Architecture de base: discute ou référence de base document d'architecture. Répond à des questions comme Va-t-il évoluer? Cette performance-elle être améliorée? Est-il extensible et/ou maintenable? Existe-il des problèmes de sécurité? Décrivez les tranches verticales à utiliser dans les premières itérations et les concepts à prouver par chaque tranche. Etc. Par exemple, qui MVC [modèle 1, modèle 2, etc] paradigmes devrions-nous utiliser? Devrions-nous utiliser Struts, JSF et Spring MVC, etc. ou construire notre propre framework? Devrions-nous utiliser un délégué commercial pour découpler le niveau intermédiaire avec le client tier? Devrions-nous utiliser AOP (Aspect Oriented Programming) ? Devrions-nous utiliser l'injection de dépendance? Devrions-nous utiliser des annotations? Avons-nous besoin d'internationalisation? Etc. Hypothèses, Dépendances, Risques et problèmes: mettez en évidence toutes les hypothèses, dépendances, risques et problèmes. Par exemple, énumérez tous les risques que vous pouvez identifier. Concevoir des alternatives pour chaque exigence fonctionnelle clé. Discutez également pourquoi une alternative de conception particulière a été choisie par rapport aux autres. Ce processus encouragera les développeurs à analyser les alternatives de conception possibles sans avoir à sauter sur la solution évidente, qui pourrait ne pas toujours être la meilleure. Logique de traitement: discutez de la logique de traitement pour le niveau client, le niveau intermédiaire et le niveau de données. Où ajouter des diagrammes de flux de processus. Ajoutez toutes les conditions de prétraitement et / ou de post-traitement. Diagrammes UML pour communiquer la conception aux autres développeurs, concepteurs de solutions, architectes, etc. Habituellement, des diagrammes de classe et des diagrammes de séquence sont requis. Les autres des diagrammes peuvent être ajoutés pour tous les cas particuliers. Diagramme de diagramme d'état: utile pour décrire le comportement d'un objet dans plusieurs cas d'utilisation Diagramme d'activité: utile pour exprimer des opérations complexes. Soutient et encourage les comportements parallèles. Le diagramme de diagramme d'activité et d'état est bénéfique pour la modélisation de flux de travail avec la programmation multithread. Diagrammes de collaboration et de séquence: Utilisez un diagramme de collaboration ou de séquence lorsque vous souhaitez examiner le comportement de plusieurs objets dans un seul cas d'utilisation. Si vous souhaitez examiner un seul objet dans plusieurs cas d'utilisation, utilisez le graphique d'état. Diagrammes d'objets: Les diagrammes d'objets affichent des instances au lieu de classes. Ils sont utiles pour expliquer en détail certains objets compliqués, tels que la mise en évidence de relations récursives. Répertoriez les noms de paquet, les noms de classe, les noms de base de données et les noms de table avec une brève description de leur responsabilité sous forme de tableau.

3. Préparer un document de normes de codage pour toute l'équipe afin de promouvoir la cohérence et l'efficacité. Certaines pratiques de codage peuvent dégrader les performances par exemple: Utilisation inappropriée de la classe String. Utilisez StringBuffer au lieu de String pour les mutations intensives de calcul. Code en termes d'interface. Par exemple, vous pouvez décider que LinkedList est le meilleur choix pour une application, mais ensuite décider ArrayList pourrait être un meilleur choix. Mauvaise approche pour la liste ArrayList = nouvelle liste ArrayList(); Bonne approche de la liste List = new ArrayList ( 100); La capacité d'un collection appropriée (par exemple ArrayList, HashMap, etc.). Pour promouvoir la cohérence, définissez des normes pour les noms de variables, les noms de méthodes, l'utilisation de la journalisation, les positions des accolades, etc.
4. Préparer un document de revue de code et des modèles pour toute l'équipe. Examinons certains des éléments que la révision du code devrait couvrir: Déclaration de variable appropriée: par exemple, instance par rapport aux variables statiques, constantes, etc. Problèmes de performances: par exemple, utilisez ArrayList, HashMap, etc. au lieu de Vector, Hashtable quand il n'y en a pas fil problème de sécurité. Problèmes de mémoire: par exemple, instanciation incorrecte d'objets au lieu de réutilisation d'objets et de mise en commun d'objets, ne pas fermer de ressource précieuse dans un bloc final, etc. Problèmes de sécurité des threads: par exemple, les classes d'API Java telles que SimpleDateFormat, Calendar, DecimalFormat, etc. ne sont pas thread safe, déclarer des variables dans JSP n'est pas thread safe, stocker des informations d'état dans la classe d'action Struts ou le servlet multithread n'est pas thread safe. Gestion des erreurs: par exemple, Relancer l'exception sans imbriquer l'original exception, méthodes EJB ne lançant pas d'exception EJB pour les exceptions système,etc. Utilisation de normes de codage: par exemple, ne pas utiliser de cadres, de système.est utilisé à la place de log4j etc. Problèmes de conception: Pas de réutilisation du code, pas de séparation claire des responsabilités, utilisation invalide de l'héritage pour obtenir la réutilisation des méthodes, servlets effectuant un accès direct JDBC au lieu d'utiliser des classes DAO (Data Access Objects), code HTML dans les classes Struts action ou servlet, servlets utilisés comme classes utilitaires plutôt que comme contrôleur de flux etc. Documentation du code: par exemple Pas de commentaires, pas de fichiers d'en-tête, etc. Bogues: par exemple, Appeler setAutoCommit dans une transaction gérée par conteneur, binaire OU " | "utilisé au lieu de logique OU"|/", en s'appuyant sur la référence de passage dans les appels distants EJB, ResultSet n'étant pas fermé sur les exceptions, les méthodes EJB ne lançant pas EJBException pour les exceptions système, etc.
5. Préparer des documents de lignes directrices facultatives supplémentaires selon les exigences à partager par l'équipe. Cela favorisera la cohérence et les normes. Pour exemple: Directives pour la mise en place de l'environnement de développement J2EE. Lignes directrices pour le système de contrôle de version (CVS, VSS, etc.). Directives pour les étapes de déploiement, les paramètres d'environnement, les cibles ant, etc. Lignes directrices pour la modélisation des données (toutes les normes de l'entreprise). Lignes directrices pour la gestion des erreurs. Lignes directrices pour la conception de l'interface utilisateur. Document d'aperçu du projet, document de processus de développement logiciel, etc.

Il y a un bon article de blog par @tom sur reflectoring.io j'ai lu récemment qui peut vous aider. Il m'a aidé!

Une liste de contrôle pour la mise en place d'une architecture logicielle basée sur Java

Voici la liste des sujets de haut niveau discutés,

• Style d'architecture
• Problèmes de back-end
• Préoccupations Frontend
• Opérations Concerne
• Problèmes de développement

Merci

J'ai édité un nouveau livre sur Spring, Hibernate et Data Modeling qui répondra à votre question sur l'aspect design d'une application web Java EE. En règle générale, une application Web Java EE comporte 5 niveaux: client, présentation, service commercial, accès aux données et ressource(entité). Le livre se concentre sur la façon de concevoir et de développer chacun de ces niveaux en prenant des exemples de toutes les relations de modélisation de données à l'aide de Spring et Hibernate. En téléchargement une application Web entière est donnée où vous trouverez informations sur la gestion de chaque relation de scénario de modélisation de données.

Regardons une entité autonome simple. Afin de gérer l'entité, des méthodes telles que créer, lire, mettre à jour, supprimer et trouver tous les enregistrements doivent être conçues. Donc, si nous allons de bas en haut, la création d'entité forme la première étape. Ensuite, nous examinons le référentiel qui a des méthodes décrites ci-dessus. Plus loin vient le niveau de service commercial, puis le contrôleur REST Spring qui est basé sur JSON. La tâche restante implique coder la page JSP et les appels jQuery AJAX au contrôleur REST.

Vous pouvez trouver plus d'informations sur le livre ici