Este documento presenta el desarrollo de un software para una empresa de muebles utilizando patrones de comportamiento. Describe varios problemas comunes que podría enfrentar la empresa y cómo aplicar patrones como Chain of Responsibility, State y Visitor para resolverlos. El software permitirá gestionar pedidos, inventario, clientes y ventas. El proyecto sigue las etapas de recolección de requisitos, diseño, implementación y entrega del software.

1. UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS
DESARROLLO DE APLICACIONES CON USO DE PATRONES DE COMPORTAMIENTO
(Modelos de programación)
JUAN CAMILO BOCANEGRA OSORIO
CODIGO 20072020012
SERGIO ANDRES NOVOA
CODIGO 20072020111
PROFESOR JULIO BARON VELANDIA
PROYECTO CURRICULAR INGENIERIA DE SISTEMAS
BOGOTA
30 DE MAYO DE 2013

2. UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS
PROYECTO CURRICULAR INGENIERIA DE SISTEMAS
DESARROLLO DE APLICACIONES CON USO DE PATRONES DE COMPORTAMIENTO
(Modelos de programación)
INTRODUCCION:
En la ingeniería de software nos topamos con ciertos problemas que se repiten frecuentemente, y
para los cuales, luego de aplicar los principios de diseño orientado a objetos(Abierto - Cerrado,
Sustitución de Liskov, Segregación de Interfaces, entre otros…), generalmente llegamos a las
mismas soluciones. en cierto modo, un patrón de diseño es “la solución más natural a cierto tipo
de problema común”.
Viéndolo de ese modo, parece lógico pensar que cuando nos topemos con uno de esos “problemas
modelo” podríamos aplicar “la solución conocida”, sin tener que reinventar la rueda.
Este documento se encargará de demostrar mediante un ejemplo conocido, la aplicación de
algunos de los patrones de diseño estudiados a través del semestre cursado, y como estos servirán
para el desarrollo confiable de aplicaciones diseñadas para solucionar de manera confiable, estos
problemas.
Claro que, antes de aplicar un patrón, debemos asegurarnos de que nuestro problema encaja con
el modelo, y de que las consecuencias del patrón (buenas o malas) se adaptan a nuestro caso: la
idea no es tratar de usar patrones aquí y allá, si no que sean usados cuando encajen con el
problema de diseño que queremos solucionar.
OBJETIVOS:
El objetivo de este documento es transmitir conocimientos de diseño de software según el
paradigma de objetos. Se busca que a partir del conocimiento del paradigma, técnicas de diseño
y lenguajes, se pueda estar en condiciones de diseñar sistemas nuevos y modificar sistemas
existentes utilizando tecnología de objetos y distintos tipos de "arquitectura".
Para lograrlo se presenta un sistema de patrones para ser usado en distintos contextos y resolver
diferentes tipos de problemas.
PALABRAS CLAVE:
Patrones, Comportamiento, Java, UML, POO.
CONTENIDO:
Un Patrón de Diseño es una vía formal de documentar una solución a un problema de diseño en un
campo particular de experiencia.
Un patrón documenta un par problema-solución recurrente dentro de un contexto dado. Sin
embargo, es más que sólo el problema o la estructura de la solución: se incluye tanto el problema
como la solución, junto con la lógica que los une.
Un problema se considera con respecto a las fuerzas en conflicto (por ejemplo, mantenibilidad
vs. reusabilidad), detallando por qué el problema es un problema. Una solución propuesta se
describe en términos de su estructura, e incluye una presentación clara de las consecuencias,
tanto los beneficios como los inconvenientes, de la aplicación de la solución.
En la Ingeniería del software se encuentra una gran cantidad de patrones que solucionan una
amplia gama de problemas comunes. Entre ellos, y gracias al auge de la programación orientada
a objetos, ha sido posible recolectar y documentar catálogos de aquellos que ha sido más

3. eficaces para resolver los problemas más comunes de diseño.
Un patrón de diseño no es una solución final absoluta que puede transformarse directamente a
código, es una descripción o plantilla de como resolver un problema que puede usarse en muchas
situaciones diferentes.
Los patrones de diseño pueden acelerar el proceso de desarrollo, al proporcionar paradigmas que
muchas veces han sido probados útiles.
Patrones de comportamiento
Estos patrones tratan acerca de la comunicación entre objetos y conjuntos de estos.
Chain of responsibility
Evita emparejar el objeto que envía una petición con el objeto que recibe esa petición, al
permitir que mas de un objeto pueda tomar la responsabilidad de la petición enviada. Encadena
los objetos que podrán recibir la petición y pasa la petición a lo largo de la cadena hasta que un
objeto acepte la petición.
Command
Transforma una petición en un objeto de tal manera que puedas catalogar clientes con diferentes
peticiones, mantener un registro de las peticiones y soportar el deshacer operaciones.

4. Interpreter
Permite definir una representación de la gramática de un lenguaje para usarla en un interprete
del lenguaje.
Iterator
Provee de una manera de acceder secuencialmente a los elementos de una colección sin exponer
su representación interna.

5. Mediator
Crea un objeto mediador que encapsula el cómo un conjunto de objetos interactúan. Mediator
promociona la organización de como interactúan los objetos, sin necesidad de que entre ellos
mismos se referencíen.
Memento
Sin violar el principio de encapsulación, captura y externaliza el estado interno de un objeto de
manera que el objeto pueda regresar al estado después.

6. Observer
Define una dependencia de uno a muchos entre objetos de tal manera que cuando un objeto
cambie su estado, todas las dependencias del objeto sean notificadas y actualizadas
automáticamente.
State
Permite que un objeto cambie su comportamiento al cambiar su estado. El objeto parecerá que
cambio de clase.

7. Strategy
Crea un conjunto de algoritmos encapsulados intercambiables. Permite que un algoritmo varíe
independientemente de los clientes que los usan.
Template method
Otorga el derecho a subclases de re definir ciertos pasos o procedimientos de un algoritmo sin
cambiar la estructura de tal algoritmo.
Visitor
Permite definir una operación nueva sin cambiar las clases de los elementos en los cuales opera.

8. DESCRIPCIÓN DEL PROYECTO
MUEBLES MODULARES es una asociación privada que agrupa 39 fábricas de muebles. Funciona
hace más de 15 años. Aunque no existe una dirección física, se caracteriza entre sus clientes por
ser una empresa que no recibe a sus clientes, sino que va hasta ellos.
MISIÓN
Ofrecer productos de excelente calidad brindando una gran variedad de diseño de muebles y
decoración para el hogar. Que satisfagan las necesidades de nuestros clientes, con magnifico
respaldo y garantía.
VISIÓN
Ser el primer centro de diseño y decoración en muebles para hogar y oficina, que ofrece
productos de vanguardia con una amplia oferta de mobiliario comercial en la puerta de su hogar
o negocio.
IDENTIFICACIÓN DEL PROBLEMA
Debido a las nuevas políticas de expansión y alcance de la empresa, MUEBLES MODULARES se ve
en la obligación de crear un software que le permita manejar los pedidos a proveedores, la
organización de las ventas y los datos de clientes y compras, además del manejo del inventario,
por tal razón acuden a nosotros para el desarrollo de éste proyecto.
ETAPAS Y ACTIVIDADES CONTEMPLADAS EN EL PROYECTO.
1. Reunión con los socios de MUEBLES MODULARES, para la consecución y recolección de
requerimientos necesarios.
2. Delegación de responsabilidades miembros del grupo de desarrollo de software.
3. Asistencia de asesor externo para la consecución del proyecto (profesor Julio Barón
Velandia).
4. Desarrollo diagramas para la generación del software.
5. Primera entrega documento.
6. Aplicación correcciones documento.
7. Segunda entrega documento.
8. Implementación en código (JAVA o VISUAL según los requerimientos de la empresa).
9. Revisión de la implementación.
10. Correcciones de la implementación.
11. Entrega final.
PRODUCTOS DEL PROYECTO.
El grupo de desarrollo de software se encargará de crear un aplicativo, que será utilizado única y
exclusivamente por MUEBLES MODULARES, para el manejo total de todo el proceso de producción
y venta de muebles y decoración del cual se encarga MUEBLES MODULARES.
BENEFICIARIOS DEL PROYECTO.
Este software será utilizado exclusivamente por personal perteneciente a la empresa MUEBLES
MODULARES, y personal perteneciente al grupo de desarrollo de software, en calidad de servicio
de mantenimiento y capacitación en el uso del software descrito.

9. BREVE RESUMEN DEL PROYECTO - REQUERIMIENTOS.
• ¿ Cuál es el problema y sus causas?
Debido a la expansión de la empresa MUEBLES MODULARES, se hace necesario la
implementación de un software para el manejo de ventas y producción.
• ¿ Qué se pretende lograr con el proyecto?
Generar un software que permita la optimización de manejo de datos, de la empresa
MUEBLES MODULARES.
• ¿ A quiénes beneficiará? ¿ A cuántos?
Aunque los derechos del software sólo pueden pertenecer a MUEBLES MODULARES, según
la cantidad de filiales que genere, el software podrá ser utilizado por ellos.
• ¿Datos básicos a manejar?
Según la reunión con los socios, el software necesario, es muy básico, el cual manejará
datos de los productos que la empresa MUEBLES MODULARES ofrece, los cuales son
muebles y decoración y todas las características que hay tras la producción de ellos,
además manejará clientes y proveedores y el sistema de venta de productos.
• ¿ Con qué recursos?
El software a utilizar estará basado en el lenguaje de programación JAVA o VISUAL, según
los requerimientos de sistema de los equipos de cómputo de MUEBLES MODULARES.
• ¿ Quiénes lo harán? Responsable. Con la colaboración de quienes más?
El proyecto será realizado por los miembros del grupo de desarrollo de software con la
asistencia del profesor JULIO BARON VELANDIA como asesor.
• ¿ Cuánto tiempo durará? Plazos.
Los plazos de entrega de de documentos e implementación fueron acordados según
reuniones desarrolladas anteriormente.
IMPLEMENTACION PATRONES
PROBLEMA
Se necesita crear una serie de elementos que fueron pedidos por un cliente, por la caracteristicas
de estos muebles, se necesita poner a funcionar las maquinas ensambladoras, pero la cortadora
envía las partes aleatoriamente para cada tipo de mueble. Se necesita ir seleccionando las partes
y enviarlas a su respectiva ensambladora.
PATRON UTILIZADO
El patrón Chain of responsability permite establecer una cadena de objetos receptores a través
de los cuales se pasa una petición formulada por un objeto emisor. La idea es que cualquiera de
los receptores pueden responder a la petición en función de un criterio establecido. Encadena los
objetos receptores y pasa la petición a través de la cadena hasta que es procesada por algún
objeto
En este caso se crearan una serie de clases EnsambleSilla, EnsambleMesa y EnsambleSillon, y
según el tipo de partes que sean enviadas, La clase SeleccionarEnsamble, le delegará la
responsabilidad a la maquina respectiva

10. PROBLEMA
La fábrica va a recibir nuevos moldes para la creación de camarotes, existen de dos y tres pisos,
sin embargo existe el problema que según la cantidad de material que entre a las maquinas están
tendrán la decisión de hacer el camarote especifico.
PATRON UTILIZADO
En determinadas ocasiones, cuando el contexto en el que se está desarrollando requiere que un
objeto tenga diferentes comportamientos según el estado en que se encuentra, resulta
complicado poder manejar el cambio de comportamientos y los estados de dicho objeto, todos
dentro del mismo bloque de código. El patrón State propone una solución a esta complicación,
creando básicamente, un objeto por cada estado posible del objeto que lo llama.
Se utilizará una clase ArmarCamarote, que según la cantidad de material ingresado, creará el
respectivo camarote CamaroteDos o CamaroteTres con sus respectivas caracteristicas.

11. PROBLEMA
Para la entrada a las instalaciones existe un sistema de identificación, que según el tipo de
persona(cliente, empleado o socio) le permite el acceso a las distintas instalaciones, pero las
caracteristicas de cada uno son similares, y la única diferencia es el tipo de identificación, de
que forma se puede controlar el acceso.
PATRON UTILIZADO
El patrón Plantilla permite que ciertos pasos de un algoritmo definido en una operación de una
superclase, sean redefinidos en las subclases sin necesidad de tener que sobrescribir la operación
entera.
Se utilizará una clase EntradaPorID que según el tipo de persona(Cliente,Empleado, Socio),
los cuales sólo se diferencian por el tipo de ID, permitirá que con esté ID puedan ingresar al
complejo.
PROBLEMA
Por cambio de temporada, MUEBLES MODULARES hará un descuento para las compras, pero con
una caracteristica, los operarios tendrán un descuento mayor que el de los clientes, se necesita
un algoritmo que regule esto.
PATRON UTILIZADO
El patrón Visitor es útil cuando se desea encapsular buscando datos desde un número de
instancias de varias clases. Los patrones de diseño sugieren que el visitante puede proporcionar
una funcionalidad adicional a una clase sin cambiarla. Pero es más práctico decir que un visitante
puede agregar funcionalidad a una colección de clases y encapsular los métodos que utiliza.
A traves de las clases UsuarioPrintVisitor y UsuarioDescuentoVisitor() podremos calcular el
descuento que se hará a cada uno de las personas interesados, según el tipo que es.

13. CONCLUSIONES
A través del desarrollo del proyecto se entendió la utilización de los patrones de comportamiento
en la realización de programas, con un fin didáctico, explicando de una forma concisa, pero
detallada los patrones utilizados, así como su implementación en uno de los lenguajes de
programación con mayores ventajas para la programación, como es el lenguaje JAVA.
Se puso a prueba el diseño de documentos para la realización de proyectos, en este caso de
desarrollo de software

14. BIBLIOGRAFIA
Guia de construcción de software en JAVA con patrones de diseño Francisco Javier Martinez Juan
“Design Patterns” E. Gamma et al., Addison Wesley, 1998.
Design Patterns http://www.oodesign.com/
Design Patterns http://sourcemaking.com/design_patterns
Formato de anteproyecto de grado UNIVERSIDAD DE CIENCIAS APLICADAS Y AMBIENTALES –
U.D.C.A.