spectacular literature gradual famous english career articles architects architecture definition

architecture - literature - Diseño de Software vs. Arquitectura de Software



literature definition (30)

¿Alguien podría explicar la diferencia entre el diseño de software y la arquitectura de software?

Más específicamente; Si le dices a alguien que te presente el ''diseño'', ¿qué esperas que presenten? Lo mismo ocurre con la ''arquitectura''.

Mi entendimiento actual es:

  • Diseño: diagrama UML / diagrama de flujo / esquemas de conexión simples (para IU) para un módulo / parte específico 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 me equivoco. Me 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.

  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.

What parte es el diseño, el How es la implementación concreta y la intersección de What y How es la 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 la 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 de los límites de sus componentes, 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 criterio del diseñador del módulo o el 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.

Bastante subjetivo pero mi toma:

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 global. Esto también incluiría la API del componente para la interacción con otros componentes.

Buena pregunta ... Aunque la línea entre ellos no es una línea clara y brillante, imho, si está usando ambos términos, entonces 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) cambiar una vez implementado, mientras que el Diseño abarca aquellas decisiones que son fáciles de cambiar más adelante (como los nombres de los métodos, la estructura organizativa del archivo de la clase <->, los 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.)

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

Por ejemplo, si está viendo un diagrama de clase o un diagrama de secuencia, puede mapear una clase y sus relaciones con un lenguaje de programación orientado a objetos utilizando la construcción sintáctica de la 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 creas un diagrama 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, suponga que su aplicación Java está dividida en módulos, y cada módulo es un conjunto de paquetes (representado como una unidad de implementación de archivos jar), y se le presenta un diagrama que contiene módulos y sus dependencias, entonces, eso es Arquitectura. No hay una manera 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 )

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 dolores 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 creciente reconocimiento 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 aplicaciones web, la arquitectura en capas está ganando la mayor popularidad actualmente (capa lógica de Biz, capa de acceso a datos, etc.) Las partes de nivel inferior de este arco se consideran diseño (diagramas de clase, firmas de métodos, etc.) ) Esto se definiría de manera diferente en los dominios de sistemas integrados, sistemas operativos, compiladores, etc.

En algunas descripciones del SDLC (Ciclo de vida del desarrollo del software) 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 .

Estas dos etapas parecerán fusionarse por diferentes razones.

  1. Los proyectos más pequeños a menudo no tienen el alcance suficiente para separar la planificación en estos por 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ódigos reutilizables, etc.)
  3. Las nuevas formas de pensar acerca del SDLC (ver agile ) reorganizan de alguna manera este enfoque tradicional. El diseño (la arquitectura en menor medida) tiene lugar a lo largo del SDLC a propósito . A menudo hay más iterations donde todo el proceso pasa una y otra vez.
  4. El desarrollo de software es complicado y difícil de planear de todos modos, pero los clientes / gerentes / vendedores generalmente lo hacen más difícil al cambiar los objetivos y los requisitos a medio camino. El diseño e incluso las decisiones arquitectónicas deben realizarse más adelante en el proyecto, ya sea ese el plan o no.

Incluso si las etapas o áreas de responsabilidad se combinan y suceden en todas partes, siempre es bueno saber qué nivel de toma de decisiones está ocurriendo. (Podríamos continuar para siempre con esto. Estoy tratando de mantenerlo como un resumen.) Terminaré con: Aunque parezca que su proyecto no tiene una etapa formal de arquitectura o diseño / 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 ocurre con el diseño. Estos conceptos son casi más importantes si no hay etapas formales que los representen.

Encontré esto mientras buscaba una distinción simple entre arquitectura y diseño;
¿Qué te parece esta forma de mirarlos?

  • La arquitectura es "lo que" estamos construyendo;
  • el diseño es "cómo" estamos construyendo;

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 se requiere para comenzar con el diseño detallado.

Un buen arquitecto evitará las hipercerpecificaciones: la arquitectura no debe especificarse de manera excesiva, sino que basta con las decisiones (arquitectónicas) establecidas solo para los aspectos que presentan los riesgos más costosos de manejar, y proporcionan efectivamente un marco ("elementos comunes") dentro de los cuales Se puede trabajar en el diseño detallado, es decir, la variabilidad para la funcionalidad local.

De hecho, el proceso de arquitectura o el ciclo de vida solo siguen este tema: nivel adecuado de abstracción para delinear la estructura para los requisitos de negocio (arquitectónicamente) significativos, y dejar más detalles a la fase de diseño para entregables más concretos.

Hace mucho tiempo, en un lugar lejano, los filósofos estaban preocupados por la distinción entre uno y muchos. La arquitectura tiene que ver con la relación, que requiere de los muchos. La arquitectura tiene componentes. El diseño tiene que ver con el contenido, que requiere el 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 como primordiales. Pero la arquitectura también está dentro del diseño. Así es como elegimos ver lo que tenemos ante nosotros: lo uno o lo múltiple.

La arquitectura del 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 (p. Ej., Algoritmos y estructuras de datos). El diseño arquitectónico implica una colección de abstracciones más rica que la que proporciona normalmente 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 respaldar la arquitectura y satisfacer los requisitos.

La "arquitectura" se usa a menudo como un simple 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".

Echa un vistazo a este enlace.

Definición de los términos Arquitectura, Diseño e Implementación.

La arquitectura de software de un programa o sistema informático es la estructura o estructuras del sistema, que comprende 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 que se determinen 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 :)

La arquitectura del software se utiliza mejor a nivel del 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 operadores, y sus funciones principales incluyen "evaluación de cartera" y "cálculo de riesgo".

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

La "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 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 de proyecto (más orientados a la implementación de las funciones empresariales ) sus respectivos proyectos.

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.

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 las limitaciones locales, como los patrones de diseño, los lenguajes de programación y las refactorizaciones.

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 juntar todo esto?

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 Patterns of Enterprise Application Architecture , por Martin Fowler.

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

Me gusta la definición y explicación de Roy Thomas Fielding sobre 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 operación. 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.

Enfatiza los "elementos de tiempo de ejecución" y los "niveles de abstracción".

Mi recordatorio

  • Podemos cambiar el diseño sin preguntar a alguien.
  • Si cambiamos la arquitectura, debemos comunicárselo a alguien (equipo, cliente, parte interesada, ...)

No hay una respuesta definitiva a esto porque "arquitectura de software" y "diseño de software" tienen un buen número de definiciones y no hay una definición canónica para ninguno de los dos.

Una buena forma de verlo es la afirmación de Len Bass, Paul Clements y Rick Kazman de que "toda la arquitectura es diseño, pero no todo el 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 capta la esencia de que la arquitectura es una actividad de diseño que se ocupa del subconjunto crítico de diseño.

Mi definición ligeramente frívola (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 de separar arquitectura, diseño e 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, de manera simplista, dicen que la arquitectura es un diseño que se puede usar en muchos contextos y se debe aplicar en todo el sistema, el diseño es (err) un diseño que se puede usar en muchos contextos pero se aplica en una parte específica del sistema, y ​​la 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 puede 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 de esclavo en el módulo de manejo de solicitud de entrada del sistema (un principio general que podría usarse en cualquier parte, pero en este caso solo se usa en un módulo) y, finalmente, una decisión de implementación podría ser trasladar las 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!

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".

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

Realmente me gustó este artículo como 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 la 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.

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

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

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

Entonces, depende del nivel de abstracción o detalle. ¡La arquitectura de una persona puede ser un diseño de otros!

Tienes razón, sí. La arquitectura de un sistema es su ''esqueleto''. Es el más alto nivel 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 están implementados. Al igual que los patrones de diseño, hay patrones arquitectónicos: MVC, diseño en capas de 3 niveles, etc.

El diseño del software consiste en diseñar los módulos / componentes individuales. ¿Cuáles son las responsabilidades, 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 del software es más sobre el diseño de todo el sistema, mientras que el diseño del software hace hincapié en el nivel de módulo / componente / clase.

Veo la arquitectura como lo hace Patrick Karcher, el panorama general. Por ejemplo, puede proporcionar la arquitectura a 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.

Por lo tanto, mientras ha diseñado el edificio, no ha diseñado el diseño de cada oficina. Creo que lo mismo vale para el software.

Puede ver el diseño del diseño, como "arquitectura del diseño", aunque ...

Versión Cliff Notes:

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

Arquitectura: la base / herramientas / infraestructura / componentes que soportan su diseño.

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

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

La arquitectura es la asignación de los requisitos del sistema a los elementos del sistema. Cuatro afirmaciones 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 pretende 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 un techo .

El diseño es una representación informativa de la implementación (propuesta) de la función. Su objetivo es obtener comentarios 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 instalar la cocina, pero no es esencial para los requisitos 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.

Arquitectura:
El diseño estructural trabaja en niveles más altos de abstracción que realizan requisitos técnicamente significativos en el sistema. La arquitectura sienta las bases para un mayor diseño.

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.

La arquitectura es diseño, pero no todo 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 (ymmv!). Desarrollamos nuestras heurísticas para dar una respuesta, como "los diagramas de clase son arquitectura y los diagramas de secuencia son diseño". Ver el libro de DSA para más.

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 abstracción alta o baja, entre lógica y física? ¡Depende!

Entonces, mi sugerencia es:

  • crear un documento de diseño único.
  • Nombre este documento de diseño de la manera que desee o, mejor, 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.
  • haga que las vistas en el documento sean navegables agregando referencias cruzadas o hipervínculos
  • luego 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 vista múltiple ( here ).

Habiendo dicho todo eso ... una pregunta más relevante que debemos hacer 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?