Departamento de Informática Universidad Técnica Federico Santa María Diseño e Implementación...
-
Upload
carmelo-plaza-espejo -
Category
Documents
-
view
217 -
download
0
Transcript of Departamento de Informática Universidad Técnica Federico Santa María Diseño e Implementación...
Departamento de InformáticaDepartamento de InformáticaUniversidad Técnica Federico Santa MaríaUniversidad Técnica Federico Santa María
Diseño e ImplementaciónDiseño e Implementación
Diseño al nivel de componentes
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
1 ¿Qué es un componente?
1.1 Concepto Orientado a Objetos• Un componente contiene un conjunto de clases que
colaboran entre si.• Cada clase de un componente se ha elaborado
completamente para incluir todos los atributos y las operaciones relevantes para su implementación.
• Cómo parte de la elaboración del diseño también deben definirse todas las interfaces (mensajes) que permiten que las clases se comuniquen y colaboren con otras clases de diseño.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
1 ¿Qué es un componente?
1.1 Concepto Orientado a Objetos• Para lograrlo el diseñador empieza con el modelo de
análisis y elabora:– Clases de análisis (en el caso de componentes que se
relacionan con el dominio del problema)
– Clases de infraestructura (en el caso de componentes que proporcionan servicios de soporte para el dominio del problema).
• Ej: Desarrollo de SW para una imprenta sofisticada, cuyo objetivo general es recopilar las necesidades del cliente en el mostrador, cotizar un trabajo de impresión y pasarlo a una planta de producción automatizada.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
1 ¿Qué es un componente?
Trabajo Imprenta
Nº de páginasNº de ladosTipo PapelAmpliaciónCaracterísticas producción
Calcular costo trabajo()Imprimir y pasar trabajo()
Clase de análisis
Trabajo Imprenta
Componente de diseño
Iniciar trabajo
Calcular trabajo
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
Clase de diseño elaborado
Trabajo Imprenta
Nº de páginasNº de ladosTipo Papel Peso papel tamaño papel color papelAmpliaciónRequisitos ColorCaracterísticas producción Opciones distribución Opciones encuadernado portadas Almacén refine prioridad
Calcular costo página()Calcular costo trabajo()Imprimir y pasar trabajo()Calcular costo trabajo total()Revisar prioridad()Pasar trabajo a producción()
<<Interfaz>>Iniciar trabajo
ConstruirOrdenTrabajo()VerificarPrioridad()PasarTrabajoaProducción()
<<Interfaz>>calcular trabajo
CalcularCostoPagina()CalcularCostoPapel()CalcularCostoProd()CalcularCostoTrabajoTotal()
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
1 ¿Qué es un componente?
• 1.1 Concepto Orientado a Objetos– Deben especificarse las estructuras de datos
apropiadas para cada atributo.
– Se diseña el detalle algorítmico que se requiere para implementar la lógica de procesamiento asociada con cada operación.
– Se diseñan los mecanismos necesarios para implementar la interfaz (en OO esto abarca la descripción de todos los mensajes que se requieren para realizar la comunicación entre objetos dentro del sistema)
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
1 ¿Qué es un componente?
• 1.2 El concepto convencional– Un componente es un elemento funcional de un programa que
incorpora:• La lógica del procesamiento• Las estructuras internas de los datos necesarios para
implementar dicha lógica• Una interfaz que permita la invocación del componente y el paso
de los datos.
– El componente convencional, también denominado módulo, reside dentro de la arquitectura del SW y representa uno de tres papeles importantes1. Como componente de control, que coordina la invocación de
todos los demás componentes del dominio del problema.2. Como componente del dominio del problema que implementa
una función completa o parcial requerida por el cliente.3. Como componente de infraestructura responsable de funciones
que soportan el procesamiento requerido.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
1 ¿Qué es un componente?
• 1.2 El concepto convencional– Al igual que en OO, los componentes del SW
convencional se derivan del modelo de análisis.– Pero en este caso el elemento de datos orientado
al flujo sirve como base para la derivación.• Cada Transformación representada en los niveles
inferiores del DFD se correlaciona directamente con una jerarquía de módulos.
• Los componentes de control (módulos) residen cerca de la parte superior de la jerarquía (arquitectura) y los componentes de dominio de problema tienden a residir hacia la parte inferior de la jerarquía.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
1 ¿Qué es un componente?
• 1.2 El concepto convencional
Leer datos de Trabajo deImpresión
Sistema de Administración
De Trabajo
Seleccionar laFunción deManejo de
trabajo
DesarrollarCosto detrabajo
ConstruirOrden detrabajo
Enviar trabajoA producción
Calcular costoDe página
Calcular costo De papel
Calcular costoDe
producciónRevisar prioridad
Pasar trabajoA producción
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
1 ¿Qué es un componente?
• 1.2 El concepto convencional– Durante el diseño a nivel de componente, se
elabora cada módulo mostrado en la figura anterior.
• La interfaz de diseño se define de forma explicita, es decir, se representa cada objeto de datos o de control que fluye por la interfaz.
• El algoritmo que permite que el módulo realice su función está diseñado con el enfoque de refinamiento. El comportamiento del módulo suele representarse con un diagrama de estado.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
1 ¿Qué es un componente?
• 1.2 El concepto convencional– Ej: Considérese el módulo CalcularCostoPagina
• Su Objetivo es calcular el costo de impresión por página a partir de las especificaciones del cliente. Los datos necesarios para la realización de la función son:
» Nº de páginas en el documento» Nº total de documentos que se producirán» Impresión por una o ambas caras» Color o blanco y negro» Tamaño.
• Estos datos se pasan a CalcularCostoPagina mediante la interfaz del módulo.
• Este usa los datos y determina un costo por página que se basa en el tamaño y la complejidad del trabajo (Una función de todos los datos pasados al módulo con la interfaz).
• El costo por página es inversamente proporcional al tamaño del trabajo y directamente proporcional a su complejidad.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
Calcular costoDe página
AccesarBDcostos
ObtenerdatosTrabajos Componente del diseño
Costo Página
Entra: número de página Entra: Nº de documentos Entra: lados = 1, 2 Entra: color = 1, 2, 3, 4 Entra: Tamaño Página = A, B, C, D Entra: Costo de Página Entra: color = 1, 2, 3, 4 Sale: CBP Sale: CF
ObtenerDatosTrabajo(Nº de páginas,Nº de documentos, lados, color,Tamaño página, costo página)Accesar BD costos(Tamaño trabajo,Color, tamañoPagina, CBP, SF)Calcular Costo página()
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
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2. Diseño de componentes basado en Clases
• El nivel de componentes se basa en información desarrollada como parte del modelo de análisis y representada como parte del modelo arquitectónico.
• Al elegir el método de Ingeniería de SW basado en componentes, el diseño al nivel de estos se concentra en:– La elaboración de las clases de análisis (clases específicas
del dominio del problema)
– Y la afinación y definición de las clases de infraestructura.
• La descripción detallada de atributos, operaciones y las interfaces empleadas por estas clases representa el detalle de diseño requerido como precursor de la actividad de construcción.
Departamento de InformáticaDepartamento de InformáticaUniversidad Técnica Federico Santa MaríaUniversidad Técnica Federico Santa María
Principios Básicos del diseño de Principios Básicos del diseño de componentecomponente
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2. Diseño de componentes basado en Clases
• 2.1 Principios básicos de diseño– Hay 4 principios básicos de diseño aplicables al
diseño al nivel de componentes y se han adoptado ampliamente cuando se aplica Ingeniería de SW orientada a objetos.
– La idea central de estos principios es crear diseños que sean más sensibles al cambio y reducir la propagación de efectos secundarios cuando ocurren cambios.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2.1 Principios básicos de diseño
• El Principio Abierto-Cerrado (PAC)“El Módulo debe estar abierto para extensión, pero cerrado para
modificación”
• El diseñador debe especificar el componente de manera que permita extenderlo (dentro del dominio funcional que atiende) sin necesidad de modificaciones internas al propio componente (al nivel de código o lógica).
• Para esto el diseñador crea abstracciones que sirven como memoria intermedia entre la funcionalidad que tal vez habrá de extenderse y la propia clase de diseño.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
<html><script languaje="JavaScript">var n,m,h,p;do
n = parseInt(prompt("Ingrese unn número entero",1));while((n<1)||(n>3));if(n==1){
document.write(“Sensor de Puerta y ventanas”);}else{ if(n==2)
{ document.write(“Sensor humo”);}else{ if(n==3)
{ document.write(“Sensor de movimiento”);}else{ document.write("Esta opción no está implementada");}
}}</script></html>
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
Detector
SensorPuertas/Ventana
Sensor humoDetector deMovimiento
Sensor CalorSensor
CO2
<<Interfaz>>Sensor
Leer()
Habilitar()
Inhabilitar()
Probar()
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2. Diseño de componentes basado en Clases
• 2.2 Principios de sustitución de Liskov“”Debe tenerse la opción de sustituir las subclases con sus clases
principales”• Un componente que use la clase principal debe seguir
funcionando apropiadamente si, en cambio, se pasa al componente una clase derivada.
• Para lograr esto, este principio exige que cualquier clase derivada de una clase principal se apegue a cualquier contrato implícito entre la clase principal y los componentes que la usan.
• En este contexto un contrato es una condición previa que deber ser verdad cuando el componente usa una clase principal y una condición posterior que debe ser cierta después que el componente usa la clase principal.
• Cuando un diseñador crea clases derivadas, estas también deben ajustarse a la condiciones previas y posteriores
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2. Diseño de componentes basado en Clases
• 2.3 Principio de inversión en independencia (PID)“Dependa de las abstracciones, no de las concreciones”
• acuerdo al principio del PAC, las abstracciones son el lugar donde el diseño se puede extender sin grandes complicaciones.
• Cuanto más dependa un componente de otros componentes concretos (en lugar de abstractos, como la interfaz) más difícil será extenderlos.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2. Diseño de componentes basado en Clases
• 2.4 Principio de segregación de la interfaz (PSI)“Es mejor tener muchas interfaces especificas del cliente que una
interfaz de propósito general”
• Cuando varios componentes de cliente usan las operaciones proporcionadas por una clase servidor.
• El PSI sugiere que el diseñador debe crear una interfaz especializada para servir a cada categoría especial de cliente.
• Sólo las operaciones importantes para una categoría especial de clientes deben especificarse en la interfaz para esos clientes.
• Si varios clientes necesitan las mismas operaciones, deben especificarse en cada una de las interfaces especializadas.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2. Diseño de componentes basado en Clases
• 2.4 Principio de segregación de la interfaz (PSI)
• Ejemplo: Clase PlanoCasa que se usa para funciones de seguridad y vigilancia– Funciones Seguridad: ColocarDispositivo(),
mostrarDispositiuvo(), agruparDispositivo(), y eliminarDispositivo()
– Funciones de Vigilancia: Estas además requieren de operaciones especiales para las cámaras: mostrarPV() y mostrarIDDispositivo().
Departamento de InformáticaDepartamento de InformáticaUniversidad Técnica Federico Santa MaríaUniversidad Técnica Federico Santa María
Principios de EmpaquetamientoPrincipios de Empaquetamiento
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2. Diseño de componentes basado en Clases
• En muchos casos los componentes o las clases individuales se organizan en subsistemas o paquetes, no existen en el vacío.– ¿Cómo se debe presentar esta actividad de
empaquetamiento?
– ¿Cómo deben organizarse los componentes a medida que avanza el diseño?
• Para esto se sugieren principios adicionales de empaquetamiento que son aplicables al diseño a nivel de componentes
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2. Diseño de componentes basado en Clases
• Principio de equivalencia ente reutilización y versión (PER)
“La esencia de la reutilización es la misma que de la versión”• Cuando las clases o componentes se diseñan
para reutilizarlos, hay un contrato explícito entre el desarrollador de la entidad reutilizable y la persona que lo usará.
• Lo aconsejable es agrupar las clases reutilizables en paquetes que se pueden manejar y controlar a medida que evolucionan nuevas versiones.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2. Diseño de componentes basado en Clases
• Principio del cierre común (PCC)“Las clases que cambian juntas deben permanecer juntas”
• Las clases deben empaquetarse de manera que sean un todo coherente, es decir, cuando las clases se empaquetan como parte de un diseño, deben atender la misma área de funciones o comportamiento.
• Esto lleva a un control de cambio y a un manejo de versiones más efectivo
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2. Diseño de componentes basado en Clases
• Principio común de la reutilización (PCR)“Las clases que no se reutilizan juntas no deben agruparse juntas”
• Cuando una o más clases cambian en un paquete, también cambia el número de versión del paquete.
• Todas las demás clases o paquetes que dependen de ese paquete deben actualizarse ahora a la versión más reciente del paquete y probarse para asegurar que la nueva versión funciona sin incidentes.
• Si no hubo cohesión al agrupar las clases, es posible que cambie una clase que no tenga relación con las demás.
• Esto requerirá un proceso innecesario de integración y de prueba. Por esto, sólo deben incluirse en un mismo paquete las clases que se reutilizarán juntas.
Departamento de InformáticaDepartamento de InformáticaUniversidad Técnica Federico Santa MaríaUniversidad Técnica Federico Santa María
Líneas generales de diseñoLíneas generales de diseño
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2.2 Líneas generales de diseño al nivel de componentes
• Componentes: Deben definirse convenciones de asignación de nombres para componentes especificados como parte del modelo arquitectónico, y luego refinarse y elaborarse como parte del diseño al nivel de componentes.
• Los nombres del modelo arquitectónico deben extraerse del dominio del problema y tener algún significado para los participantes que ven el modelo arquitectónico
• Ej: la clase PlanoCasa al nivel arquitectónico
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2.2 Líneas generales de diseño al nivel de componentes
• Interfaces: Las interfaces proporcionan información importante acerca de la comunicación y la colaboración (además de ayudar a lograr el PAC).
• Sin embargo, una representación libre de las interfaces tiende a complicar los diagramas del componente.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
2.2 Líneas generales de diseño al nivel de componentes
• Dependencias y Herencias:
• Para mejorar la legibilidad es buena idea modelar las dependencias de izquierda a derecha y la herencia de abajo (clases derivadas) hacia arriba (clases principales).
• Además las interdependencias entre los componentes deben representarse mediante interfaces, en lugar de hacerlo mediante la representación de una dependencia de componente a componente. Siguiendo la filosofía del PAC.
• Esto ayuda a mejorar las opciones de mantenimiento del sistema
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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.
Departamento de InformáticaDepartamento de InformáticaUniversidad Técnica Federico Santa MaríaUniversidad Técnica Federico Santa María
Conducción del Diseño a nivel de Conducción del Diseño a nivel de componentescomponentes
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• El diseño al nivel de componente es de naturaleza elaborativa.
• El diseñador debe transformar la información del análisis y los modelos arquitectónicos en una representación de diseño que proporcione suficiente detalle para guiar la actividad de construcción (codificación y prueba).
• Los siguientes pasos representan un conjunto de tareas típicas para el diseño al nivel de componentes, al aplicar el sistema orientado a objetos:
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• Paso 1: Identificar todas las clases de diseño que corresponden al dominio del problema.
• Paso 2: Identificar todas las clases de diseño que corresponden al dominio de la infraestructura.– Estas clases no se describen en el modelo del análisis y a
menudo faltan en el modelo arquitectónico, pero deben describirse acá.
• Paso 3: Elaborar todas las clases de diseño que no se adquieran como componentes reutilizables.– La elaboración requiere que se describan de manera
detallada todas las interfases, los atributos y las operaciones necesarias para implementar la clase. Al realizar esta tarea debe tomarse en cuenta el diseño de la heurística (Por ej: la cohesión y el acoplamiento de componentes)
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• 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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• Paso 3a: TrabajoProducción
ColaTrabajoOrdenTrabajo
1: ConstruirTrabajo (númeroOT) 2: RemitirTrabajo (númeroOT)
[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
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• 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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
Trabajo Imprenta
Nº de páginasNº de ladosTipo Papel Peso papel tamaño papel color papelAmpliaciónRequisitos ColorCaracterísticas producción Opciones distribución Opciones encuadernado portadas Almacén refine prioridad
Calcular costo página()Calcular costo trabajo()Imprimir y pasar trabajo()Calcular costo trabajo total()Revisar prioridad()Pasar trabajo a producción()
<<Interfaz>>Iniciar trabajo
ConstruirOrdenTrabajo()VerificarPrioridad()PasarTrabajoaProducción()
<<Interfaz>>calcular costo trabajo
CalcularCostoPagina()CalcularCostoPapel()CalcularCostoProd()CalcularCostoTrabajoTotal()
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
Imprimirtrabajo
Trabajo Producción
OrdenTrabajo
Atributos apropiados
ConstruirOrdenTrabajo()
ColaTrabajo
Atributos apropiados
revisarPrioridad()
<<Interfaz>>Iniciar Trabajo
pasarTrabajoaProduccion()
CalcularTrabajo
InicarTrabajo
ConstruirTrabajo
RemitirTrabajo
ObtenerDescripciónTrabajo
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• 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 atributotipo-Expresión: es el tipo de datosvalor-inicial: Valor que toma el objeto cuando es creado{propiedad cadena}: define una propiedad o característica del atributo
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• 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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• 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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• 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
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
Valida entrada de atributos
Accesar BDPapel(peso)
CostoPapelPorPagina = CostoBasePorPágina
CostoPapelPorPagina =CostoBasePorPagina * 1.2
CostoPapelPorPagina = CostobasePorPagina * 1.4
CostoPapelPorpagina =CostoBasePorPagina * 1.6
CostoPapelPorPagina =costoBasePorPágina * 1.14
Devuelve(CostoPapelPorPagina)
Regresa a costoPapelPorPagina
Tamaño = B
Tamaño = C
Tamaño = D
El color espersonalizado
El color es estandar
3. Conducción del diseño al nivel de componentes
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• 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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• 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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
Construir datos trabajoEntrar/leerDatosTrabajo()
Salir/desplegarDatosTrabajo()Hacer/revisarCosistencia()
Incluir/entradaDatos
Calcular Costo TrabajoEntrar/calcularTrabajo
Salir/guardarcostoTotalTrabajo()
Formar trabajoEntrar/ConstruirTrabajo()Salir/guardarNumeroOT()
Hacer/
Remitir trabajoEntrar/remitirTrabajo()Salir/iniciarTrabajo()
Hacer/colocar en ColaTrabajo
EntradaDatosIncompletos
entradaDatosCompletada [todos los elementos de datos consistentes]/desplegarOpcionesUsuario
costoTrabajoAceptado [el cliente está autorizado] / obetenerFirmaElectrónica
fechaEntregaAceptada [el cliente está autorizado] / estimadoTrabajoImpresión
trabajoRemitido [todas las autorizaciones adquiridas] / imprimirOrdenTrabajo
Comportamiento dentro del estado ConstuirDatosTrabajo
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
3. Conducción del diseño al nivel de componentes
• 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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
4. Lenguajes de restricción de Objetos
• 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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
• 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:1. Un contexto que define la situación limitada en que es
válida la instrucción.
2. Una propiedad que representan algunas características del contexto.
3. Una operación que manipula o califica una propiedad
4. Palabras clave (como if, then, else, and, or, not, implies) con que se especifican expresiones condicionales.
4. Lenguajes de restricción de Objetos
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
• 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.
Clientetiene.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.
4. Lenguajes de restricción de Objetos
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
• 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.
4. Lenguajes de restricción de Objetos
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
4. Lenguajes de restricción de Objetos
• 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.
Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas
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