1 Capitulo 2 Diseño de Arquitectura de Software
2 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.
3 Quality Atribute-oriented Software Architecture design methodDiseño de AS Q.A.S.A.R Quality Atribute-oriented Software Architecture design method
4 Diseño de AS Evolución del producto Desarrollo iterativo del productoClientes, 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.
5
6 Artefactos producidos por QASARLos 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
7 Especificación de Requerimientos Arquitectura de Software Diagrama deContexto Interfase Requerimientos Funcionales Arquetipos Relación Prioridad Estructura Componentes Requerimientos de Calidad Relación Expediente de escenarios Decisión de Diseño Resultados de Evaluación
8 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.
9 Importancia del Diseño de ASEl 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
10 Importancia del Diseño de ASEl 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.
11 Estos problemas pueden no estar presentes cuando el personal de una compañía puede considerarse experto en el dominio del sistema.
12 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.
13 El método a usar ok No Estimación de Atributos de CalidadEspecificación de Requerimientos 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 No
14 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.
15 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 Evaluación basada en experiencia
16 Paso 3. Transformación de la arquitecturaImponer 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
17 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.
18 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.”
19 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 --
20 Requisitos No FuncionalesLos requisitos no funcionales tienen una fuerte influencia en la arquitectura del sistema.
21 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.
22 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).
23 El sistema FURPS+ para clasificar requisitos.Supportability Performance Reliability Usability Functionality.
24 FURPS+: Requisitos FuncionalesEstos 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.
25 FURPS+: Requisitos FuncionalesSin 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.
26 Requerimientos funcionales arquitectónicamente significativosFunció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.
27 Casos de Uso y Valor AgregadoActor: 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.
28 Plantilla de Casos de Uso 1UC0001 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
29 Plantilla de casos de uso 2Happy Path Escenario Principal: Este caso de uso inicia cuando el Condómino acude a la oficina del Administrador a pagar su cuota. El Administrador introduce el código del condómino en el sistema. El sistema despliega los datos del condómino y el importe de la cuota a pagar. El administrador informa al Condómino y este ultimo paga. El Administrador captura en el sistema el importe del pago del condómino. El Sistema actualiza el saldo del condominio e imprime recibo de pago. Administrador entrega recibo al Condómino. Fin de Caso de uso. Extensiones: *a. En cualquier momento 1a 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.
30 Requisitos Usabilidad, Fiabilidad, Desempeño , y capacidad de soporteEl 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.
31 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.
32 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.
33 Soporte Supportability se refiere a: Capacidad de ser probado.Adaptabilidad. Mantenimiento: Capacidad de configurarse Escalabilidad
34 Requisitos de diseño, de implementación e interfaceEl "+" 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
35 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.
36 Mecanismos ArquitectónicosSon 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 Persistence RDBMS Oracle Ingres OODBMS ObjectStore Communication Object request broker Orbix VisiBroker Message queue MSMQ MQSeries
37 Relación entre requerimientos y mecanismos
38 Lista completa de mecanismos de análisisMecanismos de analisis.doc|
39 Conseguir requerimientos arquitectónicosConseguir 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.
40 Metodo para obtener requisitos arquitectonicos.Mantener una lista completa de requerimientos arquitectónicos. 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. Asiste a los stakeholder para que vea el impacto potencial de responder las preguntas de una forma u de otra. Captura las respuestas de tus Stakeholders a cada una de las preguntas. Asegúrate una vez que los usuarios además de responder las preguntas asignen una prioridad o peso a cada requerimiento.
41 Ejemplo de un cuestionario (Cuestionario completo)