Diseño e Implementación

1. Diseño e Implementación Diseño al nivel de componentes

2. Introducción • ¿Qué és?: Un conjunto completo de componentes del SW se define durante el diseño arquitectónico, pero las estructuras de datos internas y el procesamiento de detalles de cada componente no se representan en un grado de abstracción parecido al código. • El diseño a nivel de componentes define las estructuras de datos, los algoritmos, las características de la interfaz y los mecanismos de comunicación asignados a cada componente del SW.

3. Introducción • ¿Quién lo hace?: Un ingeniero de SW realiza el diseño a nivel de componentes. • ¿Por qué es importante?: Antes de construir el SW se debe tener la capacidad de determinar si funcionará bien. • El diseño a nivel de componentes representa el SW de tal manera que permite revisar si los detalles del diseño son correctos y consistentes con las representaciones iniciales del diseño (es decir, los diseños de datos, arquitectura e interfaz). • Proporciona una manera de evaluar si funcionarán las estructuras, las interfaces y los algoritmos.

4. Introducción • ¿Cuáles son los pasos?: Las representaciones al nivel de diseños de datos, arquitectura e interfaz representan la base del diseño al nivel de componentes. • La definición de clase o la narrativa de procesamiento de cada componente se traduce en un diseño detallado que usa diagramas o formas de texto que especifican estructuras de datos internas, detalle de la interfaz local y lógica de procesamiento. • La notación de diseño abarca diagramas UML y representaciones complementarias. • El diseño procedimental se especifica mediante un conjunto de construcciones de programación estructurada.

5. Introducción • ¿Cuál es el producto obtenido?: El diseño de cada componente, representado en una notación gráfica, tabular o textual, es el principal producto de trabajo creado durante el diseño a nivel de componente. • ¿Cómo puedo estar seguro de que lo he hecho correctamente?: Se realiza un recorrido o una inspección al diseño. Éste se examina para determinar si las estructuras de datos, las interfaces, las secuencias y las condiciones lógicas son correctas y para ver si arrojan los datos apropiados o la transformación de control asignada al componente durante las primeras etapas del diseño.

6. 1 ¿Qué es un componente? • De manera general, un componente es un bloque de construcción modular para el SW de cómputo. • De manera formal, un componente es “una parte modular, desplegable y reemplazable de un sistema que encapsula implementación y expone un conjunto de interfaces”. • Los componentes pueblan la estructura del SW, y por tanto, ayudan a cumplir con los objetivos y requisitos del sistema en construcción. • Debido a que los componentes residen en el interior de la arquitectura del SW, deben comunicarse con otros componentes y con entidades (como sistemas, dispositivos, personas) que existen fuera de los límites del SW.

7. 1 ¿Qué es un componente? 1.1 Concepto Orientado a Objetos • Un componente contiene un conjunto de clases que colaboran entre si. • Cada clase de un componente se ha elaborado completamente para incluir todos los atributos y las operaciones relevantes para su implementación. • Cómo parte de la elaboración del diseño también deben definirse todas las interfaces (mensajes) que permiten que las clases se comuniquen y colaboren con otras clases de diseño.

8. 1 ¿Qué es un componente? 1.1 Concepto Orientado a Objetos • Para lograrlo el diseñador empieza con el modelo de análisis y elabora: • Clases de análisis (en el caso de componentes que se relacionan con el dominio del problema) • Clases de infraestructura (en el caso de componentes que proporcionan servicios de soporte para el dominio del problema). • Ej: Desarrollo de SW para una imprenta sofisticada, cuyo objetivo general es recopilar las necesidades del cliente en el mostrador, cotizar un trabajo de impresión y pasarlo a una planta de producción automatizada.

9. 1 ¿Qué es un componente? Clase de análisis Trabajo Imprenta Nº de páginas Nº de lados Tipo Papel Ampliación Características producción Calcular costo trabajo() Imprimir y pasar trabajo() Componente de diseño Calcular trabajo Trabajo Imprenta Iniciar trabajo

10. Clase de diseño elaborado Trabajo Imprenta Nº de páginas Nº de lados Tipo Papel Peso papel tamaño papel color papel Ampliación Requisitos Color Características producción Opciones distribución Opciones encuadernado portadas Almacén refine prioridad Calcular costo página() Calcular costo trabajo() Imprimir y pasar trabajo() Calcular costo trabajo total() Revisar prioridad() Pasar trabajo a producción() <<Interfaz>> calcular trabajo CalcularCostoPagina() CalcularCostoPapel() CalcularCostoProd() CalcularCostoTrabajoTotal() <<Interfaz>> Iniciar trabajo ConstruirOrdenTrabajo() VerificarPrioridad() PasarTrabajoaProducción()

11. 1 ¿Qué es un componente? • 1.1 Concepto Orientado a Objetos • Deben especificarse las estructuras de datos apropiadas para cada atributo. • Se diseña el detalle algorítmico que se requiere para implementar la lógica de procesamiento asociada con cada operación. • Se diseñan los mecanismos necesarios para implementar la interfaz (en OO esto abarca la descripción de todos los mensajes que se requieren para realizar la comunicación entre objetos dentro del sistema)

12. 1 ¿Qué es un componente? • 1.2 El concepto convencional • Un componente es un elemento funcional de un programa que incorpora: • La lógica del procesamiento • Las estructuras internas de los datos necesarios para implementar dicha lógica • Una interfaz que permita la invocación del componente y el paso de los datos. • El componente convencional, también denominado módulo, reside dentro de la arquitectura del SW y representa uno de tres papeles importantes • Como componente de control, que coordina la invocación de todos los demás componentes del dominio del problema. • Como componente del dominio del problema que implementa una función completa o parcial requerida por el cliente. • Como componente de infraestructura responsable de funciones que soportan el procesamiento requerido.

13. 1 ¿Qué es un componente? • 1.2 El concepto convencional • Al igual que en OO, los componentes del SW convencional se derivan del modelo de análisis. • Pero en este caso el elemento de datos orientado al flujo sirve como base para la derivación. • Cada Transformación representada en los niveles inferiores del DFD se correlaciona directamente con una jerarquía de módulos. • Los componentes de control (módulos) residen cerca de la parte superior de la jerarquía (arquitectura) y los componentes de dominio de problema tienden a residir hacia la parte inferior de la jerarquía.

14. 1 ¿Qué es un componente? • 1.2 El concepto convencional Sistema de Administración De Trabajo Seleccionar la Función de Manejo de trabajo Leer datos de Trabajo de Impresión Desarrollar Costo de trabajo Construir Orden de trabajo Enviar trabajo A producción Calcular costo De página Calcular costo De papel Calcular costo De producción Revisar prioridad Pasar trabajo A producción

15. 1 ¿Qué es un componente? • 1.2 El concepto convencional • Durante el diseño a nivel de componente, se elabora cada módulo mostrado en la figura anterior. • La interfaz de diseño se define de forma explicita, es decir, se representa cada objeto de datos o de control que fluye por la interfaz. • El algoritmo que permite que el módulo realice su función está diseñado con el enfoque de refinamiento. El comportamiento del módulo suele representarse con un diagrama de estado.

16. 1 ¿Qué es un componente? • 1.2 El concepto convencional • Ej: Considérese el módulo CalcularCostoPagina • Su Objetivo es calcular el costo de impresión por página a partir de las especificaciones del cliente. Los datos necesarios para la realización de la función son: • Nº de páginas en el documento • Nº total de documentos que se producirán • Impresión por una o ambas caras • Color o blanco y negro • Tamaño. • Estos datos se pasan a CalcularCostoPagina mediante la interfaz del módulo. • Este usa los datos y determina un costo por página que se basa en el tamaño y la complejidad del trabajo (Una función de todos los datos pasados al módulo con la interfaz). • El costo por página es inversamente proporcional al tamaño del trabajo y directamente proporcional a su complejidad.

17. Componente del diseño ObtenerdatosTrabajos Calcular costo De página Costo Página Entra: número de página Entra: Nº de documentos Entra: lados = 1, 2 Entra: color = 1, 2, 3, 4 Entra: Tamaño Página = A, B, C, D Entra: Costo de Página Entra: color = 1, 2, 3, 4 Sale: CBP Sale: CF ObtenerDatosTrabajo(Nº de páginas, Nº de documentos, lados, color, Tamaño página, costo página) Accesar BD costos(Tamaño trabajo, Color, tamañoPagina, CBP, SF) Calcular Costo página() AccesarBDcostos Tamaño de trabajo (TT) = NºPaginas = NºDocumentos; Buscar costo Base de páginas(CBP) -> AccesarBDCostos(TT,color); Buscar Factor de Tamaño (FT) -> AccesarBDCostos(TT, color, tamaño) Factor de Complejidad de Trabajo (FCT)= 1 + [(lados -1)* costoLado + FT] costoPagina = CBP * FCT

18. 2. Diseño de componentes basado en Clases • El nivel de componentes se basa en información desarrollada como parte del modelo de análisis y representada como parte del modelo arquitectónico. • Al elegir el método de Ingeniería de SW basado en componentes, el diseño al nivel de estos se concentra en: • La elaboración de las clases de análisis (clases específicas del dominio del problema) • Y la afinación y definición de las clases de infraestructura. • La descripción detallada de atributos, operaciones y las interfaces empleadas por estas clases representa el detalle de diseño requerido como precursor de la actividad de construcción.

19. Principios Básicos del diseño de componente

20. 2. Diseño de componentes basado en Clases • 2.1 Principios básicos de diseño • Hay 4 principios básicos de diseño aplicables al diseño al nivel de componentes y se han adoptado ampliamente cuando se aplica Ingeniería de SW orientada a objetos. • La idea central de estos principios es crear diseños que sean más sensibles al cambio y reducir la propagación de efectos secundarios cuando ocurren cambios.

21. 2.1 Principios básicos de diseño • El Principio Abierto-Cerrado (PAC) “El Módulo debe estar abierto para extensión, pero cerrado para modificación” • El diseñador debe especificar el componente de manera que permita extenderlo (dentro del dominio funcional que atiende) sin necesidad de modificaciones internas al propio componente (al nivel de código o lógica). • Para esto el diseñador crea abstracciones que sirven como memoria intermedia entre la funcionalidad que tal vez habrá de extenderse y la propia clase de diseño.

22. <html> <script languaje="JavaScript"> var n,m,h,p; do n = parseInt(prompt("Ingrese unn número entero",1)); while((n<1)||(n>3)); if(n==1) { document.write(“Sensor de Puerta y ventanas”); } else { if(n==2) { document.write(“Sensor humo”); } else { if(n==3) { document.write(“Sensor de movimiento”); } else { document.write("Esta opción no está implementada"); } } } </script> </html>

23. <<Interfaz>> Sensor Detector Leer() Habilitar() Inhabilitar() Probar() SensorPuertas/ Ventana Sensor humo Detector de Movimiento Sensor Calor Sensor CO2

24. 2. Diseño de componentes basado en Clases • 2.2 Principios de sustitución de Liskov “”Debe tenerse la opción de sustituir las subclases con sus clases principales” • Un componente que use la clase principal debe seguir funcionando apropiadamente si, en cambio, se pasa al componente una clase derivada. • Para lograr esto, este principio exige que cualquier clase derivada de una clase principal se apegue a cualquier contrato implícito entre la clase principal y los componentes que la usan. • En este contexto un contrato es una condición previa que deber ser verdad cuando el componente usa una clase principal y una condición posterior que debe ser cierta después que el componente usa la clase principal. • Cuando un diseñador crea clases derivadas, estas también deben ajustarse a la condiciones previas y posteriores

25. 2. Diseño de componentes basado en Clases • 2.3 Principio de inversión en independencia (PID) “Dependa de las abstracciones, no de las concreciones” • acuerdo al principio del PAC, las abstracciones son el lugar donde el diseño se puede extender sin grandes complicaciones. • Cuanto más dependa un componente de otros componentes concretos (en lugar de abstractos, como la interfaz) más difícil será extenderlos.

26. 2. Diseño de componentes basado en Clases • 2.4 Principio de segregación de la interfaz (PSI) “Es mejor tener muchas interfaces especificas del cliente que una interfaz de propósito general” • Cuando varios componentes de cliente usan las operaciones proporcionadas por una clase servidor. • El PSI sugiere que el diseñador debe crear una interfaz especializada para servir a cada categoría especial de cliente. • Sólo las operaciones importantes para una categoría especial de clientes deben especificarse en la interfaz para esos clientes. • Si varios clientes necesitan las mismas operaciones, deben especificarse en cada una de las interfaces especializadas.

27. 2. Diseño de componentes basado en Clases • 2.4 Principio de segregación de la interfaz (PSI) • Ejemplo: Clase PlanoCasa que se usa para funciones de seguridad y vigilancia • Funciones Seguridad: ColocarDispositivo(), mostrarDispositiuvo(), agruparDispositivo(), y eliminarDispositivo() • Funciones de Vigilancia: Estas además requieren de operaciones especiales para las cámaras: mostrarPV() y mostrarIDDispositivo().

28. Principios de Empaquetamiento

29. 2. Diseño de componentes basado en Clases • En muchos casos los componentes o las clases individuales se organizan en subsistemas o paquetes, no existen en el vacío. • ¿Cómo se debe presentar esta actividad de empaquetamiento? • ¿Cómo deben organizarse los componentes a medida que avanza el diseño? • Para esto se sugieren principios adicionales de empaquetamiento que son aplicables al diseño a nivel de componentes

30. 2. Diseño de componentes basado en Clases • Principio de equivalencia ente reutilización y versión (PER) “La esencia de la reutilización es la misma que de la versión” • Cuando las clases o componentes se diseñan para reutilizarlos, hay un contrato explícito entre el desarrollador de la entidad reutilizable y la persona que lo usará. • Lo aconsejable es agrupar las clases reutilizables en paquetes que se pueden manejar y controlar a medida que evolucionan nuevas versiones.

31. 2. Diseño de componentes basado en Clases • Principio del cierre común (PCC) “Las clases que cambian juntas deben permanecer juntas” • Las clases deben empaquetarse de manera que sean un todo coherente, es decir, cuando las clases se empaquetan como parte de un diseño, deben atender la misma área de funciones o comportamiento. • Esto lleva a un control de cambio y a un manejo de versiones más efectivo

32. 2. Diseño de componentes basado en Clases • Principio común de la reutilización (PCR) “Las clases que no se reutilizan juntas no deben agruparse juntas” • Cuando una o más clases cambian en un paquete, también cambia el número de versión del paquete. • Todas las demás clases o paquetes que dependen de ese paquete deben actualizarse ahora a la versión más reciente del paquete y probarse para asegurar que la nueva versión funciona sin incidentes. • Si no hubo cohesión al agrupar las clases, es posible que cambie una clase que no tenga relación con las demás. • Esto requerirá un proceso innecesario de integración y de prueba. Por esto, sólo deben incluirse en un mismo paquete las clases que se reutilizarán juntas.

33. Líneas generales de diseño

34. 2.2 Líneas generales de diseño al nivel de componentes • Componentes: Deben definirse convenciones de asignación de nombres para componentes especificados como parte del modelo arquitectónico, y luego refinarse y elaborarse como parte del diseño al nivel de componentes. • Los nombres del modelo arquitectónico deben extraerse del dominio del problema y tener algún significado para los participantes que ven el modelo arquitectónico • Ej: la clase PlanoCasa al nivel arquitectónico

35. 2.2 Líneas generales de diseño al nivel de componentes • Interfaces: Las interfaces proporcionan información importante acerca de la comunicación y la colaboración (además de ayudar a lograr el PAC). • Sin embargo, una representación libre de las interfaces tiende a complicar los diagramas del componente.

36. 2.2 Líneas generales de diseño al nivel de componentes • Dependencias y Herencias: • Para mejorar la legibilidad es buena idea modelar las dependencias de izquierda a derecha y la herencia de abajo (clases derivadas) hacia arriba (clases principales). • Además las interdependencias entre los componentes deben representarse mediante interfaces, en lugar de hacerlo mediante la representación de una dependencia de componente a componente. Siguiendo la filosofía del PAC. • Esto ayuda a mejorar las opciones de mantenimiento del sistema

37. 2.3 Cohesión • En el contexto del diseño al nivel de componentes para sistemas orientados a objetos, la cohesión implica que un componente o una clase sólo encapsula atributos y operaciones relacionadas estrechamente entre sí y con la clase del propio componente. • Funcional: Exhibido principalmente para operaciones, este grado de cohesión se presenta cuando un módulo realiza un solo cálculo y luego devuelve un resultado.

38. 2.3 Cohesión • De capa: Exhibido para paquetes, componentes y clases, este tipo de cohesión ocurre cuando una capa superior tiene acceso a los servicios de una inferior, pero ésta no tiene acceso a aquélla. Panel de control Detector Teléfono Modem T-com

39. 2.3 Cohesión • Comunicación: Todas las operaciones con acceso a los mismos datos se definen dentro de una clase. En general, esa clase sólo se concentra en los datos en cuestión, accesándolos y almacenándolos. • Resulta relativamente fácil implementar, probar y mantener las clases y los componentes que muestran cohesión funcional, de capa y de comunicación. • El diseñador debe luchar por alcanzar estos grados de cohesión.

40. 2.3 Cohesión • Secuencial: Los componentes o las operaciones están agrupados de manera que el primero permita la entrada al siguiente, y así sucesivamente. El objetivo es implementar una secuencia de operaciones. • Procedimental: Las componentes o las operaciones están agrupados de manera que permitan la invocación de uno inmediatamente después de que se invoque el anterior, aunque no se hayan pasado datos entre ellos. • Temporal: Las operaciones que se realizan reflejan un comportamiento o estado específico, como una operación que se realiza al principio o todas las operaciones realizadas cuando se detecta un error.

41. 2.3 Cohesión • Utilitaria: Se han agrupado componentes, clases u operaciones que existen dentro de la misma categoría, pero que no tienen otra relación. • Por ejemplo: una clase llamada estadística muestra cohesión utilitaria si contiene todos los atributos y las operaciones necesarios para calcular seis medidas estadísticas simples. • Estos grados de cohesión son menos deseables y deben evitarse cuando existen otras opciones de diseño, sin embargo, es importante tomar en cuenta que a veces los temas pragmáticos de diseño e implementación obligan al diseñador a optar por los grados inferiores de cohesión

42. 2.4 Acoplamiento • El acoplamiento es la medida cualitativa del grado al que las clases de conectan entre sí. A medida que las clases y (los componentes) se vuelven más interdependientes, el acoplamiento aumenta. • Un objetivo importante en el diseño al nivel de componentes consiste en mantener el acoplamiento lo más bajo posible. • El acoplamiento de clases se manifiesta de varias formas: • Acoplamiento de contenido: Ocurre cuando un componente modifica “a escondidas” datos internos de otro”. Esto viola la ocultación de información.

43. 2.4 Acoplamiento • Acoplamiento común: ocurre cuando varios componentes usan una variable global, aunque esto es necesario en algunas ocasiones (para establecer valores predeterminados en toda la aplicación), el acoplamiento común puede llevar a la programación incontrolable de errores y a efectos colaterales imprevisibles cuando se hacen cambios. • Acoplamiento de control: Se presenta cuando la operación A() invoca la operación B() y pasa una marca de control a B. • La marca de control dirige entonces el flujo lógico dentro de B • El problema es que un cambio no relacionado en B puede causar la necesidad de cambiar el significado de la marca de control que pasa A.

44. 2.4 Acoplamiento • Acoplamiento de estampa: Ocurre cuando claseB se declara como tipo para un argumento de una operación de claseA. Debido a que claseB ahora es parte de la definición de claseA, la modificación del sistema se vuelve más compleja. • Acoplamiento de datos: ocurre cuando las operaciones pasan cadenas largas de argumentos de datos. “El ancho de banda” de la comunicación entre clases y componentes crece y la complejidad de la interfaz aumenta. La prueba y el mantenimiento son más difíciles.

45. 2.4 Acoplamiento • Acoplamiento de llamada a rutina: ocurre cuando una operación invoca a otra. Este grado de acoplamiento es común y, a menudo muy necesario. Sin embargo, aumenta la conectividad del sistema. • Acoplamiento de uso de tipo: Ocurre cuando el componente A usa un tipo de datos definidos en el componente B (por ejemplo, esto ocurre cada vez que “una clase” declara una variable de instancia o una local como si estuviera otra clase para su tipo”). Si cambia la definición del tipo, también deben cambiar todos los componentes que usan la definición.

46. 2.4 Acoplamiento • Acoplamiento de inclusión o importación: ocurre cuando el componente A importa o incluye un paquete o el contenido del componente B. • Acoplamiento externo: Ocurre cuando un componente se comunica o colabora con componentes de infraestructura (como las funciones del sistema de operación, capacidad de la base de datos, las funciones de comunicación). Aunque este tipo de acoplamiento es necesario, debe limitarse a un pequeño número de componente o clases de un sistema

47. 2.4 Acoplamiento • El SW debe comunicarse interna y externamente. Por tanto, el acoplamiento es fundamental. Sin embargo, el diseñador debe trabajar para reducir el acoplamiento cada vez que sea posible y comprender las ramificaciones de un acoplamiento elevado cuando no pueda evitarse.

48. Conducción del Diseño a nivel de componentes

49. 3. Conducción del diseño al nivel de componentes • El diseño al nivel de componente es de naturaleza elaborativa. • El diseñador debe transformar la información del análisis y los modelos arquitectónicos en una representación de diseño que proporcione suficiente detalle para guiar la actividad de construcción (codificación y prueba). • Los siguientes pasos representan un conjunto de tareas típicas para el diseño al nivel de componentes, al aplicar el sistema orientado a objetos:

50. 3. Conducción del diseño al nivel de componentes • Paso 1: Identificar todas las clases de diseño que corresponden al dominio del problema. • Paso 2: Identificar todas las clases de diseño que corresponden al dominio de la infraestructura. • Estas clases no se describen en el modelo del análisis y a menudo faltan en el modelo arquitectónico, pero deben describirse acá. • Paso 3: Elaborar todas las clases de diseño que no se adquieran como componentes reutilizables. • La elaboración requiere que se describan de manera detallada todas las interfases, los atributos y las operaciones necesarias para implementar la clase. Al realizar esta tarea debe tomarse en cuenta el diseño de la heurística (Por ej: la cohesión y el acoplamiento de componentes)