Tesis APPI - Java

UNIVERSIDAD NACIONAL DE RÍO CUARTO
FACULTAD DE CIENCIAS EXACTAS, FÍSICO-QUÍMICAS Y NATURALES
TRABAJO FINAL PARA OPTAR AL TÍTULO DE

ANALISTA EN COMPUTACIÓN
Sistema para la Administración de Programas y Proyectos de

Investigación coordinados por la Secretaría de Ciencia y Técnica de la
Universidad Nacional de Río Cuarto.
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.
Un agradecimiento especial de todo corazón a nuestras familias, por su amor, cariño,

paciencia y comprensión durante la realización de este trabajo. Siempre nos alentaron a seguir
adelante a pesar de las dificultades personales que se nos presentaron. A ellos, dedicamos el mismo.
Un sincero agradecimiento a todos nuestros amigos y compañeros de trabajo que nos

brindaron su apoyo compartiendo su tiempo, conocimientos y experiencias.
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.
A todos muchas gracias.

INDICE
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.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.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.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.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.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.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.
La Secretaría de Ciencia y Técnica de la Universidad Nacional de Río Cuarto fue creada en el

año 1981, asignándole la misión de atender las relaciones de la Universidad con otras instituciones,
entidades u organismos oficiales y privados que organicen, promuevan y financien el desarrollo de la
investigación científico y técnico, apoyando proyectos y actividades cuya finalidad es la generación de
nuevos conocimientos, tanto en temáticas básicas como aplicadas. Entre sus funciones se destacan:
 Coordinar la elaboración y presentación de proyectos de investigación.

 Supervisar la inversión del presupuesto de Ciencia y Tecnología.
 Supervisar el cumplimiento de convenios con otros organismos, y administrar los subsidios,
destinados a financiar los proyectos de investigación, en el marco de los planes y programas
establecidos para el sector de Ciencia y Tecnología.
En lo que a proyectos de investigación se refiere, actualmente esta Secretaría administra y

controla proyectos que pueden ser financiados con fondos propios, fondos de organismos externos y
también cofinanciados, entre la Universidad y algún organismo externo. También administra y
controla becas y programa de incentivos.
El presente trabajo es un proyecto de tesis para optar al título de Analista en Computación, el

cual tiene como objetivo informatizar el manejo de la información con la cual trabaja esta Secretaría.
1.1. Motivación
El aumento constante en la cantidad y diversidad de proyectos de investigación que hoy

administra y controla esta Secretaria, trae aparejado problemas administrativos y de gestió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.
1.2. Objetivo Principal
Proponemos la creación de un sistema de software que aporte funcionalidad, transparencia y

seguridad en el seguimiento de los Proyectos de Investigación que mantiene la Secretaría de Ciencia
y Técnica de la UNRC, financiados con recursos propios o con recursos provistos por organismos
externos. El sistema deberá permitir una eficiente administración presupuestaria y financiera de
dichos Proyectos. Además, el sistema manejará las cuentas bancarias de la Secretaría.
La centralización de la información permitirá el análisis pormenorizado, tanto financiero como

presupuestario, al detalle de cada proyecto y de cada una de sus etapas, y de todo lo acontecido con
los recursos destinados a los mismos. Esta información es de suma utilidad para una gestión
dinámica, eficaz, y eficiente favoreciendo la toma de decisiones. Los beneficios no sólo serán
inmediatos a la implementación, sino que también traerá beneficios a mediano y largo plazo,
permitiendo analizar y estudiar comportamientos de variables que hoy no están disponibles, como por
ejemplo, todo tipo de información estadística que se pueda deducir como consecuencia de un
Página 1
Introducción
almacenamiento histórico, detallado, y seguro de datos que hacen a las ejecuciones de proyectos de
investigación.
1.3. Organización de este trabajo
El presente trabajo está organizado de la siguiente manera:
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
2. DESCRIPCION DEL NEGOCIO

La Secretaría de Ciencia y Técnica dependiente de la UNRC, es la encargada de realizar las
tareas de promoción y coordinación de la investigación científica y técnica. Para ello, tiene como
responsabilidad la coordinación de las propuestas (Proyectos, Programas, etc.) presentadas por los
distintos investigadores.
Las propuestas se receptan cuando se abre un llamado a presentación de programas y

proyectos de investigación, denominado convocatoria, las que deberán ajustarse a las bases que la
reglamenta.
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.
Todas las propuestas que se presentan a una convocatoria en particular, se someten a

evaluaciones científicas para su aprobación.
La Secretaría debe registrar todas las propuestas presentadas, para posteriormente

administrar y controlar las propuestas admitidas.
En la actualidad existen varias líneas de proyectos y programas vigentes:
Proyectos y Programas Financiados con Presupuesto Propios
PPI: Programas y Proyectos de Investigación.
PIIMEG: Proyectos de Innovación e Investigación para el mejoramiento de la Enseñanza de Grado.
IP: Ideas Proyectos.
Proyectos y Programas Financiados con Presupuestos de Organismos Externos, o Co-Financiados
PICTO: Proyectos de Investigación Científica y Técnica Orientados.
PICT: Proyectos de Investigación Científica y Tecnológica.
PID: Proyectos de Investigación y desarrollo.
El llamado a Convocatoria para presentar proyectos y programas de investigación es

realizado por alguno de los organismos que aportan los fondos para ello.
Cuando la Universidad, por intermedio de la Secretaría de Ciencia y Técnica llama a

convocatoria a los docentes investigadores, establece en su normativa los plazos para desarrollar las
investigaciones, (“vigencia de la convocatoria”), plazos para presentar las propuestas, (“fechas de
apertura y cierre de presentación”), áreas y temas prioritarios, las modalidades aceptadas
(“Proyectos, Programas, Proyectos de Fomento, etc.”), categorías a las que pueden pertenecer los
Proyectos, condiciones de admisibilidad (“condicionamientos a los proyectos, directores, co-
directores, integrantes, etc..”), rubros que se financian, restricciones sobre los rubros, como montos
máximos, etc. Las presentaciones deben hacerse ante las áreas responsables de las facultades y
deben contar con el aval del decano de la facultad a la cual pertenece el director del proyecto o
programa.
Una vez cerrada la convocatoria a presentación, las propuestas son sometidas a

evaluaciones para determinar su admisibilidad.
Una convocatoria establece una cantidad de Proyectos y Programas a financiar. También

define modalidades de Proyectos y Programas de acuerdo a como están organizados. Por ejemplo
los proyectos organizados y ejecutados por equipos de trabajo dedicados a generar conocimiento
científico y tecnológico en un área o disciplina, y los programas, que están organizados sobre la base
Página 3
Descripción del Negocio
de proyectos articulados para tratar una problemática interdisciplinariamente.
De acuerdo a cómo se realizan las actividades de investigación de los Proyectos y

Programas, se definen categorías. Por ejemplo aquellos que realizan actividades experimentales de
campo y/o laboratorio y aquellos que no incluyen actividades experimentales. Dichas categorías
pueden tener subcategorías.
Dentro de una convocatoria se fija un monto máximo de crédito, de acuerdo a las diferentes
categorías y modalidades.
Un Proyecto o Programa tiene un presupuesto de gastos por cada año de ejecución, a

excepción de aquellos en los que el plazo es menor al año, para éstos, se tiene un único
presupuesto. Este presupuesto incluye el conjunto de rubros en los cuales dicho Proyecto o
Programa puede gastar el monto que se le ha asignado.
Los responsables de programas o proyectos solicitan adelantos de dinero que no superen el

saldo financiero. Estos, deben ser rendidos a través de comprobantes de gastos, como pueden ser
facturas, pago de becas, viáticos.
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
3. METODOLOGIA UTILIZADA: Proceso Unificado de Desarrollo de Software

La necesidad de la construcción de softwares grandes y complejos que se adapten mejor a
las necesidades del usuario, hacen necesario utilizar un proceso que integre las múltiples facetas del
desarrollo y que proporcione una guía para ordenar las actividades de un equipo. La presencia de un
proceso bien definido y bien gestionado es una diferencia esencial entre proyectos productivos y otros
que fracasan.
El Proceso Unificado de Desarrollo de Software [1] es el conjunto de actividades necesarias

para transformar los requisitos de un usuario en un sistema de software. Es un marco de trabajo
genérico que puede especializarse para una gran variedad de sistemas de software, para diferentes
áreas de aplicación, diferentes tipos de organizaciones y diferentes tamaños de proyecto.
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.
Construcción: Se crea el producto, es decir se añade el software terminado a la arquitectura.
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.
En la Captura de Requerimientos se construyen dos artefactos:
 Modelo de Negocio: estudia el negocio donde se implementará el sistema.

 Modelo de Casos de Uso: especifica y describe las funcionalidades del sistema.
4.1. Modelo de Negocio
El Modelo de Negocio establece una abstracción de la organización. Nos permite comprender

los procesos de negocio de la organización, entender su estructura y dinámica, entender los
problemas corrientes, las posibles mejoras, asegurar a los clientes, usuarios y desarrolladores que
tengan una compresión común de la organización, derivar los requisitos del sistema necesarios para
soportar la estructura y dinámica de la misma.
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.
4.1.1 Modelo de Dominio

El modelo de dominio permite establecer el contexto del sistema. Su objetivo es comprender y
describir las entidades más importantes del mismo.
Para una mejor visualización dividimos el modelo de dominio en tres partes que reflejan
distintos aspectos del contexto del sistema:
Vista de convocatorias y proyectos: Ver Figura Nº 4.1
Vista de ejecución presupuestaria: Ver Figura Nº 4.2
Vista bancaria: Ver Figura Nº 4.3.
4.1.2 Reglas de Negocio

Las reglas de negocio especifican políticas o condiciones que restringen el comportamiento y
la estructura del negocio. Definen una restricción o invariante que el negocio debe satisfacer. Se
describen en lenguaje natural o en lenguaje formal. Generalmente, UML utiliza un lenguaje de
restricción de objetos denominado OCL (Object Constraint Language), pero puede resultar dificultoso
de interpretar. Por ello utilizamos un conjunto de palabras reservadas que utilizamos para definir las
reglas de nuestro negocio.
En el contexto de nuestro sistema se han definido las siguientes reglas de negocio:
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
Figura Nº 4.1 – Modelo de Dominio – Vista de convocatorias y proyectos
Página 7
Figura Nº 4.2 – Modelo de Dominio – Vista de ejecución presupuestaria
Página 8
Figura Nº 4.3 – Modelo de Dominio – Vista

bancaria
3. IT MUST ALWAYS HOLD THAT los miembros de un proyecto, el cual es parte de un
programa, no podrán ser miembros de otro proyecto que sea parte del mismo programa.
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.
9. IF el proyecto es un Proyecto de Fomento THEN no podrá contar con la figura de co-director.
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
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.
4.1.3 Glosario de términos del Negocio

El glosario define los términos importantes usados en el modelo de negocio. La definición
dada a cada término debe ser única y consistente durante todo el proyecto. En el contexto de nuestro
sistema se definen los siguientes términos:
Convocatoria: Llamado a presentación de propuestas de un tipo determinado. Normativa que

describe las características particulares para el presente llamado. Las convocatorias pueden ser
implementadas por la Universidad, o por Organismos externos, ya sea en conjunto con la Universidad
o utilizando a ésta como órgano administrativo.
Proyecto: Organizados y ejecutados por equipos de trabajo dedicados a generar conocimientos
científicos y tecnológicos con la posibilidad de aplicación y transferencia en temas acotados a un área
o disciplina.
Programa: Estarán organizados sobre la base de proyectos articulados que se desarrollen alrededor
de un área problema o de una problemática tratada interdisciplinariamente.
Proyecto de Fomento: Son aquellos que están destinados a promover grupos de trabajo en
formación o en etapa de desarrollo inicial.
PPI: Proyectos y Programas de Investigación.
PIIMEG: Proyectos de Innovación e investigación para el Mejoramiento de la enseñanza de Grado.
IP: Ideas Proyectos.PICTO: Proyectos de Investigación Científica y Técnica Orientados.
PICT: Proyectos de Investigación Científica y Tecnológica.
PID: Proyectos de Investigación y Desarrollo.
Modalidad: Describe las distintas modalidades que implementa una Convocatoria pudiendo ser
Proyectos, Programas, Proyectos de Fomentos y otras...
Categoría: Describe las Categorías en la que los proyectos pueden participar en una Convocatoria.
Por Ejemplo Los Proyectos que tienen actividades de campo o laboratorio pertenecen a una
categoría, y los que no tienen este tipo de actividades pertenecen a otra.
Área: Describe las Áreas temáticas Prioritarias en las que se desarrollaran los proyectos de una
Convocatoria. Para cada Convocatoria La Universidad definirá las áreas temáticas prioritarias o
excluyentes.
Tema: Temas Prioritarios dentro de un Área específica. Definidas para el llamados a Convocatoria.
Disciplina: Código y descripción de la Disciplina asociada a un Proyecto. La misma se rige por
nomenclador Nacional.
Campo de Aplicación: Código y descripción del campo de aplicación en el que se encuadra el
proyecto. El mismo se rige por nomenclador Nacional.
Rubro: Describe en qué se invertirá el dinero obtenido para el proyecto.
Proyecto: Describe las tareas de investigación que se desarrollarán.
Programa: Un Programa es una asociación de proyectos con uno o más objetivos comunes.
Administrativamente tiene el mismo comportamiento que los proyectos.
Saldo Financiero: Es el monto del cual disponen los integrantes de cada proyecto o programa para
sus gastos, deducido del monto total otorgado menos los adelantos realizados.
Saldo Presupuestario: Es el monto del cual disponen los integrantes de cada proyecto o programa
para gastar en cada rubro, deducido del monto total asignado al rubro menos el importe ya gastado
en el mismo.
Página 10
Rendición: Es el acto donde un responsable de proyecto o programa presenta un comprobante de

gasto.
Ejecución Presupuestaria: Son las rendiciones, adelanto y devolución de dinero de los
presupuestos de Proyectos y Programas.
4.1.4 Modelo de Casos de Uso de negocio

El modelo de casos de uso de negocio representa las funciones más importantes del negocio.
Facilita la identificación de roles y responsabilidades de los miembros del 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.
4.1.4.1 Casos de uso de negocio

Los distintos Casos de uso de Negocio están expresados mediante una descripción textual y
para aquellos que consideramos más complejos de comprender además de la descripción, utilizamos
diagramas BPD (Business Process Diagram), siguiendo la notación de modelado de casos de uso del
negocio BPMN (Bussiness Process Management Initiative) [3]. Este modelo provee una notación
entendible para el analista del negocio, el desarrollador técnico y hasta las personas propias del
negocio. Describe las tareas que realiza cada participante en el proceso, así como su ordenación
temporal y el intercambio de mensajes con entidades externas. Crea un puente estandarizado entre
el diseño de procesos de negocio y su implementación.
Casos de uso de Negocio
 Confección de una convocatoria

 Presentación y Evaluación de propuestas
 Solicitud de adelantos
 Rendición de gastos
 Reformulación de presupuesto
Descripción de los casos de uso del negocio

Confección de una convocatoria
El o los entes financieros, fijan las bases para la convocatoria, estableciendo su tipo (PPI, PIIMEG,
PICTO, etc.), plazos de apertura y cierre del actual llamado, áreas y temas prioritarios, modalidades y
categorías de propuestas, admisibilidad, evaluación, financiación, formas de presentación y rubros.
Posteriormente otorga a la Secretaría de Ciencia y Técnica la administración de la misma. Ésta a
través del encargado administrativo promociona e implementa dicha convocatoria.
Presentación y Evaluación de propuestas

Los Responsables de los proyectos presentan propuestas para su evaluación. La secretaría por
medio de una comisión evalúa la admisibilidad de las propuestas presentadas. La secretaría
comunica a los responsables el resultado de la evaluación. Si la propuesta es admitida, el encargado
administrativo inicia el seguimiento y control administrativo de dicha propuesta, pudiendo, los
responsables, iniciar la ejecución de las actividades de investigación. En caso de ser rechazada, el
encargado administrativo registra y archiva, el resultado de la evaluación.
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
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.
4.1.4.2 Actores del negocio

Los actores del negocio son las personas que se relacionan con los procesos de negocio y
son los siguientes:
 Ente financiero
 Secretaría de Ciencia y Técnica
 Encargado Administrativo
 Encargado Contable
 Responsable de Proyecto ó Programa
Descripción de los actores de Negocio

Ente financiero: Organismo que financia los proyectos de investigación de una Convocatoria. Una
Convocatoria puede ser financiada por un Organismo Ej.: (UNRC para los PPI), o bien Co-financiados
por dos o más Organismos.
Secretaría de Ciencia y Técnica: Secretaría dependiente de la UNRC encargada de realizar las
tareas de promoción y coordinación de la investigación científica y Técnica. Para ello tiene como
responsabilidad la coordinación de las propuestas (Proyectos, Programas, etc.) presentadas por los
distintos investigadores.
Encargado Administrativo: Persona empleada por la UNRC que trabaja en la Secretaría de Ciencia
y Técnica que realiza tareas de administración de la presentación, evaluación de los Proyectos y/o
Programas.
Encargado Contable: Persona empleada por la UNRC que trabaja en la Secretaría de Ciencia y
Técnica que realiza tareas de administración contable de los Proyectos y/o Programas.
Responsable de Proyecto o Programa: Persona que dirige un Proyecto o Programa de
Investigación
Diagrama de Casos de Uso del Negocio
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
Figura Nº 4.4 – Caso de Uso de Negocio – Solicitud de Adelanto
Página 13
Figura Nº 4.5 – Caso de Uso de Negocio – Rendición de Gastos
Página 14
Figura Nº 4.6 – Caso de Uso de Negocio – Reformulación de Presupuesto
Página 15
Figura Nº 4.7 – Modelo de Casos de Uso de Negocio
4.2. Modelo de Casos de Uso de Negocio
El Modelo de Casos de Uso, permite a clientes y desarrolladores acordar en los

requerimientos del sistema. Es usado y refinado en las sucesivas etapas del desarrollo del sistema.
(Captura de Requerimientos, Análisis, Diseño, Implementación, Prueba).
Los casos de uso representan las funcionalidades o comportamiento del sistema, los actores
representan los usuarios del mismo.
Los artefactos del Modelo de Casos de Uso son los siguientes:

 Actores: usuarios que requieren del uso de las funciones del sistema
 Casos de Uso: funcionalidades que brindan algún resultado de valor para uno o más
actores.
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:
Actores del Negocio Actores del Sistema

Ente Financiero Encargado Contable
Secretaría de Ciencia y Técnica Encargado Administrativo
Encargado Administrativo
Encargado Contable
Responsable del Proyecto o Programa
4.2.2 Casos de Uso

Para encontrar los Casos de Uso debemos identificar las funcionalidades del sistema, a partir
de: modelo de dominio, casos de uso del negocio, reglas del negocio, glosario de términos, y otros
requisitos solicitados.
Casos de Uso del Sistema a partir de los Casos de Uso de Negocio

Para cada caso de uso de negocio se observa su descripción y diagrama de BPD
correspondiente en caso de tenerlo, y de cada actividad ó conjunto de actividades se decide qué se
puede automatizar siempre que se resuelvan problemas y se mejore el negocio. Ver Figuras Nº 4.8 y
Nº 4.9.
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
Figura Nº 4.8 – Realización de Casos de Uso de Negocio a Casos de Uso del Sistema
Página 17
Figura Nº 4.9 – Realización de Casos de Uso de Negocio a Casos de Uso del

Sistema
Figura Nº 4.10 – Casos de Uso del Sistema
Página 18
4.2.2.1 Diagrama de Casos de Uso del Sistema

A continuación se visualiza el diagrama de casos de uso del sistema relacionados con sus
respectivos actores. Ver Figura Nº 4.11-A y Nº 4.11-B.
Figura Nº 4.11-A – Diagrama de casos de uso de sistema relacionados con el Encargado

Administrativo
Figura Nº 4.11-B – Diagrama de casos de uso de sistema relacionados con el Encargado

Contable
En los diagramas siguientes mostraremos los casos de uso del sistema y las relaciones que
existen entre ellos. En estos diagramas hemos dispuesto no graficar los actores para tener una mejor
visualización de cada uno de los diagramas, pero se puede consultar la Figura Nº 4.11-A y Nº 4.11-B
para ver los actores relacionados a los mismos.
Gestión Convocatoria: Ver Figura Nº 4.12.

Gestión Proyecto/Programa: Ver Figura Nº 4.13. Este diagrama sirve para reflejar las relaciones de
los casos de uso de Gestionar Proyecto como el de Gestionar Programas. Tener en cuenta que en el
Página 19
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.
Figura Nº 4.12 – Relaciones entre casos de uso - Gestión de convocatoria
Página 20
Figura Nº 4.13 – Relaciones entre casos de uso - Gestión Proyecto y Gestión Programa
Figura Nº 4.14 – Relaciones entre casos de uso - Gestión Presupuesto
Página 21
Figura Nº 4.15 – Relaciones entre casos de uso - Gestión viático y Gestión

Factura
Página 22
Figura Nº 4.16 – Relaciones entre casos de uso – Gestión Beca y Solicitud y Devolución de Adelantos
Figura Nº 4.17 – Relaciones entre casos de uso - Gestión Genérico
4.2.2.2 Clasificación de Casos de Uso en iteraciones

Teniendo en cuenta la captura de requerimientos realizada y pudiendo tener una primera
visualización de la envergadura del sistema, se resolvió separar los casos de uso en las siguientes
iteraciones.
Página 23
4.2.2.2.1 Casos de uso de la primera iteración

Para esta primera iteración se consideró importante la realización de los casos de uso que
están relacionados con el caso de uso Gestionar Convocatoria, el cual consideramos el eje del
sistema, ya que la mayoría de los demás casos de usos, dependen de la implementación del mismo.
Dichos casos de uso son los siguientes:
 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
4.2.2.2.2 Casos de uso de la segunda iteración

En esta segunda etapa, donde se tendría especificado e implementado el caso de uso
Gestionar Convocatoria, que es la base desde la cual parte el sistema, se resolvió continuar con
todos los casos de uso que impliquen la administración de Proyectos y Programas de una
convocatoria. Dichos casos de uso son los siguientes:
 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
4.2.2.2.3 Casos de uso de la tercera iteración

Para esta tercera etapa, se resolvió seguir con los casos uso que tienen que ver con
administración contable de los presupuestos de los proyectos y programas, ya que suponen un mejor
entendimiento del sistema en su totalidad, además de necesitar previamente la especificación de los
demás casos de uso del sistema para poder realizarlos. Dichos casos de uso son los siguientes:
 Solicitud y Devolución de Adelantos

 Gestión Movimiento de Cuenta
 Gestión Viatico
 Gestión Beca
 Gestión Factura
 Gestión Proveedor
4.2.2.3 Casos de uso Genéricos

La descripción de cada caso de uso se torna una actividad repetitiva y tediosa cuando el
comportamiento es similar en muchos de los casos e independiente del elemento. Es por ello, que las
plantillas utilizadas son un patrón que da una solución general a problemas de inserción, eliminación,
modificación y búsqueda de un elemento [4] [5].
La utilización de dichas plantillas nos permite:
Página 24
- 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:
 Eliminar y Buscar Convocatoria

 Eliminar y Buscar Presupuesto
 Eliminar y Buscar Proyecto/Programa
 Modificar, Eliminar y Buscar Beca
 Modificar, Eliminar y Buscar Viático
 Modificar, Eliminar y Buscar Factura
 Gestión Rubro
 Gestión Tipo de Proyecto
 Gestión Cargo
 Gestión Banco
Página 25
Primera Iteración – Descripción de Casos de Uso
5. PRIMERA ITERACION
5.1. Descripción de casos de usos del Sistema
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.
5.1.1 Descripción de casos de uso

Nombre: Alta de Convocatoria
Pre-condición: Existe una nueva convocatoria a ser ingresada
Post-condición: La convocatoria queda registrada en el sistema o la convocatoria ya estaba
registrada en el sistema
Descripción: Realiza la inserción de una nueva convocatoria
Encargado Administrativo SISTEMA

1. Ingresa el nombre de la Convocatoria y
datos restantes
2. Selecciona Tipo de Proyecto
3.Verifica si existe la Convocatoria
4. Registra la convocatoria
2.1 Si no existe el tipo de proyecto. Termina
3.1 Si existe la Convocatoria, el sistema informa de su existencia. Termina
Nombre: Modificación de Convocatoria

Pre-condición: Existe una convocatoria a ser modificada
Post-condición: La modificación de la convocatoria queda registrada en el sistema.
Descripción: Realiza la modificación de una convocatoria incluyendo la regla de negocio R14

1. Muestra todas las convocatorias existentes.
2. Selecciona Convocatoria a ser
modificada
3. Muestra los datos de la convocatoria
4. Modifica datos principales de la
convocatoria (fecha de apertura, fecha de
cierre, fecha de ejecución, plazo de
ejecución, mínimo exigible, tipo de
proyecto, monto)
5. Selecciona las modalidades asociadas
6. Elimina una modalidad asociada o asocia una
nueva, include (Buscar Modalidad)
7. Selecciona las categorías asociadas
8. Elimina una categoría asociada o asocia una nueva,
include(Buscar Categoría)
9. Selecciona los límites de crédito según
categoría y modalidad.
Página 26
10. Elimina, modifica o ingresa un nuevo límite de

crédito,
11. Selecciona las Áreas y temas
prioritarios asociadas
12.Elimina un área asociada o asocia una nueva,
include(Buscar Área y Temas prioritarios)
13. Selecciona los Entes Financieros
asociados y modifica porcentaje de
financiación.
14. Elimina un Ente Financiero asociado o asocia uno
nuevo con su porcentaje.
15. Selecciona los rubros asociados y/o
ingresa porcentaje de financiación por
cada uno de los subrubros pertenecientes
a cada rubro..
16. Elimina un rubro asociado o asocia uno nuevo,
include(Buscar Rubro), ingresando el porcentaje de
financiación de cada subrubro perteneciente al mismo,
include(Buscar Subrubro). Tener en cuenta la regla de
negocio R14
17. Selecciona cuenta de Banco asociada
18. Elimina la cuenta de Banco asociada o asocia una
nueva, include(Buscar Cuenta)
19. Registra la actualización de la convocatoria
6.1 Si no existe alguna modalidad, extend (Alta Modalidad).
8.1 Si no existe alguna categoría, extend (Alta Categoría).
12.1 Si no existe algún área y tema prioritario, extend (Alta Área y Tema prioritarios).
5.1.2 Descripción de Casos de Uso utilizando plantillas Genéricas

A continuación se detallan las instanciaciones de las plantillas genéricas [4] para los casos de
uso de nuestro sistema de la primera iteración, que se comportan de manera genérica y que refieren
a problemas de inserción, modificación, eliminación y búsqueda, que serán tratados de manera
genérica. Estos casos de uso son:
 Eliminar y Buscar Convocatoria

 Gestión Rubro
 Gestión Tipo de Proyecto
 Gestión Banco
Página 27
Página 28
Página 29
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.
Los artefactos de esta etapa son los siguientes:
 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.
o Paquetes de Análisis: Permiten organizar el modelo de análisis en piezas más

manejables. Pueden contener realizaciones de Casos de Uso, Clases de Análisis y
otros paquetes de Análisis.
o Realizaciones de Casos de Uso: Descripción de la realización de cada caso de uso
en término de clases de análisis y la interacción entre objetos de análisis.
o Clases de Análisis: Representan una abstracción de una o varias clases y/o
subsistemas en el diseño del sistema. Para cada clase identificada se debe
determinar su nombre, responsabilidades, atributos y relaciones. Pueden ser las
siguientes:
 Clases Límite: Modelan interacción entre el sistema y sus actores.

 Clases Entidad: Modelan la información persistente.
 Clases Control: Representan coordinación, secuenciamiento, transacciones
y control de objetos.
 Descripción de la Arquitectura: Contiene una vista arquitectónica del Modelo de Análisis

mostrando sus artefactos más significativos.
A continuación se muestran las clases de análisis obtenidas a partir de las descripciones,

definiendo los nombres, atributos y responsabilidades de las mismas. Se desarrollan los diagramas
de clases de análisis con el fin de describir las relaciones entre las clases y se representan
escenarios significativos a partir de diagramas de comunicación.
5.2.1 Caso de Uso: Alta Convocatoria
Clases Nombre Atributos Responsabilidades

UI_Convocatoria Verificar correctitud del
Interfaz
formato de los datos
Control_Gestion_Convocatoria Verificar si existe la
convocatoria.
Buscar los datos principales
necesarios para la
convocatoria y el tipo de
Proyecto para esta
Control
convocatoria.
Registra la Convocatoria.
Control_Gestion_TipoProyecto Obtiene todos los tipos de

proyectos existentes.
Convocatoria nombre
fecha_ini_pren
fecha_fin_pren
Entidad plazo_duración
monto_total_financ
minimo_exigible
tipoProyecto
Página 31
5.2.1.1 Diagrama de Clases de Análisis del caso de uso Alta Convocatoria

El diagrama de clases de Análisis del caso de uso Alta Convocatoria se puede apreciar en la
Figura Nº 5.1.
Figura Nº 5.1 – Diagrama de Clases de Análisis – Alta Convocatoria
5.2.1.2 Diagrama de Comunicación del caso de uso Alta Convocatoria

Los diagramas de comunicación destacan la organización estructural de los objetos que
participan en una interacción, es decir, objetos que envían y reciben mensajes. Estos diagramas se
utilizan para modelar los aspectos dinámicos de un sistema. A continuación se plantea un escenario
para el caso de uso Alta Convocatoria:
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.
5.2.2 Caso de Uso: Modificar Convocatoria

UI_Convocatoria Verificar correctitud del formato de los
Interfaz
UI_BuscarConvotaria datos
Control_Gestion_Convocatoria Buscar los datos a modificar de la
convocatoria.
Guardar modificaciones.
Interactuar con los siguientes casos de
uso:
 Buscar Modalidad
 Alta Modalidad
 Buscar Categoría
 Alta Categoría
 Buscar Área y Temas
Control Prioritarios
 Alta Área y Temas Prioritarios
 Buscar Ente Financiero
 Buscar Rubro
 Buscar Subrubro
 Buscar Cuenta Banco
Control_Gestion_TipoProyecto Lista los tipos de proyectos existentes

Control_Gestion_Modalidad Verificar si existe la modalidad.
Registrar la modalidad.
Página 32
Control_Gestion_Categoría Verificar si existe categoría

Registrar categoría.
Control_Gestion_AreaTemasPrioritarios Verificar si existe el área y
tema prioritario.
Registrar el Área.
Contro_Gestion_Rubro Verificar existencia de
Rubros.
Contro_Gestion_Subrubro Verificar existencia de
Subrubros.
Control_Gestion_CuentaBanco Verificar existencia de la
Cuenta del Banco.
Control_Gestion_EnteFinanciero Verificar si existe ente
financiero.
Convocatoria nombre
fecha_ini_pren
fecha_fin_pren
plazo_duración
monto_total_financ
minimo_exigible
modalidad
Entidad
categoría
limite_credito
areas-
temas_prioritarios
entes_financieros
rubros
cuenta_banco
5.2.2.1 Diagrama de Clases de Análisis del caso de uso Modificar Convocatoria

El diagrama de clases de Análisis del caso de uso Modificar Convocatoria se puede apreciar
en la Figura Nº 5.2.
Figura Nº 5.2 – Diagrama de Clases de Análisis – Modificar Convocatoria
5.2.2.2 Diagramas de Comunicación del caso de uso Modificar Convocatoria

Escenario: Se desea modificar los límites de crédito según la modalidad y categoría de una
convocatoria existente. La convocatoria ya tiene modalidades y categorías asociadas. Ver Figura Nº
5.4
Página 33
Figura Nº 5.3 – Modelo de Análisis – Diagrama de Colaboración de Alta Convocatoria
Página 34
Figura Nº 5.4 – Modelo de Análisis – Diagrama de Colaboración de Modificar Convocatoria
Página 35
5.2.3 Análisis de Casos de Uso utilizando Plantillas Genéricas de Análisis

A continuación se detallan las instanciaciones de las plantillas de análisis [5], para los casos
de uso de esta iteración, que se comportan de manera genérica y que refieren a problemas de
inserción, modificación, eliminación y búsqueda (Gestión Elemento).
Página 36
Primera Iteración – Diseño e Implementación de Casos de Uso
5.3. Diseño e Implementación
En esta sección explicamos en forma conjunta la etapa de diseño e implementación. Para

ello, al comienzo se hace una breve descripción de ambas etapas seguida de la descripción de la
arquitectura y tecnologías utilizadas en el desarrollo de este sistema.
Etapa de Diseño
La entrada fundamental de la etapa de Diseño es el Modelo de Análisis. Aquí se adquiere

mayor comprensión en cuanto a los requerimientos no funcionales, como el lenguaje de
programación, sistema operativo, componentes de reúso, distribución y concurrencia, tecnologías de
interface-usuario.
Esta focalizado sobre el final de la fase de elaboración e inicio de la construcción. Se logra
una arquitectura estable y es la base fundamental para la implementación.
Los artefactos en la etapa de diseño son:
 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.
Clase de diseño: es una abstracción de una clase en la implementación del sistema.

Realización de casos de uso-diseño: es una colaboración en el modelo de diseño
que describe como se realiza un caso de uso específico y como se ejecuta, en
términos de clases de diseño y sus objetos.
 Subsistema de diseño: provee una manera de organizar los artefactos del modelo
de diseño en piezas más manejables.
 Modelo de despliegue: es un modelo de objetos que describe la distribución física del sistema
en términos de cómo se distribuye la funcionalidad entre los nodos de cómputos.
Trabajadores:
 Arquitecto: es responsable de la integridad de los modelos de diseño y de despliegue,

garantizando que los modelos son correctos, consistentes y legibles en su totalidad.
 Ingeniero de casos de uso: es responsable de la integridad de una o más realizaciones de
casos de uso, y debe garantizar que se cumplan los requisitos que se esperan de ellos.
 Ingeniero de componentes: define y mantiene las operaciones, métodos, atributos, relaciones y
requisitos de implementación de una o más clases del diseño, garantizando que cada clase de
diseño cumple con los requisitos que se esperan de ella según las realizaciones de cada caso de
uso. Además mantiene la integridad de uno o más subsistemas.
Actividades:
 Diseño arquitectónico: contorno de los modelos de diseño y de despliegue. Considera varias

posibilidades de reutilización:
 Identificar nodos y configuraciones de redes (cliente/servidor)

 Identificar subsistemas y sus interfaces.
 Identificar persistencia, distribución y seguridad
 Realización de cada caso de uso:

o Identificamos las clases de diseño a través de la realización de clases de análisis a clases de
diseño.
o Realizamos diagramas de Clases de Diseño para cada caso de uso.
o A partir de los escenarios planteados en el análisis y los diagramas de colaboración, se
realiza la interacción entre los objetos a través de Diagramas de Secuencia.
 Clase:
o Identificar operaciones
Página 37
o Identificar relaciones entre clases
Etapa de Implementación
El resultado principal de la implementación es el modelo de implementación, el cual es una

jerarquía de subsistemas de implementación que contienen componentes e interfaces.
En la implementación se empieza con el resultado del diseño y se implementa el sistema en

términos de componentes. El propósito fundamental es desarrollar la arquitectura y el sistema como
un todo.
Los objetivos de la implementación son:
 Planificar las integraciones del sistema necesarias en cada iteración.

 Distribuir el sistema asignando componentes ejecutables a los nodos en el diagrama de
despliegue.
 Implementar las clases y subsistemas encontrados durante el diseño
 Probar los componentes individualmente y a continuación integrarlos compilándolos y
enlazándolos en uno o más ejecutables.
Los artefactos de esta etapa son: Modelo de implementación, Componente Subsistema de

implementación, Interfaz, Descripción de la arquitectura
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.
5.3.1 Descripción de la Arquitectura

La arquitectura de un sistema de software se desarrolla en base a los requerimientos
funcionales y no funcionales del mismo. A continuación presentamos una breve descripción de los
componentes que conforman la arquitectura de nuestro sistema, como lo son, patrones de diseño,
arquitectura cliente/servidor y tecnologías aplicadas, para luego presentar el modelo de diseño de
nuestra aplicación utilizando dichos componentes.
5.3.1.1 Arquitectura Cliente/Servidor

La arquitectura cliente/servidor consiste de una o más aplicaciones clientes que realizan
solicitudes o peticiones a una o más aplicaciones servidores. Estos dos conjuntos de aplicaciones se
comunican entre sí a través de un protocolo en común. El cliente es quien inicia la comunicación
solicitando datos al servidor, quien está a la espera de solicitudes entrantes. Al recibir cada una de las
peticiones, procesa los datos necesarios y las envía a quien las solicitó.
El lenguaje de programación escogido para implementar el sistema es Java, el cual provee

mecanismos propios para soporte de arquitecturas cliente/servidor. Este mecanismo es RMI (Remote
Method Invocation), el cual permite realizar llamadas a métodos de objetos remotos situados en
distintas (o la misma) máquinas virtuales de java, compartiendo así recursos y carga de
procesamiento.
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.
La utilización de este mecanismo en la práctica, implica tener en cuenta los siguientes

aspectos:
Página 38
 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.
Un objeto se convierte en remoto implementando un interface remoto, que tenga estas

características:
 Un interface remoto desciende del interface java.rmi.Remote.
 Cada método del interface declara que lanza una excepción de tipo
java.rmi.RemoteException además de cualquier excepción específica de la aplicación.
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
Figura Nº 5.5 – Interface remota y clase que implementa sus métodos
5.3.2 Persistencia de objetos

La persistencia de objetos es uno de los temas más importantes en el diseño e
implementación de sistemas y una de las tareas que mayor esfuerzo conllevan.
La solución escogida en este sistema, en lo que ha persistencia de objetos se refiere, es el

uso del estándar JDO (Java Data Object) [6]. Este es el estándar de la comunidad Java que define
las interfaces y clases para manejar las clases del dominio (objetos de negocio y de aplicación),
cuyas instancias tienen que persistir, y especifica los contratos entre proveedores de clases con
capacidad de perdurar sus instancias, y el entorno de ejecución que es parte de la propia
implantación de JDO.
Página 39
Dado que JDO es sólo la especificación de interfaces y no su implementación, es necesario

utilizar alguna implementación disponible. En este sistema, la opción elegida como implementación
de JDO es JPOX (Java Persistent Objects) [7], el cual cumple con los estándares JDO1, JDO2 y
JDO2.1.
La implementación JPOX se basa en archivos de extensión XML, en los cuales de da la

definición de los objetos que deben ser persistentes y las relaciones entre sí. En base a estos
archivos, se generan todos los objetos necesarios a nivel de base de datos como son las tablas,
vistas, etc. JPOX provee soporte para los sistemas de base datos más populares como MySQL,
Oracle, etc.
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.2.1 Consideraciones especiales

Si bien casi toda la información de los objetos persistentes está definida en los archivos XML
correspondientes, cabe aclarar que además existen algunas funciones definidas fuera de estos,
directamente sobre el motor de base de datos. Esto, aunque implica depender del motor de base de
datos escogido, permite definir funcionalidades que simplifican de manera sustancial la programación.
5.3.3 Patrones de Diseño

Los patrones de diseño [8] son soluciones reusables a problemas recurrentes que ocurren
durante el desarrollo de software. En nuestro sistema identificamos algunos problemas de diseño
para los cuales aplicamos los siguientes patrones de diseño:
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
Figura Nº 5.6 – Implementación del patrón Singleton para el manejo de la persistencia
Figura Nº 5.7 – Jerarquía de clases que representan la implementación del patrón Mediador
Página 41
5.3.3.3 DTO (Data Transfer Object)

El sistema también implementa los patrones de diseño DTO (Data Transfer Object) [9] y
Assembler, que permiten transferir objetos del dominio desde el servidor al cliente según las
peticiones del mismo. Los objetos del dominio son transformados en objetos serializables, es decir,
objetos que pueden transferirse desde el servidor hacia el cliente, a través de una clase Assembler
que convierte los mismos. Esta clase permite convertir objetos serializables en objetos del dominio y
viceversa.
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
Figura Nº 5.9 – Clase Assembler
Página 42
5.3.4 Extensión y/o adición de nuevos casos de uso

El sistema está diseñado e implementado de manera que resulte ágil y sencilla la extensión
de nuevos casos de uso. Para ello, algunas partes del mismo merecen atención especial.
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:
 NULL: inicia el caso de uso de manera nominal.

 ADD: inicia el caso de uso preparado para dar de alta un elemento.
 EDIT: inicia el caso de uso preparado para editar un elemento específico.
 DELETE: inicia el caso de uso preparado para eliminar un elemento específico.
 VIEW: inicia el caso de uso en modo vista.
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.
5.3.4.1 Caso de uso Buscar Genérico

Otro punto importante es la implementación del caso de uso Buscar de cualquier caso de uso.
El mismo es genérico y las clases que lo implementan se encuentran el paquete cliente.Buscar. El
mismo consta de una clase correspondiente a la interfaz gráfica y otra de control. Este caso de uso
ofrece la funcionalidad de búsqueda de elementos de manera genérica y al momento de su ejecución
debe parametrizarse para que se ajuste a la búsqueda deseada. Al igual que los demás casos de
uso, consta de una clase de control denominada MediadorBuscar que extiende de la clase Mediador.
Página 43
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:
Nombre de la Valor de la propiedad Requerido

propiedad
DTOObject Un objeto de tipo ClaseDTO Si
title Título de la ventana de búsqueda Si
selectionMode Modo de selección. Especificar valores No
constantes (instanciados como Integer)
definidos en la interface
ListSelectionModel:
ListSelectionModel.MULTIPLE_INTERVAL_SELECTION
ListSelectionModel.SINGLE_INTERVAL_SELECTION
ListSelectionModel.SINGLE_SELECTION
Si no se especifica valor, el valor por
defecto de este parámetro es
ListSelectionModel.SINGLE_SELECTION.
filter Filtro inicial de búsqueda. Debe ser un string No
que represente una condición booleana.
newMediator Mediador a ejecutar en caso de querer lanzar No
el caso de uso agregar de un caso de uso.
searchPanelEnabled Indica si el panel de búsqueda está o no No
habilitado. Valor por defecto: true.
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:
 private String titulosBusqueda[] = {"Apellido", "Nombre", "Nº Documento"};

 private String camposBusqueda[] = {"apellido", "nombre", "dni"};
Esto significa que se pueden buscar personas a través de su nombre, su apellido y/o su
número de documento.
5.3.5 Tecnologías utilizadas

A continuación se presentan las herramientas y tecnologías utilizadas para la documentación
y diseño e implementación del sistema.
Herramientas de documentación y diseño:

 JUDE Community 5.5: Herramienta de modelado UML.
 BizAgi Process Modeler BPMN 1.1: software para la creación de diagramas de procesos
con soporte para el estándar BPMN.
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
- 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).
5.3.6 Requerimientos de software y hardware del sistema

A continuación se detalla el software necesario para la correcta ejecución de la aplicación
además del hardware mínimo bajo el cual puede ejecutarse.
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.
Hardware mínimo requerido:

 CPU: Intel Pentium III ó similar.
 Memoria RAM: 512 Mb.
 Espacio en disco: 20 Mb
5.3.7 Diagrama de Componentes
Un diagrama de componentes representa cómo un sistema de software es dividido en

componentes y muestra las dependencias entre estos componentes. Los componentes físicos
incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los
diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser
usados para modelar y documentar cualquier arquitectura de sistema.
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.
La Figura 5.10 muestra un diagrama de componentes que contiene las bibliotecas y

ejecutables necesarios para que el sistema funcione.
Página 45
Figura 5.10 – Diagrama de Componentes
Página 46
5.3.8 Realización del Caso de Uso Gestión Convocatoria
5.3.8.1 Trazabilidad de clases de análisis a clases de diseño

A continuación se obtienen las clases de diseño a partir de las clases de análisis para el caso
de uso Gestión Convocatoria (alta, modificación, eliminación y búsqueda). En las clases de diseño no
se visualizan ni los atributos ni las operaciones para tener una vista global de la realización de casos
de uso de análisis al diseño. Ver Figura Nº 5.11
5.3.8.2 Modelo de Diseño del caso de uso Gestión Convocatoria

El 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. El modelo de diseño del caso de uso
Gestión Convocatoria se puede apreciar en la Figura Nº 5.12.
5.3.8.3 Diagramas de Secuencia para Gestión Convocatoria

Los diagramas de secuencias permiten modelar los aspectos dinámicos de un sistema y
destacan el orden temporal de los mensajes. Se construyen representaciones gráficas de escenarios
que impliquen la interacción entre objetos.
5.3.8.3.1 Diagrama de secuencia para Alta Convocatoria

Escenario: Se desea dar de alta una convocatoria y la misma no existe cargada en el sistema. Ver
Figura Nº 5.13
5.3.8.3.2 Diagrama de secuencia para Modificar Convocatoria

Escenario: Se desea modificar los datos una convocatoria existente en el sistema y sin proyectos
asociados. Se desea modificar los datos propios y asociarle una categoría existente. Ver Figura Nº
5.14
Página 47
Figura Nº 5.11 – Trazabilidad de clases – Gestión Convocatoria
Página 48
Figura Nº 5.12 – Modelo de Diseño – Gestión Convocatoria
Página 49
Figura Nº 5.13 – Modelo de Diseño – Diagrama de Secuencia – Alta Convocatoria
Página 50
Figura Nº 5.14 – Modelo de Diseño – Diagrama de Secuencia – Modificar Convocatoria
Página 51
5.3.9 Realización de Casos de Uso utilizando Plantillas de Diseño

En la tabla de la Figura Nº 5.15, se detallan las instanciaciones de las plantillas de diseño
[Capítulo 11.3] para los casos de uso de esta iteración, que se comportan de manera genérica y
que refieren a problemas de inserción, modificación, eliminación y búsqueda.
Figura Nº 5.15 – Instanciación de plantillas de diseño para Casos de uso Genéricos
Página 52
5.3.10 Diagrama de Clases Persistentes de la primera iteración

En este diagrama se muestran solo las clases involucradas en la primera iteración. El mismo
se puede apreciar en la Figura Nº 5.16
Figura Nº 5.16 – Diagrama de Clases Persistentes – Primera Iteración
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.1 se realiza la descripción detallada de los siguientes casos de uso:
 Alta y Modificación de Proyecto

 Alta y Modificación de Programa
 Alta y Modificación de Presupuesto
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:
 Eliminación y Búsqueda de Proyecto

 Eliminación y Búsqueda de Programa
 Eliminación y Búsqueda de Presupuesto
 Gestión Cargo
Nombre: Alta Proyecto

Pre-condición: Existe un nuevo proyecto a ser ingresado
Post-condición: El proyecto queda registrado en el sistema o el proyecto ya estaba registrado en el
sistema
Descripción: Realiza la inserción de un nuevo proyecto respetando las reglas de negocio (R4)
asociadas al proyecto

1. include (Buscar Convocatoria)
2. Muestra las modalidades controlando que se cumpla la regla de
negocio R4.
3. Selecciona la modalidad
4. Ingresa título del proyecto
5.Verifica si existe el proyecto

6. include (Datos Proyecto-Programa)
7. Registra el proyecto en el sistema
1.1 Si no existe la Convocatoria, el sistema lo informa. Termina
5.1 Si existe el proyecto, el sistema lo informa. Termina
Página 54
Nombre: Modificación Proyecto

Pre-condición: Existe un proyecto a ser modificado.
Post-condición: La modificación del proyecto queda registrada en el sistema.
Descripción: Realiza la modificación de un proyecto existente.

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)
6. Selecciona integrantes del

proyecto
7. Elimina o asocia nuevos integrantes del proyecto, include(Buscar
Persona).
8. Include (Buscar Tipo de Función). Selecciona las funciones para

los integrantes del proyecto
9. Ingresa dedicación de horas

de los integrantes.
10. Si el proyecto seleccionado requiere grupo responsable,
include (Buscar Persona)
11. Ingresa palabras claves,

resumen, resumen en inglés,
antecedentes del grupo de
trabajo y datos económicos.
12. Graba las modificaciones en el sistema.

1.1 Si no existe la 4Convocatoria, el sistema lo informa. Termina
Página 55
Nombre: Datos Proyecto-Programa

Pre-condición: Invocado desde Alta o Modificación de Proyecto o Programa
Post-condición: El programa queda registrado en el sistema o el programa ya estaba registrado en
el sistema
Descripción: Realiza la inserción de datos en un proyecto o programa, controlando el cumplimiento
de las reglas de negocio (R2, R4, R9) asociados al proyecto o programa.

1. include (Buscar Persona). Selecciona la persona que será el
Director del Proyecto y/o Programa. Atender regla R2
2. Si tiene Co-Director, include(Buscar Persona). Atender regla de
negocio R9
3..Selecciona la disciplina
4. Selección el campo de
aplicación
5. Selecciona la facultad
6. Selecciona Departamento
7. Muestra las áreas y temas prioritarios controlando que se
cumpla regla de negocio R4
8. Seleccionar el área y tema
prioritarios.
9. Muestra las categorías controlando se cumpla la regla de
negocio R4
10. Selecciona la categoría.
11. Ingresa el monto asignado
al proyecto
Nombre: Alta Programa

Pre-condición: Existe un nuevo programa a ser ingresado
Post-condición: El programa queda registrado en el sistema o el programa ya estaba registrado en
el sistema
Descripción: Realiza la inserción de un nuevo programa, controlando el cumplimiento de las reglas
de negocio (R4, R13) asociados al proyecto.

2. Muestra las modalidades controlando que se cumpla la regla de
negocio R4.
3. Selecciona la modalidad
4. Ingresa título del programa
5.Verifica si existe el programa
7. include (Buscar Proyecto). Selecciona los proyectos que
formaran parte del programa. Atender la reglar de negocio R13
8. Registra el programa en el sistema.
5.1 Si existe el programa, el sistema lo informa. Termina
Página 56
Nombre: Modificación Programa

Pre-condición: Existe un programa a ser modificado
Post-condición: La modificación del programa queda registrada en el sistema.
Descripción: Realiza la modificación de un nuevo programa, controlando el cumplimiento de las
reglas de negocio (R13) asociados al programa.

2. Selecciona el programa.
4. include (Buscar Proyecto). Selecciona los proyectos que
formarán parte del programa. Atender regla de negocio R13.
5. Ingresa palabras claves,
resumen, resumen en inglés,
antecedentes del grupo de
trabajo y datos económicos.
6. Graba las modificaciones en el sistema.
4.1 Si la cantidad de proyectos seleccionados es menor a 2 o si no existe alguno de los proyectos que
deben ser asociados al programa, el sistema lo informa. Termina.
Nombre: Alta Presupuesto

Pre-condición: Existe un proyecto o programa al cual cargar un presupuesto de gastos.
Post-condición: El presupuesto de gasto queda registrado en el sistema asociado a un proyecto o
programa vigente.
Descripción: Realiza la inserción de un presupuesto de gastos, controlando el cumplimiento de las
reglas de negocio (R5, R6) asociadas al presupuesto.
Encargado Contable SISTEMA

1. include (Buscar Proyecto)
2. Selecciona Proyecto o
Programa
3. Muestra datos del Proyecto o Programa seleccionado
2. Ingresa períodos de
ejecución del presupuesto.
4. Verifica si los períodos ingresados son válidos. Atender las
reglas de negocio R5
5. El sistema genera un presupuesto con montos vacios para cada
uno de los periodos ingresados, con los rubros y subrubros
correspondientes. Atender reglas de negocio R5 y R6
6. Registra el presupuesto en el sistema
1.1 Si la convocatoria no existe el sistema lo informa. Termina.

4.1 Si el período ingresado es inválido, el sistema lo informa. Termina.
Página 57
Nombre: Modificar Presupuesto

Pre-condición: Existe un presupuesto a ser modificado.
Post-condición:
Descripción: Registra en el sistema datos el presupuesto de gastos asociado a un proyecto o
programa con los montos asignado a los rubros, controlando el cumplimiento de las reglas de negocio
(R7 y R8) asociadas al presupuesto.

1. include (Buscar Proyecto)
2. Selecciona Proyecto o
Programa
3. Muestra datos de proyecto

4. Selecciona período de
ejecución
5. Selecciona los subrubros a los cuales se le va ingresar o

modificar los montos
6. Ingresa monto
presupuestado para cada
subrubro seleccionado.
7. Verifica montos ingresados para cada subrubro. Atender las
reglas de negocio R8.
8. Calcula total por rubro.
9. Calcula el total de presupuesto del período actual de ejecución.

Atender la regla de negocio R7.
10. Asienta en el historial la modificación de los montos de cada

uno de los subrubros seleccionados.
11. Registrar el presupuesto.

1.1 Si convocatoria no existe el sistema lo informa. Termina.
7.1 Si montos ingresados no válidos, el sistema lo informa. Termina

A continuación se detallan las instanciaciones de las plantillas [4] para los casos de uso
indicados en el punto 6.1.
Página 58
Página 59
Página 60
Página 61
Segunda Iteración – Análisis de Casos de Uso
6.2. Análisis

escenarios significativos a partir de diagramas de comunicación.
6.2.1 Caso de Uso: Alta Proyecto

UI_Proyecto Verificar correctitud del
Interfaz
UI_BuscarProyecto formato de los datos
Control_Gestion_Proyecto Verificar si existe el proyecto.
necesarios para el proyecto
Registra el proyecto.
Control_Gestion_Convocatoria Obtiene todas las
convocatorias existentes.
Control_Gestion_Modalidad Obtiene las modalidades

Control
asociadas a la convocaría
elegida.
Control_Datos_ProyectoPrograma Obtiene personas, facultad,
categoría, área y temas
prioritarios y campo de
aplicación relacionados al
proyecto,
Proyecto nombre
fecha_ini_pren
fecha_fin_pren
Entidad
plazo_duración
monto_total_financ
minimo_exigible
6.2.1.1 Diagrama de Clases de Análisis del caso de uso Alta Proyecto

El diagrama de clases de Análisis del caso de uso Alta Proyecto se puede apreciar en la
Figura Nº 6.1.
Figura Nº 6.1 – Clases de Análisis – Alta Proyecto
Página 62
6.2.1.2 Diagramas de Comunicación del caso de uso Alta Proyecto

Escenario: Se desea dar de alta un proyecto de una convocatoria existente. Ver Figura Nº 6.2
Figura Nº 6.2 - Modelo de Análisis – Diagrama de colaboración Alta Proyecto
Página 63
6.2.2 Caso de Uso: Modificación Proyecto

UI_Proyecto Verificar correctitud del
Interfaz UI_BuscarProyecto formato de los datos
Control_Gestion_Proyecto Verificar si existe el proyecto.

necesarios para el proyecto.
Registra el proyecto.

Control Control_Datos_ProyectoPrograma Busca director, co-director,

facultad, departamento,
disciplina, categoría, área y
temas prioritarios y campo de
proyecto,
Control_Gestion_Persona Busca integrantes del
proyecto
Control_Gestion_TipoFuncion Busca los tipos de funciones
existentes para las personas
integrantes del proyecto.
Proyecto nombre
fecha_ini_pren
fecha_fin_pren
Entidad
plazo_duración
monto_total_financ
minimo_exigible
6.2.2.1 Diagrama de Clases de Análisis del caso de uso Modificar Proyecto

El diagrama de clases de Análisis del caso de uso Modificar Proyecto se puede apreciar en la
Figura Nº 6.3.
Figura Nº 6.3 – Clases de Análisis – Modificar Proyecto
Página 64
6.2.2.2 Diagramas de Comunicación del caso de uso Modificar Proyecto

Escenario: Se desea agregar una persona nueva como integrante de un proyecto existente de una
convocatoria dada. Ver Figura Nº 6.4
Figura Nº 6.4 - Modelo de Análisis – Diagrama de colaboración Modificar Proyecto
Página 65
6.2.3 Caso de Uso: Alta Programa

UI_Programa Verificar correctitud del
Interfaz UI_BuscarPrograma formato de los datos
Control_Gestion_Programa Verificar si existe el

programa.
necesarios para el programa
Registra el programa.
Control_Gestion_Modalidad Obtiene las modalidades

Control asociadas a la convocaría
elegida.
Control_Datos_ProyectoPrograma Obtiene personas, facultad,
categoría, área y temas
prioritarios y campo de
programa,
Control_Gestion_Proyecto Obtiene los proyectos que
serán parte del programa.
Proyecto nombre
fecha_ini_pren
fecha_fin_pren
Entidad
plazo_duración
monto_total_financ
minimo_exigible
6.2.3.1 Diagrama de Clases de Análisis del caso de uso Alta Programa

El diagrama de clases de Análisis del caso de uso Alta Programa se puede apreciar en la
Figura Nº 6.5.
Figura Nº 6.5 – Clases de Análisis – Alta Programa
Página 66
6.2.3.2 Diagramas de Comunicación del caso de uso Alta Programa

Escenario: Se desea dar de alta un programa de una convocatoria existente. Ver Figura Nº 6.6
Figura Nº 6.6 - Modelo de Análisis – Diagrama de colaboración Alta Programa
Página 67
6.2.4 Caso de Uso: Modificación Programa

UI_Programa Verificar correctitud del
Interfaz
UI:BuscarPrograma formato de los datos
Control_Gestion_Programa Verificar si existe el
programa.
necesarios para el programa.
Registra el programa.
Control_Datos_ProyectoPrograma Busca director, co-director,
facultad, departamento,
disciplina, categoría, área y
Control temas prioritarios y campo de
programa
Control_Gestion_Persona Busca integrantes del
programa
Control_Gestion_TipoFuncion Busca los tipos de funciones
existentes para las personas
integrantes del programa
Control_Gestion_Proyecto Busca los proyectos que
formaran parte del programa
Proyecto nombre
fecha_ini_pren
fecha_fin_pren
Entidad
plazo_duración
monto_total_financ
minimo_exigible
6.2.4.1 Diagrama de Clases de Análisis del caso de uso Modificar Programa

El diagrama de clases de Análisis del caso de uso Modificar Programa se puede apreciar en
la Figura Nº 6.7.
Figura Nº 6.7 – Clases de Análisis – Modificar Programa
Página 68
6.2.4.2 Diagramas de Comunicación del caso de uso Modificar Programa

Escenario: Se desea agregar un proyecto existente como proyecto integrante de un programa. Ver
Figura Nº 6.8
Figura Nº 6.8 - Modelo de Análisis – Diagrama de colaboración Modificar Programa
Página 69
6.2.5 Caso de Uso: Datos Proyecto-Programa

UI_Datos_ProyectoPrograma Verificar correctitud del formato
Interfaz
de los datos
Control_Datos_ProyectoProg Interactuar con los siguiente
rama casos de uso:
 Buscar Categoría
 Buscar Area y Tema
prioritarios
 Buscar Disciplina
 Buscar Facultad
 Buscar Departamento
 Buscar Campo
aplicaciones
 Buscar Persona
Control
Control_Gestion_Persona Obtiene el director y/o co-
director
Control_Gestion_Categoria Obtiene categorías
Control_Gestion_CampoAplic Obtiene los campos de
acion aplicación
Control_Gestion_AreaTemas Obtiene las área y temas
prioritarios prioritarios
Control_Gestion_Facultad Obtiene la facultad
Control_Gestion_Departamen Obtiene el departamento
to
Control_Gestion_Disciplina Obtiene la disciplina
6.2.5.1 Diagrama de Clases de Análisis del caso de uso Datos ProyectoPrograma

El diagrama de clases de Análisis del caso de uso Datos ProyectoPrograma se puede
apreciar en la Figura Nº 6.9.
Figura Nº 6.9 – Clases de Análisis – Datos Proyecto-Programa
Página 70
6.2.5.2 Diagramas de Comunicación del caso de uso Datos ProyectoPrograma

Este caso de uso no será invocado directamente por ningún actor del sistema, sino que serán
otros casos de uso los encargados de iniciarlo. Debido a esta razón, no podemos plantear un
escenario propio para este caso de uso, por lo tanto desarrollaremos su interacción con el caso de
uso alta proyecto en el escenario que se planteo para el mismo. Ver Figura Nº 6.10
Figura Nº 6.10 - Modelo de Análisis – Diagrama de colaboración – Datos ProyectoPrograma
Página 71
6.2.6 Caso de Uso: Alta Presupuesto

UI_ Presupuesto Verificar correctitud del formato de los datos
Interfaz
UI_BuscarPresupuesto
Control_Gestion_Presupue Verificar si existe el presupuesto.
sto Verificar que el período de ejecución sea
válido. Verificar que si existe un presupuesto
del período anterior, él mismo haya sido
rendido el mínimo exigible. Verificar que los
rubros relacionados con el presupuesto de un
proyecto estén incluidos en la normativa de la
convocatoria a la que pertenece dicho
proyecto. Verificar que en el presupuesto se
respeten los topes de financiamientos por
rubro descriptos en la normativa de la
convocatoria. Asentar en el historial los
movimientos de montos sobre los rubros del
Control presupuesto. Calcular el presupuesto anual.
Registrar el presupuesto. Interactuar con los
siguiente casos de uso:
 Buscar Proyecto
 Buscar SubRubro
Control_Gestion_Proyecto Obtiene los proyectos existentes. Verifica que
el proyecto seleccionado exista
Control_Gestion_Program Obtiene los programas existentes. Verifica que
a el programa seleccionado exista.
Control_Gestion_Convocat Obtiene las convocatorias existentes
oria
Control_Gestion_SubRubr Obtiene los subrubros existentes
o
Presupuesto id_periodo
total_presupuesto
Movimiento_Presupuestari fecha
Entidad
o monto
presupuesto
subrubro
6.2.6.1 Diagrama de Clases de Análisis del caso de uso Alta Presupuesto

El diagrama de clases de Análisis del caso de uso Alta Presupuesto se puede apreciar en la
Figura Nº 6.11.
Figura Nº 6.11 – Clases de Análisis – Alta Presupuesto
Página 72
6.2.6.2 Diagrama de Comunicación del caso de uso Alta Presupuesto

Escenario 1: Se desea dar de alta un presupuesto de un proyecto existente. El período ingresado es
válido, dicho proyecto no tiene asociado ningún presupuesto para el período ingresado y no existe
presupuesto de períodos anteriores que no haya sido rendido al menos en el mínimo exigible. Ver
Figura Nº 6.12
Figura Nº 6.12 - Modelo de Análisis – Diagrama de colaboración – Alta Presupuesto
Página 73
6.2.7 Caso de Uso: Modificación Presupuesto

UI_Presupuesto Verificar correctitud del formato de los
Interfaz
UI_BuscarPresupuesto datos
Control_Gestion_Presupue Verificar si existe el presupuesto. Verificar
sto que el período de ejecución sea válido.
Verificar que si existe un presupuesto del
período anterior, él mismo haya sido
rendido el mínimo exigible. Verificar que los
rubros relacionados con el presupuesto de
un proyecto estén incluidos en la normativa
de la convocatoria a la que pertenece dicho
proyecto. Verificar que en el presupuesto
se respeten los topes de financiamientos
por rubro descriptos en la normativa de la
convocatoria. Asentar en el historial los
Control movimientos de montos sobre los rubros
del presupuesto. Calcular el presupuesto
anual. Registrar el presupuesto. Interactuar
con los siguiente casos de uso:
 Buscar Proyecto
 Buscar SubRubro
Control_Gestion_Proyecto Obtiene los proyectos existentes. Verifica
que el proyecto seleccionado exista
Control_Gestion_Program Obtiene los programas existentes. Verifica
a que el programa seleccionado exista.
Control_Gestion_Convocat Busca la convocatoria a la cual pertenece
oria el proyecto seleccionado, para obtener los
subrubros asociados a esta convocatoria.
Presupuesto id_periodo
total_presupuesto
Movimiento Presupuestario fecha
Entidad
monto
presupuesto
subrubro
6.2.7.1 Diagrama de Clases de Análisis del caso de uso Modificar Presupuesto

El diagrama de clases de Análisis del caso de uso Modificar Presupuesto se puede apreciar
en la Figura Nº 6.13.
Figura Nº 6.13 – Clases de Análisis – Modificar Presupuesto
Página 74
6.2.7.2 Diagrama de Comunicación del caso de uso Modificar Presupuesto

Escenario: Se desea ingresar los montos para los subrubros de un presupuesto de un proyecto
existente. Ver Figura Nº 6.14
Figura Nº 6.14 - Modelo de Análisis – Diagrama de colaboración – Modificar Presupuesto
Página 75

A continuación se detallan las instanciaciones de las plantillas de análisis [5] para los casos
de uso de esta iteración que se comportan de manera genérica y que refieren a problemas de
Página 76
Segunda Iteración – Diseño e Implementación de Casos de Uso
En esta sección se deben tener en cuenta las consideraciones de diseño e implementación

explicadas en el capítulo 5.3 de la primera iteración.
6.3.1 Realización del Caso de Uso Gestión Proyecto

A continuación se obtienen las clases de diseño a partir de las clases de análisis para el caso
de uso Gestión Proyecto (alta, modificación, eliminación y búsqueda). En las clases de diseño no se
visualizan ni los atributos ni las operaciones para poder tener una vista global de la realización de
este caso de uso de análisis al diseño. Ver Figura Nº 6.15
Figura Nº 6.15 – Trazabilidad de Clases – Gestión Proyecto
Página 77
6.3.1.2 Modelo de Diseño del caso de uso Gestión Proyecto

Para una mejor visualización de las relaciones entre las clases, primero se muestra el
paquete cliente con la relaciones de las clases que interactúan con Gestión Proyecto. Ver Figura Nº
6.16. Luego, en la Figura Nº 6.17, se visualizan las relaciones entre los paquetes, incluyendo solo
aquellas clases que forman parte de la interacción.
Figura Nº 6.16 - Modelo de Diseño – Paquete Cliente – Gestión Proyecto
Página 78
Figura Nº 6.17 - Modelo de Diseño – Gestión Proyecto – Vista en Paquetes
Página 79
6.3.1.3 Diagramas de Secuencia para Gestión Proyecto
6.3.1.3.1 Diagrama de secuencia para Alta Proyecto

Escenario: Se da de alta a un nuevo Proyecto el cual genera un presupuesto con los rubros asociados a
la convocatoria que pertenece el proyecto. Ver Figura Nº 6.18
Figura Nº 6.18 - Modelo de Diseño – Diagrama de Secuencia – Alta Proyecto
Página 80
6.3.1.3.2 Diagrama de secuencia para Modificar Proyecto

Escenario: Se desea modificar la disciplina asociada a un proyecto existente. Ver Figura Nº 6.19
Figura Nº 6.19 - Diagrama de Secuencia – Modificar Proyecto
Página 81
6.3.2 Realización del Caso de Uso Gestión Presupuesto

La trazabilidad de las clases de análisis a las clases de diseño del caso de uso Gestión
Presupuesto se puede apreciar en la Figura Nº 6.20
Figura Nº 6.20 – Trazabilidad de Clases – Gestión Presupuesto
6.3.2.2 Modelo de Diseño del caso de uso Gestión Presupuesto

El modelo de diseño del caso de uso Gestión Presupuesto se puede apreciar en la Figura Nº
6.21.
Página 82
Figura Nº 6.21 – Modelo de Diseño – Gestión Presupuesto
Página 83
6.3.2.3 Diagramas de Secuencia para Gestión Presupuesto
6.3.2.3.1 Diagrama de secuencia para Modificar Presupuesto

Escenario: Se desea modificar el monto asociado a un subrubro del presupuesto de un proyecto. Ver
Figura Nº 6.22
Figura Nº 6.22 - Diagrama de Secuencia – Modificar Presupuesto
Página 84

A continuación se detallan las instanciaciones de las plantillas de diseño [Capítulo 11.3] para
los casos de uso de esta iteración, que se comportan de manera genérica y que refieren a
problemas de inserción, modificación, eliminación y búsqueda. En esta etapa surgió la necesidad de
la incorporación un nuevo caso de uso que es Gestión Tipo de Documento, el cual también es
instanciado por medio de plantillas de diseño.
Página 85
6.3.4 Diagrama de Clases Persistentes de la segunda iteración

En este diagrama se muestran solo las clases involucradas en la segunda iteración. El mismo
Figura Nº 6.23 – Diagrama de Clases persistentes – Segunda Iteración
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.1 se realiza la descripción detallada para los casos de uso:
 Solicitud y Devolución de Adelantos

 Gestión Viatico
 Gestión Beca
 Gestión Factura
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:
 Modificación, Eliminación y Búsqueda de Viático

 Modificación, Eliminación y Búsqueda de Beca
 Modificación, Eliminación y Búsqueda de Factura
Nombre: Solicitud y Devolución de Adelantos

Pre-condición: Existe un pedido de adelanto de dinero o de devolución de dinero de un presupuesto
asignado a un proyecto o programa.
Post-condición: El adelanto de dinero es otorgado y registrado en el sistema o no lo es.
Descripción: Registra en el sistema un adelanto de dinero del presupuesto de un programa o
proyecto vigente.

1. include (Buscar Proyecto) o include (Buscar Programa)
2. Selecciona el presupuesto
del cual se quiere solicitar el
adelanto o devolución.
3. Muestra la información del presupuesto, año de ejecución, saldo

presupuestario, saldo disponible, etc..
4. Ingresa número, fecha,

monto y solicitante de dinero y
selecciona el tipo de
movimiento
5. Si el tipo de movimiento es un Adelanto, verifica si tiene saldo

financiero disponible.
Página 87
6. Si el tipo de movimiento es una Devolución, verifica que el monto

devuelto sea menor o igual que el saldo de dinero no rendido.
7. Genera un cheque o valor por el importe ingresado y asocia el

movimiento de dinero a la cuenta de banco correspondiente.
8. Registra en el sistema el adelanto o devolución.

1.1 Si el proyecto no existe el sistema lo informa. Termina.
5.1 Si no tiene saldo financiero disponible, el sistema lo informa. Termina.
6.1 Si el monto no es menor o igual, el sistema lo informa. Termina
Nombre: Alta Viático

Pre-condición: Existe un pedido de viático
Post-condición: El viático es otorgado y registrado en el sistema o no lo es.
Descripción: Registra en el sistema un viático solicitado, controlando el cumplimiento de las reglas
de negocio (R12) asociados al proyecto.

1. include ( Buscar Proyecto) o include (Buscar Programa)
2. Selecciona presupuesto
3. include (Buscar Persona). Muestra integrantes del Proyecto y/o
Programa.Atender regla de negocio R12.
4. Selecciona beneficiario del
viático
5. Ingresa identificador del
comprobante, fecha, monto
total, destino, motivo y días del
viático.
6. Verifica que el monto ingresado no supere el saldo
presupuestario disponible en el rubro viatico en dicho período.
7. Registra el viatico.
3.1 Si la persona ingresada no es integrante del proyecto, el sistema lo informa. Termina
6.1 Si no tiene saldo presupuestario disponible, el sistema lo informa. Termina.
Nombre: Alta Beca

Pre-condición: Existe un pedido de Beca
Post-condición: La beca es otorgada y registrada en el sistema o no lo es.
Descripción: Registra en el sistema la beca solicitada.

3. include (Buscar Persona). Muestra Becarios.
4. Selecciona beneficiario de la
beca.
Página 88
5. Ingresa monto de la beca,

identificador del comprobante
y fecha
6. Verifica que el monto ingresado de la beca no supere el saldo
presupuestado para el subrubro beca.
7. Include (Solicitud y Devolución de Adelantos)
8. Registra la beca.
3.1 Si el proyecto no tiene becarios, el sistema lo informa. Termina
6.1 Si el monto ingresado supera el saldo presupuestario, el sistema lo informa. Termina
Nombre: Alta Factura

Pre-condición: Existe una factura para ser presentada
Post-condición: La factura es aceptada y registrada en el sistema o no lo es.
Descripción: Registra en el sistema la factura presentada.

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.
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.

A continuación se detallan las instanciaciones de las plantillas [4] para los casos de uso de
nuestro sistema de la tercera iteración, que se comportan de manera genérica y que son los
indicados en el punto 7.1
Página 89
Página 90
Página 91
Tercera Iteración - Análisis de Casos de Uso
7.2. Análisis

escenarios significativos a partir de diagramas de comunicación
7.2.1 Caso de Uso: Solicitud y Devolución de Adelantos

UI_SolicitudAdelantoDevo Verificar correctitud del formato de los
Interfaz
lucion datos
Control_SolicitudAdelanto Verificar si existe el proyecto y tiene
Devolucion saldo financiero.
Buscar los datos principales necesarios
para realizar la solicitud y/o devolución
del adelanto. Registra el movimiento.
Control_Gestion_Proyecto Obtiene los proyectos existentes.
Control_Gestion_Program Obtiene los programas existentes.
a
Control Control_Gestion_Presupu Obtiene el presupuesto del proyecto del
esto cual se solicita o devuelve el adelanto.
Control_Gestión_CuentaB Obtiene la cuenta de banco a la cual se
anco le realiza el movimiento.
Control_Gestion_Movimie Encargada de registrar el movimiento en
ntoCuenta la cuenta,
Control_Gestion_Persona Obtiene la persona que solicita o
devuelve un adelanto.
AdelantoyDevoluciones presupuesto
cuenta_banco
firmante
Entidad
tipo_movimiento_financiero
tipo_movimiento_financiero
fecha_movimiento
7.2.1.1 Diagrama de Clases de Análisis del caso de uso Solicitud y Devolución

de Adelantos
El diagrama de clases de Análisis del caso de uso Solicitud y Devolución de Adelantos se
puede apreciar en la Figura Nº 7.1.
Figura Nº 7.1 – Clases de Análisis – Solicitud y Devolución de Adelantos
Página 92
7.2.1.2 Diagrama de Comunicación del caso de uso Solicitud y Devolución de

Adelantos
Escenario: Se desea pedir un adelanto del presupuesto de un proyecto de una convocatoria
existente, el cual tiene disponible saldo financiero para solicitar dicho adelanto. Ver Figura Nº 7.2
Figura Nº 7.2 – Modelo de Análisis – Diagrama de Colaboración – Solicitud de devolución y adelanto
Página 93
7.2.2 Caso de Uso: Alta viático

UI_Viatico Verificar correctitud del formato de los
Interfaz
datos
Control_Gestion_Viatico Busca los datos principales necesarios
para realizar el viático.
Registra el viático.
Control_Gestion_Programa Obtiene los programas existentes
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
Control_Gestion_Persona Obtiene la persona beneficiaria del

viático.
Viatico persona
motivo
destino
Entidad fecha_desde
fecha_hasta
monto
fecha_rendicion
7.2.2.1 Diagrama de Clases de Análisis del caso de uso Alta Viático

El diagrama de clases de Análisis del caso de uso Alta Viático se puede apreciar en la Figura
Nº 7.3
Figura Nº 7.3 – Clases de Análisis – Alta Viático
Página 94
7.2.2.2 Diagrama de Comunicación del caso de uso Alta Viático

Escenario: Se desea solicitar un viatico para un integrante de un proyecto de un programa existente,
el cual tiene disponible saldo financiero. Ver Figura Nº 7.4
Figura Nº 7.4 – Modelo de Análisis – Diagrama de Colaboración – Alta Viático
Página 95
7.2.3 Caso de Uso: Alta Beca

UI_Beca Verificar correctitud del formato de los
Interfaz
datos
Control_Gestion_Beca Buscar los datos principales necesarios
para otorgar la beca. Registra la beca
Control_Gestion_Proyecto Obtiene los proyectos existente.
Control_Gestion_Presupuesto Obtiene el presupuesto del proyecto del

Control cual se solicita la beca.
Control_Gestión_SubRubro Obtiene el subrubro beca.
Control_Gestion_Persona Obtiene la persona beneficiaria de la beca.
Control_Gestion_SolicitudAdel Se encarga de asentar la beca como una

antoDevolucion solicitud de adelanto
Beca beneficiario
periodo
Entidad
monto
fecha_rendicion
7.2.3.1 Diagrama de Clases de Análisis del caso de uso Alta Beca

El diagrama de clases de Análisis del caso de uso Alta Beca se puede apreciar en la Figura
Nº 7.5.
Figura Nº 7.5 – Clases de Análisis – Alta Beca
7.2.3.2 Diagramas de Comunicación del caso de uso Alta Beca
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
Figura Nº 7.6 – Modelo de Análisis – Diagrama de Colaboración – Alta Beca
Página 97
7.2.4 Caso de Uso: Alta Factura

UI_Factura Verificar correctitud del formato de los
Interfaz
datos
Control_Gestion_Factura Buscar los datos principales necesarios
para registrar la factura.
Control Control_Gestion_Presupuesto Obtiene el presupuesto del

proyecto/programa del cual se rinde la
factura
Control_Gestión_SubRubro Obtiene los subrubros integrantes de la
factura presentada.
Control_Gestion_Proveedor Obtiene los proveedores existentes
Factura nro_factura
tipo_factura
condición_venta
monto
fecha_rendicion
Entidad ItemFactura nro_item
descripcion
cantidad
precio_unitario
MontoporItem importe
7.2.4.1 Diagrama de Clases de Análisis del caso de uso Alta Factura

El diagrama de clases de Análisis del caso de uso Alta Factura se puede apreciar en la
Figura Nº 7.7.
Figura Nº 7.7 – Clases de Análisis – Alta Factura
Página 98
7.2.4.2 Diagramas de Comunicación del caso de uso Alta Factura

Escenario: El director de un proyecto presenta una factura en fecha y forma. Dicha factura será
compartida con otro proyecto. Ver Figura Nº 7.8
Figura Nº 7.8 – Modelo de Análisis – Diagrama de Colaboración – Alta Factura
Página 99

A continuación se detallan las instanciaciones de las plantillas de análisis [5] para los casos de
uso de esta iteración, que se comportan de manera genérica y que refieren a problemas de
Página 100
Tercera Iteración - Diseño e Implementación de Casos de Uso
En esta sección se deben tener en cuenta las consideraciones de diseño e implementación

explicadas en el capítulo 5.3 de la primera iteración.
7.3.1 Realización del Caso de Uso Solicitud y Devolución de Adelanto

La trazabilidad de las clases de análisis a las clases de diseño del caso de uso Solicitud y
Devolución de Adelanto se puede apreciar en la Figura Nº 7.9
Figura Nº 7.9 – Trazabilidad de Clases – Solicitud y Devolución de Adelantos
Página 101
7.3.1.2 Modelo de Diseño del caso de uso Solicitud y Devolución de Adelanto

El modelo de diseño del caso de uso Solicitud y Devolución de Adelanto se puede apreciar en
la Figura Nº 7.10.
Figura Nº 7.10 – Modelo de Diseño – Solicitud y Devolución de Adelanto
Página 102
7.3.1.3 Diagramas de Secuencia para Solicitud y Devolución de Adelanto

Escenario: El responsable de un proyecto solicita un adelanto del presupuesto designado al
proyecto. Ver Figura Nº 7.11
Figura Nº 7.11 - Diagrama de Secuencia – Solicitud y Devolución de Adelanto
Página 103
7.3.2 Realización del Caso de Uso Gestión Viático
7.3.2.1 Trazabilidad de clases análisis a clases de diseño

Viático se puede apreciar en la Figura Nº 7.12
Figura Nº 7.12 – Trazabilidad de clases – Gestión Viático
Página 104
7.3.2.2 Modelo de Diseño del caso de uso Gestión Viático

El modelo de diseño del caso de uso Gestión Viático se puede apreciar en la Figura Nº 7.13.
Figura 7.13 – Modelo de Diseño – Gestión Viático
Página 105
7.3.2.3 Diagramas de Secuencia para Gestión Viático
7.3.2.3.1 Diagrama de secuencia para Alta Viático

Escenario: Se otorga un viático para un integrante de un proyecto dado. Ver Figura Nº 7.14
Figura Nº 7.14 - Diagrama de Secuencia – Alta Viático
Página 106
7.3.3 Realización del Caso de Uso Gestión Beca

La trazabilidad de las clases de análisis a las clases de diseño del caso de uso Gestión Beca
Figura Nº 7.15 – Trazabilidad de clases – Gestión Beca
Página 107
7.3.3.2 Modelo de Diseño del caso de uso Gestión Beca

El modelo de diseño del caso de uso Gestión Beca se puede apreciar en la Figura Nº 7.16.
Figura Nº 7.16 – Modelo de Diseño – Gestión Beca.
Página 108
7.3.3.3 Diagramas de Secuencia para Gestión Beca
7.3.3.3.1 Diagrama de secuencia para Alta Beca

Escenario: Se otorga una beca para un becario de un proyecto dado. Ver Figura Nº 7.17
Figura Nº 7.17 - Diagrama de Secuencia – Alta Beca
Página 109
7.3.4 Realización del Caso de Uso Gestión Factura

Factura se puede apreciar en la Figura Nº 7.18
Figura Nº 7.18 – Trazabilidad de clases – Gestión Factura
Página 110
7.3.4.2 Modelo de Diseño del caso de uso Gestión Factura

El modelo de diseño del caso de uso Gestión Factura se puede apreciar en la Figura Nº 7.19.
Figura Nº 7.19 – Modelo de Diseño – Gestión Factura
Página 111
7.3.4.3 Diagramas de Secuencia para Gestión Factura
7.3.4.3.1 Diagrama de secuencia para Alta Factura

Escenario: El responsable de un proyecto presenta una factura como rendición de gastos. Ver Figuras Nº
7.20-A y Nº 7.20-B
Figura Nº 7.20-A - Diagrama de Secuencia – Alta Factura – Primera Parte
Página 112
Figura Nº 7.20-B - Diagrama de Secuencia – Alta Factura – Segunda Parte
Página 113

A continuación se detallan las instanciaciones de las plantillas de diseño [Capítulo 11.3] para
los casos de uso de esta iteración, que se comportan de manera genérica y que refieren a problemas
de inserción, modificación, eliminación y búsqueda. En la siguiente tabla se incorpora la instanciación
del caso de uso Gestión Usuario, que surgió en esta iteración debido a la necesidad de definir roles
que permitan el acceso a ciertos módulos del sistema mientras otros queden inaccesibles. Esto
permite mayor seguridad y claridad de trabajo para los diferentes usuarios.
Página 114
7.3.6 Diagrama de Clases Persistentes Tercera Iteración

En este diagrama se muestran solo las clases involucradas en la tercera iteración. El mismo
Figura Nº 7.21 – Diagrama de Clases Persistentes – Tercera Iteración
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.
El resultado principal de la prueba es el modelo de prueba, el cual describe como ha sido

probado el sistema. Este modelo incluye casos de prueba, procedimientos de prueba y componentes
de prueba.
Los objetivos de la etapa de prueba son los siguientes:
 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.
La realización de las pruebas se centra en las fases de elaboración y construcción cuando la

mayor parte del sistema esta implementado. Durante la fase de transición el centro se desplaza hacia
la corrección de defectos y las pruebas de regresión.
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.
La prueba de unidad es una manera de probar el correcto funcionamiento de un módulo de

código aislado del resto de los módulos. Cuando se considera oportuno realizar pruebas de unidad se
realizan pruebas sistemáticas. El objetivo de éstas, es buscar fallos a través de criterios específicos
denominados pruebas de caja negra y pruebas de caja blanca. Cada uno de éstos tiene un objetivo
diferente. La prueba de caja blanca se centra en la estructura de control de programa mientras que la
prueba de caja negra se centra en la estructura de control de programa.
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.
8.1. Pruebas de Caja Negra
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.
8.1.1 Tabla de decisión

Cuando se desea armar el presupuesto de un proyecto, en el caso de uso Gestión
Presupuesto es necesario asignar montos a los subrubros que formarán parte del mismo. Se realiza
la prueba de Tabla de Decisión para verificar que esta operación se efectúa de manera correcta.
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
Los casos de prueba están diseñados bajo los siguientes supuestos:
Monto Total del Proyecto= $2000

Mínimo exigible = 75%
Tope del subrubro Viático = 33% ( en este caso serían $660)
Tope del subrubro Laboratorio = 100% (no tiene tope)
Casos de Prueba Valor Valor

Esperado Obtenido
C1: No tiene período anterior, por lo tanto mínimo exigible es True ERROR ERROR
C2: Saldo disponible= $800
C3: ¿Tope viatico? True
C4: Monto a ingresar en subrubro viático= $900, 900 > 800? True
C1: Período anterior rendido al 100% ERROR ERROR

C1: Período anterior rendido al 80% ERROR OK
C4: Monto a ingresar en subrubro viático= $700. ¿700 > 800? False
C5: ¿700 > 660? True
C1: Período anterior rendido al 90% OK OK

C4: Monto a ingresar en subrubro viático= $600. ¿600 > 1000? False
C5: ¿600 > 660? False
C1: No tiene período anterior, por lo tanto mínimo exigible es True ERROR ERROR
C3: ¿Tope Laboratorio? False
C4: Monto a ingresar en subrubro laboratorio= $550. ¿550 > 400?
True
C1: Período anterior rendido al 95% OK OK

C3: ¿Tope Laboratorio? False
C4: Monto a ingresar en subrubro laboratorio= $20. ¿200 > 400?
False
C1: Período anterior rendido al 50% ERROR ERROR
Página 117
Prueba
8.2. Pruebas de Caja Blanca
Se centra en la estructura de control de programa, es decir, usa la estructura interna del

programa para derivar los casos de prueba. Las pruebas de caja blanca están dirigidas a las
funciones internas.
8.2.1 Cobertura de Arco

Para realizar las pruebas se seleccionó el método de caja blanca Cobertura de Arco, que
selecciona un conjunto de pruebas T tal que, ejecutando el programa P para cada uno de los casos
de prueba de T, cada arco del flujo de control de P es atravesado al menos una vez.
8.2.1.1 Actualizar el saldo disponible en un subrubro

En el caso de uso Gestión Presupuesto, el siguiente fragmento de código actualiza el saldo
disponible de un subrubro cuando se desea presupuestar el mismo. Se realiza la prueba de cobertura
de arco para este fragmento. El grafo de flujo de control de este fragmento de código se puede
apreciar en la Figura Nº 8.2.
….
…
// Monto total presupuestado en el subrurbo "subrubroDestino"
Float montoAsignadoTotal = getMontoAsignadoTotal(subrubroDestino);
// Obtiene el porcentaje y monto del tope asignado al subrubro "subrubroDestino"

getTopePorSubrubro(subrubroDestino, porc, tope);
// Monto asignado al proyecto menos lo ya presupuestado = Saldo disponible

Float saldoDisponible = getProyecto().getMonto() - (Float)
uiFrameGestionPresupuesto.getJfdTotalPresupuestado().getValue();
// Si el subrubro posee tope...

if (porc.get() != 100.0f) {
// Si el tope menos el monto total presupuestado es menor al saldo

// disponible -> Saldo = tope - monto total presupuestado
if ((tope.get() - montoAsignadoTotal) < saldoDisponible) {
uiFramePresupuesto.getJfdSaldoDisponibleSubrubroDestino().setValue(tope.get(
) - montoAsignadoTotal);
} else {
uiFramePresupuesto.getJfdSaldoDisponibleSubrubroDestino().setValue(saldoDisp
onible);
}
} else {
uiFramePresupuesto.getJfdSaldoDisponibleSubrubroDestino().setValue(saldoDisp
onible);
}
...
Figura Nº 8.1 – Fragmento de código que actualiza el saldo disponible de un subrubro
Página 118
Prueba
montoAsignadoTotal = getMontoAsignadoTotal(subrubroDestino);
getTopePorSubrubro(subrubroDestino, porc, tope);
saldoDisponible = getProyecto().getMonto() - (Float)

uiFrameGestionPresupuesto.getJfdTotalPresupuestado().getValue();
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:
T= { <montoAsignadoTotal=130, porc=33%, tope=330, saldoDisponible=500 >,

<montoAsignadoTotal=130, porc=33%, tope=330, saldoDisponible=50>,
<montoAsignadoTotal=X, porc=100%, tope=Y, saldoDisponible=Z > }
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.
8.2.1.2 Retornar el tope definido en un subrubro

El siguiente fragmento de código retorna el tope definido para el subrubro o el monto total del
proyecto si no posee tope. Para el mismo se realiza la prueba de cobertura de camino. El grafo de
flujo de control de este fragmento de código se puede apreciar en la Figura Nº 8.4.
….
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)> }
8.3. Resultados de las pruebas
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:
Prueba Resultado Esperado Resultado Obtenido

Tabla de Decisión Que solo se asigna el monto de Observamos que el sistema no
dinero en un subrubro controlaba bien el tope de
específico, si las condiciones subrubro, es decir controlaba
necesarias se cumplen. el tope por año de
presupuesto y no por total
asignado al proyecto.
Cobertura de Arco: Actualizar el saldo disponible de El saldo disponible del

Framengo de código un subrubro cuando se subrubro queda actualizado de
Figura 8.1 presupuesta el mismo. manera correcta.
Cobertura de Arco Retornar el tope de dinero Se retorna de manera correcta

Fragmento de código disponible a gastar en un el tope a gastar de un
Figura 8.3 subrubro específico. subrubro específico.
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.
9.1. Trabajos Futuros
 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.
La implementación de esta aplicación permitirá a los usuarios, el acceso a la información de

manera inmediata mediante un navegador, lo que descongestionara la atención
personalizada que se brinda en el área de administración de la secretaría.
 Otros módulos que permitan manejar la información de:
- Evaluación de proyectos de investigación.

- Currículos de docentes investigadores.
- Proceso de investigación y registro de resultados de las investigaciones permitiendo
la publicación de resultados de las mismas.
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.
 [3] Object Management Group/Business Process Management Initiative

http://www.bpmn.org/
Ultimo acceso: 25/04/2010
 [4] Daniele Marcela, Romero Daniel. Evolución de Plantillas Genéricas para la descripción de
Casos de Uso a Plantillas Genéricas para Análisis y Diseño”. VII Workshop de Investigadores
en Ciencias de la Computación (WICC 2005), Universidad Nacional de Río Cuarto, Argentina,
Mayo 2005. ISBN: 950-665-337-2.
 [5] Daniele Marcela, Martellotto Paola, Romero Daniel. Extendiendo las plantillas genéricas
para la definición de casos de uso con un framework genérico distribuido. III Congreso de
Tecnología en Educación y Educación en Tecnología (TE&ET’08), Bahía Blanca, Argentina,
del 12 al 13 de Junio 2008.
 [6] JDO JavaTM Data Objects (JDO) Specification
http://www.jcp.org/en/jsr/detail?id=12
Último acceso: 13/03/2010
 [7] Java Persistent Objects - JPOX
http://www.jpox.org/docs/index.html
 [8] Gamma Erich, Heml Richard. “Design Patterns: Elements of Reusable Object-Oriented
Software”
 [9] Data Transfer Object - DTO
http://msdn.microsoft.com/en-us/library/ff649585.aspx
 [10] “Análisis y Diseño Orientado a Objetos: Con Aplicaciones “.Booch Grady.
AddisonWesley. 1996.
 [11] OMG. Object Management Group. Unified Modeling Language Specification.

http://www.omg.org. Ultimo acceso 18/10/2010
 [12] Arnold Ken, Gosling James. El Lenguaje de Programación JAVA. Addison

Wesley/Domo.1997.
 [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
 [16] JUDE Desing & Communication.

http://jude.change-vision.com/jude-web/product/community.html.
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.
Las plantillas representan un patrón general para solucionar problemas de inserción,

eliminación, modificación y búsqueda de elemento cuando el comportamiento es similar en muchos
de los casos e independiente del elemento.
Permiten reducir el volumen de documentación, evitando la repetición de modelos que

resuelven el mismo tipo de problema. Además homogenizan el comportamiento y la apariencia de las
funcionalidades del sistema que son del mismo tipo como el insertar, modificar, eliminar y buscar.
Instancian problemas reales en un modelo general propuesto.
11.1. PLANTILLAS GENERICAS PARA LA DESCRIPCION DE CASOS DE USO
11.1.1 Descripción del caso de uso: INSERCION DE ELEMENTO

Nombre: Inserción de {elemento}.
Pre-condición: existe un {elemento} a ser ingresado.
Post-condición: el {elemento} queda registrado en el sistema, o el {elemento} ya estaba registrado
en el sistema.
Descripción: realiza la inserción de un {elemento}, controlando la existencia del elemento en el
sistema y el cumplimiento de las reglas del negocio (r1,..,rn) asociadas al {elemento}.
Actor: nombre de los actores que interactúan con el caso de uso.
PLANTILLA 1: INSERCIÓN DE {ELEMENTO}
Página 125
ANEXO: Plantillas
11.1.2 Descripción del caso de uso: MODIFICACION DE ELEMENTO

Nombre: Modificación de {elemento}.
Pre-condición: hay {atributos} de un {elemento} que deben se modificados.
Post-condición: el {elemento} modificado queda registrado en el sistema, o el {elemento} a modificar
no existía en el sistema.
Descripción: realiza la modificación de los {atributos} de un {elemento}, controlando el cumplimiento
de las reglas del negocio (r1,..,rn) asociadas al {elemento}.
PLANTILLA 2: MODIFICACIÓN DE {ELEMENTO}
Página 126
ANEXO: Plantillas
11.1.3 Descripción del caso de uso: ELMINACION DE ELEMENTO

Nombre: Eliminación de {elemento}.
Pre-condición: existe un {elemento} a ser eliminado .
Post-condición: el {elemento} fue eliminado del sistema, o el {elemento} a eliminar no existía en el
sistema.
Descripción: realiza la eliminación de un {elemento}, controlando la existencia del elemento en el
sistema y el cumplimiento de las reglas del negocio (r1,..,rn) asociadas al {elemento}.
PLANTILLA 3: ELIMINACIÓN DE {ELEMENTO}
Página 127
ANEXO: Plantillas
11.1.4 Descripción del caso de uso: BUSQUEDA DE ELEMENTO

Nombre: Búsqueda de {elemento}.
Pre-condición: existe la necesidad de buscar el {elemento}.
Post-condición: el {elemento} buscado fue encontrado en el sistema, o el {elemento} no estaba
registrado en el sistema.
Descripción: realiza la búsqueda de un {elemento} según el {criterio de búsqueda}.
PLANTILLA 4: BÚSQUEDA DE {ELEMENTO}
Página 128
ANEXO: Plantillas
11.2. PLANTILLA GENERICA PARA EL ANALISIS DE CASOS DE USO
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.
11.2.1 Diagrama Genérico de Clases de Análisis
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
11.2.2 Diagrama Genérico de Colaboración: Insertar Elemento

Escenario: El <Actor> desea ingresar un <Nombre> que no está en el sistema.
Descripción del flujo de eventos del Insertar

El CU es iniciado por el objeto :Control <Nombre>, permitiendo al :<Actor> el ingresar los atributos
claves. El sistema verifica el formato de los atributos y verifica que no exista ningún elemento igual,
así permite continuar agregando los demás atributos.
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.
11.2.3 Diagrama Genérico de Colaboración: Modificar Elemento

Escenario: El <Actor> desea modificar un <Nombre> que está en el sistema.

Se incluye al caso de uso Buscar para permitir al actor que haga la selección del elemento a
modificar, se muestran los datos y el actor realiza los cambios y se guardan en el sistema.
Página 130
ANEXO: Plantillas
11.2.4 Diagrama Genérico de Colaboración: Eliminar Elemento

Escenario: El <Actor> desea eliminar un <Nombre> que está en el sistema.

Se incluye al caso de uso Buscar para permitir al actor que haga la selección del elemento a eliminar,
se muestran los datos y el actor confirma la eliminación.
11.2.5 Diagrama Genérico de Colaboración: Buscar Elemento

Escenario: El <Actor> selecciona un criterio de búsqueda, y se realiza la búsqueda de los
<Nombre> que cumplen con el criterio.
Descripción del flujo de eventos del Buscar:

El actor debe seleccionar un criterio de búsqueda e ingresar los datos correspondientes, luego el
sistema busca los elementos que cumplen con la condición y muestra los resultados. El CU termina
cuando el actor confirma la búsqueda.
Página 131
ANEXO: Plantillas
11.3. PLANTILLAS DE DISEÑO DE CASOS DE USO
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.
11.3.1 Realización de C.U. de Análisis a Clases de Diseño

Para los casos de uso que se comportan de igual manera para el alta, modificación, eliminación y
búsqueda, se obtuvieron las clases de diseño a partir de las clases de análisis de manera genérica.
Página 132
ANEXO: Plantillas
11.3.2 Modelo de Diseño para el diseño de Casos de uso
Página 133
ANEXO: Plantillas
11.3.3 Diagramas de Secuencia

INSERCIÓN
Escenario: Se desea ingresar un elemento no existente en el sistema.
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

Tesis APPI - Java

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tesis APPI - Java

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDAD NACIONAL DE RÍO CUARTO

FACULTAD DE CIENCIAS EXACTAS, FÍSICO-QUÍMICAS Y NATURALES

TRABAJO FINAL PARA OPTAR AL TÍTULO DE

Sistema para la Administración de Programas y Proyectos de

Un agradecimiento especial de todo corazón a nuestras familias, por su amor, cariño,

Un sincero agradecimiento a todos nuestros amigos y compañeros de trabajo que nos

A todos muchas gracias.

La Secretaría de Ciencia y Técnica de la Universidad Nacional de Río Cuarto fue creada en el

 Coordinar la elaboración y presentación de proyectos de investigación.

En lo que a proyectos de investigación se refiere, actualmente esta Secretaría administra y

El presente trabajo es un proyecto de tesis para optar al título de Analista en Computación, el

El aumento constante en la cantidad y diversidad de proyectos de investigación que hoy

1.2. Objetivo Principal

Proponemos la creación de un sistema de software que aporte funcionalidad, transparencia y

La centralización de la información permitirá el análisis pormenorizado, tanto financiero como

1.3. Organización de este trabajo

El presente trabajo está organizado de la siguiente manera:

2. DESCRIPCION DEL NEGOCIO

Las propuestas se receptan cuando se abre un llamado a presentación de programas y

Todas las propuestas que se presentan a una convocatoria en particular, se someten a

La Secretaría debe registrar todas las propuestas presentadas, para posteriormente

En la actualidad existen varias líneas de proyectos y programas vigentes:

Proyectos y Programas Financiados con Presupuesto Propios

PPI: Programas y Proyectos de Investigación.

PIIMEG: Proyectos de Innovación e Investigación para el mejoramiento de la Enseñanza de Grado.

IP: Ideas Proyectos.

Proyectos y Programas Financiados con Presupuestos de Organismos Externos, o Co-Financiados

PICTO: Proyectos de Investigación Científica y Técnica Orientados.

PICT: Proyectos de Investigación Científica y Tecnológica.

PID: Proyectos de Investigación y desarrollo.

El llamado a Convocatoria para presentar proyectos y programas de investigación es

Cuando la Universidad, por intermedio de la Secretaría de Ciencia y Técnica llama a

Una vez cerrada la convocatoria a presentación, las propuestas son sometidas a

Una convocatoria establece una cantidad de Proyectos y Programas a financiar. También

de proyectos articulados para tratar una problemática interdisciplinariamente.

De acuerdo a cómo se realizan las actividades de investigación de los Proyectos y

Un Proyecto o Programa tiene un presupuesto de gastos por cada año de ejecución, a

Los responsables de programas o proyectos solicitan adelantos de dinero que no superen el

3. METODOLOGIA UTILIZADA: Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software [1] es el conjunto de actividades necesarias

Construcción: Se crea el producto, es decir se añade el software terminado a la arquitectura.

En la Captura de Requerimientos se construyen dos artefactos:

 Modelo de Negocio: estudia el negocio donde se implementará el sistema.

4.1. Modelo de Negocio

El Modelo de Negocio establece una abstracción de la organización. Nos permite comprender

4.1.1 Modelo de Dominio

Vista de convocatorias y proyectos: Ver Figura Nº 4.1

Vista de ejecución presupuestaria: Ver Figura Nº 4.2

Vista bancaria: Ver Figura Nº 4.3.

4.1.2 Reglas de Negocio

En el contexto de nuestro sistema se han definido las siguientes reglas de negocio:

Figura Nº 4.1 – Modelo de Dominio – Vista de convocatorias y proyectos

Figura Nº 4.2 – Modelo de Dominio – Vista de ejecución presupuestaria

Figura Nº 4.3 – Modelo de Dominio – Vista

9. IF el proyecto es un Proyecto de Fomento THEN no podrá contar con la figura de co-director.

4.1.3 Glosario de términos del Negocio

Convocatoria: Llamado a presentación de propuestas de un tipo determinado. Normativa que

Rendición: Es el acto donde un responsable de proyecto o programa presenta un comprobante de

4.1.4 Modelo de Casos de Uso de negocio

4.1.4.1 Casos de uso de negocio

Casos de uso de Negocio

 Confección de una convocatoria

Descripción de los casos de uso del negocio