Unidad 1.

Introducción a la
Arquitectura de Software
 Definición y conceptos básicos de Arquitectura de
Software.
 Notaciones para describir la Arquitectura de Software: el
lenguaje de modelado UML, el modelo 4+1
 El proceso de desarrollo de la Arquitectura de Software.
 Arquitectura y atributos de calidad del sistema.
 Calidad en la arquitectura de software.
Introducción

 La creación de grandes aplicaciones de

software es uno de los retos más importantes
de la Ingeniería de Software de los tiempos
modernos
Actividades básicas de la IS
 Análisis de requerimientos.
 Diseño del producto
 Diseño de alto nivel o Diseño Arquitectónico
 Diseño detallado
 Implementación (codificación) e Integración
 Prueba (producto completo) y Aceptación del
producto.
 Mantenimiento del producto.
Proceso de desarrollo de software
 El subproceso para el desarrollo de la Arquitectura
Software (AS). Punto de vista actual
Diseño arquitectónico.
 Comprende las actividades para el establecimiento de
un marco de trabajo estructural para un sistema
software.

 Establecer la estructura general del software, compuesta

por los componentes y la manera en que éstos
interactúan.
Arquitectura del Software
 Es la estructura del sistema, que incluye los
componentes del software, las propiedades visibles
externamente de esos componentes y las relaciones
entre ellos. (Bass, Clement)

 La Arquitectura de Software es la organización

fundamental de un sistema encarnada en sus
componentes, las relaciones entre ellos y el ambiente y
los principios que orientan su diseño y evolución (Microsoft)
Otras definiciones de Arquitectura software

 Una Arquitectura de software, también denominada Arquitectura

lógica, consiste en un conjunto de patrones y abstracciones
coherentes que proporcionan el marco de referencia necesario para
guiar la construcción del software.

 La vista arquitectónica es una vista abstracta, que aporta el más

alto nivel de comprensión y suprime detalles.
[Clements 1996]
Analogía
Ejemplo

diagrama de paquetes UML con la arquitectura para el sistema

SITFO (aplicación centralizada).
Definición de conceptos básicos
 Componente (concepto convencional)
 Un componente es un elemento funcional de un sistema que
incorpora la lógica de procesamiento, las estructuras internas de
los datos necesarios para implementar dicha lógica y una interfaz
que permita la invocación del componente y el paso de datos.
 Conector
 mecanismo que mediatiza la comunicación, coordinación o
cooperación entre componentes;
 (rpc, protocolos, streams, etc.).
Definición de conceptos básicos

 Configuración
 Estructura organizativa de los componentes.

 Estilo arquitectónico
 Un estilo arquitectónico expresa los componentes
y las relaciones entre ellos, con las limitaciones
de su aplicación, así como la composición y el
diseño de normas asociadas a su construcción.
Estilos de Arq. de Sw
 Indican:
 Los tipos de componentes y conectores involucrados.
 Patrones y restricciones de interconexión o
composición entre ellos
 Invariantes del estilo (restricciones)

 Asociados a cada estilo hay una serie de

propiedades que lo caracterizan
 Determinan sus ventajas e inconvenientes
 Condicionan la elección de uno u otro estilo.
Analogía con los estilos arquitectónicos de
la arquitectura convencional
Definición de conceptos básicos
 Patrón arquitectónico
 El patrón arquitectónico especifica un conjunto predefinido de
componentes con sus responsabilidades y una serie de
recomendaciones para su organización.
Definición de conceptos básicos
 Arquitectura de
referencia
 Una arquitectura
de referencia
proporciona una
plantilla de
solución probada
para la
arquitectura
software de
aplicaciones en
un dominio
particular.
Actividad 1

 Investigar y analizar las diferencias entre los conceptos

de estilo de arquitectura, patrón arquitectónico,
arquitectura de referencia y arquitectura de software.
Colocar la descripción y preferentemente un ejemplo de
cada uno (imagen de un estilo, un patrón, etc.), al final
su análisis sobre las diferencias.
Definición de conceptos básicos
 Proceso
 Conjunto de procedimientos o funciones que tienen
uno o más objetivos.
 Conjunto de actividades sistemáticas que persiguen
un fin. Se amolda a un modelo de proceso.

Modelo de Proceso iterativo e incremental

 Notaciones para describir la Arquitectura
del Software
 Existen lenguajes especializados para la descripción de
arquitecturas de software denominados ADL, que expresan la
estructura de las aplicaciones.
 Proporcionan modelos, notaciones y herramientas que permiten describir los
componentes y sus enlaces específicos.
 Se emplean para desarrollar prototipos rápidos y verificación formal de
propiedades.
 Entre algunos:
 ACME
 Aesop
 Artek
 C2
 Darwin
 SADL
 Wright
 Notaciones para describir la Arquitectura
del Software
 El lenguaje de modelado UML.
 Es un lenguaje gráfico para visualizar, especificar,
construir y documentar los artefactos de un sistema.

 Proporciona una forma estándar de escribir los planos

de un sistema, cubriendo tanto aspectos
conceptuales, funciones del sistema, como elementos
concretos: clases, esquemas de BD y componentes.
Modelado en UML
 Técnica para modelar la Arquitectura del
Software.
Una técnica para el modelado de la Arquitectura del Software se conoce como
El modelo de “4+1” vistas de la Arquitectura del Software. Esta técnica
describe la forma para crear los modelos arquitectónicos, divide al sistema en
cinco vistas concurrentes (Kruchten, 1995):
• Vista Lógica: Describe la estructura estática del
sistema, la abstracción del dominio del problema.
• Vista Física: describe el mapeo de la aplicación
en el hardware (la red de computadoras) y refleja
los aspectos de distribución
• Vista de Procesos: Describe los hilos y procesos
de ejecución así como la comunicación entre estos
(concurrencia y sincronización).
• Vista de Desarrollo: describe la organización
estática del software en su entorno de desarrollo.
• Vista de escenarios: que contiene requisitos
desarrollados en las restantes vistas.
Esta técnica requiere de
un lenguaje de modelado
para elaborar las vistas
 Actividad 2.
 Leer y analizar el artículo del modelo de 4+1 vistas de
Kruchten
El modelo 4+1 vistas de la Arquitectura del Software
Escenarios directos:
 Vista de escenarios E1. Un cuentahabiente consulta el saldo de su(s) cuenta(s).
ud Use Case Model
E2. Un cuentahabiente retira efectivo.

E3. Un cuentahabiente transfiere saldo entre cuenta propias.

tranferir saldo
consultar saldo
entre cuentas E4. Un cuentahabiente transfiere saldo a otras cuentas del mismo
banco.

E5. Un cuentahabiente programa transacciones.

transferir saldo programar
transacciones
otras cuentas E6. Un cuentahabiente paga servicios.

E7. Un cuentahabiente cambia su contraseña.

retirar efectiv o E8. Un cuentahabiente cambia su clave de transacciones.

pagar serv icios

E9. Un cuentahabiente imprime su comprobante de saldo

E10. Un cuentahabiente traspasa efectivo a otros bancos.

cambiar
cambiar cv e
contraseñas
cuentaHabiente
transacciones E11. Cuando un cuentahabiente realiza operaciones sobre sus
cuentas debe iniciar sesión.

E12. Un ejecutivo desbloquea cuentas bancarias.

imprimir
desbloquear ctas
comprobante
E13. Un ejecutivo imprime saldos totales de clientes.

E14. Un ejecutivo visualiza reporte de actividad (en línea y ATM) del

realizar traspasos imprimir saldos cliente.
otros bancos totales por cliente
«include»
E15. Cuando un ejecutivo manipula cuentas bancarias debe iniciar
«include» ej ecutiv o sesión.
v isualizar reporte
Iniciar sesión
«include»
de activ idades
Escenarios indirectos
cliente

E16. Permitir la integración del módulo ejecutivo (SWING) con el

Banco en línea.
Modelo de casos de uso de “Banco en Línea/ATM”
 El modelo 4+1 vistas de la Arquitectura
Software
Vista Lógica

ud Data Model2

«architectural»
AdmorUsuarios

comunica

«architectural»
«architectural» AdmorAcceso
AdmorMov imientos

comunica
notifica
«architectural»
AdmorCuentas

Vista lógica de un sistema de venta de Vista lógica del sistema de

boletos Banco en Línea/ATM
Vista lógica del sistema de Banco en
Línea/ATM a nivel caso de uso
El modelo 4+1 vistas de la Arquitectura
Software
Vista de desarrollo Sistema de Banca en Línea
El modelo 4+1 vistas de la Arquitectura
Software
Vista Física o de despliegue Sistema de Banca en Línea
en UML
Vista física o de despliegue
(no en UML)
El modelo 4+1 vistas de la Arquitectura
Software
Vista de procesos
El proceso de desarrollo de la Arquitectura
de Software.

 De manera general, las tareas que se realizan para el

desarrollo de una arquitectura software son:

identificación de los diseño de la arquitectura documentación de la evaluación y validación

requerimientos arquitectura de la arquitectura
arquitectónicos
Actividad 3.

Investigar las propuestas para el proceso de

desarrollo de una arquitectura software para
aplicaciones Web.
Identificación de los requerimientos
arquitectónicos
 La arquitectura de software se encuentra
influenciada por los involucrados o
interesados en el desarrollo del sistema de
software, la organización para la que está
siendo desarrollado, los requerimientos no
funcionales, el ambiente técnico y la
experiencia del arquitecto.
Identificación de los requerimientos
arquitectónicos
 El análisis de requerimientos se realiza considerando
diferentes perspectivas del sistema ( Cliente, usuario,
programador, arquitecto, etc.)
 El documento de requerimientos debe contener
requerimientos funcionales (alto nivel) y requerimientos no
funcionales.
 Una arquitectura de software, está basada de forma muy
importante en requerimientos no funcionales del sistema,
atributos como: desempeño, confiabilidad, seguridad,
facilidad de modificación, facilidad de uso, robustez,
portabilidad, escalabilidad, reutilización, disponibilidad,
etcétera.
El Diseño de la Arquitectura
Decisiones a tomar:
 Analizar si existe una arquitectura genérica que pueda usarse.
 Descomponer el sistema en partes o elementos identificando el
estilo arquitectónico o estilos a aplicar (definir componentes).
 Decidir qué elementos deben subdividirse y qué elementos derivan
de otros.
 Asignar funcionalidad a los elementos.
 Definir estrategias de control global
 Definir protocolos de comunicación y sincronización
 Definir la distribución física de los elementos y su replicación
 Definir una biblioteca de componentes reutilizables en el dominio.
 Elegir lenguajes y herramientas.
Diseño físico de la arquitectura
software
 Toda arquitectura debe ser implementarle en
una arquitectura física, que consiste
simplemente en determinar qué computadora
tendrá asignada cada tarea.
Diseño de la arquitectura

 Al diseñar una arquitectura de software se

debe crear y representar componentes que
interactúen entre ellos y tengan asignadas
tareas específicas, además de organizarlos
de forma tal que se logren los requerimientos
establecidos. Se puede partir con patrones
de soluciones ya probados.
Diseño de la arquitectura

 Estas soluciones probadas se conocen como

estilos arquitectónicos, patrones
arquitectónicos, arquitecturas de referencia y
patrones de diseño, respectivamente de lo
general a lo particular.
Documentación de la arquitectura
 La documentación del diseño de la arquitectura de
software cumple varios propósitos importantes. Entre
ellos están:

• Comunicar a los distintos involucrados el diseño de alto

nivel y las decisiones que permitieron llegar a éste.

• Permitir realizar análisis y evaluación del diseño.

• Soportar las actividades de mantenimiento

Documentación de la arquitectura
 Las estructuras del diseño arquitectural se documentan de forma
separada a través de distintas vistas. Cada vista modela una parte
del diseño arquitectural desde distintas perspectivas que pueden
ser por ejemplo dinámicas, lógicas o físicas.
 Es conveniente usar un enfoque preestablecido que sirve de guía
en la elección y organización de las vistas. Entre algunos:
 El modelo 4+1 vistas de la arquitectura que está asociado a RUP.
 IEEE 1471, es un estándar de la IEEE para la descripción arquitectural de
sistemas complejos.
 Views and Beyond . Enfoque desarrollado por el SEI, establece que la
documentación de la AS involucra la elección de las vistas relevantes de la AS,
emplea plantillas estándar para documentar las vistas, no especifica el número
de vistas a usar.
 Actividad Grupal
 Realizar el documento de arquitectura
software para un ejemplo de un sistema
bancario
 Evaluación y validación de la
arquitectura
 ¿Por qué evaluar?
 Entre más temprano se encuentre un problema
mucho mejor
 La evaluación es un mecanismo relativamente barato
para evitar desastres.
 Puede realizarse en etapas tempranas (durante el
diseño y antes de implementarla) y tardías
( implementación de AS terminada).
 Participantes: Equipo de evaluación y stakeholders.
 La evaluación identificará riesgos.
 Arquitectura y atributos de calidad del
sistema
 Los atributos de calidad son la base para la
definición de la AS y para su evaluación.
 Pero… simplemente nombrarlos no es
suficiente
 “.. El sistema debe ser robusto”
 “.. El sistema debe ser altamente modificable”
 Existen en el contexto de objetivos
específicos y se deben priorizar.
Calidad en la arquitectura de
software
Principales características de calidad de la norma ISO 9126 ‐1 para
la medición de la calidad del software .
Calidad en la arquitectura de
software
Personalización del estándar del modelo de calidad para la AS
 Funcionalidad. La AS debe tener las suficientes funciones para las

tareas requeridas. Involucra dos aspectos.

 Tener las funcionalidades del sistema identificadas y documentadas.
 Se especifica la arquitectura en función de sus componentes y dicha composición
debe reunir los requisitos funcionales del sistema.

 Precisión. El sistema debe proporcionar resultados correctos, con

grado de precisión necesario.
 Tener identificados a los componentes con las funciones responsables de
cálculos de precisión.
 Tener métrica(s) para medir este aspecto.
Calidad en la arquitectura de
software
 Interoperabilidad. La AS presenta la capacidad de interactuar con
más sistemas.
 Tener identificados los conectores de comunicación con sistemas externos
especificados.
 Establecer si o no se tiene a los componentes middleware correspondientes.

 Seguridad. La AS tiene la capacidad para prevenir el acceso no

autorizado a programas y datos.
 Tener un mecanismo o dispositivo para llevar a cabo esta tarea.
 Establecer si o no, se tiene la presencia del mecanismo o dispositivo.