Diseño e Implementación

Presentación del tema: "Diseño e Implementación"— Transcripción de la presentación:

1 Diseño e Implementación
Introducción

2 Introducción La Ingeniería del diseño abarca un conjunto de principios, conceptos y prácticas que conducen al desarrollo de un sistema o producto de calidad. Los principios del diseño establecen una filosofía primordial que guían al diseñador en el desempeño de su trabajo. Es necesario comprender estos principios y conceptos antes de que se apliquen las mecánicas de la práctica del diseño.

3 Principios del Diseño

4 Principios del diseño El modelado del diseño del SW comienza con la representación de la totalidad del objeto que será construido y con lentitud se refina hasta proporcionar una guía para construir cada detalle, proporcionando diferentes vistas del sistema. No hay pocos métodos para derivar los diferentes elementos de un diseño de SW. Métodos que se guían de los datos  arquitectura del SW y los componentes de procesamiento resultante. Patrón al utilizar la información acerca del dominio del problema  estilos arquitectónicos y patrones de procesamiento. Orientados a Objetos  creación de estructuras de datos y los métodos para manipularlos.

5 Principios del diseño Diseños rastreables hasta el modelo de análisis.
Antes de diseñar considerar la arquitectura Diseño de datos es tan importante como el de funciones. Diseñar con cuidado las interfaces int-externa. Considerar al usuario en el diseño de Interfaz Diseño al nivel de componente diferentes al funcional. Bajo acoplamiento, vinculado a ambiente externo Representación comprensible por todos Diseño iterativo, buscando la calidad y simplicidad

6 1.- El diseño debe ser rastreable hasta el modelo de análisis
El análisis describe: El dominio de la información del problema Las funciones visibles para el usuario El comportamiento del sistema Y un conjunto de clases de análisis El Diseño traduce esta información a una arquitectura Un conjunto de subsistemas que implementan las funciones más importantes y un conjunto de diseños al nivel de componentes que son la realización de las clases de análisis. Excepto el modelo asociado a la infraestructura de SW, todos los elementos del diseño deben ser mapeados al modelo de análisis

7 La arquitectura del SW es el esqueleto del sistema. Esta afecta:
2.- Siempre se debe considerar la arquitectura del sistema que se va a construir La arquitectura del SW es el esqueleto del sistema. Esta afecta: Las interfaces La estructura de datos El flujo y comportamiento de control del programa La manera en que se realizarán las pruebas Facilidad de mantenimiento del sistema resultante Por esas razones el diseño debe iniciarse con las consideraciones del diseño arquitectónico. Sólo después de haberse establecido la arquitectura, se pueden considerar aspectos a nivel de componentes.

8 3.- El diseño de datos es tan importante como el diseño de funciones de procesamiento
Un diseño de datos bien estructurado ayuda a simplificar el flujo del programa. Facilita el diseño e implementación de los componentes del SW y confiere más eficiencia al procesamiento en general Por lo tanto no se puede dejar a la suerte la manera en que se realizan los objetos de los datos dentro del sistema.

9 4.- Las interfaces (interna y externas) deben diseñarse con cuidado
La manera en la que fluyen los datos entre los componentes de un sistema tiene mucho que ver con: La eficiencia del procesamiento La propagación del error La simplicidad del diseño Una interfaz bien diseñada facilita la integración y ayuda a quien realiza la prueba de validar funciones de componentes.

10 Hay que resaltar la facilidad de uso.
5.- El diseño de la interfaz del usuario debe ajustarse a la necesidad del usuario final Hay que resaltar la facilidad de uso. La interfaz del usuario es la manifestación visible del SW, no importa: Que tan sofisticadas sean las funciones internas Que tan comprensibles sean las estructuras de datos Que tan bien diseñada esté su arquitectura Si el diseño de la interfaz es pobre conduce a la percepción de que el SW está “mal” hecho

11 La independencia funcional  componente de SW “Sencillo”.
6.- El diseño a nivel de componentes debe ser independiente del modo funcional La independencia funcional  componente de SW “Sencillo”. La funcionalidad que entrega un componente debe ser cohesiva, es decir, debe centrarse en una y sólo una función o subfunción.

12 El acoplamiento se consigue de las siguientes formas:
7.- Los componentes deben estar acoplados entre si en forma mínima y vinculados con el ambiente externo El acoplamiento se consigue de las siguientes formas: Vía interfaz de componentes Por mensajes A través de datos globales. A mayor acoplamiento: Mayor es la probabilidad de propagación del error Menor facilidad de mantenimiento general del SW

13 8.- La representaciones del diseño deben ser fácilmente comprensibles
El propósito del diseño es comunicar información a los profesionales que: Generarán códigos Probarán el SW Mantengan el SW en el futuro. Por lo tanto si el diseño es difícil de entender, no servirá como un medio efectivo de comunicación

14 9. - El diseño debe desarrollarse de manera iterativa
9.- El diseño debe desarrollarse de manera iterativa. En cada iteración el diseñador debe buscar mayor simplicidad. Cómo es casi todas las actividades creativas, el diseño ocurre de modo iterativo. Las primeras iteraciones sirven para refinar el diseño y corregir errores, pero las iteraciones posteriores deben buscar que el diseño sea tan simple como sea posible.

15 Factores de calidad Cuando se aplican estos principios de manera apropiada, el ingeniero de SW crea un diseño que muestra los factores internos y externos de calidad. Los factores externos son aquellos que los usuarios pueden observar fácilmente (como velocidad, confiabilidad, corrección, facilidad de uso). Los factores internos son importante para los Ing de SW, ya que conducen a un diseño de alta calidad desde una perspectiva técnica Lograr factores de calidad internos requiere que el diseñador entienda conceptos básicos de diseño.

16 Características de un buen SW
Un buen SW debe cumplir con lo siguiente: Firmeza: El programa no debe tener ningún error que inhiba su función. Comodidad: Un programa debe cumplir con los propósitos para los cuales fue creado. Placer: La experiencia de usar el programa debe ser agradable

17 Para lograr diseños de calidad, el diseñador debe practicar la diversificación y la convergencia.
Diversificación: es la adquisición de un repertorio de alternativas, la materia prima del diseño: componentes, soluciones de componentes y conocimiento todo contenido en catálogos, libros de texto y en la mente. Convergencia: una vez que se ha integrado todo la información de las alternativas el diseñador debe elegir y tomar elementos del repertorio que cumplan con los requisitos y el modelo de análisis. Con esto se consideran y rechazan las alternativas y se converge a una configuración en particular y por lo tanto a un producto final.

18 Un buen diseño es clave para la práctica efectiva de cualquier disciplina de la ingeniería
No es posible formalizar el proceso de diseño, debido al carácter de creativo que debe practicarse. Este proceso se aprende por medio de la experiencia y el estudio de sistemas existentes.

19 Proceso de diseño

20 Etapas para atacar cualquier proceso de diseño
Identificar y entender el problema desde distintos puntos de vista. Identificar las características fundamentales de algunas posibles soluciones y evaluarlas sobre la experiencia del diseñador, la disponibilidad de componentes reusables y la simplicidad del producto derivado. Describir y analizar en detalle cada abstracción usada en la solución elegida, con el propósito de encontrar y corregir errores, omisiones, etc.

21 Rol del diseño dentro del proceso de desarrollo de SW
El proceso de diseño se desarrolla iterativamente a través de varias versiones diferentes, en las que se van agregando correcciones, formalidad y detalle a las versiones anteriores. Como resultado se tienen varios modelos del sistema de distintos niveles de abstracción. Se considera el núcleo técnico. Una vez que se analizan y se especifican los requerimientos, el diseño del SW es la última acción de la ingeniería de SW dentro de la actividad de modelado, la cual establece una plataforma para la construcción

22 Modelo general para el proceso de diseño

23 Modelo general para el proceso de diseño
No hay límites rígidos entre las actividades, pero identificarlas le da visibilidad al proceso facilitando su gestión. El resultado de cada actividad es una especificación de algún tipo El resultado final es una especificación precisa de los algoritmos y estructuras de datos que deben implementarse. Las actividades aparecen como secuenciales, pero en la práctica pueden proceder en paralelo.

24 Las actividades del proceso de diseño son
Diseño Arquitectónico: Se identifican y documentan los subsistemas que componen el sistema y sus relaciones. Especificación Abstracta: se especifican los servicios que proveen cada uno de los subsistemas y las restricciones bajo las cuales operan. Diseño de Interfaces: Se diseñan y documentan las interfaces de cada subsistema (con c/u de los otros subsistemas). De manera de permitir que puedan ser usados sin conocimientos de cómo operan.

25 Las actividades del proceso de diseño son
Diseño de componentes: Se completan las especificaciones y los diseños no detallados de cada subsistema. Transforma los elementos estructurales de la arquitectura del SW en una descripción procedimental de los componentes de éste. Diseño de estructuras de datos: Se especifican y diseñan detalladamente las estructuras de datos del sistema. Diseño de algoritmos: Se especifican y diseñan los algoritmos del sistema.

26 Normalmente se hacen distinciones entre un diseño de alto nivel y un detallado.
El diseño de alto nivel considera el diseño arquitectónico, la especificación abstracta, el diseño de la interfaz y el diseño de componentes. El diseño detallado abarca el diseño de las estructuras de datos y el de los algoritmos.

27 Productos del proceso de diseño
Los productos se usan como la base sobre la cual se implementa el sistema. Sirven como medio de comunicación entre las personas involucradas en el desarrollo del sistema. Dan información al equipo de mantención del mismo.

28 Notaciones que se usan en los documentos de diseño de SW
Texto informal: permite expresar la racionalidad del diseño, consideraciones no funcionales, etc. Lenguajes (textuales) para la descripción de programas (PDL): combinan construcciones formales de estructuración y control, similares a las de los lenguajes de programación, con textos explicativos. Lenguajes gráficos: apropiados para mostrar relaciones entre componentes y para relacionar el diseño con el sistema que se está modelando

29 Importancia del Diseño

30 Importancia del Diseño
Calidad El diseño es la etapa en la que se fomentará la calidad en la ingeniería de SW El diseño es la única forma en que, de manera exacta, un requisito del cliente se puede convertir en un sistema o producto de SW. Sin diseño se corre el riesgo de: Construir un sistema inestable, el cual fallará cuando se realicen cambios pequeños. Sistema difícil de probar Su calidad no podrá evaluarse sino hasta etapas tardías del proceso de SW, cuando queda poco tiempo y ya se ha gastado mucho dinero en él. (Análisis de factibilidad).

31 Proceso y Calidad del Diseño
El diseño se representa en un grado alto de abstracción, el cual puede rastrearse de manera directa hasta conseguir: El objetivo específico del sistema Requisitos más detallados de comportamiento funcionales y de datos A medida que ocurren las iteraciones del diseño, un refinamiento conduce a representaciones del diseño a grados mucho más bajos de abstracción. Estos grados aún se pueden rastrear hasta los requisitos, pero la conexión es más sutil.

32 Proceso y Calidad del Diseño
Técnicas formales para evaluar la calidad del proceso de diseño. McGlaughlin sugiere 3 características que sirven como guía de evaluación: El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis, y debe ajustarse a todos los requisitos implícitos que desea el cliente. El diseño debe ser una guía legible y comprensible para quienes generan código y quienes realizan las pruebas y, en consecuencia, dan soporte al SW. El diseño debe proporcionar una imagen completa del SW, dando dirección a los dominios de datos, funcionales y de comportamiento desde una perspectiva de implementación

33 Directrices de calidad del diseño

34 Directrices de Calidad del diseño
Con el fin de evaluar la calidad de una representación de diseño se deben establecer los criterios técnicos para un buen diseño. Para esto se presentan las siguientes directrices: Un diseño debe presentar una estructura arquitectónica que: Se haya creado mediante patrones de diseño reconocibles La integren componentes que exhiban buenas características de diseño ( se explicarán más adelante). Pueda implementarse de manera evolutiva para que de esta forma facilite la implementación y las pruebas. Un diseño debe ser modular, esto es el SW deberá dividirse de manera lógica en elementos o subsistemas. Un diseño debe contener distintas representaciones de los datos, la arquitectura, las interfaces y los componentes.

35 Directrices de Calidad del diseño
Un diseño debe conducir a: Estructuras de datos que sean apropiadas para las clases que habrán de implementarse y que procedan de patrones de datos reconocibles. Componentes que presenten características funcionales independientes. Interfaces que reduzcan las complejidad de las conexiones entre los componentes y el ambiente externo. Un diseño debe obtenerse por medio de un método repetible que se base en la información obtenida durante el análisis de requisitos del SW. Un diseño debe representarse por medio de una notación que comunique de manera eficaz su significado.

36 Atributos de calidad del diseño

37 Atributos de Calidad del diseño
HP desarrollo un conjunto de atributos de calidad, los cuales representan un objetivo para todo el diseño de SW. Estos son: La funcionalidad se estima al evaluar el conjunto de características y capacidades del programa, la generalidad de las funciones que se entregan y la seguridad del sistema en su totalidad. La facilidad de uso se valora al considerar los factores humanos, la estética, la consistencia y documentación en general. La confiabilidad se evalúa al medir la frecuencia y severidad de las fallas, la precisión de los resultados de salida, la medida del momento de fallas, la habilidad para recuperarse de las fallas y la previsibilidad del programa.

38 Atributos de Calidad del diseño
El desempeño se mide con la velocidad de procesamiento, tiempo de respuesta, consumo de recursos, rendimiento y eficacia. La soportabilidad combina la habilidad de extender el programa (extendibilidad), la adaptabilidad y la serviciabilidad, estos atributos representan un concepto más común: Facilidad de mantenimiento Resistencia a pruebas Compatibilidad Configurabilidad (habilidad para organizar y controlar elementos de la configuración de SW) Facilidad con que se instala el sistema Facilidad con la que se puede localizar el problema No todos los atributos tienen el mismo peso cuando se desarrolla el diseño del SW.

39 Conceptos del diseño M.A.Jackson señaló una vez: “El comienzo de la sabiduría para un Ing. De SW es reconocer la diferencia entre hacer que un programa funcione y conseguir que lo haga del modo correcto”. Los conceptos fundamentales del diseño ofrecen el marco de trabajo necesario para hacer las cosas “del modo correcto”. Abstracción Arquitectura Patrones Modularidad Ocultación de la Información Independencia Funcional Refinamiento Refabricación Clases de Diseño

40 Conceptos de diseño

41 Solución se establece en términos generales, entorno del problema
1.- Abstracción Cuando se considera una solución modular a cualquier problema se pueden exponer muchos grados de abstracción. El nivel más bajo de abstracción permitirá que la solución pueda implementarse directamente. Solución se establece en términos generales, entorno del problema Alto Nivel de Abstracción Se proporciona una descripción más detallada de la solución, al nivel de implementación Bajo

42 1.- Abstracción En la medida en que cambien los diferentes grados de abstracción se trabaja para crear abstracciones procedimentales y de datos. Una abstracción procedimental, se refiere a una secuencia de instrucciones que tiene una función específica y limitada. Un ejemplo de abstracción procedimental sería la palabra abrir para una puerta. Una abstracción de datos es una colección nombrada de datos que describe un objeto de datos. En el contexto de abstracción procedimental, abrir se puede definir como una abstracción de datos llamada puerta.

43 2.- Arquitectura La arquitectura de SW alude a La estructura general del SW y las formas en que la estructura proporciona una integridad conceptual para un sistema. Desde un punto de vista más simple, la arquitectura es la estructura u organización de los componentes del programa (módulos), la manera es que éstos componentes interactúan y la estructura de datos que utilizan los componentes. Una de las metas del diseño de SW es derivar una representación arquitectónica de un sistema. Esta representación sirve como el marco de trabajo a partir del cual se conducen actividades de diseño más detalladas.

44 2.- Arquitectura Un conjunto de patrones arquitectónicos permite que se reutilicen conceptos a nivel de diseño. Existen diferentes tipos de modelos que se pueden usar para representar a una arquitectura. Modelos estructurales: Representan la arquitectura como una colección organizada de componentes del programa. Modelos del marco de trabajo: incrementan el grado de abstracción del diseño al intentar identificar marcos de trabajo repetibles del diseño arquitectónico que se encuentran en tipos de aplicaciones similares. Modelos dinámicos: abordan los aspectos conductuales de la arquitectura del programa, al indicar cómo puede cambiar la configuración de la estructura o el sistema, como función de los eventos externos.

45 2.- Arquitectura Los modelos del proceso: se centran en el diseño del proceso técnico o de negocios que el sistema debe contener. Los modelos funcionales: pueden utilizarse para representar la jerarquía funcional de un sistema.

46 3.- Patrones Un patrón “es una semilla de conocimiento, la cual tiene un nombre y transporta la esencia de una solución probada a un problema recurrente dentro de cierto contexto en medio de intereses en competencia”.[Brad Appleton 98]. Un patrón de diseño describe una estructura de diseño que resuelve un problema de diseño particular dentro de un contexto específico y en medio de “fuerzas” que pueden tener un impacto en la manera en que se aplica y utiliza el patrón. Cada patrón describe un problema que ocurre una u otra vez en nuestro entorno y después describe la esencia de la solución a dicho problema, de tal forma que puedas usar esta solución un millón de veces más, sin nunca hacerlo las veces de la misma forma. [Christopher Alexander]

47 3.- Patrones La finalidad de cada patrón de diseño es proporcionar una descripción que le permita al diseñador determinar: Si el patrón es aplicable al trabajo actual Si el patrón se puede reutilizar Si el patrón puede servir como guía para desarrollar un patrón similar, pero diferente en cuanto a la funcionalidad o estructura.

48 4.- Modularidad El SW se divide en componentes con nombres independientes y que es posible abordar en forma individual. Estos componentes, llamados módulos, se integran para satisfacer los requisitos del problema. Módulo: cada una de las unidades claramente definidas y manejables constituyentes del SW. La modularidad es el atributo particular del SW que permite que un programa sea manejable de manera intelectual Esta consiste en el particionamiento del SW en elementos con nombres y direcciones separadas que se denominan módulos, los cuales en su composición generan una totalidad que debe ser capaz de resolver el problema que da origen a la necesidad de construir un producto de SW.

49 4.- Modularidad Tiene que ver con la división de las funciones que en conjunto cumplen un objetivo mayor, esto es, responden a la idea de totalidades emergentes propia de la noción de sistemas. Sus beneficios son: Programas más simples, ya que puede ser comprendido, verificado, programado, depurado, mejorado y alterado por partes. Módulos que pueden ser desarrollados con relativa independencia Disminución de la posibilidad de errores al reducir la complejidad Programas que pueden evaluarse por partes, por lo cual todo test se hace más fácil. Programas más fáciles de alterar ya que son menores las líneas de código a considerar para incorporar los cambios.

50 4.- Modularidad Sus beneficios son:
Módulos de función única que pueden ser reutilizados. El programa puede ser comprendido por partes. Disminuye errores de programación. Son menos las líneas de código que deben enfrentar al mismo tiempo los programadores. Los efectos colaterales de los cambios que afectan al sistema son drásticamente reducidos. Rotación de personal menos crítica, ya que los programadores están involucrados en unidades de código más pequeñas por lo cual la sustitución resulta menos dificultosa. Responde al requerimiento de la división del código en segmentos de una página, como lo sugiere la programación estructurada.

51 4.- Modularidad Un módulo que controla a otro se dice que es “superordinado” a éste y, reciprocamente, un módulo controlado por otro se dice que es “subordinado”. El FAN OUT es una medida del número de módulos controlados directamente por otro módulo (número de subordinados inmediatos que posee). El FAN IN indica cuántos módulos controlan directamente un determinado módulo (Número de superiores inmediatos que posee)

52 4.- Modularidad Módulo Superordinado Módulo Subordinado
FAN OUT: FAN IN : 1

53 ¿ Dividir hasta el infinito para que el Esfuerzo sea Cero ?
4.- Modularidad ¿ Dividir hasta el infinito para que el Esfuerzo sea Cero ? Costos o Esfuerzo Costo Total SW Costo por Integración Costos Mínimos Costo por Módulo N° Módulos

54 5.- Ocultación de la Información
El principio de ocultación de información sugiere que los módulos “se caracterizan por las decisiones de diseño que cada uno oculta a los otros. En otras palabras, los módulos deben especificarse y diseñarse de manera que la información (procedimiento y datos) que está dentro del módulo sea inaccesible para otros módulos que no necesiten esa información. La ocultación implica que se puede conseguir una modularidad efectiva al definir un conjunto de módulos independientes que se comuniquen entre si y que intercambien sólo la información necesaria para lograr la función del SW.

55 5.- Ocultación de la Información
La abstracción ayuda a definir las entidades del procedimiento (o información) que conforman el SW. La ocultación define y fortalece las restricciones de acceso para los detalles de procedimiento dentro de un módulo y para cualquier estructura de datos local que utilice el módulo. Beneficios: Cuando se requieren modificaciones durante la realización de las pruebas y, después, en el curso de mantenimiento del SW. Cómo la mayoría de los datos y procedimientos está oculta de las otras partes del SW, existe una probabilidad menor de introducir errores inadvertidos al realizar las modificaciones y propagarlos a otros lugares dentro del SW.

56 6.- Independencia Funcional
El concepto de independencia funcional es la suma directa de la modularidad y de los conceptos de abstracción y ocultación de información. La independencia funcional se consigue al desarrollar módulos con una función “determinante” y una “aversión” a la interacción excesiva con otros módulos. Es decir, se desea diseñar el SW de tal manera que cada módulo aborde una subfunción específica de los requisitos y tenga una sola interfaz cuando se observe desde otras partes de la estructura del programa. El SW con una modularidad efectiva, es decir, con módulos independientes, es más fácil de desarrollar porque la función se puede fraccionar y las interfaces se simplifican.

57 6.- Independencia Funcional
Beneficios: Los módulos independientes son más fáciles de mantener y probar, porque se limitan los efectos secundarios que originan las modificaciones al diseño o al código, se reduce la propagación de errores, y es posible emplear módulos reutilizables. La independencia funcional es una clave para el buen diseño, y el diseño es clave para lograr la calidad del SW.

58 6.- Independencia Funcional
Cómo evaluar la independencia?? Aplicando 2 criterios cualitativos: Cohesión y acoplamiento. La cohesión: es una medida de la fuerza funcional relativa de un módulo. El acoplamiento: es una medida de la interdependencia relativa entre los módulos. Cohesión  ocultación de información. Un módulo cohesivo realiza una sola tarea , para lo cual requiere muy poca interacción con otros componentes en otras partes del programa. Un módulo cohesivo debe (idealmente) hacer una sola cosa.

59 6.- Independencia Funcional
El acoplamiento es una medida de la interconexión entre los módulos de una estructura de SW. El acoplamiento depende de la complejidad de la interfaz entre los módulos, el punto donde se realiza una entrada o referencia a un módulo, y los datos que pasan a través de la interfaz. Una conectividad sencilla entre los módulos da como resultado un SW más fácil de entender y menos propenso a experimentar el efecto “ola”, el cual se presenta cuando surgen problemas en un lugar y después se propagan a través del sistema

60 7.- Refinamiento Proceso iterativo mediante el cual la arquitectuta del SW es el reflejo de la especificación de requerimientos del sistema, el cual se realiza sistemáticamente con el propósito de lograr una estructura modular, es decir, una representación que explicite las relaciones entre los principales elementos del SW. Se configura una representación que muestra una visión global tanto de las estructuras de datos como de las estructuras de los componentes. Tras un proceso de refinamiento sucesivo se transforma en una representación del diseño muy cercana al código fuente En cuanto a los detalles de los procedimientos que han de regir las transformaciones que deben llevarse a cabo en cada módulo y en estructuras de datos detalladas.

61 7.- Refinamiento En cada etapa del refinamiento, se descomponen una o varias de las instrucciones del programa dado en instrucciones cada vez más detalladas. Esta descomposición o refinamiento sucesivo termina cuando todas las instrucciones están expresadas en términos de cualquier lenguaje básico de computación o de programación”. El refinamiento es un proceso de elaboración, que se inicia con el enunciado de una función (o una descripción de datos) que se define con un alto grado de abstracción. El enunciado describe los datos o la función de manera conceptual, pero no proporciona información acerca de los trabajos internos de la función o de la estructura interna de los datos. El refinamiento hace que el diseñador trabaje sobre el enunciado original y que proporcione más y más detalles conforme se realiza cada refinamiento sucesivo.

62 7.- Refinamiento La abstracción y el refinamiento son conceptos complementarios. La abstracción permite al diseñador especificar procedimientos y datos sin considerar detalles de grado menor. El refinamiento ayuda al diseñador a revelar los detalles de grado menor mientras se realiza el diseño. Ambos conceptos auxilian al diseñador en la creación de un modelo de diseño completo a medida que evoluciona la actividad de diseño.

63 7.- Refinamiento En la ISW, la modularización se apoya en lo que se conoce como refinamiento sucesivo gradual para la configuración de la estructura del SW Refinamiento Gradual Abstracción Módulo A Modularidad Factorización A1 A2

64 8.- Refabricación Es la técnica de reorganización que simplifica el diseño (o código) de un componente sin cambiar su función o comportamiento. La refabricación es el proceso de cambiar un sistema de SW de tal forma que no se altere el comportamiento externo de su código y diseño y aún así se mejore su estructura interna. Cuando un SW se refabrica el diseño existente se examina en busca de redundancias, elementos de diseño inútiles, algoritmos innecesarios o insuficientes, estructuras de datos inapropiadas o construidas de manera incorrecta, o cualquier otra falla de diseño que se pueda corregir para lograr un mejor diseño.

65 9.- Clases de Diseño En la etapa de análisis se definen un conjunto completo de clases de análisis. Cada una de estas clases describe algún elemento del dominio del problema. El grado de abstracción de una clase de análisis es relativamente alto. Conforme evoluciona el modelado del diseño, el equipo de SW debe definir un conjunto de clases de diseño que: Refine las clases de análisis al proporcionar detalles del diseño que permitirán la implementación de las clases. Produzca un conjunto nuevo de clases de diseño que implementen una infraestructura de SW para soportar la solución del negocio.

66 9.- Clases de Diseño Se sugieren 5 diferentes tipos de clases de diseño, cada una representa una capa distinta de la arquitectura de diseño. Las clases de interfaz con el usuario definen todas las abstracciones necesarias para la interacción humano-computadora (IHC). En muchos casos, la IHC ocurre dentro del contexto de una metáfora y las clases de diseño para la interfaz pueden ser representaciones visuales de los elementos de la métafora. Las clases del dominio de negocios a menudo son refinamientos de las clases de análisis definidas antes. Las clases identifican los atributos y servicios (métodos) necesarios para implementar algún elemento del dominio de negocios.

67 9.- Clases de Diseño Las clases del proceso implementan abstracciones del negocio en un nivel más bajo, las cuales se requieren para manejar por completo las clases del dominio de negocios. Las clases persistentes representan almacenamientos de datos (por ej. Una BD) que persistirán más allá de la ejecución del SW. Las clases de sistema implementan las funciones de gestión y control del SW que permiten que el sistema opere y se comunique dentro de su entorno de computación y con el mundo exterior.

68 9.- Clases de Diseño A medida que evoluciona el modelo de diseño, el equipo debe desarrollar un conjunto completo de atributos y operaciones para cada clase de diseño. El grado de abstracción se reduce conforme cada clase de análisis se transforma en una representación del diseño. Las clases de diseño presentan un mayor detalle técnico, pues son una guía para la implementación.

69 9.- Clases de Diseño 4 caracterísitcas de una clase de diseño bien formada: Completa y suficiente: Una clase de diseño debe ser la encapsulación completa de todos los atributos y métodos que se pueden esperar. Primitivismo: Los métodos asociados con una clase de diseño deben enfocarse en el cumplimiento de un servicio para la clase. Una vez que el servicio ha sido implementado con un método, la clase no debe proporcionar otra forma de complementar la misma cosa. Ej VideoClip (inicio-fin). Cohesión alta: Una clase de diseño cohesiva tiene un conjunto de responsabilidades pequeño y enfocado, aplica atributos y métodos de manera sencilla para implementar dichas responsabilidades. Ej: Edición VideoClip

70 9.- Clases de Diseño Bajo Acoplamiento: Dentro del modelo de diseño es necesario que las clases de diseño colaboren con alguna otra. Sin embargo, la colaboración se debe mantener en un mínimo aceptable. Si el sistema tiene un alto grado de acoplamiento, es decir, todas las clases de diseño colaboran con todas las otras clases, el sistema es difícil de implementar, probar y difícil de mantener a través del tiempo. En general las clases de diseño de un sistema deben de tener sólo un conocimiento limitado de las clases en otros subsistemas. La ley de DEMÉTER sugiere que un método sólo debe enviar mensajes a métodos de clases vecinas.

71 Fin conceptos de diseño

72 Acoplamiento y cohesión

73 Factores de calidad Acoplamiento: Corresponde al grado de independencia entre los módulos. Minimizar el acoplamiento aparece entonces como un objetivo al configurar la estructura. La obtención de módulos tan independientes como sea posible se puede lograr de 3 maneras: Eliminando relaciones innecesarias Reduciendo el número de relaciones necesarias Debilitando la dependencia de las relaciones necesarias.

74 Cohesión: Corresponde a la medida de relación funcional de los elementos en un módulo.
Los elementos de un módulo corresponden a instrucciones, definiciones de datos, o llamadas a otros módulos. La idea es organizar estos elementos de tal manera que tengan una mayor relación entre ellos al momento de cumplir su tarea.

75 Tipos de Acoplamiento Acoplamiento normal Acoplamiento de Datos.
Acoplamiento de Marca (stramp) Acoplamiento de Control Acoplamiento Común Acoplamiento Externo Acoplamiento de contenido

76 Tipos de Acoplamiento Mejor Acoplamiento NORMAL DATOS DE MARCA (STAMP)
CONTROL EXTERNO (caso especial de COMÚN) COMÚN CONTENIDO (grado más alto : peor) Grado de Acoplamiento

77 1.- Acoplamiento Normal Dos módulos A y B están Normalmente Acoplados si: Un módulo A llama a Otro B B retorna el contol a A No se produce traspaso de parámetros entre ellos, solo existe la llamada de uno a otro. A B

78 2.- Acoplamiento de datos
Dos módulos están acoplados por datos si ellos se comunican por parámetros. Siendo cada parámetro una unidad elemental de datos. El acoplamiento de datos corresponde a la comunicación de datos necesaria entre módulos. Toda vez que los módulos tienen que comunicarse entre sí, la ligazón por datos es inevitable y serán adecuados si se mantienen a niveles mínimos Obtener Datos Cliente Rut_cliente Leer Rut

79 3.- Acoplamiento de Marca (stramp)
Calcular Deuda Cliente Dos módulos aparecen “acoplados de marca” si ellos se refieren a la misma estructura de datos local. Por estructura de datos se debe entender un grupo compuesto de datos en vez de argumentos simples. Por ejemplo un registro. Cliente Leer Cliente Cliente= rut+nombres+apellido_paterno+ apellido_materno+dirección+fono+e_mail

80 4.- Acoplamiento de Control
Dos módulos están acoplados por control cuando uno de ellos pasa al otro módulo indicadores de control (flag, switch). Provoca dependencia de ejecución entre un módulo y otro. No es recomendable. Tratar de utilizarlo moderadamente. Obtener Datos Cliente Tipo_dato Cliente Leer Cliente

81 5.- Acoplamiento Común Dos módulos presentan acoplamiento común, si ellos se refieren a la misma área global de datos (Archivo o área de memoria). Programas con muchos datos globales son difíciles de entender por los programadores de mantención, porque no es fácil saber cuales son los datos usados por un cierto módulo. Actualizar Stock Video Obtener Nombre Video video Leer Registro Video

82 6.- Acoplamiento Externo
Cuando los módulos están atados a un entorno externo al SW se dan niveles relativamente altos de acoplamiento. Por ejemplo, la E/S acopla un módulo a dispositivos, formatos y protocolos de comunicación. El acoplamiento externo debe limitarse a unos pocos módulos en la estructura. Actualizar DW Obtener Nómina Registro_act Nómina DW

83 7.- Acoplamiento de Contenido
Este es un tipo de acoplamiento indeseable. Dos módulos presentan acoplamiento de contenido (o patológico) si uno hace referencia al interior del otro. Esto ocurre si por ejemplo en un módulo se desvía la secuencia de instrucciones al interior de otro o si un módulo altera un comando de otro Tal acoplamiento rompe el concepto de módulos configurados bajo el criterio de la caja negra. Forzando a un módulo conocer explicitamente los contenidos y la implementación de otro A B ……….. Srch: Move.. ………. ……… ……….. ……… Jump to Srch ……….

84 Tipos de acoplamiento Los módulos pueden estar relacionados por más de un tipo de acoplamiento. Si esto ocurre, el acoplamiento que caracteriza la relación entre ellos queda definido por el peor tipo que presenten. Por ejemplo, si dos módulos están ligados por acoplamiento de marca y acoplamiento común a la vez, se dirá que los módulos están ligados por acoplamiento común.

85 ¿Cómo analizar el tipo de Acoplamiento?
Imaginar el módulo como una biblioteca Cómo el módulo podría ser más fácilmente entendido. Cómo el módulo podría ser más utilizado por otros sistemas o invocado por otros módulos del mismo sistema. Cada módulo es codificado por un programador diferente ¿Qué tan independientes pueden trabajar los programadores? ¿Existe algún supuesto, convención o decisiones de implementación a los cuales más de un módulo deba prestar atención? Cuales son las posibilidades de cambio que existen en relación a los supuestos, convenciones o a la implementación? ¿Existe alguna manera de aislar aquellos cambios y situarlos en un solo módulo?

86 Ideas centrales Sistemas altamente acoplados conducen a depurar verdaderas pesadillas. Evítelo. Sistemas altamente acoplados, tienden a tratarse como una sola gran unidad, y un sistema monolítico es la contrapartida a particionar. Hablar de módulos, cajas negras, es hablar de particionamiento Particionar es la estrategia para abordar la complejidad. Las cajas negras se organizan jerárquicamente.

87 Tipos de Cohesión STEVEN, MYERS, CONSTANTINE y YOURDON (1974)
Mayor Cohesión Módulo como Caja Negra FUNCIONAL SECUENCIAL COMUNICACIONAL PROCEDURAL Módulo Transparente TEMPORAL LÓGICA COINCIDENTAL Grado de Cohesión STEVEN, MYERS, CONSTANTINE y YOURDON (1974) establecieron "una escala de cohesión"

88 1.- Cohesión Funcional Un módulo con cohesión funcional es aquel que contiene elementos que contribuyen a la ejecución de una y sólo una tarea relacionada al problema. Ejemplos Calcular el coseno de un ángulo Calcular el I.V.A. de una factura Verificar el dígito de un rut

89 2.- Cohesión Secuencial Ejemplo: Calcular el salario.
Un módulo secuencialmente cohesionado es aquel cuyos elementos están envueltos en actividades tales que los datos de salida de una actividad en general sirven como datos de entrada para la próxima actividad. Ejemplo: Calcular el salario. Obtener el suelo base Verificar número de cargas Revisar días con permiso Revisar días con licencia Calcular horas de trabajo Descontar horas de atraso Agregar horas extras. ….

90 3.- Cohesión Comunicacional
Un módulo presenta cohesión comunicacional cuando sus elementos contribuyen a actividades que usan la misma entrada o la misma salida. No importa el orden secuencial. Ejemplo obtener datos producto Obtener nombre Obtener Stock Obtener ubicación Obtener precio …..

91 4.- Cohesión Procedimental
Cuando sus elementos de procesamiento están relacionados y deben ejecutarse en un orden específico.

92 5.- Cohesión Temporal Un módulo con cohesión temporal es aquel cuyos elementos están envueltos en actividades que están relacionadas en función del momento en que se realizan Actividades al iniciar el día Apagar despertador Tomar ducha Vestirse Hacer la cama Tomar desayuno …….

93 6.- Cohesión lógica Un módulo tiene cohesión lógica, cuando existe alguna relación entre los elementos del módulo, contribuyendo al desarrollo de actividades de una misma categoría general, donde la actividad o las actividades a ser ejecutadas se seleccionan desde fuera del módulo. Ejemplo Registrar Pago Registrar pago con tarjeta de crédito Registrar pago con cheques. Registrar pago con efectivo. ……

94 7.- Cohesión Coincidental
Ejemplo: Comprar un libro Comer un trozo de torta Ir al teatro Lavar la ropa Dormir …. Un módulo coincidentalmente cohesioando es aquel cuyos elementos desarrollan actividades sin relación significativa entre si.

95 Cómo medir la calidad del diseño

96 Evaluación de la calidad del diseño: RTF
Durante el diseño la calidad se evalúa al realizar una serie de revisiones técnicas formales (RTF). Una RTF es una reunión que dirigen miembros del equipo de SW Por lo general participan de 2 a 4 personas, dependiendo del ámbito de información del diseño que se revisará. Cada persona desempeña un rol: El líder de revisión planea la reunión, establece la agenda y después realiza la reunión El relator toma notas para que nada se olvide El productor es la persona a la cual se le revisa el producto

97 Evaluación de la calidad del diseño: RTF
Antes de cada reunión, cada persona del equipo recibe una copia del producto de trabajo de diseño y se solicita que sea leído en busca de errores, omisiones y ambigüedades El objetivo de la reunión es el de detectar todos los problemas del producto de diseño, para que estos puedan corregirse antes de la implementación, con una duración de 90 a 120 min. Al termino de la RTF, el equipo de revisión determina si se requieren acciones posteriores por parte del productor antes que el producto pase a ser parte del producto de diseño final

98 Fin Conceptos de Diseño