Desarrollo de un prototipo de aplicaci´
on
web para el monitoreo y control de ventas
que realizan los clientes de la empresa
Pago Digital
Autor: Diego Armando Estrada Tinjac´a Director: Jos´e Ignacio Palacios Osma
0.1. RESUMEN 3
0.1.
Resumen
El presente trabajo de grado trata sobre la creaci´on de una aplicaci´on web donde una empresa espec´ıfica podr´a facilitar a sus empleados una herra-mienta para trabajar desde cualquier lugar en forma de teletrabajo.
Este documento mostrara las diferentes fases necesarias para llevar a cabo el proyecto y la forma de implementarlo en base a la arquitectura empresarial apoyada de marcos de referencia como TOGAF 9.1.
Se presentara al lector la informaci´on de la empresa a nivel de organiza-ci´on como los son organigrama, servicios y procesos, esta informaci´on est´a totalmente abalada por la empresa la cual se beneficiara de dicho software.
El teletrabajo es parte fundamental del proyecto, por ende se aborda infor-maci´on acerca de este tema a lo largo del documento, se intenta evidenciar su impacto en Latinoam´erica y especialmente en las empresas Colombianas.
0.2.
Palabras Clave
4
0.3.
Abstract
The present work of degree deals with the creation of a web application where a specific company can provide its employees a tool to work from any place in the form of telecommuting.
This document will show the different phases necessary to carry out the pro-ject and how to implement it based on the business architecture supported by frames of reference as TOGAF 9.1.
The information of the company will be presented to the reader at the organization level as they are organization chart, services and processes, this information is totally shaken by the company that will benefit of said software.
Teleworking is a fundamental part of the project, so information about this topic is addressed throughout the document, an attempt is made to show its impact in Latin America and especially in Colombian companies.
0.4.
Keywords
0.5. AGRADECIMIENTOS 5
0.5.
Agradecimientos
Dedicado a mis padres Nancy y Arturo quienes a pesar de las circunstancias me apoyaron y creyeron siempre en m´ı, a mi novia Yuly que ha estado a mi lado en los buenos y malos momentos y a todos los docentes que hicieron parte de este proyecto.
8 ´INDICE GENERAL
4.2.4. Correspondencia entre Archimate y TOGAF . . . 43
´
6. Capa de Aplicaci´on 61 6.1. Introducci´on . . . 61
10 ´INDICE GENERAL
12 ´INDICE GENERAL
11.2. Trabajos Futuros . . . 164
11.3. Contrastaci´on . . . 165
11.4. Bibliografia . . . 167
11.4.1. Libros . . . 167
11.4.2. Art´ıculos . . . 167
11.4.3. Conferencias . . . 167
11.4.4. Otros . . . 168
11.5. Imagenes Portal PD . . . 169
11.5.1. Frontend . . . 169
´
Indice de figuras
5.4. Metamodelo Proceso de Negocio: Venta telef´onica a tarjeta-habiente . . . 54
5.5. Metamodelo Cooperaci´on de Proceso de Negocio: Venta te-lef´onica a tarjetahabiente . . . 56
5.6. Metamodelo Cooperaci´on de Proceso de Negocio: Pago Digital 58 6.1. Metamodelo Comportamiento de Aplicaci´on: Pago Digital . . 62
6.2. Metamodelo Cooperaci´on de Aplicaci´on: Pago Digital . . . . 64
6.3. Metamodelo Estructura de Aplicaci´on: Pago Digital . . . 66
6.4. Metamodelo Uso de Aplicaci´on: Pago Digital . . . 68
7.1. Metamodelo Infraestructura: Pago Digital . . . 72
7.2. Metamodelo Uso de Infraestructura: Pago Digital . . . 74
7.3. Metamodelo Implementaci´on y Despliegue: Pago Digital . . . 76
7.4. Metamodelo Estructura de informaci´on: Pago Digital . . . 78
7.5. Metamodelo Realizaci´on del servicio: Pago Digital . . . 80 7.6. Metamodelo Capas: Pago Digital (Ventas con tarjeta de cr´edito) 82
8.1. Metamodelo Stakeholder: Pago Digital (Partes interesadas) . 86
14 ´INDICE DE FIGURAS
8.2. Metamodelo Realizaci´on de Objetivos: Pago Digital
(Objeti-vos Partes interesadas) . . . 88
8.3. Metamodelo Contribuci´on de Objetivos: Pago Digital . . . 90
8.4. Metamodelo Principios: Pago Digital (Valores Corporativos) . 92 8.5. Metamodelo Realizaci´on de Requerimientos: Pago Digital . . 94
8.6. Metamodelo Motivaci´on: Pago Digital(Monitorear ventas en tiempo real ) . . . 96
9.1. Metamodelo Proyecto: Pago Digital . . . 100
9.2. Metamodelo Migraci´on: Pago Digital . . . 102
9.3. Metamodelo Implementaci´on y Migraci´on: Pago Digital . . . 104
10.1. Estructura: Patr´on M´etodo Singleton . . . 112
10.13.Estructura: Patr´on M´etodo Cadena de Responsabilidad . . . 139
´
INDICE DE FIGURAS 15
11.5. Portal PD: Detalle de Ventas . . . 171
11.6. Portal PD: Migraci´on Creaci´on de Empresa . . . 172
11.7. Portal PD: Creaci´on de Modelo . . . 172
11.8. Portal PD: Creaci´on de Controlador . . . 173
11.9. Portal PD: Creaci´on de la Ruta . . . 173
11.10.Portal PD: Consulta con Eloquent Laravel . . . 174
11.11.Portal PD: Configuraci´on de la Vista . . . 174
Parte I
Proyecto
Cap´ıtulo 1
Anteproyecto
1.1.
Introducci´
on
El presente proyecto de investigaci´on se basa en la creaci´on d e un pro-totipo de aplicaci´on web para la empresa Pago Digital Colombia, donde los trabajadores podr´an controlar y monitorear las ventas que los clientes de la empresa realizan a los tarjetahabientes (Poseedor de tarjeta cr´edito o d´ ebi-to), esta actividad se podr´a ejecutar sin la necesidad de estar en un lugar fijo.
El ´area espec´ıfica a la cual se encuentra dirigida la aplicaci´on es el ´area de monitoreo (callcenter). Esta actividad se realizara bajo la modalidad de teletrabajo la cual no requiere la presencia f´ısica del trabajador, por ende el empleado cuenta con la libertad de elegir su sitio de trabajo.
Uno de los factores fundamentales para asegurar el cumplimiento del te-letrabajo es el m´odulo de reconocimiento de voz donde el empleado deber´a loguearse constantemente para validar su presencia en el sistema. Cabe acla-rar que el teletrabajo no es una profesi´on, un callcenter o un servicio a do-micilio, es solo una forma de realizar una actividad laboral espec´ıfica que permite realizarse desde cualquier lugar.
Para llevar a cabo el teletrabajo, los procesos de la actividad laboral de-ben encontrarse centralizados ya sea f´ısica o digitalmente y requiere de es-trategias de seguimiento para llevar a feliz t´ermino estas actividades. La utilizaci´on de tecnolog´ıas para facilitar la comunicaci´on es vital para llevar a cabo esta modalidad de trabajo.
20 CAP´ITULO 1. ANTEPROYECTO
1.2. DEFINICI ´ON DEL PROBLEMA 21
1.2.
Definici´
on del Problema
Actualmente la empresa Pago Digital dedicada al procesamiento de pa-gos con tarjeta de cr´edito y d´ebito, monitorea las ventas realizadas a tarjeta-habientes (poseedores de tarjeta cr´edito o d´ebito) por v´ıa telef´onica. Estas ventas son monitoreadas al instante para evitar posibles fraudes bancarios.
Los trabajadores de la empresa del ´area monitoreo (callcenter) controlan las ventas en su horario laboral de 8:00 am a 6:00 pm, es por ello que las ventas realizadas posterior a las 6:00 pm, no son monitoreadas al instante, dando lugar a posibles fraudes con tarjetas ya que las ventas se monitorean al siguiente d´ıa h´abil.
22 CAP´ITULO 1. ANTEPROYECTO
1.3.
Hip´
otesis
1.4. OBJETIVOS 23
1.4.
Objetivos
1.4.1. Objetivo General
Crear un prototipo de aplicaci´on por medio de tecnolog´ıas web para el monitoreo y control de ventas no presenciales.
1.4.2. Objetivos Espec´ıficos
Dise˜nar los formularios del aplicativo web sin consultas SQL para evi-tar inyecciones de tipo sql inyection.
Crear un panel de administraci´on en lenguaje PHP donde los traba-jadores podr´an ingresar los detalles de una venta.
24 CAP´ITULO 1. ANTEPROYECTO
1.5.
Justificaci´
on
1.5.1. Social
Estamos en una era donde la tecnolog´ıa influye en diferentes decisiones que la sociedad debe tomar, muchas de ellas cambian dr´asticamente al mo-mento de elegir o no un elemo-mento tecnol´ogico, es por ello que dar el salto al uso de estas herramientas se vuelve tormentoso m´as si no se cuenta con la experiencia necesaria para tomar decisiones.
Un claro ejemplo son las compras por internet, existe temor de realizar transacciones por este medio y esto es un paradigma que afecta al desarrollo tecnol´ogico del pa´ıs.
Casos como el mencionado anteriormente se le suma la poca credibilidad que una empresa tiene en el teletrabajo donde la uni´on de tecnolog´ıas puede lograr esta forma de trabajo beneficiando al trabajador y a la empresa.
Con el desarrollo del presente proyecto la empresa Pago Digital dar´a un paso hacia la innovaci´on tecnol´ogica apoyando esta forma de trabajo que crece d´ıa a dia en latinoam´erica.
1.5.2. Tecnol´ogica
A nivel tecnol´ogico Pago Digital apuesta por la uni´on de tecnolog´ıas web para que el control sobre sus ventas no presenciales cuenten con la seguridad necesaria para no afectar a los tarjetahabientes.
La empresa actualmente se encuentra en el proceso de certificaci´on PCI por ende solicita que sus desarrollos no tengan consultas SQL en sus scripts, por ende se tomo la decisi´on de desarrollar el software en un framework co-mo laravel el cual no trabaja con este tipo de consultas gracias a su co-modulo eloquent el cual con menos lineas de c´odigo es posible crear las consultas a la base de datos.
1.5.3. Ambiental
Cap´ıtulo 2
Metodolog´ıa
2.1.
Introducci´
on
Para la elaboraci´on del presente proyecto se tomara la metodolog´ıa en sus fases de an´alisis y ejecuci´on donde se analizara el estado actual y se presentara una alternativa de soluci´on detallada en base a la arquitectura empresarial.
Se identificaran las partes interesadas y as´ı mismo sus puntos de vista para abordar mejor el proyecto y poder cubrir las necesidades de cada uno de ellos, todo esto apoyado bajo el marco togaf en su versi´on 9.1 y en lenguaje de modelado archimate.
26 CAP´ITULO 2. METODOLOG´IA
2.2.
Archimate
Figura 2.1: Archimate
2.3. CRONOGRAMA 27
2.3.
Cronograma
Figura 2.2: Cronograma
El cronograma cuenta con las siguientes fases:
Etapa 1 Contexto Organizacional
Etapa 2 Modelamiento Arquitectura Empresarial
Etapa 3 Desarrollo
Parte II
Arquitectura
Cap´ıtulo 3
Empresa
3.1.
Introducci´
on
Pago Digital es una empresa Colombiana creada en el 2013 por el Sr. William Alonso Talero Rivera, sus inicios fueron en el barrio JJ Vargas de la ciudad de Bogot´a, la experiencia y habilidades del Sr. William lo llevaron a crear una pasarela de pagos donde diferentes personas poseedoras de tarjetas de cr´edito o d´ebito (tarjetahabientes) pueden realizar pagos, compras , consignaciones etc. por medio de su sistema.
Figura 3.1: Logotipo - Logo Pago Digital
32 CAP´ITULO 3. EMPRESA
3.2.
Misi´
on
Proveer un sistema de pago seguro con soluciones a diferentes tipos de negocios brindando un sistema antifraude con mejora continua y adapt´ ando-se a los cambios socioculturales, para convertirnos en una empresa l´ıder de pagos en l´ınea.
3.3.
Visi´
on
3.4. ORGANIGRAMA 33
3.4.
Organigrama
En la figura 3.2 se presenta la organizaci´on estructural de Pago Digital, la estructura la componen un ´area principal y 3 sub ´areas:
Gerencia ´area principal
Direcci´on de Mercadeo
Direcci´on Comercial
Area Contadur´ıa
34 CAP´ITULO 3. EMPRESA
3.5.
Procesos
La empresa Pago Digital cuenta con diferentes procesos para su funcio-namiento, debido a que el proyecto se centra en el proceso de monitoreo de ventas, citaremos los diferentes procesos que tiene la empresa en cuanto a la venta concierne.
3.5.1. Proceso de venta con carrito de compras
Si un cliente de Pago Digital tiene configurado un carrito de compras en su pagina web la venta funciona de la siguiente forma:
1. El cliente selecciona el producto
2. Selecciona la opci´on pagar
3. Se habilita la opci´on ”Pago Digital”
4. Confirmar compra
Para este tipo de compra no se realiza monitoreo debido a que es el cliente quien realiza la compra desde la pagina web del comercio.
3.5.2. Proceso de venta telef´onica
La venta telef´onica la realizan los comercios(clientes) afiliados a Pago Digital a diferentes personas con tarjeta de cr´edito o d´ebito, el proceso para esta venta es el siguiente:
1. El comercio contacta al tarjetahabiente y le ofrece un producto o ser-vicio
2. El tarjetahabiente aprueba la compra
3. El tarjetahabiente indica los datos de su tarjeta de cr´edito
4. Indica el numero de tarjeta y contrase˜na
5. El comercio ingresa la venta por el portal de Pago Digital
6. La venta es aprobada y descontado el dinero al tarjetahabiente
3.6. PRODUCTOS Y SERVICIOS 35
3.6.
Productos y Servicios
Pago digital ofrece diversos servicios de los cuales se mencionan los m´as generales:
3.6.1. Carrito Digital
Permite a los comercios que tengan un sitio web, agregar su carrito para recibir pagos electr´onicos por medio de los distintos plugins que se manejan como Prestashop, VirtueMart, Woocommerce, Magento y Opencart.
3.6.2. Integraci´on Digital
Permite a los comercios que tengan un sitio web integrar la pasarela de pagos de una forma externa o interna seg´un su requerimiento.
3.6.3. Enlace Digital
Permite que un comercio env´ıe por medio de mail o redes sociales un enlace para que el cliente procese su pago electr´onico, es ideal para aquellos comercios que a´un no tienen un sitio web.
3.6.4. Bot´on Digital
36 CAP´ITULO 3. EMPRESA
3.7.
Funciones
A continuaci´on se describen las funciones de la empresa de acuerdo a las ´
areas que la componen:
3.7.1. Gerencia
Se encarga de la toma de decisiones que la compa˜n´ıa enfrenta en su d´ıa a d´ıa.
3.7.2. Direcci´on Comercial
Vela por establecer un nivel de ventas acorde a la proyecci´on de la em-presa. Esta ´area tiene la misi´on de mantener un tope de ventas diarias con incidencia incremental.
3.7.3. Direcci´on de Mercadeo y Publicidad
Esta ´area se encarga de ofrecer los productos mediante diferentes medios (web, impresos, terreno) los cuales est´an enfocados al core del negocio el cual es el procesamiento de pagos con tarjeta cr´edito o d´ebito.
3.7.4. Area Contadur´ıa´
3.8. OBJETIVOS ORGANIZACIONALES 37
3.8.
Objetivos Organizacionales
Se describen algunos de los objetivos de la organizaci´on.
3.8.1. Objetivo 1
Fortalecer y mejorar el trabajo en equipo mediante trabajo colaborativo y asi mantener un excelente clima laboral.
3.8.2. Objetivo 2
Realizar revisiones constantes a los sistemas con reuniones peri´odicas para fortalecer los servicios y generar una alta disponibilidad en nuestros sistemas.
3.8.3. Objetivo 3
Cap´ıtulo 4
Archimate y ADM
4.1.
Introducci´
on
Archimate es un lenguaje de modelado que se usa en la implementaci´on de arquitectura empresarial. El objetivo es apoyar la descripci´on, an´alisis y visualizaci´on de la arquitectura dentro y fuera de los dominios del negocio en una forma no ambigua.
ADM (M´etodo de Desarrollo de Arquitectura) ,describe como obtener una Arquitectura Empresarial que sea espec´ıfica para la organizaci´on y para res-ponder a los requerimientos del negocio. ADM es el componente principal del marco TOGAF y proporciona direcci´on a los arquitectos en sus diferentes niveles.
40 CAP´ITULO 4. ARCHIMATE Y ADM
4.2.
Archimate
El lenguaje de modelado Archimate permite representar la arquitectura empresarial de una organizaci´on bajo tres diferentes perspectivas: negocio, sistemas y tecnolog´ıa. El lenguaje Archimate sirve para dise˜nar los diferentes cat´alogos que faciliten la adopci´on de tecnolog´ıa en las empresas, vinculando los procesos de negocio con los activos tecnol´ogicos.
El dise˜no de una arquitectura empresarial facilita la administraci´on de pro-yectos de tecnolog´ıa y cambio organizacional, permitiendo que los expertos de negocio puedan priorizar los requerimientos de alto nivel y generar pro-yectos que impacten positivamente la organizaci´on. El lenguaje de modelado Archimate define un conjunto de elementos estandard para el dise˜no de ar-quitecturas empresariales, al igual que los diferentes artefactos necesarios para tener un lenguaje com´un entre expertos de negocio y de tecnolog´ıa.
La herramienta permitir´a de manera intuitiva el desarrollo del cat´alogo de roles dentro del concepto de arquitectura empresarial y permite describir ca-da uno de los elementos necesarios para su correcta y acertaca-da construcci´on. Tambi´en se incluye una explicaci´on de los cat´alogos la cual permite identi-ficar los requerimientos de negocio y de la perspectiva de implementaci´on, la cual permite representar cualquier diagrama necesario desde el marco de arquitectura empresarial Togaf.
4.2.1. Dise˜no de arquitectura
Integrada
El n´ucleo de ArchiMate es un lenguaje de dise˜no para describir la arqui-tectura de negocio y arquiarqui-tecturas de TI en coherencia entre s´ı. Al margen del lenguaje de dise˜no, ArchiMate ofrece una amplia gama de t´ecnicas para la visualizaci´on, an´alisis, dise˜no y uso de la arquitectura empresarial con el fin de resolver los cambios necesarios del negocio. ArchiMate proporciona al arquitecto de la empresa instrumentos de arquitectura para apoyar y mejo-rar el proceso de cambio en los negocios. Estos instrumentos ayudan a los arquitectos en la comunicaci´on con todos los actores involucrados, que van desde los gerentes hasta los desarrolladores de software.
4.2. ARCHIMATE 41
La capa de negocio: procesos de negocio, organizaci´on, funciones de negocios, productos y servicios de oficina
La capa de aplicaci´on: aplicaciones, servicios de aplicaci´on, las funcio-nes de aplicaci´on, interfaces de aplicaciones
42 CAP´ITULO 4. ARCHIMATE Y ADM
4.2.2. Tres Capas fundamentales
El nivel de procesos de negocio, servicios, funciones y eventos de las unidades de negocio. Esta capa ofrece productos y servicios a clientes externos.
La capa de aplicaci´on comprende aplicaciones de software que apoyan los componentes del negocio – de la capa anterior – realizando servicios de aplicaci´on.
La capa de tecnolog´ıa comprende el hardware y la infraestructura de comunicaci´on para apoyar la capa de aplicaci´on. Esta capa ofrece servi-cios de infraestructura necesarios para ejecutar aplicaciones, realizado por computadora y hardware de comunicaciones y software del siste-ma.
4.2.3. ArchiMate y TOGAF
TOGAF es un marco de arquitectura - un conjunto de m´etodos y herra-mientas para el desarrollo de una amplia gama de las diferentes arquitecturas de TI. que permite a los usuarios dise˜nar, evaluar y construir una arquitec-tura correcta de su organizaci´on, y reduce los costes de planificaci´on, dise˜no y aplicaci´on de arquitecturas basadas en soluciones de sistemas abiertos.
La clave para TOGAF es el m´etodo de desarrollo de arquitectura (ADM) -un sistema fiable y -un m´etodo probado para desarrollar una Arquitectura Empresarial que satisfaga las necesidades de su negocio.
4.2. ARCHIMATE 43
4.2.4. Correspondencia entre Archimate y TOGAF
Archimate esta relacionado con TOGAF, pero no es TOGAF aunque se mezclan muy bien ambos. En la figura 3-8 es f´acil de identificar la corres-pondencia entre el ciclo ADM (izquierda) y TOGAF (derecha), debido al uso de colores:
La fase A, H junto con Requerimientos y Preliminar agrupadas de color lila, representan lo motivacional y nos responde el porqu´e vamos a hacer la arquitectura
Las fases B, C y D agrupadas cada una de tres colores que representan la informaci´on (Verde), el comportamiento (Amarillo) y la estructura (Azul), nos responde el qu´e vamos a hacer.
Las fases E, F y G agrupadas de color rojo representan la migraci´on y nos responde el c´omo vamos a hacer la arquitectura.
44 CAP´ITULO 4. ARCHIMATE Y ADM
4.3.
ADM
El marco de trabajo (framework) TOGAF consiste en un m´etodo deta-llado y un conjunto de herramientas que direccionan la arquitectura empre-sarial. Est´a compuesto por cuatro partes principales:
el m´etodo de desarrollo de la arquitectura ADM (Architecture Develop-ment Method), la taxonom´ıa empresarial (Enterprise Continuum) y la base de recursos (Architecture Repository).
TOGAF aborda el desarrollo a partir de cuatro niveles de abstracci´on: ar-quitectura de negocio, arar-quitectura de sistemas de informaci´on, arquitectura de datos y arquitectura tecnol´ogica.
ADM refleja estos niveles de abstracci´on en diferentes fases que determi-nan la l´ınea base (baseline o as-is) y final de un nivel de abstracci´on (target o to-be) junto con un an´alisis de brecha (gap analysis) que permite conocer el estado final de la arquitectura despu´es de una o varias iteraciones.
El m´etodo define ocho niveles A, B, C, D, E, F, G, H que van desde la visi´on de la arquitectura hasta la administraci´on del cambio, por ser una metodolog´ıa iterativa permite completar, eliminar o crear nuevos items en su recorrido mediante el an´alisis de brecha que se realiza al final de cada nivel.
4.3. ADM 45
Modelo ADM Metodo de Desarrollo de Arquitectura:
Figura 4.2: Metodo: ADM
4.3.1. Fases
46 CAP´ITULO 4. ARCHIMATE Y ADM
Fase A – Visi´on de Arquitectura: En esta fase, se establece el proyecto de arquitectura junto con el alcance de la iniciativa de EA. Se deben identificar las partes interesadas, sus inquietudes y requerimientos de negocio.
Fase B – Arquitectura de Negocios — Fase C – Arquitectura de Siste-mas de Informaci´on — Fase D – Arquitectura de Tecnolog´ıa: En estas tres fases, se desarrolla la l´ınea base de arquitectura (AS-IS Architec-ture) y la arquitectura final (es decir, la arquitectura objetivo de la iniciativa de EA, TO-BE Architecture)
Fase E – Oportunidades y Soluciones: En esta fase, se define la plani-ficaci´on inicial para la puesta en marcha de la arquitectura objetivo, se identifican y agrupan los principales paquetes de trabajo necesarios
Fase F – Planificaci´on de Migraci´on: En esta fase, los proyectos de migraci´on identificados en la etapa anterior son priorizados. Para ello, se debe realizar la evaluaci´on coste/beneficio, an´alisis de riesgo y la asignaci´on del valor
Fase G – Gobernanza de la Implementaci´on: En esta fase, se confirma y supervisa el alcance y las prioridades de los proyectos de implemen-taci´on. Tambi´en, se realizan las revisiones de cumplimiento de EA
Fase H – Gesti´on de Cambios de Arquitectura: En esta fase, se revisa que la arquitectura resultante alcanza el valor para el negocio que se hab´ıa establecido como objetivo.
Cap´ıtulo 5
Capa de Negocio
5.1.
Introducci´
on
Es una de las capas m´as importantes debido a que el lenguaje que se uti-liza, permite hablar en t´erminos de las entidades del negocio, por lo que es importante distribuir adecuadamente la sem´antica. Esta capa gira en torno a tres dimensiones de comportamiento: procesos, servicios y producto (cen-tro del negocio).
Las capas agregan conceptos que soportan las etapas del ADM de TOGAF en las fases B, C y D que se encuentran relacionadas con el negocio, aplica-ci´on o datos e infraestructura.
48 CAP´ITULO 5. CAPA DE NEGOCIO
5.2.
Organizaci´
on
5.2.1. Modelo
5.2. ORGANIZACI ´ON 49
5.2.2. Caso de Estudio
El metamodelo de la organizaci´on describe los actores de la empresa, no se precisa como un organigrama aunque tenga similitud.
Los actores del modelo son los siguientes:
Pago Digital
50 CAP´ITULO 5. CAPA DE NEGOCIO
5.3.
Cooperaci´
on de Actor
5.3.1. Modelo
Hace referencia a las relaciones existentes entre los actores y los actores con su entorno. Es importante este modelo debido a que evidencia como sus componentes de aplicaci´on cooperan para realizar un proceso de negocio.
5.4.
Organizaci´
on
5.4.1. Modelo
5.4. ORGANIZACI ´ON 51
5.4.2. Caso de Estudio
Se observa en este modelo a dos actores que forman una colaboraci´on llamada ”Pasarela de Pagos”luego se desprende un rol ”Puente virtual”que enlaza a los clientes y tarjetahabientes por medio de un portal web.
52 CAP´ITULO 5. CAPA DE NEGOCIO
5.5.
Funci´
on de Negocio
5.5.1. Modelo
Este punto de vista muestra las principales funciones de negocio de una organizaci´on as´ı como su relaci´on en flujos de informaci´on la funci´on de negocio provee una mirada de alto nivel en las operaciones generales de la compa˜n´ıa
Para el caso de pago digital se tomaran las funciones del ´area de callcen-ter(monitoreo) que es donde se desarrolla espec´ıficamente el proyecto.
5.5. FUNCI ´ON DE NEGOCIO 53
5.5.2. Caso de Estudio
En este modelo se precisan dos roles fundamentales, el coordinador y el analista; el primero con 5 funciones principales:
Descargar llamadas de los tarjetahabientes
Contactar a los comercios con ventas con posible fraude
Controlar llamadas
Indicar monto de ventas aprobadas
Elaborar informe de ventas negadas y aprobadas
La funci´on principal del analista es:
54 CAP´ITULO 5. CAPA DE NEGOCIO
5.6.
Proceso de Negocio
5.6.1. Modelo
Este punto de vista es usado para mostrar la estructura de alto nivel y composici´on de uno o mas procesos de negocio.
5.6. PROCESO DE NEGOCIO 55
5.6.2. Caso de Estudio
56 CAP´ITULO 5. CAPA DE NEGOCIO
5.7.
Cooperaci´
on de Proceso de Negocio
5.7.1. Modelo
Este punto de vista es usado para mostrar las relaciones de uno o mas procesos de negocio entre si mismos y con su ambiente.
5.7. COOPERACI ´ON DE PROCESO DE NEGOCIO 57
5.7.2. Caso de Estudio
58 CAP´ITULO 5. CAPA DE NEGOCIO
5.8.
Producto
5.8.1. Modelo
Representa el valor que los productos ofrecen a los clientes o a otros entes externos involucrados.
Tambi´en para mostrar las interfaces a trav´es de los cuales es ofrecido el producto y los eventos asociados a el.
5.8. PRODUCTO 59
5.8.2. Caso de Estudio
En este punto de vista se plantean los beneficios de trabajar con Pago Digital en cuanto a su procesamiento de ventas, algunos de sus servicios de valor son:
Pago ´agil y seguro
Sin costo de afiliaci´on
Pago seguro respaldado por la norma PCI
Cap´ıtulo 6
Capa de Aplicaci´
on
6.1.
Introducci´
on
La capa de aplicaci´on soporta la capa de negocio con servicios de apli-caci´on los cuales son realizados por aplicaciones de software.
62 CAP´ITULO 6. CAPA DE APLICACI ´ON
6.2.
Comportamiento de Aplicaci´
on
6.2.1. Modelo
El comportamiento de aplicaci´on describe el comportamiento interno de una aplicaci´on,por ejemplo, el como realiza uno o mas servicios de aplicaci´on Este punto de vista es ´util en el dise˜no de los comportamientos principales de las aplicaciones, o para identificar los cambios funcionales entre diferentes aplicaciones.
6.2. COMPORTAMIENTO DE APLICACI ´ON 63
6.2.2. Caso de Estudio
El modelo comportamiento de aplicaci´on describe el pago realizado por diferentes medios, all´ı encontramos diferentes componentes con funciones especificas, los procesos que se desprenden de estos componentes son:
Procesar Pagos (Componente Credibanco)
Ventas v´ıa telef´onica con tarjeta de cr´edito (Componente Pago)
Realizar pagos con carrito de compras(Componente Pago)
64 CAP´ITULO 6. CAPA DE APLICACI ´ON
6.3.
Cooperaci´
on de Aplicaci´
on
6.3.1. Modelo
Este punto de vista describe las relaciones entre componentes de apli-caciones en t´erminos de los flujos de informaci´on entre ellas, o en t´erminos de los servicios que ellas ofrecen o utilizan. Este punto de vista es usado t´ıpicamente para crear una visi´on general del panorama de aplicaciones de una organizaci´on
Tambi´en es usado para expresar la cooperaci´on interna o la orquestacion de servicios que en conjunto soportan la ejecuci´on de un proceso de negocio.
6.3. COOPERACI ´ON DE APLICACI ´ON 65
6.3.2. Caso de Estudio
Este modelo muestra dos partes fundamentales que son el frontend y el backend de los componentes involucrados. Por el lado del frontend tenemos 2 componentes:
Portal Web
Pagina Web
Por el lado del backend tenemos 4 componentes:
Callcenter
Comercio
Credibanco
66 CAP´ITULO 6. CAPA DE APLICACI ´ON
6.4.
Estructura de Aplicaci´
on
6.4.1. Modelo
El punto de vista de estructura de aplicaci´on muestra la estructura de una o m´as aplicaciones o componentes. Este punto de vista es utilizado en el dise˜no o entendimiento de la estructura principal de aplicaciones o compo-nentes y los datos asociados, por ejemplo, para descomponer la estructura del sistema que esta en construcci´on.
6.4. ESTRUCTURA DE APLICACI ´ON 67
6.4.2. Caso de Estudio
Para el presente modelo se elaboran 5 componentes con sus respectivas interfaces, el componente central es la pasarela de pagos la cual tiene las siguientes interfaces:
Comunicaci´on
Recaudo
Seguridad
68 CAP´ITULO 6. CAPA DE APLICACI ´ON
6.5.
Uso de Aplicaci´
on
6.5.1. Modelo
Este punto describe como son usadas las aplicaciones para soportar uno o mas procesos de negocio, y como estas son usadas por otras aplicaciones. Puede ser utilizado en el dise˜no de una aplicaci´on identificando los servicios necesitados por procesos de negocio y otras aplicaciones.
6.5. USO DE APLICACI ´ON 69
6.5.2. Caso de Estudio
Para el presente modelo intervienen los siguientes elementos en el proceso de venta:
Ventas
Monitoreo
Hacer pagos con tarjeta
Cap´ıtulo 7
Capa de Tecnolog´ıa
7.1.
Introducci´
on
La capa de tecnolog´ıa ofrece servicios de infraestructura, por ejemplo servicios de almacenamiento y comunicaci´on necesarios para ejecutar apli-caciones. Esta capa muestra la conexi´on entre el hardware y los sistemas de software.
72 CAP´ITULO 7. CAPA DE TECNOLOG´IA
7.2.
Infraestructura
7.2.1. Modelo
El presente punto de vista contiene los elementos de infraestructura de software y de hardware que soportan la capa de aplicaci´on, tales como dispo-sitivos f´ısicos, redes o sistemas de software por ejemplo (sistemas operativos, bases de datos, red, servidores)
7.2. INFRAESTRUCTURA 73
7.2.2. Caso de Estudio
El metamodelo de Infraestructura muestra la estructura de Pago Digital la cual soporta la capa de aplicaci´on, podemos observar algunos componen-tes de software y hardware. El diagrama inicia con 2 nodos principales que son ”Banco y Credibanco.a estos nodos se conecta la aplicaci´on web de la
empresa ”Portal PD”. Este portal se encuentra en un hosting con el servidor web y el servidor de base de datos.
74 CAP´ITULO 7. CAPA DE TECNOLOG´IA
7.3.
Uso Infraestructura
7.3.1. Modelo
En el punto de vista uso de infraestructura muestra como las aplicaciones son soportadas por la infraestructura de software y hardware. Este punto de vista juega un papel importante en el an´alisis de rendimiento y escalabilidad ya que relaciona la infraestructura con las aplicaciones
7.3. USO INFRAESTRUCTURA 75
7.3.2. Caso de Estudio
76 CAP´ITULO 7. CAPA DE TECNOLOG´IA
7.4.
Implementaci´
on y Despliegue
7.4.1. Modelo
Este punto de vista muestra como una o mas aplicaciones son llevadas a la realidad en la capa de infraestructura. Esto implica el mapeo de apli-caciones y componentes l´ogicos en artefactos f´ısicos como por ejemplo Java NetBeams.
7.4. IMPLEMENTACI ´ON Y DESPLIEGUE 77
7.4.2. Caso de Estudio
78 CAP´ITULO 7. CAPA DE TECNOLOG´IA
7.5.
Estructura de Informaci´
on
7.5.1. Modelo
El presente punto de vista es comparable al modelo tradicional de infor-maci´on creado en el desarrollo de cualquier sistema de informaci´on Muestra la estructura usada en la empresa o en un proceso de negocio o aplicaci´on especifica, en t´erminos de tipos de datos o estructuras de clases orientadas a objetos, inclusive, este punto de vista puede mostrar como la informaci´on a nivel de negocio es representada en el nivel de aplicaci´on.
7.5. ESTRUCTURA DE INFORMACI ´ON 79
7.5.2. Caso de Estudio
80 CAP´ITULO 7. CAPA DE TECNOLOG´IA
7.6.
Realizaci´
on del Servicio
7.6.1. Modelo
Este punto de vista es usado para mostrar como uno o mas servicios de negocio son llevados a la realidad por los procesos subyacentes y en algunas ocasiones por los componentes de aplicaci´on De esta manera conforma el puente entre el punto de vista de productos de negocio y la vista de procesos de negocio. Esto provee una (vista desde afuera) en uno o mas procesos de negocio.
7.6. REALIZACI ´ON DEL SERVICIO 81
7.6.2. Caso de Estudio
82 CAP´ITULO 7. CAPA DE TECNOLOG´IA
7.7.
Capas
7.7.1. Modelo
Este punto de vista esquematiza m´ultiples capas y aspectos de una ar-quitectura empresarial en un diagrama. Las capas son el resultado de usar relaciones de agrupamiento para un particionamiento natural del conjunto completo de objetos y relaciones que pertenecen a un modelo.
7.7. CAPAS 83
7.7.2. Caso de Estudio
Cap´ıtulo 8
Capa de Motivaci´
on
8.1.
Introducci´
on
la capa motivacional a˜nade los conceptos motivacionales tales como ob-jetivos, principios y requerimientos. Esto direcciona la forma en que la ar-quitectura empresarial esta alineada a su contexto, tal como lo describen los elementos motivacionales.
86 CAP´ITULO 8. CAPA DE MOTIVACI ´ON
8.2.
Stakeholder
8.2.1. Modelo
El punto de vista stakeholder le permite al analista modelar a los intere-sados, los motores de cambio y las valoraciones en t´erminos de fortalezas, debilidades, oportunidades y amenazas. Tambi´en pueden ser descritos los enlaces a los objetivos iniciales de alto nivel que direccionan estos asuntos y valoraciones. Estos objetivos conforman las bases para el proceso de inge-nier´ıa de requerimientos, incluyendo el refinamiento de objetivos y an´alisis de contribuciones y conflictos.
8.2. STAKEHOLDER 87
8.2.2. Caso de Estudio
En este punto de vista se identifican tres stakeholder:
Analista de monitoreo
Comercio
Tarjetahabiente
88 CAP´ITULO 8. CAPA DE MOTIVACI ´ON
8.3.
Realizaci´
on de Objetivos
8.3.1. Modelo
Este punto de vista permite al dise˜nador modelar el refinamiento de objetivos de alto nivel en objetivos mas concretos y el refinamiento de di-chos objetivos concretos en requerimientos o restricciones que describen las propiedades que son necesarias para realizar los objetivos.
8.3. REALIZACI ´ON DE OBJETIVOS 89
8.3.2. Caso de Estudio
90 CAP´ITULO 8. CAPA DE MOTIVACI ´ON
8.4.
Contribuci´
on de Objetivos
8.4.1. Modelo
El presente punto de vista permite modelar las relaciones influyentes entre objetivos y requerimientos. Las vistas resultantes pueden ser usadas para analizar el impacto que tienen los objetivos.
8.4. CONTRIBUCI ´ON DE OBJETIVOS 91
8.4.2. Caso de Estudio
Se observa en este punto de vista como se generan nuevos objetivos a partir de los requerimientos, se toman dos requerimientos de los cuales se muestran sus objetivos positivos y negativos. Se pueden crear objetivos ne-gativos ya que se pueden cruzar los requerimientos con los objetivos.
92 CAP´ITULO 8. CAPA DE MOTIVACI ´ON
8.5.
Principios
8.5.1. Modelo
El punto de vista de principios permite al dise˜nador modelar los prin-cipios que son relevantes al problema de dise˜no que se esta resolviendo, incluyendo los objetivos que motivaron dichos principios. En pocas palabras los principios son valores corporativos de la organizaci´on en base al objetivo planteado.
8.5. PRINCIPIOS 93
8.5.2. Caso de Estudio
94 CAP´ITULO 8. CAPA DE MOTIVACI ´ON
8.6.
Realizaci´
on de Requerimientos
8.6.1. Modelo
Este punto de vista permite modelar la realizaci´on de requerimientos por elementos fundamentales como actores, servicios o procesos de negocio. En s´ıntesis este punto de vista puede ser usado para refinar requerimientos en requerimientos mas detallados.
8.6. REALIZACI ´ON DE REQUERIMIENTOS 95
8.6.2. Caso de Estudio
96 CAP´ITULO 8. CAPA DE MOTIVACI ´ON
8.7.
Motivaci´
on
8.7.1. Modelo
El punto de vista permite modelar aspectos generales como una vista completa de los aspectos motivacionales relacionando a las partes interesa-das, sus objetos primarios, los principios que aplican y los requerimientos principales en servicios, procesos, aplicaciones y objetos.
8.7. MOTIVACI ´ON 97
8.7.2. Caso de Estudio
Cap´ıtulo 9
Capa de Proyecto
9.1.
Introducci´
on
La capa de proyecto incluye conceptos para modelar la implementaci´on de programas y los proyectos que soportan dicho programa, portafolio, ges-ti´on de proyectos y el concepto de platea para soportar la planeaci´on de migraciones.
100 CAP´ITULO 9. CAPA DE PROYECTO
9.2.
Proyecto
9.2.1. Modelo
El punto de vista de proyecto es usado principalmente para modelar la gesti´on del cambio de arquitectura. La Arquitectura del proceso de migraci´on de una vieja situaci´on (estado actual de la arquitectura empresarial) a una nueva y deseada situaci´on tiene consecuencias significativas en el mediano y largo plazo de la estrategia de crecimiento puesto que realizar la Arquitec-tura empresarial para toda una organizaci´on es un proceso que puede tardar a˜nos y es necesario el entero compromiso de todas las partes interesadas.
No obstante realizar la arquitectura permitir´a unir esfuerzos y mejorar cada uno de los procesos de la organizaci´on.
9.2. PROYECTO 101
9.2.2. Caso de Estudio
102 CAP´ITULO 9. CAPA DE PROYECTO
9.3.
Migraci´
on
9.3.1. Modelo
El punto de vista de migraci´on implica modelos y conceptos que pueden ser usados para especificar la transici´on de una arquitectura existente a una arquitectura deseada. Los conceptos principales modelados son las plateas (hitos del proyecto) y las brechas (dificultades que deben ser superadas).
9.3. MIGRACI ´ON 103
9.3.2. Caso de Estudio
104 CAP´ITULO 9. CAPA DE PROYECTO
9.4.
Implementaci´
on y Migraci´
on
9.4.1. Modelo
El presente punto de vista es usado para relacionar programas y pro-yectos con las partes de la arquitectura que ellos implementan. Esta vista permite modelar el alcance de programas, proyectos, actividades de proyec-tos en t´erminos de las plateas que son realizadas o los elementos individuales de arquitectura que son afectados.
9.4. IMPLEMENTACI ´ON Y MIGRACI ´ON 105
9.4.2. Caso de Estudio
Parte III
Dise˜
no
Cap´ıtulo 10
GoF
−Gang of Four−
10.1.
Introducci´
on
El concepto de patrones de dise˜no fue el resultado de un trabajo rea-lizado por un grupo de 4 personas (Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, conocidos como ”la pandilla de los cuatro - Gang of four”) que se public´o en 1995 en un libro titulado ”Patrones de dise˜no: Elementos de software orientado a objetos reutilizables.enel que se
esboza-ban 23 patrones de dise˜no.
La palabra patr´on fue definido por Cristopher Alexander como la apari-ci´on repetida de un problema y por supuesto el eje central de la soluci´on a dicho problema, de forma que esta pueda ser utilizada un mill´on de veces sin la necesidad de hacer todo desde ceros. Esta definici´on que fue utilizada para referirse a problemas de construcci´on de edificaciones, es perfectamente trasladable al contexto de construcci´on de software.
Un patr´on consta de 4 elementos principales;
NOMBRE DEL PATR ´ON: Este nombre se compone de una o dos palabras con las cuales nos referimos al problema de dise˜no, a su soluci´on y probablemente a las consecuencias de su aplicaci´on.
PROBLEMA: El problema describe cuando debe ser utilizado el patr´on, incluyendo de ser necesario el contexto de dicho problema y las condiciones presentes para considerar el uso del patr´on.
SOLUCI ´ON:La soluci´on describe los elementos de dise˜no necesarios
110 CAP´ITULO 10. GOF −GANG OF FOUR−
para resolver el problema, estructuras, colaboraciones, responsabilida-des.
10.2. CREACIONAL 111
10.2.
Creacional
Los patrones de dise˜no creacionales, abstraen el proceso de instanciacion de objetos. Ayudan a que un sistema sea independiente de como sus objetos son creados, compuestos y representados.
Los patrones creacionales se hacen mas importantes a medida que los siste-mas evolucionan para depender siste-mas de la composici´on de objetos que de la herencia de clases. Al suceder esto, el ´enfasis cambia de codificar un conjun-to fijo de comportamienconjun-tos hacia la definici´on de un conjunto de compor-tamientos fundamentales que pueden ser compuestos en unos mas complejos.
En estos patrones se representan dos temas recurrentes. El primero, todos buscan encapsular el conocimiento de que clase concreta utiliza el sistema. El segundo, todos ocultan como las instancias de dichas clases son creadas y puestas en conjunto.
Patr´on Descripci´on
Fabrica Abstracta
Provee una interface para crear familias de objetos relacio-nados o dependientes sin especificar sus clases concretas. Constructor Separa la construcci´on de un objeto complejo de su
repre-sentaci´on, de forma que el mismo proceso de construcci´on pueda crear diferentes representaciones.
M´etodo Fa-brica
Define una interface para crear un objeto, pero deja que las subclases decida que objeto instanciar.
Prototipo Especifica los tipos de objetos a crear usando instancias pro-tot´ıpicas, y crea los nuevos objetos copiando este prototipo. Singleton Asegura que una clase tenga una sola instancia, y provee un
punto global de acceso a ella.
112 CAP´ITULO 10. GOF −GANG OF FOUR−
10.2.1. Singleton
Modelo
Patr´on de dise˜no dise˜nado para restringir la creaci´on de objetos perte-necientes a una clase o el valor de un tipo a un ´unico objeto. Su intenci´on consiste en garantizar que una clase s´olo tenga una instancia y proporcionar un punto de acceso global a ella.
El patr´on singleton se implementa creando en nuestra clase un m´etodo que crea una instancia del objeto s´olo si todav´ıa no existe alguna. Para asegurar que la clase no puede ser instanciada nuevamente se regula el alcance del constructor (con modificadores de acceso como protegido o privado).
10.2. CREACIONAL 113
Caso de Estudio
114 CAP´ITULO 10. GOF −GANG OF FOUR−
10.2.2. Fabrica Abstracta
Modelo
El patr´on de dise˜no F´abrica Abstracta se utiliza para proporcionar una interfaz com´un para crear una serie de objetos (productos) bajo una u otra arquitectura o framework, sin que los clientes de dichos productos tengan que tener conocimiento de la arquitectura elegida para implementar cada familia de productos.
10.2. CREACIONAL 115
Caso de Estudio
Observamos en este patr´on como se crea una arquitectura com´un para diferentes productos, lo ideal de este patr´on es acoplarse a las propiedades del primer producto para posterior a ello tomar su l´ogica correspondiente.
116 CAP´ITULO 10. GOF −GANG OF FOUR−
10.2.3. M´etodo F´abrica
Modelo
Define una interface para crear un objeto, pero deja que sean las subcla-ses decidir cual clase debe ser instanciada. El m´etodo fabrica permite que una clase delegue la instanciacion de las subclases.
Este patr´on debe usarse cuando:
Una clase no puede anticipar la clase de objetos que deben ser creados.
Las clases delegan sus responsabilidades a uno o mas clases auxiliares, y se desea localizar el conocimiento de cual subclase auxiliar es la delegada.
10.2. CREACIONAL 117
Caso de Estudio
118 CAP´ITULO 10. GOF −GANG OF FOUR−
10.2.4. Constructor
Modelo
El prop´osito de este patr´on es separar la construcci´on de un objeto com-pleto de su representaci´on, de forma que el mismo proceso de construcci´on permita crear diferentes representaciones.
Este patr´on debe usarse cuando:
El algoritmo para crear un objeto complejo puede ser independiente de las partes que componen el objeto y de como estas son ensambladas.
El proceso de construcci´on tiene que permitir diferentes representacio-nes para el objeto que es construido.
10.2. CREACIONAL 119
Caso de Estudio
120 CAP´ITULO 10. GOF −GANG OF FOUR−
10.2.5. Prototipo
Modelo
El patr´on de dise˜no prototipo (Prototype), tiene como finalidad crear nuevos objetos duplic´andolos, clonando una instancia creada previamente.
Este patr´on especifica la clase de objetos a crear mediante la clonaci´on de un prototipo que es una instancia ya creada. La clase de los objetos que ser-vir´an de prototipo deber´a incluir en su interfaz la manera de solicitar una copia, que ser´a desarrollada luego por las clases concretas de prototipos.
10.2. CREACIONAL 121
Caso de Estudio
122 CAP´ITULO 10. GOF −GANG OF FOUR−
10.3.
Estructural
Los patrones estructurales se ocupan de como las clases y los objetos son compuestos para formar estructuras mas grandes
Los patrones estructurales de clase usan la herencia para componer inter-faces o implementaciones. En cambio los patrones estructurales de objeto describen formas de componer objetos para realizar una nueva funcionali-dad.
La flexibilidad a˜nadida de la composici´on de objetos viene de la habilidad para cambiar la composici´on en tiempo de ejecuci´on, lo cual es imposible con composici´on est´atica de clases.
Patr´on Descripci´on
Adaptador Convierte la interfaz de una clase en otra que el cliente es-pera. Permite que dos clases con interfaces incompatibles puedan trabajar juntas.
Puente Desacopla una abstracci´on de su implementaci´on de forma que las dos puedan variar independientemente.
Compuesto Compone objetos en estructuras de ´arbol que representan jerarqu´ıas parte-todo.
Decorador Agrega responsabilidades adicionales a un objeto dinamica-mente. los decoradores proveen una alternativa flexible a la herencia para extender funcionalidades.
Fachada Provee una interface unificada a un conjunto de interfaces en un subsistema. La fachada define una interface de alto nivel que hace al subsistema mas f´acil de usar.
Peso Ligero Usa objetos compartidos para soportar un largo numero de objetos granulares de forma mas eficiente.
Apoderado Provee un sucesor o reemplazante para otro objeto de forma que se pueda controlar el acceso a este.
10.3. ESTRUCTURAL 123
10.3.1. Adaptador
Modelo
El patr´on Adapter (Adaptador) se utiliza para transformar una interfaz en otra, de tal modo que una clase que no pudiera utilizar la primera, haga uso de ella a trav´es de la segunda.
El prop´osito de este patr´on es convertir la interfaz de una clase en otra interfaz que el cliente espera. Adapter permite a las clases trabajar juntas, lo que de otra manera no podr´ıa hacerlo debido a sus interfaces incompati-bles.
124 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
Observamos en la figura los siguientes participantes y su funci´on:
Target: define la interfaz espec´ıfica del dominio que Client usa.
Client: colabora con la conformaci´on de objetos para la interfaz Target.
Adaptee: define una interfaz existente que necesita adaptarse.
10.3. ESTRUCTURAL 125
10.3.2. Puente
Modelo
El patr´on Bridge, tambi´en conocido como Handle/Body, es una t´ecnica usada en programaci´on para desacoplar una abstracci´on de su implementa-ci´on, de manera que ambas puedan ser modificadas independientemente sin necesidad de alterar por ello la otra. Esto es, se desacopla una abstracci´on de su implementaci´on para que puedan variar independientemente.
126 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
Observamos en la figura los siguientes participantes y su funci´on:
Abstraction: define una interface abstracta. Mantiene una referencia a un objeto de tipo Implementor.
RefinedAbstraction: extiende la interface definida por Abstraction.
Implementor define la interface para la implementaci´on de clases. Esta interface no se tiene que corresponder exactamente con la interface de Abstraction; de hecho, las dos interfaces pueden ser bastante diferente.
10.3. ESTRUCTURAL 127
10.3.3. Componente
Modelo
Este patr´on sirve para construir objetos complejos a partir de otros m´as simples y similares entre s´ı, gracias a la composici´on recursiva y a una es-tructura en forma de ´arbol.
Esto simplifica el tratamiento de los objetos creados, ya que al poseer todos ellos una interfaz com´un, se tratan todos de la misma manera. Dependiendo de la implementaci´on, pueden aplicarse procedimientos al total o una de las partes de la estructura compuesta como si de un nodo final se tratara, aunque dicha parte est´e compuesta a su vez de muchas otras. Un claro ejem-plo de uso extendido de este patr´on se da en los entornos de programaci´on 2D para aplicaciones gr´aficas. Un videojuego puede contener diferentes ca-pas ”layers”de sprites (como una capa de enemigos) pudi´endose invocar un m´etodo que act´ue sobre toda esta capa de sprites a la vez (por ejemplo, para ocultarlos, darles un filtro de color etc.).
128 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
Se observa con este patr´on como se pueden crear estructuras en ´arbol ya que es posible construir nuevos objetos incluso mas complejos que los primarios, es fundamental que la clase primaria cumpla con las propiedades necesarias para crear nuevas subclases a partir de ella.
10.3. ESTRUCTURAL 129
10.3.4. Decorador
Modelo
El patr´on Decorador responde a la necesidad de a˜nadir din´amicamente funcionalidad a un Objeto. Esto nos permite no tener que crear sucesivas clases que hereden de la primera incorporando la nueva funcionalidad, sino otras que la implementan y se asocian a la primera.
130 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
En la figura ser observa los siguientes componentes con su funci´on:
Decorador: Mantiene una referencia al componente asociado. Imple-menta la interfaz de la superclase Componente delegando en el com-ponente asociado.
10.3. ESTRUCTURAL 131
10.3.5. Fachada
Modelo
Fachada es un tipo de patr´on de dise˜no estructural. Viene motivado por la necesidad de estructurar un entorno de programaci´on y reducir su com-plejidad con la divisi´on en subsistemas, minimizando las comunicaciones y dependencias entre estos.
es un tipo de patr´on de dise˜no estructural. Viene motivado por la necesidad de estructurar un entorno de programaci´on y reducir su complejidad con la divisi´on en subsistemas, minimizando las comunicaciones y dependencias entre estos.
132 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
10.3. ESTRUCTURAL 133
10.3.6. Peso Ligero
Modelo
El patr´on Flyweight (u objeto ligero) sirve para eliminar o reducir la re-dundancia cuando tenemos gran cantidad de objetos que contienen informa-ci´on id´entica, adem´as de lograr un equilibrio entre flexibilidad y rendimiento (uso de recursos).
134 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
10.3. ESTRUCTURAL 135
10.3.7. Proxy
Modelo
El patr´on Proxy es un patr´on estructural que tiene como prop´osito pro-porcionar un subrogado o intermediario de un objeto para controlar su ac-ceso.El patr´on proxy se usa cuando se necesita una referencia a un objeto m´as flexible o sofisticada que un puntero. Dependiendo de la funci´on que se desea realizar con dicha referencia podemos distinguir diferentes tipos de proxies:
proxy remoto: representante local de un objeto remoto.
proxy virtual: crea objetos costosos bajo demanda (como la clase Ima-genProxy en el ejemplo de motivaci´on).
proxy de protecci´on: controla el acceso al objeto original.
proxy de referencia inteligente: sustituto de un puntero que lleva a cabo operaciones adicionales cuando se accede a un objeto.
136 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
10.4. COMPORTAMIENTO 137
10.4.
Comportamiento
Los patrones de comportamiento se ocupan de los algoritmos y de la asig-naci´on de responsabilidades entre los objetos. Estos patrones no solamente describen patrones de clases u objetos sino tambi´en patrones de comunica-ci´on entre ellos. Estos patrones caracterizan flujos de control complejos que son dif´ıciles de trazar en tiempo de ejecuci´on
138 CAP´ITULO 10. GOF −GANG OF FOUR−
Patr´on Descripci´on
Cadena de responsabi-lidad
Evita acoplar al emisor de una petici´on con su receptor dan-do a mas de un objeto la posibilidad de manejar la petici´on
Comando Encapsula una petici´on como un objeto permitiendo que los clientes puedan ser parametrizados con diferentes peticiones, guardarlas o trazarlas.
Iterador Provee una forma de acceder secuencialmente a los elementos de un objeto colecci´on sin exponer su representaci´on interna. Interprete Dado un lenguaje, define una representaci´on de su gram´atica y un interprete que usa dicha representaci´on para interpretar sentencias de dicho lenguaje.
Mediador Define un objeto que encapsula el como interactuan un con-junto de objetos. El mediador promueve el bajo acoplamien-to evitando las referencias explicitas y permitiendo variar las interacciones de forma independiente.
Recuerdo Sin violar la encapsulacion, captura y externaliza el estado interno de un objeto de forma que pueda ser restaurado un estado anterior posteriormente.
Observador Define dependencias uno a muchos entre objetos, de forma que cuando un objeto cambie su estado todos los dependien-tes sean notificados y actualizados autom´aticamente Estado Permite que un objeto cambie su comportamiento cuando su
estado interno cambie. El objeto aparenta cambiar su clase. Estrategia Define una familia de algoritmos, encapsula cada uno y los vuelve intercambiables Permite que el algoritmo var´ıe inde-pendientemente de los clientes que lo usan.
M´etodo Plantilla
Define el esqueleto de un algoritmo en una operaci´on, de-legando algunos pasos a subclases. Permite que se puedan redefinir ciertos pasos del algoritmo sin cambiar la estructu-ra del mismo.
Visitante Representa una operaci´on para que sea realizada en los ob-jetos estructura del objeto. Permite definir una nueva ope-raci´on sin cambiar las clases o elementos en los cuales opera.
10.4. COMPORTAMIENTO 139
10.4.1. Cadena de Responsabilidades
Modelo
El patr´on de dise˜no cadena de responsabilidad es un patr´on de compor-tamiento que evita acoplar el emisor de una petici´on a su receptor dando a m´as de un objeto la posibilidad de responder a una petici´on. Para ello, se encadenan los receptores y pasa la petici´on a trav´es de la cadena hasta que es procesada por alg´un objeto. Este patr´on es utilizado a menudo en el contexto de las interfaces gr´aficas de usuario donde un objeto puede estar compuesto de varios objetos (que generalmente heredan de una super clase ”vista”).
140 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
10.4. COMPORTAMIENTO 141
10.4.2. Comando
Modelo
Este patr´on permite solicitar una operaci´on a un objeto sin conocer real-mente el contenido de esta operaci´on, ni el receptor real de la misma. Para ello se encapsula la petici´on como un objeto, con lo que adem´as facilita la parametrizaci´on de los m´etodos.
Prop´osito
Encapsula un mensaje como un objeto, con lo que permite gestionar colas o registro de mensaje y deshacer operaciones.
Soportar restaurar el estado a partir de un momento dado.
Ofrecer una interfaz com´un que permita invocar las acciones de for-ma uniforme y extender el sistefor-ma con nuevas acciones de forfor-ma m´as sencilla.
142 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
10.4. COMPORTAMIENTO 143
10.4.3. Iterador
Modelo
En dise˜no de software, el patr´on de dise˜no Iterador, define una interfaz que declara los m´etodos necesarios para acceder secuencialmente a un grupo de objetos de una colecci´on. Algunos de los m´etodos que podemos definir en la interfaz Iterador son:
Primero()
Siguiente()
HayMas()
ElementoActual()
Este patr´on de dise˜no permite recorrer una estructura de datos sin que sea necesario conocer la estructura interna de la misma.
144 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
10.4. COMPORTAMIENTO 145
10.4.4. Interprete
Modelo
El interprete es un patr´on de dise˜no que, dado un lenguaje, define una representaci´on para su gram´atica junto con un int´erprete del lenguaje.Se usa para definir un lenguaje para representar expresiones regulares que repre-senten cadenas a buscar dentro de otras cadenas. Adem´as, en general, para definir un lenguaje que permita representar las distintas instancias de una familia de problemas.
146 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
La soluci´on es representar la gram´atica del lenguaje (previamente defini-da) mediante una jerarqu´ıa de objetos. Los nodos terminales de las produc-ciones los representaremos creando clases TerminalExpression y los nodos no terminales con NonterminalExpression. Ambas clases implementan una interfaz com´un (o heredan de una clase abstracta com´un) llamada Abstrac-tExpression y que contendr´a la declaraci´on del m´etodo interpret(), que se encargar´a de evaluar el nodo en concreto.
10.4. COMPORTAMIENTO 147
10.4.5. Mediador
Modelo
El patr´on mediador define un objeto que encapsula c´omo un conjunto de objetos interact´uan. Este patr´on de dise˜no est´a considerado como un patr´on de comportamiento debido al hecho de que puede alterar el comportamiento del programa en ejecuci´on.
Habitualmente un programa est´a compuesto de un n´umero de clases (mu-chas veces elevado). La l´ogica y computaci´on es distribuida entre esas clases. Sin embargo, cuantas m´as clases son desarrolladas en un programa, espe-cialmente durante mantenimiento y/o refactorizaci´on, el problema de comu-nicaci´on entre estas clases quiz´as llegue a ser m´as complejo. Esto hace que el programa sea m´as dif´ıcil de leer y mantener. Adem´as, puede llegar a ser dif´ıcil cambiar el programa, ya que cualquier cambio podr´ıa afectar c´odigo en muchas otras clases.
148 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
10.4. COMPORTAMIENTO 149
10.4.6. Momento
Modelo
Momento, es un patr´on de dise˜no cuya finalidad es almacenar el estado de un objeto (o del sistema completo) en un momento dado de manera que se pueda restaurar en ese punto de manera sencilla. Para ello se mantiene almacenado el estado del objeto para un instante de tiempo en una clase independiente de aquella a la que pertenece el objeto (pero sin romper la encapsulaci´on), de forma que ese recuerdo permita que el objeto sea modi-ficado y pueda volver a su estado anterior.
Se usa este patr´on cuando se quiere poder restaurar el sistema desde es-tados pasados y por otra parte, es usado cuando se desea facilitar el hacer y deshacer de determinadas operaciones, para lo que habr´a que guardar los estados anteriores de los objetos sobre los que se opere (o bien recordar los cambios de forma incremental).
150 CAP´ITULO 10. GOF −GANG OF FOUR−
Caso de Estudio
10.4. COMPORTAMIENTO 151
10.4.7. Observador
Modelo
Observador (en ingl´es: Observer) es un patr´on de dise˜no que define una dependencia del tipo uno-a-muchos entre objetos, de manera que cuando uno de los objetos cambia su estado, notifica este cambio a todos los dependien-tes.El patr´on Observer es la clave del patr´on de arquitectura Modelo Vista Controlador (MVC).1 De hecho el patr´on fue implementado por primera vez en Smalltalk’s MVC basado en un framework de interfaz.2 Este patr´on est´a implementado en numerosos librer´ıas y sistemas, incluyendo todos los toolkits de GUI.
