UNIDAD IV: DOCUMENTANDO LA ARQUITECTURA DE SOFTWARE

SESION 15: METODOS DISEÑO Y USO DE ARQUITECTURA DE

SOFTWARE
 LOGRO Y CONTENIDO DE LA SESIÓN DE CLASE

• LOGRO DE SESIÓN:
Al término de la sesión, el estudiante conoce los distintos métodos de evaluación de
arquitecturas de software que le ayudarán a detectar riesgos en ésta.

• TEMAS A TRATAR

 Método Diseño y Uso de Arquitecturas

 COMPLEJIDAD ARQUITECTÓNICA

• Para evaluar la complejidad total de una arquitectura, una técnica consiste en

considerar las relaciones de dependencia entre los componentes de la
arquitectura.

• Existen 3 tipos de dependencias:

 Dependencias de compartimiento:
 Representan las relaciones de dependencia entre los consumidores que utilizan
los mismos recursos o los productores que producen para los mismos
consumidores.

 Dependencias de flujo
 Representan las relaciones de dependencias entre los productores y los
consumidores de recursos.

 Dependencias restrictivas
 Representan las restricciones de un relativo flujo de control entre un cuadro de
actividades.
TÉCNICAS DE EVALUACIÓN DE LAS ARQUITECTURAS

• Técnicas de evaluación
Existen diversas técnicas de evaluación de arquitectura de software, que se
describen a continuación:

• Checklists y cuestionarios
El uso de checklist (listas de verificación) y cuestionarios para realizar revisiones
e inspecciones del diseño que se ha producido.

Realizarlos de forma efectiva, no es una tarea trivial. Checklist y cuestionarios

deben enfocarse sobre cuestiones de fondo del diseño más que de forma.
Algunos ejemplos de preguntas y comentarios al respecto, se muestran a
continuación:
TÉCNICAS DE EVALUACIÓN DE LAS ARQUITECTURAS

• Evaluación basada en escenarios

Las evaluaciones basadas en escenarios son una técnica más efectiva que la anterior, sin
embargo, se trata también de una técnica más costosa y más compleja de implantar.

La evaluación basada en escenarios, toma como entrada escenarios que pueden ser de
atributos de calidad (como los descritos arriba) o bien funcionales (por ejemplo, el flujo
principal de algún caso de uso).

Los escenarios son usados por un equipo de evaluación para cuestionar al arquitecto
sobre las decisiones de diseño que tomó y el arquitecto debe ser capaz de
argumentar de manera convincente que el diseño planteado satisface o no los
escenarios sobre los cuales se le está cuestionando.
• Proceso de
Evaluación de
Escenarios
DESARROLLO BASADO EN ARQUITECTURAS

Los pasos de dicho proceso son:

• Obtención de los requerimientos de la arquitectura.-
Este paso genera un listado de:

a) Los requerimientos funcionales (casos de uso)

b) Requerimientos arquitectónicos específicos
c) Escenarios de calidad.

• Diseño de la arquitectura.-
Esta fase de diseño esta expresada en vistas arquitectónicas como:

a) Funcional
b) Código
c) Concurrencia
d) Física y
e) Desarrollo.
DESARROLLO BASADO EN ARQUITECTURAS

• Documentación de la arquitectura.- Se diseña para que sirva de base y soporte a los

programadores y analistas. En esta fase los autores dan una serie de recomendaciones
para generar una documentación mantenible.

• Análisis de la arquitectura.- Evalúa la arquitectura para identificar riesgos potenciales y

verificar los requerimientos de calidad que han sido tomados en cuenta en el diseño.
Dicha evaluación se hace por medio del método ATAM (Architecture Tradeoff Analysis
Method).

• Generación de la arquitectura.- Codificación de la arquitectura a partir del diseño

generado.

• Mantenimiento de la arquitectura.- En esta fase se dan una serie de recomendaciones

para tener una arquitectura mantenible, ya que consideran que es un riesgo no tener la
arquitectura documentada y consistente con las decisiones de diseño.

(*) ATAM: Método de análisis de la compensación de arquitectura

 WEBSA

• WebSA es una metodología para la definición de arquitecturas software de las

aplicaciones web, la cual se basa principalmente en 2 aspectos:

1. La definición de la arquitectura a través del paradigma DSSA (Domain Specific

Software Architecture),es decir, de las arquitecturas software de dominio
específico, que en su caso fija el dominio en el desarrollo de aplicaciones web.

2. Se basa en la definición de arquitecturas mediante múltiples vistas concurrentes,

para ello se vale de la utilización del estándar MDA (Arquitectura dirigida por
modelos), que nos permite definir un conjunto de modelos UML, dándole la
formalidad necesaria con la utilización de estándares como MOF para la
definición de los elementos de modelado, y de OCL, para la definición de
restricciones.

(*) OCL Object Constraint Language)

 WEBSA Y VENTAJAS

• DSSA se basa en la siguiente asunción:

"El desarrollo de sistemas en un dominio bien conocido es un proceso de
emparejamiento de los requerimientos hacia aproximaciones conocidas para
aportar soluciones en ese dominio”.

Las principales ventajas que nos aporta la aproximación MDA son:

 Integración con sistemas legados .

 Utilización de estándares como UML, XMI, CWM que nos proporcionan la posibilidad
de intercambiar nuestros modelos a cualquier herramienta que sea compatible UML.

 La formalización a través MOF (Meta-Object-Facility) y OCL (Object Constraint

Language) de todos los modelos definidos a partir de UML.

 Reducción de costos durante todo el ciclo de vida de la aplicación.

 Rápida inclusión de los beneficios de las tecnologías emergentes en sus sistemas

existentes.
(*) DSSA (Domain Specific Software Architecture)
(*) MDA Arquitectura dirigida por modelos
WEBSA – PUNTOS DE VISTA

Punto de Vista de Requisitos:

Realizado durante la fase de requisitos, en el, los analistas

recogen la información necesaria a partir de la cual vamos a
especificar el sistema.

1. Vista Requisitos Funcionales: En dicha vista se expresan

mediante los casos de uso que recogerían los requisitos
funcionales.
2. Vista Requisitos No Funcionales: En esta vista se expresan
mediante escenarios de calidad los requisitos no funcionales.
3. Vista Conceptual: Expresa la funcionalidad del sistema de
información sobre el que se define la aplicación.
WEBSA – PUNTOS DE VISTA

Punto de Vista Funcional:

A partir de los requisitos de usuario especificados en la fase

anterior se definen un conjunto de vistas que van a recoger la
funcionalidad de un sistema web.

4. Vista de Presentación: Se preocupa de indicar cual va a ser

el aspecto de la aplicación y la funcionalidad asociada a esta.
5. Vista de Navegación: Expresa cada una de las interacciones
que el usuario realiza para transcurrir a través de los
diferentes escenarios de la aplicación.
6. Vista Procesos: Expresa cuales son las actividades de los
procesos y el flujo de los procesos, estableciendo que
actividades deben procesarse en secuencia o en paralelo.
WEBSA – PUNTOS DE VISTA

Punto de Vista de Arquitectura:

A partir de requisitos funcionales y no funcionales se definen las vistas
que tradicionalmente se han denominado de arquitectura, y son la
principal aportación:

7. Vista de la Arquitectura Lógica: expresa cuales son los

componente lógicos (subsistemas, módulos o componentes
software) que participan en nuestra solución y la relación entre
ellos.

8. Vista de la Arquitectura Física: expresa cuáles son los

componentes físicos que participan en nuestra solución y la
relación entre ellos(clientes, servidores, redes, BD, etc)
MODELO GENERAL (VISTAS)
EVOLUCION WEBSSA
¿¿¿PREGUNTAS???