Arquitectura de Software

Juan Bernardo Quintero

Contexto
¿Por qué fracasan los proyectos?

 Requisitos incompletos: 13%  Expectativas no realistas: 10%

 Cambios en requisitos: 9%  Producto no necesario: 8%
 No implicación de usuarios: 12%
 TOTAL: 52%
Contexto

50-200X

Coste de la
corrección

50-200X

Fase en la que se
detecta el fallo

Requisitos 1X

Arquitectura 1X

Diseño detallado

Construcción

Requisitos Arquitectura Diseño detallado construcción Producción

Fase en la que se soluciona el fallo

¿ Por qué Gestionar Requisitos?

 El coste de corrección de defectos de

requisitos es del orden de 100 a 200 veces
inferior en las etapas iniciales.
 La corrección de requisitos defectuosos
implica mucho retrabajo sobre otros
productos del proyecto.
¿Qué es un Requisito?
IEEE Standard Glossary of Software Engineering Terminology
(1990)
Una condición o capacidad necesaria por un usuario para solucionar un
problema o lograr un objetivo.
Una condición o capacidad que debe cumplir o poseer un sistema o
componente de un sistema para satisfacer un contrato, estándar,
especificación u otro documento formalmente impuesto.
Una representación documentada de una condición o capacidad como
en 1 o 2.

Somerville y Sawler (1997)

Una especificación de qué se debería implementar.
Son descripciones de cómo se debe comportar el sistema, o de un
atributo o propiedad del sistema.
Puede ser una restricción en el proceso de desarrollo de un sistema.
¿Qué NO es un Requisito?

Detalles de Diseño o implementación o pruebas.

Información relativa a la Planificación del Proyecto.

Necesidades del Proyecto.

Estos elementos se suelen llamar ―Especificaciones

suplementarias‖
Características

Características de las buenas descripciones de requisitos

Requisitos Especificación

Posibles Completa
Necesarios Correcta
Priorizados Consistente
Concretos Modificable
Verificables Trazable
Defectos
Los defectos comunes en los requisitos y sus consecuencias

Implicación insuficiente Problemas en la validación

del cliente del producto obtenido

Requisitos crecientes Degradación de la estructura

y cambiantes y arquitectura del producto

Pérdida de tiempo en
Requisitos ambiguos
re-codificación

Requisitos
Trabajo innecesario
innecesarios

Requisitos mínimos Problemas en la validación

(insuficientes) del producto obtenido

Requisitos mínimos Error en la estimación

(insuficientes) y planificación

Omisión de las necesidades

Usuarios insatisfechos
de grupos de usuarios
Técnicas
Técnicas de obtención de requisitos

Reuniones JAD, cuestionarios

ENTREVISTAS reuniones de grupo
entrevista, lluvia de ideas

Casos de uso, tarjetas CRC

ESCENARIOS diagramas de flujo, escenarios

TÉCNICAS
Prototipos rápidos
PROTOTIPOS prototipos evolutivos

Introspección
OBSERVACIÓN análisis de protocolo
documentación, otros sistemas
Ingeniería de Requisitos
Desarrollo de Requisitos
Proceso de Extraer, analizar, especificar y verificar los requisitos
El proceso de desarrollo de requisitos varía radicalmente de una organización a
otra dependiendo de su madurez, cultura de la organización, dominio de
aplicación, implicación, etc.
No existen procesos ―ideales‖ de desarrollo requisitos y gestión de los requisitos.
Desarrollo de Requisitos
Desarrollo de Requisitos
Buenas Prácticas
Gestión de Requisitos

 Definir un Proceso de Control de Cambios

 Establecer un Grupo (o comité) de Control de cambios (GCC)
 Realizar análisis de Impacto sobre los cambios
 Crear líneas Base y controlar las versiones de los requisitos
 Mantener la historia de los cambios
 Seguir el estado de los requisitos
 Medir la volatilidad de los requisitos
 Usar herramientas de gestión de requisitos
 Crear matrices de trazabilidad de los requisitos
Gestión de Requisitos
Procedimiento de Control de Cambios
Tipos de Requisitos
Clasificación de los requisitos (Según Juan Palacios)

 Funcionales:
Definen el comportamiento del sistema o Requisito
tareas que el sistema debe realizar.
Funcionales
Restricción
 No Funcionales:
Definen aspectos, que sin ser
funcionalidades, (tareas que el sistema debe Requisito
realizar) resultan deseables desde el punto Tiipos de No
de vista del usuario. Generalmente Requisitos Funcionales
comprenden atributos de calidad: Restricción
• Tiempos de respuesta.
• Características de usabilidad.
Requisito
• Facilidad de mantenimiento.
De Interfaz
 De Interfaz: Restricción
Definen las interacciones del sistema con su
entorno.
Tipos de Requisitos
Clasificación de los requisitos (Según Amador Durán)

Catálogo de Requisitos
…
• Objetivos del sistema
• Requisitos de información
• Requisitos funcionales
- Diagramas de casos de uso
- Definición de actores
- Casos de uso del sistema
• Requisitos no funcionales
…
Tipos de Requisitos
Tipos de Requisitos
Desde la perspectiva Funcional
Manejo de los Requisitos Funcionales
Visibles Vía Ejecución
Atributo de Descripción
Calidad
Disponibilidad Es la medida de disponibilidad del sistema para el uso
(Availability) (Barbacci et al.,1995)
Confidencialidad Es la ausencia de acceso no autorizado a la información
(Confidentiality) (Barbacci et al., 1995)
Funcionalidad Habilidad del sistema para realizar el trabajo para el cual fue concebido
(Functionality) (Kazman et al., 2001)
Es el grado en el cual un sistema o componente cumple con sus
Desempeño
funciones designadas, dentro de ciertas restricciones dadas, como
(Performance)
velocidad, exactitud o uso de memoria (IEEE 610.12)
Confiabilidad Es la medida de la habilidad de un sistema a mantenerse operativo a lo
(Reliability) largo del tiempo (Barbacci et al., 1995)
Ausencia de consecuencias catastróficas en el ambiente. Es la medida
Seguridad externa
de ausencia de errores que generan pérdidas de información (Barbacci
(Safety)
et al.,1995)
Es la medida de la habilidad del sistema para resistir a intentos de uso
Seguridad interna
no autorizados y negación del servicio, mientras se sirve a usuarios
(Security)
legítimos (Kazman et al., 2001)
No Visibles Vía Ejecución (1)

Atributo de Descripción
Calidad
Configurabilidad Posibilidad que se otorga a un usuario experto a realizar ciertos cambios
(Configurability) al sistema (Bosch et al., 1999)
Es la medida en que trabajan correctamente componentes del sistema
Interoperabilidad
que fueron desarrollados separadamente al ser integrados (Bass et al.
(Interoperability)
1998)
Integridad Es la ausencia de alteraciones inapropiadas de la información (Barbacci
(Integrity) et al., 1995)
Modificabilidad Es la habilidad de realizar cambios futuros al sistema
(Modifiability) (Bosch et al. 1999)
Es la capacidad de someter a un sistema a reparaciones y evolución
Mantenibilidad (Barbacci et al., 1995)
(Maintainability) Capacidad de modificar el sistema de manera rápida y a bajo costo
(Bosch et al. 1999)
No Visibles Vía Ejecución (2)

Atributo de Descripción
Calidad
Es la habilidad del sistema para ser ejecutado en diferentes ambientes de
Portabilidad computación. Estos ambientes pueden ser hardware, software o una
(Portability) combinación de los dos
(Kazman et al., 2001)
Es la capacidad de diseñar un sistema de forma tal que su estructura o
Reusabilidad
parte de sus componentes puedan ser reutilizados en futuras aplicaciones
(Reusability)
(Bass et al. 1998)
Escalabilidad Es el grado con el que se pueden ampliar el diseño arquitectónico, de
(Scalability) datos o procedimental (Pressman, 2002)
Es la medida de la facilidad con la que el software, al ser sometido a una
Capacidad serie de pruebas, puede demostrar sus fallas. Es la probabilidad de que,
de Prueba asumiendo que tiene al menos una falla, el software fallará en su próxima
(Testability) ejecución de prueba
(Bass et al. 1998)
Modelo de McCall (1977)

1. Determinación de los factores que influyen sobre la calidad

del software
2. Identificación de los criterios para juzgar cada factor
3. Definición de las métricas de los criterios y establecimiento
de una función de normalización que define la relación entre
las métricas de cada criterio y los factores correspondientes
4. Evaluación de las métricas
5. Correlación de las métricas a un conjunto de guías que
cualquier equipo de desarrollo podría seguir
6. Desarrollo de las recomendaciones para la colección de
métricas
Modelo de McCall
Modelo de McCall (1)

Factor Criterio
Rastreabilidad
Correctitud Completitud
Consistencia
Consistencia
Confiabilidad Exactitud
Tolerancia a fallas
Eficiencia de ejecución
Eficiencia
Eficiencia de almacenamiento
Control de acceso
Integridad
Auditoría de acceso
Operabilidad
Usabilidad Entrenamiento
Comunicación
Simplicidad
Mantenibilidad
Concreción
Modelo de McCall (2)
Factor Criterio
Simplicidad
Instrumentación
Capacidad de Prueba
Auto-descriptividad
Modularidad
Auto-descriptividad
Capacidad de expansión
Flexibilidad
Generalidad
Modularidad
Auto-descriptividad
Portabilidad Independencia del sistema
Independencia de máquina
Auto-descriptividad
Generalidad
Reusabilidad Modularidad
Independencia del sistema
Independencia de máquina

Modularidad
Interoperabilidad Similitud de comunicación
Similitud de datos
Modelo FURPS (1987)

Functionality: Funcionalidad.
Usability: Usabilidad.
Reliability: Confiabilidad.
Performance: Desempeño.
Supportability: Capacidad de soporte.
Modelo FURPS
Factor de Calidad Atributos
Características y capacidades del programa
Funcionalidad Generalidad de las funciones
Seguridad del sistema
Factores humanos
Factores estéticos
Facilidad de uso
Consistencia de la interfaz
Documentación
Frecuencia y severidad de las fallas
Exactitud de las salidas
Confiabilidad Tiempo medio de fallos
Capacidad de recuperación ante fallas
Capacidad de predicción
Velocidad del procesamiento
Tiempo de respuesta
Rendimiento Consumo de recursos
Rendimiento efectivo total
Eficacia
Extensibilidad
Adaptabilidad
Capacidad de pruebas
Capacidad de Soporte Capacidad de configuración
Compatibilidad
Requisitos de instalación
Modelo ISO/IEC 9126

Diferentes aspectos de la calidad

Efecto del
Proceso Producto producto

Influye Influye Influye

Calidad de Calidad Calidad Calidad

proceso interna externa en uso Contextos
de uso
Depende de Depende de Depende de

proveedor usuario
Modelo ISO/IEC 9126

Adaptado respecto del presentado en ISO/IEC 9126-1

Modelo ISO/IEC 9126

La calidad en el ciclo de vida del software

Modelo ISO/IEC 9126
Estructura de la norma

Internas
Externas
Modelo ISO/IEC 9126
Característica Subcaracterística
Adecuación
Exactitud
Funcionalidad Interoperabilidad
Seguridad
Madurez
Confiabilidad Tolerancia a falla
Recuperabilidad
Entendibilidad
Usabilidad Capacidad de aprendizaje
Operabilidad
Comportamiento en tiempo
Eficiencia Comportamiento de recursos
Analizabilidad
Modificabilidad
Mantenibilidad Estabilidad
Capacidad de pruebas
Adaptabilidad
Portabilidad Instalabilidad
Reemplazabilidad
Modelo ISO/IEC 9126 (1991)
Modelo ISO/IEC 9126
Evaluación del producto software: ISO 14598

Efecto del
Recursos y Proceso de Producto
producto
entorno evaluación software
software

Apoyo a la Proceso de Métricas Métricas Métricas de

evaluación evaluación Internas externas calidad en
uso

14598-1

14598-2 14598-3 9126-1

14598-4
14598-6 9126-3 9126-2 9126-4
14598-5
Modelo de Dromey (1996)
1. Especificación de los atributos de calidad de alto nivel (por
ejemplo, confiabilidad, mantenibilidad)

2. Determinación de los distintos componentes del producto a un

apropiado nivel de detalle (por ejemplo, paquetes, subrutinas,
declaraciones)

3. Para cada componente, determinación y categorización de sus

implicaciones más importantes de calidad

4. Proposición de enlaces que relacionan las propiedades implícitas a

los atributos de calidad, o, alternativamente, uso de enlaces de las
cuatro categorías de atributos propuestas

5. Iteración sobre los pasos anteriores, utilizando un proceso de

evaluación y refinamiento
Modelo de Dromey

Propiedades del producto Atributos de Calidad

Funcionalidad
Correctitud Confiabilidad
Mantenibilidad
Internas Eficiencia
Confiabilidad
Mantenibilidad
Reusabilidad
Contextuales Portabilidad
Confiabilidad

Mantenibilidad
Reusabilidad
Descriptivas Portabilidad
Usabilidad
ISO/IEC 9126
Adaptado para Arquitecturas de Software (2003)

Atributos de calidad de ISO-9126 planteados por Losavio et al.

(2003), que poseen subcaracterísticas asociadas con
elementos de tipo arquitectónico.

Relación entre Arquitectura de Software y Atributos de Calidad

ISO/IEC 9126
Adaptado para Arquitecturas de Software (1)

Característica Subcaracterística Elementos de tipo arquitectónico

Adecuación Refinamiento de los diagramas de secuencia
Identificación de los componentes con las
Exactitud
funciones responsables de los cálculos
Funcionalidad Identificación de conectores de comunicación con
Interoperabilidad
sistemas externos
Mecanismos o dispositivos que realizan
Seguridad
explícitamente la tarea
Existencia de mecanismos o dispositivos de
Tolerancia a fallas
software para manejar excepciones
Confiabilidad Existencia de mecanismos o dispositivos de
Recuperabilidad software para reestablecer el nivel de desempeño
y recuperar datos
ISO/IEC 9126
Adaptado para Arquitecturas de Software (2)

Característica Subcaracterística Elementos de tipo arquitectónico

Componentes involucrados en un flujo de
Desempeño
ejecución para una funcionalidad
Eficiencia
Utilización de Relación de los componentes en términos de
recursos espacio y tiempo
Acoplamiento Interacciones entre componentes
Mantenibilidad Número de componentes que dependen de un
Modularidad
componente
Adaptabilidad Presencia de mecanismos de adaptación
Instalabilidad Presencia de mecanismos de instalación
Portabilidad Presencia de mecanismos que faciliten la
Coexistencia
coexistencia
Lista de componentes reemplazables para cada
Reemplazabilidad
componente
Calidades Sistémicas

Definición: Propiedades que establecen la calidad de servicio

(QoS) que un sistema expone.

Tipos mas notables:

Manifiestas

Operacionales

Evolutivas
Calidades Sistémicas - Manifiestas
Observables por los usuarios del sistema.

Performance: Tiempo de respuesta desde el punto de vista del usuario.

Reliability: Grado de probabilidad de realizar operaciones correctamente.
Availability: Porcentaje de tiempo que un sistema puede procesar
solicitudes.
Calidades Sistémicas - Operacionales

Observables cuando el sistema está operando en producción.

Throughput: Solicitudes atendidas por unidad de tiempo.

Manageability: Cantidad inversa de esfuerzo para realizar labores
administrativas.
Serviceability: Esfuerzo para actualizar el sistema para reparar errores.
Security: Prevención de uso indeseado, por abuso o uso inapropiado:
– Identidad
– Autoridad
– Confidencialidad
– Auditabilidad
– Integridad

Testability: Esfuerzo invertido para detectar y aislar errores.

Calidades Sistémicas - Evolutivas
Relacionadas con el comportamiento del sistema cuando sufre algún cambio.

Escalability: La habilidad para soportar la calidad de servicio requerida

conforme la carga aumenta.
Flexibility: Esfuerzo ahorrado cuando se hace un cambio de
configuración.
Portability: Esfuerzo ahorrado cuando se migra a una infraestructura
diferente.
Reusability: Esfuerzo ganado en la utilización de componentes existentes.
Extensibility: Esfuerzo ahorrado para adicionar nuevas funcionalidades.
Mantainability: Esfuerzo ahorrado para revisar y corregir errores.
Servicios de Infraestructura
Se refieren a servicios orientados a la tecnología, como por ejemplo
'Imprimir documento' o 'Enviar email', que son requeridos por las
aplicaciones.
Los servicios de infraestructura definen la llamada ―Calidad de Servicio‖
(QoS por las siglas en ingles de Quality of Service).
Los servicios de infraestructura típicos incluyen:
Messaging (Mensajería y Notificaciones).
Pooling.
Caching.
Clustering.
Naming.
Logging.
etc.
The Sun 3-D Architectural Framework

Tomado de: Suntone Architecture Methodology: a 3-dimensional approach to architectural design

Dimensions
Tiers: A logical or physical organization of components into an ordered
chain of service providers and consumers. Components within a tier
typically consume the services of those in an ―adjacent‖ provider tier and
provide services to one or more ―adjacent‖ consumer tiers. Within a tier,
services are organized together according to like requirements, e.g.
functionality, security, or load distribution.
Layers: The hardware and software stack that hosts services within a
given tier; physical, network, and software platforms and standard API
sets that support the components which provide a service. Layers, like
tiers, represent a well-ordered relationship across interface-mediated
boundaries. While tiers represent processing chains across components,
layers represent container/component relationships in implementation
and deployment of services.
Systemic Qualities: The strategies, tools, and practices that will deliver
the requisite quality of service (e.g. availability, scalability, security, and
manageability) across the tiers and layers.

Tomado de: Suntone Architecture Methodology: a 3-dimensional approach to architectural design

Tiers vs. Layers

Tomado de: Suntone Architecture Methodology: a 3-dimensional approach to architectural design

Tiers
Clients: Any client device or system that manages display and local
interaction processing. Enterprises may not have control over the
technologies available on the client platform, an important consideration
in tier structuring. For this reason state at the client tier should be
transient and disposable.

Presentation services: These services aggregate and personalize

content and services into channel-specific user interfaces. This entails
the assembly of content, formatting, conversions, and content
transformations—anything that has to do with the presentation of
information to end users or external systems. These services manage
channel-specific user sessions and translate inbound application
requests into calls to the appropriate business services.

Tomado de: Suntone Architecture Methodology: a 3-dimensional approach to architectural design

Tiers
Business services: These services execute business logic and manage
transactions. Examples range from low-level services such as authentication
and mail transport to true line-of-business services such as order entry,
customer profile, payment, and inventory management.
Integration services: These services abstract and provide access to external
resources. Due to the varied and external nature of these resources, this tier
often employs loosely coupled paradigms such as queuing, publish/subscribe
communications, and synchronous and asynchronous point-to-point
messaging. Upper-platform components in this tier are typically called
―middleware.‖
Resources: This tier includes legacy systems, databases, external data
feeds, specialized hardware devices such as telco switches or factory
automation, and so on. These are information sources, sinks, or stores that
may be internal or external to the system. The resource tier is accessed and
abstracted by the integration tier.

Tomado de: Suntone Architecture Methodology: a 3-dimensional approach to architectural design

Layers
Virtual platform layer provides an application with standard APIs and
specifications for the upper platform. By writing Applications so that they
depend only on the virtual platform APIs, developers can make
applications portable across upper platform products.

Upper platform layer consists of products such as Web servers,

application servers, and various types of middleware.

Lower platform layer is comprised of the operating system environment

and associated low-level systems services.

Hardware platform layer includes computing hardware such as servers,

storage hardware such as storage arrays, and networking hardware such
as switches and routers, and associated peripherals.

Tomado de: Suntone Architecture Methodology: a 3-dimensional approach to architectural design

Example: Layers vs. QoS

Tomado de: Suntone Architecture Methodology: a 3-dimensional approach to architectural design

¿What is architecture?
Architecture Is NOT about... Architecture Is about...
What happens when a button is How often the button is pushed, how many users are
pushed? simultaneously pushing the button, where the users physically
are (e.g. inside the intranet, out on the Internet, etc.) when they
push the button.
How the system should respond to The timing constraints, if any, between events.
an event.
Which bits of information should What kinds of constraints should be placed on which kind of
be supplied in response to an data, based on which user characteristics.
event.
What are the business rules? How complex are the rules? How often are they changed? Can
they be changed by programmers or by users themselves?
Will they be implemented by a single individual, or by separate
teams? Do they change together or independently?
What is the database schema? How complex is the schema, are there any pre-existing
constraints around it? (E.g. predefined DB.)
What are the fields of the What are the external systems that could be or must be
messages? interacted with, and what are their characteristics?

Tomado de: Suntone Architecture Methodology: a 3-dimensional approach to architectural design

Outline of the Architectural Process

Tomado de: Suntone Architecture Methodology: a 3-dimensional approach to architectural design

Referencias
Piattini, M., Calvo-Manzano, J.A., Cervera, J. y Fernández, L. Análisis y
Diseño de Aplicaciones Informáticas de Gestión: Una perspectiva de
Ingeniería del Software. Ed:Rama, Octubre - 2003

Sommerville, I. "Ingeniería del software" Pearson, 2005 (7ª ed.)

Larman, C. ―UML y Patrones. Introducción al Análisis y Diseño Orientado a

Objetos y al Proceso Unificado‖. Prentice Hall, 2004.

Amador Durán Toro, Beatriz Bernárdez Jiménez, "Metodología para la

Elicitación de Requisitos de Sistemas Software", Versión 2.3, Informe
Técnico LSI–2000–10 (revisado), Universidad de Sevilla

González Rodríguez, Julia, Olsina, Luís. Hacia la Medición de Calidad en

Uso Web Departamento de Informática de Universidad Cáceres España y
UNLPam Argentina.

Grupo de Investigación Kybele. Ingeniería de Requisitos y Calidad de

Producto. Universidad Rey Juan Carlos
Referencias
Barbacci, M., Klein, M., Longstaff, T., & Weinstock, C. (1995). Quality
Attributes. Carnegie Mellon University. Technical Report:
http://www.sei.cmu.edu/publications/documents/95.reports/95.tr.021.html

Kazman, R., Clements, P., Klein, M. (2001). Evaluating Software

Architectures. Methods and case studies. Addison Wesley.

Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The UML Modeling
LanguageUser Guide. Adisson-Wesley

Bass, L., Clements, P., & Kazman, R. (1998). Software Architecture in

practice.Addison-Wesley.

Pressman R. (2002) Ingeniería de Software. Un Enfoque Práctico. Quinta

Edición. Mc Graw Hill.

Sun Microsystems. Suntone architecture methodology: a 3-dimensional

approach to architectural design.

Mauricio Naranjo. Fundamentos de Definición de Arquitectura de Software.

XXV Salón de Informática de ACIS, 2005.