Embed Size (px)
Citation preview
INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE
INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
IMPLEMENTACIÓN DE PLANTILLAS BASE Y
COMPONENTES REUTILIZABLES EN
AMBIENTE WEB
T E S I S QUE PARA OBTENER EL GRADO DE
MAESTRO EN CIENCIAS EN INFORMÁTICA
P R E S E N T A:
FABIÁN RAMÍREZ GALINDO
DIRECTOR DE TESIS:
M.C. ABEL BUENO MEZA
i
ii
iii
AGRADECIMIENTOS
Agradezco a Dios, por darme la fortaleza para superar los retos presentados a lo largo
de mi vida.
Al Instituto Politécnico Nacional, por haberme brindado la oportunidad de continuar mi
formación académica en mis estudios de posgrado.
A mi esposa Fabiola, por su enorme apoyo y ayuda para no desistir en este sueño que
parecía tan lejano y ahora se encuentra muy próximo a hacerse realidad, ella que ha
decidido caminar a mi lado.
A mis hijos Andrea y Gabriel, por llegar a cambiar mi vida, por permitirme tomar parte
de su tiempo para trabajar en este proyecto.
A mi madre Lydia, por sus enseñanzas, su sacrificio, su confianza y sabios consejos en
cada uno de los momentos de mi vida.
A mis hermanas Fabiola y Gabriela, por escucharme, por estar siempre conmigo, por la
confianza depositada en mí.
A mi profesor y director de Tesis, el M. en C. Abel Bueno Meza, por los cursos impartidos
y por su guía en la realización de este trabajo de Tesis.
Al M. en C. Eduardo Rene Rodríguez Ávila, por el gran apoyo con sus revisiones y
observaciones que me brindó durante el desarrollo del presente trabajo.
Al Mtro. Fernando Sánchez, por sus enseñanzas y consejos otorgados, por permitirme
tomar ese curso de Comportamiento Organizacional, el cual ha sido uno de los cursos
más enriquecedores de mi formación.
iv
Tabla de contenidos Tabla de figuras ......................................................................................................................... vii
Índice de tablas ........................................................................................................................... x
Resumen ...................................................................................................................................... xi
Abstract ....................................................................................................................................... xii
Capítulo I ...................................................................................................................................... 1
Del desarrollo de software y su problemática ....................................................................... 1
El desarrollo de software ....................................................................................................... 1
Las dificultades del desarrollo de software ........................................................................ 2
La categorización de problemas .......................................................................................... 3
Reflexión .................................................................................................................................. 4
Historia de grandes errores de software ............................................................................. 5
Herramientas generadoras de código ................................................................................. 7
Visual Studio ....................................................................................................................... 7
Smart Code Generator ...................................................................................................... 8
ASPRunner.NET ................................................................................................................. 9
Consecuencias ....................................................................................................................... 9
Capítulo II................................................................................................................................... 10
Patrones de diseño y frameworks actuales .......................................................................... 10
Calidad ................................................................................................................................... 10
Atributos de calidad .......................................................................................................... 10
Estándares............................................................................................................................. 12
Arquitectura de software ..................................................................................................... 13
Patrones de diseño .............................................................................................................. 14
Procesos de desarrollo ........................................................................................................ 17
Modelos de proceso prescriptivo ................................................................................... 18
Modelo de cascada .......................................................................................................... 18
Desarrollo incremental ..................................................................................................... 19
Ingeniería de software orientada a la reutilización ...................................................... 20
Modelos de proceso evolutivo ........................................................................................ 21
Prototipos ........................................................................................................................... 21
Modelo espiral ................................................................................................................... 21
Ingeniería de software basada en componentes ............................................................ 22
El proceso Unificado ............................................................................................................ 23
v
Proceso de software personal (PSP) ................................................................................ 24
Proceso de software en equipo (TSP) .............................................................................. 25
CMMI ...................................................................................................................................... 26
Desarrollo ágil ....................................................................................................................... 29
Métodos ágiles .................................................................................................................. 29
Programación extrema ........................................................................................................ 30
SCRUM .................................................................................................................................. 30
Principios de Scrum ......................................................................................................... 32
Aspectos de SCRUM ....................................................................................................... 32
Organización ..................................................................................................................... 32
Justificación del negocio.................................................................................................. 32
Calidad ............................................................................................................................... 32
Cambio ............................................................................................................................... 33
Riesgo ................................................................................................................................ 33
Procesos de SCRUM ...................................................................................................... 33
Kanban ................................................................................................................................... 34
Capítulo III ................................................................................................................................. 36
Análisis y diseño ....................................................................................................................... 36
Análisis de la plantilla creada ............................................................................................. 36
Herramientas utilizadas ....................................................................................................... 36
Patrones arquitectónicos ..................................................................................................... 36
Patrones de diseño .............................................................................................................. 38
Especificación de los casos de Uso .................................................................................. 39
Actores ............................................................................................................................... 39
Casos de uso .................................................................................................................... 40
Modelo de dominio ............................................................................................................... 51
Clases de control .................................................................................................................. 51
Diagramas de secuencia ..................................................................................................... 52
Diagramas de colaboración ................................................................................................ 58
Capítulo IV ................................................................................................................................. 64
Implementación ......................................................................................................................... 64
Actividades de la fase de Construcción ............................................................................ 64
Herramientas utilizadas ....................................................................................................... 64
Fase de construcción ........................................................................................................... 64
vi
Construcción de base de datos ...................................................................................... 64
Construcción de componentes reusables..................................................................... 67
Construcción de servicio web ......................................................................................... 71
Construcción de la aplicación Web ................................................................................ 74
Pruebas del sitio web ........................................................................................................... 75
Caso práctico ........................................................................................................................ 86
Ventajas de uso del modelo propuesto ............................................................................. 90
Caso 1 ................................................................................................................................ 90
Caso 2 ................................................................................................................................ 92
Caso 3 ................................................................................................................................ 93
Implementación de patrones .......................................................................................... 94
Métricas de código ........................................................................................................... 96
Conclusiones ............................................................................................................................. 99
Perspectivas .............................................................................................................................. 99
Referencia bibliográfica ......................................................................................................... 101
Anexo 1 .................................................................................................................................... 103
Convenciones y estándares de nombres ....................................................................... 103
Anexo 2 .................................................................................................................................... 107
Script de creación de base de datos ............................................................................... 107
Script de creación de objetos de la base de datos PlantillaDB ................................... 109
Anexo 3 .................................................................................................................................... 116
Fuentes de clase DalcCatalogo ....................................................................................... 116
Fuentes de clase ProcesosCatalogo ............................................................................... 117
Fuentes de entidad TablaPlantilla.................................................................................... 120
Fuentes de interfaz de servicio IServicioBase ............................................................... 121
Fuentes de implementación de servicio ServicioBase ................................................. 121
vii
Tabla de figuras Figura 1. IDE Visual Studio 2017 ............................................................................................. 7
Figura 2. Código generado de forma automática. ................................................................. 8
Figura 3. Proyecto Smart Code Generator. ............................................................................ 8
Figura 4. ASPRunner.NET. ....................................................................................................... 9
Figura 5. Modelo de cascada. ................................................................................................ 19
Figura 6. Desarrollo incremental. ........................................................................................... 20
Figura 7. Modelo de espiral. ................................................................................................... 21
Figura 8. Flujo de proceso de PSP. ....................................................................................... 24
Figura 9. Integración efectiva de equipos con TSP. ........................................................... 26
Figura 10. Proceso de mejora continua CMMI. ................................................................... 27
Figura 11. Flujo de Scrum de un sprint. ................................................................................ 31
Figura 12. Tablero KANBAN................................................................................................... 35
Figura 13. Estructura propuesta............................................................................................. 38
Figura 14. Diagrama de Casos de Uso. ................................................................................ 40
Figura 15. Modelo de dominio. ............................................................................................... 51
Figura 16. Paquete de seguridad........................................................................................... 52
Figura 17. Paquete de control. ............................................................................................... 52
Figura 18. OSD_IniciarSesionAdmin. .................................................................................... 53
Figura 19. OSD_IniciarSesionUO. ......................................................................................... 53
Figura 20. OSD_ConsultarCatalogo. ..................................................................................... 54
Figura 21. OSD_AdministrarCatalogo. .................................................................................. 54
Figura 22. OSD_Insertarcatalogo. ......................................................................................... 55
Figura 23. OSD_ActualizarCatalogo. .................................................................................... 55
Figura 24. OSD_EliminarCatalogo. ....................................................................................... 56
Figura 25. OSD_AdministrarUsuarios. .................................................................................. 56
Figura 26. OSD_InsertarUsuario. .......................................................................................... 57
Figura 27. OSD_ActualizarUsuario. ...................................................................................... 57
Figura 28. OSD_EliminarUsuario. .......................................................................................... 58
Figura 29. OSD_RegistrarPistas. ........................................................................................... 58
Figura 30. OC_IniciarSesionAdmin. ...................................................................................... 59
Figura 31. OC_IniciarSesionUO. ............................................................................................ 59
Figura 32. OC_ConsultarCatalogo. ....................................................................................... 60
Figura 33. OC_AdministrarCatalogo. .................................................................................... 60
Figura 34. OC_Insertarcatalogo. ............................................................................................ 60
Figura 35. OC_ActualizarCatalogo. ....................................................................................... 61
Figura 36. OC_EliminarCatalogo. .......................................................................................... 61
Figura 37. OC_AdministrarUsuarios. .................................................................................... 61
Figura 38. OC_InsertarUsuario. ............................................................................................. 62
Figura 39. OC_ActualizarUsuario. ......................................................................................... 62
Figura 40. OC_EliminarUsuario. ............................................................................................ 63
Figura 41. OC_RegistrarPistas. ............................................................................................. 63
Figura 42. Diagrama E-R. ....................................................................................................... 65
Figura 43. Ejecución de script de creación de objetos. ...................................................... 65
Figura 44. Servicio WEB. ........................................................................................................ 68
viii
Figura 45. Componentes de acceso a datos. ...................................................................... 69
Figura 46. Componente de control de errores. .................................................................... 69
Figura 47. Componentes de Utilerías. .................................................................................. 70
Figura 48. Diagrama de clases de ProcesamientoBase. ................................................... 71
Figura 49. Diagrama de clases de Seguridad. .................................................................... 72
Figura 50. Diagrama de clases del servicioWCF. ............................................................... 72
Figura 51. Servicio Seguridad. ............................................................................................... 73
Figura 52. Servicio Base. ........................................................................................................ 74
Figura 53. Fuentes de aplicación WEB. ................................................................................ 74
Figura 54. Página de inicio de sesión. .................................................................................. 75
Figura 55. Página principal. .................................................................................................... 75
Figura 56. Página consulta de catálogo. .............................................................................. 76
Figura 57. Registro nuevo en página Consulta de catálogo. ............................................. 76
Figura 58. Página Mantenimiento de Catálogo. .................................................................. 77
Figura 59. Página Alta de Catálogo....................................................................................... 77
Figura 60. Página de mantenimiento de Catálogo con alta satisfactoria. ....................... 78
Figura 61. Selección de registro en la página Mantenimiento de Catálogo. ................... 78
Figura 62. Página de actualización del catálogo. ................................................................ 79
Figura 63. Mensaje al actualizar registró en la página Actualización de Catálogo. ....... 79
Figura 64. Página de mantenimiento de Catálogo con actualización satisfactoria. ....... 80
Figura 65. Selección de registro para eliminar en la página de Mantenimiento de
Catálogo. .................................................................................................................................... 80
Figura 66. Mensaje al eliminar registro en página Mantenimiento de Catálogo. ........... 81
Figura 67. Página Registro de Usuarios. .............................................................................. 81
Figura 68. Página Alta de usuarios. ...................................................................................... 82
Figura 69. Mensaje de alta de usuario satisfactoria. .......................................................... 82
Figura 70. Selección de usuario a actualizar. ...................................................................... 83
Figura 71. Página Actualización de Usuario. ....................................................................... 83
Figura 72. Mensaje exitoso de actualización de usuario. .................................................. 84
Figura 73. Selección de usuario a dar de baja. ................................................................... 84
Figura 74. Mensaje de baja exitosa de usuario. .................................................................. 85
Figura 75. Página al presionar el botón INICIO. .................................................................. 85
Figura 76. Página de Inicio de Sesión al presionar el botón SALIR. ............................... 86
Figura 77. Método ConsultarOrganizacion expuesto en Servicio web. ........................... 87
Figura 78. Método ConsultarArea expuesto en Servicio web. .......................................... 87
Figura 79. Método ConsultarTipoDepartamento expuesto en Servicio web. .................. 88
Figura 80. Método ConsultarRol expuesto en Servicio web. ............................................. 88
Figura 81. Método ConsultarDepartamento expuesto en Servicio web. ......................... 89
Figura 82. Método ConsultarEmpleado expuesto en Servicio web. ................................. 89
Figura 83. Método de acceso a datos Consulta_DatInventarios. ..................................... 90
Figura 84. Método de acceso a datos Consulta_OrdenInventario. .................................. 91
Figura 85. Método de acceso a datos c_obtenDatosTRecetas. ....................................... 92
Figura 86. Método de acceso a datos c_sconfig. ................................................................ 93
Figura 87. Métodos de acceso a datos c_CatalogoPorLlave y c_CatalogoPorClave. .. 94
ix
Figura 88. Métodos de acceso a datos c_CatalogoPorLlave y c_CatalogoPorClave con
llamados a procedimientos almacenados. ........................................................................... 94
Figura 89. Métodos RegistrarPistasAuditoria y c_UsuarioPorClave. ............................... 95
Figura 90. Método CreateEntity. ............................................................................................ 96
x
Índice de tablas Tabla 1. Áreas de proceso por nivel de madurez................................................................ 29
Tabla 2. Procesos de SCRUM. .............................................................................................. 34
Tabla 3. Caso de uso Iniciar Sesión. ..................................................................................... 41
Tabla 4. Consultar Catalogo. .................................................................................................. 42
Tabla 5. Administrar Catálogo ................................................................................................ 42
Tabla 6. Insertar catálogo. ...................................................................................................... 44
Tabla 7. Actualizar catálogo. .................................................................................................. 45
Tabla 8. Eliminar catálogo....................................................................................................... 46
Tabla 9. Administrar Usuarios. ............................................................................................... 46
Tabla 10. Insertar Usuario....................................................................................................... 48
Tabla 11. Actualizar Usuario................................................................................................... 49
Tabla 12. Eliminar Usuario. ..................................................................................................... 50
Tabla 13. Registrar Pistas de auditoria. ................................................................................ 50
Tabla 14. Relación de objetos de la base de datos. ........................................................... 66
Tabla 15. Entidad Catalogo. ................................................................................................... 66
Tabla 16. Entidad Operaciones. ............................................................................................. 66
Tabla 17. Entidad Usuarios..................................................................................................... 66
Tabla 18. Entidad PistasAuditoria. ......................................................................................... 67
Tabla 19. Entidad BitacoraAcceso......................................................................................... 67
Tabla 20. Métricas de código de Ejemplo 1. ........................................................................ 96
Tabla 21. Métricas de código de Ejemplo 2. ........................................................................ 98
Tabla 22. Métricas de código de Ejemplo 3. ........................................................................ 98
xi
Resumen Con el paso del tiempo el software ha tomado un papel protagónico en la sociedad, no
se puede imaginar un área que no haga uso de él, como software incrustado lo
encontramos en infinidad de artículos como pueden ser relojes, teléfonos celulares,
televisores inteligentes, automóviles. También lo encontramos como software de
aplicación, por ejemplo los sistemas que controlan las transacciones bancarias o los
sistemas de administración de inventarios. No se puede dejar de mencionar las redes
sociales actuales, que son sistemas de software que permiten interactuar de forma
virtual con otros individuos.
La dependencia que se ha generado sobre el software ha ocasionado que las personas,
empresas y gobiernos requieran sistemas de software que cumplan con mayor cantidad
de requerimientos, ocasionando que los sistemas sean cada vez más grandes y
complejos. La importancia que juega el software en la actualidad demanda que se
desarrollen sistemas de cómputo de una forma más rápida, con el mínimo de defectos,
que cumplan con las necesidades de los usuarios, fáciles de mantener, la forma de
lograr esto es mediante la Ingeniería de software.
La ingeniería del software es una disciplina de la ingeniería preocupada por todas las
etapas de la producción del software, desde la especificación de los requerimientos
hasta el mantenimiento de los sistemas. Busca generar productos de calidad en el
tiempo y presupuesto acordado. Es una disciplina que integra métodos, herramientas y
procedimientos para el desarrollo de sistemas de software.
Una manera de reducir los tiempos de entrega y minimizar los defectos es haciendo uso
de la ingeniería de software basada en la reutilización. La finalidad de esta estrategia es
tratar de maximizar la mayor cantidad de software existente sin tener que volver a
construirlo desde un principio. Los niveles de reutilización pueden ir desde: reutilización
de sistemas de aplicación, reutilización de componentes, reutilización de objetos y
funciones.
En el presente trabajo de tesis se presenta la creación de estructuras de software
compuestas por componentes software personalizables e intercambiables. Como
producto final se obtendrá una aplicación web genérica formada por componentes
reutilizables. Los componentes implementarán la funcionalidad que el autor de esta tesis
ha identificado se construye en la mayoría de los sistemas de software.
xii
Abstract Over time the software has taken a leading role in society, it is impossible imagine an
area that does not use software, as embedded software we find in countless items such
as watches, cell phones, smart TVs, cars. We also find it as application software, for
example the software systems that control banking transactions or the WMS (inventory
management systems). Also, it is important to mention the current social networks, which
are software systems that allow interaction with other individuals.
The dependence that has been generated on software has caused people, companies
and governments to require software systems that comply with a greater number of
requirements, causing the systems to be increasingly larger and more complex. The
importance that software plays today demands that software systems be developed in a
faster way, with the minimum of defects, that meet the needs of users, easy to maintain,
the way to achieve this is through Engineering of software.
Software engineering is an engineering discipline worried with all stages of software
production, from the specification of requirements to the maintenance of systems.
Software engineering seeks to generate quality products in time and budget agreed. It is
a discipline that integrates methods, tools and procedures for the development of
software systems.
One way to reduce delivery times and minimize defects is to make use of software
engineering based on reuse. The purpose of this strategy is to try to maximize the largest
amount of existing software without having to rebuild it from the beginning. The levels of
reuse can range from: reusing application systems, reusing components or reusing
objects and functions.
In the present thesis work will built software structures composed of customizable and
interchangeable software components. As a final product you will obtain a generic web
application made up of reusable components. The components will implement the
functionality that the author of this thesis has identified is built in most software systems.
1
Capítulo I
Del desarrollo de software y su problemática Actualmente, considerar al mundo moderno sin software resulta muy difícil. Nuestra
civilización se controla mediante sistemas basados en computadoras y la mayoría de
los productos eléctricos incluyen una computadora o elementos de automatización que
requieren cierta lógica de control, alambrada o programada. La fabricación, la logística
de distribución, el sistema financiero, el entretenimiento, usan software de manera
intensiva. Incluso actividades agropecuarias o agrícolas que buscan incrementar su
eficiencia y productividad recurren al uso de computadoras o maquinaria automatizada.
Por lo tanto, el desarrollo de software es esencial para el funcionamiento de las
sociedades, tanto a nivel nacional como internacional.
Los sistemas de información son, en general, abstractos e intangibles. No están
restringidos por propiedades materiales, regidos por leyes físicas ni por procesos de
elaboración. Si bien no existen límites naturales a su potencial, su creación y
mantenimiento si puede volverse rápidamente complejo, difícil de entender y costoso.
En este capítulo se habla acerca del desarrollo de software, de cómo la ingeniería de
software se ha vuelto un punto esencial para el desarrollo de software, se exponen
problemas que todo desarrollador u organización enfrentan en el desarrollo de software.
Se mencionan algunos de los errores más frecuentes y cuáles son sus consecuencias.
También se describirán algunas herramientas de generación de código, estas
herramientas se mencionan en esta sección debido a que se han construido con la
finalidad de mejorar la productividad en el desarrollo, aumentar la calidad del software,
automatizar y generar documentación.
El desarrollo de software
El desarrollo de software es una actividad común e indispensable hoy en día, no se
puede pensar en los negocios la ciencia y la ingeniería sin considerar el software. Ha
permitido la creación de nuevas tecnologías como la ingeniería genética y la
nanotecnología, también ha sido el responsable de que tecnologías antiguas estén por
desaparecer como la industria de la impresión(Roger S. Pressman & Bruce R. Maxim,
2015). El software ha evolucionado de tal manera que hoy en día se encuentran los
sistemas del software de cualquier tipo: médicos, comida, entretenimiento. Las
empresas más importantes están relacionadas con la industria del software como
Microsoft, Apple, También se ha observado un crecimiento en las redes sociales como
Facebook, twitter.
La importancia y dependencia del software ha ocasionado que se busquen técnicas para
elaborar sistemas de software de una forma más fácil y rápida, esto ha ocasionado el
surgimiento de paradigmas como la programación Orientada o programación orientada
a aspectos.
2
El software de computadora es el producto creado por los programadores de sistemas.
Una vez creado e instalado este producto entrara a una fase de mantenimiento durante
un gran periodo de tiempo. La forma de construir software ha cambiado, inicialmente el
desarrollo era realizado por un solo programador, actualmente todo un equipo de trabajo
quien se encarga de crear el software. Sin embargo, las preguntas para crear el software
siguen siendo las mismas.
¿Por qué se requiere tanto tiempo para terminar el software?
¿Por qué son tan altos los costos de desarrollo?
¿Por qué no podemos detectar todos los errores antes de entregar el software a
nuestros clientes?
¿Por qué dedicamos tanto tiempo y esfuerzo a mantener los programas
existentes?
¿Por qué seguimos con dificultades para medir el avance mientras se desarrolla
y mantiene el software?
Las preguntas anteriores son evidencia que existe una preocupación por generar
software de mejor calidad lo ha ocasionado que se haga uso de la práctica de la
ingeniería de software. La ingeniería de software consiste en un conjunto de métodos,
procesos, herramientas que permite a los profesionales desarrollar un producto de
software de calidad satisfaciendo las necesidades del usuario final. La meta de la
ingeniería de software moderna es “desarrollar metodologías que se basen en el
concepto de evolución; es decir, el concepto de que los sistemas de software cambian
continuamente, que los nuevos sistemas de software se desarrollan a partir de los
antiguos y […] que todo debe operar entre sí y cooperar con cada uno de los
demás”(Dayani-Fard, 1999).
El IEEE ha desarrollado una definición más completa del término ingeniería de software:
“La ingeniería de software es: 1) La aplicación de un enfoque sistemático, disciplinado
y cuantificable al desarrollo, operación y mantenimiento de software; es decir, la
aplicación de la ingeniería al software. 2) El estudio de enfoques según el punto 1.(IEEE,
1993)
El proceso de software consta de cinco actividades básicas: comunicación, planeación,
modelado, construcción y despliegue. Estas actividades se aplican a cualquier proyecto
de software. En muchos proyectos estas actividades se pueden ejecutar de forma
iterativa, lo que se conoce como incremento. Existen actividades complementarias
dentro de la ingeniería de software que ayudan a administrar y controlar el avance, la
calidad, cambios y riesgos de un proyecto, Estas actividades son: seguimiento y control
del proyecto de software, administración del riesgo, aseguramiento de calidad del
software, revisiones técnicas, medición, administración de la configuración del software,
administración de la reutilización y preparación y producción del producto de trabajo.
Las dificultades del desarrollo de software
Uno de los problemas más comunes y recurrente en el desarrollo de software es la mala
estimación de los tiempos de trabajo. En la gran mayoría de los casos, los
administradores de proyecto comprometen la entrega de un proyecto estimando ligera
o equivocadamente el tiempo que es necesario invertir para la construcción de los
3
elementos de software necesarios. Dentro del conjunto de causas por las que esta
situación ocurre está aquella derivada de requerimientos muy ambiguos o a “muy alto
nivel” (es decir demasiado generales). Estos requerimientos son conocidos como
“requerimientos de usuario” los cuales hacen referencia a las solicitudes generales de
alto nivel expresado en lenguaje natural por quienes serán usuarios del sistema. Por su
parte, los “requerimientos del sistema” son descripciones detalladas de las
funcionalidades a ofrecer. Posteriormente, durante el análisis o el desarrollo de los
correspondientes programas, se identifica que la complejidad de lo que se desea es más
alta de la que inicialmente se había contemplado en la solicitud y así, más tiempo de
análisis o desarrollo es requerido.
Otra situación que se presenta con gran frecuencia es cuando el cliente solicita que se
haga el desarrollo empleando cierta tecnología y el proveedor, sin tener dentro de su
plantilla programadores con esos conocimientos, toma el proyecto. En el peor de los
casos el administrador de proyecto considera un tiempo muy corto en la curva de
aprendizaje de la tecnología para los desarrolladores que construirán el producto. En el
mejor de los casos se busca contratar desarrolladores con los conocimientos o
habilidades necesarias, aunque es muy posible que no se tenga el criterio suficiente
para evaluar a los candidatos y, al final, se contrate a desarrolladores que no cuenten
con los conocimientos necesarios que requiere el proyecto.
También se puede presentar el caso en el cual los administradores o líderes de
proyecto, al no contar con el conocimiento técnico necesario, propongan el uso de una
nueva tecnología, metodología, proceso, lenguaje, etc. con la idea de que esto será la
“solución mágica” para disminuir los tiempos del calendario. (Brooks, 1986)
La categorización de problemas
Steve McConnell menciona en su libro “Rapid Development: Taming Wild Software
Schedules” la existencia de 36 errores clásicos del software que se dividen en cuatro
categorías: errores relacionados con las personas, procesos, productos y
tecnología(Mcconnell, 1996). A continuación se listan las consecuencias o causas por
las que se producen los errores de software.
Errores relacionados con las personas
o Motivación baja.
o Personal Inadecuado.
o Empleados problemáticos.
o Esfuerzos heroicos.
o Agregar personal a un proyecto retrasado.
o Oficinas ruidosas.
o Fricción entre desarrolladores y clientes.
o Expectativas poco realistas.
o Falta de un patrocinador efectivo del proyecto.
o Falta de compromiso de las partes interesadas.
o Poca participación del usuario.
o Anteponer decisiones políticas sobre el objetivo del proyecto.
o Pensamiento ilusorio.
Errores Relacionados con procesos
o Planificación optimista.
4
o Gestión de riesgos insuficientes.
o Fallo de los proveedores.
o Abandono de la planificación bajo presión.
o Tiempo perdido antes del inicio del proyecto.
o Acortar las tareas de alto nivel (Reducir el tiempo de las actividades que
no producen código).
o Diseño inadecuado.
o Control de calidad deficiente (eliminar revisiones de diseño y código,
realizar pruebas superficiales).
o Control insuficiente de administración del proyecto.
o Preparación del producto para su liberación de forma prematura o con
demasiada frecuencia.
o Omitir tareas necesarias en la estimación.
o Planificar pensando que se recuperara el tiempo perdido.
o Programar a destajo.
Errores relacionados con el producto
o Adición de requerimientos no solicitados por el cliente.
o Cambios de alcance.
o Los desarrolladores añaden características no solicitadas.
o Negociación de tira y afloja.
o Desarrollo orientado a la investigación.
Errores relacionados con la tecnología
o Soluciones mágicas conocidas como silver-bullet.
o Ahorros sobreestimados debido a la utilización de nuevas herramientas
o métodos.
o Cambio de herramientas a la mitad de un proyecto.
o Falta de control automático de código fuente.
Reflexión
La problemática descrita hasta este momento tiene como consecuencia a un producto
de software entregado con una gran cantidad de errores, difícil de mantener,
constituyendo un gran desgaste para las personas involucradas en cada uno de los
ciclos del software. El no apegarse a un proceso o actividad metódica para su desarrollo
puede terminar en un proyecto fracasado o en un problema más que un producto. No
seguir un proceso nos habla de gente y actividades donde no se están realizando tareas
con calidad, donde no hay un plan, y donde tampoco se están contemplando los riesgos
asociados.
Con 10 años de experiencia en el desarrollo de sistemas, el autor de esta tesis ha
observado que independientemente de que el error se haya originado en la fase de
obtención de requerimientos, análisis, diseño o construcción, es la fase de construcción
la que se ve principalmente impactada debido a que las fases anteriores consumieron
más tiempo del planeado. Así, en muchas ocasiones, los programadores tienen que
comenzar la codificación con la misión de recuperar el tiempo perdido. Si a estos
problemas le sumamos el comenzar un desarrollo sin tener una arquitectura definida,
sin uso de estándares, los problemas se incrementarán y cobrarán un papel protagónico
sobre el verdadero objetivo del proyecto o desarrollo buscado.
5
Historia de grandes errores de software
Se han mencionado las situaciones que se presentan durante el desarrollo del software
y las consecuencias o errores que originan la falta de calidad. En esta sección se
mencionarán casos históricos relacionados con errores de software y las pérdidas
económicas y humanas que ocasionaron estos errores.
Uno de los errores de software más conocidos de la historia fue el Y2K que se
temía tuviera consecuencias letales y que trascendiera en otros sectores
además del mundo de la informática. Este error estaba relacionado con las
fechas que se almacenaban en los equipos de cómputo, únicamente se
utilizaban dos números en lugar de cuatro para indicar el año. Por ejemplo, para
el año “1991” únicamente se utilizaba el “91”, la razón de esto era para ahorrar
espacio de almacenamiento y memoria pensando que para el año 2000 los
sistemas de cómputo ya estarían obsoletos.
A pesar de lo que se creyó muchos sistemas seguían vigentes próximos al año
2000 y se comenzó a ajustar los sistemas para garantizar que estuvieran
preparados para el error del cambio de milenio, se suponía que una vez
alcanzado el año 2000, las computadoras y sistemas informáticos marcarían el
año 2000 como el año 00 sin que esto significar el cambio de siglo, sino que los
sistemas tomarían este valor como 1900 ocasionando que fallaran los sistemas
primarios, las compañías bancarias. El costo de este error ascendió a 214,634
millones de Euros, se cree que el costo de no realizar ajustes a los sistemas
informáticos hubiera sido de 164,156 millones de Euros.(Koldobica Gotxone
Villar & Rivas, 2012)
El 15 de enero de 1990 el software instalado en los en los procesadores frontales
de 114 de los sistemas de conmutación 4ESS de la compañía telefónica
American Telephone and Telegraph Company (AT&T) presentaron un problema
mecánico y desactivó el centro. Cuando éste volvió a estar habilitado, envió un
mensaje a los otros nodos haciendo que todos ellos dejaran de funcionar, lo que
provocó una caída de 9 horas en la red de la compañía. El costo de este error
fue aproximadamente de $60 millones de dólares al dejar aproximadamente a
60,000 clientes sin comunicación en llamadas de larga distancia.(“The Crash of
the AT&T Network in 1990,” 1990)
Han existido errores de software en misiones de la NASA, los cuales van desde
errores de proceso hasta errores de diseño, esto ha ocasionado la pérdida de
datos científicos hasta pérdidas de misiones enteras. El orbitador climatológico
de Marte diseñado para orbitar Marte como el primer satélite meteorológico
interplanetario se quemó en la atmósfera marciana en 1999 después de haber
perdido su inserción orbital, la falla se originó al realizar la transferencia de
información entre el equipo de la nave espacial Mars Climate Orbiter en Colorado
y el equipo de navegación de la misión en California, mientras que un equipo
utilizo unidades de medición inglesas (pulgadas, pies, yardas), el otro equipo
utilizó el sistema métrico decimal (centímetros, metros, kilómetros) para una
operación clave de la nave espacial.(“Mars Climate Orbiter team finds likely
cause of loss,” 1999) Este error tuvo un costo de $125 millones de
dólares.(Pollack, 1999)
6
Uno de los accidentes más conocidos relacionados con el software está
relacionado con el Therac-25, un acelerador médico de uso dual, tenía la
capacidad de emitir electrones de baja intensidad o un haz de rayos X. Los rayos
X se conseguían a través de un impacto de alta energía sobre una placa
metálica la cual estaba situada entre el acelerador y el paciente. Los accidentes
se presentaban cuando se disparaba el haz de electrones de alta energía en
lugar del haz de baja energía sin que estuviera la placa difusora en el lugar, esto
provocaba que el paciente recibiera una dosis de radiación potencialmente letal.
Al realizarse la investigación sobre las causas del problema del Therac-25 la
comisión investigadora concluyo que existían malas prácticas en el desarrollo
de software, un mal análisis de requerimiento, diseño erróneo y errores de
código. Este error de software trajo como resultado cinco muertos entre 1985 y
1987.(“Fracasos de software,” n.d.)
El 4 de junio de 1996 la Agencia Espacial Europea explotó el cohete Ariane 5 a
los 38 segundos de haber despegado, el cohete de que había sido diseñado
para colocar dos satélites de tres toneladas en cada lanzamiento estallo sobre
la costa de Guyana Francesa. La causa de la explosión se presentó al re utilizar
el acelerómetro del Ariane 4 que manejaba número de 16, no se consideró era
infinitamente superior y tenía que manejar números de coma flotante de 64 bits,
por lo tanto la información que se obtenía al transformar los números de 64 bits
a 16 era errona lo cual ocasiono un error de desbordamiento. El costo estimado
de este error fue de 500 millones de dólares y una década de desarrollo.(Lions,
1996)(Koldobica Gotxone Villar & Rivas, 2012)
La guerra fría fue un enfrentamiento que se dio entre los Estados unidos y la
Unión Soviética al finalizar la segunda guerra mundial. Los países anteriormente
mencionados no se enfrentaron directamente desde el punto de vista militar sin
embargo si existía una gran tensión debido a que las dos potencias se vigilaban
una a la otra a través de sus sistemas de detección. El sistema OKO (ojo en
ruso) era el sistema de alerta que utilizaba la Unión Soviética, este sistema se
encontraba basado en satélites que apuntaban a las principales bases de
lanzamiento y su función era detectar lanzamiento de misiles de los Estados
Unidos.
El 24 de septiembre el sistema OKO detecto el lanzamiento de un misil desde la
base de Malmstrom en Montana, el cual resulto ser una falsa alarma. Se
dictaminó que el Sol, la Tierra y el satélite OKO habían experimentado una
alineación que provocó que la luz solar reflejada en las nubes se confundiera
con el lanzamiento de un misil.(Velasco, 2014)
La nave espacial Mariner I fue lanzado el 22 de julio de 1962 desde Cabo
Cañaveral florida que tenía como primera misión sobrevolar Venus, sin embargo
el vehículo tuvo que ser destruido 293 segundos después del lanzamiento. Un
error de programación del software, el cual consistía en a omisión de un guion
en las instrucciones del programa de edición de datos provocó que el vehículo
desviara su rumbo en una posible dirección del Atlántico Norte o una zona
habitada, por esta situación se envió el comando destrucción. El costo de este
error fue de 18.5 millones de dólares.(National Aeronautics and Space
Administration, 1962)
7
Herramientas generadoras de código
La generación automática de código fue visto en algún momento como el fin a la
existencia del programador. Escuelas y tendencias como los “lenguajes de 4ta
generación”, las “computadoras de 5ta generación” y el “computer aided design” fueron
vistas o enarboladas como la solución para que el usuario final pudiera directamente
hacer uso de un computador sin programación (ni programadores) de por medio. El
tiempo, sin embargo, ha demostrado otra cosa.
A pesar de lo anterior, cierta capacidad de automatización se ha logrado en las
actividades de programación y desarrollo de sistemas de información. Mucho de esto a
través de los llamados “Integrated Development Environments” (IDE) y herramientas
CASE (Computer Aided Software Engineering). En esta sección revisamos algunos
productos generadores de código.
Visual Studio
Visual Studio es un entorno de desarrollo integrado el cual permite el desarrollo de
aplicaciones de escritorio, web, moviles, servicios web, etcétera. Se enfoca
principalmente para sistemas operativos Windows. Es un entorno que cuenta con un
asistente el cual da la opción de autocompletar instrucciones o proporcionar ayuda para
los lenguajes C#, Visual Basic, C++, javaScript. (“IDE de Visual Studio,” n.d.)
La Figura 1 muestra el IDE de Visual Studio tiene la opción de hacer uso de templates,
es decir; al momento de crear un proyecto se puede seleccionar la opción de contar con
un proyecto de ejemplo. El uso de templates o plantillas pueden servir como base para
comenzar ela fase de desarrollo debido a que se generá codigo de manera automatica
como se puede apreciar en la Figura 2. El problema de hacer uso de este tipo de
templates es que son genéricos y no siempre se adaptan a la arquitectura deseada.
Figura 1. IDE Visual Studio 2017
8
Figura 2. Código generado de forma automática.
Smart Code Generator
Smart Code Generator es un generador de código el cual tiene como interfaz una
aplicación web ASP.NET. Este generador de código permite generar archivos en VB y
C# haciendo uso de plantillas las cuales se pueden personalizar dinámicamente. Las
plantillas son controles de usuario ASCX. Las plantillas se alojarán dentro del directorio
template, se puede crear plantillas para entidades, acceso a datos. (“Smart Code
Generator (Asp.Net),” 2009)
La principal desventaja al utilizar este generador de código es que sólo se puede
desarrollar con Visual Studio 2005 o Visual Studio 2008. Además de que se tendrán que
escribir el código para crear las plantillas. La figura 3 muestra como está construida la
solución Smart Code Generator.
Figura 3. Proyecto Smart Code Generator. Fuente: Elaboración propia.
9
ASPRunner.NET
ASPRunner:NET es un generador de código para ASP.NET, esta herramienta permite
generar una aplicación web que permite crear, eliminar, modificar y buscar datos en los
manejadores de bases de datos Oracle, SQL Server, MS Access, PostgresSQL,
MySQL. Cuenta con una gran cantidad de fondos con estilos diferentes. La principal
ventaja de esta herramienta es que es muy fácil de usar, la generación de la aplicación
web no requiere programación y se puede lograr en cuestión de
minutos.(“ASPRunner.NET - code generator for ASP.NET,” 2017)
El principal punto en contra de esta herramienta es que crea demasiadas clases en el
proyecto lo cual hace compleja la tarea de modificación del código además de que es
un software que se tiene que comprar.
Figura 4. ASPRunner.NET. Fuente: XLineSoft.
Consecuencias
Actualmente existe una gran cantidad de herramientas que hacen uso de plantillas
haciendo más simple la actividad de codificación, estas plantillas generan artefactos que
se pueden tomar como base para comenzar el desarrollo. Sin embargo, la mayoría de
estas herramientas genera código que se tiene que modificar debido a que sólo crea
una funcionalidad básica que generalmente no se ajusta o cubre con lo que se necesita.
Adicionalmente, como efecto colateral, al realizar modificaciones a lo generado por la
herramienta se pueden insertar defectos, ocasionando que la calidad del sistema
disminuya.
Si a lo anterior le sumamos que el desarrollo de sistemas es una actividad creativa en
la cual cada programador tiene un estilo distinto de programar. Un sistema de software
que no tiene un estándar de programación corre el riesgo de insertar defectos cuando
se tenga que modificar código por un programador distinto a su creador. Además, el
incremento de tiempos de construcción es resultado del análisis que se necesitará para
entender que es lo que hace el código siendo modificado. También se puede presentar
el caso de que se tengan programados bloques de código por distintas personas con la
misma funcionalidad (duplicidad).
10
Capítulo II
Patrones de diseño y frameworks actuales
En este capítulo se habla sobre calidad y la relación de los atributos de calidad en los
sistemas de software, se presenta y explora distintas alternativas y soluciones que se
han elaborado para atacar los problemas de la calidad del software, como el uso de
procesos, metodologías, estándares, modelos. Se observará que varías de las técnicas
mencionan el termino de reutilización, esto desde un sentido a alto nivel como los
patrones arquitectónicos o los patrones de diseño hasta un punto muy fino como pueden
ser los componentes.
Calidad
Los primeros grandes sistemas de software no eran muy confiables, sus tiempos de
respuesta eran lentos, eran difíciles de mantener. A consecuencia de esto surgieron
técnicas para la gestión de calidad, y la adopción de procesos. Junto con lo anterior,
nuevas tecnologías permitieron obtener mejoras en la funcionalidad y capacidad de los
sistemas de información pero su complejidad incrementó, así como el tiempo de
desarrollo asociado.
En la industria manufacturera, la calidad se define como la conformidad con una
especificación de producto detallada y la noción de tolerancia. Sin embargo, esta
definición no se puede aplicar directamente al software por las siguientes razones:
1. Es prácticamente imposible escribir especificaciones sin ambigüedades, los
desarrolladores y los clientes pueden interpretar los requerimientos de distintas
formas.
2. Los sistemas de software grandes no incluyen los requerimientos de todos los
interesados. En estas situaciones es posible que las personas excluidas
consideren el sistema de baja calidad debido a que no se implementa la
funcionalidad que ellos requieren.
3. Si se piensa en las características de calidad, algunas son difíciles de medir o
pueden presentar ambigüedades.
En el desarrollo de software, la calidad considera que el sistema cumpla los
requerimientos funcionales, es decir, que la especificación definida esté implementada
en el sistema. También debe considerar que se cumplan ciertos requerimientos no
funcionales, los cuales se conocen también como atributos de calidad del software.
La calidad de software se define como “Proceso eficaz de software aplicado de una
manera que crea un producto útil que proporciona valor medible a quienes lo producen
y a quienes lo utilizan.”(Roger S. Pressman & Bruce R. Maxim, 2015)
Atributos de calidad
Los atributos de calidad son características que se pueden medir, expresar y evaluar
el grado de satisfacción de los usuarios. Los atributos de calidad más comunes
son(“Quality Attributes,” n.d.):
11
Seguridad: Es la capacidad que tiene un sistema para proteger el acceso de
forma accidental o intencional.
Portabilidad: Es la facilidad para modificar un sistema con la finalidad de que
opere en un entorno distinto (servidor o sistema operativo) para el cual fue
desarrollado inicialmente.
Usabilidad: Es la facilidad con la que los usuarios pueden aprender y utilizar un
sistema.
Rendimiento: Es la velocidad de tiempo de procesamiento, el tipo de respuesta
de un sistema para ejecutar una acción dentro de un intervalo de tiempo.
Confiabilidad: Es la capacidad de un sistema para operar sin fallas. Las
mediciones que se realizan para este atributo de calidad son el tiempo promedio
entre fallas, ocurrencia de fallas.
Mantenibilidad: Es la facilidad con la que se puede modificar un sistema de
software. Los cambios pueden consistir en agregar nuevas funcionalidades,
mejorar el rendimiento o corregir defectos.
Reutilización: Esta característica define la capacidad de los componentes,
módulos, subsistemas para ser adecuados en otras aplicaciones o escenarios.
Este atributo tiene como principal objetivo duplicidad de componentes y tiempo
de implementación.
Interoperabilidad: Es la capacidad que tiene un sistema de funcionar de forma
exitosa mediante la comunicación y el intercambio de comunicación con
sistemas externos los cuales pueden ser desarrollados con una tecnología
totalmente distinta.
Escalabilidad: Esta característica consiste en incrementar la capacidad del
sistema sin realizar cambios.
Disponibilidad: Capacidad de un sistema para permanecer funcionando sin
detener su operación. Este atributo se puede medir obteniendo el porcentaje de
inactividad total de un sistema durante un periodo predefinido.
Es recomendable expresar los atributos de calidad de manera cuantitativa y debe ser
acorde al requerimiento, sistema o entorno para el cual se está desarrollando; un
sistema bancario deberá considerar de manera más rigurosa el atributo de calidad
seguridad que un sistema de encuestas escolares.
La ganancia de algunos atributos puede significar que otros se vean afectados de forma
negativa. Por ejemplo, un sistema que requiera tener implementado como atributo de
calidad la seguridad verá afectado el atributo de calidad rendimiento. También, se debe
ser consciente que exigir métricas excesivas para los atributos de calidad puede
ocasionar que se tomen decisiones de diseño complejas y costosas.(“Quality Attributes,”
n.d.) (Mcconnell, 2004)
Es fundamental identificar los atributos de calidad en la fase de análisis y definición de
requerimientos con el fin de generar un diseño arquitectónico que pueda satisfacer los
requerimientos no funcionales del sistema. Existen algunas recomendaciones para
identificar estos atributos:
Identificar los objetivos de negocio del sistema.
iniciar la documentación de los casos de uso principales.
12
Al realizar las entrevistas para la obtención de requerimientos realizar preguntas
para obtener información relacionada con los atributos de calidad.
Identificar métricas para los atributos de calidad, es importante que estas
métricas tengan un sustento, es decir; que se encuentren alineadas a las
necesidades del negocio del sistema.
Priorizar y verificar los atributos de calidad.(Cervantes, 2010)
Estándares
Los estándares de software son un punto primordial para el manejo de la calidad debido
a que reflejan las prácticas aprendidas en los proyectos anteriores con el fin de no volver
a cometer los mismos errores. También asegura que los ingenieros dentro de una
organización adopten las mismas prácticas, con esto se puede reducir el esfuerzo de
aprendizaje.
Existen dos tipos de estándares en la ingeniería de software, el primero es estándares
de producto, el cual contempla estándares de documentos, estándares de codificación.
El segundo estándar define cuales son los procesos que deben seguirse durante el
desarrollo de software, pueden incluir las herramientas a utilizar, que documentos se
escribirán durante dicho proceso, estos es conocido como estándares del proceso.
La medición y las métricas de software forman parte de la calidad, inicialmente se
comienzan a tomar mediciones de defectos encontrados en un sistema y se van
registrando, estas son conocidas como métricas del producto, posteriormente se
combinan para desarrollar métricas públicas para el equipo de software, conocidas
como métricas del proyecto, conforme se van desarrollando sistemas se van
consolidando para crear métricas de proceso, las cuales son públicas para la
organización.(Roger S. Pressman & Bruce R. Maxim, 2015) Algunas de las métricas
utilizadas en el software son:(Sommerville, 2011)
Métricas orientadas a tamaño.
o Fan-in/Fan-out (abanico de entrada/abanico de salida).
o Longitud de código.
o Complejidad ciclomática.
o Longitud de identificadores.
o Profundidad de anidado condicional.
o Índice Fog.
Métricas orientas a función.
o Punto de función (PF).
Métricas orientadas a objeto.
o Métodos ponderados por clase (weighted methods per class, WMC).
o Profundidad de árbol de herencia (depth of inheritance tree,tree, DIT).
o Número de hijos (number of children, NOC).
o Acoplamiento entre clases de objetos (coupling between object classes,
CBO).
o Respuesta por clase (response for a class, RFC).
o Falta de cohesión en métodos (lack of cohesion in methods, LCOM).
Métricas orientadas a casos de uso.
o Puntos de casos de uso (PCU).
13
Métricas de proyectos web App.
o Número de páginas web estáticas.
o Número de páginas web dinámicas.
o Número de vínculos de página internos.
o Número de objetos de datos persistentes.
o Número de sistemas externos puestos en interfaz.
o Número de objetos de contenido estáticos.
o Número de objetos de contenido dinámicos.
o Número de funciones ejecutables.
Arquitectura de software
El diseño arquitectónico es la primera etapa en el proceso de diseño de software. En él
se enlaza el diseño y la ingeniería de requerimientos. La salida del proceso de diseño
arquitectónico es un modelo que describe la manera en se organiza un sistema como
un conjunto de componentes en comunicación.
Es importante definir la arquitectura de software debido a que se considera desde antes
de comenzar la fase de construcción los requerimientos no funcionales, que pueden ser:
el desempeño, escalabilidad, seguridad, interoperabilidad y capacidad de
mantenimiento. Las ventajas de diseñar y documentar la arquitectura son las siguientes:
Fácil comunicación con todos los involucrados: Debido a que la arquitectura es
una representación a alto nivel del sistema permite que todos los involucrados
tengan un panorama del sistema de una forma rápida.
Análisis del sistema: Permite que desde una etapa temprana se consideren
atributos de calidad con los cuales contara el sistema.
Reutilización a gran escala: El modelo de una arquitectura de un sistema es una
descripción de cómo está organizado un sistema y cuál es la relación entre sus
componentes. De forma ideal se busca que los sistemas que tengan
requerimientos similares estén construidas bajo la misma arquitectura lo cual
permite la reutilización del software a gran escala.
El diseño arquitectónico es una actividad creativa del arquitecto, quien con base a su
experiencia y considerando los requerimientos funcionales y no funcionales definirá el
diseño arquitectónico. Los arquitectos deben de considerar las siguientes preguntas
sobre el sistema para tomar la decisión de que diseño arquitectónico
utilizar:(Sommerville, 2011)
¿Existe alguna arquitectura de aplicación genérica que actúe como plantilla para
el sistema que se está diseñando?
¿Cómo se distribuirá el sistema a través de algunos núcleos o procesadores?
¿Qué patrones o estilos arquitectónicos pueden usarse?
¿Cómo se realizara la segregación de componentes estructurales del sistema?
¿Qué estrategia se usará para controlar la operación de los componentes en el
sistema?
¿Cuál organización arquitectónica es mejor para entregar los requerimientos no
funcionales del sistema?
¿Cómo se evaluará el diseño arquitectónico?
¿Qué artefactos se crearan la arquitectura del sistema?
14
Como se ha mencionado anteriormente hay una relación directa entre los
requerimientos no funcionales y la arquitectura de software. Por ejemplo, si la aplicación
debe considera la seguridad como uno requerimientos críticos será necesario
considerar una estructura de capas.
Los patrones arquitectónicos también conocidos como estilos arquitectónicos se pueden
considerar como una descripción abstracta de un nivel mayor que los patrones de
diseño. Un patrón arquitectónico expresa un esquema de organización estructural
esencial para un sistema de software, que consta de subsistemas, sus
responsabilidades y relaciones entre ellos.(Roger S. Pressman & Bruce R. Maxim,
2015)(Sommerville, 2011) Algunos patrones arquitectónicos son:
Arquitectura en capas. El patrón de arquitectura en capas soporta el desarrollo
incremental. Tiene la facilidad de cambiar una capa por otra mientras la interfaz
no cambie. Generalmente este patrón se utiliza cuando el desarrollo del sistema
se está realizando por varios equipos de trabajo, de esta manera los equipos
pueden estar trabajando en paralelo en una capa distinta; también se utiliza
cuando hay un requerimiento de seguridad multinivel.
Arquitectura de repositorio. El uso de este patrón es recomendable en sistemas
que manejan grandes volúmenes de datos se organizan sobre un repositorio
compartido. En este patrón los componentes no interactúan entre ellos, solo lo
hacen a través del repositorio.
Arquitectura cliente-servidor. En una arquitectura cliente-servidor la
funcionalidad del sistema se rige por servicios en donde cada servicio lo entrega
un servidor independiente. Esta arquitectura se utiliza cuando desde varias
ubicaciones se tiene que acceder a una base de datos compartida.
Arquitectura de tubería y filtro: Generalmente se utiliza en aplicaciones de
procesamiento por datos, donde las entradas se procesan en etapas separadas
para generar salidas relacionadas.
MVC (Modelo Vista Controlador): Esta arquitectura separa la presentación e
interacción de los datos del sistema. Está compuesta de tres componentes
lógicos: el modelo que maneja los datos del sistema, el componente vista se
encarga de presentar los datos al usuario y el componente controlador dirige la
interacción del usuario y pasa estas interacciones a la vista y modelo. Se usa
cuando existen varias maneras de ver e interactuar con los datos.
Arquitectura orientada a servicios: Esta arquitectura donde el software está
construido por una composición de servicios. Está diseñado para que los
sistemas de información sean escalable y flexible a nuevos requerimientos,
brinda una forma bien definida de exposición e invocación de servicios lo cual
facilita la interacción con sistemas desarrollados con distintas tecnologías.
Patrones de diseño
El diseño y la implementación del software son actividades fuertemente vinculadas de
la ingeniería de software que en conjunto generan un sistema de software ejecutable.
El diseño de software es una actividad en la cual se identifican los componentes de
software y sus relaciones que cubren los requerimientos del sistema. La implementación
consiste en tomar como insumo los artefactos de diseño para crear un programa.
(Sommerville, 2011)
15
El arquitecto Austriaco Christopher Alexander, reconocido por sus diseños de edificios
en California, Japón y México define el termino patrón de la siguiente manera “Cada
patrón describe un problema que ocurre una y otra vez en nuestro entorno, para
describir después el núcleo de la solución a ese problema, de tal manera que esa
solución pueda ser usada más de un millón de veces sin hacerlo ni siquiera dos veces
de la misma forma”(Christopher Alexander, Sara Ishikawa, 1977). Alexander dio la
definición anterior para ciudades y edificios esto también es válido para patrones de
diseño orientado a objetos, esta es la razón por la que se ha reconocido a Alexander
como el padre del movimiento “pattern language” en ciencias de la computación.
Los patrones de diseño se pueden definir como una descripción de un problema y la
solución a esta solución pueda reutilizarse para resolver problemas de la misma índole.
Un patrón debe de contar con los siguientes cuatro elementos:
1. El nombre del patrón.
2. Descripción del problema en el cual se aplica el patrón.
3. Descripción de solución de las partes de la solución de diseño, sus relaciones,
responsabilidades y colaboraciones. En este caso la solución se puede ver
como una plantilla que puede aplicarse en situaciones distintas.
4. Las consecuencias, ventajas e inconvenientes de utilizar este patrón.
Un punto importante para la reutilización de los sistemas consiste en estar anticipado a
nuevos requisitos y a los cambios de los requerimientos actuales, para prever la
situación anterior es necesario diseñar sistemas que puedan evolucionar. Los patrones
de diseño ayudan a elegir alternativas de diseño que hacen que un sistema sea
reutilizable y extensible. Se revisará de forma breve tres clases de software en donde
se hace uso de los patrones de diseño:
Programas de aplicación: Este tipo de aplicaciones busca la reutilización interna
lo cual se logra implementando lo estrictamente necesario. En este caso los
patrones de diseño que reducen dependencias pueden aumentar la reutilización
interna. También se busca que sean fáciles de mantener, los patrones de diseño
permite que las aplicaciones sean más fáciles de mantener al limitar la
dependencia de plataforma utilizando patrones como Abstract Factory o Bridge.
Toolkits: Los toolkits son un conjunto de clases predefinidas que proporcionan
funcionalidad útil de propósito general. Evitan a los desarrolladores el programar
funcionalidad común lo cual se puede interpretar como reutilización de código.
Frameworks: Un framework es un conjunto de clases cooperantes que
constituyen un diseño reutilizable para una clase especifica de
software(Johnson, 2001). El cual se personaliza para una aplicación específica,
el framework define la arquitectura de la aplicación que hará uso de él. Definirá
su estructura general, su partición en clases y objetos, las responsabilidades
claves, la relación que existe entre clases y objetos. Además de tener
predefinido los parámetros de diseño, con esto el programador solo se enfocará
en las particularidades de la aplicación.
Al hacer uso de un framework se está perdiendo la parte creativa del diseñador
o programador, sin embargo, la ventaja que se tiene al tomarlo como referencia
es que el desarrollo de aplicaciones se realizara de una forma más rápida. Las
aplicaciones desarrolladas bajo el mismo framework tendrán estructuras
16
parecidas, por lo cual el mantenimiento de las aplicaciones se agilizará. Además
de la utilización de patrones de diseño, por lo cual es más probable que sea
reutilizable(Gamma, 2002).
Los patrones de diseño se encuentran agrupados de la siguiente manera(Eric Freeman,
Elisabeth Freeman, Bert Bates, 2013):
Patrones creacionales, tienen que ver con el proceso de creación e
inicialización de objetos, los patrones más conocidos son:
o Fábrica Abstracta (Abstract Factory): Tiene como propósito crear familias
de objetos relacionados o que dependan entre sí, por ejemplo la creación
de interfaces graficas de distintos tipos.
o Constructor (Buider): El propósito de este patrón es separar la
construcción de un objeto complejo a partir de su representación, de tal
manera que al ejecutarse el mismo proceso de construcción pueda crear
diferentes representaciones.
o Método de Fabricación (Factory Method): Este patrón permite que una
clase delegue a las subclases la creación de los objetos.
o Prototipado (Prototype): Se basa en la creación de objetos copiados de
un prototipo.
o Singleton (Único): Restringe la creación de solo una instancia por clase.
o MVC (Modelo Vista Controlador): El propósito general de este patron es
establecer la separación del problema en tres capas: la capa model que
corresponde a la representación de las entidades de negocio utilizadas
en la aplicación, la capa view en la que se encarga de desplegar los
datos de la capa model y la capa controller quien es el encargado de
recibir y procesar las peticiones.
Patrones de comportamiento, se centra en describir en cómo interactúan las
clases y objetos, los patrones más conocidos son:
o Cadena de responsabilidad (Chain of responsibility): La base de este
patrón es permitir a más de un objeto atender una petición.
o Orden (Command): Encapsula la petición en un objeto dando la
posibilidad de deshacer la petición.
o Intérprete (Interpreter): El objetivo de este patrón es interpretar un
lenguaje definido anteriormente mediante su gramática.
o Iterador (Iterator): Define la forma de acceder secuencialmente a los
elementos de un objeto sin necesidad de exponer su estructura interna.
o Mediador (Mediator): Define la relación de un conjunto de objetos. El
objetivo de este patrón es conseguir un bajo acoplamiento entre los
objetos.
o Recuerdo (Memento): Almacena el estado de un objeto con la finalidad
de que el objeto pueda regresar a este estado más tarde.
o Observador (Observer): Notifica el cambio de estado de un objeto a
todos los objetos que dependan de él.
o Estado (State): El objetivo de este patrón es cambiar el comportamiento
de un objeto cuando cambia su estado.
o Estrategia (Strategy): Una vez definida una familia de algoritmos permite
la selección de uno de ellos.
17
o Método plantilla (Template Method): Define el esqueleto de un algoritmo
en una operación, donde las subclases pueden redefinir los pasos sin
cambiar su estructura.
o Visitante (Visitor): Permite definir nuevas operaciones sin cambiar las
clases de los elementos que utiliza.
Patrones estructurales, trata con la composición de clases u objetos, los
patrones más conocidos son:
o Adaptador (Adapter): Convierte la interfaz de una clase en otra distinta.
o Puente (Bridge): Desacopla una abstracción de su implementación
permitiendo modificarlas independientemente.
o Objeto Compuesto (Composite): Este patrón es utilizado para construir
objetos compuestos a partir de objetos simples, utiliza composición
recursiva y estructura de árbol.
o Envoltorio (Decorator): Permite agregar funcionalidad de forma dinámica
a un objeto, le da flexibilidad a la herencia para extender la funcionalidad.
o Fachada (Facade): Proporciona una interfaz unificada para un conjunto
de interfaces de un subsitema.
o Peso Ligero (Flyweight): Elimina la redundancia cuando tenemos objetos
con la misma información.
o Apoderado (Proxy): Proporciona un objeto sustituto para controlar el
acceso a otro objeto.
Procesos de desarrollo
Un proceso de software es un conjunto de actividades relacionadas que conduce a la
elaboración de un producto de software.(Sommerville, 2011) Inicialmente este conjunto
de actividades incluían el desarrollo de software desde cero sin embargo hoy en día se
desarrolla agregando funcionalidad a sistemas existentes, o mediante integración de
componentes o configurando software comercial.
Los procesos de software deben incluir cuatro actividades básicas que son:
1. Especificación del software.
2. Diseño e implementación del software.
3. Validación del software.
4. Evolución del software.
En la especificación del software tiene como finalidad obtener y entender los servicios
que requiere el sistema, en esta actividad se debe obtener un documento de
requerimientos que cumplirá el sistema. En esta etapa existen cuatro actividades
primordiales que son: estudio de factibilidad, obtención y análisis de los requerimientos,
especificación de los requerimientos y por último la validación de los requerimientos.
La etapa de diseño e implementación de software tiene como finalidad convertir la
especificación obtenida en la etapa anterior en un producto ejecutable. En esta etapa
también se realiza la actividad de programación y pruebas del código desarrollado.
La validación de software abraca la verificación y validación, es decir, revisar y aprobar
el software, esta etapa abarca una gran cantidad de actividades de prueba como son:
pruebas de desarrollo, de sistema y de aceptación.
18
La evolución del software más conocido como mantenimiento de software es muchas
veces lucrativo que el desarrollo en sí.
Las descripciones de los procesos deben incluir los productos, que son los resultados
finales de una actividad del proceso; roles, precondiciones y postcondiciones.
Modelos de proceso prescriptivo
Los modelos de proceso prescriptivo también conocidos como modelos de proceso
tradicional tienen como objetivo mejorar la calidad del sistema de software, administrar
los proyectos de tal forma que se puedan estimar los tiempos y recursos de una manera
más exacta, guiar a los involucrados del proyecto en las actividades que realizan. Sin
embargo, el no adaptar el proceso a las necesidades del proyecto puede generar
burocracia y alentar el desarrollo de los sistemas.
Los modelos de proceso prescriptivos buscan generar estructura y orden(Roger S.
Pressman & Bruce R. Maxim, 2015). Establecen actividades estructurales, tareas,
productos a elaborar, aseguramiento de calidad y mecanismos de control de cambio
para el proyecto. Además de establecer la manera en que los elementos del proceso se
relacionan entre sí.
Modelo de cascada
El modelo de cascada es un proceso que está dirigido por un plan, de manera inicial se
debe planear y programar todas las actividades antes de comenzar a trabajar en ellas.
Las principales etapas del modelo de cascada son:
1. Análisis y definición de requerimientos.
2. Diseño del sistema y del software.
3. Codificación y pruebas unitarias
4. Integración y pruebas del sistema
5. Operación y mantenimiento.
Cada fase generará insumos para la fase siguiente, por ejemplo en la fase de análisis y
definición de los requerimientos se genera la especificación del sistema que será el
insumo para la fase de diseño del sistema y del software. No se puede comenzar una
fase hasta que se haya concluido la fase anterior.
19
Figura 5. Modelo de cascada. Fuente: Elaboración propia.
La figura 5 muestra el modelo de cascada el cual es el paradigma más antiguo de la
ingeniería de software(Roger S. Pressman & Bruce R. Maxim, 2015), debe de usarse
preferentemente cuando se tenga bien definidos los requerimientos, se tenga la
seguridad que estos no cambiarán y que el trabajo seguirá las fases establecidas de
forma lineal Uno de los problemas que puede enfrentar el desarrollo de software
utilizando este proceso es que no se tendrá una versión funcional del sistema hasta una
etapa muy avanzada del proyecto, en donde un error puede ser muy costoso.
Desarrollo incremental
El desarrollo de software incremental consiste en generar una versión inicial del sistema
y posteriormente se realizarán incrementos agregando nueva funcionalidad. En este tipo
de desarrollo los primeros incrementos contendrán la funcionalidad más importante o
necesaria del sistema.
Este tipo de desarrollo tiene como principales ventajas la adaptación a cambios en los
requerimientos, se puede realizar entregas en etapas muy tempranas del proyecto y con
esto obtener retroalimentación por parte del cliente.
Las principales desventajas de este modelo son a nivel administrativo, el proceso no es
visible por los tanto los administradores necesitan entregas regulares para medir el
avance del proyecto. Conforme se va avanzando en los incrementos el software tiende
a degradarse, la incorporación de cambios al sistema se hace más compleja. La figura
6 muestra la representación del desarrollo incremental.
20
Figura 6. Desarrollo incremental. Fuente: Elaboración propia.
Ingeniería de software orientada a la reutilización
Es difícil imaginar que los proyectos no hagan uso de la reutilización del software, este
pude ser desde unas cuantas líneas de código hasta el uso de métodos, clases o
módulos. El enfoque orientado a la reutilización es el de hacer uso de una base de
componentes de software reutilizable. Las etapas involucradas en el proceso orientado
a la reutilización son:
1. Análisis de componentes.
2. Modificación de los requerimientos.
3. Diseño de sistema con reutilización.
4. Desarrollo e integración.
Existen tres tipos de componentes de software que pueden ser usados en el paradigma
de la reutilización de software:
1. Servicios web. Los cuales son desarrollados con la finalidad de ofrecer servicios
que puedan ser invocados de forma remota independientemente e interoperable.
2. Conjunto de objetos que se desarrollan como un paquete para su integración
con un marco de componentes.
3. Sistemas de software independientes.
Hacer uso de este modelo tiene como principal ventaja la disminución de elementos de
software a desarrollar y con esto reducir los tiempos de entrega así como también
disminuir la cantidad de defectos en la construcción.(Sommerville, 2011)
Implementación
Pruebas
Evaluacón
Planeación
Análisis y Diseño
Planeación inicial
Despliegue
21
Modelos de proceso evolutivo
Los modelos de proceso evolutivo son iterativos y tienen como principal característica
generar versiones cada vez más completa del sistema de software. Estos tipos de
modelos se utilizan en situaciones cuando el cliente tiene definidos los requerimientos
básicos del sistema pero no tienen todos los detalles del producto o hay extensiones del
sistema que están por definirse, también se utiliza en situaciones donde por cuestiones
de competencia se tiene que lanzar una versión del sistema al mercado a la cual se le
ira agregando funcionalidad en cada iteración. Dos de los modelos más comunes de
proceso evolutivo son los prototipos y el modelo de espiral.
Prototipos
Un prototipo es una versión inicial del sistema el cual tiene como finalidad mostrar la
funcionalidad de una manera rápida al cliente. No deben ser necesariamente
ejecutables, de hecho, sólo pueden realizar con un papel y lápiz. En el proceso de
ingeniería de requerimientos un prototipo puede servir para apoyar en la validación de
los requerimientos del sistema, en el proceso de diseño de sistema puede apoyar en el
diseño de interfaces de usuario.
Modelo espiral
En el modelo de espiral, el sistema de software se crea mediante una serie de entregas
evolutivas donde cada una de las entregas se realiza de acuerdo al ciclo de vida clásico,
como primera entrega se puede entregar un prototipo y en las iteraciones siguientes se
producen versiones más completas del sistema. Este modelo puede utilizarse durante
todo el tiempo que se encuentre un sistema de software activo. La figura 7 muestra el
comportamiento del modelo de espiral.
Figura 7. Modelo de espiral. Fuente: Ingeniería Del Software, Roger S, Pressman.
22
Ingeniería de software basada en componentes
La ingeniería de software basada en componentes (CBSE) surgió a finales de las
década de 1990 con la finalidad de desarrollar sistemas de software basado en la
reutilización de componentes de software. El paradigma del desarrollo a objetos no
conducía a la reutilización que se había considerado originalmente.
Actualmente la ingeniería de software basada en componentes es considerada como la
mejor manera de diseñar, construir, implementar software de una forma rápida y a un
costo bajo, siempre y cuando se seleccionen los componentes óptimos. Las
aplicaciones de software son construida por una gran variedad de componentes
desarrollados en distintos lenguajes de programación y pueden ser ensamblados de una
manera transparente, también se puede dar el caso de que los componentes sean
desarrollados en el mismo lenguaje, en esta caso se dice que son de naturaleza
heterogénea. (Sharma, Kumar, & Kavita, 2016)
La especificación OMG del Lenguaje de Modelado Unificado define un componente
como “una parte modular, desplegable y sustituible en un sistema, que incluye la
implantación y está definido por sus interfaces”. El término componente puede ser
interpretado de distintas maneras, a continuación se listaran 3 visiones distintas:
Desde el punto de vista de la orientación a objetos, un componente es un
conjunto de clases que colaboran, en ocasiones un componente puede estar
formado por una sola clase.
Desde el punto de vista de la ingeniería de software tradicional un componente
es un elemento funcional de un programa que incorpora lógica de
procesamiento.
El punto de vista relacionado con el proceso se busca elaborar sistemas de
cómputo que utilicen componentes de software o patrones de diseño ya
existentes. Conforme se construye la arquitectura se van seleccionando los
componentes de un catálogo.
Los sistemas de software que se desarrollan en la actualidad son muy grandes y
complejos, además de que necesitan ser desarrollados de forma muy rápida, lo que trae
consigo una mala calidad del producto con un atributo de calidad de mantenibilidad muy
baja. Bajo estas circunstancias la manera de entregar el software con tiempos de
entrega más cortos y de mejor calidad es a través de la reutilización en lugar de volver
a implementar los componentes. Los fundamentos de la ingeniería basada en
componentes son:
Componentes independientes que están especificados mediante sus interfaces.
La interfaz debe ser independiente de la implementación de forma que la
implementación del componente se pueda cambiar sin que los sistemas que
consumen el componente se vean afectados.
Estándares de componentes que faciliten su integración. En estos estándares se
define como deben especificarse las interfaces de componentes y como es su
comunicación.
Middleware que brinde soporte de software para la integración de componentes.
El cual permite que compontes independientes distribuidos trabajen en conjunto.
23
Un proceso de desarrollo que permita la evolución de requerimientos a partir de
los componentes disponibles.
Si se tiene como meta desarrollar componentes se deben tomar en cuenta los
principios de diseño para la construcción de software comprensible y mantenible.
Los principios son:
1. Se debe ocultar la implementación de los componentes permitiendo la
modificación del componente sin afectar el sistema que está haciendo uso
de ellos.
2. Los componentes se comunican a través de interfaces bien definidas. Lo cual
permite que si las interfaces se mantienen un componente puede ser
sustituido por otro.
3. Las infraestructuras de componentes ofrecen varios servicios estándar para
ser usados en un sistema de aplicación, reduciendo la cantidad de código a
desarrollarse.(Sommerville, 2011)
El proceso Unificado
El proceso unificado busca extraer las mejores características de los modelos
tradicionales del proceso de software pero también busca utilizar muchos de los mejores
principios de los métodos ágiles. Reconoce la importancia de la comunicación del cliente
y plasmar la interacción que el cliente tendrá con su sistema utilizando un lenguaje
coloquial (caso de uso). Sugiere un flujo de trabajo de forma iterativa e incremental.
Además de estar centrado en la arquitectura del software.
El proceso unificado está dividido en cuatro fases que son:
La fase de concepción: Esta fase contempla actividades de comunicación con el
cliente donde se identifican los requerimientos del negocio. Una vez obtenidos
los requerimientos se propone una arquitectura tentativa para el sistema y se
desarrollan actividades de planeación como son identificación de los recursos,
evaluación de posibles riesgos, se establece un calendario de actividades.
La fase de elaboración: En esta fase continúan las actividades de comunicación,
se refinan los casos de uso desarrollados en la dase de concepción, la
representación de la arquitectura incluye cinco puntos de vista del software que
son: los modelos de casos de uso, de requerimientos, de diseño, de
implementación y despliegue.
La fase de construcción: La fase de construcción tiene como entrada los
artefactos del modelo de arquitectura y con esto genera los componentes del
software. Conforme se van construyendo los componentes se van ejecutando
pruebas unitarias para posteriormente integrar los componentes y realizar
pruebas de integración. También se realizan pruebas de aceptación que son
validadas mediante los casos de uso.
La fase de transición: Esta fase incluye las últimas actividades de construcción
y se comienzan con las actividades de despliegue. Los usuarios finales
comienzan a realizar pruebas beta, reportando defectos y cambios al sistema.
También en esta fase se genera documentación de apoyo al sistema como son:
manuales de operación, de instalación.
24
Proceso de software personal (PSP)
El proceso de software personal es un proceso diseñado para ayudar a controlar,
administrar y mejorar la forma de trabajo. Está estructurado de formas guías y procesos
para desarrollar software. El PSP usado de correctamente proporciona datos históricos
necesarios para cumplir de una manera eficaz los compromisos de entrega de software.
El PSP es un proceso personal para desarrollar software, principalmente se divide en
tres partes que son las siguientes:
Pasos definidos. Formas. Estándares.
El PSP es una línea de trabajo de medición y análisis para ayudarle a caracterizar su
proceso.
El propósito del PSP es ayudar a ser un mejor Ingeniero de software. Es una poderosa
herramienta que puede usarse de distintas maneras, por ejemplo para administrar el
trabajo, analizar el desempeño, construir habilidades. El PSP puede ayudar a planear
mejor, llevar el control del rendimiento personal y mejorar la calidad de un producto. Si
se diseñan programas, levantan requerimientos, se escribe documentación o se le da
mantenimiento a software existente.
Flujo del proceso.
Figura 8. Flujo de proceso de PSP. Fuente: Elaboración propia.
El PSP sigue una línea de trabajo estructurada, dividida en una serie de fases
representadas en la figura 8, cada una de las fases será descrita a continuación:
25
Durante la fase de planeación el desarrollador crea el modelo conceptual, que es la base para la construcción de cada uno de los métodos de la realización del sistema o programa.
Al entrar en la fase de Diseño se crean o diseñan cada uno de los métodos del programa, en base a la fase de planeación.
En la fase de compilación se construyen los módulos previamente diseñados en el lenguaje escogido.
En la fase de compilación se compila el programa hasta que se encuentre libre de errores, los errores se apuntan en una plantilla, donde cada defecto o error tiene un tipo especificado.
En la fase de pruebas se ejecuta el programa y se eliminan todos los errores lógicos hasta obtener los resultados deseados.
Por último tenemos el resumen del plan de proyecto conocida como postmortem, que es otra plantilla donde aparecen los tiempos de desarrollo, el número de defectos encontrados, el tamaño del programa, una serie de datos, que van aumentando conforme va avanzando el proceso.
Durante cada una de las fases documentamos el tiempo de trabajo de cada fase en una
bitácora, también se llenan algunas plantillas adicionales.
El principal objetivo del PSP es ayudar a los ingenieros de software a realizar mejor su
trabajo. También está diseñado para demostrar el valor de utilizar procesos definidos y
medidos.
Proceso de software en equipo (TSP)
La meta del proceso de software en equipo es construir un equipo de proyecto auto
dirigido, que se organice para producir un software de alta calidad. Un equipo auto
dirigido entiende en forma consistente sus metas y objetivos generales. Define funciones
y responsabilidades para cada uno de los miembros, registra datos de productividad y
calidad del proyecto, define estándares, evalúa posibles riesgos así como la forma de
controlarlos.
El TSP es una línea de trabajo y un proceso estructurado para construir y guiar equipos
de ingeniería que desarrollan software.
El TSP contiene:
Un proceso de integración de equipo que trata los aspectos de objetivos, compromiso, cohesión y estructura del equipo.
Un proceso de trabajo en equipo que trata los procesos y prácticas de ingeniería usadas por el equipo.
Un prerrequisito para que un equipo use el TSP es un entendimiento de las habilidades
de ingeniería de software y procesos enseñados en el PSP.
26
Figura 9. Integración efectiva de equipos con TSP. Fuente: Elaboración propia.
CMMI
El modelo CMM-Capability Maturity Model o Modelo de Capacidad de Madurez, surgió
como respuesta a una iniciativa de la fuerza aérea de Estados Unidos, que estaba ya
frustrada con su proceso de adquisición de software en los 80’s. La universidad de
Carnegie Mellon ganó la propuesta en 1984 para crear y operar una organización de
investigación y desarrollo con fondos federales. Esta organización: el Instituto de
Ingeniería de Software (SEI por sus siglas Software Engineering Institute) creó un
modelo que contenía un compendio de “best practices” o mejores prácticas,
recomendadas para asegurar proyectos exitosos, el cual pudieran utilizar para realizar
evaluaciones objetivas de sus proveedores de software.
Las siglas CMMI significan Capability Maturity Model Integration o Integración de CMM.
Existen dos maneras de implementar el modelo CMMI:
Representación continua está orientada a un enfoque de mejora en la capacidad
de las áreas de proceso (PAs). El modelo continuo permite que las compañías
puedan elegir las áreas de proceso que necesiten fortalecer de acuerdo a sus
necesidades y requerimientos, las compañías que implementan este modelo no
obtienen un nivel de madurez, sin embargo está trabajando dentro del marco de
mejora CMMI.
Representación por etapa o niveles está diseñada de manera que apoye el
enfoque de mejoras de madurez organizacional. Aquí se encuentran definidos 5
niveles de madurez donde se encuentran distribuidas las áreas de proceso. Fig.
10
27
Figura 10. Proceso de mejora continua CMMI. Fuente: Elaboración propia.
Cuando una organización se encuentra en el nivel de madurez 1, significa que no se
cuenta con un ambiente estable y el éxito del proyecto dependerá de la competencia y
la heroicidad de las personas de la organización y no en el uso de procesos probados.
Aunque las organizaciones de nivel 1 pueden generar productos y servicios que
satisfagan al cliente, es muy probable que se exceda el presupuesto o se entregue el
producto de manera tardía. Debido a que no se tiene una base para saber cuáles fueron
las acciones que llevaron al éxito el producto a servicio es muy difícil que se pueda
repetir este éxito.
El nivel 2 está caracterizado por tener procesos administrados, en este nivel un proceso
es utilizado repetidamente. Las organizaciones se aseguran que requerimientos,
procesos, entregables y servicios sean documentados. Se cuenta con planes de trabajo,
a los cuales se les da seguimiento y que son medidos y controlados.
En el nivel de madurez 3, los procesos están bien caracterizados o comprendidos. Los
estándares, descripciones de procesos y procedimientos para un proyecto se adaptan
desde el conjunto de procesos estándar de la organización para adaptarse a un
determinado proyecto.
El nivel 4 se caracteriza por ser cuantitativamente administrado, además de las
mediciones se tiene un proceso de administración y control adicional. Se selecciona un
grupo de procesos o subprocesos de los cuales depende en gran parte el desempeño
de un proyecto y se trata de controlarlos utilizando técnicas estadísticas. Aquí se definen
objetivos cuantitativos para la calidad y el desempeño de los procesos de acuerdo a las
necesidades del cliente y la organización.
Nivel 5 Optimizado
Nivel 4 Administrado cuatitativamente
Nivel 3 Definido
Nivel 2 Administrado
Nivel1 Inicial
28
En nivel 5 está caracterizado por la optimización. La administración de procesos incluye
la optimización y mejora deliberada de procesos. No debe entenderse por optimización
el reducir actividades, en algunos casos el incluir un nuevo control en el proceso
generará una mejora. En este nivel, los procesos son mejorados continuamente
tomando como base una comprensión cuantitativa de las causas de variación más
comunes que existen. Es decir, que aquí habrá un enfoque en el proceso que se tiene
y su desviación. Se establecen objetivos de mejora de procesos cuantitativos y una vez
que se definen las mejoras, son analizadas y evaluadas para saber qué efectos han
tenido al implementar estos cambios.
Un área de proceso es un conjunto de prácticas relacionas dentro de un área que al
implementarse conjuntamente satisface un conjunto de metas consideradas importantes
para mejorar esa área. La tabla 1 muestra agrupadas las áreas de proceso por niveles
de madurez.
Nivel Áreas de proceso
1 Inicial
2 Administrado
Gestión de Requisitos (REQM).
Planificación del Proyecto (PP).
Monitorización y Control del Proyecto (PMC).
Aseguramiento de la Calidad del Proceso y del
Producto (PPQA).
Administración de la Configuración (CM).
Medición y Análisis (MA).
Gestión de Acuerdos con Proveedores (SAM).
3 Definido
Enfoque en Procesos de la Organización (OPF).
Definición de Procesos de la Organización (OPD).
Formación en la Organización (OT).
Gestión Integrada del Proyecto (IPM).
Gestión de Riesgos (RSKM).
Desarrollo de Requisitos (RD).
Solución Técnica (TS).
Integración del Producto (PI).
Validación (VAL).
29
Verificación (VER).
Análisis de Decisiones y Resolución (DAR).
4 Administrado
cuantitativamente
Gestión Cuantitativa del Proyecto (QPM).
Gestión del Rendimiento de la Organización
(OPM).
5 Optimizado
Análisis Causal y Resolución (CAR)
Innovación y despliegue organizacional (OID)
Tabla 1. Áreas de proceso por nivel de madurez. Fuente: Elaboración propia.
Desarrollo ágil
En la actualidad el software se ha convertido en una necesidad. Forma parte de todas
las operaciones industriales y para responder a todas las amenazas competitivas y
cambios del entorno de toda empresa es necesario que se desarrolle con rapidez, sin
embargo, esta rapidez generalmente impacta en su calidad.
Las empresas se encuentran en un entorno global que es variable, lo cual implica
dificultades para asegurar una especificación de requerimientos sin cambios. Los
requerimientos iniciales regularmente cambian por diversas situaciones, por ejemplo, si
se está realizando el desarrollo apegado a un proceso por iteraciones en cascada se
puede presentar la situación que se termina la primera iteración (análisis, diseño,
construcción, pruebas e instalación) y al comenzar la siguiente iteración se descubra
que no se contempló el impacto que tendría la segunda iteración sobre la primera
entrega, lo cual implicara que se tendrá que re trabajar la primera entrega a la par que
se tiene que continuar con el desarrollo de los requerimientos de la segunda iteración.
A finales de la década 1990 se comenzó con el enfoque de “desarrollos ágiles”, el cual
consiste en el desarrollo de software rápido para contar con una versión ejecutable útil
en un periodo corto. Este software no se desarrolla como una sola unidad, es un
desarrollo por incrementos donde cada incremento va agregando funcionalidad al
sistema. Las características que comparte el desarrollo ágil son las siguientes:
1. No existe una especificación a detalle del sistema, el documento de
requerimientos contempla únicamente los puntos más importantes del sistema.
2. El sistema se desarrolla en diferentes versiones.
3. Se utilizan herramientas para desarrollo de prototipos para las interfaces de
usuario del sistema.
Métodos ágiles
Los métodos ágiles permiten que el equipo de desarrollo se enfoque en el software en
lugar del diseño y la documentación. Existe un manifiesto para la filosofía para los
métodos ágiles el cual dice lo siguiente:
“Estamos descubriendo mejores formas para desarrollar software, al hacerlo y al ayudar
a otros a hacerlo. Gracias a este trabajo llegamos a valorar:
A los individuos y las interacciones sobre los procesos y las herramientas.
30
Al software operativo sobre la documentación exhaustiva.
La colaboración con el cliente sobre la negociación del contrato.
La respuesta al cambio sobre el seguimiento de un plan.
Esto es, aunque exista valor en los objetos a la derecha, valoraremos más los de la
izquierda.”(Sommerville, 2011)
Los métodos agiles más conocidos son la Programación Extrema (Extreme
Programming) y Scrum. A estos se le suman otros métodos como son el desarrollo de
software adaptativo, de Crystal, el desarrollo dirigido por características, etcétera.
Los principios de los métodos agiles son:
1. El cliente debe estar involucrado con el proceso de desarrollo de software.
2. El software se desarrolla en incrementos especificados por el cliente.
3. Se tiene que hacer uso de las habilidades de los miembros del equipo de trabajo
para trabajar mediante el enfoque de métodos ágiles.
4. Diseñar el sistema considerando posibles cambios.
5. Mantener la simplicidad del software y del proceso utilizado en el desarrollo.
Un punto importante a considerar en los métodos ágiles es que el contrato se debe
basar en el tiempo para el desarrollo del sistema en vez de hacerlo por el desarrollo de
un conjunto específico de requerimientos.
Programación extrema
La programación extrema (XP) es un enfoque de la ingeniería de software formulado
por Kent Beck (1999). Haciendo la analogía con los principios de los métodos ágiles.
1. Se realiza el desarrollo por incrementos donde los requerimientos se generan
en base a escenarios llamados historias de usuario.
2. El cliente debe estar completamente involucrado con el equipo de desarrollo.
3. El desarrollo se realiza en pares, no siempre programan juntos los mismos pares
en este principio los tiempos extras no son aceptables.
4. Los cambios se realizan mediante liberaciones regulares del sistema, desarrollo,
refactorización (buscar mejoras de software e implementarlas al instante) e
integración continúa.
5. La simplicidad se logra mediante la técnica de refactorización, es decir, se
reescribe el código existente para mejorarlo buscando sea más legible y fácil de
mantener.
SCRUM
En los 80’s Hirotaka Takeuchi y Ikujiro Nonaka implementarón una estrategia de
desarrollo de productos donde el equipo de desarrollo trabaja en conjunto para lograr
un objetivo común. Describieron un este método para el desarrollo de productos que
llamaron enfoque holístico o “rugby”. El concepto de rugby de un Scrum es cuando un
grupo de jugadores se junta para reiniciar el juego el cual haya sido detenido por una
infracción. Takeuchi y Nonaka conceptualizaba que el desarrollo de productos debía ser
similar al juego de rugby donde el equipo trabaja en conjunto moviendo el balón hacia
atrás y adelante.(A Guide to the Scrum Body of Knowledge (SBOKTM Guide), 2016)
31
Scrum es uno de los proyectos agiles más populares. Es adaptativo, iterativo, rápido y
un framework efectivo diseñado que genera valor durante el proyecto. Usando Scrum
se garantiza transparencia en la comunicación.
Una de las principales fortalezas de Scrum es el manejo de equipos inter funcionales,
auto organizados que dividen su trabajo en pequeños ciclos conocidos como sprints. El
ciclo de Scrum consta de los siguientes pasos:
1. Se comienza con una reunión de stakeholders, en donde se crea la visión del
proyecto.
2. El propietario del producto (product owner) crea una lista de prioridades del
producto el cual contiene una lista de requerimientos con prioridades escritas
como historias de usuario.
3. Cada sprint comienza con una reunión de planificación de sprint en la cual se
consideran las historias de usuario con más prioridad para incluirlas en el sprint.
4. Un ciclo de sprint tiene una duración entre una y seis semanas en la cual el
equipo trabaja en atender la lista de requerimientos para generar entregables del
producto.
5. Durante el sprint se llevan reuniones diarias en las cuales deben asistir todos
los participantes de los equipos, los participantes deben permanecer
preferentemente de pie debido a que son reuniones que no se deben alargar. En
esta reunión cada uno de los participantes comparten los avances respecto a la
reunión anterior, problemas que han surgido y las actividades que se realizaran
al día siguiente.
6. Hacia la etapa final del sprint se realiza una reunión de revisión del sprint en
donde se hace la demostración del producto al product owner y a los
stakeholders.
7. El product owner acepta el producto solo si cumple con los criterios de
aceptación definidos al inicio del sprint.
8. Como paso final se realiza una reunión de retrospectiva del sprint en la cual el
equipo analiza las formas de mejora de procesos.
Figura 11. Flujo de Scrum de un sprint. Fuente: A Guide to the SCRUM BODY OF KNOWLEDGE.
32
Idealmente los equipos de Scrum deben contar de seis a diez miembros. Por esta razón
se tiene la idea de que Scrum solo puede utilizarse en proyectos pequeños. Sin embargo
Scrum es escalable.
Principios de Scrum
Existen seis principios de Scrum los cuales deben implementarse de forma obligatoria
en todos los proyectos de Scrum, los principios son:
1. Control del proceso empírico.
2. Auto-organización.
3. Colaboración.
4. Priorización basada en valor.
5. Time-boxing.
6. Desarrollo iterativo.
Aspectos de SCRUM
Los aspectos deben administrarse durante todo el proyecto, los cinco aspectos de
Scrum son:
1. Organización
2. Justificación del negocio
3. Calidad
4. Cambio
5. Riesgo
Organización
Scrum define roles y responsabilidades, los roles de Scrum se dividen en 2 categorías:
Roles centrales: Las personas que tienen asignado estos roles están
involucrados en su totalidad con el proyecto y son que son los responsables del
éxito de este. Los roles centrales son: Product Owner, Scrum Master y el equipo
de Scrum.
Roles no centrales: Estos roles no es necesario que existan en el proyecto de
Scrum, interactúan con el equipo pero no son responsables del éxito del
proyecto. Los roles no centrales son: stakeholders, Scrum Guidance Body y
vendedores.
Justificación del negocio
En Scrum la justificación del negocio está basado en el concepto de entrega impulsada
por valor. Debido a que Scrum busca realizar la entrega de resultados en etapas
tempranas del proyecto, permite a los stakeholders observar el valor del proyecto desde
el inicio.
Calidad
El aspecto de calidad en Scrum tiene que ver de como un producto o entregable cuenta
con los criterios de aceptación. Como Scrum trabaja por incrementos en los sprints,
permite que los errores o defectos sean identificados fácilmente durante las pruebas de
cada incremento en lugar de identificar estos errores al final del proyecto lo cual podría
ser más costoso. Las tareas de calidad del desarrollo se realizan durante el mismo sprint
por lo que las pruebas y documentación forman parte del Sprint.
33
Cambio
El cambio es uno de los aspectos de Scrum, el equipo debe estar consciente de que el
cada proyecto puede presentar cambios y que Scrum está diseñado para aceptar estos
cambios.
Un principio de Scrum es reconocer que los stakeholders cambian de opinión respecto
a los requerimientos, esto es conocido como “requisitos volatiles”, por otro lado es
prácticamente imposible que los requisitos sean definidos en su totalidad desde el inicio
del proyecto.
Debido a que los proyectos de Scrum se manejan por sprints permite la
retroalimentación del cliente en cada iteración. La generación de entregables en cada
Sprint permite al cliente realizar cambios en los requisitos antes de comenzar el
siguiente Sprint con una afectación mínima.
Riesgo
Un riesgo está definido como un evento inesperado que puede afectar los objetivos del
proyecto y puede ocasionar que este sea exitoso o falle. Si los riesgos son manejados
de manera positiva en el proyecto se convierten en oportunidades. Por el lado contrario,
si los riesgos afectan de forma negativo al proyecto se convierten en amenazas. El
proceso de gestión de riesgos en Scrum debe ser realizado de manera preventiva y que
no se debe perder de vista durante el tiempo que dure el proyecto.
Es importante que se realice la identificación de riesgos lo más pronto posible en el
proyecto para que puedan ser analizados y atendidos con base a dos factores que son:
la probabilidad de que ocurra el riesgo y el impacto que generara esta ocurrencia.
Los riesgos que tienen una probabilidad alta y un impacto alto deben ser atacados
primero.
Procesos de SCRUM
Scrum maneja 19 procesos los cuales se agrupan en 5 fases listados en la tabla 2.
Fase Proceso de Scrum
Inicio 1. Crear la visión del proyecto
2. Identificar al Scrum Master y
Stakeholders
3. Formar Equipos Scrum
4. Desarrollar épica(s)
5. Crear el backlog Priorizado del
Producto
6. Realizar la planificación de
lanzamiento
Planificación y estimación 7. Crear historias de usuario
34
8. Estimar historias de usuario
9. Comprometer historias de usuario
10. Identificar tareas
11. Estimar tareas
12. Crear el sprint backlog
Implementación 13. Crear entregables
14. Realizar daily standup
15. Refinar el backlog Priorizado del
Producto
Revisión y retrospectiva 16. Demostrar y validar el sprint
17. Retrospectiva del sprint
Lanzamiento 18. Enviar entregables
19. Retrospectiva del proyecto
Tabla 2. Procesos de SCRUM. Fuente: Elaboración propia.
Kanban
Kanban es una metodología ágil que por sus características se puede considerar una
metodología más adaptativa que las mencionadas anteriormente. Las únicas normas a
considerar son la visualización del flujo de trabajo y limitación del trabajo en curso.
Kan-ban es una palabra Japonesa que significa “tarjetas visuales”, donde Kan es
“visual”, y Ban corresponde a “tarjeta”. El origen de esta metodología tiene origen en los
procesos de producción de Toyota creado por Taiichi Ohno quien argumento lo
siguiente: "Los dos pilares del sistema de producción de Toyota son just-in-time y la
automatización con un toque humano, o la autonomía. La herramienta utilizada para
operar el sistema es kanban".
El sistema de Kanban tiene como base: el trabajo en curso debería limitarse, solo se
debe comenzar algo cuando el bloque del trabajo anterior ha sido entregado o ha
pasado a otro estado. El Kanban significa que se crea una señal visual en donde se
indica que hay nuevos bloques o tareas de trabajo que se pueden comenzar a trabajar
debido a que el trabajo en curso no ha alcanzado el máximo acordado.
El mecanismo visual que se utiliza es a través de un pizarrón donde se agregan notas
adhesivas o también se puede utilizar un pizarrón electrónico de tarjetas. El pizarrón
debe contar con divisiones que corresponden a columnas que son las fases por las que
atravesara el sistema, estas columnas deben estar limitada lo que se conoce como el
trabajo en curso (WIP)
Las cinco propiedades para crear un conjunto emergente de comportamiento Lean en
las organizaciones son:
35
1. Visualizar el flujo de trabajo.
2. Limitar los trabajos en curso.
3. Medir y gestionar el flujo.
4. Hacer un proceso de políticas explícito.
5. Uso de modelos para reconocer oportunidades de mejora.
Los comportamientos que se han presentado en la mayoría de los casos donde se ha
implementado Kanban:
Un proceso único adaptado a cada flujo del proyecto.
Un desarrollo sin iteraciones.
Trabajo programado por oportunidad,
Valor optimizado por clase de servicio.
Administración de riesgo con capacidad de distribución.
Tolerancia en le experimentación de procesos.
Administración cuantitativa
Propagación viral de Kanban en toda la organización.
La unión de pequeños equipos para obtener mayor fluidez.
Figura 12. Tablero KANBAN. Fuente: Elaboración propia.
PILA
A
B
C
SELECCION DE TAREAS
(4)
D
E
F
G
DESARROLLO (3)
H
I
J
PRUEBA(2)
K
L
TERMINADO
M
N
O
P
Q
36
Capítulo III
Análisis y diseño En este capítulo se realizarán actividades de análisis y diseño de la propuesta de
solución al problema descrito en el capítulo 1. Se lista un resumen de las actividades
realizadas para la creación de la solución. Se documentan las herramientas CASE
utilizadas para la generación de los diagramas UML que se utilizaran para representar
el modelo de componentes genéricos. Se definen los patrones arquitectónicos utilizados
para la desarrollo de la plantilla base, así como los patrones de diseño utilizados en la
creación de los componentes reusables. Como sección final del capítulo se está
realizando la especificación de los distintos modelos UML que se consideraron
necesarios documentar.
Análisis de la plantilla creada
En el análisis realizado para la creación de la plantilla genérica formada por
componentes reusables, los pasos realizados fueron los siguientes:
Se analizaron distintas aplicaciones web en las que el autor de esta tesis ha
laborado y se identificó la funcionalidad en común de estas aplicaciones.
Se identificaron los patrones arquitectónicos a utilizar en el desarrollo de la
solución propuesta.
Se realizaron los siguientes diagramas UML de la plantilla genérica a desarrollar:
o Diagrama de casos de uso.
o Diagramas de clases.
o Diagramas de secuencia.
o Diagramas de colaboración.
o Diagramas de componentes.
Herramientas utilizadas
Las herramientas utilizadas en la fase de análisis y diseño para el proyecto de creación
de la plantilla genérica formada por componentes reusables son los siguientes:
Para la generación del diagrama de casos de uso, diagramas de secuencia y de
colaboración se utilizó el software StarUML V1.0. Las razones para utilizar esta
herramienta CASE es el conocimiento con el que ya se cuenta en el uso de la
herramienta, además de ser una herramienta de software libre.
Para realizar la documentación de los diagramas de clases y componentes se
utilizó la herramienta Visual Paradigm. Las razones para la selección de esta
herramienta son: el conocimiento en el uso de la herramienta debido a que se
utilizó en algunas asignaturas de la maestría, la facilidad de uso y la extensa
documentación y tutoriales que existen en el sitio. Además de considerarse el
tema de las licencias por lo que la versión utilizada fue la versión Community
debido a que es una versión gratuita de uso no comercial.
Patrones arquitectónicos
El patrón arquitectónico utilizado para el desarrollo de la solución de la plantilla genérica
formada por componentes reusables será una arquitectura 3 capas. Este tipo de
37
arquitectura permite reemplazar alguna de las capas de forma transparente en el mejor
de los casos, en el peor de los casos el trabajo de reemplazo será mínimo. Bajo este
escenario podemos considerar a cada una de las capas como un componente reusable
e intercambiable. Las capas están definidas de la siguiente manera:
Capa de presentación, en esta capa se encuentran contenidas las interfaces
de usuario (formularios Windows, páginas HTML, páginas aspx en el caso de la
tecnología net), controles visuales (textBox, comboBox, dataGrids, etc.) y los
eventos de cada uno de estos controles.
Capa de negocio, esta capa también es conocida como lógica del dominio, en
esta capa se concentra todo el código que define las reglas de negocio (cálculos,
validaciones).
Capa de acceso a datos, en esta capa se encuentran los métodos que permite
acceder a las fuentes de datos. Esencialmente trata sobre 4 operaciones
básicas, llamadas CRUD que responde a las siglas en inglés de Crear, Leer,
Actualizar y Eliminar, son las operaciones que se puede realizar sobre las bases
de datos. En este caso se está realizando sobre una base de datos relacional
con el manejador de base de datos SQL Server.
Este tema de tesis tiene como título “Implementación de plantillas base y componentes
reutilizables en ambiente web”, como se mencionó anteriormente se está utilizando un
patrón arquitectónico en 3 capas la cual se estará complementando con una arquitectura
orientada a servicios (SOA). En la solución propuesta la capa de servicios contendrá la
capa de negocio y la capa de datos, lo anterior nos permitirá un bajo acoplamiento con
la capa de presentación dando como resultado que la capa de presentación en
determinado momento pueda ser distinta de un sitio web como puede ser una aplicación
Windows, una aplicación de consola o también puede darse el caso de que sea otro
servicio web. Una gran ventaja del desarrollo con SOA es que el servicio puede ser
consumido con una aplicación desarrollada en una tecnología distinta de .NET.
La estructura común considerada como esqueleto de aplicaciones web se muestra en
la Figura 13.
38
Figura 13. Estructura propuesta. Fuente: Elaboración propia.
Patrones de diseño
Durante la implementación de las distintas capas de la arquitectura seleccionada se
aplicarán los siguientes patrones de diseño.
Patrón constructor (Builder): Se mencionó en el capítulo que este patrón
separa la construcción de un objeto de su representación, de forma que el mismo
proceso de construcción puede crear diferentes representaciones. Es
recomendable utilizar el patrón constructor cuando el algoritmo para crear un
objeto complejo debiera ser independiente de las partes que compone dicho
objeto y de cómo se ensamblan.
Se utilizará el patrón de diseño constructor en el módulo de acceso a datos,
considerando la definición anterior se implementará funcionalidad que utilice el
mismo proceso de construcción para crear entidades distintas.
Patrón Adaptador (Adapter): También se conoce a este patrón como wraper,
el propósito de este patrón es proporcionar una interfaz de una clase en otra
39
interfaz que es la que esperan los clientes. Permite que cooperen clases que de
otra forma no podría tener interfaces compatibles.
Se utilizará este patrón al realizar una implementación en capas, como se ha
comentado la capa de acceso a datos y negocio se construirán en un WCF, la
interfaz expondrá métodos teniendo como argumentos y/o valores de retorno las
clases de entidad que se utilizarán para transportar los datos obtenidos de la
base de datos, esto nos permitirá tener interfaces compatibles con clientes de
tecnologías distintas a la net.
Patrón fachada (facade): Este patrón tiene como finalidad proporcionar una
interfaz unificada para un conjunto de interfaces de un subsistema. Define una
interfaz de alto nivel que hace que un subsistema sea más fácil de usar.
Para el trabajo de esta tesis se decidió utilizar el patrón facha ya que es
recomendable utilizarlo cuando se desea dividir en capas los subsistemas, se
utiliza una fachada para definir un punto de entrada en cada nivel del
subsistema.
Patrón peso ligero (Flyweight): Se recomienda utilizar este patrón cuando se
desea tener un gran número de objetos de grano fino de forma eficiente. Es
recomendable utilizar este patrón cunado una aplicación instancia una gran
cantidad de objetos o cuando los costes de almacenamiento son elevados
debido a la gran cantidad de objetos
Se está utilizando este patrón en los módulos de manejo de al crear clases
estáticas, con esto se estará evitando crear instancias por cada uno de los
errores.
Especificación de los casos de Uso
La aplicación a desarrollar consiste en un sistema base compuesto de componentes con
la funcionalidad que se ha identificado se construye de forma recurrente en la gran
mayoría de sistemas de software. Los casos de uso que se identificaron son:
E1:INICIAR SESIÓN
E2:CONSULTAR CATALOGO
E3:ADMINISTRAR CATÁLOGO
o E3.1:INSERTAR CATÁLOGO
o E3.2.:ACTUALIZAR CATÁLOGO
o E3.3:ELIMINAR CATÁLOGO
E4:ADMINISTRAR USUARIOS
o E4.1:INSERTAR USUARIO
o E4.2:ACTUALIZAR USUARIO
o E4.3:ELIMINAR USUARIO
E5:REGISTRAR PISTAS DE AUDITORIA
Actores
Los actores que interactuaran con el sistema son:
Administrador: Es el actor del sistema que tiene como responsabilidad realizar:
altas, bajas lógicas (inhabilitar usuarios) y actualizaciones del catálogo de
usuarios.
40
Usuario operacional: Es el actor del sistema que cuenta los permisos para
realizar las siguientes acciones en el sistema:
o Realizar altas, bajas y actualizaciones del catálogo.
o Consultar los registros del catálogo filtrado por clave.
Casos de uso
Figura 14. Diagrama de Casos de Uso. Fuente: Elaboración propia.
El diagrama de casos de uso de la figura 14 contiene los casos de uso que se
implementaran en la plantilla base, estos casos de uso muestran la interacción entre los
actores y el sistema, describen la funcionalidad principal del sistema. Se puede
visualizar al modelo de casos de uso como una “caja negra”, hasta este punto solo se
esa definiendo el comportamiento del sistema, el cómo se construya esta funcionalidad
se detallarla en diagramas siguientes. A continuación se redactaran los casos de uso
que se implementaran en la fase de construcción.
Caso de uso E1:Iniciar Sesión
Descripción Caso de uso que permite al usuario operacional o al
administrador ingresar al sistema.
Precondiciones No aplica
Postcondiciones No aplica
Flujo principal
El usuario ingresa en la pantalla de inicio de sesión su
clave de usuario y contraseña.
El sistema verifica que sea un usuario registrado en el
sistema. (FA1) (FA2)
El sistema muestra la pantalla principal con las opciones:
System
Administrador
Usuario operacional
E2:Consultar Catalogo
E3:Administrar Catálogo
E4:Administrar Usuarios
E3.1:Insertar catálogo
E3.2.:Actualizar catálogoE3.3:Eliminar catálogo
E4.1:Insertar Usuario E4.2:Actualizar Usuario E4.3:Eliminar Usuario
<<include>><<include>> <<include>>
<<include>> <<include>>
<<include>>
E5:Registrar Pistas deauditoria
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
E1:Iniciar Sesión
<<include>>
<<include>>
<<include>>
41
o Consulta de Catálogo.
o Mantenimiento de Catálogo
El usuario selecciona la opción deseada.
Fin de caso de uso.
Flujos alternos
(FA1)
En caso de que el usuario no se encuentre registrado en
el sistema.
El sistema muestra el mensaje "Usuario / contraseña
incorrectos".
Fin de caso de uso.
(FA2)
En caso de que el usuario tenga el perfil de
administrador, el sistema muestra la pantalla principal
con la opción:
o Mantenimiento de usuarios.
El usuario selecciona la opción.
Fin de caso de uso.
Tabla 3. Caso de uso Iniciar Sesión.
Caso de uso E2:Consultar Catalogo
Descripción Permite al Usuario Operacional realizar consultas al catálogo
filtrado por clave.
Disparador: El Usuario Operacional presiona la opción "Consulta de
Catálogo" en el menú principal.
Precondiciones El usuario tiene habilitados los permisos para seleccionar la
opción "Consulta de Catálogo".
Postcondiciones Se conoce la descripción e identificador del catálogo asociados
a la clave.
Flujo principal
El sistema muestra la pantalla de "Consulta de Catálogo"
con una caja de texto para capturar la clave del catálogo.
El Usuario Operacional introduce la clave y presiona el
botón "Aceptar".
El sistema verifica el campo. FA1
42
El sistema muestra los datos asociados a la clave
(Identificador y descripción).
El Usuario Operacional presiona el botón INICIO.
El sistema muestra la pantalla principal.
Fin del caso de uso.
Flujos alternos
FA1
En caso de no exista registro asociado a la clave en la
base de datos.
El sistema manda el mensaje "No se encontró registro en
la Base de Datos.".
El Usuario Operacional presiona el botón INICIO.
El sistema muestra la pantalla principal.
Fin del caso de uso.
Tabla 4. Consultar Catalogo.
Caso de uso E3:Administrar Catálogo
Descripción Permite al Usuario Operacional realizar la gestión del catálogo.
Disparador El Administrador presiona la opción Mantenimiento de catálogo
en el menú principal.
Precondiciones El usuario tiene habilitados los permisos para seleccionar la
opción “Mantenimiento de Catálogo”.
Postcondiciones No aplica
Flujo principal
El sistema muestra la pantalla de "Mantenimiento de
Catálogo" con los datos del catálogo (Clave, descripción)
y los botones Alta (Ver CU E3.1: Insertar catálogo),
Actualizar (Ver CU E3.2: Actualizar catálogo) y Baja (Ver
CU E3.3: Eliminar catálogo).
Fin del caso de uso.
Flujos alternos No tiene flujos alternos
Tabla 5. Administrar Catálogo
Caso de uso E3.1:Insertar catálogo.
43
Descripción Permite al Usuario operacional realizar altas de registros en la
tabla catálogo.
Disparador El Administrador presiona el botón Alta en la pantalla
Mantenimiento Catálogos.
Precondiciones El usuario tiene habilitados los permisos para seleccionar la
opción "Mantenimiento de Catálogo".
Postcondiciones Se inserta de forma satisfactoria un registro en el catálogo.
Flujo principal
El sistema muestra la pantalla "Alta de Catálogo" con una
caja de texto para capturar la clave y una caja de texto
para capturar la descripción.
El Usuario Operacional captura la clave y descripción y
presiona el botón "Agregar".
El sistema valida que se hayan capturado los campos.
FA1-FA2 (Ver CU E5: Registrar Pistas de auditoria).
El sistema muestra el mensaje "El registro fue dado de
alta satisfactoriamente.".
El Usuario presiona el botón Salir.
El sistema muestra la pantalla principal.
Fin del caso de uso.
Flujos alternos
FA1
En caso de no haber capturado la clave.
El sistema manda el mensaje "El campo Clave es
requerido.".
El Usuario presiona el botón "Salir".
El sistema muestra la pantalla principal.
Fin del caso de uso.
FA2
En caso de no haber capturado la descripción.
El sistema manda el mensaje "El campo Descripción es
requerido.".
El Usuario presiona el botón "Salir".
El sistema muestra la pantalla principal.
44
Fin del caso de uso.
Tabla 6. Insertar catálogo.
Caso de uso E3.2.:Actualizar catálogo
Descripción Permite al Usuario Operacional realizar la actualización de
registros de la tabla catálogo.
Disparador No aplica
Precondiciones El usuario tiene habilitados los permisos para seleccionar la
opción “Mantenimiento de Catálogo”.
Postcondiciones Se actualizó de forma satisfactoria el registro en el catálogo
Tabla Catálogo.
Flujo principal
El Usuario Operacional selecciona un elemento de la
tabla "Lista Catálogo" en la pantalla "Mantenimiento de
Catálogo". FA1
El sistema sombrea el registro seleccionado.
El Usuario Operacional presiona el botón "Actualizar".
El sistema muestra la pantalla Actualización del catálogo
con la el dato de la clave en modo lectura y una caja de
texto para capturar la descripción.
El Usuario Operacional edita el dato de la descripción y
presiona el botón Guardar.
El sistema válida que se hayan capturado el dato de la
descripción FA2(Ver CU E5:Registrar Pistas de
auditoria).
El sistema muestra el mensaje "El registro fue
actualizado correctamente.".
El Usuario Operacional presiona el botón “Salir”.
El sistema muestra la pantalla principal.
Fin del caso de uso.
Flujos alternos
FA1
En caso de no haber seleccionado un elemento de la
"Lista Catálogo".
El sistema manda el mensaje "Debe seleccionar un
registro para poderlo actualizar.".
45
Fin del caso de uso.
FA2
En caso de que el campo descripción se encuentre vacío.
El sistema manda el mensaje "El campo Descripción es
requerido.".
El Usuario Operacional presiona el botón Salir.
El sistema muestra la pantalla principal.
Fin del caso de uso.
Tabla 7. Actualizar catálogo.
Caso de uso E3.3:Eliminar catálogo
Descripción Permite al Usuario operacional realizar la baja física de registros
de la tabla catálogo.
Disparador No aplica
Precondiciones El usuario tiene habilitados los permisos para seleccionar la
opción “Mantenimiento de Catálogo”.
Postcondiciones Se eliminó de forma satisfactoria el registro en la tabla Catalogo.
Flujo principal
El Usuario Operacional selecciona un elemento de la
tabla "Lista Catálogo" en la pantalla "Mantenimiento de
Catálogo". FA1
El sistema sombrea el registro seleccionado.
El Usuario Operacional presiona el botón "Eliminar".
El sistema muestra el mensaje "El registro fue
eliminado." (Ver CU E5:Registrar Pistas de auditoria)
El Usuario Operacional presiona el botón INICIO.
El sistema muestra la pantalla principal.
Flujos alternos
FA1
En caso de no haber seleccionado un elemento de la
"Lista Catálogo".
El sistema manda el mensaje "Debe seleccionar un
registro para eliminarlo.".
El Usuario Operacional presiona el botón Salir.
El sistema muestra la pantalla principal.
46
Fin del caso de uso.
Tabla 8. Eliminar catálogo.
Caso de uso E4:Administrar Usuarios
Descripción Caso de uso que permite al Administrador realizar la gestión de
los usuarios.
Disparador El Administrador presiona la opción "Mantenimiento de
Usuarios" en el menú principal.
Precondiciones El usuario tiene habilitados los permisos para seleccionar la
opción "Mantenimiento de Usuarios".
Postcondiciones No aplica
Flujo principal
El sistema muestra la pantalla de Mantenimiento de
Usuarios con los datos RFC, Nombre, Apellido Paterno,
Apellido Materno, clave, estatus del catálogo de Usuarios
y los botones Alta (Ver E4.1:Insertar Usuario), Actualizar
(Ver CU E4.2:Actualizar Usuario) y Baja (Ver CU
E4.3:Eliminar Usuario).
Fin del caso de uso.
Flujos alternos No aplica
Tabla 9. Administrar Usuarios.
Caso de uso E4.1:Insertar Usuario
Descripción Permite al Administrador realizar el registro de Usuarios que
utilizaran el sistema.
Disparador El Administrador presiona el botón Alta en la pantalla
Mantenimiento de Usuarios.
Precondiciones El usuario tiene habilitados los permisos para seleccionar la
opción “Mantenimiento de Usuarios”.
Postcondiciones Se insertó un registro en el catálogo de Usuarios de forma
satisfactoria.
47
Flujo principal
El sistema muestra en la pantalla Alta de Usuario cajas
de texto para capturar la clave de usuario, RFC, Nombre,
Apellido Paterno, Apellido Materno.
El Administrador captura la clave de usuario, RFC,
Nombre, Apellido Paterno, Apellido Materno y presiona
el botón Agregar.
El sistema verifica que se hayan capturado los campos.
FA1, FA2, FA3 (Ver CU E5: Registrar Pistas de
auditoria).
El sistema muestra el mensaje "El Usuario fue dado de
alta satisfactoriamente.".
El administrador presiona el botón Salir.
El sistema muestra la pantalla principal.
Fin del caso de uso.
Flujos alternos
FA1
En caso de no haber capturado la clave de usuario.
El sistema manda el mensaje "El campo Clave es
requerido.".
El Administrador presiona el botón Salir.
El sistema muestra la pantalla principal.
Fin del caso de uso.
FA2
En caso de no haber capturado el RFC
El sistema manda el mensaje "El campo RFC es
requerido.".
El Administrador presiona el botón Salir.
El sistema muestra la pantalla principal.
Fin del caso de uso.
FA3
En caso de no haber capturado el Nombre.
El sistema manda el mensaje "El campo Nombre es
requerido.".
El Administrador presiona el botón Salir.
El sistema muestra la pantalla principal.
48
Fin del caso de uso.
Tabla 10. Insertar Usuario.
Caso de uso E4.2:Actualizar Usuario
Descripción Permite al Administrador realizar la actualización de Usuarios
que utilizaran el sistema.
Disparador No aplica
Precondiciones El usuario tiene habilitados los permisos para seleccionar la
opción “Mantenimiento de Usuarios”.
Postcondiciones Se actualizó de forma satisfactoria el registro en el catálogo de
Usuarios.
Flujo principal
El Administrador selecciona un elemento del Grid Lista
de Usuarios. FA1
El sistema sombrea el registro seleccionado.
El Administrador presiona el botón actualizar.
El sistema muestra la pantalla Actualización de Usuarios
con el dato de la clave de usuario en modo lectura,
también muestra las cajas de texto RFC, Nombre,
Apellido Paterno, Apellido Materno en modo edición.
El Administrador edita el valor deseado y presiona el
botón Guardar.
El sistema válida que se las cajas de texto no estén
vacías. FA2, FA3 (Ver CU E5: Registrar Pistas de
auditoria).
El sistema muestra el mensaje "El usuario fue
actualizado correctamente.".
El Administrador presiona el botón Salir.
El sistema muestra la pantalla principal.
Fin del caso de uso.
Flujos alternos
FA1
En caso de no haber seleccionado un elemento del grid
Lista de Usuarios.
El sistema manda el mensaje "Debe seleccionar un
usuario para poderlo actualizar.".
49
El Administrador presiona el botón Salir.
El sistema muestra la pantalla principal.
Fin del caso de uso.
FA2
En caso de no haber capturado el RFC del usuario.
El sistema manda el mensaje "El campo RFC es
requerido.".
El Administrador presiona el botón Salir.
El sistema muestra la pantalla principal.
Fin del caso de uso.
FA3
En caso de no haber capturado el Nombre del usuario.
El sistema manda el mensaje "El campo Nombre es
requerido.".
El Administrador presiona el botón Salir.
El sistema muestra la pantalla principal.
Fin del caso de uso.
Tabla 11. Actualizar Usuario.
Caso de uso E4.3:Eliminar Usuario
Descripción Permite al Administrador realizar la baja lógica de Usuarios.
Dispararador No aplica
Precondiciones El usuario tiene habilitados los permisos para seleccionar la
opción “Mantenimiento de Usuarios”.
Postcondiciones Se dio de baja el usuario de forma satisfactoria.
Flujo principal
El Administrador selecciona un elemento de la tabla Lista
Tabla Plantilla. FA1
El sistema sombrea el registro seleccionado.
El Administrador presiona el botón “Baja”.
El sistema muestra el mensaje "El Usuario fue dado de
baja." (Ver CU E5: Registrar Pistas de auditoria).
50
El Usuario presiona el botón INICIO.
El sistema muestra la pantalla principal.
Fin del caso de uso.
Flujos alternos
FA1
En caso de no haber seleccionado un elemento del grid
Lista de Usuarios.
El sistema manda el mensaje "Debe seleccionar un
Usuario para poderlo dar de baja.".
El Administrador presiona el botón Salir.
El sistema muestra la pantalla principal.
Fin del caso de uso.
Tabla 12. Eliminar Usuario.
Caso de uso E5:Registrar Pistas de auditoria
Descripción Registra los eventos realizados por los Usuarios o
administradores que utilizan el sistema.
Disparador No aplica
Precondiciones No aplica
Postcondiciones No aplica
Flujo principal
El Sistema obtiene la dirección IP de la ubicación donde
se está realizando la petición
El sistema obtiene la fecha actual.
El sistema obtiene el identificador del usuario que realizo
la petición.
El sistema obtiene el identificador de la operación que se
realizó."(Ver tabla de operaciones)
El sistema obtiene el identificador de usuario de
operación (Solo si fue Alta, baja o actualización de
usuarios).
El sistema realiza la inserción de los datos obtenidos.
Fin del caso de uso.
Flujos alternos No aplica
Tabla 13. Registrar Pistas de auditoria.
51
Modelo de dominio
Una vez que definido el comportamiento del sistema en los casos de uso, el siguiente
paso será definir el modelo del dominio del sistema, el cual son las clases que deberán
ser almacenadas persistentemente en el sistema. La figura 15 muestra las clases de
entidad que se identificaron para el modelo del dominio.
Figura 15. Modelo de dominio. Fuente: Elaboración propia.
Clases de control
La figura 16 muestra la clase de control del módulo de seguridad y la figura 17 muestra
las clases de control que se identificaron en los casos de uso. Las clases se definen
con el estereotipo “<<control>>”.
52
Figura 16. Paquete de seguridad. Fuente: Elaboración propia.
Figura 17. Paquete de control. Fuente: Elaboración propia.
Diagramas de secuencia
Cada uno de los casos de uso tendrá asociado un diagrama de secuencia excepto el
caso de uso E1:INICIAR SESIÓN debido a que este caso de uso tiene interacción con
los actores Administrador y Usuario operacional tendrá asociado dos diagramas de
secuencia. Los siguientes diagramas de secuencia describen el comportamiento
dinámico del sistema.
53
Figura 18. OSD_IniciarSesionAdmin. Fuente: Elaboración propia.
Figura 19. OSD_IniciarSesionUO. Fuente: Elaboración propia.
54
Figura 20. OSD_ConsultarCatalogo. Fuente: Elaboración propia.
Figura 21. OSD_AdministrarCatalogo. Fuente: Elaboración propia
55
Figura 22. OSD_Insertarcatalogo. Fuente: Elaboración propia.
Figura 23. OSD_ActualizarCatalogo. Fuente: Elaboración propia.
56
Figura 24. OSD_EliminarCatalogo. Fuente: Elaboración propia.
Figura 25. OSD_AdministrarUsuarios. Fuente: Elaboración propia.
57
Figura 26. OSD_InsertarUsuario. Fuente: Elaboración propia.
Figura 27. OSD_ActualizarUsuario. Fuente: Elaboración propia.
58
Figura 28. OSD_EliminarUsuario. Fuente: Elaboración propia.
Figura 29. OSD_RegistrarPistas. Fuente: Elaboración propia.
Diagramas de colaboración
En los diagramas de colaboración siguientes se representará la colección de objetos
que trabajan juntos para soportar el comportamiento del sistema.
59
Figura 30. OC_IniciarSesionAdmin. Fuente: Elaboración propia.
Figura 31. OC_IniciarSesionUO. Fuente: Elaboración propia.
60
Figura 32. OC_ConsultarCatalogo. Fuente: Elaboración propia.
Figura 33. OC_AdministrarCatalogo. Fuente: Elaboración propia.
Figura 34. OC_Insertarcatalogo. Fuente: Elaboración propia.
61
Figura 35. OC_ActualizarCatalogo. Fuente: Elaboración propia.
Figura 36. OC_EliminarCatalogo. Fuente: Elaboración propia.
Figura 37. OC_AdministrarUsuarios. Fuente: Elaboración propia.
62
Figura 38. OC_InsertarUsuario. Fuente: Elaboración propia.
Figura 39. OC_ActualizarUsuario. Fuente: Elaboración propia.
63
Figura 40. OC_EliminarUsuario. Fuente: Elaboración propia.
Figura 41. OC_RegistrarPistas. Fuente: Elaboración propia.
64
Capítulo IV
Implementación En este capítulo se están documentando como se llevó a cabo la fase de construcción
de cada una de las capas del sistema, se listan las herramientas utilizadas para el
desarrollo de la plantilla base compuesta de componentes reusables. También se
mencionan los casos prácticos en donde se ha aplicado el modelo desarrollado ya sea
de una forma total o parcial a nivel de componentes o servicio web. También se está
realizando un análisis de calidad obteniendo métricas de calidad de código con el
entorno de desarrollo integrado Visual Studio.
Actividades de la fase de Construcción
Las actividades de la fase de construcción fueron las siguientes:
Se elaboró un documento de estándares de codificación el cual se encuentra en
el anexo 1.
Se construyeron la base de datos, la tabla y los procedimientos almacenados
sobre las cuales se implementarán los métodos de acceso a datos.
Se construyeron los componentes reusables.
Se desarrolló la plantilla genérica utilizando estos componentes, el desarrollo de
la plantilla se realizó respetando los estándares de codificación.
Se realizaron pruebas de los componentes y de la plantilla genérica.
Herramientas utilizadas
Como herramienta de desarrollo se utilizó el entorno de desarrollo integrado
Microsoft Visual Studio 2017 seleccionando como lenguaje de programación C#.
Se seleccionó está herramienta de desarrollo debido a que el autor de esta tesis
tiene experiencia como desarrollador en este lenguaje. También se utilizó la
versión Community por el tema de licencias.
Se utilizó el manejador de base de datos Microsoft SQL Server 2016 debido a
que uno de los componentes de acceso a datos es para una base de datos SQL
Server. Se utilizó la versión SQL Server Developer debido a que es una edición
gratuita para ambientes de desarrollo y pruebas. También es uno de los
manejadores de bases de datos en la cual el autor de esta tesis tiene más
experiencia.
Fase de construcción
Construcción de base de datos
Como primer paso para la elaboración de la plantilla base formada de componentes
reutilizables será necesario contar con una estructura de almacenamiento permanente.
La figura 42 muestra el modelo entidad relación, las tablas del diagrama fueron
identificadas durante la creación del modelo de dominio del capítulo anterior.
65
Figura 42. Diagrama E-R. Fuente: Elaboración propia.
En el anexo 2 se encuentra el Script de creación de base de datos, el cual contiene
las instrucciones de creación de la base de datos PlantillaDB. La figura 43 muestra la
ejecución exitosa del script.
Figura 43. Ejecución de script de creación de objetos. Fuente: Elaboración propia.
Una vez creada la base de datos se ejecutará el script Script de creación de objetos
de la base de datos PlantillaDB ubicado en el Anexo 2. Al ejecutar el script se crearan
los objetos de la tabla 14.
Tablas Procedimientos almacenados
BitacoraAcceso
Catalogo
CuentaUsuarios
Operaciones
PistasAuditoria
Usuarios
ActualizarBitacoraAcceso
usp_ActualizarUsuario
usp_ConsultarCatalogo
usp_ConsultarCatalogoPorClave
usp_ConsultarCatalogoPorLlave
usp_ConsultarUsuarioPorClave
66
usp_ConsultarUsuarios
usp_EliminarCatalogo
usp_InsertarCatalogo
usp_InsertarUsuario
usp_RegistrarBitacoraAcceso
usp_RegistrarPistasAuditoria
usp_validarUsuario Tabla 14. Relación de objetos de la base de datos. Fuente: Elaboración propia.
Diccionario de datos
En esta sección se listan los atributos y características de cada una de las tablas
creadas.
ENTIDAD: Catalogo Descripción: Tabla que almacena los tipos de catálogo.
ATRIBUTO TIPO LONGITUD DESCRIPCIÓN NULOS LLAVE
Identificador Int 10 Identificador único consecutivo de la tabla catálogo.
NO SI
Clave Varchar 10 Identificador alfanumérico del catálogo
SI
Descripción Varchar 50 Cadena que describe el catálogo.
SI
Tabla 15. Entidad Catalogo. Fuente: Elaboración propia.
ENTIDAD: Operaciones Descripción: Catálogo que almacena los tipos de operaciones.
ATRIBUTO TIPO LONGITUD DESCRIPCION NULOS LLAVE
IdOperacion Int 10 Identificador único para identificar la operación.
NO SI
Descripcion varchar 100 Descripción de la operación. NO Tabla 16. Entidad Operaciones. Fuente: Elaboración propia.
ENTIDAD: Usuarios Descripción: Catálogo que almacena los tipos de operaciones.
ATRIBUTO TIPO LONGITUD DESCRIPCION NULOS LLAVE
IdUsuario Int 10 Identificador único consecutivo para el Usuario.
NO SI
claveUsuario Varchar 8 Identificador del Usuario.
RFC Varchar 13 RFC del Usuario a 13 posiciones.
NO
Nombre Varchar 20 Nombre del usuario. NO
ApellidoPaterno Varchar 20 Apellido paterno del usuario.
NO
ApellidoMaterno Varchar 20 Apellido materno del usuario.
SI
Rol Varchar 2 Identificador del Rol al que pertenece el usuario.
NO
Estatus Char 1 Indicador si está activo ó inactivo el usuario
NO
Tabla 17. Entidad Usuarios. Fuente: Elaboración propia.
67
ENTIDAD: PistasAuditoria Descripción: Tabla que almacena los tipos de movimiento realizados.
ATRIBUTO TIPO LONGITUD DESCRIPCIÓN NULOS LLAVE
IdPistaAuditoria Bigint 19 Identificador único consecutivo para la pista de auditoria.
NO SI
Fecha datetime Fecha en que se realizó la operación a la que corresponde la pista.
NO
DireccionIP Varchar 15 Dirección IP que identifica a la computadora desde donde se realizó la operación a la que se refiere la pista.
NO
IdOperacion Int 10 Identificador único de la operación realizada a la que corresponde la pista.
NO
IdUsuario Int 10 Identificador del usuario correspondiente a la pista.
NO
IdUsuarioOperacion Int 10 Clave que identifica al usuario que realiza la operación en el sistema.
SI
Tabla 18. Entidad PistasAuditoria. Fuente: Elaboración propia.
ENTIDAD: BitacoraAcceso
Descripción: Tabla para almacenar los históricos de los accesos de los funcionarios al sistema.
ATRIBUTO TIPO LONGITUD DESCRIPCION NULOS LLAVE
IdBitacoraAcceso Bigint 19 Clave para identificar el acceso al sistema.
NO
IdUsuario Int 10 Identificador del usuario. NO
InicioSession datetime Fecha y Hora en que se inicia la sesión.
NO
FinSession datetime Fecha y Hora en que se cierra la sesión.
SI
Rol varchar 2 Rol Activo del usuario. NO
DireccionIP varchar 15 Dirección IP que identifica a la computadora de registro.
SI
Tabla 19. Entidad BitacoraAcceso. Fuente: Elaboración propia.
Construcción de componentes reusables
Para realizar el desarrollo de los componentes se identificó la funcionalidad más común,
la figura 44 muestra el diagrama de componentes de la capa de acceso a datos y capa
de negocio, las cuales estarán contenidas en un servicio web. Los componentes
68
comunes que se construyeron se están diferenciando por distintos colores, la
descripción de estos colores son:
Los bloques verdes son los componentes de acceso a datos.
El bloque amarillo, nombrado Utilerías.
El bloque azul agua, nombrado ControlErrores.
Figura 44. Servicio WEB. Fuente: Elaboración propia.
Los componentes de acceso a datos están divididos en tres bloques verdes, se podría
haber creado solo un módulo pero se tendría una baja cohesión en el componente. Cada
uno de los bloques tiene funcionalidad muy definida.
La figura 45 muestra los componentes de acceso a datos. El componente
DataAccessHelper contiene los métodos de acceso a una base de datos de SQL
Server, en caso de que se quiera desarrollar funcionalidad de acceso a datos de otro
manejador esta clase es la única que se reemplazaría, este módulo hace uso de los
métodos expuestos por las librerías Microsoft.Practices.EnterpriseLibrary. El
componente Entidades tiene implementada una clase con funcionalidad similar al
comportamiento de las propiedades que podrán utilizar las clases que hereden de ella.
Por último el componente ProcessHelper es el responsable de llenar la entidad o
conjunto de entidades con los datos obtiene la clase DataAccessHelper.
69
Figura 45. Componentes de acceso a datos. Fuente: Elaboración propia.
La figura 46 muestra el componente ControlErrores contiene métodos de registro de
errores en el visor de eventos del sistema operativo, así como registro de errores en
archivos log.
Figura 46. Componente de control de errores. Fuente: Elaboración propia.
70
La figura 47 contiene clases con funcionalidad de cifrado de datos, serialización de
objetos a un formato XML o a una estructura de tipo Json, conversión de caracteres.
Figura 47. Componentes de Utilerías. Fuente: Elaboración propia.
Una vez que se terminó la construcción de estos componentes se compilaron y se
generaron bibliotecas de vínculos dinámicos (DLL) lo cual nos hará más fácil la
implementación de nuestra plantilla base, para utilizar estas librerías solo será necesario
realizar la referencia a través del entorno de desarrollo integrado. En caso de que se
hagan mejoras a los componentes comunes el reemplazo se podrá realizar de una
manera transparente.
71
Construcción de servicio web
Se realizó la construcción del servicio web, en el caso de la tecnología .NET estos
servicios son conocidos como Windows Communication Foundation (WCF), se
construyeron tres proyectos, el proyecto ProcesamientoBase que están formados por
la capa de acceso a datos y la capa de negocio, la figura 48 muestra el diagrama de
clases del CRUD sobre la tabla Catalogo, se puede observar que en la capa de negocio
ProcesosNegocio se implementó la clase ProcesosCatalogo, la clase anteriormente
mencionada está consumiendo el componente ProcessHelper. En la capa de acceso
a datos AccesoDatos se implementó la clase DalcCatalogo, que contiene todos los
métodos que invocan a los procedimientos almacenados, la clase DalcCatalogo está
consumiendo el componente DataAccessHelper. La entidad Catalogo está
consumiendo el componente EntityBase, las entidades serán clases transversales que
se utilizan para transportar los datos entre las distintas capas.
Figura 48. Diagrama de clases de ProcesamientoBase. Fuente: Elaboración propia.
El siguiente proyecto que se construyó es el de Seguridad que se muestra en la figura
49, este proyecto contiene una entidad Usuario cuya funcionalidad será transportar la
información de los usuarios que utilizaran el sistema, también se construyeron las
entidades BitacoraAcceso, la cual se encargará de transportar la información de los
accesos al sistema y la entidad PistasAuditoria que registrara las operaciones que se
realizan dentro del sistema. Como se puede observar la estructura del proyecto es muy
similar al proyecto ProcesamientoBase lo cual nos indica que se está respetando
estándares de programación y de diseño.
72
Figura 49. Diagrama de clases de Seguridad. Fuente: Elaboración propia.
El proyecto Procesamiento.ServiciosWCF es la interfaz del servicio web, La figura 50
muestra el proyecto donde se encuentran todos los métodos de ejemplo que quedaran
expuestos del proyecto ProcesamientoBase y del proyecto Seguridad, el desarrollo
de este servicio se realizó respetando los estándares de codificación definidos en el
Anexo 1.
Figura 50. Diagrama de clases del servicioWCF. Fuente: Elaboración propia.
73
Para la construcción del servicio web se está haciendo uso de la Librería de Clase Base,
la librería está incluida en el .NET Framework y está agrupada en espacios de nombres
donde las clases tienen funcionalidad en común. Adicional a la Librería de Clase Base,
fue necesario instalar el paquete Microsoft Enterprise Library, el cual es una colección
de bloques de aplicación reutilizables utilizado para el desarrollo de software y que ataca
los siguientes puntos: almacenamiento de cache, el acceso a datos, criptografía, manejo
de excepciones, seguridad, validación. Para los fines de esta tesis únicamente se utilizó
la funcionalidad de acceso a datos, las librerías utilizadas son:
Microsoft.Practices.EnterpriseLibrary.Common.dll
Microsoft.Practices.EnterpriseLibrary.Data.dll
Microsoft.Practices.ObjectBuilder.dll
El realizar el desarrollo utilizando componentes está reduciendo el tiempo y la cantidad
de líneas a codificar, en el Anexo3 se encuentran los archivos fuentes utilizados para
la construcción del servicio web que contiene las capas de negocio y datos. La figura 51
muestra la instancia del servicio web referente al módulo de seguridad que sera utilizada
para la aplicación web. La figura 52 muestra la instancia del ServicioBase el cual
contiene los métodos del CRUD, este servicio puede ser consumido por una aplicación
web, una aplicación Windows u otro servicio web sin necesidad de utilizar el módulo de
seguridad.
Figura 51. Servicio Seguridad. Fuente: Elaboración propia.
74
Figura 52. Servicio Base. Fuente: Elaboración propia.
Construcción de la aplicación Web
El sitio web se realizó creando una nueva solución de Visual Studio la cual contiene tres
proyectos, un proyecto del tipo aplicación web, que contendrá todos los formularios, un
proyecto de biblioteca de clases llamado Negocio en el cual se implementará la
invocación de los métodos del servicio web. Por último, tendrá otro proyecto de
biblioteca de clases que administra la seguridad del sitio web.
Figura 53. Fuentes de aplicación WEB. Fuente: Elaboración propia.
75
Pruebas del sitio web
Las siguientes imágenes corresponden a la aplicación web construida con componentes
reusables
La figura 54 es la página de inicio de sesión de la aplicación, se captura cuenta de
usuario y contraseña y se presiona el botón Aceptar.
Figura 54. Página de inicio de sesión. Fuente: Elaboración propia.
Al capturar la clave de usuario y la contraseña correcta el sistema se dirige a la página
principal, en el menú principal se selecciona la opción Consulta de Catálogo.
Figura 55. Página principal. Fuente: Elaboración propia.
76
En la caja de texto Clave se captura el dato a buscar y se presiona el botón Aceptar.
Figura 56. Página consulta de catálogo. Fuente: Elaboración propia.
El sistema obtiene los valores Identificador y Descripción asociados a la clave.
Figura 57. Registro nuevo en página Consulta de catálogo. Fuente: Elaboración propia.
77
Al presionar la opción Mantenimiento de Catálogo del menú principal se abre la página
de la figura 58, se presiona el botón Alta para insertar un nuevo registro.
Figura 58. Página Mantenimiento de Catálogo. Fuente: Elaboración propia.
Se registra la clave, descripción y se presiona el botón Agregar.
Figura 59. Página Alta de Catálogo. Fuente: Elaboración propia.
78
Al regresar a la pantalla de Mantenimiento de catálogo, figura 60 se observa que se
insertó el registro deseado.
Figura 60. Página de mantenimiento de Catálogo con alta satisfactoria. Fuente: Elaboración propia.
Para realizar la actualización de un registro se debe seleccionar un elemento y
posteriormente presionar el botón Actualizar.
Figura 61. Selección de registro en la página Mantenimiento de Catálogo. Fuente: Elaboración propia.
79
Se actualiza la descripción y se presiona el botón Guardar.
Figura 62. Página de actualización del catálogo. Fuente: Elaboración propia.
Al realizarse la actualización de forma exitosa el sistema mostrara el mensaje “El registro
fue actualizado correctamente”. Presionar el botón salir para regresar a la pantalla
Mantenimiento de Catálogo.
Figura 63. Mensaje al actualizar registró en la página Actualización de Catálogo. Fuente: Elaboración propia.
80
Al regresar a la pantalla de Mantenimiento de Catalogo se puede observar que la
información se encuentra actualizada.
Figura 64. Página de mantenimiento de Catálogo con actualización satisfactoria. Fuente: Elaboración propia.
Para realizar el borrado de un elemento se seleccionara el elemento que se desea borrar
y posteriormente presionar el botón eliminar.
Figura 65. Selección de registro para eliminar en la página de Mantenimiento de Catálogo. Fuente: Elaboración propia.
81
Al realizarse el borrado el sistema mostrara el mensaje “El registro xxxx fue eliminado”.
Figura 66. Mensaje al eliminar registro en página Mantenimiento de Catálogo. Fuente: Elaboración propia.
Al presionar la opción Mantenimiento de usuarios en el menú principal el sistema
mostrara la pantalla de la imagen 67. Presionar el botón Alta para insertar un nuevo
usuario.
Figura 67. Página Registro de Usuarios. Fuente: Elaboración propia.
82
Capturar los datos correspondientes en las cajas de texto y presionar el botón Agregar.
Figura 68. Página Alta de usuarios. Fuente: Elaboración propia.
Si el registro se realiza de forma exitosa el sistema mostrara el mensaje “El usuario xxx
fue dado de alta satisfactoriamente “.
Figura 69. Mensaje de alta de usuario satisfactoria. Fuente: Elaboración propia.
83
Al regresar a la pantalla Mantenimiento de usuarios el sistema muestra en la tabla Lista
de Usuarios los datos del elemento recién ingresado. Seleccionar el elemento a
actualizar y presionar el botón Actualizar.
Figura 70. Selección de usuario a actualizar. Fuente: Elaboración propia.
Actualizar los datos y presionar el botón Guardar.
Figura 71. Página Actualización de Usuario. Fuente: Elaboración propia.
84
El sistema muestra el mensaje “El usuario xxx fue actualizado correctamente”. Presionar
el botón Salir para regresar a la pantalla de Mantenimiento de Usuarios.
Figura 72. Mensaje exitoso de actualización de usuario. Fuente: Elaboración propia.
Para realizar una baja lógica se debe seleccionar un elemento y presionar el botón Baja.
Figura 73. Selección de usuario a dar de baja. Fuente: Elaboración propia.
85
El sistema muestra el mensaje “El usuario xxx” fue dado de baja.
Figura 74. Mensaje de baja exitosa de usuario. Fuente: Elaboración propia.
Al presionar el botón INICIO el sistema se dirige a la pantalla principal.
Figura 75. Página al presionar el botón INICIO. Fuente: Elaboración propia.
86
Figura 76. Página de Inicio de Sesión al presionar el botón SALIR. Fuente: Elaboración propia.
Caso práctico
Como caso práctico se documentará la utilización de la estructura de software
compuesta de componentes personalizables e intercambiables utilizada en la asignatura
de Sistemas manejadores de bases de datos. En este caso únicamente se hizo uso del
servicio web, debido a que ya se contaba con el componente de acceso a datos
únicamente se realizaron las siguientes actividades:
Se generó una entidad por cada una de las tablas de la base de datos.
Una clase de acceso a datos.
Una clase de negocio.
Una clase de interfaz y una clase con la implementación.
Los procedimientos almacenados de las consultas a realizar.
87
1. Se está consumiendo un método del servicio web que proporciona los datos de
la tabla Organización.
Figura 77. Método ConsultarOrganizacion expuesto en Servicio web.
Fuente: Elaboración propia.
2. Se está consumiendo un método del servicio web que proporciona los datos de
la tabla Area.
Figura 78. Método ConsultarArea expuesto en Servicio web. Fuente: Elaboración propia.
88
3. Se está consumiendo un método del servicio web que proporciona los datos de
la tabla TipoDepartamento.
Figura 79. Método ConsultarTipoDepartamento expuesto en Servicio web. Fuente: Elaboración propia.
4. Se está consumiendo un método del servicio web que proporciona los datos de
la tabla Rol.
Figura 80. Método ConsultarRol expuesto en Servicio web. Fuente: Elaboración propia.
89
5. Se está consumiendo un método del servicio web que proporciona los datos de
la tabla departamento.
Figura 81. Método ConsultarDepartamento expuesto en Servicio web. Fuente: Elaboración propia.
6. Se está consumiendo un método del servicio web que proporciona los datos de
la tabla empleados.
Figura 82. Método ConsultarEmpleado expuesto en Servicio web. Fuente: Elaboración propia.
90
Ventajas de uso del modelo propuesto
En esta sección inicialmente se mostrarán imágenes con tres casos de ejemplo de
métodos de acceso a datos, los dos primeros casos no hacen uso del modelo propuesto,
el tercer caso está haciendo del módulo de acceso a datos construido para el trabajo de
tesis. Posteriormente se obtendrán las métricas de código de los proyectos donde se
encuentran los métodos de las imágenes para realizar una comparativa y observar los
beneficios de utilizar un proyecto compuesto de componentes reusables. Las métricas
se obtendrán utilizando el analizador en el entorno de desarrollo integrado Visual Studio
2017 que fue utilizado para la construcción de este trabajo de tesis.
Caso 1
En la figura 83 se observa el método de acceso a datos el cual realiza una conexión a
una base de datos SQL Server, el método Consulta_DatInventario consume el
procedimiento almacenado pc_SegRev_DatInventarios y con los datos obtenidos se
llena un conjunto de entidades SegRev_DatInventarios, en la imagen se puede
observar que se codifica el llenado de cada uno de los atributos de la entidad.
Figura 83. Método de acceso a datos Consulta_DatInventarios. Fuente: Elaboración propia.
En la figura 84 el método Consulta_OrdenInventario consume el procedimiento
almacenado pc_SegRev_OrdenInventario y con los datos obtenidos se llena un
conjunto de entidades SegRev_DatInventariosC, igual que en la figura 83 se observa
que se codifica el llenado de cada uno de los atributos de la entidad. En este primer
escenario se mostraron dos ejemplos de métodos de acceso a datos, se puede observar
que la funcionalidad es muy similar pero se tiene que codificar el llenado de las entidades
en cada uno de los métodos.
91
Figura 84. Método de acceso a datos Consulta_OrdenInventario. Fuente: Elaboración propia.
92
Caso 2
En la figura 85 se puede observar un método con una implementación distinta de acceso
a datos. El método c_obtenDatosTRecetas tiene la consulta a la tabla TRecetasIMSS
incrustada en código
Figura 85. Método de acceso a datos c_obtenDatosTRecetas. Fuente: Elaboración propia.
La figura 86 muestra el método c_sconfig que tiene implementada una consulta
incrustada de la tabla sconfig. Este método al igual que el de la figura 85 tiene como
valor de retorno un objeto llamado DataTable el cual es un objeto propio de la tecnología
net. Al ser un DataTable un objeto que genera su estructura de forma dinámica se puede
llenar con cualquier consulta sin realizar implementación adicional, sin embargo esto lo
convierte en una gran desventaja al querer consumirlo con otras tecnologías.
93
Figura 86. Método de acceso a datos c_sconfig. Fuente: Elaboración propia.
Caso 3
La figura 87 muestra dos métodos de acceso a datos, en la imagen se puede observar
que los dos métodos son muy similares, únicamente cambian por el nombre de los
métodos que en este caso son c_CatalogoPorLlave y c_CatalogoPorClave. Estos
métodos están invocando a los métodos de la figura 88, la cual se observa que
únicamente realizan el llamado de los procedimientos almacenados respectivos. Como
ventajas, el hacer uso del modelo propuesto en el trabajo de esta tesis es que ya no se
trabaja en el llenado de las entidades, se reducen las líneas de código a escribir, al
utilizar entidades y tener implementado la capad de datos y negocio en un wcf permite
que este proyecto pueda ser consumido por distintas tecnologías.
94
Figura 87. Métodos de acceso a datos c_CatalogoPorLlave y c_CatalogoPorClave. Fuente: Elaboración propia.
Figura 88. Métodos de acceso a datos c_CatalogoPorLlave y c_CatalogoPorClave con llamados a procedimientos almacenados. Fuente: Elaboración propia.
Implementación de patrones
En el anexo 3 se encuentra el código fuente correspondiente al servicio web que tiene
implementado los métodos de la entidad “catalogo”, se puede observar que el método
“c_Catalogo” tiene implementada la línea “return this.CreateEntity<Catalogo>(reader);”,
si se sustituye el valor Catalogo por “PistasAuditoria” o “Usuario” se puede observar que
son las líneas de código que se encuentran implementadas en los métodos de la figura
89, en este caso se puede observar la implementación del patrón de diseño constructor,
que menciona que el mismo proceso de construcción puede crear diferentes
representaciones, en este caso el mismo proceso de construcción está creando tres
distintas representación de entidades.
95
Figura 89. Métodos RegistrarPistasAuditoria y c_UsuarioPorClave. Fuente: Elaboración propia.
En las figuras 85 y 86 se puede observar que está como valor de retorno un objeto
conocido como DataTable, este componente es nativo de la tecnología .net para el
manejo de acceso a datos, las ventajas de usar componentes como DataSet, DataTable,
DataViews es la facilidad de uso y que estos componentes se pueden mandar
directamente a la capa de vista y el control de la vista podría desplegar la información
sin realizar ninguna modificación al código, la principal desventaja es que este
componente no existe en otras tecnologías como java. Para el propósito de esta tesis
se utilizó el patrón Adapter para convertir los objetos de .net a entidades y con esto
permitir que el servicio pueda ser consumido por cualquier sistema con una tecnología
distinta. La figura 90 muestra el bloque de código que se utiliza para convertir el conjunto
de datos de un objeto reader a entidad.
96
Figura 90. Método CreateEntity. Fuente: Elaboración propia.
Métricas de código
La tabla 20 contiene las métricas de código del Ejemplo 1, se puede observar que el
método Consulta_DatInventario con 28 líneas de código tiene un índice de
mantenimiento de 47, que aún se puede considerar bueno y la complejidad ciclomática
es pequeña, sin embargo el método Consulta_OrdenInventario con 61 líneas de
código disminuye mucho en índice de mantenimiento y la complejidad ciclomática se
eleva a 50 lo cual significa que tiene 50 caminos distintos que pueden ocurrir en la
ejecución.
Proyecto Miembro Índice de mantenimiento
Complejidad ciclomática
Acoplamiento de clases
Líneas de código
CADSUIEFI CAD_SegRev_DatInventarios() 89 1 3 1
CADSUIEFI Consulta_DatInventarios(int, string, int, string, string) : List<SegRev_DatInventarios>
47 5 8 28
CADSUIEFI Consulta_OrdenInventario(int) : List<SegRev_DatInventariosC>
29 50 7 61
Entidades SegRev_DatInventarios() 100 1 0 1
Entidades SegRev_DatInventariosC() 100 1 0 1
ServiciosSUIEFI DatInventarios(int, string, int, string, string) : List<SegRev_DatInventarios>
78 1 3 3
ServiciosSUIEFI OrdenInventario(int) : List<SegRev_DatInventariosC>
79 1 3 3
ServiciosSUIEFI SegRev() 100 1 0 1
ServiciosSUIEFI DatInventarios(int, string, int, string, string) : List<SegRev_DatInventarios>
78 1 4 3
ServiciosSUIEFI DatInventariosX() 100 1 1 1
Tabla 20. Métricas de código de Ejemplo 1. Fuente: Elaboración propia.
97
La tabla 21 contiene las métricas de código del ejemplo 2, el método
c_obtenDatosTRecetas a pesar de únicamente contar con 19 líneas de código su
métrica de índice de mantenimiento de 53, aunque este valor se puede considerar
aceptable es necesario verificar que se debe ajustar debido a que tiene muy pocas
líneas de código, también se observa un acoplamiento de clases alto. El método
c_sconfig tiene 16 líneas de código, su índice de mantenimiento es de 56 y su valor de
acoplamiento es de 7. Se puede observar una gran variación de líneas de código por
método.
Proyecto Miembro Índice de mantenimiento
Complejidad ciclomática
Acoplamiento de clases
Líneas de código
MonitoreoIMSS DarRecetaAlta(DataRow, DataRow, DataRow, DataRow, DataRow, int, int) : bool
37 8 18 54
MonitoreoIMSS DarRecetaBaja(DataRow, DataRow) : bool
33 8 23 72
MonitoreoIMSS ImprimirMensaje(DataRow, string) : void
27 56 3 85
MonitoreoIMSS MoverArchivos() : void 48 5 11 26
MonitoreoIMSS Recetas() 80 1 0 3
MonitoreoIMSS RegistrarRecetasIMSS(string, int) : void
54 4 6 17
MonitoreoIMSS validaRecetas(DataRow) : string 23 37 19 126
MonitoreoIMSS obtenercrts(int) : int 63 1 6 8
MonitoreoIMSS ServFinalAut(int, int, int, SqlConnection, SqlTransaction) : bool
38 6 23 53
MonitoreoIMSS Data() 84 1 2 2
MonitoreoIMSS getAdapter(string) : SqlDataAdapter 70 2 3 6
MonitoreoIMSS getConnection() : SqlConnection 68 2 3 7
MonitoreoIMSS ModHH() 100 1 0 1
MonitoreoIMSS c_sconfig(int, int) : DataTable 56 3 7 16
MonitoreoIMSS m_nconfigIncrementaUno(int) : bool 51 4 7 23
MonitoreoIMSS sconfigDAO() 100 1 0 1
MonitoreoIMSS SP_ServiciosAutomaticos() 100 1 0 1
MonitoreoIMSS usp_SFA(int, int, int, SqlConnection, SqlTransaction) : bool
53 4 11 19
MonitoreoIMSS usp_SIA(int, int, int, SqlConnection, SqlTransaction) : bool
53 4 11 19
MonitoreoIMSS a_tebdesglose(int, int, long, int, SqlConnection, SqlTransaction) : bool
51 4 6 22
MonitoreoIMSS tebdesgloseDAO() 100 1 0 1
MonitoreoIMSS a_tebdocumserv(int, int, long, int, SqlConnection, SqlTransaction) : bool
53 4 6 20
MonitoreoIMSS tebdocumservDAO() 100 1 0 1
MonitoreoIMSS a_tebserviciodet(int, int, long, int, SqlConnection, SqlTransaction) : bool
51 4 6 22
MonitoreoIMSS tebserviciodetDAO() 100 1 0 1
MonitoreoIMSS a_tebserviciomae(int, int, long, int, SqlConnection, SqlTransaction) : bool
50 4 6 24
MonitoreoIMSS tebserviciomaeDAO() 100 1 0 1
MonitoreoIMSS a_temserviciodet(int, int, long, int, SqlConnection, SqlTransaction) : bool
49 4 6 26
MonitoreoIMSS temserviciodetDAO() 100 1 0 1
MonitoreoIMSS actualizaReceta(DataRow, int) : bool 49 4 9 25
MonitoreoIMSS c_imprimeRecetas(string) : DataTable 41 2 7 47
98
MonitoreoIMSS c_obtenDatosTRecetas(string) : DataTable
53 3 9 19
MonitoreoIMSS c_VistaTRecetas(string, DataRow) : DataTable
50 4 9 22
Tabla 21. Métricas de código de Ejemplo 2. Fuente: Elaboración propia.
En la tabla 22 se puede observar que los métodos c_CatalogoPorLlave y
c_CatalogoPorClave de la figura 87 tienen 7 líneas de código cada uno de los métodos
con un índice de mantenimiento de 66, una complejidad ciclomática de 2 y un
acoplamiento de 6. Por otro lado cada uno de los métodos de la figura 88 tiene una
línea de código teniendo un índice de mantenimiento de 92. Se puede observar que los
valores de la tabla 22 son muy similares. Ninguno de los métodos de la tabla supera las
10 líneas de código lo cual hace los métodos con un alto índice de mantenimiento. La
complejidad ciclomática más alta es de 2.
Proyecto Miembro Índice de mantenimiento
Complejidad ciclomática
Acoplamiento de clases
Líneas de código
ProcesamientoBase a_Catalogo(params object[]) : IDataReader
92 1 2 1
ProcesamientoBase b_Catalogo(params object[]) : IDataReader
92 1 2 1
ProcesamientoBase c_Catalogo() : IDataReader 94 1 2 1
ProcesamientoBase c_CatalogoPorClave(params object[]) : IDataReader
92 1 2 1
ProcesamientoBase c_CatalogoPorLlave(params object[]) : IDataReader
92 1 2 1
ProcesamientoBase DalcCatalogo() 98 1 1 1
ProcesamientoBase m_Catalogo(params object[]) : IDataReader
92 1 2 1
ProcesamientoBase Catalogo() 100 1 1 1
ProcesamientoBase Clave.get() : string 98 1 0 1
ProcesamientoBase Clave.set(string) : void 95 1 0 1
ProcesamientoBase Descripcion.get() : string 98 1 0 1
ProcesamientoBase Descripcion.set(string) : void 95 1 0 1
ProcesamientoBase Identificador.get() : int 98 1 0 1
ProcesamientoBase Identificador.set(int) : void 95 1 0 1
ProcesamientoBase a_Catalogo(Catalogo) : Catalogo 65 2 6 7
ProcesamientoBase b_Catalogo(Catalogo) : void 68 2 4 6
ProcesamientoBase c_Catalogo() : Catalogo[] 67 2 5 7
ProcesamientoBase c_CatalogoPorClave(Catalogo) : Catalogo
66 2 6 7
ProcesamientoBase c_CatalogoPorLlave(Catalogo) : Catalogo
66 2 6 7
ProcesamientoBase Errores(string, string, string, object[]) : string
62 2 2 9
ProcesamientoBase m_Catalogo(Catalogo) : Catalogo 65 2 6 7
ProcesamientoBase ProcesosCatalogo() 100 1 1 1
Tabla 22. Métricas de código de Ejemplo 3. Fuente: Elaboración propia.
99
Conclusiones El presente trabajo de tesis muestra las ventajas de reusar software. En el caso práctico
se puede observar que al reutilizar la plantilla base compuesta de componentes
reusables las actividades se ven disminuidas, esto debido a que se cuenta con un
conjunto de componentes de código con la funcionalidad requerida, los componentes
utilizados se encuentran ensamblados en un servicio web. Se puede ver claramente
como disminuyen los tiempos de desarrollo ya que se están consumiendo las librerías
de acceso a datos en lugar de invertir tiempo en construir la funcionalidad de acceso a
datos.
El hacer uso de componentes de software ya probado nos ayuda a mejorar la calidad
del producto, debido a que los componentes ya pasaron por etapas de análisis, diseño,
construcción y los distintos tipos de pruebas, unitarias, pruebas de integración, de
estrés, rendimiento, etc. Otro punto a favor es que los componentes pueden
desarrollarse de forma aislada, es decir sin que se encuentren integrados con los
proyectos que están haciendo uso de ellos y una vez que se encuentran probados se
puede realizar el reemplazo sin afectar a los clientes que consumen los componentes.
Es importante hacer notar que el hacer uso de patrones de diseño en los componentes
proporciona la garantía de desarrollar software de mayor calidad. Los patrones de
diseño es una forma de reutilización de alto nivel. Al tener un problema se busca dentro
de un catálogo a qué categoría de problemas pertenece y se reutiliza la idea de solución
para este tipo de problemas.
La creación de la plantilla base disminuye el tiempo de ensamble y configuración de los
componentes, los desarrolladores se enfocan en construir las reglas de negocio en lugar
de invertir tiempo para ver cómo se ensamblan los componentes entre sí o las capas de
la arquitectura definida en este trabajo de tesis.
Una ventaja de desarrollar la plantilla base con componentes es que si en un momento
se decide cambiar alguna de las capas, el proceso de cambio es transparente debido a
que el sistema maneja un principio de alta cohesión y bajo acoplamiento. Como
evidencia se tiene el uso de la plantilla base en la asignatura de sistemas manejadores
de bases de datos, en este caso no se invirtió tiempo en el desarrollo de una interfaz
web, se construyeron los métodos de acceso a datos y debido a que no era necesario
ningún tipo de interacción con un usuario final, se decidió que la capa que iba a consumir
el servicio web compuesto de la capa de acceso a datos y capa de negocio era una
aplicación de consola.
Perspectivas Los componentes reutilizables que se utilizaron para construir la plantilla base han sido
probados y utilizados en ambientes productivos. Como trabajo a futuro de este proyecto
se tiene considerado dar soporte a los componentes, se buscará optimizar cada uno de
los componentes buscando mejorar los atributos de calidad e ir integrando nuevos
patrones de diseño.
Respecto a la plantilla construida se investigarán nuevas tecnologías para integrarlas
progresivamente a la solución previamente creada. Como plan a corto plazo se tiene
100
considerado modificar la capa de vista integrando HTML5 con JavaScript y CSS3.
Además de ver la posibilidad de integrar tecnologías para dispositivos móviles.
Se tiene considerado construir nuevos componentes con los mismos estándares de
diseño y patrones utilizados en los componentes anteriores. Los primeros componentes
a construir están relacionados con módulos de acceso a datos para los motores de
bases de datos de Oracle e Informix. Debido a lo importante que ha sido desarrollar
utilizando patrones de diseño, se estudiarán a profundidad y se buscará construir
componentes con nuevos patrones de diseño.
También se creará una estructura genérica para una arquitectura MVC en la tecnología
de .net. Este proyecto utilizará Entity Framework como tecnología de base de datos. Así
como la integración de frameworks como jquery y boostrap en la capa de vista.
101
Referencia bibliográfica A Guide to the Scrum Body of Knowledge (SBOKTM Guide). (2016) (Third Edit).
SCRUMstudyTM, a brand of VMEdu, Inc.
ASPRunner.NET - code generator for ASP.NET. (2017). Retrieved from https://xlinesoft.com/asprunnernet/index.htm
Brooks, F. P. J. (1986). No silver bullet-essence and accidents of software engineering. Proceedings of the IFIP Tenth World Computing Conference, 1069–1076. https://doi.org/10.1109/MC.1987.1663532
Cervantes, H. (2010). Requerimientos y Arquitectura. SG #28. Retrieved from https://sg.com.mx/revista/28/requerimientos-y-arquitectura#.Wa9G4LLyi01
Christopher Alexander, Sara Ishikawa, M. S. (1977). A Pattern Language: Towns, Buildings, Construction. Oxford University Press (1977).
Dayani-Fard, H. (1999). Legacy Software Systems: Issues, Progress, and Challenges. IBM Technical Report.
Eric Freeman, Elisabeth Freeman, Bert Bates, K. S. (2013). Head First Design Patterns. Carcinogenesis (Vol. 34). O’Reilly. https://doi.org/10.1093/carcin/bgt051
Fracasos de software. (n.d.). Retrieved from https://fracasosdesoftware.wordpress.com/2012/05/18/therac-25/
Gamma, E. (2002). Patrones de diseño: elementos de software orientado a objetos reutilizable. (ADDISON-WESLEY, Ed.).
IDE de Visual Studio. (n.d.). Retrieved from https://www.visualstudio.com/es/vs/
IEEE. (1993). IEEE Standard Glossary of Software Engineering Terminology.
Johnson, R. E. (2001). Designing Reusable Classes.
Koldobica Gotxone Villar, & Rivas, F. B. (2012). Grandes desastres tecnológicos.
Lions, J.-L. (1996). ARIANE 5 Flight 501 Failure.pdf.
Mars Climate Orbiter team finds likely cause of loss. (1999). Retrieved from https://mars.nasa.gov/msp98/news/mco990930.html
Mcconnell, S. (1996). Rapid Development - Taming Wild Software Schedules (1 edition). Microsoft Press.
Mcconnell, S. (2004). Code Complete (Second Edi). Microsoft Press.
National Aeronautics and Space Administration. (1962). Mariner 1. Retrieved from https://nssdc.gsfc.nasa.gov/nmc/spacecraftDisplay.do?id=MARIN1
Pollack, A. (1999). Two Teams, Two Measures Equaled One Lost Spacecraft. LOS ANGELES. Retrieved from http://partners.nytimes.com/library/national/science/100199sci-nasa-mars.html
Quality Attributes. (n.d.). Retrieved from https://msdn.microsoft.com/en-us/library/ee658094.aspx
Roger S. Pressman, P. D., & Bruce R. Maxim, P. D. (2015). Software Engineering A Practitioner’s Approach (EIGHTH EDI). McGraw-Hill Education.
102
Sharma, J., Kumar, A., & Kavita. (2016). A Design Based New Reusable Software Process Model for Component Based Development Environment. Procedia Computer Science, 85(Cms), 922–928. https://doi.org/10.1016/j.procs.2016.05.283
Smart Code Generator (Asp.Net). (2009). Retrieved from http://smartcodegenerator.codeplex.com/
Sommerville, I. (2011). Ingeniería de software 9 (NOVENA EDI). México.
The Crash of the AT&T Network in 1990. (1990). Retrieved from http://www.phworld.org/history/attcrash.htm
Velasco, J. J. (2014). El caso Petrov y otros errores tecnológicos que casi desatan una guerra nuclear. Retrieved from http://www.eldiario.es/turing/Errores-tecnologicos-desatan-guerra-nuclear_0_305519830.html
103
Anexo 1
Convenciones y estándares de nombres
Notación Pascal – El primer carácter de todas las palabras se escribe en Mayúsculas
y los otros caracteres en minúsculas.
Ejemplo: ColorDeFondo
Notación de Camell – El primer carácter de todas las palabras, excepto de la primera
palabra se escribe en Mayúsculas y los otros caracteres en minúsculas.
Ejemplo: colorDeFondo
1. Usa notación Pascal para el nombre de las Clases public class ClaseEjemplo
{
…
}
2. Nombrado de Métodos. i. Usa notación Camell para el nombre de Métodos excepto métodos de
acceso a datos. public void obtenerPrecio(int ai_producto)
{
…
}
ii. Los Método de acceso a datos se nombraran de la siguiente manera. <prefijo>_<descripción>
Prefijo Descripción
c Consulta de datos.
a Inserción de registros.
l Obtiene el resultado de un
cálculo.
m Modificación de registros.
b Eliminación de registros.
3. Se utilizara la siguiente notación de para el nombrado de variables y parámetros de los métodos.
104
<Ámbito><Tipo de dato>_<descripción>
AMBITO
Descripción del prefijo Prefijo
Argumento para una función a
Variable instancia i
Variable global g
Variable local l
Tipo de dato
Descripción Prefijo
Clase Cls
Objeto O
Bolean B
Byte Byt
Long L
String S
Decimal Dc
Char C
DateTime Dt
Double Db
Integer I
DataSet Dts
DataTable Dtb
DataColumn Dtc
DataRow Dtr
Ejemplo:
public bool validarProducto(String as_nombre)
{
105
int li_cuentaTotal = 0;
...
}
4. Usa el prefijo “I” con notación Pascal para las interfaces (Ejemplo: IEntity). 5. Usa palabras entendibles y descriptivas para nombrar a las variables. Evitar el
uso de abreviaturas a menos que el nombre completo sea excesivo. En los casos necesarios, las abreviaturas deben ser totalmente conocidas y aprobadas por los integrantes del equipo.
Correcto:
string direccion;
int salario;
Incorrecto:
string nom;
string domic;
int sal;
6. No uses nombres de variables de un solo caracter como i, n, s etc. Usa nombres como indice, temp. Una excepción en este caso podría ser las variables usadas para iteraciones
en los ciclos:
for ( int i = 0; i < li_ordenes; i++)
{
…
}
7. No uses palabras reservadas para nombres de variables. 8. Los nombres de Clases o Métodos y funciones deben seguir el estándar:
<Accion><descripción>
GetClientes();
AddCliente();
9. Los nombres de los espacios de nombres deben seguir el siguiente estándar de patrón
<NombreDeCompañía>.<NombreDeProducto>.<MóduloSuperior>.<MóduloInferior>
10. Usa un prefijo apropiado para cada elemento de la interfaz gráfica.
106
Controles
Control Prefijo
Label Lbl
Textbox Txt
DataGrid Dtg
Button Btn
DropDownList Ddl
ListBox Lst
Checkbox chk
RadioButton Rbt
RadioButtonlist Rbl
Panel pan
Validators val
GridView grv
Forma Frm
LinkButton Lnk
ImageButton ibtn
image img
checkboxlist chkl
Ejemplo:
lblNombre
Identación y espacios
11. Usa #region para agrupar piezas de código juntas. 12. Use un interlineado para separar bloques de código.
107
Anexo 2
Script de creación de base de datos USE [master] GO CREATE DATABASE [PlantillaDB] ON PRIMARY ( NAME = N'PlantillaDB', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLFARG2008\MSSQL\DATA\PlantillaDB.mdf' , SIZE = 18432KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ) LOG ON ( NAME = N'PlantillaDB_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLFARG2008\MSSQL\DATA\PlantillaDB.ldf' , SIZE = 13632KB , MAXSIZE = 2048GB , FILEGROWTH = 10%) GO ALTER DATABASE [PlantillaDB] SET COMPATIBILITY_LEVEL = 100 GO IF (1 = FULLTEXTSERVICEPROPERTY('IsFullTextInstalled')) begin EXEC [PlantillaDB].[dbo].[sp_fulltext_database] @action = 'enable' end GO ALTER DATABASE [PlantillaDB]SET ANSI_NULL_DEFAULT OFF GO ALTER DATABASE [PlantillaDB]SET ANSI_NULLS OFF GO ALTER DATABASE [PlantillaDB]SET ANSI_PADDING OFF GO ALTER DATABASE [PlantillaDB]SET ANSI_WARNINGS OFF GO ALTER DATABASE [PlantillaDB]SET ARITHABORT OFF GO ALTER DATABASE [PlantillaDB]SET AUTO_CLOSE OFF GO ALTER DATABASE [PlantillaDB]SET AUTO_CREATE_STATISTICS ON GO ALTER DATABASE [PlantillaDB]SET AUTO_SHRINK OFF GO ALTER DATABASE [PlantillaDB]SET AUTO_UPDATE_STATISTICS ON GO ALTER DATABASE [PlantillaDB]SET CURSOR_CLOSE_ON_COMMIT OFF GO ALTER DATABASE [PlantillaDB]SET CURSOR_DEFAULT GLOBAL GO ALTER DATABASE [PlantillaDB]SET CONCAT_NULL_YIELDS_NULL OFF GO ALTER DATABASE [PlantillaDB]SET NUMERIC_ROUNDABORT OFF GO ALTER DATABASE [PlantillaDB]SET QUOTED_IDENTIFIER OFF GO ALTER DATABASE [PlantillaDB]SET RECURSIVE_TRIGGERS OFF GO ALTER DATABASE [PlantillaDB]SET DISABLE_BROKER GO ALTER DATABASE [PlantillaDB]SET AUTO_UPDATE_STATISTICS_ASYNC OFF GO ALTER DATABASE [PlantillaDB]SET DATE_CORRELATION_OPTIMIZATION OFF GO ALTER DATABASE [PlantillaDB]SET TRUSTWORTHY OFF GO ALTER DATABASE [PlantillaDB]SET ALLOW_SNAPSHOT_ISOLATION OFF GO
108
ALTER DATABASE [PlantillaDB]SET PARAMETERIZATION SIMPLE GO ALTER DATABASE [PlantillaDB]SET READ_COMMITTED_SNAPSHOT OFF GO ALTER DATABASE [PlantillaDB]SET HONOR_BROKER_PRIORITY OFF GO ALTER DATABASE [PlantillaDB]SET READ_WRITE GO ALTER DATABASE [PlantillaDB]SET RECOVERY SIMPLE GO ALTER DATABASE [PlantillaDB]SET MULTI_USER GO ALTER DATABASE [PlantillaDB]SET PAGE_VERIFY CHECKSUM GO ALTER DATABASE [PlantillaDB]SET DB_CHAINING OFF GO
109
Script de creación de objetos de la base de datos PlantillaDB --Script de creación de objetos de la base de datos PlantillaDB USE PlantillaDB go CREATE TABLE dbo.Catalogo ( Identificador int, clave varchar(10), descripcion varchar(50), PRIMARY KEY(Identificador) ) go USE PlantillaDB go CREATE PROCEDURE usp_ActualizarCatalogo @ai_Identificador int, @av_clave varchar(10), @av_descripcion varchar(50) AS BEGIN SET NOCOUNT ON; update Catalogo set clave = @av_clave, descripcion = @av_descripcion where Identificador = @ai_Identificador END go CREATE PROCEDURE usp_ConsultarCatalogo AS BEGIN SET NOCOUNT ON; select Identificador, clave, descripcion from Catalogo END go CREATE PROCEDURE usp_ConsultarCatalogoPorClave @av_clave varchar(10) AS BEGIN SET NOCOUNT ON; SELECT Identificador, clave, descripcion FROM Catalogo WHERE clave=@av_clave END go CREATE PROCEDURE usp_ConsultarCatalogoPorLlave @ai_Identificador int AS BEGIN SET NOCOUNT ON;
110
SELECT Identificador, clave, descripcion FROM Catalogo WHERE Identificador=@ai_Identificador END go CREATE PROCEDURE usp_EliminarCatalogo @ai_Identificador int AS BEGIN SET NOCOUNT ON; DELETE FROM Catalogo where Identificador = @ai_Identificador END go CREATE PROCEDURE usp_InsertarCatalogo @ai_Identificador int, @av_clave varchar(10), @av_descripcion varchar(50) AS BEGIN SET NOCOUNT ON; set @ai_Identificador = (select isnull(max(Identificador), 0) + 1 from Catalogo) INSERT INTO Catalogo ( Identificador, clave, descripcion ) VALUES ( @ai_Identificador, @av_clave, @av_descripcion ) select @ai_Identificador as Identificador END go CREATE TABLE Usuarios( IdUsuario int NOT NULL, claveUsuario varchar(8) NOT NULL, RFC varchar(13) NOT NULL, Nombre varchar(20) NOT NULL, ApellidoPaterno varchar(20) NOT NULL, ApellidoMaterno varchar(20) NULL, Rol varchar(2) NOT NULL, Estatus char(1) NOT NULL, CONSTRAINT PK_Usuario PRIMARY KEY ( IdUsuario ASC ) ) ON PRIMARY GO ALTER TABLE Usuarios
111
ADD CONSTRAINT UC_ClaveUsuario UNIQUE (ClaveUsuario); CREATE TABLE BitacoraAcceso( IdBitacoraAcceso bigint NOT NULL, IdUsuario int NOT NULL, InicioSession datetime NOT NULL, FinSession datetime NULL, Rol varchar(4) NOT NULL, DireccionIP varchar(15) NULL ) ON PRIMARY GO CREATE TABLE CuentaUsuarios( IdCuentaUsuario int NOT NULL, claveUsuario varchar(8) NOT NULL UNIQUE, Contrasenia varchar(13) NOT NULL, CONSTRAINT PK_CuentaUsuario PRIMARY KEY ( IdCuentaUsuario ASC ) ) ON PRIMARY GO ALTER TABLE CuentaUsuarios ADD CONSTRAINT UC_CuentaClaveUsuario UNIQUE (ClaveUsuario); go CREATE PROCEDURE usp_RegistrarBitacoraAcceso @IdBitacoraAcceso int, @IdUsuario int, @InicioSession datetime, @FinSession datetime, @Rol varchar(4), @DireccionIP varchar(15) AS BEGIN set @IdBitacoraAcceso = (select isnull(max(IdBitacoraAcceso), 0) + 1 from bitacoraacceso) INSERT INTO bitacoraacceso ( IdBitacoraAcceso, IdUsuario, InicioSession, Rol, DireccionIP ) VALUES ( @IdBitacoraAcceso, @IdUsuario, @InicioSession, @Rol, @DireccionIP ) select @IdBitacoraAcceso as IdBitacoraAcceso END go CREATE PROCEDURE ActualizarBitacoraAcceso @IdBitacoraAcceso int,
112
@FinSession datetime AS BEGIN UPDATE bitacoraacceso SET FinSession = @FinSession WHERE IdBitacoraAcceso = @IdBitacoraAcceso END go CREATE PROCEDURE usp_ConsultarUsuarioPorClave @av_claveUsuario varchar(8) AS BEGIN SET NOCOUNT ON; SELECT IdUsuario, claveUsuario, RFC, Nombre, ApellidoPaterno, ApellidoMaterno, Rol, Estatus FROM Usuarios WHERE claveUsuario=@av_claveUsuario END GO CREATE PROCEDURE usp_InsertarUsuario @ai_IdUsuario int, @av_claveUsuario varchar(8), @av_RFC varchar(13), @av_Nombre varchar(20), @av_ApellidoPaterno varchar(20), @av_ApellidoMaterno varchar(20), @av_Rol varchar(2), @ac_Estatus char(1) AS BEGIN SET NOCOUNT ON; set @ai_IdUsuario = (select isnull(max(IdUsuario), 0) + 1 from Usuarios) INSERT INTO Usuarios ( IdUsuario, claveUsuario, RFC, Nombre, ApellidoPaterno, ApellidoMaterno, Rol, Estatus ) VALUES ( @ai_IdUsuario, @av_claveUsuario, @av_RFC, @av_Nombre, @av_ApellidoPaterno, @av_ApellidoMaterno,
113
@av_Rol, @ac_Estatus ) select @ai_IdUsuario as IdUsuario END go CREATE PROCEDURE usp_ActualizarUsuario @ai_IdUsuario INT, @av_claveUsuario VARCHAR(8), @av_RFC VARCHAR(13), @av_Nombre VARCHAR(20), @av_ApellidoPaterno VARCHAR(20), @av_ApellidoMaterno VARCHAR(20), @av_Rol VARCHAR(2), @ac_Estatus CHAR(1) AS BEGIN SET NOCOUNT ON; UPDATE Usuarios SET claveUsuario = @av_claveUsuario, RFC = @av_RFC, Nombre = @av_Nombre, ApellidoPaterno = @av_ApellidoPaterno, ApellidoMaterno = @av_ApellidoMaterno, Rol = @av_Rol, Estatus = @ac_Estatus WHERE claveUsuario = @av_claveUsuario SELECT IdUsuario, claveUsuario, RFC, Nombre, ApellidoPaterno, ApellidoMaterno, Rol, Estatus FROM Usuarios WHERE claveUsuario=@av_claveUsuario END go CREATE PROCEDURE usp_ConsultarUsuarios AS BEGIN SET NOCOUNT ON; SELECT IdUsuario, claveUsuario, RFC, Nombre, ApellidoPaterno, ApellidoMaterno, Rol, Estatus FROM Usuarios END go CREATE PROCEDURE usp_validarUsuario @av_claveUsuario varchar(8), @av_contrasenia varchar(13) AS BEGIN
114
SET NOCOUNT ON; IF EXISTS(SELECT IdCuentaUsuario FROM CuentaUsuarios WHERE claveUsuario=@av_claveUsuario AND contrasenia=@av_contrasenia) BEGIN SELECT 1 END ELSE BEGIN SELECT 0 END END GO CREATE TABLE Operaciones ( IdOperacion int NOT NULL, Descripcion varchar(100) NOT NULL, CONSTRAINT PK_Operaciones PRIMARY KEY CLUSTERED (IdOperacion) ) go CREATE TABLE PistasAuditoria ( IdPistaAuditoria bigint NOT NULL, IdUsuario int NOT NULL, DireccionIP nvarchar(15) NOT NULL, IdOperacion int NOT NULL, Fecha datetime NOT NULL, IdUsuarioOperacion int NULL, CONSTRAINT PK_BitacoraUsuario PRIMARY KEY CLUSTERED (IdPistaAuditoria) ) go ALTER TABLE PistasAuditoria WITH CHECK ADD CONSTRAINT FK_PistasAuditoria_Usuarios FOREIGN KEY(IdUsuario) REFERENCES Usuarios (IdUsuario) GO ALTER TABLE PistasAuditoria CHECK CONSTRAINT FK_PistasAuditoria_Usuarios GO ALTER TABLE PistasAuditoria WITH CHECK ADD CONSTRAINT FK_PistasAuditoria_Operaciones FOREIGN KEY(IdOperacion) REFERENCES Operaciones (IdOperacion) GO ALTER TABLE PistasAuditoria CHECK CONSTRAINT FK_PistasAuditoria_Operaciones GO CREATE PROCEDURE usp_RegistrarPistasAuditoria @ai_IdPistaAuditoria bigint, @ai_IdUsuario int, @av_DireccionIP varchar(15), @ai_IdOperacion int, @adt_Fecha datetime, @ai_IdUsuarioOperacion int AS BEGIN
115
set @ai_IdPistaAuditoria = (select isnull(max(IdPistaAuditoria), 0) + 1 from PistasAuditoria) INSERT INTO PistasAuditoria ( IdPistaAuditoria, IdUsuario, DireccionIP, IdOperacion, Fecha, IdUsuarioOperacion ) VALUES ( @ai_IdPistaAuditoria, @ai_IdUsuario, @av_DireccionIP, @ai_IdOperacion, @adt_Fecha, @ai_IdUsuarioOperacion ) select @ai_IdPistaAuditoria as IdPistaAuditoria END go
116
Anexo 3
Fuentes de clase DalcCatalogo using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using System.Data; using Comunes.AccesoDatos; namespace ProcesamientoBase.AccesoDatos { public class DalcCatalogo : DataAccessHelper { public DalcCatalogo(): base("BaseDeDatos") { } public IDataReader c_CatalogoPorLlave(params object[] parameters) { return this.ExecuteReader("usp_ConsultarCatalogoPorLlave", parameters); } public IDataReader c_CatalogoPorClave(params object[] parameters) { return this.ExecuteReader("usp_ConsultarCatalogoPorClave", parameters); } public IDataReader c_Catalogo() { return this.ExecuteReader("usp_ConsultarCatalogo"); } public IDataReader a_Catalogo(params object[] parameters) { return this.ExecuteReader("usp_InsertarCatalogo", parameters); } public IDataReader m_Catalogo(params object[] parameters) { return this.ExecuteReader("usp_ActualizarCatalogo", parameters); } public IDataReader b_Catalogo(params object[] parameters) { return this.ExecuteReader("usp_EliminarCatalogo", parameters); } } }
117
Fuentes de clase ProcesosCatalogo using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using ProcesamientoBase.Entidades; using ProcesamientoBase.AccesoDatos; using Comunes.ProcesosNegocio; namespace ProcesamientoBase.ProcesosNegocio { public class ProcesosCatalogo:ProcessHelper { public String Errores(String metodo, String message, String argumentos, object[] parametros) { String leyenda = ""; if (parametros == null) { leyenda = "Error: " + metodo + ", " + message + " - " + argumentos; } else { leyenda = "Error: " + metodo + ", " + message + " - " + parametros; } ControlErrores controlErrores = new ControlErrores(); controlErrores.EnviaLog("ProcCatalogo", "ProcCatalogo", leyenda); controlErrores.GuardaBitacora(DateTime.Now + leyenda); return leyenda; } public Catalogo c_CatalogoPorLlave(Catalogo acls_Catalogo) { try { DalcCatalogo lcls_DalcCatalogo = new DalcCatalogo(); System.Data.IDataReader reader = lcls_DalcCatalogo.c_CatalogoPorLlave(acls_Catalogo.Identificador); return this.CreateEntity<Catalogo>(reader); } catch (Exception ex) { String metodo = Errores("c_CatalogoPorLlave", ex.Message, null, acls_Catalogo.GetValues()); throw new Exception(metodo); } } public Catalogo c_CatalogoPorClave(Catalogo acls_Catalogo) { try { DalcCatalogo lcls_DalcCatalogo = new DalcCatalogo(); System.Data.IDataReader reader = lcls_DalcCatalogo.c_CatalogoPorClave(acls_Catalogo.Clave); return this.CreateEntity<Catalogo>(reader); } catch (Exception ex) { String metodo = Errores("c_CatalogoPorClave", ex.Message, null, acls_Catalogo.GetValues());
118
throw new Exception(metodo); } } public Catalogo[] c_Catalogo() { try { DalcCatalogo lcls_DalcCatalogo = new DalcCatalogo(); System.Data.IDataReader reader = lcls_DalcCatalogo.c_Catalogo(); return this.CreateEntityCollection<Catalogo>(reader); } catch (Exception ex) { String metodo = Errores("c_Catalogo", ex.Message, null, null); throw new Exception(metodo); } } public Catalogo a_Catalogo(Catalogo acls_Catalogo) { DalcCatalogo lcls_DalcCatalogo = new DalcCatalogo(); try { System.Data.IDataReader reader = lcls_DalcCatalogo.a_Catalogo(acls_Catalogo.Identificador, acls_Catalogo.Clave, acls_Catalogo.Descripcion); return this.CreateEntity<Catalogo>(reader); } catch (Exception ex) { String metodo = Errores("a_Catalogo", ex.Message, null, acls_Catalogo.GetValues()); throw new Exception(metodo); } } public Catalogo m_Catalogo(Catalogo acls_Catalogo) { DalcCatalogo lcls_DalcCatalogo = new DalcCatalogo(); try { System.Data.IDataReader reader = lcls_DalcCatalogo.m_Catalogo(acls_Catalogo.Identificador, acls_Catalogo.Clave, acls_Catalogo.Descripcion); return this.CreateEntity<Catalogo>(reader); } catch (Exception ex) { String metodo = Errores("m_Catalogo", ex.Message, null, acls_Catalogo.GetValues()); throw new Exception(metodo); } } public void b_Catalogo(Catalogo acls_Catalogo) { DalcCatalogo lcls_DalcCatalogo = new DalcCatalogo(); try { lcls_DalcCatalogo.b_Catalogo(acls_Catalogo.Identificador); } catch (Exception ex) { String metodo = Errores("b_Catalogo", ex.Message, null, acls_Catalogo.GetValues());
119
throw new Exception(metodo); } } } }
120
Fuentes de entidad TablaPlantilla using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using Comunes.AccesoDatos; using Comunes.Entidades; using Comunes.ProcesosNegocio; using System.Runtime.Serialization; namespace ProcesamientoBase.Entidades { [DataContract] public class Catalogo : EntityBase { #region Campos privados... [EntityColumn(0)] private int identificador; [EntityColumn(1)] private string clave; [EntityColumn(2)] private string descripcion; #endregion #region Propiedades públicas... [DataMember] public int Identificador { get { return identificador; } set { identificador = value; } } [DataMember] public string Clave { get { return clave; } set { clave = value; } } [DataMember] public string Descripcion { get { return descripcion; } set { descripcion = value; } } #endregion } }
121
Fuentes de interfaz de servicio IServicioBase using System; using System.Collections.Generic; using System.Linq; using System.Runtime.Serialization; using System.ServiceModel; using System.Text; using ProcesamientoBase.Entidades; namespace Procesamiento.ServiciosWCF { // NOTA: puede usar el comando "Rename" del menú "Refactorizar" para cambiar el nombre de interfaz "IServicioBase" en el código y en el archivo de configuración a la vez. [ServiceContract] public interface IServicioBase { [OperationContract] Catalogo c_CatalogoPorLlave(Catalogo acls_TablaPlantilla); [OperationContract] Catalogo c_CatalogoPorClave(Catalogo acls_TablaPlantilla); [OperationContract] Catalogo[] c_Catalogo(); [OperationContract] Catalogo a_Catalogo(Catalogo acls_TablaPlantilla); [OperationContract] Catalogo m_Catalogo(Catalogo acls_TablaPlantilla); [OperationContract] void b_Catalogo(Catalogo acls_TablaPlantilla); } }
Fuentes de implementación de servicio ServicioBase using System; using System.Collections.Generic; using System.Linq; using System.Runtime.Serialization; using System.ServiceModel; using System.Text; using ProcesamientoBase.Entidades; using ProcesamientoBase.ProcesosNegocio; namespace Procesamiento.ServiciosWCF { public class ServicioBase : IServicioBase { public Catalogo a_Catalogo(Catalogo acls_Catalogo) { ProcesosCatalogo lcls_procesos = new ProcesosCatalogo(); return lcls_procesos.a_Catalogo(acls_Catalogo); } public void b_Catalogo(Catalogo acls_Catalogo) { ProcesosCatalogo lcls_procesos = new ProcesosCatalogo(); lcls_procesos.b_Catalogo(acls_Catalogo); }
122
public Catalogo[] c_Catalogo() { ProcesosCatalogo lcls_procesos = new ProcesosCatalogo(); return lcls_procesos.c_Catalogo(); } public Catalogo c_CatalogoPorClave(Catalogo acls_Catalogo) { ProcesosCatalogo lcls_procesos = new ProcesosCatalogo(); return lcls_procesos.c_CatalogoPorClave(acls_Catalogo); } public Catalogo c_CatalogoPorLlave(Catalogo acls_Catalogo) { ProcesosCatalogo lcls_procesos = new ProcesosCatalogo(); return lcls_procesos.c_CatalogoPorLlave(acls_Catalogo); } public Catalogo m_Catalogo(Catalogo acls_Catalogo) { ProcesosCatalogo lcls_procesos = new ProcesosCatalogo(); return lcls_procesos.m_Catalogo(acls_Catalogo); } } }
