Arquitecturas Software

296 Pages·2013·11.57 MB·English

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA
MÁSTER UNIVERSITARIO EN INVESTIGACIÓN EN
INGENIERÍA DE SOFTWARE Y SISTEMAS INFORMÁTICOS
ITINERARIO INGENIERÍA DE SOFTWARE
COD: 31105128

TRABAJO DE INVESTIGACIÓN

“Arquitecturas Software: Gestión de los atributos de
calidad y su incorporación en ArchE para la mejora
del análisis, evaluación y soporte en la toma de
decisiones durante el desarrollo arquitectónico”

Estudiante: Carlos Alberto Gaitán Peña
Dpto: Ingeniería de Software y Sistemas Informáticos
Prof.: Dr. D. José Félix Estívariz López
Curso (2012/2013)
Enero de 2014
1
UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA
MÁSTER UNIVERSITARIO EN INVESTIGACIÓN EN
INGENIERÍA DE SOFTWARE Y SISTEMAS INFORMÁTICOS

ITINERARIO INGENIERÍA DE SOFTWARE

COD: 31105128

Arquitecturas Software: Gestión de los atributos de calidad
y su incorporación en ArchE para la mejora del análisis,
evaluación y soporte en la toma de decisiones durante el
desarrollo arquitectónico

Carlos Alberto Gaitán Peña
TRABAJO DE INVESTIGACIÓN
Dpto: Ingeniería de Software y Sistemas Informáticos
Prof.: Dr. D. José Félix Estívariz López
2
Arquitecturas Software: Gestión de los atributos de calidad
y su incorporación en ArchE para la mejora del análisis,
evaluación y soporte en la toma de decisiones durante el
desarrollo arquitectónico

Trabajo de Investigación para el Máster en Investigación en Ingeniería de Software y
Sistemas Informáticos modalidad oferta general curso (2012/2013)

Realizado por: ______________________________ (firma) ______________________

Dirigido por: _______________________________ (firma) ______________________

Supervisado por:_____________________________ (firma) ______________________

Tribunal / Órgano Calificador:

Presidente: D./Da ___________________________ (firma) _____________________

Secretario: D./Da ___________________________ (firma) _____________________

Vocal: D./Da ___________________________ (firma) _____________________

Fecha de lectura y defensa:

Calificación:

3
Autorización de publicación y difusión del Trabajo de Fin de
Máster para fines académicos

Autorización

Autorizo a la Universidad Nacional de Educación a Distancia (UNED) a difundir y utilizar,
con fines académicos, no comerciales y mencionando expresamente al autor, tanto la
memoria de este Trabajo Fin de Máster, como el código, la documentación y/o el prototipo
desarrollado.

Firma:______________________________
Carlos Alberto Gaitán Peña

Juan del Rosal, 16
28040, Madrid
Tel: [phone]
Fax: [phone]

www.issi.uned.es
4
RESUMEN

En este documento se presenta la propuesta de investigación “Gestión de los
Atributos de Calidad y su Incorporación en ArchE para la Mejora del Análisis, Evaluación
y Soporte en la Toma de Decisiones Durante el Desarrollo Arquitectónico” para el Máster
en Investigación en Ingeniería de Software y Sistemas Informáticos de la UNED. La
propuesta consiste en la evaluación de arquitecturas a partir de un conjunto de tácticas las
cuales permiten mejorar u optimizar los atributos de calidad para el soporte y diseño de
sistemas altamente reutilizables y escalables.

A lo largo del proceso de desarrollo de software el arquitecto utiliza gran variedad
de técnicas para validar sus diseños, siendo una de ellas la que responde a la valoración de
los atributos de calidad en función de los requerimientos del sistema. Estos atributos y su
definición a través de los escenarios de calidad proporcionan un mecanismo eficiente para
la evaluación de cualquier arquitectura a partir de los seis (6) atributos reconocidos por
(Bass, Len; Clements, Paul; Kazman, Rick, 2003) en su libro “Software Architecture in
Practice”. Una de las características fundamentales de dichos atributos consiste en que a
partir de su definición se puedan tomar decisiones “tempranas” sobre una determinada
arquitectura. Las decisiones o “Estrategias” no son más que la suma de un conjunto de
reglas que permiten ajustar los diseños a un determinado modelo de negocio con base en
las necesidades y los planes estratégicos de la organización.

Un diseño arquitectónico es el resultado de la toma de decisiones y la aplicación de
un conjunto de técnicas y tácticas para la mejora en los procesos de negocio, donde
indiscutiblemente los requerimientos juegan un papel importante ya que a partir de su
concepción y definición, el arquitecto modela su experiencia de acuerdo al criterio del
medio “entorno” en el cual se está desempeñando la arquitectura. Es evidente que un mejor
diseño siempre conllevará a una independencia y flexibilidad de los diferentes componentes
de un sistema software, lo que hace escalable cualquier arquitectura; por ello el análisis y la
planificación de los requerimientos debe ser una tarea fundamental para el arquitecto, la
cual debe ir acompañada siempre de procesos de mejora continua para asegurar la calidad
y la vida útil de cualquier sistema informático lo que se traduce en un ROI más eficiente.

La propuesta contempla la utilización de la herramienta ArchE del SEI, un
instrumento que sirve como base para el diseño de arquitecturas que soportadas por Marcos
de Razonamiento para la evaluación de atributos de calidad como la Modificabilidad y el
Rendimiento, la cual se convierte en un soporte para el acercamiento de una arquitectura
“ideal” para sistemas basados en Requerimientos.

Palabras Claves: Arquitectura de Software, Análisis y Diseño Basado en
Arquitecturas, Atributos de Calidad, Diseño Dirigido por Atributos de
Calidad, ArchE, Estrategias, Tácticas para Arquitecturas de Software, Estilos
Arquitectónicos

5
ABSTRACT

This document introduce to “Quality Attributes in Software Architecture and
Integration with ArchE for the Quality Improvement, Analysis, Evaluation and Decision
Making in Architectonic Design Software” for the Masters in Investigation in Software
Engineering and Computer Systems of the UNED. This thesis proposes the evaluation of
software architectures from a set of Tactics for Quality Attributes to improve the design,
reliability, reusability and performance for escalable systems.

In the process of software development, the architect uses a great variety of
techniques to validate his designs, being the most important the Quality Attributes to
improve the design of software architectures and their last evaluation form of the system
requirements. These attributes and their definition through the Quality Scenaries provide
an efficient mechanism for the evaluation of any architecture from the six (6) attributes
mentioned by (Bass, Len; Clements, Paul; Kazman, Rick, 2003) in their book “Software
Architecture in Practice”. The principal features of these attributes consists of the capacity
that they have to make “early” decisions over an specific architecture. These decisions or
“Strategies” correspond to a set of rules to improve the designs and to fit their behavior to
the own needs of business and the strategic plans of the organization.

Architectural Design is the result of the decision making and the application of a set
of techniques and tactics for the improvement in the business processes, where
unquestionably the requirements play an important role since from their conception and
their definition, the architect models his experience according to the criterion of means
“environment” in which the architecture is evolving. It´s evident that a better design will
always entail to an independence and flexibility over the different components from the
architecture, turning any into highly scalable; for that reason the analysis and the planning
of the requirements must be a fundamental task for all software architects, who must
accompany their analysis with estrategical process to improve and to insurance the quality
and the best life cycle over the system software for a better ROI.

This work evaluate the use of the Architecture Expert (ArchE) of SEI-CMU, as an
instument to drive the process to design systems software and different kind of
architectures based on Reasoning Framework as Modifiability and Performance for the
evaluation of Quality Attributes. This tool help to software architects and designers to
explore ef-fective alternatives in architectural models and designs for a particular set of
requirements for an “ideal” architectural model.

Keywords: Software Architecture, Architectural Styles, Scenario-based
Analysis of Software Architecture, Quality Attributes, Attibute Driven Design,
ArchE, Strategies, Tactics

6
AGRADECIMIENTOS

El Autor quiere expresar sus agradecimientos a aquellas personas e instituciones que
de forma directa e indirecta influyeron en la realización y conclusión del presente trabajo de
investigación.

A Dios, señor y dador de vida por ser El quien motiva mi vida y mis deseos de
superación y para quien siempre dedicaré mis logros y confiaré mis pensamientos.

A mi hijo Sergio Alejandro, el ser más maravilloso y la mayor bendición de mi
vida; para Él una dedicatoria especial, por ser ese motor que mueve mi corazón y mi
orgullo como padre, ya que sin su amor, sacrificio y dedicación no hubiese sido posible la
realización de este trabajo.

A mi Madre, por ser esa persona excepcional que comparte mis triunfos y fracasos.
A ella mis agradecimientos infinitos por que sin su apoyo y dedicación no hubiese sido
posible la realización de muchas metas como individuo y como ser social. A ella debo la
disciplina y consagración en mis estudios así como la vida misma.

A mi Padre… que sería de mi vida sin el ejemplo de este hombre ejemplar, para El
también va dedicado este triunfo, ya que sin su apoyo y consejos no hubiese podido llevar a
buen término mi trabajo de grado.

A mi hermano, y demás familiares, gracias por su apoyo incondicional en este y en
tantos proyectos de mi vida.

A mi director de Tesis, Dr. D. José Félix Estívariz López, por haber depositado su
confianza en mí y por haberme acompañado en todo el proceso permitiendo gestionar mi
conocimiento y contribuyendo a la ampliación de mis saberes en esta y otras asignaturas del
Máster, a El mis agradecimientos y gratitud por su labor.

A la alma Máter, UNED, al equipo docente del Máster de la ETSI y demás
miembros que integran este prestigioso claustro universitario, mis más sentidos
agradecimientos por su apoyo y por haberme acogido como uno de sus estudiantes, al
brindarme una oportunidad de aprendizaje y crecimiento personal.

A todos vosotros, gracias.

7
TABLA DE CONTENIDO

Pág.

1. OBJETO PRELIMINAR DE LA INVESTIGACIÓN .................................... 21
1.1. OBJETIVO GENERAL ......................................................................... 21
1.2. OBJETIVOS ESPECÍFICOS ................................................................. 21

2. INTRODUCCIÓN A LA ARQUITECTURA DE SOFTWARE ................... 23
2.1. ESTADO DEL ARTE ............................................................................ 23

3. CALIDAD DEL PRODUCTO SOFTWARE ................................................... 32
3.1. EL PROCESO DEL SOFTWARE ........................................................ 32
3.1.1. Concepto de Calidad del Software ........................................ 34
3.1.2. Factores de Calidad ................................................................ 34
3.2. MEDIDA EN LA CALIDAD DEL SOFTWARE ................................. 35
3.3. MÉTRICAS DE SOFTWARE .............................................................. 36
3.3.1. Clasificación de las Métricas .................................................. 37
3.3.2. Métricas usadas en desarrollo de Software ............................. 38

4. ARQUITECTURA DE SOFTWARE ............................................................... 41
4.1. CONCEPTOS EN LA ARQUITECTURA DE SOFTWARE ............... 43
4.1.1. Estilos Arquitectónicos ........................................................... 43
4.1.2. Lenguajes de Descripción Arquitectónica .............................. 45
4.1.2.1. Architecture Based Design Method (ABD) ............. 45
4.1.2.2. Active Design Reviews (ADR) ................................ 46
4.1.2.3. Active Reviews for Intermediated Designs .............. 46
4.1.2.4. Architecture Tradeoff Analysis Method ................... 46
4.1.2.5. Attribute-Based Architectural Styles (ABAS) ......... 47
4.1.2.6. Attribute-Driven Design (ADD) .............................. 47
4.1.2.7. Cost-Benefit Analysis Method (CBAM) .................. 47
4.1.2.8. Quality-Attribute-Driven Software (QADSAR) ...... 48
4.1.2.9. Quality Attribute Workshops (QAW) ...................... 48
4.1.2.10. Software Architecture Analysis (SAAM) .............. 49
4.1.3. Frameworks y Vistas .............................................................. 49
4.1.3.1. Framework para Arquitecturas de Zachman ............ 50
4.1.3.2. Pattern Oriented Software Architecure “POSA” ...... 50
4.1.3.3. C4ISR Architecture Framework ............................... 50
4.1.3.4. Modelo de Referencia (RM-ODP) ........................... 51
4.1.3.5. The Open Group Architecture (TOGAF) ................. 51
4.1.3.6. Modelo 4+1 de Rational Software Corp. ................. 51
4.1.3.7. Unified Modeling Language (UML) ........................ 52
4.1.3.8. Pattern Oriented Software Architecure (POSA) ...... 52
4.1.3.9. Modelo de Vistas de Microsoft ................................ 53
4.1.4. Abstracción ............................................................................. 54
4.1.5. Procesos/Metodologías ........................................................... 56
4.1.6. Requerimientos ....................................................................... 62
8
4.1.7. Escenarios ............................................................................... 64
4.1.8. Concerns Arquitectónicos o “Asuntos de Interés” ................. 65

5. ATRIBUTOS DE CALIDAD ............................................................................. 66
5.1. ISO/IEC 9126 Software Engineering – Product Quality (2001) ........... 67
5.2. ESCENARIOS PARA ATRIBUTOS DE CALIDAD .......................... 69
5.2.1. Disponibilidad (Availability) .................................................. 70
5.2.2. Modificabilidad (Modifiability) .............................................. 75
5.2.3. Desempeño (Performance) ...................................................... 77
5.2.4. Seguridad (Security) ................................................................ 78
5.2.5. Facilidad de Pruebas - Verificabilidad (Testability) .............. 83
5.2.6. Usabilidad (Usability) ............................................................. 84

6. ESTRATEGIAS ARQUITECTÓNICAS ......................................................... 89
6.1. TÁCTICAS PARA EL CONTROL DE ATRIBUITOS ....................... 90
6.1.1. Tácticas aplicadas a la Disponibilidad (Availability) ............. 90
6.1.1.1. Detección de Fallos (Fault Detection) ..................... 91
6.1.1.2. Recuperación de Fallos (Fault Recovery) ............... 92
6.1.1.3. Prevención de Fallos (Fault Prevention) ................ 93
6.1.2. Tácticas aplicadas a la Modificabilidad (Modifiability) ......... 94
6.1.2.1. Reducción de Costos en Responsabilidades ............. 96
6.1.2.1.1. División de Responsabilidades .................. 97
6.1.2.2. Incremento en la Cohesión ....................................... 98
6.1.2.3. Reducción de Acoplamientos ................................... 98
6.1.3. Tácticas aplicadas al Rendimiento (Performance) .................. 99
6.1.3.1. Demanda de Recursos (Resource Demand) .......... 100
6.1.3.2. Manejo de Recursos (Resource Managment) ......... 101
6.1.3.3. Arbitraje de Recursos (Resorurce Arbitration) ...... 102
6.1.4. Tácticas aplicadas a la Seguridad (Security) ......................... 102
6.1.4.1. Resistencia a Ataques (Resisting Attacks) ............. 103
6.1.4.2. Detección de Ataques (Detecting Attacks) ............ 104
6.1.4.3. Recuperación de Ataques ....................................... 104
6.1.5. Tácticas aplicadas a la Verificabilidad (Testability) ............. 105
6.1.5.1. Manejo de Entradas/Salidas ................................... 105
6.1.5.2. Monitorización Interna (Internal Monitoring) ........ 106
6.1.6. Tácticas aplicadas a la Usabilidad (Usability) ...................... 106
6.1.6.1. Tácticas en Tiempo de Ejecución ........................... 107
6.1.6.2. Tácticas en Tiempo de Diseño ............................... 107
6.2. PATRONES ARQUITECTÓNICOS .................................................. 108
6.2.1. From Mud To Structure ........................................................ 109
6.2.1.1. Capas (Layers) ........................................................ 109
6.2.1.2. Tuberías y Filtros (Pipes and Filters) ..................... 112
6.2.1.3. Tablero (Blackboard) ............................................. 113
6.2.2. Sistemas Distribuidos (Distributed Systems) ........................ 116
6.2.2.1. Intermediarios (Broker) .......................................... 116
6.2.3. Sistemas Interactivos (Interactive Systems) .......................... 117
6.2.3.1. MVC (Modelo-Vista-Controlador) ........................ 118
9
6.2.3.2. Control-Abstracción-Presentación (PAC) .............. 122
6.2.4. Sistemas Adapatables o Adaptativos .................................... 124
6.2.4.1. MicroKernel ........................................................... 124
6.2.4.2. Reflexión (Reflection) ............................................ 126

7. ARCHITECTURE EXPERT DESIGN ASSISTANT .:.ArchE.:. ................ 127
7.1. RESPONSABILIDADES EN ArchE .................................................. 128
7.2. TACTICAS ARQUITECTÓNICAS UTILIZADAS POR ArchE ...... 129
7.3. REASONING FRAMEWORK - RF ................................................... 129
7.3.1. Modifiability Reasoning Framework .................................... 132
7.3.1.1. Tácticas de Modificabilidad en ArchE ................... 135
7.3.2. Performance (ICM) Reasoning Framework .......................... 135
7.3.2.1. Tácticas de Performance aplicadas por ArchE ....... 138
7.4. ESCENARIOS EN ArchE ................................................................... 139
7.5. FLUJO DE TRABAJO EN ArchE ...................................................... 141
7.6. DESCRIPCIÓN DE COMPONENTES EN ArchE ............................. 144
7.6.1. Estructura de ArchE .............................................................. 144
7.6.2. Especificación de Módulos en el Sistema Experto ArchE .... 145

8. CONFIGURACIÓN DE LA ARQUITECTURA .:.ArchE.:. ....................... 157
8.1. INSTALACIÓN DEL JDK .................................................................. 158
8.2. INSTALACIÓN IDE ECLIPSE .......................................................... 163
8.3. INSTALACIÓN DE MySQL DATABASE ........................................ 165
8.4. INSTALACIÓN DE GEF (Graphical Editing Framework) ................ 173
8.5. INSTALACIÓN DEL SISTEMA EXPERTO JESS ........................... 175
8.6. INSTALACIÓN DE XmlBlaster ......................................................... 181
8.7. INSTALACIÓN DE ArchE ................................................................. 185

9. UTILIZACIÓN DE ArchE EN UN CASO PRÁCTICO – CTAS ................ 195
9.1. DESCRIPCIÓN DEL CASO PRÁCTICO CTAS ............................... 196
9.2. PASOS PARA LA DEFINICIÓN DE LA ARQUITECTURA .......... 196
9.2.1. Paso 1 - Obtener Requerimientos ......................................... 196
9.2.2. Paso 2 - Refinamiento de Escenarios .................................... 196
9.2.3. Paso 3 - Seleccionar el Framework de Razonamiento ........ 199
9.2.4. Paso 4 - Construir el Escenario de Calidad ......................... 199
9.2.5. Paso 5 - Generar el Modelo ................................................. 200
9.3. CASO PRÁCTICO CTAS (Clemson Traveler Assistant System) ...... 200
9.3.1. Paso 1 – Requerimientos en el Sistema CTAS ..................... 200
9.3.1.1. Actores o Stakeholders en CTAS ........................... 201
9.3.1.2. Caso de Uso para el Sistema CTAS ....................... 202
9.3.1.3. Atributos de Calidad para el Sistema CTAS .......... 203
9.3.1.4. Especificación de Requerimientos ......................... 205
9.3.1.5. Responsabilidades y Dependencias en CTAS ........ 206
9.3.2. Paso 2 - Refinamiento de Escenarios en CTAS .................... 207
9.3.2.1. Definición de Escenarios para CTAS ..................... 207
9.3.2.1.1. Agregar un nuevo Escenario ................... 207
9.3.3. Paso 3 – Selección del RF para CTAS .................................. 212
10