¿Cuál es la mejor manera de entender la arquitectura de software de manera efectiva?

La ingeniería inversa del código fuente para comprender la arquitectura de software es muy, muy ineficiente y propensa a errores. Y, además, ¡anula completamente el propósito de crear la arquitectura en primer lugar!

¡La mejor manera es diseñar y documentar la arquitectura, antes de escribir una sola línea de código!

No obstante, las diferentes perspectivas del sistema / aplicación representan la arquitectura en gran medida, independientemente de si se crearon / documentaron antes del desarrollo o si se diseñaron mediante ingeniería inversa.

  1. Diagrama de despliegue / alojamiento de aplicaciones / servidores
  2. Diagrama de integración de la aplicación, que muestra la integración de diferentes capas / niveles de la aplicación y sus comunicaciones / interacciones entre sí.
  3. Diagrama de módulos de aplicación, identificando diferentes módulos.
  4. Modelo de objeto
  5. ERD – Diagrama de relaciones entre entidades
  6. Diagramas de flujo de trabajo principales / críticos
  7. A veces, diagramas que explican los motores personalizados creados para el procesamiento de lógica empresarial / flujo de trabajo dedicado / crítico

Los documentos creados originalmente como Solution-Architecture y Application-Architecture contienen mucha más información que esta.

¡Espero que ayude!

¡Aclamaciones!

Manoj Bhaiwal

Qué es la arquitectura del software es una pregunta del millón. Es el término más mal especificado. Todo el mundo tiene su propia definición. Así que intentaré responder utilizando la definición de arquitectura de archivo. Una arquitectura (plan) es un diseño del componente y cómo están conectados ( vías ). En el caso de edificios, las cosas son más simples ya que todos los componentes son físicos. En el caso del software, es un poco difícil ya que los componentes están en dos niveles, lógico y físico. Para simplificar, supongamos que todos los componentes son iguales en ambos niveles. Entonces, en mi opinión, la mejor manera de entender la arquitectura es dividir el software funcionalmente en componentes de forma recursiva y documentar cómo se conectan. La respuesta corta es un diagrama de colaboración de bajo nivel en cada nivel de granularidad y cómo se logra la navegación .

Vamos a dividirlo en 2 áreas:

app arch – sigue los datos. Esa es la clave para entender el arco y la razón por la que existe esta aplicación. Esto mostrará cómo / quién está almacenando, organizando, calculando y cambiando los datos, con la esperanza de que pueda averiguar por qué. Esto le dará una mirada razonable al arco de aplicación sw. Esto también debería llevarlo al arco hw, virtual o real y, si es bueno, la estructura de la red, como f5, etc.

sys arch – similar pero sigues los paquetes de datos y los mecanismos de cola detrás del sw. Esto conducirá a qué rutinas del sistema operativo se utilizan los controladores. Necesitas profundizar para entender cómo la configuración del sistema operativo afecta al sw.

Si el sw está bien documentado, es decir, el diagrama, los casos de uso, uml, los requisitos, el lib lib de prueba, el diagrama de relaciones, puede tener suerte y esto ayudará, pero tenga en cuenta que la mayoría de la documentación no envejece bien y con el tiempo hay una deriva entre lo que Se está ejecutando y lo que está documentado.

Las vistas ayudan a comprender la intención de un arquitecto sobre cómo y por qué un sistema o sistemas de sistemas están diseñados de la forma en que están diseñados. También ayuda a comprender qué componente (s) cumplen una responsabilidad específica en el gran esquema de las cosas. Un guión gráfico, un diagrama de secuencia, una vista de despliegue, etc. son muy útiles para que un arquitecto se comunique y convenza de su visión a los demás. Algunos de estos artefactos deben mantenerse actualizados con la compilación para que puedan ser muy útiles para la implementación, la trazabilidad y la compatibilidad.