TRABAJO PRÁCTICO N°7:

PATRONES DE DISEÑO.
Ingeniería en Sistemas de Información.
DISEÑO DE SISTEMAS.
Integrantes:
Costa Liloff, Christian Ariel. LU: 11569.
Deibele González, Augusto Julián. LU: 11348.
Makula, Daiana Jacqueline. LU: 8932.
Tourn, Franco Emanuel. LU: 10172.
Yrala, Fabián Elias. LU: 9506.

Profesor: Lic. Esp. Paszco Gustavo Ariel.

Fecha de entrega: 13/11/2021.
 Ingeniería en Sistemas de Información – UNCAus
Profesor: Lic. Paszco Gustavo Ariel
PARA CADA EJERCICIO ESPECIFICAR:
• Nombre del patrón o los patrones adoptados.
• Diagrama de clases.
• Cómo sería su aplicabilidad en el ejercicio.
• Participantes en el ejercicio.
• Cómo sería la implementación.

1. ImperiumAO, también conocido como IAO, es un videojuego de rol online multijugador

masivo disponible para los sistemas operativos Windows. Fue desarrollado en el año 2004 como
una modificación del videojuego Argentum Online. La acción se desarrolla en un mundo de
ficción virtual donde se adopta el papel de un personaje determinado que interactúa con otros
personajes, ya sean jugadores online o personajes no jugadores. Todas las interacciones se
desarrollan en un ambiente fantástico como en un juego de rol.
Se necesita desarrollar una estrategia utilizando PATRONES DE DISEÑO que permita al usuario
interactuar con personajes que juegan ciertos roles. Se desea incorporar al juego una facilidad
para crear nuevos personajes que se añaden al conjunto de personajes predefinidos. En el juego,
todos los personajes serán instancias de un pequeño conjunto de clases tales como: guerrero,
aldeano hechicero, clérigo, criaturas, carpinteros, etc.
Cada clase tiene una serie de atributos como nombre, imagen, altura, peso, inteligencia,
habilidades, etc. y según sus valores, una instancia de la clase representa a un personaje u otro,
por ejemplo, podemos tener los personajes hechicero amateur o un hechicero avanzado, o criatura
maligna o benigna. Diseña una solución basada en patrones que permita al usuario crear nuevos
personajes y seleccionar para cada sesión del juego personajes de una colección de personajes
creados.
Diseña las clases de los métodos del catálogo de personajes que permiten añadir un nuevo
personaje a la colección y seleccionar un personaje para jugar.
Patrón Utilizado: Prototype (Prototipo).
Aplicabilidad: La finalidad del patrón Prototype es la creación de instancias de personajes
que ya están creados en vez de ir creando manualmente una instancia de la clase cada vez
con el estado apropiado. Además, poder instanciar las clases en tiempo de ejecución.
Participantes:
Prototipo: Personaje.
Prototipo Concreto: Hechicero, Guerrero, Aldeano, Clérigo, Carpintero y Criatura.
Cliente: CatalogoCreacion.
Implementación: La solución es hacer que CatalogoCreacion cree un nuevo Personaje
clonando una instancia de una subclase de la clase Personaje.
Simplemente, CatalogoCreacion se parametriza con el prototipo que ha de clonar y así poder
añadirlo al juego. Todas las subclases de la clase Personaje tienen una operación clonar,
siendo que CatalogoCreacion puede clonar cualquier tipo de Personaje.
Entonces, cada instancia de CatalogoCreacion va a generar un tipo de personaje clonando su
prototipo y añadiendo el clon a la clase Personaje.

Página 1|6
 Ingeniería en Sistemas de Información – UNCAus
Profesor: Lic. Paszco Gustavo Ariel

2. La aplicación “ContaSol” necesita soportar diferentes tipos de servicios externos de

terceras partes, entre los que se encuentran los calculadores de impuestos, servicios de
autorización de pagos, sistemas de inventario, y sistemas de contabilidad. Cada uno tiene una API
diferente, que no puede ser cambiada.
Una solución es añadir un nivel de indirección con objetos que adapten las distintas interfaces
externas a una interfaz consistente que es la que se utiliza en la aplicación.
Contexto/Problema: ¿Cómo resolver interfaces incompatibles, o proporcionar una interfaz estable
para componentes similares con diferentes interfaces?
Solución (consejo): Convertir la interfaz original de un componente en otra interfaz, a través de
un objeto adaptador intermedio.
Patrón Utilizado: Adapter.
Aplicabilidad: Se utiliza el patrón Adapter debido a que hay que crear una clase que tiene que
cooperar con clases que tienen interfaces no compatibles.
Participantes:
Objetivo: InterfazObjetivo.
Adaptador: InterfazAdaptador.
Adaptable: InterfazImpuestos, InterfazPagos, InterfazInventario, InterfazContablidad.
Cliente: ContaSol.
Implementación: InterfazAdaptador actuara como mediador entre los distintos tipos de
interfaces y el usuario, los cuales estos tipos de interfaces tendrán sus propias api en cierto
lenguaje de programación.

Página 2|6
 Ingeniería en Sistemas de Información – UNCAus
Profesor: Lic. Paszco Gustavo Ariel

3. La estrategia de fijación de precios de una venta puede variar. Durante un periodo podría
ser el 10% de descuento en todas las ventas, después podría ser un descuento de 100 $ si el total
de la venta es superior a 2000 $, y podrían ocurrir muchas otras variaciones. ¿Cómo diseñamos
los diversos algoritmos de fijación de precios?
Patrón Utilizado: Strategy.
Aplicabilidad: Se utiliza el patrón Strategy debido a los distintos casos que pueden haber en la
fijación de precios.
Participantes:
Estrategia: FijacionDePrecio.
Contexto: Venta..
EstrategiaConcreta: Descuento10Porciento, Descuento2000.
Implementación: FijacionDePrecio tiene una relación de dependencia con la clase Venta y esta
definirá el tipo de descuento que se aplica a la venta realizada, dependiendo de cuál sea la
variación elegida.

Página 3|6
 Ingeniería en Sistemas de Información – UNCAus
Profesor: Lic. Paszco Gustavo Ariel

4. Sea un conjunto de clases que permiten la creación y envío de mensajes de correo

electrónico y que entre otras incluye clases que representan el cuerpo del mensaje, los anexos, la
cabecera, el mensaje, la firma digital y una clase encargada de enviar el mensaje. El código cliente
debe interactuar con instancias de todas estas clases para el manejo de los mensajes, por lo que
debe conocer en qué orden se crean esas instancias; cómo colaboran esas instancias para obtener
la funcionalidad deseada y cuáles son las relaciones entre las clases. Idea una solución basada en
algún patrón tal que se reduzcan las dependencias del código cliente con esas clases y se reduzca
la complejidad de dicho código cliente para crear y enviar mensajes. Dibuja el diagrama de clases
que refleje la solución e indica qué patrón has utilizado.

Patrón Utilizado: Facade (Fachada).

Aplicabilidad: El patrón fachada implementa una clase que proporciona una interfaz simple a un
subsistema complejo que contiene muchas partes móviles.
Una fachada puede proporcionar una funcionalidad más simplificada en comparación con trabajar
directamente con cada subsistema.
Participantes:

• Fachada: CorreoElectronico.
• Clases del Subsistema: CorreoNuevo, BotonEnviar, Cabecera, CuerpoMensaje,
Firma, Anexo.
Implementación: CorreoNuevo es una clase compuesta por subclases. El cliente puede
comunicarse con el conjunto de subclases por medio de la interfaz CorreoElectronico y de esta
manera se evita que los clientes tengan que saber sobre la implementación de los subsistemas que
están usando.

Página 4|6
 Ingeniería en Sistemas de Información – UNCAus
Profesor: Lic. Paszco Gustavo Ariel

5. Supuesto que se está construyendo una librería de clases para representar componentes
GUI, se ha decidido que en vez de que un programador defina la posición de los componentes
GUI (Button, List, Dialog,..) sobre una ventana, se incluyan manejadores de disposición de
componentes (layout manager), cada uno de los cuales distribuye un conjunto dado de
componentes gráficos de acuerdo a algún esquema de distribución: horizontalmente,
verticalmente, en varias filas, en forma de una matriz, etcétera. Debe ser posible cambiar en
tiempo de ejecución la distribución elegida inicialmente. Supuesto que la clase JPanel es la que
representa a un contenedor de componentes gráficos, diseña una solución para introducir en la
librería los manejadores de disposición. Dibuja el diagrama de clases que refleje la solución e
indica qué patrón has utilizado.
Patrón utilizado: Strategy.
Aplicabilidad: los manejadores de posición se introducen implementando el patrón de diseño
STRATEGY para si encapsular la responsabilidad del posicionamiento de los elementos en la
clase abstracta LayoutManager. Las subclases de esta serán las encargadas de establecer los
diferentes algoritmos para el posicionamiento de los objetos, y así el cliente podrá utilizar una
política u otra y modificarla en tiempo de ejecución.
Participantes:
Contexto: JPanel.
Estrategia (componedor): LayoutManager.
Estrategia concreta: EsquemaHorizontal, EsquemaVertical y EsquemaMatricia
Implementación: JPanel y LayoutManager se definen de manera que cada estrategia concreta
pueda acceder a cualquier dato que ésta necesite de contexto (JPanel) y viceversa, haciendo que
contexto (JPanel) pase los datos como parámetros a las operaciones de estrategia
(LayoutManager).

Página 5|6
 Ingeniería en Sistemas de Información – UNCAus
Profesor: Lic. Paszco Gustavo Ariel

6. Gestor de ayuda: Tenemos varias clases “Boton”, “Pantalla” y “Aplicacion”. Cada una
con un método “ayuda()”. Queremos desacoplar al emisor de un mensaje del receptor, de forma
que se pueda ejecutar la operación “ayuda()” en cualquier objeto. Si el objeto es capaz de hacerse
cargo de la operación, la ejecutará, y si no la pasará a otro (sucesor) hasta que alguien se haga
cargo del mensaje. ¿Cómo podríamos modelarlo?
Patrón Utilizado: Chain of responsability (Cadena de Responsabilidad).
Aplicabilidad: Se aplica este patrón porque se busca que el método ayuda() se pueda ejecutar
desde cualquier objeto según la petición del Usuario.
Participantes:
Manejador: GestorDeAyuda
ManejadorConcreto: Boton, Pantalla, Aplicacion.
Cliente: UserApp
Implementación: Se separa el emisor del receptor para que cuando se reciba la petición esta sea
asignada al objeto correspondiente.

Página 6|6