6.6 DISEÑO. [Proceso]

Transcripción

1 6.6 DISEÑO. [Proceso] Durante un Ciclo de Desarrollo iterativo es posible pasar a la Fase de Diseño una vez completada la documentación de la fase de Análisis. Durante esta etapa se desarrolla una solución lógica basada en el paradigma orientado a objetos. La parte central de esta solución se basa en la cr4eación de Diagramas de Interacción. Estos diagramas muestran la forma en que los objetos se comunican y de esta forma cumplen con los requerimientos establecidos. Una vez terminados los Diagramas de Interacción propuestas para el ciclo de desarrollo actual, se procede al diseño de los Diagramas de Clases, los cuales contienen las clases (interfaces) que serán implementadas mediante software Describiendo Casos de Uso Reales. Los casos de uso reales presentan un diseño concreto, la forma en que un Caso de Uso deberá ser realizado. La definición de Casos de Uso Reales es la primera actividad a realizar durante la fase de diseño en el ciclo de desarrollo actual. La creación de los Casos de Uso Reales esta basada en la definición previa de los Casos de Uso esenciales relacionados. Casos de Uso: Expandido y Esencial Casos de Uso: Real Caso de Uso Interacción Modelo Conceptual Glosario Clases Diagrama Secuencia Sistema Contratos de del Arquitectura de Paquetes Diagrama Estado de Base de Datos Figura # 8, Dependencias, Fase de Diseño. Creación de Caso de Uso Reales Un Caso de Uso Real describe el diseño real del caso de uso en términos de entradas y salidas concretas pensando en la tecnología disponible para su implementación.. En ocasiones a manera de ejemplificar pueden ser involucradas interfaces graficas a manera de prototipos, no es 62

2 necesario implementarlas, sin embargo son una alternativa para presentar detalles de la implementación, durante el diseño. A continuación se muestra el Caso de Uso de la Facturación Versión, en donde se ha agregado algunas textos para clarificar detalles del curso de eventos. NOMBRE: Facturación Versión. Caso de Uso: Facturación Versión. Actores: Propósito: Tipo: Descripción: Referencias Cruzadas: Cliente (iniciador), Vendedor. Generar un documento con los datos del cliente, datos y precio de los productos y el total de la venta. Llamado Factura. Primario y esencial. El Vendedor introduce la clave del producto, el número de productos, la clave del cliente. se calcula el subtotal por producto y el total de la venta. R3, R4, R5, R6, R7 Curso de Eventos: Facturación Versión. No Acción del Actor No Respuesta del Sistema. Este caso de uso inicia cuando el Cliente llega a la terminal de Punto de Venta con los productos que desea adquirir. 2. Para cada artículo el vendedor introduce la clave del producto. 3. Busca en el archivo la clave del artículo y muestra su descripción y precio de lista. Se agrega a la lista de productos adquiridos. 5. Se calcula y muestra el total del importe por cada artículo. 7. Se calcula y despliega el total de la venta. 4. El vendedor teclea el número de artículos solicitados por el Cliente. 6. Una vez terminada la captura de todos los artículos. el vendedor indica fin de la venta. 8. El Vendedor introduce el número de cliente. 0. El Vendedor pide la confirmación de los datos al Cliente. El Vendedor manda a imprimir la Factura 2. Se imprime la Factura. 9. Busca en el archivo y despliega los datos del cliente. 63

3 6.6.2 Diseño de diagramas de interacción. Durante la etapa del diseño hay dos pasos importantes a dar: la asignación de responsabilidades y la creación de diagramas de interacción. Los Diagramas de Interacción ilustran la manera de cómo los objetos interactúan vía mensajes para llevar a cabo un tarea especifica. La creación de Diagramas de Interacción ocurre dentro de la fase de diseño durante el ciclo de desarrollo en cuestión. Su creación depende de haber trabajado previamente en los artifacs mostrados en la Figura # 9. Casos de Uso: Expandido y Esencial Casos de Uso: Real Caso de Uso Modelo Conceptual Glosario Interacción Clases Diagrama Secuencia Sistema Contratos de del Arquitectura de Paquetes Diagrama Estado de Base de Datos Figura 9, Dependencias Fase de Diseño. Creación de Interacción. Uno de los problemas mas comunes en la creación de proyectos utilizando la tecnología de objetos es valorar la creación de los diagramas de interacción, al cuidar el asignar responsabilidades y hacer que cada una de ellas y todas en conjunto cumplan con los requerimientos establecidos. Por lo que el asignar responsabilidades y diseñar objetos colaborativos es muy importante, entonces, una porcentaje considerable del trabajo en el proyecto deberá aplicarse a la fase del diseño de diagramas de interacción Responsabilidades y métodos. La Responsabilidad se define como un contrato u obligación de un tipo o clase. Las responsabilidades están relacionadas a las obligaciones de un objeto en términos de su comportamiento, siendo básicamente de 2 tipos: 64

4 . Responsabilidad de conocer. 2. Responsabilidad de hacer. La responsabilidad de conocimiento de un objeto incluye: Conocimiento acerca de encapsulamiento de datos privados. Conocimiento acerca de objetos relacionados. Conocimiento de cosas que puede dirigir o calcular. La responsabilidad de hacer de un objeto incluye: Hacer alguna cosa por él mismo. Inicializar acciones sobre otros objetos. Las responsabilidades se asignan a objetos durante la fase de diseño. Las responsabilidades relacionadas con el conocimiento son frecuentemente identificadas desde el modelo conceptual ya que en él se muestran atributos y asociaciones. La translación de responsabilidades en clases y métodos se ve influenciada por la granularidad de la responsabilidad. Una responsabilidad no es lo mismo que un método, los métodos son implementados para cumplir responsabilidades. Las responsabilidades se implementan usando métodos, los que actuan tanto sobre otros métodos como sobre objetos. La manera de implementar las responsabilidades (implementadas como métodos) es mediante la creación de los interacción, los cuales muestra las interacciones de los mensajes entre instancias (y clases) en el Modelo de Clase. El punto de partida para estas interacciones son las descripciones de las Post-condiciones de los contratos. El UML define dos conjuntos de diagramas de interacción, donde cualquiera de los dos expresan los mismos conceptos en cuanto a la interacción de los mensajes: Diagramas de Secuencia. Ilustran la interacción entre objetos, en una secuencia de tiempo, expresada en el eje vertical. Diagramas de Colaboración. Ilustran la interacción entre objetos, utilizando un formato de grafo o de red Patrones. En la tecnología e objetos, un Patrón es la descripción de un problema y su solución, la cual puede ser aplicada a un nuevo contexto. Existen patrones que brindan lineamientos de cómo asignar las responsabilidades a objetos en el contexto de categorías especificas de problemas Patrones: Principios Generales de Asignación de Responsabilidades (del inglés GRASP). Existen 5 categorías de patrones GRASP. Experto. Creador. Bajo acoplamiento. Alta Cohesión. Controlador. 65

5 PATRÓN: Experto. Asigna una responsabilidad al experto de la información --- La clase Solución: que tiene la información necesaria para cumplir con la responsabilidad Problema: Cuál es el principio básico por el cual las responsabilidades son asignadas en el Diseño Orientado. Un Modelo de Clase puede definir docenas de cientos de clases de software y una aplicación puede requerir cientos de miles de responsabilidades a ser cumplidas. Durante el Diseño Orientado a Objetos, cuando la interacción entre objetos es definida, ya se deben haber asignado las responsabilidades a las clases. Un sistema bien hecho, tiende a ser fácil de entender, mantener y extender, y existe la oportunidad del rehúso de los componentes en futuras aplicaciones. Discusión: Este patrón es el mas usado en la asignación de responsabilidades, el objeto hace cosas relacionadas con la información que tiene. También se pueden manejar Expertos parciales cuando se requiere información contenida en otras clases y objetos. Beneficios: Se mantiene el encapsulamiento, ya que los objetos utilizan su propia información. El comportamiento del sistema es distribuido a través de clases que cuentan con la información requerida PATRON: Creador Solución Asignar a la clase B la responsabilidad de crear una instancia de la clase A, si se cumple cualquiera de los siguientes puntos: B es una agregación del objeto A B contiene objetos del tipo A B actualiza instancias de objetos A B usa estrechamente objetos A B inicializa datos que van a ser pasados a A cuando es creado (entonces, B es un Experto con respecto a la creación de A). B es creador de A Si aplica mas de una opción, entonces, B deberá contener a, A. Problema: Quien deberá tener la responsabilidad para la creación de una instancia de alguna clase. La creación de objetos es una de las actividades mas comunes en un sistema orientado a objetos, consecuentemente es útil contar con principios para asignar responsabilidades de creación de instancias. Haciendo una buena asignación, el diseño tendrá bajo acoplamiento, incrementando la claridad, encapsulamiento y rehusabilidad. Discusión: Los lineamientos de creación asignan responsabilidades relacionadas con la creación de objetos, una actividad muy común en los sistemas orientados a objetos Agregación agrega parte, Contenedor contiene contenido, Actualizador actualiza graba. La actualización de información es una relación muy común entre clases en un diagrama de clases Beneficios: Bajo acoplamiento, implica menor dependencia en el mantenimiento y alta oportunidad de rehúso. 66

6 PATRON: Bajo Acoplamiento Solución Asigna responsabilidades, de tal forma que el acoplamiento permanezca bajo Problema: Cómo soportar baja dependencia e incrementar el rehúso. Una clase con alto acoplamiento, hace referencia a muchas otras clases, tales clases son indeseables, ocasionando los siguientes problemas: Cambios en las clases relacionadas propician cambios locales. Difíciles de entender para aislarlas. Difíciles de rehusar ya que su uso requiere la presencia adicional de las clases de las que depende. discusión: El bajo acoplamiento es un principio que se debe cuidar durante las decisiones de diseño, es un lineamiento que se debe considerar continuamente. Es un patrón de evaluación, aplicado por cualquier diseñador al avaluar cualquier decisión de diseño. En los lenguajes orientados a objetos una forma común de acoplamiento desde un Tipo_X a un Tipo_Y incluye: Tipo_X tiene un atributo (dato miembro o variable de instancia) que hace referencia a una instancia del Tipo_Y o al Tipo_Y en sí mismo. Tipo_X tiene un método él cual hace referencia a una instancia del Tipo_Y o Tipo_Y en sí mismo, por cualquier medio. Esto incluye a un parámetro o variable local del Tipo_Y o el objeto regresado desde un mensaje referenciando una instancia del Tipo_Y. Tipo_X es directa o indirectamente una subclase del tipo_y. Tipo_Y es una interfase, y Tipo_X implementa la interfase. El bajo acoplamiento soporta el diseño de clases que son mas independientes, lo que redice el impacto de cambios y propicia el rehúso, dando la oportunidad de una productividad mayor. El bajo acoplamiento puede no ser importante si no se piensa en la reutilización Una subclase esta fuertemente acoplada a su superclase. La decisión de derivar de una superclase deberá ser cuidadosamente considerada desde este punto de vista. Beneficios: No hay afectación por cambios en otros componentes. Simple para entender el aislamiento. Conveniente para rehúso. 67

7 PATRON: Alta Cohesión. Solución Asignar responsabilidades manteniendo alta cohesión. Problema: Cómo mantener la complejidad manejable. En términos de diseño orientado a objetos, la cohesión (o de manera mas específica, la cohesión funcional) es una medida de que tanto se ha enfocado la responsabilidad en una clase, así, una clase con una responsabilidad alta, y que no realiza un trajo abrumador, tiene una alta cohesión. Una clase con una baja cohesión hace muchas cosas irrelevantes o realiza mucho trabajo, tales clases son indeseables, ellas tienen los siguientes problemas: Difíciles de comprender. Difíciles de usar. Difíciles de mantener. Clases con baja cohesión representan un alto grado de abstracción o tienen responsabilidades que deberán ser delegadas a otras clases. discusión: Tanto el Bajo acoplamiento como la alta cohesión deberán ser principios que se deben tomar en cuenta en las decisiones de diseño, son lineamientos que se deben siempre considerar. Es un patrón de evaluación que el diseñador aplica mientras toma decisiones de diseño. Muy baja cohesión. Una clase es la responsable de muchas cosas en diferentes áreas de funcionalidad. Baja Cohesión. Una clase es la responsable de realizar un trabajo complejo en un área de funcionalidad. Alta Cohesión. Una clase tiene moderadas responsabilidades en un área funcional y colabora con otras clases para llevar a cabo otros trabajos. Moderada Cohesión. Una clase tiene moderada responsabilidad en varias áreas diferentes que están lógicamente relacionadas al concepto de la clase, pero no a otras. Beneficios: Se mejora la claridad y la compresión del diseño. Se simplifica el mantenimiento. Soporta con frecuencia también bajo acoplamiento. Una ganancia adicional con la relativamente alta funcionalidad agregada se incrementa el rehúso, ya que una clase con alta cohesión se puede usar para propósitos muy específicos. 68

8 PATRON: Controlador Solución Asignar la responsabilidad del manejo de los mensajes de eventos a una clase que represente: El sistema. El negocio o la organización. Alguna cosa del mundo real que es activo. Un manejador artificial de todos los eventos del sistema, de un caso de uso. Usar la misma clase controlador para todos los eventos del sistema en el mismo caso de uso. Problema: Quién deberá asumir la responsabilidad de manejar los eventos del sistema. Un evento del sistema es un evento del sistema de alto nivel generado por un actor externo; es un evento externo de entrada, son asociados con operaciones del sistema --- operaciones del sistema en respuesta a eventos del sistema Un Controlador no es un objeto de interfase de usuario responsable del manejo de los eventos del sistema. Un Controlador define los métodos para la operación del sistema. discusión: La mayoría de los sistemas reciben eventos externos, como la IU, de censores de señal, etc. Un defecto común en el diseño de controladores es asignarles muchas responsabilidades. Normalmente un controlador deberá delegar a otros objetos el trabajo que necesita realizar mientras coordina las actividades Beneficios: Incrementa el potencial para componentes reutilizables. Asegura que los procesos son manejados por objetos de la capa de dominio, no por objetos del de la capa de interfase.. La responsabilidad de un controlador técnicamente deberá ser manejada por un objeto de interfase, pero la implementación de tal diseño es que el código y lógica del programa se manejen como procesos del dominio. Conocimiento del estado del caso de uso. Ayuda a que las operaciones ocurran en una secuencia lógica o que se identifique el estado actual del caso de uso Responsabilidades y cartas CRC. Un dispositivo que puede ayudar a asignar responsabilidades e indicar colaboraciones con otros objetos son las Cartas CRC (Cartas de: Clase Responsabilidad Colaboración), éstas fueron diseñadas por Kent Beck y Ward Cunningham. Las cartas CRC son cartas de índice, una para cada clase, sobre las cuales se escriben brevemente las responsabilidades e cada clase y una lista de los objetos que colaboran para cumplir con la tarea asignada. Normalmente se analiza el rol jugado por cada clase o por un conjunto pequeño de clases. La asignación de responsabilidades y el desarrollo de los Diagramas de interacción es la etapa de creación mas significativa durante la etapa de diseño. 69

9 6.6.5 Como hacer un diagrama de interacción. Crear un diagrama por separado para cada operación del sistema que se encuentra en el ciclo de desarrollo actual. Para cada operación del sistema, haga un diagrama, utilizando el nombre de la operación como el mensaje de inicio. 2. Si el diagrama es demasiado complejo dividirlo en pequeños diagramas. 3. Usar del contrato: la sección de responsabilidades, post-condiciones y la descripción del caso de uso como un punto de inicio, diseñe un sistema de objetos que interactúen que cumplan con el trabajo encomendado Diagramas de iteración del Caso de Uso Facturación Versión [Caso de Estudio] Tomando como base el Secuencia del Sistema, y las operaciones encontradas, se deberán construir los siguientes diagramas de iteración:. Entra artículo. 2. Fin de venta. 3. Entra Cliente. Para cada evento del sistema crear un diagrama de interacción donde el mensaje de inicia sea el mensaje del evento del sistema. Usando las secciones de responsabilidades y post-condiciones de los contratos y los casos de uso como punto de partida, diseñar un sistema de objetos que interactúan para llevar a cabo una tarea.. Contrato: Entra Artículo. CONTRATO: entra_articulo() Nombre entra_artículo(numero : entero, cantidad : entero) Responsabilidad Tipo Referencia cruzada Notas Excepciones Salida Registrar la compra de un articulo, añadirlo a la venta total, desplegar precio de lista y su descripción. Cuando se introduce la cantidad de artículos despliega el precio total por artículo. Sistema. R4, R5, R6 Accesa el Catalogo de Productos. Envía un error si no existe el artículo. Muestra la descripción del artículo, su precio de lista y el importe total por artículo. 70

10 Pre-condición Es necesario conocer la clave del producto y la cantidad de productos solicitada por el Cliente. Post-condición Al introducir el primer artículo, se crea una nueva instancia de Venta. Se crea una asociación con el producto. Al introducir la cantidad de productos, se modifica el atributo Venta.cantidad. Definiendo un controlador. De acuerdo a los patrones es necesario definir el controlador. una opción es la Terminal de Punto de Venta TPV. No es un objeto del dominio, va a ser un objeto en el dominio del software. Puede representar el Sistema del Vivero. : entra_articulo(numero, cantidad) : TPV : Vendedor Figura # 20, Definir Controlador Si se considera el principio de separación Modelo Vista, no es responsabilidad de los objetos del dominio comunicarse con el usuario, por lo tanto, los procesos que indiquen una visualización de datos deberán ser ignorados. Lo que se requiere con respecto a la responsabilidad de mostrar información es que el dato sea conocido. Registrar una nueva venta. Al iniciar una nueva venta se debe crear una nueva instancia de Factura. Posteriormente se debe crear la asociación correspondiente. Analizando el Modelo conceptual y reflexionando sobre los objetos del dominio, TPV es el candidato para crear una nueva instancia de Factura. Analizando el modelo conceptual, es necesario también crear una colección de instancias (instancias de Venta) que mantengan información de la cantidad adquirida de cada producto. De esta forma TPV crea una instancia de factura y la factura crea una colección vacía de instancias de Venta. Creando una nueva instancia para Venta. Se creo una instancia de Venta. (creación de instancia) La venta se asoció con la Factura. (formación de asociación) Se modifica la cantidad. (modificación de atributo) 7

11 : entra_articulo(numero, cantidad) : TPV 2: crea() : Factura : Vendedor 3: crea_coleccion() Figura #2, Crear instancia de Factura y colección vacía de Venta : Venta Encontrando la especificación del producto. La instancia de Venta debe ser asociada con la Especificación del producto, él cual debe tener el número de la clave del producto, lo cual es necesario para obtener una Especificación de Producto. Es necesario primero pensar en quien es responsable de conocer la Especificación del producto en base a su número de clave. Usando el patrón Experto dice; que quien posea la información deberá ser el indicado de cumplir la responsabilidad. Analizando el Modelo Conceptual se ve que el indicado es el Catalogo de Productos, por lo que este concepto es un buen candidato para cumplir con la responsabilidad. Visibilidad hacia el Catalogo de Productos. Quién deberá enviar el mensaje de especificación a el Catalogo de Productos para preguntar por la Especificación del Producto?. Si se asume que las instancias de TPV y el Catalogo de Productos fueron creados durante el inicio del Caso de uso y que la conexión entre ellos es permanente y suponiendo que es posible para el TPV enviar el mensaje de especificación al Catalogo de Productos. Esto implica otro concepto en el Diseño Orientado : visibilidad. La Visibilidad es la habilidad de un objeto para ver o tener una referencia de otro objeto. Para que un objeto envie un mensaje a otro objeto debe teber visibilidad de él. Colaboración de entra artículo. Es necesario hacer una serie de reflexiones basadas en los patrones GRASP para conseguir el diseño del diagrama; El diseño de objetos que interactúan y la asignación de responsabilidades, requieren considerable tiempo de deliberación. Mensajes a multiobjetos. El mensaje busca() deberá localizar en la Especificación del Producto, aquel que coincida en el numero de producto. El mensaje crea() va a crear la colección vacía. El mensaje crea(cantidad) crea una instancia de Venta. El mensaje suma() agrega un elemento Venta a la colección. 72

12 : entra_articulo(numero, cantidad) 2: crea() : TPV : Factura : Vendedor 4: prod = especifica(numero) 6: suma_art( prod, cantidad) 3: crea_coleccion() : Cat_producto 7: crea(prod, cantidad) 5: prod = busca(numero) : Esp_Producto 8: suma(vi) : Venta Figura # 22, Colaboración, entra_articulo CONTRATO: Fin de Venta. Este contrato ocurre cuando el Vendedor selecciona fin de venta. CONTRATO: fin_venta() Nombre fin_venta( ) Responsabilidades Tipo Referencias cruzadas Notas Excepciones Salida Pre-condiciones Termina el proceso de captura de artículos, calcula el importe total de la venta. Sistema R7 Se muestra el importe total de la Venta. Post-condiciones! Se actualiza su numero (el cual es consecutivo.! Se actualiza la fecha con la del sistema.! Se almacena el importe total de la factura. 73

13 Seleccionando el Controlador. De acuerdo al patrón GRASP, y al contrato anterior, se selecciona como controlador el concepto TPV. Indicación de Fin de Venta. Se agrega un atributo escompletada, él cual toma el valor de True. Quién será responsable de modificar el atributo escompletada a true?. De acuerdo al patrón Experto, la misma clase Factura, deberá modificar dicho atributo, por lo tanto TPV enviará el mensaje completado(), a la clase Factura para que ésta lo ponga a true De igual forma la clase Factura deberá actualizar la fecha, tomando ésta del sistema y el consecutivo leído de la Factura anterior. Calculo del Total de la Factura. Responsabilidad. El calculo del total de la factura deberá ser responsabilidad de la clase que conoce la información Calculo. o La Venta Total es la suma de los subtotales de la suma de cada artículo. o El subtotal es igual a la cantidad * el precio de cada artículo. El atributo Total es de Factura, por lo tanto esta clase deberá ser la responsable del calculo del total. o o Cada subtotal deberá obtenerlo de la clase Venta y de la Clase Especificación del Producto (Esp_Producto) Deberá ir acumulando cada subtotal de cada instancia Venta hasta terminar todas las instancias almacenadas en la colección. El diagrama de colaboración completo quedará como sigue: : fin_venta() 2: escompletada() : TPV : Factura 4: total() : Vendedor 3: subtotal() : Esp_Producto : Venta 5: pr = lprecio(numero) Figura # 23, Contrato, fin_venta 74

14 Mostrado de Información. Durante la creación de los Diagramas de Colaboración, no se debe tomar en cuenta el mostrar información en pantalla, solo se debe de poner disponible la información. NOTA: No necesariamente se debe iniciar el Colaboración con el mensaje nombre del contrato, si el diseñador decide iniciar con otro mensaje, es libre de hacerlo. CONTRATO: entra_cliente CONTRATO: entra_cliente Nombre Responsabilidades Tipo Referencias cruzadas Notas Excepciones Salida Pre-condiciones Post-condiciones entra_cliente(numero) Accesar los datos del cliente para incluirlos en la Factura. Sistema R3 Accesa el Catalogo de Clientes. Envía un error si no existe el Cliente. Muestra los datos del Cliente. Se imprime la factura. Es necesario conocer la clave del cliente. De acuerdo al patrón GRASP, y al contrato anterior, se selecciona como controlador la Factura. : entra_cliente(numero) : Factura : Vendedor 2: Especifica(numero) : Esp_Cliente : Cat_Cliente 3: cte = busca(numero) Figura # 24, Contrato, entra_cliente 75

15 La clase que conoce a todos los clientes es la clase Catalogo de Clientes (Cat_cliente), va a buscar utilizando el número de cliente, los datos del cliente para agregarlos a la factura y ponerlos a disposición para poderlos mostrar Determinando Visibilidad. [Proceso] Como se mencionó anteriormente, la visibilidad es la habilidad que tiene un objeto de ver o tener referencia a otro objeto. Por lo tanto si un objeto emisor envía un mensaje a un objeto receptor, el emisor debe ser visible al receptor y el emisor debe tener algún tipo de referencia al receptor. Existen 4 tipos de visibilidad: Visibilidad como atributo o asociación. C es un atributo de B Visibilidad como Parámetro: C es un parámetro de un método de B Visibilidad declarada localmente: C es declarado como un objeto local en un método de B Visibilidad global: C es de alguna forma globalmente visible. Estos tipos son considerados cuando: un objeto de B envía un mensaje a un objeto C, C debe ser visible a B. Cuando se termino de desarrollar los diagramas de colaboración, se analiza el tipo de visibilidad que tendrá cada mensaje y una vez que se ha sido definido, el siguiente paso es el desarrollo del diagrama de clases. 6.7 Diseñando Diagramas de clase. [Proceso] El diagrama de clases se construye cuando han sido desarrollados los diagramas de interacción (aunque se pueden hacer paralelamente) y por supuesto con la ayuda del modelo conceptual. Las actividades y dependencias para la creación del Clases se muestran en la Figura # Diseñando Diagramas de Clases Un clases ilustra las especificaciones para las clases de software e interfases, esta información se incluye como sigue: Clases, asociaciones y atributos. Interfases, con sus operaciones y constantes. Métodos. atributos. navegabilidad. Dependencias. En contraste con el modelo conceptual, un diseño de un diagrama de clases presenta definiciones para entidades de software en lugar de conceptos del mundo real En el modelo conceptual, una Factura no representa una definición de software, es una abstracción de un concepto del mundo real. Un diseño de un clases expresa para la aplicación de software --- la definición de clases como componentes de software, por lo tanto, una clase Factura representará una clase de software. 76

16 Casos de Uso: Expandido y Esencial Casos de Uso: Real Caso de Uso Interacción Modelo Conceptual Glosario Clases Diagrama Secuencia Sistema Contratos de del Arquitectura de Paquetes Diagrama Estado de Base de Datos Figura # 25, Dependencias, Clases. Los pasos para diseñar un diagrama de clases son los siguientes:. Analizar los diagramas de interacción e identificar las clases que participan en la solución del software. Algunas clases del modelo conceptual pueden no estar presentes en el ciclo de desarrollo actual, pero tal vez sean manejadas en ciclos posteriores. 2. Dibujar cada una de ellas en un diagrama de clases. 3. Añadir los atributos de los conceptos asociados del modelo conceptual o las clases correspondientes en el diagrama de clases. 4. Analizar los diagramas de interacción para identificar y añadir los nombres de los métodos a su clase correspondiente. Tomar en cuenta que los métodos de creación generalmente son omitidos al igual que los métodos de simple acceso a atributos privados. También los mensajes a un multi-objeto son omitidos debido a que no pertenecen a una clase participante en el diagrama, sin embargo se puede añadir información acerca de esto. 5. Añadir el tipo de atributos, parámetros de los métodos y el valor de retorno de los métodos, aunque esto puede ser opcional. 6. Añadir las asociaciones necesarias de tal forma de soportar la visibilidad de los atributos. 7. Añadir las flechas de navegabilidad a las asociaciones para indicar la dirección de visibilidad de los atributos. La navegabilidad implica visibilidad, la más común; visibilidad como atributo. Esto no implica que todas las asociaciones deban ser adornadas con navegabilidad, se sugieren solo las siguientes: a. B envía un mensaje a C b. B crea una instancia de C c. B necesita mantener una asociación con C 77

17 8. Añadir relaciones de dependencia, las cuales indican una visibilidad de los siguientes tipos: parámetro, global o declarada localmente. Una relación de dependencia indica que un elemento tiene conocimiento de otro elemento y es representada mediante una flecha con línea punteada. 9. Pueden agregarse detalles como visibilidad, valores iniciales si es que estos son importantes Creando el clases del Problema del Vivero. [Caso de Estudio] Identificando clases de software. Se pueden encontrar analizando cada diagrama de colaboración. PTV Factura Venta Cat_Producto Esp_Producto Cat_Cliente Esp_Cliente El siguiente punto es dibujar un diagrama de clases para estas clases incluyendo los atributos previamente identificados en el modelo conceptual. TPV Cat_Cliente Factura numero : int fecha : Date importe : float Venta cantidad : int Esp_Cliente numero : int nombre : Cadena RFC : Cadena domicilio : Direccion Cat_producto Esp_Producto numero : int descripcion : Cadena precio : float Figura # 26, Clases obtenidas de los Diagramas de colaboración Algunos de los Conceptos del modelo conceptual pueden no aparecer en el Clases del ciclo de desarrollo actual, sin embargo, en ciclos de desarrollo futuros, en donde nuevos casos de uso los requieran, se deberán incluir en el diseño. 78

18 Agregando nombres de métodos. Los métodos que corresponden a cada clase pueden ser identificados analizando los Diagramas de Colaboración, de esta forma, por ejemplo; el mensaje escompletada() se envia a una instancia de la clase Factura, entonces la clase factura deberá definir el método escompletada(). En general, el conjunto de todos los mensajes enviados a una clase X a través de todos los Diagramas de Colaboración, se deberán incluir en la clase X. Por inspección de todos los Diagramas de Colaboración del caso de uso Facturación Versión, las clases quedarán conformadas como sigue: TPV entra_articulo(int numero, int cantidad) fin_venta() Venta num_art : int suma(venta Vi) subtotal() Cat_Cliente especifica(int numero) num_fact : int fecha : Date importe : float terminada : int Factura Esp_Cliente num_cte : int nombre : Cadena RFC : Cadena domicilio : Direccion suma_art(esp_producto prod, int cantidad) escompletada() total() entra_cliente(int numero) Cat_Producto especifica(int numero) Esp_Producto num_prod : int descripcion : Cadena precio : float precio(int numero) Figura # 27, Atributos y métodos NOTA: Algunos cambios... Se agrega el atributo terminada en la clase Factura, para indicar que fue concluida. Se cambia el nombre del atributo número en las clases; Venta, Factura, Esp_Cliente, Esp_Producto por; num_art, num_fact, num_cte y num_prod respectivamente. 79

19 Consideraciones en el nombres de métodos. Deberán tenerse en cuenta las siguientes consideraciones al nombrar métodos. a) Interpretación del mensaje crear(). En el UML este mensaje indica creación e inicialización, cuando se traslada el diseño a un lenguaje particular deberá considerarse el nombre de este método de acuerdo al lenguaje de programación empleado. Debido a sus múltiples interpretaciones y a que la inicialización es un trabajo muy común, es costumbre omitir este tipo de mensajes en el Diseño de clase. b) Métodos de acceso. Los métodos de acceso son aquellos que leen o actualizan atributos, es común contar con este tipo de métodos para cada atributo, así mismo declarar todos los atributos como privados. Este tipo de métodos son normalmente excluidos de los diagramas de clase ya que generan mucho ruido, pues si se tienen N atributos se generarán 2N métodos. c) Interpretación de mensajes a multiobjetos. Un mensaje a un multiobjeto es interpretado como un mensaje al contenedor / colección de objetos en si mismo. Por ejemplo el método buscar(numero) se deberá interpretar como un mensaje a una colección de objetos, por lo que el método buscar(numero) no es parte de la clase Esp_Producto, es parte de la definición del diccionario de clases, por lo cual será incorrecto agregarlo como un método de la clase Esp_Producto. Este tipo de clases contenedor son librerías de clases predefinidas, por lo que no es útil mostrar estos métodos en el diagrama de clases, ya que agregan ruido y muy poca información. d) Sintaxis dependiente del lenguaje. El UML usa su propia sintaxis, por lo tanto será necesario realizar una traslación al lenguaje que se usará en la implementación, esta traslación se deberá realizar durante la generación de código, en vez de durante la creación de los diagramas de clase e) Agregando información de tipos. El tipo de los atributos, parámetros de los métodos y valores de retorno de los métodos se pueden mostrar de una manera opcional Agregando asociaciones y navegabilidad. Cada terminación de una asociación es un rol, él cual puede ser adornado con una flecha para indicar navegabilidad. La navegabilidad es una propiedad del rol que indica el sentido de la navegación a través de la asociación desde el objeto de la clase fuente al objeto de la clase destino. La navegabilidad también indica visibilidad, usualmente visibilidad de atributos. La interpretación mas común de una asociación con una flecha de navegación es la visibilidad de atributos desde la clase fuente a la clase destino. Durante la implementación en un lenguaje de programación orientado a objetos se traslada indicando que la clase fuente tiene un atributo que se refiere a una instancia de la clase destino. En el diseño de un diagrama de clases, las asociaciones son seleccionadas de acuerdo a criterios de necesidad de conocer que asociaciones se requieren para satisfacer la visibilidad y necesidades de memoria indicadas por los diagramas de interacción. Esto es en contraste con las asociaciones en el modelo conceptual, las cuales se justifican por la intención de mejorar la comprensión del dominio del problema. Una vez mas, se aprecia una distinción en las metas en el diseño de los diagramas de clase y el modelo conceptual, uno es analítico y el otro es una descripción de los componentes de software. 80

20 La visibilidad requerida y las asociaciones entre clases son indicadas por los diagramas de interacción. Las siguientes son situaciones que sugieren la necesidad de definir una asociación con un adorno de navegabilidad entre B y C. a. B envía un mensaje a C b. B crea una instancia de C c. B necesita mantener una asociación con C Tomando en cuenta los criterios antes mencionados sobre asociaciones y navegabilidad, analizando los diagramas de colaboración generados anteriormente para el Caso de Uso de Facturación Versión, se construye el diagrama de clases de la Figura # 28. TPV entra_articulo(int numero, int cantidad) fin_venta() ve en Cat_Producto especifica(int numero) captura consulta Cat_Cliente especifica(int numero) contiene 0..* num_fact : int fecha : Date importe : float terminada : int Factura suma_art(esp_producto prod, int cantidad) escompletada() total() entra_cliente(int numero) contiene..* Esp_Producto num_prod : int descripcion : Cadena precio : float precio(int numero)..* Esp_Cliente num_cte : int nombre : Cadena RFC : Cadena domicilio : Direccion describe almacena..* Venta num_art : int suma(venta Vi) subtotal() Figura # 28, Clases Caso de Uso Facturación Versión En el diagrama de clase de la figura # 28 no existen las mismas asociaciones que se generaron en el modelo conceptual. Por ejemplo, en el modelo conceptual no existe una asociación entre Terminal de Punto de Venta (TPV) y el Catalogo de Clientes (Cat_Cliente), y en el Clases si existe se llama ve en ya que es necesario consultar el Catalogo de Clientes desde la Terminal de Punto de Venta. 8

21 Agregando Relaciones de Dependencia. El UML incluye una notación para indicar las Relaciones de Dependencia (una flecha punteada), él cual indica que un elemento tiene conocimiento de otro elemento. En las diagramas de clase las relaciones de dependencia son útiles para indicar atributos no visibles entre clases, en otras palabras; parámetros, visibilidad de declaraciones locales o globales. En contraste, la visibilidad planeada de los atributos se muestra mediante líneas de asociación y flechas de navegación. TPV entra_articulo(int numero, int cantidad) fin_venta() ve en Cat_Producto especifica(int numero) captura 0..* consulta Cat_Cliente especifica(int numero) contiene num_fact : int fecha : Date importe : float terminada : int Factura suma_art(esp_producto prod, int cantidad) escompletada() total() entra_cliente(int numero) contiene..* Esp_Producto num_prod : int descripcion : Cadena precio : float precio(int numero)..* Esp_Cliente num_cte : int nombre : Cadena RFC : Cadena domicilio : Direccion describe almacena..* Venta num_art : int suma(venta Vi) subtotal() Figura # 29, Clase, Dependencias. Caso de Uso Facturación, Versión En la Figura # 29 se muestran 2 dependencias, la primera es entre TPV y Esp_Producto, se da porque TPV recibe de Cat_Producto un objeto del tipo Esp_Producto regresado desde la función Cat_Producto.especifica(numero). La segunda dependencia se presenta entre Factura y Esp_Cliente, se da porque Factura debe recibir de Esp_Cliente un objeto del tipo Esp_Cliente regresado desde la función Cat_Cliente.especifica(numero). Estos atributos no visibles se pueden mostrar mediante la notación de dependencia. 82