1 Diseño e ImplementaciónDiseñ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 ObjetosUn 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 ObjetosPara 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 ImprentaNº 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 elaboradoTrabajo 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() <> calcular trabajo CalcularCostoPagina() CalcularCostoPapel() CalcularCostoProd() CalcularCostoTrabajoTotal() <> Iniciar trabajo ConstruirOrdenTrabajo() VerificarPrioridad() PasarTrabajoaProducción()

11 1.1 Concepto Orientado a Objetos1 ¿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 convencionalUn 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.2 El concepto convencional1 ¿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.2 El concepto convencional1 ¿Qué es un componente? 1.2 El concepto convencional Sistema de Administración De Trabajo Leer datos de Trabajo de Impresión Seleccionar la Función de Manejo de trabajo 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.2 El concepto convencional1 ¿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 convencionalEj: 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 ObtenerdatosTrabajosComponente 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 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 ClasesEl 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 Clases2.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ñoEl 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 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/22/%3Chtml%3E+%3Cscript+languaje%3D+JavaScript+%3E+var+n%2Cm%2Ch%2Cp%3B+do.+n+%3D+parseInt%28prompt%28+Ingrese+unn+n%C3%BAmero+entero+%2C1%29%29%3B.jpg", "name": " var n,m,h,p; do. n = parseInt(prompt( Ingrese unn número entero ,1));", "description": "while((n3)); if(n==1) { document.write( Sensor de Puerta y ventanas ); } else. { if(n==2) document.write( Sensor humo ); { if(n==3) document.write( Sensor de movimiento ); document.write( Esta opción no está implementada ); "> 23 <>Sensor Detector Leer() Habilitar() Inhabilitar() Probar() SensorPuertas/ Ventana Sensor humo Detector de Movimiento Sensor Calor Sensor CO2 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/23/%3C%3CInterfaz%3E%3E.jpg", "name": "", "description": "Sensor. Detector. Leer() Habilitar() Inhabilitar() Probar() SensorPuertas/ Ventana. Sensor humo. Detector de. Movimiento. Sensor Calor. Sensor. CO2.", "width": "800" } 24 2. Diseño de componentes basado en Clases2.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 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/24/2.+Dise%C3%B1o+de+componentes+basado+en+Clases.jpg", "name": "2. Diseño de componentes basado en Clases", "description": "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.", "width": "800" } 25 2. Diseño de componentes basado en Clases2.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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/25/2.+Dise%C3%B1o+de+componentes+basado+en+Clases.jpg", "name": "2. Diseño de componentes basado en Clases", "description": "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.", "width": "800" } 26 2. Diseño de componentes basado en Clases2.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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/26/2.+Dise%C3%B1o+de+componentes+basado+en+Clases.jpg", "name": "2. Diseño de componentes basado en Clases", "description": "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.", "width": "800" } 27 2. Diseño de componentes basado en Clases2.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(). { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/27/2.+Dise%C3%B1o+de+componentes+basado+en+Clases.jpg", "name": "2. Diseño de componentes basado en Clases", "description": "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().", "width": "800" } 28 Principios de Empaquetamiento { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/28/Principios+de+Empaquetamiento.jpg", "name": "Principios de Empaquetamiento", "description": "Principios de Empaquetamiento", "width": "800" } 29 2. Diseño de componentes basado en ClasesEn 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 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/29/2.+Dise%C3%B1o+de+componentes+basado+en+Clases.jpg", "name": "2. Diseño de componentes basado en Clases", "description": "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.", "width": "800" } 30 2. Diseño de componentes basado en ClasesPrincipio 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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/30/2.+Dise%C3%B1o+de+componentes+basado+en+Clases.jpg", "name": "2. Diseño de componentes basado en Clases", "description": "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.", "width": "800" } 31 2. Diseño de componentes basado en ClasesPrincipio 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 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/31/2.+Dise%C3%B1o+de+componentes+basado+en+Clases.jpg", "name": "2. Diseño de componentes basado en Clases", "description": "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.", "width": "800" } 32 2. Diseño de componentes basado en ClasesPrincipio 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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/32/2.+Dise%C3%B1o+de+componentes+basado+en+Clases.jpg", "name": "2. Diseño de componentes basado en Clases", "description": "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.", "width": "800" } 33 Líneas generales de diseño { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/33/L%C3%ADneas+generales+de+dise%C3%B1o.jpg", "name": "Líneas generales de diseño", "description": "Líneas generales de diseño", "width": "800" } 34 2.2 Líneas generales de diseño al nivel de componentesComponentes: 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 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/34/2.2+L%C3%ADneas+generales+de+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "2.2 Líneas generales de diseño al nivel de componentes", "description": "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.", "width": "800" } 35 2.2 Líneas generales de diseño al nivel de componentesInterfaces: 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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/35/2.2+L%C3%ADneas+generales+de+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "2.2 Líneas generales de diseño al nivel de componentes", "description": "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.", "width": "800" } 36 2.2 Líneas generales de diseño al nivel de componentesDependencias 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 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/36/2.2+L%C3%ADneas+generales+de+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "2.2 Líneas generales de diseño al nivel de componentes", "description": "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.", "width": "800" } 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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/37/2.3+Cohesi%C3%B3n.jpg", "name": "2.3 Cohesión", "description": "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.", "width": "800" } 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 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/38/2.3+Cohesi%C3%B3n.jpg", "name": "2.3 Cohesión", "description": "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.", "width": "800" } 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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/39/2.3+Cohesi%C3%B3n.jpg", "name": "2.3 Cohesión", "description": "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.", "width": "800" } 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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/40/2.3+Cohesi%C3%B3n.jpg", "name": "2.3 Cohesión", "description": "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.", "width": "800" } 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 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/41/2.3+Cohesi%C3%B3n.jpg", "name": "2.3 Cohesión", "description": "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.", "width": "800" } 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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/42/2.4+Acoplamiento.jpg", "name": "2.4 Acoplamiento", "description": "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.", "width": "800" } 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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/43/2.4+Acoplamiento.jpg", "name": "2.4 Acoplamiento", "description": "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.", "width": "800" } 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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/44/2.4+Acoplamiento.jpg", "name": "2.4 Acoplamiento", "description": "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.", "width": "800" } 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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/45/2.4+Acoplamiento.jpg", "name": "2.4 Acoplamiento", "description": "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.", "width": "800" } 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 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/46/2.4+Acoplamiento+Acoplamiento+de+inclusi%C3%B3n+o+importaci%C3%B3n%3A+ocurre+cuando+el+componente+A+importa+o+incluye+un+paquete+o+el+contenido+del+componente+B..jpg", "name": "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.", "description": "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.", "width": "800" } 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. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/47/2.4+Acoplamiento.jpg", "name": "2.4 Acoplamiento", "description": "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.", "width": "800" } 48 Conducción del Diseño a nivel de componentes { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/48/Conducci%C3%B3n+del+Dise%C3%B1o+a+nivel+de+componentes.jpg", "name": "Conducción del Diseño a nivel de componentes", "description": "Conducción del Diseño a nivel de componentes", "width": "800" } 49 3. Conducción del diseño al nivel de componentesEl 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: { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/49/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "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:", "width": "800" } 50 3. Conducción del diseño al nivel de componentesPaso 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) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/50/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "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)", "width": "800" } 51 3. Conducción del diseño al nivel de componentesPaso 3a: Especificar los detalles del mensaje cuando las clases o los componentes colaboran. El modelo de análisis emplea el diagrama de colaboración para mostrar la manera en que las clases de análisis colaboran entre sí. Acá es útil mostrar los detalles de estas colaboraciones, especificando la estructura de mensajes que se pasan entre los objetos del sistema. (opcional, pero puede usarse como el inicio de la especificación de interfaces ya que muestran la manera en que se comunican y colaboran los componentes del sistema. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/51/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Paso 3a: Especificar los detalles del mensaje cuando las clases o los componentes colaboran. El modelo de análisis emplea el diagrama de colaboración para mostrar la manera en que las clases de análisis colaboran entre sí. Acá es útil mostrar los detalles de estas colaboraciones, especificando la estructura de mensajes que se pasan entre los objetos del sistema. (opcional, pero puede usarse como el inicio de la especificación de interfaces ya que muestran la manera en que se comunican y colaboran los componentes del sistema.", "width": "800" } 52 3. Conducción del diseño al nivel de componentesPaso 3a: TrabajoProducción 1: ConstruirTrabajo (númeroOT) 2: RemitirTrabajo (númeroOT) OrdenTrabajo ColaTrabajo [condición guardia] Expresión de secuencia (valor devuelto): = Nombre del mensaje (lista de argumentos) Condición guardia = Especifica cualquier conjunto de condiciones que deben cumplirse antes de enviar el mensaje Expresión de secuencia: es un valor entero que indica el orden secuencial en que se envía un mensaje (Valor devuelto) es el nombre de la información que devuelve la operación que se invoca por el mensaje Nombre del mensaje Identifica la operación que se invoca (Lista de argumento) es la lista de los atributos que se pasan a la operación { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/52/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Paso 3a: TrabajoProducción. 1: ConstruirTrabajo (númeroOT) 2: RemitirTrabajo (númeroOT) OrdenTrabajo. ColaTrabajo. [condición guardia] Expresión de secuencia. (valor devuelto): = Nombre del mensaje. (lista de argumentos) Condición guardia = Especifica cualquier conjunto de condiciones que deben cumplirse antes de enviar el mensaje. Expresión de secuencia: es un valor entero que indica el orden secuencial en que se envía un mensaje. (Valor devuelto) es el nombre de la información que devuelve la operación que se invoca por el mensaje. Nombre del mensaje Identifica la operación que se invoca. (Lista de argumento) es la lista de los atributos que se pasan a la operación.", "width": "800" } 53 3. Conducción del diseño al nivel de componentesPaso 3b: Identificar las interfaces apropiadas para cada componente. En el contexto del diseño a nivel de componentes, una interfaz UML es un grupo de operaciones externamente visibles (i.e públicas). La interfaz no contiene estructura interna; no tiene atributos ni asociaciones. Formalmente una interfaz es el equivalente a una clase abstracta que proporciona una conexión controlada entre las clases de diseño. En esencia, las operaciones definidas para la clase de diseño están orientadas en una o más clases abstractas Cada operación dentro de la interfaz debe tener cohesión, es decir, debe mostrar procesamiento que se concentra en una función o sub función limitada. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/53/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Paso 3b: Identificar las interfaces apropiadas para cada componente. En el contexto del diseño a nivel de componentes, una interfaz UML es un grupo de operaciones externamente visibles (i.e públicas). La interfaz no contiene estructura interna; no tiene atributos ni asociaciones. Formalmente una interfaz es el equivalente a una clase abstracta que proporciona una conexión controlada entre las clases de diseño. En esencia, las operaciones definidas para la clase de diseño están orientadas en una o más clases abstractas. Cada operación dentro de la interfaz debe tener cohesión, es decir, debe mostrar procesamiento que se concentra en una función o sub función limitada.", "width": "800" } 54 3. Conducción del diseño al nivel de componentesTrabajo 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() <> calcular costo trabajo CalcularCostoPagina() CalcularCostoPapel() CalcularCostoProd() CalcularCostoTrabajoTotal() <> Iniciar trabajo ConstruirOrdenTrabajo() VerificarPrioridad() PasarTrabajoaProducción() { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/54/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "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() calcular costo trabajo. CalcularCostoPagina() CalcularCostoPapel() CalcularCostoProd() CalcularCostoTrabajoTotal() Iniciar trabajo. ConstruirOrdenTrabajo() VerificarPrioridad() PasarTrabajoaProducción()", "width": "800" } 55 3. Conducción del diseño al nivel de componentesCalcularTrabajo Imprimir trabajo InicarTrabajo OrdenTrabajo Atributos apropiados ConstruirOrdenTrabajo() <> Iniciar Trabajo pasarTrabajoaProduccion() ConstruirTrabajo Trabajo Producción ObtenerDescripciónTrabajo ColaTrabajo Atributos apropiados revisarPrioridad() RemitirTrabajo { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/55/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "CalcularTrabajo. Imprimir. trabajo. InicarTrabajo. OrdenTrabajo. Atributos apropiados. ConstruirOrdenTrabajo() Iniciar Trabajo. pasarTrabajoaProduccion() ConstruirTrabajo. Trabajo. Producción. ObtenerDescripciónTrabajo. ColaTrabajo. Atributos apropiados. revisarPrioridad() RemitirTrabajo.", "width": "800" } 56 3. Conducción del diseño al nivel de componentesPaso 3c: Elaborar atributos y definir los tipos y las estructuras de datos necesarios para implementarlos. En general, las estructuras y los tipos de datos con que se describen atributos se definen dentro del contexto del lenguaje de programación que habrá de usarse para la implementación. La sintaxis usada por UML para definir un tipo de datos es la siguiente Nombre: tipo-Expresión = valor-inicial {propiedad cadena} Nombre: corresponde al nombre del atributo tipo-Expresión: es el tipo de datos valor-inicial: Valor que toma el objeto cuando es creado {propiedad cadena}: define una propiedad o característica del atributo { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/56/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Paso 3c: Elaborar atributos y definir los tipos y las estructuras de datos necesarios para implementarlos. En general, las estructuras y los tipos de datos con que se describen atributos se definen dentro del contexto del lenguaje de programación que habrá de usarse para la implementación. La sintaxis usada por UML para definir un tipo de datos es la siguiente. Nombre: tipo-Expresión = valor-inicial {propiedad cadena} Nombre: corresponde al nombre del atributo. tipo-Expresión: es el tipo de datos. valor-inicial: Valor que toma el objeto cuando es creado. {propiedad cadena}: define una propiedad o característica del atributo.", "width": "800" } 57 3. Conducción del diseño al nivel de componentesPaso 3c: Elaborar atributos y definir los tipos y las estructuras de datos necesarios para implementarlos. Ejemplo: en las primeras iteraciones los atributos suelen describirse por nombre, sin embargo, a medida que avanza la elaboración del diseño, cada atributo se define empleando el formato de atributos UML Tipo-pesopapel: string = “A”{contiene 1 de 4 valores: A, B, C o D} Si un atributo aparece varías veces en varias clases de diseño, y tiene una estructura relativamente compleja, es mejor crear una clase separada para acomodar el atributo. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/57/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Paso 3c: Elaborar atributos y definir los tipos y las estructuras de datos necesarios para implementarlos. Ejemplo: en las primeras iteraciones los atributos suelen describirse por nombre, sin embargo, a medida que avanza la elaboración del diseño, cada atributo se define empleando el formato de atributos UML. Tipo-pesopapel: string = A {contiene 1 de 4 valores: A, B, C o D} Si un atributo aparece varías veces en varias clases de diseño, y tiene una estructura relativamente compleja, es mejor crear una clase separada para acomodar el atributo.", "width": "800" } 58 3. Conducción del diseño al nivel de componentesPaso 3-D: Describir de manera detallada el flujo de procesamiento dentro de cada operación. Esto se logra utilizando un pseudo código basado en un lenguaje de programación o el diagrama de actividad de UML. Cada componente de SW se elabora mediante varias interacciones que aplican el concepto de refinamiento paso a paso. La primera iteración define cada operación como parte de la clase de diseño. En cada caso, la operación debe estar caracterizada de manera que asegure una cohesión elevada, es decir, la operación debe realizar una sola función o sustitución definida. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/58/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Paso 3-D: Describir de manera detallada el flujo de procesamiento dentro de cada operación. Esto se logra utilizando un pseudo código basado en un lenguaje de programación o el diagrama de actividad de UML. Cada componente de SW se elabora mediante varias interacciones que aplican el concepto de refinamiento paso a paso. La primera iteración define cada operación como parte de la clase de diseño. En cada caso, la operación debe estar caracterizada de manera que asegure una cohesión elevada, es decir, la operación debe realizar una sola función o sustitución definida.", "width": "800" } 59 3. Conducción del diseño al nivel de componentesPaso 3-D: Describir de manera detallada el flujo de procesamiento dentro de cada operación. La siguiente iteración hace poco más que expandir el nombre de la operación Por Ejemplo: la operación calcularcostoPapel() se expandiría de la siguiente forma: CalcularCostoPapel(peso, tamaño, color):numérico Esto significa que la operación CalcularCostoPapel() requiere los atributos peso, tamaño y color como entrada y devuelve un valor numérico como salida. Si el algoritmo requerido para implementar CalcularCostoPapel() es simple y se comprende ampliamente, tal vez sea innecesario elaborar diseño adicional { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/59/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Paso 3-D: Describir de manera detallada el flujo de procesamiento dentro de cada operación. La siguiente iteración hace poco más que expandir el nombre de la operación. Por Ejemplo: la operación calcularcostoPapel() se expandiría de la siguiente forma: CalcularCostoPapel(peso, tamaño, color):numérico. Esto significa que la operación CalcularCostoPapel() requiere los atributos peso, tamaño y color como entrada y devuelve un valor numérico como salida. Si el algoritmo requerido para implementar CalcularCostoPapel() es simple y se comprende ampliamente, tal vez sea innecesario elaborar diseño adicional.", "width": "800" } 60 3. Conducción del diseño al nivel de componentesValida entrada de atributos Accesar BDPapel(peso) Regresa a costoPapelPorPagina CostoPapelPorPagina = CostoBasePorPágina CostoPapelPorPagina = CostoBasePorPagina * 1.2 Tamaño = B Tamaño = C CostoPapelPorPagina = CostobasePorPagina * 1.4 Tamaño = D CostoPapelPorpagina = CostoBasePorPagina * 1.6 El color es personalizado CostoPapelPorPagina = costoBasePorPágina * 1.14 El color es estandar Devuelve (CostoPapelPorPagina) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/60/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Valida entrada de atributos. Accesar BDPapel(peso) Regresa a costoPapelPorPagina. CostoPapelPorPagina = CostoBasePorPágina. CostoPapelPorPagina = CostoBasePorPagina * 1.2. Tamaño = B. Tamaño = C. CostoPapelPorPagina = CostobasePorPagina * 1.4. Tamaño = D. CostoPapelPorpagina = CostoBasePorPagina * 1.6. El color es personalizado. CostoPapelPorPagina = costoBasePorPágina * 1.14. El color es estandar. Devuelve (CostoPapelPorPagina)", "width": "800" } 61 3. Conducción del diseño al nivel de componentesPaso 4: Describir fuentes de datos persistentes (bases de datos y archivos) e identificar las clases necesarias para manejarlas. Paso 5: Desarrollar y elaborar representaciones del comportamiento de una clase o un componente. Al comportamiento dinámico de un objeto lo afectan eventos externos y estado actual del objeto. Para comprender el comportamiento dinámico de un objeto, el diseñador debe examinar todos los casos de uso relevantes durante el periodo de vida de la clase diseño. Estos casos de uso proporcionan información que ayuda al diseñador a delinear los eventos que afectan al objeto y a los estados en que reside éste mientras pasa el tiempo y ocurren eventos. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/61/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Paso 4: Describir fuentes de datos persistentes (bases de datos y archivos) e identificar las clases necesarias para manejarlas. Paso 5: Desarrollar y elaborar representaciones del comportamiento de una clase o un componente. Al comportamiento dinámico de un objeto lo afectan eventos externos y estado actual del objeto. Para comprender el comportamiento dinámico de un objeto, el diseñador debe examinar todos los casos de uso relevantes durante el periodo de vida de la clase diseño. Estos casos de uso proporcionan información que ayuda al diseñador a delinear los eventos que afectan al objeto y a los estados en que reside éste mientras pasa el tiempo y ocurren eventos.", "width": "800" } 62 3. Conducción del diseño al nivel de componentesPaso 5: Desarrollar y elaborar representaciones del comportamiento de una clase o un componente. La transición entre estados (impulsados por los eventos) se representa empleando un diagrama de estados de UML. El evento que gatilla la transición de un estado a otro toma la siguiente forma: Nombre-evento {lista parámetros} [condición de guardia] / expresión de acción. Nombre-evento: identifica el evento. Lista-parámetros: incorpora datos asociados con el evento. Condición-guardia: está escrita en lenguaje de restricción de objetos (OCL). Y especifica una condición que debe cumplirse antes de que pueda ocurrir el evento. Expresión de acción: define una acción antes de que ocurra cuando tenga lugar la transición. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/62/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Paso 5: Desarrollar y elaborar representaciones del comportamiento de una clase o un componente. La transición entre estados (impulsados por los eventos) se representa empleando un diagrama de estados de UML. El evento que gatilla la transición de un estado a otro toma la siguiente forma: Nombre-evento {lista parámetros} [condición de guardia] / expresión de acción. Nombre-evento: identifica el evento. Lista-parámetros: incorpora datos asociados con el evento. Condición-guardia: está escrita en lenguaje de restricción de objetos (OCL). Y especifica una condición que debe cumplirse antes de que pueda ocurrir el evento. Expresión de acción: define una acción antes de que ocurra cuando tenga lugar la transición.", "width": "800" } 63 3. Conducción del diseño al nivel de componentesComportamiento dentro del estado ConstuirDatosTrabajo EntradaDatosIncompletos Construir datos trabajo Entrar/leerDatosTrabajo() Salir/desplegarDatosTrabajo() Hacer/revisarCosistencia() Incluir/entradaDatos entradaDatosCompletada [todos los elementos de datos consistentes]/desplegarOpcionesUsuario Calcular Costo Trabajo Entrar/calcularTrabajo Salir/guardarcostoTotalTrabajo() costoTrabajoAceptado [el cliente está autorizado] / obetenerFirmaElectrónica Formar trabajo Entrar/ConstruirTrabajo() Salir/guardarNumeroOT() Hacer/ fechaEntregaAceptada [el cliente está autorizado] / estimadoTrabajoImpresión Remitir trabajo Entrar/remitirTrabajo() Salir/iniciarTrabajo() Hacer/colocar en ColaTrabajo trabajoRemitido [todas las autorizaciones adquiridas] / imprimirOrdenTrabajo { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/63/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Comportamiento dentro del estado ConstuirDatosTrabajo. EntradaDatosIncompletos. Construir datos trabajo. Entrar/leerDatosTrabajo() Salir/desplegarDatosTrabajo() Hacer/revisarCosistencia() Incluir/entradaDatos. entradaDatosCompletada [todos los elementos de datos consistentes]/desplegarOpcionesUsuario. Calcular Costo Trabajo. Entrar/calcularTrabajo. Salir/guardarcostoTotalTrabajo() costoTrabajoAceptado [el cliente está autorizado] / obetenerFirmaElectrónica. Formar trabajo. Entrar/ConstruirTrabajo() Salir/guardarNumeroOT() Hacer/ fechaEntregaAceptada [el cliente está autorizado] / estimadoTrabajoImpresión. Remitir trabajo. Entrar/remitirTrabajo() Salir/iniciarTrabajo() Hacer/colocar en ColaTrabajo. trabajoRemitido [todas las autorizaciones adquiridas] / imprimirOrdenTrabajo.", "width": "800" } 64 3. Conducción del diseño al nivel de componentesPaso 6: Elaborar diagramas de despliegue para proporcionar detalles de la implementación adicional. Se elaboran diagramas de despliegue para representar la ubicación de paquetes clave de componentes. Sin embargo, por lo general los componentes de representan individualmente dentro de un diagrama de componente. La razón de esto es evitar la complejidad del diagrama. Paso 7: Factorizar todas las representaciones del diseño al nivel de componentes y siempre deben considerarse alternativas El primer modelo a nivel de componente que se cree no será tan completo, consistente o exacto como la enésima iteración que aplique al modelo. Es esencial usar refactorización mientras se realiza el trabajo de diseño. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/64/3.+Conducci%C3%B3n+del+dise%C3%B1o+al+nivel+de+componentes.jpg", "name": "3. Conducción del diseño al nivel de componentes", "description": "Paso 6: Elaborar diagramas de despliegue para proporcionar detalles de la implementación adicional. Se elaboran diagramas de despliegue para representar la ubicación de paquetes clave de componentes. Sin embargo, por lo general los componentes de representan individualmente dentro de un diagrama de componente. La razón de esto es evitar la complejidad del diagrama. Paso 7: Factorizar todas las representaciones del diseño al nivel de componentes y siempre deben considerarse alternativas. El primer modelo a nivel de componente que se cree no será tan completo, consistente o exacto como la enésima iteración que aplique al modelo. Es esencial usar refactorización mientras se realiza el trabajo de diseño.", "width": "800" } 65 4. Lenguajes de restricción de ObjetosLa variedad de diagramas disponible como parte de UML proporciona a un diseñador un rico conjunto de formas de representación para el modelo de diseño. Sin embargo, las representaciones gráficas no suelen bastar. El diseñador necesita de un mecanismo para representar explicita y formalmente la información que restringe algún elemento del modelo de diseño. Es posible, describir las restricciones en lenguaje natural, pero este método lleva invariablemente a la inconsistencia y la ambigüedad, por lo que lo apropiado parece un lenguaje formal que tome en cuenta la teoría de conjunto y los lenguajes formales de especificación, pero que tenga una cantidad menor de sintaxis matemáticas que un lenguaje de programación. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/65/4.+Lenguajes+de+restricci%C3%B3n+de+Objetos.jpg", "name": "4. Lenguajes de restricción de Objetos", "description": "La variedad de diagramas disponible como parte de UML proporciona a un diseñador un rico conjunto de formas de representación para el modelo de diseño. Sin embargo, las representaciones gráficas no suelen bastar. El diseñador necesita de un mecanismo para representar explicita y formalmente la información que restringe algún elemento del modelo de diseño. Es posible, describir las restricciones en lenguaje natural, pero este método lleva invariablemente a la inconsistencia y la ambigüedad, por lo que lo apropiado parece un lenguaje formal que tome en cuenta la teoría de conjunto y los lenguajes formales de especificación, pero que tenga una cantidad menor de sintaxis matemáticas que un lenguaje de programación.", "width": "800" } 66 4. Lenguajes de restricción de ObjetosEl lenguajes de restricción de Objetos (OCL) complementa al UML al permitir que un ingeniero de SW use gramática y sintaxis formales para construir instrucciones sin ambigüedades relacionadas con varios elementos del modelo de diseño. En OCL las instrucciones se construyen en 4 partes: Un contexto que define la situación limitada en que es válida la instrucción. Una propiedad que representan algunas características del contexto. Una operación que manipula o califica una propiedad Palabras clave (como if, then, else, and, or, not, implies) con que se especifican expresiones condicionales. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/66/4.+Lenguajes+de+restricci%C3%B3n+de+Objetos.jpg", "name": "4. Lenguajes de restricción de Objetos", "description": "El lenguajes de restricción de Objetos (OCL) complementa al UML al permitir que un ingeniero de SW use gramática y sintaxis formales para construir instrucciones sin ambigüedades relacionadas con varios elementos del modelo de diseño. En OCL las instrucciones se construyen en 4 partes: Un contexto que define la situación limitada en que es válida la instrucción. Una propiedad que representan algunas características del contexto. Una operación que manipula o califica una propiedad. Palabras clave (como if, then, else, and, or, not, implies) con que se especifican expresiones condicionales.", "width": "800" } 67 4. Lenguajes de restricción de ObjetosEjemplo: considere la condición de guardia colocada en el evento costoTrabajoAceptado que causa una transición entre los estados calcularCostoTrabajo() y formarTrabajo() dentro del diagrama de gráfica de estado para la clase TrabajoImprenta. En el diagrama, la condición guardia se expresa en lenguaje natural y especifica que la autorización sólo se presentará si el cliente está autorizado para aprobar el costo del trabajo. Cliente tiene.autoridadAutorización = “si” Donde un atributo booleano, autoridadAutorización, de la clase CLIENTE (una instancia específica de la clase) debe tener el valor si para satisfacer la condición guardia. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/67/4.+Lenguajes+de+restricci%C3%B3n+de+Objetos.jpg", "name": "4. Lenguajes de restricción de Objetos", "description": "Ejemplo: considere la condición de guardia colocada en el evento costoTrabajoAceptado que causa una transición entre los estados calcularCostoTrabajo() y formarTrabajo() dentro del diagrama de gráfica de estado para la clase TrabajoImprenta. En el diagrama, la condición guardia se expresa en lenguaje natural y especifica que la autorización sólo se presentará si el cliente está autorizado para aprobar el costo del trabajo. Cliente. tiene.autoridadAutorización = si Donde un atributo booleano, autoridadAutorización, de la clase CLIENTE (una instancia específica de la clase) debe tener el valor si para satisfacer la condición guardia.", "width": "800" } 68 4. Lenguajes de restricción de ObjetosCuando se crea el modelo de diseño suele haber instancias en que deben satisfacerse las condiciones previas y posteriores antes de completar alguna opción especificada en el diseño. El OCL proporciona una herramienta poderosa para especificar condiciones previas y posteriores de manera formal. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/68/4.+Lenguajes+de+restricci%C3%B3n+de+Objetos.jpg", "name": "4. Lenguajes de restricción de Objetos", "description": "Cuando se crea el modelo de diseño suele haber instancias en que deben satisfacerse las condiciones previas y posteriores antes de completar alguna opción especificada en el diseño. El OCL proporciona una herramienta poderosa para especificar condiciones previas y posteriores de manera formal.", "width": "800" } 69 4. Lenguajes de restricción de ObjetosCuando se crea el modelo de diseño suele haber instancias en que deben satisfacerse las condiciones previas y posteriores antes de completar alguna opción especificada en el diseño. El OCL proporciona una herramienta poderosa para especificar condiciones previas y posteriores de manera formal. Ej: al sistema de la imprenta, el cliente ahora proporciona un límite de costo superior para el trabajo de impresión y una fecha de entrega límite, al mismo tiempo que se especifican otras características de trabajo. Si el costo y la entrega estimada exceden esos límites, el trabajo no se entregará y debe notificarse al cliente. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://slideplayer.es/5515554/17/images/69/4.+Lenguajes+de+restricci%C3%B3n+de+Objetos.jpg", "name": "4. Lenguajes de restricción de Objetos", "description": "Cuando se crea el modelo de diseño suele haber instancias en que deben satisfacerse las condiciones previas y posteriores antes de completar alguna opción especificada en el diseño. El OCL proporciona una herramienta poderosa para especificar condiciones previas y posteriores de manera formal. Ej: al sistema de la imprenta, el cliente ahora proporciona un límite de costo superior para el trabajo de impresión y una fecha de entrega límite, al mismo tiempo que se especifican otras características de trabajo. Si el costo y la entrega estimada exceden esos límites, el trabajo no se entregará y debe notificarse al cliente.", "width": "800" } 70 Context TrabajoImprenta::validate(limiteSuperiorCosto : Integer, reqEnvioCliente : Integer)pre: LimiteSuperiorCosto > 0 and reqEnvioCliente > 0 and tiene.autorizacionTrabajo = “no” post: if tiene.costoTotalTrabajo <= limiteSuperiorCosto and tiene.fechaEnvio <= reqEnvioCliente then tiene.autorizacionTrabajo = “si” endif

23 <>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 Clases2.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 Clases2.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 Clases2.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 Clases2.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 ClasesEn 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 ClasesPrincipio 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 ClasesPrincipio 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 ClasesPrincipio 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 componentesComponentes: 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 componentesInterfaces: 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 componentesDependencias 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 componentesEl 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 componentesPaso 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)

51 3. Conducción del diseño al nivel de componentesPaso 3a: Especificar los detalles del mensaje cuando las clases o los componentes colaboran. El modelo de análisis emplea el diagrama de colaboración para mostrar la manera en que las clases de análisis colaboran entre sí. Acá es útil mostrar los detalles de estas colaboraciones, especificando la estructura de mensajes que se pasan entre los objetos del sistema. (opcional, pero puede usarse como el inicio de la especificación de interfaces ya que muestran la manera en que se comunican y colaboran los componentes del sistema.

52 3. Conducción del diseño al nivel de componentesPaso 3a: TrabajoProducción 1: ConstruirTrabajo (númeroOT) 2: RemitirTrabajo (númeroOT) OrdenTrabajo ColaTrabajo [condición guardia] Expresión de secuencia (valor devuelto): = Nombre del mensaje (lista de argumentos) Condición guardia = Especifica cualquier conjunto de condiciones que deben cumplirse antes de enviar el mensaje Expresión de secuencia: es un valor entero que indica el orden secuencial en que se envía un mensaje (Valor devuelto) es el nombre de la información que devuelve la operación que se invoca por el mensaje Nombre del mensaje Identifica la operación que se invoca (Lista de argumento) es la lista de los atributos que se pasan a la operación

53 3. Conducción del diseño al nivel de componentesPaso 3b: Identificar las interfaces apropiadas para cada componente. En el contexto del diseño a nivel de componentes, una interfaz UML es un grupo de operaciones externamente visibles (i.e públicas). La interfaz no contiene estructura interna; no tiene atributos ni asociaciones. Formalmente una interfaz es el equivalente a una clase abstracta que proporciona una conexión controlada entre las clases de diseño. En esencia, las operaciones definidas para la clase de diseño están orientadas en una o más clases abstractas Cada operación dentro de la interfaz debe tener cohesión, es decir, debe mostrar procesamiento que se concentra en una función o sub función limitada.

54 3. Conducción del diseño al nivel de componentesTrabajo 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() <> calcular costo trabajo CalcularCostoPagina() CalcularCostoPapel() CalcularCostoProd() CalcularCostoTrabajoTotal() <> Iniciar trabajo ConstruirOrdenTrabajo() VerificarPrioridad() PasarTrabajoaProducción()

55 3. Conducción del diseño al nivel de componentesCalcularTrabajo Imprimir trabajo InicarTrabajo OrdenTrabajo Atributos apropiados ConstruirOrdenTrabajo() <> Iniciar Trabajo pasarTrabajoaProduccion() ConstruirTrabajo Trabajo Producción ObtenerDescripciónTrabajo ColaTrabajo Atributos apropiados revisarPrioridad() RemitirTrabajo

56 3. Conducción del diseño al nivel de componentesPaso 3c: Elaborar atributos y definir los tipos y las estructuras de datos necesarios para implementarlos. En general, las estructuras y los tipos de datos con que se describen atributos se definen dentro del contexto del lenguaje de programación que habrá de usarse para la implementación. La sintaxis usada por UML para definir un tipo de datos es la siguiente Nombre: tipo-Expresión = valor-inicial {propiedad cadena} Nombre: corresponde al nombre del atributo tipo-Expresión: es el tipo de datos valor-inicial: Valor que toma el objeto cuando es creado {propiedad cadena}: define una propiedad o característica del atributo

57 3. Conducción del diseño al nivel de componentesPaso 3c: Elaborar atributos y definir los tipos y las estructuras de datos necesarios para implementarlos. Ejemplo: en las primeras iteraciones los atributos suelen describirse por nombre, sin embargo, a medida que avanza la elaboración del diseño, cada atributo se define empleando el formato de atributos UML Tipo-pesopapel: string = “A”{contiene 1 de 4 valores: A, B, C o D} Si un atributo aparece varías veces en varias clases de diseño, y tiene una estructura relativamente compleja, es mejor crear una clase separada para acomodar el atributo.

58 3. Conducción del diseño al nivel de componentesPaso 3-D: Describir de manera detallada el flujo de procesamiento dentro de cada operación. Esto se logra utilizando un pseudo código basado en un lenguaje de programación o el diagrama de actividad de UML. Cada componente de SW se elabora mediante varias interacciones que aplican el concepto de refinamiento paso a paso. La primera iteración define cada operación como parte de la clase de diseño. En cada caso, la operación debe estar caracterizada de manera que asegure una cohesión elevada, es decir, la operación debe realizar una sola función o sustitución definida.

59 3. Conducción del diseño al nivel de componentesPaso 3-D: Describir de manera detallada el flujo de procesamiento dentro de cada operación. La siguiente iteración hace poco más que expandir el nombre de la operación Por Ejemplo: la operación calcularcostoPapel() se expandiría de la siguiente forma: CalcularCostoPapel(peso, tamaño, color):numérico Esto significa que la operación CalcularCostoPapel() requiere los atributos peso, tamaño y color como entrada y devuelve un valor numérico como salida. Si el algoritmo requerido para implementar CalcularCostoPapel() es simple y se comprende ampliamente, tal vez sea innecesario elaborar diseño adicional

60 3. Conducción del diseño al nivel de componentesValida entrada de atributos Accesar BDPapel(peso) Regresa a costoPapelPorPagina CostoPapelPorPagina = CostoBasePorPágina CostoPapelPorPagina = CostoBasePorPagina * 1.2 Tamaño = B Tamaño = C CostoPapelPorPagina = CostobasePorPagina * 1.4 Tamaño = D CostoPapelPorpagina = CostoBasePorPagina * 1.6 El color es personalizado CostoPapelPorPagina = costoBasePorPágina * 1.14 El color es estandar Devuelve (CostoPapelPorPagina)

61 3. Conducción del diseño al nivel de componentesPaso 4: Describir fuentes de datos persistentes (bases de datos y archivos) e identificar las clases necesarias para manejarlas. Paso 5: Desarrollar y elaborar representaciones del comportamiento de una clase o un componente. Al comportamiento dinámico de un objeto lo afectan eventos externos y estado actual del objeto. Para comprender el comportamiento dinámico de un objeto, el diseñador debe examinar todos los casos de uso relevantes durante el periodo de vida de la clase diseño. Estos casos de uso proporcionan información que ayuda al diseñador a delinear los eventos que afectan al objeto y a los estados en que reside éste mientras pasa el tiempo y ocurren eventos.

62 3. Conducción del diseño al nivel de componentesPaso 5: Desarrollar y elaborar representaciones del comportamiento de una clase o un componente. La transición entre estados (impulsados por los eventos) se representa empleando un diagrama de estados de UML. El evento que gatilla la transición de un estado a otro toma la siguiente forma: Nombre-evento {lista parámetros} [condición de guardia] / expresión de acción. Nombre-evento: identifica el evento. Lista-parámetros: incorpora datos asociados con el evento. Condición-guardia: está escrita en lenguaje de restricción de objetos (OCL). Y especifica una condición que debe cumplirse antes de que pueda ocurrir el evento. Expresión de acción: define una acción antes de que ocurra cuando tenga lugar la transición.

63 3. Conducción del diseño al nivel de componentesComportamiento dentro del estado ConstuirDatosTrabajo EntradaDatosIncompletos Construir datos trabajo Entrar/leerDatosTrabajo() Salir/desplegarDatosTrabajo() Hacer/revisarCosistencia() Incluir/entradaDatos entradaDatosCompletada [todos los elementos de datos consistentes]/desplegarOpcionesUsuario Calcular Costo Trabajo Entrar/calcularTrabajo Salir/guardarcostoTotalTrabajo() costoTrabajoAceptado [el cliente está autorizado] / obetenerFirmaElectrónica Formar trabajo Entrar/ConstruirTrabajo() Salir/guardarNumeroOT() Hacer/ fechaEntregaAceptada [el cliente está autorizado] / estimadoTrabajoImpresión Remitir trabajo Entrar/remitirTrabajo() Salir/iniciarTrabajo() Hacer/colocar en ColaTrabajo trabajoRemitido [todas las autorizaciones adquiridas] / imprimirOrdenTrabajo

64 3. Conducción del diseño al nivel de componentesPaso 6: Elaborar diagramas de despliegue para proporcionar detalles de la implementación adicional. Se elaboran diagramas de despliegue para representar la ubicación de paquetes clave de componentes. Sin embargo, por lo general los componentes de representan individualmente dentro de un diagrama de componente. La razón de esto es evitar la complejidad del diagrama. Paso 7: Factorizar todas las representaciones del diseño al nivel de componentes y siempre deben considerarse alternativas El primer modelo a nivel de componente que se cree no será tan completo, consistente o exacto como la enésima iteración que aplique al modelo. Es esencial usar refactorización mientras se realiza el trabajo de diseño.

65 4. Lenguajes de restricción de ObjetosLa variedad de diagramas disponible como parte de UML proporciona a un diseñador un rico conjunto de formas de representación para el modelo de diseño. Sin embargo, las representaciones gráficas no suelen bastar. El diseñador necesita de un mecanismo para representar explicita y formalmente la información que restringe algún elemento del modelo de diseño. Es posible, describir las restricciones en lenguaje natural, pero este método lleva invariablemente a la inconsistencia y la ambigüedad, por lo que lo apropiado parece un lenguaje formal que tome en cuenta la teoría de conjunto y los lenguajes formales de especificación, pero que tenga una cantidad menor de sintaxis matemáticas que un lenguaje de programación.

66 4. Lenguajes de restricción de ObjetosEl lenguajes de restricción de Objetos (OCL) complementa al UML al permitir que un ingeniero de SW use gramática y sintaxis formales para construir instrucciones sin ambigüedades relacionadas con varios elementos del modelo de diseño. En OCL las instrucciones se construyen en 4 partes: Un contexto que define la situación limitada en que es válida la instrucción. Una propiedad que representan algunas características del contexto. Una operación que manipula o califica una propiedad Palabras clave (como if, then, else, and, or, not, implies) con que se especifican expresiones condicionales.

67 4. Lenguajes de restricción de ObjetosEjemplo: considere la condición de guardia colocada en el evento costoTrabajoAceptado que causa una transición entre los estados calcularCostoTrabajo() y formarTrabajo() dentro del diagrama de gráfica de estado para la clase TrabajoImprenta. En el diagrama, la condición guardia se expresa en lenguaje natural y especifica que la autorización sólo se presentará si el cliente está autorizado para aprobar el costo del trabajo. Cliente tiene.autoridadAutorización = “si” Donde un atributo booleano, autoridadAutorización, de la clase CLIENTE (una instancia específica de la clase) debe tener el valor si para satisfacer la condición guardia.

68 4. Lenguajes de restricción de ObjetosCuando se crea el modelo de diseño suele haber instancias en que deben satisfacerse las condiciones previas y posteriores antes de completar alguna opción especificada en el diseño. El OCL proporciona una herramienta poderosa para especificar condiciones previas y posteriores de manera formal.

69 4. Lenguajes de restricción de ObjetosCuando se crea el modelo de diseño suele haber instancias en que deben satisfacerse las condiciones previas y posteriores antes de completar alguna opción especificada en el diseño. El OCL proporciona una herramienta poderosa para especificar condiciones previas y posteriores de manera formal. Ej: al sistema de la imprenta, el cliente ahora proporciona un límite de costo superior para el trabajo de impresión y una fecha de entrega límite, al mismo tiempo que se especifican otras características de trabajo. Si el costo y la entrega estimada exceden esos límites, el trabajo no se entregará y debe notificarse al cliente.

70 Context TrabajoImprenta::validate(limiteSuperiorCosto : Integer, reqEnvioCliente : Integer)pre: LimiteSuperiorCosto > 0 and reqEnvioCliente > 0 and tiene.autorizacionTrabajo = “no” post: if tiene.costoTotalTrabajo <= limiteSuperiorCosto and tiene.fechaEnvio <= reqEnvioCliente then tiene.autorizacionTrabajo = “si” endif