¿Cómo planifica la arquitectura de una aplicación antes de escribir cualquier código? [cerrado]

Una cosa con la que lucho es planificar la arquitectura de una aplicación antes de escribir cualquier código.

No me refiero a recopilar requisitos para concretar lo que la aplicación debe hacer, sino a pensar de manera eficaz en una buena manera de diseñar la clase general, las estructuras de datos y flujo, e iterar esos pensamientos para tener un plan creíble de acción en mente antes incluso de abrir el IDE. Por el momento, es muy fácil abrir el IDE, crear un proyecto en blanco, comenzar a escribir bits y bobs y dejar que el diseño "crezca" a partir de ahí.

Entiendo que UML es una forma de hacer esto, pero no tengo experiencia con él, por lo que parece un poco nebuloso.

¿Cómo se planea la arquitectura de una aplicación antes de escribir ningún código? Si UML es el camino a seguir, ¿puede recomendar una introducción concisa y práctica para un desarrollador de aplicaciones pequeñas?

Agradezco tu aporte.

Realmente encuentro que escribir en papel o pizarra es realmente crucial. Luego, muévase a UML si lo desea, pero nada supera la flexibilidad de dibujarlo a mano al principio.

Considero lo siguiente:

1. lo que se supone que debe hacer el sistema, es decir, cuál es el problema que el sistema está tratando de resolver
2. quién es el cliente y cuáles son sus deseos
3. con qué tiene que integrarse el sistema
4. ¿Hay algún aspecto heredado que deba tenerse en cuenta?
5. cuáles son las interacciones del usuario
6. etc ...

Luego empiezo a mirar el sistema como una caja negra y:

1. ¿Cuáles son las interacciones que deben ocurrir con esa caja negra?
2. ¿Cuáles son los comportamientos que deben suceder dentro de la caja negra, es decir, qué debe suceder con esas interacciones para que la caja negra muestre el comportamiento deseado en un nivel superior, por ejemplo, recibir y procesar mensajes entrantes de un sistema de reservas, actualizar una base de datos, etc.? .

Luego, esto comenzará a darle una vista del sistema que consta de varias cajas negras internas, cada una de las cuales se puede dividir aún más de la misma manera.

UML es muy bueno para representar tal comportamiento. Puede describir la mayoría de los sistemas simplemente usando dos de los muchos componentes de UML, a saber:

• diagramas de clases, y
• diagramas de secuencia.

Es posible que también necesite diagramas de actividad si hay algún paralelismo en el comportamiento que deba describirse.

Un buen recurso para aprender UML es el excelente libro de Martin Fowler "UML Distilled" ( enlace de Amazon - saneado para los nazis de enlace de niños de script que existen (-:). Este libro le brinda una mirada rápida a las partes esenciales de cada uno de los componentes de UML.

Oh. Lo que he descrito es más o menos el enfoque de Ivar Jacobson. Jacobson es uno de los tres amigos de OO. De hecho, UML fue desarrollado inicialmente por las otras dos personas que forman los Tres Amigos, Grady Booch y Jim Rumbaugh.

Definitivamente debería echar un vistazo al Código completo de Steve McConnell, y especialmente a su capítulo de sorteos sobre "Diseño en la construcción".

Puedes descargarlo desde su sitio web:

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

Si está desarrollando para .NET, Microsoft acaba de publicar (¡como un libro electrónico gratuito!) La Guía de arquitectura de aplicaciones 2.0b1 . Proporciona mucha información realmente buena sobre la planificación de su arquitectura antes de escribir cualquier código.

Si estaba desesperado, espero que pueda usar grandes porciones para arquitecturas no basadas en .NET.

Prólogo a esto diciendo que me dedico principalmente al desarrollo web donde gran parte de la arquitectura ya está decidida de antemano (WebForms, ahora MVC) y la mayoría de mis proyectos son esfuerzos razonablemente pequeños, de una sola persona que toman menos de un año. También sé que tendré un ORM y DAL para manejar mi objeto comercial y la interacción de datos, respectivamente. Recientemente, cambié a usar LINQ para esto, por lo que gran parte del "diseño" se convierte en diseño de base de datos y mapeo a través del diseñador DBML.

Por lo general, trabajo de manera TDD (desarrollo impulsado por pruebas). No paso mucho tiempo trabajando en detalles arquitectónicos o de diseño. Reúno la interacción general del usuario con la aplicación a través de historias. Utilizo las historias para elaborar el diseño de interacción y descubrir los componentes principales de la aplicación. Hago muchos pizarrones durante este proceso con el cliente, a veces capturando detalles con una cámara digital si parecen lo suficientemente importantes como para mantenerlos en forma de diagrama. Principalmente, mis historias se capturan en forma de historia en una wiki. Eventualmente, las historias se organizan en lanzamientos e iteraciones.

En este momento, normalmente tengo una idea bastante clara de la arquitectura. Si es complicado o hay partes inusuales, cosas que difieren de mis prácticas normales, o estoy trabajando con otra persona (no es típico), diagramaré las cosas (nuevamente en una pizarra). Lo mismo ocurre con las interacciones complicadas: puedo diseñar el diseño de la página y el flujo en una pizarra, guardándolo (o capturando a través de la cámara) hasta que termine con esa sección. Una vez que tenga una idea general de hacia dónde voy y qué debo hacer primero, comenzaré a escribir pruebas para las primeras historias. Por lo general, esto dice: "Está bien, para hacer eso, necesitaré estas clases. Comenzaré con esta y debe hacer esto". Luego comienzo alegremente a TDD y la arquitectura / diseño crece a partir de las necesidades de la aplicación.

Periódicamente, me encuentro deseando volver a escribir algunos fragmentos de código o pensar "esto realmente huele" y refactorizo ​​mi diseño para eliminar la duplicación o reemplazar los fragmentos malolientes con algo más elegante. Principalmente, me preocupa reducir la funcionalidad mientras sigo buenos principios de diseño. Encuentro que usar patrones conocidos y prestar atención a los buenos principios a medida que avanza funciona bastante bien.

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

Utilizo UML y encuentro que la guía es bastante útil y fácil de leer. Avísame si necesitas algo diferente.

UML es una notación. Es una forma de registrar tu diseño, pero no (en mi opinión) de hacer un diseño. Sin embargo, si necesita escribir algo, recomendaría UML, no porque sea el "mejor", sino porque es un estándar que probablemente otros ya sepan leer, y es mejor que inventar su propio "estándar".

Creo que la mejor introducción a UML sigue siendo UML Distilled , de Martin Fowler, porque es conciso, brinda una guía práctica sobre dónde usarlo y deja en claro que no es necesario que compre toda la historia de UML / RUP para sé útil

Hacer diseño es difícil, realmente no se puede capturar en una respuesta de StackOverflow. Desafortunadamente, mis habilidades de diseño, tal como son, han evolucionado a lo largo de los años, por lo que no tengo una fuente a la que pueda referirlos.

Sin embargo, un modelo que he encontrado útil es el análisis de robustez (google para ello, pero hay una intro aquí ). Si tiene sus casos de uso de lo que debería hacer el sistema, un modelo de dominio de las cosas involucradas, entonces he encontrado que el análisis de robustez es una herramienta útil para conectar los dos y determinar cuáles deben ser los componentes clave del sistema. .

Pero el mejor consejo se lee ampliamente, se piensa bien y se practica. No es una habilidad puramente enseñable, tienes que hacerlo realmente.

No soy lo suficientemente inteligente para planificar el futuro más que un poco. Cuando planifico con anticipación, mis planes siempre salen mal, pero ahora he pasado n días con malos planes. Mi límite parece ser de unos 15 minutos en la pizarra.

Básicamente, trabajo lo menos que puedo para saber si voy en la dirección correcta.

Miro mi diseño en busca de preguntas críticas: cuando A haga de B a C, ¿será lo suficientemente rápido para D? Si no es así, necesitamos un diseño diferente. Cada una de estas preguntas se puede responder con un pico. Si los picos se ven bien, entonces tenemos el diseño y es hora de ampliarlo.

Codifico en la dirección de obtener un valor real para el cliente lo antes posible, para que un cliente pueda decirme a dónde debo ir.

Como siempre me equivoco, confío en la refactorización para ayudarme a hacerlo bien. La refactorización es arriesgada, así que tengo que escribir pruebas unitarias sobre la marcha. Escribir pruebas unitarias después del hecho es difícil debido al acoplamiento, así que primero escribo mis pruebas. Mantener la disciplina sobre estas cosas es difícil, y un cerebro diferente ve las cosas de manera diferente, así que me gusta tener un amigo codificando conmigo. Mi compañero de programación tiene nariz, así que me ducho con regularidad.

Llamémoslo "Programación extrema".

"Las pizarras blancas, los bocetos y las notas post-it son excelentes herramientas de diseño. Las complicadas herramientas de modelado tienden a distraer más que iluminar". De Practices of an Agile Developer por Venkat Subramaniam y Andy Hunt .

No estoy convencido de que nada puedaplanificarse con anticipación antes de la implementación. Tengo 10 años de experiencia, pero solo he estado en 4 empresas (incluidos 2 sitios en una empresa, que eran casi polos opuestos), y casi toda mi experiencia ha sido en términos de observación de grupos colosales ****** ** s ocurren. Estoy empezando a pensar que cosas como la refactorización es realmente la mejor manera de hacer las cosas, pero al mismo tiempo me doy cuenta de que mi experiencia es limitada y que podría estar reaccionando a lo que he visto. Lo que realmente me gustaría saber es cómo obtener la mejor experiencia para poder llegar a las conclusiones adecuadas, pero parece que no hay atajos y solo implica mucho tiempo para ver a la gente haciendo las cosas mal :(. I Realmente me gustaría intentar trabajar en una empresa donde la gente hace las cosas bien (como lo demuestran las implementaciones de productos exitosas),

Lamento diferir: UML se puede usar para arquitectura de aplicaciones, pero se usa más a menudo para arquitectura técnica (frameworks, diagramas de clases o de secuencia, ...), porque aquí es donde esos diagramas se pueden mantener sincronizados con el desarrollo .

La Arquitectura de la Aplicación ocurre cuando usted toma algunas especificaciones funcionales (que describen la naturaleza y los flujos de operaciones sin hacer suposiciones sobre una implementación futura) y las transforma en especificaciones técnicas.

Esas especificaciones representan las aplicaciones que necesita para implementar algunas necesidades comerciales y funcionales.

Por lo tanto, si necesita procesar varias carteras financieras grandes (especificación funcional), puede determinar que necesita dividir esa especificación grande en:

• un despachador para asignar esos pesados ​​cálculos a diferentes servidores
• un lanzador para asegurarse de que todos los servidores de cálculo estén en funcionamiento antes de comenzar a procesar esas carteras.
• una GUI para poder mostrar lo que está sucediendo.
• un componente "común" para desarrollar los algoritmos específicos del portafolio, independientemente del resto de la arquitectura de la aplicación, para facilitar las pruebas unitarias, pero también algunas pruebas funcionales y de regresión.

Entonces, básicamente, pensar en la arquitectura de la aplicación es decidir qué "grupo de archivos" necesitas desarrollar de manera coherente (no puedes desarrollar en el mismo grupo de archivos un lanzador, una GUI, un despachador, ... no podría evolucionar al mismo ritmo)

Cuando la arquitectura de una aplicación está bien definida, cada uno de sus componentes suele ser un buen candidato para un componente de configuración , es decir, un grupo de archivos que se pueden versionar como un todo en un VCS (Sistema de control de versiones), lo que significa que todos sus archivos serán etiquetados juntos cada vez que necesite grabar una instantánea de esa aplicación (nuevamente, sería difícil etiquetar todo su sistema, cada una de sus aplicaciones no puede estar en un estado estable al mismo tiempo)

He estado haciendo arquitectura por un tiempo. ¡Utilizo BPML para refinar primero el proceso empresarial y luego uso UML para capturar varios detalles! ¡El tercer paso generalmente es ERD! Para cuando haya terminado con BPML y UML, su ERD será bastante estable. Ningún plan es perfecto y ninguna abstracción va a ser del 100%. Planee la refactorización, ¡el objetivo es minimizar la refactorización tanto como sea posible!

Intento dividir mi pensamiento en dos áreas: una representación de las cosas que estoy tratando de manipular y lo que pretendo hacer con ellas.

Cuando trato de modelar las cosas que estoy tratando de manipular, se me ocurren una serie de definiciones de elementos discretos: un sitio de comercio electrónico tendrá un SKU, un producto, un cliente, etc. También tendré algunas cosas no materiales con las que estoy trabajando, un pedido o una categoría. Una vez que tenga todos los "sustantivos" en el sistema, crearé un modelo de dominio que muestre cómo estos objetos se relacionan entre sí: un pedido tiene un cliente y varios SKU, muchos skus se agrupan en un producto, y así en.

Estos modelos de dominio se pueden representar como modelos de dominio UML, diagramas de clases y ERD de SQL.

Una vez que he descifrado los sustantivos del sistema, paso a los verbos, por ejemplo, las operaciones por las que pasa cada uno de estos elementos para confirmar un pedido. Por lo general, se asignan bastante bien a los casos de uso de mis requisitos funcionales; la forma más fácil de expresarlos que he encontrado son los diagramas de secuencia, actividad o colaboración UML o diagramas de carriles.

Es importante pensar en esto como un proceso iterativo; Haré un pequeño rincón del dominio, luego trabajaré en las acciones y luego volveré. Idealmente, tendré tiempo para escribir código para probar cosas a medida que avanzo; nunca querrás que el diseño se adelante demasiado a la aplicación. Este proceso suele ser terrible si cree que está construyendo la arquitectura completa y final para todo; realmente, todo lo que está tratando de hacer es establecer las bases básicas que el equipo compartirá a medida que avanza en el desarrollo. En su mayoría, está creando un vocabulario compartido para que los miembros del equipo lo usen mientras describen el sistema, no estableciendo la ley sobre cómo debe hacerse.

Me encuentro teniendo problemas para pensar completamente en un sistema antes de codificarlo. Es demasiado fácil echar un vistazo superficial a algunos componentes que solo más tarde se da cuenta de que son mucho más complicados de lo que pensaba.

Una solución es esforzarse mucho. Escriba UML en todas partes. Pasa por todas las clases. Piense en cómo interactuará con sus otras clases. Esto es dificil de hacer.

Lo que me gusta hacer es hacer una descripción general al principio. No me gusta UML, pero me gusta dibujar diagramas que transmitan el mensaje. Entonces empiezo a implementarlo. Incluso cuando estoy escribiendo la estructura de la clase con métodos vacíos, a menudo veo cosas que me perdí antes, así que actualizo mi diseño. Mientras estoy codificando, me daré cuenta de que necesito hacer algo diferente, así que actualizaré mi diseño. Es un proceso iterativo . El concepto de "diseñar todo primero y luego implementarlo todo" se conoce como modelo en cascada, y creo que otros han demostrado que es una mala forma de hacer software.

Prueba Archimate.