Capitulo 2Diseño de Arquitectura de

Software

Diseño de AS

• “la actividad más compleja durante el desarrollo de una aplicación es la transformación de las especificaciones de los requerimientos en una arquitectura para el sistema”

• Otras actividades “menos complejas”:– El diseño y la implementación son mejor entendidos– Existen mejores metodologías para el diseño y la

implementación que las existentes para la arquitectura.– El diseño de la arquitectura es mas un arte que una

disciplina de ingeniería.

Diseño de AS

Q.A.S.A.R Q.A.S.A.R Quality Atribute-oriented Software

Architecture design method

Diseño de AS

• Evolución del producto– Clientes, mercadotecnia e ingenieros especifican

características• Desarrollo iterativo del producto

– Descubrimiento de requerimientos en iteraciones y desarrollo de prototipos

• Selección de requerimientos– Inserción de requisitos en cada iteración

• Diseño, evaluación y transformación de la AS– Diseño de la AS basado en RF, evaluación y

transformación de la AS – Ver figura 6 del texto.

Artefactos producidos por QASAR

• Los artefactos producidos por QASAR se muestran en la figura 7.

• Los artefactos caen en dos categorías:– La especificación de requerimientos– La arquitectura del software

Prioridad

Arquitectura deSoftware

Especificación deRequerimientos

Resultados de Evaluación

Requerimientos deCalidad

RequerimientosFuncionales

Expediente de escenarios

Diagrama deContexto

Interfase

Arquetipos Relación

Componentes

Relación

Decisión de Diseño

Estructura

Requerimientos

• La comunidad OO (UML específicamente) usa los Casos de Uso para capturar y especificar los requerimientos funcionales.

• Se usaran Expedientes de Uso para capturar y especificar requerimientos de calidad (así como requerimientos funcionales).

• Los Expedientes de Uso servirán para evaluar en que grado la arquitectura cumple con los requerimientos de calidad.

Importancia del Diseño de AS

• El diseño OO se enfoca en la funcionalidad.

• Con el uso de estos métodos para diseñar la arquitectura se lograra en el sistema:– Reuso– Flexibilidad– Mantenibilidad

Importancia del Diseño de AS

• El proceso típico es construir el sistema de acuerdo a los requerimientos funcionales y posteriormente “afinar” el sistema para agregar los requerimientos de calidad.

• Problema:– Muchos sistemas no pueden ser “afinados” lo

que genera costos muy elevados, en algunos casos es necesario iniciar de nuevo el proceso.

• Estos problemas pueden no estar presentes cuando el personal de una compañía puede considerarse experto en el dominio del sistema.

Pero…• Si los expertos NO DOCUMENTAN cuando éstos se van

la compañía se debilita pues no tiene el conocimiento.• Cuando la compañía inicia el desarrollo de un software en

un nuevo ámbito, esencialmente se inicia de nuevo el proceso.

• La arquitectura no puede ser evaluada explícitamente.• La educación se complica pues no existe conocimiento

para ser enseñado. Los estudiantes deben hacerse de este conocimiento por experiencia propia.

El método a usar

Especificación deRequerimientos

Arquitectura de la Aplicación

QA. Soluciones-Optimizaciones

Diseño de Arq.Basado en

Funcionalidad

Estimación de Atributos de Calidad

Transformación de Arquitectura

ok

Nook

Paso 1.

• Diseño de la arquitectura basado en la funcionalidad.– Desarrollar una arquitectura basándose en los

requisitos funcionales.• Identificar las principales abstracciones (arquetipos)

• Determinar la interacción entre los arquetipos.

Paso 2.

• Evaluar atributos de calidad.– Evaluación basada en escenarios.

• Un conjunto para el diseño (casos de uso)

• Un conjunto para la evaluación

– Simulación y/o elaboración de prototipo• Bueno para atributos de calidad operacionales

– Creación de modelo matemático• Bueno para atributos de calidad operacionales

– Evaluación basada en experiencia

Paso 3.

• Transformación de la arquitectura– Imponer un estilo arquitectónico

• Las capas incrementan flexibilidad pero decrementan rendimiento

– Imponer un patrón arquitectónico• Afecta la arquitectura en general

– Distribuir los requerimientos• Rendimiento y Confiabilidad

Requerimientos

• Requerimientos de Software:– Requerimientos funcionales.- Aquellos relacionados

con la funcionalidad de la aplicación.

– Requerimientos de calidad.- • De Desarrollo.- mantenibilidad, reusabilidad, flexibilidad

• Operacionales.- rendimiento, confiabilidad, tolerancia a fallas.

– Los requerimientos funcionales pueden dirigirse a partes especificas del software, pero los requerimientos de calidad no son fácilmente ubicados en partes específicas.

Requisitos

• Usualmente los requisitos de calidad no pueden ser medidos cuantitativamente de tal forma que no pueden o no ser aprobados.

• Ejemplos:– “El sistema debe tener un grado de mantenibilidad tan

bueno como sea posible.”

– “El rendimiento debe ser satisfactorio para un usuario promedio.”

– “Las GUI deben ser fáciles de usar.”

Tipos de requisitos

Funcionales: Características y capacidades relacionadas con el dominio del problema, que el sistema debe solventar. – Casos de Uso -

No Funcionales (Atributos de calidad):Usability (Usabilidad): Factores Humanos, Ayudas, documentación.Realiability(Confiabilidad): Frecuencia de fallo, Capacidad de recuperación,

etc.Performance(Desempeño): Tiempo de respuesta, Exactitud, capacidad, uso de

recursos.Supportability(Capacidad de soporte): adaptabilidad, mantenimiento,

internacionalización, Configurabilidad.

- Especificación Suplementaria --

Requisitos No Funcionales

Los requisitos no funcionales tienen una fuerte influencia en la arquitectura del sistema.

Casos de Uso: Captando requisitos funcionales.

El principio fundamental de esta tarea es escribir historias de uso del sistema (del futuro sistema).

Pemiten entender, descubrir y registrar los requisitos funcionales.

UP define el Modelo de casos de uso dentro de la disciplina de Requisitos. Es un modelo de la funcionalidad del sistema y su ambiente.

Los clientes y usuarios finales tienen propósitos o necesidades (goals o needs) y desean que los sistemas computarizados les ayuden a lograrlos.

Los UC son historias de uso del sistema que le permiten a los usuarios lograr sus propósitos (o satisfacer sus necesidades-alcanzar sus goals).

El sistema FURPS+ para clasificar requisitos.

FURPS Supportability

Performance

Reliability

Usability

Functionality.

FURPS+: Requisitos Funcionales

Estos requisitos representan las características principales que un sistema debe cumplir.

Por ejemplo en un sistema de almacén un requerimiento funcional puede ser:

El procesamiento de ordenes de entrada/salida.

Control de Stock.

FURPS+: Requisitos Funcionales

Sin embargo, los requisitos funcionales no siempre son específicos del dominio, por ejemplo:

Proveer capacidades de impresión Es un requisito funcional, no especifico del dominio con alto impacto arquitectónico.

Requerimientos funcionales arquitectónicamente significativos

Función Descripción

Auditoria Proporciona información de los cambios realizados en el sistema.

Licenciamiento Proporciona servicios para seguimiento, instalación y monitoreo del uso de licencias de software.

Localización Soportar múltiples idiomas.

Correo Proporcionar servicios para enviar/recibir correo electronico.

Impresión Proporcionar facilidades de impresión (Gráfica, Texto, Etc.)

Reporteo Soporte para reporteo y análisis de información.

Seguridad Proteger los recursos de sistema.

Casos de Uso y Valor Agregado

Actor: Algunas veces tiene comportamiento, como una persona, un sistema computacional, o organización, Ejemplo Cliente.

Esenario: Especifica una secuencia de acciones entre el sistema y actores.

Caso de uso: Una colección relacionada de esenarios satisfactorios y con fallas que describe los actores usando un sistema que cumple con el objetivo.

Plantilla de Casos de Uso 1

UC0001 Cobrar cuotas mensuales Actor Primario: Administrador

Stakeholders e Intereses: Administrador: Desea capturar los pago de manera ágil y sin errores. Asimismo que los pagos actualicen el saldo de la cuenta.

Condómino: Desea un trámite sencillo y obtener un comprobante de pago.

Precondiciones: El Administrador es identificado y autorizado por el sistema.

Poscondiciones: El Pago de mensualidad es registrado. Comprobante de pago es impreso.

Frecuencia de uso Muy Comunmente

Plantilla de casos de uso 2

Escenario Principal:1. Este caso de uso inicia cuando el Condómino acude a la

oficina del Administrador a pagar su cuota.2. El Administrador introduce el código del condómino en el

sistema.3. El sistema despliega los datos del condómino y el importe

de la cuota a pagar. 4. El administrador informa al Condómino y este ultimo paga.5. El Administrador captura en el sistema el importe del pago

del condómino.6. El Sistema actualiza el saldo del condominio e imprime

recibo de pago.7. Administrador entrega recibo al Condómino.8. Fin de Caso de uso.

Extensiones: *a. En cualquier momento1a El Administrador cancela pago de cuota. - El Administrador cancela pago de cuota en el sistema. - Sistema confirma cancelación de pago y regresa al estado

normal.2a. Código de Condómino inválido (no se encuentra en el

sistema) - Administrador pide nombre a Condómino. - Administrador ejecuta Buscar Condómino para obtener el

código correcto.4a. El recibo se atascó en la impresora. - Administrador inserta otro recibo en la impresora. - Administrador ejecuta Reimpresión de Recibos para

entregarlo a Condómino.

Happy Path

Requisitos Usabilidad, Fiabilidad, Desempeño , y capacidad de soporte

El resto de las categorías "URPS+" describe requerimientos no funcionales que son arquitectónicamente significativos.

Usability (Usabilidad) Se refieren a características estéticas y de consistencia en la interface de usuario.

Ejemplo:•Estilo de interface Gráfica: Web, Windows, Consola.•Estetica•Accesibildad: Capacidad de uso para personas discapacitadas.

Reliability (Fiabilidad) trata sobre características como:

Availability (la cantidad de tiempo que el sistema debe estar disponible “up time").

Accuracy( Presición de los cálculos que realiza el sistema)

Recover from failure(Capacidad que tiene el sistema a sobreponerse a los fallos.

Performance(Desempeño) relacionado a propiedades tales como:Throughput (rendimiento) response time (El Tiempo que transcurre desde que el usuario solicita

algo al sistema y este de respuesta), recovery time (Tiempo de recuperación)start-up time and shutdown time.

Soporte

Supportability se refiere a:

Capacidad de ser probado.

Adaptabilidad.

Mantenimiento:

Capacidad de configurarse

Escalabilidad

Requisitos de diseño, de implementación e interface

El "+" en el acrónimo FURPS+ es usado para identificar categorías adicionales que generalmente representan restricciones.

Requerimiento de Diseño, comúnmente llamado restricción de diseño, especifica las opciones para diseñar el Sistema. Ej. Si tu especificas que la persistencia se llevara a través de una BD relacional, es una restricción de diseño. Requerimiento de implementación: Especifica el código o la construcción de un sistema. Ej. Puede incluir los estándares requeridos, lenguajes de implementación, y recursos limites.

Requerimiento de interface: Especifica un elemento externo con el cual el sistema debe interactuar , o especificar los formatos y factores necesarios para esa iteración

Ejemplos:

El producto debe soportar varios idiomas.La persistencia debe ser manejada por una BD Relacional.La BD debe ser Oracle 8i.El sistema debe correr 7d x 24hr durante 365 días.El sistema de ayuda en línea es indispensable.La capa de lógica debe ser escrita completamente en Visual Basic.

Mecanismos Arquitectónicos

Son usados frecuentemente para realizar requerimientos arquitectónicos.

Analysis Mechanism (Aspecto Independiente

Implementación)

Design Mechanism (Algunos detalles de

Implementación)

Implementation Mechanism (depende de la

Implementación)

Persistence RDBMS Oracle

Ingres

OODBMS ObjectStore

Communication Object request broker Orbix

VisiBroker

Message queue MSMQ

MQSeries

Relación entre requerimientos y mecanismos

Lista completa de mecanismos de análisis

Mecanismos de analisis.doc|

Conseguir requerimientos arquitectónicos

Conseguir requerimientos arq. Significa adentrarse en un territorio inexplorado (En contraste con req. Orientados al dominio), por las siguientes razones:

En la mayoría de los sistemas, desde la perspectiva de usuario final, los requerimientos del dominio son mas visibles que su contraparte no funcional.

Stakeholders no están usualmente familiarizados con la mayoría de los requerimientos arquitectónicos.

Técnicas para obtener requerimientos no funcionales son menos conocidas que técnicas para obtener requerimientos específicos al dominio.

Metodo para obtener requisitos arquitectonicos.

1. Mantener una lista completa de requerimientos arquitectónicos.

2. Por cada req. Arquitectónico, formular una o más preguntas, que puedan ayudar en el proceso de especificación. Asegúrate que todos los stakeholders puedan entender las preguntas.

3. Asiste a los stakeholder para que vea el impacto potencial de responder las preguntas de una forma u de otra.

4. Captura las respuestas de tus Stakeholders a cada una de las preguntas.

5. Asegúrate una vez que los usuarios además de responder las preguntas asignen una prioridad o peso a cada requerimiento.

Ejemplo de un cuestionario(Cuestionario completo)Requireme

nt Questions Impact Answers Priority

Licensing Will the system, or parts of the system, be licensed? Are there any constraints on the mechanism used to provide licensing capability?

The greater the sophistication of the licensing mechanism, the longer the time to market, and the greater the long-term maintenance cost.

The stock control module will be marketed as a separate component of the system and will require licensing. The FlexLM tool is used throughout our organization to provide licensing capability.

Medium

Availability Are there any requirements regarding system "up time"? This may be specified in terms of Mean Time Between Failures (MTBF).

The higher the availability, the longer the time to market.

Availability is a key product feature. The product must have an MTBF of 60 days.

High

Platform

support

What platforms must the system support?

Development for a single platform shortens the time to market. It also allows closer integration with platform features. Development for multiple platforms lengthens the time to market. Close integration with platform features is lessened, increasing the maintenance of the system.

The product will be released on the following UNIX platforms: Sun Solaris IBM AIX HPUX

High