Arquitectura de Software

Maestría en Ingeniería de Sistemas e Informática

Mención: Ingeniería de Software

Docente: Mg. Ing. Félix Santos López

 Contenido:
• Introducción
• ¿Qué es Arquitectura de Software?
• The Architecture Influence Cycle: Qué influencia a los
arquitectos y a la arquitectura de software
• Relaciones entre sistemas de calidad y arquitectura de
software.
• Patrones de arquitectura de software
• Auto-Driven Design (ADD)
• Documentación de arquitectura de software
 Contenido:
• Evaluación de arquitectura de software
• Re-uso de arquitectura de software para líneas de productos
• Arquitectura en proyectos agiles
• Modelamiento UML para arquitectos de software
• Introducción a la arquitectura empresarial
Evaluación:

- Presentación Grupal (30%)

- Paper de Revisión Bibliográfica y

presentación individual (40%)

- Examen Final (30%)

Fechas:
- Presentación Grupal (Todas las
semanas)

- Envío de paper de Revisión Bibliográfica

(20 de diciembre) y presentación
individual (17 de diciembre)

- Examen Final (17 de diciembre)

Temas de Investigación:
Arquitectura de Sistemas Distribuidos
Arquitectura Orientado a Servicios (SOA)
Arquitectura MOM (Message-Oriented Middleware)
Arquitectura de Software para Sistemas en Tiempo Real
Arquitectura de Software Agil
Arquitectura de Software en la Nube
Arquitectura de microservicios
Arquitectura de software P2P
Arquitectura de Software para el Internet de las Cosas (IoT)
Arquitectura de software crowdsourcing
Libros de Referencia:
Certificación:

http://www.sei.cmu.edu/training/
certificates/architecture/professio
nal.cfm
SEI:
Clase 1: Introducción
Conceptos Previos:
¿Aplicaciones Empresariales?
Se define como software de larga escala localizados en un servidor que atienden a
usuarios finales, mediante la comunicación de una red, para soportar o proveer
información respecto a la ejecución de procesos de negocios.
Conceptos Previos:
Entonces, las aplicaciones dentro de una organización pueden ser desarrolladas o
adquiridas. Requieren por tanto, en un inicio (ya sean de desarrollo interno o de
un proveedor), del ciclo de vida del desarrollo de software.
Conceptos Previos:
¿Arquitectura?

Casa de perro
Casa

Torres Petronas
 Discusión
Aplicando sus experiencias, traten de definir lo siguiente:

- Arquitectura Empresarial
- Arquitectura de Sistema
- Arquitectura de Software
Arquitectura Empresarial:
Arquitectura empresarial es un termino comúnmente usado en el ámbito de los
negocios hoy en día, pero ¿Qué significa?

Arquitectura empresarial describe las estructuras de negocio y los procesos que los
conectan.

Describe el flujo de información y las actividades entre varios grupos dentro de la

organización, que realizan alguna actividad de negocio global.

Las arquitecturas empresariales pueden ser o no soportadas por sistemas de

computo.

El software y su diseño no son necesariamente explicados y detallados en una

arquitectura empresarial
Arquitectura de Sistema:
Arquitectura de Sistema describe los elementos e interacciones de un sistema
completo incluyendo sus elementos hardware y software.

La Arquitectura de Sistema se ocupa de los elementos del sistema y su contribución a

los objetivos del sistema, pero no con su subestructura.
¿Dónde encaja la arquitectura de software?
La arquitectura empresarial y la arquitectura del sistema proveen un ambiente en el
cual el software puede existir.

Ambos proveen requerimientos y restricciones para la arquitectura de software que

se debe de adherir.

Los elementos de ambos son susceptibles a contener arquitectura de software.

 Conceptos:
¿Qué es Arquitectura de Software? (1)
Arquitectura = {elementos, organización, decisiones}
La Arquitectura de Software es un conjunto de elementos arquitecturales
que poseen alguna organización (3 tipos).

- Elementos que usan o transforman información;

- Elementos que contienen la información para ser usada y transformada;
- Elementos que conectan elementos de cualquier tipo entre sí.
La organización dicta las relaciones entre los elementos arquitecturales. Las relaciones poseen
propiedades y restringen como los elementos deben interactuar.

(Perry y Wolf)
Conceptos:
¿Qué es Arquitectura de Software? (2)
La arquitectura de un programa o de sistemas computacionales
es la estructura o estructuras del sistema, la cual está
compuesta de elementos de software, de propiedades
externamente visibles de esos elementos y de las relaciones
entre ellas.
Bass et al.

La arquitectura de software se hace necesaria cuando el tamaño y la complejidad de los

sistemas de software crecen. El problema de construir va más allá de los algoritmos y de
las estructuras de datos correctos. Además decisiones (protocolos de comunicación,
sincronización, acceso a datos, distribución física, etc.)

“elemento”  Abstracción
 ¿Qué es Arquitectura de Software? (3)

La arquitectura de software de un programa o sistema computacional es

la estructura o estructuras del sistema que comprenden:

• Componentes Software.
• Las propiedades visibles de aquellos componentes.
• Las relaciones entre los componentes.

(Bass, Clements, and Kazman)

 ¿Qué es Arquitectura de Software? (4)

La arquitectura es la organización fundamental de un sistema

incorporada en sus componentes, sus relaciones con el entorno
y los principios que conducen su diseño y evolución.

ISO/IEEE 1471-2000

Definición más aceptada

 Discusión

¿Definir la arquitectura, en los proyectos

actuales de ingeniería de software, es crítico?
Arquitectura: nivel alto de abstracción

Granularidad

Diseño de Alto Nivel vs. Diseño Detallado

 Discusión

¿Existe alguna diferencia entre arquitectura y

diseño de software?
 Arquitectura vs Diseño
La arquitectura y el diseño difieren en tres áreas:

Arquitectura Diseño
Nivel de Abstracción Alto Nivel Bajo nivel. Enfoque
especifico de detalles.
Entregables Planificación de Diseño detallado de
subsistemas, interfaces componentes.
con sistemas externos,
servicios, componentes Especificación de
reutilizables, prototipo codificación.
arquitectónico.
Áreas de Enfoque Selección de Requerimientos
tecnologías, funcionales.
requerimientos no
funcionales, manejo de
riesgos.
 Una típica Arquitectura de Software (1)

Una arquitectura de software es usualmente descrita usando gráficos de “líneas y

cajas”, dibujando el sistema que intenta resolver los problemas articulados por la
especificación.

Las cajas muestran elementos o “partes” del sistema.

Las líneas muestran las relaciones entre las partes.

 Analicemos la definición
Ejemplo de “Simulación Acústica Submarina”:

Proceso
de Control
(CP)

Modelo Modelo de Modelo

de Pérdida Reverberación de Ruido
(MODP) (MODR) (MODN)
 Analizando

¿Cuál es la naturaleza de los elementos?

• ¿Cuál es la significancia de su separación?

• ¿Existen en tiempo de ejecución?
• ¿Corren en tiempos separados?
• ¿Son procesos, programas o hardware?
• ¿Son objetos, tareas, funciones o procesos?
• ¿Son sistemas distribuidos?

¿Cuáles son las responsabilidades de los elementos?

• ¿Qué es lo que hacen?

• ¿Qué funciones proveen dentro del contexto del sistema?
Una típica Arquitectura de Software (2)
 ¿Qué se puede decir del gráfico?

• ¿El sistema consiste de muchos elementos?

• ¿Los elementos interactúan con otros mediante varias redes de trabajo?

• ¿Algunos de los elementos representan capas o niveles en sus relaciones?

• ¿Cuáles son las aplicaciones envueltas y los elementos que lo componen?

• ¿El sistema tiene múltiple niveles?

• ¿Cuáles son los datos, mecanismos de control y comunicaciones utilizados?

 ¿Qué es lo que la imagen omite? (1)

¿Cuál es la naturaleza de los elementos?

• ¿Cuál es la significancia de su separación?

• ¿Existen en tiempo de ejecución?
• ¿Corren en tiempos separados?
• ¿Son procesos, programas o hardware?
• ¿Son objetos, tareas, funciones o procesos?
• ¿Son sistemas distribuidos?

¿Cuáles son las responsabilidades de los elementos?

• ¿Qué es lo que hacen?

• ¿Qué funciones proveen dentro del contexto del sistema?
 ¿Qué es lo que la imagen omite? (2)

¿Cuál es la significancia de las conexiones entre los elementos?

• ¿Los elementos se comunican unos con otros?

• ¿Los elementos se controlan uno con otros?
• ¿Los elementos comparten datos entre ellos?
• ¿Los elementos se usan los unos a los otros?
• ¿Los elementos se invocan entre ellos?
• ¿Los elementos se sincronizan?

¿Cuál es la significancia de cómo los elementos son posicionados en el diagrama?

• Por ejemplo: ¿ShopKwik usa, llama, controla, y/o contiene a Personalization

Services, Reporting Services o Order Management Services?
 Implicaciones de la Definición (1)

Una arquitectura de software es la abstracción de un sistema. La arquitectura:

• Define los elementos y como se relacionan entre ellos.

• Elimina detalles de que es lo que hacen internamente los elementos y de su

información interna local. Los detalles internos no forman parte de la
arquitectura.

• Los detalles internos de los elementos no afectan como es que esos

elementos son usados o como es que se relacionan o interactúan con otros
elementos.
 Implicaciones de la Definición (2)

El término “propiedades” se refiere a aquellos supuestos que un elemento puede

hacer sobre otro elemento como:

• Qué servicios es el que provee.

• Cómo se desempeña.
• Cómo se manejan las fallas.
• Cómo usa los recursos compartidos.

Los elementos interactúan entre sí por medio de interfaces cuyos datos se

encuentran en partes publicas y privadas.

La arquitectura se enfoca en la parte pública.

 Implicaciones de la Definición (3)
Los sistemas pueden tener muchas estructuras:

• El número de estructuras candidatas no es fijo ni pre-definido.

• Las relaciones y los elementos se pueden relacionar en tiempo de ejecución:

 “se envía datos a”, “invoca” o “se emite señal a”

 Procesos o tareas

• Las relaciones y los elementos se pueden relacionar también en tiempo que

no es de ejecución:

 “es un sub-modulo de”, “hereda de”, “es colocado al equipo X para

implementar …”
 Un clase o librería
 Implicaciones de la Definición (4)
Todo sistema tiene una arquitectura:

• Todo sistema es compuesto de elementos y sus relaciones entre ellos.

• En el caso más simple, un sistema está compuesto de un solo elemento

relacionado solamente a el mismo.

• El solo hecho de tener una arquitectura es diferente de tener una arquitectura

que es conocida por todos:

• ¿Es la arquitectura “real” la misma como la de la especificación?

• ¿Cuál es la “razón fundamental” (rationale) de las decisiones arquitecturales?

• Si no desarrollas explícitamente una arquitectura, igual obtendrás una de todas

maneras – y quizás no te llegue a gustar lo que obtuviste.
 Implicaciones de la Definición (5)
Solo los diagramas de “líneas y cajas”, solo ellos, no son arquitecturas: ellos son un
punto de partida.

• Se puede imaginar, quizás, el comportamiento de una caja o elemento

etiquetado como “base de datos”.

• Se necesita agregar especificaciones y propiedades a los elementos y sus

relaciones.

• Finalmente, la definición de arquitectura es indiferente a que si la arquitectura del

sistema es buena o mala.
• Una buena arquitectura es aquella que permite al sistema lograr su
funcionalidad, atributos de calidad, y el ciclo de vida de sus requerimientos.
 Patrones, Modelos de Referencia, y
Arquitectura de Referencia
Los arquitectos se encontrarán siempre con los siguientes términos:

• Patrones Arquitecturales

• Modelos de Referencia

• Arquitecturas de Referencia

• Pero, ¿exactamente qué significan? ¿cómo están relacionadas con la arquitectura

de software?
 Patrones, Modelos de Referencia, y
Arquitectura de Referencia (2)
Un patrón de arquitectura es una descripción de los elementos y sus tipos de
relaciones, cómo es que son usados y sus restricciones.

• Los patrones definen familias de arquitecturas como cliente-servidor, tuberías

y filtros, etc.

• Los patrones muestran las propiedades de los atributos de calidad.

• La selección de un patrón de arquitectura es a menudo la primera decisión de

diseño de un arquitecto.

• El término estilo arquitectural ha sido también ampliamente usado para

describir patrones de arquitectura.
 Patrones, Modelos de Referencia, y
Arquitectura de Referencia (3)
Un modelo de referencia es una división de las funcionalidades dentro de los
elementos y el flujo de datos.

• Los modelos de referencia incluyen bases de datos y compiladores, entre otras

muchas cosas.

• Por ejemplo: los elementos de un compilador son conocidos como:

 Parseador
 Analizador léxico
 Generador de código
 Optimizador, ……

• El flujo de datos y la conectividad entre aquellas piezas son bien establecidas.

 Patrones, Modelos de Referencia, y
Arquitectura de Referencia (4)

Una arquitectura de referencia es un modelo de referencia que es mapeado dentro

de los elementos software que implementan la funcionalidad definida en el modelo.

• El mapeo no tiene que ser de uno a uno.

• Los elementos pueden implementar un función, partes de un función simple,

o muchas funciones.

• Plantillas, estándares, y herramientas aceleran el desarrollo y ayudan a los

implementadores para que se adhieran a las restricciones señaladas por la
arquitectura de referencia.
 Patrones, Modelos de Referencia, y
Arquitectura de Referencia (5)

Patrones de arquitectura, modelos de referencia, y arquitecturas de referencia; no

son arquitecturas; en su lugar, ellos proveen soluciones conocidas a varios problemas
de diseño que podemos adaptar e incorporar en nuestras arquitecturas.
 Rol de la Arquitectura de Software
Si el único criterio para un software es conseguir la respuesta correcta, entonces no
harían faltas las arquitecturas – no estructurado, sistemas monolíticos, serían
suficientes.
Pero, otras cosas también importan, como:

• Modificabilidad
• Tiempo de desarrollo
• Rendimiento
• Coordinación de equipos de trabajo

Los atributos de calidad, como los mencionados, son ampliamente dependientes en

las decisiones que se toman para definir una arquitectura.

• Todos los diseños implican concesiones entre los atributos de calidad

• Si pensamos tempranamente en las concesiones, mejor.
 ¿Por qué la arquitectura de software es
importante?
La arquitectura es importante por estas tres razones primarias:

• Provee un vehículo de comunicaciones entre stakeholders.

• Es la manifestación de las decisiones de diseño más temprana acerca de un

sistema.

• Es una abstracción transferible y reutilizable de un sistema.

 ¿Por qué la arquitectura de software es
importante?
La arquitectura es importante por estas tres razones primarias:

• Provee un vehículo de comunicaciones entre stakeholders.

• Es la manifestación de las decisiones de diseño más temprana acerca de un

sistema.

• Es una abstracción transferible y reutilizable de un sistema.

 Vehículo de Comunicaciones
La arquitectura provee un marco común de referencia en el que los intereses en
competencia pueden ser expuestos y negociados. Estos intereses incluyen:

• Negociar los requisitos con los usuarios.

• Mantener al usuario informado del progreso y costos.
• Implementar una gestión de decisiones y asignación

Arquitectos y desarrolladores usan la arquitectura como un guía en el proceso de

desarrollo:

• Se hace compatible con el análisis de la arquitectura

 ¿Por qué la arquitectura de software es
importante?
La arquitectura es importante por estas tres razones primarias:

• Provee un vehículo de comunicaciones entre stakeholders.

• Es la manifestación de las decisiones de diseño más temprana acerca de un

sistema.

• Es una abstracción transferible y reutilizable de un sistema.

 Primeras decisiones de diseño (1)
La arquitectura define restricciones en la implementación:

• La implementación debe ajustarse a las decisiones de diseño prescritos tales

como las relativas a:
 Elementos
 Interacciones
 Comportamientos
 Responsabilidades

• La implementación debe ser conforme a la asignación de recursos como

aquellos respectos a:
 Planificación de propiedades y tiempo de presupuestos
 Data compartida y repositorios

Las arquitecturas son tanto prescriptivas y descriptivas.

 Primeras decisiones de diseño (2)
La arquitectura dictamina la estructura de la organización:

• La arquitectura representa el más alto nivel de descomposición de un sistema

y es usado como una base para:
 Particionar y asignar el trabajo a realizar.
 Formular planes, cronogramas y presupuestos
 Establecer canales de comunicación entre los equipos
 Establecer planes, procedimientos y artefactos para la gestión de la
configuración, pruebas, integración, despliegue y mantenimiento.

Para razones de gestión, una vez establecido, una arquitectura se vuelve muy difícil
de cambiar.
 Primeras decisiones de diseño (3)
La arquitectura permite el logro de alcanzar los atributos de calidad del sistema
deseado. Las estrategias para lograrlo son entonces arquitecturales:

Si se desea …. Se necesita enfocarse en ….

Alto Rendimiento Minimizar la frecuencia y volumen de comunicación entre
elementos.
Modificabilidad Limitar la interacción entre elementos.
Seguridad Gestionar y proteger la comunicación entre elementos.
Reusibilidad Minimizar la interdependencias entre los elementos.
Disponibilidad Las propiedades y comportamientos que los elementos
deben de tener y los mecanismos que se emplearan para la
detección de fallas, prevención y recuperación.
Y muchos más …..
 Primeras decisiones de diseño (4)
La arquitectura permite predecir los atributos de calidad del sistema sin esperar a
que el sistema este completamente desarrollo o desplegado.

• Desde que la arquitectura influencia, en formas conocidas, en los atributos de

calidad, eso nos permite determinar que tan bien serán implementados los
atributos de calidad.

• Podemos analizar una arquitectura para evaluar que tan bien son logrados los
atributos de calidad.
 Primeras decisiones de diseño (5)
La arquitectura nos ayuda a razonar acerca de cómo gestionar los cambios de un
sistema durante su ciclo de vida.

Una arquitectura divide todos los cambios en tres tipos generales:

• Local: se modifica un elemento en especifico.

• No-local: se modifican muchos elementos.

• Arquitectural: se modifica el grueso de la topología del sistema, sus

mecanismos de comunicación y coordinación.
 Primeras decisiones de diseño (6)
Una vez que la arquitectura ha sido definida, puede ser analizada y prototipada
como un esqueleto de sistema. Esto contribuye al proceso de desarrollo en tres
formas:

• La arquitectura puede ser implementada como un marco esquelético en que

los elementos puede ser conectados (plugged).

• Los elementos riesgosos de un sistema pueden ser identificados vía la

arquitectura y mitigados con prototipos específicos.

• El sistema puede tener una versión ejecutable más tempranamente en el ciclo

de vida del producto. La fidelidad del sistema aumenta a medida que los
elementos prototipados son reemplazados por elementos terminados.
 Primeras decisiones de diseño (7)
La arquitectura permite un costeo más preciso, un cronograma con tiempos mejor
determinados, mejora el planeamiento del proyecto y su seguimiento.

• A medida que se tiene mayor conocimiento acerca del alcance y la estructura

de un sistema, nuestras estimaciones serán mejores.

• Los equipos asignados a elementos específicos de un arquitectura podrán

proveer estimaciones más precisas.

• Los gestores de proyectos podrán resolver dependencias y conflictos.

 ¿Por qué la arquitectura de software es
importante?
La arquitectura es importante por estas tres razones primarias:

• Provee un vehículo de comunicaciones entre stakeholders.

• Es la manifestación de las decisiones de diseño más temprana acerca de un

sistema.

• Es una abstracción transferible y reutilizable de un sistema.

 Transferible, abstracción reusable (1)

La arquitectura de software constituye un modelo que es transferible para sistemas

similares.

• La arquitectura de software puede servir como la base de un programa de

reutilización estratégica, que puede incluir:

 Requerimientos
 Artefactos de apoyo al desarrollo (plantillas, herramientas, etc.)
 Código
 Componentes
 Experiencia
 Estándar
 Transferible, abstracción reusable (2)

La arquitectura es fundamental para la producción de líneas de productos de

software.

Una línea de producto software es un conjunto de sistemas intensos de software

compartiendo un común y gestionado grupos de características que satisfacen las
necesidades de un particular de un segmento de mercado o misión, y que además
son desarrollados desde un conjunto de activos principales de manera prescrita 1.

Las línea de productos de software es una poderosa aproximación al desarrollo de

múltiples sistemas que han demostrado beneficios en términos de magnitud en el
tiempo de comercialización, costos, productividad y calidad del producto.

Clements, P. & Northrop, L. Software Product Lines, Practices and Patterns. Boston, MA: Addison-Wesley, 2002
 Transferible, abstracción reusable (3)

La arquitectura soporta la construcción de sistemas basados en grandes

componentes, que se desarrollan de forma independiente.

• El desarrollo basado en la arquitectura se centra en la composición de sus

elementos, en lugar de cómo se programan.

• La composición es posible porque la arquitectura define que elementos

pueden ser incorporados dentro del sistema, así como permite entender en
que forma son limitadas.

• El enfoque en la composición provee el intercambio de componente.

• El intercambio es clave para permitir que los elementos de software de

terceros, subsistemas e interfaces de comunicación; puedan ser usados como
elementos de la arquitectura.
 Transferible, abstracción reusable (4)
La arquitectura permite el desarrollo basado en plantillas.

• La arquitectura encarga decisión de diseño acerca de cómo interactúan los

elementos. Estas decisiones pueden ser localizados y escritos una sola vez.

• Las plantillas pueden ser usada para codificar los marcos de trabajo de
interacción de los elementos.
 El desarrollador se enfoca en partes únicas/particulares y re-usa partes
comunes.

• Las plantillas aceleran el desarrollo e incrementa la confiabilidad.

 La fuente de muchos errores es eliminada.
 Corregir la causa de un error permite mejoras en varios lugares.

 El diseño orientado a aspectos es un enfoque moderno para hacer frente a

muchas de estas preocupaciones.
 Estructuras Arquitecturales (1)

El cuerpo humano Una vista estática Una vista

comprende de una de aquellas dinámica de la
múltiples estructuras misma estructura
estructuras
 Estructuras Arquitecturales (2)

Estas vistas son

necesarias para … pero no para un
un cardiólogo traumatologo

Diferentes stakeholders están interesados en diferentes estructuras

 Estructuras Arquitecturales (3)
Los sistemas de software modernos son demasiado complejos para entenderlos y
analizarlos todos a la vez. En cualquier momento, restringimos nuestra atención a un
pequeño número de estructuras del sistema software.

Para comunicarse de manera significativa una arquitectura, hay que dejar en claro
qué estructura o estructuras que estamos discutiendo.
 Estructuras Arquitecturales (4)

Las estructuras arquitecturales de un Sistema software puede ser dividido en tres

tipos:

1. Estructura de Modulo: consiste de elementos que son unidades de

implementación llamadas módulos y las relaciones entre ellos.

2. Estructura Componente & Conector: consiste de componentes en tiempo de

ejecución (unidades de computo) y los conectores (rutas de comunicación) entre
ellos.

3. Estructura de Localización: consiste de elementos software y sus relaciones a

elementos en ambientes externos en los cuales el software es creado y
ejecutado.
 Ejemplos de Estructuras de Módulo

Estructura de Descomposición: consiste de módulos que con relacionados vía la

relación de “es sub-módulo de”

Estructura de Uso: consiste de módulos que son relaciones vía la relación “uses” (es
decir, un módulo usa los servicios provistos por otro módulo).

Estructura de Capas: consiste de módulos que son particionados dentro de grupos

de coherente y relacionada funcionalidad. Cada grupo representa una capa en la
estructura general.

Estructura Clase/Generalización: consiste de módulos llamados clases que son

relacionados mediante el “hereda de” o “es una instancia de” en sus relaciones.
 Ejemplos de Estructuras Componente &
Conector

Estructura de Proceso: consiste de procesos o hilos que son conectados mediante

comunicación, sincronización y/o operaciones de exclusión.

Estructura de Concurrencia: consiste de componentes y conectores donde los

conectores representan “hilos lógicos”.

Estructura de Data Compartida (Repositorio): consiste de grupos de conectores que

crean, almacenan y acceden a data persistente.

Estructura Cliente/Servidor: consiste de la cooperación de clientes y servidores, y de

sus conectores (es decir, los protocolos y los mensajes que se comparten).
 Ejemplos de Estructuras de Localización

Estructura de Despliegue: consiste de los elementos software y sus localizaciones al

hardware y elementos de comunicación.

Estructura de Implementación: consiste de elementos software y su mapeo a

estructura de archivos en el desarrollo, integración y ambientes de control de la
configuración.

Estructura de Asignación de Trabajo: Consiste de módulos y como ellos son

asignados al responsable de los equipos de desarrollo para la implementación e
integración.
 Resumen de las Estructuras Arquitecturales

Los arquitectos deben enfocarse en aquellas estructuras que le proveerán mayor

influencia en la consecución de los atributos de calidad del sistema.
 ¿Qué lo que hace que una Arquitectura sea
“Buena”?

No hay tal cosa como una arquitectura inherentemente buena o mala.

Las arquitecturas son más o menos aptos para algún propósito.

Las arquitecturas pueden ser evaluadas, pero sólo en un contexto declarado con
objetivos específicos.

Sin embargo, existen las denominadas “buenas reglas”.

 Proceso – “Buenas Reglas”
La arquitectura debe ser el producto de un solo arquitecto o un pequeño grupo de
arquitectos con un líder técnico identificado.
 Este enfoque conduce a la integridad conceptual y coherencia técnica.
 Esta recomendación es válida para los proyectos agiles y de open source, así
como los "tradicionales".
 Debe haber una fuerte conexión entre el arquitecto (s) y el equipo de
desarrollo.
El arquitecto (o equipo de arquitectura) debe basar la arquitectura en una lista
priorizada de los requisitos de los atributos de calidad bien especificadas.

La arquitectura debe ser evaluada por su capacidad de ofrecer importantes atributos

de calidad del sistema.

La arquitectura debe ser un proceso de aplicación gradual.

 Crear "esqueleto“ del sistema en el que las vías de comunicación se ejercen,
pero que al principio tiene una funcionalidad mínima.
 Estructura – “Buenas Reglas”
La arquitectura debe ofrecer módulos bien definidos cuyas responsabilidades
funcionales se les asigna en los principios de ocultación de información y la
separación de las capas.
 Los módulos de información ocultos deben encapsular cosas que puedan
cambiar.
 Cada módulo debe tener una interfaz bien definida que encapsula o "esconde"
los aspectos cambiantes de otro software.
A menos que los requerimientos sean excepcionales, los atributos de calidad deben
de ser abordados usando patrones de arquitectura conocidos.

La arquitectura no debe depender de una versión particular de un producto

comercial o herramienta. En caso se requiera, se deberá estructurar de modo que el
cambio a una versión diferente sea sencilla y barata.

Los módulos que producen datos deben estar separadas de los módulos que
consumen datos.
 Estructura – “Buenas Reglas”

No hay que esperar una correspondencia uno a uno entre los módulos y
componentes.

La arquitectura deberá caracterizar un pequeño número de maneras para que los

componentes interactúen.

 El sistema debe hacer las mismas cosas de la misma manera en todas partes.

 Esto ayudará en la comprensibilidad, reducir el tiempo de desarrollo,

aumentar la fiabilidad y mejorar la capacidad de modificación.
 Resumen

La arquitectura es importante porque:

• Provee un vehículo de comunicaciones entre stakeholders.

• Es la manifestación de las decisiones de diseño más temprana acerca de un
sistema.
• Es una abstracción transferible y reutilizable de un sistema.

Una arquitectura se compone de muchas estructuras, cada una de las cuales

comprende elementos de software y sus relaciones.