Diseño de software vs. 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 dices a alguien que te presente el 'diseño', ¿qué esperas que presente? Lo mismo ocurre con la 'arquitectura'.

Mi comprensión actual es:

• Diseño: diagrama UML / diagrama de flujo / tramas simples (para UI) para un módulo específico / parte del sistema
• Arquitectura: diagrama de componentes (que muestra cómo los diferentes módulos del sistema se comunican entre sí y con otros sistemas), qué lenguaje se utilizará, patrones ...

Corrígeme si estoy equivocado. He referido que Wikipedia tiene artículos en http://en.wikipedia.org/wiki/Software_design y http://en.wikipedia.org/wiki/Software_architecture , pero no estoy seguro de haberlos entendido correctamente.

Tienes razon si. 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 está presente, 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, funciones, del módulo x? ¿De la clase Y? ¿Qué puede hacer y qué no? ¿Qué patrones de diseño se pueden usar?

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 hace hincapié en el nivel de módulo / componente / clase.

En algunas descripciones del SDLC (Software Development Life Cycle) son intercambiables, pero el consenso es que son distintos. Son al mismo tiempo: diferentes (1) etapas , (2) áreas de responsabilidad y (3) niveles de toma de decisiones .

• La arquitectura es el panorama general: la elección de marcos, lenguajes, alcance, objetivos y metodologías de alto nivel ( racional , en cascada , ágil , etc.).
• El diseño es la imagen más pequeña: el plan de cómo se organizará el código; cómo se verá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 combinarse por diferentes razones.

1. Los proyectos más pequeños a menudo no tienen el alcance suficiente para separar la planificación en etapas.
2. 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.)
3. Nuevas formas de pensar sobre el SDLC (ver metodologías ágiles ) reorganizan de alguna manera este enfoque tradicional. El diseño (arquitectura en menor medida) se lleva a cabo en todo el SDLC a propósito . A menudo hay más iteraciones donde todo el proceso ocurre una y otra vez.
4. 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. El diseño e incluso las decisiones arquitectónicas deben tomarse más adelante en el proyecto, sea ese el plan o no.

Incluso si las etapas o áreas de responsabilidad se mezclan y suceden por todas partes, siempre es bueno saber qué nivel de toma de decisiones está sucediendo. (Podríamos continuar para siempre con esto. Estoy tratando de mantener un resumen). Terminaré con: Incluso si parece que su proyecto no tiene una etapa de arquitectura o diseño formal / AOR / documentación, ESTÁ sucediendo si alguien está conscientemente haciéndolo o no. Si nadie decide hacer arquitectura, entonces ocurre una predeterminada que probablemente sea pobre. Lo mismo para 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, herramientas, paradigmas de programación, estándares de ingeniería de software basados ​​en componentes, principios de alto nivel.

Si bien el diseño es una actividad relacionada con restricciones locales, como patrones de diseño, modismos de programación y refactorizaciones.

Encontré esto cuando estaba buscando una distinción simple entre arquitectura y diseño;
¿Qué opinas de esta forma de verlos?

• la arquitectura es "qué" estamos construyendo;
• el diseño es "cómo" estamos construyendo;

1. Arquitectura significa la estructura conceptual y la organización lógica de una computadora o sistema basado en computadora.

   Diseño significa un plan o dibujo producido para mostrar el aspecto y la función o el funcionamiento de un sistema o un objeto antes de que se realice.

2. Si está "diseñando" un componente, está definiendo cómo se comporta en el sistema más grande.

   Si está "diseñando" el mismo componente, está definiendo cómo se comporta internamente.

Toda arquitectura es diseño pero NO todo diseño es arquitectura.

Whatparte es el diseño, la Howes la aplicación concreta y la intersección de Whaty Howes Arquitectura.

Imagen para diferenciar Arquitectura y Diseño :

También hay decisiones de diseño, que no son arquitectónicamente significativas, es decir, no pertenecen a la rama de arquitectura del diseño. Por ejemplo, las decisiones de diseño interno de algunos componentes, como la elección del algoritmo, la selección de la estructura de datos, etc.

Cualquier decisión de diseño que no sea visible fuera del límite de su componente es un diseño interno de un componente y no es arquitectónico. Estas son las decisiones de diseño que un arquitecto de sistemas dejaría a discreción del diseñador del módulo o del equipo de implementación, siempre que su diseño no rompa las restricciones arquitectónicas impuestas por la arquitectura a nivel del sistema.

El enlace que da buena analogía

Yo diría que tienes razón, en mis propias palabras;

La arquitectura es la asignación de requisitos del sistema a elementos del sistema. Cuatro declaraciones sobre una arquitectura:

1. Puede introducir requisitos no funcionales como lenguaje o patrones.
2. Define la interacción entre componentes, interfaces, temporización, etc.
3. No introducirá nuevas funcionalidades,
4. Asigna las funciones (diseñadas) que el sistema está destinado a realizar a los elementos.

La arquitectura es un paso de ingeniería esencial cuando se subdivide una complejidad del sistema.

Ejemplo: piense en su casa, no necesita un arquitecto para su cocina (solo un elemento involucrado) pero el edificio completo necesita algunas definiciones de interacción, como puertas y techo .

El diseño es una representación informativa de la implementación (propuesta) de la función. Su objetivo es obtener retroalimentación y discutir con las partes interesadas. Puede ser una buena práctica, pero no es un paso de ingeniería esencial .

Sería bueno ver el diseño de la cocina antes de instalarla, pero no es esencial para el requisito de cocción :

Si lo pienso, puedes decir:

• la arquitectura es para un público / ingenieros en un nivel de abstracción más detallado
• el diseño está destinado al público en un nivel de abstracción menos detallado

Mi recordatorio:

• Podemos cambiar el diseño sin preguntarle a alguien
• Si cambiamos la arquitectura, necesitamos comunicarla a alguien (equipo, cliente, parte interesada, ...)

Creo que deberíamos usar la siguiente regla para determinar cuándo hablamos de Diseño vs Arquitectura: si los elementos de una imagen de software que ha creado pueden asignarse uno a uno a una construcción sintáctica del lenguaje de programación, entonces es Diseño, si no es Arquitectura.

Entonces, por ejemplo, si está viendo un diagrama de clase o un diagrama de secuencia, puede asignar una clase y sus relaciones a un lenguaje de programación orientado a objetos utilizando la construcción sintáctica de clase. Esto es claramente diseño. Además, esto podría traer a la mesa que esta discusión tiene una relación con el lenguaje de programación que utilizará para implementar un sistema de software. Si usa Java, se aplica el ejemplo anterior, ya que Java es un lenguaje de programación orientado a objetos. Si se te ocurre un diagrama que muestre los paquetes y sus dependencias, también es Design. Puede asignar el elemento (un paquete en este caso) a una construcción sintáctica Java.

Ahora, suponga que su aplicación Java está dividida en módulos, y cada módulo es un conjunto de paquetes (representados como una unidad de despliegue de archivo jar), y se le presenta un diagrama que contiene módulos y sus dependencias, entonces, eso es Arquitectura. No hay una forma en Java (al menos no hasta Java 7) de asignar un módulo (un conjunto de paquetes) a una construcción sintáctica. También puede notar que este diagrama representa un paso más alto en el nivel de abstracción de su modelo de software. Cualquier diagrama anterior (de grano grueso) que un diagrama de paquete, representa una vista arquitectónica cuando se desarrolla en el lenguaje de programación Java. Por otro lado, si está desarrollando en Modula-2, entonces, un diagrama de módulo representa un Diseño.

(Un fragmento de http://www.copypasteisforword.com/notes/software-architecture-vs-software-design )

Personalmente, me gusta este:

"El diseñador está preocupado por lo que sucede cuando un usuario presiona un botón, y el arquitecto está preocupado por lo que sucede cuando diez mil usuarios presionan un botón".

Guía de estudio de SCEA para Java ™ EE por Mark Cade y Humphrey Sheil

Estoy de acuerdo con muchas de las explicaciones; esencialmente estamos reconociendo la distinción entre el diseño arquitectónico y el diseño detallado de los sistemas de software.

Si bien el objetivo del diseñador es ser tan preciso y concreto en las especificaciones como sea necesario para el desarrollo; el arquitecto esencialmente apunta a especificar la estructura y el comportamiento global del sistema tanto como sea necesario para comenzar con el diseño detallado.

Un buen arquitecto evitará las hiperespecificaciones: la arquitectura no debe especificarse en exceso, sino lo suficiente, las decisiones (arquitectónicas) establecidas solo para los aspectos que presentan riesgos más costosos de manejar y proporcionar de manera efectiva un marco ("comunalidad") dentro del cual Se puede trabajar en un diseño detallado, es decir, la variabilidad de la funcionalidad local.

De hecho, el proceso de arquitectura o el ciclo de vida simplemente sigue este tema: un nivel adecuado de abstracción para delinear la estructura de los requisitos comerciales (arquitectónicamente) significativos y dejar más detalles en la fase de diseño para resultados más concretos.

La arquitectura es diseño, pero no todo el diseño es arquitectónico. Por lo tanto, estrictamente hablando, tendría más sentido tratar de diferenciar entre diseño arquitectónico y diseño no arquitectónico . ¿Y cual es la diferencia? ¡Depende! Cada arquitecto de software puede tener una respuesta diferente (¡mmm!). Desarrollamos nuestra heurística para llegar a una respuesta, como 'los diagramas de clase son arquitectura y los diagramas de secuencia son diseño'. Ver libro de DSA para más información.

Es común decir que la arquitectura está en un nivel de abstracción más alto que el diseño, o la arquitectura es lógica y el diseño es físico. Pero esta noción, aunque comúnmente aceptada, es inútil en la práctica. ¿Dónde trazas la línea entre la abstracción alta o baja, entre lo lógico y lo físico? ¡Depende!

Entonces, mi sugerencia es:

• crear un solo documento de diseño.
• nombra este documento de diseño de la manera que quieras o, mejor aún, de la forma en que los lectores están más acostumbrados. Ejemplos: "Arquitectura de software", "Especificación de diseño de software".
• divida este documento en vistas y tenga en cuenta que puede crear una vista como un refinamiento de otra vista.
• hacer que las vistas en el documento sean navegables agregando referencias cruzadas o hipervínculos
• entonces tendrá vistas de nivel superior que muestran una visión general amplia pero superficial del diseño, y vistas más cercanas a la implementación que muestran detalles de diseño estrechos pero más profundos.
• Es posible que desee ver un ejemplo de documento de arquitectura de múltiples vistas ( aquí ).

Habiendo dicho todo eso ... una pregunta más relevante que debemos hacernos es: ¿cuánto diseño es suficiente? Es decir, ¿cuándo debo dejar de describir el diseño (en diagramas o en prosa) y pasar a la codificación?

Sí, eso me suena bien. El diseño es lo que vas a hacer, y la arquitectura es la forma en que las partes del diseño se unirán. Podría ser independiente del lenguaje, pero normalmente especificaría las tecnologías que se utilizarán, es decir, LAMP v Windows, Servicio web v RPC.

La arquitectura de software de un programa o sistema informático es la estructura o estructuras del sistema, que comprenden componentes de software, las propiedades visibles externamente de esos componentes y las relaciones entre ellos.

(de Wikipedia, http://en.wikipedia.org/wiki/Software_architecture )

El diseño de software es un proceso de resolución de problemas y planificación para una solución de software. Después de determinar el propósito y las especificaciones del software, los desarrolladores de software diseñarán o emplearán diseñadores para desarrollar un plan para una solución. Incluye problemas de implementación de algoritmos y componentes de bajo nivel, así como la vista arquitectónica.

(de Wikipedia, http://en.wikipedia.org/wiki/Software_design )

No podría haberlo dicho mejor :)

Veo la arquitectura como lo hace Patrick Karcher: el panorama general. Por ejemplo, puede proporcionar la arquitectura de un edificio, ver su soporte estructural, las ventanas, entradas y salidas, drenaje de agua, etc. Pero no ha "diseñado" el diseño del piso, las posiciones de los cubículos, etc.

Entonces, si bien ha diseñado el edificio, no ha diseñado el diseño de cada oficina. Creo que lo mismo es cierto para el software.

Sin embargo, puede ver el diseño del diseño como "arquitectura del diseño" ...

Buena pregunta ... Aunque la línea entre ellos no es una línea clara y aguda, en mi opinión, si está utilizando ambos términos, entonces Arquitectura abarca decisiones más técnicas o estructurales sobre cómo construir o construir algo, especialmente aquellas decisiones que serán difíciles ( o más difícil) cambiar una vez implementado, mientras que Diseño abarca aquellas decisiones que son fáciles de cambiar más tarde (como nombres de métodos, estructura organizativa de clase <-> archivo, patrones de diseño, ya sea para usar un singleton o una clase estática para resolver algún problema específico , etc.) y / o aquellos que afectan la apariencia o los aspectos estéticos de un sistema o aplicación (interfaz humana, facilidad de uso, apariencia, etc.)

Arquitectura de software está "preocupada por problemas ... más allá de los algoritmos y las estructuras de datos de la computación.

La arquitectura no se trata específicamente de ... detalles de implementaciones (por ejemplo, algoritmos y estructuras de datos). El diseño arquitectónico implica una colección de abstracciones más rica que la que normalmente proporciona OOD ”(diseño orientado a objetos).

Diseño se refiere a la modularización e interfaces detalladas de los elementos de diseño, sus algoritmos y procedimientos, y los tipos de datos necesarios para soportar la arquitectura y satisfacer los requisitos.

"Arquitectura" se usa a menudo como un mero sinónimo de "diseño" (a veces precedido por el adjetivo "alto nivel"). Y muchas personas usan el término "patrones arquitectónicos" como sinónimo de "patrones de diseño".

Mira este enlace.

Definición de los términos Arquitectura, diseño e implementación

Arquitectura: el
trabajo de diseño estructural a niveles más altos de abstracción que cumple requisitos técnicamente significativos en el sistema. La arquitectura establece los cimientos para un diseño posterior.

Diseño:
El arte de completar lo que la arquitectura no hace a través de un proceso iterativo en cada capa de abstracción.

Realmente me gustó este artículo como una regla general para separar la arquitectura del diseño:

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

Se llama la hipótesis de Intensión / Localidad. Las declaraciones sobre la naturaleza del software que no son locales e intensivas son arquitectónicas. Las declaraciones que son locales e intensivas son de diseño.

... hace mucho tiempo, en un lugar lejano, a los filósofos les preocupaba la distinción entre uno y muchos. La arquitectura tiene que ver con la relación, que requiere muchos. La arquitectura tiene componentes. El diseño se trata de contenido, que requiere uno. El diseño tiene propiedades, cualidades, características. Normalmente pensamos que el diseño está dentro de la arquitectura. El pensamiento dualista da a los muchos lo primordial. Pero la arquitectura también está dentro del diseño. Todo es cómo elegimos ver lo que está delante de nosotros: el uno o los muchos.

Bastante subjetivo pero mi opinión:

Arquitectura El diseño general del sistema, incluidas las interacciones con otros sistemas, los requisitos de hardware, el diseño general de los componentes y el flujo de datos.

Diseño La organización y el flujo de un componente en el sistema general. Esto también incluiría la API del componente para la interacción con otros componentes.

La arquitectura de software se usa mejor a nivel de sistema, cuando necesita proyectar negocios y funciones identificadas por niveles de arquitectura más altos en las aplicaciones.

Por ejemplo, su negocio se trata de "Ganancias y pérdidas" para los comerciantes, y sus funciones principales incluyen "evaluación de cartera" y "cálculo de riesgos".

Pero cuando un arquitecto de software detallará su solución, se dará cuenta de que:

La "evaluación de cartera" no puede ser una sola aplicación. Necesita ser refinado en proyectos manejables como:

• GUI
• Lanzacohetes
• Despachador
• ...

(debido a que las operaciones involucradas son tan grandes que deben dividirse entre varias computadoras, mientras se monitorean en todo momento a través de una GUI común)

Un diseño de software examinará las diferentes aplicaciones, su relación técnica y sus subcomponentes internos.
Producirá las especificaciones necesarias para que funcione la última capa de Arquitectura (la "Arquitectura Técnica") (en términos de marco técnico o componentes transversales), y para que comiencen los equipos del proyecto (más orientados en la implementación de las funciones comerciales ) sus respectivos proyectos

si alguien construye un barco, entonces el motor, el casco, los circuitos eléctricos, etc. serán sus "elementos arquitectónicos". Para él, la construcción del motor será un "trabajo de diseño".

Si luego delega la construcción del motor a otro equipo, crearán una "arquitectura del motor" ...

Entonces, depende del nivel de abstracción o detalle. ¡La arquitectura de una persona podría ser el diseño de otra!

La arquitectura son "las decisiones de diseño que son difíciles de cambiar".

Después de trabajar con TDD, lo que prácticamente significa que su diseño cambia todo el tiempo, a menudo me encuentro luchando con esta pregunta. La definición anterior se extrae de Patrones de arquitectura de aplicaciones empresariales , por Martin Fowler

Significa que la arquitectura depende del idioma, el marco y el dominio de su sistema. Si puede extraer una interfaz de su Clase Java en 5 minutos, ya no es una decisión de arquitectura.

Versión de Cliff Notes:

Diseño: Implementación de una solución basada en las especificaciones del producto deseado.

Arquitectura: La base / herramientas / infraestructura / componentes que respaldan su diseño.

Esta es una pregunta bastante amplia que invocará muchas respuestas.

La arquitectura es la colección resultante de patrones de diseño para construir un sistema.

Supongo que el diseño es la creatividad utilizada para poner todo esto junto.

El diseño de software tiene una historia más larga, mientras que el término arquitectura de software tiene apenas 20 años. Por lo tanto, está pasando por problemas de crecimiento en este momento.

Los académicos tienden a ver la arquitectura como parte del campo más amplio del diseño de software. Aunque hay un reconocimiento creciente de que Arch es un campo dentro de sí mismo.

Los practicantes tienden a ver a Arch como decisiones de diseño de alto nivel que son estratégicas y pueden ser costosas en un proyecto para deshacer.

La línea exacta entre Arch y el diseño depende del dominio del software. Por ejemplo, en el dominio de las aplicaciones web, la arquitectura en capas está ganando la mayor popularidad actualmente (Biz Logic Layer, Data Access Layer, etc.) Las partes de nivel inferior de este Arch se consideran diseño (diagramas de clases, firmas de métodos, etc. ) Esto se definiría de manera diferente en los dominios de sistemas integrados, sistemas operativos, compiladores, etc.

La arquitectura es de alto nivel, diseño abstracto y lógico, mientras que el diseño de software es de bajo nivel, diseño detallado y físico.

Además, consulte: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Me gusta la definición y explicación de Roy Thomas Fielding sobre lo que es la arquitectura de software en su artículo: estilos arquitectónicos y el diseño de arquitecturas de software basadas en red

Una arquitectura de software es una abstracción de los elementos de tiempo de ejecución de un sistema de software durante alguna fase de su funcionamiento. Un sistema puede estar compuesto por muchos niveles de abstracción y muchas fases de operación, cada una con su propia arquitectura de software.

Él enfatiza los "elementos de tiempo de ejecución" y los "niveles de abstracción".

No hay una respuesta definitiva a esto porque la "arquitectura de software" y el "diseño de software" tienen bastantes definiciones y tampoco hay una definición canónica.

Una buena forma de pensarlo es la declaración de Len Bass, Paul Clements y Rick Kazman de que "toda arquitectura es diseño pero no todo diseño es arquitectura" [Arquitectura de software en la práctica]. No estoy seguro de estar de acuerdo con eso (porque la arquitectura puede incluir otras actividades), pero captura la esencia de que la arquitectura es una actividad de diseño que se ocupa del subconjunto crítico del diseño.

Mi definición ligeramente flipante (que se encuentra en la página de definiciones de SEI ) es que es el conjunto de decisiones que, si se toman incorrectamente, hacen que su proyecto se cancele.

Un intento útil para separar la arquitectura, el diseño y la implementación como conceptos fue realizado por Amnon Eden y Rick Kazman hace algunos años en un trabajo de investigación titulado "Arquitectura, diseño, implementación" que se puede encontrar aquí: http: //www.sei.cmu .edu / library / assets / ICSE03-1.pdf . Su lenguaje es bastante abstracto, pero de manera simplista dicen que la arquitectura es un diseño que se puede usar en muchos contextos y está destinado a aplicarse en todo el sistema, el diseño es (err) diseño que se puede usar en muchos contextos pero se aplica en una parte específica del sistema e implementación es un diseño específico para un contexto y se aplica en ese contexto.

Por lo tanto, una decisión arquitectónica podría ser una decisión de integrar el sistema a través de mensajes en lugar de RPC (por lo que es un principio general que podría aplicarse en muchos lugares y está destinado a aplicarse a todo el sistema), una decisión de diseño podría ser utilizar un maestro / estructura de subproceso esclavo en el módulo de manejo de solicitud de entrada del sistema (un principio general que podría usarse en cualquier lugar, pero en este caso solo se usa en un módulo) y, por último, una decisión de implementación podría ser mover las responsabilidades de seguridad desde el Enrutador de solicitud al controlador de solicitudes en el módulo Administrador de solicitudes (una decisión relevante solo para ese contexto, utilizada en ese contexto).

¡Espero que esto ayude!