PROCESO DE DESARROLLO - itlalaguna.edu.mx y... · 164 Instituto Tecnológico de la Laguna Análisis y Diseño Orientado a Objetos Paola Romero Guillén 6.6.2 Diseño de diagramas

162

Instituto Tecnológicode la Laguna

Análisis y Diseño Orientadoa Objetos

Paola Romero Guillén

6.6 DISEÑO. [Proceso]

Durante un Ciclo de Desarrollo iterativo es posible pasar a la Fase de Diseño una vezcompletada la documentación de la fase de Análisis. Durante esta etapa se desarrolla una soluciónlógica basada en el paradigma orientado a objetos. La parte central de esta solución se basa en lacr4eación de Diagramas de Interacción. Estos diagramas muestran la forma en que los objetosse comunican y de esta forma cumplen con los requerimientos establecidos.

Una vez terminados los Diagramas de Interacción propuestas para el ciclo de desarrolloactual, se procede al diseño de los Diagramas de Clases, los cuales contienen las clases(interfaces) que serán implementadas mediante software.

6.6.1 Describiendo Casos de Uso Reales.

Los casos de uso reales presentan un diseño concreto, la forma en que un Caso de Usodeberá ser realizado. La definición de Casos de Uso Reales es la primera actividad a realizardurante la fase de diseño en el ciclo de desarrollo actual. La creación de los Casos de Uso Realesesta basada en la definición previa de los Casos de Uso esenciales relacionados.

Un Caso de Uso Real describe el diseño real del caso de uso en términos de entradas ysalidas concretas pensando en la tecnología disponible para su implementación. . En ocasiones amanera de ejemplificar pueden ser involucradas interfaces graficas a manera de prototipos, no es

Casos de Uso:Real

Base de Datos

Arquitectura deDiagrama dePaquetes

Diagrama deClases

Diagrama deInteracción

Casos de Uso:Expandido yEsencial

Diagrama deCaso de Uso

Contratos

Diagrama deSecuencia delSistema

Glosario

ModeloConceptual

Diagrama deEstado

Figura # 18, Diagrama de Dependencias, Fase de Diseño.Creación de Caso de Uso Reales

163




necesario implementarlas, sin embargo son una alternativa para presentar detalles de laimplementación, durante el diseño.

A continuación se muestra el Caso de Uso de la Facturación Versión 1, en donde se haagregado algunas textos para clarificar detalles del curso de eventos.

NOMBRE: Facturación Versión 1.

Caso de Uso: Facturación Versión 1.

Actores: Cliente (iniciador), Vendedor.

Propósito: Generar un documento con los datos del cliente, datos yprecio de los productos y el total de la venta. LlamadoFactura.

Tipo: Primario y esencial.

Descripción:El Vendedor introduce la clave del producto, el número deproductos, la clave del cliente. se calcula el subtotal porproducto y el total de la venta.

ReferenciasCruzadas:

R3, R4, R5, R6, R7

Curso de Eventos: Facturación Versión 1.

No Acción del Actor No Respuesta del Sistema1. Este caso de uso inicia cuando el Cliente

llega a la terminal de Punto de Venta conlos productos que desea adquirir.

2. Para cada artículo el vendedor introduce laclave del producto.

3. Busca en el archivo la clave del artículo ymuestra su descripción y precio de lista.Se agrega a la lista de productosadquiridos.

4. El vendedor teclea el número de artículossolicitados por el Cliente.

5. Se calcula y muestra el total del importepor cada artículo.

6. Una vez terminada la captura de todos losartículos. el vendedor indica fin de la venta.

7. Se calcula y despliega el total de la venta.

8. El Vendedor introduce el número decliente.

9. Busca en el archivo y despliega los datosdel cliente.

10. El Vendedor pide la confirmación de losdatos al Cliente

11. El Vendedor manda a imprimir la Factura 12. Se imprime la Factura.

164




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 deresponsabilidades 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íamensajes para llevar a cabo un tarea especifica. La creación de Diagramas de Interacción ocurredentro de la fase de diseño durante el ciclo de desarrollo en cuestión. Su creación depende dehaber trabajado previamente en los artifacs mostrados en la Figura # 19.

Uno de los problemas mas comunes en la creación de proyectos utilizando la tecnología deobjetos es valorar la creación de los diagramas de interacción, al cuidar el asignarresponsabilidades y hacer que cada una de ellas y todas en conjunto cumplan con losrequerimientos establecidos. Por lo que el asignar responsabilidades y diseñar objetoscolaborativos es muy importante, entonces, una porcentaje considerable del trabajo en el proyectodeberá aplicarse a la fase del diseño de diagramas de interacción.

6.6.3 Responsabilidades y métodos.

La Responsabilidad se define como un contrato u obligación de un tipo o clase. Lasresponsabilidades están relacionadas a las obligaciones de un objeto en términos de sucomportamiento, siendo básicamente de 2 tipos:

Casos de Uso:Real

Base de Datos


Diagrama deClases




Contratos


Glosario

ModeloConceptual

Diagrama deEstado

Figura 19, Diagrama de Dependencias Fase de Diseño.Creación de Diagrama de Interacción.

165




1. 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. Lasresponsabilidades relacionadas con el conocimiento son frecuentemente identificadas desde elmodelo conceptual ya que en él se muestran atributos y asociaciones.

La translación de responsabilidades en clases y métodos se ve influenciada por lagranularidad de la responsabilidad.

Una responsabilidad no es lo mismo que un método, los métodos son implementados paracumplir responsabilidades. Las responsabilidades se implementan usando métodos, los que actuantanto sobre otros métodos como sobre objetos.

La manera de implementar las responsabilidades (implementadas como métodos) esmediante la creación de los Diagrama de interacción, los cuales muestra las interacciones de losmensajes entre instancias (y clases) en el Modelo de Clase. El punto de partida para estasinteracciones son las descripciones de las Post-condiciones de los contratos. El UML define dosconjuntos de diagramas de interacción, donde cualquiera de los dos expresan los mismosconceptos en cuanto a la interacción de los mensajes:

• Diagramas de Secuencia. Ilustran la interacción entre objetos, en una secuencia detiempo, expresada en el eje vertical.

• Diagramas de Colaboración. Ilustran la interacción entre objetos, utilizando un formato degrafo o de red.

6.6.4 Patrones.

En la tecnología e objetos, un Patrón es la descripción de un problema y su solución, lacual puede ser aplicada a un nuevo contexto. Existen patrones que brindan lineamientos de cómoasignar las responsabilidades a objetos en el contexto de categorías especificas de problemas.

6.6.4.1 Patrones: Principios Generales de Asignación de Responsabilidades (del inglésGRASP).

Existen 5 categorías de patrones GRASP.

• Experto.• Creador.• Bajo acoplamiento.• Alta Cohesión.• Controlador.

166




PATRÓN: Experto.

Solución:Asigna una responsabilidad al experto de la información --- La claseque tiene la información necesaria para cumplir con laresponsabilidad

Problema: Cuál es el principio básico por el cual las responsabilidades son asignadasen el Diseño Orientado a Objetos.Un Modelo de Clase puede definir docenas de cientos de clases desoftware y una aplicación puede requerir cientos de miles deresponsabilidades a ser cumplidas. Durante el Diseño Orientado aObjetos, cuando la interacción entre objetos es definida, ya se debenhaber asignado las responsabilidades a las clases. Un sistema bienhecho, tiende a ser fácil de entender, mantener y extender, y existe laoportunidad del rehúso de los componentes en futuras aplicaciones.

Discusión: Este patrón es el mas usado en la asignación de responsabilidades, elobjeto hace cosas relacionadas con la información que tiene. También sepueden manejar Expertos parciales cuando se requiere informacióncontenida en otras clases y objetos.

Beneficios: • Se mantiene el encapsulamiento, ya que los objetos utilizan su propiainformación.

• El comportamiento del sistema es distribuido a través de clases quecuentan con la información requerida

PATRON: CreadorSolució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). Bes 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 unsistema orientado a objetos, consecuentemente es útil contar conprincipios 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 conla creación de objetos, una actividad muy común en los sistemasorientados a objetosAgregación agrega parte, Contenedor contiene contenido, Actualizadoractualiza graba. La actualización de información es una relación muycomún entre clases en un diagrama de clases

Beneficios: Bajo acoplamiento, implica menor dependencia en el mantenimiento y altaoportunidad de rehúso.

167




PATRON: Bajo AcoplamientoSolución Asigna responsabilidades, de tal forma que el acoplamiento

permanezca bajoProblema: 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 considerarcontinuamente. Es un patrón de evaluación, aplicado por cualquierdiseñador al avaluar cualquier decisión de diseño.En los lenguajes orientados a objetos una forma común de acoplamientodesde 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 unparámetro o variable local del Tipo_Y o el objeto regresado desde unmensaje 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 masindependientes, 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 lareutilizaciónUna subclase esta fuertemente acoplada a su superclase . La decisión dederivar de una superclase deberá ser cuidadosamente considerada desdeeste punto de vista.

Beneficios: • No hay afectación por cambios en otros componentes.• Simple para entender el aislamiento.• Conveniente para rehúso.

168




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 masespecífica, la cohesión funcional) es una medida de que tanto se haenfocado la responsabilidad en una clase, así, una clase con unaresponsabilidad alta, y que no realiza un trajo abrumador, tiene una altacohesión.Una clase con una baja cohesión hace muchas cosas irrelevantes orealiza mucho trabajo, tales clases son indeseables, ellas tienen lossiguientes 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 otienen responsabilidades que deberán ser delegadas a otras clases.

discusión: Tanto el Bajo acoplamiento como la alta cohesión deberán ser principiosque se deben tomar en cuenta en las decisiones de diseño, sonlineamientos que se deben siempre considerar. Es un patrón deevaluació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 otrostrabajos.

• Moderada Cohesión. Una clase tiene moderada responsabilidad envarias áreas diferentes que están lógicamente relacionadas alconcepto 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ónse puede usar para propósitos muy específicos.

169




PATRON: ControladorSolució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 elmismo caso de uso.

Problema: Quién deberá asumir la responsabilidad de manejar los eventos delsistema.Un evento del sistema es un evento del sistema de alto nivel generadopor un actor externo; es un evento externo de entrada, son asociados conoperaciones del sistema --- operaciones del sistema en respuesta aeventos del sistemaUn Controlador no es un objeto de interfase de usuario responsable delmanejo de los eventos del sistema. Un Controlador define los métodospara la operación del sistema.

discusión: La mayoría de los sistemas reciben eventos externos, como la IU, decensores de señal, etc.Un defecto común en el diseño de controladores es asignarles muchasresponsabilidades. Normalmente un controlador deberá delegar a otrosobjetos el trabajo que necesita realizar mientras coordina las actividades

Beneficios: • Incrementa el potencial para componentes reutilizables. Asegura quelos procesos son manejados por objetos de la capa de dominio, no porobjetos del de la capa de interfase.. La responsabilidad de uncontrolador técnicamente deberá ser manejada por un objeto deinterfase, pero la implementación de tal diseño es que el código ylógica del programa se manejen como procesos del dominio.

• Conocimiento del estado del caso de uso. Ayuda a que lasoperaciones ocurran en una secuencia lógica o que se identifique elestado actual del caso de uso.

6.6.4.2 Responsabilidades y cartas CRC.

Un dispositivo que puede ayudar a asignar responsabilidades e indicar colaboraciones conotros objetos son las Cartas CRC (Cartas de: Clase – Responsabilidad – Colaboración), éstasfueron diseñadas por Kent Beck y Ward Cunningham. Las cartas CRC son cartas de índice, unapara cada clase, sobre las cuales se escriben brevemente las responsabilidades e cada clase yuna lista de los objetos que colaboran para cumplir con la tarea asignada. Normalmente se analizael rol jugado por cada clase o por un conjunto pequeño de clases.

La asignación de responsabilidades y el desarrollo de losDiagramas de interacción es la etapa de creación massignificativa durante la etapa de diseño.

170




6.6.5 Como hacer un diagrama de interacción

1. Crear un diagrama por separado para cada operación del sistema que se encuentra en elciclo de desarrollo actual.

• Para cada operación del sistema, haga un diagrama, utilizando el nombre de laoperació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 quecumplan con el trabajo encomendado.

6.6.6 Diagramas de iteración del Caso de Uso Facturación Versión 1 [Caso de Estudio]

Tomando como base el Diagrama de Secuencia del Sistema, y las operacionesencontradas, se deberán construir los siguientes diagramas de iteración:

1. Entra artículo.2. Fin de venta.3. Entra Cliente.

1. Contrato: Entra Artículo.

CONTRATO: entra_articulo()

Nombre entra_Artículo(numero : entero, cantidad : entero)

Responsabilidad Registrar la compra de un articulo, añadirlo a laventa total, desplegar precio de lista y sudescripción.Cuando se introduce la cantidad de artículosdespliega el precio total por artículo.

Tipo Sistema.

Referencia cruzada R4, R5, R6

Notas Accesa el Catalogo de Productos.

Excepciones Envía un error si no existe el artículo.

Salida Muestra la descripción del artículo, su precio de listay el importe total por artículo.

Para cada evento del sistema crear un diagrama de interacción dondeel mensaje de inicia sea el mensaje del evento del sistema.

Usando las secciones de responsabilidades y post-condiciones de loscontratos y los casos de uso como punto de partida, diseñar un sistemade objetos que interactúan para llevar a cabo una tarea.

171




Pre-condición Es necesario conocer la clave del producto y lacantidad de productos solicitada por el Cliente.

Post-condición • Al introducir el primer artículo, se crea unanueva 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 dePunto 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.

Si se considera el principio de separación Modelo – Vista, no es responsabilidad de losobjetos del dominio comunicarse con el usuario, por lo tanto, los procesos que indiquen unavisualización de datos deberán ser ignorados. Lo que se requiere con respecto a la responsabilidadde 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 elcandidato 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 cadaproducto.

De esta forma TPV crea una instancia de factura y la factura crea una colección vacía deinstancias 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)

: TPV

: Vendedor

1: entra_articulo(numero, cantidad)

Figura # 20, Definir Controlador

172




Encontrando la especificación del producto.

La instancia de Venta debe ser asociada con la Especificación del producto, él cual debetener el número de la clave del producto, lo cual es necesario para obtener una Especificación deProducto. Es necesario primero pensar en quien es responsable de conocer la Especificación delproducto en base a su número de clave. Usando el patrón Experto dice; que quien posea lainformación deberá ser el indicado de cumplir la responsabilidad. Analizando el Modelo Conceptualse ve que el indicado es el Catalogo de Productos, por lo que este concepto es un buen candidatopara cumplir con la responsabilidad.

Visibilidad hacia el Catalogo de Productos.

¿Quién deberá enviar el mensaje de especificación a el Catalogo de Productos parapreguntar por la Especificación del Producto?.

Si se asume que las instancias de TPV y el Catalogo de Productos fueron creados duranteel inicio del Caso de uso y que la conexión entre ellos es permanente y suponiendo que es posiblepara el TPV enviar el mensaje de especificación al Catalogo de Productos.

Esto implica otro concepto en el Diseño Orientado a Objetos: 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.

Diagrama de Colaboración de entra artículo.

Es necesario hacer una serie de reflexiones basadas en los patrones GRASP paraconseguir el diseño del diagrama; El diseño de objetos que interactúan y la asignación deresponsabilidades, requieren considerable tiempo de deliberación.

Mensajes a multiobjetos.

• El mensaje busca() deberá localizar en la Especificación del Producto, aquel quecoincida 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.

: Vendedor

: TPV

1: entra_articulo(numero, cantidad)

: Factura

: Venta

3: crea_coleccion()

2: crea()

Figura #21, Crear instancia de Factura ycolección vacía de Venta

173




CONTRATO: Fin de Venta.

Este contrato ocurre cuando el Vendedor selecciona fin de venta.

CONTRATO: fin_venta()

Nombre fin_venta( )

Responsabilidades Termina el proceso de captura de artículos, calculael importe total de la venta.

Tipo Sistema

Referencias cruzadas R7NotasExcepciones

Salida Se muestra el importe total de la Venta.Pre-condiciones

Post-condiciones ! Se actualiza su numero (el cual esconsecutivo.

! Se actualiza la fecha con la del sistema.! Se almacena el importe total de la factura.

: Vendedor

: TPV : Factura

: Venta

: Cat_producto

: Esp_Producto

1: entra_articulo(numero, cantidad)2: crea()

6: suma_art( prod, cantidad)

4: prod = especifica(numero) 3: crea_coleccion()

7: crea(prod, cantidad)

8: suma(Vi)5: prod = busca(numero)

Figura # 22, Diagrama de Colaboración, entra_articulo

174




Seleccionando el Controlador.

De acuerdo al patrón GRASP, y al contrato anterior, se selecciona como controlador elconcepto 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 alpatrón Experto, la misma clase Factura, deberá modificar dicho atributo, por lo tanto TPV enviará elmensaje 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 elconsecutivo 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 lainformació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 calculodel total.

o Cada subtotal deberá obtenerlo de la clase Venta y de la Clase Especificacióndel Producto (Esp_Producto)

o Deberá ir acumulando cada subtotal de cada instancia Venta hasta terminartodas las instancias almacenadas en la colección.

El diagrama de colaboración completo quedará como sigue:

: Vendedor

: TPV : Factura

: Venta : Esp_Producto

1: fin_venta() 2: esCompletada()

4: total()

3: subtotal()

5: pr = lprecio(numero)

Figura # 23, Contrato, fin_venta

175




Mostrado de Información.

Durante la creación de los Diagramas de Colaboración, no se debe tomar en cuenta elmostrar información en pantalla, solo se debe de poner disponible la información.

NOTA: No necesariamente se debe iniciar el Diagrama de Colaboración con el mensaje nombredel contrato, si el diseñador decide iniciar con otro mensaje, es libre de hacerlo.

CONTRATO: entra_cliente

CONTRATO: entra_cliente

Nombre entra_cliente(numero)

Responsabilidades Accesar los datos del cliente para incluirlos en laFactura.

Tipo Sistema

Referencias cruzadas R3

Notas Accesa el Catalogo de Clientes.

Excepciones Envía un error si no existe el Cliente.

Salida Muestra los datos del Cliente. Se imprime la factura.

Pre-condiciones Es necesario conocer la clave del cliente.Post-condiciones

De acuerdo al patrón GRASP, y al contrato anterior, se selecciona como controlador laFactura.

: Vendedor

: Factura

: Cat_Cliente : Esp_Cliente

1: entra_cliente(numero)

2: Especifica(numero)

3: cte = busca(numero)

Figura # 24, Contrato, entra_cliente

176




La clase que conoce a todos los clientes es la clase Catalogo de Clientes (Cat_cliente), vaa buscar utilizando el número de cliente, los datos del cliente para agregarlos a la factura yponerlos a disposición para poderlos mostrar.

6.6.7 Determinando Visibilidad. [Proceso]

Como se mencionó anteriormente, la visibilidad es la habilidad que tiene un objeto de ver o tenerreferencia a otro objeto. Por lo tanto si un objeto emisor envía un mensaje a un objeto receptor, elemisor 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 servisible a B.Cuando se termino de desarrollar los diagramas de colaboración, se analiza el tipo de visibilidadque tendrá cada mensaje y una vez que se ha sido definido, el siguiente paso es el desarrollo deldiagrama de clases.

6.7 Diseñando Diagramas de clase. [Proceso]

El diagrama de clases se construye cuando han sido desarrollados los diagramas deinteracción (aunque se pueden hacer paralelamente) y por supuesto con la ayuda del modeloconceptual. Las actividades y dependencias para la creación del Diagrama de Clases se muestranen la Figura # 25.

6.7.1 Diseñando Diagramas de Clases

Un Diagrama de 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 presentadefiniciones 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 unaabstracción de un concepto del mundo real. Un diseño de un Diagrama de clases expresa – para laaplicación de software --- la definición de clases como componentes de software, por lo tanto, unaclase Factura representará una clase de software.

177




Los pasos para diseñar un diagrama de clases son los siguientes:

1. Analizar los diagramas de interacción e identificar las clases que participan en la solucióndel software. Algunas clases del modelo conceptual pueden no estar presentes en el ciclode 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 generalmenteson omitidos al igual que los métodos de simple acceso a atributos privados. También losmensajes a un multi-objeto son omitidos debido a que no pertenecen a una claseparticipante 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; visibilidadcomo atributo. Esto no implica que todas las asociaciones deban ser adornadas connavegabilidad, se sugieren solo las siguientes:

a. B envía un mensaje a Cb. B crea una instancia de Cc. B necesita mantener una asociación con C

Base de DatosDiagrama deEstado

Casos de Uso:Real


Diagrama deClases




Contratos


Glosario

ModeloConceptual

Figura # 25, Diagrama de Dependencias, Diagrama de Clases.

178




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 unelemento tiene conocimiento de otro elemento y es representada mediante una flecha conlínea punteada.

9. Pueden agregarse detalles como visibilidad, valores iniciales si es que estos sonimportantes

6.7.2 Creando el Diagrama de clases del Problema del Vivero. [Caso de Estudio]

6.7.2.1 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 losatributos previamente identificados en el modelo conceptual.

Algunos de los Conceptos del modelo conceptual pueden no aparecer en el Diagrama de Clasesdel ciclo de desarrollo actual, sin embargo, en ciclos de desarrollo futuros, en donde nuevos casosde uso los requieran, se deberán incluir en el diseño.

TPV Factura

numero : intfecha : Dateimporte : float

Venta

cantidad : int

Cat_Cliente

Esp_Cliente

numero : intnombre : CadenaRFC : Cadenadomicilio : Direccion

Esp_Producto

numero : intdescripcion : Cadenaprecio : float

Cat_producto

Figura # 26, Clases obtenidas de los Diagramas de colaboración

179




6.7.2.2 Agregando nombres de métodos.

Los métodos que corresponden a cada clase pueden ser identificados analizando losDiagramas de Colaboración, de esta forma, por ejemplo; el mensaje esCompletada() se envia auna instancia de la clase Factura, entonces la clase factura deberá definir el métodoesCompletada().

En general, el conjunto de todos los mensajes enviados a una clase X a través de todos losDiagramas 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ónVersión 1, las clases quedarán conformadas como sigue:

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.

TPV

entra_articulo(int numero, int cantidad)fin_venta()

Factura

num_fact : intfecha : Dateimporte : floatterminada : int

suma_art(Esp_Producto prod, int cantidad)esCompletada()total()entra_cliente(int numero)

Venta

num_art : int

suma(Venta Vi)subtotal()

Cat_Cliente

especifica(int numero)

Esp_Cliente

num_cte : intnombre : CadenaRFC : Cadenadomicilio : Direccion

Esp_Producto

num_prod : intdescripcion : Cadenaprecio : float

precio(int numero)

Cat_Producto


Figura # 27, Atributos y métodos

180




6.7.2.3 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 aun lenguaje particular deberá considerarse el nombre de este método de acuerdo allenguaje de programación empleado.Debido a sus múltiples interpretaciones y a que la inicialización es un trabajo muycomún, es costumbre omitir este tipo de mensajes en el Diagrama de Diseño de clase.

b) Métodos de acceso.Los métodos de acceso son aquellos que leen o actualizan atributos, es comúncontar con este tipo de métodos para cada atributo, así mismo declarar todos losatributos como privados.Este tipo de métodos son normalmente excluidos de los diagramas de clase ya quegeneran 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 unacolección de objetos, por lo que el método buscar(numero) no es parte de la claseEsp_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 pocainformación.

d) Sintaxis dependiente del lenguaje.El UML usa su propia sintaxis, por lo tanto será necesario realizar una traslación allenguaje que se usará en la implementación, esta traslación se deberá realizar durantela 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étodosse pueden mostrar de una manera opcional

6.7.2.4 Agregando asociaciones y navegabilidad.

Cada terminación de una asociación es un rol, él cual puede ser adornado con una flechapara indicar navegabilidad. La navegabilidad es una propiedad del rol que indica el sentido de lanavegación a través de la asociación desde el objeto de la clase fuente al objeto de la clasedestino. 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 deatributos desde la clase fuente a la clase destino. Durante la implementación en un lenguaje deprogramación orientado a objetos se traslada indicando que la clase fuente tiene un atributo que serefiere a una instancia de la clase destino.

En el diseño de un diagrama de clases, las asociaciones son seleccionadas de acuerdo a criteriosde necesidad de conocer que asociaciones se requieren para satisfacer la visibilidad ynecesidades de memoria indicadas por los diagramas de interacción. Esto es en contraste con lasasociaciones en el modelo conceptual, las cuales se justifican por la intención de mejorar lacomprensión del dominio del problema. Una vez mas, se aprecia una distinción en las metas en eldiseño de los diagramas de clase y el modelo conceptual, uno es analítico y el otro es unadescripción de los componentes de software.

181




La visibilidad requerida y las asociaciones entre clases son indicadas por los diagramas deinteracción. Las siguientes son situaciones que sugieren la necesidad de definir una asociación conun adorno de navegabilidad entre B y C.

a. B envía un mensaje a Cb. B crea una instancia de Cc. 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 deFacturación Versión 1, se construye el diagrama de clases de la Figura # 28.

En el diagrama de clase de la figura # 28 no existen las mismas asociaciones que segeneraron en el modelo conceptual. Por ejemplo, en el modelo conceptual no existe unaasociación entre Terminal de Punto de Venta (TPV) y el Catalogo de Clientes (Cat_Cliente), y en elDiagrama de Clases si existe se llama ve en ya que es necesario consultar el Catalogo de Clientesdesde la Terminal de Punto de Venta.

1 1

Venta

num_art : int


TPV


Factura



0..*1 captura

1..*

1

almacena

Cat_Producto


1

1ve en

Esp_Producto


precio(int numero)

describe

1..*

1

contiene

Cat_Cliente


11consulta

Esp_Cliente


1..*

1

contiene

1

1

1..*

1..*

0..*1

11

1 11

1..*

11

Figura # 28, Diagrama de ClasesCaso de Uso Facturación Versión 1

182




6.7.2.5 Agregando Relaciones de Dependencia.

El UML incluye una notación para indicar las Relaciones de Dependencia (una flechapunteada), él cual indica que un elemento tiene conocimiento de otro elemento. En las diagramasde clase las relaciones de dependencia son útiles para indicar atributos no visibles entre clases, enotras palabras; parámetros, visibilidad de declaraciones locales o globales. En contraste, lavisibilidad planeada de los atributos se muestra mediante líneas de asociación y flechas denavegación.

En la Figura # 29 se muestran 2 dependencias, la primera es entre TPV y Esp_Producto, se daporque TPV recibe de Cat_Producto un objeto del tipo Esp_Producto regresado desde la funciónCat_Producto.especifica(numero).La segunda dependencia se presenta entre Factura y Esp_Cliente, se da porque Factura deberecibir de Esp_Cliente un objeto del tipo Esp_Cliente regresado desde la funciónCat_Cliente.especifica(numero).Estos atributos no visibles se pueden mostrar mediante la notación de dependencia.

Venta

num_art : int


TPV


Factura



0..*1 captura

1..*

1

almacena

Cat_Producto


1

1ve en

Esp_Producto


precio(int numero)

1 1

describe

1..*

1

contiene

Cat_Cliente


11consulta

Esp_Cliente


1..*

1

contiene

1

1

1..*

1..*

0..*1

11

1 1

1

1..*

11

Figura # 29, Diagrama de Clase, Dependencias.Caso de Uso Facturación, Versión 1

Documents

PROCESO DE DESARROLLO - itlalaguna.edu.mx y... · 164 Instituto Tecnológico de la Laguna Análisis y Diseño Orientado a Objetos Paola Romero Guillén 6.6.2 Diseño de diagramas