1 Curso 2007Ingeniería de SoftwareDiseño 1 Diseñando el Sistema 1. Diseño - qué es Diseño y Especificación de Requerimientos Descomposición - Enfoques 2. Arquitectura (distintos estilos) 3. Técnicas y Herramientas 4. Características de un buen diseño 5. Técnicas para mejorar el diseño 6. Validación del Diseño 7. Documentación

2 Curso 2007Ingeniería de SoftwareDiseño 2 1. Diseño - qué es Significado: *Proceso por el que se genera una solución a un problema *Descripción de la solución Diseño 1 Diseño 2 Diseño n... Distintos Diseños (Alternativas) permiten cumplir con los requerimientos, pero cada uno ofrece prestaciones específicas Requeri- mientos Restricciones

3 Curso 2007Ingeniería de SoftwareDiseño 3 DISEÑO CONCEPTUAL función DISEÑO TÉCNICO forma QUÉ CÓMO Constructores del Sistema Diseñadores del Sistema Clientes Diseño y Especificación de Requerimientos(1)

4 Curso 2007Ingeniería de SoftwareDiseño 4 Diseño y Especificación de Requerimientos(2) “El usuario podrá enviar mensajes a cualquier usuario en cualquier otra computadora en red” Topología de Red Protocolo Velocidad (bps)... DISEÑO TÉCNICO DISEÑO CONCEPTUAL

5 Curso 2007Ingeniería de SoftwareDiseño 5 Descomposición y Modularidad Determinar un conjunto de componentes e interfaces entre ellos, que satisfacen un conjunto especificado de requerimientos (De Marco 1982) Métodos de descomposición (Wasserman 1995) *Modular (a partir de las funciones) *A partir de los Datos *A partir de Eventos (y transiciones de Estados) *A partir de las Entradas (de afuera hacia adentro) *Orientado a Objetos Sistema Modular : cuando cada una de las actividades la realiza exactamente un único componente donde además están bien definidas c/u de sus entradas y salidas.

6 Curso 2007Ingeniería de SoftwareDiseño 6 Proceso de Descomposición Nivel Superior Primer Nivel de descomposición Segundo Nivel de descomposición

7 Curso 2007Ingeniería de SoftwareDiseño 7 Niveles de Diseño (1) Arquitectura: Requerimientos => componentes del sistema y sus interconexiones (2) Diseño del Código: Módulos => algoritmos y estructuras de datos (3) Diseño de la Ejecución: Algoritmos (código) => asignación de memoria, tiempo de ejecución, optimizaciones de código ENFOQUE: trabajar desde lo general a lo particular

8 Curso 2007Ingeniería de SoftwareDiseño 8 Proceso genérico de Diseño (Sommerville) Diseño Arquitectónico Especificación subsistemas Especificación interfaces Diseño estructuras de datos Diseño algoritmos Diseño elementos NIVEL 1 NIVEL 2 NIVEL 3: se realiza sobre el nivel 2

9 Curso 2007Ingeniería de SoftwareDiseño 9 2. Arquitectura (1) Definición, estilos y evaluación: Primer nivel de descomposición, que muestra como se organiza el sistema en términos de sus componentes y las interacciones entre ellos. Cambiar la Arquitectura de un producto ya construido en general exige mucho esfuerzo *=> Evaluación de Arquitecturas Distintos “estilos” que definen familias de sistemas en términos de patrones de organización estructural. Un estilo de arquitectura implica sus componentes, conectores y exigencias al combinarlos. Identificarlos y caracterizarlos para facilitar la comunicación entre diseñadores

10 Curso 2007Ingeniería de SoftwareDiseño 10 2. Arquitectura (2) Influencia y características: Sus características condicionan las características del producto final (escalabilidad, capacidad, desempeño, consistencia, mantenibilidad, compatibilidad, etc.) Estilo y estructura particular elegidos pueden depender de Requerimientos No Funcionales: 1 - Desempeño: localizar operaciones críticas en un número reducido de subsistemas con poca comunicación. Componentes de grano grueso. 2 - Seguridad: estructurar en capas con los recursos más críticos protegidos por las capas más internas con alto nivel de validación. 3 - Mantenibilidad: componentes autocontenidos que puedan ser intercambiados con facilidad, evitando estructuras de datos compartidas. Componentes de grano fino. CONFLICTO DE INTERESES: entre los requerimientos 1 y 3, si se tienen ambos se deberá buscar una solución intermedia.

11 Curso 2007Ingeniería de SoftwareDiseño 11 2. Arquitectura (3) Elementos para la documentación: SAD (Software Architecture Description) salida del proceso de diseño de arquitectura, donde se incluyen modelos gráficos que muestran perspectivas distintas del sistema y descripciones textuales. Documentarla para que pueda ser utilizada y mantenida por otros, con suficiente detalle, sin ambiguedades ni repeticiones, registrando decisiones tomadas. Notaciones: UML general, accesible. ADL’s formales, para expertos. Complejidad se maneja documentando diferentes vistas de la arq., proyección en una dimensión mostrada desde una perspectiva, sin tener en cuenta entidades no relevantes a esa perspectiva. The “4+1” View Model of Software Architecture – Kruchten’95 Vistas definidas: lógica, procesos, implementación, física y CU. Todas son guiadas por los CU (o escenarios) significativos a la arquitectura

12 Curso 2007Ingeniería de SoftwareDiseño 12 Beneficios esperados de prestarle atención: Mejorar la comunicación entre los distintos interesados: *Cliente – diseñadores *Diseñadores – desarrolladores Clarificar intenciones de diseño *la arquitectura concebida a menudo se pierde, comunicación en gral. informal (difícil) Proporcionar bases para análisis del diseño *predecir desempeño y otras características y ajustar el diseño como tarea rutinaria Mejorar el mantenimiento *gran parte del esfuerzo de mantenimiento se dedica a entender Identificar cuestiones interesantes *incluso careciendo de métodos formales 2. Arquitectura (4)

13 Curso 2007Ingeniería de SoftwareDiseño 13 Métodos para evaluación de arquitecturas: Analizar la arquitectura para ver si cumple requisitos de calidad establecidos (ej. confiabilidad, interoperabilidad) Preferible realizar evaluaciones tempranas que permitan introducir cambios con menor impacto y mejorar los aspectos de riesgo identificados Evaluaciones a posteriori resultan útiles como forma de aprendizaje y estudio de posibilidades de mejora, por ej. para una nueva versión del producto Software Engineering Institute (SEI) propone: *Architecture Tradeoff Analysis Method (ATAM) *Software Architecture Analysis Method (SAAM) 2. Arquitectura (5)

14 Curso 2007Ingeniería de SoftwareDiseño 14 Diseño: Arquitectura vs. Programas Implementaciones de partes Interacciones entre partes Muestra Copia de código o llamado a bibliotecas Composición de subsistemas Reutilización Dentro de los límites de módulo Fuera de los límites de módulo Visión Desempeño de algoritmos Desempeño a nivel del Sistema Evaluación En general dinámicoEn general estáticoAnálisis Propiedades computacionales Propiedades estructurales Considera ProgramasArquitectura

15 Curso 2007Ingeniería de SoftwareDiseño 15 Arquitectura–Estilos (Garlan&Shaw, Sommerville,otros) 1.Flujo de Datos *Secuencial por lotes / Tubos y Filtros/ Circuitos de Control 2.Llamada y Retorno *Programa Principal y subrutinas / Orientada a Objetos 3.Componentes Independientes *Procesos que se comunican / Invocación implícita (Eventos) 4.Centrado en los Datos (repositorios) *Bases de Datos / Pizarrones (Blackboards) 5.Máquinas Virtuales *Intérpretes / Capas Jerárquicas 6.Específicas del Dominio de Aplicación Modelos genéricos / Modelos de referencia 7.Distribuidas Cliente-Servidor/ Objetos Dists. / Dist. Procesos, datos / SOAs 8.Heterogéneas y Otras

16 Curso 2007Ingeniería de SoftwareDiseño 16 1 - Flujo de Datos Caracterizadas por: La disponibilidad de los datos controla la ejecución La estructura del diseño está dominada por el movimiento ordenado de los datos de un componente a otro El patrón del flujo de datos es explícito En un sistema puro no hay otra interacción entre procesos Ejemplos: Secuencial por lotes (dominada por actualización de BD) Tubos y Filtros - Filtros conectados en un grafo de flujo de datos Circuitos de Control de Procesos

17 Curso 2007Ingeniería de SoftwareDiseño 17 Tubos y Filtros (1) Características: Por los tubos fluyen datos, transmisión de salidas de un filtro a la entrada de otro Cada filtro admite una o varias entradas (tubos) y una o varias salidas (tubos) Cada filtro es independiente del resto y no conocen la identidad de los filtros antes y después de él La transformación del filtro puede comenzar antes de terminar de leer la entrada (distinto al proceso por lotes) Respetando el grafo, no importa la secuencia (paralelismo) Ejemplo: pipelines (Unix) Filtro Tubo

18 Curso 2007Ingeniería de SoftwareDiseño 18 Tubos y Filtros (2) Bondades: Fácil comprender el comportamiento total de entrada/salida del sistema a partir de los efectos de cada filtro (entrada->transformación->salida) Permite reutilización (simplicidad de interfaces, filtros reutilizables) Fácil evolución y mantenimiento (agregar, sustituir, eliminar filtros) Permite evaluar desempeño (independencia de filtros) Permite ejecución en paralelo Limitaciones: Orientado a procesamiento por lotes (no interactivo) Necesidad de consistencia entre flujos de datos La independencia entre filtros puede acarrear la repetición de procesos de preparación (ineficiencias) *(ej. validaciones)

19 Curso 2007Ingeniería de SoftwareDiseño 19 Circuitos de Control (de Procesos) (1) Propósito: Proveer control dinámico de un entorno físico. Ej. sist. acond. ambiental Mantener propiedades específicas de las salidas del proceso dentro o cerca de valores de referencia indicados (puntos fijos o referencias) Elementos a considerar: Variables a monitorear, sensores a utilizar, su calibración, temporización tanto del sensado como del control. Clasificación: Bucle con retroalimentación (feedback loop) *Mide la variable controlada y ajusta el proceso para mantener el valor cerca o dentro de la referencia. Bucle con prealimentación o anticipador (feedforward loop) *Mide otras variables del proceso que actúan como indicadores e intenta anticipar los futuros efectos sobre la variable controlada.

20 Curso 2007Ingeniería de SoftwareDiseño 20 Circuitos de Control (de Procesos) (2) Proceso Controlador variables de Entrada Punto de fijación Variable Controlada Cambios en las variables manipuladas Bucle con retroalimentación (feedback loop): Bucle anticipador (feedforward loop): variables de Entrada Punto de fijación Controlador Cambios en las variables manipuladas Variable Controlada Proceso

21 Curso 2007Ingeniería de SoftwareDiseño 21 Flujo de Control vs. Flujo de Datos Flujo de Control: *La cuestión dominante es cómo se mueve el control a través del programa *los datos pueden acompañar el control pero no son dominantes *el razonamiento se refiere al orden de ejecución Flujo de Datos: *La cuestión dominante es cómo los datos se mueven a través de un conjunto de procesos atómicos *a medida que se mueven los datos se activa el control *el razonamiento se refiere a la disponibilidad de los datos, su transformación, las demoras

22 Curso 2007Ingeniería de SoftwareDiseño 22 2 - Llamada y retorno Programa Principal y Subrutinas: *Descomposición Funcional tradicional Orientada a Objetos (tipos abstractos de datos) *Ocultamiento de Información, especialmente de representaciones Otros *Capas Jerárquicas *Sistemas Cliente/Servidor *Remote Procedure Call

23 Curso 2007Ingeniería de SoftwareDiseño 23 Programa Principal y Subrutinas (1) Características: Descomposición jerárquica: *basada en la relación “usa” Único Hilo de Control (Thread of Control) *soportado directamente por los lenguajes de programación Estructura de subsistemas implícita *subrutinas agregadas en un módulo Razonamiento jerárquico: *que una subrutina sea correcta depende de que sean correctas las subrutinas llamadas Bondades: *Permite analizar los flujos de control y saber como responderá el sistema a cierto tipo de entradas Limitaciones: Manejo de excepciones

24 Curso 2007Ingeniería de SoftwareDiseño 24 Programa Principal y Subrutinas (2) Principal Subr. ASubr.BSubr.C Subsistema Llamado/Retorno

25 Curso 2007Ingeniería de SoftwareDiseño 25 Orientada a Objetos (1) Caracterizada por: La solución está compuesta por un conjunto de agentes que interactúan Representación de datos y operaciones asociadas se encapsulan en un objeto o TAD. Herencia, Polimorfismo, Sobrecarga de operadores, enlace dinámico Bondades: Facilita el Mantenimiento (localización de impacto) Promueve la reutilización de componentes Permite cambiar la implementación de un objeto sin afectar al resto Limitaciones: Un objeto debe conocer las interfaces de aquellos que utiliza Si se cambia una interfaz, se afectan todos los que la utilizan

26 Curso 2007Ingeniería de SoftwareDiseño 26 Orientada a Objetos (2) Llamado Objeto

27 Curso 2007Ingeniería de SoftwareDiseño 27 3 - Componentes Independientes Procesos que se comunican *Pasan mensajes a los participantes conocidos Sistemas guiados por eventos *Invocación implícita de participantes desconocidos Otros *Envíos de mensajes múltiples con enlace dinámico *Procesos guiados por interrupciones Controlador de interrupciones pasa el control a algún componente para su procesamiento

28 Curso 2007Ingeniería de SoftwareDiseño 28 Procesos que se comunican (1) Características: Muestra al sistema como un conjunto de unidades ejecutando concurrentemente y sus interacciones. Componentes: procesos independientes *típicamente implementados como tareas independientes Conectados por: mensajes *punto a punto *asincrónicos y sincrónicos *RPC y otros protocolos se pueden construir encima Ejemplos: procesos que monitorean ejecución de otros procesos.

29 Curso 2007Ingeniería de SoftwareDiseño 29 Procesos que se comunican (2) Mensaje Proceso

30 Curso 2007Ingeniería de SoftwareDiseño 30 Invocación Implícita (guiada por eventos) Caracterizada por: Se registran procedimientos para los eventos Un componente comunica un evento Cuando se anuncia un evento los procedimientos asociados son invocados implícitamente El orden de invocación es no determinista Bondades: Facilita la reutilización de componentes Fácil cambiar los componentes que atienden un evento Limitaciones: No hay garantías respecto a qué va a pasar frente a un evento (quién responderá ni en que orden se dará la ejecución) Limitaciones en la verificación (comprobar correctitud debido a dependencia del contexto y secuencia de eventos) Ejemplos: Depurador de programas que invoca uno u otro editor

31 Curso 2007Ingeniería de SoftwareDiseño 31 4 - Centrados en los datos (repositorios) Caracterizada por: *Hay un almacenamiento central de datos y un conjunto de componentes que operan sobre éste. Bases de Datos transaccionales *gran almacén de datos central *orden de operación determinado por la entrada de datos Pizarrón (blackboard) *representación central compartida adecuada a una aplicación *orden de operación determinado por estado actual de la estructura central Otros *Herramientas CASE *Sistemas integrados de diseño

32 Curso 2007Ingeniería de SoftwareDiseño 32 Pizarrón (Blackboard) (1) Fuentes de Conocimiento *Procesos independientes que corresponden a particiones del conocimiento del mundo y del dominio dependientes de la aplicación *Responden a cambios en el pizarrón Estructura de datos del Pizarrón *Estado completo de la solución del problema *Jerarquía de datos de estado para resolver el problema *único medio por el cual las Fuentes de conocimiento interactúan para llegar a la solución Control *Guíado enteramente por el estado del pizarrón *Las Fuentes de conocimiento responden oportunamente cuando los cambios en el pizarrón aplican *Puede implementarse en las FC, en el pizarrón, en un componente separado o cualquier combinación de éstos.

33 Curso 2007Ingeniería de SoftwareDiseño 33 Pizarrón (2) Pizarrón FC 1 FC 7 FC 6 FC 2 FC 3 FC 4 FC 5 Cálculos Memoria (Compartida)

34 Curso 2007Ingeniería de SoftwareDiseño 34 5 - Máquinas Virtuales Intérpretes: *crean una máquina virtual cuando no se dispone de la que se desea Capas Jerárquicas: *cada capa constituye una máquina virtual que provee servicios a las otras capas Otros: *Sistemas basados en Reglas °tipo especial de intérpretes *procesadores de lenguaje de comandos *shells

35 Curso 2007Ingeniería de SoftwareDiseño 35 Intérpretes (1) Características: procesador emulado por software datos *representación del programa que se interpreta *estado del programa que se interpreta *estado interno del intérprete El control reside en el ciclo de ejecución del intérprete

36 Curso 2007Ingeniería de SoftwareDiseño 36 Datos (estado del programa) Programa siendo interpretado Estado interno del interprete Motor de interpretación simulada Memoria entradas salidas Máquina de estado de la ejecución Instrucción seleccionada Datos seleccionados Acceso a datos Recuperar/Almacenar Intérpretes (2)

37 Curso 2007Ingeniería de SoftwareDiseño 37 Capas Jerárquicas (1) Caracterizada por: Hay diversas capas, cada una provee un conjunto de servicios a las capas superiores y requiere servicios de las inferiores. Modelo estricto: el acceso a servicios de otras capas está limitado, una capa sólo utiliza servicios de la inmediata inferior, y ofrece servicios a la inmediata superior. Sino Modelo relajado. Definición de protocolos mediante los que interactúan las capas Bondades: Facilita la comprensión (basado en niveles de abstracción) Facilita mantenimiento (posible modificar una capa sin afectar al resto) Facilita reutilización Facilita portabilidad Limitaciones: No siempre es fácil estructurar en capas ni identificar los niveles de abstracción a partir de los Requerimientos Puede afectar el desempeño la coordinación entre los niveles

38 Curso 2007Ingeniería de SoftwareDiseño 38 Capas Jerárquicas (2) Usuarios Criptografía Interfaces de Archivos Gestión de Claves Autenticación Ejemplo: Capas de Sistema de Seguridad

39 Curso 2007Ingeniería de SoftwareDiseño 39 6 – Específicas del dominio de aplicación Modelos específicos para un dominio de aplicación particular Modelos genéricos: *Abstracciones de sistemas existentes que encapsulan las características principales de los mismos. A menudo representan la arq. común de una familia de aplicaciones (línea de productos). Ejs. Módulos que se deben incluir en un compilador Modelos de referencia: *Modelos abstractos idealizados derivados de un estudio del dominio de aplicación. Proveen información sobre la estructura general del sistema y actúan como estándar contra el cual evaluar sistemas. Ejs. Modelo de capas OSI para sists. de comunicación

40 Curso 2007Ingeniería de SoftwareDiseño 40 7 – Distribuidas Cliente-Servidor: *servicios provistos por los servidores y requeridos por los clientes Objetos Distribuidos: *objetos brindan y requieren servicios de otros objetos Service Oriented Architecture (SOA): *composición de servicios (ej. web-services) Distribución de: *Datos (centralizados, distribuidos, replicados) *Procesos (fija, variable) Comunicación: *Remote Procedure Call *Pasaje de mensajes

41 Curso 2007Ingeniería de SoftwareDiseño 41 7 – Distribuidas Características: El procesamiento de la info es distribuído sobre varias computadoras (procesadores) conectados por una red se requiere cierto software de “middleware” para administrar las partes y asegurar comunicación e intercambio de datos el “middleware” es un software de propósito gral. que por lo regular se vende comercialmente, y actúa como mediador entre las partes categorías de “middleware”: monitor transaccional (TPM), remote procedure call (RPC), message oriented mid.(MOM), distributed object mid., database access mid. Bondades: Compartición de recursos, apertura, concurrencia, escalabilidad, tolerancia a fallas, transparencia. Limitaciones: complejidad, seguridad, difíciles de gestionar, poco predecibles

42 Curso 2007Ingeniería de SoftwareDiseño 42 Cliente - Servidor Caracterizada por: hay un conjunto de servicios provistos por los servidores y un conjunto de clientes que requieren esos servicios. Los clientes conocen a los servidores pero no a otros clientes y los servidores no tienen porque conocer a los clientes tanto los clientes como los servidores son procesos lógicos la asignación de procesos a procesadores no tiene porqué ser 1:1 Ejemplo: C i = clientes S i = servidores

43 Curso 2007Ingeniería de SoftwareDiseño 43 Cliente - Servidor en 2 niveles Organización más simple de la distribución C/S, un conjunto de clientes y un servidor (o varios servidores idénticos): CLIENTE FINO: *el procesamiento de la aplicación y manejo de los datos se hace en el servidor. El software en el cliente implementa solo la presentación *Gran carga de procesamiento tanto en el servidor como en la red CLIENTE GRUESO: *el servidor solo es responsable por el manejo de los datos. El software en el cliente implementa la lógica de la aplicación y las interacciones con el usuario. *Administración del sistema más compleja (actualizaciones) Los applets descargables de Java permiten: *Parte del software de procesamiento de la aplicación se descarga en el cliente como applets de Java, la interfaz de usuario se construye utilizando un navegador Web que los ejecuta

44 Curso 2007Ingeniería de SoftwareDiseño 44 3 niveles: *Los procesos lógicos que tienen que ver con la presentación, lógica de aplicación y administración de datos pueden ser distribuídos en 3 sistemas de cómputo distintos. N niveles: *Se amplía la de 3 niveles agregando niveles según se requiera. Ej. aplicación que necesita acceder y utilizar datos de distintas fuentes (integración) Bondades: *Respecto a C/S en 2 niveles: son más escalables, se reduce el tráfico en la red (respecto a cliente fino), facilita la actualización del procesamiento de la aplicación (respecto a cliente grueso) Cliente – Servidor en 3 y más niveles

45 Curso 2007Ingeniería de SoftwareDiseño 45 Objetos distribuidos Características: No hay distinción entre clientes y servidores Cada elemento distribuido es un objeto que provee servicios a otros objetos y requiere servicios de otros objetos. Comunicación entre objetos es a través de un middleware llamado Object Request Broker (software bus) ej. CORBA Más complejos de diseñar que los sistemas C/S Ejemplo:

46 Curso 2007Ingeniería de SoftwareDiseño 46 Service Oriented Architecture (SOA) Características: Funcionalidades expuestas como servicios independientes mediante interfaces públicas bien definidas Procesos del negocio se realizan estableciendo secuencias (coreografías) de invocación de éstas funcionalidades Implementación con web-services brinda mayor interoperabilidad, utilización de protocolos estándares de comunicación e intercambio de información (SOAP, XML) Funcionamiento gral.:

47 Curso 2007Ingeniería de SoftwareDiseño 47 Motivación: Costo de un acceso remoto en una red super- rápida es aprox. 4 veces el costo de un acceso local. Soluciones: Distribuir los datos en varias máquinas según cercanía a quienes más los acceden, el todo es la suma de las partes. Replicar los datos en varias máquinas (caso extremo en cada una) de forma que los accesos sean mayormente locales. Se debe mantener consistencia de las copias Distribución de Datos Distribución de Procesos Puede ser estática o dinámica: Estática: está predefinido donde se ejecutará cada proceso Dinámica: la distribución de procesos se establece en tiempo de ejecución  permite migración de procesos

48 Curso 2007Ingeniería de SoftwareDiseño 48 Remote Procedure Call: Llamada retorno entre módulos en distintas máquinas. Aspectos a tener en cuenta: pasaje de parámetros (distintos espacios de memoria), manejo de excepciones. Pasaje de mensajes: Cada módulo recibe mensajes de otros, los procesa y responde al módulo apropiado. Aspectos a tener en cuenta: cantidad de mensajes que se pueden recibir. Ambos paradigmas son iguales en capacidades, uno puede simularse con el otro. RPC inherentemente sincrónico y pasaje de mensajes asincrónico. Comunicación

49 Curso 2007Ingeniería de SoftwareDiseño 49 8 – Heterogéneas y Otras Combinación de varios de los estilos vistos anteriormente Distintas formas de realizar esta combinación: *Jerárquicamente: un componente organizado en un estilo puede tener estructura interna desarrollada en otro estilo. Ej. Tubos y filtros y cada filtro con otro estilo. *Mezcla de conectores: un componente puede utilizar distintos estilos de conectores para interactuar con distintas partes del sistema. Ej. un componente accede a un repositorio a través de parte de su interface pero interactúa a través de tubos con otros componentes. Otras: clasificación no cerrada, pueden haber otros estilos, pueden clasificarse en forma distinta ……

50 Curso 2007Ingeniería de SoftwareDiseño 50 3. Técnicas y Herramientas Concurrencia Interfaz de Usuario Principios para guiar el Diseño Modelo de Análisis de Jacobson Tarjetas CRC Diagramas UML Patrones de Diseño Marcos de trabajo (Frameworks) Model Driven Development / Architecture (MDD – MDA) Desarrollo basado en componentes

51 Curso 2007Ingeniería de SoftwareDiseño 51 Procesos Concurrentes Control de Acceso a Recursos Compartidos *Exclusión mutua (Prueba y Bloqueo en una operación indivisible) *Guardián (un “demonio” que acepta requerimientos si el recurso está disponible) *Monitores (un objeto abstracto que exporta servicios garantizando exclusión) Tiempo Real *Procesos Concurrentes + tiempo crítico Según gravedad de no suministrar servicio en el plazo: °Soft – operación se degrada si no se cumplen los reqs. de tiempo (ej: central telefónica) °Hard – operación es incorrecta si no se cumplen los reqs. de tiempo (ej: central nuclear)

52 Curso 2007Ingeniería de SoftwareDiseño 52 Complejidad en el diseño Sist. Secuencial tiempo solo Sist. Concurrente afecta performance Sist. Tiempo Real *Softtiempo también *Hardafecta correctitud Los Sists. de Tiempo Real en gral. interactúan con ambiente externo que produce estímulos en forma autónoma a los cuales el software debe responder en un tiempo límite establecido.

53 Curso 2007Ingeniería de SoftwareDiseño 53 Diseño de la Interfaz de Usuario (1) Principios generales (Sommerville) Familiaridad: utilizar términos familiares a los usuarios Consistencia: menúes y comandos con el mismo formato y significado en toda la aplicación Mínima sorpresa: misma acción en contextos comparables produzcan un cambio similar Recuperabilidad: recuperación frente a errores cometidos por el usuario, brindar: * confirmación de acciones destructivas *recursos para deshacer en varios niveles Guía al usuario: proveer ayuda en varios niveles Diversidad de usuarios: tener en cuenta distintos tipos de usuarios.

54 Curso 2007Ingeniería de SoftwareDiseño 54 Diseño de la Interfaz de Usuario (2) Elementos Claves (Pfleeger): Metáforas: imágenes fundamentales y conceptos Modelo del método: la organización y representación de la información Reglas de navegación para el modelo: cómo moverse y el modelo espacial Apariencia: transmite información y significado para los usuarios Sensación: la que proporciona experimentar las técnicas de interacción

55 Curso 2007Ingeniería de SoftwareDiseño 55 Color en el diseño de la Interfaz (1) Lineamientos clave (Shneiderman 1998) Limitar cantidad de colores utilizados, no más de cuatro o cinco colores distintos por ventana Utilizar un cambio de color para indicar un cambio en el estado del sistema Utilizar el código de colores para apoyar tarea de usuarios, por ej. resaltar similitudes o diferencias Utilizar el código de colores en forma consistente, por ej. desplegar mensajes de error en rojo siempre! Tener cuidado al combinar colores que puedan producir cansancio en la vista

56 Curso 2007Ingeniería de SoftwareDiseño 56 Color en el diseño de la Interfaz (2) Elementos culturales ¿Qué color utilizar? ¿Púrpura? *En Inglaterra representa la realeza *En Japón, dignidad y nobleza *En Grecia representaba al diablo y la muerte Dos pasos para hacer nuestros sistemas multi- culturales *(1) eliminar sesgos o referencias a una cultura específica *(2) ajustar (1) para las culturas que utilizarán el software

57 Curso 2007Ingeniería de SoftwareDiseño 57 Preferencias de Usuario A ella le gusta, a él no... No hay una interfaz universal aplicable a todo el mundo construir un prototipo y evaluarlo con la audiencia objetivo permitir adaptar la interfaz de usuario *ejemplo: Microsoft Word vs. WordPerfect

58 Curso 2007Ingeniería de SoftwareDiseño 58 Guía para definir la interfaz de usuario Facilidad de Uso Alto Medio Bajo Entrada de datos Reconocimiento Línea de Formu- Pantalla OCR de Voz Comandos larios sensibleoptical character al tacto recognition

59 Curso 2007Ingeniería de SoftwareDiseño 59 Soporte al Usuario Sistema de ayuda debe proveer: *Mensajes de error °Amables, concisos, consistentes y constructivos, si es posible incluir sugerencia para correción *Ayuda en línea °Páginas web con hipervinculos, ventanas múltiples °Cuidar la estructura de navegación, si es compleja los usuarios se pierden *Documentación de usuario °Incluyendo secciones de: instalación, descripción general, descripción funcional, mensajes de error.

60 Curso 2007Ingeniería de SoftwareDiseño 60 Mensajes de error Error #27 Identificador de paciente no válido ? El paciente J. Bates no está registrado Seleccione: Pacientes para listado de pacientes registrados Reintentar para reingresar el nombre del paciente Ayuda para más información Pacientes Mensaje orientado al sistema Mensaje orientado al usuario AyudaReintentarCancelar Aceptar Cancelar

61 Curso 2007Ingeniería de SoftwareDiseño 61 Diseño - Principios Diseño para el Cambio Separación de Intereses Modularización (localización del impacto de los cambios) Niveles de Abstracción (facilita comprensión) Ocultamiento de Información (encapsular) Alta Cohesión, Bajo Acoplamiento

62 Curso 2007Ingeniería de SoftwareDiseño 62 Diseño para el cambio ¿Qué puede cambiar? *Algoritmos °requerimientos de desempeño, escala *Representación de los datos °requerimientos de desempeño, escala °cambios en interfaces *equipos externos *ambiente social Para reducir el impacto de los cambios: Modularizar

63 Curso 2007Ingeniería de SoftwareDiseño 63 Modularización (1) Módulo: un componente bien definido de un sistema de software que provee recursos y servicios *Están bien definidos: °Recursos y Servicios °La forma de suministrarlos (Interfaces) *Un módulo puede ser un programa o varios, una subrutina o varias Principio de Separación de Intereses *cada módulo se ocupa de aspectos específicos

64 Curso 2007Ingeniería de SoftwareDiseño 64 Modularización (2) Definir módulos e interfaces *Interfaces definen el acoplamiento entre módulos *Comportamiento (Pre-Post condiciones) y colaboraciones Ocultamiento de Información *La información de un módulo debe ser privada a menos que se declare pública, única garantía de que otros módulos no la utilicen ( - impacto de cambios, + fácil de comprender y usar) *Diseño interfaz:¿Qué servicios brindar, qué ocultar? °Mínima, bien definida, independiente de implementación Alta Cohesión – Bajo acoplamiento *Alta cohesión interna de cada módulo (los elementos del módulo están fuertemente relacionados entre sí) *Bajo acoplamiento entre módulos (débiles conexiones entre módulos -impacto reducido de cambios)

65 Curso 2007Ingeniería de SoftwareDiseño 65 Categorías de módulos Sin persistencia (estado) *Abstracciones de procedimientos (algoritmo) *Bibliotecas (ej. rutinas matemáticas) Sólo Datos *Repositorio común de datos (ej. Configuración) Algoritmos + Estado *Objetos abstractos (ej. Stack) Tipos Abstractos de Datos *paramétrico en tipo (ej. Stack (?) ) Clases (OO)

66 Curso 2007Ingeniería de SoftwareDiseño 66 Criterios para modularizar Descomposición *Descomponer el problema en sub-problemas (diseño top-down) Composición *A partir de los componentes es posible obtener un nuevo sistema (diseño bottom-up) Continuidad del impacto por cambios *Pequeños cambios en la especificación afectan pocos módulos Protección durante ejecución *Efectos de anomalías durante la ejecución están localizados

67 Curso 2007Ingeniería de SoftwareDiseño 67 Principio Abierto/Cerrado “los módulos debieran ser a la vez abiertos y cerrrados” Abierto para permitir extensiones *Agregar operaciones o atributos para extender el comportamiento *Cambiar representaciones internas e implementaciones en caso necesario Cerrado para permitir ser usado por otros módulos *La interfaz debe mantenerse cerrada a los cambios y asegurar que se mantiene el comportamiento (pre- y post-condiciones)

68 Curso 2007Ingeniería de SoftwareDiseño 68 Principio de elección única Cuando un sistema de software debe soportar un conjunto de alternativas, un módulo y sólo uno debe conocer la lista completa de alternativas Minimiza *Código a escribir *Impacto de cambios en la lista *Reduce la complejidad y por lo tanto facilita comprensión En general, se debe minimizar la distribución de conocimiento

69 Curso 2007Ingeniería de SoftwareDiseño 69 Modularización - Beneficios Separar aspectos del diseño *Permitir cambiar algunos sin afectar al resto Permite *Extender fácilmente artefactos (extensibilidad) *Reusar artefactos existentes (reusabilidad) *Ocultar dependencias de la plataforma (portabilidad) *Diseñar interfaces que se adapten a otras (compatibilidad) *Minimizar impacto de cambios (mantenibilidad) *Facilitar la comprensión *Organizar y distribuir el trabajo Alta modularización => Alta cohesión – Bajo acoplamiento

70 Curso 2007Ingeniería de SoftwareDiseño 70 Cohesión Coincidente (no relacionados) Lógica (tipo de función) Temporal (se usan en el mismo momento) de Procedimiento (asegurar el orden de ejecución) de Comunicación (operan sobre o generan los mismos datos) Secuencial (salida de una parte es entrada de otra) Funcional (cada parte es esencial para cumplir una función) de Información (TAD – extensión para OO)

71 Curso 2007Ingeniería de SoftwareDiseño 71 Cohesión Coincidente Poca o ninguna relación entre los elementos de un módulo *Dificulta el mantenimiento *Módulos no reusables Manifestaciones en el caso de OO *Clase no representa un único concepto OO *Conjunto de código usado frecuentemente como una clase con herencia múltiple

72 Curso 2007Ingeniería de SoftwareDiseño 72 Cohesión Lógica El módulo cumple varias funciones relacionadas. Al invocar al módulo se debe indicar mediante un parámetro qué función llevar a cabo *Interfaz difícil de entender *El código para más de una función puede entremezclado *Difícil de reusar Solución: *Aislar cada función en operaciones separadas

73 Curso 2007Ingeniería de SoftwareDiseño 73 Cohesión Temporal Los elementos del módulo están agrupados porque se usan en el mismo período *No reusable Ejemplo: *Módulo que concentra la inicialización de valores a objetos *Módulos que se encargan de limpiar al fin de un trabajo

74 Curso 2007Ingeniería de SoftwareDiseño 74 Cohesión de Procedimiento Los elementos del módulo están agrupados sobre la base de participar en un proceso o algoritmo *Específicos para una aplicación *Difícilmente reusable *En el contexto el módulo es razonable, pero difícil de entender fuera de este Solución: *Rediseñar

75 Curso 2007Ingeniería de SoftwareDiseño 75 Cohesión de Comunicación Los elementos del módulo usan y/o generan el mismo conjunto de datos *Difícilmente reusable Solución: *Aislar cada elemento en módulos separados

76 Curso 2007Ingeniería de SoftwareDiseño 76 Cohesión Funcional Las operaciones de un módulo se pueden describir colectivamente como una única función *más reusable *Mantenimiento correctivo más fácil En OO: *Cada operación de la interfaz pública debiera presentar cohesión funcional *Cada objeto debe representar un único concepto cohesivo

77 Curso 2007Ingeniería de SoftwareDiseño 77 Cohesión de Información Un módulo tiene cohesión de información si cumple varias funciones: *Varios puntos de entrada *Cada entrada desempeña una función específica *Todas las funciones están relacionadas por un concepto, estructura de datos, o recurso que el módulo oculta

78 Curso 2007Ingeniería de SoftwareDiseño 78 Acoplamiento Acoplamiento por Contenido *modificación de variable interna, ejecución de una porción de procedimiento Area Común (cualquiera modifica) De Control (No hay ocultamiento de información) *Parámetro (de entrada o salida) que gobierna ejecución Estructura de Datos (comparten la estructura) Datos (lo deseable) – mínima No acoplado

79 Curso 2007Ingeniería de SoftwareDiseño 79 Tarjetas CRC (1) Clase - el nombre Responsabilidades- lo que sabe y lo que hace Collaboraciones- quiénes le ayudan Clase: Model Colaboradores: View Controller Responsabilidad: Proporciona el núcleo de funcionalidad de la aplicación Registra los View y Controller dependientes Notifica a los componentes dependientes acerca de cambios en los datos

80 Curso 2007Ingeniería de SoftwareDiseño 80 Tarjetas CRC (2) Permite una rápida visión de los elementos esenciales de las clases al encarar la descomposición Se usan como técnica de diseño con participación de usuarios *Cada uno desempeña el rol de una clase *Cada uno describe lo que hace al “ejecutar” un determinado escenario de cierto caso de uso

81 Curso 2007Ingeniería de SoftwareDiseño 81 Diagramas UML (1) Paquetes (visión de alto nivel mostrando dependencias) *mecanismo para agrupación de elementos *la dependencia significa que cambios en uno afectan al otro Subsistemas (visión de paquetes, comportamiento de clases) *agrupación lógica de elementos de diseño, con interface de servicios que brinda (implementados por las clases) De Interacción (dos visiones distintas de lo mismo) *Secuencia (deja en claro la evolución temporal) *Comunicación (muestra más claramente las interacciones, pero el orden está dado por números) Clases (relaciones estáticas, operaciones,navegabilidad) Componentes (dependencias entre componentes) Despliegue (Deployment del software en el hardware)

82 Curso 2007Ingeniería de SoftwareDiseño 82 Diagramas UML (2) Paquetes Elemento de modelado que contiene otros elementos de modelado como mecanismo de agrupación no tiene semántica definida puede no tener representación en implementación (si tiene podría ser un directorio) un paquete es dueño de sus elementos; un elemento pertenece a un solo paquete el uso de paquetes fuerza a la modularidad

83 Curso 2007Ingeniería de SoftwareDiseño 83 Diagramas UML (3) Subsistemas agrupación de elementos donde algunos constituyen la especificación del comportamiento ofrecido por otros elementos contenidos [Booch,1999] elemento de modelado que tiene semántica package+clase que provee comportamiento implementa una o más interfaces que definen el comportamiento del subsistema un subsistema representa un componente en el diseño el uso de subsistemas fuerza a la modularidad &encapsulación

84 Curso 2007Ingeniería de SoftwareDiseño 84 Diagramas UML (4) Componentes describe la organización de los componentes físicos del sistema un componente es la realización física de una abstracción en el diseño los componentes corresponden a implementación ejemplos de componentes son: *.exe,.dll,.java,.class se pueden estereotipar como: >, >, >, entre otros.

85 Curso 2007Ingeniería de SoftwareDiseño 85 Diagramas UML (5) De Interacción: Secuencia sobre un conjunto de objetos y sus relaciones, muestra la interacción entre éstos incluyendo los mensajes que intercambian el orden de los mensajes se muestra en relación al tiempo cada objeto tiene una línea de vida sobre la cual se muestran los bloques de activación (tiempo que el objeto necesita para completar una tarea) se pueden modelar mensajes sincrónicos y asincrónicos, loops, entre otros.

86 Curso 2007Ingeniería de SoftwareDiseño 86 Diagramas UML (6) De Interacción:Comunicación sobre un conjunto de objetos y sus relaciones, muestra la interacción entre éstos incluyendo los mensajes que intercambian el orden de los mensajes se muestra numerado los mensajes se pueden anidar mostrando la anidación con la numeración, se pueden modelar loops. las asociaciones son las existentes entre los objetos en el diagrama de clases.

87 Curso 2007Ingeniería de SoftwareDiseño 87 Diagramas UML (7) Clases: Muestra las clases en el sistema y como se relacionan Información sobre atributos y tipos correspondientes, operaciones con paramétros y tipos correspondientes, multiplicidad de las asociaciones, agregación, composición, generalización. Clases que pueden iniciar y controlar flujo de las actividades se recuadran en negritas (por ej. correspondiente a una clase de control para un CU)

88 Curso 2007Ingeniería de SoftwareDiseño 88 Diagramas UML (8) Deployment o despliegue muestra los recursos físicos de un sistema incluyendo componentes, nodos y conexiones presenta la distribución de componentes de software en nodos donde ejecutan, y las asociaciones entre los nodos asociaciones representan conexiones físicas entre nodos estereotipadas por protocolos de la comunicación, ej. TCP/IP, HTTP.

89 Curso 2007Ingeniería de SoftwareDiseño 89 Patrones de Diseño “ Un patrón es una solución a un problema en un contexto” (Christopher Alexander) => Reuso y Diseminación Surgen en la arquitectura (de casas) y los principios se aplicaron exitosamente a OOP. Nombre del patrón. Hace posible referirse a él. El problema. Un patrón particular es aplicable a ciertos tipos de problemas. Un aspecto relevante de la definición de un patrón es la descripción de para qué tipos de problemas es útil. La solución. Un patrón define una solución conceptual particular al problema. Consecuencias. Las decisiones de implementación implican ciertos compromisos. Las consecuencias de esas decisiones y las fuerzas que están por detrás del patrón son aspectos esenciales de este.

90 Curso 2007Ingeniería de SoftwareDiseño 90 Patrones de Diseño para Sistemas Interactivos Mecanismos complicados de GUI *Cambios y adaptaciones frecuentes *Múltiples estándares de apariencia Funcionalidad Compleja *Usualmente permanece relativamente estable El problema: *mantener la funcionalidad del núcleo independiente de Interfaz de Usuario Patrones: *Model-View-Controller (MVC) *Presentation-Abstraction-Control (PAC)

91 Curso 2007Ingeniería de SoftwareDiseño 91 Model-View-Controller (MVC) Model *Núcleo de la Funcionalidad View *Desplegar la Información Controller *manejar la entrada de usuario GUI Datos del Núcleo Ejemplo:

92 Curso 2007Ingeniería de SoftwareDiseño 92 MVC - Fuerzas La misma información se presenta distinto en diferentes ventanas El despliegue y comportamiento de la aplicación debe reflejar inmediatamente las manipulaciones de los datos Cambios a la IU debieran ser fáciles y posibles en tiempo de ejecución Soportar distintos estándares de apariencia o portar la IU no debiera afectar el núcleo de la aplicación

93 Curso 2007Ingeniería de SoftwareDiseño 93 MVC - Clases (1) Clase: Model Colaboradores: View Controller Responsabilidad: Proporciona el núcleo de funcionalidad de la aplicación Registra los View y Controller dependientes Notifica a los componentes dependientes acerca de cambios en los datos Encapsula los datos, proporciona métodos de acceso para las vistas “Controllers” invocan los métodos exportados para el procesamiento de la aplicación El patrón “Observer” se puede usar para propagar los cambios

94 Curso 2007Ingeniería de SoftwareDiseño 94 MVC - Clases (2) Clase: View Colaboradores: Controller Model Responsabilidad: Crea e inicializa su Controller asociado Obtiene datos de Model Despliega información al usuario Implementa el procedimiento update Cada View crea un Controller adecuado (uno a uno) Ofrece interfaces que habilitan a Controller para algunas manipulaciones de despliegue que no afectan el modelo (p.e. scroll)

95 Curso 2007Ingeniería de SoftwareDiseño 95 MVC - Clases (3) Clase: Controller Colaboradores: View Model Responsabilidad: Acepta entradas del usuario como eventos Traduce eventos en solicitudes de servicio para Model o View Si se precisa, implementa el procedimiento update EL procedimiento update se implementa en caso de que el comportamiento de Controller depende del estado de Model (p.e. un cambio del modelo habilita o deshabilita un menú)

96 Curso 2007Ingeniería de SoftwareDiseño 96 Diagrama de Clases

97 Curso 2007Ingeniería de SoftwareDiseño 97 Distintas opciones Cliente/Servidor Cliente Servidor Int. Usuario Int. Usuario Lógica Aplic. DBMS Int. Usuario Lógica Aplic. DBMS Interfaz distribuida Aplic. Remota Int. Usuario Lógica Aplic. Lógica Aplic. DBMS Aplic. distribuida Int. Usuario Lógica Aplic. DBMS Int. Usuario Lógica Aplic. DBMS DBMS Remoto DBMS distribuido

98 Curso 2007Ingeniería de SoftwareDiseño 98 Patrones para Distribución Además, se pueden tener otros niveles... *¿cuál es el costo de cambiar la forma de distribución? *¿cómo incide en el esfuerzo de desarrollo la comunicación entre los componentes? Problema: *Componentes remotos debieran aparecer como locales *Cliente y Servidores no debieran preocuparse de la comunicación

99 Curso 2007Ingeniería de SoftwareDiseño 99 Solución: *Un sustituto del servicio que permite el acceso local Proxy Cliente Servicio Abstracto servicio Servicio servicio Proxy servicio No es directamente accesible al Cliente 11 Proxy representa al Servicio y asegura el acceso a él (misma interfaz)

100 Curso 2007Ingeniería de SoftwareDiseño 100 Proxy – diagrama de secuencia ClienteProxyServicio servicio Pre-proceso y asignación Post-proceso y devolución

101 Curso 2007Ingeniería de SoftwareDiseño 101 ¿Cuántos proxys precisamos? Problema: *Muchos servicios pueden ser remotos *Las ubicaciones de estos pueden cambiar *Se deben poder agregar, cambiar y suprimir servicios dinámicamente *Los detalles debieran quedar ocultos para el desarrollador

102 Curso 2007Ingeniería de SoftwareDiseño 102 Broker Proxy-Cliente Servicio_p Proxy-Servidor Servicio Abstracto Call_servicio_p Servidor Servicio_i llama mensajes Solución: *Un intermediario entre proxys cliente y servidor

103 Curso 2007Ingeniería de SoftwareDiseño 103 Broker - diagrama de secuencia

104 Curso 2007Ingeniería de SoftwareDiseño 104 Marcos de trabajo (Frameworks) (1) Aplicación reusable, semi-completa que puede ser especializada *Proporciona un esqueleto extensible *Soporta reuso del diseño y del código Gran parte del esfuerzo y costo proviene de: *Redescubrir y reinventar el diseño de clases básicas y de sus interacciones Clases de frameworks: *infraestructura de sistemas (ej. interfaces usuario Struts) *integración de middleware (ej. Corba, Com) *aplicaciones empresariales (ej. sists. Financieros)

105 Curso 2007Ingeniería de SoftwareDiseño 105 Marcos de trabajo (Frameworks) (2) Diferencias con otras bibliotecas de clases: *Principio de “inversión del control” *Basado en el patrón de diseño “template method *Captura las interacciones entre objetos en un “template method”, postergando algunos pasos (“hook methods”) *Especificando los “hook methods” los desarrolladores pueden ajustar las interacciones provistas por el framework *Son los “template methods” los que invocan a los “hook methods” => inversión del control

106 Curso 2007Ingeniería de SoftwareDiseño 106 Marcos de trabajo (Frameworks) (3) biblioteca aplicación Framework Biblioteca de Clases biblioteca aplicación Reescribiendo los “hook methods”el desarrollador inserta la personalización Framework invoca “hook methods” como parte de su interacción El desarrollador implementa las clases del núcleo y sus interacciones reusando funcionalidad ya existente Conjunto de clases con funcionalidad preexistente

107 Curso 2007Ingeniería de SoftwareDiseño 107 Marcos de trabajo (Frameworks) (4) Problemas: *No existe metodología: °cómo desarrollarlos °Cómo usarlos *Curva de aprendizaje °En general lleva mucho tiempo y esfuerzo aprender a utilizar un marco de forma eficiente. Cuanto más complejo el marco, mayor es la curva de aprendizaje

108 Curso 2007Ingeniería de SoftwareDiseño 108 Model Driven Development/Architecture (MDD - MDA) (1) Enfoque de desarrollo basado en modelos *brinda significado al uso de modelos *dirigen el curso del: conocimiento, diseño, construcción, distribución, operación, mantenimiento y modificación del sw MDA es un estándar bastante reciente del OMG (Object Management Group) ( versión 1.0.1 junio 2003 ) Principales objetivos de MDA *Portabilidad *Interoperabilidad *reusabilidad

109 Curso 2007Ingeniería de SoftwareDiseño 109 Principales conceptos de MDA Computation Independent Model (= modelo de dominio) Platform Independent Model (funcionalidad y comportamiento del sistema, sin detalles de tecnología) Platform Specific Model ( mapeo a diversas tecnologías de middleware, generado a partir del PIM, aplicando mapeos standard de la OMG. Código parcialmente autom.) Model Driven Development/Architecture (MDD - MDA) (2) CIM PIM PSM

110 Curso 2007Ingeniería de SoftwareDiseño 110 Ejemplo de MDA *Modelo conceptual UNICO *Modelo funcionalidad y comportamiento UNICO PSM (distintas plataformas) y Deployment Model Driven Development/Architecture (MDD - MDA) (3) CIM PIM Modelo Corba Modelo Java/EJB Modelo XML/SOAP Otros Modelos CorbaJava/EJBXML/SOAPOtros

111 Curso 2007Ingeniería de SoftwareDiseño 111 Desarrollo basado en componentes (1) Surgimiento a fines de los ’90, originado por el no cumplimiento de las expectativas de reutilización que había prometido el desarrollo OO, debido a: *Clases demasiado detalladas, específicas y ligadas a las aplicaciones *Muchas veces hacía necesario disponer del código fuente => dificultades en comercialización Visión de componente: proveedor de servicios *Entidad ejecutable e independiente *Publica interfaz de servicios suministrados y las interacciones son a través de ésta *Generalmente también define interfaz de servicios que debe proveer el sistema que lo utiliza

112 Curso 2007Ingeniería de SoftwareDiseño 112 Desarrollo basado en componentes (2) Distintos niveles de abstracción (Meyer ’99) *Funcional: implementa una sola función (ej.matematica) *Agrupamiento casual: colección de entidades relacionadas débilmente (ej. declaraciones de datos, funciones) *Abstracciones de datos: abstracción o clase de datos en OO (crear, modificar, acceder) *Abstracciones de clúster: grupo de clases relacionadas que trabajan conjuntamente (también marcos de trabajo o frameworks) *Abstracciones de sistemas: sistema autocontenido (también COTS)

113 Curso 2007Ingeniería de SoftwareDiseño 113 4. Características de un buen Diseño Independencia de Componentes Tratamiento de Anomalías Prevención de Fallas

114 Curso 2007Ingeniería de SoftwareDiseño 114 Independencia de componentes Cuanto mayor es la independencia, más fácil es: *La comprensión *Mejorar, extender, adaptar, corregir *Mantenimiento Medida de independencia (Myers, Constantine) *Cohesión: medida de cuán focalizado está el módulo en una cosa *Acoplamiento: medida de cuán conectado está el módulo con otros y con el ambiente Se busca alta cohesión y bajo acoplamiento

115 Curso 2007Ingeniería de SoftwareDiseño 115 Identificación y Tratamiento de Anomalías Diseño defensivo *tratando de anticipar situaciones que podrían llevar a problemas en el sistema Anomalías incluyen: *imposibilidad de brindar un servicio *proporcionar un servicio o datos incorrectos *corrupción de datos Tratamiento: *Reintentar: restaurar e intentar nuevamente con estrategia distinta *Corregir: restaurar, corregir algo e intentar de nuevo con misma estrategia *Informar: de la imposibilidad a alguien, restaurar pero no intentar nuevamente

116 Curso 2007Ingeniería de SoftwareDiseño 116 Prevención de Faltas y Tolerancia a Faltas Tratar de anticipar faltas y manejarlas de forma de minimizar los efectos negativos y maximizar la seguridad Falta: el error cometido por una persona se traduce en una falta en un producto de software (o productos) Falla: desvío del sistema del comportamiento requerido No toda falta produce una falla, las condiciones para que una falta resulte en falla pueden no producirse nunca Prevenir o tolerar faltas para evitar fallas, construyendo el sistema para que reaccione de manera aceptable

117 Curso 2007Ingeniería de SoftwareDiseño 117 Técnicas para evitar fallas (1) Detección activa de faltas (antes de ser falla) *Periódicamente verificar síntomas de faltas, anticipar si van a ocurrir: °control de totales, dígitos verificadores (redundancia) *Sospecha mutua : cada componente verifica sus entradas, supone que los demás tienen defectos *Procesos independientes sincronizados: arquitectura especial, realizan en paralelo el mismo trabajo y comparan resultados continuamente *Ejecutar n versiones distintas del programa: °diseño y construcción independiente °con mecanismos de votación para decidir acción siguiente

118 Curso 2007Ingeniería de SoftwareDiseño 118 Técnicas para evitar fallas (2) Respuesta a la Falta Detectada: *Dependiendo de la criticidad del sistema, falta, requerimientos de disponibilidad, mantenibilidad, se puede: °Detener el sistema (más fácil determinar causa) °Registrar y continuar a partir de un estado seguro *reparar el daño causado por la falta *cambiar el sistema para eliminar la falta Tolerancia a Faltas: *aislamiento del daño causado por la falta *prevenir que la falta se convierta en falla *basada en la predicción de las ubicaciones de las faltas y definición de caminos alternativos de operación

119 Curso 2007Ingeniería de SoftwareDiseño 119 5. Técnicas para Mejorar el Diseño Reducir Complejidad Diseño por Contrato Prototipado del Diseño Análisis de Arbol de Faltas

120 Curso 2007Ingeniería de SoftwareDiseño 120 Reducir Complejidad (1) 10 9 8 7 6 5 4 3 2 1 20253035 Complejidad del Diseño del Sistema Faltas por mil lineas de código

121 Curso 2007Ingeniería de SoftwareDiseño 121 Reducir Complejidad (2) Generalidad de la solución *con menos componentes más simples resolver el problema *nivel de abstracción Adaptabilidad de la solución *cubrir con una solución distintos problemas particulares

122 Curso 2007Ingeniería de SoftwareDiseño 122 Diseño por Contrato (B.Meyer) interacción entre componentes basada en contrato entre un cliente de un servicio y un proveedor del mismo contrato define: *obligaciones del cliente-requisitos del servidor (precondiciones) *beneficios cliente-compromiso servidor (post-condiciones) si un servidor recibe un requerimiento que no cumple las precondiciones, no está obligado a nada *podría abortar la ejecución, entrar en ciclo sin fin, etc. internamente cada componente tendrá ciertas restricciones de consistencia (invariantes) tratamiento de excepciones *si un servidor no puede cumplir un servicio, debe levantar una excepción (la que debe ser tratada por el cliente)

123 Curso 2007Ingeniería de SoftwareDiseño 123 Prototipado de Diseño Brooks (1975) recomienda construir un sistema, tirarlo y construirlo de nuevo para aprovechar en el segundo el aprendizaje de los errores cometidos al construir el primero Construir una parte del sistema para evaluar factibilidad /riesgos *prototipo desechable *evolutivo *herramientas RAD (Rapid Application Development) Mejora la comunicación en el grupo y con el cliente

124 Curso 2007Ingeniería de SoftwareDiseño 124 Análisis del Arbol de Faltas Ayudan a descomponer el diseño para identificar situaciones que podrían generar una falla árbol lógico desde el efecto a las posibles causas and Modo llenado activo Sistema de enfriamiento desbordado or falla Válvula abierta trancada Pueden ocurrir ambos Timeout falla Falla Sensor Deben ocurrir ambos Evento básico

125 Curso 2007Ingeniería de SoftwareDiseño 125 Análisis del Arbol de Faltas G3 G1 G2 G4G5 A1A2A3A4 A5 G1 G2G3 {G4,G5}{A4,A5} {A1,G5}{A2,G5} {A1,A3}{A1,A4}{A2,A3}{A2,A4} Conjunto de Corte Arbol de Faltas

126 Curso 2007Ingeniería de SoftwareDiseño 126 6. Validación del diseño Evaluación y validación del diseño Técnicas para validar y verificar

127 Curso 2007Ingeniería de SoftwareDiseño 127 Evaluación y Validación del Diseño Validación: asegurar que el diseño satisface todos los requerimientos Verificación: asegurar que incorpora características de un buen diseño

128 Curso 2007Ingeniería de SoftwareDiseño 128 Técnicas para Validar y Verificar Validación Matemática Medir la Calidad del Diseño Comparar Diseños *Una Especificación, Varios Diseños *Tablas Comparativas Revisiones de Diseño *Preliminar *Crítica *De Programas

129 Curso 2007Ingeniería de SoftwareDiseño 129 Validación Matemática Prueba que el diseño es correcto Demostrando que: *Si el conjunto de entradas se formula correctamente, es transformada correctamente en las salidas esperadas *El proceso termina sin fallar.

130 Curso 2007Ingeniería de SoftwareDiseño 130 Medir la Calidad del Diseño Medir el diseño de alto nivel, incluyendo cohesión y acoplamiento Medir la complejidad de cada componente y de la relación entre componentes

131 Curso 2007Ingeniería de SoftwareDiseño 131 Comparar Diseños Una Especificación, Varios Diseños *Generar varios diseños para la misma especificación basados en diferentes estilos de arquitectura *Decidir cuál es el más adecuado para el propósito del sistema Tablas Comparativa (ejemplo): *Facilidad para cambiar algoritmos *Facilidad para cambiar la representación de los datos *Facilidad para cambiar las funciones *Desempeño (tiempo de respuesta) *Facilidad de reuso

132 Curso 2007Ingeniería de SoftwareDiseño 132 Revisiones de Diseño ¿Para qué? *Cuanto antes encontremos un problema, en menos lugares deberemos buscar la causa y corregirla. *Hacer todas las preguntas para asegurar que el diseño cubre todo lo necesario (listas de comprobación) Preparación *Definir Participantes *deben saber qué se espera de ellos y recibir la documentación con antelación (posiblemente con breve charla) Roles especiales: *Moderador: para que la reunión sea productiva *Secretario: para registrar los problemas y de las acciones a tomar Acciones posteriores (Verificar que se cumplan)

133 Curso 2007Ingeniería de SoftwareDiseño 133 Revisiones de Diseño RD Preliminar (Al definir la Arquitectura) *cliente, usuario *analistas, diseñador sistema, otros no involucrados *moderador, secretario RD Crítica (Técnica, previa al diseño detallado) *analistas, diseñador sistema, otros no involucrados *Diseñadores de programas *moderador, secretario RD de Programas (Técnica, previa a la codificación) *analistas, diseñador sistema, otros no involucrados *Diseñadores de programas *Programadores *moderador, secretario

134 Curso 2007Ingeniería de SoftwareDiseño 134 7. Documentando el Diseño Un producto importante del proceso de Diseño es un conjunto de documentos que describen el sistema a construir. Referencia Cruzada a los Requerimientos Es la solución del problema