Diseño de software versus arquitectura de software [cerrado]
¿Alguien podría explicar la diferencia entre diseño de software y arquitectura de software?
Más específicamente; Si le pides a alguien que te presente el "diseño", ¿qué esperarías que te presente? Lo mismo ocurre con la "arquitectura".
Mi comprensión actual es:
- Diseño: diagrama UML/diagrama de flujo/estructuras alámbricas simples (para UI) para un módulo/parte específico del sistema
- Arquitectura: diagrama de componentes (que muestra cómo se comunican los diferentes módulos del sistema entre sí y con otros sistemas), qué lenguaje se utilizará, patrones...
Corrígeme si estoy equivocado. He referido que Wikipedia tiene artículos sobre http://en.wikipedia.org/wiki/Software_design y http://en.wikipedia.org/wiki/Software_architecture , pero no estoy seguro de haberlos entendido correctamente.
Tienes razón, sí. La arquitectura de un sistema es su "esqueleto". Es el nivel más alto de abstracción de un sistema. Qué tipo de almacenamiento de datos hay, cómo interactúan los módulos entre sí, qué sistemas de recuperación existen. Al igual que los patrones de diseño, existen patrones arquitectónicos: MVC, diseño en capas de 3 niveles, etc.
El diseño de software consiste en diseñar los módulos/componentes individuales. ¿Cuáles son las responsabilidades y funciones del módulo x? ¿De clase Y? ¿Qué puede hacer y qué no? ¿Qué patrones de diseño se pueden utilizar?
En resumen, la arquitectura de software tiene más que ver con el diseño de todo el sistema, mientras que el diseño de software enfatiza el nivel de módulo/componente/clase.
En algunas descripciones del SDLC (Ciclo de vida de desarrollo de software) son intercambiables, pero la conclusión es que son distintos. Son a la vez: diferentes (1) etapas , (2) áreas de responsabilidad , y (3) niveles de toma de decisiones .
- La arquitectura es el panorama más amplio: la elección de marcos, lenguajes, alcance, objetivos y metodologías de alto nivel ( racional , en cascada , ágil , etc.).
- El diseño es el panorama más pequeño: el plan sobre cómo se organizará el código; cómo serán los contratos entre las diferentes partes del sistema; la implementación continua de las metodologías y objetivos del proyecto. Las especificaciones se escriben durante esta etapa.
Estas dos etapas parecerán mezclarse por diferentes razones.
- Los proyectos más pequeños a menudo no tienen suficiente alcance para separar la planificación en estas dos etapas.
- Un proyecto puede ser parte de un proyecto más grande y, por lo tanto, partes de ambas etapas ya están decididas. (Ya existen bases de datos, convenciones, estándares, protocolos, marcos, código reutilizable, etc.)
- Las nuevas formas de pensar sobre el SDLC (ver Metodologías ágiles ) reorganizan un poco este enfoque tradicional. El diseño (arquitectura en menor medida) se realiza a lo largo del SDLC de forma intencionada . A menudo hay más iteraciones en las que todo el proceso se repite una y otra vez.
- El desarrollo de software es complicado y difícil de planificar de todos modos, pero los clientes/gerentes/vendedores generalmente lo hacen más difícil al cambiar los objetivos y requisitos a mitad de camino. Las decisiones de diseño e incluso arquitectónicas deben tomarse más adelante en el proyecto, ya sea que ese sea el plan o no.
Incluso si las etapas o áreas de responsabilidad se mezclan y suceden en todas partes, siempre es bueno saber qué nivel de toma de decisiones está ocurriendo. (Podríamos seguir eternamente con esto. Estoy tratando de mantenerlo como un resumen.) Terminaré con: Incluso si parece que su proyecto no tiene una etapa formal de arquitectura o diseño/AOR/documentación, ESTÁ sucediendo, ya sea que alguien esté hacerlo conscientemente o no. Si nadie decide hacer arquitectura, entonces surge una predeterminada que probablemente sea pobre. Lo mismo ocurre con el diseño. Estos conceptos son casi más importantes si no hay etapas formales que los representen.
La arquitectura es estratégica, mientras que el diseño es táctico.
La arquitectura comprende los marcos, las herramientas, los paradigmas de programación, los estándares de ingeniería de software basados en componentes y los principios de alto nivel.
Si bien el diseño es una actividad relacionada con las limitaciones locales, como patrones de diseño, modismos de programación y refactorizaciones.
Encontré esto porque yo mismo buscaba una distinción simple entre arquitectura y diseño;
¿Qué opinas de esta forma de verlos?
- la arquitectura es "lo" que estamos construyendo;
- el diseño es "cómo" construimos;