UNIVERSIDAD AUTNOMA DE GUERRERO UNIDAD ACADMICA DE INGENIERA

P.E. INGENIERO EN COMPUTACION

INGENIERIA DE SOFTWARE

SISTEMA GYMNASIO COLOSsOS

PROFESOR: ROBERTO ARANDA BENITO

ALUMNOS:

MOISES MOJICA REYES. JESSE AXEL GUZMAN REYES. JONATHAN FLORES AGUILAR.
JOXAN ZAMACONA MARTINEZ.

8vo. Semestre

T.V. Grupo B .

CHILPANCINGO, GRO. JUNIO DE 2013.

NDICE 1. Plan de Trabajo.. 1 2. Anlisis de requerimientos1 3. Introduccin2 3.1 Propsito del sistema2-3 3.2 Problemtica3 3.3 Objetivos3 3.4 Alcances3-4 4. Sistema actual4 5. Sistema propuesto.4 5.1. Los usuarios del sistema4 5.2 Requerimientos funcionales.4 5.3 Requerimientos no funcionales..5-6 6. Diagrama de Casos de Uso ...6-7 6.1 Descripcin de Casos de Uso ..8-12 6.2 Diagrama de Clases Entidad.........13 6.3 Diagrama de Clases Control....14 6.4 Diagrama de Clases Interfaz...15 6.5 Diagrama de Secuencia..16-19 6.6 Interfaces Graficas..20-23

1. Plan de trabajo Todo plan es un conjunto sistemtico de actividades que se lleva a cabo para concretar una accin. De esta manera, el plan tiende a satisfacer necesidades o resolver ciertos planes.

Un plan de trabajo es una herramienta que permite ordenar y sistematizar informacin relevante para realizar un trabajo. Esta especie de gua propone una forma de interrelacionar los recursos humanos, financieros, materiales y tecnolgicos disponibles. Como instrumento de planificacin, el plan de trabajo establece un cronograma, designa a los responsables y marca metas y objetivos. Las acciones que aparecen incluidas dentro del plan de trabajo pueden ser seguidas, controladas y evaluadas por el responsable; de esta manera, cuando la organizacin est lejos de cumplir con sus objetivos, es posible dictaminar un cambio en la conducta y rectificar las acciones. 2. Anlisis de Requerimientos El objetivo de este captulo es la descripcin por completo desde el punto de vista de los requerimientos funcionales y no funcionales, y sirve como una base contractual entre el cliente y los desarrolladores. Se documentan los resultados de la actividad de obtencin de requerimientos y la actividad de anlisis de dichos requerimientos. Se incluyen los casos de uso, los requerimientos funcionales y no funcionales y el modelo de objetos del dominio.

Pgina 1

3. Introduccin Un caso de uso es la descripcin de una secuencia de interacciones entre el sistema y uno o ms actores en la que se considera al sistema como una caja negra y en la que los actores obtienen resultados observables. Los actores son personas u otros sistemas que interactan con el sistema cuyos requisitos se estn describiendo. Los casos de uso presentan ciertas ventajas sobre la descripcin meramente textual de los requisitos funcionales, ya que facilitan la licitacin de requisitos y son fcilmente comprensibles por los clientes y usuarios. Adems, pueden servir de base a las pruebas del sistema y a la documentacin para los usuarios. Los casos de uso tienen una representacin grfica en los denominados diagramas de casos de uso [Boo99]. En estos diagramas, los actores se representan en forma de pequeos monigotes y los casos de uso se representan por elipses contenidas dentro de un rectngulo que representa al sistema. La participacin de los actores en los casos de uso se indica por una flecha entre el actor y el caso de uso que apunta en la direccin en la que fluye la informacin. Cada caso de uso puede estar definido por: texto que lo describe, secuencia de pasos ejecutados dentro del caso de uso, condiciones pre-post para que el caso de uso comience o termine Los diagramas de casos de uso sirven para proporcionar una visin global del conjunto de casos de uso de un sistema as como de los actores y los casos de uso en los que estos intervienen. Las interacciones concretas entre los actores y el sistema no se muestran en este tipo de diagramas. A pesar de ser una tcnica ampliamente aceptada, existen mltiples propuestas para su utilizacin concreta. En nuestro caso vamos a utilizar la herramienta Racional Rose 98, para la construccin de los diagramas de casos de uso. Para la descripcin concreta de los casos de uso se proponen unas plantillas, en las que las interacciones se numeran y se describen usando el lenguaje natural, en forma de patrones lingsticos. El objetivo de estas plantillas es el de intentar paliar la falta de propuestas concretas sobre la expresin de requisitos.

3.1 Propsito del sistema En este trabajo se ofrece un ejemplo de la tcnica de los casos de uso, aplicndolo al GYMNASIO COLOSSOS. En la introduccin inicial se explica brevemente en que consiste esta tcnica y sus caractersticas ms importantes. A continuacin se han desarrollado los diferentes

Pgina 2

casos de uso del negocio de GYMNASIO junto a las plantillas para su especificacin. Dado que se trata de un anlisis real pero no para ponerlo a prueba. El ejemplo no es una especificacin de requisitos completa, se incluye solo a modo de ejemplo como se especific anteriormente. 3.2 Problemtica Los actuales procesos del GYMNASIO no funcionan con gran rapidez ya que no cuentan con un software que lleve a cabo la administracin del negocio, el manejo de clientes, proveedores, profesionales, consultas y un sistema de caja. Lo que se busca es que los procesos y el manejo de informacin sea oportuna y su uso confidencial con base a un marco legal y que tenga rapidez. 3.3 Objetivos En este apartado vamos a definir una lista con los diferentes objetivos que se esperan alcanzar con el sistema software a desarrollar. El encargado del GYM mediante el sistema se encargara de llevar el control de los clientes, proveedores y profesionales. El encargado tambin deber realizar por medio del sistema el registro de los clientes, proveedores y profesionales, en dicho registro se ingresaran datos tales como nombre completo, edad, peso, direccin y telfono. El encargado tambin deber realizar por medio del sistema la actualizacin de datos ya sea para un cliente, proveedor o profesional. El encargado tambin deber realizar por medio del sistema la eliminacin de los registros que no estn actualizados. El encargado tambin deber realizar por medio del sistema las consultas requeridas por el cliente, proveedor o profesional. El encargado tambin deber realizar por medio del sistema el cobro de mensualidades de cada cliente, as como tambin realizar los pagos correspondientes a profesionales y proveedores.

3.4 Alcances El alcance del sistema de GYMNASIO COLOSSOS son los siguientes: Al sistema solo tendr acceso el encargado del GYM y no podr ser interactuado por el cliente, proveedor ni profesional.

Pgina 3

El cliente solo proporcionara sus datos verbalmente o mediante una identificacin oficial. El sistema solo podr ser ejecutado en el equipo avalado por el encargado del GYM. El sistema no funcionara en ningn tipo de red compartida. Los clientes, profesionales y proveedores que se ausenten en lapso de un mes ser dado de baja en el sistema.

4. Sistema actual Esta versin del sistema se encuentra en desarroll por el personal de la Unidad Acadmica de Ingeniera de la carrera de Computacin. Despus de realizarse un exhaustivo estudio se determin que es preferible realizar un sistema para el GYMNASIO COLOSSOS que facilite al administrador llevar un control y no tener prdidas de tiempo y dinero. 5. Sistema propuesto 5.1. Los usuarios del sistema
Representante Encargado Funcin Este actor es el encargado de llevar acabo los registros de los clientes, proveedores, profesionales y del sistema de cobro de mensualidades.

5.2 Requerimientos funcionales El objetivo de esta seccin es dar a conocer la lista de requerimientos funcionales del sistema de software para la administracin del GYMNASIO COLOSSOS. La lista de requerimientos es el resultado de una serie de entrevistas directas a los involucrados (clientes y administrador). Los requerimientos se obtienen y se definen desde el punto de vista del usuario, lo que documenta el comportamiento que tendr el sistema de software dentro de los casos de uso. Los requerimientos funcionales son las capacidades que el sistema de software debe cumplir. A continuacin se listan en la tabla cada uno de los requerimientos funcionales del proyecto.
Identificador de requerimiento SGRO_RF 1 SGRO_RF 2 GRO_RF 3 Descripcin El sistema deber almacenar la informacin correspondiente a los datos personales de los clientes, proveedores y profesionales para poder efectuar el registro. El sistema deber almacenar la informacin correspondiente a las mensualidades pagadas y que adeudan cada uno de los clientes. El sistema deber almacenar la informacin correspondiente a los pedidos a los proveedores.

Pgina 4

5.3 Requerimientos no funcionales Los requerimientos no funcionales son aquellos requerimientos que especifican propiedades especiales que el sistema de software debe presentar, como restricciones en el entorno o de la implementacin, rendimiento, dependencia de la plataforma, facilidad de mantenimiento, extensibilidad y fiabilidad.
Identificacin de Requerimiento Requerimientos del Producto SGRO_RNF 1 Usabilidad SGRO_RNF 2 Eficiencia (Rendimiento) SGRO_RNF 3 SGRO_RNF 4 Clasificacin Descripcin

El sistema deber tener una interfaz grfica complementada con un sistema de ayuda. El sistema no deber permitir el cierre de una operacin hasta que todos sus procesos, subprocesos y tareas relacionados, hayan sido terminados y guardados satisfactoriamente. La informacin almacenada deber ser consultada y actualizada simultneamente, sin que se afecte el tiempo de respuesta. El sistema deber tener la capacidad de responder en un tiempo aceptable las solicitudes hechas por parte del encargado o de los procesos alternos en el acceso a los contenidos y en la ejecucin de las aplicaciones sin importar la plataforma sobre la que se hacen las solicitudes, en perodos de alta, media y baja demanda de uso del sistema. El sistema deber estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades despus de su construccin y puesta en marcha inicial. El sistema deber proporcionar un tiempo de servicio garantizado para el administrador de 7 das las 24 horas. En caso de una posible falla: Contar con un plan de contingencia Generar alarmas ventanas de notificacin de error al encargado del sistema. El sistema deber contar con un sistema de respaldo, para resguardar la informacin en caso de alguna falla tcnica o de software y as evitar la prdida de la misma. El sistema deber estar en capacidad de permitir en el futuro su fcil mantenimiento con respecto a los posibles errores que se puedan presentar durante la operacin del sistema. El sistema deber garantizar que su despliegue se pueda realizar sobre plataforma hardware de 64 bits/ 32 bits sin que esto afecte el rendimiento del mismo

SGRO_RNF 5

SGRO_RNF 6 Fiabilidad

SGRO_RNF 7 SGRO_RNF 8

Portabilidad

SGRO_RNF 9

Pgina 5

Entrega

SGRO_RNF 10 SGRO_RNF 11

El proceso de desarrollo del sistema y los documentos a entregar debern ajustarse al proceso RUP (Rational Unificed Process). El sistema deber utilizar para su desarrollo, tecnologa Java en sus versiones estables.

Implementacin Requerimientos Organizacionales Implementacin SGRO_RNF 12 SGRO_RNF 13 Deber ser capaz de apegarse a los requerimientos de software y hardware establecidos por el GYMNASIO COLOSSOS en el cual se va a desarrollar el sistema. El manejador de base de datos deber ser MySQL en su versin estable.

Implementacin

SGRO_RNF 14 SGRO_RNF 15

Estndares

SGRO_RNF 16

El sistema deber ser en idioma espaol en su totalidad. El sistema deber implementarse con la utilizacin de software con licencias gratuitas. Deber contar con garantas de calidad, mantenimiento y capacitacin, adems notas de derechos de autor, notas de la patente, marca registrada, contrato legal. El sistema deber de contar con un mtodo de encriptacin de datos para la confidencialidad de los mismos.

Requerimientos Externos Legislativos (Privacidad) SGRO_RNF 17

6. Diagrama de Casos de Uso En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento UML mejorado. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms detallados que los diagramas de casos de uso. Un caso de uso es una descripcin de los pasos o las actividades que debern realizarse para llevar a cabo algn proceso. Los personajes o entidades que participarn en un caso de uso se denominan actores. En el contexto de ingeniera del software, un caso de uso es una secuencia de interacciones que se desarrollarn entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicacin y el comportamiento de un sistema mediante su interaccin con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relacin entre los actores y los casos de uso en un sistema.

Pgina 6

Una relacin es una conexin entre los elementos del modelo, por ejemplo la especializacin y la generalizacin son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cmo reacciona a eventos que se producen en su mbito o en l mismo.

Pgina 7

6.1 Descripcin de Casos de Uso

CASO DE USO: Registro del cliente al GYM (Registro del pago) OBJETIVO: Realiza el registro de los clientes para anxalos al sistema o se le da autorizacin al pagar la visita correspondiente. ACTORES: Encargado (C). PRECONDICIONES: PASOS: 1. 2. 3. 4. 5. C: El caso inicia cuando el cliente llega a solicitar el servicio del GYM. C: Se le brinda informacin sobre si ser pago mensual o pago de visita. C: Se le solicita una identificacin IFE. C: Se Introduce los datos del interesado al sistema. S: Se valida los datos del interesado y se imprime una credencial con la fecha de inicio y finalizacin del mes pagado. 6. C: Se confirma el pago cuando el cliente le facilita el dinero. 7. C: Se Imprime la credencial y se le entrega al cliente 8. S: Finaliza el sistema

CASO DE USO: Registro de los proveedores OBJETIVO: Realizar proveedor. Alta de proveedor, Baja de proveedor, Modificacin

ACTORES: Encargado (C). PRECONDICIONES: PASOS: 1. C: El caso de uso comienza cuando llega un proveedor a promover sus productos. 2. C: El encargado del puesto le pregunta si es nuevo proveedor, si la respuesta es si entonces le pide una identificacin para darlo de alta y a su vez dar de baja a algn proveedor obsoleto. 3. C: El Encargado recibe un ticket que le entrega el Proveedor como comprobante del pago hecho por los productos comprados. 4. C: El encargado finaliza el proceso. 5. C: Al finalizar cierra el sistema.

Pgina 8

CASO DE USO: Registro de profesionales OBJETIVO: Realizar el registro de los nuevos profesionales que se incorporan al GYM ACTORES: Encargado (C). PRECONDICIONES:

PASOS: 1. C: El caso de uso inicia cuando el profesional se va a dar de alta como nuevo o cuando dejara de brindar sus servicios al GYM. 2. C: El profesional proporciona sus datos al encargado y su especialidad. 3. S: El sistema valida los datos del profesional y si son correctos accede. 4. S: El sistema genera un credencial al cual le aade un ID y la imprime. 5. C: Al finalizar cierra el sistema.

CASO DE USO: Elimina clientes y profesionales. OBJETIVO: El sistema debe ser capaz de eliminar la informacin que se desea borrar de los profesionales y de los clientes. ACTORES: Encargado (C). PRECONDICIONES: PASOS: 1. C: El caso de uso inicia cuando el dueo le pide al encargado que elimine alguno de los datos de un profesional o un cliente. 2. C: El encargado introduce el nombre de usuario, si es correcto accede al sistema. 3. S: El sistema genera un informe donde se indica si es un profesional o un cliente, ya adentro de los datos generados en el informe el encargado procede a eliminar los datos que le fueron pedidos. 4. C: El caso Finaliza Verificando si fueron correctos los datos eliminados.

Pgina 9

CASO DE USO: Actualiza clientes y profesionales. OBJETIVO: El sistema debe ser capaz de actualizar la informacin que se fue modificada de los profesionales y de los clientes. ACTORES: Encargado (C). PRECONDICIONES: PASOS: 1. C: El caso de uso inicia cuando el encargado elimino o modifico alguno de los datos de un profesional o un cliente. 2. C: El encargado introduce el nombre de usuario, si es correcto accede al sistema. 3. S: El sistema genera un informe donde se indica si es un profesional o un cliente, ya adentro de los datos generados en el informe el encargado procede actualizar los datos que anteriormente fueron eliminados o modificados. 4. C: El Sistema muestra los nuevos datos despus de ver sido actualizados. 5. C: Al finalizar de actualizar y ver los nuevos resultados cierra el sistema.

CASO DE USO: Consulta clientes, proveedores y profesionales OBJETIVO: El sistema debe ser capaz de proporcionar la informacin que se desea consultar de los profesionales, clientes y proveedores. ACTORES: Encargado (C). PRECONDICIONES: PASOS: 1. C: El caso de uso inicia cuando llega el profesional, cliente, proveedores. 2. C: El encargado introduce el nombre de usuario, si es correcto accede al sistema. 3. S: El sistema genera un informe donde se indica si es un profesional, cliente o proveedores, en el caso de los clientes genera cuando vence su mensualidad y si adeuda algn mes, de los profesionales genera los pagos proporcionados por el GYM. 4. C: Imprime el reporte y cierra el sistema.

Pgina 10

CASO DE USO: Validar entrada del Usuarios al GYM OBJETIVO: Llevar un control de los das que asiste el usuario al GYM sin que no haya algn da que no se pague. ACTORES: Encargado (C). PRECONDICIONES: PASOS: 1. C: El caso inicia cuando el usuario llega al GYM. 2. C: El Encargado pide la credencial al usuario y checa el nmero de credencial. 3. C: El encargado registra la entrada del usuario. 4. C: El caso termina cuando el encargado entrega su credencial al usuario se cierra el sistema.

CASO DE USO: Tomar asistencia de Profesional al GYM OBJETIVO: Llevar un control de la hora en que llega el profesional y los das que asiste al GYM sin que no haya algn da que falte en lo que marca su registro de contrato. ACTORES: Encargado (C). PRECONDICIONES: PASOS: 1. 2. 3. 4. C: El caso inicia cuando el Profesional llega al GYM. C: El Encargado verifica la hora de entrada del profesional. C: El encargado registra la hora de la llegada del profesional. C: Se cierra el sistema.

Pgina 11

CASO DE USO: Cobrar OBJETIVO: Se encarga de realizar el cobro mensual de cada uno de los clientes del GYM ACTORES: Encargado (C). PRECONDICIONES:

PASOS: 1. C: El caso de uso inicia cuando el cliente va a la caja con el dinero para pagar su mensualidad o el Profesional va a cobrar su mensualidad. 2. C: el encargado de la caja introduce el nombre del cliente o Profesional. 3. S: El sistema muestra el total a pagar, as como el nmero de meses que adeuda y el ticket que se va a imprimir, si es un Profesional genera un ticket con su sueldo. 4. C: El encargado recibe el dinero y confirma el pago, imprime el ticket y lo entrega al cliente o empleado como comprobante. 5. C: El encargado finaliza el proceso. 6. C: Al finalizar cierra el sistema.

Pgina 12

6.2 Diagrama de Clases Entidad Uno de los diagramas ms importantes dentro del lenguaje UML. Se utiliza para modelar informacin que posee una vida larga y que es a menudo persistente. Define la estructura del Sistema y Dirige al anlisis y diseo. Captura la estructura esttica de las relaciones del Sistema.

Pgina 13

6.3 Diagrama de Clases Control Representan coordinacin, secuencia, transacciones y control de los objetos y se usan para encapsular el control de un caso de uso en concreto.

2.7 Diagrama de Clases Interfaz Se utiliza para modelar la interaccin entre el sistema y sus actores. Representan ventanas, formularios, paneles, interfaces de comunicacin, etc.

Pgina 14

6.4 Diagrama de Clases Interfaz Se utiliza para modelar la interaccin entre el sistema y sus actores. Representan ventanas formularios, paneles, interfaces de comunicacin etc.

Pgina 15

6.5 Diagrama de Secuencia Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales. En general, es la descripcin de cada caso de uso como una secuencia de varios pasos.

Diagrama de Secuencia.- Registrar.

Pgina 16

Diagrama de Secuencia.- Eliminar

Diagrama de Secuencia.- Actualizar

Pgina 17

Diagrama de Secuencia.- Consultar

Diagrama de Secuencia.- Cobrar

Pgina 18

Diagrama de Secuencia.- Tomar Asistencia Profesional

Diagrama de Secuencia.- Validar Entrada Usuario

Pgina 19

Interfaces Grficas Interfaz de Acceso al Sistema

Interfaz del Men Principal

Pgina 20

Interfaz Cliente

Interfaz Profesionales

Pgina 21

Interfaz Proveedores

Interfaz Registro de Entrada

Pgina 22

Interfaz de Registro de Asistencia

Interfaz Registro de Cobros

Pgina 23