Patrones, Modelado Y Evaluación De Diseño de Arquitectura De Software

Andrade Freddy, López Erlyn, Rodríguez Aronsis, Vargas G Oscar M.

Enero 2024.
Universidad Politecnica Territorial “José Antonio Anzoáategui”, Barcelona

PNF Informática

Ingeniería De Software

Profesor, Ing Eleana Mendez.

Barcelona
 Indice

Introducción ..................................................................................................................................................... 4

La arquitectura de software. ............................................................................................................................5

Diferencia Entre Arquitectura de Software y Diseño de Software .................................................................. 6

Relación Entre Arquitectura de Software y Diseño de Software ..................................................................... 7

Propósito y Beneficio ....................................................................................................................................... 8

Patrones ........................................................................................................................................................... 9

Tipos de Patrones .............................................................................................................................................9

Patrones de Alto Nivel ....................................................................................................................................10

Estilos Arquitectónicos ...................................................................................................................................10

Estilos Arquitectónicos ...........................................................................................................................10

Llamadas y Retorno ................................................................................................................................11

Centrada en Datos ..................................................................................................................................11

Arquitectura de Flujo de Datos .............................................................................................................. 11

Orientación a Objetos ............................................................................................................................ 11

Arquitectura en Capas ............................................................................................................................11

Patrones de Diseño ........................................................................................................................................ 12

Componentes de un Patrón ................................................................................................................... 12

Tipos de Patrones ...................................................................................................................................12

Idioms .....................................................................................................................................................12

Componente ...................................................................................................................................................13

Propiedades de los Componentes ......................................................................................................... 13

Relaciones entre Componentes ............................................................................................................. 13

Vista de Arquitectura ..................................................................................................................................... 13

Arquitectura 4 + 1 .......................................................................................................................................... 13

Vistas .............................................................................................................................................................. 14

Vista Lógica. ........................................................................................................................................... 14

Vista de Desarrollo ................................................................................................................................. 14

Vista de Procesos ................................................................................................................................... 14

Vista Física .............................................................................................................................................. 15

Vista + 1 ..................................................................................................................................................15

Modelado de Diseño. ..................................................................................................................................... 15

Diseño de datos ......................................................................................................................................16

Modelo de Diseño .................................................................................................................................. 16

Diseño de interfaces ...............................................................................................................................16

Elementos de diseño de Interfaz ........................................................................................................... 16

Diseño de componentes ........................................................................................................................ 17

Definiciones y Conceptos sobre Evaluación de Arquitecturas .......................................................................17

Propósito de evaluar una Arquitectura ..........................................................................................................18

Momento para realizar una evaluación de Arquitectura .............................................................................. 18

Métodos de Evaluación de Arquitecturas ......................................................................................................19

Architecture Level Modifiability Analysis (ALMA) ..................................................................................21

Performance Assessment of Software Architecture (PASA) ..................................................................23

Scenario based Architecture Level UsabiliTy Analysis (SALUTA) ........................................................... 27

Survivable Network Analysis (SNA)SNA ................................................................................................. 29

Conclusión ...................................................................................................................................................... 33
 Introducción

El software se ha convertido en una parte esencial de nuestra vida diaria. Lo usamos para

trabajar, comunicarnos, entretenernos y mucho más. A medida que la complejidad del software

aumenta, la necesidad de una arquitectura bien diseñada se vuelve aún más importante.

La arquitectura de software es la estructura y organización interna del software. Define cómo se

interconectan sus diferentes partes y cómo interactúan con el entorno. Una arquitectura bien diseñada

puede mejorar significativamente la calidad, el rendimiento, la escalabilidad y la mantenibilidad del

software.

En este trabajo de investigación, abordaremos el tema de la arquitectura de software en

profundidad. Analizaremos su importancia, los diferentes estilos arquitectónicos, los patrones de diseño,

las técnicas de evaluación y las herramientas disponibles.

El objetivo de este trabajo es proporcionar una comprensión completa de la arquitectura de

software y su papel en el desarrollo de software de alta calidad.

Preguntas de investigación:

¿Qué es la arquitectura de software y por qué es importante?

¿Cuáles son los diferentes estilos arquitectónicos que se pueden utilizar para estructurar el

software?

¿Qué son los patrones de diseño y cómo pueden ayudar a mejorar la calidad del software?

¿Cómo se puede evaluar la arquitectura del software antes de comenzar la implementación?

¿Qué herramientas están disponibles para ayudar a los arquitectos de software en su trabajo?

Metodología:

Para abordar las preguntas de investigación, se utilizará una metodología de revisión

bibliográfica. Se analizarán libros, artículos científicos y otras fuentes de información relevantes para el

tema de la arquitectura de software.

 Resultados esperados:

Se espera que este trabajo de investigación proporcione una comprensión completa de la

arquitectura de software y su papel en el desarrollo de software de alta calidad. Se espera que los

resultados de la investigación sean útiles para estudiantes, profesionales de la industria del software e

investigadores.
 La arquitectura de software.

La arquitectura de software de un sistema muestra la organización o estructura del sistema y

explica el comportamiento esperado. La arquitectura de software apoya y proporciona una base sólida

sobre la que se puede construir el software.

Una estructura de software introduce un proceso y una base que soporta una serie de

decisiones y compensaciones de arquitectura. Estas decisiones incluyen la seguridad, el rendimiento y la

capacidad de gestión. Estas decisiones repercuten en última instancia en la calidad, el mantenimiento, el

rendimiento y el éxito general de la aplicación. Los problemas comunes y las consecuencias a largo plazo

tienen el poder de poner en riesgo tu sistema.

Los estilos arquitectónicos son patrones y principios de arquitectura de alto nivel que se utilizan

habitualmente en los sistemas modernos. La arquitectura del software hace uso de una combinación de

estilos arquitectónicos para formar un plano.

La arquitectura de software suele diseñarse en cuatro capas (algunos también lo hacen en tres),

que son, de arriba a abajo, capa de presentación, capa de servicio, capa de negocio y capa de datos.

La capa de presentación contiene componentes para que los usuarios interactúen con la

aplicación. Se encarga de procesar las entradas del usuario y devolverle la respuesta correcta.

La capa de servicio actúa como límite de la transacción y contiene tanto servicios de aplicación

como de infraestructura.

La capa de negocio incluye la funcionalidad principal de la aplicación.

La capa de datos es la capa más baja de una aplicación. Es responsable de la comunicación con

el almacenamiento de datos utilizado.

 Diferencia Entre Arquitectura de Software y Diseño de Software

La diferencia entre la arquitectura de software es una línea borrosa. Ambos conceptos se

apoyan mutuamente, aunque también tienen algunas diferencias significativas.

El diseño de software abarca el diseño de módulos o componentes individuales, mientras que, la

arquitectura de software abarca la arquitectura completa del sistema global.

El diseño de software define las propiedades detalladas particulares del sistema, mientras que la

arquitectura de software define las propiedades fundamentales.

El diseño de software se refiere a la creación de una especificación de requisitos de software

que ayuda a los desarrolladores a implementar el software. En cambio, la arquitectura se refiere al

proceso de creación de una estructura de alto nivel de un sistema de software completo.

 El diseño de software sienta las bases para la implementación del software, mientras que, la

arquitectura define la infraestructura de alto nivel del software.

Por lo general, en los modelos de cascada, el diseño del software es la fase inicial, mientras que,

la arquitectura del software es un plano que limita el diseño del software para evitar los errores típicos y

alcanzar los objetivos.

Los patrones de arquitectura de software son de microservicio, sin servidor y orientados a

eventos, mientras que, los patrones de diseño de software son de creación, estructurales y de

comportamiento.

El diseño de software se centra en la implementación, mientras que, la arquitectura de software

se centra en la estructura.

La arquitectura de software proporciona una base para gestionar la complejidad del sistema.

Sirve para coordinar los distintos componentes del sistema y permite el seguimiento durante el proceso

de desarrollo y las fases posteriores. Además, ayuda a garantizar que, el software cumpla todos los

requisitos y atributos de calidad, incluidos los objetivos de seguridad y rendimiento.

La arquitectura del software abarca los elementos esenciales que soportan el sistema, incluidos,

los elementos estructurales y el comportamiento y la colaboración de estos elementos. Por el contrario,

el diseño del software actúa como un plano sólo durante el proceso de desarrollo y guía fases y tareas

específicas, como la codificación, la integración, las pruebas y la integración. También ayuda a identificar

los requisitos del sistema y a establecer las expectativas de todo el equipo.

Relación Entre Arquitectura de Software y Diseño de Software

La arquitectura y el diseño de software hacen las mismas cosas, aunque la arquitectura de

software cubre todo el sistema mientras que el plano cubre la fase de implementación principalmente.
La arquitectura de software trabaja sobre la estructura de un sistema sin los detalles de la

implementación. La arquitectura también sugiere y rastrea cómo los elementos y componentes de un

sistema interactúan entre sí. El diseño de software profundiza en los detalles de implementación del

sistema. El diseño se ocupa de la selección de estructuras de datos y algoritmos, así como de los detalles

de implementación de los componentes individuales.

Las preocupaciones de la arquitectura y el diseño, a menudo, se superponen durante el ciclo de

vida del proyecto. A veces, las decisiones son más arquitectónicas, mientras que, otras veces, las

conclusiones se centran en el diseño y en cómo ayuda a conseguir esa arquitectura.

Otra forma de decirlo es que, la arquitectura es diseño, pero no todo el diseño es arquitectónico.

Las últimas tendencias en arquitectura de software asumen que el diseño evoluciona y el diseño

generalmente evoluciona durante las etapas de implementación del sistema. Así, el arquitecto de

software observa y prueba continuamente el formato frente a los requisitos del mundo real.

Propósito y Beneficio

La arquitectura de software crea una base firme para el ciclo de vida del proyecto de software

que hace que el proyecto y la plataforma sean más escalables.

Una arquitectura de software bien estructurada aumenta el rendimiento de la plataforma

mediante la reducción de costos y el uso óptimo de todo tipo de recursos.

Estudiar la arquitectura es una forma eficaz de evaluar los requisitos de la organización. La

arquitectura de software proporciona una visión global.

Dado que, la arquitectura de software abarca todo el ciclo de vida del proyecto, puede

identificar áreas para un posible ahorro de costos. Por ejemplo, la arquitectura puede sugerir que varios
sistemas de bases de datos pueden transferirse a un único sistema para reducir los costos de adquisición

y soporte de software.

La arquitectura de software apoya la reutilización de activos valiosos. Los activos reutilizables

pueden reducir el costo global de un sistema y también mejorar su calidad.

Proporciona una mejor capacidad de mantenimiento del código, cambios más rápidos en los

sistemas informáticos y una mayor calidad de la plataforma.

La arquitectura de software ayuda a gestionar la complejidad y los riesgos. Ayuda a reducir los

riesgos y las posibilidades de fracaso.

También crea una clara separación de preocupaciones para apoyar una mayor adaptabilidad.

La arquitectura de software reduce el tiempo de desarrollo.

La arquitectura de software facilita la comunicación con todas las partes interesadas. La

comunicación sobre sistemas complejos ayuda a las partes interesadas a entender las consecuencias de

los requisitos y a tomar las decisiones de diseño.

Patrones

Solución que puede utilizarse de manera repetida a problemas comunes.

Solución a un problema no trivial que es efectiva y reusable.

Ya ha resuelto un problema similar de manera correcta.

Se puede aplicar a problemas de diseño similares.

Tipos de Patrones

Patrones de Alto Nivel

Patrones de Arquitectura

Patrones de Nivel Medio

Patrones de Diseño

Patrones de Bajo Nivel

Idioms

Patrones de Alto Nivel

Se refieren a una forma de resolver problemas de arquitectura

Proporciona un conjunto de tipos de elementos ya establecidos

Especifica como se organizan las relaciones entre estos elementos

Es común que se combinen varios patrones al momento de diseñar una arquitectura

Estilos Arquitectónicos

Describen:

Los componentes (módulos, bases de datos, etc) que tienen una función específica

Conectores que permiten la colaboración entre componentes

Restricciones en la integración de componentes

Estilos Arquitectónicos

Arquitectura Centrada en Datos

Arquitectura de Flujo de Datos

Arquitecturas de Llamada y Retorno

Arquitecturas Orientadas a Objetos

Arquitecturas en Capas
 Llamadas y Retorno

Se basa en una comunicación de llamadas y retornos entre módulos

Se divide en arquitectura de programa principal y sub programas y Llamadas a

Procedimientos Remotos (basado en el modelo Cliente - Servidor)

Centrada en Datos

Se enfoca en el almacenamiento de datos al que tienen acceso otros componentes, Se

basa en un almacenamiento central y los componentes tienen acceso a él Arquitectura del

Pizarrón (Blackboard)

Arquitectura de Flujo de Datos

Se utiliza cuando hay transformaciones en secuencia sobre ciertos datos. Se basa en el

concepto de tuberías, los componentes (filtros) se comunican a través de conectores (pipe) o

tuberías

Orientación a Objetos

Los componentes de un sistema son datos y operaciones encapsulados y se comunican a

través del paso de mensajes

Arquitectura en Capas

Se tienen varias capas, cada capa se comunica con las capas inferiores o superiores a

través del paso de información y servicios

 Patrones de Diseño

Es una descripción de clases y objetos y la manera en que se comunican entre ellos. A través de

modificaciones, se adaptan para resolver ciertos problemas de diseños de un mismo contexto

Componentes de un Patrón

Nombre.

Describe el problema

Problema

Especifica cuando aplicar el patrón

Solución

Elementos que componen el diseño, como se relacionan y que responsabilidades tienen

asignadas

Tipos de Patrones

De creación. Definen como se crearán los objetos

De estructura. Se refieren a la estructura de clases y objetos

De Comportamiento. Indican la forma en que interactúan las clases u objetos

Idioms

Son los patrones de más bajo nivel

Se enfocan en problemas específicos relacionados con la implementación en un

determinado lenguaje

Ejemplos:

Convenciones de nombres

Formatos para código fuente

 Manejo de memoria

Componente

Un componente de software puede ser desde un módulo de un programa hasta incluir

bases de datos o sistemas de configuración entre clientes y servidores

Propiedades de los Componentes

Se refieren a las características que hacen posible la interacción entre

componentes No se especifican las propiedades internas de cada componente, por

ejemplo, detalles de funcionamiento o algoritmos

Relaciones entre Componentes

Las relaciones pueden ser tan sencillas como una invocación de un módulo a

otro hasta el protocolo de conexión con base de datos

Vista de Arquitectura

Las vistas se utilizan para representar la arquitectura del software en un solo diagrama Una vista

se define como la forma de presentar un modelo que describe un sistema de manera completa desde un

cierto punto de vista

Arquitectura 4 + 1
Describe la arquitectura de un sistema a partir de su representación en vistas

Vistas

Vista Lógica.

Representa los requisitos funcionales del sistema y lo que debe hacer Se representa a

través de los diagramas:

Diagramas de Clases

Diagrama de Secuencia

Utiliza mucho el esquema Orientado a Objetos

Vista de Desarrollo

También llamada de Despliegue

Se enfoca en la organización de los módulos que componen el software

Se representa a través de los diagramas:

Diagrama de Componentes

Diagrama de Paquetes

Diagramas de Estado

Es común utilizar un representación en capas

Vista de Procesos

Representa el flujo del trabajo del sistema en tiempo de ejecución

Se representa con los diagramas:

Diagramas de Actividad

Se utilizan tuberías y filtros, llamadas y retornos

Considera aspectos como la tolerancia a fallos

 Vista Física

Muestra como se reparten los componentes en los equipos que formarán el sistema

completo

Se representa a partir de los siguientes diagramas:

Diagrama de Despliegue

Considera la disponibilidad del sistema, tolerancia a fallos y escalabilidad

Vista + 1

También llamada Vista de Escenarios, está representada por el conjunto de los casos de

uso

Sirve como enlace entre las otras cuatro vistas

Identifica los componentes que implementados representan una funcionalidad.

Modelado de Diseño.

El diseño es una representación significativa de ingeniería de algo que se va a construir. En el

contexto de la ingeniería de Software el diseño se centra en cuatro áreas importantes:

- Datos

- Interfaces

- Componentes

La importancia del diseño del software se puede describir con una sola palabra, calidad.

Nos proporciona las representaciones del software que se pueden evaluar en cuanto a calidad.

Es la única forma de convertir los requisitos de el cliente en un producto de software.

Sirve como fundamento para todos los pasos siguientes del soporte de software. Sin un diseño

corremos el riesgo de construir un sistema inestable.

 Diseño de datos

Transforma el modelo del dominio de información que se crea durante el análisis en las

estructuras de datos que se necesitarán para implementar el software. Los objetos de datos, las

relaciones definidas en el diagrama relación entidad y el contenido de datos son la base de esta

actividad.

Un buen diseño de datos es importante por que puede conducir a una mejor estructura

de programa, a una modularidad efectiva y a una complejidad procedimental reducida.

Modelo de Diseño

Elementos del diseño de Datos:

• Conocido como arquitectura de datos.

• Representación con alto grado de abstracción.

• Refinamiento progresivo del modelo.

• En diversos proyectos esta arquitectura de los datos se vera reflejada en la

arquitectura del software.

• Base fundamental para un aplicativo.

Diseño de interfaces

Describe la manera de comunicarse el software dentro de sí mismo, con sistemas que

interoperan dentro de él y con las personas que lo utilizan. Una interfaz implica un flujo de

información (por ejemplo, datos y/o control) y un tipo específico de comportamiento.

Ayuda a minimizar el tiempo de entrenamiento para usar el sistema, genera

confiabilidad y mayor portabilidad.

Elementos de diseño de Interfaz

• Equivalente a un dibujo detallado de puertas y ventanas en un plano de una casa.

 • Se indica donde están localizadas las interfaces.

• Muestran como la información fluye hacia fuera o adentro del sistema.

• Interfaces Internas:

• Relacionado directamente con el diseño a nivel de componentes.

• Posibles comunicaciones al interior del sistema.

• Cada mensaje debe ser diseñado para ajustarse al patrón de comunicación.

Diseño de componentes

Transforma los elementos estructurales de la arquitectura del software en una

descripción procedimental de los componentes del software.

La información que se obtiene de EP, EC y de DTE sirve como base para el diseño de los

componentes.

Es importante ya que facilita la legibilidad, prueba y mantenimiento de cada

componente.

Elementos de diseño a nivel de componentes:

• Equivale a graficar los cuartos de una casa en un plano.

• Describen en detalle la estructura interna de un componente.

Definiciones y Conceptos sobre Evaluación de Arquitecturas

Arquitectura de Software:, según el estándar IEEE (Institute of Electrical and Electronics

Engineers) es la organización fundamental de un sistema basada en sus componentes, las relaciones

entre ellos y el ambiente y los principios que orientan su diseño y evolución.

 Componente: Es una parte de una arquitectura de software claramente identificable,

independiente a la aplicación en la que se utiliza y de otros componentes (partes), que describe y realiza

funciones específicas y claras dentro del contexto de la arquitectura.

Escenario: Un escenario consta de tres partes: el estímulo, el contexto y la respuesta. El estímulo

es la parte del escenario que explica o describe lo que el involucrado en el desarrollo hace para iniciar la

interacción con el sistema. Puede incluir ejecución de tareas, cambios en el sistema, ejecución de

pruebas, configuración, etc. El contexto describe qué sucede en el sistema al momento del estímulo. La

respuesta describe, a través de la arquitectura, cómo debería responder el sistema ante el estímulo.

Este último elemento es el que permite establecer cuál es el atributo de calidad asociado.

Evaluación: Es un estudio de factibilidad que pretende detectar posibles riesgos, así como

buscar recomendaciones para contenerlos. La diferencia entre evaluar y verificar es que la evaluación se

realiza antes de la implementación de la solución. La verificación, es con el producto ya construido.

Stakeholders: Aquellas personas que están relacionadas de cierta forma con el sistema, ya sea

un desarrollador, usuario, gerente, etc.

Atributo de calidad: es una característica de calidad que afecta a un elemento. Donde el término

“característica” se refiere a aspectos no funcionales y el término “elemento” a componente.

Propósito de evaluar una Arquitectura

El propósito de realizar evaluaciones a la arquitectura, es para analizar e identificar riesgos

potenciales en su estructura y sus propiedades, que puedan afectar al sistema de software resultante,

verificar que los requerimientos no funcionales estén presentes en la arquitectura, así como determinar

en qué grado se satisfacen los atributos de calidad.

Momento para realizar una evaluación de Arquitectura

Según Kazman, es posible realizarla en cualquier momento , pero propone dos variantes que

agrupan dos etapas distintas: temprano y tarde.

 Temprano. No es necesario que la arquitectura esté completamente especificada para efectuar

la evaluación, y esto abarca desde las fases tempranas de diseño y a lo largo del desarrollo.

Tarde. Cuando ésta se encuentra establecida y la implementación de la solución, ya se ha

completado.

Métodos de Evaluación de Arquitecturas

Existen varias técnicas para realizar evaluaciones de arquitectura que se dividen basicamente en

técnicas cualitativas y cuantitativas. Normalmente, las técnicas de evaluación cualitativas son utilizadas

cuando la arquitectura está en construcción, mientras que las técnicas de evaluación cuantitativas, se

usan cuando la arquitectura ya ha sido implantada.

Hay métodos de evaluación de arquitecturas, que se centran en un atributo particular, como por

ejemplo:

ALMA (Architecture Level Modifiability Analysis): El atributo de calidad que analiza este método

es la facilidad de modificación.

PASA (Performance Assessment of Software Architecture):El atributo de calidad que analiza este

método es el desempeño.
 SALUTA (Scenario based Architecture Level Usability Analysis): Se basa en el atributo de la

facilidad del uso del sistema.

Survivable Network Analysis (SNA) SNA es un método desarrollado por el CERT (Computer

Emergency Response Team) que forma parte del SEI (Software Engineering Institute)

Hay otros métodos más generales, donde es posible realizar la evaluación desde distintas

perspectivas y que pueden analizar distintos atributos de calidad. Entre estos métodos se encuentra:

ATAM (Architecture Trade-off Analysis Method).

SAAM (Software Architecture Analysis Method).

ARID (Active Reviews for Intermediate Design).

Atributos de calidad por los que puede ser evaluada una arquitectura

Los atributos de calidad, se clasifican en las siguientes dos categorías:

Observables vía Ejecución: Son los atributos que se determinan del comportamiento del sistema,

en tiempo de ejecución.

No Observables vía Ejecución: Son los atributos que se establecen durante el desarrollo del

sistema.

En la siguiente figura, aparecen a modo de ejemplo algunos atributos de calidad categorizados.

 Architecture Level Modifiability Analysis (ALMA)

El atributo de calidad que analiza ALMA en una arquitectura de software es la facilidad

de modificación.

La facilidad de modificación en un sistema de software es la facilidad con la cual éste

puede ser modificado a cambios en el entorno, cambios en los requerimientos o cambios a la

especificación funcional. ALMA es el resultado de los trabajos de investigación realizados por

Bengtsson y Lassing.

ALMA es un método de evaluación orientado a metas; dependiendo de la meta, este

método puede ser usado para predecir el costo de mantenimiento en una arquitectura, evaluar

los riesgos al haber una modificación en esta, o comparar un conjunto de arquitecturas para

determinar cuál es la más apropiada en soportar cambios.

A continuación se describe en qué consiste cada una de estas metas:

Predicción del costo de mantenimiento. Consiste en estimar el esfuerzo requerido para

modificar la arquitectura a cambios requeridos en un futuro.

Evaluación de riesgos. Identifica los tipos de cambios que pueden ser complejos o que

sean inflexibles en la arquitectura de software.

Selección de un conjunto de arquitecturas. Compara dos o más arquitecturas

propuestas y selecciona aquella que proporcione mayor soporte a cambios.

ALMA puede ser utilizado una vez que concluye la especificación de la arquitectura

(evaluación clásica),no obstante este método puede ser usado si la arquitectura ha sido

implementada (evaluación tardía). La técnica de evaluación principal que utiliza este método es

el uso de escenarios de cambio. Los escenarios de cambio son usados para capturar eventos
futuros en los que se requiere que el sistema sea adaptado. Antes de iniciar la evaluación es

necesario que se cuente con la especificación de la arquitectura de software, así como los

requerimientos no funcionales.

Este método se compone de cinco pasos que se muestran en la Figura y que a

continuación se describen.

1. Definir la meta de evaluación. Dependiendo del objetivo de la evaluación se

selecciona alguna de las tres metas.

2. Describir la arquitectura de software. En este punto se colecta la información de las

partes más relevantes de la arquitectura como son la descomposición de ésta en componentes,

las relaciones entre componentes así como las relaciones que existen en el entorno del sistema.

3. Obtener escenarios. Una vez que se cuenta con la información de la arquitectura se

procede a encontrar y definir los escenarios de cambio, estos escenarios son agrupados en

categorías.

Dependiendo de la meta de evaluación se seleccionan los escenarios. Por ejemplo, si la

meta es estimar el esfuerzo de mantenimiento, se recomienda seleccionar aquellos escenarios

que corresponden a los cambios que tienen una alta probabilidad de que ocurran durante la

vida operacional del sistema. Esta actividad finaliza cuando se han identificado los principales

escenarios de cambio.

4. Evaluar escenarios. En este punto se realiza un análisis de impacto que consiste en

identificar los componentes afectados por los escenarios previamente definidos, determinar el

efecto del cambio sobre los componentes así como determinar los efectos del cambio en otros

componentes. Los resultados de este análisis se deben expresar ya sea de manera cuantitativa o

cualitativa.
 5. Interpretar resultados. Finalmente se interpretan los resultados así como las

conclusiones del análisis dependiendo de la meta de evaluación seleccionada

Las personas involucradas durante la evaluación son el arquitecto de software y el

equipo de desarrollo.

ALMA se considera un método de evaluación maduro ya que éste ha sido validado en

diferentes dominios de aplicación como son: sistemas de control embebido, sistemas médicos,

telecomunicaciones y sistemas administrativos.

Performance Assessment of Software Architecture (PASA)

PASA es el trabajo resultante de Williams y Smith en el que utilizan un conjunto de

técnicas para analizar el desempeño en una arquitectura de software. Entre estas técnicas se
encuentran el uso de estilos arquitectónicos, anti-patrones, guías de diseño, modelos, así como

técnicas empleadas en la ingeniería del desempeño de software.

El atributo de calidad que analiza PASA es el desempeño. El desempeño se interesa por

conocer qué tanto tiempo le toma al sistema de software responder cuando uno o varios

eventos ocurren, así como determinar el número de eventos procesados en un intervalo de

tiempo dado.

PASA puede ser usado una vez que la especificación de la arquitectura ha concluido o

ésta se encuentra implementada. La técnica de evaluación principal que utiliza PASA es el uso de

escenarios. Estos proporcionan una medida de razonamiento con respecto al desempeño del

sistema. Si se requieren análisis más detallados, los escenarios sirven como punto de partida

para construir modelos de desempeño.

Para utilizar este método la arquitectura de software debe estar previamente

documentada, en caso de que se encuentre parcialmente documentada es necesario extraer la

información que falta de los miembros del equipo de desarrollo así como de códigos fuente y

documentación existente.

Este método está compuesto de nueve pasos que se muestran en la Figura y que a

continuación se describen.

1. Presentar el método de evaluación. En este paso se elabora una presentación que

contiene el objetivo de realizar la evaluación, en qué consiste el método PASA, qué información

de la arquitectura es necesaria para efectuar la evaluación así como los resultados de la

evaluación. La presentación va dirigida a los administradores y al equipo de desarrollo.

2. Presentar la arquitectura. A continuación el equipo de desarrollo presenta la

arquitectura actual de una manera general sin entrar en detalles.

 3. Identificar casos de uso críticos. Se seleccionan los casos de uso que son importantes

para la operación del sistema como son aquellos que demandan una respuesta de tiempo rápida

para el usuario así como los que presentan algún riesgo de desempeño.

Es importante aclarar que un caso de uso puede contener uno o varios escenarios, estos

describen las secuencias de acciones requeridas para ejecutar el caso de uso. Los escenarios

deben ser especificados en UML como diagramas de secuencia.

4. Seleccionar los escenarios de desempeño principales. Por cada caso de uso crítico se

debe identificar los escenarios que son importantes con respecto al desempeño. Por ejemplo,

seleccionar aquellos escenarios que son ejecutados frecuentemente así como aquellos que son

críticos desde la percepción

de desempeño del usuario.

5. Identificar objetivos de desempeño. Por cada escenario de desempeño principal, se

debe especificar al menos un objetivo de desempeño. Los objetivos de desempeño pueden ser

expresados de distintas maneras. Por ejemplo, expresarlos en tiempo de respuesta, capacidad

de respuesta, restricciones o utilización de recursos. Cabe señalar que el objetivo de desempeño

debe ser cuantitativo para que este pueda ser medido.

6. Clarificar la arquitectura y discutirla. En este paso se estudia la arquitectura más a

detalle por lo que se tienen reuniones con el arquitecto y miembros del equipo de desarrollo

para aclarar dudas con respecto a las interacciones entre componentes si existe información

acerca del desempeño del sistema se colectan métricas.

7. Analizar la arquitectura. En este paso se utilizan diferentes técnicas para analizar el

desempeño de la arquitectura. Por ejemplo, se identifican estilos arquitectónicos con la

finalidad de detectar efectos negativos en el desempeño, se identifican anti-patrones de

desempeño que documentan problemas comunes de desempeño y se sugieren formas de cómo

resolverlos, se elaboran modelos de desempeño con el objetivo de identificar problemas en la

arquitectura. También se pueden utilizar técnicas de Ingeniería del desempeño de software para

elaborar modelos más precisos.

8. Identificar alternativas. Si se encontraron problemas de desempeño, se identifican

alternativas de solución para satisfacer los objetivos de desempeño. Estas alternativas pueden

incluir el cambio de estilo arquitectónico, modificar la arquitectura para eliminar anti-patrones

de desempeño, o alternativas para optimizar la interacción entre componentes.

9. Presentar resultados. Finalmente se elabora un documento con los resultados de la

evaluación que incluye los objetivos de la evaluación, hallazgos encontrados, pasos específicos a

seguir y recomendaciones

Las personas involucradas durante la evaluación son el arquitecto, el equipo de

desarrollo y en algunos momentos de la evaluación los administradores responsables del

proyecto. La duración de la evaluación puede ser llevada a cabo intensivamente en una semana.

PASA se considera un método de evaluación maduro ya que ha sido probado en varios dominios

de aplicación tales como sistemas basados en Web, aplicacionesfinancieras y sistemas en

tiempo real.

Scenario based Architecture Level UsabiliTy Analysis (SALUTA)

SALUTA es el primer método desarrollado para evaluar en la arquitectura de software la

facilidad de uso del sistema. La facilidad de uso es la facilidad con la cual el usuario puede

aprender a operar, preparar entradas e interpretar las salidas de un sistema o componente.

SALUTA es el resultado de los trabajos de investigación hechos por Folmer y Gurp.

Este método hace uso de un marco de referencia elaborado por los mismos autores en

el que se expresan las relaciones que existen entre la facilidad de uso y la arquitectura de

software. Este marco de referencia incluye un conjunto integrado de soluciones de diseño tales

como patrones de diseño y propiedades que tienen un efecto positivo sobre la facilidad de uso

en un sistema de software.

SALUTA analiza cuatro atributos que están directamente relacionados con la facilidad de

uso en un sistema de software, estos son: facilidad de aprendizaje, eficiencia de uso,

confiabilidad y satisfacción. Se recomienda efectuar la evaluación una vez que la especificación

de la arquitectura ha finalizado y ésta no se ha implementado.

La técnica principal de evaluación que utiliza este método es el uso de escenarios de uso.

Estos se agrupan en uno o varios perfiles de uso. En un perfil de uso se representa la facilidad de

uso requerida por el sistema de software. Para efectuar la evaluación se requiere que la

especificación de la arquitectura se encuentre disponible, así como el documento que incluya

los requerimientos no funcionales relacionados con la facilidad de uso.

 SALUTA está compuesto de cuatro pasos que se muestran en la Figura y que a

continuación se

describen.

1. Crear perfiles de uso. En este punto se identifican los usuarios y se organizan en

categorías. A continuación se identifican las tareas más significativas del sistema, se identifica el

contexto donde será usado el sistema, se determinan los valores para los atributos: facilidad de

aprendizaje, eficiencia de uso, confiabilidad y satisfacción. Para reflejar la diferencia en la

prioridad de los atributos, se asigna a cada uno un valor numérico no repetido entre 1 y 4. Por

último se seleccionan los escenarios más representativos que tienen mayor prioridad con

respecto a sus atributos.

2. Describir la facilidad de uso proporcionada. Se colecta la información de la

arquitectura de software para determinar el nivel de soporte en los escenarios de uso. Esto se

realiza efectuando un análisis basado en patrones o basado en propiedades. En ambos análisis

se utiliza el marco de referencia para determinar la presencia de patrones o propiedades de

facilidad de uso en la arquitectura a evaluar.

3. Evaluar escenarios. En este paso se evalúa cada uno de los escenarios que forman

parte del perfil de uso. Por cada escenario se analizan los patrones y propiedades previamente

identificados. Se recomienda usar el marco de referencia para analizar cómo un patrón o

propiedad particular afecta a un atributo específico en un escenario de uso. Finalmente en este

paso se expresan de manera cuantitativa los resultados del análisis, que indican el grado de

soporte de facilidad de uso en cada uno de los escenarios.

4. Interpretar resultados. En este paso se obtienen los resultados de la evaluación que

contienen el grado de facilidad de uso que soporta la arquitectura evaluada.

 Las personas involucradas durante la evaluación son el arquitecto de software,

ingenieros derequerimientos o ingenieros responsables por la facilidad de uso. SALUTA es un

método que se encuentra enetapa de maduración ya que solamente se ha probado en algunos

casos de estudio, sin embargo los resultadosque se han obtenido han sido satisfactorios.

Survivable Network Analysis (SNA)SNA

es un método desarrollado por el CERT (Computer Emergency Response Team) que

formaparte del SEI (Software Engineering Institute). Este método ayuda a identificar la

capacidad de supervivencia enun sistema analizando su arquitectura. La supervivencia es la

capacidad que tiene un sistema para completarsu misión a tiempo ante la presencia de ataques,

fallas o accidentes.

Un ejemplo de la definición anterior es la siguiente: un cajero automático debe

garantizar al usuario los servicios esenciales aun cuando este seencuentre en presencia de algún

ataque externo o falla interna.

 SNA utiliza tres propiedades clave para evaluar la supervivencia en un sistema. Estas son:

1. Resistencia. Es la capacidad del sistema para repeler ataques, fallas o accidentes.

2. Reconocimiento. Es la capacidad de detectar ataques, fallas o accidentes y si estos

ocurren evaluar los daños.

3. Recuperación. Es la capacidad de mantener en operación los servicios esenciales en

presencia de ataques, fallas o accidentes.

Este método puede ser usado en el proceso de construcción de la arquitectura

(evaluación temprana), una vez que la construcción de esta ha terminado o si la

arquitectura se encuentra implementada.La técnica de evaluación que utiliza SNA es el

uso de escenarios.

SNA hace uso de dos tipos de escenarios.

El primer tipo son los escenarios normales de uso, éstos se componen de una serie de

pasos donde los usuarios invocan a servicios y obtienen acceso a activos tales como

bases de datos.

El segundo tipo de escenarios son los de intrusión, en los que se representan diferentes

tipos de ataques al sistema. Para llevara cabo la evaluación, se requiere que se cuente

con la especificación de la arquitectura. Si hace falta documentación de la especificación

se procede a completarla.

SNA está compuesto de cuatro pasos que se muestran en la Figura y que a continuación

se describen.

1. Definición del sistema. En este paso se obtiene la misión del sistema, se

discute el entorno de uso en términos de capacidades y ubicaciones de los usuarios, se

analizan posibles riesgos que el sistema pueda presentar en condiciones adversas,

finalmente se analiza la arquitectura de software.

 2. Definición de las capacidades esenciales. A continuación se seleccionan los

servicios esenciales y los activos que usan. Se deben de seleccionar aquellos servicios y

activos que sean críticos para garantizaren condiciones adversas la misión del sistema.

Una vez seleccionados, estos se trazan a través de la arquitectura para identificar los

componentes que participan en proporcionar los servicios esenciales.

3. Definición de las capacidades que comprometen al sistema. En este paso se

selecciona un conjunto representativo de posibles ataques basados en el entorno de

operación del sistema. Se definen los escenarios de intrusión y se trazan a través de la

arquitectura para identificar componentes que comprometan la supervivencia del

sistema logrando así el acceso y daño a éste.

4. Analizar la supervivencia. Finalmente se identifican los escenarios de

intrusión que contienen los componentes esenciales y que comprometen la

supervivencia del sistema. Por cada componente identificado se procede a analizarlo en

términos de las capacidades de resistencia, reconocimiento y recuperación. Estos

análisis se colocan en una tabla llamada mapa de supervivencia que contiene por cada

escenario de intrusión las estrategias de supervivencia actuales y las recomendadas con

respecto a cada una de las capacidades.

El resultado que se obtiene al final de la evaluación es un documento que

incluye modificaciones recomendadas a la arquitectura acompañadas del mapa

de supervivencia. Las personas involucradas durante la evaluación son el

arquitecto de software, el diseñador principal, los propietarios del sistema y

usuarios del mismo. SNA se considera un método maduro ya que se ha utilizado

satisfactoriamente en sistemas comerciales y de gobierno. No obstante este

método se mantiene en un proceso de mejoramiento continuo.

 Conclusión

En este trabajo de investigación, hemos abordado el tema de la arquitectura de software,

analizando su importancia, los diferentes estilos arquitectónicos, los patrones de diseño, las

técnicas de evaluación y las herramientas disponibles.

A lo largo del trabajo, hemos destacado la importancia de una arquitectura bien diseñada para

el éxito de un proyecto de software. Una buena arquitectura puede mejorar la calidad, el

rendimiento, la escalabilidad, la flexibilidad y la mantenibilidad del software.

También hemos presentado los diferentes estilos arquitectónicos que se pueden utilizar para

estructurar el software, como la arquitectura en capas, la arquitectura orientada a objetos y la

arquitectura de microservicios. Cada estilo tiene sus ventajas y desventajas, y la elección del

estilo adecuado dependerá de los requisitos específicos del proyecto.

Además, hemos explorado los patrones de diseño, que son soluciones reutilizables a problemas

comunes de diseño de software. Los patrones de diseño pueden ayudar a crear software flexible,

escalable y robusto.

Para evaluar la arquitectura del software antes de comenzar la implementación, hemos

presentado diferentes técnicas, como el análisis de escenarios, el análisis de métricas y la

simulación. Estas técnicas pueden ayudar a identificar posibles problemas en la arquitectura y

asegurar que cumple con los requisitos del proyecto.

Por último, hemos presentado algunas de las herramientas que pueden ayudar a los arquitectos

de software en su trabajo, como las herramientas de modelado, las herramientas de análisis y

las herramientas de generación de código.

En conclusión, la arquitectura de software es una disciplina fundamental en la ingeniería del

software. Invertir tiempo y esfuerzo en la arquitectura del software puede ayudar a crear

software de alta calidad, flexible, escalable y fácil de mantener.