Anlisis y diseo - Parte III ADOO - Lic.

Morales Modelo conceptual Un modelo conceptual explica los conceptos ms significativos en un dominio del problema, identificando los atributos y las asociaciones, y es la herramienta ms importante del anlisis orientado a objetos. Los casos de uso son una importante herramienta para el anlisis de requerimientos, pero realmente no estn orientados a objetos. Un modelo conceptual representa cosas del mundo real, no componentes del software. En UML se representa mediante un grupo de diagramas de estructura esttica donde no se define ninguna operacin. En estos diagramas se muestran conceptos (objetos), asociaciones entre conceptos (relaciones) y atributos de conceptos (atributos). La siguiente figura muestra un modelo conceptual parcial del dominio de la tienda y las ventas.

Un modelo conceptual es una descripcin del dominio de un problema real, no es una descripcin del diseo del software. Debido a esto, no es conveniente aqu incluir elementos como ventanas o bases de datos. En el dominio real de comprar productos en una tienda usando una terminal de punto de venta (TPDV), intervienen tres conceptos principales: tienda, TPDV y una venta. Por lo general es mejor exagerar un poco y especificar un modelo conceptual con muchos conceptos. Esto debido a que es frecuente omitir conceptos durante el anlisis, y al descubrirlos ms tarde, es ms difcil incorporarlos. La siguiente lista muestra un conjunto de conceptos idneos para ser incluidos en el modelo conceptual. Categora del concepto Objetos fsicos o tangibles Especificaciones, diseo o descripciones de cosas Lugares Transacciones Lnea o rengln de un elemento de transacciones Ejemplos TDPV, Dado EspecicacindeProducto, ReglasdeJuego Tienda, MesadeJuego Venta, Pago, Reservacion, Apuesta VentasLineadeProducto

Rol de las personas Contenedores de otras cosas Cosas dentro de un contenedor

Cajero, Gerente, Jugador Tienda, Cesto, Biblioteca Producto, Libro

Otros sistemas de cmputo o electromecnicos SistemaAutorizacionTarjetasdeCredito externos al sistema Conceptos de nombres abstractos Organizaciones Eventos Hambre, Suerte DepartamentodeVentas, LineaAerea Venta, Robo, RodarDados Junta, Vuelo, Accidente,

Procesos (A menudo no estn representados como VentaUnProducto, ReservacionAsiento conceptos, pero pueden estarlo) Reglas y polticas Catlogos PoliticadeReembolso, PoliticadeCancelaciones CatalogodeProductos, CatalogodeLibros

Registros de finanzas, de trabajo, de contratos, de Recibo, Mayor, ContratodeEmpleo asuntos legales Instrumentos y servicios financieros Manuales y libros LineadeCredito, Existencia ManualdePersonal, ManualdeReparaciones

Otra forma simple de obtener conceptos, es identificarlos de un anlisis semntico de las descripciones textuales referentes al dominio del problema. Para hacer esto, los casos de uso expandidos proveen una buena fuente de conceptos. Por ejemplo, el caso de uso Comprar productos: Accin de los actores 1. Este caso de uso comienza cuando un Cliente llega a una caja de TPV con los productos que desea comprar. 2. El Cajero registra el cdigo de barras de cada producto. Si hay ms de un producto, el Cajero puede introducir tambin la cantidad. 3. Determina el precio del producto y a la transaccin de venta le agrega la informacin sobre el producto. Se muestra la descripcin y el precio del producto actual. Respuesta del sistema

A partir de la lista de categoras de conceptos podemos generar un conjunto de conceptos para nuestro problema del punto de venta: TPV Producto Tienda Venta Pago CatalogodeProductos EspecificaciondeProducto VentasLineadeProductos Cajero Cliente Gerente

Se debera incluir la boleta que imprime el punto de venta? Esta boleta es un informe del sistema, y dado que toda su informacin proviene de otros objetos, no es necesario incluirlo. Sin embargo, es posible que en una etapa posterior (por ejemplo cuando se implemente devolver productos) se justifique su inclusin. Por tanto, el modelo conceptual inicial del sistema de punto de venta (sin incluir atributos ni asociaciones) sera:

Falta ahora agregar los atributos relevantes de cada concepto, y las asociaciones. Atributos Un atributo es un valor lgico de un dato de un objeto. Es preferible que los atributos sean simples. Entre los tipos de atributos ms comunes se encuentran: booleanos (o lgicos), fechas, nmeros, texto y horas. Algunos tipos comunes son: direccin, color, telfono, RUT, cdigo de barras, cdigo postal. Los atributos no deberan usarse para relacionar conceptos en el modelo conceptual, solamente para describir estos conceptos. Una de las violaciones ms comunes a esta regla consiste en agregar atributos como llaves forneas. Por ejemplo:

Uno de los errores ms frecuentes al crear modelos conceptuales, es representar algo como un atributo, cuando debera haber sido un concepto aparte. Una regla prctica para evitar esto es: si en el mundo real no consideramos algn concepto X como nmero o texto, probablemente X sea un concepto y no un atributo. Por ejemplo, en un dominio de reservaciones en lneas areas, el Destino debera ser un atributo de Vuelo u otro concepto?

En el mundo real, un aeropuerto de destino no se considera nmero ni texto, por lo que debera ser un concepto. Sugerencia: En caso de duda, convierta el atributo en un concepto independiente. Otro error comn, es incluir atributos con multiplicidad mayor que 1. Por ejemplo:

Asociaciones Una asociacin es una relacin entre dos conceptos que indica alguna conexin significativa entre ellos. Las asociaciones tiles a determinar, suelen incluir el conocimiento de una relacin que ha de preservarse por algn tiempo: puede tratarse de milisegundos o de aos (segn el contexto). Por ejemplo, debemos recordar cuales instancias de VentasLineadeProducto estn asociadas a Venta? Claro que si, porque de lo contrario no sera posible reconstruir la venta, imprimir la boleta ni calcular el total de la venta. Por otra parte, necesitamos recordar una relacin entre una Venta y Gerente? Probablemente no es indispensable ni til dentro del contexto de nuestros requerimientos. Una asociacin se representa como una lnea entre conceptos, con el nombre de la asociacin. La asociacin es intrnsecamente bidireccional, es un posible nexo lgico entre los objetos. Este nexo es totalmente abstracto, no es una afirmacin sobre las conexiones entre las entidades del software. Los extremos de una asociacin pueden contener una expresin de multiplicidad que indica la relacin numrica entre las instancias de los conceptos. Opcionalmente se puede poner una flecha que indique la direccin en que debe leerse el nombre de la asociacin (no indica nada ms, es slo una ayuda para leer el diagrama).

Para identificar las asociaciones ms comunes, la siguiente lista es de gran ayuda. Categora de la asociacin A es una parte fsica de B A es una parte lgica de B A est fsicamente contenido en B A est contenido lgicamente en B A es una descripcin de B Ejemplos Caja-TPDV VentasLneadeProducto-Venta TPDV-Tienda, Producto-Estante DescripcindeProductoCatlogo DescripcindeProductoProducto

A es un elemento de lnea (o rengln) en una transaccin o reporte VentasLneadeProducto-Venta B A se conoce/introduce/registra/presenta/captura en B Venta-TPDV

A es miembro de B A es una unidad organizacional de B A usa o dirige a B A se comunica con B A se relaciona con una transaccin B A es una transaccin relacionada con otra transaccin B A es propiedad de B

Cajero-Tienda Departamento-Tienda Cajero-TPDV Cliente-Cajero Pago-Venta Pago-Venta TPDV-Tienda

Las asociaciones ms importantes son las siguientes: A es una parte fsica o lgica de B A est fsica o lgicamente contenido en B A est registrado en B Las asociaciones son importantes, pero no se debe dedicar tiempo excesivo a ellas. Es ms importante identificar los conceptos que las asociaciones. Muchas asociaciones tienden a confundir el modelo conceptual, en vez de aclararlo. Se pueden incorporar las que se indican en los casos de uso, y las que se consideren necesarias para un adecuado entendimiento del problema. La multiplicidad define cuntas instancias de un tipo A pueden asociarse a una instancia del tipo B en determinado momento. Las expresiones de multiplicidad son las siguientes: * 1..* 1..40 5 2,4,6 Por ejemplo: cero o ms, muchos uno o ms de uno a cuarenta exactamente cinco exactamente dos, cuatro o seis

Los nombres de las asociaciones deben ser lo ms claros posibles, y deben permitir leer y entender fcilmente las relaciones entre conceptos. Por ejemplo:

En sntesis, para construir un modelo conceptual se deben aplicar los siguientes pasos: 1. Liste los conceptos idneos usando la lista de categoras de conceptos. 2. Dibjelos en un modelo conceptual. 3. Incorpore las asociaciones necesarias para registrar las relaciones ms importantes (las que se deben recordar). 4. Agregue los atributos necesarios para cumplir con las necesidades de informacin. El modelo conceptual de la siguiente figura muestra un conjunto de conceptos, asociaciones y atributos idneos para la aplicacin de punto de venta.

El modelo conceptual es una herramienta de comunicacin, con la cual se intenta comprender los conceptos importantes y sus relaciones. Es tambin til para transmitir este conocimiento a otros.

Paquetes: Organizacin de los elementos Veamos el caso de uso extendido del Pago con tarjeta de crdito. Accin de los actores 1. Este caso de uso comienza cuando un Cliente decide pagar con tarjeta de crdito, una vez que le han comunicado el total de la venta. 3. Genera una Solicitud de pago con tarjeta de crdito y la 2. El Cliente entrega su tarjeta de enva a un Servicio externo de autorizacin de crdito, a crdito al Cajero, quien la pasa por travs de un modem conectado al TPV. Requiere que se un lector de tarjetas para efectuar el registren los datos de la compra, se transmitan, y se espera por pago con tarjeta de crdito. el registro de respuesta. 4. Recibe una respuesta aprobando el crdito por parte del Servicio de autorizacin. 5. Registra en el sistema Cuentas por cobrar el pago con la tarjeta de crdito y la respuesta aprobando la transaccin. (El Servicio externo de autorizacin le debe dinero a la tienda, y por eso Cuentas por Cobrar le debe dar seguimiento). 6. Muestra el mensaje de autorizacin del crdito. Falta considerar el caso en que la tarjeta se reprueba. El caso de uso para pago con cheque es similar. Despus de analizar todos los casos de uso extendidos (anlisis semntico), y revisar la lista de posibles candidatos a conceptos, se obtiene la versin preliminar del modelo conceptual. Respuesta del sistema

Cuando el nmero de elementos del modelo conceptual empieza a ser grande, se hace necesario buscar una forma de organizarlos, y para esto usaremos paquetes. Un paquete UML se muestra grficamente como una carpeta etiquetada. En su interior se pueden incluir los paquetes subordinados. Ejemplo:

Un elemento es propiedad del paquete en el cual est definido, pero puede referenciarse en otros paquetes. En este caso, para referenciar el nombre de ruta se usa el nombre del paquete y luego el nombre del elemento, de la siguiente forma: NombrePaquete::NombreElemento. Ejemplo:

Si un elemento de un modelo depende de otro, esta dependencia puede mostrarse a travs de una relacin de subordinacin. Ejemplo:

Para dividir el modelo conceptual en paquetes, se deben reunir los elementos que: - Se encuentren en la misma rea o tema (estrechamente relacionados). - Se encuentren en la misma jerarqua de tipos. - Participen en los mismos casos de uso.

Es conveniente crear un paquete llamado Conceptos del dominio, para agrupar todos los elementos del modelo conceptual. Los conceptos comunes compartidos por la mayora de paquetes, se pueden agrupar en un paquete llamado Elementos bsicos. De esta forma, el modelo conceptual del Sistema de TPV podra organizarse de la siguiente manera:

Patrones Los patrones de software describen un problema que ocurre repetidas veces en algn contexto determinado del proceso de desarrollo de software, y entregan una buena solucin ya probada. Esto ayuda a disear correctamente en menos tiempo, ayuda a construir problemas reutilizables y extendibles, y facilita la documentacin y la comunicacin con otros miembros del equipo de desarrollo. Ejemplo: Delegacin (Patrn de Diseo) Este es un patrn fundamental de tipo estructural. Indica cundo no usar herencia. La delegacin es una forma de extender y reutilizar la funcionalidad de una clase, escribiendo una clase adicional con funcionalidad extra que usa instancias de la clase original para proveer su propia funcionalidad. La delegacin es una forma de extender el comportamiento de una clase mediante llamadas a mtodos de otra clase, ms que heredando de ella. La delegacin es ms apropiada que la herencia en muchas situaciones. Por ejemplo, la herencia es til para modelar relaciones de tipo es-un o es-una, ya que

estos tipos de relaciones son de naturaleza esttica. Sin embargo, relaciones de tipo es-un-rolejecutado-por son mal modeladas con herencia. En este tipo de relaciones, instancias de una clase pueden jugar mltiples roles. Por ejemplo, supongamos que tenemos el caso de una universidad donde se tienen tres tipos de roles: estudiantes, acadmicos y funcionarios. Es posible representar esta situacin mediante una clase llamada Persona (o Personal-universitario) que tiene las subclases correspondientes a cada uno de los roles.

El problema con este diagrama, es que una misma persona puede jugar ms de un rol al mismo tiempo. Alguien podra ser funcionario y a la vez estar estudiando una carrera. Del mismo modo, alguien podra ser acadmico y estar ocupando un puesto administrativo. Para modelar adecuadamente esta situacin, se necesitaran 7 subclases de Persona: Estudiante, Acadmico, Funcionario, AcadmicoyEstudiante, FuncionarioyEstudiante, AcadmicoyFuncionario, EstudianteyAcadmicoyFuncionario. En este tipo de situaciones, el nmero de subclases que se necesitan, se incrementa exponencialmente con el nmero de roles (por ejemplo, se necesitaran 63 subclases para modelar 6 roles). Pero el problema ms serio se presenta cuando la misma persona puede jugar combinaciones distintas de roles en distintos tiempos. La herencia es una relacin esttica que no cambia con el tiempo. Para resolver esta situacin, es posible representar personas en diferentes roles usando delegacin, como se muestra en la siguiente figura.

La solucin general propuesta en este patrn es: incorporar la funcionalidad de la clase original usando una instancia de la clase original y llamando sus mtodos.

En el diagrama anterior, se muestra una clase con rol Delegador que usa una clase con el rol Delegado. Aqu se usa la delegacin para reutilizar y extender el comportamiento de la clase. Patrones de Anlisis Los patrones de anlisis son un conjunto de clases y relaciones entre ellas, que tienen algn sentido en el contexto de una aplicacin. Representan una estructura que puede ser vlida para otras aplicaciones.

Ejemplo 1: Casa reparadora de computadores (Eduardo Fernndez) Se tiene una casa reparadora de computadores (casa matriz) que coordina una cadena de casas reparadoras. Los clientes traen las computadoras daadas a alguna de estas casas, y un tcnico realiza una estimacin del dao y del costo de la reparacin. Si el cliente est de acuerdo con la estimacin, se asigna un tcnico. Todos los eventos que ocurren durante la reparacin son guardados en una especie de "expediente" del equipo (para futuras reparaciones). El modelo conceptual de este problema podra ser como el siguiente:

El diagrama de modelo de estados podra ser el siguiente:

Ejemplo 2: Hospital (Eduardo Fernndez) En un hospital se atienden personas. Por lo general, un hospital forma parte de una cadena de hospitales. Una persona trae al paciente al hospital. Los mdicos hacen un diagnstico de cada paciente que ingresa. Si el paciente (o la persona que lo trae) est de acuerdo, se le asigna un mdico para que lo trate. Los eventos durante la estada del paciente se almacenan en su expediente. El modelo conceptual de este problema podra ser como el siguiente:

El diagrama de modelo de estados podra ser el siguiente:

Diagramas de secuencia El diagrama de secuencia de un sistema muestra grficamente los eventos que originan los actores y que impactan al sistema. La creacin de los diagramas de secuencia forma parte de la investigacin para conocer el sistema, por lo que es parte del anlisis del mismo. La creacin de los diagramas de secuencia depende de la formulacin de los casos de uso. Los casos de uso indican cmo los actores interactan con el sistema. Durante la operacin del sistema, los actores generan eventos, solicitando alguna operacin a cambio. Por ejemplo, cuando un cajero ingresa un cdigo de barras de un artculo, est pidiendo al sistema de TPV que registre esa compra. Con este evento se inicia una operacin en el sistema. Antes de iniciar el diseo lgico de la aplicacin de software, es necesario investigar y definir su comportamiento como una "caja negra". Vamos a estudiar el comportamiento del sistema, desde la perspectiva de qu es lo que hace, y no de cmo lo hace. Def.: El diagrama de secuencia de un sistema es una representacin que muestra, en determinado escenario de un caso de uso, los eventos generados por actores externos, su orden y los eventos internos del sistema. Lo importante aqu son los eventos originados por los actores, que trascienden las fronteras del sistema. Los sistemas mismos son cajas negras. Recordemos el caso de uso Comprar productos:

Caso de uso: Comprar productos Cliente, cajero Actores: Primario Tipo: Descripcin: Un Cliente llega a la caja registradora con los artculos que va a comprar. El Cajero registra el cdigo de cada producto. Si hay ms de una unidad de un producto, puede registrar la cantidad. El sistema determina el precio del producto, y agrega la informacin a la transaccin actual de venta. Se muestra la descripcin del producto y el precio. Esto se repite para todos los artculos. Al final, el cajero cobra el importe. Al terminar la operacin, el Cliente se marcha con los productos. El siguiente diagrama de secuencia describe el caso de uso Comprar productos. En estos diagramas el tiempo avanza hacia abajo, y el orden de los eventos debera seguir el orden indicado en el caso de uso correspondiente.

En el diagrama anterior, se indica que el Cajero es el nico actor, y que se generan los eventos del sistema: pasarProducto, terminarVenta y efectuarPago. Def.: Un evento es un hecho externo de entrada, que un actor produce en el sistema. Cada evento da origen a una operacin del sistema como respuesta. En el ejemplo anterior, se tienen tres eventos: pasarProducto, terminarVenta y efectuarPago. Los eventos y las operaciones del sistema tienen el mismo nombre, por ejemplo, cuando el cajero genera un evento de pasarProducto, causa que en el sistema se ejecute la operacin pasarProducto. Una vez que se identifican los eventos, se "registran" en la entidad que corresponda, como operaciones. Por ejemplo:

En esta notacin UML los parmetros son opcionales. Es conveniente que los nombres de los eventos comiencen con un verbo, pues estn orientados a comandos del sistema. Dado que los eventos son hechos externos de entrada, es necesario definir la frontera del sistema. Por lo general la frontera ser el sistema de software (puede tambin incluir el hardware). Es en este contexto que decimos que un evento del sistema es un hecho externo que estimula directamente al software. Observe que la representacin del tipo Sistema es muy diferente a lo que se expres en el modelo conceptual. Los elementos del modelo conceptual representan conceptos del mundo real, en cambio, el tipo Sistema es un concepto artificial. Adems muestra las operaciones que realiza. Esto se debe a que,

a diferencia del modelo conceptual, que representa informacin esttica, estamos ahora describiendo el comportamiento del sistema, que es informacin dinmica. En el caso de uso anterior (Comprar productos) lo primero que se hace es determinar los actores que interactan directamente con el sistema de software. En este caso, el cliente interacta con el cajero, pero no directamente con el software TPV. Es el cajero quien interacta con el software. Por tanto, el cliente no genera eventos en el sistema. A veces es conveniente mostrar algunos fragmentos del texto del caso de uso dentro del diagrama de secuencia. Por ejemplo:

Contratos Antes de construir el diseo lgico que dice cmo funcionar la aplicacin de software, es conveniente definir su comportamiento como una caja negra. El comportamiento del sistema es una descripcin de lo que hace, y no de cmo lo hace. Los contratos son documentos tiles para describir estos comportamientos, a partir de las operaciones del sistema o eventos. Un contrato ve las relaciones entre los proveedores y sus clientes como un acuerdo formal, que expresa los derechos y obligaciones de cada parte. La correctitud de un programa es algo relativo, y depende en gran parte de la especificacin. Una frmula de correccin (o tripleta de Hoare) es una expresin de la forma:
(1) {P} A {Q}

La frmula de correccin anterior se lee: una ejecucin de A que comience en un estado en el que se cumpla P terminar en un estado en el que se cumple Q. Aqu A denota una operacin. P y Q se denominan aserciones, de las cuales P ser la pre-condicin y Q ser la post-condicin. Ejemplo:
{x >= 9} x := x + 5 {x >= 13}

En este caso, una post-condicin ms fuerte sera {x >= 14}. Las condiciones ms fuertes acotan ms el resultado. Una condicin ms dbil hace lo contrario, por ejemplo: {x >= 10} es una postcondicin ms dbil, pero para nuestros efectos, no es muy til. La pre-condicin establece las propiedades que se tienen que cumplir cada vez que se ejecute el procedimiento. La post-condicin establece las propiedades que debe garantizar el procedimiento cuando termine. La propiedad de que un programa satisfaga su especificacin, si termina, se conoce como correccin parcial. Si un programa satisface su especificacin y termina, se dice que es totalmente correcto (total correccin implica adems terminacin).

Las aserciones permiten, a quienes desarrollan software, construir programas correctos, y documentar por qu son correctos. Ejemplo: Si una funcin raz cuadrada sqrt(int x) que produce un nmero real como resultado, tiene como pre-condicin que el valor de x tiene que ser mayor que cero, el programador puede escribir el algoritmo sin preocuparse del caso en que x sea negativo. El mtodo de diseo por contrato va ms all. Escribir esta rutina de la forma:
if x < 0 then // Tratar el error de alguna manera else // Proceder con el clculo de la raz cuadrada end

no slo es innecesario, sino inaceptable! Def.: Principio de no redundancia. Bajo ninguna circunstancia debe, el cuerpo de la rutina, verificar el cumplimiento de la pre-condicin de la rutina. Esto ltimo es contrario a lo que proponen la mayora de libros de texto en ingeniera de software: es mejor comprobar demasiado, que demasiado poco (este ltimo principio es comnmente llamado programacin defensiva). El diseo por contrato invita a identificar las condiciones de consistencia que son necesarias para el funcionamiento correcto de cada cooperacin cliente-proveedor (cada contrato) y a especificar, para cada una de estas condiciones, de quin es la responsabilidad de asegurar la misma: del cliente o del proveedor. Contratos para las operaciones Para ayudar a explicar lo que una operacin (o evento del sistema) se propone hacer, es conveniente usar contratos. Un contrato de operacin del sistema describe los cambios de estado del sistema total cuando se llama a una de sus operaciones. Por ejemplo, para la operacin pasarProducto se puede definir el siguiente contrato: Contrato pasarProducto(cdigo:nmero, cantidad:entero) Nombre: Responsabilidades: Capturar (registrar) la venta de un producto y agregarla a la venta. Desplegar la descripcin y el precio del producto. Sistema. Tipo: Funciones del sistema: R1.1, R1.3, R1.9. Referencias Casos de uso: Comprar productos. cruzadas: Utilizar acceso super-rpido a la base de datos. Notas: Si el cdigo no es vlido, indicar que se cometi un error. Excepciones: El sistema conoce el cdigo. Precondiciones: Postcondiciones: Si se trata de una nueva venta, se crea una Venta (creacin de instancia). Si se trata de una nueva venta, la nueva Venta fue asociada a TPV (asociacin formada). Se cre una instancia de VentasLneadeProducto (creacin de instancia). Se asoci una instancia de VentasLneadeProducto a la Venta (asociacin formada). Se asign cantidad a VentasLneadeProducto.cantidad (modificacin de atributo). Se asoci una instancia VentasLneadeProducto a la instancia EspecificacindeProducto, basado en la correspondencia del cdigo (asociacin formada).

Algunas recomendaciones para la elaboracin de los contratos: 1. Identificar las operaciones a partir de los diagramas de secuencia. 2. Elaborar un contrato por cada operacin. 3. Redactar inicialmente la seccin de Responsabilidades. Luego se describe informalmente el propsito de la operacin. 4. Se completa la seccin de Postcondiciones, describiendo en forma declarativa los cambios de estado de los objetos en el modelo conceptual. 5. Para describir las Postcondiciones utilice las siguiente categoras: creacin y eliminacin de instancias, modificacin de los atributos, asociaciones formadas y canceladas. Los contratos para terminarVenta, efectuarPago e inicio son los siguientes: Contrato terminarVenta( ) Nombre: Responsabilidades: Registrar que es el final de la captura de los productos de la venta y desplegar el total de la venta. Sistema. Tipo: Funciones del sistema: R1.2. Referencias Casos de uso: Comprar productos. cruzadas: Notas: Si no est realizndose una venta, indicar que se cometi un error. Excepciones: Se est realizando una venta. Precondiciones: Postcondiciones: Estableci Venta.estaTerminada en verdadero (modificacin de atributo). Contrato efectuarPago(monto:nmero) Nombre: Responsabilidades: Registrar el pago, calcular el saldo, imprimir la boleta. Sistema. Tipo: Funciones del sistema: R2.1. Referencias Casos de uso: Comprar productos. cruzadas: Notas: Si la venta no est concluida, indicar que se cometi un error. Excepciones: Precondiciones: Postcondiciones: Se cre un Pago (creacin de instancia). Se asign a Pago.montoOfrecido el valor de monto (modificacin de atributo). Se asoci el Pago a la Venta (relacin formada). Se asoci la Venta a la Tienda para agregarla al registro histrico de las ventas terminadas (relacin formada). Contrato inicio( ) Nombre: Responsabilidades: Iniciar el sistema. Sistema. Tipo: Referencias cruzadas: Notas: Excepciones:

Precondiciones: Postcondiciones:

Se cre una instancia de Tienda, TPV, CatlogodeProductos, y EspecificacindeProducto (creacin de instancias). Se asoci CatlogodeProductos a EspecificacionesdeProducto (asociacin formada). Se asoci Tienda a CatlogodeProductos (asociacin formada). Se asoci Tienda a TPV (asociacin formada). Se asoci TPV a CatlogodeProductos (asociacin formada).

Otros diagramas de secuencia del sistema son los siguientes:

Pago con tarjeta de crdito

Pago con cheque

Con estos nuevos diagramas de secuencia, se agregan nuevas operaciones del sistema (o eventos): efectuarPagoTarjeta, respuestaCredito, efectuarPagoCheque, respuestaCheque. Con estos nuevos eventos, la lista de operaciones del sistema crece:

Los nuevos contratos seran los siguientes: Contrato efectuarPagoTarjeta(num:nmero, fechaVencimiento:fecha) Nombre: Responsabilidades: Crear y solicitar autorizacin de un pago con tarjeta de crdito. Sistema. Tipo: Una solicitud de pago con tarjeta se enva al servicio de autorizacin de crdito. Salida: Se termin la venta actual. Precondiciones: Postcondiciones: Se cre un pagoTarjeta pgo. Se asoci el pgo con la Venta actual. Se cre una tarjetaCrdito tc con tc.numero = tc.Num, tc.fechaVencimiento = fechaVencimiento. Se asoci tc a pgo. Se cre una solicitudPagoTarjeta spt. Se asoci spt a servicioAutorizacionCredito. Contrato respuestaCredito(respuesta:respuestaPagoTarjeta) Nombre: Responsabilidades: Atender la respuesta del servicio de autorizacin de crdito. Si la respuesta es positiva, se concluye la venta y se registra el pago en las cuentas por cobrar. Sistema. Tipo: Si se aprueba la solicitud, la respuesta se enva a cuentas por cobrar. Salida: La solicitud de pago con tarjeta se envi al servicio de autorizacin de crdito. Precondiciones: Postcondiciones: Si la respuesta fue positiva: Se cre una aprobacin respuestaPagoTarjera. Se asoci aprobacin a cuentasPorCobrar. Se asoci la Venta a la Tienda para incorporarla al registro histrico de ventas terminadas. Si la respuesta fue negativa: Se cre una reprobatoria respuestaPagoTarjeta. Diagramas de estado Los diagramas de estado describen grficamente los eventos y los estados de los objetos. Los diagramas de estado son tiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso.

Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condicin de un objeto en un momento determinado: el tiempo que transcurre entre eventos. Una transicin es una relacin entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente. En UML, los estados se representan mediante valos. Las transiciones se representan mediante flechas con el nombre del evento respectivo. Se acostumbra poner un estado inicial (crculo negro). Por ejemplo:

Un diagrama de estado representa el ciclo de vida de un objeto: los eventos que le ocurren, sus transiciones, y los estados que median entre estos eventos. En particular, es til hacer diagramas de estado para describir la secuencia permitida de eventos en los casos de uso. Por ejemplo, en el caso de uso comprarProductos no est permitido efectuar pagoTarjeta mientras no haya ocurrido el evento terminarVenta. Un diagrama de estado que describe los eventos globales del sistema y su secuencia en un caso de uso es un diagrama de estado para casos de uso. Por ejemplo, una versin simplificada del diagrama de estados para el caso de uso comprarProductos es el siguiente:

Una versin ms completa del diagrama anterior se muestra en la siguiente figura:

El diagrama anterior aun no est completo, pues falta considerar algunos casos excepcionales, como por ejemplo, si al rechazar una tarjeta de crdito o un cheque, el cliente decide pagar usando otro mtodo, por ejemplo pagando en efectivo. Una transicin puede tener una proteccin condicional, o prueba booleana, que permite pasar al siguiente estado solamente si esta proteccin es vlida. Estas protecciones se colocan entre parntesis debajo de los eventos (ver validacin del usuario al descolgar el auricular, en la siguiente figura). Tambin se pueden tener sub-estados anidados.

Las herramientas usadas en la etapa de anlisis (investigacin del problema) se pueden resumir en la siguiente tabla. Herramienta de anlisis Preguntas que responde Casos de uso Modelo conceptual Diagramas de secuencia Contratos Cules son los procesos del dominio? Cules son los conceptos, los trminos? Cules son los eventos y las operaciones del sistema? Qu hacen las operaciones del sistema?

Casos de uso reales Los casos reales de uso representan un diseo concreto de cmo se va a realizar el caso, a partir de una tecnologa particular. Por ejemplo, si se necesita una interfaz grfica de usuario, se deben incluir diagramas de las ventanas requeridas. Los diagramas de ventanas de todos los casos de uso, as como el modelo de navegacin de stas, constituye la versin "en papel" del primer prototipo del sistema. Para la creacin de los casos de uso reales, se refinan los casos esenciales creados en la etapa de anlisis. Diagramas de colaboracin Los contratos muestran qu hacen las operaciones del sistema, pero no muestran cmo los objetos de software van a cumplir con ellas. Los diagramas de interaccin (diagramas de secuencia o diagramas de colaboracin) explican grficamente cmo los objetos interactan a travs de mensajes para realizar las tareas. Antes de definir estos diagramas, hay que generar el modelo conceptual, los contratos de operacin y los casos de uso reales (estos ltimos se generan a partir de los casos de uso definidos en el anlisis). Los diagramas de colaboracin explican grficamente las interacciones entre las instancias del modelo (objetos). Por ejemplo:

El punto de partida de las interacciones son las poscondiciones de los contratos de operacin. El siguiente ejemplo muestra el diagrama de colaboracin de la operacin efectuarPago.

Los diagramas de interaccin constituyen una de las herramientas ms importantes para el anlisis y diseo orientado a objetos. El tiempo y esfuerzo dedicado a la preparacin de stos, corresponde a un porcentaje considerable de la actividad total del proyecto. Notacin: Para representar grficamente el hecho de que un mensaje devuelva un valor, se puede hacer de la siguiente manera:

Notacin: Un objeto puede enviarse un mensaje a si mismo:

Tambin es posible indicar el nmero de veces (iteraciones) que un mensaje va a ser enviado. Por ejemplo, el siguiente mtodo:
msg1() { for i := 1 to 10 { miB.mens2(); miC.mens3(); } }

puede ser representado mediante el siguiente diagrama:

Notacin: El siguiente ejemplo muestra la forma de definir la secuencia de los mensajes dentro de un diagrama de colaboracin.

Notacin: Es posible definir mensajes condicionales. Para esto, se define la condicin entre corchetes, y el mensaje se enva solamente si la condicin es verdadera. Por ejemplo:

Notacin: Es posible definir trayectorias condicionales mutuamente excluyentes. Por ejemplo:

Notacin: Un multiobjeto, o conjunto de instancias (por ejemplo un arreglo en Java), se dibuja en forma de pila. Por ejemplo:

De esta forma, tambin podemos enviar mensajes a multiobjetos. Por ejemplo:

La siguiente figura muestra cmo enviar mensajes para crear una instancia de un objeto, y agregarla a un multiobjeto.

Tambin es posible enviar mensajes a la clase y no a una instancia, con el fin de llamar a mtodos de la clase. Por ejemplo:

Las herramientas utilizadas en las etapas anteriores se pueden resumir en la siguiente tabla: Herramienta Requerimientos Casos de uso Preguntas que responde Cules son las necesidades o deseos del producto? Cules son los procesos del dominio?

Modelo conceptual Diagramas de secuencia Contratos Diagramas de estado

Cules son los conceptos, los trminos? Cules son los eventos y las operaciones del sistema? Qu hacen las operaciones del sistema? Cules son los estados de los objetos en los eventos?

Diagramas de colaboracin Cmo hacen los objetos para cumplir con las operaciones? Un sistema orientado a objetos se compone de objetos que envan mensajes a otros objetos para que lleven a cabo ciertas operaciones. Cada clase de objetos tiene ciertas responsabilidades, que son cumplidas a travs de sus mtodos, y por la forma en que colabora con las otras clases de objetos. Decisiones poco acertadas sobre la asignacin de responsabilidades de cada clase, dan origen a sistemas y componentes frgiles y difciles de mantener, entender, reutilizar o extender. Veremos algunos patrones que se pueden aplicar durante la elaboracin de los diagramas de interaccin, al asignar las responsabilidades a los objetos y al disear la colaboracin entre ellos. Responsabilidades Las responsabilidades se relacionan con las obligaciones de un objeto respecto de su comportamiento. Estas responsabilidades pertenecen, esencialmente, a dos categoras: conocer y hacer. Entre las responsabilidades de un objeto relacionadas con el hacer se encuentran: Hacer algo en uno mismo. Iniciar una accin en otros objetos. Controlar y coordinar actividades en otros objetos. Entre las responsabilidades de un objeto relacionadas con el conocer se encuentran: Estar enterado de los datos privados encapsulados. Estar enterado de la existencia de objetos conexos. Estar enterado de cosas que se pueden derivar o calcular. Las responsabilidades se asignan a los objetos durante el diseo orientado a objetos. Por ejemplo, podra decirse que una Venta es responsable de imprimirse ella misma (un hacer), o que una Venta tiene la obligacin de conocer su fecha (un conocer). Responsabilidad no es lo mismo que mtodo: los mtodos se usan para cumplir con las responsabilidades. stas se implementan usando mtodos que operen solos o en colaboracin con otros mtodos y objetos. As por ejemplo, la clase Venta podra definir uno o varios mtodos para imprimir una instancia Venta (por ejemplo el mtodo imprimir). Para hacer esto, Venta puede colaborar con otros objetos, por ejemplo, enviando mensajes a VentasLineadeProducto para que se impriman ellos mismos. Los diseadores expertos en orientacin a objetos, van formando un amplio repertorio de principios generales que los guan al crear software. Estos principios son llamados patrones, y se codifican en un formato estructurado que describe el problema y su solucin. Cada patrn tiene un nombre. Los patrones no se proponen descubrir ni expresar principios nuevos en Ingeniera de Software. Todo lo contrario, intentan codificar el conocimiento y los principios ya existentes: cuanto ms generalizados y usados, mejor. Cinco patrones tiles para la asignacin de responsabilidades son: Experto, Creador, Controlador, Bajo acoplamiento y Alta cohesin. A continuacin se describen estos patrones.

El patrn Experto [Larman 98] Nombre: Problema: Experto. Cul es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseo orientado a objetos? Un modelo de clase puede definir docenas y hasta cientos de clases de software, y una aplicacin tal vez requiera el cumplimiento de cientos o miles de responsabilidades. Durante el diseo orientado a objetos, cuando se definen las interacciones entre los objetos, se toman decisiones sobre la asignacin de responsabilidades a clases. Si se hace en forma adecuada, los sistemas tienden a ser ms fciles de entender, mantener y ampliar, y se nos presenta la oportunidad de reutilizar los componentes en futuras aplicaciones. Asignar una responsabilidad al experto en informacin: la clase que cuenta con la informacin necesaria para cumplir la responsabilidad. En la aplicacin del punto de venta, alguna clase necesita conocer el gran total de la venta.

Solucin: Ejemplo:

Beneficios: Se conserva el encapsulamiento, ya que los objetos se valen de su propia informacin para hacer lo que se les pide. Esto provee un bajo nivel de acoplamiento, lo que favorece el hecho de tener sistemas ms robustos y de fcil mantenimiento. El comportamiento se distribuye entre las clases que cuentan con la informacin requerida, lo que ayuda a definir clases "sencillas" y ms cohesivas, que son ms fciles de comprender y mantener. A partir de esta recomendacin, se puede plantear la pregunta: Quin es el responsable de conocer el gran total de la venta? Desde el punto de vista del patrn Experto, deberamos buscar la clase de objetos que posee la informacin necesaria para calcular el total. Por ejemplo:

Qu informacin hace falta para calcular el gran total? Hay que conocer todas las instancias VentaLineadeProducto de una venta, y la suma de sus subtotales, y esto lo conoce nicamente la instancia Venta. Por tanto, desde el punto de vista del Experto, Venta es la clase de objetos correcta para asumir esta responsabilidad. Venta es el experto en informacin. Entonces:

Todava no terminamos. Qu informacin hace falta para determinar el subtotal de la lnea de productos? Se necesitan VentasLineadeProducto.cantidad y EspecificaciondeProducto.precio. VentasLineadeProducto conoce su cantidad y su correspondiente EspecificaciondeProducto. Por tanto, desde la perspectiva del patrn Experto, VentasLineadeProducto debera calcular el subtotal.

VentasLineadeProducto no puede cumplir la responsabilidad de conocer y dar el subtotal, si no conoce el precio del producto. EspecificaciondeProducto es un Experto en informacin para contestar su precio. Por tanto, habr que enviarle un mensaje preguntndole el precio.

En conclusin, para cumplir con la responsabilidad de conocer y dar el total de la venta, se asignaron tres responsabilidades a las tres clases de objetos: Clase Venta VentasLineadeProducto Responsabilidad Conoce el total de la venta Conoce el subtotal de la lnea de producto

EspecificaciondeProducto Conoce el precio del producto Note que el cumplimiento de una responsabilidad requiere a menudo informacin distribuida en varias clases de objetos. Es decir, hay muchos "expertos parciales" que colaboran en la tarea. Cuando la informacin se encuentre esparcida entre varios objetos, stos tendrn que interactuar a travs de mensajes para compartir el trabajo. El patrn Creador [Larman 98] El patrn Creador gua la asignacin de responsabilidades relacionadas con la creacin de objetos, tarea muy frecuente en los sistemas orientados a objetos. El objetivo de este patrn es encontrar un creador que debemos conectar con el objeto producido en cualquier evento.

Nombre: Problema:

Creador. Quin debera ser responsable de crear una nueva instancia de alguna clase? La creacin de objetos es una de las actividades ms frecuentes en un sistema orientado a objetos. En consecuencia, conviene contar con un principio general para asignar las responsabilidades concernientes a ella. El diseo, bien asignado, puede apoyar un bajo acoplamiento, una mayor claridad, el encapsulamiento y la reutilizacin.

Solucin:

Asignarle a la clase B la responsabilidad de crear una instancia de la clase A en uno de los siguientes casos: B agrega los objetos de A. B contiene los objetos de A. B registra las instancias de los objetos de A. B tiene los datos de inicializacin que sern enviados a A cuando este objeto sea creado (B es un experto respecto a la creacin de A). B es un creador de los objetos A. Si existe ms de una opcin, prefiera la clase B que agregue o contenga la clase A.

Ejemplo:

En la aplicacin del punto de venta, quin debera encargarse de crear una instancia de VentasLineadeProducto? Desde el punto de vista del patrn Creador, deberamos buscar una clase que agregue, contenga, y realice otras operaciones sobre este tipo de instancias.

Beneficios: Se brinda apoyo a un bajo acoplamiento, lo cual supone menos dependencias respecto al mantenimiento y mejores oportunidades de reutilizacin. Una Venta contiene (en realidad, agrega) muchos objetos VentasLineadeProducto. Es por esto que el patrn Creador sugiere que Venta es la clase idnea para asumir la responsabilidad de crear las instancias de VentasLineadeProducto. Esta asignacin de responsabilidades requiere definir en Venta un mtodo para hacerLineadeProducto.

El patrn Controlador [Larman 98] Nombre: Problema: Controlador. Quin debera encargarse de atender un evento del sistema?

Un evento del sistema es un evento de alto nivel generado por un actor externo. Es un evento de entrada externa. Se asocia a operaciones del sistema: las que se emiten en respuesta a los eventos del sistema. Por ejemplo, cuando un cajero que usa una

terminal de punto de venta oprime el botn "terminar venta", est generando un evento sistmico que indica que "la venta ha terminado". Del mismo modo, cuando alguien que usa un editor de texto pulsa el botn "revisar ortografa", est produciendo un evento del sistema. Un controlador es un objeto de interfaz que se encarga de manejar un evento del sistema. Define adems el mtodo de su operacin. Solucin: Asignar la responsabilidad del manejo de mensajes de los eventos del sistema a una clase que represente alguna de las siguientes opciones: El "sistema" global (controlador de fachada). La empresa u organizacin global (controlador de fachada). Algo en el mundo real que es activo (por ejemplo el rol de una persona) y que pueda participar en la tarea (controlador de tareas). Un manejador artificial de todos los eventos del sistema de un caso de uso (controlador de casos de uso). Utilice la misma clase controlador con todos los eventos del sistema en el mismo caso de uso. Ejemplo: En la aplicacin del punto de venta se dan varias operaciones del sistema, como terminarVenta(), pasarProducto(), efectuarPago().

Beneficios: Garantiza que la empresa o los procesos de dominio sean manejados por la capa de los objetos del dominio y no por la interfaz. Durante el anlisis del comportamiento del sistema, sus operaciones son asignadas al tipo Sistema, para indicar que son operaciones del sistema.

Pero esto no significa que una clase llamada Sistema las ejecuta durante el diseo. Durante el diseo, a la clase Controlador se le asigna la responsabilidad de las operaciones del sistema. Quin debera ser el controlador de eventos sistmicos como pasarProducto y terminarVenta? Segn el patrn Controlador, disponemos de las siguientes opciones: TPDV Tienda Cajero Representa el "sistema" global. Representa la empresa u organizacin global. Representa algo en el mundo real que est activo (por ejemplo el rol de una persona) y que puede intervenir en la tarea.

ManejadordeComprar- Representa un manejador artificial de todas las operaciones del sistema de un Productos caso de uso.

Las operaciones del sistema, detectadas en el anlisis, se asignarn a TPDV.

La mayor parte de los sistemas reciben eventos de entrada externa, los cuales generalmente incluyen una interfaz grfica para el usuario (GUI), operada por una persona. Otros medios de entrada son los mensajes externos, o seales procedentes de censores. En todos estos casos, hay que elegir los controladores que manejan estos eventos de entrada. La misma clase controlador debera usarse con todos los eventos sistmicos de un caso de uso. Esto es til por ejemplo para detectar eventos del sistema fuera de secuencia (por ejemplo, una operacin efectuarPago antes de terminarVenta). La primera categora de controlador, es un controlador de fachada, que representa al "sistema" global. Es una clase que, para el diseador, representa de alguna manera al sistema entero. Si se recurre a la cuarta categora de controlador (un "manejador artificial de casos de uso"), habr entonces un controlador para cada caso. Este no es un objeto del dominio, es un concepto artificial. Por ejemplo, si la aplicacin de punto de venta contiene casos como "Comprar Productos" y "Devolver Productos", habr una clase ManejadordeComprarProductos y una clase ManejadordeDevolverProductos. Un controlador de casos de uso es una buena alternativa cuando hay muchos eventos de sistema entre varios procesos: asigna su manejo a clases individuales controlables. El patrn Bajo acoplamiento [Larman98] Nombre: Bajo acoplamiento.

Problema: Cmo dar soporte a una mnima dependencia y a un aumento en la reutilizacin? El acoplamiento mide qu tan fuerte est una clase conectada con otras (es decir, cuntas clases conoce y necesita). Una clase con bajo (o dbil) acoplamiento no depende de "muchas otras" clases. Una clase con alto (o fuerte) acoplamiento recurre a muchas otras clases. Este tipo de clase no es conveniente, pues: cambios en las clases relacionadas ocasionan cambios en la clase local; son ms difciles de entender; son ms difciles de reutilizar. Solucin: Ejemplo: Asignar una responsabilidad para mantener bajo acoplamiento. Tres de las clases de la aplicacin de punto de venta era: Pago, TPV y Venta. Supongamos que necesitamos crear una instancia de Pago y asociarla a Venta. Como TPV "registra" un Pago en el mundo real, es un buen candidato para crearlo. Ejemplo:

Esta asignacin de responsabilidades acopla la clase TPV al conocimiento de la clase Pago. Una solucin alterna sera crear Pago y asociarlo a Venta. Por ejemplo:

Este ltimo diseo es mejor porque conserva un menor acoplamiento global. El anterior es un ejemplo donde dos patrones distintos (Creador y Bajo acoplamiento) pueden sugerir soluciones distintas. Explicacin: Las formas ms comunes de acoplamiento son las siguientes: - Una clase X posee un atributo o variable de instancia que se refiere a otra instancia de clase Y. - X tiene un mtodo que referencia una instancia de clase Y. - X tiene un parmetro o una variable local de tipo Y. - El objeto devuelto en un mensaje invocado por X es una instancia de clase Y. - X es una subclase de Y. - Y es una interfaz y X la implementa. El bajo acoplamiento apoya el diseo de clases ms independientes, que reducen el impacto de los cambios, as como clases ms reutilizables. El acoplamiento no es importante si no se busca la reutilizacin. Diseo de la solucin Para cada evento del sistema se debe construir un diagrama de colaboracin cuyo mensaje inicial sea el de sus eventos. En el caso del punto de venta, tendremos cuatro diagramas, uno para cada evento: pasarProducto, terminarVenta, efectuarPago, iniciar. El diagrama de colaboracin de pasarProducto sera el siguiente:

El mtodo especificacion(cod) fue asignado a la clase CatalogodeProductos segn el patrn Experto. La asignacin de los mtodos hacerLineadeProducto(especif,cant), crear() y crear(especif,cant), fueron asignados a sus respectivas clases segn el patrn Creador. La operacin terminarVenta ocurre cuando un cajero oprime un botn para indicar la conclusin de una venta. El diagrama de colaboracin de terminarVenta para indicar que se termin de realizar la captura de productos sera el siguiente:

La asignacin del mtodo terminarVenta() a la clase TPDV fue realizada segn el patrn Controlador. La asignacin del mtodo seTermina() a la clase Venta fue realizada segn el patrn Experto. El diagrama de colaboracin de terminarVenta para calcular el total de la venta, sera el siguiente:

La asignacin del mtodo total() a la clase Venta, as como la asignacin del mtodo subtotal() a la clase VentasLineadeProducto fueron realizadas segn el patrn Experto. La operacin efectuarPago ocurre cuando un cajero captura el efectivo ofrecido por el cliente como pago de la compra. La compra en la tienda se debe registrar como terminada. El diagrama de colaboracin de efectuarPago sera el siguiente:

El mtodo efectuarPago(efectivoOfrecido) fue asignado a la clase TPDV segn el patrn Controlador. La asignacin de efectuarPago(efectivoOfrecido) a Venta, y de crear(efectivoOfrecido) a Pago se realiz segn el patrn Creador. Para asignar el mtodo agregarVenta(v) a la clase Tienda se us el patrn Experto. El siguiente diagrama de colaboracin permite conocer el saldo final de la venta, es decir, el monto pagado menos el total de la venta:

Finalmente, la operacin Iniciar representa, en forma abstracta, la fase inicializadora de la ejecucin al comenzar la aplicacin. Este proceso, por lo general, debe crear el objeto inicial del dominio. Adems, es posible que tambin ejecute algn otro proceso. Antes de ver el diagrama de colaboracin de Iniciar, revisemos el patrn MVC. Este es un patrn arquitectural (patrones del ms alto nivel). Nombre: Problema: Modelo-Vista-Controlador (MVC) [Buschmann 96]. Las interfaces de usuario son especialmente propensas a cambios de requerimientos. Cuando se extiende la funcionalidad de una aplicacin, se deben modificar cosas, como por ejemplo: mens, botones, ventanas, etc. MVC divide una aplicacin en tres reas: procesamiento, entrada y salida. El componente modelo encapsula los datos y la funcionalidad principales de la aplicacin. El componente Vista despliega la informacin al usuario, a partir de los datos del Modelo. Cada Vista tiene un componente Controlador asociado, que se encarga de recibir las entradas del usuario (usualmente en forma de eventos como: movimiento del mouse, activacin de los botones del mouse, o entradas de teclado). Esta separacin de componentes, permite, entre otras cosas, tener distintas vistas del mismo modelo. La mayora de aplicaciones con interfaz grfica utilizan este esquema. La programacin con herramientas visuales como Visual Basic, JBuilder, Delphi, etc. sigue este esquema.

Solucin:

Ejemplo:

Beneficios: Es posible tener mltiples vistas de un mismo modelo. Es posible sincronizar las vistas cuando varios usuarios usan la misma aplicacin (juegos multiusuario, sistemas colaborativos, etc). La separacin conceptual permite intercambiar la vista y el controlador de un determinado modelo (plug and play).

El patrn MVC separa dos conceptos fundamentales en toda aplicacin: la interfaz (vista y controlador) y el modelo (datos y funcionalidad). Al usar este patrn, podramos implementar la interfaz de nuestra aplicacin de punto de venta como un applet Java, como un programa Java standalone, y de otras formas (no necesariamente en Java). Desde esta interfaz se invocara el llamado del mtodo Iniciar, que debera realizar las siguientes acciones (segn su contrato): Crear Tienda, TPV, CatalogodePooductos y EspecificaciodeProducto; Asociar Tienda a CatalogodeProductos; Asociar Tienda a TPV; Asociar TPV a CatalogodeProductos. Esto se muestra en el siguiente diagrama:

Adems, si desarrollramos la interfaz como un applet Java (por ejemplo), deberamos desde la interfaz crear la instancia de Tienda, y solicitar a esta instancia de Tienda una referencia a la correspondiente instancia de TPDV creada. Esto para conectar la capa de presentacin con la capa de dominio.