Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Autores:
Mellano, Santiago
Molina, Cecilia
Pratelli, Germán
Directora y Co-Director:
Magister Daniele, Marcela – Magister Zorzán, Fabio
DEPARTAMENTO DE COMPUTACIÓN
Agradecimientos
Queremos dar gracias en primer lugar a nuestra directora y co-director del presente trabajo
final, por el constante apoyo que nos han ofrecido en todo momento, sin el cual quizás no
hubiésemos logrado finalizarlo.
Por último, no podemos dejar de agradecer a nuestra Institución Universitaria, que nos
posibilito acceder a una carrera en forma gratuita y de enorme calidad, lo cual nos permitió incluso
antes de recibirnos, poder insertarnos laboralmente en la sociedad.
1. INTRODUCCION ................................................................................................................... 1
1.1. Motivación .............................................................................................................................. 1
1.2. Objetivo Principal ................................................................................................................... 1
1.3. Organización de este trabajo ................................................................................................. 2
2. DESCRIPCION DEL NEGOCIO ............................................................................................ 3
3. METODOLOGIA UTILIZADA: Proceso Unificado de Desarrollo de Software ................ 5
4. CAPTURA DE REQUERIMIENTOS ...................................................................................... 6
4.1. Modelo de Negocio ................................................................................................................ 6
4.1.1 Modelo de Dominio ................................................................................................................ 6
4.1.2 Reglas de Negocio ................................................................................................................. 6
4.1.3 Glosario de términos del Negocio ........................................................................................ 10
4.1.4 Modelo de Casos de Uso de negocio .................................................................................. 11
4.1.4.1 Casos de uso de negocio .................................................................................................... 11
4.1.4.2 Actores del negocio .............................................................................................................. 12
4.2. Modelo de Casos de Uso de Negocio ................................................................................. 16
4.2.1 Actores ................................................................................................................................. 16
4.2.2 Casos de Uso ....................................................................................................................... 16
4.2.2.1 Diagrama de Casos de Uso del Sistema ............................................................................. 19
4.2.2.2 Clasificación de Casos de Uso en iteraciones ..................................................................... 23
4.2.2.3 Casos de uso Genéricos ...................................................................................................... 24
5. PRIMERA ITERACION ........................................................................................................ 26
5.1. Descripción de casos de usos del Sistema ......................................................................... 26
5.1.1 Descripción de casos de uso ............................................................................................... 26
5.1.2 Descripción de Casos de Uso utilizando plantillas Genéricas ............................................. 27
5.2. Análisis ................................................................................................................................. 31
5.2.1 Caso de Uso: Alta Convocatoria .......................................................................................... 31
5.2.1.1 Diagrama de Clases de Análisis del caso de uso Alta Convocatoria .................................. 32
5.2.1.2 Diagrama de Comunicación del caso de uso Alta Convocatoria ......................................... 32
5.2.2 Caso de Uso: Modificar Convocatoria ................................................................................. 32
5.2.2.1 Diagrama de Clases de Análisis del caso de uso Modificar Convocatoria .......................... 33
5.2.2.2 Diagramas de Comunicación del caso de uso Modificar Convocatoria .............................. 33
5.2.3 Análisis de Casos de Uso utilizando Plantillas Genéricas de Análisis ................................ 36
5.3. Diseño e Implementación..................................................................................................... 37
5.3.1 Descripción de la Arquitectura ............................................................................................. 38
5.3.1.1 Arquitectura Cliente/Servidor ............................................................................................... 38
5.3.2 Persistencia de objetos ........................................................................................................ 39
5.3.2.1 Consideraciones especiales ................................................................................................ 40
5.3.3 Patrones de Diseño.............................................................................................................. 40
5.3.3.1 Singleton .............................................................................................................................. 40
5.3.3.2 Mediador .............................................................................................................................. 40
5.3.3.3 DTO (Data Transfer Object) ................................................................................................. 42
5.3.4 Extensión y/o adición de nuevos casos de uso ................................................................... 43
5.3.4.1 Caso de uso Buscar Genérico ............................................................................................. 43
5.3.5 Tecnologías utilizadas.......................................................................................................... 44
5.3.6 Requerimientos de software y hardware del sistema .......................................................... 45
5.3.7 Diagrama de Componentes ................................................................................................. 45
5.3.8 Realización del Caso de Uso Gestión Convocatoria ........................................................... 47
5.3.8.1 Trazabilidad de clases de análisis a clases de diseño ........................................................ 47
5.3.8.2 Modelo de Diseño del caso de uso Gestión Convocatoria .................................................. 47
5.3.8.3 Diagramas de Secuencia para Gestión Convocatoria ......................................................... 47
5.3.9 Realización de Casos de Uso utilizando Plantillas de Diseño ............................................. 52
5.3.10 Diagrama de Clases Persistentes de la primera iteración ................................................... 53
6. SEGUNDA ITERACION ...................................................................................................... 54
6.1. Descripción de casos de usos del Sistema ......................................................................... 54
6.1.1 Descripción de casos de uso ............................................................................................... 54
6.1.2 Descripción de Casos de Uso utilizando plantillas Genéricas ............................................. 58
6.2. Análisis ................................................................................................................................. 62
6.2.1 Caso de Uso: Alta Proyecto ................................................................................................. 62
6.2.1.1 Diagrama de Clases de Análisis del caso de uso Alta Proyecto ......................................... 62
6.2.1.2 Diagramas de Comunicación del caso de uso Alta Proyecto .............................................. 63
6.2.2 Caso de Uso: Modificación Proyecto ................................................................................... 64
6.2.2.1 Diagrama de Clases de Análisis del caso de uso Modificar Proyecto ................................. 64
6.2.2.2 Diagramas de Comunicación del caso de uso Modificar Proyecto ..................................... 65
6.2.3 Caso de Uso: Alta Programa ............................................................................................... 66
6.2.3.1 Diagrama de Clases de Análisis del caso de uso Alta Programa ....................................... 66
6.2.3.2 Diagramas de Comunicación del caso de uso Alta Programa ............................................ 67
6.2.4 Caso de Uso: Modificación Programa ................................................................................. 68
6.2.4.1 Diagrama de Clases de Análisis del caso de uso Modificar Programa ............................... 68
6.2.4.2 Diagramas de Comunicación del caso de uso Modificar Programa .................................... 69
6.2.5 Caso de Uso: Datos Proyecto-Programa............................................................................. 70
6.2.5.1 Diagrama de Clases de Análisis del caso de uso Datos ProyectoPrograma ...................... 70
6.2.5.2 Diagramas de Comunicación del caso de uso Datos ProyectoPrograma ........................... 71
6.2.6 Caso de Uso: Alta Presupuesto ........................................................................................... 72
6.2.6.1 Diagrama de Clases de Análisis del caso de uso Alta Presupuesto ................................... 72
6.2.6.2 Diagrama de Comunicación del caso de uso Alta Presupuesto .......................................... 73
6.2.7 Caso de Uso: Modificación Presupuesto ............................................................................. 74
6.2.7.1 Diagrama de Clases de Análisis del caso de uso Modificar Presupuesto ........................... 74
6.2.7.2 Diagrama de Comunicación del caso de uso Modificar Presupuesto ................................. 75
6.2.8 Análisis de Casos de Uso utilizando Plantillas Genéricas de Análisis ................................ 76
6.3. Diseño e Implementación..................................................................................................... 77
6.3.1 Realización del Caso de Uso Gestión Proyecto .................................................................. 77
6.3.1.1 Trazabilidad de clases de análisis a clases de diseño ........................................................ 77
6.3.1.2 Modelo de Diseño del caso de uso Gestión Proyecto ......................................................... 78
6.3.1.3 Diagramas de Secuencia para Gestión Proyecto ................................................................ 80
6.3.2 Realización del Caso de Uso Gestión Presupuesto ............................................................ 82
6.3.2.1 Trazabilidad de clases de análisis a clases de diseño ........................................................ 82
6.3.2.2 Modelo de Diseño del caso de uso Gestión Presupuesto ................................................... 82
6.3.2.3 Diagramas de Secuencia para Gestión Presupuesto .......................................................... 84
6.3.3 Realización de Casos de Uso utilizando Plantillas de Diseño ............................................. 85
6.3.4 Diagrama de Clases Persistentes de la segunda iteración ................................................. 86
7. TERCERA ITERACION ....................................................................................................... 87
7.1. Descripción de casos de usos del Sistema ......................................................................... 87
7.1.1 Descripción de casos de uso ............................................................................................... 87
7.1.2 Descripción de Casos de Uso utilizando plantillas Genéricas ............................................. 89
7.2. Análisis ................................................................................................................................. 92
7.2.1 Caso de Uso: Solicitud y Devolución de Adelantos ............................................................. 92
7.2.1.1 Diagrama de Clases de Análisis del caso de uso Solicitud y Devolución de Adelantos ..... 92
7.2.1.2 Diagrama de Comunicación del caso de uso Solicitud y Devolución de Adelantos ............ 93
7.2.2 Caso de Uso: Alta viático ..................................................................................................... 94
7.2.2.1 Diagrama de Clases de Análisis del caso de uso Alta Viático............................................. 94
7.2.2.2 Diagrama de Comunicación del caso de uso Alta Viático ................................................... 95
7.2.3 Caso de Uso: Alta Beca ....................................................................................................... 96
7.2.3.1 Diagrama de Clases de Análisis del caso de uso Alta Beca ............................................... 96
7.2.3.2 Diagramas de Comunicación del caso de uso Alta Beca .................................................... 96
7.2.4 Caso de Uso: Alta Factura ................................................................................................... 98
7.2.4.1 Diagrama de Clases de Análisis del caso de uso Alta Factura ........................................... 98
7.2.4.2 Diagramas de Comunicación del caso de uso Alta Factura ................................................ 99
7.2.5 Análisis de Casos de Uso utilizando Plantillas Genéricas de Análisis .............................. 100
7.3. Diseño e Implementación................................................................................................... 101
7.3.1 Realización del Caso de Uso Solicitud y Devolución de Adelanto .................................... 101
7.3.1.1 Trazabilidad de clases de análisis a clases de diseño ...................................................... 101
7.3.1.2 Modelo de Diseño del caso de uso Solicitud y Devolución de Adelanto ........................... 102
7.3.1.3 Diagramas de Secuencia para Solicitud y Devolución de Adelanto .................................. 103
7.3.2 Realización del Caso de Uso Gestión Viático ................................................................... 104
7.3.2.1 Trazabilidad de clases análisis a clases de diseño ........................................................... 104
7.3.2.2 Modelo de Diseño del caso de uso Gestión Viático .......................................................... 105
7.3.2.3 Diagramas de Secuencia para Gestión Viático ................................................................. 106
7.3.3 Realización del Caso de Uso Gestión Beca ...................................................................... 107
7.3.3.1 Trazabilidad de clases de análisis a clases de diseño ...................................................... 107
7.3.3.2 Modelo de Diseño del caso de uso Gestión Beca ............................................................. 108
7.3.3.3 Diagramas de Secuencia para Gestión Beca .................................................................... 109
7.3.4 Realización del Caso de Uso Gestión Factura .................................................................. 110
7.3.4.1 Trazabilidad de clases de análisis a clases de diseño ...................................................... 110
7.3.4.2 Modelo de Diseño del caso de uso Gestión Factura ......................................................... 111
7.3.4.3 Diagramas de Secuencia para Gestión Factura ................................................................ 112
7.3.5 Realización de Casos de Uso utilizando Plantillas de Diseño ........................................... 114
7.3.6 Diagrama de Clases Persistentes Tercera Iteración ......................................................... 115
8. PRUEBA ............................................................................................................................ 116
8.1. Pruebas de Caja Negra...................................................................................................... 116
8.1.1 Tabla de decisión ............................................................................................................... 116
8.2. Pruebas de Caja Blanca .................................................................................................... 118
8.2.1 Cobertura de Arco .............................................................................................................. 118
8.2.1.1 Actualizar el saldo disponible en un subrubro ................................................................... 118
8.2.1.2 Retornar el tope definido en un subrubro .......................................................................... 120
8.3. Resultados de las pruebas ................................................................................................ 120
9. CONCLUSIONES .............................................................................................................. 122
9.1. Trabajos Futuros ................................................................................................................ 122
10. BIBLIOGRAFIA ................................................................................................................. 123
11. ANEXOS ............................................................................................................................ 125
11.1. PLANTILLAS GENERICAS PARA LA DESCRIPCION DE CASOS DE USO .................. 125
11.1.1 Descripción del caso de uso: INSERCION DE ELEMENTO ............................................. 125
11.1.2 Descripción del caso de uso: MODIFICACION DE ELEMENTO ...................................... 126
11.1.3 Descripción del caso de uso: ELMINACION DE ELEMENTO........................................... 127
11.1.4 Descripción del caso de uso: BUSQUEDA DE ELEMENTO ............................................. 128
11.2. PLANTILLA GENERICA PARA EL ANALISIS DE CASOS DE USO ................................ 129
11.2.1 Diagrama Genérico de Clases de Análisis ........................................................................ 129
11.2.2 Diagrama Genérico de Colaboración: Insertar Elemento .................................................. 130
11.2.3 Diagrama Genérico de Colaboración: Modificar Elemento................................................ 130
11.2.4 Diagrama Genérico de Colaboración: Eliminar Elemento ................................................. 131
11.2.5 Diagrama Genérico de Colaboración: Buscar Elemento ................................................... 131
11.3. PLANTILLAS DE DISEÑO DE CASOS DE USO .............................................................. 132
11.3.1 Realización de C.U. de Análisis a Clases de Diseño ........................................................ 132
11.3.2 Modelo de Diseño para el diseño de Casos de uso ......................................................... 133
11.3.3 Diagramas de Secuencia ................................................................................................... 134
Introducción
1. INTRODUCCION
Unos de los objetivos prioritarios de la Universidad Nacional de Río Cuarto es el desarrollo de
nuevos conocimientos que como Universidad Nacional tiene el compromiso social de aportar al
desarrollo integral de la sociedad en general.
Debido a las nuevas y cambiantes situaciones resultantes del acelerado avance del
conocimiento científico, de los desarrollos tecnológicos que de él se derivan, la Universidad estableció
lineamientos generales para la política de Ciencia y Tecnología, entre los que se encuentra la
definición de áreas y temas de interés institucional para la promoción de actividades de investigación
y desarrollo.
1.1. Motivación
Las herramientas que se utilizan actualmente para administrar dichos proyectos son variadas
y muy diferentes entre sí, encontrándose desde programas de software específicos, que llevan
información en forma aislada de algunos grupos de proyectos, hasta planillas de cálculos para otros
grupos, lo cual es sabido que carecen de validación de datos y no permite cotejar, analizar ni realizar
cruce de datos entre proyectos de distintas convocatorias o programas. Es por este motivo, que
consideramos necesario desarrollar un sistema de software que contemple el manejo de esta
información de manera eficiente.
Página 1
Introducción
almacenamiento histórico, detallado, y seguro de datos que hacen a las ejecuciones de proyectos de
investigación.
Sección 1
Introducción donde se explica la motivación y objetivo principal del presente trabajo.
Sección 2
Describe en detalle cómo funciona el negocio, lo cual permite tener una visión global de la
problemática a abordar para el desarrollo del sistema.
Sección 3
Presenta una breve descripción del Proceso Unificado de Desarrollo de Software, que es la
metodología utilizada para el desarrollo de este sistema.
Sección 4
Desarrolla la captura de requerimientos, la cual describe qué hará el sistema y permite a los
desarrolladores y clientes tener un entendimiento común y un acuerdo con la descripción de las
funcionalidades del sistema.
Sección 5
En esta sección, al igual que en la sección 6 y 7, se realiza la descripción, análisis, diseño e
implementación de los casos uso del sistema. En esta sección se aborda la primera iteración, la cual
contempla los siguientes casos de uso: Gestión Categoría, Gestión Modalidad, Gestión Tipo
Proyecto, Gestión Ente Financiero, Gestión Área y Temas Prioritarios, Gestión Rubro, Gestión
Subrubro, Gestión Banco, Gestión Sucursal Banco, Gestión Cuenta Banco, Gestión Convocatoria.
Sección 6
En esta sección, se realiza la descripción, análisis y diseño de los casos uso del sistema de la
segunda iteración, la cual contempla los siguientes casos de uso: Gestión Disciplina, Gestión Campo
de Aplicación, Gestión Facultad, Gestión Departamento, Gestión Persona, Gestión Cargo, Gestión
Tipo de Cargo, Gestión Tipo de Función, Gestión Presupuesto, Gestión Proyecto, Gestión Programa
Sección 7
Realiza la descripción, análisis, diseño e implementación de los casos uso del sistema de la tercera
iteración, la cual contempla los siguientes casos de uso: Solicitud y Devolución de Adelantos, Gestión
Movimiento de Cuenta, Gestión Viatico, Gestión Beca, Gestión Factura, Gestión Proveedor.
Sección 8
En esta sección se muestran algunos casos y procedimientos de prueba, los cuales permitirán
verificar si el software desarrollado cumple con los requerimientos solicitados en forma satisfactoria
Sección 9
Conclusiones obtenidas, una vez finalizado el trabajo de tesis. También se explicita los trabajos
futuros posibles, para mejorar aún más, y complementar el manejo de la información de la Secretaría
de Ciencia y Técnica.
Sección 10
Bibliografía utilizada para el desarrollo de este trabajo final.
Sección 11
En esta sección se encuentran los anexos que contienen información que ha sido utilizada y
referenciada a lo largo de este trabajo. Dichos anexos, son los siguientes:
Plantillas genéricas para la descripción de casos de uso, Plantillas genéricas de análisis de casos de
uso y Plantillas específicas de Diseño de casos de uso (estás últimas realizadas por los autores de la
presente tesis).
Página 2
Descripción del Negocio
Las bases de las convocatorias definen la forma en que serán financiadas las propuestas
admisibles, esto es, con presupuesto propio, presupuestos de organismos externos y también
cofinanciados, entre la Universidad y algún organismo externo.
Página 3
Descripción del Negocio
Dentro de una convocatoria se fija un monto máximo de crédito, de acuerdo a las diferentes
categorías y modalidades.
Todas las erogaciones, pagos, adelantos, etc., se realizan por medio de una cuenta bancaria
habilitada a tal efecto, ya que no se admite la utilización de efectivo.
Los proyectos o programas financiados totalmente por la UNRC se administran bajo una
misma cuenta bancaria independientemente de la convocatoria. Para los cofinanciados se abrirá una
cuenta bancaria por convocatoria si así lo dispone la entidad cofinanciera.
En las bases de una convocatoria se define un conjunto de rubros sobre los cuales el
responsable de una propuesta programa el presupuesto de gastos. También en dichas bases, se
puede fijar un porcentaje máximo de financiación del presupuesto total a un rubro en particular. Un
rubro además, puede contener sub-rubros.
Las convocatorias son financiadas por distintos entes, como son: la U.N.R.C., Foncyt, agencia
Córdoba Ciencia, etc., Cada uno de ellos determina el porcentaje a financiar.
Las propuestas de proyectos y programas son presentadas por los docentes investigadores
ante las autoridades de las unidades ejecutoras (facultades). La documentación debe constar del
título identificador del proyecto, resumen de actividades a realizar, objetivos propuestos, presupuesto
estimado para la ejecución, área y disciplina de investigación en la que se encuadra el proyecto o
programa, además de nómina, antecedentes y tiempo de dedicación de los integrantes. Los
proyectos están integrados por un director, el cual debe ser un docente con dedicación exclusiva o
semi-exclusiva; ocasionalmente puede existir un co-director que debe cumplir los mismos requisitos
que el director. En el caso particular de los proyectos de fomento, y de Ideas Proyecto no pueden
contar con la figura de co-director. Los integrantes y colaboradores pueden ser: docentes, adscriptos,
becarios de grado y pos-grado y tesistas de pos-grado, técnicos de apoyo del CONICET, personal no
docente de la Universidad, docentes de otras unidades académicas, alumnos de grado, etc. Se
admite la figura de asesor para dar apoyo al desarrollo de temas específicos. Los integrantes de
programas deben cumplir con los mismos requisitos que los integrantes de un proyecto, a excepción
del director, que además debe ser director de alguno de los proyectos que componen dicho programa
y deberá tener como antecedente una exitosa dirección en algún proyecto anterior.
Los programas de investigación deben estar conformados por dos ó más proyectos cuyos
miembros integrantes no pueden estar incluidos en más de un proyecto dentro del programa.
Página 4
Metodología Utilizada
Este proceso, utiliza el Lenguaje Unificado de Modelado [2] para preparar todos los esquemas
de un sistema de software. Los tres aspectos fundamentales que definen este proceso son los
siguientes:
Dirigido por Casos de Uso: Un caso de uso es un fragmento de funcionalidad del sistema que
proporciona al usuario un resultado importante. Representan los requisitos fundamentales. Dirigido
por casos de uso quiere decir que el proceso de desarrollo sigue un hilo, avanza a través de una serie
de flujos de trabajo que parten de los casos de uso.
Centrado en la Arquitectura: La arquitectura es una vista del diseño completo con las características
más importantes resaltadas, dejando detalles de lado. La descripción de la arquitectura ayuda al
arquitecto a centrarse en los objetivos adecuados, como la comprensibilidad, la capacidad de
adaptación al cambio y la reutilización.
Iterativo e Incremental: Es práctico dividir el trabajo en partes más pequeñas o miniproyectos. Cada
mini proyecto es una iteración que resulta en un incremento. Las iteraciones sucesivas se construyen
sobre los artefactos de desarrollo tal como quedaron al final de la última iteración. Al ser mini
proyectos, comienzan con los casos de uso y continúan a través del trabajo de desarrollo
subsiguiente, análisis, diseño, implementación y prueba, que termina convirtiendo en código
ejecutable los casos de uso que se desarrollan en la iteración.
El Proceso Unificado se repite a lo largo de una serie de ciclos, que constituyen la vida de un
sistema. Cada ciclo consta de cuatro fases:
Inicio: Se desarrolla una descripción del producto final a partir de una idea y se presenta el análisis
del negocio del producto.
Elaboración: Se especifican en detalle la mayoría de los casos de uso del producto y se diseña la
arquitectura del sistema.
Transición: Cubre el período durante el cual el producto se convierte en una versión beta. En la
versión beta un grupo reducido de usuarios con experiencia prueba el producto e informa defectos y
deficiencias.
Cada una de estar fases se subdivide a su vez en iteraciones. Cada ciclo produce una nueva
versión del sistema y cada versión es un producto preparado para su entrega. El producto terminado
incluye los requisitos, casos de uso, especificaciones no funcionales y casos de prueba.
Página 5
Captura de Requerimientos – Modelo de Negocio
4. CAPTURA DE REQUERIMIENTOS
El objetivo principal en esta etapa es guiar el desarrollo hacia el sistema correcto. Esto se
obtiene mediante una descripción de los requisitos del sistema, la que permitirá que tanto clientes y
desarrolladores lleguen a un acuerdo sobre lo que debe y no debe hacer el sistema.
La captura de requisitos suele ser complicada. En algunos casos se hace difícil porque los
usuarios no tienen bien en claro cuáles son los requisitos ni tampoco como especificarlos de manera
precisa. Incluso ni con la ayuda de los analistas pueden comprender lo que el sistema de software
hará hasta que esté terminado. Entonces para conocer cuáles son los requisitos no basta sólo con
realizar una entrevista con los usuarios.
A continuación describiremos los artefactos del Modelo de Negocio que son los siguientes:
Modelo de Dominio
Reglas de Negocio
Glosario de términos
Modelo de Caso de Uso de negocio.
Para una mejor visualización dividimos el modelo de dominio en tres partes que reflejan
distintos aspectos del contexto del sistema:
1. IT MUST ALWAYS HOLD THAT se administran solamente los Proyectos o Programas que
han sido aprobados y admitidos previamente para alguna convocatoria.
2. Una persona puede ser director de un Programa de una convocatoria ONLY IF es director de
algunos de los Proyectos que conforman dicho Programa.
Página 6
Captura de Requerimientos – Modelo de Negocio
Página 7
Captura de Requerimientos – Modelo de Negocio
Página 8
Captura de Requerimientos – Modelo de Negocio
4. IT MUST ALWAYS HOLD THAT las categorías, modalidades, áreas y temas prioritarios
asociados a un proyecto deben estar incluidos en las categorías, modalidades, áreas y temas
prioritarios descriptos en la normativa de esa convocatoria.
5. IT MUST ALWAYS HOLD THAT cada proyecto tendrá un presupuesto por cada año de
ejecución.
6. IT MUST ALWAYS HOLD THAT los presupuestos de gastos se deberán confeccionar con
rubros permitidos en cada convocatoria.
7. IT MUST ALWAYS HOLD THAT la suma total de los presupuestos de un proyecto no debe
superar al monto total asignado a dicho proyecto.
8. IT MUST ALWAYS HOLD THAT en los presupuestos se deberán respetar los topes de
financiamiento por rubro descriptos en la normativa de cada convocatoria.
10. Para poder iniciar la ejecución de un período de un presupuesto dado debe cumplirse que el
período anterior del mismo esté rendido al menos en el mínimo exigible.
11. IT MUST ALWAYS HOLD THAT el monto de adelanto que se puede solicitar debe ser menor
igual al saldo financiero disponible.
12. IT MUST ALWAYS HOLD THAT los viáticos solicitados para algún integrante de algún
proyecto o programa solo deberán ser otorgados si dicho integrante posee un cargo o
relación de dependencia con la Universidad.
Página 9
Captura de Requerimientos – Modelo de Negocio
13. IT MUST ALWAYS HOLD THAT los programas deberán tener como mínimos 2 proyectos
integrantes.
14. IT MUST ALWAYS HOLD THAT los subrubros asociados a una convocatoria deberán
pertenecer a un rubro asociado a la misma.
Página 10
Captura de Requerimientos – Modelo de Negocio
Los artefactos del Modelo de Casos de Uso de Negocio son los siguientes:
Casos de Uso del Negocio: representa una secuencia de acciones que el negocio desarrolla
y por el cual obtiene un resultado de valor para uno o más actores del negocio. Permite
conocer el comportamiento del negocio, el valor que provee y cómo interactúa con su
ambiente.
Actores del Negocio: rol que algo o alguien cumple cuando interactúa con el negocio.
Solicitud de Adelantos
El responsable de la propuesta, presenta una nota al encargado contable de la Secretaría solicitando
un adelanto de dinero. El encargado, evalúa si existe saldo suficiente en el presupuesto del proyecto
o programa como así también si la Secretaría dispone de los fondos suficientes para otorgar dicho
adelanto. Si el proyecto o programa no tiene Saldo suficiente se rechaza el pedido, informando al
responsable los motivos del rechazo. Si la Secretaría no dispone de saldo suficiente para otorgar el
adelanto, éste queda en estado suspendido hasta que se dispongan de los fondos.
Página 11
Captura de Requerimientos – Modelo de Negocio
Si la Secretaría y el proyecto o programa cuentan con saldo suficiente, el encargado contable dispone
el otorgamiento total o parcial del dinero. Si éste decide no otorgar el adelanto se informa al
responsable las razones del rechazo. Ver Figura Nº 4.4.
Otorgada una solicitud de adelanto se puede hacer una devolución del mismo, el cual deberá ser
realizado por el responsable de un proyecto o programa ante el encargado contable, con dinero en
efectivo. El encargado contable controla que el monto de reintegro sea menor o igual al monto total
por rendir y procesa la devolución del dinero.
Rendición de gastos
El responsable del programa o proyecto presenta al encargado contable comprobantes de gastos
realizados. El encargado contable verifica el formato del comprobante, analizando en primer lugar si
la factura es interna o externa (proveniente de proveedores extranjeros). Si la factura es interna, se
verifica si la fecha de rendición está dentro del plazo permitido de entrega, sino, es rechazada. Si la
factura es externa, no realiza controles de forma ni de fechas ya que la documentación proveniente
del exterior puede tardar en ser recibida.
Posteriormente se analiza que el rubro al que corresponde rendir cada ítem del comprobante
presentado cuente con saldo presupuestario. Si cuenta con saldo, entonces se rinde, sino se rechaza.
Ver Figura Nº 4.5. En el caso de ser rechazada, el encargado contable le da la posibilidad al
responsable de solicitar una reformulación de presupuesto.
Reformulación de presupuesto
El responsable de un proyecto o programa propone reformular el presupuesto modificando los montos
asignados a los rubros en el presupuesto vigente, mediante la presentación de una nota. El
encargado contable verifica que disponga de saldos presupuestarios en los rubros afectados, si tiene
saldo disponible gestiona la aprobación o no, de la presente reformulación ante la autoridad
competente, sino rechaza el pedido de reformulación. Si es aprobada, el encargado contable
efectiviza la reformulación y archiva la nota. Si no, éste rechaza la reformulación. Ver Figura Nº 4.6.
Ente financiero
Secretaría de Ciencia y Técnica
Encargado Administrativo
Encargado Contable
Responsable de Proyecto ó Programa
Describe los procesos de una empresa en términos de casos de uso del negocio y actores de
negocio y ayuda a lograr un mejor entendimiento del contexto del negocio. Ver Figura Nº 4.7.
Página 12
Captura de Requerimientos – Modelo de Negocio
Página 13
Captura de Requerimientos – Modelo de Negocio
Página 14
Captura de Requerimientos – Modelo de Negocio
Página 15
Captura de Requerimientos – Modelo de Negocio
4.2.1 Actores
En esta etapa debemos identificar todos los participantes que interactuarán con el sistema. A
partir del Modelo de Casos de Uso del Negocio, más específicamente de los actores de negocio
podemos identificar los actores del sistema:
Además, a partir del Modelo de Dominio surgieron los casos de uso del sistema que se
refieren a la parte bancaria. Ver Figura Nº 4.10.
Página 16
Captura de Requerimientos – Modelo de Negocio
Figura Nº 4.8 – Realización de Casos de Uso de Negocio a Casos de Uso del Sistema
Página 17
Captura de Requerimientos – Modelo de Negocio
Página 18
Captura de Requerimientos – Modelo de Negocio
Página 19
Captura de Requerimientos – Modelo de Negocio
gestionar Programas dado que un programa está compuesto por proyectos incluye el buscar
proyectos.
Gestión Presupuesto: Ver Figura Nº 4.14.
Gestión Viático y Gestión Factura: Ver Figura Nº 4.15.
Gestión Beca y Solicitud y Devolución de Adelantos: Ver Figura Nº 4.16.
Los casos de uso restantes del sistema que incluyen alta, modificación, búsqueda y
eliminación, se relacionan de la misma manera que el caso de uso genérico Gestión Elemento. Ver
Figura Nº 4.17.
Página 20
Captura de Requerimientos – Modelo de Negocio
Figura Nº 4.13 – Relaciones entre casos de uso - Gestión Proyecto y Gestión Programa
Página 21
Captura de Requerimientos – Modelo de Negocio
Página 22
Captura de Requerimientos – Modelo de Negocio
Figura Nº 4.16 – Relaciones entre casos de uso – Gestión Beca y Solicitud y Devolución de Adelantos
Página 23
Captura de Requerimientos – Modelo de Negocio
Gestión Categoría
Gestión Modalidad
Gestión Tipo Proyecto
Gestión Ente Financiero
Gestión Área y Temas Prioritarios
Gestión Rubro
Gestión Subrubro
Gestión Banco
Gestión Sucursal Banco
Gestión Cuenta Banco
Gestión Convocatoria
Gestión Disciplina
Gestión Campo de Aplicación
Gestión Facultad
Gestión Departamento
Gestión Persona
Gestión Cargo
Gestión Tipo de Cargo
Gestión Tipo de Función
Gestión Presupuesto
Gestión Proyecto
Gestión Programa
Página 24
Captura de Requerimientos – Modelo de Negocio
- Disminuir la dificultad para comprender los diversos modelos de solución planteados para
resolver el mismo tipo de problema.
- Reducir el volumen de documentación, evitando la repetición de modelos que resuelven el
mismo problema
- Instanciar problemas reales en un modelo general propuesto
- Homogeneizar el comportamiento y la apariencia de las funcionalidades del sistema que son
del mismo tipo, tales como la inserción, modificación, eliminación y búsqueda.
A continuación listamos los casos de uso del sistema que podrán ser descriptos en esta
documentación utilizando las plantillas genéricas, dado que sus comportamientos se adaptan a
dichas plantillas. Cada uno de ellos será instanciado en la iteración que corresponda. Estos casos de
uso del sistema son los siguientes:
Página 25
Primera Iteración – Descripción de Casos de Uso
5. PRIMERA ITERACION
A medida que se van identificando los casos de uso se realiza una descripción detallada que
indica lo que el sistema necesita hacer cuando interactúa con sus actores, cómo comienza y termina
el caso de uso. Esta descripción sirve a los desarrolladores para identificar más claramente las
funcionalidades de los casos de usos frente a sus correspondientes actores y además es considerado
un buen punto de partida cuando diseñamos la interfaz de usuario.
Página 26
Primera Iteración – Descripción de Casos de Uso
Página 27
Primera Iteración – Descripción de Casos de Uso
Página 28
Primera Iteración – Descripción de Casos de Uso
Página 29
Primera Iteración – Descripción de Casos de Uso
Página 30
Primera Iteración – Análisis de Casos de Uso
5.2. Análisis
Durante esta etapa, analizamos los requisitos que se describieron en la captura de requisitos,
refinándolos y estructurándolos. El objetivo es conseguir una compresión más precisa de los
requisitos y una descripción de los mismos que nos ayude a estructurar el sistema entero.
Modelo de Análisis: Definido por una jerarquía de paquetes de Análisis conteniendo clases
de análisis y realizaciones de Casos de Uso.
Convocatoria nombre
fecha_ini_pren
fecha_fin_pren
Entidad plazo_duración
monto_total_financ
minimo_exigible
tipoProyecto
Página 31
Primera Iteración – Análisis de Casos de Uso
Escenario: Se desea dar de alta una convocatoria para un tipo de proyecto existente. La
convocatoria no existe en el sistema. Ver Figura Nº 5.3.
Página 32
Primera Iteración – Análisis de Casos de Uso
Página 33
Primera Iteración – Análisis de Casos de Uso
Página 34
Primera Iteración – Análisis de Casos de Uso
Página 35
Primera Iteración – Análisis de Casos de Uso
Página 36
Primera Iteración – Diseño e Implementación de Casos de Uso
Etapa de Diseño
Descripción de la arquitectura: contiene una vista arquitectónica del modelo de diseño, que
muestra sus artefactos relevantes para la arquitectura.
Modelo de diseño: es un modelo de objetos que describe la realización física de los casos de
uso y sirve de abstracción de la implementación del sistema.
Trabajadores:
Actividades:
Página 37
Primera Iteración – Diseño e Implementación de Casos de Uso
Etapa de Implementación
Las actividades en esta etapa son las siguientes: Implementación de la arquitectura, Integrar
el sistema, Implementar un subsistema, Implementar una clase, Realizar prueba de unidad.
Básicamente, el mecanismo RMI provee una manera sencilla de comunicar dos aplicaciones
Java de forma remota. Las funciones esenciales provistas por este mecanismo son:
Localización de objetos remotos: es la manera de obtener referencias a objetos remotos.
Esto puede hacerse mediante la facilidad de nombrado que ofrece la aplicación rmiregistry,
provista por el mecanismo RMI.
Comunicación con objetos remotos: Los detalles de comunicación entre objetos son
tranparentes al programador, quedando a cargo de RMI. La comunicación remota es similar a
la llamada estándar de un método en Java.
Carga de bytecodes para objetos enviados: RMI se encarga de la carga del código de los
objetos así como el envío del mismo.
Página 38
Primera Iteración – Diseño e Implementación de Casos de Uso
Definición de las interfaces remotas: Es necesario definir interfaces en común, para que
cliente pueda acceder a los servicios provistos por el servidor. Estas interfaces sólo definen
que métodos remotos pueden ser invocados por los clientes, no su implementación.
Implementar los objetos remotos: Es necesario definir objetos que implementen una ó más
interfaces remotas.
Implementar los clientes: Los clientes que utilizan objetos remotos pueden ser
implementados después de haber definido los interfaces remotos, incluso después de que los
objetos remotos hayan sido desplegados.
En este sistema, esta interface está representada por la interface IControl, localizada en el
paquete comun.IControl. La clase que implementa esta interface es la Control, localizada en el
paquete servidor.Control. Las clases clientes están localizadas dentro de los diferentes paquetes del
paquete cliente. Ver Figura Nº 5.5
Página 39
Primera Iteración – Diseño e Implementación de Casos de Uso
La utilización de estas tecnologías provee una alta independencia del sistema de base de
datos ya que, es la implementación del estándar JDO (por ejemplo JPOX) la encargada de proveer
los diferentes drivers para los distintos sistemas de base de datos, permitiendo así migrar fácilmente
de un sistema de base de datos a otro.
5.3.3.1 Singleton
El patrón de diseño Singleton es un patrón de tipo creacional. Garantiza que una clase sólo
tenga una instancia y proporciona un punto de acceso global a ella.
Se utiliza cuando:
Debe haber exactamente una instancia de una clase y debe ser accesible a los clientes
desde un punto de acceso conocido.
Acceso al archivo de configuración de una aplicación.
Gestor de impresión.
Una fábrica de objetos.
El sistema hace uso de este patrón para el acceso a la base de datos, en la clase
Persistencia, asegurando una única instancia que represente la conexión a la base de datos. Ver
Figura Nº 5.6.
5.3.3.2 Mediador
El mediador es un objeto intermediario que permite encapsular la forma en que interactúan un
conjunto de objetos. Cuando muchos objetos interactúan con otros objetos, se puede formar una
estructura muy compleja. En un caso extremo cada objeto puede conocer a todos los demás objetos.
Para evitar esto el patrón Mediator encapsula el comportamiento de todo un conjunto de objetos en
un solo objeto. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros
explícitamente, y permite variar la interacción entre ellos de forma independiente. En nuestro sistema
se utilizó este patrón para implementar el control de las interfaces gráficas.
En el diseño de este sistema cada caso de uso consta de única clase de control y hereda de
la clase abstracta Mediador. Dicha clase abstracta implementa una serie de métodos común a todos
sus descendientes y define un método abstracto denominado execute, el cual deberá ser
implementado por sus descendientes. Este método representa el punto de acceso al caso de uso en
cuestión, es decir, debe iniciar el caso de uso. Ver Figura Nº 5.7
Página 40
Primera Iteración – Diseño e Implementación de Casos de Uso
Figura Nº 5.7 – Jerarquía de clases que representan la implementación del patrón Mediador
Página 41
Primera Iteración – Diseño e Implementación de Casos de Uso
En este diseño, este patrón está reflejado en las clases localizadas en el paquete comun.DTO
y en el paquete comun.Assembler. El primer paquete posee el conjunto de clases que son
manipuladas tanto por el cliente como por el servidor. Estas son las que sirven de transporte entre las
dos partes, es decir, son los objetos serializables. El segundo paquete posee una única clase
encargada de la tarea de conversión de objetos del dominio a objetos serializables y viceversa.
Las clases del paquete comun.DTO heredan de una clase abstracta denominada ClaseDTO,
la cual implementa una serie de métodos común a todos sus descendientes y define dos métodos
abstractos, getTitulosBusqueda() y getCamposBusqueda(), los cuales deberán ser implementados
por sus descendientes. Estos métodos son necesarios para poder hacer uso de la búsqueda genérica
implementada en el sistema. Esta funcionalidad será explicada en detalle en la sección 5.3.4.1.
La Figura Nº 5.8 muestra la clase abstracta ClaseDTO, y un conjunto de clases que heredan
de ésta, representando las clases del paquete comun.DTO. La Figura Nº 5.9 muestra la clase
Assembler con la lista de métodos que ofrece la misma.
Figura Nº 5.8 – Jerarquía de clases que representan la implementación del patrón DTO
Página 42
Primera Iteración – Diseño e Implementación de Casos de Uso
Un caso de uso específico consta de su correspondiente paquete dentro del paquete cliente y
su nombre es representativo al caso de uso. Dentro del mismo deberían encontrarse las clases
correspondientes a la interfaz gráfica del mismo (si posee) más las clases de control del mismo. En la
implementación actual cada caso de uso consta de única clase de control que de manera general se
denomina Mediador<Elemento>, donde <Elemento> corresponde al nombre del caso de uso y hereda
de la clase abstracta Mediador localizada en el paquete cliente.Mediador. Dicha clase abstracta
implementa una serie de métodos común a todos sus descendientes y define un método abstracto
denominado execute, el cual deberá ser implementado por sus descendientes. Este método
representa el punto de acceso al caso de uso en cuestión, es decir, debe iniciar el caso de uso.
Posee dos parámetros: modoInicio, de tipo int, que representa el modo en que debe iniciarse el caso
de uso; los posibles valores están especificados en la clase Constante contenida en el paquete
comun.Utilidades:
El segundo parámetro del método execute es: parámetros, de tipo Parameter. Este parámetro
representa contiene los parámetros de entrada para la ejecución del caso de uso y básicamente
permite definir propiedades con sus valores de manera similar a la clase Property de Java. Cada
“propiedad” consta de un nombre y un valor. Los nombres y valores de cada propiedad son definidas
por el caso de uso específico. Este parámetro puede utilizarse, por ejemplo, cuando se desea iniciar
el caso de uso en modo EDIT. En este caso podría definirse una propiedad de nombre “objeto” y valor
Elemento, donde Elemento representa el objeto a modificar.
Por otro lado, el lo que concierne a la manipulación de datos del dominio, como se explicó
anteriormente, existe el paquete servidor.Assembler que contiene la clase Assembler, encargada de
convertir objetos del dominio en objetos serializables y viceversa. Dado que esta clase provee
métodos genéricos de conversión de clases, es necesario respetar cierta nomenclatura para un
correcto funcionamiento. Básicamente, deben definirse dentro del paquete servidor.persistente las
clases que representen los objetos del dominio, es decir, persistentes. Estas clases deben extender
de la clase abstracta Persistente. Por cada una de estas clases, puede definirse su correspondiente
clase serializable dentro del paquete comun.DTO, las cuales deben respetar el mismo nombre que su
correspondiente persistente más el sufijo “DTO” y deben heredar de la clase abstracta ClaseDTO. Por
ejemplo, si se define la clase persistente Factura y se desea tener una clase que represente su
correspondiente serializable, la misma deberá denominarse FacturaDTO. De esta manera, el sistema
automáticamente, por medio de los métodos assembler y desAssembler de la clase Assembler,
convertirá un objeto de tipo Factura en un objeto de tipo FacturaDTO y viceversa. Además, para que
esto funcione de manera correcta, los nombres y tipos de los atributos de las clases persistente y los
de las clases serializables correspondientes deberán ser los mismos, a excepción de los atributos de
tipo Set de las clases persistentes que deberán corresponderse con el tipo Vector en las clases
serializables correspondientes. Es decir, si la clase Factura posee los atributos: id de tipo int, fecha de
tipo Date, monto de tipo Float y items de tipo Set, la clase FacturaDTO deberá contener los mismos
atributos con los mismos tipos excepto el atributo items que deberá ser de tipo Vector. Aquellos
atributos que sólo se encuentren en una de las dos clases (persistente ó serializables) serán
excluidos en el proceso de conversión.
Página 43
Primera Iteración – Diseño e Implementación de Casos de Uso
En esta se encuentra la funcionalidad del caso de uso Buscar. Por medio del método execute se da
inicio al caso de uso. El parámetro modoInicio de este método debe ser NULL, ya que otro valor será
ignorado. El parámetro parámetros debe configurarse con las siguientes propiedades:
La primera propiedad (DTOObject), la cual es obligatoria, debe ser un objeto que herede de la
clase ClaseDTO. La búsqueda de elementos se basa en estas clases para su funcionamiento. De
ellas extrae los campos de búsqueda, por lo tanto, si se desea buscar personas, deberá existir la
clase serializable que represente personas, por ejemplo PersonaDTO. Esta clase deberá redefinir los
atributos titulosBusqueda y camposBusqueda definidos en la clase abstracta ClaseDTO que
representan los títulos de cada campo a buscar y el nombre del campo (nombre del atributo de la
clase) por el cual se desea buscar correspondientemente. Ambos atributos son de tipo array de
String. Por ejemplo, la clase PersonaDTO podría redefinir estos atributos como sigue:
Esto significa que se pueden buscar personas a través de su nombre, su apellido y/o su
número de documento.
Herramientas de desarrollo:
Lenguaje de programación Java (con máquina virtual JDK 1.6): es un lenguaje de
programación orientado a objetos e independiente de la plataforma.
IDE de desarrollo Netbeans 6.8: es un entorno de desarrollo - una herramienta para que los
programadores puedan escribir, compilar, depurar y ejecutar programas. Está escrito en Java
Página 44
Primera Iteración – Diseño e Implementación de Casos de Uso
- pero puede servir para cualquier otro lenguaje de programación. Existe además un número
importante de módulos para extender el NetBeans IDE.
MYSQL Administrator 1.2.17: es una herramienta que permite realizar tareas
administrativas sobre servidores de MySQL. Es un software multiplataforma, que por el
momento se encuentra disponible para Linux y Microsoft Windows y que cuenta con un
entorno gráfico de usuario muy intuitivo.
IReport 3.1.4: La herramienta iReport es un constructor / diseñador de informes visual,
poderoso, intuitivo y fácil de usar para JasperReports escrito en Java.
JPOX(Objetos Persistente de Java): es una implementación de los estándares JDO 1.0 y
2.0 de persistencia en Java.
IzPack 4.3.3: herramienta desarrollada en Java que permite realizar instaladores
independientes de la plataforma (en formato .jar).
Software requerido:
JRE 1.6: es el conjunto de aplicaciones necesarias para la ejecución de aplicaciones
desarrolladas bajo esta plataforma.
Motor de Base de Datos MYSQL Server 5.1: sistema de gestión de base de datos
relacional, multihilo y multiusuario.
Debido a que son más parecidos a los diagramas de casos de usos, estos son utilizados para
modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre
un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del
sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.
En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del
sistema. Uno de los usos principales es que puede servir para ver qué componentes pueden
compartirse entre sistemas o entre diferentes partes de un sistema.
Página 45
Primera Iteración – Diseño e Implementación de Casos de Uso
Página 46
Primera Iteración – Diseño e Implementación de Casos de Uso
Página 47
Primera Iteración – Diseño e Implementación de Casos de Uso
Página 48
Primera Iteración – Diseño e Implementación de Casos de Uso
Página 49
Primera Iteración – Diseño e Implementación de Casos de Uso
Página 50
Primera Iteración – Diseño e Implementación de Casos de Uso
Página 51
Primera Iteración – Diseño e Implementación de Casos de Uso
Página 52
Primera Iteración – Diseño e Implementación de Casos de Uso
Página 53
Segunda Iteración – Descripción de Casos de Uso
6. SEGUNDA ITERACION
Como se indicó en el punto 4.2.2.2.2, en esta iteración se consideran los casos de uso que
implican la administración de Proyectos y Programas.
En el punto 6.1.2 se realiza descripción mediante plantillas [9] para los casos de uso de esta
segunda iteración que se comportan de manera genérica y que refieren a problemas de inserción,
modificación, eliminación y búsqueda. Estos casos de uso son los siguientes:
3. Selecciona la modalidad
4. Ingresa título del proyecto
Página 54
Segunda Iteración – Descripción de Casos de Uso
2. Selecciona Proyecto
3. Muestra datos del Proyecto
4. Selecciona director,
codirector, facultad,
departamento, disciplina,
categoría, campo de
aplicación, área y tema
prioritario
5. Elimina o asocia datos seleccionados, include (Datos Proyecto-
Programa)
Página 55
Segunda Iteración – Descripción de Casos de Uso
Página 56
Segunda Iteración – Descripción de Casos de Uso
Página 57
Segunda Iteración – Descripción de Casos de Uso
2. Selecciona Proyecto o
Programa
Página 58
Segunda Iteración – Descripción de Casos de Uso
Página 59
Segunda Iteración – Descripción de Casos de Uso
Página 60
Segunda Iteración – Descripción de Casos de Uso
Página 61
Segunda Iteración – Análisis de Casos de Uso
6.2. Análisis
Página 62
Segunda Iteración – Análisis de Casos de Uso
Página 63
Segunda Iteración – Análisis de Casos de Uso
Página 64
Segunda Iteración – Análisis de Casos de Uso
Página 65
Segunda Iteración – Análisis de Casos de Uso
Página 66
Segunda Iteración – Análisis de Casos de Uso
Página 67
Segunda Iteración – Análisis de Casos de Uso
Página 68
Segunda Iteración – Análisis de Casos de Uso
Página 69
Segunda Iteración – Análisis de Casos de Uso
Página 70
Segunda Iteración – Análisis de Casos de Uso
Página 71
Segunda Iteración – Análisis de Casos de Uso
Página 72
Segunda Iteración – Análisis de Casos de Uso
Página 73
Segunda Iteración – Análisis de Casos de Uso
Página 74
Segunda Iteración – Análisis de Casos de Uso
Página 75
Segunda Iteración – Análisis de Casos de Uso
Página 76
Segunda Iteración – Diseño e Implementación de Casos de Uso
Página 77
Segunda Iteración – Diseño e Implementación de Casos de Uso
Página 78
Segunda Iteración – Diseño e Implementación de Casos de Uso
Página 79
Segunda Iteración – Diseño e Implementación de Casos de Uso
Página 80
Segunda Iteración – Diseño e Implementación de Casos de Uso
Página 81
Segunda Iteración – Diseño e Implementación de Casos de Uso
Página 82
Segunda Iteración – Diseño e Implementación de Casos de Uso
Página 83
Segunda Iteración – Diseño e Implementación de Casos de Uso
Página 84
Segunda Iteración – Diseño e Implementación de Casos de Uso
Página 85
Segunda Iteración – Diseño e Implementación de Casos de Uso
Página 86
Tercera Iteración - Descripción de los Casos de Uso
7. TERCERA ITERACION
Como se indicó en el punto 4.2.2.2.3, en esta iteración se consideran los casos de uso que
implican la administración contable de los presupuestos de Proyectos y Programas.
En el punto 7.1.2 se realiza descripción mediante plantillas [4] para los casos de uso de esta tercera
iteración que se comportan de manera genérica y que refieren a problemas de inserción,
modificación, eliminación y búsqueda. Estos casos de uso son los siguientes:
2. Selecciona el presupuesto
del cual se quiere solicitar el
adelanto o devolución.
Página 87
Tercera Iteración - Descripción de los Casos de Uso
Página 88
Tercera Iteración - Descripción de los Casos de Uso
2. Selecciona presupuesto
3. include (Buscar Proveedor).
4. Selecciona proveedor
5. Ingresa el número de
factura y fecha, y por cada
ítem ingresa descripción,
cantidad y precio unitario.
6. Si la factura es compartida con otro proyecto, asocia cada ítem
ingresado con los proyectos correspondientes.
7. Verifica el saldo presupuestario de cada uno de los subrubros
relacionados con los ítems ingresados.
8. Calcula el monto total de la factura.
9. Registra Factura.
1.1 Si el proyecto no existe el sistema lo informa. Termina.
3.1 Si el proveedor no existe el sistema lo ifnorma. Termina
7.1 Si no tiene saldo presupuestario disponible, el sistema lo informa. Termina.
8.1 Si el monto total de la factura supera el monto a rendir, el sistema lo informa. Termina.
Página 89
Tercera Iteración - Descripción de los Casos de Uso
Página 90
Tercera Iteración - Descripción de los Casos de Uso
Página 91
Tercera Iteración - Análisis de Casos de Uso
7.2. Análisis
Página 92
Tercera Iteración - Análisis de Casos de Uso
Página 93
Tercera Iteración - Análisis de Casos de Uso
Control
Control_Gestion_Presupuesto Obtiene el presupuesto del proyecto del
cual se solicita el viático.
Control_Gestión_SubRubro Obtiene el subrubro viático
Página 94
Tercera Iteración - Análisis de Casos de Uso
Página 95
Tercera Iteración - Análisis de Casos de Uso
Escenario: Se desea pedir una beca para un integrante de un proyecto existente que tiene becarios.
Dicho proyecto posee saldo financiero disponible en el subrubro beca. Ver Figura Nº 7.6.
Página 96
Tercera Iteración - Análisis de Casos de Uso
Página 97
Tercera Iteración - Análisis de Casos de Uso
Factura nro_factura
tipo_factura
condición_venta
monto
fecha_rendicion
Entidad ItemFactura nro_item
descripcion
cantidad
precio_unitario
MontoporItem importe
Página 98
Tercera Iteración - Análisis de Casos de Uso
Página 99
Tercera Iteración - Análisis de Casos de Uso
Página 100
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 101
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 102
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 103
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 104
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 105
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 106
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 107
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 108
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 109
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 110
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 111
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 112
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 113
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 114
Tercera Iteración - Diseño e Implementación de Casos de Uso
Página 115
Prueba
8. PRUEBA
En esta etapa se verifica el resultado de la implementación probando cada construcción,
incluyendo tanto construcciones internas como intermediarias, así como las versiones finales del
sistema a ser entregada a terceros.
Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de integración
y las pruebas de sistemas.
Diseñar e implementar las pruebas
Realizar las pruebas y manejar los resultados de las mismas.
Es importante destacar que la etapa de prueba permite asegurar la calidad de los procesos
de desarrollo, implementación y mantenimiento. Además permite verificar que el software
desarrollado cumple con los requerimientos solicitados en forma satisfactoria.
La prueba ideal sería someter al producto a todas las situaciones posibles. Pero como no es
posible, se utilizan diversas técnicas.
Para realizar las pruebas se seleccionaron sólo algunos métodos de caja negra y caja blanca.
Para cada caso de uso, se intentó escoger los métodos más significativos de prueba.
En la prueba de caja negra se designa a un módulo sujeto a estudio desde el punto de vista
de las entradas que recibe y las salidas o respuestas que éste produce, sin tener en consideración su
funcionamiento interno. Se definen pruebas orientadas a intentar comprender que es lo que el módulo
hace y no como éste lo hace.
Para realizar las pruebas se seleccionó el método de prueba de caja negra Tablas de
Decisión, que: son usadas para representar relaciones lógicas complejas. Condiciones, acciones,
reglas. Se identifican condiciones como entradas y acciones como salidas, por lo tanto las reglas son
los casos de prueba.
Página 116
Prueba
Condiciones:
C1: ¿Se ha rendido el mínimo exigible del período anterior?
C2: ¿Posee el proyecto saldo disponible?
C3: ¿Posee el subrubro un tope establecido en la convocatoria que reglamenta el proyecto?
C4: ¿Excede el monto ingresado el saldo disponible en el proyecto?
C5: ¿El monto ingresado excede el tope establecido en la convocatoria?
Condiciones
C1 True True True True True True False
C2 True False True True True True -
C3 True - True True False False -
C4 True - False False True False -
C5 - - True False - - -
Valor Esperado
Error X X X X X
Ok X X
C1: No tiene período anterior, por lo tanto mínimo exigible es True ERROR ERROR
C2: Saldo disponible= $400
C3: ¿Tope Laboratorio? False
C4: Monto a ingresar en subrubro laboratorio= $550. ¿550 > 400?
True
Página 117
Prueba
….
…
// Monto total presupuestado en el subrurbo "subrubroDestino"
Float montoAsignadoTotal = getMontoAsignadoTotal(subrubroDestino);
uiFramePresupuesto.getJfdSaldoDisponibleSubrubroDestino().setValue(tope.get(
) - montoAsignadoTotal);
} else {
uiFramePresupuesto.getJfdSaldoDisponibleSubrubroDestino().setValue(saldoDisp
onible);
}
} else {
uiFramePresupuesto.getJfdSaldoDisponibleSubrubroDestino().setValue(saldoDisp
onible);
}
...
Página 118
Prueba
montoAsignadoTotal = getMontoAsignadoTotal(subrubroDestino);
if (porc.get() != 100.0f)
else
if ((tope.get() -
montoAsignadoTotal)
< saldoDisponible) else
uiFramePresupuesto.
getJfdSaldoDisponible
SubrubroDestino().set
uiFramePresupuest Value(saldoDisponibl
o.getJfdSaldoDispo e)
uiFramePresupuesto.getJfdSaldo
nibleSubrubroDesti
DisponibleSubrubroDestino().setV
no().setValue(tope. alue(saldoDisponible);
get() -
montoAsignadoTot
al)
Figura Nº 8.2 – Grafo de flujo de control del fragmento de código de la Figura Nº 8.1
Un conjunto mínimo de casos de prueba que permite que cada arco del flujo de control se
atravesado al menos una vez, es el siguiente:
Página 119
Prueba
donde, en el último subconjunto los valores X, Y y Z no influyen en el flujo del recorrido del programa,
dado que al ser el porcentaje 100% los valores de estas variables son irrelevantes, porque el
programa toma el camino del Else del primer If que aparece en el fragmento del código de la Figura
Nº 8.1.
….
private void getTopePorSubrubro(SubrubroDTO s, AtomicReference<Float>
porcentaje, AtomicReference<Float> tope) {
porcentaje.set(100.0f);
tope.set(getProyecto().getMonto());
for (int i = 0; i < getTope_por_rubro().size(); i++) {
if (getTope_por_rubro().get(i).getSubrubro().equals(s)) {
porcentaje.set(getTope_por_rubro().get(i).getPorcentaje());
tope.set((getProyecto().getMonto() * porcentaje.get()) /
100);
}
}
}
Figura Nº 8.3 – Fragmento de código que retorna el tope deifnido en un subrubro
Un conjunto mínimo de casos de prueba que permite que cada arco del flujo de control se
atravesado al menos una vez, es el siguiente:
T= { <getTope_por_rubro().size()=0>,
< getTope_por_rubro().size()!=0, s=getTope_por_rubro().get(0)>,
< getTope_por_rubro().size()=1, s!=getTope_por_rubro().get(0)> }
Finalizadas las pruebas, se verificó que se obtuvieran los resultados esperados como
respuestas a entradas apropiadas. A continuación mostramos los resultados obtenidos de cada una
de las pruebas de unidad realizadas:
La prueba de tabla de decisión nos permitió encontrar un error de control que era importante y
que se pudo corregir antes de entregar al usuario la versión final del sistema.
Página 120
Prueba
porcentaje.set(100.0f);
tope.set(getProyecto().getMonto());
endfor
for (int i = 0;
i < getTope_por_rubro().size(); i++)
if
(getTope_por_rubro().get(i).getSub
rubro().equals(s))
if
(getTope_por_rubro().ge
t(i).getSubrubro().equals
(s))
porcentaje.set(getTop
e_por_rubro().get(i).g
etPorcentaje());
endif
tope.set((getProyecto(
).getMonto() *
porcentaje.get()) /
100);
Figura Nº 8.4 – Grafo de flujo de control del fragmento de código de la Figura 8.3
Página 121
Conclusiones y Trabajos Futuros
9. CONCLUSIONES
La aplicación del sistema de software APPI, Administración de Programas y Proyectos de
Investigación, es una herramienta que permite la administración centralizada de programas y
proyectos de investigación científica, destinado a la Secretaría de Ciencia y Técnica de la UNRC,
quien es la responsable de promover y financiar el desarrollo de la investigación científico y técnico.
Este trabajo final, produce un avance importante con respecto a las herramientas
anteriormente utilizadas por el cliente, las que carecían de validación de datos y no permitían realizar
cruce de información entre proyectos de distintas convocatorias o programas. A partir de la
instalación y utilización del sistema en la Secretaría de Ciencia y Técnica, los usuarios han podido
valorar la funcionalidad y seguridad en el seguimiento de los proyectos de investigación que este
sistema aporta, ya que la cantidad y diversidad de proyectos que administra ésta secretaría, se
incrementa de manera importante año a año, debido al acelerado avance del conocimiento científico y
de políticas que promueven la investigación.
El desarrollo de esta aplicación nos ha permitido conocer con más profundidad el proceso de
desarrollo de software y darnos cuenta del impacto que tuvo la captura de requerimiento sobre el
desarrollo y diseño general del presente trabajo, como así también adquirir mayor conocimiento sobre
las herramientas de desarrollo y arquitectura utilizados. Creemos que a partir de haber utilizado una
metodología de desarrollo de software y pudiendo integrar los conocimientos previos obtenidos en las
diferentes materias de la carrera, se ha podido desarrollar el producto propuesto como objetivo al
inicio de este trabajo, que permite al cliente realizar las tareas administrativas propias del negocio de
manera práctica, eficiente y segura.
La modalidad de grupo, adoptada para la realización del presente trabajo, fue de carácter
fundamental para poder encarar las dificultades que se presentaron a lo largo del desarrollo del
sistema, ya que se pudieron discutir y consensuar diferentes puntos de vista respecto de las posibles
soluciones e intercambiar conocimientos y experiencias vividas, fortaleciendo así las relaciones
internas y externas del grupo.
Es importante destacar, que uno de los integrantes del grupo, queda vinculado laboralmente
al área de trabajo donde se utiliza el sistema, lo cual va a favorecer el crecimiento del mismo a la hora
de incorporar nuevas funcionalidades surgidas y/o propuestas, no solo por el cliente sino también por
el grupo desarrollador.
Realización de una aplicación web que se integre al sistema desarrollado, permitiendo acceso
a los datos de cada proyecto destinada a brindar información en línea a:
- Secretario, autoridades universitarias y trabajadores de la Secretaría de Ciencia y
Técnica, con acceso restringido, para evaluación de ejecución de convocatorias y/o
proyectos, cuentas bancarias, integrantes de proyectos, dedicación de horas de sus
integrantes.
- Directores y Responsables de proyectos, con acceso restringido, para consultar el
estado financiero y presupuestario de sus proyectos, sus movimientos y saldos.
- Organismos externos financieros o de control, con acceso restringido, para la
rendición de proyectos, exportación de datos a organismos externos que necesiten
información, académica, financiera y/o presupuestaria.
Página 122
Bibliografía
10.BIBLIOGRAFIA
[1] Ivar Jacobson, Grady Booch, James Rumbaugh. El Proceso Unificado de Desarrollo de
Software - Addison-Wesley, 2000.
[2] Booch Grady, Rumbaugh James, Jacobson Ivar. “The Unified Modeling Language.
AddisonWesley. 1999.
[13] Pressman, Roger. Software Engineering: A Practitioner's Approach. Fifth edition. ISBN:
0071181822. McGraw Hill. 2001
[14] Sommerville Ian. Ingeniería del Software, 7th edition, Addisson Wesley. Pearson
Education, 2005. ISBN: 978-84-7829-074-1
[15] Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli. Fundamentals of Software Engineering.
Prentice Hall, 1991.
Página 123
Bibliografía
Página 124
ANEXO: Plantillas
11.ANEXOS
En esta sección se presentan las plantillas genéricas para la descripción y el análisis de
casos de uso, dichas plantillas no son de nuestra autoría. Además también se hace referencia a
plantillas de diseño de casos de uso, específicas para nuestro sistema, desarrolladas por nosotros, y
que hemos utilizado y referenciado a lo largo del presente trabajo.
Página 125
ANEXO: Plantillas
Página 126
ANEXO: Plantillas
Página 127
ANEXO: Plantillas
Página 128
ANEXO: Plantillas
PARÁMETROS
• Nombre: representa el nombre del caso de uso que sé está instanciando.
• Actor: interactúa con el sistema.
• Entidad1..EntidadN: clases de domino que participan en la Realización del CU (diagrama de
clases de análisis). Debe existir como mínimo una entidad definida.
• Control1..ControlN: representa las clases de control de los casos de uso que están
relacionado con este. Las relaciones pueden ser de inclusión o extensión. No siempre es
necesario que existan casos de uso relacionados.
• Atributos clave: las propiedades que identifican al elemento de forma única.
• Atributos: propiedades que componen el elemento y no son clave.
• Criterios: Criterios utilizados para la búsqueda de elementos.
RESPONSABILIDADES
Clases Interfaces:
• Visualizar resultados.
• Permitir diferentes funcionalidades al actor como: insertar, modificar,
• modificar y búscar elementos.
• Verificar el formato de los datos ingresados.
Clases de control:
• Verificar datos duplicados
• Enviar a guardar datos.
• Enviar a buscar datos.
• Enviar a eliminar datos.
• Enviar a modificar datos.
• Enviar resultados a la interface.
Clases entidad:
• Permitir obtener los datos guardados.
• Guardar los datos en forma persistente.
Página 129
ANEXO: Plantillas
Flujo alternativo:
3 y 6 Si “verifica formato” arroja algún formato inválido, el sistema informa el error y vuelve a 2 y 5
respectivamente.
4 Si “verifica <Atributos claves>” encuentra un elemento, el sistema informa de la existencia y vuelve
a 2.
Página 130
ANEXO: Plantillas
Página 131
ANEXO: Plantillas
PARÁMETROS
• Elemento: representa el nombre del caso de uso que sé está instanciando.
• FrameElemento: es un frame adicional para hacer alguna inserción y se accede desde el
FramGestionElemento. No todos los casos de uso, utilizan este fram.
• FrameGestionElemento: es el frame principal del caso de uso y el primero que se visualiza.
• MediadorElemento: representa la clase mediador entre el usuario y el sistema.
• ElementoDTO: representa la clase DTO de cada caso de uso.
Página 132
ANEXO: Plantillas
Página 133
ANEXO: Plantillas
Página 134
ANEXO: Plantillas
MODIFICACIÓN
Escenario: Se desea modificar un elemento existente en el sistema.
Página 135
ANEXO: Plantillas
ELIMINACIÓN
Escenario: Se desea eliminar un elemento existente en el sistema.
Página 136
ANEXO: Plantillas
BÚSQUEDA
Escenario: Se desea buscar un elemento existente en el sistema.
Página 137