repositorio.ucp.edu.corepositorio.ucp.edu.co/bitstream/10785/3048/1/CDPEIST23.pdf · Sistema de...

SISTEMA DE CORRESPONDENCIA CENTRO DE ACOPIO

ÁLVARO HERNÁN CÁRDENAS VALENCIA

UNIVERSIDAD CATÓLICA POPULAR DEL RISARALDA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PRACTICAS PROFESIONALES

PEREIRA 2010

Sistema de Correspondencia Centro de Acopio Registraduría Nacional del Estado Civil

Práctica UCPR-IST

Álvaro Hernán Cárdenas Valencia Página 2



Informe de Práctica Profesional

Tutor:

ALVARO IGNACIO MORALES Ingeniero de Sistemas

Jefe Inmediato:

SANDRA MILENA RAMIREZ ACOSTA Ingeniera de sistemas

UNIVERSIDAD CATÓLICA POPULAR DEL RISARALDA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNUCACIONES PRACTICAS PROFESIONALES

PEREIRA 2010


Práctica UCPR-IST


DEDICATORIA

Este trabajo está dedicado a mi padre Jorge Humberto Cárdenas López, a mi madre Luz Mariana Valencia Loaiza, por formarme como persona y por el esfuerzo que están haciendo por sacar la familia adelante brindándonos la oportunidad de estudiar para poder tener un mejor futuro.


Práctica UCPR-IST


AGRADECIMIENTOS

Registraduría Nacional del Estado Civil, Delegación Departamental del

Risaralda, Centro de Acopio. Por permitirme llevar a cabo la práctica

profesional en esta entidad.

Sandra Milena Ramírez Acosta, Ingeniera de sistemas y Coordinadora del

centro de acopio, por su colaboración en este proceso.

Álvaro Ignacio Morales, Ingeniero de Sistemas, Docente de la UCPR y tutor de

la práctica, por la orientación brindada para poder llevar a cabo este proceso.


Práctica UCPR-IST


CONTENIDO

Pág.

TITULO………………………………………………………………….…….………30

INTRODUCCION…………………………………………………...…………..…...31

1. PRESENTACION DE LA ORGANIZACIÓN O SITIO DE PRÁCTICA….32

2. DEFINICIÓN DE LAS LÍNEAS DE INTERVENCIÓN………………..…..47

3. DIAGNÓSTICO DEL ÁREA DE INTERVENCIÓN……………………….47

4. EJE DE INTERVENCIÓN……………………………………………….….48

5. JUSTIFICACIÓN DEL EJE DE INTERVENCIÓN………………….…….49

6. OBJETIVOS DEL PROYECTO…………………..…………………….….50

6.1 OBJETIVO GENERAL OBJETIVO ……………………………….…..50

6.2 OBJETIVOS ESPECÍFICO……………………………………….……50


Práctica UCPR-IST


7. REFERENTE CONCEPTUAL………………………………………...…….51

8. PRESENTACION Y ANÁLISIS DE RESULTADOS…………………..….74

8.1 MODELO DE REQUISISTOS……………………………..…………….....74

8.2 MODELO DE ANÁLISIS…………………………………….………….…108

8.3 MODELO DE DISEÑO……………………………………………….…..175

8.4 MODELO DE IMPLEMENTACIÓN………………………………….…..319

9. CONCLUSIONES…………………………………………………….……355

10. RECOMENDACIONES……………………………………………..……..356

BIBLIOGRAFIA……………………………………………………………….……357

ANEXOS…………………………………………………………………….……...358


Práctica UCPR-IST


LISTA DE TABLAS

Pág.

Tabla 8.1.1. Clases candidatas para el Sistema de correspondencia………………………………………………….……98 Tabla 8.1.2. Clases candidatas para el Sistema de correspondencia identificada De la descripción del problema……...……………………………………..………99 Tabla 8.1.3. Clases identificadas para el Sistema de correspondencia…………………………………………………..….100 Tabla 8.1.4. Asociaciones identificadas con roles para relacionar clases en el dominio del problema………………………..…..101 Tabla 8.1.5. Atributos identificados para las clases identificadas en el sistema de Correspondencia………………………..…….104 . Tabla 8.2.1. Relación entre casos de uso, actores y clases borde para el sistema de correspondencia………………………..…113 Tabla 8.2.2. Relación entre casos de uso y clases entidad para el sistema de correspondencia…………………………….……..117 Tabla 8.2.3. Relación entre casos de uso y clases control para el sistema de correspondencia……………………………………120 Tabla 8.3.1. Tarjeta para la clase ManejadorValidación Con responsabilidades identificadas hasta el momento……………………..180 Tabla 8.3.2. Tarjeta para la clase PantallaValidación con responsabilidades identificadas hasta el momento………………………180 Tabla 8.3.3. Tarjeta para la clase ManejadorRegistroUsuario con responsabilidades identificadas hasta el momento……………………..181 Tabla 8.3.4. Tarjeta para la clase InterfaceBaseDatosCorrespondencia Con responsabilidades identificadas hasta el momento……………………...181 Tabla 8.3.5. Tarjeta para la clase ManejadorMenuServicios

Clases

Nota

Las tablas solo se encuentran en el documento impreso.


Práctica UCPR-IST


con responsabilidades identificadas hasta el momento………………………182 Tabla 8.3.6. Tarjeta para la clase InterfaceUsuario con Responsabilidades identificadas hasta el momento………………………….188 Tabla 8.3.7. Tarjeta para la clase ManejadorMenuServicios con responsabilidades identificadas hasta el momento………………………189 Tabla 8.3.8. Tarjeta para la clase PantallaMenuServicio con responsabilidades identificadas hasta el momento………………………189 Tabla 8.3.9. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento……………………………195 Tabla 8.3.10. Tarjeta para la clase ManejadorDespachada con responsabilidades identificadas hasta el momento………………………196 Tabla 8.3.11. Tarjeta para la clase PantallaCorrespondenciaDespachada con nuevas responsabilidades identificadas hasta el momento……………..196 Tabla 8.3.12. Tarjeta para la clase InterfaceBaseDatosCorrespondecia con responsabilidades identificadas hasta el momento……………………..197 Tabla 8.3.13. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento………………………202 Tabla 8.3.14. Tarjeta para la clase ManejadorRecibida con responsabilidades identificadas hasta el momento………………………203 Tabla 8.3.15. Tarjeta para la clase PantallaCorrespondenciaRecibida con nuevas responsabilidades identificadas hasta el momento……………..203 Tabla 8.3.16. Tarjeta para la clase InterfaceBaseDatosCorrespondecia con responsabilidades identificadas hasta el momento………………………204 Tabla 8.3.17. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento………………………207 Tabla 8.3.18. Tarjeta para la clase ManejadorBusqueda con responsabilidades identificadas hasta el momento………………………208 Tabla 8.3.19. Tarjeta para la clase PantallaBusquedaCorrespondencia con nuevas responsabilidades identificadas hasta el momento……………..208 Tabla 8.3.20. Tarjeta para la clase InterfaceBaseDatosCorrespondecia con responsabilidades identificadas hasta el momento……………………...209


Práctica UCPR-IST


Tabla 8.3.21. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento……………………...211 Tabla 8.3.22. Tarjeta para la clase ManejadorBusqueda con responsabilidades identificadas hasta el momento………………………211 Tabla 8.3.23. Tarjeta para la clase PantallaCorrespondenciaEncontrada con nuevas responsabilidades identificadas hasta el momento……………..212 Tabla 8.3.24. Tarjeta para la clase InterfaceBaseDatosCorrespondencia con responsabilidades identificadas hasta el momento………………………212 Tabla 8.3.25. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento………………………216 Tabla 8.3.26. Tarjeta para la clase ManejadorInformes

con responsabilidades identificadas hasta el momento………………………216

Tabla 8.3.26.1 Tarjeta para la clase PantallaInformesCorrespondencia con nuevas responsabilidades identificadas hasta el momento……………..217 Tabla 8.3.27. Tarjeta para la clase InterfaceBaseDatosCorrespondecia con responsabilidades identificadas hasta el momento……………………...217 Tabla 8.3.28. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento………………………219 Tabla 8.3.29. Tarjeta para la clase ManejadorManual con responsabilidades identificadas hasta el momento………………………220 Tabla 8.3.30. Tarjeta para la clase PantallaManualusuario con nuevas responsabilidades identificadas hasta el momento……………..220 Tabla 8.3.31. Tarjeta para la clase InterfaceUsario con responsabilidades identificadas de los casos de uso ……………………………….…...………….221 Tabla 8.3.32. Tarjeta para la clase ManejadorValidación con responsabilidades identificadas de los casos de uso ValidarUsuario….222 Tabla 8.3.33. Tarjeta para la clase PantallaValidación con responsabilidades de interface identificadas de los casos de uso ValidarUsuario…………………………………………………….223 Tabla 8.3.34. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades identificadas de los casos de uso ValidarUsuario……….223


Práctica UCPR-IST


Tabla 8.3.35. Tarjeta para la clase InterfaceBaseDatosCorrespondencia con responsabilidades de escribir y leer información de registro de usuario y registro de correspondencia para los casos de uso, ValidarUsuario………..224 Tabla 8.3.36. Tarjeta para la clase ManejadorMenuServicio con responsabilidades a partir de los casos de uso Validar Usuario y Ofrecer Servicios……………………………………………………………….225 Tabla 8.3.36.1 Tarjeta para la clase PantallaMenuServicio

con responsabilidades a partir de los casos de uso

Validar Usuario y Ofrecer Servicios……………………………………………..225

Tabla 8.3.37. Tarjeta para la clase InterfaceUsario con responsabilidades y colaboraciones identificadas de los casos de uso, ValidarUsuario………….227 Tabla 8.3.38. Tarjeta para la clase ManejadorValidación con responsabilidades y colaboraciones identificadas de los casos de uso, ValidarUsuario………………………………………………..….227 Tabla 8.3.39. Tarjeta para la clase PantallaValidación con responsabilidades y colaboraciones identificadas de los casos de uso, ValidarUsuario……………………………………………………228 Tabla 8.3.40. Tarjeta para la clase RegistroUsuario sin responsabilidades ni colaboraciones de registro para el caso de uso RegistrarUsuario…………………………………………………...228 Tabla 8.3.41. Tarjeta para la clase ManejadorMenuServicio con responsabilidades y colaboraciones a partir de los casos de uso ValidarUsuario……………………………………………………………………...229 Tabla 8.3.42. Tarjeta para la clase PantallaMenuServicio con responsabilidades y colaboraciones a partir de los casos de uso ValidarUsuario……………………………………………………229 Tabla 8.3.43. Responsabilidades y colaboraciones para la clase InterfaceUsario……………………………………………………………..230 Tabla 8.3.44. Grupos de responsabilidades y colaboraciones para la clase InterfaceUsario……………………………………………………230 Tabla 8.3.45. Grupos de responsabilidades y colaboraciones para la clase InterfaceUsuario revisados según la creación de dos nuevas superclases: Pantalla y Manejador……………………………233


Práctica UCPR-IST


Tabla 8.3.46. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones y jerarquías identificadas de los casos de uso ValidarUsuario……………………………..234 Tabla 8.3.47. Grupos de responsabilidades y colaboraciones para las diversas pantallas…………………………………………………….…234 Tabla 8.3.48. Tarjeta para la superclase clase Pantalla con responsabilidades, colaboraciones y jerarquías identificadas…………..238 Tabla 8.3.49. Tarjeta para la superclase clase Pantalla con responsabilidades, colaboraciones y jerarquías revisadas…………….240 Tabla 8.3.50. Grupos de responsabilidades y colaboraciones para los diversos manejadores…………………………………………………240 Tabla 8.3.51. Tarjeta para la clase Manejador con responsabilidades, colaboraciones y jerarquías identificadas de los diversos manejadores para los casos de uso……………242 . Tabla 8.3.52. Tarjeta para la clase ManejadorValidación con responsabilidades, colaboraciones y jerarquías identificadas de los caso de uso………………………………………………..244 Tabla 8.3.53. Tarjeta para la clase PantallaValidación

con responsabilidades, colaboraciones y jerarquías identificada

en el caso de uso ValidarUsuario……………………………………………….244

Tabla 8.3.54. Tarjeta para la clase Datos con responsabilidades, colaboraciones y jerarquías identificadas de las diversas clases entidad para los casos de uso…………………………………………………..245 Tabla 8.3.55. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones y jerarquías identificada en el caso de uso ValidarUsuario………………………………………………246 Tabla 8.3.56. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones y jerarquías de actualizar y consultar información de registro para el caso de uso RegistrarUsuario…………………………………246 Tabla 8.3.57. Tarjeta para la clase InterfaceBaseDatosCorrespondencia con responsabilidades, colaboraciones y jerarquías……………………...…..247 Tabla 8.3.58. Tarjeta para la clase PantallaMenuServicio con responsabilidades, colaboraciones y jerarquías, a partir de los casos de uso ofrecer servicios…………………………………………..247


Práctica UCPR-IST


Tabla 8.3.59. Responsabilidades asignadas a la clase InterfaceUsario luego de la etapa de jerarquías……………………………….248 Tabla 8.3.60. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquías y contratos identificadas de los casos de uso……………………………………252 Tabla 8.3.61. Responsabilidades para la superclase clase Pantalla definidas…………………………………………………………………252 Tabla 8.3.62. Tarjeta para la superclase clase Pantalla colaboraciones, jerarquías y contratos identificadas de los casos de uso ………………….…254 Tabla 8.3.63. Responsabilidades para la superclase clase Manejador definidas……………………………………………………………..254 Tabla 8.3.64. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquías y contratos identificadas de los diversos manejadores para los casos de uso……………………………………………256 Tabla 8.3.65 Tarjeta para la clase InterfaceUsuario revisada

con números de contratos para las colaboraciones…………………………..257

Tabla 8.3.66. Tarjeta para la clase ManejadorRegistroUsuario

con responsabilidades, colaboraciones, jerarquías y contratos identificadas de los casos de uso………………………………………………258 Tabla 8.3.67. Tarjeta para la clase PantallaValidación con responsabilidades, colaboraciones, jerarquías y contratos identificadas de los casos de uso…………………………………258 Tabla 8.3.68. Tarjeta para la clase Datos con responsabilidades, colaboraciones y jerarquías identificadas de las diversas clases entidad para los casos de uso…………………………………………………...259 Tabla 8.3.69. Responsabilidades definidas para la clase ManejadoRegistroUsuario……………………………………………….……….259 Tabla 8.3.70. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquías y contrato identificado del caso de uso ValidarUsuario…………………………………..261 Tabla 8.3.71. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones, jerarquías y contratos de actualizar y consultar información de registro para el caso de uso RegistrarUsuario…………………………………………..262


Práctica UCPR-IST


Tabla 8.3.72. Responsabilidades definidas para la clase InterfaceBaseDatosCorrespondencia…………………………………………..262 Tabla 8.3.73. Tarjeta para la clase InterfaceBaseDatosCorrespondencia con responsabilidades, colaboraciones, jerarquías y contratos de escribir y leer información de registro de usuario, para los casos de uso ValidarUsuario…………………………………………………………………….263 Tabla 8.3.74. Tarjeta para la clase ManejadorMenuServicio con responsabilidades, colaboraciones, jerarquías y contratos a partir de los casos de uso RegistrarUsuario…………………………………264 Tabla 8.3.75. Tarjeta para la clase PantallaMenuServicio con responsabilidades, colaboraciones, jerarquías y contratos a partir de los casos de uso RegistrarUsuario…………………………………265 Tabla 8.3.76. Tarjeta para el subsistema InterfaceUsuario…………...............266 Tabla 8.3.77. Tarjeta de subsistema para SubsistemaInterfaceUsuario mostrando sus contratos y servidores a partir de los casos de uso RegistrarUsuario, ValidarUsuario……………………………………………….270 Tabla 8.3.78. Tarjeta de subsistema para SubsistemaValidación mostrando sus contratos y servidores a partir de los casos de uso RegistrarUsuario, ValidarUsuario……………………………………………….271 Tabla 8.3.79. Tarjeta de subsistema para SubsistemaRegistro mostrando sus contratos y servidores a partir de los casos de uso RegistrarUsuario, ValidarUsuario……………………………………………….272 Tabla 8.3.80. Tarjeta de subsistema para SubsistemaMenuServicios mostrando sus contratos y servidores a partir del caso de uso RegistrarUsuario…………………………………………………………………..273 Tabla 8.3.81. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquías, contratos y subsistemas identificados de los casos de uso RegistrarUsuario, ValidarUsuario……………………………….275 Tabla 8.3.82. Tarjeta para la clase ManejadorValidación con responsabilidades, colaboraciones, jerarquías, contratos y subsistemas identificadas de los casos de uso RegistrarUsuario, ValidarUsuario………………………………276


Práctica UCPR-IST


Tabla 8.3.83. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquías, contratos y subsistemas identificadas de los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario……………………………………………………………………..277 Tabla 8.3.84. Tarjeta para la clase ManejadorMenuServicio con responsabilidades, colaboraciones, jerarquías, contratos y subsistemas a partir de los casos de uso RegistrarUsuario………………………………………………….277 Tabla 8.3.85. Responsabilidades públicas para la clase InterfaceUsuario…………………………………………………………...278 Tabla 8.3.86. Responsabilidad “desplegarPantalla” con protocolo para la clase InterfaceUsuario…………………………………..279 Tabla 8.3.87. Responsabilidad “enviarEvento” con protocolo para la clase InterfaceUsuario……………………………………….279 Tabla 8.3.88. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquías, contratos, subsistemas y protocolos identificados de los casos de uso RegistrarUsuario, ValidarUsuario……………………………………………….280 Tabla 8.3.89. Tarjeta para la superclase clase Pantalla con responsabilidades asignadas a contratos y privadas…………………….280 Tabla 8.3.90. Tarjeta para la superclase clase Pantalla con protocolo para la responsabilidad “desplegarPantalla”…………………..281 Tabla 8.3.91. Tarjeta para la superclase clase Pantalla con protocolo para la responsa…………………………………………………281 Tabla 8.3.92. Tarjeta para la superclase clase Pantalla con responsabilidades, colaboraciones, jerarquías, contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario……………………………….281 Tabla 8.3.93. Tarjeta para la clase Manejador………………………………...282 Tabla 8.3.94. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquías, contratos, subsistemas y protocolos identificadas de los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario……………………………….282


Práctica UCPR-IST


Tabla 8.3.95. Tarjeta para la clase ManejadorValidación con responsabilidades, colaboraciones, jerarquías, contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario………………………………………………283 Tabla 8.3.96. Tarjeta para la clase ManejadoRegistroUsuario………………284 Tabla 8.3.97. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquías, contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario y ValidarUsuario………………………………………………285 Tabla 8.3.98. Tarjeta para la clase InterfaceBaseDatosCorrespondencia….285 Tabla 8.3. 99. Tarjeta para la clase InterfaceBaseDatosCorrespondencia con responsabilidades, colaboraciones, jerarquías, contratos y protocolos de escribir y leer información de registro de usuario y registro de tarjeta para los casos de uso RegistrarUsuario, ValidarUsuario.286 Tabla 8.3.100. Tarjeta para la clase ManejadorMenuServicio……………….286 Tabla 8.3.101. Tarjeta para la clase ManejadorMenuServicio con responsabilidades, colaboraciones, jerarquías, contratos, subsistemas y protocolos a partir de los casos de uso RegistrarUsuario…..287 Tabla 8.3.102. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquías, contratos, protocolos y atributos identificados de los casos de uso……………………..288 Tabla 8.3.103. Tarjeta para la superclase Pantalla con responsabilidades, colaboraciones, jerarquías, contratos, protocolos y atributos identificados de los casos de uso……………………..289 Tabla 8.3.104. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquías, contratos, protocolos y atributos identificados de los diversos manejadores para los casos de uso …………………………290 Tabla 8.3.105. Tarjeta para la clase ManejadorValidación con responsabilidades, colaboraciones, jerarquías, contratos, protocolos y atributos identificados de los casos de uso RegistrarUsuario, ValidarUsuario……………………………………………….291 Tabla 8.3.106. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquías, contratos, protocolos y atributos identificados de los casos de uso RegistrarUsuario y ValidarUsuario………………………………………………292


Práctica UCPR-IST


Tabla 8.3.107. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones, jerarquías, contratos, protocolos y atributos para el caso de uso RegistrarUsuario…....292 Tabla 8.3.108. Tarjeta para la clase ManejadorMenuServicio con responsabilidades, colaboraciones, jerarquías, contratos, protocolos y atributos a partir de los casos de uso RegistrarUsuario……….293 Tabla 8.3.109. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y especificación de algoritmos identificados de los casos de uso RegistrarUsuario, ValidarUsuario…………………………………………………………………….295 Tabla 8.3.110. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y especificación de algoritmos identificados de los casos de uso RegistrarUsuario, ValidarUsuario……………………………………………………………………..295 Tabla 8.3.111. Tarjeta para la superclase Pantalla con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y especificación de algoritmos identificados de los casos de uso RegistrarUsuario, ValidarUsuario……………………….296 Tabla 8.3.112. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y especificación de algoritmos identificados de los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario……………………………………………………….…………….296 Tabla 8.3.113. Tarjeta para la clase ManejadorValidación con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y especificación de algoritmos identificados de los casos de uso RegistrarUsuario, ValidarUsuario……………………….297 Tabla 8.3.114. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y especificación de algoritmos identificados de los casos de uso RegistrarUsuario y ValidarUsuario……………………...298 Tabla 8.3.115. Tarjeta para la clase InterfaceBaseDatosCorrespondencia con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y especificación de algoritmos identificados para los casos de uso RegistrarUsuario, ValidarUsuario…………………….299 Tabla 8.3.116. Tarjeta para la clase ManejadorMenuServicio con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y especificación de algoritmos identificados a partir de los casos de uso RegistrarUsuario…………………………………300


Práctica UCPR-IST


Tabla 8.3.117. Contrato enviarEvento para la clase InterfaceUsuario……...302 Tabla 8.3.118. Contrato enviarEvento con protocolo revisado para la clase InterfaceUsuario…………………………………………………..303 Tabla 8.3.119. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y algoritmos identificados……………………..…………303 Tabla 8.3.120. Tarjeta para la superclase clase Pantalla modificada de acuerdo al diseño gráfico. Se eliminó la responsabilidad privada enviarEvento..…..304 Tabla 8.3.121. Diseño de la base de datos para la correspondiente a la clase RegistroUsuario……………………………………306

Tabla 8.3.122. Diseño de la base de datos para la correspondiente a la clase Archivo……………………………………………...306 Tabla 8.3.123. Diseño de la base de datos para la Tabla correspondiente a la clase Correspondencia_Despachada………………….306 Tabla 8.3.124. Diseño de la base de datos para la Tabla correspondiente a la clase Correspondencia_Recibida………………………307 Tabla 8.3.125. Diseño de la base de datos para la Tabla correspondiente a la clase Oficio………………………………………………..307 Tabla 8.3.126. Diseño de la base de datos para la Tabla correspondiente a la clase Sección……………………………………………..307 Tabla 8.3.127. Diseño de la base de datos para la Tabla correspondiente a la clase Ciudad………………………………………………308 Tabla 8.3.128. Tarjeta para la clase InterfaceRegistro con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y algoritmos para los casos de uso, ValidarUsuario….309


Práctica UCPR-IST


Tabla 8.3.129. Tarjeta para la clase InterfaceArchivoRegistro con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y algoritmos …………………………………………………………....310 Tabla 8.3.130. Tarjeta para la clase InterfaceArchivoRegistro con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y algoritmos para los casos de uso RegistrarUsuario, ValidarUsuario………..311


Práctica UCPR-IST


LISTA DE FIGURAS

Pág.

Figura 7.1 Dependencia de los distintos Modelos del proceso de software del Modelo de casos de uso………………………………………...…………………52 Figura 7.2 Los tres ejes de modelado

del modelo de requisitos………………………………………...…………………53

Figura 7.3 El actor y el caso de uso son

las entidades básicas del modelo de casos de uso……………...………..……56

Figura 7.4 Delimitación de un sistema según los actores……………………...57

Figura 7.5 Ejemplo de casos de uso mostrando la relación con los actores..59

Figura 7.6. El diagrama muestra conceptualmente el modelo de análisis junto con la arquitectura general de objetos en relación al modelo de requisitos anteriormente desarrollado…………………………...64

Figura 7.7 Diagrama de tres dimensiones correspondientes

a la arquitectura MVC – Modelo. Vista Control………………………………….65

Figura 7.8 Diagrama de clases con estereotipos………………………………66

Figura 7.9. Diagrama de clases para los tres estereotipos…………………….66

Figura 7.10. Diagrama mostrando los estereotipos de los objetos……………67

Figura 7.11. El diseño añade el ambiente de implementación

como un nuevo eje de desarrollo…………………………………………………68

Figura 7.12. El modelo de diseño es una continuación del

modelo de análisis………………………………………………………………….69

Figura 8.1. 1. Delimitación del Sistema de Correspondencia………………….76

Clases

Nota

Las figuras solo se encuentran en el documento impreso


Práctica UCPR-IST


Figura 8.1. 2. Casos de uso para un sistema de Correspondencia…………..78 Figura 8.1. 3. Caso de Uso principales para el sistema de correspondencia..79 Figura 8.1. 4. Pantalla de validación del sistema (P -1)………………………..82 Figura 8.1. 5. Pantalla de menú de servicios. (P-2)………………………….....85 Figura 8.1. 6. Pantalla de ingreso de Información de la Correspondencia Despachada (P-3)………………………………………………………………..…87 Figura 8.1. 7. Pantalla de ingreso de Información de la Correspondencia Recibida (P-4)……………………………………………….....89 Figura 8.1. 8. Pantalla de Búsqueda de Información de la Correspondencia (P-5)……………………………………………………………..91 Figura 8.1. 9. Pantalla de la correspondencia encontrada (P-6)……………...92 Figura 8.1. 10. Pantalla Informes de la Correspondencia (P-7)……………….94 Figura 8.1. 11. Pantalla Manual de Usuario (P-8)………………………….......96 Figura 8.1. 12. Diagrama de clases con asociaciones entre clases identificadas……………………………………………………………….100 Figura 8.1. 13. Diagrama de clases con asociaciones y roles entre clases identificadas………………………………………………………...102 Figura 8.1. 14 Diagrama de clases con asociaciones………………………...103 Figura 8.1.15. Diagrama de clases con asociaciones, roles, multiplicidad y atributos para clases identificadas………………………………………………105 Figura 8.1. 16. Diagrama de clases para el módulo de Archivo del sistema de Correspondencia…………………………………………………….107 Figura 8.2. 1. Clases borde para el sistema de correspondencia identificada directamente de los actores………………………………………108 Figura 8.2. 2. Clases borde identificadas del caso uso Validar Usuario……109 Figura 8.2. 3. Clases borde identificadas del caso uso Ofrecer Servicios….109


Práctica UCPR-IST


Figura 8.2. 4. Clases borde identificadas del caso uso Correspondencia Despachada……………………………………………………………………….110 Figura 8.2. 5. Clases borde identificadas del caso uso Correspondencia Recibida……………………………………………………….110 Figura 8.2. 6. Clases borde identificadas del caso uso Búsqueda de Correspondencia………………………………………………………………….111 Figura 8.2.7. Clases borde identificadas del caso uso Informes de Correspondencia………………………………………………………………….112 Figura 8.2.7.8 Clases borde identificadas del caso uso Manual de Usuari.....112 Figura 8.2. 9. Clases entidad identificadas del caso uso Validar Usuario.…114 Figura 8.2. 10. Clases entidad identificadas del caso uso Correspondencia Despachada……………………………………………………………………….114 Figura 8.2. 11. Clases entidad identificadas del caso uso Correspondencia Recibida……………………………………………………………………………115 Figura 8.2. 12. Clases entidad identificadas del caso uso Búsqueda de Correspondencia………………………………………………………………….115 Figura 8.2. 13. Clases entidad identificadas del caso uso Informes de Correspondencia………………………………………………………………….116 Figura 8.2. 14. Clases entidad identificadas del caso uso Manual Usuario..116 Figura 8.2. 15. Clase control para el caso uso Validar Usuario………………..….118 Figura 8.2. 16. Clase control para el caso uso Ofrecer Servicios……………118 Figura 8.2. 17. Clase control para el caso uso Correspondencia Despachada………………………………………………….119 Figura 8.2. 18. Clase control para el caso uso Correspondencia Recibida...119 Figura 8.2. 19. Clase control para el caso uso Búsqueda de Información….119 Figura 8.2. 20. Clase control para el caso uso Informes Correspondencia...120 Figura 8.2. 21. Clase control para el caso uso Manual de Usuario………….120 Figura 8.2. 22. Clases identificadas para el caso uso Validar Usuario……..121


Práctica UCPR-IST


Figura 8.2. 23 Clases identificadas para el caso uso Ofrecer Servicios……122 Figura 8.2. 24. Clases identificadas para el caso uso Correspondencia Despachada……………………………………………………………………….122 Figura 8.2. 25. Clases identificadas para el caso uso Correspondencia Recibida……………………………………………………….123 Figura 8.2. 26. Clases identificadas para el caso uso Búsqueda de Correspondencia………………………………………………………………….124 Figura 8.2. 27 Clases identificadas para el caso uso Informes Correspondencia………………………………………………………………….125 Figura 8.2. 28. Clases identificadas para el caso uso Manual de Usuario…126 Figura 8.2. 29. Diagrama de secuencia Validación Usuario del caso de uso Validar Usuario…………………………………………………….127 Figura 8.2. 30. Diagrama de secuencia Guardar Información del caso de uso Correspondencia Despachada…………………………………...130 Figura 8.2. 31. Diagrama de secuencia Modificar Información del caso de uso Correspondencia Despachada…………………………………...133 Figura 8.2. 32. Diagrama de secuencia Eliminar Información del caso de uso Correspondencia Despachada……………………………….136 Figura 8.2. 33. Diagrama de secuencia Guardar Información del caso de uso Correspondencia Recibida……………………………………….139 Figura 8.2. 34. Diagrama de secuencia Modificar Información del caso de uso Correspondencia Recibida………………………………………..142 Figura 8.2. 35. Diagrama de secuencia Eliminar Información del caso de uso Correspondencia Recibida………………………………………..145 Figura 8.2. 36. Diagrama de secuencia Buscar Información del caso de uso Búsqueda de Correspondencia……………………………........148 Figura 8.2. 37. Diagrama de secuencia Buscar Información del caso de uso Búsqueda de Correspondencia………………………………….151 Figura 8.2. 38. Diagrama de secuencia Generar Informes del caso de uso Informes Correspondencia………………………………………..154


Práctica UCPR-IST


Figura 8.2. 39. Diagrama de secuencia Manual del caso de uso Manual de Usuario…………………………………………………156 Figura 8.2. 40. Módulos principales del sistema de correspondencia………168 Figura 8.2. 41. Módulos adicionales del módulo Servicios…………………..170 Figura 8.3.1. El diagrama muestra las colaboraciones descritas hasta el momento para la clase InterfaceUsuario……………………………..232 Figura 8.3.2 El diagrama muestra las colaboraciones descritas hasta el momento para la clase InterfaceUsuario luego de la introducción de las superclases Pantalla y Manejador……………………….234 Figura 8.3.3. El diagrama muestra las colaboraciones descritas a partir de las diversas pantallas y en dirección a la InterfaceUsuario………………………236 Figura 8.3.4 El diagrama muestra las colaboraciones descritas a partir de las diversas pantallas conteniendo la superclase Pantalla y en dirección a la InterfaceUsuario…………………………………..237 Figura 8.3.5 El diagrama muestra la jerarquía de clases para el módulo de registro a partir de la clase Pantalla incluyendo las clases PantallaCorrespondenciaEncontrada………………………………….239 Figura 8.3.6 El diagrama muestra las colaboraciones descritas a partir de los diversos manejadores y en dirección a la InterfaceUsuario y ManejadorMenuServicio…………………………………...241 Figura 8.3.7 El diagrama muestra las colaboraciones descritas a partir de los diversos manejadores conteniendo la superclase Manejador y en dirección a la InterfaceUsuario y ManejadorMenuServicio…………………………………………………………...242 Figura 8.3.8. El diagrama muestra la jerarquía de clases a partir de la clase Manejador……………………………………………………..243 Figura 8.3.9. El diagrama muestra la jerarquía de clases para el módulo de registro a partir de la clase Datos………………………………….245 Figura 8.3.10. El diagrama muestra a las diversas clases manejadores y pantallas solicitando…………………………………………….250 Figura 8.3.11. El diagrama muestra la clase InterfaceUsuario como cliente de las diversas pantallas a través de la responsabilidad “desplegarPantalla” de la clase Pantalla…………………...253 Figura 8.3.13 El diagrama muestra la clase InterfaceUsuario


Práctica UCPR-IST


como cliente de los diversos manejadores a través de la responsabilidad “manejarEvento” de la clase Manejador…………………….255 Figura 8.3.14 El diagrama muestra las clases ManejadorValidación como clientes de las diversas responsabilidades de la clase ManejadoRegistroUsuario………………………………………………………..259 Figura 8.3.15 El diagrama muestra las clases ManejadorValidación y ManejadoMenurServicio como clientes del contrato “Registrar Usuario”, contrato número “2”, de la clase ManejadoRegistroUsuario…………………261 Figura 8.3.16 El diagrama muestra las clases ManejadoRegistroUsuario como clientes de la clase InterfaceBaseDatosCorrespondencia……………262 Figura 8.3.17. El diagrama muestra a las diversas clases de manejadores como clientes de de la clase ManejadorMenuServicio……….264 Figura 8.3 18. Diagrama de subsistema con un contrato asociado con la clase servidor que lo implementa………………………………………..266 Figura 8.3.19. Diagrama de subsistema para el ejemplo del subsistema InterfaceUsuario……………………………………………………267 Figura 8.3.20. Diagrama de colaboración donde Clase Cliente llama al Contrato del Subsistema implementado por la Clase Servidor……267 Figura 8.3.21 Diagrama de subsistema para el ejemplo del subsistema InterfaceUsuario con dos clientes para el contrato “Desplegar Pantalla”, ManejadorValidación y ManejadorMenuServicio……………………………...268 Figura 8.3.22. Subsistemas de alto nivel para el sistema de correspondencia……………………………………………………..268 Figura 8.3.23. Diagrama de subsistemas para el SubsistemaInterfaceUsuario mostrando únicamente a InterfaceUsuario, la clase servidor………………..270 Figura 8.3. 24. Diagrama de subsistemas para el SubsistemaValidación….271 Figura 8.3.25 Diagrama de subsistemas para el SubsistemaRegistro……...272 Figura 8.3. 26 Diagrama de subsistemas para el SubsistemaMenuServicio..273 Figura 8.3.28. Diagrama de secuencias para el caso de uso Validar Usuario……………………………………………………..274 Figura 8.3. 27. Diagrama mostrando la relación esquemática……………….308


Práctica UCPR-IST


Figura 8.3.28. Diagrama de secuencias para el caso de uso Validar Usuario……………………………………………………..312 Figura 8.3.29. Diagrama de secuencias para el caso de uso Correspondencia Despachada, subflujo Guardar, el cual es el mismo proceso para el caso de Uso Correspondencia Recibida……………………………………………………….313 Figura 8.3.30. Diagrama de secuencias para el caso de uso Correspondencia Despachada, subflujo Modificar, el cual es el mismo proceso para el caso de Uso Correspondencia Recibida……….……314 Figura 8.3.31. Diagrama de secuencias para el caso de uso Correspondencia Despachada, subflujo Eliminar, el cual es el mismo proceso para el caso de Uso Correspondencia Recibida…………..315 Figura 8.3.32. Diagrama de secuencias para el caso de uso Busqueda de Correspondencia, subflujo Buscar………………………………316 Figura 8.3.33. Diagrama de secuencias para el caso de uso Informes de Correspondencia, subflujo Generar Informe…………………………………...317 Figura 8.3.34. Diagrama de secuencias para el caso de uso Manual de Usuario………………………………………………………………..318 Figura 8.4.1. Modelo Relacional de la Base de datos Correspondencia………………………………………………………………….319 Figura 8.4.2. Pantalla de validación de Usuario……………………………….326 Figura 8.4.3. Pantalla del Menú principal………………………………………328 Figura 8.4.4. Pantalla de Correspondencia Despachada…………………….330 Figura 8.4.5. Pantalla de la correspondencia Recibida……………………….338 Figura 8.4.6. Pantalla de la Búsqueda de la correspondencia……………….346 Figura 8.4.7. Pantalla de la correspondencia encontrada……………………349


Práctica UCPR-IST


Figura 8.4.8. Pantalla de Informes de Correspondencia……………………..350 Figura 8.4.9. Pantalla del manual de Usuario………………………………….353


Práctica UCPR-IST


LISTA DE ANEXOS

Pág.

Manual de Usuario………………………………………………………………..359

CD Sistema de Correspondencia…………………….…………………………368

Jessica

Nota

Los anexos se encuentran en un cd aparte.


Práctica UCPR-IST


RESUMEN

El proyecto de intervención que se llevo a cabo en la práctica profesional

realizada en la Registraduría Nacional del Estado Civil en la Delegación

Departamental del Risaralda en el área del Centro de Acopio. Se diseño un

software para el control y búsqueda de la correspondencia el cual le permite a

la persona encargada ingresar la los oficios o documentos que son recibidos o

despachados. Por medio del sistema puede realizar búsqueda de la

correspondencia que ya esta archivada para poder ubicar en que caja y legajo

se encuentran archivados los folios.

También permite generar informes de la correspondencia que se ha

despachado o recibido durante un tiempo determinado, ya que para la

organización es importante tener esto datos.

El software se diseño siguiendo los siguientes pasos de la Ingeniería del

Software, Modelo de Requisitos, Modelo Análisis, Modelo Diseño, Modelo

Implementación y pruebas.

Se siguió un Ciclo de vida de Prototipos, en cual permite hacer cambios para

mejorar el software para tener un producto de calidad.

Palabras clave: Modelo de Requisitos, Modelo de Análisis, Modelo de Diseño,

Modelo de Implementación y pruebas.


Práctica UCPR-IST


ABSTRACT

The intervention project was carried out in professional practice conducted in

the National Registry of Civil Status in Risaralda Departmental Delegation in the

area of the collection center. Software was designed to control and search of

correspondence which allows the person in charge to enter the trades or

documents that are received or shipped. Through the system can perform

search and correspondence is filed in order to place that box and bundle the

sheets are on file.

It also can generate reports of the correspondence has been sent or received

during a certain time, because the organization is important to keep this data.

The software was designed by following the steps of Software Engineering,

Requirements Model, Analysis Model, Model Design, Model Implementation

and testing.

It stages following a Prototype, in which allows changes to improve the software

to have a quality product.

Keywords: Requirements Model, Analysis Model, Model of Design,

Implementation and testing model.


Práctica UCPR-IST


TITULO



Práctica UCPR-IST


INTRODUCCIÓN

El proyecto de intervención que se hizo en la práctica profesional de la

Registraduría Nacional del estado civil, Delegación departamental del Risaralda

en el Centro de Acopio. Fue un software para la búsqueda y control de la

correspondencia la cual permite el ingreso, modificación o eliminar todo lo que

tiene que ver con la correspondencia recibida y despachada del centro de

acopio. Ya que esta correspondencia va ser ingresada al sistema en el cual

quedara almacenada en la base de datos para que posteriormente sea

archivada.

La búsqueda de la correspondencia se puede hacer por diferentes campos

como por ejemplo empresas, fechas de radicados, teléfonos, direcciones, etc.

Lo que permite poder encontrar correspondencia en la que se tiene muy poca

información donde fue archivada.

La utilidad de la propuesta del desarrollo del software lo que hace es permitir

llenar una base de datos con la correspondencia despachada y la

correspondencia recibida, permitiendo una búsqueda más rápida, y haciendo

mas eficiente esta tarea dentro de la organización.

Este software fue diseñado en diferentes etapas, que fueron la del modelo de

requisitos, Análisis, Diseño, Implementación y pruebas. Esta parte de la

ingeniería del software está documentada para futuras modificaciones o

correcciones que la organización dese hacer.

La interfaces graficas se realizo en visual estudio 2005 y la bases de datos en

Mysql 5, se realizo un ciclo de vida de prototipos para el diseño del software.


Práctica UCPR-IST


1. PRESENTACIÓN DE LA ORGANIZACIÓN O SITIO DE PRÁCTICA

1.1 HISTORIA

Los orígenes de la Registraduría Nacional como entidad llamada a responder

por la elaboración de la cédula de ciudadanía, puede remontarse al año 1934,

cuando en la Policía Nacional se designó a la Sección Electoral para

encargarse de las funciones relacionadas con la cedulación.

Más tarde, hacia 1935, en atención a que el volumen de trabajo se hacía cada

vez mayor, se dispuso que en el Ministerio de Gobierno funcionara la Oficina

Nacional de Identificación Electoral, con tarjetas dactiloscópicas decadactilares,

negativos fotográficos de los ciudadanos, archivos alfabético, numérico y

dactiloscópico.

Por decreto de 1935, se asignó a la Contraloría General de la República las

estadísticas electorales de cada municipio del país. Se separó la oficina de

Identificación de la Policía Nacional y se fijaron las siguientes bases para la

organización que demandaba el gran volumen de trabajo:

• Aumento del personal

• Fijación de promedios de trabajo para cada empleado.

• Disminución de sueldos por déficit de rendimiento o trabajo mal ejecutado.

• Aumento de sueldos por rendimiento y mayor actividad.

• Control directo del Ministerio de Gobierno, por ser este ente el encargado de

“garantizar la efectividad del derecho del sufragio y la libre expresión de

voluntad popular”. El apoyo prestado por esta oficina se extendió, además, a

los campos civil y criminal. [1]


Práctica UCPR-IST


1.2 Grandes cambios:

Hacia 1948, con la expedición de la Ley 89, se concibe que esta labor deba ser

desempeñada por una entidad autónoma e independiente que pueda

responder de manera directa y sin influencias por la labor de identificación y

organización de las elecciones. Se crea la Organización Electoral, a cargo de:

• Una Corte Electoral con sede en Bogotá, integrada por el más antiguo ex-

presidente de la República, los dos magistrados más antiguos de la Corte

Suprema de Justicia de diferente filiación política, el rector de la Universidad

Nacional y el Gerente del Banco de la República. Se reúne por primera vez la

Corte Electoral en el Palacio Presidencial el 18 de diciembre de 1948.

• Las comisiones escrutadoras y de recuentos de votos en los Departamentos,

Intendencias, Comisarías y Municipios.

• El Registrador Nacional del Estado Civil.

• Los Delegados del Registrador Nacional en los Departamentos.

• Los Registradora Municipales y sus delegados en las mesas de votación. [1]


Práctica UCPR-IST


1.3 La creación de la Organización Electoral obedeció a dos objetivos

principales

1. Evitar la influencia de los partidos políticos en la obtención de la cédula de

ciudadanía, en la formación de los censos electorales, en las votaciones y en

los escrutinios.

2. Garantizar la plena responsabilidad y la imparcialidad política de los

funcionarios adscritos a ella.

Esta ley autoriza al Gobierno para contratar una misión técnica extranjera que

estudie y recomiende los sistemas que deban emplearse en la identificación y

cedulación y en la formación de los censos electorales, así como la

organización de la Oficina Nacional de Identificación Electoral.

En virtud de esta disposición se contrató con la Misión Técnica Canadiense en

la cual en 1949, presentó al Ministerio de Gobierno un informe detallado de la

situación encontrada, sus deficiencias e irregularidades, referidas básicamente

a:

1. Falta de confrontación dactiloscópica antes de la expedición de la cédula de

ciudadanía. Este era el error básico.

2. Archivos de tarjetas dactiloscópicas en quince Departamentos separados,

haciendo así extremadamente difíciles las verificaciones.

3. Imposibilidad de hacer una confrontación adecuada debido al número de

tarjetas dactilares defectuosas, la mayoría de las cuales estaban en ese

momento sin clasificar y muchas otras eran inclasificables.

4. Falta total de medidas severas para asegurar la devolución de la cédula de

ciudadanía y de un modo especial, en el caso de personas que habían muerto.

5. La facilidad con que las personas podrían obtener una segunda cédula

aduciendo solamente la pérdida anterior.

7. Insuficientes medidas de seguridad para impedir que los menores obtuvieran

la cédula de ciudadanía.

7. Mala calidad de la cédula en cuanto a su presentación y método deficiente

de compilación. La fotografía podía ser cambiada fácilmente.

Se presentaban, además, otras deficiencias como:


Práctica UCPR-IST


• Insuficientes medidas para cancelar en los censos las inscripciones

correspondientes a ciudadanos fallecidos.

• Deficientes medios de prueba para acreditar la vecindad.

• Inconvenientes de orden práctico con motivo de la expedición de cédulas a

homónimos.

• Falta de concordancia de los nombres y apellidos con que aparecía en

ciudadano en la cédula y los que figuraban en la partida de bautismo.

La Misión Técnica Canadiense propuso las siguientes recomendaciones

técnicas para superar tales deficiencias:

1. Centralización en Bogotá de los archivos dactiloscópico, alfabético,

numérico, fotográfico y estadístico.

2. Adopción del sistema de clasificación dactiloscópica Henry.

3. Adopción del sistema fotográfico Monroe Duo.

4. Organización de la oficina principal de identificación, comisiones locales

permanentes y móviles.

5. Establecimiento de cupos numéricos para cada departamento.

7. Adopción de la cédula de ciudadanía laminada con la firma del Registrador

Nacional.

7. Conformación de censos electorales.

Así mismo, la Misión Técnica Canadiense hace minuciosas recomendaciones

en cuanto a los procedimientos, el personal necesario, el espacio requerido,

equipos y suministros, recomendaciones adoptadas a partir de 1951. Se inició

también el adiestramiento de un grupo de funcionarios en el sistema Henry, del

cual se escogieron los mejores para dirigir otros cursos hasta completar el

personal necesario y extender la cedulación a todo el país.

En 1952 se expide la primera cédula laminada al doctor Laureano Gómez

Castro, Presidente de la República.

En 1957 se expide la primera cédula femenina a doña Carola Correa de Rojas.

En 1970, mediante el decreto 1270, se faculta a la Registraduría para expedir

la tarjeta de identidad a los colombianos mayores de 7 y menores de 21 años.

La ley 97 de 1985 y el Decreto 2241 de 1987 o Código Electoral, reemplazan la

Corte Electoral por el Consejo Nacional Electoral y dictan nuevas disposiciones


Práctica UCPR-IST


en materias administrativas, de identificación y electoral. Esta misma Ley 97

crea el Fondo Rotatorio de la Registraduría.

Para esta época, el Consejo de Estado nombra a los consejeros del Censo

Nacional Electoral -período de 4 años- y éste último nombre al Registrador

Nacional –período de 5 años-.

En 1985, la Registraduría Nacional traslada su sede de las oficinas Centrales

del centro de Bogotá al centro Administrativo Nacional, CAN.

A partir de 1987 la Registraduría asume gradualmente el Registro Civil.

En 1991, el Título IX de la Nueva Constitución define a la Organización

Electoral como un organismo autónomo e independiente.

En 1997 se inicia el proceso de modernización tecnológica y administrativa,

para la cual se contrata a la firma SAGEM Colombia. [1]

1.4 Estado actual

Con base en facultades extraordinarias dadas por el Congreso al Presidente de

la República, se expide la ley que autoriza la reestructuración de la Entidad. En

desarrollo de esta Ley, el 7 de junio del año 200 se dictan los Decretos 1010,

1011, 1012, 1013 y 1014 por medio de los cuales se determina la nueva

situación de la Entidad en materia de estructura interna, planta de personal,

nomenclatura y clasificación de los empleos, sistema de remuneración, carrera

administrativa, funciones y requisitos de los cargos.

De acuerdo a la nueva organización interna, la estructura de la planta de

personal se divide en dos niveles: central y desconcentrado.

De conformidad con el Acto Legislativo No. 1 del 3 julio de 2003, el Consejo

Nacional Electoral es elegido por el Congreso de la República en pleno para un

periodo institucional de 4 años.

El Registrador Nacional del Estado Civil será escogido por los presidentes de:

la Corte Constitucional, la Corte Suprema de Justicia y el Consejo de Estado,

mediante concurso de méritos según la Ley, por un periodo de 4 años. [1]


Práctica UCPR-IST


1.5 MISION

“Es misión de la Registraduría Nacional del Estado Civil, garantizar la

organización y transparencia del proceso electoral, la oportunidad y

confiabilidad de los escrutinios y resultados electorales, contribuir al

fortalecimiento de la democracia mediante su neutralidad y objetividad,

promover la participación social en la cual se requiere la expresión de la

voluntad popular mediante sistemas de tipo electoral en cualquiera de sus

modalidades, así como promover y garantizar en cada evento legal en que

deba registrarse la situación civil de las personas, que se registren tales

eventos, se disponga de su información a quien deba legalmente solicitarla, se

certifique mediante los instrumentos idóneos establecidos por las disposiciones

legales y se garantice su confiabilidad y seguridad plenas”. [1]

1.6 VISION

La Registraduría Nacional del Estado Civil será una Institución reconocida por la ciudadanía colombiana, por su excelencia en la prestación de los servicios a su cargo, garantizando la facilidad de acceso a toda la población, mediante la utilización de tecnologías modernas y el compromiso de sus funcionarios en la consolidación de un sistema de registro civil e identificación ágil, confiable y transparente, en la expedición de los documentos de identidad y la oportunidad, transparencia y eficiencia en la realización de los procesos electorales. [1]

1.7 PRINCIPIOS CORPORATIVOS

Imparcialidad Secreto al Voto y publicidad del Escrutinio Eficacia del voto Capacidad Electoral Proporcionalidad Habeas data Debido proceso Responsabilidad Ética Transparencia


Práctica UCPR-IST


1.8 VALORES (Compromiso Ético – Organización Electoral Registraduría Nacional del Estado Civil)

Compromiso Honestidad Lealtad Tolerancia Respeto Responsabilidad Comunicación Autoestima Generosidad Prudencia

1.9 NÚMERO DE TRABAJADORES

Risaralda 58 empleados, Delegación departamental de Risaralda 12

empleados


Práctica UCPR-IST


1.10 ORGANIGRAMA

CENTRO DE ACOPIO RISARALDA Práctica Profesional Ucpr. Álvaro Hernán Cárdenas Valencia


Práctica UCPR-IST


1.11 FUNCIONES DE LA REGISTRADURÍA NACIONAL DEL ESTADO CIVIL

1. Proponer las iniciativas sobre proyectos de ley y presentarlos a consideración del Consejo Nacional Electoral por conducto del Registrador Nacional, así como los decretos y demás normas relacionadas con la función de registro civil.

2. Adoptar las políticas del Registro Civil en Colombia y atender lo relacionado con la adopción, ejecución y control de los planes y programas propios del registro civil con miras a garantizar su óptimo funcionamiento.

3. Garantizar en el país y el exterior, la inscripción confiable y efectiva de los hechos, actos y providencias sujetos a registro, proferir las autorizaciones a los entes o autoridades habilitadas legalmente para que concurran en el cumplimiento de dicha función, y conocer mediante los actos administrativos pertinentes de todo lo relativo a cancelaciones, reconstrucciones, anulaciones, modelos de expedición y demás actos jurídicos sobre el registro civil.

4. Expedir las copias de registro civil de las personas que sean solicitadas de conformidad con las leyes vigentes.

5. Atender el manejo, clasificación, archivo y recuperación de la información relacionada con el registro civil.

7. Difundir las normas y procedimientos a seguir dentro del proceso de registro civil y adelantar campañas y programas de capacitación en la materia.

7. Coordinar y armonizar con los demás organismos y entes del Estado las políticas, desarrollo y consulta en materia de registro civil.

8. Adelantar inspección y vigilancia de los servicios de registro del estado civil de las personas. 9. Realizar o promover estudios, investigaciones y compilaciones en materia de registro del estado civil de las personas y divulgar los resultados.

10. Proteger el ejercicio del derecho al sufragio y otorgar plenas garantías a


Práctica UCPR-IST


los ciudadanos, actuando con imparcialidad, de tal manera que ningún partido o grupo político pueda derivar ventaja sobre los demás.

11. Dirigir y organizar el proceso electoral y demás mecanismos de participación ciudadana y elaborar los respectivos calendarios electorales.

12. Llevar el Censo Nacional Electoral.

13. Asesorar y prestar el apoyo pertinente en los procesos de elecciones de diversa índole en que las disposiciones legales así lo determinen.

14. Llevar las estadísticas de naturaleza electoral relacionadas con los resultados obtenidos en los debates electorales y procesos de participación ciudadana.

15. Coordinar con los organismos y autoridades competentes del Estado las acciones orientadas al desarrollo óptimo de los eventos electorales y de participación ciudadana. 17. Proceder a la cancelación de las cédulas por causales establecidas en el Código Electoral y demás disposiciones sobre la materia y poner en conocimiento de las autoridades competentes los hechos, cuando se trate de irregularidades. 17. Asignar el Número Único de Identificación Nacional, NUIP, al momento de hacer la inscripción de nacimiento en el Registro del Estado Civil de las personas y ejercer los controles físico, lógico y técnico, para que dicho número sea exclusivo a cada ciudadano y exista un único documento de identificación.

18. Responder las solicitudes de personas naturales o jurídicas y organismos de seguridad del Estado o de la rama judicial en cuanto a identificación, identificación de necrodactilias y demás requerimientos, de acuerdo a la normatividad vigente, teniendo como soporte la información contenida en las bases de datos de registro civil y el sistema de identificación.

19. Expedir y elaborar las cédulas de ciudadanía de los colombianos, en óptimas condiciones de seguridad, presentación y calidad y adoptar un sistema único de identificación a las solicitudes de primera vez, duplicados y rectificaciones. 20. Atender todo lo relativo al manejo de la información, las bases de datos, el Archivo Nacional de Identificación y los documentos necesarios par el proceso


Práctica UCPR-IST


técnico de la identificación de los ciudadanos, así como informar y expedir las certificaciones de los trámites a los que hubiera lugar.

21. Celebrar los convenios que se requieran para que otras actividades públicas o privadas adelanten el registro civil de las personas.

22. Llevar las estadísticas sobre producción de documentos de identificación y el estado civil de las personas y su proyección.

23. Innovar en investigación y adopción de nuevas tecnologías, normas de calidad y controles que mejoren la producción de documentos de identificación y del manejo del registro civil.

24. Atender las solicitudes de expedición de la cédula de ciudadanía en los consulados de Colombia en el exterior para que quienes estén habilitados puedan ejercer sus derechos políticos como ciudadanos colombianos y brindar información acerca de su trámite. 25. Efectuar el recaudo del valor de los duplicados y rectificaciones de la cédula de ciudadanía, copias y certificaciones del registro civil y de los libros y publicaciones que edite la Registraduría, y las tarifas de los demás servicios que ésta preste. 27. Las demás que le asigne la Constitución Política y las disposiciones legales vigentes. [1]


Práctica UCPR-IST


1.12 FUNCIONES DEL SEÑOR REGISTRADOR NACIONAL DEL ESTADO CIVIL

1. Constitución Política artículo 277: "...ejercerá las funciones que establezca la ley, incluida la dirección y organización de las elecciones, el registro civil y la identificación de las personas, así como la de celebrar contratos en nombre de la Nación, en los casos que aquella disponga.”

2. Dirigir el funcionamiento de todas las dependencias de la Registraduría Nacional del estado Civil. (Numeral 1º Art. 27 Decreto 2241/87).

3. Ejercer la representación legal del Fondo Rotatorio de la Registraduría Nacional. (Art.59 decreto 2241/87).

4. Llevar la representación legal, dentro del marco de sus competencias que le correspondan al interior de la organización electoral, de todos los asuntos que en el ejercicio de sus funciones se presenten a favor o en contra de la Entidad. 5. Fijar las políticas, planes, programas y estrategias para el desarrollo de la organización y vigilancia electoral, la identificación de las personas y el registro civil y de las demás funciones asignadas a la Registraduría Nacional del Estado Civil de conformidad con la Constitución y la ley.

7. Realizar todas y cada una de sus acciones atendiendo los conceptos de autocontrol y autoevaluación Art. 5º, literal e, Decreto 2145/99.

7. Establecer y utilizar adecuados instrumentos de gestión que garanticen la correcta aplicación y utilización de las políticas y normas constitucionales y legales en materia de control interno. Así mismo, remitirán al Consejo Asesor del Gobierno Nacional en materia de Control Interno de las entidades del orden nacional y territorial, antes del 17 de febrero, copia del Informe Ejecutivo Anual que contenga el resultado final de la evaluación del Sistema de Control Interno, documento que servirá de base para el informe que sobre el avance del Control interno del Estado presentará al inicio de cada legislatura el Presidente de la República al Congreso de la República. Numeral c, Artículo 5º Decreto 2145/99, modificado por el Articulo 2º del Decreto 2539 del 4 del 2000.

8. Convocar el Consejo Nacional Electoral. (Numeral 3º Art.27 Decreto 2241/87) 9. Organizar y vigilar el proceso electoral. (Numeral 2º Art.27 Decreto


Práctica UCPR-IST


2241/87) 10. Elaborar y publicar las listas sobre el número de concejales que correspondan a cada municipio, de acuerdo con la ley. (Numeral 19º Art.27 Decreto 2241/87) 11. Actuar como Secretario del Consejo Nacional Electoral y como clavero del arca triclave de la misma corporación. (Numeral 7º Art.27 Decreto 2241/87) 12. Dictar y hacer conocer las resoluciones que fijen los términos para la entrega de los pliegos electorales de los corregimientos e inspecciones de policía al respectivo Registrador del Estado Civil. (Numeral 12º Art.27 Decreto 2241/87) 13. Organizar la difusión de los resultados electorales a medida que se vayan conociendo los escrutinios practicados por las comisiones escrutadoras Distritales, municipales y zonales y por los Delegados del Consejo Nacional Electoral. (Numeral 21º Art.27 Decreto 2241/87, modificado por el artículo 1º Ley 7a/90)

14. Fijar, con aprobación del Consejo Nacional Electoral, los viáticos para las comisiones escrutadoras Distritales, municipales y auxiliares, los jurados de votación cuando presten el servicio fuera del lugar donde residen y los empleados de la Registraduría del Estado Civil (Numeral 17º Art.27 Decreto 2241/87)

15. Señalar y supervisar el trámite para la expedición de las cédulas de ciudadanía y tarjetas de identidad. (Numeral 4º Art.27 Decreto 2241/87)

17. Dictar las medidas relativas a la preparación, tramitación, expedición de duplicados, rectificación, altas, bajas y cancelaciones de cédulas y tarjetas de identificación. (Numeral 11º Art.27 Decreto 2241/87).

17. Fijar el precio de las fotografías que impriman y revelen los empleados de la Registraduría Nacional, para la cédula de ciudadanía y tarjeta de identidad. (Numeral 14º Art.27 Decreto 2241/87).

18. Adoptar las políticas y procedimientos para el manejo del Registro del Estado Civil en Colombia, asegurando la inscripción confiable y efectiva de los hechos, actos y providencias sujetos a registro con miras a garantizar su óptimo funcionamiento. 19. Fijar las políticas, planes, programas y estrategias necesarias para el


Práctica UCPR-IST


adecuado manejo administrativo y financiero de la Registraduría Nacional, en desarrollo de la autonomía administrativa y presupuestal dentro de los límites establecidos por la Constitución y la ley.

20. Suscribir los contratos administrativos que deba celebrar la Registraduría Nacional. (Numeral 18º Art.27 Decreto 2241/87)

21. Fijar las políticas, planes y programas para el desarrollo, ejecución y control del sistema presupuestal de la Registraduría Nacional del Estado Civil.

22. Elaborar el presupuesto de la Registraduría. (Numeral 15º Art.27 Decreto 2241/87) 23. Autorizar el pago de viáticos y gastos de transporte y reconocer y ordenar el pago de los demás gastos, a nivel nacional, que afecten el presupuesto de la Registraduría Nacional del Estado Civil. (Numeral 17º Art.27 Decreto 2241/87)

24. Crear, fusionar, suprimir cargos y señalar las asignaciones correspondientes, con aprobación del Consejo Nacional Electoral. (Numeral 7º Art.27 Decreto 2241/87)

25. Nombrar al Secretario General, quien será de distinta filiación política a la suya, así como a los Visitadores Nacionales, Delegados del Registrador Nacional del Estado Civil y Registradores Distritales de Bogotá, con aprobación del Consejo Nacional Electoral, y a los demás empleados de las oficinas centrales. Tanto el Secretario General, como los Visitadores Nacionales deberán reunir las calidades de Magistrado del Tribunal Superior, o haber desempeñado uno de estos cargos por un período de dos años. (Numeral 8º Art.27 Decreto 2241/87).

27. Aprobar los nombramientos de Registradores de las capitales de departamentos y de aquellas ciudades que tengan más de cien mil (100.000) cédulas vigentes. (Numeral 9º Art.27 Decreto 2241/87)

27. Disponer el movimiento del personal de las oficinas centrales de la Registraduría.(Numeral 10º Art.27 Decreto 2241/87)

28. Determinar las funciones y requisitos de los empleos de la Entidad.


Práctica UCPR-IST


29. Delegar en los servidores públicos de los niveles Directivo y Asesor de la Registraduría Nacional del Estado Civil las funciones de acuerdo al artículo 22, cap. IV del Decreto 1010.

30. Ejercer, dentro de su competencia, el control, la supervisión y la orientación del régimen específico de carrera administrativa de la Registraduría Nacional del Estado Civil. 31. Ordenar investigaciones y visitas para asegurar el correcto funcionamiento de la organización electoral. (Numeral 5º Art.27 Decreto 2241/87)

32. Resolver el recurso de apelación que se interponga contra las sanciones impuestas por los Delegados del Registrador Nacional del Estado Civil y por los Registradores Distritales de Bogotá (Numeral 13 º Art.27 Decreto 2241/87)

33. Actuar como segunda instancia en los procesos disciplinarios que se adelanten contra sus servidores, de acuerdo a lo estipulado en el artículo 48 de la Ley 200 de 1995. 34. Resolver los desacuerdos que se susciten entre los Delegados del Registrador Nacional del Estado Civil y entre los Registradores Distritales de Bogotá. (Numeral 20º Art.27 Decreto 2241/87).

35. Las demás funciones que le confiere la Constitución, la Ley y el Consejo Nacional Electoral. (En concordancia con lo establecido en el numeral 22, art. 27 del Decreto 2241/87). [1]


Práctica UCPR-IST


2. DEFINICIÓN DE LAS LÍNEAS DE INTERVENCIÓN

La línea de intervención en la que se desarrollo el software para el manejo de

la Correspondencia del centro de acopio. Fue la de Software en la que se hizo

toda la parte de ingeniería de Software como el modelo de requisitos, Análisis,

Diseño, Implementación y pruebas.

3. DIAGNÓSTICO DEL ÁREA DE INTERVENCIÓN

El área donde se realizo la práctica profesional fue en el centro de acopio de la

delegación departamental de Risaralda, de la Registraduría Nacional del

Estado Civil.

Este diagnostico se hizo por medio de una entrevista realizada con la Ingeniera

Sandra Milena Ramírez, se determino el software que se desarrollo para el

centro de acopio.

Las pautas para el desarrollar del software las dio la ingeniera el cual planteo

las siguientes necesidades para el software, que se presentan a continuación:

Organización de la correspondencia

Información a digitar

Correspondencia despacha

Numero de Oficio

Fecha oficio

Destinatario (nombre representante)

Entidad o persona

Objeto o referencia

Sección o persona que envía: subseccion- serie, subserie,

Numero de folio

Numero legajo

Numero caja


Práctica UCPR-IST


Correspondencia recibida

Numero de oficio

Fecha de oficio

Fecha recibido y radicado

Remitente: nombre quien firmo oficio, entidad que remite,

Subseccion, serie – subserie.

Objeto o referencia

Dirección remitente

Teléfono remitente.

Nota: es necesario que al querer buscar un oficio ya sea enviado o recibido,

pueda buscarse con alguno de los datos básicos y haya un despliegue de

operaciones a fin de seleccionar en buscado: con fecha o entidad o remitente o

el objeto.

4. EJE DE INTERVENCIÓN

El eje de intervención donde se llevo a cabo la práctica profesional fue en el

área del Centro de Acopio el cual se desarrollo un software para el manejo de

la correspondencia.

5. JUSTIFICACIÓN DEL EJE DE INTERVENCIÓN

El manejo de la correspondencia en las organizaciones es de suma

importancia ya que hoy en día esta debe ir archivada. Para mejorar este

proceso de archivar y buscar la correspondencia que se necesite fue necesario

desarrollar un software que permita tener un control y una mejor búsqueda de

la misma.


Práctica UCPR-IST


Antes la correspondencia del centro de acopio era recibida o despachada y

final mente archivada. Ahora con este software que permite la búsqueda de los

documentos que son archivados lo que facilita a la persona encargada

encontrar los oficios que sean necesarios o que se requieran al instante. La

búsqueda se puede realizar ya sea por medio de los nombres, empresas,

fechas de radicados, teléfonos, direcciones, etc. Lo que permite encontrar la

correspondencia con la poca información que se tenga.

La utilidad del desarrollo de este software lo que hace es permitir llenar una

base de datos con la correspondencia despachada y la correspondencia

recibida, permitiendo una búsqueda más rápida, y haciendo más eficiente esta

tarea dentro de la organización.

El porqué se desarrollo este proyecto fue por la necesidad de tener un control y

una mejor búsqueda de la correspondencia ya que para el centro de acopio es

de mucha importancia el manejo de estos documentos.

Para que con este software se agilizaran las tareas de búsqueda de la

correspondencia ya que son documentos oficiales.


Práctica UCPR-IST


6. OBJETIVOS DEL PROYECTO

6.1 Objetivo General:

Diseñar un software que por medio de una base de datos permita llevar el control y búsqueda de la correspondencia del Centro de Acopio de la Delegación departamental del Risaralda de la Registraduría Nacional del Estado Civil.

6.2 Objetivos Específicos:

Realizar el documento del desarrollo del software (Ingeniería del Software).

Diseñar la interface grafica que tanga un ambiente amigable para el usuario.

Diseñar la base de datos para el almacenamiento de la información del archivo de la correspondencia.

Realizar un prototipo del software.

Hacer pruebas y cambios al prototipo del software.


Práctica UCPR-IST


7. REFERENTE CONCEPTUAL

7.1 Modelo de Requisitos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la

funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo

puede funcionar como un contrato entre el desarrollador y el cliente o usuario

del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción

del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender

este modelo.

El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base

para la formación de todos los demás modelos en el desarrollo de software. En

general, el cualquier cambio en la funcionalidad del sistema es más fácil de

hacer, y con menores consecuencias, a este nivel que posteriormente. El

modelo de requisitos que desarrollaremos se basa en la metodología Objectory

(Jacobson et al. 1992), basada principalmente en el modelo de casos de uso.

Actualmente esta metodología es parte del Proceso Unificado de Rational

(RUP). El modelo de casos de uso y el propio modelo de requisitos son la base

para los demás modelos, como se describió anteriormente en el Capítulo 3 y se

resume aquí:

Requisitos: El modelo de casos de uso sirve para expresar el modelo de

requisitos, el cual se desarrolla en cooperación con otros modelos como se

verá más adelante. [1]

Análisis: La funcionalidad especificada por el modelo de casos de uso se

estructura en el modelo de análisis, que es estable con respecto a cambios,

siendo un modelo lógico independiente del ambiente de implementación. [2]


Práctica UCPR-IST


Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es

realizada por el modelo de diseño, adaptándose al ambiente de

implementación real y refinándose aún más. [3]

Implementación: Los casos de uso son implementados mediante el código

fuente en el modelo de implementación. [4]

Pruebas: Los casos de uso son probados a través de las pruebas de

componentes y pruebas de integración.

Documentación: El modelo de casos de uso debe ser documentado a lo largo

de las diversas actividades, dando lugar a distintos documentos como los

manuales de usuario, manuales de administración, etc.

El diagrama de la Figura 7.1 ilustra los distintos modelos. Describiremos los

detalles y la notación más adelante.

Figura 7.1 Dependencia de los distintos modelos del proceso de software del

modelo de casos de uso

El propósito del modelo de requisitos es comprender completamente el

problema y sus implicaciones. Todos los modelos no solamente se verifican

contra el modelo de requisitos, sino que también se desarrollan directamente

de él. El modelo de requisitos sirve también como base para el desarrollo de

las instrucciones operacionales y los manuales ya que todo lo que el sistema


Práctica UCPR-IST


deba hacer se describe aquí desde la perspectiva del usuario. El modelo de

requisitos no es un proceso mecánico, el analista debe interactuar

constantemente con el cliente para completar la información faltante, y así

clarificar ambigüedades e inconsistencias. El analista debe separar entre los

requisitos verdaderos y las decisiones relacionadas con el diseño e

implementación. Se debe indicar cuales aspectos son obligatorios y cuales son

opcionales para evitar restringir la flexibilidad de la implementación. Durante el

diseño se debe extender el modelo de requisitos con especificaciones de

rendimiento y protocolos de interacción con sistemas externos, al igual que

provisiones sobre modularidad y futuras extensiones. En ciertas ocasiones ya

se puede incluir aspectos de diseño, como el uso de lenguajes de

programación particulares.

En la metodología de Objetos, el modelo de requisitos consiste de tres modelos

principales, visualmente representado por un diagrama de tres dimensiones

como se muestra en la Figura 7.2.

Figura 7.2 Los tres ejes de modelado del modelo de requisitos

El modelo de comportamiento, basado directamente en el modelo de casos de

uso, especifica la funcionalidad que ofrece el sistema desde el punto de vista

del usuario. Este modelo utiliza dos conceptos claves: actores para representar

los distintos papeles que los usuarios pueden jugar con el sistema, y casos de

uso para representar qué pueden hacer los actores con respecto al sistema.


Práctica UCPR-IST


El modelo de presentación o modelo de interfaces o borde especifica cómo

interactúa el sistema con actores externos al ejecutar los casos de uso, en

particular, en los sistemas de información ricos en interacción con el usuario,

especifica cómo se verán visualmente las interfaces gráficas y que

funcionalidad ofrecerá cada una de ellas.

El modelo de información o modelo del dominio del problema especifica los

aspectos estructurales del sistema. Este modelo conceptualiza el sistema

según los objetos que representan las entidades básicas de la aplicación.

Aunque en muchas metodologías se permite especificar la funcionalidad

completa del sistema utilizando el modelo del dominio del problema, incluyendo

operaciones formales sobre los objetos correspondientes a un modelo de

requisitos expresado sin casos de uso, el modelo del dominio del problema

será de mucha más ayuda como apoyo al modelo de casos de uso y no como

una entidad totalmente independiente.

Es importante resaltar que esta separación en tres ejes de modelado

independientes es la base para una mayor estabilidad en el desarrollo del

sistema, permitiendo minimizar los efectos de cada uno sobre los otros dos.

Para ilustrar el modelo de requisitos y el desarrollo de los modelos posteriores,

utilizaremos el ejemplo del “Sistema de Reservaciones de Vuelo” como se

mencionó anteriormente. Para tal meta, mostraremos inicialmente una

descripción del problema. A partir de esta descripción inicial se describirán los

tres modelos básicos del modelo de requisitos.


Práctica UCPR-IST


7.2 Descripción del Problema

La descripción del problema es una descripción muy preliminar de necesidades

que sirve únicamente como punto de inicio para comprender los requisitos del

sistema. Se trata aquí de simular una descripción preparada por un cliente la

cual debe evolucionar por medio del modelo de requisitos para lograr la

especificación final del sistema a desarrollarse. La descripción del problema

debe ser una descripción de necesidades y no una propuesta para una

solución. La descripción inicial puede ser incompleta e informal. No hay razón

para esperar que la descripción inicial del problema, preparada sin un análisis

completo, sea correcta.

Modelo de Casos de Uso

El modelo de casos de uso describe un sistema en término de sus distintas

formas de utilización, cada uno de estas formas es conocida como un caso de

uso. Cada caso de uso o flujo se compone de una secuencia de eventos

iniciada por el usuario. Dado que los casos de uso describen el sistema a

desarrollarse, cambios en los requisitos significarán cambios en los casos de

uso. Por ejemplo, un caso de uso para manejar un automóvil sería la secuencia

de eventos desde que el conductor entra en el coche encendiendo el motor

hasta llegar a su destino final. Por lo tanto, para comprender los casos de uso

de un sistema primero es necesario saber quiénes son sus usuarios. Por

ejemplo, conducir un automóvil es distinto a arreglarlo, donde los usuarios

también son distintos, el dueño del automóvil y el mecánico, respectivamente.

Para ello se define el concepto de actor, correspondiente al tipo de usuario que

está involucrado en la utilización de un sistema, siendo el actor una entidad

externa al propio sistema. Juntos, el actor y el caso de uso representan los dos

elementos básicos de este modelo lo cual se muestran de manera gráfica en la

Figura 7.3 de acuerdo a la notación UML.


Práctica UCPR-IST


Figura 7.3 El actor y el caso de uso son las entidades básicas del modelo de

casos de uso.

Los casos de uso son una idea simple y práctica que no requieren muchas

habilidades tecnológicas para ser utilizadas (a diferencia de las demás

actividades del desarrollo). Por el contrario, si se volvieran muy complejas se

perdería un poco la importancia de los casos de uso. Dado que el modelo de

requisitos es la primera actividad del desarrollo del sistema, nos podemos dar

el lujo de muchos cambios en su especificación sin afectar al resto del sistema.

Más aún, considerando que siempre habrá cambios, no debe hacerse

demasiado trabajo muy temprano, ya que solo sería descartado. Cuando se

identifican y describe los casos de uso, habrá ciertas imprecisiones que se irán

resolviendo más adelante. Para ello, un enfoque incremental es lo indicado. De

esta manera se puede desarrollar de forma independiente los distintos casos

de uso y luego integrarlos para formar el modelo de requisitos completo.

Esta habilidad para tomar parte de la funcionalidad permite un desarrollo más

flexible e incluso concurrente.

Actores

Los actores son entidades distintas a los usuarios, en el sentido que los

usuarios son las personas reales que utilizan el sistema, mientras que los

actores representan un cierto papel que una persona real puede jugar.

Utilizando terminología orientada a objetos, se considera al actor como una

clase de usuario, mientras que los usuarios se consideran como objetos o

instancias de esa clase. Incluso, una misma persona puede aparecer como

diferentes instancias de diferentes actores.

Los actores modelan cualquier entidad externa que necesite intercambiar

información con el sistema. Los actores no están restringidos a ser personas

físicas, pudiendo representar otros sistemas externos al actual. Lo esencial es

que los actores representen entidades externas al sistema. Además, cada uno

de estos actores podrá ejecutar una o más tareas del sistema.


Práctica UCPR-IST


Para especificar los actores de un sistema, se dibuja un diagrama

correspondiente a la delimitación del sistema, la cual representa al sistema

como una “caja negra” y a los diferentes actores como entidades externas a

ésta, como se muestra en la Figura 7.4.

Figura 7.4 Delimitación de un sistema según los actores

En general, no se describen los actores con demasiado detalle por ser estos

externos al sistema además de que sus acciones no son deterministas, en

otras palabras, un actor a diferencia del propio sistema, en cada momento

puede decidir entre múltiples opciones. Por otro lado, el sistema y los casos de

uso correspondientes deben ser deterministas, de lo contrario el sistema hará

lo que le plazca, lo cual no es aceptable. Sin embargo, para poder identificar

los casos de uso, es necesario primero identificar los actores del sistema,

comenzando por aquellos que son la razón principal del sistema, conocidos

como actores primarios. Estos actores típicamente rigen la secuencia lógica de

ejecución del sistema. Además de los actores primarios existen actores

supervisando y manteniendo el sistema. Estos actores secundarios existen

primordialmente como complemento a los actores primarios, siendo esta

distinción importante para dedicarle el esfuerzo principal a las necesidades de

los actores primarios. Al contrario de los actores primarios que típicamente

corresponden a personas físicas, los actores secundarios corresponden por lo

general a máquinas o sistemas externos, siendo estos últimos más difíciles de

identificar. Los actores secundarios tienden a responder a secuencias lógicas

del sistema y no tanto a inicializarlas de manera propia. En particular, existe

siempre la duda, por ejemplo, de si el sistema operativo o una base de datos

serían actores. La decisión depende del papel que jueguen con respecto al

sistema en desarrollo, si juegan un papel activo entonces deben modelarse

como actores.


Práctica UCPR-IST


Casos de Uso

Después de haber definido los actores del sistema, se define la funcionalidad

propia del sistema por medio de los casos de uso. Utilizando terminología

orientada a objetos, cada caso de uso define una clase o forma particular de

usar el sistema mientras que cada ejecución del caso de uso se puede ver

como una instancia del caso de uso, o sea, un objeto, con estado y

comportamiento. Cada caso de uso constituye un flujo completo de eventos

especificando la interacción que toma lugar entre el actor y el sistema. El actor

primario es encargado de dar inicio a esta interacción, mientras que los casos

de uso son instanciados como respuesta al evento anterior. Una instancia de

un actor puede ejecutar varias de estas secuencias, consistiendo de diferentes

acciones que a su vez deben llevarse a cabo. La instancia del caso de uso

existe mientras el caso de uso siga ejecutando. La ejecución del caso de uso

termina cuando el actor genere un evento que requiera un caso de uso nuevo.

Las diferentes instancias de los casos de uso se conocen como escenarios.

Como varios casos de uso pueden comenzar de una misma forma, no es

siempre posible decidir que caso de uso se ha instanciado hasta que éste se

haya completado.

La descripción de los casos de uso es mediante diagramas similares a los de

transición de estados. Se puede ver a cada caso de uso como representando

un estado en el sistema, donde un estímulo enviado entre un actor y el sistema

ocasiona una transición entre estados. En la Figura 7.5 se muestra un ejemplo

de casos de uso, donde un programador escribe y depura un programa,

mientras que otro usuario lo ejecuta.

Figura 7.5 Ejemplo de casos de uso mostrando la relación con los actores


Práctica UCPR-IST


Para identificar los casos de uso, se puede leer la descripción del problema y

discutirlo con aquellos que actuarán como actores, haciendo preguntas como:

¿Cuales son las tareas principales de cada actor?

¿Tendrá el actor que consultar y modificar información del sistema?

¿Tendrá el actor que informar al sistema sobre cambios externos?

¿Desea el actor ser informado sobre cambios inesperados?

Por ejemplo, en un sistema de conmutación telefónica, un actor podría ser un

subscriptor, y un caso de uso típico sería hacer una llamada local. El caso de

uso comienza cuando el subscriptor levanta el teléfono. Otro caso de uso es

ordenar una llamada de despertar. Ambos casos de uso comienzan cuando el

subscriptor levanta el teléfono. Pero cuando el subscriptor levanta el teléfono

no sabemos cual caso de uso desea ejecutar. Por lo tanto, los casos de uso

pueden comenzar de forma similar y no podemos saber cual se está

instanciando hasta que se termine. En otras palabras, el actor no requiere que

un caso de uso se ejecute, sólo que inicie una secuencia de eventos que

finalmente resulte en la terminación de algunos casos de uso.

Extensión

Un concepto importante que se utiliza para estructurar y relacionar casos de

uso es la extensión. La extensión especifica cómo un caso de uso puede

insertarse en otro para extender la funcionalidad del anterior. El caso de uso

donde se va a insertar la nueva funcionalidad debe ser un flujo completo, por lo

cual éste es independiente del caso de uso a ser insertado. De esta manera, el

caso de uso inicial no requiere consideraciones adicionales al caso de uso a

ser insertado, únicamente especificando su punto de inserción.


Práctica UCPR-IST


Inclusión

Una relación adicional entre casos de uso es la inclusión. A diferencia de una

extensión, la inclusión se define como una sección de un caso de uso que es

parte obligatoria del caso de uso básico. El caso de uso donde se va a insertar

la funcionalidad depende del caso de uso a ser insertado. Se etiqueta la

relación con “incluye” (“include”).

Generalización

Una relación adicional entre casos de uso es la generalización la cual apoya la

reutilización de los casos de uso.

Mediante la relación de generalización es necesario describir las partes

similares una sola vez en lugar de repetirlas para todos los casos de uso con

comportamiento común. Se conoce a los casos de uso que se extraen como

casos de uso abstractos, ya que no serán instanciados independientemente,

sirviendo sólo para describir partes que son comunes a otros casos de uso. Se

conoce a los casos de uso que realmente serán instanciados como casos de

uso concretos. Las descripciones de los casos de uso abstractos se incluyen

en las descripciones de los casos de uso concretos. Esto significa que, cuando

una instancia de un caso de uso sigue la descripción de un caso de uso

concreto, en cierto punto continúa la descripción del caso de uso abstracto en

su lugar. Los casos de uso abstractos también pueden ser usados por otros

casos de uso abstractos. Es difícil saber cuando ya no tiene sentido seguir

extrayendo más casos de uso abstractos. Una técnica para extraer casos de

uso abstractos es identificar actores abstractos. Normalmente, no hay razón

para crear casos de uso abstractos que se usan en un solo caso de uso. Por lo

general, comportamientos similares entre casos de uso se identifica después

que se han descrito los casos de uso. Sin embargo, en algunos casos es

posible identificarlos antes. De forma intuitiva, esto es un „herencia de

secuencias‟ (en lugar de operaciones en el caso normal de herencia).


Práctica UCPR-IST


Documentación

Parte fundamental del modelo de casos de uso es una descripción textual

detallada de cada uno de los actores y casos de uso identificados. Estos

documentos son sumamente críticos ya que a partir de ellos se desarrollará el

sistema completo. El formato de documentación es el siguiente:

Actor: Nombre del actor

Casos de

Uso:

Nombre de los casos de uso en los cuales participa

Tipo: Primario o Secundario

Descripción: Breve descripción del actor

Las descripciones de los casos de uso representan todas las posibles

interacciones de los actores con el sistema para los eventos enviados o

recibidos por los actores. En esta etapa no se incluyen eventos internos al

propio sistema ya que esto será tratado durante el análisis y únicamente

agregaría complejidad innecesaria en esta etapa. El formato de documentación

es el siguiente

Caso de Uso: Nombre del caso de uso

Actores: Actores primarios y secundarios que

interaccionan con el caso de uso.

Tipo: Tipo de flujo: Básico, Inclusión, Extensión,

Generalización, o algún otro.

Propósito: Razón de ser del caso de uso.

Resumen: Resumen del caso de uso.

Precondiciones: Condiciones que deben satisfacerse

para poder ejecutar el caso de uso.

Flujo Principal: El flujo de eventos más importante del

caso de uso, donde dependiendo de

las acciones de los actores se

continuará con alguno de los


Práctica UCPR-IST


subflujos.

Subflujos: Los flujos secundarios del caso de

uso, numerados como (S-1), (S-2),

etc.

Excepciones: Excepciones que pueden ocurrir

durante el caso de uso, numerados

como (E-1), (E-2), etc.

7.3 Modelo de Interfaces

El modelo de interfaces describe la presentación de información entre los

actores y el sistema. Se especifica en detalle como se verán las interfaces de

usuario al ejecutar cada uno de los casos de uso. Si se trata de Interfaz

Humano Computadora (“HCI - Human Computer Interface”) se puede usar

esquemas de cómo vería el usuario las pantallas cuando se ejecuta cada caso

de uso. También se puede generar una simulación más sofisticada usando un

Sistema Manejador de Interfaces de Usuario (“UIMS - User Interface

Management System”). Normalmente, un prototipo funcional de requisitos

mostrando las interfaces de usuario es una estrategia importante. Esto ayuda al

usuario a visualizar los casos de uso según serán mostrados por el sistema a

ser construido. Tal enfoque elimina muchas posibilidades de malos

entendimientos. Cuando se diseñan las interfaces de usuario, es esencial tener

a los usuarios involucrados, siendo esencial que las interfaces reflejen la visión

lógica del sistema. Esto es realmente uno de los principios fundamentales del

diseño de interfaces humanas, donde debe existir consistencia entre la imagen

conceptual del usuario y el comportamiento real del sistema. Si las interfaces

son protocolos de hardware, se puede referir a los diferentes estándares, como

protocolos de comunicación. Estas descripciones de interfaces son por lo tanto

partes esenciales de las descripciones de los casos de uso y las deben

acompañar.


Práctica UCPR-IST


7.4 Modelo de Análisis

Cuando ya se ha desarrollado y aceptado el modelo de requisitos se comienza

el desarrollo del modelo de análisis.

El objetivo del modelo de análisis es comprender y generar una arquitectura de

objetos para el sistema en base a lo especificado en el modelo de requisitos.

Durante esta etapa no se considera el ambiente de implementación, lo cual

incluye al lenguaje de programación, manejador de base de datos, distribución

o configuración de hardware, etc. En otras palabras el análisis pretende

modelar el sistema bajo condiciones ideales, garantizando que la arquitectura

de software resultante se suficientemente robusta y extensible para servir de

base a la estructura lógica de la aplicación pero sin consideraciones relativas al

entorno de implementación que es posible que cambien incluso radicalmente.

Tarde o temprano el sistema tendrá que ser adaptado a las condiciones de

implementación deseadas, algo que se hará durante el diseño, cuando todas

las consideraciones que han sido descartadas durante el análisis sean

consideradas. Es importante enfatizar que el modelo de análisis no es una

reflexión del dominio del problema sino una representación de ésta adaptada a

la aplicación particular. El modelo de análisis genera una representación

conceptual del sistema, consistiendo de clases de objetos. Cada una de las

clases de objetos contribuye de manera especial para lograr la robustez de la

arquitectura, como se muestra conceptualmente en la Figura 7.6.

Figura 7.6. El diagrama muestra conceptualmente el modelo de análisis junto

con la arquitectura general de objetos en relación al modelo de requisitos

anteriormente desarrollado.


Práctica UCPR-IST


7.5 Arquitectura de Clases

El modelo de análisis tiene como objetivo generar una arquitectura de objetos

que sirva como base para el diseño posterior del sistema. Como se discutió en

la introducción del libro, dependiendo del tipo de aplicación existen diversas

arquitecturas que se pueden utilizar, siendo de nuestro interés aquellas

arquitecturas especialmente diseñadas para el manejo de los sistemas de

información, las cuales involucran ricas bordes de usuario y accesos a base de

datos como aspectos fundamentales de la arquitectura.

En le caso de los sistemas de información, uno de las tipos de arquitecturas

mas importantes es la arquitectura MVC – Modelo, Vista, Control (Model, View,

Control) popularizada por los ambientes de desarrollo de de Smalltalk. Esta

arquitectura se basa en tres dimensiones principales: Modelo (información),

Vista (presentación) y Control (comportamiento) como se muestra en la Figura

7.7.

Figura 7.7 Diagrama de tres dimensiones correspondientes a la arquitectura

MVC – Modelo. Vista Control.

Figura 7.7 Diagrama de tres dimensiones correspondiente a la arquitectura

MVC – Modelo, Vista, Control. La vista o presentación de la información

corresponde a las bordes que se le presentan al usuario para el manejo de la

información, donde por lo general pueden existir múltiples vistas sobre un

mismo modelo. Típicamente la información representa el dominio del problema

y es almacenada en una base de datos.


Práctica UCPR-IST


Clases con Estereotipos

El tipo de funcionalidad o “la razón de ser” de un objeto dentro de una

arquitectura se le conoce como su estereotipo. Para los sistemas de

información la arquitectura del sistema según nuestro modelo de análisis se

basa en tres estereotipos básicos de objetos:

El estereotipo entidad (“entity” en inglés)para objetos que guarden información

sobre el estado interno del sistema, a corto y largo plazo, correspondiente al

dominio del problema. Todo comportamiento naturalmente acoplado con esta

información también se incluye en los objeto entidad. Un ejemplo de un objeto

entidad es un registro de usuario con sus datos y comportamiento asociados.

El estereotipo interface o borde (“boundary” en inglés) para objetos que

implementen la presentación o vista correspondiente a las bordes del sistema

hacia el mundo externo, para todo tipo de actores, no sólo usuarios humanos.

Un ejemplo de un objeto borde es la funcionalidad de interface de usuario para

insertar o modificar información sobre el registro de usuario.

El estereotipo control (“control” en inglés) para objetos que implementen el

comportamiento o control especificando cuando y como el sistema cambia de

estado, correspondiente a los casos de uso. Los objetos control modelan

funcionalidad que no se liga naturalmente con ningún otro tipo de objeto, como

el comportamiento que opera en varios objetos entidad a la vez, por ejemplo,

hacer alguna computación y luego devolver el resultado a un objeto borde. Un

ejemplo típico de objeto control es analizar el uso del sistema por parte de

algún usuario registrado y presentar tal información posteriormente. Este

comportamiento no le pertenece a ningún objeto entidad u objeto borde

específico.


Práctica UCPR-IST


Nótese que no hay ninguna restricción a los diferentes estereotipos que puedan

utilizarse, no solamente las tres anteriores. La notación de UML para un

estereotipo se muestra en la Figura 7.8.

Figura 7.8 Diagrama de clases con estereotipos.

Figura 7.9. Diagrama de clases para los tres estereotipos.

Figura 7.7 Diagrama de clase para los tres estereotipo. Considerando que

habrá interacción entre los diferentes tipos de objetos, existirá cierto traslape en

la funcionalidad que los objetos ofrecen. Como se mencionó anteriormente,

este traslape deberá minimizarse para asegurar una buena extensibilidad,

donde típicamente, cada tipo de objeto captura por lo menos dos de las tres

dimensiones. Sin embargo, cada uno de ellos tiene cierta inclinación hacia una

de estas dos dimensiones, como se muestra en la Figura 7.10.

Figura 7.10. Diagrama mostrando los estereotipos de los objetos.


Práctica UCPR-IST


7.6 Modelo de Diseño

El modelo de diseño es un refinamiento y formalización adicional del modelo de

análisis donde se toman en cuenta las consecuencias del ambiente de

implementación. El resultado del modelo de diseño son especificaciones muy

detalladas de todos los objetos, incluyendo sus operaciones y atributos.

Se requiere un modelo de diseño ya que el modelo de análisis no es lo

suficientemente formal para poder llegar al código fuente. Por tal motivo se

debe refinar los objetos, incluyendo las operaciones que se deben ofrecer, la

comunicación entre los diferentes objetos, los eventos que los objetos envían

entre si, etc. El sistema real debe adaptarse al ambiente de implementación. En

el análisis se asume un mundo ideal para el sistema, en la realidad se debe

adaptar el sistema al ambiente de implementación, algo que puede cambiar

durante el ciclo de vida del sistema. Se busca además aspectos como, los

requisitos de rendimiento, necesidades de tiempo real, concurrencia, el

lenguaje de programación, el sistema de manejo de base de datos, etc. Se

desea también validar los resultados del análisis. Según el sistema crece y se

formaliza, se verá qué tan bien los modelos de requisitos y análisis describen al

sistema. Durante el diseño, se puede ver si los resultados del análisis son

apropiados para su implementación. Si se descubre aspectos que no están

claros en alguno de los modelos anteriores, estos deben ser clarificados,

quizás regresando a etapas anteriores.

Aunque esto pudiera verse como deficiencias del resultado de las fases

anteriores que deben ser clarificadas aquí, esto sería una visión incorrecta de

las diferentes etapas del desarrollo, ya que el propósito de los modelos de

requisitos y análisis es comprender el sistema y darle una buena estructura.

También es importante comprender que las consideraciones tomadas en

cuenta durante el diseño deben influir en la estructura del sistema lo menos

posible. Es la propia aplicación la que controla la estructura, no las

circunstancias de su implementación. Se considera el modelo de diseño como

una formalización del espacio de análisis, extendiéndolo para incluir una

dimensión adicional correspondiente al ambiente de implementación, como se

puede ver en el diagrama de la Figura 7.11.


Práctica UCPR-IST


Figura 7.11. El diseño añade el ambiente de implementación como un nuevo

eje de desarrollo.

Figura 7.11 El diseño añade el ambiente de implementación como un nuevo eje

de desarrollo. Esta nueva dimensión correspondiente al ambiente de

implementación debe considerarse al mismo tiempo que el propio modelo es

refinado. La meta es refinarlo hasta que sea fácil escribir código fuente. Como

el modelo de análisis define la arquitectura general del sistema, se busca

obtener una arquitectura detallada como resultado del modelo de diseño, de

manera que haya una continuidad de refinamiento entre los dos modelos, como

se puede ver en el diagrama de la Figura 7.12. En particular se puede apreciar

el cambio en los modelos a partir de la introducción del ambiente de

implementación

Figura 7.12. El modelo de diseño es una continuación del modelo de análisis.

La transición de análisis a diseño debe decidirse por separado para cada

aplicación particular. Aunque es posible continuar trabajando sobre el modelo

de análisis, incluso durante la incorporación del ambiente de implementación,

esto no es recomendable, ya que aumenta su complejidad.


Práctica UCPR-IST


Diseño de Objetos. Se refina y formaliza el modelo para generar

especificaciones muy detalladas de todos los objetos, incluyendo sus

operaciones y atributos. Se describe cómo interaccionan los objetos en cada

caso de uso específico, especificando qué debe hacer cada operación en cada

objeto. Este paso genera las interfaces de los objetos, las cuales deben ser

luego implementadas mediante métodos.

Diseño de Sistema. Se adapta el modelo al ambiente de implementación. Este

paso incluye identificar e investigar las consecuencias del ambiente de

implementación sobre el diseño. Aquí deben ser tomadas las decisiones de

implementación estratégicas: (i) cómo se incorporará una base de datos en el

sistema, (ii) qué bibliotecas de componentes se usarán y cómo, (iii) qué

lenguajes de programación se utilizarán, (iv) cómo se manejarán los procesos,

incluyendo comunicación y requisitos de rendimiento, (v) cómo se diseñará el

manejo de excepciones y recolección de basura, etc.

7.8 Estrategias de Diseño

Antes de poder resolver el diseño es necesario tomar decisiones generales

sobre las estrategias de diseño a seguir. Algunas de las decisiones a tomar se

presentan a continuación y se relacionan con aspectos que incluyen la

arquitectura, robustez, reuso y extensibilidad del sistema.

7.9 Implementación

El modelo de implementación toma el resultado del modelo de diseño para

generar el código final. Esta traducción debe ser relativamente sencilla y

directa, ya que las decisiones mayores han sido tomadas durante las etapas

previas.


Práctica UCPR-IST


Durante el modelo de implementación se hace una adaptación al lenguaje de

programación y/o la base de datos de acuerdo a la especificación del diseño y

según las propiedades del lenguaje de implementación y base de datos.

Aunque el diseño de objetos es bastante independiente del lenguaje actual,

todos los lenguajes tendrán sus particularidades, las cuales deberán adecuarse

durante la implementación final. La elección del lenguaje influye en el diseño,

pero el diseño no debe depender de los detalles del lenguaje. Si se cambia de

lenguaje de programación no debe requerirse el re-diseño del sistema.

En general, no se debe comenzar prematuramente a programar, es importante

primero completar el proceso de planeación del sistema final desarrollado

durante el diseño. Se debe usar guías de programación existentes en la

organización. Si no existen, el equipo de software deben crear sus propias

guías para decidir aspectos, como formatos para la asignación de nombres a

las variables, estilo de programación, métodos de documentación, y

documentación en línea. Vale la pena resaltar que aunque existe cierta

automatización en el proceso de generación del código final, en su gran

mayoría los programadores hacen de manera “manual” la transición final a

código fuente.

7.10 Modelo de Pruebas

Probar un producto es relativamente independiente de la metodología de

desarrollo utilizada para construirlo.

Existen diversos tipos de pruebas aplicados durante las diferentes actividades

del proceso de desarrollo. Estas pruebas requieren de tiempo y presupuesto

adicional, pudiendo llegar a significar entre un 30% y un 50% del costo total de

desarrollo. Por tal motivo, el modelo de pruebas debe ser planificado con

anticipación y de manera integral junto con el propio desarrollo del sistema. Es

un error pensar que las pruebas son la última actividad del desarrollo ya que no

se puede lograr software de alta calidad sólo mediante pruebas finales y

depuraciones. Las pruebas deben hacerse en paralelo al desarrollo del

sistema, teniendo pruebas finales únicamente como certificación final de la

calidad del producto y no como la oportunidad para encontrar errores.

Encontrar errores al final del desarrollo es bastante problemático dado que

requerirá regresar a etapas anteriores para resolverlos.

Se considera que "evitar defectos" es más poderoso que "remover defectos"


Práctica UCPR-IST


7.11 Definición de Conceptos

Las siguiente definiciones de IEEE (1983) pueden utilizarse para definir ciertos

conceptos conocidos de manera informal como “bugs”:

Una falla (failure) ocurre cuando un programa no se comporta bien, siendo la

falla una propiedad (estadística) de un sistema en ejecución. Una falta (fault)

existe en el código del programa, el cual si se presenta, puede ocasionar una

falla (failure). No puede haber una falta si el programa no puede fallar (fail).

Un error es una acción humana que resulta en que un software contenga una

falta, por lo cual un error puede significar la inclusión de una falta en el

programa, haciendo que el sistema falle. Un aspecto importante con los

conceptos anteriores es que no se puede garantizar ni probar que un sistema

jamás falle, solo se puede demostrar que contiene faltas. En otras palabras, no

encontrar faltas no significa que la prueba haya sido exitosa. Se debe

considerar una prueba como exitosa sólo si esta ha encontrado faltas. Sin

embargo, pruebas exitosas significarán que no se ha desarrollado un buen

sistema. Dada la dificultad de probar un sistema y de encontrar faltas, el

encargado de encontrar las faltas en el código es generalmente una persona

distinta al desarrollador del sistema. Esto también significa un costo adicional

en el desarrollo del sistema, por lo cual a veces sólo se prueban las partes

principales del sistema.

Es un fenómeno muy conocido que cuando se corrigen las faltas detectadas,

se introducen nuevas faltas en el sistema, requiriendo probar nuevamente todo

el sistema completo, esperando que el número de faltas introducidas sea

menor que el número anterior. Según Levendel (1990), generalmente se

introduce una nueva falta por cada tercera falta corregida.


Práctica UCPR-IST


7.13 Tipos de Pruebas

Los tipos de pruebas se dividen de manera general en pruebas de verificación

y validación. En el caso de la verificación se revisa si el resultado corresponde

a la especificación del sistema, en otras palabras, si se está construyendo el

sistema correctamente, algo por si sólo no garantiza la satisfacción de los

clientes. En el caso de la validación se revisa si el resultado es realmente lo

que el cliente quería, en otras palabras, si se está construyendo el sistema

correcto de manera que tanto la especificación como el resultado sean los

correctos. En este capítulo nos concentraremos principalmente en la

verificación del sistema. La validación del sistema debiera hacerse durante la

especificación inicial del sistema a través de prototipos que deben ser

aprobados por el cliente y que correspondan a la funcionalidad deseada. El

sistema debe validarse continuamente durante el proceso de desarrollo del

sistema de manera siempre corresponda con lo especificado. La validación se

basa en el modelo de casos de uso. Existen también diferentes técnicas y

niveles de pruebas que pueden aplicarse. Estas se describen en las siguientes

secciones.


Práctica UCPR-IST


8. PRESENTACION Y ANÁLISIS DE RESULTADOS

8.1 MODELO DE REQUISITOS

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo [1].


Práctica UCPR-IST


8.1.1 DESCRIPCIÓN DEL PROBLEMA

Este es un sistema que permite al usuario buscar la ubicación donde fue archivada la correspondencia del centro de Acopio del Centro de Acopio de la Registraduría Nacional del Estado Civil, además de poder generar informes durante diferentes periodos de tiempo sobre la correspondencia recibida o despachada, este sistema permitirá tener un control y digitalización de la información del archivo de la correspondencia facilitando así la búsqueda de cualquier oficio que sea requerido por el usuario. Se Utilizara una base de datos en MySQL ya que esta se ajusta a las necesidades del sistema propuesto para desarrollar, especificaciones que se explicaran mas adelante con el desarrollo del sistema. La descripción del problema para nuestro sistema de correspondencia es la siguiente: El Sistema de correspondencia permite al usuario ingresar la información de la correspondencia despachada y recibida, realizar búsqueda de los oficios que fueron despachados o recibidos, además de poder generar informes sobre estadísticas del manejo de la correspondencia. El sistema presenta en su pantalla principal un mensaje de bienvenida describiendo el nombre del programa. Luego se pasa a la parte de acceso que se da por medio de la inserción de un nombre de usuario previamente especificado y un clave previamente escogido y que debe validarse. Una vez registrado el usuario, y después de haberse validado el registro y contraseña del usuario, se pueden seleccionar las siguientes actividades:

Ingreso de la Correspondencia Despachada.

Ingreso de la Correspondencia Recibida

Búsqueda de la información de la Correspondencia Despachada o Recibida.

Generar Informes durante tiempos determinados de la correspondencia.

Manual de usuario.

Salir El ingreso de la correspondencia Despachada, permite al usuario ingresar toda la información del oficio, la sección a la que pertenece, la ciudad y la ubicación donde fue archivada.


Práctica UCPR-IST


El ingreso de la correspondencia Recibida, permite al usuario ingresar toda la información del oficio, la sección a la que pertenece, la ciudad y la ubicación donde fue archivada. La búsqueda de la correspondencia, le permite al usuario por cualquier tipo de información ya sea la del oficio, la sección, la ciudad o la ubicación donde fue archivada, encontrar la información de la correspondencia Despachada o recibida. Generar Informes, le permite al usuario sacar estadísticas de la correspondencia durante tiempos determinados Manual de usuario le permite tener información sobre el manejo del sistema para un mejor manejo del sistema desarrollado. Además de los servicios de ingreso de correspondencia, el usuario podrá en cualquier momento accesar, modificar o cancelar cualquier ingreso, todo esto después de haber sido el usuario validado en el sistema.

8.1.2 MODELO DE CASOS DE USO

Sistema de Reservaciones de Correspondencia, se pueden identificar de la descripción del problema que se tiene un actor, el Usuario, encargado de ingresar la información realizar consultas y generar informes. Se puede identificar que las bases de datos es muy activo con respecto al sistema en desarrollo. A este actor lo llamaremos la Base de Datos de Correspondencia, mantiene la información donde son archivadas la correspondencia Despachada o Recibida. El diagrama de Delimitación del Sistema con los actores correspondientes se muestra en la Figura 8.1.1.

Figura 8.1. 1. Delimitación del Sistema de Correspondencia.

USUARIO

Sistema de

Correspondencia

Base de datos

de

correspondencia


Práctica UCPR-IST


El actor Usuario se considera un actor primario, ya que el sistema se construye pensando en sus usuarios, mientras que Base de Datos Correspondencia es un actor secundario.

8.1.3 CASOS DE USO

El actor primario es encargado de dar inicio a esta interacción, mientras que los casos de uso son instanciados como respuesta al evento anterior. Una instancia de un actor puede ejecutar varias de estas secuencias, consistiendo de diferentes acciones que a su vez deben llevarse a cabo. La instancia del caso de uso existe mientras el caso de uso siga ejecutando. La ejecución del caso de uso termina cuando el actor genere un evento que requiera un caso de uso nuevo. Las diferentes instancias de los casos de uso se conocen como escenarios. Como varios casos de uso pueden comenzar de una misma forma, no es siempre posible decidir qué caso de uso se ha instanciado hasta que éste se haya completado. La descripción de los casos de uso es mediante diagramas similares a los de transición de estados. Se puede ver a cada caso de uso como representando un estado en el sistema, donde un estímulo enviado entre un actor y el sistema ocasiona una transición entre estados. [1] En el sistema de Correspondencia los actores ya identificados como punto de partida. Dado que el Usuario es el actor primario se comienza con él. El sistema tiene que poder dar ciertos servicios al usuario, como Ingreso, búsqueda y generación de informes de la Información. De aquí podemos definir nuestros casos de uso principales, Ingresar Información y Hacer Búsqueda. La Figura 8.1. 2 muestra el sistema con los dos casos de uso, además de un caso de uso adicional, Generar Informes, Correspondiente a un actor secundario que es manejado por el Usuario. Sin embargo, para lograr una mejor especificación de requisitos y evitar complejidad adicional, no veremos ninguna funcionalidad de mantenimiento en nuestro desarrollo.


Práctica UCPR-IST


Figura 8.1.2. Casos de uso para un sistema de Correspondencia.

En la descripción del problema se menciona que para poder utilizar el sistema el usuario debe estar registrado, por lo cual agregamos un caso de uso Validar Usuario. Por otro lado, se debe incluir la Base de Datos de Correspondencia, ya que es actor secundario necesario. Estos Cuatro casos de uso se muestran en la Figura 8.1. 3.

USUARIO

Ingresar Información

Buscar Información

Generar Informes


Práctica UCPR-IST


Figura 8.1.3. Caso de Uso principales para el sistema de correspondencia.

USUARIO

Validar Usuario

Ingresar Información

Buscar Información

Generar Informes

Base de datos

de

correspondencia


Práctica UCPR-IST


8.1.4 MODELO DE INTERFACES

El modelo de interfaces describe la presentación de información entre los actores y el sistema. Se especifica en detalle cómo se verán las interfaces de usuario al ejecutar cada uno de los casos de uso. Si se trata de Interfaz Humano Computadora (“HCI - Human Computer Interface”) se puede usar esquemas de cómo vería el usuario las pantallas cuando se ejecuta cada caso de uso. También se puede generar una simulación más sofisticada usando un Sistema Manejador de Interfaces de Usuario (“UIMS - User Interface Management System”). Normalmente, un prototipo funcional de requisitos mostrando las interfaces de usuario es una estrategia importante. Esto ayuda al usuario a visualizar los casos de uso según serán mostrados por el sistema a ser construido. [1]

8.1.5 ACTORES Y CASOS DE USO PARA EL SISTEMA DE CORRESPONDENCIA

ACTORES

Se describen en total cuatro actores en el sistema de correspondencia. El Usuario interactúa con todos los casos de uso, aunque todas las asociaciones no fueron diagramadas de manera explícita en la Figura 8.1.3.

ACTORES:

USUARIO

CASOS DE USO:

Validar Usuario, Ingresar Información, Buscar Información, Generar informes.

TIPO:

Primario


Práctica UCPR-IST


DESCRIPCION:

Es el actor principal y representa a cualquier persona que desee utilizar del sistema de correspondencia.

La Base de Datos de Correspondencia interactúa con los casos de uso relacionados exclusivamente con correspondencia.

ACTORES:

Base de datos Correspondencia

CASOS DE USO:

Validar Usuario, Ingresar Información, Buscar Información, Generar informes.

TIPO:

Secundario

DESCRIPCION:

Es un actor secundario y representa a la base de datos donde se guarda toda la información relacionada con la correspondencia pero independiente de los propios usuarios del sistema.


Práctica UCPR-IST


8.1.6 CASOS DE USO

Como apoyo en la descripción de los casos de uso mostraremos las diversas pantallas diseñadas, comenzando con la pantalla inicial. Dado que el requisito de uso del sistema es que todo usuario ya esté registrado, la pantalla de inicio es para validar el usuario. Como se muestra en la Figura 8.1.4.

Figura 8.1.4. Pantalla de validación del sistema (P -1)

A continuación describimos los distintos casos de uso con las pantallas correspondientes. Se excluyen pantallas menores como aquellas con mensajes de error o confirmación del éxito de la operación. Comenzamos describiendo los flujos Validar Usuario, por los diversos casos de uso. Posteriormente describimos cada uno de los casos básicos y de extensión.


Práctica UCPR-IST


Validar Usuario

El caso de uso Validar Usuario está vinculado con la pantalla principal (P-1) y es llamada a partir de los casos de uso Usuario, valida en nombre de usuario y contraseña para poder acceder a la pantalla del menú principal (P-2).

CASOS DE USO

Validar Usuario

ACTORES

Usuario, Base de datos Correspondencia

TIPO

Básico

PROPÓSITOS

Validar a un usuario ya registrado para el uso del sistema de correspondencia.

RESUMEN

Este caso de uso es iniciado por el Usuario. Valida al usuario mediante un usuario y contraseña a ser validado con su respectivo registro en la base de datos, para así poder utilizar el sistema de correspondencia.

PRECONDICIONES

Se requieren estar el usuario registrado en la base de datos correspondencia.

FLUJO PRINCIPAL

Se presenta al usuario la Pantalla de Validación (P-1). El Usuario ingresa el nombre de usuario y contraseña. Luego da “Aceptar” valida el usuario y la contraseña. Una vez validado el usuario (E-1), se continúa con la pantalla menú (P-2). Si la actividad seleccionada es "Cancelar" se saldrá del sistema.

SUBFLUJOS

Ninguno

EXCEPCIONES

E-1 no hubo validación: El Usuario/Contraseña no se validó correctamente. Se solicita al usuario volver a ingresar Usuario/contraseña.


Práctica UCPR-IST


OFRECER SERVICIOS

Si nos referimos al diagrama de casos de uso de la Figura 8.1.3 vemos que existen tres casos de uso básicos que el usuario puede instanciar, Ingresar información, Buscar Información y Generar Informes. El caso de uso Ofrecer Servicio es incluido por estos tres casos de uso básicos para delegar de manera adecuada a ellos según las opciones seleccionadas por el usuario. También es incluido por el caso de uso Manual de Usuario. Información sobre el manejo del sistema.

CASOS DE USO

Ofrecer Servicios

ACTORES

Usuario

TIPO

Inclusión

PROPÓSITOS

Ofrecer los diversos servicios a un usuario ya registrado para el uso del sistema de correspondencia.

RESUMEN

Este caso de uso es iniciado por el Usuario. Tiene opciones para utilizar las diversas opciones del sistema de correspondencia.

PRECONDICIONES

Se requieren haber la validación correcta del usuario.

FLUJO PRINCIPAL

Se presenta al usuario la Pantalla Menú (P-2). El usuario puede seleccionar entre las siguientes actividades: Para ingresar la información puede seleccionar “Correspondencia Despachada” o “Correspondencia Recibida”, para buscar información “Buscar Correspondencia”, para generar informes "Informes Correspondencia" y "Salir". Si la actividad seleccionada es "Correspondencia Despachada" o “Correspondencia Recibida”, se continua con el caso de uso Ingresar Información, subflujo Ingreso Correspondencia Despachada (S-1)o


Práctica UCPR-IST


Correspondencia Recibida (S-2). Si la actividad seleccionada es "Buscar Correspondencia", se continua con el caso de uso Buscar Información, subflujo Buscar Correspondencia (S-1). Si la actividad seleccionada es "Informes Correspondencia", se continúa con el caso de uso Generar Informes, subflujo Informes Correspondencia (S-1). Si la actividad seleccionada es "Salir" se saldrá del sistema.

SUBFLUJOS

Ninguno

EXCEPCIONES

Ninguno

La siguiente pantalla del sistema debe permitir al usuario seleccionar las opciones correspondientes, como se muestra en la Figura 8.1.5.

Figura 8.1. 5. Pantalla de menú de servicios. (P-2)


Práctica UCPR-IST


CORRESPONDENCIA DESPACHADA

El caso de uso Correspondencia Despachada está vinculado con el registro inicial del usuario y la modificación de la información de registro. Además, deben ya incluirse los puntos de inclusión y extensión para los casos de uso Validar Usuario, Ofrecer Servicios y Ingresar Información, respectivamente. Se describe a continuación las secciones iniciales del caso de uso.

CASOS DE USO

Correspondencia Despachada

ACTORES


TIPO

Básico

PROPÓSITOS

Permite ingresar la información de la correspondencia Despachada.

RESUMEN

Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para crear, modificar y eliminar el ingreso de información con el sistema de correspondencia.

PRECONDICIONES

Debe estar validado el usuario registrado en la base de datos correspondencia.

FLUJO PRINCIPAL

Se ejecuta el caso de uso Ingreso Información. Dependiendo de las opciones seleccionadas por el Usuario, podrá crear, modificar o eliminar. Según los permisos que tenga el usuario validado en el caso de uso Validado Usuario.

SUBFLUJOS

S-1 Ingresar información de la correspondencia despachada Se presenta al usuario la Pantalla Correspondencia


Práctica UCPR-IST


Despachada (P-3). Esta pantalla contiene información de registro que debe ser llenada por el usuario, lo cual incluye destinatario, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio. El usuario puede seleccionar entre las siguientes actividades: "Crear”, "Modificar", “Eliminar” o “Menú”. Si el usuario selecciona “crear”. Si la actividad seleccionada es "Menú" se saldrá y regresara a la pantalla(P-2)

EXCEPCIONES

Para poder modificar o eliminar debe llenar los campos “Destinatario” y “Numero de Oficio”. Si no llena estos campos se le solicitara que debe ingresar estos datos.

El diseño de la pantalla para Ingresar la información de la Correspondencia Despachada se muestra en la Figura 8.1.6.


Práctica UCPR-IST


Figura 8.1. 6. Pantalla de ingreso de Información de la Correspondencia Despachada (P-3)

CORRESPONDENCIA RECIBIDA

El caso de uso Correspondencia Recibida está vinculado con el registro inicial del usuario y la modificación de la información de registro. Además, deben ya incluirse los puntos de inclusión y extensión para los casos de uso Validar Usuario, Ofrecer Servicios y Ingresar Información, respectivamente. Se describe a continuación las secciones iniciales del caso de uso.

CASOS DE USO

Correspondencia Recibido

ACTORES


TIPO

Básico

PROPÓSITOS

Permite ingresar la información de la correspondencia Recibida.

RESUMEN

Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para crear, modificar y eliminar el ingreso de información con el sistema de correspondencia.

PRECONDICIONES


FLUJO PRINCIPAL


SUBFLUJOS

S-1 Ingresar información de la Correspondencia Recibida Se presenta al usuario la Pantalla Correspondencia


Práctica UCPR-IST


Recibida (P-3). Esta pantalla contiene información de registro que debe ser llenada por el usuario, lo cual incluye remitente, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, dirección, teléfono, fecha recibido, fecha radicado sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio. El usuario puede seleccionar entre las siguientes actividades: "Crear”, "Modificar", “Eliminar” o “Menú”. Si el usuario selecciona “crear”. Si la actividad seleccionada es "Menú" se saldrá y regresara a la pantalla(P-2)

EXCEPCIONES

Para poder modificar o eliminar debe llenar los campos “Destinatario” y “Numero de Oficio”. Si no llena estos campos se le solicitara que debe ingresar estos datos.

El diseño de la pantalla para Ingresar la información de la Correspondencia Despachada se muestra en la Figura 8.1.7.


Práctica UCPR-IST


Figura 8.1. 7. Pantalla de ingreso de Información de la Correspondencia Recibida (P-4)

BÚSQUEDA DE CORRESPONDENCIA

El caso de uso Búsqueda de Correspondencia está vinculado con el caso de uso búsqueda de la información. Se describe a continuación las secciones iniciales del caso de uso.

CASOS DE USO

Búsqueda de Correspondencia

ACTORES


TIPO

Básico

PROPÓSITOS

Permite buscar la información de la correspondencia.

RESUMEN

Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para buscar la información de la correspondencia.

PRECONDICIONES


FLUJO PRINCIPAL


SUBFLUJOS

S-1 Ingresar la información por la cual desea buscar la correspondencia Se presenta al usuario la Pantalla de búsqueda de Correspondencia (P-5). Esta pantalla contiene información de registro que debe ser llenada por el


Práctica UCPR-IST


usuario, lo cual incluye remitente, destinatario, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, dirección, teléfono, fecha recibido, fecha radicado sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio. El usuario puede seleccionar entre las siguientes actividades: "Buscar” o “Menú”. Si el usuario selecciona “Buscar”, debe seleccionar un check de la información con la que quiere buscar la informacion. Si la actividad seleccionada es "Menú" se saldrá y regresara a la pantalla(P-2)

EXCEPCIONES

Para poder Buscar el usuario debe seleccionar si la correspondencia es “Despachada” o “Recibida”. Si no selecciona el tipo de correspondencia el sistema tomara uno por defecto.

El diseño de la pantalla para Buscar la información de la correspondencia se muestra en la Figura 8.1.8.


Práctica UCPR-IST


Figura 8.1.8. Pantalla de Búsqueda de Información de la Correspondencia (P-5)

Dado que el usuario al dar Buscar se despliega una pantalla (P-6), en donde se observa toda la información de la correspondencia encontrada, como se muestra en el subflujo a continuación.

SUBFLUJO

S-1 Buscar

Se despliega la Pantalla de Correspondencia Encontrada (P-6). El usuario ver la información de la correspondencia encontrada en la base de datos Correspondencia. .

Si el usuario presiona "Menú" se cierra la pantalla (P-6) y regresa al menú.

En la Figura 8.1. 9 se muestra el diseño de la pantalla de correspondencia encontrada, correspondiente al subflujo Buscar(S-1).


Práctica UCPR-IST


Figura 8.1. 9. Pantalla de la correspondencia encontrada (P-6).

INFORMES CORRESPONDENCIA

El caso de uso Informes Correspondencia está vinculado con el caso de uso Generar Informes. Se describe a continuación las secciones iniciales del caso de uso.

CASOS DE USO

Informes Correspondencia

ACTORES


TIPO

Básico

PROPÓSITOS

Permite generar informes de la correspondencia recibida o despachada durante un tiempo determinado.


Práctica UCPR-IST


RESUMEN

Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para elegir una fecha inicial y final, para conocer qué cantidad de correspondencia se ha enviado o recibido.

PRECONDICIONES


FLUJO PRINCIPAL

Se ejecuta el caso de uso Generar Informes. Puede generar un informe del numero de la correspondencia despachada o recibida por medio de un periodo de tiempo determinado..

SUBFLUJOS

S-1 Generar Informes de la Correspondencia Recibida o Despachada. Se presenta al usuario la Pantalla Informes Correspondencia (P-7). Esta pantalla contiene información de registro que debe ser llenada por el usuario, lo cual incluye fecha inicial, fecha final. El usuario puede seleccionar entre las siguientes actividades: “Generar Informe”, “Menú”.Si la actividad seleccionada es “Generar Informe” se mostrara en pantalla la información de la correspondencia durante el tiempo seleccionado. Si la actividad seleccionada es "Menú" se saldrá y regresara a la pantalla(P-2)

EXCEPCIONES Ninguno

El diseño de la pantalla para Informes Correspondencia se muestra en la Figura 8.1. 10.


Práctica UCPR-IST


Figura 8.1. 10. Pantalla Informes de la Correspondencia (P-7)

MANUAL DE USUARIO

El caso de uso Manual de Usuario está vinculado con el documento de información del manejo del sistema. Se describe a continuación las secciones iniciales del caso de uso.


Práctica UCPR-IST


CASOS DE USO Manual de Usuario

ACTORES

Usuario

TIPO

Básico

PROPÓSITOS

Permite ver un documento de la información sobre el manejo del sistema.

RESUMEN

Este caso de uso es iniciado por el Usuario. Ofrece al usuario la posibilidad de ver el documento del manual de usuario.

PRECONDICIONES

Ninguno

FLUJO PRINCIPAL

Se presenta al usuario la Pantalla de Manual Usuario (P-8). En el que se muestra el documento del manual de usuario para el manejo del sistema. Si la actividad seleccionada es "Menú" Se cierra la pantalla (P-8) y regresa a la pantalla del menú (P-2).

SUBFLUJOS

Ninguno

EXCEPCIONES Ninguno

El diseño de la pantalla para el Manual de Usuario se muestra en la Figura 8.1. 11.


Práctica UCPR-IST


Figura 8.1. 11. Pantalla Manual de Usuario (P-8)

8.1.7 Modelo del Dominio del Problema


Práctica UCPR-IST


El modelo del dominio del problema define un modelo de clases común para todos los involucrados en el modelo de requisitos, analistas al igual que clientes. Este modelo de clases consiste de los objetos del dominio del problema, sea objetos que tienen una correspondencia directa en el área de la aplicación. Como los usuarios y clientes deberían reconocer todos los conceptos, se puede desarrollar una terminología común al razonar sobre los casos de uso, y por lo tanto disminuyendo la probabilidad de malos entendimientos entre el analista y el usuario. Al discutirlo, se evolucionará el modelo del dominio del problema. [1]

Identificación de clases.

La identificación de clases del dominio del problema se obtiene principalmente de algún documento textual que describa el sistema. Que se presenta a continuación. El Sistema de Correspondencia del Centro de Acopio es un sistema que permite al usuario tener un control y búsqueda de la correspondencia despachada o recibida, además de poder generar informes sobre el total de la correspondencia despachada recibida durante un tiempo determinado, sin la necesidad de tener que buscar esta correspondencia en todas las cajas donde se guardan los legajos donde son archivados los folios. Se desea que el sistema de Correspondencia se pueda buscar por cualquiera de sus atributos, como por ejemplo a la sección a la que pertenecen, la ciudad, o información del oficio. El sistema presenta en su pantalla principal un mensaje de bienvenida y posteriormente la parte de autentificación del usuario en el cual solicitara el nombre y contraseña. Una vez validado el usuario el usuario y contraseña, se ingresa al menú principal en donde podrá seleccionar las siguientes actividades:

Ingresar la información de la Correspondencia Despachada.

Ingresar la información de la Correspondencia Recibida.

Buscar la Información de la Correspondencia Despachada o Recibida.

Generar Informes de la Correspondencia.

Ver el Manual de Usuario

Salir. El ingreso de la información de la correspondencia Despachada o Recibida, permite digitar la información del folio o documento que es enviado y luego archivado


Práctica UCPR-IST


La búsqueda de la información de la correspondencia, muestra la información y la ubicación en donde fue archivada. Generar Informes permite al usuario generar un informe sobre la cantidad de correspondencia despachada o Recibida durante un tiempo determinado. El manual de usuario, presenta un documento para el buen manejo del sistema. Además de los Ingresos de información, el usuario podrá en cualquier momento accesar, modificar o eliminar la información de la correspondencia, todo esto después de haber sido el usuario validado en el sistema. A partir de estos sustantivos se prepara una lista inicial de clases candidatas, como se muestra en la Tabla 8.1.1.

Clases Candidatas

Sistema de Correspondencia Sistema Usuario Control Búsqueda Correspondencia Despachada Correspondencia Recibida Generar Informes Tiempo determinado Buscar Correspondencia Cajas Legajos Folios Buscar Sección Ciudad oficio

Autentificación Usuario Nombre Contraseña Correspondencia Despachada Correspondencia Recibida Buscar Correspondencia Informes de la Correspondencia Manual de Usuario Salir Ingreso Folio Archivado Búsqueda información generar informes cantidad tiempo determinado accesar modificar eliminar

Tabla 8.1.1. Clases candidatas para el sistema de correspondencia

La Tabla 8.1. 2. Muestra las modificaciones a las clases candidatas originales.


Práctica UCPR-IST


Clases Candidato

Modificación

Sistema de Correspondencia Sistema Usuario Control Búsqueda Correspondencia Despachada Correspondencia Recibida Generar Informes Tiempo determinado Buscar Correspondencia Cajas Legajos Folios Buscar Sección Ciudad oficio Autentificación Nombre Contraseña Correspondencia Despachada Correspondencia Recibida Buscar Correspondencia Informes de la Correspondencia Manual de Usuario Salir Ingreso Folio Archivado Búsqueda información generar informes cantidad tiempo determinado accesar modificar eliminar

Eliminada (Sistema completo) Eliminada (imprecisa) Eliminada (Actor) Eliminada (operación) Eliminada (operación) Eliminada (operación) Eliminada (imprecisa) Eliminada(operacional) Eliminada(Sistema Completo) Eliminada(atributo) Eliminada(atributo) Eliminada(atributo) Eliminada(operacional) Renombrada Usuario Eliminada(atributo) Eliminada(atributo) Eliminada(duplicidad) Eliminada(duplicidad) Eliminada(operacional) Eliminada(imprecisa) Eliminada(imprecisa) Eliminada(irrelevante) Eliminada(imprecisa) Eliminada(atributo) Renombrada Archivo Eliminada(operacional) Eliminada(imprecisa) Eliminada(operacional) Eliminada(operacional) Eliminada(operacional) Eliminada(operacional) Eliminada(operacional) Eliminada(operacional)

Tabla 8.1. 2. Clases candidatas para el sistema de correspondencia identificadas de la descripción del problema.


Práctica UCPR-IST


Las clases identificadas se muestran en la Tabla 8.1. 3.

Clases Identificadas

Correspondencia Despachada Correspondencia Recibida Sección Ciudad

Oficio Usuario archivo

Tabla 8.1. 3. Clases identificadas para el sistema de correspondencia

Correspondencia_Despachada

Sección

Oficio

Figura 8.1.12. Diagrama de clases con asociaciones entre clases identificadas.

Después de haber hecho el diagrama de clases con asociaciones, se puede construir una versión del diagrama de clases incluyendo roles. Como se muestra en la Tabla 8.1. 4.

Correspondencia_Recibida

Ciudad

usuario

Archivo


Práctica UCPR-IST


Asociaciones identificadas con roles

Un archivo contiene correspondencia recibida Un archivo contiene correspondencia despachada Un archivo pertenece a una ciudad Un archivo pertenece a una ciudad Un archivo tiene un usuario Un oficio puede ser de correspondencia recibida Un oficio puede ser de correspondencia despachada

Tabla 8.1.4. Asociaciones identificadas con roles para relacionar clases en el dominio del problema.

A continuación se presenta el modelo entidad relación del sistema de la correspondencia.


Práctica UCPR-IST


Figura 8.1.13. Diagrama de clases con asociaciones y roles entre clases identificadas.

El diagrama de clases con asociaciones y roles, para incluir multiplicidad, como se muestra en la Figura 8.1.14

Oficios

Correspondencia_DespachadaCorrespondencia_Recibida

Ciudad

ArchivoSeccion

Usuario

RecibeDespacha

Almacenar

Guardar

Para Ingresar

Tiene

posee

CORRESPONDENCIA CENTRO DE ACOPIO

REGISTRADURIA NACIONAL DEL ESTADO CIVIL

DELEGACION DEPARTAMENTAL DEL RISARALDA

CENTRO DE ACOPIO


Practicante

UNIVERSIDAD CATOLICA POPULAR DEL RISARALDA

FACULTAD DE CIENCIAS BASICAS E INGENIERIA

PROGRAMA INGENIERIA DE SISTEMAS Y TELECOMUNICACIONES

PEREIRA - 2009

Registra

Pertenece

ContieneHay


Práctica UCPR-IST



Sección

Oficio

Figura 8.1.14 Diagrama de clases con asociaciones.

8.1.8 Identificación de Atributos

En lugar de esto, simplemente identificamos nuestros propios atributos para las distintas clases identificadas para el dominio del problema del sistema de reservaciones, como se muestran en la Tabla 8.1.5.

Clases Atributos

Correspondencia_Recibida Codigo_Despacho, Destinatario, Seccion_persona, Numero_Oficio,


Ciudad

usuario

Archivo

*

1

* * * * *

* * * *

*

*

1

1

1 1

1

1

1

1 1


Práctica UCPR-IST


Correspondencia Recibida

Oficios

Archivo

Sección

Ciudad

Usuario

Fecha_Oficio, Objeto_Referencia, Entidad_Persona, Legajo, Folio, Caja, Fecha_inicial, Fecha_final, Ciudad, Subseccion, Serie, Subserie.

Codigo_Recibido, Remitente, Fecha_Recibido, Fecha_Radicado, Dirección, Teléfono, Numero_de_Oficio, Fecha_Oficio, Objeto_Referencia, Entidad_Persona, Legajo, Folio, Caja, Fecha_inicial, Fecha_final, Ciudad, Subseccion, Serie, Subserie. Numero_Oficio, Fecha_Oficio, Objeto_Referencia, Entidad_Persona. Codigo_Archivo, Legajo, Folio, Caja, Fecha_Inicial, Fecha_Final, Ciudad, Subseccion, serie, Subserie, Nombre, Clave. Codigo_Seccion, Subseccion, Serie, Subserie. Codigo_Ciudad, Departamento, Municipio Nombre, Clave.

Tabla 8.1.5. Atributos identificados para las clases identificadas en el sistema de Correspondencia.

8.1.9 Diagrama de Clases con Atributos


Práctica UCPR-IST


Se extiende el diagrama de clases con asociaciones, roles y multiplicidad, para incluir los atributos principales, como se muestra en la Figura 8.1.15.

Figura 8.1.15. Diagrama de clases con asociaciones, roles, multiplicidad y atributos para clases identificadas.

8.1.10 Diccionario de Clases

Oficios

Codigo_Oficio <PK>

Numero_Oficio

Fecha_Oficio

Objeto_Referencia

Entidad_Persona


Codigo_Despacho <PK>

Destinatario

Seccion_Persona

Codigo_Oficio <FK>

Codigo_Ciudad <FK>

Codigo_Seccion <FK>

Codigo_Archivo <FK>


Codigo_Recibo <PK>

Remitente

Fecha_Recibido

Fecha_Radicado

Direccion

Telefono

Codigo_Oficio <FK>

Codigo_Seccion <FK>

Codigo_Ciudad <FK>

Codigo_Archivo <FK>

Ciudad

Codigo_Ciudad <PK>

Departamento

MunicipioArchivo

Codigo_Archivo <PK>

Legajo

Folio

Caja

Fecha_Inicial

Fecha_Final

Codigo_Seccion <FK>

Codigo_Ciudad <FK>

Clave <FK>

Seccion

Codigo_Seccion <PK>

Subseccion

Serie

Subserie

Usuario

Clave <PK>

Nombre

RecibeDespacha

Almacenar

Guardar

Para Ingresar

Tiene

posee

CORRESPONDENCIA CENTRO DE ACOPIO

REGISTRADURIA NACIONAL DEL ESTADO CIVIL

DELEGACION DEPARTAMENTAL DEL RISARALDA

CENTRO DE ACOPIO


Practicante

UNIVERSIDAD CATOLICA POPULAR DEL RISARALDA

FACULTAD DE CIENCIAS BASICAS E INGENIERIA

PROGRAMA INGENIERIA DE SISTEMAS Y TELECOMUNICACIONES

PEREIRA - 2009

Registra

Pertenece

ContieneHay


Práctica UCPR-IST


Correspondencia_Despachada: Se denomina por medio de un número. Tiene asociado un Oficio, que es archivado en un Legajo y una caja. Pertenece a una ciudad determinada y a una sección de trabajo. Correspondencia_Recibido: Se denomina por medio de un número. Tiene asociado un Oficio, que es archivado en un Legajo y una caja. Pertenece a una ciudad determinada y a una sección de trabajo. Oficios: Es el documento el cual es enviado o recibido y posteriormente es archivado. Archivo: Es donde se almacenan todos los oficios por medio de legajos que van en diferentes cajas. Sección: Un oficio pertenece a una sección, el archivo puede ser de diferentes secciones, y una sección es la ubicación en un área de trabajo determinado en este caso sería el centro de acopio. Usuario: Es la persona encargada de archivar la correspondencia, y la persona autorizada para manejar el sistema de correspondencia. Ciudad: Los oficios, la secciones y el archivo pueden estar o venir de cualquier ciudad de Colombia.

8.1.11 Dominio del Problema para el Sistema de Correspondencia.

Para el sistema de correspondencia podemos identificar un módulo principal para el dominio del problema de acuerdo a la relación lógica entre las clases. Este módulo es Archivo, conteniendo las clases que guardan información sobre el usuario del sistema, la correspondencia despachada o recibida. En otras palabras, la clase para el módulo de archivo se relaciona con la utilización del sistema ligado al actor Base de Datos de Correspondencia. Archivo


Práctica UCPR-IST


En la Figura 8.1.16. Se muestra las clases pertenecientes al módulo de Archivo del sistema de correspondencia.

Figura 8.1.16. Diagrama de clases para el módulo de Archivo del sistema de Correspondencia.


Práctica UCPR-IST


8.2 MODELO DE ANÁLISIS Cuando ya se ha desarrollado y aceptado el modelo de requisitos se comienza el desarrollo del modelo de análisis. El objetivo del modelo de análisis es comprender y generar una arquitectura de objetos para el sistema en base a lo especificado en el modelo de requisitos. Durante esta etapa no se considera el ambiente de implementación, lo cual incluye al lenguaje de programación, manejador de base de datos, distribución del hardware, etc. [2]

8.2.1 Clases para Casos de Uso En el sistema de correspondencia, cada uno de los actores concretos, Usuario, Base de Datos de Correspondencia, necesita su propio objeto borde al sistema, como se muestra en la Figura 8.2. 1. El Usuario necesita de las pantallas de presentación, mientras que la Base de Datos de correspondencia necesita sus propias bordes para poder intercambiar información con el sistema.

Figura 8.2.1. Clases borde para el sistema de correspondencia identificada directamente de los actores.

Validar Usuario: Se interactúa con los actores Usuario y Base de Datos Correspondencia a través de las clases borde InterfaceUsuario e InterfaceBaseDatosCorrespondencia, respectivamente. Se utiliza únicamente la

Usuario

Interface

Usuario

Interface Base de

Datos

Correspondencia

Base de Datos

Correspondencia


Práctica UCPR-IST


pantalla validación del sistema (P-1) para la validación de usuario. Por lo tanto se incluye únicamente la clase borde PantallaValidacion además de las dos anteriores. Recuérdese que pantallas adicionales como las de mensajes o error no las estamos considerando aún para nuestro prototipo. En la Figura 8.2. 2 se muestran las clases borde identificadas en este caso de uso.

Figura 8.2.2. Clases borde identificadas del caso uso Validar Usuario.

Ofrecer Servicios: Este caso de uso utiliza únicamente la pantalla de menú servicios del sistema (P-2). Por lo tanto se incluye únicamente la clase borde PantallaMenuServicio. Dado que se interactúa con el actor Usuario se incluye también la clase borde InterfaceUsuario. En la Figura 8.2. 3 se muestran las clases borde identificadas en este caso de uso.

Figura 8.2.3. Clases borde identificadas del caso uso Ofrecer Servicios.

Correspondencia Despachada: Se interactúa con los actores Usuario y Base de Datos Correspondencia a través de las clases borde InterfaceUsuario e InterfaceBaseDatosCorrespondencia, respectivamente. Se utilizan las pantallas de menú de servicios (P-2), ingreso de información de la correspondencia despachada (P-3). En la Figura 8.2. 4 se muestran las clases borde identificadas en este caso de uso.

InterfaceUsuario

InterfaceBaseDatosCorrespondencia

PantallaValidacion

InterfaceUsuario

PantallaMenuServicios


Práctica UCPR-IST


Figura 8.2.4. Clases borde identificadas del caso uso Correspondencia Despachada.

Correspondencia Recibida: Se interactúa con los actores Usuario y Base de Datos Correspondencia a través de las clases borde InterfaceUsuario e InterfaceBaseDatosCorrespondencia, respectivamente. Se utilizan las pantallas de menú de servicios (P-2), ingreso de información de la correspondencia recibida (P-4). En la Figura 8.2. 5 se muestran las clases borde identificadas en este caso de uso.

Figura 8.2.5. Clases borde identificadas del caso uso Correspondencia Recibida.

Búsqueda de Correspondencia: Se interactúa con los actores Usuario y Base de Datos Correspondencia a través de las clases borde InterfaceUsuario e InterfaceBaseDatosCorrespondencia, respectivamente. Adicionalmente se deben incluir clases borde correspondientes a las pantallas propias de este

InterfaceUsuario

PantallaCorrespondenciaDespachada

InterfaceUsuario

PantallaCorrespondenciaDespachada

InterfaceMenuServicios





Práctica UCPR-IST


caso de uso, que son la pantalla de menú de servicios (P-2), búsqueda de correspondencia (P-5), pantalla de correspondencia encontrada (P-6). A las clases borde correspondientes las llamaremos PantallaBusquedaCorrespondencia, PantallaCorrespondenciaEncontrada, respectivamente. En la Figura 8.2. 6. Se muestran las clases borde identificadas en este caso de uso.

Figura 8.2. 6. Clases borde identificadas del caso uso Búsqueda de Correspondencia.

Informes de Correspondencia: Se interactúa con los actores Usuario y Base de Datos Correspondencia a través de las clases borde InterfaceUsuario e InterfaceBaseDatosCorrespondencia, respectivamente. Adicionalmente se deben incluir clases borde correspondientes a las pantallas propias de este caso de uso, que son las pantallas de menú de servicios (P-2), informes de correspondencia (P-7). A la clase borde correspondiente la llamaremos PantallaInformesCorrespondencia, PantallaCorrespondenciaEncontrada, respectivamente. En la Figura 8.2.7. Se muestran las clases borde identificadas en este caso de uso.

InterfaceUsuario

PantallaBusquedaCorrespondencia


PantallaCorrespondenciaEncontrada



Práctica UCPR-IST


Figura 8.2. 7. Clases borde identificadas del caso uso Informes de Correspondencia.

Manual Usuario: Se interactúa con el actor Usuario a través de las clases borde InterfaceUsuario, respectivamente. Se utilizan las pantallas de menú de servicios de correspondencia (P-2) y la de de manual de usuario (P-8). En la Figura 8.2.8 se muestran las clases borde identificadas en este caso de uso.

Figura 8.2.8 Clases borde identificadas del caso uso Manual de Usuario.

En la Tabla 8.2.1. Se muestran el resumen los casos de uso identificados durante el modelo de requisitos junto con los actores y clases borde correspondientes.

Casos de Uso

Actores

Clases Borde

InterfaceUsuario

PantallaInformesCorrespondencia



InterfaceUsuario


PantallaManualUsuario


Práctica UCPR-IST


Validar Usuario

Usuario, Base de Datos Correspondencia

InterfaceUsuario, PantallaValidacion, InterfaceBaseDatosCorrespondencia

Ofrecer Servicios

Usuario InterfaceUsuario, PantallaMenuServicios



InterfaceUsuario, PantallaMenuServicios, PantallaCorrespondenciaDespachada, InterfaceBaseDatosCorrespondencia



InterfaceUsuario, PantallaMenuServicios, PantallaCorrespondenciaRecibida, InterfaceBaseDatosCorrespondencia

Búsqueda Correspondencia


InterfaceUsuario, PantallaMenuServicios, PantallaBusquedaCorrespondencia, PantallaCorrespondenciaEncontrada, InterfaceBaseDatosCorrespondencia



InterfaceUsuario, PantallaMenuServicios, PantallaInformesCorrespondencia, InterfaceBaseDatosCorrespondencia

Manual de usuario

Usuario InterfaceUsuario, PantallaMenuServicios, PantallaManualUsuario.

Tabla 8.2.1. Relación entre casos de uso, actores y clases borde para el sistema de correspondencia.

Entidad


Práctica UCPR-IST


Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. La información a corto plazo existe por lo general durante la ejecución del caso de uso, mientras que la información a largo plazo sobrevive a los casos de uso, por lo cual es necesario guardar esta información en alguna base de datos. Adicionalmente, se debe incluir comportamiento para manejar la propia información local al objeto entidad. [2]

Validar Usuario: Este caso de uso requiere validar información exclusivamente guardada en el registro de usuario, lo que se hace en la clase entidad RegistroUsuario. En la Figura 8.2.9. Se muestran las clases entidad identificadas en este caso de uso.

Figura 8.2. 9. Clases entidad identificadas del caso uso Validar Usuario.

Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad.

Correspondencia Despachada: Este caso de uso requiere guardar información exclusivamente de la correspondencia despachada, lo que se hace en la clase entidad CorrespondenciaDespachada. En la Figura 8.2.10. Se muestran las clases entidad identificadas en este caso de uso.

Figura 8.2. 10. Clases entidad identificadas del caso uso Correspondencia Despachada.

RegistroUsuario

RegistroCorrespondenicaDespachada


Práctica UCPR-IST


Correspondencia Recibida: Este caso de uso requiere guardar información exclusivamente de la correspondencia Recibida, lo que se hace en la clase entidad CorrespondenciaRecibida. En la Figura 8.2.10. Se muestran las clases entidad identificadas en este caso de uso.

Figura 8.2. 11. Clases entidad identificadas del caso uso Correspondencia Recibida.

Búsqueda de Correspondencia: Este caso de uso requiere de toda la información relacionada con consultas. Se tiene las clases entidad Archivo, Correspondencia Despachada, Correspondencia Recibida, Sección, Usuario, Ciudad. En la Figura 8.2. 12. Se muestran las clases entidad identificadas en este caso de uso.

Figura 8.2. 12. Clases entidad identificadas del caso uso Búsqueda de Correspondencia.

RegistroCorrespondenicaRecibida

Archivo Correspondencia Despachada Correspondencia Recibida

Sección Usuario Ciudad Oficio


Práctica UCPR-IST


Informes de Correspondencia: Este caso de uso requiere de toda la información relacionada con consultas. Se tiene las clases entidad Archivo, Correspondencia Despachada, Correspondencia Recibida, Sección, Usuario, Ciudad. En la Figura 8.2. 13. Se muestran las clases entidad identificadas en este caso de uso.

Figura 8.2. 13. Clases entidad identificadas del caso uso Informes de Correspondencia.

Manual Usuario: Este caso de uso requiere el registro de usuario, lo que se hace en la clase entidad RegistroUsuario. En la Figura 8.2.14. Se muestran las clases entidad identificadas en este caso de uso.

Figura 8.2.14. Clases entidad identificadas del caso uso Manual Usuario.



RegistroUsuario


Práctica UCPR-IST


En la Tabla 8.2. 2. Se muestran el resumen de los casos de uso identificados durante el modelo de requisitos junto con clases entidades correspondientes.

Casos de Uso

Clases Entidad

Validar Usuario RegistroUsuario

Ofrecer Servicios


RegistroCorrespondenciaDespachada


RegistroCorrespondenciaRecibida

Búsqueda de Información

CorrespondenciaDespachada, Archivo, CorrespondenciaRecibida, Sección, Usuario, Ciudad, Oficio.


CorrespondenciaDespachada, Archivo, CorrespondenciaRecibida, Sección, Usuario, Ciudad, Oficio.

Manual Usuario

Tabla 8.2.2. Relación entre casos de uso y clases entidad para el sistema de correspondencia.

Control Hasta ahora se han identificado partido objetos borde y entidad a partir de cada caso de uso. En algunas situaciones todo un caso de uso pudiera implementarse exclusivamente mediante estos dos tipos de objetos. De tal manera no se necesitaría ningún objeto control para el respectivo caso de uso. Sin embargo, en la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos, ya que realmente no pertenece de manera natural a ninguno de ellos. [2]

Validar Usuario: Este caso de uso requiere un controlador para manejar la validación del registro de usuario. Dado que esto utiliza la misma información de registro podemos como enfoque inicial utilizar la misma clase control, por lo cual utilizamos la clase control ManejadorRegistroUsuario. En la Figura 8.2. 15. Se muestra la clase control para este caso de uso.


Práctica UCPR-IST


Figura 8.2. 15. Clase control para el caso uso Validar Usuario.

Ofrecer Servicios: Este caso de uso requiere un controlador para administrar los aspectos generales de los servicios. Como enfoque inicial utilizar utilizaremos una clase general de control que llamaremos ManejadorMenuServicio. En la Figura 8.2. 16. Se muestra la clase control para este caso de uso.

Figura 8.2. 16. Clase control para el caso uso Ofrecer Servicios.

Correspondencia Despachada: Este caso de uso requiere un controlador para manejar la correspondencia despachada. Como enfoque inicial utilizar utilizaremos una clase general de control que llamaremos ManejadorDespachada. En la Figura 8.2. 17. Se muestra la clase control para este caso de uso.

Figura 8.2. 17. Clase control para el caso uso Correspondencia Despachada.

ManejadorRegistroUsuario

ManejadorMenuServicios

ManejadorDespachada


Práctica UCPR-IST


Correspondencia Recibida: Este caso de uso requiere un controlador para manejar la correspondencia recibida. Como enfoque inicial utilizar utilizaremos una clase general de control que llamaremos ManejadorRecibida. En la Figura 8.2. 18. Se muestra la clase control para este caso de uso.

Figura 8.2. 18. Clase control para el caso uso Correspondencia Recibida.

Búsqueda de información: Este caso de uso requiere de un controlador para manejar la información y las bordes relacionadas con las consultas, lo que se hace en la clase control ManejadorBusqueda. En la Figura 8.2. 19. Se muestran las clases control identificadas en este caso de uso.

Figura 8.2. 19. Clase control para el caso uso Búsqueda de Información.

Informes Correspondencia: Este caso de uso requiere de un controlador para manejar la información y las bordes relacionadas con generar informes, lo que se hace en la clase control ManejadorInformes. En la Figura 8.2. 20. Se muestran las clases control identificadas en este caso de uso.

Figura 8.2. 20. Clase control para el caso uso Informes Correspondencia.

ManejadorBusqueda

ManejadorInformes

ManejadorRecibida


Práctica UCPR-IST


Manual de Usuario: Este caso de uso requiere un controlador para administrar los aspectos generales del manual de usuario. Como enfoque inicial utilizar utilizaremos una clase general de control que llamaremos ManejadorManual. En la Figura 8.2. 21. Se muestra la clase control para este caso de uso.

Figura 8.2. 21. Clase control para el caso uso Manual de Usuario.

En la Tabla 8.2. 3. Se muestran el resumen de los casos de uso identificados durante el modelo de requisitos junto con clases control correspondiente.

Casos de Uso

Clases Control

Validar Usuario ManejadorRegistroUsuario

Ofrecer Servicios

ManejadorMenuServicios


ManejadorDespachada


ManejadorRecibida

Búsqueda de Información

ManejadorBusqueda


ManejadorInformes

Manual Usuario ManejadorManual

Tabla 8.2.3. Relación entre casos de uso y clases control para el sistema de correspondencia.

8.2.3 Clases según Casos de Uso

En esta sección se mostrara un diagrama de clases para cada caso de uso de acuerdo a las clases identificadas en la sección anterior. En estos diagramas incluiremos de manera preliminar asociaciones y multiplicidad. Para simplificar este proceso de asignación de asociaciones y para ser consistentes entre diagramas, asignaremos a la clase control de cada caso de uso como el “centro

ManejadorManual


Práctica UCPR-IST


de las comunicaciones” para todas las clases borde y entidad pertenecientes al mismo caso de uso. Estas clases borde y entidad no estarán asociadas entre sí por el momento. [2] Validar Usuario El caso de uso Validar Usuario involucra una clase control ManejadorRegistroUsuario que es encargada de controlar la información de RegistroUsuario y las clases borde InterfaceUsuario e InterfaceBaseDatosCorrespondencia. Agregamos también la clase PantallaValidacion por recibir la información de registro a ser validada y al ManejadorValidacion por ser el controlador de la pantalla anterior. En la Figura 8.2. 22 se muestran las clases identificadas en este caso de uso.

Figura 8.2. 22. Clases identificadas para el caso uso Validar Usuario.

Ofrecer Servicios El caso de uso Ofrecer Servicios involucra una clase control ManejadorMenuServicios que es encargada de controlar la pantalla PantallaMenuServicio. Agregamos también la clase borde InterfaceUsuario. En la Figura 8.2. 23 se muestran las clases identificadas en este caso de uso.

InterfaceUsuario PantallaValidacion ManejadorValidacion

InterfaceBaseDatosCorrespondencia ManejadorRegistroUsuario RegistroUsuario


Práctica UCPR-IST


Figura 8.2. 23 Clases identificadas para el caso uso Ofrecer Servicios.

Correspondencia Despachada El caso de uso Correspondencia Despachada involucra una clase control ManejadorDespachada que es encargada de controlar la información del RegistroCorrespondenciaDespachada y las clases borde correspondiente a las pantallas PantallaCorrespondenciaDespachada además de las clases borde InterfaceUsuario e InterfaceBaseDatosCorrespondencia. En la Figura 8.2. 24 se muestran las clases identificadas en este caso de uso.

Figura 8.2. 24. Clases identificadas para el caso uso Correspondencia Despachada.

InterfaceUsuario PantallaMenuServicio ManejadorMenuServicios

InterfaceUsuario PantallaCorrespondenciaDespachada


ManejadorDespachada

RegistroCorrespondenicaDespachada


Práctica UCPR-IST


Correspondencia Recibida El caso de uso Correspondencia Recibida involucra una clase control ManejadorRecibida que es encargada de controlar la información del RegistroCorrespondenciaRecibida y las clases borde correspondiente a las pantallas PantallaCorrespondenciaRecibida además de las clases borde InterfaceUsuario e InterfaceBaseDatosCorrespondencia. En la Figura 8.2. 25 se muestran las clases identificadas en este caso de uso.

Figura 8.2. 25. Clases identificadas para el caso uso Correspondencia Recibida.

Búsqueda de Correspondencia El caso de uso Búsqueda de Correspondencia involucra una clase control ManejadorBusqueda que es encargada de controlar los diferentes tipos de consultas junto con la clase borde correspondiente a la pantalla PantallaBusquedaCorrespondencia, además de las clases borde InterfaceUsuario e InterfaceBaseDatosCorrespondencia. Dado que este caso de uso tiene un subflujo importante, que es la PantallaCorrespondenciaEncontrada. En la Figura 8.2. 26 se muestran las clases principales identificadas en este caso de uso.

InterfaceUsuario PantallaCorrespondenciaRecibida


ManejadorRecibida

RegistroCorrespondenicaRecibida


Práctica UCPR-IST


Figura 8.2. 26. Clases identificadas para el caso uso Búsqueda de Correspondencia.

InterfaceUsuario PantallaBusquedaCorrespondencia

PantallaCorrespondenciaEncontrada InterfaceBaseDatosCorrespondencia

ManejadorBusqueda




Práctica UCPR-IST


Informes Correspondencia El caso de uso Informes Correspondencia involucra una clase control ManejadorInformes que es encargada de controlar la generación de informes junto con las clases bordes correspondiente a la pantalla PantallaInformesCorrespondencia, además de las clases borde InterfaceUsuario e InterfaceBaseDatosCorrespondencia. Se incluyen en el diagrama todas las clases entidad necesarias, que son Archivo, Correspondencia Despachada, Correspondencia Recibida, Sección, Usuario, Ciudad. En la Figura 8.2. 27. Se muestran las clases identificadas en este caso de uso.

Figura 8.2. 27 Clases identificadas para el caso uso Informes Correspondencia.

ManejadorInformes InterfaceUsuario InterfaceBaseDatosCorrespondencia

PantallaInformesCorrespondencia PantallaInformesCorrespondencia




Práctica UCPR-IST


Manual de Usuario El caso de uso Manual de Usuario involucra una clase control ManejadorManual que es encargada de controlar la información de RegistroManual y las clases borde InterfaceUsuario. En la Figura 8.2. 28. Se muestran las clases identificadas en este caso de uso.

Figura 8.2. 28. Clases identificadas para el caso uso Manual de Usuario.

Diagramas de Secuencias Una vez identificadas las clases anteriores, proseguimos describiendo los casos de uso del modelo de requisitos según la lógica que deberán presentar estas clases para lograr la funcionalidad descrita en los diversos casos de uso. Este es un paso muy importante ya que en base a la lógica propuesta para esta descripción, definiremos la arquitectura de análisis tanto estructural como funcional. [2] Validar Usuario El diagrama de secuencia Validar Usuario se muestra en el diagrama de la Figura 8.2. 29. Esta secuencia inicia en el flujo principal de Registro Usuario que hace la validación definida en Validar Usuario. Validar Usuario. Nuevamente, aunque la secuencia se inicia en el flujo principal de Registrar Usuario, se continúa inmediatamente con la inserción del caso de uso Validar Usuario, donde podemos iniciar con el ManejadorValidacion enviando el evento desplegarPantallaValidacion a la InterfaceUsuario, el cual despliega la PantallaValidacionl. En este momento el usuario debe validarse, insertando su nombre y contraseña. Al ser datos, estos no generan ningún evento. Una vez el usuario genere el evento “OK” oprimiendo el botón correspondiente, se instancia la validación. La InterfaceUsuario envía el mismo evento al

InterfaceUsuario ManejadorManual RegistroManual


Práctica UCPR-IST


ManejadorValidacion. El Manejadorvalidacion reconoce que este evento corresponde a una actividad de registro y envía el evento validarRegistroUsuario al ManejadorRegistroUsuario. Este controlador reconoce el tipo de evento particular y solicita a la InterfaceBaseDatosCorrespondencia que haga una validación del usuario mediante un evento adicional con el mismo nombre. La InterfaceBaseDatosCorrespondencia envía a su vez un evento similar al actor Base de Datos Correspondencia, el cual contesta con un OK si la validación es buena. Dado que sólo consideramos una secuencia de eventos, una validación incorrecta se mostraría en otro diagrama. El OK es sucesivamente enviado a la InterfaceBaseDatosCorrespondencia, de allí a ManejadorRegistroUsuario y luego a ManejadorValidacion como respuesta a las secuencias de validación. Una vez el ManejadorValidacion recibió este último OK.

Figura 8.2.29. Diagrama de secuencia Validación Usuario del caso de uso Validar Usuario.

Usuario InterfaceUsuario


ManejadorValidacion


Base de Datos

Correspondencia

1 Desplegar Pantalla validación

2 “OK”

3 “OK”

4 Validar Reg Usuario



7 “OK”

8 “OK”

9 “OK”


Práctica UCPR-IST



Guardar Información

El diagrama de secuencia para el subflujo Guardar Información se muestra en el Figura 8.2. 30. Se guarda información siguiendo el flujo principal de Ofrecer Servicios en lugar del subflujo Correspondencia Despachada (S-1). Dentro del caso de uso Ofrecer Servicios se continuará con los subflujos Correspondencia Despachada (S-1). Validar Usuario. La secuencia comienza con la validación del usuario a partir del evento desplegarPantallaValidacion de la clase ManejadorValidacion a la InterfaceUsuario. El usuario se valida enviando el evento “OK“. La InterfaceUsuario envía el mismo evento al ManejadorValidacion. El ManejadorValidacion envía el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosCorrespondencia que haga una validación del usuario mediante el mismo evento. La InterfaceBaseDatosCorrespondencia envía a su vez el evento a la Base de Datos Correspondencia, el cual contesta con un OK si la validación es buena. El OK es enviado a la InterfaceBaseDatosCorrespondencia, de allí al ManejadorRegistroUsuario y luego al ManejadorValidacion como respuesta a las secuencias de validación. Una vez el ManejadorValidacion recibió este último OK, solicita al ManejadorMenuServicio que entre en acción mediante el evento ofrecerServicios. Ofrecer Servicios. A continuación podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorMenuServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaMenuServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lógica principal de este subflujo, el usuario debe presionar “Correspondencia Despachada“. Correspondencia Despachada subflujo principal. Siguiendo con la lógica, la InterfaceUsuario envía el mismo evento al ManejadorRegistroUsuario, el cual solicita CorrrespondenciaDespachada al ManejadorDespachada. Correspondencia Despachada subflujo Obtener Correspondencia Despachada. El ManejadorDespachada que es responsable de todo lo relacionado con el registro de tarjeta, solicita obtenerCorrespondenciaDespachada a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia envía el mismo evento al actor Base de Datos Correspondencia. Este actor responde mediante un NULL correspondiente a un registro de Correspondencia inexistente. Este evento es enviado de regreso al ManejadorDespachada.


Práctica UCPR-IST


Guarda Información subflujo Correspondencia Despachada (S-1). A continuación, el ManejadorDespachada solicita desplegarPantallaCorrespondenciaDespachada a InterfaceUsuario. El usuario ingresa los datos de Correspondencia Despachada y presiona el botón de “Guardar” generando el evento Guardar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorDespachada el cual envía el evento GuardarCorrespondenciaDespachada a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorDespachada. A continuación, el ManejadorDespachada envía el evento desplegarPantallaCorrespondenciaDespachada a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia. En resumen, la secuencia podrá iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Correspondencia Despachada y finalmente el flujo principal de Correspondencia Despachada seguido por los subflujos Guardar Información (S-1)


Práctica UCPR-IST


Figura 8.2. 30. Diagrama de secuencia Guardar Información del caso de uso Correspondencia Despachada.



ManejadorValidacion

IterfaceBDCorrespondencia

BD

Correspondencia

ManejadorDespachada

ManejadorMenuServicio

1 Despliegue de pantalla validar

2 “OK” 3 “OK”

4 Validar registro de Usuario


6

Validar

registro de

Usuario

7 “OK” 8 “OK”

9 “OK”

10 ofrecer

servicios 11 Despliegue de pantalla Menú Servicio

12

Correspondencia

Despachada

13 Correspondencia

Despachada

14 Correspondencia

Despachada 15 Obtener Correspondencia

Despachada

16

O.C.D.

17 Null 18 Null 19 Despliegue de pantalla

Correspondencia

Despachada

20 “Guardar”

21 “Guardar” 22 “Guardar” Correspondencia Despachada

23

G.C.D

24 “OK”

25 “OK”

27 Despliegue de pantalla

Correspondencia

Despachada

21 “Salir”


Práctica UCPR-IST



Modificar Información

El diagrama de secuencia para el subflujo Modificar Información se muestra en el Figura 8.2. 31. Se guarda información siguiendo el flujo principal de Ofrecer Servicios en lugar del subflujo Correspondencia Despachada (S-1). Dentro del caso de uso Ofrecer Servicios se continuará con los subflujos Correspondencia Despachada (S-1). Validar Usuario. La secuencia comienza con la validación del usuario a partir del evento desplegarPantallaValidacion de la clase ManejadorValidacion a la InterfaceUsuario. El usuario se valida enviando el evento “OK“. La InterfaceUsuario envía el mismo evento al ManejadorValidacion. El ManejadorValidacion envía el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosCorrespondencia que haga una validación del usuario mediante el mismo evento. La InterfaceBaseDatosCorrespondencia envía a su vez el evento a la Base de Datos Correspondencia, el cual contesta con un OK si la validación es buena. El OK es enviado a la InterfaceBaseDatosCorrespondencia, de allí al ManejadorRegistroUsuario y luego al ManejadorValidacion como respuesta a las secuencias de validación. Una vez el ManejadorValidacion recibió este último OK, solicita al ManejadorMenuServicio que entre en acción mediante el evento ofrecerServicios. Ofrecer Servicios. A continuación podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorMenuServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaMenuServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lógica principal de este subflujo, el usuario debe presionar “Correspondencia Despachada“. Correspondencia Despachada subflujo principal. Siguiendo con la lógica, la InterfaceUsuario envía el mismo evento al ManejadorRegistroUsuario, el cual solicita CorrrespondenciaDespachada al ManejadorDespachada. Correspondencia Despachada subflujo Obtener Correspondencia Despachada. El ManejadorDespachada que es responsable de todo lo relacionado con el registro de tarjeta, solicita obtenerCorrespondenciaDespachada a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia envía el mismo evento al actor Base de Datos Correspondencia. Este actor responde mediante un NULL correspondiente a un registro de Correspondencia inexistente. Este evento es enviado de regreso al ManejadorDespachada.


Práctica UCPR-IST


Modificar Información subflujo Correspondencia Despachada (S-1). A continuación, el ManejadorDespachada solicita desplegarPantallaCorrespondenciaDespachada a InterfaceUsuario. El usuario ingresa los datos a modificar de la Correspondencia Despachada y presiona el botón de “Modificar” generando el evento Modificar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorDespachada el cual envía el evento ModificarCorrespondenciaDespachada a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorDespachada. A continuación, el ManejadorDespachada envía el evento desplegarPantallaCorrespondenciaDespachada a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia. En resumen, la secuencia podrá iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Correspondencia Despachada y finalmente el flujo principal de Correspondencia Despachada seguido por los subflujos Modificar Información (S-1).


Práctica UCPR-IST


Figura 8.2. 31. Diagrama de secuencia Modificar Información del caso de uso Correspondencia Despachada.


2 “OK” 3 “OK”



6

Validar

registro de

Usuario

7 “OK” 8 “OK”

9 “OK”

10 ofrecer

servicios 11 Despliegue de pantalla Menú Servicios

12

Correspondencia

Despachada

13 Correspondencia

Despachada

14 Correspondencia


Despachada

16

O.C.D.


Correspondencia

Despachada

20 “Modificar”

21 “Modificar” 22 “Modificar” Correspondencia Despachada

23

G.C.D

24 “OK”

25 “OK”


Correspondencia

Despachada

21 “Salir”



ManejadorValidacion


BD

Correspondencia

ManejadorDespachada



Práctica UCPR-IST



Eliminar Información

El diagrama de secuencia para el subflujo Eliminar Información se muestra en el Figura 8.2. 32. Se guarda información siguiendo el flujo principal de Ofrecer Servicios en lugar del subflujo Correspondencia Despachada (S-1). Dentro del caso de uso Ofrecer Servicios se continuará con los subflujos Correspondencia Despachada (S-1). Validar Usuario. La secuencia comienza con la validación del usuario a partir del evento desplegarPantallaValidacion de la clase ManejadorValidacion a la InterfaceUsuario. El usuario se valida enviando el evento “OK“. La InterfaceUsuario envía el mismo evento al ManejadorValidacion. El ManejadorValidacion envía el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosCorrespondencia que haga una validación del usuario mediante el mismo evento. La InterfaceBaseDatosCorrespondencia envía a su vez el evento a la Base de Datos Correspondencia, el cual contesta con un OK si la validación es buena. El OK es enviado a la InterfaceBaseDatosCorrespondencia, de allí al ManejadorRegistroUsuario y luego al ManejadorValidacion como respuesta a las secuencias de validación. Una vez el ManejadorValidacion recibió este último OK, solicita al ManejadorMenuServicio que entre en acción mediante el evento ofrecerServicios. Ofrecer Servicios. A continuación podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorMenuServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaMenuServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lógica principal de este subflujo, el usuario debe presionar “Correspondencia Despachada“. Correspondencia Despachada subflujo principal. Siguiendo con la lógica, la InterfaceUsuario envía el mismo evento al ManejadorRegistroUsuario, el cual solicita CorrrespondenciaDespachada al ManejadorDespachada. Correspondencia Despachada subflujo Obtener Correspondencia Despachada. El ManejadorDespachada que es responsable de todo lo relacionado con el registro de tarjeta, solicita obtenerCorrespondenciaDespachada a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia envía el mismo evento al actor Base de Datos Correspondencia. Este actor responde mediante un NULL correspondiente a un registro de Correspondencia inexistente. Este evento es enviado de regreso al ManejadorDespachada.


Práctica UCPR-IST


Eliminar Información subflujo Correspondencia Despachada (S-1). A continuación, el ManejadorDespachada solicita desplegarPantallaCorrespondenciaDespachada a InterfaceUsuario. El usuario ingresa los datos para eliminar de la Correspondencia Despachada y presiona el botón de “Eliminar” generando el evento Eliminar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorDespachada el cual envía el evento EliminarCorrespondenciaDespachada a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorDespachada. A continuación, el ManejadorDespachada envía el evento desplegarPantallaCorrespondenciaDespachada a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia. En resumen, la secuencia podrá iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Correspondencia Despachada y finalmente el flujo principal de Correspondencia Despachada seguido por los subflujos Modificar Información (S-1).


Práctica UCPR-IST


Figura 8.2. 32. Diagrama de secuencia Eliminar Información del caso de uso Correspondencia Despachada.


2 “OK” 3 “OK”



6

Validar

registro de

Usuario

7 “OK” 8 “OK”

9 “OK”

10 ofrecer


12

Correspondencia

Despachada

13 Correspondencia

Despachada

14 Correspondencia


Despachada

16

O.C.D.


Correspondencia

Despachada

20 “Eliminar”

21 “Eliminar” 22 “Eliminar” Correspondencia Despachada

23

G.C.D

24 “OK”

25 “OK”


Correspondencia

Despachada

21 “Salir”



ManejadorValidacion


BD

Correspondencia

ManejadorDespachada



Práctica UCPR-IST



Guardar Información

El diagrama de secuencia para el subflujo Guardar Información se muestra en el Figura 8.2. 33. Se guarda información siguiendo el flujo principal de Ofrecer Servicios en lugar del subflujo Correspondencia Recibida (S-1). Dentro del caso de uso Ofrecer Servicios se continuará con los subflujos Correspondencia Recibida (S-1). Validar Usuario. La secuencia comienza con la validación del usuario a partir del evento desplegarPantallaValidacion de la clase ManejadorValidacion a la InterfaceUsuario. El usuario se valida enviando el evento “OK“. La InterfaceUsuario envía el mismo evento al ManejadorValidacion. El ManejadorValidacion envía el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosCorrespondencia que haga una validación del usuario mediante el mismo evento. La InterfaceBaseDatosCorrespondencia envía a su vez el evento a la Base de Datos Correspondencia, el cual contesta con un OK si la validación es buena. El OK es enviado a la InterfaceBaseDatosCorrespondencia, de allí al ManejadorRegistroUsuario y luego al ManejadorValidacion como respuesta a las secuencias de validación. Una vez el ManejadorValidacion recibió este último OK, solicita al ManejadorMenuServicio que entre en acción mediante el evento ofrecerServicios. Ofrecer Servicios. A continuación podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorMenuServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaMenuServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lógica principal de este subflujo, el usuario debe presionar “Correspondencia Recibida“. Correspondencia Recibida subflujo principal. Siguiendo con la lógica, la InterfaceUsuario envía el mismo evento al ManejadorRegistroUsuario, el cual solicita CorrrespondenciaRecibida al ManejadorRecibida. Correspondencia Recibida subflujo Obtener Correspondencia Recibida. El ManejadorRecibida que es responsable de todo lo relacionado con el registro de tarjeta, solicita obtenerCorrespondenciaRecibida a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia envía el mismo evento al actor Base de Datos Correspondencia. Este actor responde mediante un NULL correspondiente a un registro de Correspondencia inexistente. Este evento es enviado de regreso al ManejadorRecibida. Guarda Información subflujo Correspondencia Recibida (S-1). A continuación, el ManejadorRecibida solicita desplegarPantallaCorrespondenciaRecibida a


Práctica UCPR-IST


InterfaceUsuario. El usuario ingresa los datos de Correspondencia Recibida y presiona el botón de “Guardar” generando el evento Guardar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorRecibida el cual envía el evento GuardarCorrespondenciaRecibida a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorRecibida. A continuación, el ManejadorRecibida envía el evento desplegarPantallaCorrespondenciaRecibida a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia. En resumen, la secuencia podrá iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Correspondencia Recibida y finalmente el flujo principal de Correspondencia Recibida seguido por los subflujos Guardar Información (S-1).


Práctica UCPR-IST


Figura 8.2. 33. Diagrama de secuencia Guardar Información del caso de uso Correspondencia Recibida.


2 “OK” 3 “OK”



6

Validar

registro de

Usuario

7 “OK” 8 “OK”

9 “OK”

10 ofrecer


12

Correspondencia

Recibida

13 Correspondencia

Recibida

14 Correspondencia

Recibida 15 Obtener Correspondencia

Recibida

16

O.C.R.



20 “Guardar”

21 “Guardar” 22 “Guardar” Correspondencia Recibida

23

G.C.R

24 “OK”

25 “OK”



21 “Salir”



ManejadorValidacion


BD

Correspondencia

ManejadorRecibida



Práctica UCPR-IST



Modificar Información

El diagrama de secuencia para el subflujo Modificar Información se muestra en el Figura 8.2. 34. Se guarda información siguiendo el flujo principal de Ofrecer Servicios en lugar del subflujo Correspondencia Recibida (S-1). Dentro del caso de uso Ofrecer Servicios se continuará con los subflujos Correspondencia Recibida (S-1). Validar Usuario. La secuencia comienza con la validación del usuario a partir del evento desplegarPantallaValidacion de la clase ManejadorValidacion a la InterfaceUsuario. El usuario se valida enviando el evento “OK“. La InterfaceUsuario envía el mismo evento al ManejadorValidacion. El ManejadorValidacion envía el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosCorrespondencia que haga una validación del usuario mediante el mismo evento. La InterfaceBaseDatosCorrespondencia envía a su vez el evento a la Base de Datos Correspondencia, el cual contesta con un OK si la validación es buena. El OK es enviado a la InterfaceBaseDatosCorrespondencia, de allí al ManejadorRegistroUsuario y luego al ManejadorValidacion como respuesta a las secuencias de validación. Una vez el ManejadorValidacion recibió este último OK, solicita al ManejadorMenuServicio que entre en acción mediante el evento ofrecerServicios. Ofrecer Servicios. A continuación podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorMenuServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaMenuServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lógica principal de este subflujo, el usuario debe presionar “Correspondencia Recibida“. Correspondencia Recibida subflujo principal. Siguiendo con la lógica, la InterfaceUsuario envía el mismo evento al ManejadorRegistroUsuario, el cual solicita CorrrespondenciaRecibida al ManejadorRecibida. Correspondencia Recibida subflujo Obtener Correspondencia Recibida. El ManejadorRecibida que es responsable de todo lo relacionado con el registro de tarjeta, solicita obtenerCorrespondenciaRecibida a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia envía el mismo evento al actor Base de Datos Correspondencia. Este actor responde mediante un NULL correspondiente a un registro de Correspondencia inexistente. Este evento es enviado de regreso al ManejadorRecibida. Modificar Información subflujo Correspondencia Recibida (S-1). A continuación, el ManejadorRecibida solicita desplegarPantallaCorrespondenciaRecibida a


Práctica UCPR-IST


InterfaceUsuario. El usuario ingresa los datos a modificar de la Correspondencia Recibida y presiona el botón de “Modificar” generando el evento Modificar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorRecibida el cual envía el evento ModificarCorrespondenciaRecibida a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorRecibida. A continuación, el ManejadorRecibida envía el evento desplegarPantallaCorrespondenciaRecibida a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia. En resumen, la secuencia podrá iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Correspondencia Recibida y finalmente el flujo principal de Correspondencia Recibida seguido por los subflujos Modificar Información (S-1).


Práctica UCPR-IST


Figura 8.2. 34. Diagrama de secuencia Modificar Información del caso de uso Correspondencia Recibida.


2 “OK” 3 “OK”



6

Validar

registro de

Usuario

7 “OK” 8 “OK”

9 “OK”

10 ofrecer


12

Correspondencia

Recibida

13 Correspondencia

Recibida

14 Correspondencia

Recibida 15 Obtener Correspondencia Recibida

16

O.C.R.



20 “Modificar”

21 “Modificar” 22 “Modificar” Correspondencia Recibida

23

G.C.R

24 “OK”

25 “OK”



21 “Salir”



ManejadorValidacion


BD

Correspondencia

ManejadorRecibida



Práctica UCPR-IST



Eliminar Información

El diagrama de secuencia para el subflujo Eliminar Información se muestra en el Figura 8.2. 35. Se guarda información siguiendo el flujo principal de Ofrecer Servicios en lugar del subflujo Correspondencia Recibida (S-1). Dentro del caso de uso Ofrecer Servicios se continuará con los subflujos Correspondencia Recibida (S-1). Validar Usuario. La secuencia comienza con la validación del usuario a partir del evento desplegarPantallaValidacion de la clase ManejadorValidacion a la InterfaceUsuario. El usuario se valida enviando el evento “OK“. La InterfaceUsuario envía el mismo evento al ManejadorValidacion. El ManejadorValidacion envía el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosCorrespondencia que haga una validación del usuario mediante el mismo evento. La InterfaceBaseDatosCorrespondencia envía a su vez el evento a la Base de Datos Correspondencia, el cual contesta con un OK si la validación es buena. El OK es enviado a la InterfaceBaseDatosCorrespondencia, de allí al ManejadorRegistroUsuario y luego al ManejadorValidacion como respuesta a las secuencias de validación. Una vez el ManejadorValidacion recibió este último OK, solicita al ManejadorMenuServicio que entre en acción mediante el evento ofrecerServicios. Ofrecer Servicios. A continuación podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorMenuServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaMenuServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lógica principal de este subflujo, el usuario debe presionar “Correspondencia Recibida“. Correspondencia Recibida subflujo principal. Siguiendo con la lógica, la InterfaceUsuario envía el mismo evento al ManejadorRegistroUsuario, el cual solicita CorrrespondenciaRecibida al ManejadorRecibida. Correspondencia Recibida subflujo Obtener Correspondencia Recibida. El ManejadorRecibida que es responsable de todo lo relacionado con el registro de tarjeta, solicita obtenerCorrespondenciaRecibida a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia envía el mismo evento al actor Base de Datos Correspondencia. Este actor responde mediante un NULL correspondiente a un registro de Correspondencia inexistente. Este evento es enviado de regreso al ManejadorRecibida. Eliminar Información subflujo Correspondencia Recibida (S-1). A continuación, el ManejadorRescibida solicita desplegarPantallaCorrespondenciaRecibida a


Práctica UCPR-IST


InterfaceUsuario. El usuario ingresa los datos para eliminar de la Correspondencia Recibida y presiona el botón de “Eliminar” generando el evento Eliminar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorRecibida el cual envía el evento EliminarCorrespondenciaRecibida a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorRecibida. A continuación, el ManejadorRecibida envía el evento desplegarPantallaCorrespondenciaRecibida a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia. En resumen, la secuencia podrá iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Correspondencia Recibida y finalmente el flujo principal de Correspondencia Recibida seguido por los subflujos Eliminar Información (S-1).


Práctica UCPR-IST


Figura 8.2. 35. Diagrama de secuencia Eliminar Información del caso de uso Correspondencia Recibida.


2 “OK” 3 “OK”



6

Validar

registro de

Usuario

7 “OK” 8 “OK”

9 “OK”

10 ofrecer


12

Correspondencia

Recibida

13 Correspondencia

Recibida

14 Correspondencia

Recibida 15 Obtener Correspondencia Recibida

16

O.C.R.



20 “Eliminar”

21 “Eliminar” 22 “Eliminar” Correspondencia Recibida

23

G.C.R

24 “OK”

25 “OK”



21 “Salir”



ManejadorValidacion


BD

Correspondencia

ManejadorRecibida



Práctica UCPR-IST



Buscar Información

El diagrama de secuencia para el subflujo Buscar Información se muestra en el Figura 8.2. 36. Se busca la información siguiendo el flujo principal de Ofrecer Servicios en lugar del subflujo Búsqueda de Correspondencia (S-1). Dentro del caso de uso Ofrecer Servicios se continuará con los subflujos Búsqueda de Correspondencia (S-1). Validar Usuario. La secuencia comienza con la validación del usuario a partir del evento desplegarPantallaValidacion de la clase ManejadorValidacion a la InterfaceUsuario. El usuario se valida enviando el evento “OK“. La InterfaceUsuario envía el mismo evento al ManejadorValidacion. El ManejadorValidacion envía el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosCorrespondencia que haga una validación del usuario mediante el mismo evento. La InterfaceBaseDatosCorrespondencia envía a su vez el evento a la Base de Datos Correspondencia, el cual contesta con un OK si la validación es buena. El OK es enviado a la InterfaceBaseDatosCorrespondencia, de allí al ManejadorRegistroUsuario y luego al ManejadorValidacion como respuesta a las secuencias de validación. Una vez el ManejadorValidacion recibió este último OK, solicita al ManejadorMenuServicio que entre en acción mediante el evento ofrecerServicios. Ofrecer Servicios. A continuación podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorMenuServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaMenuServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lógica principal de este subflujo, el usuario debe presionar “Búsqueda de Correspondencia“. Búsqueda de Correspondencia subflujo principal. Siguiendo con la lógica, la InterfaceUsuario envía el mismo evento al ManejadorRegistroUsuario, el cual solicita BuscarCorrespondencia al ManejadorBusqueda. Búsqueda de Correspondencia subflujo Obtener Correspondencia Encontrada. El ManejadorBusqueda que es responsable de todo lo relacionado con el registro de tarjeta, solicita obtenerBuscarCorrepondencia a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia envía el mismo evento al actor Base de Datos Correspondencia. Este actor responde mediante un NULL correspondiente a un registro de Correspondencia inexistente. Este evento es enviado de regreso al ManejadorBusqueda.


Práctica UCPR-IST


Buscar Información subflujo Búsqueda de Correspondencia (S-1). A continuación, el ManejadorBusqueda solicita desplegarPantallaBuscarcorrespondencia a InterfaceUsuario. El usuario ingresa los datos a que desea buscar de la Correspondencia y presiona el botón de “Buscar” generando el evento Buscar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorBusqueda el cual envía el evento BuscarCorrespondencia a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorBusqueda. A continuación, el ManejadorBusqueda envía el evento desplegarPantallaBuscarCorrespondencia a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia. En resumen, la secuencia podrá iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Búsqueda de Correspondencia y finalmente el flujo principal de Búsqueda de Correspondencia seguido por los subflujos Buscar Información (S-1).


Práctica UCPR-IST


Figura 8.2. 36. Diagrama de secuencia Buscar Información del caso de uso Búsqueda de Correspondencia.


2 “OK” 3 “OK”



6

Validar

registro de

Usuario

7 “OK” 8 “OK”

9 “OK”

10 ofrecer


12

Búsqueda de

Correspondencia

13 Búsqueda de

Correspondencia

14 Búsqueda de

Correspondencia 15 Obtener Búsqueda de

Correspondencia

16

O.B.C


Búsqueda de

Correspondencia

20 “Buscar”

21 “Buscar” 22 “Buscar” Correspondencia

23

B.C

24 “OK”

25 “OK”


Búsqueda de

Correspondencia

21 “Salir”



ManejadorValidacion


BD

Correspondencia

ManejadorRecibida



Práctica UCPR-IST



Buscar Información

El diagrama de secuencia para el subflujo Buscar Información se muestra en el Figura 8.2. 37. Se busca la información siguiendo el flujo principal de Ofrecer Servicios en lugar del subflujo Búsqueda de Correspondencia (S-1). Dentro del caso de uso Ofrecer Servicios se continuará con los subflujos Búsqueda de Correspondencia (S-1). Validar Usuario. La secuencia comienza con la validación del usuario a partir del evento desplegarPantallaValidacion de la clase ManejadorValidacion a la InterfaceUsuario. El usuario se valida enviando el evento “OK“. La InterfaceUsuario envía el mismo evento al ManejadorValidacion. El ManejadorValidacion envía el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosCorrespondencia que haga una validación del usuario mediante el mismo evento. La InterfaceBaseDatosCorrespondencia envía a su vez el evento a la Base de Datos Correspondencia, el cual contesta con un OK si la validación es buena. El OK es enviado a la InterfaceBaseDatosCorrespondencia, de allí al ManejadorRegistroUsuario y luego al ManejadorValidacion como respuesta a las secuencias de validación. Una vez el ManejadorValidacion recibió este último OK, solicita al ManejadorMenuServicio que entre en acción mediante el evento ofrecerServicios. Ofrecer Servicios. A continuación podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorMenuServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaMenuServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lógica principal de este subflujo, el usuario debe presionar “Búsqueda de Correspondencia“. Búsqueda de Correspondencia subflujo principal. Siguiendo con la lógica, la InterfaceUsuario envía el mismo evento al ManejadorRegistroUsuario, el cual solicita BuscarCorrespondencia al ManejadorBusqueda. Búsqueda de Correspondencia subflujo Obtener Correspondencia Encontrada. El ManejadorBusqueda que es responsable de todo lo relacionado con el registro de tarjeta, solicita obtenerBuscarCorrepondencia a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia envía el mismo evento al actor Base de Datos Correspondencia. Este actor responde mediante un NULL correspondiente a un registro de Correspondencia inexistente. Este evento es enviado de regreso al ManejadorBusqueda.


Práctica UCPR-IST


Buscar Información subflujo Búsqueda de Correspondencia (S-1). A continuación, el ManejadorBusqueda solicita desplegarPantallaBuscarcorrespondencia a InterfaceUsuario. El usuario ingresa los datos a que desea buscar de la Correspondencia y presiona el botón de “Buscar” generando el evento Buscar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorBusqueda el cual envía el evento BuscarCorrespondencia a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorBusqueda. A continuación, el ManejadorBusqueda envía el evento desplegarPantallaBuscarCorrespondencia a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia. En resumen, la secuencia podrá iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Búsqueda de Correspondencia y finalmente el flujo principal de Búsqueda de Correspondencia seguido por los subflujos Buscar Información (S-1).


Práctica UCPR-IST


Figura 8.2. 37. Diagrama de secuencia Buscar Información del caso de uso Búsqueda de Correspondencia.


2 “OK” 3 “OK”



6

Validar

registro de

Usuario

7 “OK” 8 “OK”

9 “OK”

10 ofrecer


12

Búsqueda de

Correspondencia

13 Búsqueda de

Correspondencia

14 Búsqueda de

Correspondencia 15 Obtener Búsqueda de

Correspondencia

16

O.B.C


Búsqueda de

Correspondencia

20 “Buscar”

21 “Buscar” 22 “Buscar” Correspondencia

23

B.C

24 “OK”

25 “OK”


Búsqueda de

Correspondencia

21 “Salir”



ManejadorValidacion


BD

Correspondencia

ManejadorBusqueda



Práctica UCPR-IST



Generar Informes

El diagrama de secuencia para el subflujo Generar Informes se muestra en el Figura 8.2. 38. Se busca la información siguiendo el flujo principal de Ofrecer Servicios en lugar del subflujo Informes Correspondencia (S-1). Dentro del caso de uso Ofrecer Servicios se continuará con los subflujos Informes Correspondencia(S-1). Validar Usuario. La secuencia comienza con la validación del usuario a partir del evento desplegarPantallaValidacion de la clase ManejadorValidacion a la InterfaceUsuario. El usuario se valida enviando el evento “OK“. La InterfaceUsuario envía el mismo evento al ManejadorValidacion. El ManejadorValidacion envía el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosCorrespondencia que haga una validación del usuario mediante el mismo evento. La InterfaceBaseDatosCorrespondencia envía a su vez el evento a la Base de Datos Correspondencia, el cual contesta con un OK si la validación es buena. El OK es enviado a la InterfaceBaseDatosCorrespondencia, de allí al ManejadorRegistroUsuario y luego al ManejadorValidacion como respuesta a las secuencias de validación. Una vez el ManejadorValidacion recibió este último OK, solicita al ManejadorMenuServicio que entre en acción mediante el evento ofrecerServicios. Ofrecer Servicios. A continuación podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorMenuServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaMenuServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lógica principal de este subflujo, el usuario debe presionar “Informes Correspondencia“. Informes Correspondencia subflujo principal. Siguiendo con la lógica, la InterfaceUsuario envía el mismo evento al ManejadorRegistroUsuario, el cual solicita BuscarCorrespondencia al ManejadorInformes. Generar Informes de Correspondencia subflujo Obtener Informes. El ManejadorInformes que es responsable de todo lo relacionado con lo de generar informes, solicita obtenerinformeCorrespondencia a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia envía el mismo evento al actor Base de Datos Correspondencia. Este actor responde mediante un NULL correspondiente a un registro de Correspondencia inexistente. Este evento es enviado de regreso al ManejadorInformacion. Generar Informes subflujo Informes Correspondencia (S-1). A continuación, el ManejadorInformes solicita desplegarPantallaInformesCorrespondencia a


Práctica UCPR-IST


InterfaceUsuario. El usuario ingresa los datos a que desea buscar de la Correspondencia y presiona el botón de “Generar Informes” generando el evento Generar Informes. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorInformes el cual envía el evento BuscarCorrespondencia a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorInformes. A continuación, el ManejadorInformes envía el evento desplegarPantallaInformesCorrespondencia a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia. En resumen, la secuencia podrá iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Informes Correspondencia y finalmente el flujo principal de Informes Correspondencia seguido por los subflujos Generar Informes (S-1).


Práctica UCPR-IST


Figura 8.2. 38. Diagrama de secuencia Generar Informes del caso de uso Informes Correspondencia.


2 “OK” 3 “OK”



6

Validar

registro de

Usuario

7 “OK” 8 “OK”

9 “OK”

10 ofrecer


12

Informes

Correspondencia

13 Informes

Correspondencia

14 Informes

Correspondencia 15 Obtener Informes Correspondencia

16

O.I.C



20 “Generar

Informes”

21 “Generar

Informes” 22 “Generar Informes” Correspondencia

23

G.I.C

24 “OK”

25 “OK”



21 “Salir”



ManejadorValidacion


BD

Correspondencia

ManejadorInformes



Práctica UCPR-IST


Manual de Usuario

Manual

El diagrama de secuencia para el subflujo Manual se muestra en el Figura 8.2. 39. Se busca la información siguiendo el flujo principal de Ofrecer Servicios en lugar del subflujo Manual de Usuario (S-1). Dentro del caso de uso Ofrecer Servicios se continuará con los subflujos Manual de Usuario (S-1). Validar Usuario. La secuencia comienza con la validación del usuario a partir del evento desplegarPantallaValidacion de la clase ManejadorValidacion a la InterfaceUsuario. El usuario se valida enviando el evento “OK“. La InterfaceUsuario envía el mismo evento al ManejadorValidacion. El ManejadorValidacion envía el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosCorrespondencia que haga una validación del usuario mediante el mismo evento. La InterfaceBaseDatosCorrespondencia envía a su vez el evento a la Base de Datos Correspondencia, el cual contesta con un OK si la validación es buena. El OK es enviado a la InterfaceBaseDatosCorrespondencia, de allí al ManejadorRegistroUsuario y luego al ManejadorValidacion como respuesta a las secuencias de validación. Una vez el ManejadorValidacion recibió este último OK, solicita al ManejadorMenuServicio que entre en acción mediante el evento ofrecerServicios. Ofrecer Servicios. A continuación podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorMenuServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaMenuServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lógica principal de este subflujo, el usuario debe presionar “Manual de Usuario“. Manual de Usuario subflujo principal. Siguiendo con la lógica, la InterfaceUsuario envía el mismo evento al ManejadorRegistroUsuario, el cual solicita Manual de Usuario al ManejadorIManual. Manual de Correspondencia subflujo Obtener Manual. El ManejadorManual que es responsable de todo lo relacionado con lo de generar iManual , solicita obtenerManualUsuario a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia envía el mismo evento al actor Base de Datos Correspondencia. Este actor responde mediante un NULL correspondiente a un registro de Correspondencia inexistente. Este evento es enviado de regreso al ManejadorManual. Manual subflujo Manual de Usuario (S-1). A continuación, el ManejadorManual solicita desplegarPantallaManualUsuario a InterfaceUsuario. El usuario puede


Práctica UCPR-IST


ver la información del manual de usuario y presiona el botón de “Salir“, dando por concluida la secuencia. En resumen, la secuencia podrá iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Manual de Usuario y finalmente el flujo principal de Manual de Usuario seguido por los subflujos Manual (S-1)

Figura 8.2. 39. Diagrama de secuencia Manual del caso de uso Manual de Usuario.


2 “OK” 3 “OK”



6

Validar

registro de

Usuario

7 “OK” 8 “OK”

9 “OK”

10 ofrecer


12

Manual de

Usuario

13 Manual de

Usuario

14 Manual de

Usuario 15 Obtener Manual de Usuario

16

O.M.U.


Manual de Usuario

20 “Salir”



ManejadorValidacion


BD

Correspondencia

ManejadorManual



Práctica UCPR-IST


Documento de Casos de Uso A partir de las diversas secuencias analizadas y descritas en los diagramas de secuencias, podemos generar una descripción casi completa de los casos de uso del sistema de Correspondencia a nivel de análisis. Para lograr este paso, tomamos todas las descripciones y las insertamos en los flujos o subflujos correspondientes de los diversos casos de uso. Dado que las secuencias no mencionan todos los posibles eventos sino los principales, podemos en este momento completar los que sean necesarios. En particular se debe asegurarnos que no existan discontinuidades entre las secuencias de eventos. Sin embargo, debe siempre mantenerse una buena consistencia entre los casos de uso de análisis y las secuencias anteriores que en el fondo son instanciaciones a partir de los casos de uso. Cualquier cambio en la lógica en las secuencias o casos de uso deberá reflejarse también en los diagramas de secuencia. [2]


Práctica UCPR-IST


Validar Usuario

El flujo principal del caso de uso Validar Usuario se muestra a continuación.

Caso de Uso Validar Usuario

Actores Usuario, Base de Datos Correspondencia

Tipo Inclusión.

Propósito

Validar a un usuario ya registrado para el uso del sistema de correspondencia.

Resumen

Este caso de uso es iniciado por el Usuario. Valida al usuario mediante un nombre y contraseña a ser validado con su respectivo registro de usuario para así poder utilizar el sistema de correspondencia.

Precondiciones El Usuario debe estar registrado en la base de datos.

Flujo Principal

El ManejadorValidacion solicita desplegarPantallaValidacion a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaValidacion. La PantallaValidacion se despliega. El Usuario puede seleccionar entre las siguientes opciones: "Aceptar" y "Cancelar". Si la actividad seleccionada es "Aceptar", se valida el registro de usuario mediante un nombre y un contraseña insertados por el Usuario en la PantallaValidacion. La PantallaValidacion envía el evento “Aceptar” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Aceptar” al ManejadorPrincipal. El ManejadorValidacion solicita validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita validarRegistroUsuario a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia solicita validarRegistroUsuario a la Base de Datos Correspondencia. La Base de Datos Correspondencia valida al usuario y devuelve el OK a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia devuelve el OK al ManejadorRegistroUsuario. El ManejadorRegistroUsuario devuelve el OK al ManejadorValidacion. Una vez validado el usuario (E-1), el ManejadorValidacion solicita ofrecerServicio al ManejadorServicio. Se continúa con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Cancelar", la PantallaValidacion envía el evento “Cancelar” a la InterfaceUsuario. La InterfaceUsuario envía el evento


Práctica UCPR-IST


“Cancelar” al ManejadorValidacion. El ManejadorValidacion sale del sistema.

Subflujos Ninguno.

Excepciones E-1 no hubo validación: El nombre/contraseña no se validó correctamente. Se le pide al usuario que vuelva a intentar..

Ofrecer Servicios

El flujo principal del caso de uso Ofrecer Servicios se muestra a continuación.

Caso de Uso Validar Usuario

Actores Usuario, Base de Datos Correspondencia

Tipo Inclusión.

Propósito Ofrecer los diversos servicios a un usuario ya registrado para el uso del sistema de correspondencia.

Resumen Este caso de uso es iniciado por el Usuario. Tiene opciones para utilizar los diversos servicios del sistema de correspondencia.

Precondiciones Se requiere la validación correcta del usuario.

Flujo Principal

El ManejadorMenuServicio solicita desplegarPantallaMenuServicio a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaMenuServicio. La PantallaMenuServicio se despliega. El Usuario puede seleccionar entre las siguientes actividades: “Correspondencia Despachada”, “Correspondencia Recibida”, "Búsqueda de Correspondencia", “Informes Correspondencia”, “Manual de Usuario” y "Salir". Si la actividad seleccionada es "Correspondencia Despachada", la PantallaMenuServicio envía el evento “Correspondencia Despachada” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Correspondencia Despachada” al ManejadorMenuServicio. El ManejadorMenuServicio solicita consultar al ManejadorDespachada. Se continúa con el caso de uso Correspondencia Despachada, subflujo Guardar (S-1), Modificar (S-2) y Eliminar (S-3). Si la actividad seleccionada es "Correspondencia Recibida", la PantallaMenuServicio envía el evento “Correspondencia Recibida” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Correspondencia Recibida” al ManejadorMenuServicio. El ManejadorMenuServicio solicita consultar al ManejadorRecibida. Se continúa con el caso de uso Correspondencia Recibida, subflujo Guardar (S-1), Modificar (S-2) y Eliminar (S-3).


Práctica UCPR-IST


Si la actividad seleccionada es "Búsqueda de Correspondencia", la PantallaMenuServicio envía el evento “Búsqueda de Correspondencia” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Búsqueda de Correspondencia” al ManejadorMenuServicio. El ManejadorMenuServicio solicita consultar al ManejadorBusqueda. Se continúa con el caso de uso Búsqueda de Correspondencia, subflujo Buscar (S-1). Si la actividad seleccionada es "Informe Correspondencia", la PantallaMenuServicio envía el evento “Informe Correspondencia” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Informe Correspondencia” al ManejadorMenuServicio. El ManejadorMenuServicio solicita consultar al ManejadorInforme. Se continúa con el caso de uso Informes Correspondencia, subflujo Generar Informe (S-1). Si la actividad seleccionada es "Manual de Usuario", la PantallaMenuServicio envía el evento “Manual de Usuario” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Manual de usuario” al ManejadorMenuServicio. El ManejadorMenuServicio solicita consultar al ManejadorManual. Se continúa con el caso de uso Manual de Usuario. Si la actividad seleccionada es "Salir", la PantallaMenuServicio envía el evento “Salir” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Salir” al ManejadorMenuServicio. El ManejadorMenuServicio sale del sistema.

Subflujos Ninguno.

Excepciones Ninguno.


El flujo principal del caso de uso Correspondencia Despachada se muestra a continuación.

Casos de Uso Correspondencia Despachada

Actores Usuario, Base de Datos

Tipo Básico

Propósito Permitir a un usuario Guardar, Modificar y Eliminar Información del sistema de Correspondencia.

Resumen


Práctica UCPR-IST


Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para Guardar, Modificar y Eliminar información del destinatario, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio. Con el sistema de Correspondencia.

Precondiciones Se requieren haber ejecutado anteriormente el caso de uso Validar Usuario.

Flujo Principal Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Usuario, se continuará con los diversos subflujos de este caso de uso.

El subflujo Guardar (S-1), del caso de uso Correspondencia Despachada se muestra a continuación.

Subflujos

S-1 Guardar Guarda Información subflujo Correspondencia Despachada (S-1). A continuación, el ManejadorDespachada solicita desplegarPantallaCorrespondenciaDespachada a InterfaceUsuario. El usuario ingresa los datos de Correspondencia Despachada y presiona el botón de “Guardar” generando el evento Guardar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorDespachada el cual envía el evento GuardarCorrespondenciaDespachada a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorDespachada. A continuación, el ManejadorDespachada envía el evento desplegarPantallaCorrespondenciaDespachada a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia.


Práctica UCPR-IST


El subflujo Modificar (S-2), del caso de uso Correspondencia Despachada se muestra a continuación.

Subflujos

S-2 Modificar Modificar Información subflujo Correspondencia Despachada (S-1). A continuación, el ManejadorDespachada solicita desplegarPantallaCorrespondenciaDespachada a InterfaceUsuario. El usuario ingresa los datos a modificar de la Correspondencia Despachada y presiona el botón de “Modificar” generando el evento Modificar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorDespachada el cual envía el evento ModificarCorrespondenciaDespachada a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorDespachada. A continuación, el ManejadorDespachada envía el evento desplegarPantallaCorrespondenciaDespachada a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia.

El subflujo Eliminar (S-3), del caso de uso Correspondencia Despachada se muestra a continuación.

Subflujos

S-3 Eliminar Eliminar Información subflujo Correspondencia Despachada (S-1). A continuación, el ManejadorDespachada solicita desplegarPantallaCorrespondenciaDespachada a InterfaceUsuario. El usuario ingresa los datos para eliminar de la Correspondencia Despachada y presiona el botón de “Eliminar” generando el evento Eliminar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorDespachada el cual envía el evento EliminarCorrespondenciaDespachada a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorDespachada. A continuación, el ManejadorDespachada envía el evento desplegarPantallaCorrespondenciaDespachada a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia.


Práctica UCPR-IST



El flujo principal del caso de uso Correspondencia Recibida se muestra a continuación.

Casos de Uso Correspondencia Recibida


Tipo Básico

Propósito Permitir a un usuario Guardar, Modificar y Eliminar Información del sistema de Correspondencia.

Resumen Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para Guardar, Modificar y Eliminar información de el remitente, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, dirección, teléfono, fecha recibido, fecha radicado sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio. Con el sistema de Correspondencia.



El subflujo Guardar (S-1), del caso de uso Correspondencia Recibida se muestra a continuación.

Subflujos

S-1 Guardar Guarda Información subflujo Correspondencia Recibida (S-1). A continuación, el ManejadorRecibida solicita desplegarPantallaCorrespondenciaRecibida a InterfaceUsuario. El usuario ingresa los datos de Correspondencia Recibida y presiona el botón de “Guardar” generando el evento Guardar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorRecibida el cual envía el evento GuardarCorrespondenciaRecibida a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorRecibida. A continuación, el ManejadorRecibida envía el evento desplegarPantallaCorrespondenciaRecibida a la


Práctica UCPR-IST


InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia.

El subflujo Modificar (S-2), del caso de uso Correspondencia Recibida se muestra a continuación.

Subflujos

S-2 Modificar Modificar Información subflujo Correspondencia Recibida (S-1). A continuación, el ManejadorRecibida solicita desplegarPantallaCorrespondenciaRecibida a InterfaceUsuario. El usuario ingresa los datos a modificar de la Correspondencia Despachada y presiona el botón de “Modificar” generando el evento Modificar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorRecibida el cual envía el evento ModificarCorrespondenciaRecibida a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorRecibida. A continuación, el ManejadorRecibida envía el evento desplegarPantallaCorrespondenciaRecibida a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia.

El subflujo Eliminar (S-3), del caso de uso Correspondencia Recibida se muestra a continuación.

Subflujos

S-3 Eliminar Eliminar Información subflujo Correspondencia Recibida (S-1). A continuación, el ManejadorRescibida solicita desplegarPantallaCorrespondenciaRecibida a InterfaceUsuario. El usuario ingresa los datos para eliminar de la Correspondencia Recibida y presiona el botón de “Eliminar” generando el evento Eliminar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorRecibida el cual envía el evento EliminarCorrespondenciaRecibida a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorRecibida. A continuación, el


Práctica UCPR-IST


ManejadorRecibida envía el evento desplegarPantallaCorrespondenciaRecibida a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia.


El flujo principal del caso de uso Búsqueda de Correspondencia se muestra a continuación.

Casos de Uso Búsqueda de Correspondencia


Tipo Básico

Propósito Permitir a un usuario Buscar Información del sistema de Correspondencia.

Resumen Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para Buscar la información por remitente, destinatario, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, dirección, teléfono, fecha recibido, fecha radicado sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio. Con el sistema de Correspondencia.



El subflujo Buscar (S-1), del caso de uso Búsqueda de correspondencia se muestra a continuación.

Subflujos

S-1 Buscar Buscar Información subflujo Búsqueda de Correspondencia (S-1). A continuación, el ManejadorBusqueda solicita desplegarPantallaBuscarcorrespondencia a InterfaceUsuario. El usuario ingresa los datos a que desea buscar de la Correspondencia y presiona el botón de “Buscar” generando el evento Buscar. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al


Práctica UCPR-IST


ManejadorBusqueda el cual envía el evento BuscarCorrespondencia a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorBusqueda. A continuación, el ManejadorBusqueda envía el evento desplegarPantallaBuscarCorrespondencia a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia.


El flujo principal del caso de uso Informes Correspondencia se muestra a continuación.

Casos de Uso Informes Correspondencia


Tipo Básico

Propósito Permitir a un usuario Genere Informes del sistema de Correspondencia.

Resumen Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para Genera Informes del total de la correspondencia recibida o despachada durante un tiempo determinado, del sistema de correspondencia.



El subflujo Generar Informe (S-1), del caso de uso Informes Correspondencia se muestra a continuación.

Subflujos

S-1 Generar Informes Generar Informes subflujo Informes Correspondencia (S-1). A continuación, el ManejadorInformes solicita desplegarPantallaInformesCorrespondencia a InterfaceUsuario. El usuario ingresa los datos a que desea


Práctica UCPR-IST


buscar de la Correspondencia y presiona el botón de “Generar Informes” generando el evento Generar Informes. Como consecuencia de esto, InterfaceUsuario envía el mismo evento al ManejadorInformes el cual envía el evento BuscarCorrespondencia a InterfaceBaseDatosCorrespondencia. Este último envía el mismo evento al actor Base de Datos Correspondencia, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorInformes. A continuación, el ManejadorInformes envía el evento desplegarPantallaInformesCorrespondencia a la InterfaceUsuario. En ese momento el Usuario presiona “Salir“, dando por concluida la secuencia.

Manual de Usuario

El flujo principal del caso de uso Manual de Usuario se muestra a continuación.

Casos de Uso Manual de Usuario

Actores Usuario

Tipo Básico

Propósito Permitir a un usuario ver el manual de Usuario del sistema de Correspondencia.

Resumen Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para ver el manual de usuario del sistema de correspondencia.


Flujo Principal Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Usuario.


Práctica UCPR-IST


Diccionario de Clases Como última etapa del modelo de análisis, se actualiza el diccionario de datos originalmente descrito para el dominio del problema para incluir todas las clases identificadas durante el modelo de análisis. [2] A continuación para el sistema de correspondencia. Comenzamos con cuatro módulos o paquetes principales: InterfaceUsuario, Validación, RegistroUsuario y Servicios, como se muestra en la Figura 8.2.40.

Figura 8.2.40. Módulos principales del sistema de correspondencia.

InterfaceUsuario Validación

RegistroUsuario Servicios


Práctica UCPR-IST


InterfaceUsuario El módulo InterfaceUsuario está compuesto por una sola clase: InterfaceUsuario – Clase Borde. Toda la interacción con el usuario se hace por medio de la borde de usuario. Validación El módulo Validación está compuesto por dos clases: PantallaPrincipal - Clase Borde. Pantalla Validación (P-1). ManejadorValidacion - Clase Control. El manejador validación es el encargado de desplegar la pantalla principal de interacción con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados.

RegistroUsuario El módulo Usuario está compuesto por las clases: RegistroUsuario - Clase Entidad. Para poder utilizar el sistema de correspondencia, el usuario debe estar registrado con el sistema. El registro contiene información acerca del usuario que incluye nombre, contraseña. ManejadorRegistroUsuario - Clase Control. El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Servicios El módulo Servicio se divide en los siguientes módulos: ServicioMenú, Correspondencia Despachada, Correspondencia Recibida, Búsqueda de Correspondencia, Informes Correspondencia y Manual de Usuario como se muestra en la Figura 8.2. 41.


Práctica UCPR-IST


Figura 8.2. 41. Módulos adicionales del módulo Servicios.

ServicioMenú Correspondencia

Despachada

Correspondencia

Recibida

Búsqueda de

Correspondencia

Informes

Correspondencia

Manual de

Usuario

Dominio


Práctica UCPR-IST


ServicioMenú El módulo ServicioMenú está compuesto por las clases: InterfaceBaseDatosCorrespondencia - Clase Borde. La información del sistema de correspondencia se almacena en la base de datos de correspondencia la cual se tiene acceso mediante el borde de la base de datos de correspondencia. Esto permite generar Informes, buscar, guardar, modificar y eliminar la correspondencia. PantallaMenuServicio - Clase Borde. Pantalla Menú de servicios (P-2). ManejadorMenuServicio - Clase Control. El manejador de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores especializados para correspondencia despachada, correspondencia recibida, Búsqueda de Correspondencia, informes correspondencia y manual de usuario. Dominio El módulo Dominio está compuesto por las clases: Remitente - Clase Entidad. Para poder recibir la correspondencia debe ser remitida por el nombre de una persona o empresa. Destinatario - Clase Entidad. Para poder enviar la correspondencia debe tener el nombre de la persona o empresa. Numero de Oficio - Clase Entidad. Se denomina por medio de un número. El número de folio es el consecutivo del oficio de la correspondencia recibida o despachada. . Fecha de Oficio – Clase Entidad. Es la fecha del oficio que indica su creación. Entidad o Persona - Clase Entidad. Es un campo en el cual se puede identificar la entidad o persona la cual va dirigida la correspondencia. Objeto o Referencia - Clase Entidad. Es un campo en el cual permite al usuario colocar un objeto o una referencia para su búsqueda. Dirección- Clase Entidad. Hace parte de la información de la correspondencia recibida, puede ser la dirección de la oficina o persona que envía la correspondencia.


Práctica UCPR-IST


Teléfono- Clase Entidad. Hace parte de la información de la correspondencia recibida, puede ser el teléfono de la oficina o persona que envía la correspondencia. Fecha Recibido - Clase Entidad. Hace parte de la información de la correspondencia recibida, es la fecha la cual es recibida la correspondencia. Fecha Radicado - Clase Entidad. Hace parte de la información de la correspondencia recibida, es la fecha la cual se radica la correspondencia. Sección o Persona - Clase Entidad. Es un campo en el cual se puede identificar la sección o persona que está enviando la correspondencia. Subseccion - Clase Entidad. Es un campo en el cual se describe la subseccion que es envidad o recibida la correspondencia, como por ejemplo la Delegación Departamental. Serie - Clase Entidad. Es un campo en el cual se describe la subseccion que es envidad o recibida la correspondencia, como por ejemplo Comunicados Oficiales. Subserie - Clase Entidad. Es un campo en el cual se describe la subseccion que es envidad o recibida la correspondencia, como por ejemplo Material Cedulas Centro de Acopio. Numero de folio - Clase Entidad. Se denomina por medio de un número. El número de folio es el consecutivo del folio que se va archivar. Numero de legajo - Clase Entidad. Se denomina por medio de un número. El número de legajo donde se va archivar. Numero de caja - Clase Entidad. Se denomina por medio de un número. El número de caja donde se va archivar la correspondencia. Departamento - Clase Entidad. Es el departamento donde es envidada o recibida la correspondencia. Municipio - Clase Entidad. Es la ciudad donde es envidada o recibida la correspondencia.


Práctica UCPR-IST


Correspondencia Despachada El módulo Correspondencia Despachada está compuesto por las clases: InterfaceBaseDatosCorrespondencia - Clase Borde. La información del sistema de correspondencia se almacena en la base de datos de correspondencia la cual se tiene acceso mediante el borde de la base de datos de correspondencia. Esto permite generar Informes, buscar, guardar, modificar y eliminar la correspondencia. PantallaCorrespondenciaDespachada - Clase Borde. Pantalla correspondencia despachada (P-3). ManejadorDespachada - Clase Control. El manejador de despachada se encarga de enviar las peticiones particulares de servicios a los manejadores especializados para guardar, modificar y eliminar correspondencia. Correspondencia Recibida El módulo Correspondencia Recibida está compuesto por las clases: InterfaceBaseDatosCorrespondencia - Clase Borde. La información del sistema de correspondencia se almacena en la base de datos de correspondencia la cual se tiene acceso mediante el borde de la base de datos de correspondencia. Esto permite generar Informes, buscar, guardar, modificar y eliminar la correspondencia. PantallaCorrespondenciaRecibida - Clase Borde. Pantalla correspondencia Recibida (P-4). ManejadorRecibida - Clase Control. El manejador Recibida se encarga de enviar las peticiones particulares de servicios a los manejadores especializados para guardar, modificar y eliminar correspondencia. Búsqueda de Correspondencia El módulo Búsqueda de Correspondencia está compuesto por las clases: InterfaceBaseDatosCorrespondencia - Clase Borde. La información del sistema de correspondencia se busca en la base de datos de correspondencia la cual se tiene acceso mediante el borde de la base de datos de correspondencia. Esto permite buscar la correspondencia.


Práctica UCPR-IST


PantallaCorrespondenciaDespachada - Clase Borde. Pantalla Búsqueda de Correspondencia (P-5). ManejadorBusqueda - Clase Control. El manejador de Buscar encarga de enviar las peticiones particulares de servicios a los manejadores especializados para buscar la correspondencia. Informes Correspondencia El módulo Informes de Correspondencia está compuesto por las clases: InterfaceBaseDatosCorrespondencia - Clase Borde. La información del sistema de correspondencia se genera informes de la base de datos de correspondencia la cual se tiene acceso mediante el borde de la base de datos de correspondencia. Esto permite generar informes de la correspondencia. PantallaCorrespondenciaDespachada - Clase Borde. Pantalla Informes Correspondencia (P-6). ManejadorInformes - Clase Control. El manejador de Informes encarga de enviar las peticiones particulares de servicios a los manejadores especializados para Generar informes de la correspondencia. Manual de Usuario El módulo Manual de Usuario está compuesto por las clases: InterfaceBaseDatosCorrespondencia - Clase Borde. La información del sistema de correspondencia muestra el manual de la base de datos de correspondencia la cual se tiene acceso mediante el borde de la base de datos de correspondencia. Esto permite mostrar el manual de usuario del sistema de la correspondencia. PantallaCorrespondenciaDespachada - Clase Borde. Pantalla Manual de Usuario (P-7). ManejadorManual - Clase Control. El manejador de Manual se encarga de enviar las peticiones particulares de servicios a los manejadores especializados para mostrar en pantalla el manual de usuario de la correspondencia.


Práctica UCPR-IST


8.3 MODELO DE DISEÑO

El modelo de diseño es un refinamiento y formalización adicional del modelo de

análisis donde se toman en cuenta las consecuencias del ambiente de

implementación. El resultado del modelo de diseño son especificaciones muy

detalladas de todos los objetos, incluyendo sus operaciones y atributos.

Se requiere un modelo de diseño ya que el modelo de análisis no es lo

suficientemente formal para poder llegar al código fuente. Por tal motivo se

debe refinar los objetos, incluyendo las operaciones que se deben ofrecer, la

comunicación entre los diferentes objetos, los eventos que los objetos envían

entre sí, etc. [3]

Arquitectura

El término arquitectura se refiere, en nuestro caso, a la organización de las

clases dentro del sistema. Durante el modelo de análisis se generó una

arquitectura de clases para el sistema y se definió la funcionalidad “conceptual”

ofrecida por las distintas clases dentro de la arquitectura. Durante el diseño

esta arquitectura debe detallarse, pudiéndose cambiar los aspectos

considerados inicialmente, como fue la funcionalidad inicialmente asignada a

cada clase, e incluso las propias clases. [3]

Robustez

La robustez de un sistema debe ser uno de los objetivos Validaciones del

diseño. Jamás debe agregarse funcionalidad o simplificar código a expensas

de la robustez. El sistema debe estar protegido contra errores y debe al menos

ofrecer diagnósticos para las fallas que aún pudiesen ocurrir, en particular

aquellas que son fatales. Durante el desarrollo es a veces bueno insertar

instrucciones internas en el código para descubrir fallas, aunque luego sean

removidas durante la producción. [3]

Reusó

El reusó es un aspecto fundamental del diseño. Cuanto más se pueda reutilizar

el código mejor será la robustez del sistema. [3]

Extensibilidad

La mayoría de los sistemas son extendidos en manera no prevista por el diseño

original. Por lo tanto, los componentes reutilizables mejorarán también la

extensibilidad. [3]


Práctica UCPR-IST


8.31 Diseño de Objetos

El diseño de objetos es un proceso de añadir detalles al análisis y tomar

decisiones junto con diseño de sistema, o sea al ambiente de implementación,

de manera que podamos lograr una especificación detallada antes de

comenzar la implementación final. [3]

Consideremos el sistema de correspondencia. Dado que la complejidad de un

sistema se incrementa radicalmente durante el diseño en relación a la

arquitectura desarrollada durante el análisis, procederemos con la descripción

de solamente una parte del sistema, mientras que el resto del diseño se

mostrará en los apéndices. Para ello nos concentraremos inicialmente en los

casos de uso relacionados con registro: Validar Usuario.

Validar Usuario

A continuación mostramos el flujo Validación del caso de uso Validar Usuario

como se presentó al final del capítulo de análisis.

Flujo Validación

El ManejadorRegistroUsuario solicita desplegarPantallaValidación a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaValidación. La PantallaValidación se despliega. El Usuario puede seleccionar entre las siguientes opciones: “Aceptar” y “Cancelar”. Si la actividad seleccionada es “Aceptar”, se valida el registro de usuario mediante un Nombre de Usuario y una Clave insertados por el Usuario en la PantallaValidación. La PantallaValidación envía el evento “ACEPTAR” a la InterfaceUsuario. La InterfaceUsuario envía el evento “ACEPTAR” al ManejadorValidación. El ManejadorValidación solicita validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita validarRegistroUsuario a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia solicita validarRegistroUsuario a la Base de Datos Correspondencia. La Base de Datos Correspondencia valida al usuario y devuelve el ACEPTAR a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia devuelve el ACEPTAR al ManejadorRegistroUsuario. El ManejadorRegistroUsuario devuelve el ACEPTAR al ManejadorValidación. Una vez validado el usuario (E-1), el


Práctica UCPR-IST


ManejadorValidación solicita ofrecerServicio al ManejadorMenuServicios. Se continúa con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es “Cancelar”, la PantallaValidación envía el evento “Cancelar” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Cancelar” al ManejadorValidación. El ManejadorValidación sale del sistema.

Tomamos cada una de las frases que describen el flujo y las analizaremos para

decidir qué responsabilidad representan y a que clase se le asignan:

1. El ManejadorRegistroUsuario solicita desplegarPantallaValidación

a la InterfaceUsuario. La primera pregunta es “cuál es la responsabilidad”. La responsabilidad que podemos identificar aquí es “solicita desplegarPantallaValidación”. La siguiente pregunta es “a quién se le asigna la responsabilidad”. Existen dos opciones, asignar “solicita desplegarPantallaValidación” al ManejadorValidación o asignar “desplegarPantallaValidación” a la InterfaceUsuario. Por lo tanto, asignaremos la responsabilidad inicial para la “solicitud desplegarPantallaValidación” al ManejadorRegistroUsuario, definiendo la responsabilidad de manera completa como “solicitar desplegarPantallaValidación a la InterfaceUsuario”. Como veremos con la segunda frase, la responsabilidad de desplegarPantallaValidación será asignada de manera adecuada a la InterfaceUsuario por lo cual no será necesario hacerlo en este momento. Sin embargo, siempre revisamos que exista la responsabilidad complementaria para la segunda clase en la frase. El objetivo esencial es asegurarse de asignar responsabilidades a las diferentes clases de manera que no se rompa con el flujo de colaboraciones, algo que debe tratarse con sumo cuidado para resolver cuanto antes el problema general de asignación de Ofrecer Servicios. Se debe también recordar que habrá varias etapas dentro de la actividad de diseño donde se podrá afinar la asignación de responsabilidades.

2. La InterfaceUsuario despliega la PantallaValidación. De manera análoga a la oración anterior, la responsabilidad que identificamos es “despliega la PantallaValidación” y la asignamos a InterfaceUsuario utilizando la misma lógica anterior. Nótese que esta responsabilidad corresponde al servicio solicitado por ManejadorValidación en la oración anterior. Esto resalta el hecho de que las responsabilidades se están asignando de manera correcta y sin romper el flujo de colaboraciones.


Práctica UCPR-IST


3. La PantallaValidación se despliega. Esta responsabilidad se asigna a la única clase involucrada que es PantallaValidación. Nótese también, que esta responsabilidad, “despliega”, corresponde al servicio de despliegue de la PantallaValidación referido en la oración anterior.

4. El Usuario puede seleccionar entre las siguientes opciones: “Aceptar” y “Cancelar”. En general los actores no son parte de la arquitectura del sistema por lo cual no se les asigna ninguna responsabilidad.

5. Si la actividad seleccionada es “Aceptar”, se valida el registro de

usuario mediante un Nombre de Usuario y una Clave insertados por el Usuario en la PantallaValidación. Oraciones que describen responsabilidades para actores no son incluidas ya que no agregan responsabilidades.

6. La PantallaValidación envía el evento “ACEPTAR” a la

InterfaceUsuario. La responsabilidad es “envía el evento “ACEPTAR” a la InterfaceUsuario” y se asigna a PantallaValidación.

7. La InterfaceUsuario envía el evento “ACEPTAR” al ManejadorValidación. La responsabilidad es “envía el evento “ACEPTAR” al ManejadorRegistroUsuario” y se asigna a InterfaceUsuario. Adicionalmente, se asigna la responsabilidad “maneja el evento “ACEPTAR”” y se asigna al ManejadorRegistroUsuario.

8. El ManejadorValidación solicita validarRegistroUsuario al ManejadorRegistroUsuario. La responsabilidad es “solicita validarRegistroUsuario al ManejadorValidación” y se asigna a ManejadorRegistroUsuario.

9. El ManejadorValidación solicita validarRegistroUsuario a la

InterfaceBaseDatosCorrespondencia. La responsabilidad es “solicita validarRegistroUsuario a la InterfaceBaseDatosCorrespondencia” y se asigna a ManejadorRegistroUsuario.

10. La InterfaceBaseDatosCorrespondencia solicita

validarRegistroUsuario a la Base de Datos Correspondencia. La responsabilidad es “solicitar validarRegistroUsuario a la Base de Datos Correspondencia” y se asigna a InterfaceBaseDatosCorrespondencia.

11. La Base de Datos Correspondencia valida al usuario y devuelve el

ACEPTAR a la InterfaceBaseDatosCorrespondencia. Esta frase no agrega responsabilidades ya que involucra un actor externo al sistema junto con un evento de devolución.


Práctica UCPR-IST


12. La InterfaceBaseDatosCorrespondencia devuelve el ACEPTAR al ManejadorRegistroUsuario. Esta frase no agrega responsabilidades ya que describe un evento de devolución.

13. El ManejadorRegistroUsuario devuelve el ACEPTAR al

ManejadorValidación. Nuevamente, esta frase no agrega responsabilidades ya que describe un evento de devolución.

14. Una vez validado el usuario (E-1), el ManejadorValidación solicita

ofrecerServicio al ManejadorMenuServicios. La responsabilidad es “solicita ofrecerServicio al ManejadorMenuServicios” la cual se asigna a ManejadorValidación. Adicionalmente asignamos la responsabilidad “ofrecerServicio” a la clase ManejadorMenuServicios para asegurarse que exista una responsabilidad complementaria en esta última clase.

15. Se continúa con el caso de uso Ofrecer Servicios. Esta es una frase

que describe continuación entre casos de uso y no agrega ninguna responsabilidad.

16. Si la actividad seleccionada es “Cancelar”, la PantallaValidación envía el evento “Cancelar” a la InterfaceUsuario. Se asigna la responsabilidad “envía el evento “Cancelar” a la InterfaceUsuario” a la PantallaValidación.

17. La InterfaceUsuario envía el evento “Cancelar” al

ManejadorValidación. Se asigna la responsabilidad “envía el evento “Cancelar” al ManejadorValidación” a la InterfaceUsuario. Se asigna adicionalmente la responsabilidad “maneja el evento “Cancelar”” al ManejadorRegistroUsuario.

18. El ManejadorValidación sale del sistema. Se asigna la responsabilidad “sale del sistema” al ManejadorValidación. A partir de estas frases obtenemos nuestras primeras responsabilidades y las insertamos en las tarjetas de clase correspondientes, logrando una versión preliminar de las tarjetas de clase. En general, las tarjetas tienen la ventaja de forzar a uno a ser breve, de tal manera que las responsabilidades se listan lo más compacto posible.

En la Tabla 8.31. Se muestra las responsabilidades identificadas hasta el

momento para la clase ManejadorValidación.

Nótese, que agregamos entre paréntesis el índice de la frase de la cual

provienen en la descripción del caso de uso.


Práctica UCPR-IST


Clase: ManejadorValidación

Descripción: El manejador validación es el encargado de desplegar la pantalla Validación de interacción con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados.

Módulo: Validación

Estereotipo: Control

Propiedades:

Superclases:

Subclases:

Atributos:

solicita desplegarPantallaValidación a la InterfaceUsuario (1)

maneja el evento “ACEPTAR” (7)

solicita validarRegistroUsuario al ManejadorValidación (8)

solicita ofrecerServicio al ManejadorMenuServicios (14)

maneja el evento “Cancelar” (17)

sale del sistema (18)

Tabla 8.31. Tarjeta para la clase ManejadorValidación con responsabilidades

identificadas hasta el momento.

En la Tabla 8.32 muestra las responsabilidades identificadas hasta el momento

para la clase PantallaValidación.

Clase: PantallaValidación

Descripción: Pantalla validación (P-1).


Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega (3)

envía el evento “Aceptar” a la InterfaceUsuario (6)

envía el evento “Cancelar” a la InterfaceUsuario (16)

Tabla 8.32. Tarjeta para la clase PantallaValidación con responsabilidades



Práctica UCPR-IST


La Tabla 8.33 muestra las responsabilidades identificadas hasta el momento

para la clase ManejadorRegistroUsuario.

Clase: ManejadorRegistroUsuario

Descripción: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema.

Módulo: Registro.Usuario


Propiedades:

Superclases:

Subclases:

Atributos:

solicita validarRegistroUsuario a la InterfaceBaseDatosCorrespondencia (9)

Tabla 8.33. Tarjeta para la clase ManejadorRegistroUsuario con

responsabilidades identificadas hasta el momento.

En la Tabla 8.34. Muestra las responsabilidades identificadas hasta el momento

para la clase InterfaceBaseDatosCorrespondencia.

Clase: InterfaceBaseDatosCorrrespondencia

Descripción: La información de cada usuario se almacena en la base de datos de correspondencia la cual se accede mediante la interface de la base de datos de correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre la correspondencia.

Módulo: Registro.InterfaceBD

Estereotipo: Interface

Propiedades:

Superclases:

Subclases:

Atributos:

solicita validarRegistroUsuario a la BaseDatosCorrespondencia (10)

Tabla 8.34. Tarjeta para la clase InterfaceBaseDatosCorrespondencia con



Práctica UCPR-IST


La Tabla 8.35. Muestra las responsabilidades identificadas hasta el momento

para la clase ManejadorMenuServicios.

Clase: ManejadorMenuServicios

Descripción: El manejador de Ofrecer Servicios se encarga de enviar las peticiones particulares de Ofrecer Servicios a los manejadores especializados para consulta, reserva y compra.

Módulo: Ofrecer Servicios


Propiedades:

Superclases:

Subclases:

Atributos:

ofrecerServicio (14)

Tabla 8.35. Tarjeta para la clase ManejadorMenuServicios con


Es posible también obtener responsabilidades a partir de las frase descritas en

el manejo de excepciones, como se muestra a continuación.

Excepciones

E-1 no hubo validación: El Nombre de Usuario/Clave no se validó correctamente. Se le pide al usuario que vuelva a intentar.

Sin embargo, solo se van a realizar los flujos básicos y no los alternos. En

general, los flujos alternos, como los de excepción, son los menos comunes y

son importantes de diseñar pero no en una primera etapa.

Ofrecer Servicios

A continuación mostramos el flujo Validación del caso de uso Validar Usuario.

Flujo Validación

El ManejadorMenuServicios solicita desplegarPantallaMenuServicio a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaMenuServicio. La PantallaMenuServicio se despliega. El Usuario puede seleccionar entre las siguientes actividades: “Correspondencia Despachada”, “Correspondencia Recibida”, “Búsqueda de Información”, “Informes Correspondencia”, “Manual de Usuario” y “Salir”. Si la actividad seleccionada es “Correspondencia Despachada”, la PantallaMenuServicio envía el evento “Correspondencia Despachada” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Correspondencia Despachada”


Práctica UCPR-IST


al ManejadorMenuServicios. El ManejadorMenuServicios solicita Correspondencia Despachada al ManejadorDespachada. Se continúa con el caso de uso Correspondencia Despachada, subflujo Guardar (S-1), Modificar(S-2) y Eliminar(S-3). Si la actividad seleccionada es “Correspondencia Recibida”, la PantallaMenuServicio envía el evento “Correspondencia Recibida” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Correspondencia Recibida” al ManejadorMenuServicios. El ManejadorMenuServicios solicita Correspondencia Recibida al ManejadorRecibida. Se continúa con el caso de uso Correspondencia Recibida, subflujo Guardar (S-1), Modificar(S-2) y Eliminar(S-3). Si la actividad seleccionada es “Búsqueda de Correspondencia”, la PantallaMenuServicio envía el evento “Búsqueda de Correspondencia” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Búsqueda de Correspondencia” al ManejadorMenuServicios. El ManejadorMenuServicios solicita Informes Correspondencia al ManejadorBusqueda. Se continúa con el caso de uso Busqueda de Correspondencia, subflujo Buscar (S-1). Si la actividad seleccionada es “Informes Correspondencia”, la PantallaMenuServicio envía el evento “Informes Correspondencia” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Informes Correspondencia” al ManejadorMenuServicios. El ManejadorMenuServicios solicita Informes Correspondencia al ManejadorInformes. Se continúa con el caso de uso Correspondencia Recibida, subflujo Generar Informes (S-1). Si la actividad seleccionada es “Manual de Usuario”, la PantallaMenuServicio envía el evento “Manual de Usuario” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Manual de Usuario” al ManejadorManual. El ManejadorMenuServicios solicita Manual de Usuario al ManejadorInformes. Se continúa con el caso de uso Manual de Usuario. Si la actividad seleccionada es “Salir”, la PantallaMenuServicio envía el evento “Salir” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Salir” al ManejadorMenuServicios. El ManejadorMenuServicios sale del sistema.


Práctica UCPR-IST


Nuevamente, tomamos cada una de las frases que describen el flujo y las

analizaremos para decidir qué responsabilidad representan y a que clase se le

asignan:

19. El ManejadorMenuServicios solicita desplegarPantallaMenuServicio a la InterfaceUsuario. La responsabilidad es “solicita desplegarPantallaMenuServicio a la InterfaceUsuario” y se asigna a ManejadorMenuServicios.

20. La InterfaceUsuario despliega la PantallaMenuServicio. La responsabilidad “despliega la PantallaMenuServicio” se asigna a InterfaceUsuario.

21. La PantallaMenuServicio se despliega. La responsabilidad es

“despliega” y se asigna a PantallaMenuServicio.

22. El Usuario puede seleccionar entre las siguientes actividades: “Correspondencia Despachada”, “Correspondencia Recibida”, “Búsqueda de Correspondencia”, “Informes de Correspondencia”, “Manual de Usuario” y “Menú”. Esta frase es informativa describiendo opciones del Usuario, por lo cual no se agregan responsabilidades adicionales.

23. Si la actividad seleccionada es “Correspondencia Despachada”, la

PantallaMenuServicio envía el evento “Correspondencia Despachada” a la InterfaceUsuario.

24. La InterfaceUsuario envía el evento “Correspondencia

Despachada” al ManejadorMenuServicios.

25. El ManejadorMenuServicios solicita Ingresar Correspondencia Despachada al ManejadorDespachada.

. 26. Se continúa con el caso de uso Correspondencia Despachada,

subflujo Ingresar Correspondencia Despachada (S-1).

27. Si la actividad seleccionada es “Correspondencia Recibida”, la PantallaMenuServicio envía el evento “Correspondencia Recibida” a la InterfaceUsuario.

28. La InterfaceUsuario envía el evento “Correspondencia Recibida” al

ManejadorMenuServicios.

29. El ManejadorMenuServicios solicita Ingresar Correspondencia Recibida al ManejadorDespachada.


Práctica UCPR-IST


30. Se continúa con el caso de uso Correspondencia Despachada, subflujo Ingresar Correspondencia Despachada (S-1). Retomamos el proceso de identificación de responsabilidades a partir de la siguiente frase, correspondiente a lógica relacionada con el caso de uso de Correspondencia Despachada.

31. Si la actividad seleccionada es “Correspondencia Recibida”, la

PantallaMenuServicio envía el evento “Correspondencia Recibida” a la InterfaceUsuario.

32. La InterfaceUsuario envía el evento “Correspondencia Recibida” al


33. El ManejadorMenuServicios solicita Ingresar Correspondencia Recibida al ManejadorRecibida.

. 34. Se continúa con el caso de uso Correspondencia Recibida,

subflujo Ingresar Correspondencia Recibida (S-1). 35. Si la actividad seleccionada es “Correspondencia Recibida”, la

PantallaMenuServicio envía el evento “Correspondencia Recibida” a la InterfaceUsuario.

36. La InterfaceUsuario envía el evento “Correspondencia Recibida” al ManejadorMenuServicios.

37. El ManejadorMenuServicios solicita Ingresar Correspondencia

Recibida al ManejadorRecibida.

38. Se continúa con el caso de uso Correspondencia Recibida, subflujo Ingresar Correspondencia Recibida (S-1). Retomamos el proceso de identificación de responsabilidades a partir de la siguiente frase, correspondiente a lógica relacionada con el caso de uso de Correspondencia Recibida.

39. Si la actividad seleccionada es “Búsqueda de Correspondencia”,

la PantallaMenuServicio envía el evento “Buscar Correspondencia” a la InterfaceUsuario.

40. La InterfaceUsuario envía el evento “Búsqueda de

Correspondencia” al ManejadorMenuServicios.

41. El ManejadorMenuServicios solicita Buscar Correspondencia al ManejadorBusqueda.

. 42. Se continúa con el caso de uso Búsqueda de Correspondencia,

subflujo Buscar Correspondencia (S-1).


Práctica UCPR-IST


43. Si la actividad seleccionada es “Búsqueda de Correspondencia”, la PantallaMenuServicio envía el evento “Búsqueda de Correspondencia” a la InterfaceUsuario.

44. La InterfaceUsuario envía el evento “Búsqueda de


45. El ManejadorMenuServicios solicita Buscar Correspondencia al ManejadorBusqueda.

46. Se continúa con el caso de uso Búsqueda de Correspondencia,

subflujo Buscar Correspondencia (S-1). Retomamos el proceso de identificación de responsabilidades a partir de la siguiente frase, correspondiente a lógica relacionada con el caso de uso de Búsqueda de Correspondencia.

47. Si la actividad seleccionada es “Informes de Correspondencia”, la

PantallaMenuServicio envía el evento “Informes Correspondencia” a la InterfaceUsuario.

48. La InterfaceUsuario envía el evento “Informes de


49. El ManejadorMenuServicios solicita Informes de Correspondencia

al ManejadorInformes. .

50. Se continúa con el caso de uso Informes Correspondencia, subflujo Informes Correspondencia (S-1).

51. Si la actividad seleccionada es “Informes de Correspondencia”, la PantallaMenuServicio envía el evento “Informes Correspondencia” a la InterfaceUsuario.

52. La InterfaceUsuario envía el evento “Informes Correspondencia”

al ManejadorMenuServicios.

53. El ManejadorMenuServicios solicita Informes Correspondencia al ManejadorInformes.

54. Se continúa con el caso de uso Informes Correspondencia,

subflujo Informes Correspondencia (S-1). Retomamos el proceso de identificación de responsabilidades a partir de la siguiente frase, correspondiente a lógica relacionada con el caso de uso de Informes de Correspondencia.


Práctica UCPR-IST


55. Si la actividad seleccionada es “Manual de Usuario”, la PantallaMenuServicio envía el evento “Manual de Usuario” a la InterfaceUsuario.

56. La InterfaceUsuario envía el evento “Manual de Usuario” al


57. El ManejadorMenuServicios solicita Manual de Usuario al ManejadorManual.

. 58. Se continúa con el caso de uso Manual de Usuario, subflujo

Manual de Usuario (S-1). 59. Si la actividad seleccionada es “Manual de Usuario”, la

PantallaMenuServicio envía el evento “Manual de Usuario” a la InterfaceUsuario.

60. La InterfaceUsuario envía el evento “Manual de Usuario” al


61. El ManejadorMenuServicios solicita Manual de Usuario al ManejadorManual.

62. Se continúa con el caso de uso Manual de Usuario, subflujo

Manual de Usuario (S-1). Retomamos el proceso de identificación de responsabilidades a partir de la siguiente frase, correspondiente a lógica relacionada con el caso de uso de Manual de Usuario.

63. Si la actividad seleccionada es “Salir”, la PantallaMenuServicio

envía el evento “Salir” a la InterfaceUsuario. Se asigna la responsabilidad “envía el evento “Salir” a la InterfaceUsuario” a la clase PantallaMenuServicio.

64. La InterfaceUsuario envía el evento “Salir” al

ManejadorMenuServicios. Se asigna la responsabilidad “envía el evento “Salir” a la ManejadorMenuServicios” a la clase InterfaceUsuario. Adicionalmente, se asigna “maneja el evento “Salir” al ManejadorMenuServicios.

65. El ManejadorMenuServicios sale del sistema. Se asigna la

responsabilidad “sale del sistema” al ManejadorMenuServicios. A partir de estas frases obtenemos nuevas responsabilidades y las insertamos

en las tarjetas de clase correspondientes. Dado que no todas las clases

agregan nuevas responsabilidades, iremos mostrando sólo aquellas que sí lo

hacen. En particular, las responsabilidades identificadas para las clases


Práctica UCPR-IST


ManejadorRegistroUsuario y PantallaValidación no han sido modificadas y se

mantienen iguales a las descritas en la Tabla 8.31 y en la Tabla 8.32,

respectivamente. De manera similar, las responsabilidades identificadas para

las clases ManejadorRegistroUsuario y InterfaceBaseDatosCorrespondencia no

han sido modificadas.

La Tabla 8.36 muestra las responsabilidades para la clase InterfaceUsuario

anteriormente identificadas en la Tabla 8.3.1 junto con las nuevas

responsabilidades.

Clase: InterfaceUsuario

Descripción: Toda la interacción con el usuario se hace por medio de la interface de usuario.

Módulo: InterfaceUsuario

Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega la PantallaValidación (2)

envía el evento “Aceptar” al ManejadorValidación(6)

envía el evento “Cancelar” al ManejadorValidación (16)

despliega la PantallaMenuServicio (24)

envía el evento “Correspondencia Despachada” al ManejadorMenuServicios (24)

envía el evento “Correspondencia Recibida” al ManejadorMenuServicios (32)

envía el evento “Búsqueda de Correspondencia” al ManejadorMenuServicios (40)

envía el evento “Informes Correspondencia” al ManejadorMenuServicios (48)

envía el evento “Manual de Usuario” al ManejadorMenuServicios (56)

envía el evento “Salir” al ManejadorServicio (64)

Tabla 8.36. Tarjeta para la clase InterfaceUsuario con responsabilidades


En la Tabla 8.37 se muestra las responsabilidades para la clase

ManejadorMenuServicio anteriormente identificadas en la Tabla 8.3.3 junto con

las nuevas responsabilidades.


Práctica UCPR-IST


Clase: ManejadorMenuServicios

Descripción: El manejador de Ofrecer Servicios se encarga de enviar las peticiones particulares de Ofrecer Servicios a los manejadores especializados para consulta, reserva y compra.



Propiedades:

Superclases:

Subclases:

Atributos:

ofrecerServicio (14)

solicita desplegarPantallaMenuServicio a la InterfaceUsuario (19)

maneja el evento “Correspondencia Despachada” (31)

maneja el evento “Salir” (64)


Tabla 8.37. Tarjeta para la clase ManejadorMenuServicios con


La Tabla 8.38 muestra las responsabilidades identificadas hasta el momento

para la clase PantallaMenuServicio.

Clase: PantallaMenuServicio

Descripción: Pantalla menú de Ofrecer Servicios (P-2).


Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega (19)

envía el evento “Salir” a la InterfaceUsuario (63)

Tabla 8.38. Tarjeta para la clase PantallaMenuServicio con responsabilidades


Este caso de uso no especifica responsabilidades adicionales a las

mencionadas anteriormente, incluyendo responsabilidades por razones de

manejo de excepciones.


Práctica UCPR-IST



A continuación mostramos el flujo Validación del caso de uso Correspondencia

Despachada.

Flujo Validación

Se continúa con el subflujo Correspondencia Despachada (S-1)

Tomamos cada una de las frases que describen el flujo y las analizaremos para

decidir qué responsabilidad representan y a que clase se le asignan:

66. Se continúa con el subflujo Correspondencia Despachada (S-1). Esta frase describe flujo interno del caso de uso y no agrega responsabilidades.

Como podemos apreciar, el flujo anterior no agrega responsabilidades

adicionales.

Continuamos con el subflujo Correspondencia Despachada (S-1) del caso de

uso Correspondencia Despachada como se muestra a continuación,

Subflujos

S-1 Correspondencia Despachada El ManejadorDespachada solicita desplegarPantallaCorrespondenciaDespachada a la InterfaceUsuario. La InterfaceUsuario despliega a la PantallaCorrespondenciaDespachada. La PantallaCorrespondenciaDespachada se despliega. Esta pantalla contiene información que debe ser llenada por el Usuario, lo cual incluye destinatario, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio. El Usuario puede seleccionar entre las siguientes actividades: “Guardar”, “Modificar”, “Eliminar” y “Menú”. Si el Usuario selecciona “Guardar”, la PantallaCorrespondenciaDespachada envía el evento “Guardar” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Guardar” al ManejadorDespachada. El ManejadorDespachada solicita Guardar a la InterfaceBaseDatosCorrespondencia. La


Práctica UCPR-IST


InterfaceBaseDatosCorrespondencia solicita Guardar a la Base de Datos Correspondencia (E-1). La Base de Datos Correspondencia devuelve el OK a la InterfaceBaseDatosCorrespondecia. La InterfaceBaseDatosCorrespondencia devuelve el OK al ManejadorDespachada. Si el Usuario selecciona “Modificar”, la PantallaCorrespondenciaDespachada envía el evento “Modificar” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Modificar” al ManejadorDespachada. El ManejadorDespachada solicita Modificar a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia solicita Modificar a la Base de Datos Correspondencia (E-1). La Base de Datos Correspondencia devuelve el OK a la InterfaceBaseDatosCorrespondecia. La InterfaceBaseDatosCorrespondencia devuelve el OK al ManejadorDespachada. Si el Usuario selecciona “Eliminar”, la PantallaCorrespondenciaDespachada envía el evento “Eliminar” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Eliminar” al ManejadorDespachada. El ManejadorDespachada solicita Eliminar a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia solicita eliminar a la Base de Datos Correspondencia (E-1). La Base de Datos Correspondencia devuelve el OK a la InterfaceBaseDatosCorrespondecia. La InterfaceBaseDatosCorrespondencia devuelve el OK al ManejadorDespachada. Si la actividad seleccionada es “Menú”, la PantallaCorrespondenciaDespachada envía el evento “Menú” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Menú” al ManejadorDespachada. El ManejadorDespachada cierra la pantallaCorrespondenciaDespachada y regresa a la pantalla (P-2). (Si aún no se ha presionado “Guardar”, la información que ésta será perdida).

Nuevamente, tomamos cada una de las frases y las analizamos para identificar

nuevas responsabilidades.

67. El ManejadorDespachada solicita desplegarPantallaCorrespondenciaDespachada a la InterfaceUsuario. La responsabilidad es “solicita desplegarPantallaCorrespondenciaDespachada a la InterfaceUsuario” y se asigna a ManejadorDespachada.

68. La InterfaceUsuario despliega a la PantallaCorrespondenciaDespachada. La responsabilidad es “despliega la PantallaCorrespondenciaDespachada” y se asigna a InterfaceUsuario.


Práctica UCPR-IST


69. La PantallaCorrespondenciaDespachada se despliega. La

responsabilidad es “despliega” y se asigna a PantallaCorrespondenciaDespachada.

70. Esta pantalla contiene información que debe ser llenada por el

Usuario, lo cual incluye destinatario, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio. Esta es una frase totalmente informativa por lo cual no agrega responsabilidades.

71. El Usuario puede seleccionar entre las siguientes actividades:

“Guardar”, “Modificar”, “Eliminar” y “Menú”. Esta es nuevamente una frase informativa sobre las opciones del Usuario y no agrega responsabilidades.

72. Si el Usuario selecciona “Guardar”, la

PantallaCorrespondenciaDespachada envía el evento “Guardar” a la InterfaceUsuario. Se identifica la responsabilidad “envía el evento “Guardar” a la InterfaceUsuario” y se asigna a la PantallaCorrespondenciaDespachada.

73. La InterfaceUsuario envía el evento “Guardar” al

ManejadorDespachada. Se identifica la responsabilidad “envía el evento “Guardar” al ManejadorDespachada” y se asigna a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Guardar” al ManejadorDespachada.

74. El ManejadorDespachada solicita guardar a la InterfaceBaseDatosCorrespondencia. Se identifica la responsabilidad “solicita guardar a la InterfaceBaseDatosCorrespondencia” y se asigna al ManejadorDespachada.

75. La InterfaceBaseDatosCorrespondencia solicita guardar a la Base

de Datos Correspondencia (E-1). Se identifica la responsabilidad “solicita guardar a la Base de Datos Correspondencia” y se asigna a la InterfaceBaseDatosCorrespondencia. Nuevamente, no tiene mucho sentido asignar responsabilidades a la Base de Datos Correspondencia dado que los actores son externos al sistema.

76. La Base de Datos Correspondencia devuelve el OK a la

InterfaceBaseDatosCorrespondencia. No se asigna ninguna responsabilidad a la Base de Datos Correspondencia por ser externa al sistema. Tampoco se agregan responsabilidades por razones de devolución de información.


Práctica UCPR-IST


77. La InterfaceBaseDatosCorrespondencia devuelve el OK al ManejadorDespachada. No se asigna responsabilidades dado que la frase describe una devolución de información.

78. Si el Usuario selecciona “Modificar”, la

PantallaCorrespondenciaDespachada envía el evento “Modificar” a la InterfaceUsuario. Se identifica la responsabilidad “envía el evento “Modificar” a la InterfaceUsuario” y se asigna a la PantallaCorrespondenciaDespachada.

79. La InterfaceUsuario envía el evento “Modificar” al

ManejadorDespachada. Se identifica la responsabilidad “envía el evento “Modificar” al ManejadorDespachada” y se asigna a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Modificar” al ManejadorDespachada.

80. El ManejadorDespachada solicita guardar a la

InterfaceBaseDatosCorrespondencia. Se identifica la responsabilidad “solicita guardar a la InterfaceBaseDatosCorrespondencia” y se asigna al ManejadorDespachada.

81. La InterfaceBaseDatosCorrespondencia solicita Modificar a la Base

de Datos Correspondencia (E-1). Se identifica la responsabilidad “solicita guardar a la Base de Datos Correspondencia” y se asigna a la InterfaceBaseDatosCorrespondencia. Nuevamente, no tiene mucho sentido asignar responsabilidades a la Base de Datos Correspondencia dado que los actores son externos al sistema.



83. La InterfaceBaseDatosCorrespondencia devuelve el OK al

ManejadorDespachada. No se asigna responsabilidades dado que la frase describe una devolución de información.

84. Si el Usuario selecciona “Eliminar”, la

PantallaCorrespondenciaDespachada envía el evento “Eliminar” a la InterfaceUsuario. Se identifica la responsabilidad “envía el evento “Eliminar” a la InterfaceUsuario” y se asigna a la PantallaCorrespondenciaDespachada.

85. La InterfaceUsuario envía el evento “Eliminar” al

ManejadorDespachada. Se identifica la responsabilidad “envía el evento “Eliminar” al ManejadorDespachada” y se asigna a la


Práctica UCPR-IST


InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Eliminar” al ManejadorDespachada.

86. El ManejadorDespachada solicita eliminar a la

InterfaceBaseDatosCorrespondencia. Se identifica la responsabilidad “solicita eliminar a la InterfaceBaseDatosCorrespondencia” y se asigna al ManejadorDespachada.

87. La InterfaceBaseDatosCorrespondencia solicita eliminar a la Base

de Datos Correspondencia (E-1). Se identifica la responsabilidad “solicita eliminar a la Base de Datos Correspondencia” y se asigna a la InterfaceBaseDatosCorrespondencia. Nuevamente, no tiene mucho sentido asignar responsabilidades a la Base de Datos Correspondencia dado que los actores son externos al sistema.




ManejadorDespachada. No se asigna responsabilidades dado que la frase describe una devolución de información.

90. Si la actividad seleccionada es “Menú”, la

PantallaCorrespondenciaDespachada envía el evento “Menú” a la InterfaceUsuario. Se asigna la responsabilidad “envía el evento “Menú” a la InterfaceUsuario” a la PantallaCorrespondenciaDespachada.

91. La InterfaceUsuario envía el evento “Menú” al

ManejadorDespachada. Se asigna la responsabilidad “envía el evento “Menú” al ManejadorDespachada” a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Menú”” al ManejadorDespachada.

92. El ManejadorDespachada sale del sistema. Se asigna la

responsabilidad “sale de la correspondencia Despachada y regresa a la pantalla (P-2)” al ManejadorDespachada.

93. (Si aún no se ha presionado “Guardar”, la información que ésta será perdida). Nuevamente, esta es una frase informativa por lo cual no se asignan nuevas responsabilidades.


Práctica UCPR-IST


A partir de estas frases obtenemos nuevas responsabilidades y las insertamos

en las tarjetas de clase correspondientes. Dado que no todas las clases

agregan nuevas responsabilidades, iremos mostrando sólo aquellas. Que sí lo

hacen. En particular, las responsabilidades identificadas para las clases

ManejadorRegistroUsuario y PantallaValidación no han sido modificadas y se


respectivamente. Las responsabilidades identificadas para las clases

ManejadorMenuServicios y PantallaServicio tampoco han sido modificadas y se


respectivamente.

Adicionalmente, las responsabilidades identificadas para las clases

ManejadorRegistroUsuario, tampoco han sido modificadas y se mantienen

iguales a las descritas en la Tabla 8.37 y Tabla 8.38, respectivamente.

En la Tabla 8.39 se muestra las responsabilidades para la clase

InterfaceUsuario.




Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:


envía el evento “Aceptar” al ManejadorValidación (7)

envía el evento “Cancelar” al ManejadorValidaicion (17)


envía el evento “Correspondencia Despachada” al ManejadorMenuServicios (24)

despliega la PantallaCorrespondenciaDespachada (68)

envía el evento “Guardar” al ManejadorDespachada (73)

envía el evento “Modificar” al ManejadorDespachada (79)

envía el evento “Guardar” al ManejadorDespachada (85)

envía el evento “Menú” al ManejadorDespachada (91)

Tabla 8.39. Tarjeta para la clase InterfaceUsuario con responsabilidades



Práctica UCPR-IST


En la Tabla 8.310. Se muestra las responsabilidades para la clase

ManejadorDespachada.

Clase: ManejadorDespachada

Descripción: El manejador despachada es el encargado del manejo de la correspondencia Despachada.

Módulo: Correspondencia Despachada


Propiedades:

Superclases:

Subclases:

Atributos:

solicita desplegarPantallaCorrespondenciaDespachada a la InterfaceUsuario (67)

maneja el evento “Guardar” (73)

solicita guardar a la InterfaceBaseDatosCorrespondencia (74)

maneja el evento “Modificar” (79)

solicita modificar a la InterfaceBaseDatosCorrespondencia (80)

maneja el evento “Eliminar” (85)

solicita eliminar a la InterfaceBaseDatosCorrespondencia (86)

maneja el evento “Menú” (91)


Tabla 8.310. Tarjeta para la clase ManejadorDespachada con


Agregamos una nueva tarjeta de clase describiendo las responsabilidades para

la clase PantallaCorrespondenciaDespachada como se muestra en la Tabla

8.3.11.

Clase: PantallaCorrespondenciaDespachada

Descripción: Pantalla de ingreso de Información de la correspondencia despachada (P-3).

Módulo: Ingreso de Información

Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega (69)

envía el evento “Guardar” a la InterfaceUsuario (73)

envía el evento “Modificar” a la InterfaceUsuario (79)

envía el evento “Eliminar” a la InterfaceUsuario (85)

envía el evento “Menú” a la InterfaceUsuario (91)

Tabla 8.3.11. Tarjeta para la clase PantallaCorrespondenciaDespachada con

nuevas responsabilidades identificadas hasta el momento.


Práctica UCPR-IST


En la Tabla 8.3.12. Se muestra las responsabilidades para la clase

InterfaceBaseDatosCorrespondencia.

Clase: InterfaceBaseDatosCorrespondencia

Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se aceza mediante la interface de la base de datos de Correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre la correspondencia despachada.



Propiedades:

Superclases:

Subclases:

Atributos:


Tabla 8.3.12. Tarjeta para la clase InterfaceBaseDatosCorrespondecia con

responsabilidades identificadas hasta el momento. Continuamos con el subflujo

Obtener Registro Tarjeta (S-2) del caso de uso Registrar Tarjeta como se

muestra a continuación,

94. Se continúa con el subflujo Correspondencia Recibida (S-1). Esta frase describe flujo interno del caso de uso y no agrega responsabilidades.



adicionales. Continuamos con el subflujo Correspondencia Recibida (S-2) del

caso de uso Correspondencia Recibida como se muestra a continuación,

Subflujos

S-2 Correspondencia Recibida El ManejadorRecibida solicita desplegarPantallaCorrespondenciaRecibida a la InterfaceUsuario. La InterfaceUsuario despliega a la PantallaCorrespondenciaRecibida. La PantallaCorrespondenciaRecibida se despliega. Esta pantalla contiene información que debe ser llenada por el Usuario, lo cual incluye remitente, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, dirección, teléfono, fecha recibido, fecha radicado sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio.


Práctica UCPR-IST


El Usuario puede seleccionar entre las siguientes actividades: “Guardar”, “Modificar”, “Eliminar” y “Menú”. Si el Usuario selecciona “Guardar”, la PantallaCorrespondenciaRecibida envía el evento “Guardar” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Guardar” al ManejadorRecibida. El ManejadorRecibida solicita Guardar a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia solicita Guardar a la Base de Datos Correspondencia (E-1). La Base de Datos Correspondencia devuelve el OK a la InterfaceBaseDatosCorrespondecia. La InterfaceBaseDatosCorrespondencia devuelve el OK al ManejadorRecibida. Si el Usuario selecciona “Modificar”, la PantallaCorrespondenciaRecibida envía el evento “Modificar” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Modificar” al ManejadorRecibida. El ManejadorRecibida solicita Modificar a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia solicita Modificar a la Base de Datos Correspondencia (E-1). La Base de Datos Correspondencia devuelve el OK a la InterfaceBaseDatosCorrespondecia. La InterfaceBaseDatosCorrespondencia devuelve el OK al ManejadorRecibida. Si el Usuario selecciona “Eliminar”, la PantallaCorrespondenciaRecibida envía el evento “Eliminar” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Eliminar” al ManejadorRecibida. El ManejadorRecibida solicita Eliminar a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia solicita eliminar a la Base de Datos Correspondencia (E-1). La Base de Datos Correspondencia devuelve el OK a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia devuelve el OK al ManejadorRecibida. Si la actividad seleccionada es “Menú”, la PantallaCorrespondenciaRecibida envía el evento “Menú” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Menú” al ManejadorRecibida. El ManejadorRecibida cierra la pantallaCorrespondenciaRecibida y regresa a la pantalla (P-2). (Si aún no se ha presionado “Guardar”, la información que ésta será perdida).




Práctica UCPR-IST


95. El ManejadorRecibida solicita desplegarPantallaCorrespondenciaRecibida a la InterfaceUsuario. La responsabilidad es “solicita desplegarPantallaCorrespondenciaRecibida a la InterfaceUsuario” y se asigna a ManejadorRecibida.

96. La InterfaceUsuario despliega a la PantallaCorrespondenciaRecibida. La responsabilidad es “despliega la PantallaCorrespondenciaRecibida” y se asigna a InterfaceUsuario.

97. La PantallaCorrespondenciaRecibida se despliega. La

responsabilidad es “despliega” y se asigna a PantallaCorrespondenciaRecibida.

98. Esta pantalla contiene información que debe ser llenada por el

Usuario, lo cual incluye remitente, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, dirección, teléfono, fecha recibido, fecha radicado sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio. Esta es una frase totalmente informativa por lo cual no agrega responsabilidades.

99. El Usuario puede seleccionar entre las siguientes actividades:

“Guardar”, “Modificar”, “Eliminar” y “Menú”. Esta es nuevamente una frase informativa sobre las opciones del Usuario y no agrega responsabilidades.

100. Si el Usuario selecciona “Guardar”, la

PantallaCorrespondenciaRecibida envía el evento “Guardar” a la InterfaceUsuario. Se identifica la responsabilidad “envía el evento “Guardar” a la InterfaceUsuario” y se asigna a la PantallaCorrespondenciaRecibida.

101. La InterfaceUsuario envía el evento “Guardar” al

ManejadorRecibida. Se identifica la responsabilidad “envía el evento “Guardar” al ManejadorRecibida” y se asigna a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Guardar” al ManejadorRecibida.

102. El ManejadorRecibida solicita guardar a la

InterfaceBaseDatosCorrespondencia. Se identifica la responsabilidad “solicita guardar a la InterfaceBaseDatosCorrespondencia” y se asigna al ManejadorRecibida.

103. La InterfaceBaseDatosCorrespondencia solicita guardar a la

Base de Datos Correspondencia (E-1). Se identifica la responsabilidad “solicita guardar a la Base de Datos Correspondencia” y se asigna a la InterfaceBaseDatosCorrespondencia. Nuevamente, no tiene mucho


Práctica UCPR-IST


sentido asignar responsabilidades a la Base de Datos Correspondencia dado que los actores son externos al sistema.




ManejadorRecibida. No se asigna responsabilidades dado que la frase describe una devolución de información.

106. Si el Usuario selecciona “Modificar”, la

PantallaCorrespondenciaRecibida envía el evento “Modificar” a la InterfaceUsuario. Se identifica la responsabilidad “envía el evento “Modificar” a la InterfaceUsuario” y se asigna a la PantallaCorrespondenciaRecibida.

107. La InterfaceUsuario envía el evento “Modificar” al

ManejadorRecibida. Se identifica la responsabilidad “envía el evento “Modificar” al ManejadorRecibida” y se asigna a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Modificar” al ManejadorRecibida.

108. El ManejadorRecibida solicita Modificar a la

InterfaceBaseDatosCorrespondencia. Se identifica la responsabilidad “solicita guardar a la InterfaceBaseDatosCorrespondencia” y se asigna al ManejadorRecibida.

109. La InterfaceBaseDatosCorrespondencia solicita Modificar a la Base de Datos Correspondencia (E-1). Se identifica la responsabilidad “solicita guardar a la Base de Datos Correspondencia” y se asigna a la InterfaceBaseDatosCorrespondencia. Nuevamente, no tiene mucho sentido asignar responsabilidades a la Base de Datos Correspondencia dado que los actores son externos al sistema.






Práctica UCPR-IST


112. Si el Usuario selecciona “Eliminar”, la

PantallaCorrespondenciaRecibida envía el evento “Eliminar” a la InterfaceUsuario. Se identifica la responsabilidad “envía el evento “Eliminar” a la InterfaceUsuario” y se asigna a la PantallaCorrespondenciaRecibida.

113. La InterfaceUsuario envía el evento “Eliminar” al

ManejadorRecibida. Se identifica la responsabilidad “envía el evento “Eliminar” al ManejadorRecibida” y se asigna a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Eliminar” al ManejadorRecibida.

114. El ManejadorRecibida solicita eliminar a la

InterfaceBaseDatosCorrespondencia. Se identifica la responsabilidad “solicita eliminar a la InterfaceBaseDatosCorrespondencia” y se asigna al ManejadorRecibida.

115. La InterfaceBaseDatosCorrespondencia solicita eliminar a la

Base de Datos Correspondencia (E-1). Se identifica la responsabilidad “solicita eliminar a la Base de Datos Correspondencia” y se asigna a la InterfaceBaseDatosCorrespondencia. Nuevamente, no tiene mucho sentido asignar responsabilidades a la Base de Datos Correspondencia dado que los actores son externos al sistema.






PantallaCorrespondenciaRecibida envía el evento “Menú” a la InterfaceUsuario. Se asigna la responsabilidad “envía el evento “Menú” a la InterfaceUsuario” a la PantallaCorrespondenciaRecibida.


ManejadorRecibida. Se asigna la responsabilidad “envía el evento “Menú” al ManejadorRecibida” a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Menú”” al ManejadorRecibida.


Práctica UCPR-IST


120. El ManejadorRecibida sale del sistema. Se asigna la responsabilidad “sale de la correspondencia Despachada y regresa a la pantalla (P-2)” al ManejadorRecibida.

121. (Si aún no se ha presionado “Guardar”, la información que

ésta será perdida). Nuevamente, esta es una frase informativa por lo cual no se asignan nuevas responsabilidades.

En la Tabla 8.3.13 se muestra las responsabilidades para la clase

InterfaceUsuario.




Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:





envía el evento “Correspondencia Recibida” al ManejadorMenuServicios (28)

despliega la PantallaCorrespondenciaRecibida (96)

envía el evento “Guardar” al ManejadorRecibida (101)

envía el evento “Modificar” al ManejadorRecibida (107)

envía el evento “Guardar” al ManejadorRecibida (113)

envía el evento “Menú” al ManejadorRecibida (119)

Tabla 8.3.13. Tarjeta para la clase InterfaceUsuario con responsabilidades



ManejadorRecibida.


Práctica UCPR-IST


Clase: ManejadorRecibida

Descripción: El manejador Recibida es el encargado del manejo de la correspondencia Recibida.

Módulo: Correspondencia Recibida


Propiedades:

Superclases:

Subclases:

Atributos:

solicita desplegarPantallaCorrespondenciaRecibida a la InterfaceUsuario (95)

maneja el evento “Guardar” (101)

solicita guardar a la InterfaceBaseDatosCorrespondencia (102)

maneja el evento “Modificar” (107)

solicita modificar a la InterfaceBaseDatosCorrespondencia (108)

maneja el evento “Eliminar” (113)

solicita Eliminar a la InterfaceBaseDatosCorrespondencia (114)



Tabla 8.3.14. Tarjeta para la clase ManejadorRecibida con responsabilidades



la clase PantallaCorrespondenciaRecibida como se muestra en la Tabla 8.3.15.

Clase: PantallaCorrespondenciaRecibida

Descripción: Pantalla de ingreso de Información de la correspondencia recibida (P-4).

Módulo: Ingreso de Información

Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega (97)

envía el evento “Guardar” a la InterfaceUsuario (101)

envía el evento “Modificar” a la InterfaceUsuario (107)

envía el evento “Eliminar” a la InterfaceUsuario (113)


Tabla 8.3.15. Tarjeta para la clase PantallaCorrespondenciaRecibida con



Práctica UCPR-IST





Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se accede mediante la interface de la base de datos de Correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre la correspondencia Recibida.



Propiedades:

Superclases:

Subclases:

Atributos:




3.1.5 Búsqueda de Correspondencia


adicionales. Continuamos con el subflujo Búsqueda de Correspondencia (S-3)

del caso de uso Búsqueda de Correspondencia como se muestra a

continuación,

Subflujos

S-3 Búsqueda de Correspondencia El ManejadorBusqueda solicita desplegarPantallaBusquedaCorrespondencia a la InterfaceUsuario. La InterfaceUsuario despliega a la PantallaBusquedaCorrespondencia. La PantallaBusquedaCorrespondencia se despliega. Esta pantalla contiene información que debe ser llenada por el Usuario, lo cual incluye remitente, destinatario, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, dirección, teléfono, fecha recibido, fecha radicado sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio. El Usuario puede seleccionar entre las siguientes actividades: “Buscar” y “Menú”.


Práctica UCPR-IST


Si el Usuario selecciona “Buscar”, la PantallaBusquedaCorrespondencia envía el evento “Buscar” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Buscar” al ManejadorBusqueda. El ManejadorBusqueda solicita Buscar a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia solicita Buscar a la Base de Datos Correspondencia (E-1). La Base de Datos Correspondencia devuelve el OK a la InterfaceBaseDatosCorrespondecia. La InterfaceBaseDatosCorrespondencia devuelve el OK al ManejadorBusqueda. Si la actividad seleccionada es “Menú”, la PantallaBusquedaCorrespondencia envía el evento “Menú” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Menú” al ManejadorBusqueda. El ManejadorBusqueda cierra la pantallaBusquedaCorrespondencia y regresa a la pantalla (P-2).



123. El ManejadorBusqueda solicita

desplegarPantallaBusquedaCorrespondencia a la InterfaceUsuario. La responsabilidad es “solicita desplegarPantallaBusquedaCorrespondencia a la InterfaceUsuario” y se asigna a ManejadorBusqueda.

124. La InterfaceUsuario despliega a la

PantallaBusquedaCorrespondencia. La responsabilidad es “despliega la PantallaBusquedaCorrespondencia” y se asigna a InterfaceUsuario.

125. La PantallaBusquedaCorrespondencia se despliega. La

responsabilidad es “despliega” y se asigna a PantallaBusquedaCorrespondencia.

Esta pantalla contiene información que debe ser llenada por el Usuario, lo cual incluye remitente, destinatario, numero de folio, fecha de oficio, entidad o persona, objeto o referencia, dirección, teléfono, fecha recibido, fecha radicado sección o persona, subseccion, serie, subserie, numero de folio, numero de legajo, numero de caja, departamento y municipio, esta información debe ser seleccionada para poder efectuar la búsqueda. Esta es una frase totalmente informativa por lo cual no agrega responsabilidades.

126. El Usuario puede seleccionar entre las siguientes actividades: “Buscar” y “Menú”. Esta es nuevamente una frase


Práctica UCPR-IST


informativa sobre las opciones del Usuario y no agrega responsabilidades.

127. Si el Usuario selecciona “Buscar”, la PantallaBusquedaCorrespondencia envía el evento “Buscar” a la InterfaceUsuario. Se identifica la responsabilidad “envía el evento “Modificar” a la InterfaceUsuario” y se asigna a la PantallaBusquedaCorrespondencia.

128. La InterfaceUsuario envía el evento “Buscar” al

ManejadorBusqueda. Se identifica la responsabilidad “envía el evento “Buscar” al ManejadorBusqueda” y se asigna a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Buscar” al ManejadorBusqueda.

129. El ManejadorBusqueda solicita buscar a la

InterfaceBaseDatosCorrespondencia. Se identifica la responsabilidad “solicita buscar a la InterfaceBaseDatosCorrespondencia” y se asigna al ManejadorBusqueda.

130. La InterfaceBaseDatosCorrespondencia solicita buscar a la Base de Datos Correspondencia (E-1). Se identifica la responsabilidad “solicita buscar a la Base de Datos Correspondencia” y se asigna a la InterfaceBaseDatosCorrespondencia. Nuevamente, no tiene mucho sentido asignar responsabilidades a la Base de Datos Correspondencia dado que los actores son externos al sistema.




ManejadorBusqueda. No se asigna responsabilidades dado que la frase describe una devolución de información.


PantallaCorrespondenciaRecibida envía el evento “Menú” a la InterfaceUsuario. Se asigna la responsabilidad “envía el evento “Menú” a la InterfaceUsuario” a la PantallaBusquedaCorrespondencia.


ManejadorBusqueda. Se asigna la responsabilidad “envía el evento “Menú” al ManejadorBusqueda” a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Menú”” al ManejadorBusqueda.


Práctica UCPR-IST


135. El ManejadorBusqueda sale del sistema. Se asigna la responsabilidad “sale de la búsqueda de correspondencia y regresa a la pantalla (P-2)” al ManejadorBusqueda.

136. (Si aún no se ha presionado “Buscar”, la información que

ésta será perdida). Nuevamente, esta es una frase informativa por lo cual no se asignan nuevas responsabilidades.


InterfaceUsuario.




Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:


envía el evento “Aceptar” al ManejadorRegistroUsuario (7)

envía el evento “Cancelar” al ManejadorRegistroUsuario (17)


envía el evento “Búsqueda Correspondencia” al ManejadorMenuServicios (40)

despliega la PantallaBusquedaCorrespondencia(124)

envía el evento “Buscar” al ManejadorBusqueda(128)





ManejadorBusqueda.


Práctica UCPR-IST


Clase: ManejadorBusqueda

Descripción: El manejador Búsqueda es el encargado del manejo de la búsqueda de la correspondencia.

Módulo: Búsqueda de Correspondencia


Propiedades:

Superclases:

Subclases:

Atributos:

solicita desplegarPantallaBusqueda a la InterfaceUsuario (123)

maneja el evento “Buscar” (128)

solicita buscar a la InterfaceBaseDatosCorrespondencia (129)



Tabla 8.3.18. Tarjeta para la clase ManejadorBusqueda con responsabilidades



la clase PantallaBusquedaCorrespondencia como se muestra en la Tabla 8.3.

19.

Clase: PantallaBusquedaCorrespondencia

Descripción: Pantalla de ingreso de Información para la búsqueda de correspondencia (P-5).


Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega (125)

envía el evento “Buscar” a la InterfaceUsuario (128)


Tabla 8.3.19. Tarjeta para la clase PantallaBusquedaCorrespondencia con





Práctica UCPR-IST



Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se accede mediante la interface de la base de datos de Correspondencia. Esto permite validar a los distintos usuarios además de almacenar la información que se desea buscar.



Propiedades:

Superclases:

Subclases:

Atributos:




De manera general, se puede también obtener responsabilidades a partir del

manejo de excepciones, como se muestra a continuación,

Excepciones

E-1 Nombre de Usuario incorrecto: El Nombre de Usuario no es válido. Se le vuelve a pedir al usuario que complete el registro. E-2 clave incorrecta: La clave escogida es muy sencilla o no se validó correctamente. Se le vuelve a pedir al usuario que complete el registro.

Sin embargo, nos concentraremos únicamente en los flujos básicos y no los

alternos. En general, los alternos que son los menos comunes, son importantes

de diseñar pero no en una primera etapa.

Continuamos con el subflujo Correspondencia Encontrada (S-2) del caso de

uso Búsqueda Correspondencia como se muestra a continuación,

Subflujos

S-2 Correspondencia Encontrada El ManejadorBusqueda solicita desplegarPantallaCorrespondenciaEncontrada a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaCorrespondenciaEncontrada. La PantallaCorrespondenciaEncontrada se despliega. El Usuario puede seleccionar la siguiente actividad: “Menú”. Si la actividad seleccionada es “Menú”, la PantallaCorrespondenciaEncontrada envía el evento “Menú” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Menú” al ManejadorBusqueda. El ManejadorBusqueda solicita ofrecerServicio al


Práctica UCPR-IST


ManejadorMenuServicios, se continúa con el caso de uso Ofrecer Servicios.



137. El ManejadorBusqueda solicita desplegarPantallaCorrespondenciaEncontrada a la InterfaceUsuario. La responsabilidad es “solicita desplegarPantallaCorrespondenciaEncontrada a la InterfaceUsuario” y se asigna a la ManejadorBusqueda.

138. La InterfaceUsuario despliega la PantallaCorrespondenciaEncontrada. La responsabilidad es “despliega la

PantallaCorrespondenciaEncontrada” y se asigna a la InterfaceUsuario.

139. La PantallaCorrespondenciaEncontrada se despliega. La responsabilidad es “despliega” y se asigna a la PantallaCorrespondenciaEncontrada.

140. El Usuario puede seleccionar la siguiente actividad: “Menú”. Esta frase es informativa describiendo las diversas opciones del Usuario y no agrega responsabilidades.


PantallaCorrespondenicaEncontrada envía el evento “Menú” a la InterfaceUsuario. La responsabilidad es “envía el evento “Menú” a la InterfaceUsuario” y se asigna a PantallaCorrespondenciaEncontrada.

142. La InterfaceUsuario envía el evento “Menú” al ManejadorBusqueda. La responsabilidad es “envía el evento “Menú” al ManejadorBusqueda” y se debe asignar a InterfaceUsuario. Esta responsabilidad está duplicada y no es necesario volverla a agregar. Adicionalmente, tampoco es necesario agregar la responsabilidad “maneja el evento “Menú” al ManejadorBusqueda, ya que también está duplicada.

143. El ManejadorBusqueda solicita ofrecerServicio al ManejadorMenuServicios, se continúa con el caso de uso Ofrecer Servicios. La responsabilidad es “solicita ofrecerServicio al ManejadorMenuServicios” y se debe asignar al ManejadorRegistroTarjeta. Nuevamente, esta es una responsabilidad


Práctica UCPR-IST


duplicada. La última sección de la frase describe continuación del flujo interno del caso de uso y no agrega nuevas responsabilidades.


InterfaceUsuario anteriormente identificadas en la Tabla 8.3.17 junto con sus





Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:





envía el evento “Búsqueda Correspondencia” al ManejadorMenuServicios (40)

despliega la PantallaBusquedaCorrespondencia(124)

envía el evento “Buscar” al ManejadorBusqueda(128)


despliega la PantallaCorrespondenciaEncontrada(138)

envía el evento “Menú” al ManejadorBusqueda (142)




ManejadorBusqueda anteriormente identificadas en la Tabla 8.3.18 junto con

las nuevas responsabilidades.

Clase: ManejadorBusqueda

Descripción: El manejador Búsqueda es el encargado del manejo de la búsqueda de la correspondencia.



Propiedades:

Superclases:

Subclases:

Atributos:

solicita desplegarPantallaCorrespondenciaEncontrada la InterfaceUsuario (137)


Práctica UCPR-IST



Tabla 8.3.22. Tarjeta para la clase ManejadorBusqueda con responsabilidades



la clase PantallaCorrespondenciaEncontrada, como se muestra en la Tabla

8.3.23.

Clase: PantallaCorrespondenciaEncontrada

Descripción: Pantalla de correspondencia Encontrada (P-6).

Módulo: Correspondencia Encontrada

Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega (139)


Tabla 8.3.23. Tarjeta para la clase PantallaCorrespondenciaEncontrada con



InterfaceBaseDatosCorrespondencia anteriormente identificadas en la Tabla

8.3.29 junto con las nuevas responsabilidades.


Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se accede mediante la interface de la base de datos de Correspondencia. Esto permite validar a los distintos usuarios además de almacenar la información que se desea buscar.



Propiedades:

Superclases:

Subclases:

Atributos:


Tabla 8.3.24. Tarjeta para la clase InterfaceBaseDatosCorrespondencia con



Práctica UCPR-IST




adicionales. Continuamos con el subflujo Búsqueda de Correspondencia (S-4)

del caso de uso Búsqueda de Correspondencia como se muestra a

continuación,

Subflujos

S-4 Informes Correspondencia El ManejadorInformes solicita desplegarPantallaInformesCorrespondencia a la InterfaceUsuario. La InterfaceUsuario despliega a la PantallaInformesCorrespondencia. La PantallaInformesCorrespondencia despliega. Esta pantalla contiene información que debe ser llenada por el Usuario, lo cual incluye fecha inicial y Fecha Final. El Usuario puede seleccionar entre las siguientes actividades: “Generar Informe” y “Menú”. Si el Usuario selecciona “Generar Informes”, la PantallaInformesCorrespondencia envía el evento “Generar Informes” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Generar Informes” al ManejadorInformes. El ManejadorInformes solicita Informe a la InterfaceBaseDatosCorrespondencia. La InterfaceBaseDatosCorrespondencia solicita Informe a la Base de Datos Correspondencia (E-1). La Base de Datos Correspondencia devuelve el OK a la InterfaceBaseDatosCorrespondecia. La InterfaceBaseDatosCorrespondencia devuelve el OK al ManejadorInformes. Si la actividad seleccionada es “Menú”, la PantallaInformesCorrespondencia envía el evento “Menú” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Menú” al ManejadorInformes. El ManejadorInformes cierra la pantallaInformesCorrespondencia y regresa a la pantalla (P-2).




Práctica UCPR-IST


144. El ManejadorInformes solicita desplegarPantallaInformesCorrespondencia a la InterfaceUsuario. La responsabilidad es “solicita desplegarPantallaInformesCorrespondencia a la InterfaceUsuario” y se asigna a ManejadorInformes.

145. La InterfaceUsuario despliega a la PantallaInformesCorrespondencia. La responsabilidad es “despliega la PantallaInformesCorrespondencia” y se asigna a InterfaceUsuario.

146. La PantallaInformesCorrespondencia se despliega. La

responsabilidad es “despliega” y se asigna a PantallaInformesCorrespondencia.

Esta pantalla contiene información que debe ser llenada por el Usuario, lo cual incluye fecha inicial y fecha final. Esta es una frase totalmente informativa por lo cual no agrega responsabilidades.

147. El Usuario puede seleccionar entre las siguientes actividades: “Generar Informe” y “Menú”. Esta es nuevamente una frase informativa sobre las opciones del Usuario y no agrega responsabilidades.

148. Si el Usuario selecciona “Generar Informe”, la PantallaInformesCorrespondencia envía el evento “Informe” a la InterfaceUsuario. Se identifica la responsabilidad “envía el evento “Informe” a la InterfaceUsuario” y se asigna a la PantallaInformesCorrespondencia.

149. La InterfaceUsuario envía el evento “Informe” al

ManejadorInformes. Se identifica la responsabilidad “envía el evento “Informe” al ManejadorInformes” y se asigna a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Informe” al ManejadorInformes.

150. El ManejadorInformes solicita informe a la InterfaceBaseDatosCorrespondencia. Se identifica la responsabilidad “solicita buscar a la InterfaceBaseDatosCorrespondencia” y se asigna al ManejadorInformes.

151. La InterfaceBaseDatosCorrespondencia solicita buscar a la

Base de Datos Correspondencia (E-1). Se identifica la responsabilidad “solicita informe a la Base de Datos Correspondencia” y se asigna a la InterfaceBaseDatosCorrespondencia. Nuevamente, no tiene mucho


Práctica UCPR-IST


sentido asignar responsabilidades a la Base de Datos Correspondencia dado que los actores son externos al sistema.

152. La Base de Datos Correspondencia devuelve el OK a la InterfaceBaseDatosCorrespondencia. No se asigna ninguna responsabilidad a la Base de Datos Correspondencia por ser externa al sistema. Tampoco se agregan responsabilidades por razones de devolución de información.


ManejadorInformes. No se asigna responsabilidades dado que la frase describe una devolución de información.

154. Si la actividad seleccionada es “Menú”, la PantallaInformesCorrespondencia envía el evento “Menú” a la InterfaceUsuario. Se asigna la responsabilidad “envía el evento “Menú” a la InterfaceUsuario” a la PantallaInformesCorrespondencia.


ManejadorInformes. Se asigna la responsabilidad “envía el evento “Menú” al ManejadorInformes” a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Menú”” al ManejadorInformes.

156. El ManejadorInformes sale del sistema. Se asigna la responsabilidad “sale de la búsqueda de correspondencia y regresa a la pantalla (P-2)” al ManejadorInformes.

157. (Si aún no se ha presionado “Generar Informe”, la información que ésta será perdida). Nuevamente, esta es una frase informativa por lo cual no se asignan nuevas responsabilidades.


InterfaceUsuario.


Práctica UCPR-IST





Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:





envía el evento “Informes de Correspondencia” al ManejadorMenuServicios (48)

despliega la PantallaInformesCorrespondencia(145)

envía el evento “Informe” al ManejadorInformes(149)

envía el evento “Menú” al ManejadorInformes(155)




ManejadorInformes.

Clase: ManejadorInformes

Descripción: El manejador Informes es el encargado del manejo de los informes de la correspondencia

Módulo: Informes de Correspondencia


Propiedades:

Superclases:

Subclases:

Atributos:

solicita desplegarPantallaInformes a la InterfaceUsuario (144)

maneja el evento “Informe” (149)

solicita informe a la InterfaceBaseDatosCorrespondencia (150)



Tabla 8.3.26. Tarjeta para la clase ManejadorInformes con responsabilidades



la clase PantallaInformesCorrespondencia como se muestra en la Tabla

8.3.26.1


Práctica UCPR-IST


Clase: PantallaInformesCorrespondencia

Descripción: Pantalla de ingreso de Información para generar informes de correspondencia (P-7).

Módulo: Informes de Correspondencia

Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega (146)

envía el evento “Informe” a la InterfaceUsuario (148)


Tabla 8.3.26.1 Tarjeta para la clase PantallaInformesCorrespondencia con





Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se accede mediante la interface de la base de datos de Correspondencia. Esto permite validar a los distintos usuarios además de almacenar la información que se desea buscar para generar informes.



Propiedades:

Superclases:

Subclases:

Atributos:






Excepciones



Práctica UCPR-IST


Sin embargo, nos concentraremos únicamente en los flujos básicos y no los

alternos. En general, los alternos que son los menos comunes, son importantes

de diseñar pero no en una primera etapa.

Manual de usuario


adicionales. Continuamos con el subflujo Manual de Usuario (S-5) del caso de

uso Búsqueda de Correspondencia como se muestra a continuación,

Subflujos

S-5 Manual de Usuario El ManejadorManual solicita desplegarPantallaManualUsuario a la InterfaceUsuario. La InterfaceUsuario despliega a la PantallaManualUsuario. La PantallaManualUsuario despliega. El Usuario puede seleccionar la siguiente actividad: “Menú”. Si la actividad seleccionada es “Menú”, la PantallaManualUsuario envía el evento “Menú” a la InterfaceUsuario. La InterfaceUsuario envía el evento “Menú” al ManejadorManual. El ManejadorManual cierra la pantallaManualUsuario y regresa a la pantalla (P-2).



158. El ManejadorManual solicita desplegarPantallaManualUsuario

a la InterfaceUsuario. La responsabilidad es “solicita desplegarPantallaManualUsuario a la InterfaceUsuario” y se asigna a ManejadorManual.

159. La InterfaceUsuario despliega a la PantallaManualUsuario. La responsabilidad es “despliega la PantallaManualUsuario” y se asigna a InterfaceUsuario.

160. La PantallaManualUsuario se despliega. La responsabilidad es

“despliega” y se asigna a PantallaManualUsuario.

161. El Usuario puede seleccionar la siguiente actividad: “Menú”. Esta es nuevamente una frase informativa sobre las opciones del Usuario y no agrega responsabilidades.


Práctica UCPR-IST


162. Si la actividad seleccionada es “Menú”, la PantallaManualUsuario envía el evento “Menú” a la InterfaceUsuario. Se asigna la responsabilidad “envía el evento “Menú” a la InterfaceUsuario” a la PantallaManualUsuario.


ManejadorManual. Se asigna la responsabilidad “envía el evento “Menú” al ManejadorManual” a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad “maneja el evento “Menú”” al ManejadorManual.

164. El ManejadorManual sale del sistema. Se asigna la

responsabilidad “sale del manual de usuario y regresa a la pantalla (P-2)” al ManejadorManual.


InterfaceUsuario.




Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:





envía el evento “Manual de Usuario” al ManejadorMenuServicios (56)

despliega la PantallaManualUsuario(159)

envía el evento “Menú” al ManejadorInformes(163)



En la Tabla 8.3.29 Se muestra las responsabilidades para la clase

ManejadorManual.


Práctica UCPR-IST


Clase: ManejadorManual

Descripción: El manejador Informes es el encargado del manejo de del manual de usuario.

Módulo: Manual de Usuario


Propiedades:

Superclases:

Subclases:

Atributos:

solicita desplegarPantallaManualUsuario a la InterfaceUsuario (158)



Tabla 8.3.29. Tarjeta para la clase ManejadorManual con responsabilidades



la clase PantallaInformesCorrespondencia como se muestra en la Tabla 8.3.

30.

Clase: PantallaManualUsuario

Descripción: Pantalla para ver el manual de usuario (P-8).

Módulo: Manual de usuario

Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega (160)


Tabla 8.3.30. Tarjeta para la clase PantallaManualusuario con nuevas




Excepciones



Práctica UCPR-IST


InterfaceUsuario

La clase InterfaceUsuario recibe y envía eventos a un gran número de clases,

algo que es resaltado por la lista extensa de responsabilidades identificadas,

como se muestra en la Tabla 8.3.31.




Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega la PantallaValidación

envía el evento “Aceptar” al ManejadorValidación

envía el evento “Cancelar” al ManejadorValidación

despliega la PantallaMenuServicio

envía el evento “Correspondencia Despachada” al ManejadorMenuServicios

despliega la PantallaCorrespondenciaDespachada

envía el evento “Guardar” al ManejadorDespachada

envía el evento “Modificar” al ManejadorDespachada

envía el evento “Eliminar” al ManejadorDespachada

envía el evento “Menú” al ManejadorDespachada

envía el evento “Correspondencia Recibida” al ManejadorMenuServicios

despliega la PantallaCorrespondenciaRecibida

envía el evento “Guardar” al ManejadorRecibida

envía el evento “Modificar” al ManejadorRecibida

envía el evento “Eliminar” al ManejadorRecibida

envía el evento “Menú” al ManejadorRecibida

envía el evento “Búsqueda de Correspondencia” al ManejadorMenuServicios

despliega la PantallaBusquedaCorrespondencia

envía el evento “Buscar” al ManejadorBusqueda

envía el evento “Menú” al ManejadorBusqueda

envía el evento “Informes Correspondencia” al ManejadorMenuServicios

despliega la PantallaInformesCorrespondencia

envía el evento “Generar Informes” al ManejadorInformes

envía el evento “Menú” al ManejadorInformes

envía el evento “Manual de Usuario” al ManejadorMenuServicios

despliega la PantallaManualUsuario

envía el evento “Menú” al ManejadorManual

envía el evento “Salir” al ManejadorMenuServicios


Práctica UCPR-IST


Tabla 8.3.31. Tarjeta para la clase InterfaceUsario con responsabilidades

identificadas de los casos de uso Validar Usuario, Menú Ofrecer Servicios,

Correspondencia Despachada, Correspondencia Recibida, Búsqueda de

Correspondencia, Informes de Correspondencia y Manual de Usuario.

Validación

Esta sección incluye las clases “Validaciones” de la arquitectura que son el

ManejadorValidación y la PantallaValidación.

La clase ManejadorValidación recibe y envía eventos entre manejadores y la

InterfaceUsuario, como se muestra en la Tabla 8.3.32.


Descripción: El manejador Validación es el encargado de desplegar la pantalla Validación de interacción con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados.



Propiedades:

Superclases:

Subclases:

Atributos:

solicita desplegarPantallaValidación a la InterfaceUsuario

maneja el evento “Aceptar”

solicita ofrecerServicio al ManejadorMenuServicio

solicita validarRegistroUsuario al ManejadorValidación

maneja el evento “Salir”

sale del sistema

Tabla 8.3.32. Tarjeta para la clase ManejadorValidación con responsabilidades

identificadas de los casos de uso ValidarUsuario.

La clase PantallaValidación es la encarga de presentar las opciones de inicio

del sistema, como se muestra en la Tabla 8.3.33.


Práctica UCPR-IST



Descripción: Pantalla Validación (P-1).


Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega

envía el evento “Validar usuario” a la InterfaceUsuario

envía el evento “Aceptar” a la InterfaceUsuario

envía el evento “Cancelar” a la InterfaceUsuario

Tabla 8.3.33. Tarjeta para la clase PantallaValidación con responsabilidades de

interface identificadas de los casos de uso ValidarUsuario.

Usuario

Esta sección involucra las clases de Validación de usuario de usuario que son

ManejadoRegistroUsuario, PantallaValidación

La clase ManejadoRegistroUsuario administra todo lo relacionado con registro

de usuario, lo cual incluye recibir y enviar eventos entre el

ManejadorMenuServicios, la InterfaceUsuario, y la

InterfaceBaseDatosCorrespondencia, como se muestra en la Tabla 8.3.34.

Nótese que eliminamos las frases de tipo “devuelve el OK...”.





Propiedades:

Superclases:

Subclases:

Atributos:

solicita validarRegistroUsuario a la InterfaceBaseDatosCorrespondencia

solicita obtenerRegistroUsuario a la InterfaceBaseDatosCorrespondencia

solicita ofrecerServicio al ManejadorMenuServicio


sale del sistema

Tabla 8.3.34. Tarjeta para la clase ManejadoRegistroUsuario con

responsabilidades identificadas de los casos de uso ValidarUsuario.


Práctica UCPR-IST


Interface Base de Datos

La clase InterfaceBaseDatosCorrespondencia es la encargada de interactuar

con el actor BaseDatosCorrespondencia para escribir y leer la información allí

guardada, tanto de registro de usuario como de archivos de correspondencia,

como se muestra en la Tabla 8.3.35.


Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se accede mediante la interface de la base de datos de Correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre la correspondencia.



Propiedades:

Superclases:

Subclases:

Atributos:

solicita validarRegistroUsuario a la BaseDatosCorrespondencia


responsabilidades de escribir y leer información de registro de usuario y

registro de correspondencia para los casos de uso, ValidarUsuario.

Ofrecer Servicios

La clase ManejadorMenuServicio es la encargada de todo lo relacionado con

Correspondencia despachada, Correspondencia Recibida, Búsqueda de

Informes, Informes Correspondencia y Manual de Usuario. Además de esto, es

responsable de permitir al usuario acceder la información de registro, como se

muestra en la Tabla 8.3.36.


Práctica UCPR-IST


Clase: ManejadorMenuServicio

Descripción: El manejador menú de Ofrecer Servicios se encarga de enviar las peticiones particulares de Ofrecer Servicios a los manejadores especializados para archivar, buscar y generar informes.



Propiedades:

Superclases:

Subclases:

Atributos:

ofrecerServicio

solicita desplegarPantallaMenuServicio a la InterfaceUsuario

maneja el evento “Ofrecer Servicios”

solicita registrar al ManejadorRegistroUsuario


sale del sistema

Tabla 8.3.36. Tarjeta para la clase ManejadorMenuServicio con

responsabilidades a partir de los casos de uso Validar Usuario y Ofrecer

Servicios.

La clase PantallaMenuServicio es la encarga de presentar las opciones de

servicio del sistema, como se muestra en la Tabla 8.3.36.1


Descripción: Pantalla Menú de Ofrecer Servicios (P-2).


Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega

envía el evento “Ofrecer Servcios” a la InterfaceUsuario

Tabla 8.3.36.1 Tarjeta para la clase PantallaMenuServicio con

responsabilidades a partir de los casos de uso Validar Usuario y Ofrecer

Servicios.


Práctica UCPR-IST


8.3.2 COLABORACIONES

Durante el proceso de identificación de las colaboraciones se toma la tarjeta de

clase que juega el papel de cliente, escribiendo en la columna derecha el

nombre de la clase que juega el papel de servidor o sea la clase que colabora

para la responsabilidad particular. Se escribe ese nombre directamente a la

derecha de la responsabilidad a la cual la colaboración ayuda a satisfacer.

Aunque una responsabilidad pudiera requerir de varias colaboraciones, se

escribe el nombre de la clase Validación como servidor de la colaboración. Las

demás clases típicamente pasan a ser parámetros dentro de las llamadas de

métodos al momento de implementarse, por lo cual se pueden mantener como

parte de la responsabilidad general. Por otro lado, si varias responsabilidades

requieren una misma clase para colaborar, se graban varias colaboraciones,

una para cada responsabilidad. Se debe asegurar que la responsabilidad

correspondiente exista para cada colaboración que se grabe. Se debe grabar la

colaboración aunque ésta corresponda a otras instancias de la misma clase. Se

debe omitir si la colaboración corresponde al mismo objeto ya que se busca

identificar relaciones entre objetos o clases pero no llamadas dentro del mismo

objeto. [3]

En esta sección se describen las colaboraciones para el Sistema de

Correspondencia en base a los casos de uso Correspondencia Despachada,

Correspondencia Recibida, Busqueda de Informacion, Informes

Correspondencia y Manual de usuario. Nótese que se omiten actores primarios,

como Usuario, en las colaboraciones, aunque se incluyen los actores

secundarios como BaseDatosCorrespondencia.

InterfaceUsuario

A partir de la Tabla 8.3.36 se generan las colaboraciones para la clase

InterfaceUsuario, como se muestra en la Tabla 8.3.37. Nótese que

simplemente se pasa la clase subrayada en la columna izquierda a la columna

derecha. Este procedimiento se mantiene lo más mecánico posible durante

esta etapa.


Práctica UCPR-IST





Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega PantallaValidación

envía el evento “Aceptar” ManejadorValidación

envía el evento “Cancelar” ManejadorValidación

envía el evento “validar” ManejadorRegistroUsuario

envía el evento “Ofrecer Servicios” ManejadorMenuServicios

despliega PantallaMenuServicios

envía el evento “Correspondencia Despachada”

ManejadorDespachada

envía el evento “Correspondencia Recibida” ManejadorRecibida

envía el evento “Búsqueda Correspondencia ” ManejadorBusqueda

envía el evento “Informes Correspondencia ” ManejadorInformes

envía el evento “Manual de usuario” ManejadorManual

envía el evento “Salir” ManejadorMenuServicios

Tabla 8.3.37. Tarjeta para la clase InterfaceUsario con responsabilidades y

colaboraciones identificadas de los casos de uso, ValidarUsuario.

Validación

Se generan las colaboraciones para la clase ManejadorRegistroUsuario, como

se muestra en la Tabla 8.3.38.





Propiedades:

Superclases:

Subclases:

Atributos:

solicita desplegarPantallaValidación InterfaceUsuario

maneja el evento “Registrarse”

maneja el evento “OK”

solicita ofrecerServicio ManejadorMenuServicio

solicita validarRegistroUsuario ManejadorRegistroUsuario



Práctica UCPR-IST


Tabla 8.3.38. Tarjeta para la clase ManejadorValidación con responsabilidades

y colaboraciones identificadas de los casos de uso, ValidarUsuario.

Se generan las colaboraciones para la clase PantallaValidación, como se





Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega

envía el evento “Aceptar” InterfaceUsuario

envía el evento “Cancelar” InterfaceUsuario

Tabla 8.3.39. Tarjeta para la clase PantallaValidación con responsabilidades y

colaboraciones identificadas de los casos de uso, ValidarUsuario.

Se generan las colaboraciones para la clase RegistroUsuario, como se muestra

en la Tabla 8.3.40. Dado que RegistroUsuario es una clase entidad, sus

responsabilidades por lo general no involucran colaboraciones. En este caso

aún no se han asignado dichas responsabilidades.

Clase: RegistroUsuario

Descripción: Para poder utilizar el sistema de correspondencia, el usuario debe estar registrado con el sistema. El registro contiene información acerca del usuario que incluye nombre de Usuario y Clave.

Módulo: RegistroUsuario

Estereotipo: Entidad

Propiedades:

Superclases:

Subclases:

Atributos:

Módulo: RegistroUsuario


Tabla 8.3.40. Tarjeta para la clase RegistroUsuario sin responsabilidades ni

colaboraciones de registro para el caso de uso RegistrarUsuario.


Práctica UCPR-IST


Ofrecer Servicios

Se generan las colaboraciones para la clase ManejadorMenuServicio, como se



Descripción: El manejador menú de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores especializados para consulta, reserva y compra.

Módulo: Servicio


Propiedades:

Superclases:

Subclases:

Atributos:

ofrecerServicio

solicita desplegarPantallaServicio InterfaceUsuario

maneja el evento “Obtener Registro”

solicita Validar ManejadorRegistroUsuario


sale del sistema


responsabilidades y colaboraciones a partir de los casos de uso

ValidarUsuario.

Se generan las colaboraciones para la clase PantallaMenuServicio, como se



Descripción: Pantalla de menú servicios (P-2).

Módulo: Servicio

Estereotipo: Borde

Propiedades:

Superclases:

Subclases:

Atributos:

despliega

envía el evento “Validar Registro Usuario” InterfaceUsuario

Tabla 8.3.42. Tarjeta para la clase PantallaMenuServicio con responsabilidades

y colaboraciones a partir de los casos de uso ValidarUsuario.


Práctica UCPR-IST


8.3.3 JERARQUÍAS

El diseño de las jerarquías de herencia es uno de los aspectos de

programación más importantes de la orientación a objetos. Mediante la

herencia se puede lograr una buena reutilización del código del sistema,

logrando arquitecturas de clases más compactas lo cual puede reducir

radicalmente el tamaño del sistema final.

La herencia se identifica a partir de las responsabilidades y colaboraciones

obtenidas anteriormente. De manera general, existen dos formas de

aprovechar la herencia. La forma más común es la creación de superclases

que guarden responsabilidades comunes a múltiples clases. [3]

A continuación se describen las jerarquías de herencia para el Sistema de

Correspondencia en base al casos de uso ValidarUsuario.

InterfaceUsuario

Para comenzar analizamos las diversas responsabilidades y colaboraciones

asignadas a la clase InterfaceUsuario como se muestra en la Tabla 8.3.43.

despliega PantallaValidación

envía el evento “Aceptar” ManejadorRegistroUsuario

envía el evento “Cancelar” ManejadorRegistroUsuario

despliega PantallaMenuServicio

Tabla 8.3.43. Responsabilidades y colaboraciones para la clase InterfaceUsario.

Si analizamos estas responsabilidades y colaboraciones con más detalle

podemos apreciar que hay dos grupos de responsabilidades, aquellos

correspondientes a “despliega” y las correspondientes a “envía el evento...”,

como se muestra de manera condensada en la Tabla 8.3.44. Es importante

apreciar que estamos generalizando las diversas responsabilidades “envía el

evento” en una común en donde el evento particular “OK”, “Validar”, etc., son

abstraídos de la responsabilidad.

despliega PantallaValidación, PantallaMenuServicio,

envía el evento ... ManejadorMenuServicio, ManejadorRegistroUsuario,

Tabla 8.3.44. Grupos de responsabilidades y colaboraciones para la clase InterfaceUsario.


Práctica UCPR-IST


En el caso de la responsabilidad “despliega” la responsabilidad se llama

también “despliega” para todas las clases colaboradoras PantallaValidación,

PantallaMenuServicio, como se muestra a continuación, Esto es sumamente

importante si deseamos aprovechar el polimorfismo.

despliega

Grupos de responsabilidades “despliega” para las distintas pantallas,

correspondientes a las clases PantallaValidación, PantallaMenuServicio.

En el caso de los manejadores vemos que ManejadorMenuServicio,

ManejadorRegistroUsuario, todos tienen una responsabilidad común

“manejarEvento” correspondiente a la responsabilidad inicial “envía el evento”,

como se muestra a continuación.

manejarEvento

Grupos de responsabilidades “manejarEvento” para los distintos manejadores,

correspondientes a las clases ManejadorValidación, MnajeadorMenuServicio,

ManejadorRegistroUsuario.

Estos dos grupos de responsabilidades se muestran en la Figura 8.3.1. Nótese

que la dirección de la flecha representa la dirección de la llamada de servicio, o

sea en dirección de la clase colaboradora. Para el nombre de la asociación

utilizamos la responsabilidad definida en la clase colaboradora

correspondiente.


Práctica UCPR-IST


Figura 8.3.1. El diagrama muestra las colaboraciones descritas hasta el

momento para la clase InterfaceUsuario.

Interface Usuario (From Interface Usuario)

Pantalla Validación (From Validación)

Pantalla Menú Servicios (From Servicios)

Pantalla Correspondencia Despachada

(From Despachada)

Pantalla Correspondencia Recibida

(From Recibida)

Pantalla Búsqueda Correspondencia (From Búsqueda)

Pantalla Informes Correspondencia (From Informes)

Pantalla Manual de Usuario

(From Manual)

ManejadorRegistroUsuario (From Validación)

ManejadorMenuServicio (From Servicios)

ManejadorDespachada (From Despachada)

ManejadorRecibida (From Recibida)

ManejadorBusqueda (From Busqueda)

ManejadorInformes (From Informes)

ManejadorManual (From Manual)

Despliega

Despliega

Despliega

Despliega

Despliega

Despliega

ManejarEvento

ManejarEvento

ManejarEvento

ManejarEvento

ManejarEvento

ManejarEvento

ManejarEvento Despliega

ManejadorValidacion (From Validación)


Práctica UCPR-IST


En la Tabla 8.3.45. Se relación de colaboración se simplifica, aún incluimos la

lista de clases colaboradoras para no perder esta información a nivel

descriptiva. Esto se denota utilizando la notación de “superclase” seguida por

“:” y finalmente por la lista de “clases colaboradoras”. Sin embargo, el objetivo

de diseño es que la InterfaceUsuario deja de conocer explícitamente a todas

las clases colaboradoras y que únicamente conozca a la clase general que

luego será sobrecargada.

despliega Pantalla : PantallaValidación, PantallaMenuServicio, PantallaCorrepondenciaDespachada, PantallaCorrespondenciaRecibida, PantallaBusquedaCorrespondencia, PantallaInformesCorrespondencia, PantallaManualUsuario.

envía el evento ...

Manejador: ManejadorValidación, ManejadorRegistroUsuario, ManejadorMenuServicio, ManejadorDespachada, ManejadorRecibida, ManejadorBusqueda, ManejadorInformes, ManejadorManual.

Tabla 8.3.45. Grupos de responsabilidades y colaboraciones para la clase

InterfaceUsuario revisados según la creación de dos nuevas superclases:

Pantalla y Manejador.

En la Figura 8.3.2 se muestra la nueva jerarquía de herencia.


Práctica UCPR-IST


Figura 8.3.2 El diagrama muestra las colaboraciones descritas hasta el

momento para la clase InterfaceUsuario luego de la introducción de las

superclases Pantalla y Manejador.

Es importante resaltar que se tendrá que agregar una nueva interface de clase

correspondiente a las nuevas clases Pantalla y Manejador recién introducidas.

Dichas interface deberán incluir responsabilidades correspondientes a

“despliega” y “manejarEvento” que serán sobrescritas por las diversas pantallas

y manejadores en la jerarquía de herencia.




(From Despachada)


(From Recibida)




(From Manual)









Pantalla (From Interface Usuario)

Manejador (From Validación)

Despliega ManejarEvento



Práctica UCPR-IST


La interface de clase modificada para la clase InterfaceUsuario se muestra en

la Tabla 8.3.46. Como parte del proceso de afinación de nombres cambiamos

“despliega” por “desplegarPantalla”, el cual es más descriptivo, y “envía el

evento...” por “enviarEvento” lo cual es más compacto. De tal manera, se

reducen de manera radical el número de responsabilidades y colaboraciones

de la clase InterfaceUsuario. Nótese como los diversos “envía el evento ...” son

abstraídos o generalizados por una sola responsabilidad más genérica llamada

enviarEvento. Vale la pena resaltar la gran reducción en el número de

responsabilidades y colaboraciones definidas para la clase InterfaceUsuario.




Estereotipo: Borde

Propiedades: Concreta

Superclases:

Subclases:

Atributos:

desplegarPantalla Pantalla: PantallaValidación, PantallaMenuServicio, PantallaBusquedaCorrespondencia, PantallaCorrespondenciaEncontrada.

enviarEvento

Manejador:ManejadorValidación ManejadorRegistroUsuario, ManejadorMenuServicio, ManejadorBusqueda.

Tabla 8.3.46. Tarjeta para la clase InterfaceUsuario con responsabilidades,

colaboraciones y jerarquías identificadas de los casos de uso ValidarUsuario.

Antes de especificar la tarjeta de clase para la nueva superclase Pantalla

veamos otra fuente de generalización a partir de las diversas pantallas.

En la Tabla 8.3.47 se muestra de manera compacta las responsabilidades y

colaboraciones para las diversas pantallas descritas en la sección de

colaboraciones. Las diversas pantallas contienen una responsabilidad

“despliega” y otra “envía el evento ...”, la cual colabora con InterfaceUsuario.

Nuevamente abstraemos las diversas responsabilidades “enviar el evento...” en

una sola.

despliega

envía el evento ... InterfaceUsuario

Tabla 8.3.47. Grupos de responsabilidades y colaboraciones para las diversas

pantallas.


Práctica UCPR-IST


Estas responsabilidades con sus colaboraciones se muestran en la Figura 8.3.

3 Nótese que la dirección de la flecha va ahora en dirección de la

InterfaceUsuario. Para el nombre de la asociación utilizamos la responsabilidad

reescrita “enviarEvento” definida en la clase InterfaceUsuario, la clase

colaboradora.

Figura 8.3.3. El diagrama muestra las colaboraciones descritas a partir de las

diversas pantallas y en dirección a la InterfaceUsuario.

Esta es nuevamente una fuente de polimorfismo donde podemos aprovechar la

clase Pantalla antes agregada. En la Figura 8.3.4 se muestra el diagrama de

herencia correspondiente a la Figura 8.3.3 incluyendo la nueva superclase

Pantalla en base al polimorfismo “enviarEvento” a partir de las diversas

pantallas.




(From Despachada)


(From Recibida)




(From Manual)

EnviarEvento


EnviarEvento

EnviarEvento

EnviarEvento

EnviarEvento

EnviarEvento

EnviarEvento


Práctica UCPR-IST


Figura 8.3.4 El diagrama muestra las colaboraciones descritas a partir de las

diversas pantallas conteniendo la superclase Pantalla y en dirección a la

InterfaceUsuario.

La responsabilidad “envía el evento...” es rescrita como “enviarEvento” y junto

con “desplegarPantalla” definen las responsabilidades para la clase Pantalla,

como se muestra en la Tabla 8.3.48. La clase Pantalla es definida como

Abstracta ya que es una superclase. Adicionalmente, en la sección de

subclases se describen las diversas clases que heredan de ella.




(From Despachada)


(From Recibida)




(From Manual)

EnviarEvento


EnviarEvento

EnviarEvento

EnviarEvento

EnviarEvento

EnviarEvento

EnviarEvento


Práctica UCPR-IST


Clase: Pantalla

Descripción: Pantalla heredada por las demás clases de tipo pantalla.


Estereotipo: Borde

Propiedades: Abstracta

Superclases:

Subclases: PantallaValidación, PantallaMenuServicio, PantallaCorrespondenciaDespachada, PantallaCorrespondenciaRecibida, PantallaBusquedaCorrespondencia, PantallaInformesCorrespondencia, PantallaManualUsuario.

Atributos:

desplegarPantalla

enviarEvento InterfaceUsuario

Tabla 8.3.48. Tarjeta para la superclase clase Pantalla con responsabilidades,

colaboraciones y jerarquías identificadas de los casos de uso Validar Usuario,

Ofrecer Servicios, Correspondencia Despachada, Correspondencia Recibida,

Búsqueda de Correspondencia, Informes Correspondencia y Manual de

Usuario.

Antes de continuar con la superclase Manejador aprovecharemos para agregar

dos nuevas superclases de tipo pantallas agregadas exclusivamente por

razones de herencia y no polimorfismo. Esta clase es

PantallaCorrespondenciaEncontrada la cual define elementos comunes a la

pantalla PantallaBusquedaCorrespondencia y la cual define elementos

comunes a las pantallas PantallaCorrespondenciaDespachada y

PantallaCorrespondenciaRecibida. Los elementos comunes para estas

pantallas son básicamente todos los campos de textos que se repiten entre

ellas, difiriendo únicamente en los botones.

En la Figura 8.3.5 se muestra la jerarquía de herencia a partir de la clase

Pantalla y conteniendo las clases PantallaCorrespondenciaEncontrada.


Práctica UCPR-IST


Figura 8.3.5 El diagrama muestra la jerarquía de clases para el módulo de

registro a partir de la clase Pantalla incluyendo las clases

PantallaCorrespondenciaEncontrada.

En la Tabla 8.3.49 se describe la clase Pantalla redefinida de acuerdo a las

modificaciones con las clases PantallaCorrespondenciaEncontrada,

correspondiente a la Figura 8.3.5. El cambio se da únicamente en la sección de

subclases.




(From Despachada)


(From Recibida)




(From Manual)


Pantalla Correspondencia Encontrada

(From Búsqueda)


Práctica UCPR-IST


Clase: Pantalla



Estereotipo: Borde


Superclases:

Subclases: PantallaValidación, PantallaMenuServicio, PantallaBusquedaCorrespondencia, PantallaCorrespondenciaEncontrada

Atributos:

desplegarPantalla



colaboraciones y jerarquías revisadas.

Validación

A continuación llevaremos un proceso de generalización para la clase

Manejador similar al proceso llevado a cabo para la clase Pantalla. En la Tabla

8.3. 50 se muestra de manera compacta las responsabilidades y

colaboraciones comunes para los diversos manejadores descritos en la sección

de colaboraciones. Los diversos manejadores contienen una responsabilidad

“manejarEvento” que es sobrescrita por cada uno de ellos, una responsabilidad

“solicita desplegarPantalla...” en colaboración con la InterfaceUsuario y que

puede ser generalizada de manera similar a “envía el evento...”, una

responsabilidad “solicita ofrecerServicio” en colaboración con

ManejadorMenuServicio que es común a los diversos manejadores y otra

responsabilidad común “salir”. Los diversos manejadores contienen otras

responsabilidades pero estas ya no son comunes entre ellos.

manejarEvento

Solicita desplegarPantalla... InterfaceUsuario

solicita ofrecerServicio ManejadorMenuServicio

salir

Tabla 8.3.50. Grupos de responsabilidades y colaboraciones para los diversos

manejadores.

La responsabilidad “solicita desplegarPantalla...” puede ser reescrita

simplemente como “desplegarPantalla” mientras que “solicita ofrecerServicio”

puede ser reescrita como “ofrecerServicio”. Estas responsabilidades junto con


Práctica UCPR-IST


sus colaboraciones correspondientes se muestran en la Figura 8.3. 6.

Nuevamente, la responsabilidad

“desplegarPantalla” debe existir en la clase InterfaceUsuario y “ofrecerServicio”

en la clase ManejadorMenuServicio para que el diagrama sea correcto.

Figura 8.3.6 El diagrama muestra las colaboraciones descritas a partir de los

diversos manejadores y en dirección a la InterfaceUsuario y

ManejadorMenuServicio.

Con la introducción de la clase Manejador se puede generalizar estas

relaciones y aprovechar el polimorfismo correspondiente. En la Figura 8.3.7 se

muestra el diagrama de herencia correspondiente a la Figura 8.3.6 con la

inclusión de la nueva superclase Manejador.






(From Búsqueda)

DesplegarPantalla

OfrecerServicios

DesplegarPantalla

OfrecerServicios

OfrecerServicios

DesplegarPantalla

DesplegarPantalla


Práctica UCPR-IST


Figura 8.3.7 El diagrama muestra las colaboraciones descritas a partir de los

diversos manejadores conteniendo la superclase Manejador y en dirección a la

InterfaceUsuario y ManejadorMenuServicio.

Las responsabilidades anteriores para los diversos manejadores son ahora

descritos en la superclase Manejador, como se muestra en la Tabla 8.3. 51. La

clase Manejador es definida como Abstracta ya que es una superclase. En la

sección de subclases se agregan las diversas clases que heredan de ella.

Clase: Manejador

Descripción: Superclase heredada por todos los manejadores del sistema.




Superclases:

Subclases: ManejadorValidación, ManejadorRegistroUsuario ManejadorMenuServicio, ManejadorCorrespondenciaDespachada, ManejadorCorrespondenciaRecibida, ManejadorBusquedaCorrespondencia, ManejadorInformesCorrespondencia, ManejadorManual.

Atributos:





ManejadorBusqueda (From Búsqueda)





DesplegarPantalla OfrecerServicio



Práctica UCPR-IST


manejarEvento

desplegarPantalla InterfaceUsuario

ofrecerServicio ManejadorMenuServicio

salir

Tabla 8.3.51. Tarjeta para la clase Manejador con responsabilidades,

colaboraciones y jerarquías identificadas de los diversos manejadores para los

casos de uso Validación usuario, Ofrecer Servicios, Correspondencia

Despachada, Correspondencia Recibida, búsqueda de correspondencia,

Informes Correspondencia y manual de usuario,

En la Figura 8.3.8 se muestra la jerarquía de herencia a partir de la superclase

Manejador.

Figura 8.3.8. El diagrama muestra la jerarquía de clases a partir de la clase

Manejador.

Ahora veamos cómo se describen las demás clases a partir de estas

modificaciones de herencia. Se generan las jerarquías para la clase

ManejadorValidación, como se muestra en la Tabla 8.3. 52. La clase se define

como concreta y se especifica su superclase. La única responsabilidad

sobrescrita de las definidas en la superclase Manejador es “manejarEvento” ya

que el polimorfismo va en dirección de la clase InterfaceUsuario a los diversos

manejadores. Las demás responsabilidades descritas en Manejador son











Práctica UCPR-IST


únicamente heredadas por los diversos manejadores. Adicionalmente la clase

ManejadorValidación definía las responsabilidades “solicita

“solicita validarRegistroUsuario”.

.


Descripción: El manejador Validación es el encargado de desplegar la pantalla validación de interacción con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados.




Superclases: Manejador

Subclases:

Atributos:

manejarEvento

validarRegistroUsuario ManejadorRegistroUsuario

Tabla 8.3.52. Tarjeta para la clase ManejadorValidación con responsabilidades,

colaboraciones y jerarquías identificadas del caso de uso, ValidarUsuario.

En el caso de las pantallas, todas las responsabilidades se especifican en la

superclase Pantalla por lo cual ya no hay necesidad de incluir las

responsabilidades descritas anteriormente. Por lo tanto, la clase

PantallaValidación, se describirá de acuerdo a las modificaciones en las

jerarquías de herencia, como se muestra en la Tabla 8.3.53. Se eliminan las

responsabilidades y se especifica la clase como concreta y se agrega su

superclase.




Estereotipo: Borde


Superclases: Pantalla

Subclases:

Atributos:

Tabla 8.3.53. Tarjeta para la clase PantallaValidación con responsabilidades,

colaboraciones y jerarquías identificada en el caso de uso ValidarUsuario.


Práctica UCPR-IST


8.3.4 Dominio

Si consideramos que hemos agregado una nueva superclase para las diversas

pantallas correspondientes a las clases borde al igual para los diversos

manejadores correspondientes a las clases de control, resulta que sería

también una buena idea agregar una superclase para las diversas clases

entidad. Estos no es obvio en este momento ya que nuestras clases entidad,

RegistroUsuario y RegistroCorrespondencia, no tienen responsabilidades

asignadas aún. Sin embargo, agregar una superclase a grupos de clases con

estereotipo común es siempre una buena idea.

En la Figura 8.3.9 se muestra la jerarquía de herencia a partir de una

superclase general llamada Datos.

Figura 8.3.9. El diagrama muestra la jerarquía de clases para el módulo de

registro a partir de la clase Datos.

La superclase Datos que generaliza a las diferentes clases entidad, en este

caso RegistroUsuario y RegistroCorrespondencia, se muestra en la Tabla

8.3.54.

Clase: Datos

Descripción: Superclase para todas las clases entidad.

Módulo: Dominio



Superclases:

Subclases: RegistroUsuario, Registro Correspondencia

Atributos:

Tabla 8.3.54. Tarjeta para la clase Datos con responsabilidades,

colaboraciones y jerarquías identificadas de las diversas clases entidad para

Datos (From Dominio)

Registro Correspondencia (From RegistroCorrespondencia)

Registro Usuario (From RegistroUsuario)


Práctica UCPR-IST


los casos de uso, Validar Usuario, Ofrecer Servicios, Correspondencia

Despachada, Correspondencia Recibida, Búsqueda de Correspondencia,

Informes Correspondencia y Manual de Usuario.

Registro

Este módulo se compone de los módulos de Usuario e InterfaceBD.

Usuario

Esta sección involucra las clases de registro de usuario que son

ManejadoRegistroUsuario, RegistroUsuario. Se describe la clase

ManejadoRegistroUsuario, como se muestra en la Tabla 8.3. 55. Con

excepción de “manejarEvento” sobrescrita por todos los manejadores, las

responsabilidades

“desplegarPantalla”, “ofrecerServicio” y “salir” son descritas únicamente en la

superclase Manejador.







Subclases:

Atributos:

manejarEvento

validarRegistroUsuario InterfaceBaseDatosCorrespondencia


responsabilidades, colaboraciones y jerarquías identificada en el caso de uso

ValidarUsuario.

Se generan las jerarquías para la clase RegistroUsuario, como se muestra en

la Tabla 8.3.56. Nótese que RegistroUsuario es una subclase de la recién

introducida clase Datos.


Descripción: Para poder utilizar el sistema de Correspondencia, el usuario debe estar registrado con el sistema. El registro contiene información acerca del usuario que incluye nombre de Usuario y clave.





Práctica UCPR-IST


Superclases: Datos

Subclases:

Atributos:

Tabla 8.3.56. Tarjeta para la clase RegistroUsuario con responsabilidades,

colaboraciones y jerarquías.

Actualizar y consultar información de registro para el caso de uso

RegistrarUsuario.

Interface Base Datos

Como se muestra en la Tabla 8.3.57. Se reescriben las responsabilidades

eliminando la palabra “solicita”.


Mediante la interface de la base de datos de correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre la correspondencia.

Módulo: Registro.InterfaceDB

Estereotipo: Borde


Superclases:

Subclases:

Atributos:

validarRegistroUsuario BaseDatosCorrespondencia


responsabilidades, colaboraciones y jerarquías de leer información de registro

de usuario y registro de tarjeta para el caso de uso ValidarUsuario.

Ofrecer Servicios

La clase ManejadorMenuServicio, como se muestra en la Tabla 8.3.58. Los

cambios son similares a los demás manejadores.


Descripción: El manejador menú de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores especializados para consulta, reserva y compra.

Módulo: Servicios


Práctica UCPR-IST





Subclases:

Atributos:

manejarEvento

ofrecerServicio

registrar ManejadorRegistroUsuario


responsabilidades, colaboraciones y jerarquías, a partir de los casos de uso

RegistrarUsuario.

La clase PantallaMenuServicio, como se muestra en la Tabla 8.3.59.


Descripción: Pantalla menú de servicios (P-2).

Módulo: Servicios

Estereotipo: Borde



Subclases:

Atributos:

Tabla 8.3.59. Tarjeta para la clase PantallaMenuServicio con

responsabilidades, colaboraciones y jerarquías a partir de los casos de uso

ofrecer servicios.

8.3.5 CONTRATOS

Un contrato es una mecanismo de diseño para agrupar las distintas

responsabilidades de una clase que están relacionadas lógicamente entre si.

Los contratos sirven como indicadores de los diversos servicios provistos por

cada clase. El objetivo final del contrato es ser un elemento de abstracción

adicional en el manejo de la complejidad

del sistema, dado que la funcionalidad completa del sistema dada a bajo nivel

por las responsabilidades, puede ser vista a alto nivel como un grupo de

servicios o contratos.

El contrato no es simplemente otro nombre para la responsabilidad, ya que la

responsabilidad corresponde a una acción específica, mientras que un contrato

define un conjunto de responsabilidades cercanas una de la otra.


Práctica UCPR-IST


Cada responsabilidad puede ser parte de un sólo contrato, aunque no tiene que

ser necesariamente parte de algún contrato. Esto ocurre cuando las

responsabilidades representan comportamiento que una clase debe tener, pero

que son privadas a los propios objetos. En general, una clase puede apoyar

uno o más contratos, aunque a menudo una clase con varias responsabilidades

apoya un sólo contrato. [3]

En esta sección se describen los contratos para el Sistema de

Correspondencia, en base a los casos de uso, Validar Usuario, ofrecer

servicios, Correspondencia Despachada, Correspondencia Recibida, Búsqueda

de Información, Informes de Correspondencia y manual de usuario.

InterfaceUsuario

Consideremos las dos responsabilidades “desplegarPantalla” y “enviarEvento”

asignadas a la clase InterfaceUsuario en la sección anterior de jerarquías las

cuales se muestran en la Tabla 8.3.59.

desplegarPantalla Pantalla : PantallaValidación, PantallaServicio, PantallaCrearRegUsuario, PantallaObtenerRegUsuario,

enviarEvento Manejador : ManejadorValidación, ManejadorRegistroUsuario, ManejadorRegistroTarjeta ManejadorValidación, ManejadorMenuServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta

Tabla 8.3.59. Responsabilidades asignadas a la clase InterfaceUsario luego de

la etapa de jerarquías.

Si investigamos con mayor detalle estas responsabilidades podemos ver que

“desplegarPantalla” es llamada por los diversos manejadores mientras que

“enviarEvento” es llamada por las diversas pantallas, algo que se muestra en la

Figura 8.3.10. Nótese que las colaboraciones que aparecen en la Tabla 8.3. 59

se dan más adelante en la colaboración, mientras que aquí mostramos las

clases que solicitan servicio a las responsabilidades descritas en la clase

InterfaceUsuario.


Práctica UCPR-IST


Figura 8.3.10. El diagrama muestra a las diversas clases manejadores y

pantallas solicitando servicios de la clase InterfaceUsuario a través de

“desplegarPantalla” y “enviarEvento”, respectivamente




(From Despachada)


(From Recibida)




(From Manual)











EnviarEvento DesplegarPantalla


(From Búsqueda)



Práctica UCPR-IST


Estos dos grupos de relaciones realmente están definiendo dos contratos

teniendo como servidor a la clase InterfaceUsuario. El primer contrato lo

llamaremos “desplegarPantalla”, al igual que la responsabilidad

correspondiente, teniendo como cliente a los diversos manejadores y como

servidor a la InterfaceUsuario. Lo identificaremos como el contrato número “1”

de la clase InterfaceUsuario. El segundo contrato lo llamaremos “enviarEvento”,

al igual que la responsabilidad correspondiente, teniendo como cliente a las

diversas pantallas y como servidor a la clase InterfaceUsuario. Lo

identificaremos como el contrato número “2” de la clase InterfaceUsuario.

Históricamente se describían tarjetas de contratos describiendo cada uno de

los contratos en término de los clientes y servidor involucrado. Nosotros

omitiremos esta descripción ya que la información está implícita aunque

distribuida en la diversas tarjetas.

En general, toda documentación adicional tiene un precio no sólo en su

generación sino más importante en su mantenimiento. En este caso decidimos

reducir esta documentación adicional. En otras situaciones donde lo

documentación aún no exista, será necesario agregarla.

De tal manera y a partir de la Tabla 8.3. 46 se generan los contratos para la

clase InterfaceUsuario, como se muestra en la Tabla 8.3.60. Se asignan

nuevas entradas por contratos mientras que las responsabilidades se

mantienen igual únicamente asignándolas a los diferentes contratos

identificados. Del lado derecho se mantienen las mismas colaboraciones

originales para cada contrato. Los nombres de los contratos pueden ser

distintos al de las responsabilidades y en general deben ser más descriptivos.

Para resaltar el hecho de que son descripciones generales les asignaremos el

nombre “Desplegar Pantalla” al primer contrato y “Enviar Evento” al segundo.


Práctica UCPR-IST





Estereotipo: Borde


Superclases:

Subclases:

Atributos:

Contratos

1. Desplegar Pantalla

desplegarPantalla Pantalla : PantallaValidación, PantallaMenuServicio, PantallaCorrespondenciaDespachada, PantallaCorrespondenciaRecibida, PantallaBusquedaCorrespondencia, PantallaInformesCorrespondencia, PantallaManualUsuario.

2. Envíar Evento

envíarEvento Manejador : ManejadorValidación, ManejadorRegistroUsuario, ManejadorMenuServicio, ManejadorDespachada, ManjadorRecibida, ManejadorBusqueda, ManejadorInformes, ManejadorManual


colaboraciones, jerarquías y contratos identificadas de los casos de uso,

Validar Usuario, Ofrecer Servicios, Correspondencia Despachada,

Correspondencia Recibida, Búsqueda de Correspondencia, Informes de

Correspondencia y Manual de Usuario.

De manera similar podemos identificar dos grupos de responsabilidades

lógicamente separadas para las diversas pantallas, “desplegarPantalla” y

“enviarEvento”, ambas definidas en la superclase Pantalla, como se muestra en

la Tabla 8.3. 61 a partir de las responsabilidades definidas para la clase

Pantalla en la Tabla 8.3. 48. Dio la casualidad que dichas responsabilidades

corresponden a los mismos nombres en la clase InterfaceUsuario, sin embargo

representan responsabilidades por separados.

desplegarPantalla



Práctica UCPR-IST


Tabla 8.3.61. Responsabilidades para la superclase clase Pantalla definidas en

la Tabla 8.3.48 en la sección de jerarquías.

Si analizamos estas responsabilidades podemos observar que

“desplegarPantalla” tiene como cliente a la InterfaceUsuario. Sin embargo

“enviarEvento” no tiene ningún cliente identificado por lo cual la convertiremos

en una responsabilidad privada. Nótese que esta responsabilidad colabora con

los diversos manejadores a través de la superclase Manejador. En general,

tanto las responsabilidades privadas como las públicas, a través de sus

contratos, pueden tener ambas colaboradores. En la Figura 8.3.11. Se muestra

la clase InterfaceUsuario que solicita servicio a las responsabilidades de las

diversas pantallas a través de las responsabilidades descritas en la clase

Pantalla.

Figura 8.3.11. El diagrama muestra la clase InterfaceUsuario como cliente de

las diversas pantallas a través de la responsabilidad “desplegarPantalla” de la

clase Pantalla.

Asignaremos como contrato número “1” a “desplegarPantalla”, mientras que

“enviarEvento” será una responsabilidad privada. En base a estas

consideraciones y a partir de la Tabla 8.3.48 se genera la descripción para la

clase Pantalla, como se muestra en la Tabla 8.3. 62. Nótese en la columna

derecha como InterfaceUsuario aparece como colaborador de la

responsabilidad “enviarEvento” a pesar de que ésta es privada.

Adicionalmente, se agregó un “2” entre paréntesis a la derecha de la clase

colaboradora InterfaceUsuario. Este “2” corresponde al contrato número “2”

Pantalla Validación

(From Validación)



(From Despachada)


(From Recibida)




(From Manual)

Interface Usuario (From Interface

Usuario)


Desplegar Pantalla


(From Búsqueda)


Práctica UCPR-IST


definido en la clase InterfaceUsuario, en otras palabras el contrato “Enviar

Evento”. Agregando este número tenemos información adicional sobre la

colaboración entre clases pero a nivel de contratos.

Clase: Pantalla



Estereotipo: Borde


Superclases:

Subclases: PantallaValidación, PantallaMenuServicio, PantallaCorrespondenciaDespachada, PantallaCorrespondenciaRecibida, PantallaBusquedaCorrespondencia, PantallaInformesCorrespondencia, PantallaManualUsuario.

Atributos:

Contratos


desplegarPantalla

Responsabilidades Privadas

enviarEvento InterfaceUsuario (2)


colaboraciones, jerarquías y contratos identificadas de los casos de uso Validar

Usuario, Ofrecer Servicios, Correspondencia Despachada, Correspondencia

Recibida, Búsqueda de Correspondencia, Informes Correspondencia y Manual

de Usuario.

Validación

De manera similar a Pantalla podemos identificar cuatro grupos de

responsabilidades lógicamente separadas para los diversos manejadores,

“manejarEvento”, “desplegarPantalla”, “ofrecerServicio” y “salir”, todos definidos

en la superclase Manejador, como se muestra en la Tabla 8.3.63 a partir de las

responsabilidades definidas para la clase Manejador en la Tabla 8.3.51.

manejarEvento

desplegarPantalla InterfaceUsuario

ofrecerServicio ManejadorMenuServicio

salir

Tabla 8.3.63. Responsabilidades para la superclase clase Manejador definidas

en la Tabla 8.3.53 en la sección de jerarquías.


Práctica UCPR-IST


Si analizamos estas responsabilidades podemos observar que “manejarEvento”

tiene como cliente a la InterfaceUsuario. Sin embargo, las otras tres

responsabilidades, “desplegarPantalla”, “ofrecerServicio” y “salir”, no tiene

ningún cliente externo a la clase por lo cual la convertiremos en

responsabilidades privadas. Nótese nuevamente que dos de estas

responsabilidades colaboran con otras clases a pesar de ser privadas. En la

Figura 8.3.12. Se muestra la clase InterfaceUsuario que solicita servicio a las

responsabilidades de los diversos manejadores a través de la responsabilidad

“manejarEvento” descrita en la clase Manejador.

Figura 8.3.12 El diagrama muestra la clase InterfaceUsuario como cliente de

los diversos manejadores a través de la responsabilidad “manejarEvento” de la

clase Manejador.

Asignaremos como contrato número “1” a “manejarEvento”, mientras que

“desplegarPantalla”, “ofrecerServicio” y “salir”, serán responsabilidades

privadas. En base a estas consideraciones, se genera la descripción para la

clase Manejador, como se muestra en la Tabla 8.3.64. Nótese en la columna

derecha como InterfaceUsuario aparece como colaborador de la

responsabilidad “desplegarPantalla” a pesar de que ésta es privada.

Adicionalmente, se agregó un “1” entre paréntesis a la derecha de la clase

colaboradora InterfaceUsuario.

Este “1” corresponde al contrato número “1” definido en la clase

InterfaceUsuario, en otras palabras el contrato “Desplegar Pantalla”.

Adicionalmente se agregó el número “2” entre paréntesis a la derecha de la

clase colaboradora ManjeadorMenuServicio para la responsabilidad

“ofrecerServicio”, correspondiente al contrato “2” (aún no definido) para la clase










ManejarEvento



Práctica UCPR-IST


ManejadorMenuServicio. Los contratos para la clase Manejador se muestran

en la Tabla 8.3.64.

Clase: Manejador

Descripción: Superclase heredada por todos los manejadores del sistema.




Superclases:

Subclases: ManejadorValidación, ManejadorMenuServicio, ManejadorRegistroUsuario, ManejadorDespachada, ManejadorRecibida, ManejadorBusqueda, ManejadorInformes, ManejadorManual

Atributos:

Contratos

1. Manejar Evento

manejarEvento


desplegarPantalla InterfaceUsuario (1)

ofrecerServicio ManejadorMenuServicio (2)

salir


colaboraciones, jerarquías y contratos identificadas de los diversos

manejadores para los casos de uso Validar Usuario, Ofrecer Servicios,

Correspondencia Despachada, Correspondencia Recibida, Búsqueda de

Correspondencia, Informes Correspondencia y Manual de Usuario.

Dado que ya hemos explicado los números entre paréntesis agregados a las

clases colaboradoras en la columna derecha, volveremos a definir la tarjeta

para la clase InterfaceUsuario correspondiente a la Tabla 8.3. 60. Esto se

muestra en la Tabla 8.3. 65 agregando la colaboración con el contrato “1”,

“Desplegar Pantalla”, definido en la clase Pantalla y el contrato “2”, “Manejar

Evento”, definido en la clase Manejador.




Estereotipo: Borde


Superclases:

Subclases:

Atributos:

Contratos


desplegarPantalla Pantalla (1) : PantallaValidación (1), PantallaMenuServicio (1),


Práctica UCPR-IST


PantallaCorrespondenciaDespachada (1), PantallaCorrespondenciaRecibida(1), PantallaBusquedaCorrespondencia(1), PantallaInformesCorrespondencia (1), PantallaManualUsuario (1).

2. Enviar Evento

enviarEvento Manejador (1) : ManejadorValidación(1), ManejadorRegistroUsuario (1), ManejadorMenuServicio (1), ManejadorDespachada (1), ManejadorRecibida (1), ManejadorBusqueda (1), ManejadorInformes (1), ManejadorManual (1).

Tabla 8.3.65 Tarjeta para la clase InterfaceUsuario revisada con números de

contratos para las colaboraciones.

A continuación consideramos las responsabilidades definidas para la clase

ManejadorRegistroUsuario descritas en la Tabla 8.3. 52. La responsabilidad

“manejarEvento” sobre escribe la responsabilidad con el mismo nombre en la

clase

Manejador por lo cual generaremos un contrato “1” que sobrescribe al contrato

general definida en la superclase. Las responsabilidades

“validarRegistroUsuario” son privadas ya que son llamadas por la propia clase,

en realidad como consecuencia del contrato “Manejar Evento”. La clase

ManejadorRegistroUsuario con los contratos respectivos, se muestra en la

Tabla 8.3. 66. Nótese que se agrega el contrato “2” a la clase colaboradora

ManejadorRegistroUsuario, algo que aún no se ha definido, pero lo haremos

más adelante. Básicamente los contratos “1” corresponden en todos los

manejadores al contrato “Manejar Evento” mientras que los contratos a partir

del número “2” representan los contratos adicionales de los manejadores y se

van dando según una numeración local incremental.


Práctica UCPR-IST








Subclases:

Atributos:

Contratos

1. Manejar Evento

manejarEvento


crearRegistroUsuario ManejadorRegistroUsuario (2)

validarRegistroUsuario

Tabla 8.3.66. Tarjeta para la clase ManejadorRegistroUsuario con

responsabilidades, colaboraciones, jerarquías y contratos identificadas de los

casos de uso Validar Usuario, Ofrecer Servicios, Correspondencia



A partir de la Tabla 8.3.53. Se generan los contratos para la clase

PantallaValidación, como se muestra en la Tabla 8.3. 67. Dado que los

contratos como las responsabilidades fueron todas definidas en la superclase

Pantalla, esta clase se mantiene igual en su descripción.




Estereotipo: Borde



Subclases:

Atributos:

Tabla 8.3.67. Tarjeta para la clase PantallaValidación con responsabilidades,

colaboraciones, jerarquías y contratos identificadas de los casos de uso Validar

Usuario, Ofrecer Servicios, Correspondencia Despachada, Correspondencia

Recibida, Búsqueda de Correspondencia, Informes Correspondencia y Manual

de Usuario.


Práctica UCPR-IST


8.3.6. DOMINIO

A partir de la Tabla 8.3.54 se generan los contratos para la clase Datos, como

se muestra en la Tabla 8.3.68. Dado que aún no se han definido

responsabilidades para las clases entidad, esta clase se mantiene igual a la

anterior.

Clase: Datos

Descripción: Superclase para todas las clases entidad.

Módulo: Dominio



Superclases:

Subclases: RegistroUsuario, RegistroCorrespondencia

Atributos:

Tabla 8.3.68. Tarjeta para la clase Datos con responsabilidades,

colaboraciones y jerarquías identificadas de las diversas clases entidad para

los casos de uso Validar Usuario, Ofrecer Servicios, Correspondencia



8.3.7. REGISTRO

Este módulo se compone de los módulos de Usuario e InterfaceBD y servicios.

Usuario

Esta sección involucra las clases de registro de usuario que son

ManejadoRegistroUsuario, PantallaValidación,

Las responsabilidades de la clase ManejadoRegistroUsuario fueron descritas

en la Tabla 8.3. 66, las cuales se vuelven a describir en la Tabla 8.3. 69.

manejarEvento

validarRegistroUsuario InterfaceBaseDatosCorrespondencia

Tabla 8.3.69. Responsabilidades definidas para la clase

ManejadoRegistroUsuario según las Tabla 8.3.66.


Práctica UCPR-IST


De manera similar a ManejadorValidación, la responsabilidad “manejarEvento”

será asignada al contrato “1”, “Manejar Evento”, por sobrescribir el contrato con

el mismo número en la superclase Manejador. Del resto de las

responsabilidades sólo dos son acezadas externamente,

“validarRegistroUsuario”, por el ManejadorValidación, como se muestra en la

Figura 8.3.14.

Figura 8.3.14 El diagrama muestra las clases ManejadorValidación como

clientes de las diversas responsabilidades de la clase

ManejadoRegistroUsuario.

En general los diagramas de colaboración, como se muestran en la Figura

8.3.14, son extremadamente útiles para comprender las diversas

colaboraciones que ocurren dentro del sistema. Sin embargo, mostrar llamadas

a nivel de responsabilidades puede resultar en diagramas extremadamente

densos, por lo cual se busca más bien describir las colaboraciones a nivel de

los contratos los cuales son más reducidos en su número que las llamadas por

responsabilidad. El mismo diagrama pero a nivel de contratos se muestra en la

Figura 8.3. 15. En este caso introducimos un solo contrato llamado “Registrar

Usuario”, el contrato número “2”, el cual incluye las dos responsabilidades

llamadas externamente y que manipulan el registro del usuario, sea a nivel de,

validación u obtención. Existe siempre la alternativa de definir múltiples

contratos, sin embargo, esto únicamente aumentaría la complejidad en este

caso ya que la funcionalidad puede ser considerada como lógicamente similar.

ManejadorRegistroUsuario (From RegistroUsuario)


ValidarRegistroUsuario


Práctica UCPR-IST


Figura 8.3.15 El diagrama muestra las clases ManejadorValidación y

ManejadoMenurServicio como clientes del contrato “Registrar Usuario”,

contrato número “2”, de la clase ManejadoRegistroUsuario.

En la Tabla 8.3.70 se describe la tarjeta para la clase

ManejadorRegistroUsuario. La responsabilidad “manejarEvento” se asigna al

contrato número “1”, “Manejar Evento”, mientras que la responsabilidad

“validarRegistroUsuario”, son asignadas al contrato número “2”, “Registrar

Usuario”. El resto de las responsabilidades, se mantienen como

responsabilidades privadas ya que son llamadas localmente dentro de la clase

ManejadorRegistroUsuario. Nótese que nuevamente se agregaron números de

contratos a las diferentes clases colaboradoras. Estos contratos están aún por

definirse, sin embargo, mantenemos la numeración lógica anteriormente

mencionada.







Subclases:

Atributos:

Contratos

1. Manejar Evento

manejarEvento

2. Registrar Usuario

validarRegistroUsuario InterfaceBaseDatosCorrespondencia (1)


responsabilidades, colaboraciones, jerarquías y contrato identificado del caso

de uso ValidarUsuario.


RegistrarUsuario



Práctica UCPR-IST


La clase RegistroUsuario se mantiene igual a como se describió anteriormente

en la Tabla 8.3. 56, como se muestra en la Tabla 8.3.71.


Descripción: Para poder utilizar el sistema de Correspondencia, el usuario debe estar registrado con el sistema. El registro contiene información acerca del usuario que incluye nombre de Usuario y clave.




Superclases: Datos

Subclases:

Atributos:


colaboraciones, jerarquías y contratos de actualizar y consultar información de

registro para el caso de uso RegistrarUsuario.

Interface Base Datos

Las responsabilidades de la clase InterfaceBaseDatosCorrespondencia como

se puede ver en la Tabla 8.3.72.


Tabla 8.3.72. Responsabilidades definidas para la clase


Se pueden apreciar dos grupos de responsabilidades para la clase

InterfaceBaseDatosCorrespondencia, aquellas responsabilidades relacionadas

con el registro de usuario y aquellas relacionadas con el registro de tarjeta. En

la Figura 8.3. 16 podemos apreciar esto en mayor detalle.

Figura 8.3.16 El diagrama muestra las clases ManejadoRegistroUsuario como

clientes de la clase InterfaceBaseDatosCorrespondencia.


ValidarRegistroUsuario

InterfaceBaseDatosCorrespondencia (From RegistroInterfaceBD)


Práctica UCPR-IST


En la Figura 8.3.16 podemos nuevamente apreciar la complejidad de diagramar

las relaciones entre clases a nivel de responsabilidades, sería menos complejo

hacerlo a nivel de contratos siempre cuando estos agrupen a las

responsabilidades. Si consideramos que existen dos grupos de

responsabilidades, organizadas de acuerdo a las dos clases clientes,

ManejadoRegistroUsuario, podemos de manera natural definir un contrato, el

número “1” correspondiente a “Registrar Usuario”.

Esta agrupación simplifica la visualización de los contratos como podemos

apreciar en la Figura 8.3.17.

Figura 8.3.17. El diagrama muestra las clases ManejadoRegistroUsuario y

como clientes de la clase InterfaceBaseDatosCorrespondencia describiendo las

relaciones a nivel de contratos. En la Tabla 8.3.73 se describe la tarjeta para la

clase InterfaceBaseDatosCorrespondencia. Se definen dos contratos

correspondientes a “Registrar Usuario”.


Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se aceza mediante la interface de la base de datos de correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre la tarjeta de crédito para pagos en línea.


Estereotipo: Borde


Superclases:

Subclases:

Atributos:

Contratos




responsabilidades, colaboraciones, jerarquías y contratos de escribir y leer

información de registro de usuario, para los casos de uso ValidarUsuario.

Servicios

La descripción del ManejadorMenuServicio es similar a los demás

manejadores. Se genera un contrato “Manejar Evento” similar a los demás

manejadores y otro propio a esta clase, “Ofrecer Servicio” el cual tiene como

cliente a los demás Manejadores, como se muestra en la Figura 8.3.17.


Práctica UCPR-IST


Figura 8.3.17. El diagrama muestra a las diversas clases de manejadores como

clientes de de la clase ManejadorMenuServicio.

A partir de la Tabla 8.3.58 se describe la clase ManejadorMenuServicio, como

se muestra en la Tabla 8.3.74. Además de los dos contratos antes

mencionados, se agrega una responsabilidad privada llamada “registrar”.


Descripción: El manejador de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores especializados para consulta, reserva y compra.

Módulo: Servicios




Subclases:

Atributos:

Contratos

1. Manejar Evento

manejarEvento

2. Ofrecer Servicio

ofrecerServicio


registrar ManejadorRegistroUsuario (2)


responsabilidades, colaboraciones, jerarquías y contratos a partir de los casos

de uso RegistrarUsuario.


ManejadorInformes (From Informes) ManejadorRegistroUsuario

(From Validación)






OfrecerServicio



Práctica UCPR-IST


De manera similar a las demás pantallas y a partir de la Tabla 8.3.59 se

describe la clase PantallaMenuServicio, como se muestra en la Tabla 8.3.75.


Descripción: Pantalla Menú de servicios (P-2).

Módulo: Servicios

Estereotipo: Borde



Subclases:

Atributos:

Tabla 8.3.75. Tarjeta para la clase PantallaMenuServicio con

responsabilidades, colaboraciones, jerarquías y contratos a partir de los casos

de uso RegistrarUsuario.

8.3.8 SUBSISTEMAS

Como se ha podido apreciar hasta el momento, la complejidad del sistema

aumenta a medida que se incorporan nuevos detalles en el diseño, algo que

por lo general es inevitable. Para lograr un mejor manejo de esta complejidad

introducimos el concepto de subsistemas, el cual permite dividir el sistema

completo en diversas partes, inspirado en la idea de “divide y conquista”. Los

subsistemas permiten agrupar objetos relacionados para lograr cierta

funcionalidad en “mini-sistemas”. El sistema completo se compone de estos

“mini-sistemas” o subsistemas y cada subsistema puede ser subdividido en

subsistemas adicionales o ser definido en términos de los objetos finales. Los

subsistemas también permiten trabajar en diferentes partes del sistema en

paralelo mediante su asignación a múltiples diseñadores.

La organización en subsistemas se logra a partir de los contratos identificadas

anteriormente entre los objetos. Externamente, los subsistemas son

mecanismos de encapsulamiento, vistos como “cajas negras”, donde sus

objetos cooperan para proveer una unidad de funcionalidad claramente

delimitada por el subsistema. Internamente, los subsistemas pueden tener

estructuras complejas, con clases colaborando entre si para satisfacer sus

distintas responsabilidades contribuyendo al objetivo general del subsistema, o

sea, satisfacer sus responsabilidades.


Práctica UCPR-IST


Se busca tener un fuerte acoplamiento funcional dentro de cada subsistema y

un débil acoplamiento entre subsistemas, en otras palabras, se busca tener la

mínima comunicación entre los diferentes subsistemas.

Un subsistema bien diseñado tiene pocas clases o subsistemas que

directamente apoyan contratos, y un número mayor de colaboraciones entre

clases y subsistemas internos. [3]

En la Tabla 8.3. 76 se muestra un ejemplo para un subsistema

InterfaceUsuario, donde el contrato externo al subsistema sería “Manejar

Evento” mientras que la clase servidora para este contrato sería

InterfaceUsuario a través de su contrato “1”.

Subsistema: SubsistemaInterfaceUsuario

Descripción: Este subsistema agrupa todos los objetos involucrados con el manejo general de las interfaces de usuario.

Clases: InterfaceUsuario.

1. Manejar Evento InterfaceUsuario (1)

Tabla 8.3.76. Tarjeta para el subsistema InterfaceUsuario.

Antes de definir los diferentes subsistemas para el sistema de

Correspondencia, describiremos los diagramas de colaboración a nivel de

subsistemas. Una de las maneras de hacerlo, y como la haremos aquí, es

describir el subsistema como un rectángulo y cada uno de los contratos del

subsistema como círculos. Estos contratos son asociados gráficamente con la

clase servidor que implementa el contrato real mediante una relación de

realización, como se muestra en la Figura 8.3.18.

Figura 8.3 18. Diagrama de subsistema con un contrato asociado con la clase

servidor que lo implementa.

Clase Servidor

Contrato Subsistema


Práctica UCPR-IST


Lamentablemente, muchas de las herramientas CASE no apoyan de manera

completa la diagramación de los subsistemas. Por ejemplo, el subsistema

descrito en la Tabla 8.3. 76 se describiría como se muestra en la Figura 8.3.19.

Figura 8.3.19. Diagrama de subsistema para el ejemplo del subsistema

InterfaceUsuario.

Dado que los subsistemas son puramente abstracciones, los contratos se dan

entre clases clientes solicitando servicios a los subsistemas a través de sus

respectivas clases servidores utilizando una flecha del cliente al servidor, como

se muestra en la Figura 8.3. 20. (La flecha de la derecha proveniente de Clase

Cliente).

Figura 8.3.20. Diagrama de colaboración donde Clase Cliente llama al Contrato

del Subsistema implementado por la Clase Servidor.

Si dos clases hacen solicitudes a un mismo contrato, se dibuja múltiples flechas

al mismo círculo. Por ejemplo, en la Figura 8.3.21 se muestra dos manejadores

llamando al contrato “Desplegar Pantalla” del subsistema InterfaceUsuario.

Clase Servidor

1. Desplegar Pantalla SubsistemaInterfaceUsuario

Clase Servidor

Contrato

SubsistemaInterfaceUsuario

Clase Cliente


Práctica UCPR-IST


Figura 8.3.21 Diagrama de subsistema para el ejemplo del subsistema

InterfaceUsuario con dos clientes para el contrato “Desplegar Pantalla”,

ManejadorValidación y ManejadorMenuServicio.

La InterfaceUsuario ofrece servicios internos al sistema para que se pueda

desplegar las diferentes pantallas y se pueda obtener eventos del Usuario. De

igual manera, el ManejadorValidación ofrece funcionalidad para inicializar la

aplicación, nuevamente un servicio interno que coordina entre funcionalidades

externas. Por lo tanto, pudiéramos definir el sistema completo en término de

cuatro subsistemas, SubsistemaInterfaceUsuario, SubsistemaValidación,

SubsistemaRegistro y SusbsistemaMenuServicio, como se muestra en la

Figura 8.3.22

Figura 8.3.22. Subsistemas de alto nivel para el sistema de correspondencia.

Estos subsistemas serán descritos con mayor detalle a continuación, aunque

limitándonos a los subsistemas relevantes para la funcionalidad descrita en los

casos de uso RegistrarUsuario, ValidarUsuario.

Clase Servidor

1 Desplegar Pantalla


manejadorValidacion

manejadorMenuServicio

<<Subsystem>> Subsistema InterfaceUsuario

(From Logical View)

<<Subsystem>> Subsistema Registro (From Logical View)

<<Subsystem>> Subsistema Validación

(From Logical View)

<<Subsystem>> Subsistema MenuServicio

(From Logical View)


Práctica UCPR-IST



El SubsistemaInterfaceUsuario fue descrito de manera preliminar en la Tabla

8.3.76. Este subsistema consiste Validaciónmente de la clase InterfaceUsuario.

La clase InterfaceUsuario, “Desplegar Pantalla” y “Enviar Evento”.

Estos contratos tienen como clientes a los diversos manejadores y a las

diversas pantallas. El contrato “Desplegar Pantalla” se define como externo ya

que los manejadores serán parte de otros subsistemas. En el caso de las

pantallas debemos preguntarnos si éstas deberán asignarse al

SubsistemaInterfaceUsuario por ser todas clases borde o distribuirse entre los

diversos subsistemas según su funcionalidad. La decisión depende de hacer un

balance entre la relación de esta clase con las demás clases a nivel de

comunicaciones y funcionalmente a cuál de los subsistemas debieran

pertenecer. A nivel de comunicaciones, las diversas pantallas tienen los

contratos “Desplegar Pantalla” definidos en la superclase Pantalla, llamado por

la InterfaceUsuario, y a su vez llaman al contrato “Enviar Evento” definido por la

clase InterfaceUsuario. En otras palabras, a nivel de comunicaciones, lo lógico

sería asignar todas las pantallas a este subsistema. A nivel lógico, las pantallas

se deberían asignar a los subsistemas que definan la funcionalidad

correspondiente. Sin embargo, nuestro enfoque será el primero, asignar todas

las pantallas al SubsistemaInterfaceUsuario.

Esto nos evita tener que definir todos os contratos “Enviar Evento” de las

diversas pantallas como externos a cada uno de los subsistemas. Se pudiera

hacer un análisis similar para los manejadores, donde terminaríamos

asignando todos ellos a un solo subsistema, lo cual sería contraproducente. La

gran diferencia entre las pantallas y los manejadores es que los manejadores

representan la funcionalidad del sistema mientras que las pantallas representan

únicamente aspectos de presentación los cuales son hasta cierto punto

independientes de la funcionalidad. Si la lógica de la aplicación cambia, todo el

sistema debe cambiar, pero si la presentación cambia, no necesariamente

debe cambiar toda la aplicación. Por lo tanto, la decisión de asignar las

pantallas a este subsistema es más justificable que el caso de asignar a los

manejadores. La tarjeta para el SubsistemaInterfaceUsuario se muestra en la

Tabla 8.3.77.


Práctica UCPR-IST


Subsistema: SubsistemaInterfaceUsuario

Descripción: Este subsistema agrupa todos los objetos involucrados con el manejo general de las interfaces de usuario.

Clases: InterfaceUsuario, PantallaValidación, PantallaMenuServicio, PantallaCorrespondenciaDespachada, PantallaCorrespondenciaRecibida, PantallaBusquedaCorrespondencia, PantallaInformesCorrespondencia, PantallaManualUsuario

Contratos Servidor

1. Desplegar Pantalla InterfaceUsuario (1)

Tabla 8.3.77. Tarjeta de subsistema para SubsistemaInterfaceUsuario

mostrando sus contratos y servidores a partir de los casos de uso

RegistrarUsuario, ValidarUsuario. El SubsistemaInterfaceUsuario se muestra

gráficamente en la Figura 8.3. 23. Se muestra únicamente la clase

InterfaceUsuario por ser el servidor del subsistema.

Figura 8.3.23. Diagrama de subsistemas para el SubsistemaInterfaceUsuario

mostrando únicamente a InterfaceUsuario, la clase servidor.

SubsistemaValidación

El SubsistemaValidación consiste Validación mente de la clase

ManejadorValidación. Podemos apreciar que en la Tabla 8.3. 52 se definió un

sólo contrato, “Manejar Evento”, el cual tiene como cliente a la clase

InterfaceUsuario. Dado que la clase InterfaceUsuario pertenece al

SubsistemaInterfaceUsuario, el contrato “Manejar Evento” debe definirse como

externo al subsistema. La tarjeta para el SubsistemaValidación se muestra en

la Tabla 8.3.78.

InterfaceUsuario

1.Desplegar Pantalla SubsistemaInterfaceUsuario


Práctica UCPR-IST


Subsistema: SubsistemaValidación

Descripción: Este subsistema agrupa todos los objetos involucrados con el manejo general del sistema.

Clases: ManejadorSubsistema

Contratos Servidor

1. Manejar Evento ManejadorValidación (1)

Tabla 8.3.78. Tarjeta de subsistema para SubsistemaValidación mostrando sus

contratos y servidores a partir de los casos de uso RegistrarUsuario,

ValidarUsuario.

El SubsistemaValidación se muestra gráficamente en la Figura 8.3. 24. No se

incluye en el diagrama la clase PantallaValidación ya que ésta no ofrece

servicios externos.

Figura 8.3. 24. Diagrama de subsistemas para el SubsistemaValidación.

SubsistemaRegistro

El SubsistemaRegistro consiste de todas las clases relacionadas con el registro

con excepción de las pantallas que fueron asignadas al subsistema

SubsistemaInterfaceUsuario. Las clases incluidas son

ManejadorRegistroUsuario,

RegistroUsuario y InterfaceBaseDatosCorrespondencia. Se incluyeron las

clases entidad junto con los manejadores y la clase de borde con la base de

datos. En término de contratos, podemos observar que los dos contratos

“Manejar Evento” pertenecientes a los dos manejadores, deben ser externos al

subsistema ya que son llamados por la InterfaceUsuario. Adicionalmente,

existe otro contrato que puede ser nombrados externamente, “Registrar

Usuario”. Por otro lado las clases entidad, RegistroUsuario, aún no definen

contratos, mientras que la clase InterfaceBaseDatosCorrespondencia contiene

ManejadorValidacion

1.Manejar Evento SubsistemaValidacion


Práctica UCPR-IST


contratos únicamente para los manejadores internos de este subsistema. La

tarjeta para el SubsistemaRegistro se muestra en la Tabla 8.3. 79. Nótese que

existen dos servidores para el primer contrato. Esto no es un error, ya que los

servidores pueden estar activos en diferentes momentos durante la ejecución

del sistema.

Adicionalmente, pudiéramos definir “sub-subsistemas”, o sea subsistemas a un

nivel inferior en la jerarquía, sin embargo, consideramos que dado el número

limitado de clases en este subsistema, esto no será necesario.

Subsistema: SubsistemaRegistro

Descripción: Este subsistema agrupa todos los objetos involucrados con el manejo de registro de usuario.

Clases: ManejadorRegistroUsuario, RegistroUsuario, InterfaceBaseDatosCorrespondencia

Contratos Servidor

1. Manejar Evento ManejadorRegistroUsuario (1),

2. Registrar Usuario ManejadorRegistroUsuario (2),

Tabla 8.3.79. Tarjeta de subsistema para SubsistemaRegistro mostrando sus

contratos y servidores a partir de los casos de uso RegistrarUsuario,

ValidarUsuario.

El SubsistemaRegistro se muestra gráficamente en la Figura 8.3. 25. Nótese

nuevamente que el subsistema ofrece dos contratos externos ligados a los

servidores internos correspondientes.

Figura 8.3.25 Diagrama de subsistemas para el SubsistemaRegistro.


1.Manejar Evento

SubsistemaRegistro 2.Registrar Usuario


Práctica UCPR-IST


SubsistemaMenuServicios

El SubsistemaMenuServicios consiste Validación mente de la clase

ManejadorMenuServicio. Eventualmente, este subsistema incluirá clases y

subsistemas internos adicionales como parte de la funcionalidad apoyada para

los demás casos de uso, algo que se muestra en los apéndices. En la Tabla

8.3. 80 se muestran los dos contratos definidos para este subsistema, “Manejar

Evento”, similar a los demás subsistema que contienen manejadores, y

“Ofrecer Servicio”, contrato que permite seleccionar la funcionalidad del

sistema deseado. Ambos contratos son implementados por la clase

ManejadorMenuServicio.

Subsistema: SubsistemaMenuServicios

Descripción: Este subsistema agrupa los objetos generales para el manejo de los servicios de correspondencia.

Clases: ManejadormenuServicio

Contratos Servidor

1. Manejar Evento ManejadorMenuServicio (1)

2. Ofrecer Servicio ManejadorMenuServicio (2)

Tabla 8.3.80. Tarjeta de subsistema para SubsistemaMenuServicios mostrando

sus contratos y servidores a partir del caso de uso RegistrarUsuario.

El SubsistemaMenuServicio se muestra gráficamente en la Figura 8.3.26.

Ambos contratos son ofrecidos por el ManjeadorMenuServicio.

Figura 8.3. 26 Diagrama de subsistemas para el SubsistemaMenuServicios.

ManejadormenuServicio

1.Manejar Evento

SubsistemaMenuServicio 1.Ofrecer Servicio


Práctica UCPR-IST


8.3.9 SISTEMA

Una de las ventajas de definir subsistemas es la posibilidad de visualizar el

sistema completo a partir de estas. En la Figura 8.3.26 se integran los

subsistemas anteriores mostrando los contratos entre subsistemas. Se pueden

apreciar seis contratos los cuales son llamados por las clases manejadoras en

los subsistemas de Registro, Servicios y Validación y la InterfaceUsuario en el

subsistema correspondiente.

Al incluir los subsistemas es necesario modificar las tarjetas de clase para

hacer referencias a estos subsistemas y no a las clases que éstas encapsulan.

Si una clase externa a un subsistema colabora con una clase dentro de un

subsistema, se debe cambiar esto a una colaboración con el subsistema y no

directamente con la clase. Por lo tanto, no modificaremos las tarjetas de clase

con excepción a aquellas donde las colaboraciones sean con clases en otros

subsistemas



1. Manejar Evento

SubsistemaRegistro

2. Registra usuario

1. Manejar Evento

SubsistemaValidacion

1. Manejar Evento

SubsistemaMenuServico

2. Registra usuario


Práctica UCPR-IST


Módulo InterfaceUsuario

La clase InterfaceUsuario, tal como se describió en la Tabla 8.3.65, define dos

responsabilidades “desplegarPantalla” y “enviarEvento”. Las colaboraciones a

partir de “desplegarPantalla” son con pantallas las cuales residen dentro del

SubsistemaInterfaceUsuario, por lo cual ningún cambio en la descripción de las

colaboraciones es necesario. La segunda responsabilidad, “enviarEvento”,

requiere colaboraciones con los manejadores a través de los contratos de

“Manejar Evento”, los cuales están definidos a partir de la superclase

Manejador y sobrescritos por los diversos manejadores. Aunque la clase

InterfaceUsuario colabora con todos sin saber su verdadera identidad, estas

clases residen en diversos subsistemas, por lo cual se debe modificar los

nombres de clases y en su lugar poner los nombres de los subsistemas

correspondientes a los cuales pertenecen las diversas clases manejadores. La

tarjeta de clase modificada para la clase InterfaceUsuario se muestra en la

Tabla 8.3.81.




Estereotipo: Borde


Superclases:

Subclases:

Atributos:

Contratos


desplegarPantalla Pantalla (1) : PantallaValidación (1), PantallaMenuServicio (1), PantallaCorrespondenciaDespachada(1), PantallaCorrespondenciaRecibida (1), PantallaBusquedaCorrespondencia (1), PantallaInformesCorrespondencia(1) PantallaManualUsuario (1)

2. Enviar Evento

enviarEvento Manejador (1) : SubsistemaValidación(1), SubsistemaMenuServicio(1), SubsistemaRegistro (1)


colaboraciones, jerarquías, contratos y subsistemas identificados de los casos

de uso RegistrarUsuario, ValidarUsuario.


Práctica UCPR-IST


La clase Pantalla, como se definió en la Tabla 8.3. 62, y todas sus subclases

correspondientes a las distintas pantallas no son modificadas ya que la

colaboración de la clase es con la clase InterfaceUsuario que pertenece al

mismo subsistema.

Módulo Validación

La clase ManejadorValidación debe modificarse ya que sus colaborador es la

clase ManejadorRegistroUsuario como se puede apreciar en la Tabla 8.3. 71.

Por lo tanto, se actualizan los contratos para la clase ManejadorValidación, en

este caso l contrato “2” del SubsistemaRegistro, como se muestra en la Tabla

8.3.82.







Subclases:

Atributos:

Contratos

1. Manejar Evento

manejarEvento

Responsablidades Privadas

validarRegUsuario SubsistemaRegistro (2)


colaboraciones, jerarquías, contratos y subsistemas identificadas de los casos

de uso RegistrarUsuario, ValidarUsuario.

La clase Manejador, como se mostró en la Tabla 8.3.70 llama a los contratos

“1” de la InterfaceUsuario y el contrato “2” del ManejadorMenuServicio. Por lo

tanto se actualizan los contratos al contrato “1” del SubsistemaInterfaceUsuario

y el contrato “2” del SubsistemaServicio para la clase Manejador, como se

muestra en la Tabla 8.3. 83.


Práctica UCPR-IST


Clase: Manejador




Superclases:

Subclases: ManejadorValidación, ManejadorMenuServicio, ManejadorRegistroUsuario,

Atributos:

Contratos

1. Manejar Evento

manejarEvento


desplegarPantalla SubsistemaInterfaceUsuario (1)

ofrecerServicio SubsistemaServicio (2)

salir


colaboraciones, jerarquías, contratos y subsistemas identificadas de los

diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario.

Módulo Dominio

La descripción de la clase Datos se mantiene igual.

Módulo Registro

En el módulo de Registro, compuesto de los módulos Usuario e InterfaceBD,

no hay tampoco necesidad de modificar las clases.

Módulo Servicios

La clase ManejadorMenuServicio, como se muestra en la Tabla 8.3. 74, hace

llamadas al contrato “2” de la clase ManejadorRegistroUsuario el cual

pertenece al SubsistemaRegistro. La colaboración debe por lo tanto

modificarse de manera correspondiente. Los cambios para la clase

ManejadorMenuServicio se muestran en la Tabla 8.3. 84.


Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se aceza mediante la interface de la base de datos de correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre la tarjeta de crédito para pagos en línea.

Módulo: Servicios




Subclases:


Práctica UCPR-IST


Atributos:

Contratos

1. Manejar Evento

manejarEvento

2. Ofrecer Servicio

ofrecerServicio


registrar SubsistemaRegistro (2)


responsabilidades, colaboraciones, jerarquías, contratos y subsistemas a partir

de los casos de uso RegistrarUsuario.

Protocolos

Una vez completadas las etapas anteriores, se debe detallar la especificación

de cada clase hasta llegar a métodos y atributos finales. Aunque pudiéramos

generar una especificación completa a nivel de “pseudo-código” o incluso

código en un lenguaje particular, esto sería sobrespecificar el diseño ya que el

diseño debe definir los aspectos más relevantes de la solución pero sin ser el

código final. [3]

A continuación se describen las clases Validaciónes incorporando protocolos

en el Sistema de Correspondencia y en base a los casos de uso

RegistrarUsuario, ValidarUsuario.

InterfaceUsuario

La clase InterfaceUsuario define dos responsabilidades públicas,

correspondientes a dos contratos, como se especificó anteriormente en la

Tabla 8.3. 81 y como se muestra en la Tabla 8.3. 85.


desplegarPantalla Pantalla (1) : PantallaValidación (1), PantallaMenuServicio (1), PantallaCorrespondenciaDespachada (1), PantallaCorrespondenciaRecibida (1), PantallaBusquedaInformacion (1), PantallaInformesCorrespondencia (1) PantallaManualUsuario (1)

2. Enviar Evento

enviarEvento Manejador (1) : SubsistemaValidación (1), SubsistemaMenuServicio (1), SubsistemaRegistro (1)

Tabla 8.3.85. Responsabilidades públicas para la clase InterfaceUsuario

especificada en la Tabla 8.3. 81.


Práctica UCPR-IST


El método “desplegarPantalla” es llamado por los diversos manejadores como

parte del contrato “Desplegar Pantalla”. Dado que esta responsabilidad es

cliente del contrato “1”, con el mismo nombre, de la clase Pantalla y es

sobrecargada por las diversas pantallas, entonces es necesario definir como

parte del protocolo un parámetro correspondiente a la pantalla a ser

desplegada. Este parámetro de tipo Pantalla corresponde a un objeto ya

instanciado por parte del manejador controlador de dicha Pantalla. Tenemos

también que definir algún tipo de resultado, de manera sencilla podemos

simplemente devolver un tipo nulo (“void”). Todo esto se muestra en la Tabla

8.3. 86. Debe resaltarse que el parámetro corresponde a la superclase en lugar

de incluir alguna pantalla particular, siendo esto esencial para lograr el

polimorfismo.


desplegarPantalla(Pantalla) Pantalla (1) : PantallaValidación (1), PantallaMenuServicio (1), PantallaCorrespondenciaDespachada (1), PantallaCorrespondenciaRecibida (1), PantallaBusquedaCorrespondencia (1), PantallaInformesCorrrespondencia (1) PantallaManualUsuaria (1).

Tabla 8.3.86. Responsabilidad “desplegarPantalla” con protocolo para la clase

InterfaceUsuario especificada en la Tabla 8.3. 85.

En el caso de la otra responsabilidad, “enviarEvento”, la situación es la

opuesta. En este caso las diversas pantallas solicitan a la InterfaceUsuario

enviar los eventos generados por el Usuario. Posteriormente, la

InterfaceUsuario llama al contrato “1”, correspondiente a “Manejar Evento”,

definido en la clase Manejador y sobrecargado por los diferentes manejadores.

En principio, deberíamos definir dos parámetros, el evento generado y otro

correspondiente a la clase Manejador a quien se le enviará posteriormente el

evento. El evento puede corresponder a una clase tipo “Evento” que deberá

corresponder a algún tipo definido posteriormente y de acuerdo al lenguaje de

implementación. El tipo de devolución puede ser nuevamente un “void”. Esto se

muestra en la Tabla 8.3. 87.

2. Enviar Evento

enviarEvento(Evento, Manejador) devuelve void

Manejador (1) : SubsistemaValidación(1),

SubsistemaMenuServicio (1), SubsistemaRegistro (1)


Práctica UCPR-IST


Tabla 8.3.87. Responsabilidad “enviarEvento” con protocolo para la clase

InterfaceUsuario especificada en la Tabla 8.3. 81. La tarjeta de clase

modificada para la clase InterfaceUsuario se muestra en la Tabla 8.3. 88.




Estereotipo: Borde


Superclases:

Subclases:

Atributos:

Contratos


desplegarPantalla(Pantalla) devuelve void

Pantalla (1) : PantallaValidación (1), PantallaServicio (1), PantallaCrearRegUsuario (1), PantallaObtenerRegUsuario (1), PantallaCrearRegTarjeta (1), PantallaObtenerRegTarjeta (1)

2. Enviar Evento


Manejador (1) : SubsistemaValidación (1), SubsistemaServicio (1), SubsistemaRegistro

(1)


colaboraciones, jerarquías, contratos, subsistemas y protocolos identificados de

los casos de uso RegistrarUsuario, ValidarUsuario

. En la Tabla 8.3.62 se definieron las responsabilidades, asignadas a contratos y

privadas, para la clase Pantalla, como se muestra en la Tabla 8.3. 89.


desplegarPantalla


enviarEvento InterfaceUsuario (2)

Tabla 8.3.89. Tarjeta para la superclase clase Pantalla con responsabilidades

asignadas a contratos y privadas.

El contrato “desplegarPantalla” es llamado por la clase InterfaceUsuario

solicitando a las diversas pantallas que sobrescriben la responsabilidad que se

desplieguen. Dado que el contenido de la pantalla es conocida por las diversas

pantallas, en principio, no es necesario agregar ningún parámetro.


Práctica UCPR-IST


Adicionalmente, se puede devolver un tipo “void”. Esto se muestra en la Tabla

8.3.90.


desplegarPantalla() devuelve void

Tabla 8.3.90. Tarjeta para la superclase clase Pantalla con protocolo para la

responsabilidad “desplegarPantalla”.

En el caso de la responsabilidad privada “enviarEvento”, ésta es llamada

localmente por lo cual se puede dejar el parámetro sin asignar y se puede

devolver un tipo “void”. Esto se muestra en la Tabla 8.3. 91.


enviarEvento() devuelve void InterfaceUsuario (2)

Tabla 8.3.91. Tarjeta para la superclase clase Pantalla con protocolo para la

responsabilidad “enviarEvento”. La tarjeta de clase modificada para la clase

Pantalla se muestra en la Tabla 8.3.92.

Clase: Pantalla



Estereotipo: Borde


Superclases:

Subclases: PantallaValidación, PantallaMenuServicio.

Atributos:

Contratos






colaboraciones, jerarquías, contratos, subsistemas y protocolos identificadas de

los casos de uso RegistrarUsuario, ValidarUsuario.

Validación

A partir de la Tabla 8.3. 83 se muestran las diversas responsabilidades para la

clase Manejador, como se muestra en la Tabla 8.3. 93.


Práctica UCPR-IST


1. Manejar Evento

manejarEvento


desplegarPantalla SubsistemaInterfaceUsuario (1)

ofrecerServicio SubsistemaMenuServicio (2)

Salir

Tabla 8.3.93. Tarjeta para la clase Manejador según se describió en la Tabla

8.3. 83.

El contrato “Manejar Evento” es llamado por la clase InterfaceUsuario la cual

debe enviar el evento generada por el usuario y enviada luego por las diversas

pantallas. Por lo tanto debe incluirse un parámetro de tipo “Evento” y

nuevamente podemos asignar un tipo “void” de devolución. Las demás

responsabilidades son privadas y podemos dejar de asignar parámetros y

definir un tipo “void” de devolución. Esto se muestra en la Tabla 8.3.94.

Clase: Manejador





Superclases:

Subclases: ManejadorValidación, ManejadorMenuServicio, ManejadorRegistroUsuario,

Atributos:

Contratos

1. Manejar Evento

manejarEvento(Evento) devuelve void


desplegarPantalla() devuelve void SubsistemaInterfaceUsuario (1)

ofrecerServicio() devuelve void SubsistemaMenuServicio (2)

salir() devuelve void



los diversos manejadores para los casos de uso RegistrarUsuario,

ValidarUsuario.

A partir de la Tabla 8.3.82 podemos definir los protocolos para la clase

ManejadorValidación a partir del contrato “Manejar Evento” y dos

responsabilidades privadas. El contrato “Manejar Evento” contiene la

responsabilidad “manejarEvento” la cual se debe definir de manera similar a la

responsabilidad que es sobrescrita de la superclase Manjeador. Las dos


Práctica UCPR-IST


responsabilidades privadas se pueden dejar sin parámetros y devolviendo un

tipo “void”, como se muestra en la Tabla 8.3.95.







Subclases:

Atributos:

Contratos

1. Manejar Evento



validarRegistroUsuario() devuelve void

SubsistemaRegistro (2)



los casos de uso RegistrarUsuario, ValidarUsuario.

. La descripción de la clase PantallaValidación se mantiene igual ya que no

incluye responsabilidades al igual que las demás pantallas.

Dominio

La descripción de la clase Datos se mantiene igual, ya que no incluye hasta el

momento responsabilidades.

8.3.10 REGISTRO


sólo se modifican las clases de control pero no las de interface o entidad, como

se verá a continuación.


Práctica UCPR-IST


Usuario

En la Tabla 8.3. 70 se definieron las diferentes responsabilidades para la clase

ManejadoRegistroUsuario, como se muestra en la Tabla 8.3. 96.

Contratos

1. Manejar Evento

manejarEvento


validarRegistroUsuario InterfaceBaseDatosCorrespondencia (1)

Tabla 8.3.96. Tarjeta para la clase ManejadoRegistroUsuario como se definió

en la Tabla 8.3.70.

En el caso del contrato “Manejar Evento” debemos definir un protocolo para la

responsabilidad “manejarEvento” similar a la de la clase Manejador, como se

hizo con el ManejadorValidación.

En relación al contrato “Registrar Usuario” se tiene una responsabilidad,

“validarRegistroUsuario”. Esta responsabilidad es llamada por el

ManejadorValidación para iniciar transacciones de registro.

Dado que todo el control de la transacción está a cargo del

ManejadoRegistroUsuario, no hay necesidad de agregar ningún parámetro y se

puede devolver un tipo “void”.

En el caso de “validarRegistroUsuario”, el ManejadorValidación solicita al

ManejadoRegistroUsuario que valide los datos del usuario los cuales son

insertados en la PantallaValidación, la cual está a cargo del

ManejadorValidación. El ManejadorValidación debe hacerle llegar los datos del

usuario al ManejadoRegistroUsuario, algo que podemos incluir como dos

parámetros de tipo “String” (“cadenas de caracteres”), correspondientes al

nombre del usuario y su

Clave.

Dado que el ManejadorValidación debe decidir en base al resultado si proceder

con los servicios, también será necesario devolver algún tipo de valor que nos

comunique si la solicitud fue aceptada, por lo tanto agregaremos un tipo

“bolean” como resultado.

Todos estos protocolos con la tarjeta de clase completa se muestran en la

Tabla 8.3. 97.


Práctica UCPR-IST








Subclases:

Atributos:

Contratos

1. Manejar Evento



validarRegistroUsuario(String,String) devuelve boolean InterfaceBaseDatosCorrespondencia (1)

InterfaceBaseDatosCorrespondencia (1)


responsabilidades, colaboraciones, jerarquías, contratos, subsistemas y

protocolos identificadas de los casos de uso RegistrarUsuario y ValidarUsuario.

Interface Base Datos Registro

En la Tabla 8.3.73 se definieron las diferentes responsabilidades para la clase

InterfaceBaseDatosCorrespondencia, como se muestra en la Tabla 8.3. 98.



Tabla 8.3.98. Tarjeta para la clase InterfaceBaseDatosCorrespondencia como

se definió en la Tabla 8.3.73.

En el caso de “validarRegistroUsuario”, se tiene que enviar dos parámetros de

tipo “String” correspondientes al nombre del usuario y su clave.

En general podemos devolver un tipo “void” con excepción de la validación que

debe devolver un “boolean”. Todos estos protocolos con la tarjeta de clase

completa se muestran en la Tabla 8.3.99.


Práctica UCPR-IST



Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se aceza mediante la interface de la base de datos de Correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre la tarjeta de crédito para pagos en línea.


Estereotipo: Borde


Superclases:

Subclases:

Atributos:

Contratos


validarRegistro(String, String) devuelve boolean

BaseDatosCorrespondencia

Tabla 8.3. 99. Tarjeta para la clase InterfaceBaseDatosCorrespondencia con

responsabilidades, colaboraciones, jerarquías, contratos y protocolos de

escribir y leer información de registro de usuario y registro de tarjeta para los

casos de uso RegistrarUsuario, ValidarUsuario.

3.9.3 Servicios

En la Tabla 8.3. 84 se definieron las diferentes responsabilidades para la clase

ManejadorMenuServicio, como se muestra en la Tabla 8.3.100.

1. Manejar Evento

manejarEvento

2. Ofrecer Servicio

ofrecerServicio


registrar SubsistemaRegistro (2)

Tabla 8.3.100. Tarjeta para la clase ManejadorMenuServicio como se definió

en la Tabla 8.3. 84.

En el caso del contrato “Manejar Evento” debemos definir un protocolo para la

responsabilidad “manejarEvento” similar a la de la clase Manejador, como se

hizo con los demás manejadores.

En relación al contrato “Ofrecer Servicio”, la responsabilidad “ofrecerServicio”

es llamada por el los demás manejadores, algo que inicia un servicio

controlado totalmente por esta clase, por lo tanto no hay necesidad de Incluir

ningún parámetro e incluso se puede devolver un tipo “void”. La

responsabilidad privada nuevamente se define sin argumentos y con

devolución de tipo “void”.


Práctica UCPR-IST


Todos estos protocolos con la tarjeta de clase completa se muestran en la

Tabla 8.3. 101.


Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se aceza mediante la interface de la base de datos de Correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre lla correspondencia.

Módulo: Servicios




Subclases:

Atributos:

Contratos

1. Manejar Evento


2. Ofrecer Servicio

ofrecerServicio() devuelve void


registrar() devuelve void SubsistemaRegistro (2)


responsabilidades, colaboraciones, jerarquías, contratos, subsistemas y

protocolos a partir de los casos de uso RegistrarUsuario.

La descripción de la clase PantallaMenuServicio se mantiene de manera similar

a las demás pantallas.

8.3.11 ATRIBUTOS

En las secciones anteriores se ha diseñado las clases hasta llegar a los

protocolos de cada una de ellas. Estos protocolos describen las firmas para las

responsabilidades, en otras palabras, las interfaces externas de la clase. Es

difícil decidir en qué momento termina el diseño y comienza la implementación.

El objetivo general es lograr un diseño robusto que le de cierta flexibilidad al

programador pero sin modificar de manera importante la arquitectura de

diseño. Lo que haremos a continuación, es detallar un poco más nuestro

diseño especificando atributos correspondientes a estructuras de datos y

algoritmos que especifiquen la menara de implementar las diversas

responsabilidades correspondientes a los múltiples contratos de la

aplicación.[3]


Práctica UCPR-IST


A continuación se describen los atributos esenciales para las clases del

Sistema de Correspondencia y en base a los casos de uso, Validar Usuario,

Correspondencia Despachada, Correspondencia Recibida y Búsqueda

Correspondencia, Informes Correspondencia y Manual de Usuario.

InterfaceUsuario

Como se pudo observar anteriormente, la clase InterfaceUsuario se relaciona

primordialmente y a través de polimorfismo con las diversas pantallas y

manejadores. Dado que sólo se desplegará una pantalla a la vez y se

comunicará con un solo manejador en un momento específico, es suficiente

definir dos tipos de referencias,

Manejador para poder comunicarse con los diversos manejadores y Pantalla

para comunicarse con las diversas pantallas. Por lo tanto, modificamos la

tarjeta de clase correspondiente a la InterfaceUsuario como se muestra en la

Tabla 8.3.102.




Estereotipo: Borde


Superclases:

Subclases:

Atributos: Manejador, Pantalla

Contratos


desplegarPantalla(Pantalla) devuelve void

Pantalla (1) : PantallaValidación(1), PantallaMenuServicio (1), PantallaCorrespondenciaDespachada (1), PantallaCorrespondenciaRecibida (1), PantallaBusquedaCorrespondencia (1), PantallaCorrespondenciaEncontrada (1), PantallaInformesCorrespondencia (1), PantallaManualUsuario (1)

2. Enviar Evento


Manejador (1) : SubsistemaValidación (1), SubsistemaMenuServicio (1), SubsistemaRegistro (1), SubsistemaDespachada (1),


Práctica UCPR-IST


SubsistemaRecibida (1), SubsistemaBusqueda (1), SubsistemaInformes (1), SubsistemaInformacion (1)


colaboraciones, jerarquías, contratos, protocolos y atributos identificados de los

casos de uso Validar Usuario, Correspondencia Despachada, Correspondencia

Recibida y Búsqueda Correspondencia, Informes Correspondencia y Manual de

Usuario.

De manera similar a la InterfaceUsuario, las diversas pantallas deben tener

conocimiento de la InterfaceUsuario y de los manejadores que las controlan.

Aunque se pudiera especificar el tipo particular de manejador que administra

una pantalla en particular, podemos aprovechar y definir una referencia de tipo

genérica a Manejador ya que cada pantalla es administrada por un solo

manejador. Este conocimiento se implementa mediante atributos

correspondientes a las clases anteriores, como se muestra en la Tabla 8.3.103.

Clase: Pantalla



Estereotipo: Borde


Superclases:

Subclases: PantallaValidación, PantallaMenuServicio, PantallaCorrespondenciaDespachada, PantallaCorrespondenciaRecibida , PantallaBusquedaCorrespondencia, PantallaCorrespondenciaEncontrada , PantallaInformesCorrespondencia, PantallaManualUsuario

Atributos: InterfaceUsuario, Manejador

Contratos





Tabla 8.3.103. Tarjeta para la superclase Pantalla con responsabilidades,


casos de uso Validar Usuario, Correspondencia Despachada, Correspondencia

Recibida y Búsqueda Correspondencia, Informes Correspondencia y Manual de

Usuario.


Práctica UCPR-IST


Validación

De manera similar a la InterfaceUsuario y las pantallas, los manejadores deben

poder acezar a la propia InterfaceUsuario y también a sus diferentes pantallas.

Por tal motivo definimos dos atributos, uno de tipo InterfaceUsuario y otro de

tipo Pantalla correspondiente a la pantalla actualmente siendo desplegada. Si

revisamos un poco más, podemos apreciar que la gran mayoría de los

menejadores requieren comunicarse con el SubsistemaMenuServicio para

ofrecer algún servicio. Por lo tanto, también se requiere un atributo de

referencia de tipo ManejadorMenuServicio el cual puede ser definido a este

nivel en la superclase Manejador. Adicionalmente, vamos a agregar una

referencia genérica para el manejador padre el cual reside a un nivel

administrativo superior, en otras palabras, el manejador encargado de

instanciar al siguiente nivel de manejadores y así sucesivamente. Dado que el

manejador padre puede tener cualquier tipo dentro de la jerarquía de

manejadores, lo agregaremos bajo el tipo genérico Manejador. Esta referencia

es siempre buena tener, ya que un manejador particular puede tener acceso a

cualquier otro manejador siempre y cuando no pierda la referencia a su

superior. La clase Manejador se muestra en la Tabla 8.3.104.

Clase: Manejador





Superclases:

Subclases: ManejadorValidación, ManejadorMenuServicio, ManejadorRegistroUsuario, ManejadorDespachada, ManejadorRecibida, ManejadorBusqueda, ManenejadorInformes, ManejadorManual

Atributos: InterfaceUsuario, Pantalla, ManejadorMenuServicio, Manejador

Contratos

1. Manejar Evento



desplegarPantalla() devuelve void SubsistemaInterfaceUsuario (1)

ofrecerServicio() devuelve void SubsistemaMenuServicio (2)

salir() devuelve void



diversos manejadores para los casos de uso Validar Usuario, Correspondencia


Práctica UCPR-IST


Despachada, Correspondencia Recibida y Búsqueda Correspondencia,


En el caso de la clase ManejadorValidación es necesario agregar una

referencia particular a cada pantalla y manejador que pueda ser acezado desde

este clase, tomando en cuenta los ya definidos a nivel de la superclase

Manejador. Por lo tanto, definimos un atributo de tipo PantallaValidación, un

ManejadorMenuServicio y otro ManejadorRegistroUsuario, como se muestra en

la Tabla 8.3.105.


Descripción: El manejador validación es el encargado de desplegar la pantalla validación de interacción con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados.





Subclases:

Atributos: PantallaValidación, ManejadorMenuServicio, ManejadorRegistroUsuario

Contratos

1. Manejar Evento



validarRegistroUsuario() devuelve void


Tabla 8.3.105. Tarjeta para la clase ManejadorValidación con

responsabilidades, colaboraciones, jerarquías, contratos, protocolos y atributos

identificados de los casos de uso RegistrarUsuario, ValidarUsuario.

. La clase PantallaValidación no agrega atributos más allá de aquellos definidos

en la superclase Pantalla por lo cual no volvemos a repetir la descripción.

Dominio

La clase Datos es una superclase con estereotipo “entidad”. Típicamente, estas

clases se mantienen lo más limitadas posible en término de sus relaciones con

otras clases por lo cual no agregamos atributos hasta el momento.

Registro


sólo se modifican las clases de control pero no las de interface o entidad, como

se verá a continuación.


Práctica UCPR-IST


Usuario

En el caso de la clase ManejadoRegistroUsuario, definimos referencias a las

diversas pantallas bajo control de esta clase, a la clase entidad donde se

guardará la información manipulada por esta clase, RegistroUsuario,

ManejadorRegistroUsuario y a la clase InterfaceBaseDatosCorrespondencia,

correspondiente a la clase borde que acezará la base de datos de

Correspondencia. El resto de los atributos son heredados de la clase

Manejador. La tarjeta de clase para ManejadorRegistroUsuario se muestra en

la Tabla 8.3. 106.






Superclase: Manejador

Subclases:

Atributos: PantallaValidación, RegistroUsuario, InterfaceBaseDatosCorrespondencia

Contratos

1. Manejar Evento



validarRegistroUsuario(String,String) devuelve boolean



registrarUsuario() devuelve void ManejadorRegistroUsuario(2)



identificados de los casos de uso RegistrarUsuario y ValidarUsuario.

La clase RegistroUsuario incluye los atributos asignados durante la

identificación del dominio del problema y descrita en los casos de uso, como se



Descripción: Para poder utilizar el sistema de correspondencia, el usuario debe estar registrado con el sistema. El registro contiene información acerca del usuario que incluye nombre de usuario y clave.




Superclases: Datos

Subclases:


Práctica UCPR-IST


Atributos: Nombre de usuario, Clave


colaboraciones, jerarquías, contratos, protocolos y atributos para el caso de

uso RegistrarUsuario.


La clase InterfaceBaseDatosCorrespondencia no requiere atributos por el

momento.

Servicios

La clase ManejadorMenuServicio requiere únicamente una referencia a la clase

ManejadorRegistroUsuario para poder referirle solicitudes relacionadas con

registro, como se muestra en la Tabla 8.3. 108.


Descripción: La información de cada usuario se almacena en la base de datos de correspondencia la cual se aceza mediante la interface de la base de datos de correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre la correspondencia.

Módulo: Servicios




Subclases:

Atributos:

Contratos

1. Manejar Evento


2. Ofrecer Servicio

ofrecerServicio() devuelve void


registrar() devuelve void SubsistemaRegistro (2)



a partir de los casos de uso RegistrarUsuario.

La descripción de la clase PantallaMenuServicio se mantiene igual, como se

hizo con las demás pantallas.


Práctica UCPR-IST


8.3.12 ALGORITMOS

Los algoritmos definen la lógica utilizada por cada operación para resolver la

responsabilidad a la cual corresponden. En general, muchas responsabilidades

son suficientemente simples que no requieren de algoritmos, como son las

responsabilidades de delegar entre los objetos para consultar o modificar los

valores de los atributos.

Cuando se especifica el algoritmo, esto típicamente se hace mediante un

diagrama de flujo. Por el contrario, un algoritmo especificado de manera

declarativa, típicamente se hace mediante una especificación textual en cuyo

caso se debe usar algún conocimiento adicional para implementar el algoritmo.

Vale la pena resaltar que los aspectos algorítmicos pueden llegar a ser una de

las fuentes de mayor complejidad en un sistema.

A continuación especificamos nuestros algoritmos de manera declarativa,

Validación mente con un comentario sencillo.

InterfaceUsuario

La clase InterfaceUsuario se muestra en la Tabla 8.3.109.




Estereotipo: Borde


Superclases:

Subclases:

Atributos: Manejador, Pantalla

Contratos


desplegarPantalla(Pantalla) devuelve void Método encargado de desplegar las pantallas enviadas como parámetros. Se delega el despliegue particular a cada pantalla.

Pantalla (1) : PantallaValidación(1), PantallaMenuServicio (1), PantallaCorrespondenciaDespachada (1), PantallaCorrespondenciaRecibida (1), PantallaBusquedaCorrespondencia (1), PantallaCorrespondenciaEncontrada (1), PantallaInformesCorrespondencia (1), PantallaManualUsuario (1)


Práctica UCPR-IST


2. Enviar Evento

enviarEvento(Evento, Manejador) devuelve void Método encargado de recibir eventos del sistema de ventanas a través de las diversas pantallas. Se envía el evento recibido a los distintos manejadores.

Manejador (1) : SubsistemaValidación (1), SubsistemaMenuServicio (1), SubsistemaRegistro (1), SubsistemaDespachada (1), SubsistemaRecibida (1), SubsistemaBusqueda (1), SubsistemaInformes (1), SubsistemaInformacion (1)


colaboraciones, jerarquías, contratos, protocolos, atributos y especificación de

algoritmos identificados de los casos de uso RegistrarUsuario, ValidarUsuario.

La clase Pantalla se muestra en la Tabla 8.3.110.

Clase: Pantalla



Estereotipo: Borde


Superclases:

Subclases: PantallaValidación, PantallaMenuServicio, PantallaCorrespondenciaDespachada, PantallaCorrespondenciaRecibida,PantallaBusquedaCorrespondencia, PantallaCorrespondenciaEncontrada , PantallaInformesCorrespondencia, PantallaManualUsuario


Contratos


desplegarPantalla() devuelve void Método encargado de desplegar la pantalla actual.


enviarEvento() devuelve void Método encargado de recibir eventos del sistema de ventanas. Se envía el evento recibido a la InterfaceUsuario.

InterfaceUsuario (2)



algoritmos identificados de los casos de uso RegistrarUsuario,

ValidarUsuario.

La clase Pantalla se muestra en la Tabla 8.3.111.


Práctica UCPR-IST


Clase: Pantalla



Estereotipo: Borde


Superclases:



Contratos



enviarEvento() devuelve void Método encargado de recibir eventos del sistema de ventanas. Se envía el evento recibido a la InterfaceUsuario.

InterfaceUsuario (2)

Tabla 8.3.111. Tarjeta para la superclase Pantalla con responsabilidades,


algoritmos identificados de los casos de uso RegistrarUsuario, ValidarUsuario.

Validación

La clase Manejador se muestra en la Tabla 8.3. 112.

Clase: Manejador





Superclases:


Atributos: InterfaceUsuario, Pantalla, ManejadorMenuServicio, Manejador

Contratos

1. Manejar Evento



Práctica UCPR-IST


Método encargado de recibir eventos del sistema de ventanas a través de la InterfaceUsuario.


desplegarPantalla() devuelve void Método encargado de desplegar las pantallas administradas por los manejadores. Se solicita al SubsistemaInterfaceUsuario que las despliegue.

SubsistemaInterfaceUsuario (1)

ofrecerServicio() devuelve void Método encargado de solicitar al SubsistemaMenuServicio que ofrezca los servicios correspondientes.

SubsistemaMenuServicio (2)

salir() devuelve void Método encargado de salir del sistema.



algoritmos identificados de los diversos manejadores para los casos de uso


La clase ManejadorValidación se muestra en la Tabla 8.3.113.


Descripción: El manejador validación es el encargado de desplegar la pantalla Validación de interacción con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados.





Subclases:

Atributos:

Contratos

manejarEvento(Evento) devuelve void Método sobrescrito de la clase Manejador, encargado de recibir eventos del sistema de ventanas a través de la InterfaceUsuario.


validarRegistroUsuario() devuelve void Método encargado de solicitar al SubsistemaMenuServicio que de servicio al contrato de “Ofrecer Servicio”.



Práctica UCPR-IST


Tabla 8.3.113. Tarjeta para la clase ManejadorValidación con

responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y

especificación de algoritmos identificados de los casos de uso


La descripción de la clase PantallaValidación se mantiene igual ya que no

incluye responsabilidades al igual que las demás pantallas.

Dominio

La descripción de la clase Datos se mantiene igual, ya que no incluye hasta el

momento responsabilidades.

Registro


sólo se agregan especificaciones algorítmicas a las clases de control pero no

las de interface o entidad, como se verá a continuación.

Usuario

La clase ManejadoRegistroUsuario se muestra en la Tabla 8.3.114.







Subclases:

Atributos: PantallaValidación, PantallaMenuServicio, PantallaCorrespondenciaDespachada, PantallaCorrespondenciaRecibida,PantallaBusquedaCorrespondencia, PantallaCorrespondenciaEncontrada , PantallaInformesCorrespondencia, PantallaManualUsuario InterfaceBaseDatosCorrespondencia

Contratos

1. Manejar Evento



validarRegistroUsuario(String,String) devuelve Boolean Método encargado de solicitar a la InterfaceBaseDatosCorrespondencia la



Práctica UCPR-IST


validación de un usuario a través del contrato de “Registrar Usuario”



especificación de algoritmos identificados de los casos de uso RegistrarUsuario

y ValidarUsuario.

La descripción de las clases PantallaValidación, PantallaMenuServicio,

PantallaCorrespondenciaDespachada,

PantallaCorrespondenciaRecibida,PantallaBusquedaCorrespondencia,

PantallaCorrespondenciaEncontrada , PantallaInformesCorrespondencia y

PantallaManualUsuario se mantienen igual.


La clase InterfaceBaseDatosCorrespondencia se muestra en la Tabla 8.3.115.


Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se accesa mediante la interface de la base de datos de Correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre la tarjeta de crédito para pagos en línea.

Módulo: Registro. InterfaceDB

Estereotipo: Borde


Superclases:

Subclases:

Atributos:

Contratos


validarRegistro(String, String) devuelve bolean Método encargado de solicitar a la BaseDatosCorrespondencia la validación de un usuario




especificación de algoritmos identificados para los casos de uso



Práctica UCPR-IST


Servicios

La clase ManejadorMenuServicio se muestra en la Tabla 8.3.116.


Descripción: La información de cada usuario se almacena en la base de datos de Correspondencia la cual se aceza mediante la interface de la base de datos de Correspondencia. Esto permite validar a los distintos usuarios además de guardar información sobre la tarjeta la correspondencia.

Módulo: Servicios




Subclases:

Contratos

1. Manejar Evento


2. Ofrecer Servicio

ofrecerServicio() devuelve void Método encargado de hacer solicitudes de Correspondencia Despachada, Correspondencia Recibida, Búsqueda de Correspondencia, Informes Correspondencia y Manual de Usuario


registrar() devuelve void Método encargado de hacer la solicitud de administración de registros al SubsistemaRegistro




especificación de algoritmos identificados a partir de los casos de uso

RegistrarUsuario.

La descripción de la clase PantallaMenuServicio se mantiene de manera similar

a las demás pantallas.


Práctica UCPR-IST


8.3.13 DISEÑO DE SISTEMA

Hasta aquí, durante el diseño de objetos, hemos desarrollado un diseño

detallado en base a la arquitectura de análisis especificada anteriormente.

Estos aspectos del diseño fueron especificados de manera independiente al

ambiente de implementación. Aunque no entraremos en detalles de

implementación en este capítulo, es importante ya considerar dicho ambiente

ya que este afectará la implementación final. En general, el diseño de sistema

incluye diversos aspectos como:

Selección del lenguaje de programación a utilizarse, típicamente estructurados

u orientados a objetos; Incorporación de bibliotecas, como por ejemplo,

interfaces gráficas (GUI), bibliotecas numéricas y de estructuras de datos;

Incorporación de una base de datos, típicamente relacionales, relacionales

extendidos u orientados a objetos; Incorporación de archivos, en sus diferentes

formatos; Consideraciones de procesamiento, como concurrencia, paralelismo,

distribución y tiempo real; Estos aspectos pueden variar radicalmente entre uno

y otro sistema y también pueden afectar de manera importante la arquitectura

final del sistema. En general existen diversos enfoques para la incorporación

del ambiente de implementación a la arquitectura del sistema: (i) agregando

clases abstractas o interfaces que luego serán especializadas según el

ambiente de implementación particular; (ii) instanciando objetos especializados

que administren los aspectos particulares del ambiente de implementación

particular; y (iii) conFigura 8.3.ndo múltiples versiones del sistema

correspondientes a diferentes plataformas. Este es el enfoque más flexible,

aunque por lo general el de mayor costo de desarrollo.

En este modelo simplificaremos de gran manera el efecto del ambiente de

implementación. Utilizaremos a Visual Studio como lenguaje de programación

bajo un procesamiento secuencial y con interfaces gráficas sencillas escritas en

.NET. También mostraremos cómo integrar el sistema con bases de datos en

Mysql.

Lenguajes de Programación

Aunque no es obligatorio implementar un desarrollo orientado a objetos

mediante lenguajes de programación orientada a objetos, es obviamente más

natural hacerlo de tal modo. En el caso de los lenguajes orientados a objetos,

existe un apoyo directo a los conceptos y mecanismos fundamentales del

análisis orientado a objetos: encapsulamiento, clasificación, generalización y

polimorfismo. Sin embargo, se puede generalmente traducir cualquier concepto

o mecanismo orientado a objetos a otros existentes en los lenguajes no


Práctica UCPR-IST


orientados a objetos. El problema con otros tipos de lenguajes no es su poder

de computación, si no en su expresibilidad, conveniencia,

Protección contra errores, y mantenimiento. Un lenguaje orientado a objetos

hace que la escritura, mantenimiento, y extensión de los programas sea más

fácil y segura, ya que ejecuta tareas que un programador de un lenguaje no

orientado a objetos tendría que hacer manualmente.

Aunque esta decisión se ha simplificado hoy en día gracias a lenguajes como

Visual, no todos los lenguajes de programación orientados a objetos

implementan de la misma forma los diferentes conceptos de la orientación a

objetos. Existen aspectos, como el manejo del encapsulamiento, referencias,

herencia múltiple, y otros aspectos que varían de manera importante entre

lenguajes.

Como parte de la implementación de las clases en Java definiremos los

siguientes aspectos: Encapsulamiento o visibilidad de los métodos tanto como

los atributos mediante modificadores de tipo public en el caso de contratos y

responsabilidades públicas, private en el caso de responsabilidades y atributos

privados, y protected en el caso de responsabilidades y atributos privados

definidos a nivel de una superclase y que sean necesarios de acceder a nivel

de sus subclase. Protocolos correspondientes a tipos primitivos existentes en

Visual Basic, como int, float, boolean, y objetos con tipos

Interfaces Gráficas

Las interfaces gráficas tienen como objetivo esencial administrar la interacción

con el usuario mediante elementos gráficos, como lo son los botones, menús y

textos. En general, aplicaciones interactivas donde el control del ratón y el

teclado juegan un papel primordial de control, son conocidos como sistemas

controlados o dirigidos por eventos. Estos eventos corresponden al movimiento

del ratón, como oprimir o soltar uno de sus botones, oprimir una tecla, junto con

eventos que no son directamente iniciados por el usuario, como los eventos de

desplegar una pantalla o interrumpir un programa.

Los cambios Validaciones serán en relación al cliente del contrato “2” el cual

será el manejador de ventanas del sistema en lugar de las distintas pantallas.

Esto significa que el protocolo de la responsabilidad enviarEvento

correspondiente al contrato “2” de la clase InterfaceUsuario deberá modificarse,

tomado de su estado anterior como se ve en la Tabla 8.3.117.

2. Enviar Evento


Manejador (1) : SubsistemaValidación (1), SubsistemaMenuServicio (1), SubsistemaRegistro (1)

Tabla 8.3.117. Contrato enviarEvento para la clase InterfaceUsuario.


Práctica UCPR-IST


Dado que la llamada al contrato “2” es externa a nuestro sistema, no habrá

conocimiento sobre el manejador que controla la pantalla actual. Por lo tanto

omitiremos el parámetro Manejador en el protocolo, como se muestra en la

Tabla 8.3. 118.

2. Enviar Evento

enviarEvento(Evento) devuelve void Manejador (1) : SubsistemaValidación (1), SubsistemaMenuServicio (1), SubsistemaRegistro (1)

Tabla 8.3.118. Contrato enviarEvento con protocolo revisado para la clase

InterfaceUsuario.

La clase InterfaceUsuario modificada se muestra en la Tabla 8.3. 119.




Estereotipo: Borde


Superclases:

Subclases:

Atributos: Manejador manejador, Pantalla pantalla

Contratos


desplegarPantalla(Pantalla) devuelve void Método encargado de desplegar las pantallas enviadas como parámetros. Se delega el despliegue particular a cada pantalla.

Pantalla (1) : PantallaValidación(1), PantallaMenuServicio (1), PantallaCrorrespondenciaDespachada (1), PantallaCorrespondenciaRecibida (1), PantallaBusquedaCorrespondencia (1), PantallaInformesCorrespondencia (1), PantallaManualUsuario (1).

2. Enviar Evento

enviarEvento(Evento) devuelve void Método encargado de recibir eventos del sistema de ventanas a través de las diversas pantallas. Se envía el evento recibido a los distintos manejadores.

Manejador (1) : SubsistemaValidación (1), SubsistemaMenuServicio (1), SubsistemaRegistro (1)


colaboraciones, jerarquías, contratos, protocolos, atributos y algoritmos


Práctica UCPR-IST


identificados de los casos de uso RegistrarUsuario, ValidarUsuario y

RegistrarTarjeta.

La clase Pantalla incluía una responsabilidad privada enviarEvento, la cual

colaboraba con el contrato “2”, con el mismo nombre, perteneciente a la clase

InterfaceUsuario. Dado nuestras últimas modificaciones en el diseño gráfico,

esta responsabilidad privada ya no será necesaria y la clase InterfaceUsuario

recibirá directamente la llamada al contrato “2” por parte del manejador de

ventanas de la máquina. (De por si, la responsabilidad privada enviarEvento

definida en la clase Pantalla, tendría que ser pública para que el manejador de

ventanas pueda enviar los eventos.) En resumen, se eliminará la

responsabilidad enviarEvento en la clase Pantalla, como se muestra en la

Tabla 8.3.120.

Clase: Pantalla



Estereotipo: Borde


Superclases:


Atributos:

Contratos



Tabla 8.3.120. Tarjeta para la superclase clase Pantalla modificada de acuerdo

al diseño gráfico. Se eliminó la responsabilidad privada enviarEvento.

Bases de Datos

Las bases de datos siempre juegan un papel fundamental en los sistemas de

información. Una decisión estratégica importante en tal contexto es si utilizar

bases de datos relacionales u orientadas a objetos. Dado su amplia utilización,

seleccionaremos para nuestro desarrollo una base de datos relacional,

utilizando el lenguaje SQL para su interacción. En general, se consideran tres

los modelos de bases de datos Validaciónes:

Modelo Relacional definiendo una colección de Tabla 8.3.s donde cada Tabla

8.3. tiene un número específico de columnas y un número arbitrario de filas.

Cada elemento de la Tabla 8.3. guarda un valor de tipo primitivo, como enteros

o cadenas. De tal manera, cada objeto se representa como una fila en una


Práctica UCPR-IST


Tabla 8.3. y donde cada columna corresponde a un atributo distinto en el

objeto. El lenguaje de consultas se basa en operaciones simples, donde la

simplicidad del modelo es un beneficio pero también es una limitación.

Modelo Relacional Extendido extendiendo el modelo relacional mediante

procedimientos, objetos, versiones, y otras nuevas capacidades. No hay un

solo modelo relacional extendido, hay más bien una variedad de ellos, aunque

todos comparten las Tabla 8.3.s y consultas básicas del modelo relacional.

Todos incorporan algo de “objetos” y todos tienen la habilidad de guardar

procedimientos al igual que datos en la base de datos.

Modelo Orientado a Objetos definiendo un modelo orientado a objetos donde

varía el tipo de encapsulamiento de los datos y los procedimientos en el objeto.

El término “orientado a objetos” varía también según los autores. En el caso del

modelo orientado a objetos, los objetos pasan a tener persistencia más allá de

su existencia durante la ejecución del programa. En general, el diseño de

bases de datos es un aspecto crucial en los sistemas de información. Las

bases de datos son repositorios de datos guardados en uno o más archivos.

Existen sistemas de manejo de bases de datos (DBMS, OODBMS en el caso

de objetos) para la administración de los repositorios de datos permanentes, lo

cual da un apoyo importante en los siguientes aspectos:

recuperación de caída: protección ante fallas de hardware y errores de usuarios.

múltiples usuarios: acceso concurrente para diversos usuarios.

múltiples aplicaciones: acceso concurrente de lectura y escritura de datos, facilitando la comunicación entre las diferentes aplicaciones.

seguridad: protección contra acceso no autorizados de lectura o escritura.

integridad: reglas que deben ser satisfechas para controlar la calidad de los datos más allá del control particular de la aplicación.

extensibilidad: mecanismos que permitan extender la arquitectura de la base de datos sin interrumpir su ejecución.

distribución de datos: distribución de los datos en diferentes lugares, organizaciones y plataformas de hardware.

Durante el diseño de la base de datos se debe traducir el modelo del dominio

del problema a un modelo de Tabla 8.3.s. Existen diversos enfoques de diseño,

incluyendo aspectos relacionados con las correspondencia de asociaciones y

generalización a Tabla 8.3.s. Cada Tabla 8.3. derivada de una clase debe

incluir un identificador para la llave primaria, y uno o más identificadores para la

llave primaria de la Tabla 8.3. derivada de las asociaciones. La estrategia es

compatible con la orientación a objetos, donde los objetos tienen una identidad

aparte de sus propiedades. Existen beneficios en el uso de identificados, ya

que éstos son inmutables y completamente independientes a cambios en los


Práctica UCPR-IST


valores de los datos y su lugar físico. Aunque cada clase puede corresponder a

una o más Tabla 8.3.s, por lo general se diseñan Tabla 8.3.s correspondientes

a un objeto completo. Simplificaremos la tarea de diseño, creando una Tabla

8.3. correspondiente a cada clase entidad del dominio del problema y

manteniendo las asociaciones entre clases. Obviamente, el diseño de Tabla

8.3.s puede optimizarse para un acceso más eficiente, algo que no trataremos

aquí.

Dado que nuestra descripción se ha concentrado hasta el momento a lo

referente a registro de usuario y tarjeta, nos limitaremos a mostrar el diseño de

dichas Tabla 8.3.s. [3]

En la Tabla 8.3. 121, se muestra el diseño de la Tabla para el RegistroUsuario,

donde clave es definida como la llave primaria de la Tabla La primera fila

representa los nombres de los campos, mientras que la segunda muestra un

ejemplo de datos.

clave Nombre

1234 Álvaro

Tabla 8.3.121. Diseño de la base de datos para la Tabla correspondiente a la

clase RegistroUsuario.

En la Tabla 8.3.122, se muestra el diseño de la Tabla para la Archivo, donde

Codigo_Archivo es definida como la llave primaria de la Tabla La primera fila


ejemplo de datos.

Código Archivo

legajo

folio

caja

Fecha Inicial

Fecha Final

Clave

Código Sección

Código Ciudad

001 001 001 001 01/12/2009

30/12/2009

1234 66 66001

Tabla 8.3.122. Diseño de la base de datos para la Tabla 8.3. correspondiente a

la clase Archivo.

En la Tabla 8.3.123, se muestra el diseño de la Tabla para la

CorrespondenciaDespachada, donde Codigo_Despacho es definida como la

llave primaria de la Tabla. La primera fila representa los nombres de los

campos, mientras que la segunda muestra un ejemplo de datos.

Código Despach

o

Destinatario

Sección o Persona

Código

Oficio

Código

Ciudad

Código Secció

n

Código Archiv

o

001 Jorge Registradurí 001 66170 66 001


Práctica UCPR-IST


a


clase Correspondencia_Despachada.

En la Tabla 8.3.124, se muestra el diseño de la Tabla para la

CorrespondenciaRecibida, donde Codigo_Recibido es definida como la llave

primaria de la Tabla.. La primera fila representa los nombres de los campos,

mientras que la segunda muestra un ejemplo de datos.


clase Correspondencia_Recibida.

En la Tabla 8.3.125, se muestra el diseño de la Tabla para la Oficios donde

Codigo_Ofico es definida como la llave primaria de la La primera fila representa

los nombres de los campos, mientras que la segunda muestra un ejemplo de

datos.

Código Oficio

Numero Oficio

Fecha Oficio Objeto o Referencia

Entidad o Persona

001 0001 2/12/2009 Despacho Registraduría


clase Oficio.

En la Tabla 8.3.126, se muestra el diseño de la Tabla para la Sección donde

Codigo_Seccion es definida como la llave primaria de la Tabla. La primera fila


ejemplo de datos.

Código Sección

Subseccion Serie Subserie

001 Centro de Acopio

Comunicaciones oficiales

Material cedulas centro de acopio


Práctica UCPR-IST



clase Sección.

En la Tabla 8.3.127, se muestra el diseño de la Tabla para la Ciudad donde

Codigo_Ciudad es definida como la llave primaria de la Tabla. La primera fila


ejemplo de datos.

Código Ciudad Departamento Municipio

66001 Risaralda Pereira


clase Ciudad.

En la Figura 8.3. 27 se muestra de manera esquemática la relación entre las Tabla.

Figura 8.3. 27. Diagrama mostrando la relación esquemática


Práctica UCPR-IST


Archivos Aunque es siempre más efectivo trabajar con bases de datos, siempre es posible utilizar archivos, en particular cuando la especificación del sistema así lo requiera. De tal forma, aprovecharemos para extender el manejo de base de datos y mostrar cómo se puede lograr un objetivo similar a través de archivos. Este ejemplo también servirá para mostrar el poder de la extensibilidad definiendo una jerarquía de herencia a nivel de las clases borde para acezar tanto bases de datos como archivos de manera casi transparente. Para ello crearemos una nueva superclase InterfaceRegistro, de la cual heredará la clase InterfaceBaseDatosCorrespondencia y nuestra nueva clase InterfaceArchivoRegistro. La superclase la definiremos como abstracta y deberá tener contratos y responsabilidades públicas similares a las ya definidas en la clase InterfaceBaseDatosCorrespondencia. Esta clase se muestra en la Tabla 8.3. 128.

Clase: InterfaceRegistro

Descripción: Superclase para las interfaces a base de datos de registro y archivos.


Estereotipo: Borde


Superclases:

Subclases:

Atributos:

Contratos




Tabla 8.3.128. Tarjeta para la clase InterfaceRegistro con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y algoritmos para los casos de uso, ValidarUsuario. En el caso de la base de datos, la clase InterfaceBaseDatosCorrespondencia se comunica con el DBMS (manejador del sistema de la base de datos) para hacer solicitudes a cualquier Tabla 8.3.. Sin embargo, en el caso de los archivos, tal manejador no existe y será necesario hacerlo de manera manual. Por tal motivo, de manera adicional a la clase InterfaceArchivoRegistro, crearemos otra nueva clase ArchivoRegistro la cual se encargará de adminsitrar los diferentes archivos, instanciando una por archivo manipulado.


Práctica UCPR-IST


De tal manera modificaremos las colaboraciones en lamInterfaceArchivoRegistro para hacerlas con la clase ArchivoRegistro en lugar de BaseDatosCorrespondencia, como se muestra en la Tabla 8.3. 129. Nótese que todos los contratos deben ser idénticos a los de la superclase InterfaceRegistro al igual que InterfaceBaseDatosCorrespondencia para poder lograr la sobrescritura y aprovechar el polimorfismo.

Clase: InterfaceArchivoRegistro

Descripción: La información de cada usuario se almacena en la base de datos de registro la cual se aceza mediante la interface de la base de datos de registro. Esto permite validar a los distintos usuarios además de guardar información sobre la tarjeta de crédito para pagos en línea.


Estereotipo: Borde


Superclases:

Subclases:

Atributos:

Contratos



ArchivoRegistro

Tabla 8.3.129. Tarjeta para la clase InterfaceArchivoRegistro con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y algoritmos para los casos de uso RegistrarUsuario, ValidarUsuario.

La clase ArchivoRegistro de se muestra en la Tabla 8.3.130.


Práctica UCPR-IST


Clase: ArchivoRegistro

Descripción: La información de cada usuario se almacena en la base de datos de registro la cual se aceza mediante la interface de la base de datos de registro. Esto permite validar a los distintos usuarios además de guardar información sobre la correspondencia.


Estereotipo: Borde


Superclases:

Subclases:

Atributos:

Contratos


validarRegistro(String, String) devuelve bolean Método encargado de solicitar a la BaseDatosRegistro la validación de un usuario


Tabla 8.3.130. Tarjeta para la clase InterfaceArchivoRegistro con responsabilidades, colaboraciones, jerarquías, contratos, protocolos, atributos y algoritmos para los casos de uso RegistrarUsuario, ValidarUsuario.

8.3.14 DIAGRAMAS DE SECUENCIAS DEL DISEÑO

Una vez completado tanto el diseño de objetos como el del sistema, es posible describir los casos de uso del análisis en base a los protocolos de clases anteriormente definidos. Esto es muy importante ya que permita revisar que el diseño esté lógicamente completo. Para ello se describen los casos de uso mediante diagramas de secuencia, los cuales se pueden referir directamente a las clases, o incluso a partir de la interacción entre subsistemas. Esto es a menudo una técnica muy útil ya que se puede diseñar un subsistema mostrando sólo las interfaces de los subsistemas relacionados. A un nivel más detallado se pueden mostrar las interacciones internas del subsistema. Normalmente, los eventos en el diagrama corresponden a los protocolos anteriormente diseñados y se especifican exactamente como se verían en el código final. A continuación se muestran los diagramas de secuencia para el sistema de Correspondencia para los casos de uso Registrar Usuario. Nótese como estos diagramas extienden con detalles adicionales los diagramas de secuencias generados anteriormente durante el modelo de análisis.


Práctica UCPR-IST


Validar Usuario

El diagrama de secuencia para el caso de uso Validar Usuario, se muestra en

la Figura 8.3. 28.

Figura 8.3.28. Diagrama de secuencias para el caso de uso Validar Usuario.

: USUARIO

: InterfaceUsuario :ManejadorResgistro

Usuario

:ManejadorValidacion

:InterfaceBaseDatosCorrespondencia

:BaseDatos

Correspondencia

1: Desplegar Pantalla (PantallaValidacion)

2: “Ok”

3: ManejarEvento (“Ok”)

4: ValidarRegUsurio(String,String)

5: ValidarRegistro(String,String)

6:ExecuteQuery(Sql)

7: “Ok” 8: “Ok”

9: “Ok”


Práctica UCPR-IST


Guardar Correspondencia Despachada

El diagrama de secuencia para el caso de uso Correspondencia Despachada,

se muestra el subflujo Guardar, el cual es el mismo proceso para el caso de

uso Correspondencia Recibida en la Figura 8.3. 29.

Figura 8.3.29. Diagrama de secuencias para el caso de uso Correspondencia Despachada, subflujo Guardar, el cual es el mismo proceso para el caso de Uso Correspondencia Recibida.

: USUARIO : InterfaceUsuario :ManejadorResgistroUsuario :ManejadorValidacion


:BaseDatos

Correspondencia

:ManejadorCorrespon

denciaDespachada

:ManejadorMenu

Servicio


2: “Ok”




6:ExecuteQuery(Sql)

7: “Ok”

8: “Ok”

9: “Ok”

10: ofrecer Servicios 11: Desplegar Pantalla (PantallaMenuServicio)

12: “CorrespondenciaDespachada 13: ManejarEvento (“CorrespondenciaDespachada”)

14: CorrespondenciaDesapchada

15: desplegarPantalla(PantallaCorrespondenciaDespachada

16:”Guardar”

17: ManejarEvento(“Guardar”)

18: GuardarRegistro(CorrespondenciaDespachada)

19:ExecuteQuery(Sql)

20: “Ok” 21: “Ok”


23: “Salir”


Práctica UCPR-IST


Modificar Correspondencia Despachada


se muestra el subflujo Modificar, el cual es el mismo proceso para el caso de


Figura 8.3.30. Diagrama de secuencias para el caso de uso Correspondencia Despachada, subflujo Modificar, el cual es el mismo proceso para el caso de Uso Correspondencia Recibida.



:BaseDatos

Correspondencia

:ManejadorCorrespon

denciaDespachada

:ManejadorMenu

Servicio


2: “Ok”




6:ExecuteQuery(Sql)

7: “Ok”

8: “Ok”

9: “Ok”





16:”Modificarr”

17: ManejarEvento(“Modificar”)

18: ModificarRegistro(CorrespondenciaDespachada)


20: “Ok” 21: “Ok”


23: “Salir”


Práctica UCPR-IST


Eliminar Correspondencia Despachada


se muestra el subflujo Eliminar, el cual es el mismo proceso para el caso de


Figura 8.3.31. Diagrama de secuencias para el caso de uso Correspondencia Despachada, subflujo Eliminar, el cual es el mismo proceso para el caso de Uso Correspondencia Recibida.



:BaseDatos

Correspondencia

:ManejadorCorrespon

denciaDespachada

:ManejadorMenu

Servicio


2: “Ok”




6:ExecuteQuery(Sql)

7: “Ok”

8: “Ok”

9: “Ok”





16:”Eliminar”

17: ManejarEvento(“Eliminar”)

18: EliminarRegistro(CorrespondenciaDespachada)


20: “Ok” 21: “Ok”


23: “Salir”


Práctica UCPR-IST



El diagrama de secuencia para el caso de uso Busqueda de Correspondencia,

se muestra el subflujo Buscar, como se muestra en la Figura 8.3. 32.

Figura 8.3.32. Diagrama de secuencias para el caso de uso Busqueda de Correspondencia, subflujo Buscar.



:BaseDatos

Correspondencia

:ManejadorBusqueda :ManejadorMenu

Servicio


2: “Ok”




6:ExecuteQuery(Sql)

7: “Ok”

8: “Ok”

9: “Ok”


12: “Busqueda Correspondencia” 13: ManejarEvento (“Busqueda Correspondencia”)

14: Busqueda Correspondencia

15: desplegarPantalla(PantallaBusquedaCorrespondencia)

16:”Buscar”

17: ManejarEvento(“Buscar”)

18: BuscarRegistro(CorrespondenciaDespachada)


20: “Ok” 21: “Ok”

22: desplegarPantalla(PantallaCorrespondenciaEncontrada)

23: “Salir”


Práctica UCPR-IST


Informes Correspondencia El diagrama de secuencia para el caso de uso Informes Correspondencia, se

muestra el subflujo Generar Informe, como se muestra en la Figura 8.3. 33.

Figura 8.3.33. Diagrama de secuencias para el caso de uso Informes de Correspondencia, subflujo Generar Informe.



:BaseDatos

Correspondencia

:ManejadorInforme :ManejadorMenu

Servicio


2: “Ok”




6:ExecuteQuery(Sql)

7: “Ok”

8: “Ok”

9: “Ok”


12: “Informes Correspondencia” 13: ManejarEvento (“Informes Correspondencia”)

14: Informes Correspondencia

15: desplegarPantalla(PantallaInformesCorrespondencia)

16:”Generar Informe”

17: ManejarEvento(“Generar Informe”)

18: GenerarRegistro(InformesCorrespondencia)


20: “Ok” 21: “Ok”

22: desplegarPantalla(PantallaInformesCorrespondencia)

23: “Salir”


Práctica UCPR-IST


Manual de Usuario

El diagrama de secuencia para el caso de uso Manual de Usuario, se muestra

en la Figura 8.3. 34.

Figura 8.3.34. Diagrama de secuencias para el caso de uso Manual de Usuario.



:BaseDatos

Correspondencia

:ManejadorManual :ManejadorMenu

Servicio


2: “Ok”




6:ExecuteQuery(Sql)

7: “Ok”

8: “Ok”

9: “Ok”


12: “Manual de Usuario” 13: ManejarEvento (“Manual de Usuario”)

14: Manual de Usuario

15: desplegarPantalla(PantallaManualUsuario)

23: “Salir”


Práctica UCPR-IST


8.4 MODELO DE IMPLEMENTACION

El modelo de implementación toma el resultado del modelo de diseño para generar el código final. Esta traducción debe ser relativamente sencilla y directa, ya que las decisiones mayores han sido tomadas durante las etapas previas. Durante el modelo de implementación se hace una adaptación al lenguaje de programación y/o la base de datos de acuerdo a la especificación del diseño y según las propiedades del lenguaje de implementación y base de datos. Aunque el diseño de objetos es bastante independiente del lenguaje actual, todos los lenguajes tendrán sus particularidades, las cuales deberán adecuarse durante la implementación final. La elección del lenguaje influye en el diseño, pero el diseño no debe depender de los detalles del lenguaje. Si se cambia de lenguaje de programación no debe requerirse el re-diseño del sistema. [4] Programación en Visual Basic .NET En esta sección tomamos la especificación del diseño hecho en el modelo de diseño y generamos la programación, en este caso en VB.NET.

Para el manejo de la base de datos se realizo en Mysql 5. En la figura 8.4.1 se muestra el diseño de la base de datos.

Figura 8.4.1. Modelo Relacional de la Base de datos Correspondencia.


Práctica UCPR-IST


Para las consultas se crearon tres tablas de vistas para optimizar la búsqueda de la correspondencia. Vista 1- Despachada, Vista 2 – Recibida, Vista 3 – Consulta. Para las fechas se cambio el formato por uno individual ya que por conflictos de formato de fecha generaba problemas.

A continuación se muestra el código en Mysql de la base de datos Correspondencia.

# MySQL-Front 3.2 (Build 13.22) # Host: localhost Database: correspondencia # ------------------------------------------------------ # Server version 5.0.16-nt DROP DATABASE IF EXISTS `correspondencia`; CREATE DATABASE `correspondencia` /*!40100 DEFAULT CHARACTER SET latin1 */; USE `correspondencia`; # # Table structure for table archivo # CREATE TABLE `archivo` ( `CODIGO_DE_ARCHIVO` bigint(20) NOT NULL auto_increment, `NUMERO_DE_LEGAJO` bigint(20) default NULL, `NUMERO_DE_FOLIO` bigint(20) default NULL, `NUMERO_DE_CAJA` bigint(20) default NULL, `CODIGO_SECCION` bigint(20) default NULL, `CODIGO_DE_CIUDAD` bigint(20) default NULL, `CLAVE` bigint(11) default NULL, PRIMARY KEY (`CODIGO_DE_ARCHIVO`), KEY `CODIGO_SECCION` (`CODIGO_SECCION`), KEY `CODIGO_DE_CIUDAD` (`CODIGO_DE_CIUDAD`), KEY `CLAVE` (`CLAVE`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # # Dumping data for table archivo # # # Table structure for table ciudad # CREATE TABLE `ciudad` ( `CODIGO_DE_CIUDAD` bigint(20) NOT NULL, `DEPARTAMENTO` varchar(40) default NULL, `MUNICIPIO` varchar(40) default NULL, PRIMARY KEY (`CODIGO_DE_CIUDAD`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # # Table structure for table correspondencia_despachada


Práctica UCPR-IST


# CREATE TABLE `correspondencia_despachada` ( `CODIGO_DE_DESPACHO` bigint(20) NOT NULL auto_increment, `DESTINATARIO` varchar(40) default NULL, `SECCION_O_PERSONA` varchar(40) default NULL, `CODIGO_OFICIO` bigint(20) default NULL, `CODIGO_DE_CIUDAD` bigint(20) default NULL, `CODIGO_SECCION` bigint(20) default NULL, `CODIGO_DE_ARCHIVO` bigint(20) default NULL, PRIMARY KEY (`CODIGO_DE_DESPACHO`), KEY `CODIGO_OFICIO` (`CODIGO_OFICIO`), KEY `CODIGO_DE_CIUDAD` (`CODIGO_DE_CIUDAD`), KEY `CODIGO_SECCION` (`CODIGO_SECCION`), KEY `CODIGO_DE_ARCHIVO` (`CODIGO_DE_ARCHIVO`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # # Dumping data for table correspondencia_despachada # # # Table structure for table correspondencia_recibida # CREATE TABLE `correspondencia_recibida` ( `CODIGO_RECIBIDO` bigint(20) NOT NULL auto_increment, `REMITENTE` varchar(40) default NULL, `DIRECCION` varchar(40) default NULL, `TELEFONO` bigint(10) default NULL, `CODIGO_OFICIO` bigint(20) default NULL, `CODIGO_DE_CIUDAD` bigint(20) default NULL, `CODIGO_SECCION` bigint(20) default NULL, `CODIGO_DE_ARCHIVO` bigint(20) default NULL, `FECHA_RECIBIDO_DIA` bigint(2) default NULL, `FECHA_RECIBIDO_MES` bigint(2) default NULL, `FECHA_RECIBIDO_ANO` bigint(4) default NULL, `FECHA_RADICADO_DIA` bigint(2) default NULL, `FECHA_RADICADO_MES` bigint(2) default NULL, `FECHA_RADICADO_ANO` bigint(4) default NULL, PRIMARY KEY (`CODIGO_RECIBIDO`), KEY `CODIGO_OFICIO` (`CODIGO_OFICIO`), KEY `CODIGO_SECCION` (`CODIGO_SECCION`), KEY `CODIGO_DE_CIUDAD` (`CODIGO_DE_CIUDAD`), KEY `CODIGO_DE_ARCHIVO` (`CODIGO_DE_ARCHIVO`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # # Dumping data for table correspondencia_recibida # #


Práctica UCPR-IST


# Table structure for table oficios # CREATE TABLE òficios` ( `CODIGO_OFICIO` bigint(20) NOT NULL auto_increment, `NUMERO_DE_OFICIO` bigint(20) NOT NULL default '0', ÒBJETO_O_REFERENCIA` varchar(80) default NULL, ÈNTIDAD_O_PERSONA` varchar(80) default NULL, `FECHA_DE_OFICIO_DIA` bigint(2) default NULL, `FECHA_DE_OFICIO_MES` bigint(2) default NULL, `FECHA_DE_OFICIO_ANO` bigint(4) default NULL, PRIMARY KEY (`CODIGO_OFICIO`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # # Dumping data for table oficios # # # Table structure for table seccion # CREATE TABLE `seccion` ( `CODIGO_SECCION` bigint(20) NOT NULL auto_increment, `SUBSECCION` varchar(80) default NULL, `SERIE` varchar(80) default NULL, `SUBSERIE` varchar(80) default NULL, PRIMARY KEY (`CODIGO_SECCION`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # # Table structure for table usuario # CREATE TABLE ùsuario` ( `CLAVE` bigint(11) NOT NULL, `NOMBRE` varchar(40) default NULL, PRIMARY KEY (`CLAVE`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # # Dumping data for table usuario # INSERT INTO ùsuario` VALUES (12345,'admin'); # # View structure for view consultas # CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `consultas` AS (select sql_no_cache òficios`.`NUMERO_DE_OFICIO` AS `NUMERO_DE_OFICIO`,òficios`.ÒBJETO_O_REFERENCIA` AS ÒBJETO_O_REFERENCIA`,òficios`.ÈNTIDAD_O_PERSONA` AS ÈNTIDAD_O_PERSONA`,òficios`.`FECHA_DE_OFICIO_DIA` AS `FECHA_DE_OFICIO_DIA`,òficios`.`FECHA_DE_OFICIO_MES` AS `FECHA_DE_OFICIO_MES`,òficios`.`FECHA_DE_OFICIO_ANO`


Práctica UCPR-IST


AS `FECHA_DE_OFICIO_ANO`,`correspondencia_despachada`.`DESTINATARIO` AS `DESTINATARIO`,`correspondencia_despachada`.`SECCION_O_PERSONA` AS `SECCION_O_PERSONA`,`correspondencia_recibida`.`REMITENTE` AS `REMITENTE`,`correspondencia_recibida`.`DIRECCION` AS `DIRECCION`,`correspondencia_recibida`.`TELEFONO` AS `TELEFONO`,`correspondencia_recibida`.`FECHA_RECIBIDO_DIA` AS `FECHA_RECIBIDO_DIA`,`correspondencia_recibida`.`FECHA_RECIBIDO_MES` AS `FECHA_RECIBIDO_MES`,`correspondencia_recibida`.`FECHA_RECIBIDO_ANO` AS `FECHA_RECIBIDO_ANO`,`correspondencia_recibida`.`FECHA_RADICADO_DIA` AS `FECHA_RADICADO_DIA`,`correspondencia_recibida`.`FECHA_RADICADO_MES` AS `FECHA_RADICADO_MES`,`correspondencia_recibida`.`FECHA_RADICADO_ANO` AS `FECHA_RADICADO_ANO`,àrchivo`.`NUMERO_DE_LEGAJO` AS `NUMERO_DE_LEGAJO`,àrchivo`.`NUMERO_DE_FOLIO` AS `NUMERO_DE_FOLIO`,àrchivo`.`NUMERO_DE_CAJA` AS `NUMERO_DE_CAJA`,`seccion`.`SUBSECCION` AS `SUBSECCION`,`seccion`.`SERIE` AS `SERIE`,`seccion`.`SUBSERIE` AS `SUBSERIE`,`ciudad`.`DEPARTAMENTO` AS `DEPARTAMENTO`,`ciudad`.`MUNICIPIO` AS `MUNICIPIO` from (((((òficios` join `correspondencia_despachada`) join `correspondencia_recibida`) join àrchivo`) join `seccion`) join `ciudad`) where (((òficios`.`CODIGO_OFICIO` = `correspondencia_despachada`.`CODIGO_OFICIO`) and (`correspondencia_despachada`.`CODIGO_DE_ARCHIVO` = àrchivo`.`CODIGO_DE_ARCHIVO`) and (`seccion`.`CODIGO_SECCION` = `correspondencia_despachada`.`CODIGO_SECCION`) and (`ciudad`.`CODIGO_DE_CIUDAD` = `correspondencia_despachada`.`CODIGO_DE_CIUDAD`)) or ((òficios`.`CODIGO_OFICIO` = `correspondencia_recibida`.`CODIGO_OFICIO`) and (`correspondencia_recibida`.`CODIGO_DE_ARCHIVO` = àrchivo`.`CODIGO_DE_ARCHIVO`) and (`seccion`.`CODIGO_SECCION` = `correspondencia_recibida`.`CODIGO_SECCION`) and (`ciudad`.`CODIGO_DE_CIUDAD` = `correspondencia_recibida`.`CODIGO_DE_CIUDAD`)))); #


Práctica UCPR-IST


# View structure for view despachada # CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `despachada` AS (select sql_no_cache òficios`.`NUMERO_DE_OFICIO` AS `NUMERO_DE_OFICIO`,òficios`.ÒBJETO_O_REFERENCIA` AS ÒBJETO_O_REFERENCIA`,òficios`.ÈNTIDAD_O_PERSONA` AS ÈNTIDAD_O_PERSONA`,òficios`.`FECHA_DE_OFICIO_DIA` AS `FECHA_DE_OFICIO_DIA`,òficios`.`FECHA_DE_OFICIO_MES` AS `FECHA_DE_OFICIO_MES`,òficios`.`FECHA_DE_OFICIO_ANO` AS `FECHA_DE_OFICIO_ANO`,àrchivo`.`NUMERO_DE_LEGAJO` AS `NUMERO_DE_LEGAJO`,àrchivo`.`NUMERO_DE_FOLIO` AS `NUMERO_DE_FOLIO`,àrchivo`.`NUMERO_DE_CAJA` AS `NUMERO_DE_CAJA`,`correspondencia_despachada`.`DESTINATARIO` AS `DESTINATARIO`,`correspondencia_despachada`.`SECCION_O_PERSONA` AS `SECCION_O_PERSONA`,`seccion`.`SUBSECCION` AS `SUBSECCION`,`seccion`.`SERIE` AS `SERIE`,`seccion`.`SUBSERIE` AS `SUBSERIE`,`ciudad`.`DEPARTAMENTO` AS `DEPARTAMENTO`,`ciudad`.`MUNICIPIO` AS `MUNICIPIO` from ((((òficios` join àrchivo`) join `correspondencia_despachada`) join `seccion`) join `ciudad`) where ((òficios`.`CODIGO_OFICIO` = `correspondencia_despachada`.`CODIGO_OFICIO`) and (`correspondencia_despachada`.`CODIGO_DE_ARCHIVO` = àrchivo`.`CODIGO_DE_ARCHIVO`) and (`correspondencia_despachada`.`CODIGO_DE_CIUDAD` = `ciudad`.`CODIGO_DE_CIUDAD`) and (`correspondencia_despachada`.`CODIGO_SECCION` = `seccion`.`CODIGO_SECCION`))); # # View structure for view recibida # CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `recibida` AS (select sql_no_cache òficios`.`NUMERO_DE_OFICIO` AS `NUMERO_DE_OFICIO`,òficios`.ÒBJETO_O_REFERENCIA` AS ÒBJETO_O_REFERENCIA`,òficios`.ÈNTIDAD_O_PERSONA` AS ÈNTIDAD_O_PERSONA`,òficios`.`FECHA_DE_OFICIO_DIA` AS `FECHA_DE_OFICIO_DIA`,òficios`.`FECHA_DE_OFICIO_MES` AS `FECHA_DE_OFICIO_MES`,òficios`.`FECHA_DE_OFICIO_ANO` AS `FECHA_DE_OFICIO_ANO`,àrchivo`.`NUMERO_DE_LEGAJO` AS `NUMERO_DE_LEGAJO`,àrchivo`.`NUMERO_DE_FOLIO` AS `NUMERO_DE_FOLIO`,àrchivo`.`NUMERO_DE_CAJA` AS `NUMERO_DE_CAJA`,`correspondencia_recibida`.`REMITENTE` AS `REMITENTE`,`correspondencia_recibida`.`DIRECCION` AS `DIRECCION`,`correspondencia_recibida`.`TELEFONO`


Práctica UCPR-IST


AS `TELEFONO`,`correspondencia_recibida`.`FECHA_RECIBIDO_DIA` AS `FECHA_RECIBIDO_DIA`,`correspondencia_recibida`.`FECHA_RECIBIDO_MES` AS `FECHA_RECIBIDO_MES`,`correspondencia_recibida`.`FECHA_RECIBIDO_ANO` AS `FECHA_RECIBIDO_ANO`,`correspondencia_recibida`.`FECHA_RADICADO_DIA` AS `FECHA_RADICADO_DIA`,`correspondencia_recibida`.`FECHA_RADICADO_MES` AS `FECHA_RADICADO_MES`,`correspondencia_recibida`.`FECHA_RADICADO_ANO` AS `FECHA_RADICADO_ANO`,`seccion`.`SUBSECCION` AS `SUBSECCION`,`seccion`.`SERIE` AS `SERIE`,`seccion`.`SUBSERIE` AS `SUBSERIE`,`ciudad`.`DEPARTAMENTO` AS `DEPARTAMENTO`,`ciudad`.`MUNICIPIO` AS `MUNICIPIO` from ((((òficios` join àrchivo`) join `correspondencia_recibida`) join `seccion`) join `ciudad`) where ((òficios`.`CODIGO_OFICIO` = `correspondencia_recibida`.`CODIGO_OFICIO`) and (`correspondencia_recibida`.`CODIGO_DE_ARCHIVO` = àrchivo`.`CODIGO_DE_ARCHIVO`) and (`correspondencia_recibida`.`CODIGO_DE_CIUDAD` = `ciudad`.`CODIGO_DE_CIUDAD`) and (`correspondencia_recibida`.`CODIGO_SECCION` = `seccion`.`CODIGO_SECCION`))); # # Foreign keys for table archivo # ALTER TABLE àrchivo` ADD FOREIGN KEY (`CODIGO_SECCION`) REFERENCES `seccion` (`CODIGO_SECCION`), ADD FOREIGN KEY (`CODIGO_DE_CIUDAD`) REFERENCES `ciudad` (`CODIGO_DE_CIUDAD`), ADD FOREIGN KEY (`CLAVE`) REFERENCES ùsuario` (`CLAVE`); # # Foreign keys for table correspondencia_despachada # ALTER TABLE `correspondencia_despachada` ADD FOREIGN KEY (`CODIGO_OFICIO`) REFERENCES òficios` (`CODIGO_OFICIO`), ADD FOREIGN KEY (`CODIGO_DE_CIUDAD`) REFERENCES `ciudad` (`CODIGO_DE_CIUDAD`), ADD FOREIGN KEY (`CODIGO_SECCION`) REFERENCES `seccion` (`CODIGO_SECCION`), ADD FOREIGN KEY (`CODIGO_DE_ARCHIVO`) REFERENCES àrchivo` (`CODIGO_DE_ARCHIVO`);


Práctica UCPR-IST


# # Foreign keys for table correspondencia_recibida # ALTER TABLE `correspondencia_recibida` ADD FOREIGN KEY (`CODIGO_OFICIO`) REFERENCES `oficios` (`CODIGO_OFICIO`), ADD FOREIGN KEY (`CODIGO_SECCION`) REFERENCES `seccion` (`CODIGO_SECCION`), ADD FOREIGN KEY (`CODIGO_DE_CIUDAD`) REFERENCES `ciudad` (`CODIGO_DE_CIUDAD`), ADD FOREIGN KEY (`CODIGO_DE_ARCHIVO`) REFERENCES `archivo` (`CODIGO_DE_ARCHIVO`); /*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */; /*!40101 SET SQL_MODE=@OLD_SQL_MODE */; /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */; /*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */; /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */; /*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

Como se pudo ver anteriormente esta base de datos está conectada con el software. A continuación se muestra el diseño final de las Pantallas y su respectivo código.

En la figura 8.4.2. Se muestra la Pantalla de validación de usuario.

Figura 8.4.2. Pantalla de validación de Usuario.


Práctica UCPR-IST


A continuación se muestra el código de la figura 8.4.2.

Imports Mysql.Data.MySqlClient

Public Class LoginForm1

Public clave As String

Private conexion As MySql.Data.MySqlClient.MySqlConnection

Private comando As MySqlCommand

Private lector As MySqlDataReader

Private cadenaConexion As String

' TODO: inserte el código para realizar autenticación

personalizada usando el nombre de usuario y la contraseña

proporcionada

' (Consulte http://go.microsoft.com/fwlink/?LinkId=35339).

' El objeto principal personalizado se puede adjuntar al objeto

principal del subproceso actual como se indica a continuación:

' My.User.CurrentPrincipal = CustomPrincipal

' donde CustomPrincipal es la implementación de IPrincipal

utilizada para realizar la autenticación.

' Posteriormente, My.User devolverá la información de identidad

encapsulada en el objeto CustomPrincipal

' como el nombre de usuario, nombre para mostrar, etc.

Private Sub OK_Click(ByVal sender As System.Object, ByVal e As

System.EPantallargs) Handles OK.Click

usuario()

End Sub

Private Sub Cancel_Click(ByVal sender As System.Object, ByVal e As

System.EPantallargs) Handles Cancel.Click

Me.Close()

End Sub

Private Sub LoginForm1_Load(ByVal sender As System.Object, ByVal e

As System.EPantallargs) Handles MyBase.Load

End Sub

Private Sub UsernameLabel_Click(ByVal sender As System.Object,

ByVal e As System.EPantallargs) Handles UsernameLabel.Click

End Sub

Private Sub usuario()

cadenaConexion = "Data

Source=localhost;DataBase=correspondencia;User id=root;password=root;"

conexion = New MySqlConnection(cadenaConexion)

conexion.Open()

comando = New MySqlCommand()

comando.Connection = conexion

comando.CommandType = CommandType.Text


Práctica UCPR-IST


comando.CommandText = "select CLAVE,NOMBRE from usuario where

CLAVE ='" & PasswordTextBox.Text & "'And NOMBRE ='" &

UsernameTextBox.Text & "' "

lector = comando.ExecuteReader()

lector.Read()

If UsernameTextBox.Text = lector.GetValue(1) And

PasswordTextBox.Text = lector.GetValue(0) Then

clave = lector.GetValue(0)

Me.Hide()

Form1.Show()

Else

MsgBox("Usuario o Clave incorrecta")

End If

lector.Close()

conexion.Close()

End Sub

End Class

En la figura 8.4.3. Se presenta el diseño de la Pantalla de ofrecer servicios del menú principal.

Figura 8.4.3. Pantalla del Menú principal


Práctica UCPR-IST



Public Class Form1

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As

System.EPantallargs) Handles MyBase.Load

End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e

As System.EPantallargs) Handles Button1.Click

Me.Hide()

Form2.Show()

End Sub



Me.Hide()

Form3.Show()

End Sub



Me.Hide()

Form4.Show()

End Sub



Me.Hide()

Form6.Show()

End Sub



Me.Hide()

Form7.Show()

End Sub



Me.Close()

End

End Sub

Private Sub Label2_Click(ByVal sender As System.Object, ByVal e As

System.EPantallargs) Handles Label2.Click

End Sub

End Class


Práctica UCPR-IST


En la figura 8.4.4. Se muestra la Pantalla de la correspondencia despachada

Figura 8.4.4. Pantalla de Correspondencia Despachada.



Public Class Form2







Me.Hide()

Form1.Show()

End Sub



End Sub


Práctica UCPR-IST


Private Sub ComboBox1_SelectedIndexChanged(ByVal sender As

System.Object, ByVal e As System.EPantallargs) Handles

ComboBox1.SelectedIndexChanged

End Sub

Private Sub MonthCalendar1_DateChanged(ByVal sender As

System.Object, ByVal e As System.Windows.Forms.DateRangeEPantallargs)

End Sub

Private Sub ComboBox4_SelectedIndexChanged(ByVal sender As

System.Object, ByVal e As System.EPantallargs) Handles

ComboBox4.SelectedIndexChanged

End Sub



guardar()

End Sub

Private Sub guardar()

Dim numerodeoficio As String

Dim codigoseccion As String

Dim codigodedespacho As String

Dim codigodearchivo As String

Dim codigooficio As String

Dim destinatario As String

Dim entidadopersona As String

Dim objetooreferencia As String

Dim seccionopersona As String

Dim numerodelegajo As String

Dim numerodefolio As String

Dim numerodecaja As String

Dim subseccion As String

Dim serie As String

Dim subserie As String

Dim departamento As String

Dim municipio As String

Dim cadenaSql1 As String



Dim Resultado As String

Dim incremento As String

Dim codigodeciudad As String

Dim clave As String

Dim fechadeoficiodia As String

Dim fechadeoficiomes As String

Dim fechadeoficioano As String




conexion.Open()




Práctica UCPR-IST



incremento = 1

comando.CommandText = ("SELECT MAX(CODIGO_OFICIO) AS

CODIGO_OFICIO FROM oficios;")


lector.Read()

codigooficio = lector.GetValue(0) + incremento

lector.Close()

comando.CommandText = ("SELECT MAX(CODIGO_DE_ARCHIVO) AS

CODIGO_DE_ARCHIVO FROM archivo;")


lector.Read()

codigodearchivo = lector.GetValue(0) + incremento

lector.Close()

comando.CommandText = ("SELECT MAX(CODIGO_DE_DESPACHO) AS

CODIGO_DE_DESPACHO FROM correspondencia_despachada;")


lector.Read()

codigodedespacho = lector.GetValue(0) + incremento

lector.Close()

numerodeoficio = TextBox1.Text

destinatario = TextBox2.Text

entidadopersona = TextBox3.Text

objetooreferencia = TextBox4.Text

seccionopersona = TextBox5.Text

numerodefolio = TextBox6.Text

numerodelegajo = TextBox7.Text

numerodecaja = TextBox8.Text

subseccion = ComboBox1.Text

serie = ComboBox2.Text

subserie = ComboBox3.Text

departamento = ComboBox4.Text

municipio = ComboBox5.Text

fechadeoficiodia = ComboBox11.Text

fechadeoficiomes = ComboBox10.Text

fechadeoficioano = ComboBox9.Text

clave = LoginForm1.clave

comando.CommandText = ("select CODIGO_SECCION from seccion

where SUBSECCION ='" & subseccion & "'And SERIE='" & serie & "'And

SUBSERIE='" & subserie & "' ")


lector.Read()

codigoseccion = lector.GetValue(0)

lector.Close()

comando.CommandText = ("select CODIGO_DE_CIUDAD from ciudad

where MUNICIPIO ='" & municipio & "'And DEPARTAMENTO='" & departamento

& "' ")


lector.Read()

codigodeciudad = lector.GetValue(0)


Práctica UCPR-IST


lector.Close()

cadenaSql1 = String.Format("Insert Into oficios

(CODIGO_OFICIO, NUMERO_DE_OFICIO,

OBJETO_O_REFERENCIA,ENTIDAD_O_PERSONA,FECHA_DE_OFICIO_DIA,FECHA_DE_OFI

CIO_MES,FECHA_DE_OFICIO_ANO)

values('{0}','{1}','{2}','{3}','{4}','{5}','{6}')", codigooficio,

numerodeoficio, objetooreferencia, entidadopersona, fechadeoficiodia,

fechadeoficiomes, fechadeoficioano)

cadenaSql2 = String.Format("Insert Into archivo

(CODIGO_DE_ARCHIVO,NUMERO_DE_LEGAJO,NUMERO_DE_FOLIO,NUMERO_DE_CAJA,COD

IGO_SECCION,CODIGO_DE_CIUDAD, CLAVE)

values('{0}','{1}','{2}','{3}','{4}','{5}','{6}')", codigodearchivo,

numerodelegajo, numerodefolio, numerodecaja, codigoseccion,

codigodeciudad, clave)

cadenaSql3 = String.Format("Insert Into

correspondencia_despachada

(CODIGO_DE_DESPACHO,DESTINATARIO,SECCION_O_PERSONA,CODIGO_OFICIO,CODIG

O_DE_CIUDAD, CODIGO_SECCION, CODIGO_DE_ARCHIVO)

values('{0}','{1}','{2}','{3}','{4}','{5}','{6}')", codigodedespacho,

destinatario, seccionopersona, codigooficio, codigodeciudad,

codigoseccion, codigodearchivo)

comando.CommandText = cadenaSql1

Resultado = comando.ExecuteNonQuery()





conexion.Close()

End Sub

Private Sub ver()





conexion.Open()





comando.CommandText = ("Select * From oficios,

correspondencia_despachada, archivo, seccion, ciudad where

NUMERO_DE_OFICIO='" & numerodeoficio & "'AND oficios.CODIGO_OFICIO =


Práctica UCPR-IST


correspondencia_despachada.CODIGO_OFICIO AND

correspondencia_despachada.CODIGO_DE_ARCHIVO =

archivo.CODIGO_DE_ARCHIVO AND seccion.CODIGO_SECCION =

correspondencia_despachada.CODIGO_SECCION AND ciudad.CODIGO_DE_CIUDAD

= correspondencia_despachada.CODIGO_DE_CIUDAD ")


lector.Read()

TextBox1.Text = lector.GetValue(1)








ComboBox1.Text = lector.GetValue(22)








lector.Close()

conexion.Close()

End Sub

Private Sub modificar()














Dim serie As String







Práctica UCPR-IST





Dim clave As String







conexion.Open()





















comando.CommandText = ("select CODIGO_OFICIO from oficios

where NUMERO_DE_OFICIO ='" & numerodeoficio & "'")


lector.Read()

codigooficio = lector.GetValue(0)

lector.Close()

codigodearchivo = codigooficio

codigodedespacho = codigooficio





lector.Read()


lector.Close()



& "' ")



Práctica UCPR-IST


lector.Read()


lector.Close()

cadenaSql1 = String.Format("Update oficios set

NUMERO_DE_OFICIO = '{1}', OBJETO_O_REFERENCIA =

'{2}',ENTIDAD_O_PERSONA = '{3}',FECHA_DE_OFICIO_DIA =

'{4}',FECHA_DE_OFICIO_MES = '{5}',FECHA_DE_OFICIO_ANO = '{6}'WHERE

CODIGO_OFICIO = '{0}' ", codigooficio, numerodeoficio,

objetooreferencia, entidadopersona, fechadeoficiodia,


cadenaSql2 = String.Format("Update archivo set

NUMERO_DE_LEGAJO = '{1}',NUMERO_DE_FOLIO = '{2}',NUMERO_DE_CAJA =

'{3}',CODIGO_SECCION = '{4}',CODIGO_DE_CIUDAD = '{5}',CLAVE = '{6}'

WHERE CODIGO_DE_ARCHIVO = '{0}' ", codigodearchivo, numerodelegajo,

numerodefolio, numerodecaja, codigoseccion, codigodeciudad, clave)

cadenaSql3 = String.Format("Update correspondencia_despachada

set DESTINATARIO = '{1}',SECCION_O_PERSONA = '{2}',CODIGO_OFICIO =

'{3}',CODIGO_DE_CIUDAD = '{4}', CODIGO_SECCION = '{5}',

CODIGO_DE_ARCHIVO = '{6}' WHERE CODIGO_DE_DESPACHO = '{0}'",

codigodedespacho, destinatario, seccionopersona, codigooficio,

codigodeciudad, codigoseccion, codigodearchivo)







conexion.Close()

End Sub

Private Sub eliminar()

Dim Resultado1 As String













conexion.Open()



Práctica UCPR-IST






where NUMERO_DE_OFICIO = '" & numerodeoficio & "'")


lector.Read()


lector.Close()


codigodedespacho = codigooficio

cadenaSql1 = String.Format("delete From

correspondencia_despachada where CODIGO_DE_DESPACHO ='{0}'",

codigodedespacho)

cadenaSql2 = String.Format("delete From archivo where

CODIGO_DE_ARCHIVO ='{0}'", codigodearchivo)

cadenaSql3 = String.Format("delete From oficios where

CODIGO_OFICIO ='{0}'", codigooficio)


Resultado1 = comando.ExecuteNonQuery()





conexion.Close()

End Sub

Private Sub Label18_Click(ByVal sender As System.Object, ByVal e

As System.EPantallargs)

End Sub

Private Sub TextBox9_TextChanged(ByVal sender As System.Object,

ByVal e As System.EPantallargs)

End Sub



ver()

End Sub



modificar()

End Sub


Práctica UCPR-IST




eliminar()

End Sub

End Class

En la figura 8.4.5. Se muestra la Pantalla de la correspondencia Recibida.

Figura 8.4.5. Pantalla de la correspondencia Recibida.



Public Class Form3






As System.EPantallargs)

Me.Hide()

Form1.Show()

End Sub


Práctica UCPR-IST




End Sub

Private Sub guardar()



Dim codigorecibido As String



Dim remitente As String


Dim direccion As String


Dim telefono As String





Dim serie As String








Dim incremento As String


Dim clave As String




Dim fecharecibidodia As String

Dim fecharecibidomes As String

Dim fecharecibidoano As String

Dim fecharadicadodia As String

Dim fecharadicadomes As String

Dim fecharadicadoano As String




conexion.Open()




incremento = 1

comando.CommandText = ("SELECT MAX(CODIGO_OFICIO) AS

CODIGO_OFICIO FROM oficios;")


lector.Read()

codigooficio = lector.GetValue(0) + incremento


Práctica UCPR-IST


lector.Close()

comando.CommandText = ("SELECT MAX(CODIGO_DE_ARCHIVO) AS

CODIGO_DE_ARCHIVO FROM archivo;")


lector.Read()

codigodearchivo = lector.GetValue(0) + incremento

lector.Close()

comando.CommandText = ("SELECT MAX(CODIGO_RECIBIDO) AS

CODIGO_RECIBIDO FROM correspondencia_recibida;")


lector.Read()

codigorecibido = lector.GetValue(0) + incremento

lector.Close()


remitente = TextBox2.Text


direccion = TextBox4.Text


telefono = TextBox6.Text












fecharecibidodia = ComboBox14.Text

fecharecibidomes = ComboBox13.Text

fecharecibidoano = ComboBox12.Text

fecharadicadodia = ComboBox17.Text

fecharadicadomes = ComboBox16.Text

fecharadicadoano = ComboBox15.Text






lector.Read()


lector.Close()



& "' ")


lector.Read()



Práctica UCPR-IST


lector.Close()

cadenaSql1 = String.Format("Insert Into oficios

(CODIGO_OFICIO, NUMERO_DE_OFICIO,

OBJETO_O_REFERENCIA,ENTIDAD_O_PERSONA,FECHA_DE_OFICIO_DIA,FECHA_DE_OFI

CIO_MES,FECHA_DE_OFICIO_ANO)

values('{0}','{1}','{2}','{3}','{4}','{5}','{6}')", codigooficio,

numerodeoficio, objetooreferencia, entidadopersona, fechadeoficiodia,


cadenaSql2 = String.Format("Insert Into archivo

(CODIGO_DE_ARCHIVO,NUMERO_DE_LEGAJO,NUMERO_DE_FOLIO,NUMERO_DE_CAJA,COD

IGO_SECCION,CODIGO_DE_CIUDAD,CLAVE)

values('{0}','{1}','{2}','{3}','{4}','{5}','{6}')", codigodearchivo,

numerodelegajo, numerodefolio, numerodecaja, codigoseccion,

codigodeciudad, clave)

cadenaSql3 = String.Format("Insert Into

correspondencia_recibida

(CODIGO_RECIBIDO,REMITENTE,DIRECCION,TELEFONO,CODIGO_OFICIO,CODIGO_DE_

CIUDAD, CODIGO_SECCION, CODIGO_DE_ARCHIVO, FECHA_RECIBIDO_DIA,

FECHA_RECIBIDO_MES, FECHA_RECIBIDO_ANO, FECHA_RADICADO_DIA,

FECHA_RADICADO_MES, FECHA_RADICADO_ANO)

values('{0}','{1}','{2}','{3}','{4}','{5}','{6}','{7}','{8}','{9}','{1

0}','{11}','{12}','{13}')", codigorecibido, remitente, direccion,

telefono, codigooficio, codigodeciudad, codigoseccion,

codigodearchivo, fecharecibidodia, fecharecibidomes, fecharecibidoano,

fecharadicadodia, fecharadicadomes, fecharecibidoano)







conexion.Close()

End Sub

Private Sub ver()





conexion.Open()





comando.CommandText = ("Select * From oficios,

correspondencia_recibida, archivo, seccion, ciudad where

NUMERO_DE_OFICIO='" & numerodeoficio & "'AND oficios.CODIGO_OFICIO =

correspondencia_recibida.CODIGO_OFICIO AND


Práctica UCPR-IST


correspondencia_recibida.CODIGO_DE_ARCHIVO = archivo.CODIGO_DE_ARCHIVO

AND seccion.CODIGO_SECCION = correspondencia_recibida.CODIGO_SECCION

AND ciudad.CODIGO_DE_CIUDAD =

correspondencia_recibida.CODIGO_DE_CIUDAD ")


lector.Read()
























lector.Close()

conexion.Close()

End Sub

Private Sub modificar()















Dim serie As String




Práctica UCPR-IST








Dim clave As String



































where NUMERO_DE_OFICIO ='" & numerodeoficio & "'")


lector.Read()


lector.Close()


codigorecibido = codigooficio





lector.Read()


Práctica UCPR-IST



lector.Close()



& "' ")


lector.Read()


lector.Close()

cadenaSql1 = String.Format("Update oficios set

NUMERO_DE_OFICIO = '{1}', OBJETO_O_REFERENCIA =

'{2}',ENTIDAD_O_PERSONA = '{3}',FECHA_DE_OFICIO_DIA =

'{4}',FECHA_DE_OFICIO_MES = '{5}',FECHA_DE_OFICIO_ANO = '{6}'WHERE

CODIGO_OFICIO = '{0}' ", codigooficio, numerodeoficio,

objetooreferencia, entidadopersona, fechadeoficiodia,


cadenaSql2 = String.Format("Update archivo set

NUMERO_DE_LEGAJO = '{1}',NUMERO_DE_FOLIO = '{2}',NUMERO_DE_CAJA =

'{3}',CODIGO_SECCION = '{4}',CODIGO_DE_CIUDAD = '{5}',CLAVE = '{6}'

WHERE CODIGO_DE_ARCHIVO = '{0}' ", codigodearchivo, numerodelegajo,

numerodefolio, numerodecaja, codigoseccion, codigodeciudad, clave)

cadenaSql3 = String.Format("Update correspondencia_recibida

set REMITENTE = '{1}',DIRECCION = '{2}', TELEFONO = '{3}',

CODIGO_OFICIO = '{4}',CODIGO_DE_CIUDAD = '{5}', CODIGO_SECCION =

'{6}', CODIGO_DE_ARCHIVO = '{7}', FECHA_RECIBIDO_DIA = '{8}',

FECHA_RECIBIDO_MES = '{9}', FECHA_RECIBIDO_ANO = '{10}',

FECHA_RADICADO_DIA = '{11}', FECHA_RADICADO_MES = '{12}',

FECHA_RADICADO_ANO = '{13}' WHERE CODIGO_RECIBIDO = '{0}'",

codigorecibido, remitente, direccion, telefono, codigooficio,

codigodeciudad, codigoseccion, codigodearchivo, fecharecibidodia,

fecharecibidomes, fecharecibidoano, fecharadicadodia,

fecharadicadomes, fecharadicadoano)







conexion.Close()

End Sub

Private Sub eliminar()






Práctica UCPR-IST











conexion.Open()






where NUMERO_DE_OFICIO = '" & numerodeoficio & "'")


lector.Read()


lector.Close()


codigorecibido = codigooficio

cadenaSql1 = String.Format("delete From

correspondencia_recibida where CODIGO_RECIBIDO ='{0}'",

codigorecibido)

cadenaSql2 = String.Format("delete From archivo where

CODIGO_DE_ARCHIVO ='{0}'", codigodearchivo)

cadenaSql3 = String.Format("delete From oficios where

CODIGO_OFICIO ='{0}'", codigooficio)







conexion.Close()

End Sub



guardar()

End Sub

Private Sub Button1_Click_1(ByVal sender As System.Object, ByVal e


Me.Hide()

Form1.Show()

End Sub


Práctica UCPR-IST




ver()

End Sub



modificar()

End Sub



eliminar()

End Sub

End Class

En la figura 8.4.6. Se muestra la Pantalla de la Búsqueda de la correspondencia.

Figura 8.4.6. Pantalla de la Búsqueda de la correspondencia.


Option Explicit On

Option Strict On



Práctica UCPR-IST


Public Class Form4







End Sub



Me.Hide()

Form1.Show()

End Sub



End Sub



Me.Hide()

Form5.Show()

buscar()

End Sub

Private Sub buscar()

Dim adaptador As New MySqlDataAdapter

Dim consultas As New DataTable




Dim fechaoficiodia As String

Dim fechaoficiomes As String

Dim fechaoficioano As String

















Práctica UCPR-IST


Dim serie As String







conexion.Open()







fechaoficiodia = ComboBox11.Text

fechaoficiomes = ComboBox10.Text

fechaoficioano = ComboBox9.Text




















comando.CommandText = ("Select * From consultas Where

NUMERO_DE_OFICIO = '" & numerodeoficio & "' OR OBJETO_O_REFERENCIA =

'" & objetooreferencia & "' OR ENTIDAD_O_PERSONA = '" &

entidadopersona & "' OR FECHA_DE_OFICIO_DIA = '" & fechaoficiodia & "'

OR FECHA_DE_OFICIO_MES = '" & fechaoficiomes & "' OR

FECHA_DE_OFICIO_ANO = '" & fechaoficioano & "' OR DESTINATARIO = '" &

destinatario & "' OR SECCION_O_PERSONA = '" & seccionopersona & "' OR

REMITENTE = '" & remitente & "' OR DIRECCION = '" & direccion & "' OR

TELEFONO = '" & telefono & "' OR FECHA_RECIBIDO_DIA = '" &

fecharecibidodia & "' OR FECHA_RECIBIDO_MES = '" & fecharecibidomes &

"' OR FECHA_RECIBIDO_ANO = '" & fecharecibidoano & "' OR

FECHA_RADICADO_DIA = '" & fecharadicadodia & "' OR FECHA_RADICADO_MES

= '" & fecharadicadomes & "' OR FECHA_RADICADO_ANO = '" &

fecharadicadoano & "' OR NUMERO_DE_LEGAJO = '" & numerodelegajo & "'

OR NUMERO_DE_FOLIO = '" & numerodefolio & "' OR NUMERO_DE_CAJA = '" &

numerodecaja & "' OR SUBSECCION = '" & subseccion & "' OR SERIE = '" &


Práctica UCPR-IST


serie & "' OR SUBSERIE = '" & subserie & "' OR DEPARTAMENTO = '" &

departamento & "' OR MUNICIPIO = '" & municipio & "'")

adaptador.SelectCommand = comando

adaptador.Fill(consultas)

Form5.DataGridView1.DataSource = consultas


conexion.Close()

End Sub

End Class

En la figura 8.4.7. Se muestra la pantalla de la correspondencia encontrada.

Figura 8.4.7. Pantalla de la correspondencia encontrada.




Práctica UCPR-IST


Public Class Form5



End Sub



Me.Hide()

Form4.Show()

End Sub

Private Sub DataGridView1_CellContentClick(ByVal sender As

System.Object, ByVal e As

System.Windows.Forms.DataGridViewCellEPantallargs)

End Sub

Private Sub DataGridView1_CellContentClick_1(ByVal sender As



End Sub

Private Sub FillByToolStripButton_Click(ByVal sender As

System.Object, ByVal e As System.EPantallargs)

End Sub

Private Sub ArchivoBindingSource_CurrentChanged(ByVal sender As

System.Object, ByVal e As System.EPantallargs)

End Sub

Private Sub FillByToolStrip_ItemClicked(ByVal sender As


System.Windows.Forms.ToolStripItemClickedEPantallargs)

End Sub

Private Sub DataGridView1_CellContentClick_2(ByVal sender As



End Sub

End Class

En la figura 8.4.8. Se muestra la Pantalla de informes de correspondencia.


Práctica UCPR-IST


Figura 8.4.8. Pantalla de Informes de Correspondencia.


Option Explicit On

Option Strict On


Public Class Form4







End Sub



Me.Hide()

Form1.Show()

End Sub



End Sub


Práctica UCPR-IST




Me.Hide()

Form5.Show()

buscar()

End Sub

Private Sub buscar()

Dim adaptador As New MySqlDataAdapter

Dim consultas As New DataTable




Dim fechaoficiodia As String

Dim fechaoficiomes As String

Dim fechaoficioano As String
















Dim serie As String







conexion.Open()







fechaoficiodia = ComboBox11.Text

fechaoficiomes = ComboBox10.Text

fechaoficioano = ComboBox9.Text






Práctica UCPR-IST

















comando.CommandText = ("Select * From consultas Where

NUMERO_DE_OFICIO = '" & numerodeoficio & "' OR OBJETO_O_REFERENCIA =

'" & objetooreferencia & "' OR ENTIDAD_O_PERSONA = '" &

entidadopersona & "' OR FECHA_DE_OFICIO_DIA = '" & fechaoficiodia & "'

OR FECHA_DE_OFICIO_MES = '" & fechaoficiomes & "' OR

FECHA_DE_OFICIO_ANO = '" & fechaoficioano & "' OR DESTINATARIO = '" &

destinatario & "' OR SECCION_O_PERSONA = '" & seccionopersona & "' OR

REMITENTE = '" & remitente & "' OR DIRECCION = '" & direccion & "' OR

TELEFONO = '" & telefono & "' OR FECHA_RECIBIDO_DIA = '" &

fecharecibidodia & "' OR FECHA_RECIBIDO_MES = '" & fecharecibidomes &

"' OR FECHA_RECIBIDO_ANO = '" & fecharecibidoano & "' OR

FECHA_RADICADO_DIA = '" & fecharadicadodia & "' OR FECHA_RADICADO_MES

= '" & fecharadicadomes & "' OR FECHA_RADICADO_ANO = '" &

fecharadicadoano & "' OR NUMERO_DE_LEGAJO = '" & numerodelegajo & "'

OR NUMERO_DE_FOLIO = '" & numerodefolio & "' OR NUMERO_DE_CAJA = '" &

numerodecaja & "' OR SUBSECCION = '" & subseccion & "' OR SERIE = '" &

serie & "' OR SUBSERIE = '" & subserie & "' OR DEPARTAMENTO = '" &

departamento & "' OR MUNICIPIO = '" & municipio & "'")

adaptador.SelectCommand = comando

adaptador.Fill(consultas)

Form5.DataGridView1.DataSource = consultas


conexion.Close()

End Sub

End Class

En la figura 8.4.9. Se muestra la pantalla del manual de usuario.


Práctica UCPR-IST


Figura 8.4.9. Pantalla del manual de Usuario.


Public Class Form7



Me.Hide()

Form1.Show()

End Sub

Private Sub ReportViewer1_Load(ByVal sender As System.Object,

ByVal e As System.EPantallargs) Handles ReportViewer1.Load

End Sub



End Sub

End Class


Práctica UCPR-IST


9. CONCLUSIONES

Se logro cumplir con el objetivo general, el cual se desarrollo un software para el manejo y control de la correspondencia para la Registraduría Nacional del estado Civil, Delegación Departamental del Risaralda, Centro de acopio.

El software llamado Sistema de Correspondencia es un prototipo el cual fue diseñado en visual estudio .Net el cual está conectado con una base de datos en Mysqul, el cual cumple con la funcionalidad y los objetivos específicos trazados.

Se logro cumplir con el cronograma de actividades propuesto en el documento del plan de práctica. Ya que todas las entregas se realizaron en las fechas estipuladas por prácticas profesionales.

Este prototipo también puede ser utilizado en todas las Registraduría del país para el manejo de su correspondencia en cada dependencia.

Se realizo la ingeniería del software para este proyecto de intervención contenido en el capítulo 8 presentación de análisis y resultado, el cual le permite a cualquier ingeniero o practicante realizar mejoras o modificaciones al prototipo para ir logrando la optimización del programa a las necesidades que se puedan presentar en un futuro.

El prototipo cumple con todas las exigencias dadas por la empresa para el manejo de su correspondencia y finalmente su búsqueda.

Se cumplió con la expectativa de la realización de la práctica profesional, el cual fue una experiencia muy enriquecedora en el ámbito profesional y personal, ya que se adquiere experiencia laboral para un futuro en el cual hagamos parte de una organización ya formados como ingenieros.


Práctica UCPR-IST


10. RECOMENDACIONES

Se deben hacer mejoras al prototipo para optimizar su buen funcionamiento ya que por cuestiones de tiempo de la práctica solo se tiene un primer diseño del software, pero en el que queda toda la documentación e ingeniería del software que permite a cualquier practicante o ingeniero hacer estas modificaciones o mejoras para un mejor rendimiento.

El prototipo contiene un manual de usuario el cual debe ser leído por el usuario para un buen funcionamiento del software.

Para el ingreso de la información de la correspondencia se debe asignar un número único de oficio, en el cual se llama Número de oficio. Este número puede ser la combinación del número de legajo, folio, caja y fecha del oficio, como por ejemplo:

Numero Legajo: 1

Número de Folio: 2

Número de Caja: 3

Fecha de Oficio: Día: 4 Mes 5 Año: 2010

Número de Oficio: 1234512010

Esta combinación permite asignarle un número único a los oficios, el cual permite un mejor control de toda la correspondencia.

Si por alguna razón se olvida el nombre de usuario o contraseña, se puede trabajar con el Usuario: admin Contraseña: 12345


Práctica UCPR-IST


BIBLIOGRAFIA

[1]. Weitzenfeld: INGENIERIA DE SOFTWARE ORIENTADA A OBJETOS, Teoría y Práctica con UML y Java. Capítulo 6, PAG 1- 46 Modelo de Requisitos [2]. Weitzenfeld: INGENIERIA DE SOFTWARE ORIENTADA A OBJETOS, Teoría y Práctica con UML y Java. Capítulo 7, PAG 1- 61 Modelo de Análisis [3]. Weitzenfeld: INGENIERIA DE SOFTWARE ORIENTADA A OBJETOS, Teoría y Práctica con UML y Java. Capítulo 8, PAG 1- 117 Modelo de Diseño. [4]. Weitzenfeld: INGENIERIA DE SOFTWARE ORIENTADA A OBJETOS, Teoría y Práctica con UML y Java. Capítulo 9, PAG 1- 38 Implementación. [5] Mirar 7.3.1 identificación de los interesados. PRESSMAN, Roger. Ingeniería del software un enfoque práctico. Sexta edición. Mc Graw Hill. [6] Todos aquellos que se benefician de una forma directa o indirecta del sistema que está en desarrollo. [7] Mirar 7.3.4 Formulación de las primeras preguntas. PRESSMAN, Roger. Ingeniería del software un enfoque práctico. Sexta edición. Mc Graw Hill. [8] Mirar 7.4.2 Despliegue de la función de calidad. PRESSMAN, Roger. Ingeniería del software un enfoque práctico. Sexta edición. Mc Graw Hill.

[9] Mirar 5.3.2 Estudio de viabilidad. PRESSMAN, Roger. Ingeniería del software un enfoque práctico. tercera edición. Mc Graw Hill.


Práctica UCPR-IST


ANEXOS

MANUAL DE USUARIO

Este manual es una guía práctica para que el usuario, pueda hacer mejor uso del software del Sistema de correspondencia.

En la figura 1. Se muestra la Pantalla de validación de usuario.

Figura 1. Venta de validación de Usuario.

En la figura 1. Se debe ingresar el nombre de usuario y contraseña, que se encuentran en la base de datos. Si por alguna razón no puede ingresar al sistema con su nombre de usuario o contraseña puede hacerlo con el Usuario: admin Contraseña: 12345.

Luego da click en aceptar para ingresar o click en cancelar para salir del sistema.

En la figura 2 se muestra la pantalla del menú correspondencia.


Práctica UCPR-IST


Figura 2.Pantalla del Menú principal

En la figura 2, hay 6 opciones que el usuario puede elegir.

1. Correspondencia Despachada 2. Correspondencia Recibida 3. Buscar Correspondencia 4. Informes Correspondencia 5. Manual de Usuario 6. Salir

En el cual haciendo doble click puede ingresar a cualquiera de estas opciones.

En la figura 3. Se muestra la Pantalla de la correspondencia despachada


Práctica UCPR-IST


Figura 3. Pantalla de Correspondencia Despachada.

En la figura 3. Se debe ingresar la información de la correspondencia despachada.


Numero Legajo: 1

Número de Folio: 2

Número de Caja: 3




Guardar


Práctica UCPR-IST


Para guardar la información se debe ingresar toda la información en el formulario de la pantalla correspondencia despachada, y luego se debe dar doble click en el botón guardar.

Ver

Para poder ver la información debe ingresar el Numero de Oficio, y luego doble click en el botón ver.

Modificar

Para modificar primero debe ingresar el Numero de oficio que desea modificar, y dar primero doble click en ver, luego aparece la información en el formulario, la cual la podrá modificar, posteriormente debe dar doble click en el botón modificar.

Eliminar

Para eliminar debe ingresar el Numero de Oficio que desea eliminar, posterior mente debe dar doble click en el botón eliminar.

Menú

Para regresar a la pantalla del menú principal debe dar doble click en el botón menú.


Práctica UCPR-IST


En la figura 4 Se muestra la Pantalla de la correspondencia Recibida.

Figura 4 Pantalla de la correspondencia Recibida.

En la figura 4. Se debe ingresar la información de la correspondencia Recibida.


Numero Legajo: 1

Número de Folio: 2

Número de Caja: 3





Práctica UCPR-IST


Guardar

Para guardar la información se debe ingresar toda la información en el formulario de la pantalla correspondencia despachada, y luego se debe dar doble click en el botón guardar.

Ver

Para poder ver la información debe ingresar el Numero de Oficio, y luego doble click en el botón ver.

Modificar

Para modificar primero debe ingresar el Numero de oficio que desea modificar, y dar primero doble click en ver, luego aparece la información en el formulario, la cual la podrá modificar, posteriormente debe dar doble click en el botón modificar.

Eliminar

Para eliminar debe ingresar el Numero de Oficio que desea eliminar, posterior mente debe dar doble click en el botón eliminar.

Menú

Para regresar a la pantalla del menú principal debe dar doble click en el botón menú.


Práctica UCPR-IST


En la figura 5. Se muestra la Pantalla de la Búsqueda de la correspondencia.

Figura 5 Pantalla de la Búsqueda de la correspondencia.

En la figura 5. Se puede buscar la información por cualquier tipo de información que se tenga.

Se ingresa la información de la correspondencia que se desea buscar, posteriormente debe dar doble click en el botón buscar.

Para regresar al menú principal debe dar doble click en el botón de Menú.


Práctica UCPR-IST


En la figura 6. Se muestra la pantalla de la correspondencia encontrada.

Figura 6. Pantalla de la correspondencia encontrada.

En la figura 6. Es la parte donde se puede visualizar la información de la correspondencia encontrada.

Para regresar a la pantalla de Búsqueda de correspondencia se debe dar doble click en el botón Regresar.


Práctica UCPR-IST


En la figura 7. Se muestra la Pantalla de informes de correspondencia.

Figura 7. Pantalla de Informes de Correspondencia.

En la figura 7. Se puede generar informes de la correspondencia según el mes y al año que se desea obtener de la correspondencia ya sea Despachada O recibida.

Posteriormente se debe dar doble click en el botón de generar informe. En este informe también se puede cambia, o modificar la información que se tiene.

Para regresar al menú principal debe dar doble click en el botón de menú.


Práctica UCPR-IST


En la figura 8. Se muestra la pantalla del manual de usuario.

Figura 8. Pantalla del manual de Usuario.

En la figura 8. Se puede ver la información general del manejo del software. Por medio del documento Manual de Usuario.

Para regresar a la pantalla del menú principal debe dar doble click en el botón Menú.

Y para cerrar el programa del todo debe ir a la pantalla del menú, que se observo en la figura 2. Y dar doble click en el botón Salir.


Práctica UCPR-IST


Anexo un CD Sistema de Correspondencia, con el siguiente contenido:

1. Software Sistema de Correspondencia.

2. Mysqul 5.

3. Documentación del Software.

Nota: Toda esta documentación e información o software solo puede ser utilizada para fines educativos, y no puede ser comercializada.

repositorio.ucp.edu.corepositorio.ucp.edu.co/bitstream/10785/3048/1/CDPEIST23.pdf · Sistema de...

Documents

Transcript of repositorio.ucp.edu.corepositorio.ucp.edu.co/bitstream/10785/3048/1/CDPEIST23.pdf · Sistema de...