Herramienta para el seguimiento de reuniones

Texto completo

(1)HERRAMIENTA PARA EL SEGUIMIENTO DE REUNIONES. ALEJANDRO METKE JIMÉNEZ. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DEPARTAMENTO DE SISTEMAS PREGRADO BOGOTA 2002.

(2) ISC-2003-1-30. HERRAMIENTA PARA EL SEGUIMIENTO DE REUNIONES. ALEJANDRO METKE JIMENEZ. TESIS DE GRADO. PROFESOR JUAN PABLO QUIROGA. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA, DEPARTAMENTO DE SISTEMAS PREGRADO BOGOTA 2003.

(3) ISC-2003-1-30. A mi mamá y a mi papá por su apoyo incondicional..

(4) ISC-2003-1-30. CONTENIDO pág. INTRODUCCIÓN ............................................................................................... 1 1. OBJETIVOS .................................................................................................. 3 1.1 GENERALES................................................................................................ 3 1.2 ESPECÍFICOS ............................................................................................. 3 2. MARCO TEÓRICO .......................................................................................... 5 2.1 COMUNICACIÓN AL INTERIOR DE UN PROYECTO DE SOFTWARE ....................... 5 2.2 XML .......................................................................................................... 9 2.3 SOAP ........................................................................................................ 9 2.4 WEB SERVICES..........................................................................................10 2.5 JAX-RPC ...................................................................................................10 2.6 EXTREME PROGRAMMING............................................................................11 2.7 EL PROTOCOLO JABBER .............................................................................14 3. ARQUITECTURA ...........................................................................................16 4. ANÁLISIS DEL MÓDULO DE ADMINISTRACIÓN .................................................18.

(5) ISC-2003-1-30. 5. DISEÑO DEL MÓDULO DE ADMINISTRACIÓN ...................................................31 6. ANÁLISIS DEL MÓDULO DE CONVERSACIÓN....................................................37 7. DISEÑO DEL MÓDULO DE CONVERSACIÓN ......................................................47 8. CONCLUSIONES Y TRABAJO FUTURO ..............................................................52 BIBLIOGRAFÍA ................................................................................................54.

(6) ISC-2003-1-30. LISTA DE FIGURAS pág. Figura 1. Diagrama de arquitectura de la aplicación. .............................................16 Figura 2. Diagrama de casos de uso del módulo de administración..........................18 Figura 3. Diagrama de clases del módulo de administración. ..................................31 Figura 4. Diagrama de secuencia del caso de uso Crear Usuario .............................33 Figura 5. Diagrama de secuencia del caso de uso Eliminar Usuario..........................33 Figura 6. Diagrama de secuencia del caso de uso Crear Grupo. ..............................33 Figura 7. Diagrama de secuencia del caso de uso Eliminar Grupo............................34 Figura 8. Diagrama de secuencia del caso de uso Crear Proyecto. ...........................34 Figura 9. Diagrama de secuencia del caso de uso Eliminar Proyecto. .......................35 Figura 10. Diagrama de secuencia del caso de uso Autenticar Usuario. ....................35 Figura 11. Diagrama de secuencia del caso de uso Cambiar Password Usuario. .........36 Figura 12. Diagrama de casos de uso del módulo de conversación. .........................37 Figura 13. Diagrama de clases del prototipo de conversación sencillo ......................47 Figura 14. Diagrama de clases del módulo de conversación ...................................50.

(7) ISC-2003-1-30. LISTA DE TABLAS pág. Tabla 1. Caso de uso Crear Usuario ....................................................................19 Tabla 2. Caso de uso Modificar Usuario ...............................................................19 Tabla 3. Caso de uso Eliminar Usuario ................................................................20 Tabla 4. Caso de uso Crear Grupo ......................................................................21 Tabla 5. Caso de uso Modificar Grupo .................................................................21 Tabla 6. Caso de uso Eliminar Grupo ..................................................................22 Tabla 7. Caso de uso Crear Proyecto ..................................................................23 Tabla 8. Caso de uso Modificar Proyecto..............................................................23 Tabla 9. Caso de uso Eliminar Proyecto ...............................................................24 Tabla 10. Caso de uso Ver Información Usuario....................................................25 Tabla 11. Caso de uso Ver Usuarios Sistema........................................................25 Tabla 12. Caso de uso Ver Información Grupo......................................................26 Tabla 13. Caso de uso Ver Grupos Sistema..........................................................26 Tabla 14. Caso de uso Ver Información Proyecto ..................................................27 Tabla 15. Caso de uso Ver Proyectos Grupo .........................................................27 Tabla 16. Caso de uso Autenticar Usuario............................................................28 Tabla 17. Caso de uso Autenticar Administrador...................................................28 Tabla 18. Caso de uso Cambiar Password Usuario ................................................29 Tabla 19. Caso de uso Reset Password Usuario ....................................................30 Tabla 20. Caso de uso Ingresar al Sistema ..........................................................38 Tabla 21. Caso de uso Salir del Sistema ..............................................................38 Tabla 22. Caso de uso Cambiar de Proyecto ........................................................39.

(8) ISC-2003-1-30. Tabla 23. Caso de uso Cambiar Contraseña .........................................................40 Tabla 24. Caso de uso Enviar Mensaje ................................................................40 Tabla 25. Caso de uso Enviar Archivo .................................................................41 Tabla 26. Caso de uso Descargar Archivo ............................................................41 Tabla 27. Caso de uso Consultar Bitácora Reunión................................................42 Tabla 28. Caso de uso Exportar Bitácora .............................................................43 Tabla 29. Caso de uso Programar Reunión...........................................................43 Tabla 30. Caso de uso Comenzar Reunión ...........................................................44 Tabla 31. Caso de uso Pasar Siguiente Punto Reunión ...........................................44 Tabla 32. Caso de uso Generar Bitácora Reunión..................................................45.

(9) ISC-2003-1-30. LISTA DE ANEXOS pág. ANEXO A ........................................................................................................54.

(10) ISC-2003-1-30. INTRODUCCIÓN Un proceso de comunicación exitoso al interior de un grupo de trabajo es un elemento fundamental para el éxito de un proyecto. Los avances en el campo de las telecomunicaciones han permitido trabajar en equipo a personas que se encuentran separadas físicamente por miles de kilómetros. Sin embargo, los medios de comunicación disponibles en la actualidad no permiten un grado de realismo comparable con el de la presencia física. Estos grados de realismo varían dependiendo de las herramientas utilizadas y del presupuesto de las personas involucradas en el proceso. Las herramientas pueden ir desde el correo electrónico hasta la videoconferencia. La mayoría de éstas están diseñadas para ser de propósito general y son efectivas para la mayoría de procesos de comunicación simples. Sin embargo, si el proceso de comunicación es más complejo y no se cuenta con una herramienta adecuada, el resultado muy seguramente no va a ser satisfactorio. La mayoría de estas características generales de los procesos de comunicación se pueden ver plasmadas en el caso concreto de los grupos de construcción de software. A través del crecimiento masivo de Internet se ha logrado unir a muchos desarrolladores de todo el mundo en torno a un mismo proyecto de software (como en el caso de Linux y de otros proyectos de código abierto). Desde luego que esto no hubiera sido posible sin las herramientas necesarias (repositorios de software, foros, etc.). En el ámbito académico también se ha eliminado la necesidad imperativa de reunirse de manera presencial para algunas tareas. Es común ver a los estudiantes comunicándose a través de herramientas de mensajería instantánea para coordinar detalles de los proyectos cuando se encuentran todos físicamente en lugares distintos. Esto se debe a varios motivos. Primero, la mayoría de personas en el medio tienen acceso a un computador con conexión a Internet. Además, este medio resulta más adecuado para el caso de una reunión de más de dos personas que otros medios tradicionales, como el teléfono, ya que permite a todos participar simultáneamente. Las deficiencias que presenta también son varias. La velocidad del proceso se ve reducida ya que se debe hacer a través de la escritura en el teclado. Resulta mucho más sencillo comunicarse oralmente. Las personas que se encuentran conectadas pueden tener más contactos que se encuentren conectados al mismo tiempo y que no pertenecen a la reunión, generándose así un factor de distracción considerable. En el caso de algunas herramientas en concreto, existen límites en el número de personas que pueden conversar simultáneamente, volviendo la herramienta inservible para un grupo con un mayor número de integrantes de los que permite. Para los cursos de construcción de software en pregrado, el problema de la presencia física por lo general no se presenta ya que los estudiantes pasan la mayoría de su tiempo en las instalaciones de la universidad. Sin embargo, en los cursos de postgrado, el problema sí se presenta más a menudo ya que la mayoría de estudiantes trabaja y por lo tanto tienen menos tiempo disponible en un espacio físico común. Además, en un proyecto de software la frecuencia de las reuniones puede ser alta debido a la necesidad de llevar a cabo reuniones de seguimiento que pueden llegar a 1.

(11) ISC-2003-1-30. tener una frecuencia semanal. Este proyecto pretende dilucidar los elementos claves en el proceso de comunicación al interior de un proyecto de software para así poder diseñar e implementar una herramienta, que no solo permita llevar a cabo el proceso de la mejor manera posible dadas las limitaciones obvias, sino que además brinde funcionalidades adicionales que le sean de utilidad al grupo de trabajo.. 2.

(12) ISC-2003-1-30. 1. OBJETIVOS 1.1 GENERALES 1. Conocer acerca de los procesos de comunicación, haciendo énfasis en los relacionados con los grupos de construcción de software, con el objetivo de tener bases sólidas para el diseño de la herramienta. 2. Investigar acerca de las tecnologías disponibles actualmente para realizar aplicaciones cliente – servidor como la que se pretende construir en este proyecto. 3. Escoger una metodología de desarrollo apropiada, tomando en cuenta las características del proyecto y el tiempo disponible. 4. Diseñar la herramienta de seguimiento de reuniones utilizando la metodología escogida y tomando en cuenta las necesidades que se derivan del proceso de comunicación al interior de un grupo de construcción de software. 5. Implementar la herramienta diseñada utilizando las tecnologías y las herramientas de desarrollo escogidas. 1.2 ESPECÍFICOS 1. Investigar acerca de la teoría de la comunicación al interior de los grupos de construcción de software. Esto incluye identificar los diferentes procesos de comunicación que se pueden presentar y los mecanismos y herramientas que se utilizan para llevarlos acabo actualmente. 2. Investigar el protocolo Jabber y decidir si puede ser de utilidad para la elaboración de la herramienta. 3. Recolectar información acerca de la tecnología de web services para el lenguaje de programación Java. 4. Identificar los puntos más relevantes de la metodología de desarrollo Extreme Programming. 5. Buscar una forma adecuada de dividir el proceso de creación de la herramienta para adecuarlo a la metodología de Extreme Porgramming. 6. Buscar un manejador de bases de datos adecuado para manejar la persistencia del proyecto. 7. Decidir de qué forma se va a manejar la persistencia y la interacción de la aplicación con el manejador de base de datos. 3.

(13) ISC-2003-1-30. 8. Diseñar y desarrollar la primera parte del proyecto (en el primer semestre de trabajo). 9. Diseñar y desarrollar la segunda parte del proyecto (en el segundo semestre de trabajo). 10. Sacar conclusiones acerca de la metodología de trabajo y de la herramienta construida.. 4.

(14) ISC-2003-1-30. 2. MARCO TEÓRICO Para la elaboración de este proyecto se deben tener en cuenta aspectos tecnológicos al igual que aspectos relacionados directamente con el problema que se está tratando de resolver. Primero se tratará el tema de la comunicación, que está relacionado directamente con el problema, y posteriormente los diferentes temas tecnológicos. 2.1 COMUNICACIÓN AL INTERIOR DE UN PROYECTO DE SOFTWARE [1] En la Ingeniería de Software la comunicación entre los miembros de un equipo es fundamental para lograr el éxito de un proyecto. Hay muchos ejemplos en la historia que nos muestran cómo un error de comunicación puede llevar a un fracaso rotundo. Aunque muchas veces se le resta importancia frente a otros factores, una buena comunicación entre los miembros de un equipo de desarrollo es igual de importante a un buen diseño o a una implementación eficiente. Existen diferentes clasificaciones de la comunicación que son útiles para entender las diferentes necesidades de intercambio de información que se pueden presentar al interior de un proyecto. Los modos de comunicación se refieren al tipo de intercambio de información mientras que los mecanismos de comunicación se refieren a las herramientas o procedimientos que pueden usarse para recibir y transmitir información. Los modos de comunicación pueden ser de dos tipos: calendarizados o manejados por eventos. En la comunicación calendarizada existe un acuerdo previo con respecto al momento de la comunicación y por lo general se trata de un proceso periódico. Las reuniones semanales de seguimiento en un proyecto de Ingeniería de Software son un buen ejemplo de este tipo de comunicación. Por otra parte, la comunicación manejada por eventos ocurre cuando se presenta un evento que hace necesario un proceso de comunicación. La aparición de una duda en un documento de requerimientos puede dar lugar a una comunicación manejada por eventos a través de un correo electrónico en el cual la duda es presentada a los demás miembros del equipo de trabajo. Como se puede ver a través de los ejemplos, en el campo de la Ingeniería de Software son necesarios ambos modos de comunicación. Los mecanismos de comunicación, por su parte, se dividen en sincrónicos y asincrónicos. Los mecanismos sincrónicos requieren que el emisor y el receptor se encuentren disponibles en el momento de la comunicación. Algunos ejemplos son las reuniones presenciales, el teléfono, la videoconferencia y algunos programas de groupware. Algunos de estos mecanismos requieren que el emisor y el receptor se encuentren físicamente en el mismo lugar (como las reuniones) mientras que otros facilitan que el emisor y el receptor se encuentren en ubicaciones geográficas diferentes. Por otra parte, los mecanismos asincrónicos no requieren que el emisor y el receptor 5.

(15) ISC-2003-1-30. se encuentren disponibles en el momento de la comunicación. Algunos ejemplos son los cuestionarios, el fax y el correo electrónico. Estos mecanismos permiten que se comuniquen con rapidez gran cantidad de detalles y que haya una mayor cantidad de receptores. Hablando específicamente en el campo de la Ingeniería de Software encontramos varios modos de comunicación y mecanismos de comunicación que se describirán brevemente a continuación. Cada uno de los modos de comunicación tiene uno o más mecanismos de comunicación compatibles dada su naturaleza. Existen los siguientes modos de comunicación: 1. Definición del problema. Su objetivo es que el gerente del proyecto y el cliente se pongan de acuerdo sobre lo alcances del proyecto. Esta actividad produce un documento que indica el dominio y la funcionalidad del sistema. También puede incluir requerimientos no funcionales como la plataforma de operación. 2. Revisiones del cliente. Su objetivo es que el cliente valore los avances del desarrollo y que los desarrolladores confirmen o cambien los requerimientos del sistema. Por lo general se da en la forma de una presentación formal por parte de los desarrolladores en la que se exponen algunas de la características del producto (se puede presentar un prototipo o una muestra de la interfaz gráfica acompañada de un documento de especificaciones). Posteriormente se recibe la retroalimentación de cliente. 3. Revisiones del proyecto. Su objetivo es que el gerente del proyecto valore el estado actual y que los equipos revisen las interfaces de los subsistemas. También se puede intercambiar conocimiento operacional, como problemas comunes. 4. Inspecciones y pruebas de recorrido. Su objetivo es hacer una revisión de código entre iguales para mejorar la calidad del sistema En el caso de una inspección, se trata de verificar que el código se apegue a una lista de criterios predefinidos. En una prueba de recorrido se presenta el código línea por línea para que los demás miembros del equipo lo cuestionen y traten de descubrir la mayor cantidad de errores posibles. 5. Revisiones de estado. Estas revisiones se realizan principalmente al interior de un equipo y su objetivo es detectar desviaciones con respecto a una agenda de trabajo. También sirven para motivar a los desarrolladores a terminar sus tareas pendientes. 6. Lluvia de ideas. Su objetivo es generar y evaluar una gran cantidad de soluciones para un problema. La idea fundamental es que a partir de algunas de las propuestas que hacen los participantes, así no sean válidas, puede surgir ideas adicionales de los demás participantes. 7. Lanzamientos. Su objetivo es poner un documento o subsistema a disposición. 6.

(16) ISC-2003-1-30. de los demás miembros del equipo. Muchas veces se reemplaza una versión anterior. 8. Revisión post mortem. Su objetivo es extraer las lecciones aprendidas durante el desarrollo. Se debe llevar acabo justo después de la terminación del proyecto para evitar que se pierda o distorsione la información relevante. 9. Peticiones de aclaraciones. Su objetivo es solicitar información al respecto de cualquier aspecto del sistema que pueda resultar ambiguo. 10. Petición de cambio. Su objetivo es reportar un problema y en algunos casos proponer una solución. Por lo general este tipo de peticiones contienen una clasificación que indica el tipo y la severidad del problema encontrado. 11. Resolución de problemas. Su objetivo es comunicar a los desarrolladores la solución escogida a un determinado problema que se haya reportado. Existen los siguientes mecanismos de comunicación: 1. Conversaciones en pasillos. Son intercambios de información manejados por eventos basados en la oportunidad. Los participantes se reúnen accidentalmente y aprovechan para intercambiar información. Es un mecanismo sincrónico ya que requiere que los participantes estén presentes en el momento de la comunicación. Soporta las peticiones de aclaración y peticiones de cambio. 2. Cuestionarios y entrevistas estructuradas. Son formas de obtener información de los participantes con respecto a algún aspecto del proyecto. Se pueden utilizar para varios objetivos como comprender los requerimientos del usuario, obtener conocimiento del dominio de los usuarios y expertos y para extraer las lecciones aprendidas en el post mortem. Es un mecanismo sincrónico ya que requiere que los participantes estén presentes en el momento de la comunicación. Apoya las definiciones de problemas y las revisiones post mortem. 3. Reuniones. Son el mecanismo más eficiente para solucionar problemas y generar consenso. Para aumentar su eficiencia se asignan papeles a los participantes de tal manera que haya un moderador, un secretario de actas y un tomador de tiempo. También existe una agenda de reunión elaborada previamente que contiene un encabezado con los datos de la reunión (ubicación, tiempo y participantes), una lista de asuntos que deberán reportar los participantes y una lista de temas que se deben tratar. Al final se produce una minuta de reunión que incluye los mismos campos de la agenda con la respectiva información que se compartió y las decisiones que se tomaron en cada punto. Es un mecanismo sincrónico ya que requiere que los participantes estén presentes en el momento de la comunicación, ya sea de manera presencial o a través de algún medio de comunicación como la videoconferencia. Soporta las revisiones del cliente, la revisión del proyecto, las inspecciones, las revisiones de estado, las revisiones post mortem, las lluvias. 7.

(17) ISC-2003-1-30. de ideas y las resoluciones de problemas. Son reuniones formales durante las cuales una parte externa evalúa la calidad de algún elemento (código, documento, etc.). Por lo general, se realizan con una presentación formal seguida de varias peticiones de cambio. Es un mecanismo sincrónico ya que requiere que los participantes estén presentes en el momento de la comunicación. Soportan las revisiones del proyecto y las inspecciones y pruebas de recorrido. 4. Groupware en diferentes lugares y al mismo tiempo. Son herramientas que permiten que varios usuarios en localizaciones diferentes interactúen al mismo tiempo. Los usuarios “entran” a salones de conversación y todos pueden ver el mismo estado. Por lo general solo uno puede modificarlo en un momento dado. Existen casos en los que el control es anárquico (cualquiera lo puede tomar en cualquier momento) y otros en que es control es secuencial (quien tiene el control se lo debe pasar al siguiente usuario). Un ejemplo conocido de este tipo de aplicación es NetMeeting de Microsoft. Es un mecanismo sincrónico ya que requiere que los participantes estén presentes en el momento de la comunicación. Soportan las revisiones del cliente, las revisiones del proyecto, las inspecciones, las lluvias de ideas y las resoluciones de problemas. 5. Correo electrónico. Este mecanismo permite a un usuario transmitir un mensaje de texto a uno o más destinatarios. Es asincrónico ya que el mensaje es almacenado en un buzón hasta que el receptor ingrese y lo lea. Soporta los lanzamientos, las peticiones de cambio y las lluvias de ideas. 6. Grupos de noticias. Son similares al correo electrónico pero el emisor, en lugar de enviar un mensaje a una serie de destinatarios, lo envía a un grupo de noticias al que pueden estar subscritores varios usuarios que son los que en definitiva van a recibir el mensaje. Es asincrónico ya que los destinatarios no tiene que estar disponibles en el momento en que se envía el mensaje. Soportan los lanzamientos, las peticiones de cambio y las lluvias de ideas. 7. World Wide Web. Es un mecanismo de comunicación muy popular que permite alojar proyectos y proporciona las ventajas del hipertexto y lo hipervínculos. Es asincrónico porque no requiere que los participantes estén presentes al mismo tiempo. Soporta los lanzamientos, las inspecciones de código asincrónicas, las peticiones de cambio y las lluvias de ideas. Como se puede ver de esta clasificación, dependiendo de la naturaleza de cada modo de comunicación éste puede ser soportado por uno o más mecanismos de comunicación. También se puede observar la relación entre los modos de comunicación calendarizados y los mecanismos de comunicación sincrónicos, al igual que la relación entre los modos de comunicación manejados por eventos y los mecanismos de comunicación asincrónicos. A través de esta clasificación se pueden establecer procesos de comunicación apropiados para un determinado proyecto y así contribuir a su buen funcionamiento.. 8.

(18) ISC-2003-1-30. 2.2 XML [2] Desde hace algún tiempo surgió la necesidad de establecer una comunicación remota entre aplicaciones para compartir información. Existen muchas tecnologías diferentes que fueron desarrolladas para satisfacer esta necesidad en el pasado. Sin embargo, puesto que existen muchas tecnologías y sistemas de información diferentes, muchas veces resultaba imposible o supremamente complicado realizar la interacción entre dos sistemas. A través de XML, SOAP y los web services, esta dificultad se ha logrado superar. XML son las siglas en inglés para Lenguaje de Marcado Extensible. Es una manera estandarizada de representar datos que además es independiente de cualquier sistema. Tiene similitudes en la forma de escribirse con el ya popular HTML, pero tiene dos diferencias fundamentales de fondo: las marcas de XML se refieren al significado del texto que rodean (mientras que en HTML simplemente indican cómo se debe mostrar ese texto) y además es extensible, lo que implica que el usuario puede definir sus propias marcas. El siguiente ejemplo sencillo muestra cómo se podría definir una reunión utilizando XML. <Reunión> <Nombre>Lanzamiento</Nombre> <Fecha>10/06/2003</Fecha> <Hora>19:10</Hora> </Reunión> Debido a que en XML se pueden crear marcas propias, también es posible definir un esquema que verifique que un documento sea válido para un determinado escenario según las marcas que contenga. Uno de los lenguajes para definición de esquemas más comunes hoy en día es el DTD, las siglas en inglés para Definición de Tipo de Documento. Sin embargo, ya existen otras formas de definir los esquemas como los schemas que también se escriben en XML. 2.3 SOAP [3] SOAP significa Simple Object Access Protocol, o Protocolo Simple de Acceso a Objetos. Es un protocolo liviano diseñado para intercambiar información estructurada en un ambiente distribuido y descentralizado. El protocolo se encarga de definir las pautas generales para que dos aplicaciones puedan entender los mensajes elaborados en XML. Un mensaje SOAP se origina en un nodo emisor, puede recorrer varios nodos intermedios y llega a un nodo receptor. Un mensaje SOAP contiene las siguientes partes: 1. El sobre (Envelope) es el elemento de información más externo del mensaje. Es el nodo raíz del documento XML. 2. El encabezado (Header) es un mecanismo para adicionar características al mensaje SOAP, tales como el nivel de importancia del mensaje.. 9.

(19) ISC-2003-1-30. 3. El cuerpo (Body) es el contenedor de información para el último receptor del mensaje. El siguiente es un ejemplo de un mensaje SOAP en el que se puede apreciar cada una de sus partes. <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol"> <n:priority>1</n:priority> <n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env:Header> <env:Body> <m:alert xmlns:m="http://example.org/alert"> <m:msg>Pick up Mary at school at 2pm</m:msg> </m:alert> </env:Body> </env:Envelope> 2.4 WEB SERVICES [4] Un web service es sencillamente un servicio ofrecido a través de la Web. Típicamente, el término está asociado con el uso de los protocolos HTTP y SOAP. Los web services se utilizan para compartir información entre diferentes sistemas y en general están asociadas con aplicaciones B2B (Business To Business, o Negocio a Negocio). Un escenario típico es el de un distribuidor que ofrece sus productos a través de un web service que puede ser consultado por los minoristas para determinar los precios que ofrece y las cantidades disponibles. Desde luego, la tecnología sirve para ser utilizada de diferentes formas y este es tan solo un ejemplo del uso típico que se le ha dado. 2.5 JAX-RPC [5] JAX-RPC quiere decir Interfaz de Programación de Aplicación para Llamadas de Procedimientos Remotas Basadas en XML para Java. Como su nombre lo indica, esta tecnología le permite a las aplicaciones acceder a procedimientos remotos utilizando un mecanismo de comunicación basado en XML. Aunque el nombre no implica el uso de una tecnología de comunicación en particular, en la práctica JAX-RPC utiliza SOAP y HTTP (para la versión utilizada en este proyecto se utilizan las versiones 1.1 de ambos protocolos). Si bien JAX-RPC se apoya en protocolos complejos como SOAP, explicado anteriormente, para el programador esta complejidad está oculta. Para exponer un procedimiento como un web service basta con definirlo en una interfaz de Java e implementarla en una clase. Desde el punto de vista del cliente solo es necesario crear un proxy e invocar los métodos remotos sobre él, como si fueran locales.. 10.

(20) ISC-2003-1-30. Otra gran ventaja de JAX-RPC es que los procedimientos remotos pueden ser accedidos por clientes escritos en otros lenguajes de programación. Los clientes de JAX-RPC también pueden acceder a procedimientos remotos escritos en otros lenguajes de programación que cumplan con los estándares del WC3. Los procedimientos remotos se describen utilizando WSDL, un lenguaje basado en XML que le permite a los clientes saber de qué forma interactuar con el web service. Todo esto es posible gracias a la estandarización de las tecnologías. 2.6 EXTREME PROGRAMMING [6] Extreme Programming es una metodología de desarrollo de software liviana que permite abordar algunos tipos de proyectos de manera más eficiente que las metodologías tradicionales. En general, se puede decir que esta metodología es útil cuando el proyecto tiene requerimientos cambiantes, representa algo nuevo para los desarrolladores y tiene un grupo pequeño de desarrollo (2 – 10 integrantes, incluyendo a todas las personas que hacen parte del proyecto, no solo a los desarrolladores). En este proyecto se utilizan algunas de las ideas expuestas por esta metodología, ya que se ajustan a sus características. Existen diferentes pautas que se deben seguir en cada etapa del proceso de construcción de la herramienta. A continuación se expondrán brevemente, aunque no todas fueron utilizadas en este proyecto. Planeación •. Se utilizan historias escritas del usuario. Las historias del usuario deben reemplazar a los casos de uso utilizados tradicionalmente. Se diferencian de éstos en el nivel de detalle. Por lo general constan de una explicación breve del requerimiento en el lenguaje del cliente. Esta regla no se usa en el proyecto.. •. La planeación de los lanzamientos genera el cronograma. Se debe estimar el tiempo ideal que tomará crear la aplicación y planear las iteraciones del proyecto. Se debe acordar un cronograma que todas las partes involucradas puedan cumplir.. •. Se deben lanzar versiones pequeñas frecuentemente. Se debe tratar de dividir la funcionalidad de la herramienta en pequeñas unidades funcionales que tengan lógica en el esquema global de la aplicación.. •. Se debe medir la velocidad del proyecto. Esta medida es sencillamente la relación entre los estimados y la cantidad de historias de usuario que fueron terminadas en una iteración. Esta regla no se usa en el proyecto.. •. El proyecto se debe dividir en iteraciones que deben durar entre una y tres semanas. No se debe implementar nada que no esté planeado para esta iteración.. 11.

(21) ISC-2003-1-30. •. Al comienzo de cada iteración se debe acordar un plan. Se deben escoger las historias del usuario que sean más importantes para desarrollar primero, al igual que las pruebas de aceptación que hayan fallado.. •. Se deben rotar a las personas al interior del proyecto para evitar cuellos de botella en áreas específicas. Al rotar a las personas se garantiza que no solo una persona va a poder trabajar en un área determinada del proyecto. De esta forma se pueden asignar más personas para trabajar en un área si así se requiere. Esta regla no se usa en el proyecto porque solo hay una persona desarrollando el proyecto.. •. Se debe hacer una reunión diaria de pie que incluya a todos los miembros del equipo. Con esto se busca eliminar las reuniones pequeñas e innecesarias y reemplazarlas por una sola que sea realmente útil. Esta regla no se usa en el proyecto.. •. Si las reglas de la metodología fallan se deben buscar mecanismos para arreglarlas.. Diseño •. Se debe intentar mantener la simplicidad en el diseño. Si se encuentra una forma de hacer las cosas que sea más sencilla y que funcione, se debe utilizar. En este punto también es importante recordar la regla de no adicionar funcionalidades adicionales antes de que sean programadas.. •. Se deben nombrar las clases y los métodos de manera consistente. Para esto se debe escoger una metáfora del sistema. Saber de qué manera se va a nombrar algo al interior del proyecto ayuda a la comprensión del diseño y ahorra tiempo.. •. Se deben utilizar tarjetas CRC (Clases, Responsabilidades, Colaboración). Cada tarjeta representa un objeto. Con esto se busca una mayor participación de las personas en el diseño global y también que se pueda apreciar mejor la metodología orientada por objetos. Esta regla no se usa en el proyecto.. •. Se deben crear soluciones de punta para solucionar problemas complicados. Una solución de punta es un programa sencillo que explora posibles soluciones al problema.. •. No se debe incluir funcionalidad adicional en el proyecto antes de tiempo. El 90% de la funcionalidad adicional que se piensa que puede necesitarse en los proyectos en el futuro termina sin utilizarse, lo que implica un desperdicio de tiempo.. •. Se debe rediseñar constantemente para mantener el diseño lo más simple posible. Los desarrolladores tienen la tendencia de no tocar el código que funciona bien sin tener en cuenta que muchas veces contiene funcionalidades que ya no se usan y que podría simplificarse. Rediseñar constantemente ayuda. 12.

(22) ISC-2003-1-30. a mejorar la calidad del proyecto. Codificación •. El cliente siempre debe estar disponible. Todas las fases requieren comunicación directa con el cliente. El cliente debe ser considerado parte del proyecto.. •. El código que se escriba debe seguir los estándares acordados. Esto mantiene el código entendible para todo el equipo.. •. Se deben codificar las pruebas primero. Esto ayuda a planear bien la codificación del programa y ayuda a determinar qué es lo que verdaderamente debe hacerse. Si bien sí se hicieron pruebas unitarias, esta regla no se usa en el proyecto.. •. Todo el código que se incluya en una versión definitiva debe ser escrito por dos personas trabajando en un solo computador. Esto ayuda a incrementar la calidad del software. Esta regla no se usa en el proyecto.. •. La integración de código se debe hacer de manera secuencial. Existen muchos problemas que surgen de la integración de código en paralelo. Si solo se permite a una pareja integrar su código a la vez se reducen los problemas de integración y se ahorra tiempo. Esta regla no se usa en el proyecto.. •. Las integraciones de código se deben realizar frecuentemente. Nunca se debe mantener una porción de código sin integrar por más de un día. Esto evita problemas de integración graves como los que se pueden presentar si se decide integrar mucho código en un rango de tiempo mayor. Esta regla no se usa en el proyecto.. •. El código debe ser de pertenencia colectiva. Esto implica que cualquier persona del equipo puede modificar porciones de código o arreglar problemas. Si el código pertenece a todos los miembros del equipo el sistema se vuelve más confiable. Además, siempre existe la posibilidad de que un miembro del equipo tenga que irse del proyecto y si era la única persona encargada de algunas de las clases se necesita un mayor esfuerzo para reemplazarlo. Esta regla no se usa en el proyecto.. •. La optimización se debe dejar para el final. No se debe tratar de adivinar cual va a ser el cuello de botella sino que se debe medir al final. Lo más importante es que funcione y después que funcione rápido.. •. No se debe trabajar tiempo extra. Esto por lo general desmotiva al equipo de trabajo y en la mayoría de los casos el proyecto no va a estar listo a tiempo de todas formas. También es mala idea incluir más personas en el proyecto para tratar de acabar a tiempo.. 13.

(23) ISC-2003-1-30. Pruebas •. Todo el código debe tener pruebas unitarias. Todo el código se debe ingresar al repositorio con pruebas unitarias. Ningún fragmento de código puede ser lanzado oficialmente sin que tenga pruebas. Este proyecto tiene pruebas unitarias pero no para todo el código, así que esta regla en realidad no se usa.. •. Todo el código debe pasar las pruebas unitarias antes de ser lanzado. Todas las pruebas unitarias que se hicieron para este proyecto fueron pasadas por le código. Sin embargo, como no hay pruebas unitarias para todo el código, se puede decir que esta regla no se usa.. •. Cuando aparece un error se deben crear pruebas para impedir que vuelva a aparecer, Esta regla no se usa en el proyecto.. •. Se corren pruebas de aceptación a menudo y se publican los resultados. Estas pruebas se sacan de las historias de los usuarios y son de caja negra. El cliente es el responsable de verificar que la repuesta del sistema coincida con la respuesta esperada. Esta regla no se usa en el proyecto.. 2.7 EL PROTOCOLO JABBER [7] Antes de comenzar a construir la aplicación desde ceros, se pensó en investigar otros proyectos que tuvieran alguna relación con este y que pudieran ser utilizados como base o como referencia. Uno de estos proyectos es Jabber. Jabber es un protocolo abierto, basado en XML, para mensajería instantánea. Utiliza comunicación TCP/IP a través de mensajes XML. Existen varios servidores y clientes escritos en diferentes lenguajes de programación que se apegan a sus especificaciones. Principalmente se utiliza para aplicaciones de mensajería instantánea pero los clientes tienen muy pocas restricciones lo que permite incorporar en ellos funcionalidades adicionales sin comprometer la compatibilidad con los servidores Jabber. Estas restricciones son: 1. Se deben comunicar con los servidores Jabber a través de sockets TCP. 2. Deben hacer parsing e interpretar paquetes de XML bien formados. 3. Deben entender los tipos de datos de los mensajes. El sistema se compone de cuatro componentes básicos que tienen la capacidad de comunicarse con uno o más de los otros componentes. Estos son: clientes Jabber, servidores Jabber, transportes y enrrutadores “Etherx” y se explican a continuación: 1. Clientes: Cada usuario final se comunica con la arquitectura Jabber a través de un cliente que se comunica utilizando comunicación TCP simple para hablar con un servidor. Por lo general solo se comunican con los servidores.. 14.

(24) ISC-2003-1-30. 2. Servidores: Los servidores están encargados de escuchar las comunicaciones de los clientes y de comunicarse con ellos. Esta comunicación incluye servicios básicos como autenticación de usuarios, almacenamiento de mensajes offline, y almacenamiento de las listas de contacto del usuario. También están encargados de comunicarse con el componente “Etherx” para permitirle al servidor hablar con otros servidores y transportes. 3. Transportes: Son programas que permiten que Jabber se comunique con otros servidores que no son servidores Jabber. 4. Enrrutadores Etherx: Se comunica con los servidores Jabber y transportes para permitirles hablar entre ellos. La documentación es extensa y se encuentran varias implementaciones tanto de servidores como de clientes en varios lenguajes de programación con el código fuente disponible. Después de este análisis se decidió no utilizar este protocolo para la implementación por las siguientes razones: 1. Los beneficios de interconectividad con otras herramientas de mensajería instantánea no son relevantes para este proyecto. 2. El protocolo está diseñado para aplicaciones de mensajería instantánea y si bien permite cierto grado de adaptación, este grado no es lo suficientemente alto para los requerimientos del proyecto. 3. Adaptarse a las especificaciones del protocolo implica un esfuerzo de programación considerable, al tener que hacer manualmente el parsing de los mensajes XML, por ejemplo, sin que se reciban otros beneficios significativos a cambio.. 15.

(25) ISC-2003-1-30. 3. ARQUITECTURA Para el proceso de desarrollo, y tomando en cuenta la metodología de Extreme Programming, se debe dividir la herramienta en dos módulos que puedan ser diseñados e implementados de manera separada. El primero es el módulo de administración de usuarios y el segundo es el módulo de conversación como tal. El módulo de conversación depende del módulo de administración de usuarios, pero el módulo de administración de usuarios no depende del módulo de conversación y por lo tanto se podría utilizar para administrar los usuarios de otra aplicación. En este capítulo se va a describir la arquitectura de toda la aplicación y en los capítulos posteriores se tratará cada módulo por separado. El siguiente es el diagrama de arquitectura de la aplicación: Figura 1. Diagrama de arquitectura de la aplicación.. 16.

(26) ISC-2003-1-30. Cada módulo presta servicios a otros componentes de la aplicación. El módulo de administración presta servicios de autenticación y de administración de usuarios a los servlets de administración y al módulo de conversación. El módulo de conversación presta los servicios de conversación al cliente. Si bien ambos componentes se pueden montar sobre el mismo servidor de aplicaciones, es preferible montarlos en servidores diferentes. La configuración expuesta en el diagrama es la ideal ya que por motivos de seguridad los servicios prestados por el módulo de administración no deben estar expuestos públicamente mientras que los del módulo de conversación sí.. 17.

(27) ISC-2003-1-30. 4. ANÁLISIS DEL MÓDULO DE ADMINISTRACIÓN Los usuarios de la herramienta y los casos de uso se deben identificar a partir del análisis de los procesos de comunicación al interior de los proyectos de construcción de software, de las experiencias personales en este tipo de grupos en el ámbito académico y de la discusión. Hay dos usuarios que interactúan con este módulo: el usuario administrador, que es el encargado de administrar los usuarios del sistema, y el usuario representado por el módulo de conversación, que depende de los servicios de administración de usuarios para ofrecer algunas funcionalidades al usuario final. Los requerimientos se pueden ver en el diagrama de casos de usos de este módulo. Figura 2. Diagrama de casos de uso del módulo de administración.. 18.

(28) ISC-2003-1-30. La estructura de este módulo se debe diseñar pensando en un curso universitario orientado a la construcción de software, de tal forma que la herramienta sea útil en el ámbito académico. En el sistema existen usuarios, grupos y proyectos. Haciendo una analogía con el ejemplo de un curso universitario, el sistema sería la universidad, un usuario un estudiante, un grupo un curso y un proyecto un grupo de trabajo al interior de un curso. De aquí se pueden deducir todas las relaciones entre ellos que se podrán observar más adelante en el diagrama de clases. Los casos de uso detallados se muestran a continuación. Tabla 1. Caso de uso Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico de Eventos:. Caminos de Excepción:. Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. Crear Usuario Crear Usuario CU1 Necesario Alta Ciclo 1 El administrador agrega un nuevo usuario al sistema. 1. El usuario le indica al sistema que desea agregar un nuevo usuario. 2. El sistema le pide el login, el password y el correo electrónico al usuario. 3. El administrador ingresa los datos del usuario. 4. El sistema le confirma al administrador que el nuevo usuario ha sido creado. • En el punto 4, el administrador ingresa un correo electrónico que ya se encuentra registrado en el sistema. El sistema le indica que el usuario que está intentando crear ya existe y regresa al punto 2. • En el punto 4, el administrador no introduce un login para el nuevo usuario. El sistema le indica que debe ingresar un login para el usuario y regresa al punto 2. Ninguno. El administrador le indica al sistema que quiere crear un nuevo usuario. Ninguna. Ninguna. Se ha creado un nuevo usuario.. Tabla 2. Caso de uso Modificar Usuario Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración:. Modificar Usuario CU2 Necesario Alta Ciclo 1 19.

(29) ISC-2003-1-30. Resumen: Curso Básico de Eventos:. Caminos de Excepción:. Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. Tabla 3. Caso de uso Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico de Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers:. El administrador modifica un usuario del sistema. 1. El administrador le indica al sistema que quiere modificar un usuario. 2. El sistema le muestra al administrador la lista de usuarios del sistema. 3. El administrador escoge el usuario que quiere modificar. 4. El sistema le muestra al administrador el email del usuario. 5. El administrador modifica el email o el password del usuario. 6. El sistema actualiza la información. • En el punto 6 el administrador ingresa un email que ya se encuentra en el sistema. El sistema le indica que el nuevo email es inválido. • En el punto 6 el administrador cambia el password por uno que no cumple las políticas de seguridad. En el sistema le indica que el nuevo password no es válido. Ninguno. El administrador le indica al sistema que quiere modificar un usuario. Ninguna. Ninguna. Se ha modificado un usuario.. Eliminar Usuario Eliminar Usuario CU3 Necesario Alta Ciclo 1 El administrador elimina un usuario del sistema. 1. El administrador le indica al sistema que quiere eliminar un usuario. 2. El sistema le muestra al administrador la lista de usuarios del sistema. 3. El administrador escoge el usuario que quiere eliminar. 4. El sistema le pide una confirmación al administrador, 5. El administrador confirma. 6. El sistema elimina el usuario. • En el punto 5 el administrador no confirma la eliminación del usuario. El sistema le indica que ha cancelado la acción. Ninguno. El administrador le indica al sistema que quiere eliminar un usuario.. 20.

(30) ISC-2003-1-30. Suposiciones: Pre-condiciones: Post- Condiciones:. Ninguna. Ninguna. Se ha eliminado un usuario.. Tabla 4. Caso de uso Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen:. Crear Grupo Crear Grupo CU4. Curso Básico de Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. Tabla 5. Caso de uso Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico de Eventos:. Necesario Alta Ciclo 1 El administrador crea un nuevo grupo en el sistema. Un grupo en el ámbito académico es equivalente a un curso. 1. El administrador le indica al sistema que quiere adicionar un nuevo grupo. 2. El sistema le pide al administrador el nombre del nuevo grupo. 3. El administrador ingresa el nombre del grupo. 4. El sistema le muestra al administrador la lista de usuarios en el sistema para que escoja los que pertenecen al grupo. 5. El administrador escoge a los usuarios. 6. El sistema actualiza los datos en el sistema. • En el punto 4 el administrador ingresa un nombre de grupo que ya existe. El sistema le informa que el nombre que quiere ya se encuentra en uso y se devuelve al punto 2. Ninguno. El administrador le indica al sistema que quiere crear un nuevo grupo. Ninguna. Existen usuarios en el sistema. Se ha creado un nuevo grupo.. Modificar Grupo Modificar Grupo CU5 Necesario Alta Ciclo 1 El administrador adiciona o quita usuarios de un grupo del sistema. 1. El administrador le indica al sistema que quiere modificar un grupo. 2. El sistema le muestra al administrador la lista de grupos en el sistema. 21.

(31) ISC-2003-1-30. Caminos de Excepción:. Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. Tabla 6. Caso de uso Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico de Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones:. 3. El administrador escoge el grupo que quiere modificar. 4. El sistema le muestra al administrador los miembros del grupo. 5. El administrador elimina a los miembros que sea necesario 6. El sistema le muestra la lista de usuarios del sistema. 7. El administrador escoge a los usuarios que quiera agregar. 8. El sistema actualiza la información • En el punto 6 el administrador ingresa un nombre de grupo que ya existe. El sistema le informa que el nombre que quiere ya se encuentra en uso y se devuelve al punto 4. • En el punto 10 el administrador intenta agregar un miembro que ya existe en el grupo. El sistema le indica que una persona no se puede agregar dos veces al mismo grupo y se devuelve al punto 8. Ninguno. El administrador le indica al sistema que quiere modificar un grupo. Ninguna. Ninguna. Se ha modificado un grupo.. Eliminar Grupo Eliminar Grupo CU6 Necesario Alta Ciclo 1 El administrador elimina un grupo del sistema. 1. El administrador le indica al sistema que quiere eliminar un grupo. 2. El sistema le muestra al administrador la lista de grupos del sistema. 3. El administrador escoge el grupo que quiere eliminar. 4. El sistema le pide una confirmación al administrador, 5. El administrador confirma. 6. El sistema elimina el grupo. • En el punto 5 el administrador no confirma la eliminación del grupo. El sistema le indica que ha cancelado la acción. Ninguno. El administrador le indica al sistema que quiere eliminar un grupo. Ninguna. Ninguna. 22.

(32) ISC-2003-1-30. Post- Condiciones:. Se ha eliminado un grupo.. Tabla 7. Caso de uso Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen:. Crear Proyecto Crear Proyecto CU7. Curso Básico de Eventos:. Caminos de Excepción:. Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. Necesario Alta Ciclo 1 El administrador crea un nuevo proyecto en el sistema. Un proyecto en el ámbito académico es equivalente a un grupo de trabajo al interior de un curso. 1. El administrador le indica al sistema que quiere adicionar un nuevo proyecto. 2. El sistema le muestra al administrador la lista de grupos que existen en el sistema. 3. El administrador escoge el grupo al que quiere que pertenezca el proyecto. 4. El sistema le pide al administrador el nombre y la descripción del nuevo proyecto. 5. El administrador ingresa el nombre y la descripción del proyecto. 6. El sistema le muestra al administrador la lista de usuarios en el grupo para que escoja el líder del proyecto. 7. El administrador escoge al líder. 8. El sistema le muestra al administrador la lista de usuarios en el grupo para que escoja los otros miembros del proyecto. 9. El administrador escoge a los usuarios. 10. El sistema actualiza los datos en el sistema. • En el punto 6 el administrador ingresa un nombre de proyecto que ya existe. El sistema le informa que el nombre que quiere ya se encuentra en uso y se devuelve al punto 4. Ninguno. El administrador le indica al sistema que quiere crear un nuevo proyecto. Ninguna. Existe por lo menos un grupo en el sistema. Existe por lo menos un usuario en el grupo del proyecto. Se ha creado un nuevo proyecto.. Tabla 8. Caso de uso Modificar Proyecto Identificador Modificar Proyecto Nombre Caso de CU8. 23.

(33) ISC-2003-1-30. Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico de Eventos:. Caminos de Excepción:. Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. Tabla 9. Caso de uso Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico de Eventos:. Necesario Alta Ciclo 1 El administrador modifica un proyecto del sistema. 1. El administrador le indica al sistema que quiere modificar un proyecto. 2. El sistema le pide al administrador que busque el proyecto que quiere modificar. 3. El administrador escoge el proyecto que quiere modificar. 4. El sistema le muestra al administrador la descripción del proyecto. 5. El administrador los modifica si es necesario. 6. El sistema le muestra al administrador los miembros del proyecto. 7. El administrador elimina a los miembros que sea necesario. 8. El sistema le muestra la lista de usuarios del grupo al cual pertenece el proyecto. 9. El administrador escoge a los usuarios que quiera agregar. 10. El sistema actualiza la información • En el punto 10 el administrador intenta agregar un miembro que ya existe en el proyecto. El sistema le indica que una persona no se puede agregar dos veces al mismo proyecto y se devuelve al punto 8. CU13, CU14, CU15. El administrador le indica al sistema que quiere modificar un proyecto. Ninguna. Ninguna. Se ha modificado un proyecto.. Eliminar Proyecto Eliminar Proyecto CU9 Necesario Alta Ciclo 1 El administrador elimina un proyecto del sistema. 1. El administrador le indica al sistema que quiere eliminar un proyecto. 2. El sistema le pide al administrador que busque el proyecto que quiere eliminar. 3. El administrador escoge el proyecto que quiere 24.

(34) ISC-2003-1-30. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. eliminar. 4. El sistema le pide una confirmación al administrador. 5. El administrador confirma. 6. El sistema elimina el proyecto. • En el punto 5 el administrador no confirma la eliminación del proyecto. El sistema le indica que ha cancelado la acción. CU13, CU15. El administrador le indica al sistema que quiere eliminar un proyecto. Ninguna. Ninguna. Se ha eliminado un proyecto.. Tabla 10. Caso de uso Ver Información Usuario Identificador Ver Información Usuario CU10 Nombre Caso de Uso: Necesario/Deseable Necesario Prioridad Alta Iteración: Ciclo 1 Resumen: El administrador le pide al sistema la información de un usuario. Curso Básico de 1. El administrador le indica al sistema que quiere ver la Eventos: información de un usuario. 2. El sistema le pide al administrador que busque el usuario. 3. El administrador escoge el usuario. 4. El sistema le muestra los datos registrados (nombre y correo electrónico), los grupos a los que pertenece y los proyectos de los que hace parte. Caminos de Ninguno. Excepción: Puntos de CU11. Extensión: Triggers: El administrador le indica al sistema que quiere ver la información de un usuario. Suposiciones: Ninguna. Pre-condiciones: Ninguna. Post- Condiciones: Se ha mostrado la información de un usuario.. Tabla 11. Caso de uso Ver Usuarios Sistema Identificador Ver Usuarios del Sistema CU11 Nombre Caso de Uso: Necesario/Deseable Necesario 25.

(35) ISC-2003-1-30. Prioridad Iteración: Resumen: Curso Básico de Eventos: Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. Alta Ciclo 1 El administrador le pide al sistema la lista de usuarios del sistema. 1. El administrador le indica al sistema que quiere ver los usuarios registrados. 2. El sistema le muestra la lista de usuarios. Ninguno. Ninguno. El administrador le indica al sistema que quiere ver los usuarios registrados. Ninguna. Ninguna. Se han mostrado los usuarios del sistema.. Tabla 12. Caso de uso Ver Información Grupo Identificador Ver Información Grupo CU12 Nombre Caso de Uso: Necesario/Deseable Necesario Prioridad Alta Iteración: Ciclo 1 Resumen: El administrador le pide al sistema la información de un grupo. 1. El administrador le indica al sistema que quiere ver la Curso Básico de Eventos: información de un grupo. 2. El sistema le muestra al administrador la lista de grupos. 3. El administrador escoge el grupo. 4. El sistema le muestra los datos registrados (nombre e integrantes). Ninguno. Caminos de Excepción: CU13. Puntos de Extensión: Triggers: El administrador le indica al sistema que quiere ver la información de un grupo. Suposiciones: Ninguna Pre-condiciones: Ninguna. Post- Condiciones: Se ha mostrado la información de un grupo.. Tabla 13. Caso de uso Ver Grupos Sistema Identificador Ver Grupos del Sistema Nombre Caso de CU13 Uso:. 26.

(36) ISC-2003-1-30. Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico de Eventos: Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. Necesario Alta Ciclo 1 El administrador le pide al sistema la lista de grupos del sistema. 1. El administrador le indica al sistema que quiere ver los grupos registrados. 2. El sistema le muestra la lista de grupos. Ninguno. Ninguno. El administrador le indica al sistema que quiere ver los grupos registrados. Ninguna. Ninguna. Se han mostrado los grupos del sistema.. Tabla 14. Caso de uso Ver Información Proyecto Identificador Ver Información Proyecto Nombre Caso de CU14 Uso: Necesario/Deseable Necesario Prioridad Alta Iteración: Ciclo 1 Resumen: El administrador le pide al sistema la información de un proyecto. 1. El administrador le indica al sistema que quiere ver la Curso Básico de Eventos: información de un proyecto. 2. El sistema le pide al administrador que busque el proyecto. 3. El administrador escoge el proyecto. 4. El sistema le muestra la descripción y los integrantes del proyecto. Ninguno. Caminos de Excepción: Puntos de CU13. Extensión: Triggers: El administrador le indica al sistema que quiere ver la información de un proyecto. Suposiciones: Ninguna Pre-condiciones: Ninguna. Post- Condiciones: Se ha mostrado la información de un proyecto.. Tabla 15. Caso de uso Ver Proyectos Grupo Identificador Ver Proyectos Grupo. 27.

(37) ISC-2003-1-30. Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico de Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. CU15 Necesario Alta Ciclo 1 El administrador le pide al sistema la lista de proyectos de un grupo. 1. El administrador le indica al sistema que quiere ver los grupos registrados. 2. El sistema le muestra la lista de grupos. 3. El administrador escoge el grupo del cual quiere ver sus proyectos. 4. El sistema le muestra la lista de proyectos. Ninguno. CU13. El administrador le indica al sistema que quiere ver los proyectos de un grupo. Ninguna. Ninguna. Se han mostrado los proyectos de un grupo.. Tabla 16. Caso de uso Autenticar Usuario Identificador Autenticar Usuario Nombre Caso de CU16 Uso: Necesario/Deseable Necesario Prioridad Alta Iteración: Ciclo 1 Resumen: El usuario le solicita al sistema que lo autentique como un usuario del sistema. 1. El sistema le pide al usuario su login y su contraseña. Curso Básico de Eventos: 2. El usuario ingresa su login y su contraseña. 3. El sistema valida al usuario. En el punto 2 el usuario ingresa una contraseña inválida o un Caminos de Excepción: login que no existe en el sistema. El sistema indica que no pudo validar su identidad. Puntos de Ninguno. Extensión: Triggers: El usuario intenta ingresar al sistema. Suposiciones: Ninguna. Pre-condiciones: Ninguna. Post- Condiciones: El sistema ha autenticado al usuario.. Tabla 17. Caso de uso Autenticar Administrador. 28.

(38) ISC-2003-1-30. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico de Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. Autenticar Administrador CU17 Necesario Alta Ciclo 1 El administrador le solicita al sistema que lo autentique como un administrador del sistema. 1. El sistema le pide al administrador su login y su contraseña. 2. El administrador ingresa su login y su contraseña. 3. El sistema valida al administrador. En el punto 2 el administrador ingresa una contraseña inválida o un login que no existe en el sistema. El sistema indica que no pudo validar su identidad. Ninguno. El usuario intenta ingresar al sistema. Ninguna. Ninguna. El sistema ha autenticado al usuario.. Tabla 18. Caso de uso Cambiar Password Usuario Identificador Cambiar Password Usuario Nombre Caso de CU18 Uso: Necesario/Deseable Necesario Prioridad Alta Iteración: Ciclo 1 Resumen: El usuario le solicita al sistema que cambie su contraseña. 1. El sistema le pide al usuario su contraseña anterior y Curso Básico de Eventos: su nueva contraseña. 2. El usuario ingresa su contraseña anterior y su nueva contraseña. 3. El sistema verifica que la contraseña anterior coincida y la cambia por la nueva. En el punto 2 el usuario ingresa una contraseña anterior Caminos de Excepción: inválida. El sistema indica que no puede cambiar la contraseña. Ninguno. Puntos de Extensión: Triggers: El usuario le indica al sistema que quiere cambiar su contraseña. Suposiciones: Ninguna. Pre-condiciones: Ninguna. Post- Condiciones: El sistema ha cambiado la contraseña del usuario.. 29.

(39) ISC-2003-1-30. Tabla 19. Caso de uso Reset Password Usuario Identificador Reset Password Usuario CU19 Nombre Caso de Uso: Necesario/Deseable Necesario Prioridad Alta Iteración: Ciclo 1 Resumen: El administrador le solicita al sistema que devuelva la contraseña de un usuario a su estado original. 1. El administrador busca el usuario. Curso Básico de Eventos: 2. El sistema la muestra la información del usuario. 3. El administrador le indica al sistema que devuelva la contraseña del usuario a su estado original. 4. El sistema devuelve la contraseña del usuario a su estado original. Ninguno. Caminos de Excepción: Puntos de Ninguno. Extensión: Triggers: El administrador le solicita al sistema que devuelva la contraseña de un usuario a su estado original. Suposiciones: Ninguna. Pre-condiciones: Ninguna. Post- Condiciones: El sistema ha devuelto la contraseña del usuario seleccionado al valor asignado inicialmente por defecto.. 30.

(40) ISC-2003-1-30. 5. DISEÑO DEL MÓDULO DE ADMINISTRACIÓN Una vez recogidos los requerimientos en forma detallada, se debe diseñar este módulo de la aplicación. Puesto que se deben ofrecer servicios de autenticación que van a ser utilizados por dos usuarios diferentes, uno de ellos siendo otro módulo de la aplicación, es apropiado concebir este módulo como un web service. Tal como se puede ver en el diagrama de arquitectura, este módulo le presta servicios a un cliente web de administración y a otro web service que es el encargado de manejar el módulo de conversación. Tratándose de un web service resulta útil aplicar el patrón proxy para separar el contenido lógico de la aplicación de la interfaz expuesta hacia la web. De esta forma, si después es necesario utilizar el módulo de alguna otra forma (quizás exponiéndolo hacia la red con alguna otra tecnología o en una aplicación standalone) se puede hacer con muy pocos cambios en el código. En cuanto a la elección de un manejador de bases de datos, MySQL es el principal candidato. Si bien no maneja integridad referencial, se rendimiento es bastante bueno, se trata de un producto libre y tiene un controlador JDBC de nivel cuatro disponible. Además, la complejidad en las relaciones de los datos en el módulo no es muy alta, de tal manera que la ausencia del manejo de integridad referencial no constituye un problema. Además, debido al tamaño de los datos, la tarea del manejador se puede limitar a traer los datos a memoria principal al iniciar la aplicación y a guardar los cambios que afectaran la persistencia en el momento en que ocurran. No es necesario tener un manejo de la persistencia más elaborado. De todas formas sí es necesario permitir que se cambie el manejador de bases de datos si en algún momento se requiere hacerlo por algún motivo. Por lo tanto resulta útil aplicar el patrón factory para poder soportar otros manejadores diferentes sin necesidad de hacer grandes cambios en el código. En todo caso, el manejador que se va a utilizar inicialmente es MySQL. Teniendo en cuenta que los servicios de este módulo van a ser utilizados por dos usuarios diferentes, es importante crear dos interfaces, cada una con los servicios que van ser prestados a cada tipo de usuario. Esto da claridad con respecto a los servicios que están siendo utilizados por cada tipo de usuario y además permite exponer dos salidas diferentes del mismo web service hacia la red. El diagrama de clases se muestra a continuación: Figura 3. Diagrama de clases del módulo de administración.. 31.

(41) ISC-2003-1-30. 32.

(42) ISC-2003-1-30. Para facilitar la codificación de este módulo es útil crear diagramas de secuencia para algunos casos de uso que resulten claves. Estos diagramas deben utilizar la clase administrador como el punto de partida de las llamadas, debido a que las demás clases por encima de ésta solo cumplen la función de separar la interfaz del web service de las clases que contiene la lógica del módulo. Los diagramas se muestran a continuación. Figura 4. Diagrama de secuencia del caso de uso Crear Usuario. Figura 5. Diagrama de secuencia del caso de uso Eliminar Usuario.. Figura 6. Diagrama de secuencia del caso de uso Crear Grupo.. 33.

(43) ISC-2003-1-30. Figura 7. Diagrama de secuencia del caso de uso Eliminar Grupo.. Figura 8. Diagrama de secuencia del caso de uso Crear Proyecto.. 34.

(44) ISC-2003-1-30. Figura 9. Diagrama de secuencia del caso de uso Eliminar Proyecto.. Figura 10. Diagrama de secuencia del caso de uso Autenticar Usuario.. 35.

(45) ISC-2003-1-30. Figura 11. Diagrama de secuencia del caso de uso Cambiar Password Usuario.. Los demás casos de uso operan de forma similar a los expuestos anteriormente así que no se consideró necesario incluirlos en el diseño.. 36.

(46) ISC-2003-1-30. 6. ANÁLISIS DEL MÓDULO DE CONVERSACIÓN Una vez terminado el módulo de administración de usuarios se debe continuar con el análisis de los requerimientos del módulo de conversación. Este proceso es más complicado que el del módulo anterior ya que es fundamental delimitar bien el alcance de la herramienta teniendo en cuenta el tiempo que se tiene para desarrollarla. En este proceso, también teniendo como base la experiencia en los grupos de construcción de software, se deben identificar los usuarios relevantes para la herramienta, que en este caso son el líder del proyecto y el usuario común y corriente. El diagrama de casos que uso se muestra a continuación.. Figura 12. Diagrama de casos de uso del módulo de conversación.. 37.

(47) ISC-2003-1-30. Para comenzar a concebir este módulo es útil tomar como base un programa de mensajería instantánea típico (por ejemplo MSN Messenger o ICQ). A partir de esa idea, e incorporándole los aspectos más relevantes de un proceso de comunicación al interior de un grupo de construcción de software, se pueden detallarar los casos de uso. A continuación se muestran los casos de uso detallados. Tabla 20. Caso de uso Ingresar al Sistema Identificador Ingresar al Sistema Nombre Caso de CU1 Uso: Necesario/Deseable Necesario Prioridad Alta Iteración: Ciclo 1 Resumen: El usuario ingresa su nombre de usuario y su contraseña para que el sistema lo autentique. Curso Básico de 1. El sistema le muestra al usuario la pantalla de Eventos: bienvenida en donde le pide que ingrese su nombre de usuario y contraseña. 2. El usuario ingresa su nombre de usuario y contraseña. 3. El sistema autentica los datos y le muestra la información de los proyectos a los que pertenece. 4. El usuario escoge el proyecto al que desea entrar. 5. El sistema conecta al usuario a la conversación del proyecto escogido. Caminos de Excepción:. •. • •. Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. En el punto 1, el usuario ingresa un nombre de usuario que no existe en el sistema. El sistema le indicia que hay un error de autenticación y le vuelve a mostrar la pantalla de bienvenida. En el punto 1, el usuario ingresa una contraseña inválida. El sistema le indica que hay un error de autenticación y le vuelve a mostrar la pantalla de bienvenida. En el punto 4, el usuario decide cancelar y no entrar a ninguno de sus proyectos. El sistema lo desconecta.. Ninguno. El administrador le indica al sistema que quiere crear un nuevo usuario. Ninguna. Ninguna. El usuario ha ingresado al sistema.. Tabla 21. Caso de uso Salir del Sistema Identificador Salir del Sistema 38.

(48) ISC-2003-1-30. Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico de Eventos:. CU2. Caminos de Excepción:. •. Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones:. CU1. Necesario Alta Ciclo 1 El usuario decide salir del sistema. 1. El usuario le indica al sistema que desea salir. 2. El sistema la pide al usuario que confirme su decisión. 3. El usuario confirma que quiere salir del sistema. 4. El sistema remueve al usuario de la lista de usuarios conectados. En el punto 3, el usuario no confirma su decisión. El usuario continúa conectado.. El usuario decide salir del sistema. El usuario está conectado al sistema. Ninguna. El usuario ha salido del sistema.. Tabla 22. Caso de uso Cambiar de Proyecto Identificador Cambiar de Proyecto Nombre Caso de CU3 Uso: Necesario/Deseable Necesario Prioridad Alta Iteración: Ciclo 1 Resumen: El usuario decide cambiar de proyecto. 1. El usuario le indica al sistema que quiere cambiar de Curso Básico de Eventos: proyecto. 2. El sistema le muestra la lista de sus proyectos. 3. El usuario escoge el nuevo proyecto al que desea conectarse. 4. El sistema conecta al usuario a la conversación del proyecto escogido. Caminos de Excepción:. •. Puntos de Extensión: Triggers:. Ninguno.. En el punto 3, el usuario decide no escoger otro proyecto y cancela la acción. El usuario sigue conectado al mismo proyecto.. El usuario decide cambiar de proyecto. 39.