Diseño de Software vs. Arquitectura de Software

¿Podría alguien explicar la diferencia entre el diseño de software y la architecture de software?

Más específicamente; si le dices a alguien que te presente el ‘diseño’, ¿qué esperarías que presentaran? Lo mismo vale para ‘architecture’.

Mi comprensión actual es:

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

Corrígeme si estoy equivocado. Me he referido a 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 razón, sí. La architecture 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 se trata de 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 architecture de software se basa más en 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 architecture es la imagen más grande: la elección de marcos, idiomas, scope, objectives y metodologías de alto nivel ( racional , 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 objectives 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 suficiente scope 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. Las nuevas formas de pensar sobre el SDLC (ver metodologías ágiles ) reordenan un tanto este enfoque tradicional. El diseño (architecture en menor medida) tiene lugar a través del SDLC a propósito . A menudo hay más iteraciones donde todo el proceso sucede 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 las metas y los requisitos a mitad de camino. El diseño e incluso las decisiones arquitectónicas deben tomarse más adelante en el proyecto, ya sea que se trate de un plan o no.

Incluso si las etapas o áreas de responsabilidad se combinan y suceden por todas partes, siempre es bueno saber qué nivel de toma de decisiones está sucediendo. (Podríamos seguir para siempre con esto. Estoy tratando de mantenerlo en un resumen.) Terminaré con: incluso si parece que su proyecto no tiene una etapa formal de architecture / diseño / AOR / documentación, está sucediendo si alguien está conscientemente haciéndolo o no. Si nadie decide hacer architecture, entonces ocurre una predeterminada que probablemente sea deficiente. Lo mismo para el diseño. Estos conceptos son casi más importantes si no hay etapas formales que los representen.

La architecture es estratégica, mientras que el diseño es táctico.

La architecture comprende los marcos, herramientas, paradigmas de progtwigció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 progtwigción y refactorizaciones.

Encontré esto porque estaba buscando una distinción simple entre la architecture y el diseño;
¿Qué piensas de esta forma de verlos?

  • la architecture es “lo que” 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 computarizado.

    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 un sistema más grande.

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

Toda la architecture es diseño pero NO todo el diseño es architecture.

What parte es el diseño? How es la implementación concreta y la intersección de What y How es la architecture?

Imagen para diferenciar architecture y diseño :

Diseño vs Arquitectura

También hay decisiones de diseño que no son arquitectónicamente significativas, es decir, que no pertenecen a la twig de architecture 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 es visible fuera de los límites de sus componentes es el 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 architecture de nivel del sistema.

El enlace que da buena analogía

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

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

  1. Puede presentar requisitos no funcionales, como el lenguaje o los patrones.
  2. Define la interacción entre componentes, interfaces, tiempos, etc.
  3. No debe introducir nueva funcionalidad,
  4. Asigna las funciones (diseñadas) que el sistema debe realizar a los elementos.

La architecture 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. Tiene la intención de 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 agradable ver el diseño de la cocina antes de instalar la cocina, pero no es esencial para el requisito de cocción :

Si lo pienso, puede decir:

  • la architecture 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, debemos 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 creó pueden mapearse uno a uno a una construcción sintáctica de lenguaje de progtwigción, entonces es Diseño, si no es Arquitectura.

Entonces, por ejemplo, si está viendo un diagtwig de clase o un diagtwig de secuencia, puede asignar una clase y sus relaciones a un lenguaje de Progtwigción Orientada a Objetos usando 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 progtwigción que usará para implementar un sistema de software. Si usa Java, se aplica el ejemplo anterior, ya que Java es un Lenguaje de progtwigción orientado a objetos. Si se le ocurre un diagtwig que muestra los paquetes y sus dependencias, eso también es Diseño. Puede asignar el elemento (un paquete en este caso) a una construcción sintáctica de Java.

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

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

Personalmente, me gusta este:

“Al diseñador le preocupa lo que sucede cuando un usuario presiona un botón, y al arquitecto le preocupa lo que sucede cuando diez mil usuarios presionan un botón”.

Guía de estudio de SCEA for 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 objective del diseñador es ser tan preciso y concreto en las especificaciones como sea necesario para el desarrollo; el arquitecto esencialmente tiene como objective especificar la estructura y el comportamiento global del sistema tanto como se requiere para el diseño detallado para comenzar.

Un buen arquitecto evitará las hiper-especificaciones: la architecture no debe especificarse demasiado, pero sí lo suficiente, las decisiones (arquitectónicas) establecidas solo para los aspectos que presentan riesgos más costosos de manejar, y proporcionar efectivamente un marco (“comunalidad”) dentro del cual el el diseño detallado se puede trabajar sobre la variabilidad de la funcionalidad local.

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

La architecture 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 el diseño arquitectónico y el diseño no arquitectónico . ¿Y cual es la diferencia? ¡Depende! Cada arquitecto de software puede tener una respuesta diferente (ymmv!). Desarrollamos nuestra heurística para encontrar una respuesta, como ‘los diagtwigs de clase son architecture y los diagtwigs de secuencia son diseño’. Vea el libro de DSA para más.

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

Entonces, mi sugerencia es:

  • crea un solo documento de diseño.
  • nombre este documento de diseño de la manera que desee o, mejor, 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
  • luego tendrá vistas de mayor nivel 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 echar un vistazo a un ejemplo de documento de architecture 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 debería dejar de describir el diseño (en diagtwigs o en prosa) y pasar a la encoding?

Sí, eso suena bien para mí. El diseño es lo que vas a hacer, y la architecture es la forma en que los elementos del diseño se unirán. Podría ser independiente del idioma, pero normalmente especificaría las tecnologías que se utilizarán, es decir, LAMP v Windows, Web Service v RPC.

La architecture del software de un progtwig o sistema informático es la estructura o las 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 solució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 architecture como lo hace Patrick Karcher: el outlook general. Por ejemplo, puede proporcionar la architecture 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 del cubículo, etc.

Entonces, mientras 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, podría ver el diseño del diseño, como “diseñar el diseño” …

Buena pregunta … Aunque la línea entre ellos no es una línea muy clara, si usas ambos términos, la 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) para cambiar una vez implementado, mientras que el Diseño abarca aquellas decisiones que son fáciles de cambiar más tarde (como nombres de métodos, estructura organizativa de archivos de clase, patrones de diseño, si se debe usar una clase única o estática para resolver algún problema específico , etc.) y / o aquellos que afectan la apariencia o aspectos estéticos de un sistema o aplicación (Interfaz humana, facilidad de uso, apariencia, etc.)

La architecture de software está “preocupada por problemas … más allá de los algoritmos y las estructuras de datos del cálculo.

La architecture no se trata específicamente de … detalles de implementaciones (p. Ej., Algoritmos y estructuras de datos). El diseño arquitectónico implica una colección de abstracciones más rica que la que generalmente proporciona OOD “(diseño orientado a objetos).

El diseño se ocupa de la modularización y las interfaces detalladas de los elementos de diseño, sus algoritmos y procedimientos, y los tipos de datos necesarios para soportar la architecture y satisfacer los requisitos.

La “architecture” se usa a menudo como un mero sinónimo de “diseño” (a veces precedido del 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 diseño estructural funciona a niveles más altos de abstracción que cumplen requisitos técnicamente significativos en el sistema. La architecture sienta las bases para un mayor diseño.

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

Realmente me gustó este artículo como una regla práctica para separar la architecture 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 intensionales son arquitectónicas. Las declaraciones que son locales e intensionales son diseño.

… Hace mucho tiempo, en un lugar lejano, los filósofos estaban preocupados por la distinción entre uno y muchos. La architecture se trata de relación, que requiere muchos. La architecture 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 architecture. El pensamiento dualista da a los muchos como primordiales. Pero la architecture también está dentro del diseño. Así es como elegimos ver lo que tenemos ante nosotros: el uno o los muchos.

Bastante subjetivo pero mi opinión:

Arquitectura El diseño general del sistema incluye interacciones con otros sistemas, requisitos de hardware, diseño general de componentes y 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 architecture de software se utiliza mejor a nivel del sistema, cuando necesita proyectar negocios y funciones identificadas por niveles de architecture más altos en las aplicaciones.

Por ejemplo, su negocio 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:

“evaluación de cartera” no puede ser solo una aplicación. Necesita ser refinado en proyectos manejables como:

  • GUI
  • Lanzacohetes
  • Transportista

(Debido a que las operaciones involucradas son tan grandes que deben dividirse entre varias computadoras, mientras se siguen monitoreando 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 la última capa de Arquitectura (la “Arquitectura Técnica”) para trabajar (en términos de marco técnico o componentes transversales), y para que los equipos de proyecto (más orientados a la implementación de las funciones de negocios ) comiencen 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 “architecture del motor” …

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

La architecture es “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 encontré luchando con esta pregunta. La definición anterior se extrae de Patterns of Enterprise Application Architecture , por Martin Fowler

Significa que la architecture depende del Idioma, el Marco y el Dominio de su sistema. Si puede extraer una interfaz de su clase de Java en 5 minutos, ya no es una decisión de architecture.

Versión 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 architecture es la colección resultante de patrones de diseño para construir un sistema.

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

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

Los académicos tienden a ver la architecture 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 profesionales 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 architecture estratificada 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 (diagtwigs de clase, firmas de métodos, etc. ) Esto se definiría de manera diferente en los dominios de sistemas integrados, sistemas operativos, comstackdores, etc.

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

Me gusta la definición y explicación de Roy Thomas Fielding sobre qué es la architecture de software en su artículo: Estilos arquitectónicos y el diseño de architectures de software basadas en red

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

Él enfatiza “elementos de tiempo de ejecución” y “niveles de abstracción”.

No hay una respuesta definitiva porque la “architecture de software” y el “diseño de software” tienen muchas definiciones y no hay una definición canónica para ninguna de ellas.

Una buena forma de pensar es en la statement de Len Bass, Paul Clements y Rick Kazman de que “toda la architecture es diseño pero no todo diseño es architecture” [Software Architecture in Practice]. No estoy seguro de estar completamente de acuerdo con eso (porque la architecture puede incluir otras actividades) pero capta la esencia de que la architecture es una actividad de diseño que trata con el subconjunto crítico del diseño.

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

Un bash útil de separar la architecture, el diseño y la implementación como conceptos fue hecho 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 simplistamente dicen que la architecture es un diseño que puede usarse en muchos contextos y debe aplicarse en todo el sistema, el diseño es (err) el diseño que se puede usar en muchos contextos pero se aplica en una parte específica del sistema, y ​​la implementación es específica del diseño de un contexto y se aplica en ese contexto.

Así que 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 se aplica 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 gestión de solicitud de entrada del sistema (un principio general que podría usarse en cualquier lugar pero en este caso solo se utiliza en un módulo) y finalmente, una decisión de implementación podría ser transferir responsabilidades de seguridad desde el enrutador de solicitud al manejador 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!