PROTOTIPO DE HERRAMIENTA WEB PARA EL MONITOREO …repository.udistrital.edu.co/bitstream/11349/6513/1/MosqueraOrtega... · Modelo de Agrupamiento . . . . . . . . . . . . . . .

PROTOTIPO DE HERRAMIENTA WEB

PARA EL MONITOREO DE LAS

CANTIDADES DE MONOXIDO DE

CARBONO, EN LOS PARQUEADEROS DE

LA UNIVERSIDAD DISTRITAL FRANCISCO

JOSE DE CALDAS

Bayona Becerra, Sergio AlejandroCodigo: 20162099029

[email protected]

Mosquera Ortega, ChristianCodigo: 20162099040

[email protected]

18 de mayo de 2017

2

Indice general

I Proyecto 15

1. Anteproyecto 171.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2. Definicion del Problema . . . . . . . . . . . . . . . . . . . . . . . 18

1.2.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 181.2.2. Formulacion . . . . . . . . . . . . . . . . . . . . . . . . . . 191.2.3. Sistematizacion del problema . . . . . . . . . . . . . . . . 19

1.3. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.4.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . 211.4.2. Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . 21

1.5. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.5.1. Social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.5.2. Ecologica . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.5.3. Tecnologica . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.6. Marco Referencial . . . . . . . . . . . . . . . . . . . . . . . . . . 231.6.1. Marco Teorico . . . . . . . . . . . . . . . . . . . . . . . . 231.6.2. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . 231.6.3. Marco Espacial . . . . . . . . . . . . . . . . . . . . . . . . 251.6.4. Marco Temporal . . . . . . . . . . . . . . . . . . . . . . . 25

1.7. Aspectos Metodologicos . . . . . . . . . . . . . . . . . . . . . . . 261.7.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . . . 261.7.2. Metodo de investigacion . . . . . . . . . . . . . . . . . . . 261.7.3. Fuentes y tecnicas para la recoleccion de la informacion . 261.7.4. Tratamiento de la informacion . . . . . . . . . . . . . . . 26

1.8. Alcances, Limitaciones y Resultados Esperados . . . . . . . . . . 271.8.1. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.8.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . 271.8.3. Resultados Esperados . . . . . . . . . . . . . . . . . . . . 27

2. Metodologıa y Cronograma 292.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2. Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2.1. Modelo de Agrupamiento . . . . . . . . . . . . . . . . . . 30

3

4 INDICE GENERAL

2.3. Especificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.1. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.2. Cluster Hardware . . . . . . . . . . . . . . . . . . . . . . . 332.3.3. Cluster Autenticador . . . . . . . . . . . . . . . . . . . . . 342.3.4. Cluster Sensor . . . . . . . . . . . . . . . . . . . . . . . . 40

2.4. Cluster Reporteador . . . . . . . . . . . . . . . . . . . . . . . . . 452.5. Diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.6. Realizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.7. Validacion y Generalizacion . . . . . . . . . . . . . . . . . . . . . 482.8. Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

II Arquitectura Empresarial 51

3. Empresa 533.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.2. Mision y Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2.1. Mision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.2.2. Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.3. Organigrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.3.1. Organigrama . . . . . . . . . . . . . . . . . . . . . . . . . 543.3.2. Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . 543.3.3. Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.4. Procesos, Productos y Servicios . . . . . . . . . . . . . . . . . . . 573.4.1. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.4.2. Productos y Servicios . . . . . . . . . . . . . . . . . . . . 57

4. Lenguaje 594.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2. Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.2.1. Capa de Negocio . . . . . . . . . . . . . . . . . . . . . . . 604.2.2. Capa de Aplicacion . . . . . . . . . . . . . . . . . . . . . . 624.2.3. Capa de Tecnologıa . . . . . . . . . . . . . . . . . . . . . 664.2.4. Capa Motivacional . . . . . . . . . . . . . . . . . . . . . . 684.2.5. Capa Migracion . . . . . . . . . . . . . . . . . . . . . . . . 69

4.3. ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5. Capa de Negocio 735.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.2. Organizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 755.2.4. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.3. Cooperacion de Actor . . . . . . . . . . . . . . . . . . . . . . . . 765.3.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 76

INDICE GENERAL 5

5.3.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 775.3.4. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.4. Funcion de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . 785.4.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 785.4.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.4.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 795.4.4. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.5. Proceso de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . 805.5.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 805.5.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.5.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 825.5.4. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.6. Cooperacion de Proceso de Negocio . . . . . . . . . . . . . . . . . 835.6.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 835.6.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.6.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 855.6.4. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.7. Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.7.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 865.7.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.7.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 885.7.4. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6. Capa de Aplicacion 896.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.2. Uso de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.2.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 906.2.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.2.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 926.2.4. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.3. Comportamiento de Aplicacion . . . . . . . . . . . . . . . . . . . 936.3.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 936.3.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.3.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 946.3.4. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.4. Cooperacion de Aplicacion . . . . . . . . . . . . . . . . . . . . . . 956.4.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 956.4.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.4.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 966.4.4. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.5. Estructura de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . 976.5.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 976.5.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.5.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 986.5.4. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6 INDICE GENERAL

7. Capa de Infraestructura 997.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.2. Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007.2.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1007.2.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 101

7.3. Uso de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . 1027.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027.3.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1027.3.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 103

7.4. Implementacion y Despliegue . . . . . . . . . . . . . . . . . . . . 1047.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047.4.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1047.4.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 105

7.5. Estructura de la informacion . . . . . . . . . . . . . . . . . . . . 1067.5.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.5.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.5.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 107

7.6. Realizacion del Servicio . . . . . . . . . . . . . . . . . . . . . . . 1087.6.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.6.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.6.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 109

7.7. Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107.7.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107.7.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1107.7.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 111

8. Capa de Motivacion 1138.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1138.2. Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

8.2.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1148.2.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 115

8.3. Realizacion de Objetivos . . . . . . . . . . . . . . . . . . . . . . . 1168.3.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1168.3.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 117

8.4. Contribucion de Objetivos . . . . . . . . . . . . . . . . . . . . . . 1188.4.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.4.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 119

8.5. Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208.5.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1208.5.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 121

8.6. Realizacion de Requerimientos . . . . . . . . . . . . . . . . . . . 1228.6.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1228.6.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 123

8.7. Motivacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248.7.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 124

INDICE GENERAL 7

8.7.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 125

9. Capa Proyecto 1279.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1279.2. Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

9.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289.2.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1289.2.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 129

9.3. Migracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309.3.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1309.3.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 131

9.4. Migracion e Implementacion . . . . . . . . . . . . . . . . . . . . . 1329.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329.4.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 1329.4.3. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . 133

III Prototipo 135

10.Implementacion 13710.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13710.2. Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . 13710.3. Prototipo Teorico . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

10.3.1. Diagrama Esquematico del Sensor de CO2 . . . . . . . . . 13810.3.2. Prototipos de la Aplicacion Web . . . . . . . . . . . . . . 140

10.4. Prototipo Funcional . . . . . . . . . . . . . . . . . . . . . . . . . 14710.4.1. Esquema en protoboard del sensor de CO2 . . . . . . . . 14710.4.2. Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

IV Reflexiones 155

11.Conclusiones, Trabajos, Futuros Aportes, y Contrastacion 15711.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15711.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 15811.3. Aportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15911.4. Contrastacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16011.5. Codigo Fuente Arduino . . . . . . . . . . . . . . . . . . . . . . . 16511.6. Codigo Fuente Interfaces Java . . . . . . . . . . . . . . . . . . . . 166

8 INDICE GENERAL

Indice de figuras

1.1. contaminacion en el ambiente y el tiempo de exposicion[1] . . . . 24

2.1. Proceso en Cluster o de agrupamiento[23] . . . . . . . . . . . . . 302.2. Casos de Uso del Sistema . . . . . . . . . . . . . . . . . . . . . . 322.3. Caso de Uso Registrar Lectura CO2 . . . . . . . . . . . . . . . . 332.4. Caso de Uso Autenticar . . . . . . . . . . . . . . . . . . . . . . . 342.5. Caso de Uso Registrar Usuario . . . . . . . . . . . . . . . . . . . 352.6. Caso de Uso Listar Usuarios . . . . . . . . . . . . . . . . . . . . . 362.7. Caso de Uso Editar Usuario . . . . . . . . . . . . . . . . . . . . . 372.8. Caso de Uso Eliminar Usuario . . . . . . . . . . . . . . . . . . . . 382.9. Caso de Uso Consultar CO2 Usuario . . . . . . . . . . . . . . . . 392.10. Caso de Uso Seleccionar Sensor . . . . . . . . . . . . . . . . . . . 402.11. Caso de Uso Listar Sensores . . . . . . . . . . . . . . . . . . . . . 412.12. Caso de Uso Registrar Sensor . . . . . . . . . . . . . . . . . . . . 422.13. Caso de Uso Editar Sensor . . . . . . . . . . . . . . . . . . . . . . 432.14. Caso de Uso Eliminar Sensor . . . . . . . . . . . . . . . . . . . . 442.15. Caso de Uso Informe Sensores Alertados . . . . . . . . . . . . . . 452.16. Caso de Uso Informe Usuarios en Riesgo . . . . . . . . . . . . . . 462.17. Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1. Organigrama Actual . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.1. Metamodelo Capa de Negocio . . . . . . . . . . . . . . . . . . . . 604.2. Metamodelo Capa de Aplicacion . . . . . . . . . . . . . . . . . . 624.3. Metamodelo Capa Migracion e Implementacion . . . . . . . . . . 694.4. TOGAF vs Archimate . . . . . . . . . . . . . . . . . . . . . . . . 71

5.1. Meta-Modelo Organizacion . . . . . . . . . . . . . . . . . . . . . 745.2. Modelo Organizacion . . . . . . . . . . . . . . . . . . . . . . . . . 755.3. Modelo Cooperacion de Actor . . . . . . . . . . . . . . . . . . . . 765.4. Modelo Cooperacion de Actor . . . . . . . . . . . . . . . . . . . . 775.5. Modelo punto de vista funcion de negocio . . . . . . . . . . . . . 785.6. Modelo Funcion de Negocio . . . . . . . . . . . . . . . . . . . . . 795.7. Modelo punto de Vista Proceso de Negocio . . . . . . . . . . . . 81

9

10 INDICE DE FIGURAS

5.8. Modelo Proceso de Negocio . . . . . . . . . . . . . . . . . . . . . 825.9. Modelo punto de vista cooperacion de proceso de negocio . . . . 845.10. Modelo de Cooperacion de Proceso de Negocio . . . . . . . . . . 855.11. Modelo punto de vista producto . . . . . . . . . . . . . . . . . . 875.12. Modelo de Producto . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.1. Modelo Uso de Aplicacion . . . . . . . . . . . . . . . . . . . . . . 916.2. Modelo Uso de Aplicacion . . . . . . . . . . . . . . . . . . . . . . 926.3. Modelo Comportamiento de Aplicacion . . . . . . . . . . . . . . . 936.4. Modelo Comportamiento de Aplicacion . . . . . . . . . . . . . . . 946.5. Modelo Cooperacion de Aplicacion . . . . . . . . . . . . . . . . . 956.6. Modelo Cooperacion de Aplicacion . . . . . . . . . . . . . . . . . 966.7. Modelo Estructura de Aplicacion . . . . . . . . . . . . . . . . . . 976.8. Modelo Estructura de Aplicacion . . . . . . . . . . . . . . . . . . 98

7.1. Modelo Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . 1017.2. Modelo Uso de Infraestructura . . . . . . . . . . . . . . . . . . . 1037.3. Modelo de Implementacion y Despliegue . . . . . . . . . . . . . . 1057.4. Modelo de estructura de la informacion . . . . . . . . . . . . . . 1077.5. Modelo Realizacion del Servicio . . . . . . . . . . . . . . . . . . . 1097.6. Modelo de Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

8.1. Modelo de Partes Interesadas . . . . . . . . . . . . . . . . . . . . 1158.2. Modelo de Realizacion de Objetivos . . . . . . . . . . . . . . . . 1178.3. Modelo de Contribucion de Objetivos . . . . . . . . . . . . . . . 1198.4. Modelo de Principios . . . . . . . . . . . . . . . . . . . . . . . . . 1218.5. Modelo de Realizacion de Requerimientos . . . . . . . . . . . . . 1238.6. Modelo Motivacional . . . . . . . . . . . . . . . . . . . . . . . . . 125

9.1. Modelo de Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 1299.2. Modelo de Migracion . . . . . . . . . . . . . . . . . . . . . . . . . 1319.3. Modelo de Migracion e Implementacion . . . . . . . . . . . . . . 133

10.1. Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . 13710.2. Diagrama Esquematico Sensor Arduino . . . . . . . . . . . . . . 13810.3. Diagrama Sensor Arduino . . . . . . . . . . . . . . . . . . . . . . 13910.4. Autenticar (Mobile) . . . . . . . . . . . . . . . . . . . . . . . . . 14010.5. Pagina de Inicio (Mobile) . . . . . . . . . . . . . . . . . . . . . . 14010.6. Menu Usuario (Mobile) . . . . . . . . . . . . . . . . . . . . . . . 14110.7. Registrar Usuario (Mobile) . . . . . . . . . . . . . . . . . . . . . 14110.8. Selector Sensor (Mobile) . . . . . . . . . . . . . . . . . . . . . . . 14210.9. Menu Administrador (Mobile) . . . . . . . . . . . . . . . . . . . . 14210.10.Lista de usuarios (Mobile) . . . . . . . . . . . . . . . . . . . . . . 14310.11.Editar Usuario (Mobile) . . . . . . . . . . . . . . . . . . . . . . . 14310.12.Lista de sensores (Mobile) . . . . . . . . . . . . . . . . . . . . . . 14410.13.Registrar Sensor (Mobile) . . . . . . . . . . . . . . . . . . . . . . 144

INDICE DE FIGURAS 11

10.14.Editar sensor (Mobile) . . . . . . . . . . . . . . . . . . . . . . . . 14510.15.Sensores Alertados (Mobile) . . . . . . . . . . . . . . . . . . . . . 14510.16.Usuarios en Riesgo (Mobile) . . . . . . . . . . . . . . . . . . . . . 14610.17.Esquema Sensor Arduino en la protoboard . . . . . . . . . . . . . 14710.18.Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . . . 14810.19.Autenticar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14910.20.Autenticar - ¿Quienes Somos? . . . . . . . . . . . . . . . . . . . . 14910.21.Registrar Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 15010.22.Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15010.23.Seleccionar Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . 15110.24.Listar Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15110.25.Editar usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15210.26.Listar Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15210.27.Editar Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15310.28.Sensores Alertados . . . . . . . . . . . . . . . . . . . . . . . . . . 15310.29.Usuarios en riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . 154

12 INDICE DE FIGURAS

Indice de cuadros

1.1. Casos de Intoxicaciones Intramural por Monoxido de Carbono[2] 25

2.1. Caso Uso Registrar Lectura CO2 . . . . . . . . . . . . . . . . . . 332.2. Caso Uso Autenticar . . . . . . . . . . . . . . . . . . . . . . . . . 342.3. Caso Uso Registrar Usuario . . . . . . . . . . . . . . . . . . . . . 352.4. Caso Uso Listar Usuarios . . . . . . . . . . . . . . . . . . . . . . 362.5. Editar Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.6. Eliminar Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.7. Caso Uso Consultar CO2 Usuario . . . . . . . . . . . . . . . . . . 392.8. Caso Uso Seleccionar Sensor . . . . . . . . . . . . . . . . . . . . . 402.9. Caso Uso Listar Sensores . . . . . . . . . . . . . . . . . . . . . . 412.10. Caso Uso Registrar Usuario . . . . . . . . . . . . . . . . . . . . . 422.11. Editar Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.12. Eliminar sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.13. Caso Uso Informe Sensores Alertados . . . . . . . . . . . . . . . . 452.14. Caso Uso Informe Usuarios en Riesgo . . . . . . . . . . . . . . . 46

4.1. Resumen de los conceptos de capa tecnologica . . . . . . . . . . . 674.2. Conceptos motivacionales . . . . . . . . . . . . . . . . . . . . . . 684.3. Resumen de Implementacion y Conceptos de Migracion . . . . . 70

5.1. Punto de Vista Organizacion . . . . . . . . . . . . . . . . . . . . 745.2. Descripcion Punto de Vista Cooperacion de Actor . . . . . . . . 765.3. Descripcion Punto de Vista Funcion de Negocio . . . . . . . . . . 785.4. Descripcion Punto de Vista Proceso de Negocio . . . . . . . . . . 805.5. Descripcion Punto de Vista Cooperacion de Proceso de Negocio . 835.6. Descripcion Punto de Vista de Producto . . . . . . . . . . . . . . 86

6.1. Descripcion Punto de Vista Uso de Aplicacion . . . . . . . . . . . 906.2. Descripcion Punto de Vista Comportamiento de Aplicacion . . . 936.3. Descripcion Punto de Vista Cooperacion de Aplicacion . . . . . . 956.4. Descripcion Punto de Vista Estructura de Aplicacion . . . . . . . 97

7.1. Descripcion Punto de Vista Infraestructura . . . . . . . . . . . . 1007.2. Descripcion Punto de Vista Uso de Infraestructura . . . . . . . . 102

13

14 INDICE DE CUADROS

7.3. Descripcion Punto de Vista de Implementacion y Despliegue . . . 1047.4. Descripcion Punto de Vista Estructura de la informacion . . . . 1067.5. Descripcion Punto de vista Realizacion del Servicio . . . . . . . . 1087.6. Descripcion Punto de Vista de Capas . . . . . . . . . . . . . . . . 110

8.1. Descripcion Punto de Vista de Partes Interesadas . . . . . . . . . 1148.2. Descripcion Punto de Vista de Realizacion de Objetivos . . . . . 1168.3. Descripcion Punto de Vista de Contribucion de Objetivos . . . . 1188.4. Descripcion Punto de Vista de Principios . . . . . . . . . . . . . 1208.5. Descripcion Punto de Vista de Realizacion de Requerimientos . . 1228.6. Descripcion Punto de Vista Motivacional . . . . . . . . . . . . . 124

9.1. Descripcion Punto de Vista de Proyecto . . . . . . . . . . . . . . 1289.2. Descripcion Punto de Vista de Migracion . . . . . . . . . . . . . 1309.3. Descripcion Punto de Vista de Migracion e Implementacion . . . 132

Parte I

Proyecto

15

Capıtulo 1

Anteproyecto

1.1. Introduccion

Este trabajo propone una forma de monitorear los niveles de monoxido decarbono[3] en entornos cerrados, por medio de software[4] y hardware libre[5],lo que significa un bajo costo en la replicacion del sistema para otros proyectosque ası lo requieran.

El monoxido de carbono es uno de los grandes contaminantes de nuestroentorno[6], este se genera principalmente por los vehıculos automotores y lasempresas que al realizar procesos industriales generan como desechos diferentescompuestos del carbono, entre ellos el monoxido de carbono.

El monoxido de carbono es un causante de enfermedades respiratorias[7]para las personas que se exponen frecuentemente a este, como son las personasque trabajan brindando seguridad en los parqueaderos o los ciclistas que usanlos parqueaderos de la universidad y que con su medio de transporte alternativocontribuyen de manera importante a reducir la polucion de la ciudad.

En cuanto a los vehıculos automotores, las motos se consideran como lassegundas mayores contaminantes, ya que pueden generar grandes cantidades demonoxido de carbono debido a que sus motores no estan disenados para serlimpios [8] y a que se ha incrementado su numero en la ciudad de Bogota [9]para finales de ano 2015, las cuales por su cantidad en los parqueaderos puedengenerar grandes cantidades de monoxido de carbono.

17

18 CAPITULO 1. ANTEPROYECTO

1.2. Definicion del Problema

1.2.1. Descripcion

En la actualidad Bogota cuenta con un gran problema de contaminacion pormonoxido de carbono[9], esto se da en gran medida por los vehıculos automotoresy las fabricas que se encuentran dentro de la zona urbana.

Este tipo de contaminacion por monoxido de carbono afecta de manera massignificativa lugares cerrados como parqueaderos, lo que traera consecuenciaspara la salud respiratoria de las personas que transitan o permanecen suficientetiempo expuestos a esta contaminacion.

Si se contara con datos de contaminacion en lugares y horas especıficos, laspersonas podran controlar las medidas de precaucion para estar expuestos a lacontaminacion como tambien analizar cuales son los sitios mas contaminadospara realizar tareas de esparcimiento.

Esto nos lleva a preguntarnos; ¿Conocer la contaminacion en un determinadositio, me permite planificar las actividades y horarios adecuados para reducir larepercusion de la contaminacion por monoxido de carbono al pasar tanto tiempoexpuesto?

1.2. DEFINICION DEL PROBLEMA 19

1.2.2. Formulacion

Se requiere una herramienta que muestre la contaminacion por monoxido decarbono en un determinado sitio para planificar las actividades y horarios conmenos repercusion.

1.2.3. Sistematizacion del problema

¿De que forma se puede integrar todos los elementos de recoleccion dedatos con un proceso de desarrollo de software?

¿Determinar un valor apropiado para obtener la informacion sobre la con-taminacion por monoxido de carbono y trasmitirla?

¿Cual es la forma adecuada para mostrar la informacion recolectada sobrela contaminacion?


1.3. Hipotesis

Si las personas en los parqueaderos de la Universidad Distrital FranciscoJose De Caldas usan el prototipo web de medicion de monoxido de carbonoentonces pueden conocer la contaminacion en tiempo real tomando mejores de-cisiones respecto a los tiempos de exposicion medidas de proteccion adicional sise requiere permanecer expuesto.

1.4. OBJETIVOS 21

1.4. Objetivos

1.4.1. Objetivo General

Desarrollar un prototipo web que permita mostrar las lecturas de las canti-dades de monoxido de carbono en los parqueaderos de la Universidad DistritalFrancisco Jose De Caldas, con hardware y software libre, para alertar sobreniveles perjudiciales a la exposicion prolongada.

1.4.2. Objetivos Especıficos

Disenar un sistema, con una arquitectura orientada a objetos para po-der representar los elementos y comunicaciones de hardware y softwareeficientemente.

Construir el circuito electronico con hardware libre y sensores de monoxidode carbono, para medir los niveles de contaminacion en el aire, en losparqueaderos de la Universidad Distrital Francisco Jose De Caldas.

Desarrollar un prototipo web, con software libre, para poder representarlos datos obtenidos de los sensores que miden las cantidades de monoxidode carbono.


1.5. Justificacion

1.5.1. Social

Buscamos dar las herramientas que lleven a una mejor calidad de vida paralas personas que se exponen diariamente al monoxido de carbono, gracias a queel sistema propuesto busca alertar sobre los niveles perjudiciales de monoxidode carbono en el ambiente, serıa posible para los usuarios del sistema prevenirenfermedades respiratorias.

1.5.2. Ecologica

La contaminacion por monoxido de carbono, puede ser tan grave como parallevar a la muerte a una persona, dependiendo del grado de exposicion y lacantidad que se encuentre en el medio, la cual se mide en PPM (partıculas pormillon), en Colombia para el ano 2012 se presentaron 469 casos de intoxicaciony 6 muertes [10], lo que da cuenta del gran peligro que constituye el mismo engrandes cantidades para las personas de las ciudades.

1.5.3. Tecnologica

Se propone que el resultado de esta investigacion sea un prototipo de herra-mienta web porque existe la necesidad de determinar los niveles de contamina-cion por monoxido de carbono en los parqueaderos de la Universidad DistritalFrancisco Jose De Caldas, debido a que estos niveles pueden determinar lasdecisiones a tomar para proteger la salud de las personas que se encuentranexpuestas a esta contaminacion, tanto para los casos cuando sea alta o parael caso en que sea baja, pero las personas permanezcan expuestas durante untiempo prolongado, lo cual tambien afecta su salud.

1.6. MARCO REFERENCIAL 23

1.6. Marco Referencial

1.6.1. Marco Teorico

El monoxido de carbono es considerado uno de los mayores contaminantesde la atmosfera terrestre. Sus principales fuentes productoras responsables deaproximadamente 80 % de las emisiones, son los vehıculos automotores que uti-lizan como combustible gasolina o diesel y los procesos industriales que utilizancompuestos del carbono. Esta sustancia es bien conocida por su toxicidad parael ser humano[11].

1.6.1.1. Diseno orientado a objetos

Modela los sistemas de software como colecciones de objetos que cooperan,tratando los objetos individuales como instancias de una clase que esta adentrode una jerarquıa de clases[12].

1.6.1.2. Descomposicion orientada a objetos

Identifican los objetos que se derivan directamente del vocabulario del do-minio del problema. Son agentes autonomos que colaboran para llevar a caboalgun comportamiento de nivel superior. Un objeto aquı es una entidad tangibleque muestra un comportamiento bien definido[12].

1.6.2. Marco Conceptual

1.6.2.1. Arduino

Es una plataforma electronica de codigo abierto basado en facil de usarhardware y software. Las Placas Arduino son capaces de leer las entradas yproducir un conjunto de instrucciones de salida que proceso el microcontrolador.Para ello se utiliza el lenguaje de programacion de Arduino, y el software deArduino (IDE), sobre la base de procesamiento[13].

1.6.2.2. Monoxido de carbono

El monoxido de carbono es un gas incoloro e inodoro que se forma por lacombustion incompleta de material organico, en presencia deficitaria de oxıgeno.Es considerado uno de los mayores contaminantes de la atmosfera terrestre, yuno de los mayores problemas ambientales de America Latina. Las principalesfuentes productoras de este contaminante son los vehıculos automotores queutilizan como combustible gasolina o diesel[11].


1.6.2.3. Contaminacion Atmosferica

“Es la presencia en el aire de una sustancia extrana o una variacionimportante en la proporcion de sus componentes susceptibles de pro-vocar un efecto perjudicial en la salud o en el ambiente, de origenantropico (actividades humanas) o natural”[6]

En la actualidad Bogota presenta un problema de contaminacion por monoxi-do de carbono[14], esto se da por la gran cantidad de vehıculos automotores ylas fabricas que se encuentran dentro de la zona urbana[11]. La contaminaciontrae consecuencias para la salud respiratoria de las personas que transitan opermanecen suficiente tiempo expuestos a esta contaminacion[1].

Figura 1.1: contaminacion en el ambiente y el tiempo de exposicion[1]

El monoxido de carbono se puede medir en partes por millon (PPM) la cualdemuestra su peligrosidad por intoxicacion[15][16]. La intoxicacion por monoxi-do de carbono[17] pueden ser tan grave como para llevar a la muerte a una per-sona, como sucedio en Colombia, en donde para el ano 2012 se presentaron 469casos de intoxicacion[18] y 6 muertes[10]. En el envenenamiento por MonoxidoDe Carbono[18], los sıntomas son: dolores de cabeza, cansancio, nauseas, mareos,vision borrosa, vomito, confusion, perdida de la conciencia[19].El ObservatorioAmbiental de Bogota el cual tiene el informe de intoxicacion por monoxido decarbono[2] presenta los datos a nivel de Bogota donde se encuentran documen-tados los casos por ano:

1.6. MARCO REFERENCIAL 25

Fecha Casos2008 852009 652010 762011 902012 1022013 1692014 1132015 79

Cuadro 1.1: Casos de Intoxicaciones Intramural por Monoxido de Carbono[2]

1.6.2.4. Contaminacion del Aire de Interiores

Directrices de la OMS sobre la calidad del aire de interiores se subraya lanecesidad de mejorar el acceso de los hogares a fuentes de energıa menos con-taminantes. Evitando enfermedades que se deben principalmente a los elevadosniveles de partıculas finas en suspension y de monoxido de carbono[20].

1.6.2.5. Envenenamiento Por Monoxido De Carbono

Entre los sıntomas por envenenamiento por monoxido de carbono podemosencontrar: dolores de cabeza, cansancio, nauseas, mareos, vision borrosa, vomito,confusion y perdida de la conciencia[17].

1.6.2.6. Toxinas

La exposicion a las toxinas es frecuente y generalmente causan problemas ycomplicaciones causando confusiones en los diagnosticos clınicos[15].

1.6.3. Marco Espacial

La investigacion sera en los parqueaderos de la Universidad Distrital Fran-cisco Jose De Caldas, debido a la facilidad de recoleccion de datos que permitesu trafico vehicular, tanto de carros como de motocicletas.

1.6.4. Marco Temporal

La investigacion sera realizada en toma de datos por medio de los sensorespara alimentar el sistema en el periodo de tiempo entre 2016 y 2017, se esperatener suficientes datos en este periodo para alimentar el sistema.


1.7. Aspectos Metodologicos

1.7.1. Tipo de estudio

El tipo de estudio es exploratorio, ya que como investigador es uno de losprimeros acercamientos hacia el problema de enfrentar la contaminacion pormonoxido de carbono de una manera consciente por medio de la aplicacionpractica de una herramienta para este motivo. Se basara en el metodo inductivo,ya que se parte del problema de poder tomar mejores decisiones al convivir conla contaminacion por monoxido de carbono y una herramienta para analizar losdatos de esta es la indicada.

El problema de los niveles de contaminacion por monoxido de carbono ha si-do evidenciado en diferentes estudios[11], la evaluacion de estos niveles se realizapor medio de dispositivos dedicados a este proposito, pero no son evidenciablesa gran escala o enfocados al publico en particular, por lo que esta herramientapermitira subsanar esta falencia y ademas estos datos podran ser consultadospara futuras investigaciones.

1.7.2. Metodo de investigacion

Se utilizara como fuente primaria los datos obtenidos del circuito electronicocon su respectivo sensor para niveles de monoxido de carbono, ya que estosgeneraran la informacion necesaria para la toma de decisiones. Como fuentessecundarias algunos artıculos cientıficos sobre los niveles nocivos del monoxidode carbono[11] y estudios de diferentes organismos de la salud[19].

1.7.3. Fuentes y tecnicas para la recoleccion de la infor-macion

Las fuentes primarias seran los datos que suministre el circuito electronico ysu respectiva geo-localizacion. Como fuentes secundarias de datos se trabajarapara obtener la media estadıstica para clasificar los horarios con picos buenos ymalos respecto a la localizacion del circuito electronico.

1.7.4. Tratamiento de la informacion

Los datos obtenidos del circuito electronico estos se almacenaran en una basede datos la cual permitira su tabulacion y clasificacion.

1.8. ALCANCES, LIMITACIONES Y RESULTADOS ESPERADOS 27

1.8. Alcances, Limitaciones y Resultados Espe-rados

1.8.1. Alcances

Construccion del modelo para el sistema propuesto.

Ensamble de alarmas auditivas y visuales, en el circuito electronico paraniveles altos de contaminacion por monoxido de carbono.

Diseno y construccion del circuito electronico con su respectivo sensor paramedir los niveles de monoxido de carbono.

Analisis, diseno e implementacion de herramienta Web que muestre lainformacion sobre los niveles de monoxido de carbono en un mapa con lalectura del sensor.

1.8.2. Limitaciones

Autorizacion sobre la instalacion del sensor por parte de la UniversidadDistrital Francisco Jose De Caldas.

1.8.3. Resultados Esperados

Se espera llegar a una herramienta web con caracterısticas de responsivedesign para poder ser consultado desde cualquier dispositivo.

Se espera que la herramienta muestre la informacion del comportamientode los datos obtenidos de los sensores por medio de graficos que representendicho comportamiento en el tiempo.

Se espera que el diseno sea modular, contando con varios web servicesde consulta para que otros sistemas puedan acceder a la informacion delaplicativo.


Capıtulo 2

Metodologıa y Cronograma

2.1. Introduccion

Buscando la organizacion estructurada de procesos y componentes que seinterrelacionan para la solucion de este proyecto, y teniendo en cuenta queel desarrollo estara guiado por el paradigma de la orientacion a objetos, seencuentra que la mejor manera de expresar dichos componentes es por medio deUML [21] que refuerza la representacion de programacion orientada a objetos[22], todo esto dentro del marco de la metodologıa del modelo de agrupamientoo cluster, propuesta Bertrand Meyer en 1990, como una metodologıa orientada aobjetos que busca potenciar la separacion de conceptos relacionados, generandogrupos o clusteres de clases a desarrollar.

29

30 CAPITULO 2. METODOLOGIA Y CRONOGRAMA

2.2. Metodologıa

2.2.1. Modelo de Agrupamiento

El proceso en cluster o modelo de agrupamiento fue propuesto por BertrandMeyer en 1990, su concepto clave es el agrupamiento, que es un conjunto de cla-ses relacionadas con un objetivo comun, este proceso define el cluster como launidad organizativa basica, el cual es un grupo de clases relacionadas o, recursi-vamente, clusteres relacionados. El cluster es la unidad natural para el desarrollopor parte de un unico desarrollador, aunque puede ser trabajado tambien porun grupo de desarrollo. Entre sus principales caracterısticas tenemos:

Evita el efecto todo-nada propio del modelo en cascada.

Tiene un componente secuencial y un componente concurrente.

Existencia de diferentes subciclos de vida, que pueden solaparse en eltiempo.

Se aplica al cluster no al sistema completo.

El miniciclo de vida que gobierna el desarrollo de un cluster esta forma-do por Especificacion, Diseno, Implementacion, Verificacion/Validacion yGeneralizacion.

Figura 2.1: Proceso en Cluster o de agrupamiento[23]

2.2. METODOLOGIA 31

Para el proyecto, y de acuerdo a la funcionalidad proyectada, se han esta-blecido los siguientes clusteres, para organizar el desarrollo:

1. Core: Corresponde al desarrollo de la capa de modelo, de la API y la capade persistencia que son el lenguaje comun que usaran los demas clusteres.

2. Hardware: Corresponde al desarrollo de los componentes de hardwareque dan soporte al sistema entero al capturar y transmitir los datos deniveles de CO2 presnetes en el ambiente.

3. Autenticador: Corresponde al desarrollo de los componentes Usuario yAutenticador que dan el soporte para la autenticacion y la gestion deusuarios.

4. Sensor: Corresponde al desarrollo de los componentes Lector y Sensor queson los que permiten la recepcion de datos provenientes del componentehardware y la gestion de los sensores en la base de datos.

5. Reporteador: Corresponde al desarrollo de los componentes Reporteadory AlertaSoftware que son los encargados de mostrar informacion a losusuarios sobre el estado en tiempo real e historico de los sensores de CO2y sus respectivas mediciones.

6. Web: Corresponde al desarrollo de la aplicacion Web que permite mostrarla informacion a los usuarios a traves de diferentes dispositivos en formatoHTML.

A continuacion vamos a detallar el trabajo realizado en cada fase para cadauno de los clusteres establecidos.


2.3. Especificacion

2.3.1. Casos de Uso

El trabajo de especificacion del sistema comenzo con el establecimiento delos casos de uso en cada cluster de los propuestos en la metodologıa, el resultadocompleto se detalla en la siguiente figura, en donde hemos unido todos los casosde uso en un solo diagrama, no obstante en las siguientes secciones detallamoscada caso de uso por aparte, organizado en los clusteres, con la excepcion delcluster de Core, que no cubre ningun caso de uso en particular, sino que proveesoporte para los demas clusteres.

Figura 2.2: Casos de Uso del Sistema

2.3. ESPECIFICACION 33

2.3.2. Cluster Hardware

2.3.2.1. Caso Uso Registrar Lectura CO2

Figura 2.3: Caso de Uso Registrar Lectura CO2

UC-01 Registrar Lectura CO2Version 2.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Realiza el envıo de los datos tomados por el sensor y se ocupa de su recepcionPrecondicion El sensor se encuentra instalado y funcionandoSecuencia normal

Paso Usuario Sistema1 Toma dato y lo envıa por Wifi2 Valida el dato enviado2.1 Datos Validos2.1.1 Almacena el dato en base de da-

tosPostcondicion NingunaFlujos Alternos NingunoExcepciones

Paso Accion Sistema2.2 Datos Invalidos2.2.1 Devuelve codigo de error

Cuadro 2.1: Caso Uso Registrar Lectura CO2


2.3.3. Cluster Autenticador

2.3.3.1. Caso Uso Autenticar

Figura 2.4: Caso de Uso Autenticar

UC-02 AutenticarVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Permite autenticar el usuario frente al sistemaPrecondicion NingunaSecuencia normal

Paso Usuario Sistema1 Verifica si existe una sesion previa1.1 No Existe1.1.1 Redirecciona a la pagina de Login2 Digita: usuario y clave3 Presiona Boton Ingresar4 Valida Existencia usuario y clave4.1 Datos Validos4.1.1 Crea Sesion de Usuario5 Redirecciona a la pagina referida

Postcondicion NingunaFlujos alternos

Paso Accion Sistema1.2 Si existe1.2.1 Redirecciona a la pagina referida

ExcepcionesPaso Accion Sistema4.2 Datos Invalidos4.2.1 Muestra mensaje de error4.2.2 Ir a Paso 2

Cuadro 2.2: Caso Uso Autenticar


2.3.3.2. Caso Uso Registrar Usuario

Figura 2.5: Caso de Uso Registrar Usuario

UC-03 Registrar UsuarioVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Permite al usuario registrarse en el sistemaPrecondicion NingunaSecuencia normal

Paso Usuario Sistema1 Ingresa a la opcion de registrar

usuario1.1 Redirecciona a la pagina de Re-

gistro de usuarios2 Digita: <<usuario>>, <<cla-

ve>>y <<email>>3 Presiona Boton Guardar4 Valida Existencia <<usua-

rio>>e idoneidad de <<cla-ve>>

4.1 Datos Validos4.1.1 Crea Usuario4.1.2 Informa a usuario con mensaje

del exito de la operacionPostcondicion Se crea un usuario en la base de datos del sistemaFlujos alternos NingunoExcepciones

Paso Accion Sistema4.2 Datos Invalidos4.2.1 Muestra mensaje de error4.2.2 Ir a Paso 2

Cuadro 2.3: Caso Uso Registrar Usuario


2.3.3.3. Caso Uso Listar Usuarios

Figura 2.6: Caso de Uso Listar Usuarios

UC-04 Listar UsuariosVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Le muestra al usuario los usuarios existentes en el sistemaPrecondicion El usuario debe ser un administradorSecuencia normal

Paso Usuario Sistema1 Ingresa a la opcion de listar usua-

rios1.1 Redirecciona a la pagina de Lis-

tar usuarios, mostrando una ta-bla con los usuarios existentes enel sistema y botones para editaro eliminar un usuario selecciona-do en la tabla.

2 Si lo desea el usuario puede selec-cionar un <<usuario>>y editar-lo (ver UC-05) o eliminarlo (verUC-06)

Postcondicion NingunaFlujos alternos NingunoExcepciones Ninguna

Cuadro 2.4: Caso Uso Listar Usuarios


2.3.3.4. Caso Uso Editar Usuario

Figura 2.7: Caso de Uso Editar Usuario

UC-05 Editar UsuarioVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion permite editar los datos de un usuario existente en el sistemaPrecondicion El usuario debe ser un administradorSecuencia normal

Paso Usuario Sistema1 Ingresa a la opcion de editar

usuario1.1 Redirecciona a la pagina de Edi-

tar usuario, mostrando el estadoy correo electronico del usuarioseleccionado en la pagina de lis-tar Usuarios.

2 Selecciona un <<estado>>ycambia el <<email>>delusuario

3 Presiona el Boton Guardar4 Valida datos del <<usuario>>4.1 Datos Validos4.1.1 Actualiza Usuario4.1.2 Informa a usuario con mensaje

del exito de la operacionPostcondicion Se actualizan los datos del usuario en la base de datos del sistema.Flujos alternos NingunoExcepciones


Cuadro 2.5: Editar Usuario


2.3.3.5. Caso Uso Eliminar Usuario

Figura 2.8: Caso de Uso Eliminar Usuario

UC-06 Eliminar UsuarioVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion permite eliminar un usuario existente en el sistemaPrecondicion El usuario debe ser un administradorSecuencia normal

Paso Usuario Sistema1 En la pagina de Listar Usuarios

el usuario selecciona el usuario aeliminar

2.1 Presiona el Boton Eliminar3 Valida datos del <<usuario>>3.1 Datos Validos3.1.1 Elimina al Usuario3.1.2 Informa a usuario con mensaje

del exito de la operacionPostcondicion Se elimina un usuario en la base de datos del sistema.Flujos alternos NingunoExcepciones


Cuadro 2.6: Eliminar Usuario


2.3.3.6. Caso Uso Consultar CO2 Usuario

Figura 2.9: Caso de Uso Consultar CO2 Usuario

UC-07 Consultar CO2 UsuarioVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Permite autenticar el usuario frente al sistemaPrecondicion NingunaSecuencia normal

Paso Usuario Sistema1 Escoge la opcion de seleccionar

sensor o ingresa al sistema consu usuario sin haber configuradopreviamente un sensor

1.1 Redirecciona a la pagina de Se-leccion de sensor, mostrando lossensores activos y su ubicacion

2 Selecciona un <<sensor>>de latabla

3 Presiona Boton Guardar4 Valida que el <<sen-

sor>>seleccionado se encuentreactivo

4.1 Datos Validos4.1.1 actualiza Usuario, guardando la

referencia al sensor seleccionado4.1.2 Informa al usuario con mensaje

del exito de la operacionPostcondicion Se actualiza un usuario en la base de datos del sistemaFlujos alternos NingunoExcepciones


Cuadro 2.7: Caso Uso Consultar CO2 Usuario


2.3.4. Cluster Sensor

2.3.4.1. Caso Uso Seleccionar Sensor

Figura 2.10: Caso de Uso Seleccionar Sensor

UC-08 Seleccionar SensorVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Permite al usuario seleccionar un sensor para mostrarle los niveles de CO2Precondicion NingunaSecuencia normal

Paso Usuario Sistema1 Escoge la opcion de seleccionar

sensor o ingresa al sistema conusuario sin haber configuradopreviamente un sensor

1.1 Redirecciona a la pagina de Se-leccion de sensor, mostrando lossensores activos y su ubicacion

2 Selecciona un <<sensor>>3 Presiona Boton Guardar4 Valida que el sensor seleccionado

se encuentre activo4.1 Datos Validos4.1.1 actualiza Usuario, guardando la

referencia al sensor seleccionado4.1.2 Informa al usuario con mensaje

del exito de la operacionPostcondicion Se actualiza un usuario en la base de datos del sistemaFlujos alternos NingunoExcepciones


Cuadro 2.8: Caso Uso Seleccionar Sensor


2.3.4.2. Caso Uso Listar Sensores

Figura 2.11: Caso de Uso Listar Sensores

UC-09 Listar SensoresVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Le muestra al usuario los sensores existentes en el sistemaPrecondicion El usuario debe ser un administradorSecuencia normal

Paso Usuario Sistema1 Ingresa a la opcion de listar sen-

sores1.1 Redirecciona a la pagina de Lis-

tar sensores, mostrando una ta-bla con los sensores existentes enel sistema y botones para editaro eliminar un sensor seleccionadoen la tabla.

2 Si lo desea el usuario puede selec-cionar un <<sensor>>y editar-lo (ver UC-11) o eliminarlo (verUC-12)

Postcondicion NingunaFlujos alternos NingunoExcepciones Ninguna

Cuadro 2.9: Caso Uso Listar Sensores


2.3.4.3. Caso Uso Registrar Sensor

Figura 2.12: Caso de Uso Registrar Sensor

UC-10 Registrar SensorVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Permite al usuario registrar un sensor en el sistemaPrecondicion El usuario debe ser administradorSecuencia normal

Paso Usuario Sistema1 Ingresa a la opcion de registrar

sensor1.1 Redirecciona a la pagina de Re-

gistro de sensores2 Digita: <<nombre>>, <<coor-

denadas>>, <<ubicacion>>y<<descripcion>>

3 Presiona Boton Guardar4 Valida Existencia <<sensor>>e

idoneidad de datos4.1 Datos Validos4.1.1 Crea Usuario4.1.2 Informa a usuario con mensaje

del exito de la operacionPostcondicion Se crea un usuario en la base de datos del sistemaFlujos alternos NingunoExcepciones


Cuadro 2.10: Caso Uso Registrar Usuario


2.3.4.4. Caso Uso Editar Sensor

Figura 2.13: Caso de Uso Editar Sensor

UC-11 Editar SensorVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Permite editar los datos de un sensor existente en el sistemaPrecondicion El usuario debe ser un administradorSecuencia normal

Paso Usuario Sistema1 Ingresa a la opcion de editar sen-

sor1.1 Redirecciona a la pagina de Edi-

tar sensor, mostrando la localiza-cion, grupo y descripcion del sen-sor seleccionado en la pagina delistar sensorres.

2 Digita la localizacion, grupo ydescripcion del sensor

3 Presiona el Boton Guardar4 Valida datos del <<sensor>>4.1 Datos Validos4.1.1 Actualiza sensor4.1.2 Informa a usuario con mensaje

del exito de la operacionPostcondicion Se actualizan los datos del sensor en la base de datos del sistema.Flujos alternos NingunoExcepciones


Cuadro 2.11: Editar Sensor


2.3.4.5. Caso Uso Eliminar Sensor

Figura 2.14: Caso de Uso Eliminar Sensor

UC-12 Eliminar SensorVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Permite eliminar un sensor existente en el sistemaPrecondicion El usuario debe ser un administradorSecuencia normal

Paso Usuario Sistema1 En la pagina de Listar sensores

el usuario selecciona el sensor aeliminar

2.1 Presiona el Boton Eliminar3 Valida datos del <<sensor>>3.1 Datos Validos3.1.1 Elimina al sensor3.1.2 Informa a usuario con mensaje

del exito de la operacionPostcondicion Se elimina un sensor en la base de datos del sistema.Flujos alternos NingunoExcepciones


Cuadro 2.12: Eliminar sensor

2.4. CLUSTER REPORTEADOR 45

2.4. Cluster Reporteador

2.4.0.1. Caso Uso Informe Sensores Alertados

Figura 2.15: Caso de Uso Informe Sensores Alertados

UC-13 Informe Sensores AlertadosVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Permite al administrador visualizar sensores alertadosPrecondicion Ser un usuario administradorSecuencia normal

Paso Usuario Sistema1 Ingresa a la opcion de sensores

alertados2 Redirecciona a la pagina de Sen-

sores alertados2.1 Muestra una tabla con los sen-

sores cuyas ultimas diez lecturascontienen valores que estan porencima de los niveles recomenda-dos de CO2 para la salud huma-na

Postcondicion NingunaFlujos alternos NingunoExcepciones

Paso Accion Sistema2.2 No hay datos2.2.1 Muestra mensaje informativo in-

dicando que no hay sensores porencima de los niveles recomenda-dos de CO2

2.2.2 Ir a Paso 2

Cuadro 2.13: Caso Uso Informe Sensores Alertados


2.4.0.2. Caso Uso Informe Usuarios en Riesgo

Figura 2.16: Caso de Uso Informe Usuarios en Riesgo

UC-14 Informe Usuarios en RiesgoVersion 1.0Autores Christian Mosquera, Sergio BayonaFuentes Observacion y AnalisisDescripcion Permite al administrador visualizar los usuarios que se encuentran en riesgoPrecondicion El usuario debe ser administradorSecuencia normal

Paso Usuario Sistema1 Ingresa a la opcion de usuarios

en riesgo2 Redirecciona a la pagina de usua-

rios en riesgo2.1 Muestra una tabla con los usua-

rios cercanos a sensores cuyas ul-timas diez lecturas contienen va-lores que estan por encima delos niveles recomendados de CO2para la salud humana

Postcondicion NingunaFlujos alternos NingunoExcepciones

Paso Accion Sistema2.2 No hay datos2.2.1 Muestra mensaje informativo in-

dicando que no hay usuarios enriesgo por los niveles de CO2

2.2.2 Ir a Paso 2

Cuadro 2.14: Caso Uso Informe Usuarios en Riesgo

2.5. DISENO 47

2.5. Diseno

Podemos dividir la tarea de diseno en dos partes; primero el diseno delhardware que se representa por los esquemas planteados del circuito, estos seencuentran en el capitulo III Prototipo, en la seccion dedicada al prototipoteorico del sistema.

Por otro lado el diseno de la aplicacion Web esta representado por el conjun-to de prototipos que se desarrollaron para guiar la tarea de desarrollo y tambienpor la arquitectura empresarial propuesta. Para revisar los prototipos que sedisenaron para construir la aplicacion por favor referirse al capitulo III, a laseccion de prototipo teorico, en donde se encuentran los bosquejos del prototipode la aplicacion Web. y para revisar la arquitectura empresarial, por favor refe-rirse al capitulo II que cubre toda la arquitectura empresarial, que se desarrollousando el framework Archimate modelando todos sus puntos de vista, para unacomprension y diseno completo del sistema.

2.6. Realizacion

De forma similar al diseno, tambien podemos dividir la tarea de realizacionen dos partes; primero la construccion del hardware, especıficamente del sensorArduino que monitorea el CO2, el esquema de la realizacion del sensor, asıcomo comentarios sobre el codigo realizado se encuentran en el capitulo IIIPrototipo, en la seccion dedicada al prototipo funcional del sistema. Por otrolado el desarrollo de la aplicacion Web y demas componentes de software (librerıaCore y servicios REST), que se detalla tambien el el capitulo III, en la seccionde prototipo funcional, en donde se encuentran un diagrama de componentes dela aplicacion y comentarios a los componentes de software principales.


2.7. Validacion y Generalizacion

El proceso de validacion lo realizaremos con el apoyo de grupos de prue-bas unitarias y pruebas de integracion, el objetivo fundamental de las pruebasunitarias es asegurar el correcto funcionamiento de las interfaces, o del flujo dedatos entre componentes. La metodologıa para la construccion implica observarlos diversos componentes que forman parte del sistema, cada uno de estos com-ponentes debe ser probado en su totalidad, procurando tener al menos un casode uso por funciones de las interfaces programables de SmogChecker, y tambiensus interfaces o comunicaciones con los demas componentes.

Con respecto a las pruebas integrales, seran de tipo incremental, que son lasque buscan probar el sistema como un todo, para ello debemos combinar o unircada uno de los modulos desarrollados y realizar las pruebas progresivamentehasta probar el programa completo. El desarrollo de las pruebas unitarias serealizara a traves de un conjunto de proyectos de pruebas que simularan llama-das a los modulos, introduciran los datos de prueba y recogeran los resultados.Los paquetes de pruebas propuestos se organizarıan de la siguiente manera:

com.SmogChecker.Test.Persistence

com.SmogChecker.Test.Autenticador

com.SmogChecker.Test.Usuario

com.SmogChecker.Test.Lectura

com.SmogChecker.Test.Sensor

com.SmogChecker.Test.AlertaSoftware

com.SmogChecker.Test.Reporteador

2.8. CRONOGRAMA 49

2.8. Cronograma

Figura 2.17: Cronograma


Parte II

Arquitectura Empresarial

51

Capıtulo 3

Empresa

3.1. Introduccion

La dependencia Division de Recursos Fısicos de la Universidad Distrital”Francisco Jose de Caldas” es aquella division que debe responder por la admi-nistracion, planeacion y organizacion de los bienes de la Universidad, ası como dela direccion y control de las actividades y programas conducentes a la adecuadaprestacion de servicios generales que requiera la institucion.

3.2. Mision y Vision

3.2.1. Mision

Responder por la administracion, planeacion, organizacion de los bienes dela Universidad, ası como de la direccion y control de las actividades y progra-mas conducentes a la adecuada prestacion de servicios generales que requiera lainstitucion.

3.2.2. Vision

Liderar procesos de innovacion tecnologica que le permitan responder conla oportunidad que la institucion requiere para ser el apoyo efectivo de susobjetivos.

53

54 CAPITULO 3. EMPRESA

3.3. Organigrama

3.3.1. Organigrama

Figura 3.1: Organigrama Actual

3.3.2. Stakeholders

Como Stakeholders primarios para la dependencia de recursos fısicosidentificamos los siguientes grupos:

- Usuarios: Son todas las dependencias de la Universidad Distrital, en susdistintas sedes, que solicitan los servicios que recursos fısicos proporciona.

- Proveedores: Son aquellas organizaciones o personas que prestan servicios ala dependencia de recursos fisicos.

- Empleados: Es el grupo de personas con contrato laboral con ladependencia que desarrollan los procesos de la misma, organizados segun elorganigrama ya establecido (ver Figura 3.1).

- Entes Gubernamentales y Distritales: Son las organizaciones queejercen control administrativo sobre la dependencia, de acuerdo alordenamiento jurıdico de la universidad.

- Entes y organismos de Control: Son las organizaciones que vigilan laejecucion de las funciones de la dependencia de recursos fısicos, en su calidadde componente de una organizacion publica del ambito distrital.

3.3. ORGANIGRAMA 55

3.3.3. Funciones

Las funciones de la dependencia estan organizadas dentro del modelo deciclo PHVA, las mismas buscan garantizar a traves de su gestion los serviciosrelacionados con administracion de bienes,infraestructura, planta fısica, man-tenimiento, compras, inventarios, aseo y seguridad, requeridos para el optimodesarrollo de las actividades academico-administrativas de la Universidad Dis-trital ”Francisco Jose de Caldas”, estas funciones son:

1. Planear

Analizar los Lineamientos para la elaboracion del Plan Maestro deDesarrollo Fısico.

Proyectar los Lineamientos para la elaboracion del Plan Anual deCompras.

Documentar los lineamientos para la elaboracion del Plan Anual deInventarios, Almacenamiento y Bajas.

Proyectar los Lineamientos para la elaboracion del Plan Anual deConservacion y Mantenimiento de Bienes Muebles e Inmuebles.

2. Hacer

Elaborar el Plan Maestro de Desarrollo Fısico.

Elaborar el Plan Anual de Compras.

Elaborar un documento sobre las necesidades para proyectar el PlanOperativo Administrativo, Fısico y Financiero.

Elaborar el Plan Anual de Inventarios, Almacenamiento y Bajas.

Elaborar el Plan Anual de Conservacion y Mantenimiento de BienesMuebles e Inmuebles.

3. Verificar

Realizar seguimiento al Plan Operativo Administrativo, Fısico y Fi-nanciero.

Realizar la verificacion del Plan Maestro de Desarrollo Fısico, Planesde Accion y Planes de Trabajo.

Revisar las especificaciones Plan Anual de Compras.

Redisenar el Plan Anual de Inventarios, Almacenamiento y Bajas.

Revisar el Plan Anual de Conservacion y Mantenimiento de BienesMuebles e Inmuebles.

Revisar los Procedimientos de Supervision y Control de los Contratosde aseo y vigilancia de la Universidad.


4. Actuar

Realizar la verificacion del Plan Maestro de Desarrollo Fısico, Planesde Accion y Planes de Trabajo.

Ajustar el Plan Anual de Compras.

Ajustar el Plan Anual de Inventarios, Almacenamiento y Bajas.

Ajustar el Plan Anual de Conservacion y Mantenimiento de BienesMuebles e Inmuebles.

Ajustar los Procedimientos de Supervision y control de los Contratosde aseo y vigilancia de la Universidad.

3.4. PROCESOS, PRODUCTOS Y SERVICIOS 57

3.4. Procesos, Productos y Servicios

3.4.1. Procesos

Las actividades, funciones y servicios que realiza la dependencia se enmarcandentro del proceso ”Gestion de infraestructura fısica”, que es parte del macro-proceso ”gestion de recursos”, que a su vez es parte de los procesos de apoyo dela universidad. Este proceso tiene como alcance iniciar con la Planeacion Ope-rativa y ejecucion de los diferentes servicios y finalizar con el servicio prestadoen las distintas modalidades, incluyendo su seguimiento. El proceso tiene comolıder al vicerrector administrativo y financiero y como gestores a los miembrosde la dependencia de recursos fısicos que son el jefe de la division de recursosfısicos. el jefe de la seccion de compras y el almacenista general.

3.4.2. Productos y Servicios

La dependencia de recursos fısicos provee los siguientes servicios a las de-pendencias que los soliciten debidamente:

1. Aseo

2. Carpinterıa

3. Cerrajerıa

4. Electrico

5. Hidraulico (banos)

6. Jardinerıa

7. Obra y Construccion

8. Ornamentacion

9. Pintura

10. Plomerıa

11. Telefonos

12. Transporte

13. Vidrierıa

14. Carga


Capıtulo 4

Lenguaje

4.1. Introduccion

59

60 CAPITULO 4. LENGUAJE

4.2. Archimate

4.2.1. Capa de Negocio

Figura 4.1: Metamodelo Capa de Negocio

El aspecto estructural en la capa de negocio se refiere a la estructura estaticade una organizacion, en terminos de las entidades que conforman la organizaciony sus relaciones. Se distinguen dos tipos de entidades:

Las entidades activas que son los sujetos (por ejemplo, actores empresaria-les o roles comerciales) que realizan funciones como procesos o funcionesempresariales (capacidades). Los actores empresariales pueden ser perso-nas individuales (por ejemplo, clientes o empleados), sino tambien gruposde personas como (Unidades de la organizacion) y recursos que tienen unestatus permanente (o al menos a largo plazo) dentro de las organizacio-nes. Ejemplos tıpicos de estos ultimos son un departamento u unidad denegocio.

Las entidades pasivas (objetos de negocio) que son manipuladas por com-portamientos tales como procesos o funciones. Estas entidades pasivasrepresentan los conceptos importantes en los que el negocio piensa en undominio. Las descripciones arquitectonicas se centran en la estructura, loque significa que las interrelaciones de las entidades dentro de una organi-zacion juegan un papel importante. Para hacer esto explıcito, el conceptode colaboracion de negocio ha sido introducido. Las colaboraciones empre-sariales se han inspirado en colaboraciones como se define en el estandarUML 2.0, aunque las colaboraciones UML se aplican a componentes enla capa de aplicacion. Ademas, el concepto de colaboracion de negocio enArchiMate tiene un fuerte parecido al concepto de comunidadcomo se de-fine en el Lenguaje Empresarial RM-ODP, ası como al concepto de ”puntode interaccion”, definido en Ambar como el lugar donde las interaccionesocurren.

4.2. ARCHIMATE 61

El concepto de interfaces de negocio es presentado para explıcitamente mo-delar lo logico o fısico, de las posiciones o canales donde se puede acceder a losservicios que una funcion ofrece al medio ambiente. Pueden ofrecer el mismoservicio en varios interfaces diferentes; por ejemplo: por correo, por telefono, opor la Internet. En contraste con el modelado de uso, es raro en los negociosactuales reconocer el concepto de interfaz de negocio.


4.2.2. Capa de Aplicacion

El metamodelo de la capa de aplicacion y sus relaciones estan inspirados engran parte en el estandar UML 2.0, por ser un lenguaje dominante y el estandarpara describir aplicaciones de software.

Aplication Interface

Aplication Component

Aplication Colaboration

Aplication Function / Aplication Interaction

Data Object

Aplication Serviceaccede

accedido por realizado por

realiza

activado por / ujo de activa / ujo a

usa

usado por

asignado desde

asignado por

compone

compuesto de

agregado por

agrega

asignado a

Restricción.La Interacción de la Aplicación sólo puede ser asignada por una Colaboración de la Aplicación, no por un Componente de la Aplicación.

accedido por

accede

usado porusado por

usa

usa

asignado desde

Figura 4.2: Metamodelo Capa de Aplicacion

Cada concepto en el lenguaje puede tener relaciones de composicion, agrega-cion y especializacion con conceptos del mismo tipo; Ademas, existen relacionesindirectas que pueden derivarse.

El concepto estructural principal para la capa de aplicacion es el componentede aplicacion. Este concepto se utiliza para modelar cualquier entidad estructu-ral en la capa de aplicacion: no solo componentes de software (reutilizables) quepueden ser parte de una o mas aplicaciones, sino tambien aplicaciones comple-tas de software, sub-aplicaciones o sistemas de informacion. Es muy similar alUML 2.0 sin embargo nuestro concepto de componente modela estrictamente elaspecto estructural de una aplicacion: su comportamiento es modelado por unarelacion explıcita con los conceptos conductuales.

Tambien en la arquitectura de la aplicacion, las interrelaciones de los com-ponentes son un ingrediente esencial. Por lo tanto, tambien introducimos elconcepto de colaboracion de aplicaciones aquı, definido como un colectivo decomponentes de aplicacion que realizan interacciones de aplicaciones.

En el sentido puramente estructural, una interfaz de aplicacion es el canal(logico) a traves del cual se puede acceder a los servicios de un componente. Enun sentido mas amplio (tal como se utiliza en, entre otros, el UML 2.0), unainterfaz de aplicacion define algunas caracterısticas de comportamiento elemen-tales: define el conjunto de operaciones y eventos que se proporcionan por elcomponente, o los que se requieren desde el entorno, describiendo la funcionali-dad de un componente.

4.2. ARCHIMATE 63

Se puede hacer una distincion entre una interfaz proporcionada y una interfazrequerida. El concepto de interfaz de aplicacion se puede utilizar para modelarinterfaces de aplicacion a aplicacion que ofrecen servicios de aplicaciones internasy aplicaciones a interfaces de negocio (y / o interfaces de usuario) que ofrecenservicios de aplicaciones externas.

Tambien en la capa de aplicacion, distinguimos la contraparte pasiva delcomponente, que llamamos objeto de datos. Este concepto se utiliza de la mismamanera que los objetos de datos (o tipos de objetos) en enfoques de modeladode datos bien conocidos, especialmente el concepto de clase.en los diagramas declases de UML. Un objeto de datos puede ser visto como una representacion deun objeto de negocio, como una contrapartida del concepto de representacionen la capa de negocio.

Componente de aplicacion: Un componente de aplicacion se define comouna parte modular, desplegable y reemplazable de un sistema de software queencapsula su comportamiento y datos y los expone a traves de un conjunto deinterfaces. Un componente de aplicacion es una unidad autonoma de funcionali-dad. Como tal, es independientemente desplegable, reutilizable y reemplazable.Un componente de aplicacion realiza una o mas funciones de aplicacion. En-capsula su contenido: su funcionalidad solo es accesible a traves de un conjuntode interfaces de aplicacion. Los componentes de la aplicacion cooperante se co-nectan mediante colaboraciones de aplicaciones. Un componente de aplicacionse puede asignar a una o mas funciones de aplicacion, procesos de negocio ofunciones empresariales. Un componente de aplicacion tiene una o mas interfa-ces de aplicacion, que exponen su funcionalidad. Las interfaces de aplicacion deotros componentes de la aplicacion pueden ser utilizadas por un componente deaplicacion. El nombre de un componente de aplicacion debe ser preferentementeun sustantivo.

Colaboracion de aplicaciones: Una colaboracion de aplicacion se definecomo un agregado de dos o mas componentes de aplicacion que trabajan juntospara realizar un comportamiento colectivo. Una colaboracion de aplicacion espe-cifica que componentes cooperan para realizar alguna tarea. El comportamientocolaborativo, incluyendo, por ejemplo, el patron de comunicacion de estos com-ponentes, es modelado por una interaccion de aplicacion. Una colaboracion deaplicacion es una especializacion de un componente, y agrega dos o mas (quecooperan) componentes de la aplicacion. Una colaboracion de aplicacion es unelemento de estructura activa que se puede asignar a una o mas interaccionesde aplicaciones o interacciones de negocio que modelan el comportamiento aso-ciado. Una colaboracion de aplicacion puede utilizar una interfaz de aplicaciony una colaboracion de aplicacion puede estar compuesta por interfaces de apli-cacion. El nombre de una colaboracion de aplicacion debe ser preferentementeun sustantivo.

Interfaz de aplicacion: Una interfaz de aplicacion se define como un puntode acceso en el que un servicio de aplicacion esta disponible para un usuario uotro componente de aplicacion. Una interfaz de aplicacion especifica como sepuede acceder a la funcionalidad de un componente por parte de otra interfazproporcionada por los componentes) o la funcionalidad que el componente re-


quiere de su entorno (interfaz requerida). Una interfaz de aplicacion expone unservicio de aplicacion al ambiente. El mismo servicio de aplicacion puede estarexpuesto a traves de diferentes interfaces. En cierto sentido, una interfaz deaplicacion especıfica un tipo de contrato que debe cumplir un componente querealiza esta interfaz. Esto puede incluir parametros, protocolos utilizados, pre-y post condiciones y formatos de datos. Una interfaz de aplicacion puede serparte de un componente de aplicacion a traves de la composicion (no mostradaen la notacion estandar), lo que significa que estas interfaces son proporcionadaso requeridas por ese componente y pueden ser utilizadas por otros componen-tes de aplicacion. Una interfaz de aplicacion se puede asignar a servicios deaplicaciones o servicios empresariales, lo que significa que la interfaz exponeServicios al medio ambiente. El nombre de una interfaz de aplicacion debe serpreferentemente un sustantivo.

Objeto de datos: Un objeto de datos se define como un elemento pasivoadecuado para el procesamiento automatizado. Una funcion de aplicacion fun-ciona en un objeto de datos. Un objeto de datos puede ser comunicado a travesde interacciones y utilizado o producido por servicios de aplicacion. Debe seruna pieza de informacion independiente con un significado claro para el negocio,no solo para el nivel de aplicacion. Ejemplos tıpicos de objetos de datos son unregistro de cliente, una base de datos de cliente o un reclamo de seguro. Unobjeto de datos puede ser accedido por una funcion de aplicacion, una interac-cion de aplicacion o un servicio de aplicacion. Un objeto de datos puede realizarun objeto de negocio y puede realizarse mediante un artefacto. Un objeto dedatos puede tener relaciones de asociacion, especializacion, agregacion o com-posicion con otros objetos de datos. El nombre de un objeto de datos debe serpreferentemente un sustantivo.

Conceptos de Comportamiento: El comportamiento en la capa de apli-cacion se puede describir de una manera que es muy similar al comportamientode la capa de negocio. Tambien aquı, hacemos una distincion entre el comporta-miento externo de la aplicacion componentes en terminos de servicios de aplica-cion, y el comportamiento interno de estos componentes; Es decir, funciones deaplicacion que realizan estos servicios. Un servicio de aplicacion es una unidadde funcionalidad visible externamente, proporcionada por uno o mas componen-tes, expuesta a traves de interfaces bien definidas y significativa para el entorno.Los servicios que ofrece una forma de describir explıcitamente la funcionalidadque los componentes comparten entre sı y la funcionalidad que ponen a dispo-sicion del entorno. El concepto encaja bien dentro de los desarrollos actualesen el area de servicios web. La funcionalidad que programa de computadorainteractivo proporciona a traves de una interfaz de usuario tambien se modelautilizando un servicio de aplicacion, expuestos por una interfaz de aplicaciona empresa que representa la interfaz de usuario. Los servicios de aplicacionesinternas se exponen a traves de una interfaz de aplicacion a aplicacion. Unafuncion de aplicacion describe el comportamiento interno de un componente ne-cesario para realizar uno o mas servicios de aplicacion. En analogıa con la capade negocio, un concepto de ”flujo de aplicacion”separado es concebible como lacontrapartida de un proceso de negocio. Tenga en cuenta que el comportamien-

4.2. ARCHIMATE 65

to interno de un componente en la mayorıa de los casos no debe ser modeladocon demasiada Descripcion, porque para la descripcion de este comportamientopronto podrıamos enfrentarnos a problemas detallados de diseno. Una inter-accion de aplicacion es el comportamiento de una colaboracion de dos o mascomponentes de aplicacion. Una interaccion de aplicacion es un comportamien-to externo desde la perspectiva de cada uno de los componentes participantes,pero el comportamiento es interno a la colaboracion en su conjunto.

Servicio de aplicaciones: Un servicio de aplicacion se define como un ser-vicio que expone un comportamiento automatizado. Un servicio de aplicacionexpone la funcionalidad de los componentes a su entorno. Esta funcionalidad seaccede a traves de una o mas interfaces de aplicacion. Un servicio de aplicacionse realiza mediante una o mas funciones de aplicacion que realiza el componente.Puede requerir, usar y producir objetos de datos. Un servicio de aplicacion debeser significativo desde el punto de vista del medio ambiente; Debe proporcionaruna unidad de funcionalidad que, en sı misma, sea util para sus usuarios. Tieneun proposito, que establece esta utilidad para el medio ambiente. Esto significa,por ejemplo, que si este entorno incluye procesos de negocio, los servicios deaplicaciones deben tener relevancia comercial.Un proposito puede estar asocia-do con un servicio de aplicacion. Un servicio de aplicacion puede ser utilizadopor procesos empresariales, funciones empresariales, interacciones comerciales ofunciones de aplicacion. Una funcion de aplicacion puede realizar un servicio deaplicacion. Se puede asignar una interfaz de aplicacion a un servicio de aplica-cion. Un servicio de aplicacion puede acceder a objetos de datos. El nombre deun servicio de aplicacion debe ser un verbo que termina con ando”; Por ejem-plo, ”procesamiento de transacciones”. Tambien, se puede usar un nombre quecontiene explıcitamente la palabra ”servicio”.


4.2.3. Capa de Tecnologıa

El nodo es el concepto principal clave para la capa tecnologica, este conceptocomparte el mismo significado que en UML 2.0 . Es estrictamente usado paramodelos que representan los aspectos estructurales de un sistema; Su comporta-miento es modelado por una relacion explıcita de conceptos conductuales. UnaInterface de infraestructura, es el acceso a los servicios ofrecidos por el nododesde otros nodos o componentes de la capa de aplicacion. Existen dos tipos denodos: dispositivos y Sistema de software, ambos son tomadas de UML2.0. Undispositivo e es el modelo de un recurso fısico, sobre el cual se pueden desplegarartefactos para su ejecucion. Tıpicamente, un nodo consiste un numero de sub-nodos; por ejemplo, un dispositivo tal como un servidor y un sistema de softwarecomo un modelo de un sistema operativo. Las interrelaciones de componentesen la capa de tecnologıa estan principalmente formadas por comunicaciones deinfraestructura . Los modelos de comunicacion es la relacion entre dos o mas no-dos, a traves de estos nodos se puede intercambiar informacion. Las realizacionfısica de las rutas de comunicacion son modeladas con una red y ; un medio decomunicacion entre dos o mas dispositivos .

El cuadro a continuacion, brinda una vision general de los conceptos de laCapa de Tecnologıa con sus definiciones.

4.2. ARCHIMATE 67

Cuadro 4.1: Resumen de los conceptos de capa tecnologicaConcepto Definicion Notacion

Nodo Recurso computacional sobre el cualpueden almacenarse o desplegarseartefactos para su ejecucion

Dispositivo Recurso de hardware sobre el cualpueden almacenarse o desplegarseartefactos para su ejecucion

Red Medio de comunicacion entre dos omas dispositivos.

Ruta de co-municacion

Un enlace entre dos o mas nodos, atraves del cual estos nodos puedenintercambiar datos.

Interfaz deinfraestruc-tura

Un punto de acceso donde los servi-cios de infraestructura ofrecidos porun nodo pueden ser accedidos porotros nodos y componentes de laaplicacion.

Sistema deSoftware

Un entorno de software para tiposespecıficos de componentes y obje-tos que se despliegan en el en formade artefactos.

Funcion deinfraestruc-tura

Un elemento de comportamientoque agrupa el comportamiento de in-fraestructura que puede ser realiza-do por un nodo.

Servicio deinfraestruc-tura

Una unidad de funcionalidad vi-sible externamente, proporcionadapor uno o mas nodos, expuesta atraves de interfaces bien definidas ysignificativa para el entorno.

Aterfacto Una pieza fısica de datos que se uti-liza o se produce en un proceso dedesarrollo de software, o mediante eldespliegue y la operacion de un sis-tema.


4.2.4. Capa Motivacional

Los conceptos de motivacion se utilizan para modelar las motivaciones, orazones, que subyacen en el diseno o cambio de alguna arquitectura empresarial.Estas motivaciones influyen, orientan y limitan el diseno. Es esencial comprenderlos factores, que a menudo son referidos como conductores, que influyen en loselementos motivacionales. Pueden originarse desde dentro o fuera de la empresa.Los conductores internos, tambien llamados preocupaciones, estan asociadoscon las partes interesadas, que pueden ser algun ser humano individual o algungrupo de seres humanos, como un equipo de proyecto, empresa o sociedad. Lasmotivaciones reales estan representadas por objetivos, principios, requisitos ylimitaciones. Los objetivos representan algun resultado deseado - o final - queun interesado quiere lograr.

El cuadro a continuacion, brinda una vision general de los conceptos de laCapa Motivacional con sus definiciones.

Concepto Definicion Notacion

Stakeholder.

El rol de una persona, equipo uorganizacion que representan susintereses o preocupaciones relati-vas al resultado de la arquitectu-ra.

Driver. Algo que crea, motiva y alimentael cambio en una organizacion.

Assessment. La salida de algun analisis dealgun driver.

Goal. Un estado final que un stakehol-der pretende lograr.

Requirement.Una declaracion de necesidad tie-ne que ser realizada por un siste-ma.

Constraint. Una restriccion en la forma enque el sistema es desarrollado.

Principle.

Una propiedad normativa de to-dos los sistemas en un contextodado, o la forma en que se reali-zan.

Cuadro 4.2: Conceptos motivacionales

4.2. ARCHIMATE 69

4.2.5. Capa Migracion

El concepto de comportamiento central de la extension de implementacion ymigracion es el paquete de trabajo, este puede ser similar al concepto de proceso,ya que ambos son un conjunto de tareas a realizar para producir un resultadobien definido, sin embargo un paquete de trabajo es un proceso unico. Un pa-quete de trabajo define claramente las fechas de inicio y finalizacion, ası comoun conjunto claro de metas o resultados. Este puede ser usado para modelar tan-to proyectos, como sub-proyectos, tareas o incluso portafolios de proyectos. Lospaquetes de trabajo producen entregables, que pueden ser de cualquier tipo, porejemplo reportes, artıculos, servicios, software, productos fısicos o incluso resul-tados intangibles como el cambio organizacional. Un entregable tambien puedeser la implementacion de una arquitectura o de parte de ella. Un estadio se de-fine como como un estado relativamente estable de una arquitectura, que existedentro de un periodo limitado de tiempo, este concepto le da soporte a la ideafundamental de TOGAF de que las arquitecturas son descritas por diferentesescenarios a la vez, en cada una de las fases, B, C y D de ADM una arquitecturabase y una arquitectura destino son creadas, describiendo la situacion actual yla situacion futura deseada. En la fase E (Oportunidades y soluciones) se definenlas ası llamadas transiciones arquitecturales, mostrando estados incrementalesentre la arquitectura base y la arquitectura destino. Las transiciones arquitectu-rales son usadas para permitir que paquetes de trabajo individuales y proyectossean agrupados en portafolios administrados y programas, ilustrando el valor denegocio de cada etapa. Un intervalo es un resultado importante de un analisisde intervalos en las fases B, C y D del ADM de TOGAF y conforma una entradaimportante en subsecuente planeacion de implementacion y migracion. El con-cepto intervalo es el que busca relacionar dos estadios, por ejemplo entre la lıneabase y la lınea objetivo o entre dos transiciones arquitecturales subsecuentes, yrepresenta la diferencia entre esos dos estadios.

Figura 4.3: Metamodelo Capa Migracion e Implementacion


Cuadro 4.3: Resumen de Implementacion y Conceptos de MigracionConcepto Definicion Notacion

Work Package Una serie de accionesdisenada para completaruna unica meta globaldentro de un tiempo esp-cificado

Deliverable Un resultado definido conprecision de un paquete detrabajo.

Plateau Un estado relativamenteestable de la arquitectu-ra que existe durante unperıodo limitado de tiem-po.

Gap Resultado de un analisisde diferencias entre dosMesetas.

4.3. ADM

El lenguaje ArchiMate, complementa a TOGAF brindando independenciade vendedor, y se centra en los conceptos, incluyendo representaciones graficasque ayudan a crear consistencia e integracion a traves de las diferentes figurasy vistas de TOGAF.

La estructura del nucleo del lenguaje ArchiMate se corresponde estrecha-mente con las tres Arquitecturas de la TOGAF ADM. Esto se ilustra en laFigura 4.2 visualizando la correspondencia entre las vistas TOGAF y los puntosde vista ArchiMate.

Algunas vistas de TOGAF no concuerdan en el nucleo de ArchiMate. Par-cialmente, esto es porque el alcance de TOGAF es mas amplio y se ocupa tantode estrategias de alto nivel como de aspectos del desarrollo de sistemas, mien-tras el nucleo de ArchiMate esta limitado nivel de abstraccion de la arquitecturaempresarial.

4.3. ADM 71

Figura 4.4: TOGAF vs Archimate


Capıtulo 5

Capa de Negocio

5.1. Introduccion

Un punto de vista en ArchiMate es una seleccion de un subconjunto relevantede los conceptos de ArchiMate (y sus relaciones) y la representacion de la partede una arquitectura que se expresa en diferentes diagramas. Un conjunto detales puntos de vista fue desarrollado basado en la experiencia practica.

Algunos de estos puntos de vista tienen un alcance limitado a una solacapa o aspecto. Ası, los puntos de vista de funcion de negocio y de procesode negocio muestran las dos principales perspectivas sobre el comportamientodel negocio; el punto de vista de organizacion representa la estructura de laempresa en terminos de sus departamentos, roles, etc. Otros puntos de vistavinculan multiples capas o aspectos: el punto de vista de cooperacion de actory producto se relacionan con la empresa a su entorno.

73

74 CAPITULO 5. CAPA DE NEGOCIO

5.2. Organizacion

El punto de vista de la organizacion se enfoca en la organizacion (interna)de una empresa, departamento, una red de empresas u otra entidad organiza-cional. Es posible presentar modelos en bloques de diagramas anidados, perotambien de una manera mas tradicional como graficos. El punto de vista de laorganizacion es muy util para identificar las competencias, la autoridad y lasresponsabilidades de la organizacion.

5.2.1. Descripcion

Cuadro 5.1: Punto de Vista OrganizacionPunto de Vista OrganizacionInteresados Empresa, Arquitectos de procesos y dominio, ge-

rentes, empleados y accionistasAsuntos Identificacion de competencias, autoridad y res-

ponsabilidadesProposito Disenar, decidir, informarCapa de Abstraccion CoherenciaCapas Capa de NegociosAspectos Estructura

5.2.2. Modelo

Figura 5.1: Meta-Modelo Organizacion

5.2. ORGANIZACION 75

5.2.3. Caso de Estudio

El modelo de Organizacion nos muestra los roles principales que interactuanen el sistema que se encontrara localizado en la Universidad Distrital Cra 7No. 40-53, estos roles son: las divisiones de Seguridad Fısica, Recursos Fısicosy Recursos Humanos, las cuales en colaboracion buscan brindar las labores deComite Paritario de Salud Ocupacional (COPASO).

5.2.4. Modelo

Figura 5.2: Modelo Organizacion


5.3. Cooperacion de Actor

Se centra en las relaciones de los actores con cada uno de los entornos. Unejemplo comun de esto es el “diagrama de Contexto” el cual pone a la organi-zacion en su entorno, que consiste en entes externos como clientes, proveedoresy otros asociados al mismo. Es muy util determinar las dependencias y cola-boraciones externas que muestran la cadena de valor o la red de actores queoperan.

Otro importante uso del punto de vista de Cooperacion de Actor es mos-trar cual es el numero de actores operando en el negocio y la aplicacion decomponentes que conjuntamente realizan un proceso de negocio.

5.3.1. Descripcion

Cuadro 5.2: Descripcion Punto de Vista Cooperacion de ActorPunto de Vista Cooperacion de ActorStakeholders Empresa, procesos y arquitectos de dominioAsunto Relaciones de los actores con su entornoProposito Diseno, decision, informacionNivel de Abstraccion DetalleCapa Capa de NegocioAspectos Estructura, comportamiento

5.3.2. Modelo

Figura 5.3: Modelo Cooperacion de Actor

5.3. COOPERACION DE ACTOR 77


El modelo de Cooperacion de Actor presenta los dos (2) principales serviciosa los que podra acceder el Comite Paritario de Salud Ocupacional (COPASO)por medio de un portal web “Smog Check” estos son un servicio de administra-cion para la gestion y monitorizacion de los sensores, usuarios y sus exposiciones.Tambien un servicio de alertas, las cuales buscan notificar a los interesados cuan-do los niveles de monoxido de carbono esten en niveles no recomendables para lasalud. Estas alertas se pueden dar por niveles altos o por una larga permanenciaen presencia de monoxido de carbono.

5.3.4. Modelo

Figura 5.4: Modelo Cooperacion de Actor


5.4. Funcion de Negocio

El punto de vista de funcion de negocio muestra las funciones de negocioprincipales de una organizacion y sus relaciones en terminos de los flujos deinformacion, valor o de bienes entre ellos. Las funciones de negocio se utilizanpara representar los aspectos mas estables de una empresa en cuanto a las acti-vidades primarias que realiza, independientemente de cambios organizacionaleso desarrollos tecnologicos. Por lo tanto, la arquitectura de funcion de negociosde las empresas que operan en el mismo mercado a menudo exhiben semejanzascercanas. El punto de vista de la funcion de negocio ası ofrece una vision de altonivel en las operaciones generales de la empresa, y puede utilizarse para iden-tificar las competencias necesarias, o para estructurar una organizacion segunsus actividades principales.

5.4.1. Descripcion

Cuadro 5.3: Descripcion Punto de Vista Funcion de NegocioPunto de Vista Funcion de NegocioStakeholders Arquitectos de la empresa, proceso y dominioPreocupaciones Identificacion de Competencias, identificacion de

actividades principales y reduccion de compleji-dad

Proposito DisenarNivel de Abstraccion CoherenciaCapa Capa de NegocioAspectos Comportamiento, estructura

5.4.2. Modelo

Figura 5.5: Modelo punto de vista funcion de negocio

5.4. FUNCION DE NEGOCIO 79


El modelo de Funcion de Negocio no da una perspectiva de las funcionesque puede realizar cada rol del sistema. El rol de seguridad fısica el cual usa demanera directa las mediciones del sistema cuenta con funciones como: autenti-cacion, consulta de los niveles de monoxido de carbono en su respectivo sitioasociado. Los roles pertenecientes al Comite Paritario de Salud Ocupacional(COPASO) cuentan con funciones globales de administracion y segimiento.

5.4.4. Modelo

Figura 5.6: Modelo Funcion de Negocio


5.5. Proceso de Negocio

El punto de vista del proceso de negocio se utiliza para mostrar la estructuray composicion de alto nivel de uno o mas procesos de negocio. Junto a los propiosprocesos, este punto de vista contiene conceptos directamente relacionados, talescomo:

Los servicios que un proceso de negocio ofrece al mundo exterior, mos-trando como un proceso Contribuye a la realizacion de los productos dela empresa

La asignacion de los procesos de negocio a las funciones, lo que da unaidea de las responsabilidades de los actores asociados

La informacion utilizada por el proceso de negocio

Cada uno de estos puede ser considerado como una ”sub-vista”de la vistadel proceso empresarial.

5.5.1. Descripcion

Cuadro 5.4: Descripcion Punto de Vista Proceso de NegocioPunto de Vista Proceso de NegocioInteresados Arquitectos de procesos y dominio, gerentes ope-

racionalesPreocupaciones Estructura de los procesos de negocio, consisten-

cia e integridad, responsabilidadesProposito DisenoNivel de abstraccion DetalleCapa Capa empresarialAspectos Comportamiento

5.5. PROCESO DE NEGOCIO 81

5.5.2. Modelo

Figura 5.7: Modelo punto de Vista Proceso de Negocio



El modelo de procesos de negocio nos muestra como el Comite Paritario deSalud Ocupacional (COPASO) busca como funcion principal la prevencion deenfermedades por Inhalacion de CO2 a traves del sistema.

5.5.4. Modelo

Figura 5.8: Modelo Proceso de Negocio

5.6. COOPERACION DE PROCESO DE NEGOCIO 83

5.6. Cooperacion de Proceso de Negocio

El punto de vista de Cooperacion en Procesos de Negocios se utiliza paramostrar las relaciones de uno o mas procesos de negocio entre sı y / o con suentorno. Puede utilizarse tanto para crear un diseno de alto nivel de procesosempresariales dentro de su contexto como para proporcionar un gestor opera-tivo responsable de uno o mas de dichos procesos con informacion sobre susdependencias.

Aspectos importantes de la cooperacion en los procesos de negocio son:

Relaciones causales entre los principales procesos de negocio de la empresa.

Mapeo de procesos de negocio en funciones de negocio.

Realizacion de servicios por procesos de negocio.

Uso de datos compartidos.

Cada uno de ellos puede considerarse como una ”sub-vista”de la vision dela cooperacion de procesos empresariales.

5.6.1. Descripcion

Cuadro 5.5: Descripcion Punto de Vista Cooperacion de Proceso de NegocioPunto de Vista Cooperacion de Proceso de NegocioSkateholders Arquitectos de procesos y dominios, gerentes ope-

racionales.Preocupaciones Dependencias entre procesos de negocio, consis-

tencia e integridad, responsabilidades.Proposito Diseno, decisiones.Nivel de abstraccion CoherenciaCapa Capa de negocio, capa de aplicacionAspectos Comportamiento


5.6.2. Modelo

Figura 5.9: Modelo punto de vista cooperacion de proceso de negocio

5.6. COOPERACION DE PROCESO DE NEGOCIO 85


El modelo de procesos de negocio nos muestra como el Comite Paritario deSalud Ocupacional (COPASO) busca como funcion principal la prevencion deenfermedades por Inhalacion de CO2 a traves del sistema por medio del portalSmogChecker brindando funcionalidad de alertas para los casos de altos nivelesde CO2.

5.6.4. Modelo

Figura 5.10: Modelo de Cooperacion de Proceso de Negocio


5.7. Producto

El punto de vista del producto representa el valor que los productos ofrecena los clientes u otras partes externas involucradas y muestra la composicion deuno o mas productos en terminos de la constitucion de servicios (Aplicaciones onegocios), y la asociacion de contratos u otros acuerdos, esto tambien puede serusado para mostrar las interfaces (canales) a traves de los cuales este producto esofrecido, y los eventos asociados con el producto. Un punto de vista del productoes tıpicamente usado en desarrollo de productos para disenar un producto porcomposicion existente de servicios o por identificacion de que nuevos servicioshan sido creados por esos productos, dando los valores que un cliente espera deel. Esto puede entonces servir como entrada para procesos de arquitectura denegocios y otros que necesitan para disenar los procesos de TIC y realizar esosproductos.

5.7.1. Descripcion

Cuadro 5.6: Descripcion Punto de Vista de ProductoPunto de Vista ProductoSkateholders Desarrolladores de producto, gerentes de produc-

to, arquitectos de procesos y de dominioPreocupaciones Desarrollo de productos, valor ofrecido por los

productos de la empresaProposito Disenar, decidirNivel de abstraccion CoherenciaCapa Capa empresarial, capa de aplicacionAspectos Comportamiento, informacion

5.7. PRODUCTO 87

5.7.2. Modelo

Figura 5.11: Modelo punto de vista producto



El modelo del punto de vista de producto, nos representa el sistema “Smog-Checker” con sus servicios de administracion y sistema de alertas. El cual consu conjunto de caracterısticas brinda valores agregados de trazabilidad y segui-miento personalizado al llevar un control independiente por cada usuario.

5.7.4. Modelo

Figura 5.12: Modelo de Producto

Capıtulo 6

Capa de Aplicacion

6.1. Introduccion

El punto de vista de comportamiento, cooperacion y estructura de aplica-cion contiene las aplicaciones y componentes, y sus relaciones mutuas; el puntode vista de uso de aplicacion se refiere a aplicaciones para su uso, por ejemplo,procesos de negocio.

Ademas, el punto de vista de la aplicacion trata acerca de las aplicaciones desoftware que soportan los componentes del negocio con servicios de aplicaciones,componentes de aplicacion reusables, e interfaces de comunicacion para estoscomponentes.

89

90 CAPITULO 6. CAPA DE APLICACION

6.2. Uso de Aplicacion

El punto de vista de uso de la aplicacion describe como las aplicaciones sonusadas para soportar uno o mas procesos de negocio, y como ellos son usadospor otras aplicaciones. Puede ser usado en el diseno de una aplicacion paradescribir los servicios disponibles. Incluso, desde que el punto de vista identificalas dependencias de procesos de negocio en las aplicaciones, este puede ser utilpara responsables de la administracion operativa de esos procesos.

6.2.1. Descripcion

Cuadro 6.1: Descripcion Punto de Vista Uso de AplicacionPunto de Vista Uso de AplicacionInteresados Empresa, Procesos, Arquitectos de aplicacion y

GerentesAsuntos Consistencia y completitud, reduccion de la com-

plejidadProposito Disenar, DecidirCapa de Abstraccion CoherenciaCapas Capa de Negocios, Capa AplicacionAspectos Comportamiento, Estructura

6.2. USO DE APLICACION 91

6.2.2. Modelo

Figura 6.1: Modelo Uso de Aplicacion



El punto de vista de Uso de Aplicacion muestra como se realiza por mediode servicios el comportamiento de la aplicacion. La prevencion de enfermedadespor Inhalacion de CO2 se realiza por medio de servicios de alerta. El manejo deusuarios por medio de servicios de autenticacion y administracion de usuarios.Finalmente los reportes se realizan por medio de los servicios de administracionde usuarios y de sensores.

6.2.4. Modelo

Figura 6.2: Modelo Uso de Aplicacion

6.3. COMPORTAMIENTO DE APLICACION 93

6.3. Comportamiento de Aplicacion

El punto de vista de comportamiento de la aplicacion describe el compor-tamiento interno de una aplicacion, por ejemplo como esta realiza uno o masservicios de aplicacion. Este punto de vista es util para disenar los comporta-mientos principales de la aplicacion, o en identificar superposiciones funcionalesentre diferentes aplicaciones.

6.3.1. Descripcion

Cuadro 6.2: Descripcion Punto de Vista Comportamiento de AplicacionPunto de Vista Comportamiento de AplicacionInteresados Empresa, Procesos, Aplicacion y Arquitectos del

DominioAsuntos Estructura, relaciones y dependencias entre apli-

caciones, consistencia y completitud, reduccion dela complejidad

Proposito DisenarCapa de Abstraccion Coherencia, DetallesCapas Capa AplicacionAspectos Informacion, Comportamiento, Estructura

6.3.2. Modelo

Figura 6.3: Modelo Comportamiento de Aplicacion



En el modelo de comportamiento de la aplicacion mostramos de formaexplıcita las relaciones entre los componentes del sistema y las respectivas fun-ciones del proceso, identificamos en el diagrama 5 componentes principales deSmogChecker, que son el componente de usuario, que serıa el que soporta todaslas funciones de la administracion de usuarios de la aplicacion, el componentesensor que se encarga de la gestion de los datos obtenidos de los sensores fısicos,el componente de alerta que gestiona las notificaciones para usuarios y senso-res, el componente de lectura que gestiona el historial de registros historicosy consolidados tomados de los sensores y finalmente el componente reporta-dor que tomando funcionalidades de los componentes usuario y sensor permitela generacion y visualizacion de los reportes que estaran disponibles para losusuarios.

6.3.4. Modelo

Figura 6.4: Modelo Comportamiento de Aplicacion

6.4. COOPERACION DE APLICACION 95

6.4. Cooperacion de Aplicacion

El punto de vista de cooperacion de la aplicacion describe la relacion entrecomponentes de la aplicacion, en terminos de los flujos de informacion entreellos, o en terminos de los servicios que ellos ofrecen y usan. Este punto de vistaes tıpicamente usado para crear una vista general del panorama de la aplica-cion de una organizacion. Este punto de vista es tambien usado para expresarla cooperacion interna o la orquestacion de servicios que unidos soportan laejecucion de un proceso de negocio.

6.4.1. Descripcion

Cuadro 6.3: Descripcion Punto de Vista Cooperacion de AplicacionPunto de Vista Cooperacion de AplicacionInteresados Empresa, Procesos, Aplicacion y Arquitectos del

DominioAsuntos Relaciones y dependencias entre aplicaciones, or-

questacion/coreografia de servicios, consistenciay completitud, reducion de complejidad

Proposito DisenarCapa de Abstraccion Coherencia, DetallesCapas Capa AplicacionAspectos Comportamiento, Estructura

6.4.2. Modelo

Figura 6.5: Modelo Cooperacion de Aplicacion



En este modelo hemos organizado de forma logica los componentes principa-les de SmogChecker, para ello hemos usado el concepto de organizacion de backy front de la aplicacion, en el modelo vemos como los componentes que recibeninteraccion del usuario (Autenticador, Reporteador y Alerta) quedan agrupadosjuntos dentro de la capa de Front y los componentes que brindan soporte a esoscomponentes (la base de datos, Usuario, Sensor y Lectura) y que interactuancon la informacion generada por el hardware quedan agrupados en la capa deBack.

6.4.4. Modelo

Figura 6.6: Modelo Cooperacion de Aplicacion

6.5. ESTRUCTURA DE APLICACION 97

6.5. Estructura de Aplicacion

El punto de vista de estructura de la aplicacion muestra la estructura deuno o mas de una o mas aplicaciones o componentes. Este punto de vista es utilen el diseno o en la comprension de la estructura principal de las aplicaciones ocomponentes y los datos asociados, por ejemplo para desglosar la estructura deun sistema bajo en construccion o para identificar componentes de aplicacionlegados que son adecuados para migracion o integracion.

6.5.1. Descripcion

Cuadro 6.4: Descripcion Punto de Vista Estructura de AplicacionPunto de Vista Estructura de AplicacionInteresados Empresa, Procesos, Aplicacion y Arquitectos del

DominioAsuntos Relaciones y dependencias entre aplicaciones, or-

questacion/coreografia de servicios, consistenciay completitud, reducion de complejidad

Proposito DisenarCapa de Abstraccion DetallesCapas Capa AplicacionAspectos Informacion, Estructura

6.5.2. Modelo

Figura 6.7: Modelo Estructura de Aplicacion



Este modelo muestra la arquitectura logica de la aplicacion de alto nivel,representada por los componentes de software que intervienen y las interfacesde comunicacion que se proponen para la comunicacion entre ellos, Tomo el mo-delo gira en torno a SmogChecker y de allı parten 6 interfaces que conformarıanla API de SmogChecker, que son IAcceso, IPersona, IDispositivo, IConsultas,IDiagnostico e INotificaciones, que modelan los comportamientos de los com-ponentes que podrıan interactuar con SmogChecker, tanto los representados enel modelo como otros futuros que quieran agregarse, en seguida de cada in-terfaz vemos los componentes que implementarıan cada una de las interfacespropuestas.

6.5.4. Modelo

Figura 6.8: Modelo Estructura de Aplicacion

Capıtulo 7

Capa de Infraestructura

7.1. Introduccion

El nodo es el concepto principal clave para la capa tecnologica, este conceptocomparte el mismo significado que en UML 2.0 . Es estrictamente usado paramodelos que representan los aspectos estructurales de un sistema; Su comporta-miento es modelado por una relacion explıcita de conceptos conductuales. Unainterface de infraestructura, es el acceso a los servicios ofrecidos por el nododesde otros nodos o componentes de la capa de aplicacion. Existen dos tipos denodos: dispositivos y Sistema de software, ambos son tomadas de UML2.0. Undispositivo e es el modelo de un recurso fısico, sobre el cual se pueden desplegarartefactos para su ejecucion. Tıpicamente, un nodo consiste un numero de sub-nodos; por ejemplo, un dispositivo tal como un servidor y un sistema de softwarecomo un modelo de un sistema operativo. Las interrelaciones de componentesen la capa de tecnologıa estan principalmente formadas por comunicaciones deinfraestructura . Los modelos de comunicacion es la relacion entre dos o mas no-dos, a traves de estos nodos se puede intercambiar informacion. Las realizacionfısica de las rutas de comunicacion son modeladas con una red y ; un medio decomunicacion entre dos o mas dispositivos.

99

100 CAPITULO 7. CAPA DE INFRAESTRUCTURA

7.2. Infraestructura

7.2.1. Modelo

El punto de vista de Infraestructura contiene el software y los elementos deinsfraestrcutura que soportan a la capa de aplicacion, como dispositivos fısicos,redes o sistemas de software (por ejemplo sistemas operativos, bases de datos ymiddleware).

7.2.2. Descripcion

Cuadro 7.1: Descripcion Punto de Vista InfraestructuraPunto de Vista InfraestructuraInteresados Arquitectos de infraestructura, administradores

operativosAsuntos Estabilidad, seguridad, dependencias, costo de la

infraestructuraProposito DisenoCapa de Abstraccion DetallesCapas Capa de tecnologıaAspectos Comportamiento, estructura

7.2. INFRAESTRUCTURA 101


En este modelo vemos los principales elementos de la infraestructura deSmogChecker, incluyendo las interfaces del circuito, el sensor fısico de CO2, elmicrocontrolador, la red por la que se transmiten los datos del sensor, el servidorde la aplicacion donde residen los servicios REST y la aplicacion web en dondese visualizan los datos.

Figura 7.1: Modelo Infraestructura


7.3. Uso de Infraestructura

7.3.1. Modelo

El punto de vista de uso de la infraestructura muestra como las aplicacionesson soportadas por el software y la infraestructura de hardware: los servicios deinfraestructura son entregados por los dispositivos; sistemas de software y redesson provistos a las aplicaciones. Este punto de vista juega un importante rolen el analisis del desempeno y la escalabilidad, desde que relata la infraestruc-tura fısica al mundo logico de las aplicaciones. Es muy util para determinar eldesempeno y los requerimientos de calidad para la infraestructura basados enla demanda de las varias aplicaciones que lo usan.

7.3.2. Descripcion

Cuadro 7.2: Descripcion Punto de Vista Uso de InfraestructuraPunto de Vista InfraestructuraInteresados Aplicacion, arquitectos de infraestructura, admi-

nistradores operativosAsuntos Dependencias, desempeno, escalabilidadProposito DisenoCapa de Abstraccion CoherenciaCapas Capas de aplicacion y tecnologıaAspectos Comportamiento, estructura

7.3. USO DE INFRAESTRUCTURA 103


En este modelo vemos los principales elementos de la infraestructura deSmogChecker y la manera como estos elementos le dan soporte a la aplicacion,por ejemplo vemos los componentes de SmogChecker dentro de un servidor endonde se realiza su despliegue y vemos como de este servidor la aplicacion usaun servidor de aplicaciones y una base de datos MongoDB.

Figura 7.2: Modelo Uso de Infraestructura


7.4. Implementacion y Despliegue

7.4.1. Modelo

El punto de vista de Implementacion y despliegue muestra como una o masaplicaciones son desplegadas en la infraestructura. Esto comprime el mapeo deaplicaciones logicas y componentes en los artefactos fısicos, como EnterpriseJava Beans, y el mapeo de la informacion usada por estas aplicaciones y compo-nentes en la infraestructura de almacenamiento subyacente, por ejemplo tablasde bases de datos u otros archivos. Las vista de despliegue juegan un impor-tante rol en el analisis del desempeno y la escalabilidad, dado que relatan lainfraestructura fısica al mundo logico de las aplicaciones. En analisis de seguri-dad y riesgos, los puntos de vista de despliegue son usados para identificar, porejemplo, dependencias crıticas y riesgos.

7.4.2. Descripcion

Cuadro 7.3: Descripcion Punto de Vista de Implementacion y DesplieguePunto de Vista InfraestructuraInteresados Arquitectos de aplicacion e infraestructura, admi-

nistradores operativosAsuntos Dependencias, seguridad y riesgosProposito DisenoCapa de Abstraccion CoherenciaCapas Capa de tecnologıa, Capa de aplicacionAspectos Informacion, comportamiento, estructura

7.4. IMPLEMENTACION Y DESPLIEGUE 105


En este modelo vemos como la aplicacion SmogChecker se despliega en lainfraestructura fısica, que serıa el servidor de la aplicacion donde residen losservicios REST y la aplicacion web en donde se visualizan los datos.

Figura 7.3: Modelo de Implementacion y Despliegue


7.5. Estructura de la informacion

7.5.1. Modelo

El punto de vista de estructura de la informacion es comparable a los modelosde informacion tradicionales creados en el desarrollo de la mayorıa de sistemas deinformacion. Esto muestra la estructura de la informacion usada en la empresa oen un proceso de negocio especıfico o aplicacion, en terminos de tipos de datos oestructuras de clases (orientadas a objetos). De hecho, esto puede mostrar comola informacion del nivel de negocio es representada al nivel de la aplicacion en laforma de estructuras de datos usados aquı, y como estos son entonces mapeadosen la infraestructura subyacente, por ejemplo en esquema de base de datos.

7.5.2. Descripcion

Cuadro 7.4: Descripcion Punto de Vista Estructura de la informacionPunto de Vista Estructura de la informacionInteresados Arquitectos de informacion y dominioAsuntos estructura y dependencias de la informacion usa-

da, consistencia y completitudProposito DisenoCapa de Abstraccion DetallesCapas Capa de negocio, de aplicacion y de tecnologıaAspectos Informacion

7.5. ESTRUCTURA DE LA INFORMACION 107


En este modelo vemos los significados de negocio (Informar niveles peligrososy seguimiento), los objetos de negocio (medicion, seguimiento, alertas y repor-tes) y las entidades persistentes (Sensor, Usuario, Lectura e Historico) que enconjunto conforman el modelo de datos de SmogChecker.

Figura 7.4: Modelo de estructura de la informacion


7.6. Realizacion del Servicio

7.6.1. Modelo

El punto de vista de realizacion de servicios es usado para mostrar comouno o mas servicios de negocio son realizados por los procesos subyacentes (y aveces por componentes de aplicacion). Esto forma es puente entre el punto devista del producto de negocio y la vista del proceso de negocio, Este provee una”vista desde afuera” en uno o mas procesos de negocio.

7.6.2. Descripcion

Cuadro 7.5: Descripcion Punto de vista Realizacion del ServicioPunto de Vista Realizacion del ServicioInteresados Arquitectos de proceso y dominio, administrado-

res de producto y operacionalesAsuntos Procesos de valor anadido al negocio, consistencia

y completitud, responsabilidadesProposito Diseno, desicionCapa de Abstraccion CoherenciaCapas Capa de aplicacionAspectos Comportamiento, estructura, informacion

7.6. REALIZACION DEL SERVICIO 109


En este modelo vemos los objetos y procesos de negocio relacionados con laprevencion de enfermedades y reportes relacionados con los servicios, compo-nentes y estructuras de datos de SmogChecker.

Figura 7.5: Modelo Realizacion del Servicio


7.7. Capas

7.7.1. Modelo

El punto de vista de capas muestra varias capas y aspectos de una arquitec-tura empresarial en un diagrama. Hay dos categorıas de capas, a saber, capasdedicadas y capas de servicio. las capas son el resultado del uso de la relacionde ”agrupacion” para una particion natural de todo un conjunto de objetosy relaciones que pertenecen a un modelo. La infraestructura, la aplicacion, elproceso y las capas de actores y roles pertenecen a la primera categorıa. Elprincipio estructural detras de un punto de vista completamente estratificadoes que cada capa dedicada expone, mediante la relacion de realizacion, una capade servicios, que son mas usados por la siguiente capa. Ası, podemos separarfacilmente la estructura interna y la organizacion de una capa dedicada desdesu comportamiento observable externamente expresado como la capa de servicioque la capa dedicada se da cuenta. Sin embargo, este ejemplo no pretende serprescriptivo. El objetivo principal del punto de vista capas es proporcionar unavision general en un diagrama. Ademas, este punto de vista puede utilizarsecomo apoyo al impacto del analisis del cambio y analisis de rendimiento o paraextender la cartera de servicios.

7.7.2. Descripcion

Cuadro 7.6: Descripcion Punto de Vista de CapasPunto de Vista de CapasInteresados Arquitectos empresariales, de proceso, de aplica-

cion, de infraestructura y de dominio.Asuntos Consistencia, reduccion de la complejidad, impac-

to del cambio, flexibilidadProposito Disenar, decidir e informarCapa de Abstraccion Vision de conjuntoCapas Capa de negocio, de aplicacion y de tecnologıaAspectos Informacion, comportamiento, estructura

7.7. CAPAS 111


En este modelo vemos una vista general de todas las capas de negocio,aplicacion e infraestructura que conforman en su conjunto la arquitectura deArchimate hasta este punto, se destaca la manera como estas capas se relacionany como las capas inferiores van dando soporte a las capas superiores.

Figura 7.6: Modelo de Capas


Capıtulo 8

Capa de Motivacion

8.1. Introduccion

Los conceptos de motivacion se utilizan para modelar las motivaciones, o ra-zones, que subyacen en el diseno o cambio de alguna arquitectura empresarial.Estas motivaciones influyen, orientan y limitan el diseno. Es esencial comprenderlos factores, a menudo referidos como conductores, que influyen en los elemen-tos motivacionales. Pueden originarse desde dentro o fuera de la empresa. Losconductores internos, tambien llamados preocupaciones, estan asociados con laspartes interesadas, que pueden ser algun ser humano individual o algun grupode seres humanos, como un equipo de proyecto, empresa o sociedad. Ejemplosde estos factores internos son la satisfaccion del cliente, el cumplimiento de lalegislacion o la rentabilidad. Es comun que las empresas realicen una evaluacionde estos factores.

113

114 CAPITULO 8. CAPA DE MOTIVACION

8.2. Stakeholder

El punto de vista de las partes interesadas permite al analista modelar laspartes interesadas, los impulsores internos y externos del cambio y las evalua-ciones (en terminos de fortalezas, debilidades, oportunidades y amenazas) deestos controladores. Ademas, se pueden describir los vınculos con los objetivosiniciales (de alto nivel) que abordan estas preocupaciones y evaluaciones. Estosobjetivos forman la base para el proceso de ingenierıa de requisitos, incluyendorefinamiento de objetivos, contribucion y analisis de conflictos, y la derivacionde requisitos que realicen los objetivos.

8.2.1. Descripcion

Cuadro 8.1: Descripcion Punto de Vista de Partes InteresadasPunto de Vista de Partes InteresadasInteresados Partes interesadas, administradores de negocio,

arquitectos empresariales, analistas de negocio,administradores de requerimientos.

Asuntos Arquitectura de estrategia y mision, motivacionProposito Disenar, decidir e informarCapa de Abstraccion Coherencia, detallesCapas Capa de negocio, de aplicacion y de tecnologıaAspectos Motivacion

8.2. STAKEHOLDER 115


En este modelo vemos la meta motivacional, que es alerta sobre los peligrosde la exposicion al CO2 y como los interesados y las tareas contribuyen a realizaresa meta.

Figura 8.1: Modelo de Partes Interesadas


8.3. Realizacion de Objetivos

El punto de vista de la realizacion de metas permite a un disenador modelarel refinamiento de metas (de alto nivel) en metas mas concretas y el refina-miento de objetivos concretos en requisitos o restricciones que describen laspropiedades que se necesitan para realizar las metas. El refinamiento de metasen sub-objetivos se modela utilizando la relacion de agregacion. El refinamientode metas en requisitos se modela utilizando la relacion de realizacion. Ademas,los principios pueden ser modelados que guıan el refinamiento de objetivos enrequisitos.

8.3.1. Descripcion

Cuadro 8.2: Descripcion Punto de Vista de Realizacion de ObjetivosPunto de Vista de Realizacion de ObjetivosInteresados Partes interesadas, administradores de negocio,


Asuntos Mision arquitectural, estrategia y tacticas, moti-vacion

Proposito Disenar, decidirCapa de Abstraccion Vision de conjuntoCapas Capa de negocio, de aplicacion y de tecnologıaAspectos Motivacion

8.3. REALIZACION DE OBJETIVOS 117


En este modelo vemos la meta motivacional, que es alerta sobre los peligrosde la exposicion al CO2, los principios que esa meta busca satisfacer y los re-querimientos y restricciones que se deben tener en cuenta para cumplir la meta,siguiendo los principios.

Figura 8.2: Modelo de Realizacion de Objetivos


8.4. Contribucion de Objetivos

El punto de vista de la contribucion de objetivos permite a un disenadoro analista modelar las relaciones de influencia entre objetivos y requisitos. Lasvistas resultantes pueden usarse para analizar el impacto que las metas tienenentre sı o para detectar conflictos entre los objetivos de las partes interesadas.Tıpicamente, este punto de vista puede ser utilizado despues de que los objetivosse hayan refinado hasta cierto punto en subobjetivos y, posiblemente, en requi-sitos. Por lo tanto, las relaciones de agregacion y realizacion tambien puedenmostrarse en este punto de vista..

8.4.1. Descripcion

Cuadro 8.3: Descripcion Punto de Vista de Contribucion de ObjetivosPunto de Vista de Contribucion de ObjetivosInteresados Partes interesadas, administradores de negocio,



Proposito Disenar, decidirCapa de Abstraccion Coherencia, detallesCapas Capa de negocio, de aplicacion y de tecnologıaAspectos Motivacion

8.4. CONTRIBUCION DE OBJETIVOS 119


En este modelo vemos como el objetivo general para el sistema es satisfechogracias a la contribucion de otros objetivos mas pequenos, como son socializarel proceso, establecer el COPASO y hacer rotaciones del personal. Estos obje-tivos adicionales tienen siempre en cuenta las restricciones y requerimientos delsistema.

Figura 8.3: Modelo de Contribucion de Objetivos


8.5. Principios

El punto de vista de principios permite al analista o disenador modelar losprincipios que son relevantes para el problema de diseno en cuestion, incluyendolos objetivos que motivan estos principios. Ademas, las relaciones entre los prin-cipios y sus objetivos pueden ser modelados. Por ejemplo, los principios puedeninfluirse mutuamente de forma positiva o negativa.

8.5.1. Descripcion

Cuadro 8.4: Descripcion Punto de Vista de PrincipiosPunto de Vista de PrincipiosInteresados Partes interesadas, administradores de negocio,



Proposito Disenar, decidir e informarCapa de Abstraccion Coherencia, detallesCapas Capa de negocio, de aplicacion y de tecnologıaAspectos Motivacion

8.5. PRINCIPIOS 121


En este modelo vemos la meta motivacional, que es alerta sobre los peligrosde la exposicion al CO2 y como se relaciona esta meta con los principios queconduciran a cumplir la meta.

Figura 8.4: Modelo de Principios


8.6. Realizacion de Requerimientos

El punto de vista de la realizacion de los requisitos permite al disenadormodelar la realizacion de requerimientos por los elementos centrales, tales comolos actores empresariales, los servicios empresariales, los procesos empresariales,los servicios de aplicacion, los componentes de la aplicacion, etc. Tıpicamente, losrequisitos resultan del punto de vista del refinamiento de objetivos. Ademas, estepunto de vista puede usarse para refinar requisitos en requisitos mas detallados.La relacion de agregacion se utiliza para este proposito.

8.6.1. Descripcion

Cuadro 8.5: Descripcion Punto de Vista de Realizacion de RequerimientosPunto de Vista de Realizacion de RequerimientosInteresados Arquitectos empresariales, analistas de negocio,

administradores de requerimientos.Asuntos Mision arquitectural, estrategia y tacticas, moti-

vacionProposito Disenar, decidir e informarCapa de Abstraccion Coherencia, detallesCapas Capa de negocio, de aplicacion y de tecnologıaAspectos Motivacion

8.6. REALIZACION DE REQUERIMIENTOS 123


En este modelo vemos la meta motivacional, que es alerta sobre los peligrosde la exposicion al CO2, los requerimientos que al implementarse llevaran alcumplimiento de la meta la relacion de estos requerimientos con los servicios ycolaboraciones de aplicacion que son el servicio del sensor de CO2 y la aplicacionSmogChecker, respectivamente.

Figura 8.5: Modelo de Realizacion de Requerimientos


8.7. Motivacional

El punto de vista motivacional permite al disenador o analista modelar el as-pecto de la motivacion, sin centrarse en ciertos elementos dentro de este aspecto.Por ejemplo, este punto de vista puede utilizarse para presentar un panoramacompleto o parcial del aspecto de la motivacion relacionando a los interesadosdirectos, sus objetivos principales, los principios que se aplican y los principalesrequisitos de servicios, procesos, aplicaciones y objetos.

8.7.1. Descripcion

Cuadro 8.6: Descripcion Punto de Vista MotivacionalPunto de Vista MotivacionalInteresados Arquitectos empresariales, analistas de negocio,

administradores de requerimientos.Asuntos Mision arquitectural, estrategia y tacticas, moti-

vacionProposito Disenar, decidir e informarCapa de Abstraccion Vision de conjunto, coherencia, detallesCapas Capa de negocio, de aplicacion y de tecnologıaAspectos Motivacion

8.7. MOTIVACIONAL 125


En este modelo vemos una vista general de todos los elementos de la capamotivacional y como estos elementos, identificados previamente en los otrosmodelos, se relacionan.

Figura 8.6: Modelo Motivacional


Capıtulo 9

Capa Proyecto

9.1. Introduccion

El concepto de comportamiento central de la extension de implementacion ymigracion es el paquete de trabajo, este puede ser similar al concepto de proceso,ya que ambos son un conjunto de tareas a realizar para producir un resultadobien definido, sin embargo un paquete de trabajo es un proceso unico. Un pa-quete de trabajo define claramente las fechas de inicio y finalizacion, ası comoun conjunto claro de metas o resultados. Este puede ser usado para modelar tan-to proyectos, como sub-proyectos, tareas o incluso portafolios de proyectos. Lospaquetes de trabajo producen entregables, que pueden ser de cualquier tipo, porejemplo reportes, artıculos, servicios, software, productos fısicos o incluso resul-tados intangibles como el cambio organizacional. Un entregable tambien puedeser la implementacion de una arquitectura o de parte de ella. Un estadio se de-fine como como un estado relativamente estable de una arquitectura, que existedentro de un periodo limitado de tiempo, este concepto le da soporte a la ideafundamental de TOGAF de que las arquitecturas son descritas por diferentesescenarios a la vez, en cada una de las fases, B, C y D de ADM una arquitecturabase y una arquitectura destino son creadas, describiendo la situacion actual yla situacion futura deseada. En la fase E (Oportunidades y soluciones) se definenlas ası llamadas transiciones arquitecturales, mostrando estados incrementalesentre la arquitectura base y la arquitectura destino. Las transiciones arquitectu-rales son usadas para permitir que paquetes de trabajo individuales y proyectossean agrupados en portafolios administrados y programas, ilustrando el valor denegocio de cada etapa. Un intervalo es un resultado importante de un analisisde intervalos en las fases B, C y D del ADM de TOGAF y conforma una entradaimportante en subsecuente planeacion de implementacion y migracion. El con-cepto intervalo es el que busca relacionar dos estadios, por ejemplo entre la lıneabase y la lınea objetivo o entre dos transiciones arquitecturales subsecuentes, yrepresenta la diferencia entre esos dos estadios

127

128 CAPITULO 9. CAPA PROYECTO

9.2. Proyecto

9.2.1. Modelo

El punto de vista del proyecto se utiliza principalmente para modelar la ges-tion del cambio de arquitectura. La ”arquitectura” del proceso de migracion,desde una situacion anterior (arquitectura empresarial actual) hasta una nuevasituacion deseada (arquitectura empresarial objetivo) tiene consecuencias signi-ficativas sobre la estrategia de crecimiento a medio y largo plazo y el procesode toma de decisiones subsiguiente. Algunas de las cuestiones que deben tenerseen cuenta en los modelos disenados en este punto de vista son:

Desarrollar una arquitectura empresarial de toda la organizacion es unatarea que puede requerir varios anos.

Todos los sistemas y servicios deben permanecer operativos con indepen-dencia de todas las presumibles modificaciones y cambios de la arquitec-tura de la empresa durante el proceso de cambio.

El proceso de cambio puede tener que tratar con estandares tecnologicosinmaduros (por ejemplo, mensajerıa, seguridad, datos, etc.).

El cambio tiene graves consecuencias para el personal, la cultura, la formade trabajar y la organizacion.

Ademas, hay otros aspectos de gobierno que pueden restringir el proceso detransformacion, como la cooperacion interna y externa, la gestion de la carterade proyectos, la gestion de proyectos (entregables, objetivos, etc.), la planifica-cion de metas, los aspectos financieros y jurıdicos, etc.

9.2.2. Descripcion

Cuadro 9.1: Descripcion Punto de Vista de ProyectoPunto de Vista de ProyectoInteresados Administradores operativos, arquitectos empre-

sariales, empleados, accionistasAsuntos Vision arquitectural y polıticas, motivacionProposito Decidir, informarCapa de Abstraccion Vision de conjuntoCapas Extension de implementacion y migracionAspectos Informacion, comportamiento, estructura

9.2. PROYECTO 129


En este modelo vemos una vista general de todos los entregables del proyectoy de todos los paquetes de trabajo que deben generar esos entregables, todo estoorientado hacia el cumplimiento de la meta motivacional del proyecto.

Figura 9.1: Modelo de Proyecto


9.3. Migracion

9.3.1. Modelo

El punto de vista de migracion implica modelos y conceptos que pueden usar-se para especificar la transicion de una arquitectura existente a una arquitecturadeseada. Dado que los conceptos de la meseta y la brecha se han presentado an-teriormente, aquı el punto de vista de la migracion solo se describe brevementey se coloca por medio de la tabla siguiente.

9.3.2. Descripcion

Cuadro 9.2: Descripcion Punto de Vista de MigracionPunto de Vista de MigracionInteresados Arquitectos empresariales, de procesos, de aplica-

cion, de infraestructura y de dominio, empleados,accionistas

Asuntos Historia de modelosProposito Disenar, decidir e informarCapa de Abstraccion Vision de conjuntoCapas Extension de implementacion y migracionAspectos No aplicable

9.3. MIGRACION 131


En este modelo vemos una vista general de las transiciones arquitecturalesque son por ejemplo pasar del sensor actual a un sensor mas liviano (Sensor Lite)o generar una aplicacion movil que permita el acceso a los datos del sensor y lasrespectivas brechas que hay que superar entre lo que existe y esas transicionesarquitecturales.

Figura 9.2: Modelo de Migracion


9.4. Migracion e Implementacion

9.4.1. Modelo

El punto de vista de implementacion y migracion se utiliza para relacionarprogramas y proyectos con las partes de la arquitectura que implementan. Estavision permite modelar el alcance de los programas, proyectos, actividades delproyecto en terminos de las mesetas que se realizan o los elementos de arqui-tectura individuales que se ven afectados. Ademas, la forma en que se afectanlos elementos puede indicarse anotando las relaciones. Ademas, este punto devista puede ser utilizado en combinacion con el punto de vista de programas yproyectos para apoyar la gestion de portafolios:

El punto de vista de programas y proyectos es adecuado para relacionar lasmetas de negocio con proyectos. Por ejemplo, esto hace posible analizara un alto nivel si todos los objetivos de negocio estan suficientementecubiertos por los portafolios actuales.

El punto de vista de implementacion y migracion es adecuado para re-lacionar las metas (y los requisitos) de negocio a traves de programas yproyectos a (partes de) la arquitectura. Por ejemplo, esto permite analizarla superposicion potencial entre las actividades del proyecto o analizar lacoherencia entre dependencias de proyectos y dependencias entre mesetaso elementos de arquitectura.

9.4.2. Descripcion

Cuadro 9.3: Descripcion Punto de Vista de Migracion e ImplementacionPunto de Vista de Migracion e ImplementacionInteresados Arquitectos empresariales, de procesos, de aplica-

cion, de infraestructura y de dominio, empleados,accionistas

Asuntos Historia de modelosProposito Disenar, decidir e informarCapa de Abstraccion Vision de conjuntoCapas Extension de implementacion y migracionAspectos No aplicable

9.4. MIGRACION E IMPLEMENTACION 133


En este modelo vemos como las transiciones arquitecturales propuestas parael futuro del sistema son soportadas por diversos paquetes de trabajo y entre-gables, es decir mostramos la perspectiva de futuro del sistema y como lograrlaen terminos de entregables.

Figura 9.3: Modelo de Migracion e Implementacion


Parte III

Prototipo

135

Capıtulo 10

Implementacion

10.1. Introduccion

En esta seccion presentamos el prototipo logrado para la solucion del pro-blema propuesto, el mismo tal y como se planteo en la arquitectura empresarial,es un sistema integrado por componentes que se integran a a traves del esta-blecimiento de una API, compuestas por las interfaces comunes que compartene implementan los distintos componentes. A nivel de solucion podemos resaltarque contamos con una aplicacion web, compuesta de paginas HTML con javas-cript que realizan llamados a los componentes Front-End del sistema que sonlos servicios REST de Autenticador, Sensor y Reporteador, los cuales usan losdemas componentes del Back-end que son la API, las entidades del modelo denegocio y la capa de persistencia, ası como los componentes Lector y Usuarioque dan soporte a los otros componentes.

10.2. Diagrama de Componentes

Figura 10.1: Diagrama de componentes

137

138 CAPITULO 10. IMPLEMENTACION

10.3. Prototipo Teorico

10.3.1. Diagrama Esquematico del Sensor de CO2

El prototipo teorico lo podemos ver representado en el diagrama de compo-nentes ya presentado para el caso del software, pero para el hardware es necesariorealizar un diseno que sera la guıa para la construccion del sensor de CO2 basa-do en Arduino, a continuacion colocamos los diagramas que representan dichosdisenos.

Primero el diagrama esquematico del sensor, que muestra los componentesbasicos y el cableado entre los circuitos, obviamente al centro encontramos elArduino y conectados al sensor el transmisor Wifi, el buzzer y los transistores.

Figura 10.2: Diagrama Esquematico Sensor Arduino

Otra vista del diseno la tenemos en el diagrama del sensor (Figura 10.3,debajo de estas lıneas), que es el insumo para quemar dicho circuito en unabaquela y donde podemos ver todos los componentes que se encuentran en eldiagrama esquematico ya organizados.

10.3. PROTOTIPO TEORICO 139

Figura 10.3: Diagrama Sensor Arduino


10.3.2. Prototipos de la Aplicacion Web

Figura 10.4: Autenticar (Mobile)

Figura 10.5: Pagina de Inicio (Mobile)


Figura 10.6: Menu Usuario (Mobile)

Figura 10.7: Registrar Usuario (Mobile)


Figura 10.8: Selector Sensor (Mobile)

Figura 10.9: Menu Administrador (Mobile)


Figura 10.10: Lista de usuarios (Mobile)

Figura 10.11: Editar Usuario (Mobile)


Figura 10.12: Lista de sensores (Mobile)

Figura 10.13: Registrar Sensor (Mobile)


Figura 10.14: Editar sensor (Mobile)

Figura 10.15: Sensores Alertados (Mobile)


Figura 10.16: Usuarios en Riesgo (Mobile)

10.4. PROTOTIPO FUNCIONAL 147

10.4. Prototipo Funcional

10.4.1. Esquema en protoboard del sensor de CO2

El prototipo funcional del sistema, para la parte de hardware esta represen-tada por el sensor de CO2 que se armo, un diagrama del mismo, donde podemosver como se colocaron y cablearon todos los componentes y el Arduino en sı, esmostrado a continuacion, este diagrama corresponde con el sensor montado ysus componentes.

Otro aspecto, que podemos revisar en la seccion de anexos, en el numeral11.5, es el codigo fuente que usa el sensor para enviar la informacion recolectadaa una URL que recibe los datos, en este caso la recepcion la harıa el componenteSensor, que es un servicio REST que espera las lecturas que entrega el sensorfısico.

Figura 10.17: Esquema Sensor Arduino en la protoboard


10.4.2. Aplicacion

La aplicacion esta organizada en componentes como lo vimos en el diagramade componentes, logicamente las clases que usan estos componentes se organizanen paquetes, que por convencion se ubican en uno de los paquetes mostrados enla figura 10.4.

Con respecto a las clases que componen estos paquetes es complicado co-locarlas o describirlas todas en el presente documento, pero en la seccion deanexos, en el numeral 11.6 se encuentran las interfaces de la aplicacion, que sonlas que implementan cada uno de los componentes, tal y como se muestra en eldiagrama de componentes.

10.4.2.1. Estructura de la aplicacion

Figura 10.18: Diagrama de paquetes


10.4.2.2. Capturas de la aplicacion Web

Figura 10.19: Autenticar

Figura 10.20: Autenticar - ¿Quienes Somos?


Figura 10.21: Registrar Usuario

Figura 10.22: Inicio


Figura 10.23: Seleccionar Sensor

Figura 10.24: Listar Usuarios


Figura 10.25: Editar usuario

Figura 10.26: Listar Sensores


Figura 10.27: Editar Sensor

Figura 10.28: Sensores Alertados


Figura 10.29: Usuarios en riesgo

Parte IV

Reflexiones

155

Capıtulo 11

Conclusiones, Trabajos,Futuros Aportes, yContrastacion

11.1. Conclusiones

Con un sistema base para el circuito electronico se puede lograr de unaforma eficiente y economica una herramienta capaz de monitorear los ni-veles de monoxido de carbono, en la cual se puedan presentar los nivelesactuales y poder revisar estadısticamente cuales son los picos altos y bajosen el dıa frente a la exposicion a este gas.

Adicionalmente al tener los datos en tiempo real y basados en las es-timaciones recomendadas para una persona con respecto al tiempo deexposicion, presentar alarmas visuales por medio de luces conectados aldispositivo electronico, estas alarmas deberan informar cuando las PPMde monoxido de carbono esten altas para una permanencia mınima porparte de cualquier persona.

Esta herramienta tambien debe poder compartir su informacion capturadacon otros sistemas por medio de protocolos estandar de comunicacion comoes el XML[24].

El circuito electronico busca ser rentable economicamente para ser replica-do facilmente por lo que se basara en hardware de Arduino[13] y sensoresde gases compatibles con el hardware utilizado como es el caso del sensorMQ9[25] el cual mide su conductividad en el aire siendo mas baja en airelimpio[26] y alta en presencia de monoxido de carbono, este presenta ensu salida el calculo apropiado de la concentracion de este gas.

157

158CAPITULO 11. CONCLUSIONES, TRABAJOS, FUTUROS APORTES, Y CONTRASTACION

11.2. Trabajos Futuros

11.2.1. Sensor Lite

Para la optimizacion de recursos, se puede apoyar en el modulo WiFi ESP8266el cual cuenta con un micro-controlador que puede soportar las lecturas del sen-sor MQ-07 ahorrando un componente hardware, este apoyo seria programandoel micro-controlador con un lenguaje como LUA para poder utilizarlo facilmente

11.2.2. SmogChecker Mobile

Mediante un modulo bluetooth que reemplace el modulo WiFi, se puedeconectar el sensor a un dispositivo celular o similar que haga las funciones deservidor central y muestre las metricas del sensor.

11.2.3. SmogChecker BI

Cuando se cuente con una buena cantidad de mediciones se pueden incluir alsistema central algoritmos de inteligencia de negocio y toma de decisiones parapoder encontrar patrones que ayuden a las polıticas de prevencion laboral.

11.3. APORTES 159

11.3. Aportes

La solucion brinda un paso de integracion del internet de las cosas hacia losriesgos laborales.

11.4. Contrastacion

Aunque la herramienta permite conocer en tiempo real la exposicion al CO2se debe complementar con polıticas de prevencion de laboral, para que el sistematenga un impacto positivo en el personal de seguridad de los parqueaderos dela Universidad Distrital Francisco Jose de Caldas.

160CAPITULO 11. CONCLUSIONES, TRABAJOS, FUTUROS APORTES, Y CONTRASTACION

Bibliografıa

[1] Energas, “Intoxicacion por monoxido de carbono: consecuencias.”http://enargas.blogspot.com.co/2011/10/intoxicacion-por-monoxido-de-carbono.html, 2011. [Accesado 2016-11-3].

[2] O. A. de Bogota, “Casos de intoxicaciones intramural por monoxido de car-bono - cimct.” http://oab.ambientebogota.gov.co/es/indicadores?id=531,2011. [Accesado 2016-11-3].

[3] DelgadoKarlo, “Co y co2 - ¿cual es la diferencia?.”http://www.metrosco2.com/blogs/news/2568172-co-y-co2-cual-es-la-diferencia, 2011. [Accesado 2016-11-16].

[4] GNU, “¿que es el software libre?.” https://www.gnu.org/philosophy/free-sw.es.html, 2013. [Accesado 2016-11-16].

[5] VelascoJJ, “5 proyectos de hardware libre que vale la pena co-nocer.” https://hipertextual.com/2013/05/5-proyectos-de-hardware-libre-para-conocer, 2013. [Accesado 2016-11-16].

[6] M. de Salud y Proteccion Social, “AbecE de aire y salud.”https://www.minsalud.gov.co/sites/rid/Lists/BibliotecaDigital/RIDE/VS/PP/SA/abc-aire.pdf, 2015. [Accesado 2016-10-22].

[7] A. para Sustancias Toxicas y el Registro de Enfermeda-des, “ToxfaqsTM - monoxido de carbono (carbon monoxide).”https://www.atsdr.cdc.gov/es/toxfaqs/estfacts201.html, 2016. [Acce-sado 2016-11-16].

[8] CARVAJALNATALIAGOMEZ, “Motos, las segundas que mas aportan ala polucion en bogota.” http://www.eltiempo.com/bogota/las-motos-en-el-segundo-lugar-de-los-vehiculos-que-mas-contaminan/14085997, 2014. [Ac-cesado 2016-11-6].

[9] CERONJOHN, “Uso de la moto en bogota se duplico en 4anos.” http://www.eltiempo.com/bogota/motos-en-bogota-uso-se-duplico-en-4-anos/16462851, 2015. [Accesado 2016-11-6].

161

162 BIBLIOGRAFIA

[10] S. de, “Seguimiento a los resultados institucionales y su articulacioncon el plan nacional de desarrollo.” http://www.ins.gov.co/control-y-transparencia/siteassets/paginas/rendicion-de-cuentas-2012/presentacionaudiencia publica 2012.ppt, 2013. [Accesado 2016-11-3].

[11] J. T. y Alvaro Fajardo, “Contaminacion por monoxido de carbono: unproblema de salud ambiental,” 2006.

[12] BoochGBoochG, Analisis y diseno orientado a objetos. Editorial AddisonWesley Longman, 1996.

[13] Arduino, “What is arduino?.” https://www.arduino.cc/en/Guide/Introduction,2016. [Accesado 2016-9-21].

[14] S. D. de Ambiente, “Bogota se une al programa climay aire limpio en ciudades de america latina - see mo-re at: http://www.ambientebogota.gov.co/web/sda/archivo-de-noticias/-/assetpublisher/5ppa/content/bogota-se-une-al-programa-clima-y-aire-limpio-en-ciudades-de-america-lat.”http://www.ambientebogota.gov.co/web/sda/archivo-de-noticias/-/assetpublisher/5PPa/content/bogota-se-une-al-programa-clima-y-aire-limpio-en-ciudades-de-america-latina, 2016. [Accesado 2016-11-16].

[15] S. JETantawyH., “Toxins.” https://www.ncbi.nlm.nih.gov/pubmed/17240611?ga=1.161546876.1145413354.1479228900, 2006. [Accesado 2016-10-22].

[16] PardoLisandro, “Los niveles de co2 abren una ((nueva era)) para el calenta-miento global.” http://www.neoteo.com/los-niveles-co2-abren-una-nueva-calentamiento-global, 2016. [Accesado 2016-11-16].

[17] Medlineplus, “Intoxicacion con monoxido de carbono.”https://medlineplus.gov/spanish/ency/article/002804.htm, 2015. [Ac-cesado 2016-10-22].

[18] C. C. para el Control y la Prevencion de Enfermedades.,“Prevenga intoxicaciones por monoxido de carbono (co).”http://www.cdc.gov/spanish/especialescdc/monoxidodecarbono/, 2016.[Accesado 2016-11-16].

[19] C. SAFETY, “Consumer product safety commission.”https://www.cpsc.gov/es/Safety-Education/Centro-de-informacion-seguridad/Carbon-Monoxide-Info-Center-Spanish/Monoxido-de-Carbono—Preguntas-y-Respuestas/, 2016.

[20] S. de la, “La oms establece parametros para reducir los danos pa-ra la salud debidos a la contaminacion del aire de interiores.”http://www.who.int/mediacentre/news/releases/2014/indoor-air-pollution/es/, 2016. [Accesado 2016-10-10].

[21] C. Larman, UML y Patrones. Pearson, 1999.

BIBLIOGRAFIA 163

[22] M. N. M. Garcıa and F. J. G. Penalvo, “Tema 2 modelos de proceso del soft-ware.” http://avellano.usal.es/ mmoreno/ASTema2.pdf. [Accesado 2016-10-02].

[23] J. M. M. Cespedes, “Modelo cluster.”http://juanmurielc.blogspot.com.co/2012/05/ciclos-de-vida-orientados-objetos.html. [Accesado 2016-10-12].

[24] w3.org, “Extensible markup language (xml).” https://www.w3.org/XML/,2016. [Accesado 2016-11-16].

[25] H. H. E. Co, “Mq-9 semiconductor sensor for co/combusti-ble gasmq-9 semiconductor sensor for co/combustible gas.”https://www.pololu.com/file/download/MQ9.pdf?fileid=0J314, 2011.[Accesado 2016-11-3].

[26] P. Biosfera, “Aire limpio y aire contaminado.”http://recursos.cnice.mec.es/biosfera/alumno/1ESO/atmosfera/contenidos4.htm,2016. [Accesado 2016-11-16].

164 BIBLIOGRAFIA

Anexos

11.5. Codigo Fuente Arduino

1 const i n t AOUTpin=0 ; // the AOUT pin o f the CO senso r goes in toanalog pin A0 o f the arduino

const i n t DOUTpin=8 ; // the DOUT pin o f the CO senso r goes in tod i g i t a l pin D8 o f the arduino

3 const i n t ledPin=13 ; // the anode o f the LED connects to d i g i t a l pinD13 o f the arduino

5 i n t l im i t ;i n t va lue ;

7

void setup ( ) {9 S e r i a l . begin ( 115200 ) ; // s e t s the baud ra t e

pinMode (DOUTpin, INPUT) ; // s e t s the pin as an input to the arduino11 pinMode ( ledPin , OUTPUT) ; // s e t s the pin as an output o f the

arduino}

13

void loop ( ) {15 value= analogRead (AOUTpin) ; // reads the analaog value from the CO

sensor ’ s AOUT pinl im i t= d ig i ta lRead (DOUTpin) ; // reads the d i g i t a l va lue from the CO

sensor ’ s DOUT pin17 S e r i a l . p r i n t ( ”CO value : ” ) ;

S e r i a l . p r i n t l n ( va lue ) ; // p r i n t s the CO value19 S e r i a l . p r i n t ( ”Limit : ” ) ;

S e r i a l . p r i n t ( l im i t ) ; // p r i n t s the l im i t reached as e i t h e r LOW orHIGH ( above or underneath )

21 delay ( 100 ) ;i f ( l im i t == HIGH) {

23 d i g i t a lWr i t e ( ledPin , HIGH) ; // i f l im i t has been reached , LEDturns on as s t a tu s i nd i c a t o r

}25 e l s e {

d i g i t a lWr i t e ( ledPin , LOW) ; // i f th r e sho ld not reached , LEDremains o f f

27 }}

Listing 11.1: Codigo envıo de datos Arduino

165

166 BIBLIOGRAFIA

11.6. Codigo Fuente Interfaces Java

/*

2 * To change this license header , choose License

Headers in Project Properties.

* To change this template file , choose Tools |

Templates

4 * and open the template in the editor.

*/

6 package com.SmogChecker.Api;

8 import com.SmogChecker.Model.User;

10 /**

*

12 * @author Sergio Bayona , Christian Mosquera

*/

14 public interface IAccess {

16

User Autenticate(String UserName , String Password);

}

Listing 11.2: Interfaz IAccess para el componente de autenticacion

11.6. CODIGO FUENTE INTERFACES JAVA 167

1 /*

* To change this license header , choose License


3 * To change this template file , choose Tools |

Templates

* and open the template in the editor.

5 */

package com.SmogChecker.Api;

7

import com.SmogChecker.Model.User;

9 import java.util.List;

11 /**

*


*/

15 public interface IPerson {

17 public void Create(User user);

19 public void Update(User user);

21 public void Delete(User user);

23 public List <User > Get(User example);

}

Listing 11.3: Interfaz IPerson para el componente de usuario

168 BIBLIOGRAFIA

/*




Templates


*/


8 import com.SmogChecker.Model.CO2Level;

import java.util.List;

10

/**

12 *

* @author Sergio Bayona , Christian Mosquera

14 */

public interface IDiagnostic {

16

public void Create(CO2Level registry);

18

public void Update(CO2Level registry);

20

public void Delete(CO2Level registry);

22

public List <CO2Level > Get(CO2Level example);

24 }

Listing 11.4: Interfaz IDianostic para el componente de lectura


/*




Templates


*/


8 import com.SmogChecker.Model.Sensor;


10

/**

12 *


14 */

public interface IDevice {

16

public void Create(Sensor sensor);

18

public void Update(Sensor sensor);

20

public void Delete(Sensor sensor);

22

public List <Sensor > Get(Sensor example);

24 }

Listing 11.5: Interfaz ISensor para el componente de sensor de software

170 BIBLIOGRAFIA

/*




Templates


*/


8 import com.SmogChecker.Model.Sensor;

import com.SmogChecker.Model.User;

10 import java.util.List;

12 /**

*


*/

16 public interface IQueryable {

18 // Obtiene un listado de los sensores que se

// encuentran por encima de los niveles

20 //de CO2 tolerables

List <Sensor > GetAlertedSensors ();

22

// Obtiene un listado de los usuarios que se

24 // encuentran cerca de cualquier sensor que

//esta reportando valores por encima de

26 //los niveles de CO2 tolerables

List <User > GetUsersAtRisk ();

28 }

Listing 11.6: Interfaz IQueryable para el componente de reporteador


/*




Templates


*/


8 import com.SmogChecker.Model.Notification;


10

/**

12 *


14 */

public interface INotifiable {

16

// Obtiene un listado de notificaciones

18 List <Notification > GetNotifications ();

}

Listing 11.7: Interfaz IQueryable para el componente de reporteador

172 BIBLIOGRAFIA

1 /*

* To change this license header , choose License


3 * To change this template file , choose Tools |

Templates

* and open the template in the editor.

5 */

package com.SmogChecker.Api;

7

import java.util.ArrayList;

9

public interface IDao <T> {

11

T Create(T Entity);

13

void Update(T Entity);

15

void Delete(T Entity);

17

T GetById(String Id);

19

ArrayList <T> GetByExample(T Entity);

21 }

Listing 11.8: Interfaz IDao para la capa de persistencia

Documents

PROTOTIPO DE HERRAMIENTA WEB PARA EL MONITOREO …repository.udistrital.edu.co/bitstream/11349/6513/1/MosqueraOrtega... · Modelo de Agrupamiento . . . . . . . . . . . . . . .