Desarrollo de un prototipo de aplicaci on web para el ...repository.udistrital.edu.co/.../6086/1/EstradaTinjacaDiegoArmando2… · Autor: Diego Armando Estrada Tinjac a Director:

Desarrollo de un prototipo de aplicacion

web para el monitoreo y control de ventas

que realizan los clientes de la empresa

Pago Digital

Autor: Diego Armando Estrada TinjacaDirector: Jose Ignacio Palacios Osma

25 de mayo de 2017

2

0.1. RESUMEN 3

0.1. Resumen

El presente trabajo de grado trata sobre la creacion de una aplicacion webdonde una empresa especıfica podra 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 elproyecto y la forma de implementarlo en base a la arquitectura empresarialapoyada de marcos de referencia como TOGAF 9.1.

Se presentara al lector la informacion de la empresa a nivel de organiza-cion como los son organigrama, servicios y procesos, esta informacion estatotalmente abalada por la empresa la cual se beneficiara de dicho software.

El teletrabajo es parte fundamental del proyecto, por ende se aborda infor-macion acerca de este tema a lo largo del documento, se intenta evidenciarsu impacto en Latinoamerica y especialmente en las empresas Colombianas.

0.2. Palabras Clave

Teletrabajo, Arquitectura empresarial, PHP, Pago Digital, Tarjetahabien-te, ventas, comercio, credito, debito, PCI, monitoreo, Credibanco, pasarela,seguridad, metamodelo, TOGAF, Archimate, ADM, fases, portal.

4

0.3. Abstract

The present work of degree deals with the creation of a web applicationwhere a specific company can provide its employees a tool to work from anyplace 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 supportedby frames of reference as TOGAF 9.1.

The information of the company will be presented to the reader at theorganization level as they are organization chart, services and processes,this information is totally shaken by the company that will benefit of saidsoftware.

Teleworking is a fundamental part of the project, so information about thistopic is addressed throughout the document, an attempt is made to showits impact in Latin America and especially in Colombian companies.

0.4. Keywords

Teleworking, Business architecture, PHP, Pago Digital, Cardholder, sales,commerce, credit, debit, PCI, monitoring, credibanco, pasarela, security,metamodel, TOGAF, Archimate, ADM, phases, portal.

0.5. AGRADECIMIENTOS 5

0.5. Agradecimientos

Dedicado a mis padres Nancy y Arturo quienes a pesar de las circunstanciasme apoyaron y creyeron siempre en mı, a mi novia Yuly que ha estado a milado en los buenos y malos momentos y a todos los docentes que hicieronparte de este proyecto.

A la empresa Pago Digital por depositar su confianza en mı y entregarmeparte de su core del negocio para la realizacion de este proyecto y en especiala William el Director general de la empresa a quien le tengo un profundoaprecio.

6

Indice general

0.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30.2. Palabras Clave . . . . . . . . . . . . . . . . . . . . . . . . . . 30.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40.4. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40.5. Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . 5

I Proyecto 17

1. Anteproyecto 191.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.2. Definicion del Problema . . . . . . . . . . . . . . . . . . . . . 211.3. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.4.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . 231.4.2. Objetivos Especıficos . . . . . . . . . . . . . . . . . . . 23

1.5. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.5.1. Social . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.5.2. Tecnologica . . . . . . . . . . . . . . . . . . . . . . . . 241.5.3. Ambiental . . . . . . . . . . . . . . . . . . . . . . . . . 24

2. Metodologıa 252.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2. Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3. Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

II Arquitectura 29

3. Empresa 313.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7

8 INDICE GENERAL

3.2. Mision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3. Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4. Organigrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.5. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.5.1. Proceso de venta con carrito de compras . . . . . . . . 34

3.5.2. Proceso de venta telefonica . . . . . . . . . . . . . . . 34

3.6. Productos y Servicios . . . . . . . . . . . . . . . . . . . . . . 35

3.6.1. Carrito Digital . . . . . . . . . . . . . . . . . . . . . . 35

3.6.2. Integracion Digital . . . . . . . . . . . . . . . . . . . . 35

3.6.3. Enlace Digital . . . . . . . . . . . . . . . . . . . . . . 35

3.6.4. Boton Digital . . . . . . . . . . . . . . . . . . . . . . . 35

3.7. Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.7.1. Gerencia . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.7.2. Direccion Comercial . . . . . . . . . . . . . . . . . . . 36

3.7.3. Direccion de Mercadeo y Publicidad . . . . . . . . . . 36

3.7.4. Area Contadurıa . . . . . . . . . . . . . . . . . . . . . 36

3.8. Objetivos Organizacionales . . . . . . . . . . . . . . . . . . . 37

3.8.1. Objetivo 1 . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.8.2. Objetivo 2 . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.8.3. Objetivo 3 . . . . . . . . . . . . . . . . . . . . . . . . . 37

4. Archimate y ADM 39

4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2. Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.1. Diseno de arquitectura . . . . . . . . . . . . . . . . . . 40

4.2.2. Tres Capas fundamentales . . . . . . . . . . . . . . . . 42

4.2.3. ArchiMate y TOGAF . . . . . . . . . . . . . . . . . . 42

4.2.4. Correspondencia entre Archimate y TOGAF . . . . . 43

4.3. ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3.1. Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5. Capa de Negocio 47

5.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2. Organizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 49

5.3. Cooperacion de Actor . . . . . . . . . . . . . . . . . . . . . . 50

5.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.4. Organizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 50

INDICE GENERAL 9

5.4.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 51

5.5. Funcion de Negocio . . . . . . . . . . . . . . . . . . . . . . . . 52

5.5.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.5.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 53

5.6. Proceso de Negocio . . . . . . . . . . . . . . . . . . . . . . . . 54

5.6.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.6.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 55

5.7. Cooperacion de Proceso de Negocio . . . . . . . . . . . . . . . 56

5.7.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.7.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 57

5.8. Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.8.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.8.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 59

6. Capa de Aplicacion 61

6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.2. Comportamiento de Aplicacion . . . . . . . . . . . . . . . . . 62

6.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 63

6.3. Cooperacion de Aplicacion . . . . . . . . . . . . . . . . . . . . 64

6.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.3.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 65

6.4. Estructura de Aplicacion . . . . . . . . . . . . . . . . . . . . . 66

6.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.4.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 67

6.5. Uso de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . 68

6.5.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.5.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 69

7. Capa de Tecnologıa 71

7.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.2. Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.2.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 73

7.3. Uso Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . 74

7.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.3.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 75

7.4. Implementacion y Despliegue . . . . . . . . . . . . . . . . . . 76

7.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.4.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 77

10 INDICE GENERAL

7.5. Estructura de Informacion . . . . . . . . . . . . . . . . . . . . 78

7.5.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.5.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 79

7.6. Realizacion del Servicio . . . . . . . . . . . . . . . . . . . . . 80

7.6.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.6.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 81

7.7. Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.7.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.7.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 83

8. Capa de Motivacion 85

8.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8.2. Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

8.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 86

8.2.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 87

8.3. Realizacion de Objetivos . . . . . . . . . . . . . . . . . . . . . 88

8.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8.3.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 89

8.4. Contribucion de Objetivos . . . . . . . . . . . . . . . . . . . . 90

8.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 90

8.4.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 91

8.5. Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.5.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.5.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 93

8.6. Realizacion de Requerimientos . . . . . . . . . . . . . . . . . 94

8.6.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 94

8.6.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 95

8.7. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

8.7.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 96

8.7.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 97

9. Capa de Proyecto 99

9.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

9.2. Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

9.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 100

9.2.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 101

9.3. Migracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

9.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 102

9.3.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 103

9.4. Implementacion y Migracion . . . . . . . . . . . . . . . . . . . 104

INDICE GENERAL 11

9.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 104

9.4.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 105

III Diseno 107

10.GoF −Gang of Four− 109

10.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

10.2. Creacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

10.2.1. Singleton . . . . . . . . . . . . . . . . . . . . . . . . . 112

10.2.2. Fabrica Abstracta . . . . . . . . . . . . . . . . . . . . 114

10.2.3. Metodo Fabrica . . . . . . . . . . . . . . . . . . . . . . 116

10.2.4. Constructor . . . . . . . . . . . . . . . . . . . . . . . . 118

10.2.5. Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . 120

10.3. Estructural . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

10.3.1. Adaptador . . . . . . . . . . . . . . . . . . . . . . . . 123

10.3.2. Puente . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

10.3.3. Componente . . . . . . . . . . . . . . . . . . . . . . . 127

10.3.4. Decorador . . . . . . . . . . . . . . . . . . . . . . . . . 129

10.3.5. Fachada . . . . . . . . . . . . . . . . . . . . . . . . . . 131

10.3.6. Peso Ligero . . . . . . . . . . . . . . . . . . . . . . . . 133

10.3.7. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

10.4. Comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . 137

10.4.1. Cadena de Responsabilidades . . . . . . . . . . . . . . 139

10.4.2. Comando . . . . . . . . . . . . . . . . . . . . . . . . . 141

10.4.3. Iterador . . . . . . . . . . . . . . . . . . . . . . . . . . 143

10.4.4. Interprete . . . . . . . . . . . . . . . . . . . . . . . . . 145

10.4.5. Mediador . . . . . . . . . . . . . . . . . . . . . . . . . 147

10.4.6. Momento . . . . . . . . . . . . . . . . . . . . . . . . . 149

10.4.7. Observador . . . . . . . . . . . . . . . . . . . . . . . . 151

10.4.8. Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

10.4.9. Estrategia . . . . . . . . . . . . . . . . . . . . . . . . . 155

10.4.10.Metodo Plantilla . . . . . . . . . . . . . . . . . . . . . 157

10.4.11.Visitador . . . . . . . . . . . . . . . . . . . . . . . . . 159

IV Reflexiones 161

11.Conclusiones - Trabajos Futuros - Contrastacion 163

11.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

12 INDICE GENERAL

11.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . 16411.3. Contrastacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 16511.4. Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

11.4.1. Libros . . . . . . . . . . . . . . . . . . . . . . . . . . . 16711.4.2. Artıculos . . . . . . . . . . . . . . . . . . . . . . . . . 16711.4.3. Conferencias . . . . . . . . . . . . . . . . . . . . . . . 16711.4.4. Otros . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

11.5. Imagenes Portal PD . . . . . . . . . . . . . . . . . . . . . . . 16911.5.1. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . 16911.5.2. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Indice de figuras

2.1. Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2. Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1. Logotipo - Logo Pago Digital . . . . . . . . . . . . . . . . . . 313.2. Organigrama - Pago Digital . . . . . . . . . . . . . . . . . . . 33

4.1. Modelo: Archimate . . . . . . . . . . . . . . . . . . . . . . . . 434.2. Metodo: ADM . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1. Metamodelo Organizacion: Pago Digital . . . . . . . . . . . . 485.2. Metamodelo Cooperacion de Actor: Pago Digital . . . . . . . 505.3. Metamodelo Funcion de Negocio: Pago Digital . . . . . . . . 525.4. Metamodelo Proceso de Negocio: Venta telefonica a tarjeta-

habiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5. Metamodelo Cooperacion de Proceso de Negocio: Venta te-

lefonica a tarjetahabiente . . . . . . . . . . . . . . . . . . . . 565.6. Metamodelo Cooperacion de Proceso de Negocio: Pago Digital 58

6.1. Metamodelo Comportamiento de Aplicacion: Pago Digital . . 626.2. Metamodelo Cooperacion de Aplicacion: Pago Digital . . . . 646.3. Metamodelo Estructura de Aplicacion: Pago Digital . . . . . 666.4. Metamodelo Uso de Aplicacion: Pago Digital . . . . . . . . . 68

7.1. Metamodelo Infraestructura: Pago Digital . . . . . . . . . . . 727.2. Metamodelo Uso de Infraestructura: Pago Digital . . . . . . . 747.3. Metamodelo Implementacion y Despliegue: Pago Digital . . . 767.4. Metamodelo Estructura de informacion: Pago Digital . . . . . 787.5. Metamodelo Realizacion del servicio: Pago Digital . . . . . . 807.6. Metamodelo Capas: Pago Digital (Ventas con tarjeta de credito) 82

8.1. Metamodelo Stakeholder: Pago Digital (Partes interesadas) . 86

13

14 INDICE DE FIGURAS

8.2. Metamodelo Realizacion de Objetivos: Pago Digital (Objeti-vos Partes interesadas) . . . . . . . . . . . . . . . . . . . . . . 88

8.3. Metamodelo Contribucion de Objetivos: Pago Digital . . . . . 90

8.4. Metamodelo Principios: Pago Digital (Valores Corporativos) . 92

8.5. Metamodelo Realizacion de Requerimientos: Pago Digital . . 94

8.6. Metamodelo Motivacion: Pago Digital(Monitorear ventas entiempo real ) . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

9.1. Metamodelo Proyecto: Pago Digital . . . . . . . . . . . . . . . 100

9.2. Metamodelo Migracion: Pago Digital . . . . . . . . . . . . . . 102

9.3. Metamodelo Implementacion y Migracion: Pago Digital . . . 104

10.1. Estructura: Patron Metodo Singleton . . . . . . . . . . . . . . 112

10.2. Estructura: Patron Metodo Fabrica Abstracta . . . . . . . . . 114

10.3. Estructura: Patron Metodo Fabrica . . . . . . . . . . . . . . . 116

10.4. Estructura: Patron Metodo Constructor . . . . . . . . . . . . 118

10.5. Estructura: Patron Metodo Prototipo . . . . . . . . . . . . . 120

10.6. Estructura: Patron Metodo Adaptador . . . . . . . . . . . . . 123

10.7. Estructura: Patron Metodo Puente . . . . . . . . . . . . . . . 125

10.8. Estructura: Patron Metodo Componente . . . . . . . . . . . . 127

10.9. Estructura: Patron Metodo Decorador . . . . . . . . . . . . . 129

10.10.Estructura: Patron Metodo Fachada . . . . . . . . . . . . . . 131

10.11.Estructura: Patron Metodo Peso Ligero . . . . . . . . . . . . 133

10.12.Estructura: Patron Metodo Proxy . . . . . . . . . . . . . . . 135

10.13.Estructura: Patron Metodo Cadena de Responsabilidad . . . 139

10.14.Estructura: Patron Metodo Comando . . . . . . . . . . . . . 141

10.15.Estructura: Patron Metodo Iterador . . . . . . . . . . . . . . 143

10.16.Estructura: Patron Metodo Interprete . . . . . . . . . . . . . 145

10.17.Estructura: Patron Metodo Mediador . . . . . . . . . . . . . 147

10.18.Estructura: Patron Metodo Momento . . . . . . . . . . . . . . 149

10.19.Estructura: Patron Metodo Observador . . . . . . . . . . . . 151

10.20.Estructura: Patron Metodo Estado . . . . . . . . . . . . . . . 153

10.21.Estructura: Patron Metodo Estrategia . . . . . . . . . . . . . 155

10.22.Estructura: Patron Metodo Plantilla . . . . . . . . . . . . . . 157

10.23.Estructura: Patron Metodo Visitador . . . . . . . . . . . . . . 159

11.1. Portal PD: Listar Comercios . . . . . . . . . . . . . . . . . . . 169

11.2. Portal PD: Crear Comercios . . . . . . . . . . . . . . . . . . . 170

11.3. Portal PD: Listar Tarjetahabiente . . . . . . . . . . . . . . . 170

11.4. Portal PD: Crear Tarjetahabiente . . . . . . . . . . . . . . . . 171

INDICE DE FIGURAS 15

11.5. Portal PD: Detalle de Ventas . . . . . . . . . . . . . . . . . . 17111.6. Portal PD: Migracion Creacion de Empresa . . . . . . . . . . 17211.7. Portal PD: Creacion de Modelo . . . . . . . . . . . . . . . . . 17211.8. Portal PD: Creacion de Controlador . . . . . . . . . . . . . . 17311.9. Portal PD: Creacion de la Ruta . . . . . . . . . . . . . . . . . 17311.10.Portal PD: Consulta con Eloquent Laravel . . . . . . . . . . . 17411.11.Portal PD: Configuracion de la Vista . . . . . . . . . . . . . . 17411.12.Portal PD: Modelo Relacional . . . . . . . . . . . . . . . . . . 175

16 INDICE DE FIGURAS

Parte I

Proyecto

17

Capıtulo 1

Anteproyecto

1.1. Introduccion

El presente proyecto de investigacion se basa en la creacion d e un pro-totipo de aplicacion web para la empresa Pago Digital Colombia, donde lostrabajadores podran controlar y monitorear las ventas que los clientes de laempresa realizan a los tarjetahabientes (Poseedor de tarjeta credito o debi-to), esta actividad se podra ejecutar sin la necesidad de estar en un lugar fijo.

El area especıfica a la cual se encuentra dirigida la aplicacion es el areade monitoreo (callcenter). Esta actividad se realizara bajo la modalidad deteletrabajo la cual no requiere la presencia fısica del trabajador, por ende elempleado cuenta con la libertad de elegir su sitio de trabajo.

Uno de los factores fundamentales para asegurar el cumplimiento del te-letrabajo es el modulo de reconocimiento de voz donde el empleado deberaloguearse constantemente para validar su presencia en el sistema. Cabe acla-rar que el teletrabajo no es una profesion, un callcenter o un servicio a do-micilio, es solo una forma de realizar una actividad laboral especıfica quepermite 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 termino estas actividades. Lautilizacion de tecnologıas para facilitar la comunicacion es vital para llevara cabo esta modalidad de trabajo.

19

20 CAPITULO 1. ANTEPROYECTO

El presente documento se encuentra distribuido en cuatro partes funda-mentales: contextualizacion, arquitectura empresarial, diseno y conclusiones.Fuente: http://www.teletrabajo.gov.co/622/w3-article-11324.html

1.2. DEFINICION DEL PROBLEMA 21

1.2. Definicion del Problema

Actualmente la empresa Pago Digital dedicada al procesamiento de pa-gos con tarjeta de credito y debito, monitorea las ventas realizadas a tarjeta-habientes (poseedores de tarjeta credito o debito) por vıa telefonica. Estasventas son monitoreadas al instante para evitar posibles fraudes bancarios.

Los trabajadores de la empresa del area monitoreo (callcenter) controlanlas ventas en su horario laboral de 8:00 am a 6:00 pm, es por ello que lasventas realizadas posterior a las 6:00 pm, no son monitoreadas al instante,dando lugar a posibles fraudes con tarjetas ya que las ventas se monitoreanal siguiente dıa habil.

Actualmente el area de callcenter lleva el control de las ventas que mo-nitorean en un archivo en excel el cual se alimenta a diario hasta las 6:00PM, es por ello que las ventas que realizan los comercios posterior a estahora no son monitoreadas.


1.3. Hipotesis

Mediante una aplicacion web, los trabajadores de Pago Digital podranmonitorear las ventas que realizan sus clientes despues de las 6:00 pm.

1.4. OBJETIVOS 23

1.4. Objetivos

1.4.1. Objetivo General

Crear un prototipo de aplicacion por medio de tecnologıas web parael monitoreo y control de ventas no presenciales.

1.4.2. Objetivos Especıficos

Disenar los formularios del aplicativo web sin consultas SQL para evi-tar inyecciones de tipo sql inyection.

Crear un panel de administracion en lenguaje PHP donde los traba-jadores podran ingresar los detalles de una venta.

Disenar el prototipo web en base al modelo MVC para que la aplicacionsea escalable en el tiempo.


1.5. Justificacion

1.5.1. Social

Estamos en una era donde la tecnologıa influye en diferentes decisionesque la sociedad debe tomar, muchas de ellas cambian drasticamente al mo-mento de elegir o no un elemento tecnologico, es por ello que dar el salto aluso de estas herramientas se vuelve tormentoso mas si no se cuenta con laexperiencia necesaria para tomar decisiones.

Un claro ejemplo son las compras por internet, existe temor de realizartransacciones por este medio y esto es un paradigma que afecta al desarrollotecnologico del paıs.

Casos como el mencionado anteriormente se le suma la poca credibilidadque una empresa tiene en el teletrabajo donde la union de tecnologıas puedelograr esta forma de trabajo beneficiando al trabajador y a la empresa.

Con el desarrollo del presente proyecto la empresa Pago Digital dara unpaso hacia la innovacion tecnologica apoyando esta forma de trabajo quecrece dıa a dia en latinoamerica.

1.5.2. Tecnologica

A nivel tecnologico Pago Digital apuesta por la union de tecnologıas webpara que el control sobre sus ventas no presenciales cuenten con la seguridadnecesaria para no afectar a los tarjetahabientes.

La empresa actualmente se encuentra en el proceso de certificacion PCIpor ende solicita que sus desarrollos no tengan consultas SQL en sus scripts,por ende se tomo la decision de desarrollar el software en un framework co-mo laravel el cual no trabaja con este tipo de consultas gracias a su moduloeloquent el cual con menos lineas de codigo es posible crear las consultas ala base de datos.

1.5.3. Ambiental

Gracias al teletrabajo el desplazamiento de los trabajadores de PagoDigital sera mınimo y con ello muchos de sus asesores con vehıculo propiono tendran que utilizarlo para desplazarse a su lugar de trabajo.

Capıtulo 2

Metodologıa

2.1. Introduccion

Para la elaboracion del presente proyecto se tomara la metodologıa ensus fases de analisis y ejecucion donde se analizara el estado actual y sepresentara una alternativa de solucion detallada en base a la arquitecturaempresarial.

Se identificaran las partes interesadas y ası mismo sus puntos de vista paraabordar mejor el proyecto y poder cubrir las necesidades de cada uno deellos, todo esto apoyado bajo el marco togaf en su version 9.1 y en lenguajede modelado archimate.

25

26 CAPITULO 2. METODOLOGIA

2.2. Archimate

Figura 2.1: Archimate

El lenguaje de modelado seleccionado para la elaboracion del proyectoes archimate, lo cual permitira definir los componentes de la empresa a nivelgeneral centrandonos especıficamente en el area de monitoreo (callcenter)con sus actores respectivos.

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

Se tiene estimado realizar la entrega del proyecto en el mes de mayo y realizarun acto de gobierno hasta el primero de junio.

28 CAPITULO 2. METODOLOGIA

Parte II

Arquitectura

29

Capıtulo 3

Empresa

3.1. Introduccion

Pago Digital es una empresa Colombiana creada en el 2013 por el Sr.William Alonso Talero Rivera, sus inicios fueron en el barrio JJ Vargasde la ciudad de Bogota, la experiencia y habilidades del Sr. William lollevaron a crear una pasarela de pagos donde diferentes personas poseedorasde tarjetas de credito o debito (tarjetahabientes) pueden realizar pagos,compras , consignaciones etc. por medio de su sistema.

Figura 3.1: Logotipo - Logo Pago Digital

31

32 CAPITULO 3. EMPRESA

3.2. Mision

Proveer un sistema de pago seguro con soluciones a diferentes tipos denegocios brindando un sistema antifraude con mejora continua y adaptando-se a los cambios socioculturales, para convertirnos en una empresa lıder depagos en lınea.

3.3. Vision

Ser reconocidos como una empresa con altos niveles de seguridad a ni-vel nacional, brindando productos de alta calidad, expandiendo su rangode accion a nivel internacional, consolidandonos como una de las mejoresempresas del sector en Latinoamerica.

3.4. ORGANIGRAMA 33

3.4. Organigrama

En la figura 3.2 se presenta la organizacion estructural de Pago Digital,la estructura la componen un area principal y 3 sub areas:

Gerencia area principal

Direccion de Mercadeo

Direccion Comercial

Area Contadurıa

Figura 3.2: Organigrama - Pago Digital


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 deventas, citaremos los diferentes procesos que tiene la empresa en cuanto ala venta concierne.

3.5.1. Proceso de venta con carrito de compras

Si un cliente de Pago Digital tiene configurado un carrito de compras ensu pagina web la venta funciona de la siguiente forma:

1. El cliente selecciona el producto

2. Selecciona la opcion pagar

3. Se habilita la opcion ”Pago Digital”

4. Confirmar compra

Para este tipo de compra no se realiza monitoreo debido a que es el clientequien realiza la compra desde la pagina web del comercio.

3.5.2. Proceso de venta telefonica

La venta telefonica la realizan los comercios(clientes) afiliados a PagoDigital a diferentes personas con tarjeta de credito o debito, el proceso paraesta 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 credito

4. Indica el numero de tarjeta y contrasena

5. El comercio ingresa la venta por el portal de Pago Digital

6. La venta es aprobada y descontado el dinero al tarjetahabiente

Este proceso de venta es el que se debe monitorear al instantepara evitar posibles fraudes.

3.6. PRODUCTOS Y SERVICIOS 35

3.6. Productos y Servicios

Pago digital ofrece diversos servicios de los cuales se mencionan los masgenerales:

3.6.1. Carrito Digital

Permite a los comercios que tengan un sitio web, agregar su carrito pararecibir pagos electronicos por medio de los distintos plugins que se manejancomo Prestashop, VirtueMart, Woocommerce, Magento y Opencart.

3.6.2. Integracion Digital

Permite a los comercios que tengan un sitio web integrar la pasarela depagos de una forma externa o interna segun su requerimiento.

3.6.3. Enlace Digital

Permite que un comercio envıe por medio de mail o redes sociales unenlace para que el cliente procese su pago electronico, es ideal para aquelloscomercios que aun no tienen un sitio web.

3.6.4. Boton Digital

Permite que un comercio por medio de la pasarela de pagos realice elproceso de una compra ingresando los datos de su cliente y a su vez puedaverificar el estado final en tiempo real, es ideal para comercios que manejenventas telefonicas.


3.7. Funciones

A continuacion se describen las funciones de la empresa de acuerdo a lasareas que la componen:

3.7.1. Gerencia

Se encarga de la toma de decisiones que la companıa enfrenta en su dıaa dıa.

3.7.2. Direccion Comercial

Vela por establecer un nivel de ventas acorde a la proyeccion de la em-presa. Esta area tiene la mision de mantener un tope de ventas diarias conincidencia incremental.

3.7.3. Direccion de Mercadeo y Publicidad

Esta area se encarga de ofrecer los productos mediante diferentes medios(web, impresos, terreno) los cuales estan enfocados al core del negocio elcual es el procesamiento de pagos con tarjeta credito o debito.

3.7.4. Area Contadurıa

Esta vertiente es la encargada de administrar el capital de la empresa yası mismo gestiona la contabilidad.

3.8. OBJETIVOS ORGANIZACIONALES 37

3.8. Objetivos Organizacionales

Se describen algunos de los objetivos de la organizacion.

3.8.1. Objetivo 1

Fortalecer y mejorar el trabajo en equipo mediante trabajo colaborativoy asi mantener un excelente clima laboral.

3.8.2. Objetivo 2

Realizar revisiones constantes a los sistemas con reuniones periodicaspara fortalecer los servicios y generar una alta disponibilidad en nuestrossistemas.

3.8.3. Objetivo 3

Garantizar que las ventas de los clientes cuenten con las mejores practicasde seguridad velando por la confidencialidad de la informacion.


Capıtulo 4

Archimate y ADM

4.1. Introduccion

Archimate es un lenguaje de modelado que se usa en la implementacionde arquitectura empresarial. El objetivo es apoyar la descripcion, analisis yvisualizacion de la arquitectura dentro y fuera de los dominios del negocioen una forma no ambigua.

ADM (Metodo de Desarrollo de Arquitectura) ,describe como obtener unaArquitectura Empresarial que sea especıfica para la organizacion y para res-ponder a los requerimientos del negocio. ADM es el componente principal delmarco TOGAF y proporciona direccion a los arquitectos en sus diferentesniveles.

39

40 CAPITULO 4. ARCHIMATE Y ADM

4.2. Archimate

El lenguaje de modelado Archimate permite representar la arquitecturaempresarial de una organizacion bajo tres diferentes perspectivas: negocio,sistemas y tecnologıa. El lenguaje Archimate sirve para disenar los diferentescatalogos que faciliten la adopcion de tecnologıa en las empresas, vinculandolos procesos de negocio con los activos tecnologicos.

El diseno de una arquitectura empresarial facilita la administracion de pro-yectos de tecnologıa y cambio organizacional, permitiendo que los expertosde negocio puedan priorizar los requerimientos de alto nivel y generar pro-yectos que impacten positivamente la organizacion. El lenguaje de modeladoArchimate define un conjunto de elementos estandard para el diseno de ar-quitecturas empresariales, al igual que los diferentes artefactos necesariospara tener un lenguaje comun entre expertos de negocio y de tecnologıa.

La herramienta permitira de manera intuitiva el desarrollo del catalogo deroles dentro del concepto de arquitectura empresarial y permite describir ca-da uno de los elementos necesarios para su correcta y acertada construccion.Tambien se incluye una explicacion de los catalogos la cual permite identi-ficar los requerimientos de negocio y de la perspectiva de implementacion,la cual permite representar cualquier diagrama necesario desde el marco dearquitectura empresarial Togaf.

4.2.1. Diseno de arquitectura

Integrada

El nucleo de ArchiMate es un lenguaje de diseno para describir la arqui-tectura de negocio y arquitecturas de TI en coherencia entre sı. Al margendel lenguaje de diseno, ArchiMate ofrece una amplia gama de tecnicas parala visualizacion, analisis, diseno y uso de la arquitectura empresarial con elfin de resolver los cambios necesarios del negocio. ArchiMate proporciona alarquitecto de la empresa instrumentos de arquitectura para apoyar y mejo-rar el proceso de cambio en los negocios. Estos instrumentos ayudan a losarquitectos en la comunicacion con todos los actores involucrados, que vandesde los gerentes hasta los desarrolladores de software.

ArchiMate evita la ambiguedad y la confusion, ofreciendo un lenguaje sen-cillo y uniforme para describir la arquitectura de la empresa. ArchiMatedistingue tres capas de modelaje:

4.2. ARCHIMATE 41

La capa de negocio: procesos de negocio, organizacion, funciones denegocios, productos y servicios de oficina

La capa de aplicacion: aplicaciones, servicios de aplicacion, las funcio-nes de aplicacion, interfaces de aplicaciones

La capa de tecnologıa: nodos, redes, servicios de infraestructura, soft-ware.


4.2.2. Tres Capas fundamentales

El nivel de procesos de negocio, servicios, funciones y eventos de lasunidades de negocio. Esta capa ofrece productos y servicios a clientesexternos.

La capa de aplicacion comprende aplicaciones de software que apoyanlos componentes del negocio – de la capa anterior – realizando serviciosde aplicacion.

La capa de tecnologıa comprende el hardware y la infraestructura decomunicacion para apoyar la capa de aplicacion. Esta capa ofrece servi-cios de infraestructura necesarios para ejecutar aplicaciones, realizadopor 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 metodos y herra-mientas para el desarrollo de una amplia gama de las diferentes arquitecturasde TI. que permite a los usuarios disenar, evaluar y construir una arquitec-tura correcta de su organizacion, y reduce los costes de planificacion, disenoy aplicacion de arquitecturas basadas en soluciones de sistemas abiertos.

La clave para TOGAF es el metodo de desarrollo de arquitectura (ADM) -un sistema fiable y un metodo probado para desarrollar una ArquitecturaEmpresarial que satisfaga las necesidades de su negocio.

ADM consiste en un metodo iterativo (cıclico de paso a paso) para el desa-rrollo de la arquitectura general de la empresa. El lenguaje ArchiMate, comose describio anteriormente complementa al esquema TOGAF proporcionan-do un conjunto de conceptos - independiente de actores comerciales comoproveedores - incluyendo una representacion grafica, que ayuda a crear unmodelo coherente e integrado, usando diferentes temas (views) con repre-sentacion grafica

4.2. ARCHIMATE 43

4.2.4. Correspondencia entre Archimate y TOGAF

Archimate esta relacionado con TOGAF, pero no es TOGAF aunque semezclan muy bien ambos. En la figura 3-8 es facil de identificar la corres-pondencia entre el ciclo ADM (izquierda) y TOGAF (derecha), debido aluso de colores:

La fase A, H junto con Requerimientos y Preliminar agrupadas decolor lila, representan lo motivacional y nos responde el porque vamosa hacer la arquitectura

Las fases B, C y D agrupadas cada una de tres colores que representanla informacion (Verde), el comportamiento (Amarillo) y la estructura(Azul), nos responde el que vamos a hacer.

Las fases E, F y G agrupadas de color rojo representan la migraciony nos responde el como vamos a hacer la arquitectura.

Figura 4.1: Modelo: Archimate


4.3. ADM

El marco de trabajo (framework) TOGAF consiste en un metodo deta-llado y un conjunto de herramientas que direccionan la arquitectura empre-sarial. Esta compuesto por cuatro partes principales:

el metodo de desarrollo de la arquitectura ADM (Architecture Develop-ment Method), la taxonomıa empresarial (Enterprise Continuum) y la basede recursos (Architecture Repository).

TOGAF aborda el desarrollo a partir de cuatro niveles de abstraccion: ar-quitectura de negocio, arquitectura de sistemas de informacion, arquitecturade datos y arquitectura tecnologica.

ADM refleja estos niveles de abstraccion en diferentes fases que determi-nan la lınea base (baseline o as-is) y final de un nivel de abstraccion (targeto to-be) junto con un analisis de brecha (gap analysis) que permite conocerel estado final de la arquitectura despues de una o varias iteraciones.

El metodo define ocho niveles A, B, C, D, E, F, G, H que van desde lavision de la arquitectura hasta la administracion del cambio, por ser unametodologıa iterativa permite completar, eliminar o crear nuevos items ensu recorrido mediante el analisis de brecha que se realiza al final de cadanivel.

El metodo permite transitar de una arquitectura inicial (baseline o as-is)hacia una arquitectura final objetivo (target o to-be) durante el procesoiterativo se realiza un analisis de brecha denominado GAP que mide losobjetivos de arquitectura y el grado de madurez alcanzados por la organi-zacion.

4.3. ADM 45

Modelo ADM Metodo de Desarrollo de Arquitectura:

Figura 4.2: Metodo: ADM

4.3.1. Fases

Fase Preliminar: En esta etapa se define el ambito de la organizacionafectado por la iniciativa de EA, ası como el equipo de EA y los prin-cipios de la arquitectura aplicables. Ademas, dado que TOGAF es unmarco estandar con el objetivo de adaptarse a cualquier organizacion ysector, deberıa ser adaptado a los requisitos especıficos de la empresa.Por ultimo, deben implementarse las herramientas necesarias para eldesarrollo de la arquitectura.


Fase A – Vision de Arquitectura: En esta fase, se establece el proyectode arquitectura junto con el alcance de la iniciativa de EA. Se debenidentificar las partes interesadas, sus inquietudes y requerimientos denegocio.

Fase B – Arquitectura de Negocios — Fase C – Arquitectura de Siste-mas de Informacion — Fase D – Arquitectura de Tecnologıa: En estastres fases, se desarrolla la lınea base de arquitectura (AS-IS Architec-ture) y la arquitectura final (es decir, la arquitectura objetivo de lainiciativa de EA, TO-BE Architecture)

Fase E – Oportunidades y Soluciones: En esta fase, se define la plani-ficacion inicial para la puesta en marcha de la arquitectura objetivo,se identifican y agrupan los principales paquetes de trabajo necesarios

Fase F – Planificacion de Migracion: En esta fase, los proyectos demigracion identificados en la etapa anterior son priorizados. Para ello,se debe realizar la evaluacion coste/beneficio, analisis de riesgo y laasignacion del valor

Fase G – Gobernanza de la Implementacion: En esta fase, se confirmay supervisa el alcance y las prioridades de los proyectos de implemen-tacion. Tambien, se realizan las revisiones de cumplimiento de EA

Fase H – Gestion de Cambios de Arquitectura: En esta fase, se revisaque la arquitectura resultante alcanza el valor para el negocio que sehabıa establecido como objetivo.

Gestion de Requerimientos: Se trata de una actividad paralela res-ponsable de la identificacion, seguimiento y documentacion de reque-rimientos, ademas de ser la encargada de informar a la fase apropiadaacerca de cualquier modificacion o alta de requerimientos a tener encuenta.

Capıtulo 5

Capa de Negocio

5.1. Introduccion

Es una de las capas mas importantes debido a que el lenguaje que se uti-liza, permite hablar en terminos de las entidades del negocio, por lo que esimportante distribuir adecuadamente la semantica. Esta capa gira en tornoa tres dimensiones de comportamiento: procesos, servicios y producto (cen-tro del negocio).

Las capas agregan conceptos que soportan las etapas del ADM de TOGAFen las fases B, C y D que se encuentran relacionadas con el negocio, aplica-cion o datos e infraestructura.

47

48 CAPITULO 5. CAPA DE NEGOCIO

5.2. Organizacion

5.2.1. Modelo

Figura 5.1: Metamodelo Organizacion: Pago Digital

5.2. ORGANIZACION 49

5.2.2. Caso de Estudio

El metamodelo de la organizacion describe los actores de la empresa, nose precisa como un organigrama aunque tenga similitud.

Los actores del modelo son los siguientes:

Pago Digital

Direccion de Negocios

Direccion de Mercadeo

Coordinacion de Desarrollo

Coordinacion de Monitoreo

Direccion Comercial

Area Contadurıa

La ubicacion de la empresa es en el barrio polo de la ciudad de Bogota


5.3. Cooperacion de Actor

5.3.1. Modelo

Hace referencia a las relaciones existentes entre los actores y los actorescon su entorno. Es importante este modelo debido a que evidencia como suscomponentes de aplicacion cooperan para realizar un proceso de negocio.

5.4. Organizacion

5.4.1. Modelo

Figura 5.2: Metamodelo Cooperacion de Actor: Pago Digital

5.4. ORGANIZACION 51


Se observa en este modelo a dos actores que forman una colaboracionllamada ”Pasarela de Pagos”luego se desprende un rol ”Puente virtual”queenlaza a los clientes y tarjetahabientes por medio de un portal web.

Pago digital cuenta con clientes y a su vez esos clientes tienen mas clientesdenominados tarjetahabientes.


5.5. Funcion de Negocio

5.5.1. Modelo

Este punto de vista muestra las principales funciones de negocio de unaorganizacion ası como su relacion en flujos de informacion la funcion denegocio provee una mirada de alto nivel en las operaciones generales de lacompanı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.

Figura 5.3: Metamodelo Funcion de Negocio: Pago Digital

5.5. FUNCION DE NEGOCIO 53


En este modelo se precisan dos roles fundamentales, el coordinador y elanalista; 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 funcion principal del analista es:

Monitorear llamadas de ventas no presenciales


5.6. Proceso de Negocio

5.6.1. Modelo

Este punto de vista es usado para mostrar la estructura de alto nivel ycomposicion de uno o mas procesos de negocio.

Figura 5.4: Metamodelo Proceso de Negocio: Venta telefonica a tarjetaha-biente

5.6. PROCESO DE NEGOCIO 55


En este modelo se muestra el proceso de una venta telefonica con tarjetade credito, el comercio afiliado a Pago Digital ingresa la venta, posterior aello se valida la venta por medio de la grabacion de la misma, si la ventacuenta con los niveles de seguridad exigidos por la empresa se aprueba laventa y se le notifica al comercio quien procedera a despachar el producto oservicio.


5.7. Cooperacion de Proceso de Negocio

5.7.1. Modelo

Este punto de vista es usado para mostrar las relaciones de uno o masprocesos de negocio entre si mismos y con su ambiente.

Figura 5.5: Metamodelo Cooperacion de Proceso de Negocio: Venta telefoni-ca a tarjetahabiente

5.7. COOPERACION DE PROCESO DE NEGOCIO 57


En este punto de vista se observa el flujo de una venta realizada por uncomercio de Pago Digital, el rol ”Portal Web”notifica un pago realizado, unsiguiente rol Comercio”le notifica al tarjetahabiente sobre la respuesta de laventa, puede ser negada o aprobada.


5.8. Producto

5.8.1. Modelo

Representa el valor que los productos ofrecen a los clientes o a otros entesexternos involucrados.

Tambien para mostrar las interfaces a traves de los cuales es ofrecido elproducto y los eventos asociados a el.

Figura 5.6: Metamodelo Cooperacion de Proceso de Negocio: Pago Digital

5.8. PRODUCTO 59


En este punto de vista se plantean los beneficios de trabajar con PagoDigital en cuanto a su procesamiento de ventas, algunos de sus servicios devalor son:

Pago agil y seguro

Sin costo de afiliacion

Pago seguro respaldado por la norma PCI

Aceptar pagos vıa telefonica o desde la pagina web


Capıtulo 6

Capa de Aplicacion

6.1. Introduccion

La capa de aplicacion soporta la capa de negocio con servicios de apli-cacion los cuales son realizados por aplicaciones de software.

61

62 CAPITULO 6. CAPA DE APLICACION

6.2. Comportamiento de Aplicacion

6.2.1. Modelo

El comportamiento de aplicacion describe el comportamiento interno deuna aplicacion,por ejemplo, el como realiza uno o mas servicios de aplicacionEste punto de vista es util en el diseno de los comportamientos principalesde las aplicaciones, o para identificar los cambios funcionales entre diferentesaplicaciones.

Figura 6.1: Metamodelo Comportamiento de Aplicacion: Pago Digital

6.2. COMPORTAMIENTO DE APLICACION 63


El modelo comportamiento de aplicacion describe el pago realizado pordiferentes medios, allı encontramos diferentes componentes con funcionesespecificas, los procesos que se desprenden de estos componentes son:

Procesar Pagos (Componente Credibanco)

Ventas vıa telefonica con tarjeta de credito (Componente Pago)

Realizar pagos con carrito de compras(Componente Pago)

Ingresar ventas no presenciales(Componentes - Pasarela - Ventas)


6.3. Cooperacion de Aplicacion

6.3.1. Modelo

Este punto de vista describe las relaciones entre componentes de apli-caciones en terminos de los flujos de informacion entre ellas, o en terminosde los servicios que ellas ofrecen o utilizan. Este punto de vista es usadotıpicamente para crear una vision general del panorama de aplicaciones deuna organizacion

Tambien es usado para expresar la cooperacion interna o la orquestacionde servicios que en conjunto soportan la ejecucion de un proceso de negocio.

Figura 6.2: Metamodelo Cooperacion de Aplicacion: Pago Digital

6.3. COOPERACION DE APLICACION 65


Este modelo muestra dos partes fundamentales que son el frontend y elbackend de los componentes involucrados. Por el lado del frontend tenemos2 componentes:

Portal Web

Pagina Web

Por el lado del backend tenemos 4 componentes:

Callcenter

Comercio

Credibanco

Tarjetahabiente


6.4. Estructura de Aplicacion

6.4.1. Modelo

El punto de vista de estructura de aplicacion muestra la estructura deuna o mas aplicaciones o componentes. Este punto de vista es utilizado en eldiseno o entendimiento de la estructura principal de aplicaciones o compo-nentes y los datos asociados, por ejemplo, para descomponer la estructuradel sistema que esta en construccion.

Figura 6.3: Metamodelo Estructura de Aplicacion: Pago Digital

6.4. ESTRUCTURA DE APLICACION 67


Para el presente modelo se elaboran 5 componentes con sus respectivasinterfaces, el componente central es la pasarela de pagos la cual tiene lassiguientes interfaces:

Comunicacion

Recaudo

Seguridad

Conexion


6.5. Uso de Aplicacion

6.5.1. Modelo

Este punto describe como son usadas las aplicaciones para soportar unoo mas procesos de negocio, y como estas son usadas por otras aplicaciones.Puede ser utilizado en el diseno de una aplicacion identificando los serviciosnecesitados por procesos de negocio y otras aplicaciones.

Figura 6.4: Metamodelo Uso de Aplicacion: Pago Digital

6.5. USO DE APLICACION 69


Para el presente modelo intervienen los siguientes elementos en el procesode venta:

Ventas

Monitoreo

Hacer pagos con tarjeta

Pagos


Capıtulo 7

Capa de Tecnologıa

7.1. Introduccion

La capa de tecnologıa ofrece servicios de infraestructura, por ejemploservicios de almacenamiento y comunicacion necesarios para ejecutar apli-caciones. Esta capa muestra la conexion entre el hardware y los sistemas desoftware.

71

72 CAPITULO 7. CAPA DE TECNOLOGIA

7.2. Infraestructura

7.2.1. Modelo

El presente punto de vista contiene los elementos de infraestructura desoftware y de hardware que soportan la capa de aplicacion, tales como dispo-sitivos fısicos, redes o sistemas de software por ejemplo (sistemas operativos,bases de datos, red, servidores)

Figura 7.1: Metamodelo Infraestructura: Pago Digital

7.2. INFRAESTRUCTURA 73


El metamodelo de Infraestructura muestra la estructura de Pago Digitalla cual soporta la capa de aplicacion, podemos observar algunos componen-tes de software y hardware. El diagrama inicia con 2 nodos principales queson ”Banco y Credibanco.a estos nodos se conecta la aplicacion web de laempresa ”Portal PD”. Este portal se encuentra en un hosting con el servidorweb y el servidor de base de datos.

El portal se encuentra desarrollado en PHP y opera bajo un servidor linuxCentos. Al portal se conectan el comercio quien es el cliente de la empresay el callcenter el cual monitorea las ventas que realiza en comercio.


7.3. Uso Infraestructura

7.3.1. Modelo

En el punto de vista uso de infraestructura muestra como las aplicacionesson soportadas por la infraestructura de software y hardware. Este punto devista juega un papel importante en el analisis de rendimiento y escalabilidadya que relaciona la infraestructura con las aplicaciones

Figura 7.2: Metamodelo Uso de Infraestructura: Pago Digital

7.3. USO INFRAESTRUCTURA 75


El metamodelo de uso de infraestructura describe como los componentesde la capa de aplicacion son soportados por la capa de tecnologıa Observamosque el portal de la empresa (Portal PD) se conecta por medio de un webservice a Credibanco; el portal cuenta con un componente de pago y quese compone de una pasarela de pagos. Los componentes que implementa lapasarela son (Plugin de Pago) y (Carrito de Compras). El nodo pagina websirve para que los comercios (clientes) y el callcenter de la empresa accedanal sitio web.


7.4. Implementacion y Despliegue

7.4.1. Modelo

Este punto de vista muestra como una o mas aplicaciones son llevadasa la realidad en la capa de infraestructura. Esto implica el mapeo de apli-caciones y componentes logicos en artefactos fısicos como por ejemplo JavaNetBeams.

Figura 7.3: Metamodelo Implementacion y Despliegue: Pago Digital

7.4. IMPLEMENTACION Y DESPLIEGUE 77


En este modelo podemos observar una colaboracion entre los compo-nentes (Portal PD y Credibanco) esta colaboracion forma un webservicebidireccional, esto es debido a que los 2 pueden enviar y recibir peticiones,este sistema permite que el acceso a los datos sea por autorizacion en cadauno de los nodos. El unico componente que accede al sistema bancario es(Credibanco) quien envıa la peticion al banco y retornara la respuesta unaves la haya obtenido a Pago Digital por medio del servicio web.


7.5. Estructura de Informacion

7.5.1. Modelo

El presente punto de vista es comparable al modelo tradicional de infor-macion creado en el desarrollo de cualquier sistema de informacion Muestrala estructura usada en la empresa o en un proceso de negocio o aplicacionespecifica, en terminos de tipos de datos o estructuras de clases orientadasa objetos, inclusive, este punto de vista puede mostrar como la informaciona nivel de negocio es representada en el nivel de aplicacion.

Figura 7.4: Metamodelo Estructura de informacion: Pago Digital

7.5. ESTRUCTURA DE INFORMACION 79


Para este modelo observamos el objeto de negocio (Ventas con tarjetade credito) este objeto se representa con la (Factura) que se genera por cadaventa la cual la realiza el comercio afiliado a pago digital y el usuario ocomprador final es el tarjetahabiente.


7.6. Realizacion del Servicio

7.6.1. Modelo

Este punto de vista es usado para mostrar como uno o mas servicios denegocio son llevados a la realidad por los procesos subyacentes y en algunasocasiones por los componentes de aplicacion De esta manera conforma elpuente entre el punto de vista de productos de negocio y la vista de procesosde negocio. Esto provee una (vista desde afuera) en uno o mas procesos denegocio.

Figura 7.5: Metamodelo Realizacion del servicio: Pago Digital

7.6. REALIZACION DEL SERVICIO 81


Con este punto de vista se expresa la relacion entre el servicio de ne-gocio (Controlar o monitorear ventas) modelado con los objetos de negocioy los objetos de aplicacion. Observamos algunos roles involucrados como elcomercio y el tarjetahabiente.


7.7. Capas

7.7.1. Modelo

Este punto de vista esquematiza multiples capas y aspectos de una ar-quitectura empresarial en un diagrama. Las capas son el resultado de usarrelaciones de agrupamiento para un particionamiento natural del conjuntocompleto de objetos y relaciones que pertenecen a un modelo.

Figura 7.6: Metamodelo Capas: Pago Digital (Ventas con tarjeta de credito)

7.7. CAPAS 83


Este punto de vista muestra el flujo de proceso de negocio en base a suobjeto(Ventas con tarjeta de credito). Se puede observar la conexion entrelas capas (Negocio — Aplicacion — Tecnologıa). Cada una de ellas juega unpapel importante para culminar el proceso de manera exitosa. El procesofinaliza con la respuesta de la capa de tecnologıa a traves del servicio web.


Capıtulo 8

Capa de Motivacion

8.1. Introduccion

la capa motivacional anade 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 loselementos motivacionales.

85

86 CAPITULO 8. CAPA DE MOTIVACION

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 terminos de fortalezas,debilidades, oportunidades y amenazas. Tambien pueden ser descritos losenlaces a los objetivos iniciales de alto nivel que direccionan estos asuntosy valoraciones. Estos objetivos conforman las bases para el proceso de inge-nierıa de requerimientos, incluyendo el refinamiento de objetivos y analisisde contribuciones y conflictos.

Figura 8.1: Metamodelo Stakeholder: Pago Digital (Partes interesadas)

8.2. STAKEHOLDER 87


En este punto de vista se identifican tres stakeholder:

Analista de monitoreo

Comercio

Tarjetahabiente

Cada stakeholder cuenta con un objetivo (goal) y una evaluacion. El pro-ceso se realiza sobre ventas telefonicas a poseedores de tarjetas de credito(tarjetahabiente) por parte del comercio (Cliente Pago Digital)


8.3. Realizacion de Objetivos

8.3.1. Modelo

Este punto de vista permite al disenador modelar el refinamiento deobjetivos de alto nivel en objetivos mas concretos y el refinamiento de di-chos objetivos concretos en requerimientos o restricciones que describen laspropiedades que son necesarias para realizar los objetivos.

Figura 8.2: Metamodelo Realizacion de Objetivos: Pago Digital (ObjetivosPartes interesadas)

8.3. REALIZACION DE OBJETIVOS 89


En este modelo podemos observar los requerimientos y restricciones quetiene cada objetivo de las partes interesadas, con este descubrimiento sepuede pensar a grandes rasgos las restricciones del sistema al momento desu implementacion para este proceso de negocio de la organizacion.


8.4. Contribucion de Objetivos

8.4.1. Modelo

El presente punto de vista permite modelar las relaciones influyentesentre objetivos y requerimientos. Las vistas resultantes pueden ser usadaspara analizar el impacto que tienen los objetivos.

Figura 8.3: Metamodelo Contribucion de Objetivos: Pago Digital

8.4. CONTRIBUCION DE OBJETIVOS 91


Se observa en este punto de vista como se generan nuevos objetivos apartir de los requerimientos, se toman dos requerimientos de los cuales semuestran sus objetivos positivos y negativos. Se pueden crear objetivos ne-gativos ya que se pueden cruzar los requerimientos con los objetivos.

El mejor ejemplo es observar como el requerimiento (El cliente debe po-seer una tarjeta de credito) se cruza con el objetivo (Lograr vender productosa la mayor cantidad de personas posible) puesto que si el requerimiento esque el cliente debe tener tarjeta de credito, aquellas personas que no la po-seen se quedarıan por fuera de este objetivo, es por ello que se consideranegativo.


8.5. Principios

8.5.1. Modelo

El punto de vista de principios permite al disenador modelar los prin-cipios que son relevantes al problema de diseno que se esta resolviendo,incluyendo los objetivos que motivaron dichos principios. En pocas palabraslos principios son valores corporativos de la organizacion en base al objetivoplanteado.

Figura 8.4: Metamodelo Principios: Pago Digital (Valores Corporativos)

8.5. PRINCIPIOS 93


Se observa en este punto de vista los principios que surgen de cada uno delos objetivos, los principios se pueden tomar como los valores corporativosque se ofrecen por cada objetivo. Con cada principio se brinda valor alservicio ofrecido por la organizacion.


8.6. Realizacion de Requerimientos

8.6.1. Modelo

Este punto de vista permite modelar la realizacion de requerimientos porelementos fundamentales como actores, servicios o procesos de negocio. Ensıntesis este punto de vista puede ser usado para refinar requerimientos enrequerimientos mas detallados.

Figura 8.5: Metamodelo Realizacion de Requerimientos: Pago Digital

8.6. REALIZACION DE REQUERIMIENTOS 95


Para este punto de vista se observa como de un requerimiento se despren-de un nuevo objetivo y de este objetivo nuevos requerimientos y restricciones,esto se realiza para llegar a un nivel de detalle el cual permitira abordar me-jor el objeto de negocio y garantizar que se cubran todos los puntos de vistadel objetivo principal.


8.7. Motivacion

8.7.1. Modelo

El punto de vista permite modelar aspectos generales como una vistacompleta de los aspectos motivacionales relacionando a las partes interesa-das, sus objetos primarios, los principios que aplican y los requerimientosprincipales en servicios, procesos, aplicaciones y objetos.

Figura 8.6: Metamodelo Motivacion: Pago Digital(Monitorear ventas entiempo real )

8.7. MOTIVACION 97


Para el ultimo modelo de la capa de motivacion observamos un com-plemento de stakeholders, motivadores, valores, restricciones, objetivo y re-querimientos. Todos ellos unidos de manera logica en base a un objetivoprincipal el cual se basa en el monitoreo de ventas en tiempo real, este es elobjetivo del negocio en el cual se basara la aplicacion web.


Capıtulo 9

Capa de Proyecto

9.1. Introduccion

La capa de proyecto incluye conceptos para modelar la implementacionde programas y los proyectos que soportan dicho programa, portafolio, ges-tion de proyectos y el concepto de platea para soportar la planeacion demigraciones.

99

100 CAPITULO 9. CAPA DE PROYECTO

9.2. Proyecto

9.2.1. Modelo

El punto de vista de proyecto es usado principalmente para modelar lagestion del cambio de arquitectura. La Arquitectura del proceso de migracionde una vieja situacion (estado actual de la arquitectura empresarial) a unanueva y deseada situacion tiene consecuencias significativas en el mediano ylargo plazo de la estrategia de crecimiento puesto que realizar la Arquitec-tura empresarial para toda una organizacion es un proceso que puede tardaranos y es necesario el entero compromiso de todas las partes interesadas.

No obstante realizar la arquitectura permitira unir esfuerzos y mejorarcada uno de los procesos de la organizacion.

Figura 9.1: Metamodelo Proyecto: Pago Digital

9.2. PROYECTO 101


El presente modelo muestra una vista general el objetivo del proyecto, elcual es construir una aplicacion web para monitorear o controlar las ventasno presenciales de los comercios afiliados a la empresa. Los roles principalesson el comercio y el analista de monitoreo.


9.3. Migracion

9.3.1. Modelo

El punto de vista de migracion implica modelos y conceptos que puedenser usados para especificar la transicion de una arquitectura existente a unaarquitectura deseada. Los conceptos principales modelados son las plateas(hitos del proyecto) y las brechas (dificultades que deben ser superadas).

Figura 9.2: Metamodelo Migracion: Pago Digital

9.3. MIGRACION 103


En este punto de vista observamos el estado actual de la organizacion anivel de plataforma web y el esquema de brecha para la transicion entre elestado actual y el estado final que es el (Portal PD)


9.4. Implementacion y Migracion

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 vistapermite modelar el alcance de programas, proyectos, actividades de proyec-tos en terminos de las plateas que son realizadas o los elementos individualesde arquitectura que son afectados.

Figura 9.3: Metamodelo Implementacion y Migracion: Pago Digital

9.4. IMPLEMENTACION Y MIGRACION 105


Para este ultimo modelo observamos un diagrama completo entre ob-jetivo organizacional, entregable y analisis de brecha segun los hitos de laimplementacion del portal web. Esta vista es un diagrama general de laaplicacion la cual muestra el estado actual y el estado final.


Parte III

Diseno

107

Capıtulo 10

GoF −Gang of Four−

10.1. Introduccion

El concepto de patrones de diseno fue el resultado de un trabajo rea-lizado por un grupo de 4 personas (Erich Gamma, Richard Helm, RalphJohnson y John Vlissides, conocidos como ”la pandilla de los cuatro - Gangof four”) que se publico en 1995 en un libro titulado ”Patrones de diseno:Elementos de software orientado a objetos reutilizables.en el que se esboza-ban 23 patrones de diseno.

La palabra patron fue definido por Cristopher Alexander como la apari-cion repetida de un problema y por supuesto el eje central de la solucion adicho problema, de forma que esta pueda ser utilizada un millon de vecessin la necesidad de hacer todo desde ceros. Esta definicion que fue utilizadapara referirse a problemas de construccion de edificaciones, es perfectamentetrasladable al contexto de construccion de software.

Un patron consta de 4 elementos principales;

NOMBRE DEL PATRON: Este nombre se compone de una odos palabras con las cuales nos referimos al problema de diseno, a susolucion y probablemente a las consecuencias de su aplicacion.

PROBLEMA: El problema describe cuando debe ser utilizado elpatron, incluyendo de ser necesario el contexto de dicho problema ylas condiciones presentes para considerar el uso del patron.

SOLUCION: La solucion describe los elementos de diseno necesarios

109

110 CAPITULO 10. GOF −GANG OF FOUR−

para resolver el problema, estructuras, colaboraciones, responsabilida-des.

CONSECUENCIAS: Los resultados de aplicar el patron y el im-pacto que este puede tener en nuestro sistema de software.

10.2. CREACIONAL 111

10.2. Creacional

Los patrones de diseno creacionales, abstraen el proceso de instanciacionde objetos. Ayudan a que un sistema sea independiente de como sus objetosson creados, compuestos y representados.

Los patrones creacionales se hacen mas importantes a medida que los siste-mas evolucionan para depender mas de la composicion de objetos que de laherencia de clases. Al suceder esto, el enfasis cambia de codificar un conjun-to fijo de comportamientos hacia la definicion 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, todosbuscan encapsular el conocimiento de que clase concreta utiliza el sistema.El segundo, todos ocultan como las instancias de dichas clases son creadasy puestas en conjunto.

Patron Descripcion

FabricaAbstracta

Provee una interface para crear familias de objetos relacio-nados o dependientes sin especificar sus clases concretas.

Constructor Separa la construccion de un objeto complejo de su repre-sentacion, de forma que el mismo proceso de construccionpueda crear diferentes representaciones.

Metodo Fa-brica

Define una interface para crear un objeto, pero deja que lassubclases 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 unpunto global de acceso a ella.

Cuadro 10.1: Catalogo de patrones creacionales.


10.2.1. Singleton

Modelo

Patron de diseno disenado para restringir la creacion de objetos perte-necientes a una clase o el valor de un tipo a un unico objeto. Su intencionconsiste en garantizar que una clase solo tenga una instancia y proporcionarun punto de acceso global a ella.

El patron singleton se implementa creando en nuestra clase un metodo quecrea una instancia del objeto solo si todavıa no existe alguna. Para asegurarque la clase no puede ser instanciada nuevamente se regula el alcance delconstructor (con modificadores de acceso como protegido o privado).

Figura 10.1: Estructura: Patron Metodo Singleton


Caso de Estudio

El modelo del patron Singleton muestra como una clase solamente esposible instanciarla una vez, esto asegura que si el sistema detecta una ins-tancia previa no le permitira realizarlo una vez mas, obligando al proceso autilizar la instancia previa creada.


10.2.2. Fabrica Abstracta

Modelo

El patron de diseno Fabrica Abstracta se utiliza para proporcionar unainterfaz comun para crear una serie de objetos (productos) bajo una u otraarquitectura o framework, sin que los clientes de dichos productos tenganque tener conocimiento de la arquitectura elegida para implementar cadafamilia de productos.

Figura 10.2: Estructura: Patron Metodo Fabrica Abstracta


Caso de Estudio

Observamos en este patron como se crea una arquitectura comun paradiferentes productos, lo ideal de este patron es acoplarse a las propiedadesdel primer producto para posterior a ello tomar su logica correspondiente.

Si se aplica este metodo los productos deben ser iguales en su estructurapero es posible que su funcionamiento sea diferente dependiendo la logicadel negocio.


10.2.3. Metodo Fabrica

Modelo

Define una interface para crear un objeto, pero deja que sean las subcla-ses decidir cual clase debe ser instanciada. El metodo fabrica permite queuna clase delegue la instanciacion de las subclases.

Este patron 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 ladelegada.

Figura 10.3: Estructura: Patron Metodo Fabrica


Caso de Estudio

Observamos en la figura 10.3 un ejemplo de como seria la estructuradel metodo Fabrica el cual cuenta con una clase principal y 2 subclases queheredan de la clase primaria, segun la logica del negocio accedera a una delas sub clases y posterior a la clase principal.


10.2.4. Constructor

Modelo

El proposito de este patron es separar la construccion de un objeto com-pleto de su representacion, de forma que el mismo proceso de construccionpermita crear diferentes representaciones.

Este patron debe usarse cuando:

El algoritmo para crear un objeto complejo puede ser independiente delas partes que componen el objeto y de como estas son ensambladas.

El proceso de construccion tiene que permitir diferentes representacio-nes para el objeto que es construido.

Figura 10.4: Estructura: Patron Metodo Constructor


Caso de Estudio

Se observa en este patron como 2 clases se construyen a partir de unasubclase Builder, esto le permite a la subclase construir un nuevo objeto sinintervenir la clase principal.


10.2.5. Prototipo

Modelo

El patron de diseno prototipo (Prototype), tiene como finalidad crearnuevos objetos duplicandolos, clonando una instancia creada previamente.

Este patron especifica la clase de objetos a crear mediante la clonacion deun prototipo que es una instancia ya creada. La clase de los objetos que ser-viran de prototipo debera incluir en su interfaz la manera de solicitar unacopia, que sera desarrollada luego por las clases concretas de prototipos.

Figura 10.5: Estructura: Patron Metodo Prototipo


Caso de Estudio

Este modelo permite la clonacion de clases y adoptarlas para su beneficiosegun su proceso. Como se muestra en la figura una clase instancia otra paraque posteriores subclases puedan adoptar sus funciones y metodos


10.3. Estructural

Los patrones estructurales se ocupan de como las clases y los objetos soncompuestos 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 objetodescriben formas de componer objetos para realizar una nueva funcionali-dad.

La flexibilidad anadida de la composicion de objetos viene de la habilidadpara cambiar la composicion en tiempo de ejecucion, lo cual es imposiblecon composicion estatica de clases.

Patron Descripcion

Adaptador Convierte la interfaz de una clase en otra que el cliente es-pera. Permite que dos clases con interfaces incompatiblespuedan trabajar juntas.

Puente Desacopla una abstraccion de su implementacion de formaque las dos puedan variar independientemente.

Compuesto Compone objetos en estructuras de arbol que representanjerarquıas parte-todo.

Decorador Agrega responsabilidades adicionales a un objeto dinamica-mente. los decoradores proveen una alternativa flexible a laherencia para extender funcionalidades.

Fachada Provee una interface unificada a un conjunto de interfacesen un subsistema. La fachada define una interface de altonivel que hace al subsistema mas facil de usar.

Peso Ligero Usa objetos compartidos para soportar un largo numero deobjetos granulares de forma mas eficiente.

Apoderado Provee un sucesor o reemplazante para otro objeto de formaque se pueda controlar el acceso a este.

Cuadro 10.2: Catalogo de patrones estructurales.

10.3. ESTRUCTURAL 123

10.3.1. Adaptador

Modelo

El patron Adapter (Adaptador) se utiliza para transformar una interfazen otra, de tal modo que una clase que no pudiera utilizar la primera, hagauso de ella a traves de la segunda.

El proposito de este patron es convertir la interfaz de una clase en otrainterfaz 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.

Figura 10.6: Estructura: Patron Metodo Adaptador


Caso de Estudio

Observamos en la figura los siguientes participantes y su funcion:

Target: define la interfaz especıfica del dominio que Client usa.

Client: colabora con la conformacion de objetos para la interfaz Target.

Adaptee: define una interfaz existente que necesita adaptarse.

Adapter adapta la interfaz de Adapter a la interfaz Target.


10.3.2. Puente

Modelo

El patron Bridge, tambien conocido como Handle/Body, es una tecnicausada en programacion para desacoplar una abstraccion de su implementa-cion, de manera que ambas puedan ser modificadas independientemente sinnecesidad de alterar por ello la otra. Esto es, se desacopla una abstraccionde su implementacion para que puedan variar independientemente.

Figura 10.7: Estructura: Patron Metodo Puente


Caso de Estudio

Observamos en la figura los siguientes participantes y su funcion:

Abstraction: define una interface abstracta. Mantiene una referencia aun objeto de tipo Implementor.

RefinedAbstraction: extiende la interface definida por Abstraction.

Implementor define la interface para la implementacion de clases. Estainterface no se tiene que corresponder exactamente con la interface deAbstraction; de hecho, las dos interfaces pueden ser bastante diferente.

ConcreteImplementor implementa la interface de Implementor y definesu implementacion concreta.


10.3.3. Componente

Modelo

Este patron sirve para construir objetos complejos a partir de otros massimples y similares entre sı, gracias a la composicion recursiva y a una es-tructura en forma de arbol.

Esto simplifica el tratamiento de los objetos creados, ya que al poseer todosellos una interfaz comun, se tratan todos de la misma manera. Dependiendode la implementacion, pueden aplicarse procedimientos al total o una delas partes de la estructura compuesta como si de un nodo final se tratara,aunque dicha parte este compuesta a su vez de muchas otras. Un claro ejem-plo de uso extendido de este patron se da en los entornos de programacion2D para aplicaciones graficas. Un videojuego puede contener diferentes ca-pas ”layers”de sprites (como una capa de enemigos) pudiendose invocar unmetodo que actue sobre toda esta capa de sprites a la vez (por ejemplo, paraocultarlos, darles un filtro de color etc.).

Figura 10.8: Estructura: Patron Metodo Componente


Caso de Estudio

Se observa con este patron como se pueden crear estructuras en arbolya que es posible construir nuevos objetos incluso mas complejos que losprimarios, es fundamental que la clase primaria cumpla con las propiedadesnecesarias para crear nuevas subclases a partir de ella.

En la imagen se muestran 3 sublclases que heredan de la clase Grafico yrealizan la funcion Pintar, ası mismo se observa una nueva clase que puedepintar por ejemplo las 3 imagenes es por ende que esta ultima seria una clasemas compleja que las 3 mencionadas anteriormente.


10.3.4. Decorador

Modelo

El patron Decorador responde a la necesidad de anadir dinamicamentefuncionalidad a un Objeto. Esto nos permite no tener que crear sucesivasclases que hereden de la primera incorporando la nueva funcionalidad, sinootras que la implementan y se asocian a la primera.

Figura 10.9: Estructura: Patron Metodo Decorador


Caso de Estudio

En la figura ser observa los siguientes componentes con su funcion:

Decorador: Mantiene una referencia al componente asociado. Imple-menta la interfaz de la superclase Componente delegando en el com-ponente asociado.

Decorador Concreto: Anade responsabilidades al componente.


10.3.5. Fachada

Modelo

Fachada es un tipo de patron de diseno estructural. Viene motivado porla necesidad de estructurar un entorno de programacion y reducir su com-plejidad con la division en subsistemas, minimizando las comunicaciones ydependencias entre estos.

es un tipo de patron de diseno estructural. Viene motivado por la necesidadde estructurar un entorno de programacion y reducir su complejidad conla division en subsistemas, minimizando las comunicaciones y dependenciasentre estos.

Figura 10.10: Estructura: Patron Metodo Fachada


Caso de Estudio

Este patron se basa en la simplicidad de sus componentes, lo que buscaes segmentar sus partes en susbsistemas para que la complejidad no sea altay al momento de realizar una mejora o una nueva funcionalidad sea muchomas facil realizarlo.


10.3.6. Peso Ligero

Modelo

El patron Flyweight (u objeto ligero) sirve para eliminar o reducir la re-dundancia cuando tenemos gran cantidad de objetos que contienen informa-cion identica, ademas de lograr un equilibrio entre flexibilidad y rendimiento(uso de recursos).

Figura 10.11: Estructura: Patron Metodo Peso Ligero


Caso de Estudio

Se muestra en la figura la forma como se optimizan las clases para me-jorar el rendimiento del sistema, es posible agrupar los componentes paraevitar la redundancia y optimizar los recursos.


10.3.7. Proxy

Modelo

El patron Proxy es un patron estructural que tiene como proposito pro-porcionar un subrogado o intermediario de un objeto para controlar su ac-ceso.El patron proxy se usa cuando se necesita una referencia a un objetomas flexible o sofisticada que un puntero. Dependiendo de la funcion quese desea realizar con dicha referencia podemos distinguir diferentes tipos deproxies:

proxy remoto: representante local de un objeto remoto.

proxy virtual: crea objetos costosos bajo demanda (como la clase Ima-genProxy en el ejemplo de motivacion).

proxy de proteccion: controla el acceso al objeto original.

proxy de referencia inteligente: sustituto de un puntero que lleva acabo operaciones adicionales cuando se accede a un objeto.

Figura 10.12: Estructura: Patron Metodo Proxy


Caso de Estudio

En este patron se identifica como se puede crear una restriccion entrecomponentes, esto se realiza por seguridad o po flexibilidad, ya que muchasveces es necesario acceder a una clase pero solo a algunos atributos, con unpatron proxy es posible crear el intermediario y facilitar estos datos, con elloel sistema sera mucho mas flexible como lo muestra la figura 10.12.

10.4. COMPORTAMIENTO 137

10.4. Comportamiento

Los patrones de comportamiento se ocupan de los algoritmos y de la asig-nacion de responsabilidades entre los objetos. Estos patrones no solamentedescriben patrones de clases u objetos sino tambien patrones de comunica-cion entre ellos. Estos patrones caracterizan flujos de control complejos queson difıciles de trazar en tiempo de ejecucion

Estos cambian el foco lejos del flujo de control para centrar el foco de aten-cion en la forma en que los objetos estan interconectados.


Patron Descripcion

Cadena deresponsabi-lidad

Evita acoplar al emisor de una peticion con su receptor dan-do a mas de un objeto la posibilidad de manejar la peticion

Comando Encapsula una peticion como un objeto permitiendo que losclientes puedan ser parametrizados con diferentes peticiones,guardarlas o trazarlas.

Iterador Provee una forma de acceder secuencialmente a los elementosde un objeto coleccion sin exponer su representacion interna.

Interprete Dado un lenguaje, define una representacion de su gramaticay un interprete que usa dicha representacion para interpretarsentencias 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 lasinteracciones de forma independiente.

Recuerdo Sin violar la encapsulacion, captura y externaliza el estadointerno de un objeto de forma que pueda ser restaurado unestado anterior posteriormente.

Observador Define dependencias uno a muchos entre objetos, de formaque cuando un objeto cambie su estado todos los dependien-tes sean notificados y actualizados automaticamente

Estado Permite que un objeto cambie su comportamiento cuando suestado interno cambie. El objeto aparenta cambiar su clase.

Estrategia Define una familia de algoritmos, encapsula cada uno y losvuelve intercambiables Permite que el algoritmo varıe inde-pendientemente de los clientes que lo usan.

MetodoPlantilla

Define el esqueleto de un algoritmo en una operacion, de-legando algunos pasos a subclases. Permite que se puedanredefinir ciertos pasos del algoritmo sin cambiar la estructu-ra del mismo.

Visitante Representa una operacion para que sea realizada en los ob-jetos estructura del objeto. Permite definir una nueva ope-racion sin cambiar las clases o elementos en los cuales opera.

Cuadro 10.3: Catalogo de patrones de comportamiento.


10.4.1. Cadena de Responsabilidades

Modelo

El patron de diseno cadena de responsabilidad es un patron de compor-tamiento que evita acoplar el emisor de una peticion a su receptor dandoa mas de un objeto la posibilidad de responder a una peticion. Para ello,se encadenan los receptores y pasa la peticion a traves de la cadena hastaque es procesada por algun objeto. Este patron es utilizado a menudo en elcontexto de las interfaces graficas de usuario donde un objeto puede estarcompuesto de varios objetos (que generalmente heredan de una super clase”vista”).

Figura 10.13: Estructura: Patron Metodo Cadena de Responsabilidad


Caso de Estudio

Observamos en este patron la forma de como una peticion puede ser aten-dida por diferentes subclases, esto permite que las solicitudes sean atendidasen el menor tiempo posible haciendo de la aplicacion sea mas agil Este patrones ideal para evitar que las peticiones tengan que llegar a la clase principaldando potestad a demas clases para que adopten el comportamiento nece-sario para procesar las solicitudes.


10.4.2. Comando

Modelo

Este patron permite solicitar una operacion a un objeto sin conocer real-mente el contenido de esta operacion, ni el receptor real de la misma. Paraello se encapsula la peticion como un objeto, con lo que ademas facilita laparametrizacion de los metodos.

Proposito

Encapsula un mensaje como un objeto, con lo que permite gestionarcolas o registro de mensaje y deshacer operaciones.

Soportar restaurar el estado a partir de un momento dado.

Ofrecer una interfaz comun que permita invocar las acciones de for-ma uniforme y extender el sistema con nuevas acciones de forma massencilla.

Figura 10.14: Estructura: Patron Metodo Comando


Caso de Estudio

Este patron se basa en el procesamiento de solicitudes en grupos, lo quepermite realizar operaciones en masa ya que encapsula el mensaje como unobjeto y le da el tratamiento correspondiente segun su orden de llegada, sepuede decir que es un patron ciego ya que no se conoce desde un inicio supeticion, esta se descubrira al momento de procesar el mensaje.


10.4.3. Iterador

Modelo

En diseno de software, el patron de diseno Iterador, define una interfazque declara los metodos necesarios para acceder secuencialmente a un grupode objetos de una coleccion. Algunos de los metodos que podemos definir enla interfaz Iterador son:

Primero()

Siguiente()

HayMas()

ElementoActual()

Este patron de diseno permite recorrer una estructura de datos sin que seanecesario conocer la estructura interna de la misma.

Figura 10.15: Estructura: Patron Metodo Iterador


Caso de Estudio

El patron iterator permite el acceso al contenido de una estructura sinexponer su representacion interna. Ademas diferentes iteradores pueden pre-sentar diferentes tipos de recorrido sobre la estructura (recorrido de principioa fin, recorrido con saltos...). Por otro lado los iteradores no tienen por quelimitarse a recorrer la estructura, sino que podrıan incorporar otro tipo delogica (por ejemplo, filtrado de elementos). Es mas, dados diferentes tiposde estructuras, el patron iterador permite recorrerlas todas utilizando unainterfaz comun uniforme.


10.4.4. Interprete

Modelo

El interprete es un patron de diseno que, dado un lenguaje, define unarepresentacion para su gramatica junto con un interprete del lenguaje.Se usapara definir un lenguaje para representar expresiones regulares que repre-senten cadenas a buscar dentro de otras cadenas. Ademas, en general, paradefinir un lenguaje que permita representar las distintas instancias de unafamilia de problemas.

Figura 10.16: Estructura: Patron Metodo Interprete


Caso de Estudio

La solucion es representar la gramatica 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 nodosno terminales con NonterminalExpression. Ambas clases implementan unainterfaz comun (o heredan de una clase abstracta comun) llamada Abstrac-tExpression y que contendra la declaracion del metodo interpret(), que seencargara de evaluar el nodo en concreto.

Ademas puede existir un contexto comun a todas las expresiones que definaciertos valores, funciones o caracterısticas del lenguaje que estamos inter-pretando. Este contexto sera representado con la clase Context. El clientese encargara de construir el arbol sintactico de la expresion y asignar elcontexto en caso de haberlo.


10.4.5. Mediador

Modelo

El patron mediador define un objeto que encapsula como un conjunto deobjetos interactuan. Este patron de diseno esta considerado como un patronde comportamiento debido al hecho de que puede alterar el comportamientodel programa en ejecucion.

Habitualmente un programa esta compuesto de un numero de clases (mu-chas veces elevado). La logica y computacion es distribuida entre esas clases.Sin embargo, cuantas mas clases son desarrolladas en un programa, espe-cialmente durante mantenimiento y/o refactorizacion, el problema de comu-nicacion entre estas clases quizas llegue a ser mas complejo. Esto hace queel programa sea mas difıcil de leer y mantener. Ademas, puede llegar a serdifıcil cambiar el programa, ya que cualquier cambio podrıa afectar codigoen muchas otras clases.

Figura 10.17: Estructura: Patron Metodo Mediador


Caso de Estudio

La solucion consiste en crear una entidad intermediaria que se encar-gue de gestionar la comunicacion entre objetos. En primer lugar definiremosuna interfaz para exponer las operaciones que un intermediario puede reali-zar, la cual llamaremos Mediator. Como es evidente debemos implementardicha interfaz mediante una clase ConcreteMediator para dotar a este defuncionalidad.


10.4.6. Momento

Modelo

Momento, es un patron de diseno cuya finalidad es almacenar el estadode un objeto (o del sistema completo) en un momento dado de manera quese pueda restaurar en ese punto de manera sencilla. Para ello se mantienealmacenado el estado del objeto para un instante de tiempo en una claseindependiente de aquella a la que pertenece el objeto (pero sin romper laencapsulacion), de forma que ese recuerdo permita que el objeto sea modi-ficado y pueda volver a su estado anterior.

Se usa este patron cuando se quiere poder restaurar el sistema desde es-tados pasados y por otra parte, es usado cuando se desea facilitar el hacery deshacer de determinadas operaciones, para lo que habra que guardar losestados anteriores de los objetos sobre los que se opere (o bien recordar loscambios de forma incremental).

Figura 10.18: Estructura: Patron Metodo Momento


Caso de Estudio

Este patron debe ser utilizado cuando se necesite salvar el estado de unobjeto y tener disponible los distintos estados historicos que se necesiten.Por ello mismo, este patron es muy intuitivo.


10.4.7. Observador

Modelo

Observador (en ingles: Observer) es un patron de diseno que define unadependencia del tipo uno-a-muchos entre objetos, de manera que cuando unode los objetos cambia su estado, notifica este cambio a todos los dependien-tes.El patron Observer es la clave del patron de arquitectura Modelo VistaControlador (MVC).1 De hecho el patron fue implementado por primeravez en Smalltalk’s MVC basado en un framework de interfaz.2 Este patronesta implementado en numerosos librerıas y sistemas, incluyendo todos lostoolkits de GUI.

Figura 10.19: Estructura: Patron Metodo Observador


Caso de Estudio

Las consecuencias de aplicar este patron pueden ser tanto beneficiosascomo pueden perjudicar algunos aspectos. Por una parte abstrae el acopla-miento entre el sujeto y el observador, lo cual es beneficioso ya que conse-guimos una mayor independencia y ademas el sujeto no necesita especificarlos observadores afectados por un cambio. Por otro lado, con el uso de estepatron ocurre que vamos a desconocer las consecuencias de una actualiza-cion, lo cual, dependiendo del problema, puede afectarnos en mayor o menormedida (por ejemplo, al rendimiento).


10.4.8. Estado

Modelo

El patron de estado se utiliza cuando el comportamiento de un objetocambia dependiendo del estado del mismo. Por ejemplo: una alarma puedetener diferentes estados, como desactivada, activada, en configuracion Defi-nimos una interfaz Estado-alarma y luego definimos los diferentes estados.

En determinadas ocasiones, cuando el contexto en el que se esta desarro-llando requiere que un objeto tenga diferentes comportamientos segun elestado en que se encuentra, resulta complicado poder manejar el cambiode comportamientos y los estados de dicho objeto, todos dentro del mismobloque de codigo. El patron State propone una solucion a esta complicacion,creando basicamente, un objeto por cada estado posible del objeto que lollama.

Figura 10.20: Estructura: Patron Metodo Estado


Caso de Estudio

Se implementa una clase para cada estado diferente del objeto y el desa-rrollo de cada metodo segun un estado determinado. El objeto de la clase ala que le pertenecen dichos estados resuelve los distintos comportamientossegun su estado, con instancias de dichas clases de estado. Ası, siempre tienepresente en un objeto el estado actual y se comunica con este para resolversus responsabilidades.


10.4.9. Estrategia

Modelo

El patron Estrategia (Strategy) es un patron de diseno para el desarrollode software. Se clasifica como patron de comportamiento porque determinacomo se debe realizar el intercambio de mensajes entre diferentes objetospara resolver una tarea. El patron estrategia permite mantener un conjuntode algoritmos de entre los cuales el objeto cliente puede elegir aquel que leconviene e intercambiarlo dinamicamente segun sus necesidades.

Es necesario el intercambio de informacion entre estrategia y contexto. Esteintercambio puede realizarse de dos maneras:

Mediante parametros en los metodos de la estrategia.

Mandandose, el contexto, a sı mismo a la estrategia.

Figura 10.21: Estructura: Patron Metodo Estrategia


Caso de Estudio

las posibilidades disponibles a la hora de definir la interfaz entre estra-tegia y contexto, estan:

Pasar como parametro la informacion necesaria para la estrategia im-plica un bajo acoplamiento y la posibilidad de envıo de datos innece-sarios.

Pasar como parametro el contexto y dejar que la estrategia solicite lainformacion que necesita supone un alto acoplamiento entre ellos.

Mantener en la estrategia una referencia al contexto (similar al ante-rior).


10.4.10. Metodo Plantilla

Modelo

es un patron de diseno de comportamiento que define el esqueleto deprograma de un algoritmo en un metodo, llamado metodo de plantilla, elcual difiere algunos pasos a las subclases. Permite redefinir ciertos pasos se-guros de un algoritmo sin cambiar la estructura del algoritmo.

El metodo de plantilla esta disenado para marcos, donde cada cual im-plementa las partes invariables de la arquitectura de un ambito, dejando”placeholders”para personalizar las opciones.

Figura 10.22: Estructura: Patron Metodo Plantilla


Caso de Estudio

Como puede verse en el anterior diagrama, la superclase contiene el meto-do plantilla, ese metodo con el algoritmo que comparten las entidades con-cretas (subclases). Como se puede apreciar, define una o varias operacionesconcretas en forma de metodos abstractos que son usados por el metodoplantilla y que deben ser implementadas por las clases hijas. Dichos meto-dos abstractos representan los comportamientos concretos de las entidades.


10.4.11. Visitador

Modelo

En programacion orientada a objetos, el patron visitor es una forma deseparar el algoritmo de la estructura de un objeto.La idea basica es que setiene un conjunto de clases elemento que conforman la estructura de un ob-jeto. Cada una de estas clases elemento tiene un metodo aceptar (accept())que recibe al objeto visitante (visitor) como argumento. El visitante es unainterfaz que tiene un metodo visit diferente para cada clase elemento; portanto habra implementaciones de la interfaz visitor de la forma: visitorCla-se1, visitorClase2... visitorClaseN.

Figura 10.23: Estructura: Patron Metodo Visitador


Caso de Estudio

El patron visitor tambien especifica como sucede la interaccion en laestructura del objeto. En su version mas sencilla, donde cada algoritmonecesita iterar de la misma forma, el metodo accept de un elemento conte-nedor, ademas de una llamada al metodo visit del objeto visitor, tambienpasa el objeto visitor como argumento al llamar al metodo accept de todossus elementos hijos.

Parte IV

Reflexiones

161

Capıtulo 11

Conclusiones - TrabajosFuturos - Contrastacion

11.1. Conclusiones

Como resultado del presente proyecto, podemos observar que una apli-cacion web permite a los analistas de callcenter de la empresa PagoDigital llevar a cabo sus actividades laborales sin la necesidad de per-manecer en un lugar fijo en este caso la oficina. Con el aplicativo webpodran acceder a la informacion de manera concurrente y de formasegura.

Con un lenguaje de modelado como arquimate es posible definir losobjetivos de una organizacion en base a los stakeholder, con esta me-todologıa se logra evidenciar las preocupaciones y necesidades que elarea de monitoreo de la empresa Pago Digital requiere para sus fun-ciones, allı se evidencia la necesidad de centralizar la informacion pararealizar un correcto monitoreo de ventas.

Elaborar aplicaciones web con un framework garantiza que la tareade desarrollo sea mucho mas agil y escalable, en este caso cubre unobjetivo de la organizacion, y es la necesidad de que sus aplicacionesweb no cuenten con sentencias SQL en sus lineas de codigo Esto segarantiza debido a que las consultas que maneja Laravel (framework) ala base de datos las realiza con Eloquent ORM (Json) que se encuentraincluido en Laravel.

163

164CAPITULO 11. CONCLUSIONES - TRABAJOS FUTUROS - CONTRASTACION

11.2. Trabajos Futuros

Existen trabajos futuros que se realizaran en conjunto con Pago Digitaldebido a que el alcance supera el tiempo de la especializacion y son lossiguientes:

Crear login para acceso al sistema con desbloqueo facial o reconoci-miento de voz

Elaborar un modulo para que disenadores y programadores de la com-panıa puedan realizar sus actividades en forma de teletrabajo

11.3. CONTRASTACION 165

11.3. Contrastacion

Se torna relativo garantizar que los trabajadores de la empresa Pago Di-gital podran monitorear las ventas de los clientes, debido a que si la personadecide no realizar el trabajo esta afirmacion no es posible ratificarla, es porello que este esfuerzo tecnologico no es mas ni menos que una herramientapara poder realizar la actividad laboral, pero es jurisdiccion del empleadoadoptarla para este fin, por ello se pretende a futuro garantizar que el em-pleado ingrese al sistema y cumpla con estas actividades y el desbloqueofacial es ideal para este objetivo.


Bibliografia

11.4. Bibliografia

11.4.1. Libros

[1] The Open Group, ArchiMate 3.0 – A Pocket Guide, Van Harten, July2016, First, ISBN: 978940180682-4

[2] Barbosa, Valeria Karina, Teletrabajo, liderar y trabajar en equipos a dis-tancia, Editorial Dunken, 2013, First, ISBN: 978987026476-7

[3] The Open Group, TOGAF Version 9.1, Van Harten, 2015, Fifth, ISBN:978908753768-5

[4] Guillermo Pantaleo, Ludmila Rinaudo, Ingenieria de Software, AlfaOme-ga, 2015, First, ISBN: 978987160978-9

[5] Laurent Debrauwer, Yannick Evain, Patrones de Diseno en PHP, Edicio-nes ENI, Nov 2015, Second, ISBN: 978274609837-4

[6] Martin Bean, Laravel 5 Essentials, Packt Publishing, Abr 2015, First,ISBN: 978178528301-7

11.4.2. Artıculos

[7] Min TIC, Teletrabajo, Packt Publishing, 2014, Direccion: http://www.mintic-.gov.co/portal/vivedigital/612/w3-propertyvalue-571.html

11.4.3. Conferencias

[8] Open2Study, Arquitectura Empresarial, 2014, Direccion: https://www.open2study.com-/courses/introduction-to-enterprise-architecture

167


11.4.4. Otros

[9] Sandro Bolanos, Caso de Estudio Archimate, Colosoft,

[10] The open group, ArchiSurance Case Study, Jan 2012,

Anexos

11.5. Imagenes Portal PD

11.5.1. Frontend

Imagen 1 - Listar Comercios

Figura 11.1: Portal PD: Listar Comercios

169


Imagen 2 - Crear Comercios

Figura 11.2: Portal PD: Crear Comercios

Imagen 3 - Listar Tarjetahabiente

Figura 11.3: Portal PD: Listar Tarjetahabiente

11.5. IMAGENES PORTAL PD 171

Imagen 4 - Crear Tarjetahabiente

Figura 11.4: Portal PD: Crear Tarjetahabiente

Imagen 5 - Detalle de Ventas

Figura 11.5: Portal PD: Detalle de Ventas


11.5.2. Backend

Imagen 6 - Migracion Creacion de Empresa (Comercio)

Figura 11.6: Portal PD: Migracion Creacion de Empresa

Imagen 7 - Creacion de Modelo

Figura 11.7: Portal PD: Creacion de Modelo


Imagen 8 - Creacion de Controlador

Figura 11.8: Portal PD: Creacion de Controlador

Imagen 9 - Creacion de la Ruta

Figura 11.9: Portal PD: Creacion de la Ruta


Imagen 10 - Consulta a la Base de Datos

Figura 11.10: Portal PD: Consulta con Eloquent Laravel

Imagen 11 - Configuracion de la Vista

Figura 11.11: Portal PD: Configuracion de la Vista


Imagen 12 - Diseno BD Modelo Relacional

Figura 11.12: Portal PD: Modelo Relacional

Documents

Desarrollo de un prototipo de aplicaci on web para el ...repository.udistrital.edu.co/.../6086/1/EstradaTinjacaDiegoArmando2… · Autor: Diego Armando Estrada Tinjac a Director: