miércoles, 30 de marzo de 2011

Aplicación de Patrones de Diseño

Talle de Programación Orientada a Objetos - Semana 9 - Reporte 8

BUILDER PATTERN (Constructor)

Las partes de mi código que encajan con las especificaciones del patrón Builder son:


- Constructor: Mi clase Billing proporciona la interfaz y funciones para generar la factura.
- Constructor Concreto: En éste caso se trata del constructor de la Factura, el cual ensambla las partes individuales.
- Director: .
- Parte: Las partes son el Proveedor, Origen, Destino y Orden.
- Producto: El producto es la Factura.

En mi caso el primer paso es generar la factura al pedir los datos. Mi constructor sera Billing y su método makeNewBill() para construir la factura

Posterior se envían los objetos individuales al constructor de la clase Bill() :


Y el producto final es una Factura la cual se imprime en pantalla:


A partir de este producto es posible generar varios productos distintos, pues es posible imprimir la Factura, exportarla a otro formato como PDF, o generar la factura electrónica.


COMPOSITE PATTERN (Compuesto)

El Patrón compuesto lo aplique al momento de pedir los datos de cada objeto individual, cada campo que es necesario para generar ya sea el Origen, Destino ú Orden; son hojas del objeto indiviual; y cada objeto individual (pero compuesto) se vuelve hoja de lo que es la Factura principal.


Se envían los objetos a la factura y después la factura se puede guardar en la base de datos.

En éste caso el patrón compuesto se combina con el patrón constructor para generarla factura.

ITERATOR (Iterador)

Por último, en el proyecto solo he aplicado un iterador, en esté caso la función del iterador es la de ingresar a la orden del cliente para imprimir en pantalla los conceptos a facturar.


Falta implementar algunos iteradores más, porque necesito tener la capacidad de modificar los datos de la orden o agregar nuevos datos.

La implementación de los patrones fue algo complicada, de hecho siento que "emule" a los patrones y no los aplique concretamente ya que en cierto momento mi código no compiló y trate de tener algo sólido para presentar.

SALUDOS

Identificación de Patrones Diseño

Programación Orientada a Objetos - Semana 9 - Reporte 8




Un patrón es algún evento, suceso, objeto, en sí cualquier cosa que se repite en el tiempo.
Por ejemplo, en una fábrica se pueden producir diferentes tipos de artículos, por ejemplo, un jabón. El producto puede ir desde un jabón neutro, hasta uno aromatizado. Para todos se sigue un patrón el cual varía solamente al final, cuando se generan productos concretos desde un producto base. Entonces, se puede decir que el patrón es toda la línea de producción, ya que es un proceso recurrente que tiene como resultado uno o varios productos.

El mundo del software no es la excepción, existen problemas recurrentes a los cuales puede aplicarse un patrón, dichos patrones reciben el nombre de Patrón de Diseño.

"Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software. Son una descripción de clases y objetos comunicándose entre sí adaptada para resolver un problema de diseño general en un contexto particular."

Los patrones nos brindan soluciones (probadas) a problemas en el desarrollo de software los cuales están sujetos a contextos similares. Por ejemplo, un software de llenado se formas, recibos, facturas, cheques, etcétera, todos pueden tener una finalidad diferente, pero todos tienen un patrón parecido para el llenado de información por lo que su codificación puede ser parecida o la misma; a todos los anteriores se les puede aplicar un patrón de diseño igual.

Existen tres clases de patrones de diseño:

De creación: conciernen al proceso de creación de objetos.
De estructura: tratan la composición de clases y/o objetos.
De comportamiento: caracterizan las formas en las que interactúan y reparten responsabilidades las distintas clases u objetos.

Algunas de las ventajas de usar patrones de diseño son:

Indican cómo resolver un problema particular utilizando un pequeño número de clases relacionadas de forma determinada, pero no indican cómo diseñar un sistema completo, sino sólo aspectos puntuales del mismo.
Facilitan la re utilización de las clases y del propio diseño.
La propia estructura del patrón es reutilizada cada vez que se aplica.

A pesar de ser muy útiles, rara vez se nota su efecto sobre el código y es casi imposible saber que patrón fue utilizado en su desarrollo. También suele ser necesario programas más clases que las necesarias y se produce una sobrecarga en el código

IDENTIFICACIÓN EN EL PROYECTO

Encontré dos patrones que pueden aplicarse al proyecto:

BUILDER PATTERN (Constructor - Tipo Creacional)



Es un patrón de diseño creacional. Separa la construcción de un objeto complejo y a partir de ese proceso se pueden generar distintas representaciones de dicho objeto.

Para aplicar éste patrón se necesita:

- Constructor: especifica una interfaz abstracta para crear un objeto complejo Producto.
- Constructor Concreto: construye y ensambla las partes del Producto implementando la interfaz de Constructor.
- Director: obtiene las partes que forman el Producto y lo construye usando la interfaz de Constructor.
- Parte: representa las partes que se usan para construir el Producto.
- Producto: representa el objeto complejo en construcción.

Yo lo puedo utilizar al generar una factura ya que la generación de una factura necesita un proceso de llenado de formas, esta es la base o patrón.
Además necesito primero generar las partes que componen una factura:

1. Crear el proveedor del servicio.
2. Crear el origen de la carga.
3. Crear el destino de la carga.
4. Crear el pedido (que contiene la carga)
5. Realizar los cálculos (totales, descuentos, impuestos)
6. Armar la factura.
7. Exportar a PDF ó Generar factura electrónica ó Generar una factura impresa.

Como se puede observar, primero se sigue un mismo patrón, dividiendo un objeto complejo en pequeñas partes para posteriormente juntarlas y obtener un producto.
Después con el mismo patrón puedo obtener diferentes presentaciones del mismo producto

COMPOSITE PATTERN (Compuesto - Tipo Estructural)



El Patrón compuesto realiza una jerarquización en forma de "árbol" entre los objetos y así mostrar una relación parte-todo. Incluso se pueden tomar las variables de un objeto como nodos hoja las cuales siguen formando parte de un todo.

Este patrón se usa cuando los objetos tienen cierta jerarquía en el código y cuando ciertas operaciones se realizan en uno o varios objetos.

Una de las formas en que yo puedo utilizar este patrón es al momento de tomar los datos del cliente:

Como pueden ver en la imagen de ejemplo, cada campo de una forma es una hoja, una parte individual de un todo, 2 o más de dichos campos generan un objeto compuesto y así sucesivamente hasta llegar al producto final, es éste caso, una forma.

En mi caso la secuencia sería la siguiente:

1. Los campos para los datos del Origen.
2. Los campos para los datos del Destino.
3. Los campos para tomar la Orden.

En éste caso, los campos son las hojas de los objetos compuestos (Origen, Destino, Orden)

4. Los objetos que forman una Factura.

Origen, Destino y Orden son "hojas" de un objeto compuesto, la factura.

5. Las facturas que forman al objeto compuesto, base de datos.

Todas las facturas son hojas de una base de datos.

El Patrón Compuesto es bueno usarlo cuando necesitamos implementar un código que necesite agregar, remover, borrar, modificar, guardar, etcétera; algún dato u objeto, es decir, cuando se implementa algo parecido a una base de datos o un registro.

ITERATOR (Iterador - De comportamiento)

Posiblemente lo usemos y no nos demos cuenta, es un buen patrón de diseño cuando necesitamos acceder a información de manera secuencial.

- Cuando se quiere acceder al contenido de un objeto agregado sin revelar su representación interna.-
- Cuando se quiere permitir múltiples tipos de recorridos sobre objetos agregados.
- Cuando se quiere proporcionar una interfaz uniforme para recorrer diferentes estructuras de agregación.

Éste patrón lo utilizo en cierto momento de mi código, cuando necesito accesar a los datos que almacene en la Orden, mi objeto Orden es una lista de Conceptos a facturar, entonces yo necesito accesar a dicha lista por medio de un iterador para observar las características de cada uno.

También necesito accesar a la información de la base de datos una vez que la almaceno temporalmente en el programa.
Cuando implemente la búsqueda de Clientes o Facturas, necesitaré almacenar todas las coincidencias en una lista temporal, y posteriormente accesar a ella mediante un Iterador para observar el objeto buscado.

Bueno amigos, estos son los Patrones de Diseño que relaciono con mi proyecto, además, espero que les sea útil la información y para posteriores referencias les dejo las páginas que visité para saber más sobre patrones de diseño.


Y un libro que se llama PRO JavaScript Design Patterns (Ya no tengo el link pero es un libro que obtuve en PDF)

SALUDOS


jueves, 24 de marzo de 2011

Demostración de avance parcial

Taller de Programación Orientada a Objetos - Semana 8 - Reporte 7

Que tal amigos! En esta entrada voy a mostrarles una breve explicación y ejecución del código de mi proyecto.

Como recordaran, estoy realizando un Sistema de Facturación Electrónica para una empresa de logística empresarial.

Actualmente para lograr mi objetivo estoy trabajando con 5 clases:


La clase Bill que es la factura.
La clase Billing que es el módulo principal de facturación, contiene la función main por lo que es el inicio de la aplicación.
La clase Items que representa los artículos o conceptos del pedido.
La clase Order que es una lista de artículos y conceptos.
La clase Person que son las personas involucradas en la factura, Cliente y Proveedor.

En este caso vamos a analizar la clase Billing.

Lo primero que se va a realizar es generar un nuevo módulo de facturación y llamar a la función mainMenu() la cual mostrara el menú principal.




Esta pantalla muestra 3 opciones, 1. Factura 2. Base de Datos 3. Salir.





Si entramos a la opción Factura se desplegarán 3 nuevas opciones: 1. Nueva factura 2. Buscar 3. Salir.




En el menú principal, si entramos a la opción Base de Datos se desplegarán 6 nuevas opciones: 1. Ver 2. Alta 3. Baja 4. Modificar 5. Buscar 6. Salir.



Las opciones de Base de Datos solo muestran los mensajes de las acciones que se realizarán dependiendo de la opción seleccionada.




En la opción Factura del menú principal, la opción Buscar solo mostrara una impresión en pantalla indicando que una factura se buscará.
La opción Nueva Factura ira pidiendo algunos datos para generar un cliente y almacenar cada uno de los datos pedidos en los atributos del mismo.





Ahora en éste video verán la ejecución del código, debido a una falla del micrófono de mi computadora, tendremos que verlo en silencio, lo cual esta bien porque si leyeron la explicación de arriba solo basta con observar :)


Como pueden ver por ahora el diseño esta bien aunque algo simple, no obstante ya tengo los algoritmos necesarios para programar las opciones de la base de datos (alta, baja, buscar, etcétera).
Así mismo ya estoy en búsqueda de las librerías necesarias para poder exportar mis facturas a un formato electrónico y para imprimirlas físicamente.

Espero les haya gustado mi explicación y les sirva de algo mi entrada.

Saludos!! :)

martes, 22 de marzo de 2011

Presentación de Diagramas UML y de Secuencia

Programación Orientada a Objetos - Semana 8 - Reporte 7

Hola a todos!!

Estas son las diapositivas que corresponden a la presentación de mis diagramas, referentes a mi proyecto.




Este es el diagrama UML correspondiente a mi diseño actual. Cabe mencionar que con este diseño he logrado implementar algo de código que funciona correctamente.
A grandes rasgos, en primer lugar podemos ver que todas mis clases están encapsuladas dentro del paquete toBill.
(De izquierda a derecha) Posteriormente tenemos la clase Billing que por ahora funciona como la clase principal de mi programa, esta clase incluye otra llamada Proxy cuyo funcionamiento es crear un puente que comunique a la aplicación con la base de datos. Billing tiene como atributo una factura Bill.
Bill tiene como atributos un cliente, un proveedor y una orden (Client, Supplier, Order). Los métodos implementados dentro de la clase factura incluyen la capacidad de imprimirse a si misma, exportarse a otros formatos y realizar los cálculos necesarios.
La clase Person es la siguiente, de ella se dividen 2: Client y Supplier que son las 2 partes involucradas en el proceso de facturación. En esta clase se implementa un poco de herencia.
La clase siguiente es Order, la cual es una lista de Items o articulos a facturar. Order puede añadir artículos a la lista, removerlos e imprimir su contenido.
Por último tenemos a la clase Item que son cada uno de los conceptos o artículos a facturar. Se trata de nodos los cuales se van encadenando para formar una lista.



Aqui se visualiza el proceso actual que se sigue para armar una factura.
Todo comienza cuando el usuario inicia la aplicación lo cual genera un nuevo módulo de facturación Billing. Con ello se activan los métodos para continuar con el proceso.
Posteriormente se llama al método getData() el cual está dentro de Billing. getData() tomara uno a uno los datos del cliente y los irá almacenando en variables temporales; una vez terminado se generá un nuevo objeto Client y los valores de las variables temporales se envían a los atributos al constructor de Client, con lo que finaliza la primera parte que es generar el cliente.
Después, getData() comienza abriendo un ciclo con el cual se pretende pedir los artículos a facturar, el ciclo. Se genera la Order y un Item, se van pidiendo los datos del Item los cuales se almacenan en sus respectivas variables y una vez terminado, el Item se añade a la lista principal, es decir, Order.
Una vez generados estos dos objetos, se envían al constructor de Bill para generar la factura, la cual posteriormente se puede imprimir, exportar a otros formatos o guardar.


Espero le entiendan a mi presentación.
Dudas o sugerencias no duden en comentar

SALUDOS

miércoles, 16 de marzo de 2011

Código autogenerado y comparación

Taller de Programación Orientada a Objetos - Semana 7 - Reporte 6

COMPARACIÓN DE DIAGRAMAS


1. Diagrama diseñado por mi.






2. Diagrama autogenerado por mi código



Aunque en escencia son lo mismo, la verdad es que ambos difieren en varios aspectos.
Los mas importantes a resaltar son primeramente las variables. Podemos ver que en el diagrama que yo diseñe se ven las variables dentro de la cajita de las clases, pero en el diagrama autogenerado no aparecen. Esto es porque el nivel de acceso por default en el primer diagrama es "PUBLIC", mientras que en segundo diagrama mis variables estan declaradas como "PRIVATE", por eso aparecen ocultas.

Otra diferencia es la declaración de algunos métodos. Prinicipalmente los constructores de cada clase, que en el primer diagrama solo aparecen declarados y en el segundo aparecen incluso con los parámetros que éstos recibirán.

En ambos aparecen por medio de flechas con la punta en forma de rombo, las uniones de las clases que envían parámetros a otras, y el nombre de la variable arriba, debajo o a un lado de la flecha.

Para mi ambos tienen cosas que le faltan al otro. El primero muestra mas funciones, ya que es en el que estoy visualizando mi código con mas imaginación. Mientras que en el segundo me falta implementar mis ideas para que se complete correctamente.

COMPARACIÓN DEL CÓDIGO

El código fue muy diferente en ambos casos, para empezar, la autogeneración de código me produjo más clases que las que de verdad tengo y necesito, además de dividirme el proyecto en 2 partes: LogicalView (¿?) y toBill (paquete real):

Mayor cantidad de clases:
logicalview




toBill




Clases reales




Otra diferencia es que código autogenerado por el diagrama UML diseñado por mi no compilo muy bien, creo que se debío principalmente a la extraña forma en que se declaro el contructor de cada clase:

Algunos constructores autogenerados








Constructores correctos.




Otra diferencia que hay es que en lugar de tener un solo método para tomar los datos y posteriormente enviarlos al constructor, se autogeneraron varios métodos "GET" y "SET" (para tomar los datos y despues colocarlos en su atributo correspondiente).
Esto me dio un poco de desconfianza pero prefiero mi método personal el cual es más corto y funcional (en mi opinión)

Métodos SET y GET






Método getData()




Otro error visible en la autogeneración es que la clase Bill (factura) hereda los atributos de Paper (factura en papel) lo cual esta equivocado ya que es a la inversa:

Incorrecto (Autogenerado)

Correcto


Estos son los detallitos mas sobresalientes de ambos, lo demás son simples funciónes vacías las cuales ya estan completadas en mi código. Asi como espacios para los comentarios, etcétera.

SALUDOS!!!

Diagramas UML y Diagramas de Secuencia

Programación Orientada a Objetos - Semana 7 - Reporte 6

Usar diagramas UML resulta bastante útil cuando deseamos programar una aplicación bajo el paradígma orientado a objetos. Dichos diagramas nos ayudan a planear, visualizar y entender la estructura de nuestra aplicación en terminos de clases y jerarquías.

Para realizar los diagramas UML utilice la aplicación UMBRELLO, esta aplicación es capaz de generar código fuente a partir de nuestro diagrama, y viceversa.

DIAGRAMA UML

Aqui les muestro el diseño actual de mi aplicación. Todo está probado, es decir, compila y se ejecuta correctamente.


En él pueden observar la estructura principal del código que estoy implementando. Hasta arriba pueden ver que todas mis clases pertenecen al paquete toBill (facturar).
Después, en el siguiente nivel pueden ver las clases que necesito para hacer funcionar mi código, tengo primeramente la clase Billing que es el módulo principal de facturación, es decir, la clase que generará la interfaz gráfica. En esta clase se implementa otra subclase llamada Proxy que es la encargada de comunicar el módulo de facturación con la base de datos.
También necesito la factura en si, que esta representada por la clase Bill, tenemos como atributos un cliente, un proveedor y una orden (Client, Supplier, Order). Y la factura hasta ahora puede calcular sus totales y descuentos, exportarse a si misma a otros formatos e imprimirse. A partir de Bill se implementas 2 subclases más, Paper (factura en papel) y Electronic (factura digital).
También se especifica a las personas involucradas en la clase Person, la cual tiene como atributos todos los datos personales del cliente y del proveedor. Como se puede ver, apartir de esta clase se implementan dos subclases más: Supplier (o proveedor) y Client (o cliente).
Siguiendo en el segundo nivel, podemos observar la clase Order la cual tiene como atributos un Item (artículo) y numItems (número de artículos). Los métodos de la clase Order permiten: agregar artículos (add()), quitar artículos de la lista (remove()) e imprimir la lista de artículos (toPrintItems()).
Por último, la clase Items es una clase nueva, que implemente al diseñar mejor mi orden como una lista, entonces esto convierte a mis artículos en nodos de una lista. Mi orden es la lista y mis artículos los nodos. Esto me facilito mucho el diseño de la factura.
Como atributos se tiene un root que es el puntero a los nodos, el código del artículo, la descripción, la cantidad y el precio.

DIAGRAMA DE SECUENCIA

Aqui les muestro el diagrama de secuencia en el cual se detalla el proceso actual que se sigue para generar una factura. De igual forma, dicho proceso esta probado y se crean objetos completamente funcionales.



Primeramente, el Usuario va a inicializar el módulo de facturación generando un nuevo objeto Billing, como aún no tengo un menú implementado, el módulo de facturación pasa directamente a la función getData() en donde se pedirán los datos del cliente uno a uno. Después se crea el objeto Client y mediante el constructor se colocan las variables en su lugar.
Despues se va pidiendo la orden, artículo por artículo. Se crea la lista Order y se pide la información de cada Item despues de generán los Items para almacenar la información pedida y a la vez ligarlos a la lista. Mediante un loop while se van pidiendo más y más artículos hasta terminar, también podemos eliminarlos.
Por último se crea una nueva factura Bill y se le envían a su constructor la orden que acabamos de crear y el nuevo cliente. Esto da forma a la factura la cual posteriormente podemos Eliminar, guardar, imprimir o exportar

Espero les haya gustado mi explicación, y le hayan entendido. A mis colegas que estamos compartiendo la misma idea del proyecto, espero que les sirva.

SALUDOS :)