You are on page 1of 112

http://inf162scontroldepensiones.wordpress.

com/2011/09/28/sistema-de-control-de-
pensiones/
http://dspace.ups.edu.ec/handle/123456789/2423
http://repositorio.utn.edu.ec/bitstream/123456789/520/2/04%20ISC%20149%20CAPITULO%2
0I.pdf

try {
cst=Conn.prepareCall("{call buscar(?)}");
cst.setString(1, buscar);
r=cst.executeQuery();

if(r.next()){
JOptionPane.showMessageDialog(this, "Cliente
encontrado","Aviso",JOptionPane.INFORMATION_MESSAGE);
this.txtCODIGO.setText(r.getString(1));
this.txtNOMBRES.setText(r.getString(2));
this.txtRUC.setText(r.getString(3));
this.txtNOMBRES.setText(r.getString(4));
this.txtTELEFONO.setText(r.getString(5));
}else{
JOptionPane.showMessageDialog(this, "Cliente no
encontrado","Aviso",JOptionPane.INFORMATION_MESSAGE);
}




SISTEMA DE CONTROL
DE PENSIONES
sep28








I NTEGRANTES:

* CAROLINA ATANACIO FUENTES
* DELIA JALLASI YUJRA
* MARIA ELENA JIMENEZ CHAVEZ



SI STEMA DE CONTROL Y ADMI NI STRACI N
DE PAGO DE PENSI ONES
PARA COLEGI O PARTI CULAR

1. ANALISIS Y DISE;O ESTRUCTURADO
2. ORIENTADO A OBJETOS








INDICE


1.1INTRODUCCIN
1.2 Antescedentes
1.3 ARBOL DE PROBLEMAS
1.3.1 IDENTIFICACIN DEL PROBLEMA
1.3.2 PLANTEAMIENTO DEL PROBLEMA
1.4 OBJETIVOS
7 1.4.1 OBJETIVO GENERAL
8 1.4.2 OBJETIVO ESPECFICOL
9 1.5 ALCANCE
10 1.6 MTODOS DE INVESTIGACIN
11 1.7 JUSTIFICACIN
12 1.8 PLANIFICACION DE ACTIVIDADES MODELO ESENCIAL
13 a) MODELO AMBIENTAL
14 a1) DECLARACIN DE PROPOSITOS
15 a2) DIAGRAMA DE CONTEXTO
16 a3) LISTA DE ACONTECIMIENTOS
17 b) MODELO DE COMPORTAMIENTO
18 b1) MODELO PRELIMINAR DE COMPORTAMIENTO
INTRODUCCIN
En este tiempo los sistemas basados en computadora son ms necesarios para las actividades de las
empresas e instituciones, para administrar grandes volmenes de informacin que cada da va creciendo.
El fortalecimiento de los recursos humanos en un pas tiene como una de sus bases la educacin. La
constante evolucin de la tecnologa informtica y el consecuente incremento de la necesidad de
aplicaciones computacionales en organizaciones e instituciones, hace trascendental la necesidad de
construir sistemas de informacin oportunos y confiables, que permitan mantener a las instituciones
tecnolgica y cientficamente informadas para una mejora en la toma de decisiones. El Colegio Particular
Rosemaria Galindo de Barrientos (CPRGB) no est al margen de la utilizacin de esta nueva tecnologa,
puesto que la adecuada administracin de la informacin es fundamental para la toma de decisiones.
Respondiendo a sta necesidad de contar con un sistema de informacin, que apoye y agilice al trabajo
habitual del colegio para lograr un buen desempeo en las labores administrativas, se planteo el Sistema
de Control de pago de pensiones de los alumnos del CPRGB .
1.2 Antescedentes
1.2 Antescedentes
Utilizar sistemas de informacin para apoyar las tareas de administracin de control de pago de pensiones
del colegio mencionado. Ya se dio con anterioridad en nuestro medio por lo que se toma como referencia
proyectos que proponen un modelo para la incorporacin de un sistema de informacin para apoyar a la
administracin de control de pago de pensiones.
El colegio se encuentra ubicado en la ciudad de La Paz, Zona Irpavi, que nace en Marzo del 1990 gracias
al Sr. Paz que acepta el desafo de crear un lugar de educacin para nios y jvenes de la zona.
Actualmente el sistema utilizado en el CPRGB es manual, el problema radica en el tratamiento de la
informacin sobre la verificacin de pagos al da para la entrega de notas en kardex, lo cual retrasa la
informacin.
El Colegio Particular CPRGB como unidad educativa, no escapa a esta situacin, por esto surge la
necesidad de un Sistema de Control de pago de pensiones, de tal forma que se pueda tener Informacin
Almacenada y gestionada de manera ptima. Actualmente no cuenta con un proceso de almacenamiento
digital.
1.3 ARBOL DE PROBLEMAS
1.3 ARBOL DE PROBLEMAS

1.3.1 IDENTIFICACIN DEL PROBLEMA
1.3.1 IDENTIFICACIN DEL PROBLEMA
El CPRGB tropieza con dificultades en cuanto al manejo de informacin debido a la aplicacin de
mtodos tradicionales que no dan solucin a los problemas que se mencionan a continuacin:
Generacin de informacin inadecuada e inoportuna, del movimiento econmico del colegio.
Dificultad en la elaboracin de informes en los procesos de pago de pensiones.
Carencia de informacin capaz de generar datos confiables y rpidos de los alumnos, ocasionando
inseguridad en la toma de decisiones.
1.3.2 PLANTEAMIENTO DEL PROBLEMA
Se observa tambin la vulnerabilidad de la seguridad de documentos esto genera la probabilidad de
cometer ms errores en el momento de administrar y registrar dichos pagos. En consideracin a lo
mencionado se propone lo siguiente:
Desarrollar y aplicar un Sistema de Control de pago de pensiones.
Minimizar y descongestionar el accionar operativo en lo que respecta al tiempo y los recursos
humanos?
Ayudara al manejo de la contabilidad?
1.4 OBJETIVOS
1.4.1 OBJETIVO GENERAL
Disear un Sistema de Control de pago de pensiones que sirva para la administracin del colegio CPRGB
, para minimizar y descongestionar el accionar operativo en lo que respecta al tiempo y los recursos
humanos en los procesos de control de informacin que permita mejorar y agilizar los procesos de cobro
de pensiones.
1.4.2 OBJETIVO ESPECFICO
- Automatizar los procesos de pagos de pensiones del estudiante, generacin de reportes institucionales
- Mejorar la manipulacin de informacin y que la misma sea precisa, oportuna, coherente y de alta
calidad.
- Brindar una herramienta que realice el control de ingresos (dinero) a dicha institucin
1.5 ALCANCE
Los lmites del presente proyecto estn enmarcadas dentro de las necesidades encontradas al momento de
haber realizado el estudio respectivo y llegando a la conclusin de realizar una base de datos para el
proceso de cobro como ser:
Modulo de pago y control de pensiones, Control de ingresos, que facilitara el cobro de manera eficiente
y eficaz.
1.6 MTODOS DE INVESTIGACIN
El tipo de estudio que se utilizara en la parte de anlisis y diseo es una investigacin Deductiva y
cuantitativa, mediante visitas al colegio estadsticamente analizaremos los datos extrados ,usando el
metodo de la observacin en el entorno , la cual nos ayudara a obtener informacin para solucionar los
problemas que existen en la institucin , en el colegio CPRGB , podemos utilizar un mejor estudio y asi
encontrar mediante un analisis personal de cada causa una mejor solucin a los problemas detectados.
Las herramientas que se usan para diseo se encuentran enmarcadas en el anlisis estructurado de Edward
Yourdon que ayudan en la abstraccin en el anlisis y diseo.
Entre las herramientas que se utilizan tenemos diagrama de contexto, DFD,diccionario de datos, que
ofrecen una visin de como se comporta la informacin.
1.7 JUSTIFICACIN
El desarrollo de anlisis y diseo para colegios traer un gran beneficio a las personas involucradas
directamente con el CPRGB.
El Director Administrativo (dueo) obtendr la informacin del pago de las pensiones de los estudiantes.
Tambien facilitara las operaciones que realiza el personal administrativo (secretaria) en el cobro de
pensiones.
1.8 PLANIFICACION DE ACTIVIDADES
Para la planificacion usamos diagramas de Gantt.

MODELO ESENCIAL.-
Mediante el anlisis y diseo realizaremos un sistema de Control de pago de pensiones para as facilitar el
cobro en el colegio.
a) MODELO AMBIENTAL.-
Este sistema solo contempla la automatizacin del pago de pensiones y al mismo tiempo contribuye a
mejorar la calidad de atencin que brinda la Unida Educativa.
a1) DECLARACIN DE PROPOSITOS.-
El propsito del sitema de control de pago de pensiones es la de almacenar, recolectar y administrar la
informacin. Dicha informacin requerida por el director administrativo (el dueo del colegio) para el
control de cobro de dinero.
a2) DIAGRAMA DE CONTEXTO.- (NIVEL 0)

a3) LISTA DE ACONTECIMIENTOS.- El Director Administrativo:
- La administracin solicita reporte sobre pago de pensiones.
- La administracin requiere reportes de los Ingresos mensuales.
- La administracin requiere informacin sobre las deudas pendientes que tiene de los estudiantes. -La
secretaria registra pago de pensiones. -La secretaria requiere agilizar el tiempo para el registro de los
pagos. Para que el padre de familia se sienta a gusto con la atencin que su U.E. brinda. -La secretaria
solicita lista de alumnos con mora.
b) MODELO DE COMPORTAMIENTO.-
b1) MODELO PRELIMINAR DE COMPORATAMIENTO.-
NIVEL 1

FIG.0
Fig1: REGISTRO DE PAGO (NIVEL 2)

Fig. 2: SUBSISTEMA DE PAGO DE PENSIONES (NIVEL 3)

Fig.3: VERIFICA PROCESO DE PAGO (NIVEL 4)

Fig.4: OBTENER INFORMACIN DEL ALUMNO (NIVEL 5)

FUNCIONES
Registro de pago: (Nombre_Alumno, Nivel, Curso, Monto a Pagar, Nombre_Tutor)
- Si el nombre del alumno se repite entonces verificamos el nombre del tutor para realizar la operacin de
cancelacin de pago.
- Busca el nombre del alumno para hacer el pago de pensin correspondiente
- Se registra el monto de pago que realizo
Generar Comprobante de pago: (Apellido_Tutor, NIT, MONTO)
- Este comprante servir para su administracin del tutor del alumno.
- Se genera el comprobante una vez que se haya hecho el registro del pago correspondiente.
- Verificando ambas partes, recin se realiza la impresin de este comprobante.
- El comprobante llevar el Apellido del tutor del alumno cada vez que se haga el pago. (No es necesario
que el tutor este presente para cancelar la pensin, ya que puede ser realizado por terceras personas)
Obtener Datos del Alumno: (Nombre_Tutor, Telf._Tutor, Direccin_Tutor, Nombre_Alumno, Nivel,
Curso, Direccin, Certificado_Nac)
- Ac se puede obtener el estado de pensiones del alumno.
- Este podr ser visto mediante la secretaria.
- Tambin podr ser impreso cada vez que se requiera.
Verificar Deudas: (Nombre_alumno, Apellido_Alumno, Nivel, Curso, Monto_Deuda)
- Verificar Deudas Anteriores.
-
Subsistema de pago de pensiones: (Ingresos, Deudas_por_Cobrar, Datos_Alumno)
- Este es para el control del Director Administrativo
- Podr obtener la informacin general de los ingresos que hubo hasta la fecha.
- Podr obtener la informacin general de las deudas que existe hasta esa fecha.
- Se podr saber que alumno son los que deben o estn al da con sus pensiones.
Verificacin de proceso de pago: (Tipo_Plan, Datos_tutor, Nombre_Alumno)
- Elige la opcin de pago. (esto se realiza en el momento de la inscripcin)
- Se verifica que tipo de plan de pago tiene el alumno.
Puede ser que al padre o tutor del alumno le dieron un descuento por el nmero de hijos inscritos en el
colegio.
Puede ser que el padre o tutor hizo el pago anual.
Es becado.
Cancelar Pensin: (Nombre_Alumno, _Nivel, Curso, Nombre_Tutor, Monto_Deuda)
- Se procede a cancelar el monto requerido o fijado por el director
- Se detalla el tipo de pago, y el comprobante de la misma cancelacin
RESTRICCIONES.-
b2) MODELO FINAL DE COMPORTAMIENTO
b3) DIAGRAMA E/R


b4) DICCIONARIO DE DATOS
DICCIONARIO DE DATOS
Id _ alumno = *Identificador nico de alumno*
Paterno+materno+nombre+fecha_nacimiento
Nombre {carcter legal}
Paterno {carcter legal}
Materno {carcter legal}
Fecha_nacimiento = *fecha de nacimiento*
**
Carcter legal [A-Z/a-z]
Id_pensin = *Identificacin de numero de pensin*
(digito-numrico)
Id _ curso = *Identificacin de curso*
(Digito -alfanumrico)
Id_usuario = *identificacin usuario*
(digito-alfanumrico)
Num_pago = [id _ pensin]
Inf_gral_alumno = *datos de alumno en general*
{id_alumno, nombre, paterno, materno.fecha_nacimiento, id_curso, nombre_tutor, paterno_tutor,
materno_tutor, ci_tutor, direccin actual}
Direccion_actual = *datos acerca de la direccin del alumno*
**
Datos usuario = *datos actuales del usuario*
{id_usuario+nombre+paterno+materno+direccin}
Login = *nombre con el que se registra*
**
Pass Word = *contrasea usuario*
**
Datos factura = *descripcin de la factura*
{id_articulo+precio}
Reporte ingreso = *reporte a la administracin sobre ingresos por cobro*
{Total monto}
Reporte pago = *reporte a la administracin sobre pago de mensualidad*
{id_alumno+nombre+paterno+materno+curso+num_pago}
Reporte mora = *reporte a la administracin sobre mora de alumnos*
{id_alumno+nombre+paterno+materno+curso+num_pago}
Respuesta = [*pago anulado* /*no se pudo anular el pago*]
Solicitud = [*reporte de ingreso mensual*/ *reporte de pago de pensin por alumno* /*reporte por mora
por curso*/]
b5) ESPECIFICACIN DE PROCESOS
PROCESO 1.1: REGISTRAR PAGO DE PENSION
COMIENZA
ENCONTRAR alumno en ALUMNO con id_alumno = id_alumno
SI no encuentra registro
Respuesta = No existe Alumno
DESPLEGAR respuesta
SALIR
FIN_SI
ENCONTRAR condicin en CONDICION con id _ condicin= curalumno.id_condicion en cur condicin
ENCONTRAR ultimo _ pago en PENSION con id _ alumno = id _ alumno
CREAR registro de pensin a partir de id_alumno, ultimo_pago+1, curPension.monto
AADIR registro de pensin a PENSION
TERMINAR
PROCESO 1.2: VERIFICAR PAGO
COMIENZA
SI id_pension es recibido
ENCONTRAR id_alumno, id_pension en PENSION con id_alumno = id_alumno, id_pension =
id_pension
SI no encuentra registro
Respuesta = *FALSO*
DEVOLVER respuesta
CASO CONTRARIO
respuesta = *VERDADERO*
DEVOLVER respuesta
FIN_SI
FIN_SI
TERMINAR
CONCLUCIONES:
De acuerdo a la lnea de investigaciones que se eligi se llega a las siguientes conclusiones:
El colegio requiere de un sistema de control de pensiones para la mejor administracin y control de los
ingresos de las pensiones de cada alumno, siendo por excelencia, los instrumentos de contabilidad
mensual, sobre todo cuando se puede medir cuantitati-vamente los resultados del buen manejo del
sistema. Se incorpora en esta corriente la toma de decisiones como factor clave en el diseo del sistema
de control de pensiones teniendo en cuenta variables externas e internas del Colegio.
Tambien se puede sealar que una correcta implantacin del Sistema favorece y facilita el correcto
control del cobro de pensiones por lo cual aportara resultados positivos a nivel econmico en el mismo.
PROPUESTAS.
Se ha propuesto un modelo de planificacin estratgica, el cual requiere un anlisis exhaustivo de la
situacin interna y externa del Colegio del futuro que se quiera para ella, de su misin y objetivos y del
diseo de las polticas apropiadas para cumplir esta misin. Esto requiere un anlisis profundo sobre
cuales son y como son las necesidades del Colegio para el cobro de pensiones, teniendo en cuenta la
situacin actual y las previsiones del futuro de las mismas.
REFERENCIAS BIBLIOGRAFICAS.-
Bueno nosotras ms fuimos investigando mediante tesis:
- SISTEMA DE INFORMACIN PARA EL CONTROL Y SEGUIMIENTO
DE ATENCION AL CLIENTE Autor: Rosemary Merlo Quispe
- SISTEMA DE INFORMACIN VA WEB PARA EL CONTROL DE ALMACENES FBRICA DE
FIDEOS SANTA ROSA Autor: Julia Mamani Mamani.
- TESIS DE LA CARRERA DE INFORMATICA:T-1843, T-1550, T-1456
2. ORIENTADO A OBJETOS
*************************************************************************
**************************************************
CAPITULO II
INTEGRANTES:
* CAROLINA ATANACIO FUENTES
* DELIA JALLASI YUJRA
* MARIA ELENA JIMENEZ CHAVEZ
SISTEMA DE CONTROL DE PAGO DE PENSIONES
PARA COLEGIO PARTICULAR
-> ORIENTADO A OBJETOS




INDICE
CAPITULO I
1.1INTRODUCCIN
1.2 ANTECEDENTES
1.3.2 PLANTEAMIENTO DEL PROBLEMA
1.3.1 IDENTIFICACIN DEL PROBLEMA
1.3.2 ARBOL DE PROBLEMAS
1.4 OBJETIVOS
1.4.1 OBJETIVO GENERAL
1.4.2 OBJETIVO ESPECFICO
1.4.3 ARBOL DE OBJETIVOS
1.5 ALCANCE
1.7 JUSTIFICACIN
CAPITULO II
ANTECEDENTES DE LA ORGANIZACIN
2.1 PARADIGMA ORIENTADO A OBJETOS
2.2 MODELOS DE DESARRROLLO
2.2.1 METODOLOGIA RUP
2.2.2 METODOLOGIA DAS
2.2.3 METODOLOGIA XP
2.3 UML VERSION 2.0
2.4 LENGUAJES DE PROGRAMACIN
2.4.1 ECLIPSE
2.4.2 VISUAL BASIC
2.4.3 C#
2.5 SISTEMAS GESTORES DE BASE DE DATOS
2.5.1 MYSQL
2.5.2 SQL
2.5.3 ORACLE
CAP III
3.1 INTRODUCCION
3.2 FASE DE INICIO
3.3 FASE DE ELABORACIN
CAPITULO I
1.1 INTRODUCCIN
Estamos viviendo en una sociedad de informacin, la tecnologa informtica y el consecuente
incremento de la necesidad de aplicaciones computacionales en organizaciones e instituciones dependen
cada vez ms de la creacin y distribucin de sistemas de informacin a travs de redes locales, internet,
esto con lleva al uso de de las nuevas tecnologas de informacin, por medio de las cuales las
organizaciones consiguen grandes beneficios, como mejorar operaciones, mejor servicio, etc.
El fortalecimiento de los recursos humanos en un pas tiene como una de sus bases la educacin,
lo que hace trascendental el uso de estas nuevas tecnologas lo que proporciona informacin oportuna y
confiable, as como mejoras en su imagen y comunicacin.
El Colegio Particular Rosemaria Galindo de Barrientos (CPRGB) no est al margen del uso de
esta nueva tecnologa, por lo que surge la necesidad de un sistema de control de pago de pensiones, de tal
manera que se pueda tener informacin almacenada, ya que es fundamental para la toma de decisiones.
Respondiendo a sta necesidad de contar con un sistema de informacin, se pretende mejorar el
control de cobro de pensiones del Colegio Privado Rosemaria Galindo de Barrientos, que apoye y agilice
al trabajo habitual del colegio para lograr un buen desempeo en las labores administrativas.
1.2.ANTECEDENTES
El colegio CPRGB (Colegio Privado Rosamara Galindo de Barrientos) se encuentra ubicado en
la ciudad de La Paz, Zona Irpavi, que nace en Marzo del 1990 gracias al Sr. Paz que acepta el desafo de
crear un lugar de educacin para nios y jvenes de la zona.
El colegio GPRGB es una institucin de carcter privado. Es una empresa al servicio de la
educacin. Afiliada a la asociacin de colegios particulares ANDECOP y registrada en las diferentes
instancias jurdicas dependientes del estado cumple con las obligaciones de ley en actual vigencia.
El Colegio Particular CPRGB como unidad educativa, no escapa a esta situacin, por esto surge
la necesidad de un Sistema de Control de pago de pensiones, de tal forma que se pueda tener Informacin
Almacenada y gestionada de manera ptima.
Actualmente no cuenta con un proceso de almacenamiento digital, el problema radica en el tratamiento de
la informacin sobre la verificacin de pagos al da para la entrega de notas en kardex, lo cual retrasa la
informacin.
1.3. PROBLEMTICA EN TRABAJOS SIMILARES
Utilizar sistemas de informacin para apoyar las tareas de administracin de control de pago de pensiones
del colegio mencionado, ya se dio con anterioridad en nuestro medio por lo que se toma como referencia
proyectos que proponen un modelo para la incorporacin de un sistema de informacin para apoyar a la
administracin de control de pago de pensiones:
Sistema de Control disciplinario Colegio San Calixto realizado por Morales Juan en el ao
Seguimiento acadmico Colegio Santa Mara CENAFI, realizado por Nina Pealoza Marco en
el ao 2002.
Sistema de Control y seguimiento acadmico para colegios Caso de estudio: Colegio La
Salle 8 elaborado por Rudy Oliver Saavedra Pereira. El sistema est
orientado para que los padres de familia, directores, profesores y psiclogos, puedan realizar el
control y seguimiento acadmico de los estudiantes en distintas reas de aprendizaje.
Actualmente como se menciono anteriormente no cuenta con un proceso de almacenamiento digital, en el
cobro de pago de pensiones, por lo que los procesos siguen siendo manuales.
1.4. PLANTEAMIENTO DEL PROBLEMA
En la unidad educativa CPRGB se han encontrado dificultades en el manejo de informacin, no se puede
acceder a la informacin de una manera eficiente, ya que la recoleccin de la misma es manual, lo que
dificulta el control.
Para evitar lo mencionado se debe implementar un sistema de control que nos brinde informacin
confiable de forma rpida y automtica, que ayude al control de ingresos (cobro de pago de pensiones).
1.4.1. IDENTIFICACIN DEL PROBLEMA
El CPRGB tropieza con dificultades en cuanto al manejo de informacin debido a la aplicacin de
mtodos tradicionales que no dan solucin a los problemas que se mencionan a continuacin:
Generacin de informacin inadecuada e inoportuna, ya que el registro y cobro de pensiones son
manuales, lo que provoca que el control sea deficiente.
Dificultad en la elaboracin de informes en los procesos de pago de pensiones.
La informacin no es accesible y la falta de informacin no genera datos confiables y rpidos, lo
que dificulta el control de ingreso de dinero, ocasionando inseguridad en la toma de decisiones.
1.4.2. FORMULACIN DEL PROBLEMA
El anlisis y diseo a desarrollar en forma sistemtica en los procesos del colegio:
Podr aplicar controles efectivos y seguimiento al pago de pensiones?
Para evitar todo lo mencionado se debe implementar un sistema que nos brinde informacin precisa, que
ayude al control de ingresos al colegio (pago de pensiones).
1.4.3. ARBOL DE PROBLEMAS

1.5. OBJETIVOS:
1.5.1. OBJETIVO GENERAL
Desarrollar e implementar un Sistema de Control de pago de pensiones que trabaje en un entorno de red
local, que colabore al control y la administracin del colegio privado Rosemaria Galindo de Barrientos
ofreciendo informacin confiable; para agilizar los procesos de cobro de pensiones utilizando
herramientas de anlisis, diseo y desarrollo de sistemas de informacin.
1.5.2. OBJETIVOS ESPECIFICOS
Estudiar modelos de desarrollo para conocer el modo como se interrelacionan metodologas con
estndares y herramientas, que tienen como propsito el diseo y elaboracin de un sistema que realice el
control eficiente y eficaz de ingresos.
Realizar un control centralizado de los ingresos de los procesos de pago de pensiones, mediante
la interaccin de una intranet.
Proporcionar herramientas para un mejor manejo de la informacin, que la misma sea precisa,
oportuna y as facilitar la generacin de reportes.
Realizar pruebas para mejorar el diseo y la elaboracin del sistema.
1.5.3. ARBOL DE OBJETIVOS

1.6. ALCANCES
Los alcances estn enmarcados en la obtencin de resultados en los objetivos secundarios planteados
anteriormente. El sistema a desarrollar esta orientado a:
Mejorar el control y seguimiento sobre el cobro de pensiones de manera eficiente y eficaz.
Facilitar el manejo de la informacin sobre el cobro de pago de pensiones para emitir reportes.
1.7. JUSTIFICACIN
El desarrollo de un sistema de control de pago de pensiones dedicado a tareas especificas, producto del
anlisis diseo y desarrollo de sistemas de informacin, ayudara a solucionar los problemas encontrados
en la institucin, ya que traer un gran beneficio, facilitar las operaciones qu realizan las personas
involucradas directamente con el Colegio Particular Rosemaria Galindo de Barrientos.
1.7.1. JUSTIFICACION TECNICA
El diseo del sistema de control que tiene la finalidad de mejorar la informacin sobre el cobro de
pensiones de manera centralizada, se basar en el uso de la tecnologa actual existente de carcter
gratuito, as como las herramientas de diseo y los lenguajes de programacin.
1.7.2. JUSTIFICACION ECONOMICA
Reducir de gran manera los gastos en los gastos en los que se incurren por errores durante la operaciones
de cobro que se realizan en la institucin adems la funcin del sistema es la de tener un mejor control de
ingresos y mejorar las utilidades.
1.7.3. JUSTIFICACION SOCIAL
El Diseo y desarrollo del sistema mejorara la calidad del servicio hacia los usuarios de la institucin para
que de esta forma se presente una imagen seria, ya que facilitara el registro, almacenamiento y control de
la informacin al personal del rea de cobro de pensiones, as facilitar la comunicacin del usuario con la
institucin.
1.7. CRONOGRAMA

CAPITULO II MARCO TEORICO
2.1 ANTECENDENTES DE LA ORGANIZACION
El CPRGB (Colegio Privado Rosamara Galindo de Barrientos), como unidad de formacin acadmica,
requiere tecnologas que manejen y optimicen el tiempo en el pago de pensiones que realiza un usuario,
y as asegurar la calidad de la misma, para lo cual se ha pensado en un sistema de control de pago de
pensiones, lo cual permitir interactuar con los usuarios procesando sus peticiones.
Se utilizar el organigrama para mostrar en qu nivel dentro de la estructura jerrquica se encuentra el
rea en el cual se desarrolla el sistema de control de pago de pensiones del Colegio Privado Rosamara
Galindo de Barrientos.
La estructura organizativa del CPRGB (Colegio Privado Rosamara Galindo de Barrientos) se halla
configurada de la siguiente manera:
Estructura Orgnica del Colegio Particular Rosemaria Galindo de Barrientos.

2.1 PARADIGMA ORIENTADO A OBJETOS:
Es una tcnica o estilo de programacin que utiliza objetos como bloque fundamental de Construccin.
2.1.1 Elementos bsicos de la POO.
a) Bloques: Son un conjunto complejo de datos (atributos) y funciones (mtodos) que poseen una
determinada Estructura y forman parte de una organizacin. Los atributos definen el estado del objeto; los
mtodos, su comportamiento.
b) Mtodos: Es un programa procedimental que est asociado a un objeto determinado y cuya
ejecucin solo Puede desencadenarse a travs del mensaje correspondiente.
c) Mensajes: Es simplemente una peticin de un objeto a otro para que este se comporte de una
manera Determinada, ejecutando uno de sus mtodos. Los mensajes comunican a los objetos con otros y
con el mundo exterior. A esta tcnica de enviar Mensajes se la conoce como paso de mensajes.
d) Clases: Es un tipo definido por el usuario que determina la estructura de datos y las operaciones
Asociadas con ese tipo. Todos los objetos estn compuestos de tres cosas Interfaz.
e) La Interfaz es el conjunto de mtodos, propiedades, eventos y atributos que se declaran como
pblicos en su alcance y que pueden invocar los programas escritos para usar nuestro objeto
Implementacin Al cdigo dentro de los mtodos se le llama Implementacin. Algunas veces tambin se
le llama comportamiento, ya que este cdigo es el que efectivamente logra que el objeto haga un trabajo
til. Es importante entender que las aplicaciones del cliente pueden utilizar nuestro objeto aunque
cambiemos la implementacin, siempre que no cambiemos la interfaz. Siempre que se mantengan sin
cambio nuestro nombre de mtodo, su lista de parmetro y el tipo de datos de devolucin, podremos
cambiar la implementacin Estado El estado o los datos de un objeto es lo que lo hace diferente de otros
objetos de la misma clase. El estado se describe a travs de las variables del Miembro o de la Instancia.
Las variables del miembro son aquellas declaradas, de tal manera que estn disponibles para todo el
cdigo dentro de la clase. Por lo general, las variables del miembro son Privadas en su alcance. Algunas
veces, se les conoce como variables de la instancia o como atributos.
2.1.2 Caractersticas.
a) Abstraccin: Significa extraer las propiedades esenciales de un objeto que lo distinguen de los
dems tipos de Objetos y proporciona fronteras conceptuales definidas respecto al punto de vista del
observador. Es la capacidad para encapsular y aislar la informacin de diseo y ejecucin.
b) Encapsulamiento: Es el proceso de almacenar en un mismo compartimiento (una caja negra) los
elementos de una Abstraccin (toda la informacin relacionada con un objeto) que constituyen su
estructura y su Comportamiento. Esta informacin permanece oculta tanto para los usuarios como para
otros objetos Y puede ser accedida solo mediante la ejecucin de los mtodos adecuados.
c) Herencia: Es la propiedad que permite a los objetos construirse a partir de otros objetos. La clase
base contiene todas las caractersticas comunes. Las sub-clases contienen las Caractersticas de la clase
base ms las caractersticas particulares de la sub-clase. Si la sub-clase hereda caractersticas de una clase
base, se trata de herencia simple. Si hereda de dos o ms clases base, herencia mltiple.
d) Polimorfismo: Literalmente significa cualidad de tener ms de una forma. En poo, se refiere al
hecho que una Misma operacin puede tener diferente comportamiento en diferentes objetos. En otras
palabras, Diferentes objetos reaccionan al mismo mensaje de modo diferente.
e) Modularidad: Un programa es modular si se compone de mdulos independientes y robustos.
Esto permite la Reutilizacin y facilita la verificacin y depuracin de los mismos. En poo, los mdulos
estn Directamente relacionados con los objetos. Los objetos son mdulos naturales ya que corresponden
A una imagen lgica de la realidad.
f) Jerarqua: La mayora de nosotros ve de manera natural nuestro mundo como objetos que se
relacionan entre s de una manera jerrquica. Por ejemplo, un perro es un mamfero, y los mamferos son
animales, y los animales seres vivos Del mismo modo, las distintas clases de un programa se organizan
mediante la jerarqua. La representacin de dicha organizacin da lugar a los denominados rboles de
herencia Mediante la herencia una clase hija puede tomar determinadas propiedades de una clase padre.
As se simplifican los diseos y se evita la duplicacin de cdigo al no tener que volver a codificar
mtodos ya implementacin Al acto de tomar propiedades de una clase padre se denomina heredar.
2.1.3 Herencia y polimorfismo
a) Herencia: Herencia es la propiedad de que los ejemplares de una clase hija extiendan el
comportamiento y los datos asociados a las clases paternas. La herencia es siempre transitiva, es decir que
una sub-clase hereda caractersticas de superclases alejadas muchos niveles. Reusabilidad del software
Cuando el comportamiento se hereda de otra clase, no es necesario reescribir el cdigo que lo define.
Comparticin de cdigo. Muchos usuarios o proyectos distintos pueden usar las mismas clases. Por otro
lado, la herencia reduce el tiempo de escritura y el tamao final del programa. Consistencia de la interfaz.
El comportamiento de una clase madre que heredan todas sus clases hijas ser el mismo, de esta manera
se asegura que las interfaces para objetos sern similares y no solo un conjunto de objetos que son
parecidos pero que actan e interactan de forma diferente.
b) Polimorfismo Poli (muchas)-morphus (formas): Mismo servicio (interfaz) en distintos tipos de
objetos, donde c/u responde de acuerdo a su propia naturaleza (implementacin. Beneficios: Cdigo m
genrico .Permite al programador generar componentes reutilizables de alto nivel que puedan adaptarse a
diferentes aplicaciones mediante el cambio de sus partes de bajo nivel. Genrico. Maximiza la calidad de
rehus y extensibilidad.
2.1.4 Otras propiedades: El modelo objeto ideal no solo tiene las propiedades anteriormente citadas sino
que es conveniente que soporte, adems, estas otras propiedades.
a) Concurrencia (multitarea): el lenguaje soporta la creacin de procesos paralelos independientes
del sistema operativo. Esta propiedad simplificar la transportabilidad de un sistema de tiempo real de una
plataforma a otra. Se dice que dos o ms procesos son concurrentes si estn construidos de manera tal
que pueden ejecutarse al mismo tiempo y compartiendo recursos.
b) Persistencia: los objetos deben poder ser persistentes; es decir, los objetos han de poder
permanecer despus de la ejecucin del programa.
c) Genericidad: las clases parametrizadas (mediante plantillas o unidades genricas) sirven para
soportar un alto grado de reutilizacin. Estos elementos genricos se disean con parmetros formales,
que se instanciaran con parmetros reales, para crear instancias de mdulos que se compilan y enlazan, y
ejecutan posteriormente.
d) Manejo de Excepciones: se deben poder detectar, informar y manejar condiciones excepcionales
utilizando construcciones del lenguaje.
2.2. MODELOS DE DESARROLLO:
1. Introduccin
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino gil, aplicado al
desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del software,
incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar
los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y
respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados
por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades
desarrolladas.
Para asegurar el xito durante el desarrollo de software no es suficiente contar con notaciones de
modelado y herramientas, hace falta un elemento importante: la metodologa de desarrollo, la cual nos
provee de una direccin a seguir para la correcta aplicacin de los dems elementos. Generalmente el
proceso de desarrollo llevaba asociado un marcado nfasis en el control del proceso mediante una
rigurosa definicin de roles, actividades y artefactos, incluyendo modelado y documentacin detallada.
Este esquema tradicional para abordar el desarrollo de software ha demostrado ser efectivo y necesario
en proyectos de gran tamao (respecto a tiempo y recursos), donde por lo general se exige un alto grado
de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el ms adecuado para muchos de los
proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir
drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las dificultades para
utilizar metodologas tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de
desarrollo se resignan a prescindir de las buenas prcticas de la Ingeniera del Software, asumiendo el
riesgo que ello conlleva. En este contexto, las metodologas giles emergen como una posible respuesta
para llenar ese vaco metodolgico. Por estar especialmente orientadas para proyectos pequeos, las
Metodologas giles constituyen una solucin a medida para ese entorno, aportando una elevada
simplificacin que a pesar de ello no renuncia a las prcticas esenciales para asegurar la calidad del
producto.
2. Por qu usar Metodologas giles
Las metodologas tradicionales presentan los siguientes problemas a la hora de abordar proyectos:
Existen unas costosas fases previas de especificacin de requisitos, anlisis y diseo. La
correccin durante el desarrollo de errores introducidos en estas fases ser costosa, es decir, se pierde
flexibilidad ante los cambios.
El proceso de desarrollo est encorsetado por documentos firmados.
El desarrollo es ms lento. Es difcil para los desarrolladores entender un sistema complejo en su
globalidad.
Las metodologas giles de desarrollo estn especialmente indicadas en proyectos con requisitos poco
definidos o cambiantes. Estas metodologas se aplican bien en equipos pequeos que resuelven problemas
concretos, lo que no est reido con su aplicacin en el desarrollo de grandes sistemas, ya que una
correcta modularizacin de los mismos es fundamental para su exitosa implantacin. Dividir el trabajo en
mdulos abordables minimiza los fallos y el coste. Las metodologas giles presentan diversas ventajas,
entre las que podemos destacar:
1. Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo
2. Entrega continua y en plazos breves de software funcional
3. Trabajo conjunto entre el cliente y el equipo de desarrollo
4. Importancia de la simplicidad, eliminado el trabajo innecesario
5. Atencin contina a la excelencia tcnica y al buen diseo
6. Mejora continua de los procesos y el equipo de desarrollo
2.2.1 RUP:
1. Introduccin al RUP
Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Rational) es un
producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar
tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar la produccin
del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y
tiempo establecidos.
2. Dimensiones del RUP
El RUP tiene dos dimensiones: El eje horizontal representa tiempo y demuestra los aspectos del ciclo
de vida del proceso. El eje vertical representa las disciplinas, que agrupan actividades definidas
lgicamente por la naturaleza. La primera dimensin representa el aspecto dinmico del proceso y se
expresa en trminos de fases, de iteraciones, y la finalizacin de las fases. La segunda dimensin
representa el aspecto esttico del proceso: cmo se describe en trminos de componentes de proceso, las
disciplinas, las actividades, los flujos de trabajo, los artefactos, y los roles. En la figura 1 se puede
observar como vara el nfasis de cada disciplina en un cierto plazo en el tiempo, y durante cada una de
las fases. Por ejemplo, en iteraciones tempranas, pasamos ms tiempo en requerimientos, y en las ltimas
iteraciones pasamos ms tiempo en poner en prctica la realizacin del proyecto en s.

Figura 1. Disciplinas, fases, iteraciones del RUP
Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP:
a) Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilizacin de los Casos de Uso
para el desenvolvimiento y desarrollo de las disciplinas con los artefactos, roles y actividades necesarias.
Los Casos de Uso son la base para la implementacin de las fases y disciplinas del RUP.
a. Un Caso de Uso es una secuencia de pasos a seguir para la realizacin de un fin o propsito, y se
relaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia de pasos que
conlleva la realizacin e implementacin de un Requerimiento planteado por el Cliente.
b) Proceso Iterativo e Incremental: Es el modelo utilizado por RUP para el desarrollo de un
proyecto de software. Este modelo plantea la implementacin del proyecto a realizar en Iteraciones, con
lo cual se pueden definir objetivos por cumplir en cada iteracin y as poder ir completando todo el
proyecto iteracin por iteracin, con lo cual se tienen varias ventajas, entre ellas se puede mencionar la de
tener pequeos avances del proyectos que son entregables al cliente el cual puede probar mientras se est
desarrollando otra iteracin del proyecto, con lo cual el proyecto va creciendo hasta completarlo en su
totalidad. Este proceso se explica ms adelante a detalle.
c) Proceso Centrado en la Arquitectura: Define la Arquitectura de un sistema, y una arquitectura
ejecutable construida como un prototipo evolutivo.
Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes. Una arquitectura
ejecutable es una implementacin parcial del sistema, construida para demostrar algunas funciones y
propiedades. RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un
prototipo evolutivo.
II. FASES
El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales (figura 2). En cada
extremo de una fase se realiza una evaluacin (actividad: Revisin del ciclo de vida de la finalizacin de
fase) para determinar si los objetivos de la fase se han cumplido. Una evaluacin satisfactoria permite que
el proyecto se mueva a la prxima fase.

Fig. 2Fases del RUP
Planeando las fases
El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del
producto, cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de
iteraciones, estas fases son:
1. Concepcin, Inicio o Estudio de oportunidad
- Define el mbito y objetivos del proyecto
- Se define la funcionalidad y capacidades del producto
2. Elaboracin
- Tanto la funcionalidad como el dominio del problema se estudian en profundidad
- Se define una arquitectura bsica
- Se planifica el proyecto considerando recursos disponibles
3. Construccin
- El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de
anlisis, diseo e implementacin
- Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de
manera incremental conforme se construye (se permiten cambios en la estructura)
- Gran parte del trabajo es programacin y pruebas.
- Se documenta tanto el sistema construido como el manejo del mismo.
- Esta fase proporciona un producto construido junto con la documentacin
4. Transicin
- Se libera el producto y se entrega al usuario para un uso real.
- Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin,
entrenamiento, soporte, mantenimiento, etc.
- Los manuales de usuario se completan y refinan con la informacin anterior
- Estas tareas se realizan tambin en iteraciones
Todas las fases no son idnticas en trminos de tiempo y esfuerzo. Aunque esto vara considerablemente
dependiendo del proyecto, un ciclo de desarrollo inicial tpico para un proyecto de tamao mediano debe
anticipar la distribucin siguiente el esfuerzo y horario:

En un ciclo evolutivo, las fases de concepcin y elaboracin seran considerablemente ms pequeas.

Algunas herramientas que pueden automatizar una cierta porcin del esfuerzo de la fase de Construccin
pueden atenuar esto, haciendo que la fase de construccin sea mucho ms pequea que las fases de
concepcin y elaboracin juntas. Este es precisamente el objetivo del trabajo.
Cada paso con las cuatro fases produce una generacin del software. A menos que el producto muera,
se desarrollar nuevamente repitiendo la misma secuencia las fases de concepcin, elaboracin,
construccin y transicin, pero con diversos nfasis cada fase. Estos ciclos subsecuentes se llaman los
ciclos de la evolucin. Mientras que el producto pasa durante varios ciclos, se producen las nuevas
generaciones.

III. Ciclo evolutivo en la elaboracin de software basado en el RUP
Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por el usuario, cambios en el
contexto del usuario, cambios en la tecnologa subyacente, reaccin a la competicin, etctera. Los ciclos
evolutivos tienen tpicamente fases de concepcin y elaboracin mucho ms cortas, puesto que la
definicin y la arquitectura bsicas del producto son determinadas por los ciclos de desarrollo anteriores.
Las excepciones a esta regla son los ciclos evolutivos en los cuales ocurre o surge un producto
significativo o una redefinicin arquitectnica.
1. Esfuerzo respecto de los flujos de trabajo
De forma vertical se muestra el esfuerzo que se tiene que realizar por cada una de las disciplinas o flujos
de trabajo, y los dos porcentajes que se muestran de forma horizontal son para todo el proyecto.
Explicando mas puntualmente se puede observar en la figura que para la obtencin de requerimientos o
requisitos en la fase de concepcin se empiezan a obtener, en la fase de elaboracin tiene su auge y va
declinando en la fase de construccin, realizar todo esto requiere aproximadamente un 15% de esfuerzo, y
as sucesivamente con las dems disciplinas. En esta seccin y la siguiente, los porcentajes pueden variar
de un proyecto a otro.

2. Esfuerzo respecto de las fases
El esfuerzo realizado por cada fase en forma general e incluyendo las iteraciones dentro de cada fase; y en
la segunda fila, la duracin que tiene aproximadamente en porcentajes del tiempo total del proyecto para
cada una de las fases incluyendo todas las iteraciones que conlleven realizar cada fase. Explicando ms
puntualmente una pequea parte de la figura se puede observar que para la fase de construccin se tiene
que dedicar ms esfuerzo y mayor duracin, siempre y cuando dependiendo de qu disciplina estemos
ejecutando, por ejemplo en la disciplina de implementacin se tiene mucho auge en la fase de
construccin.

3. Iteraciones
El RUP maneja el proceso Iterativo Incremental para el desarrollo de las aplicaciones o proyectos, por tal
motivo es de suma importancia explicar brevemente en qu consiste este proceso.
4. Proceso Iterativo e Incremental
Este proceso se refiere a la realizacin de un ciclo de vida de un proyecto y se basa en la evolucin de
prototipos ejecutables que se muestran a los usuarios y clientes. En este ciclo de vida iterativo a cada
iteracin se reproduce el ciclo de vida en cascada a menor escala, estableciendo los objetivos de una
iteracin en funcin de la evaluacin de las iteraciones precedentes y las actividades se encadenan en una
mini-cascada con un alcance limitado por los objetivos de la iteracin. En la figura 7 se muestran los
pasos a realizar para seguir el ciclo de vida iterativo incremental, hasta la realizacin de una fase.

Para la realizacin de cada iteracin se tiene que tomar en cuenta la planificacin de la iteracin,
estudiando los riesgos que conlleva su realizacin, tambin incluye el anlisis de los casos de uso y
escenarios, el diseo de opciones arquitectnicas, la codificacin y pruebas, la integracin gradual
durante la construccin del nuevo cdigo con el existente de iteraciones anteriores, la evaluacin de la
entrega ejecutable (evaluacin del prototipo en funcin de las pruebas y de los criterios definidos) y la
preparacin de la entrega (documentacin e instalacin del prototipo). Algunos de estos elementos no se
realizan en todas las fases. Para la realizacin de cada iteracin se tiene que tomar en cuenta la
planificacin de la iteracin, estudiando los riesgos que conlleva su realizacin, tambin incluye el
anlisis de los casos de uso y escenarios, el diseo de opciones arquitectnicas, la codificacin y pruebas,
la integracin gradual durante la construccin del nuevo cdigo con el existente de iteraciones anteriores,
la evaluacin de la entrega ejecutable (evaluacin del prototipo en funcin de las pruebas y de los
criterios definidos) y la preparacin de la entrega (documentacin e instalacin del prototipo). Algunos de
estos elementos no se realizan.
5. Comparacin entre 2 enfoques
El ciclo de Cascada, en el cual cada disciplina se realiza al finalizar su predecesora y solo al finalizar la
nueva se empieza la sucesora y hasta terminar con las disciplinas necesarias.

El ciclo de vida de un software siguiendo el enfoque Iterativo Incremental (utilizado por el RUP), en el
cual se puede observar que en cada iteracin se realiza una pequea parte de cada disciplina en paralelo,
aumentando poco a poco hasta concluir con la realizacin, todas las disciplinas con un numero de
iteraciones prudente.

6. Disciplinas
Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminacin
de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias
son las necesarias para la realizacin de un proyecto de software, aunque para proyectos no muy grandes
se pueden omitir algunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, Anlisis y
Diseo, Implementacin, Pruebas, Despliegue. Las de apoyo son las que como su nombre lo indica sirven
de apoyo a las primarias y especifican otras caractersticas en la realizacin de un proyecto de software;
entre estas se tienen: Entorno, Gestin del Proyecto, Gestin de Configuracin y Cambios. A
continuacin se describe rpidamente cada una de estas disciplinas.
IV. MODELADO DEL NEGOCIO
Esta disciplina tiene como objetivos comprender la estructura y la dinmica de la organizacin,
comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio.
Utiliza el Modelo de CU del Negocio para describir los procesos del negocio y los clientes, el Modelo de
Objetos del Negocio para describir cada CU del Negocio con los Trabajadores, adems utilizan los
Diagramas de Actividad y de Clases.
1. Requerimientos Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer
(Especificar Requisitos), definir los lmites del sistema, y una interfaz de usuario, realizar una estimacin
del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los
CU, Actores y Relaciones, adems utiliza los diagramas de Estados de cada CU y las especificaciones
suplementarias.
2. Anlisis y diseo Esta disciplina define la arquitectura del sistema y tiene como objetivos
trasladar requisitos en especificaciones de implementacin, al decir anlisis se refiere a transformar CU
en clases, y al decir diseo se refiere a refinar el anlisis para poder implementar los diagramas de clases
de anlisis de cada CU, los diagramas de colaboracin de de cada CU, el de clases de diseo de cada CU,
el de secuencia de diseo de CU, el de estados de las clases, el modelo de despliegue de la arquitectura.
3. Implementacin
Esta disciplina tiene como objetivos implementar las clases de diseo como componentes (ej. fichero
fuente), asignar los componentes a los nodos, probar los componentes individualmente, integrar los
componentes en un sistema ejecutable (enfoque incremental). Utiliza el Modelo de Implementacin,
conjuntamente los Diagramas de Componentes para comprender cmo se organizan los Componentes y
dependen unos de otros.
4. Pruebas Esta disciplina tiene como objetivos verificar la integracin de los componentes (prueba
de integracin), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar
que los defectos detectados han sido resueltos antes de la distribucin.
5. Despliegue Esta disciplina tiene como objetivos asegurar que el producto est preparado para el
cliente, proceder a su entrega y recepcin por el cliente. En esta disciplina se realizan las actividades de
probar el software en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, as como la
tarea de ensear al usuario.
6. Gestin y configuracin de cambios Es esencial para controlar el nmero de artefactos
producidos por la cantidad de personal que trabajan en un proyecto conjuntamente. Los controles sobre
los cambios son de mucha ayuda ya que evitan confusiones costosas como la compostura de algo que ya
se haba arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos
de los siguientes tipos de problemas:
Actualizacin simultnea: Es la actualizacin de algo elaborado con anterioridad, sin saber que
alguien ms lo est actualizando.
Notificacin limitada: Al realizar alguna modificacin, no se deja informacin sobre lo que se
hizo, por lo tanto no se sabe quien, como, y cuando se hizo.
Versiones mltiples: No saber con exactitud, cual es la ltima versin, y al final no se tiene un
orden sobre que modificaciones se han realizado a las diversas versiones.
7. Gestin del proyecto Su objetivo es equilibrar los objetivos competitivos, administrar el riesgo,
y superar restricciones para entregar un producto que satisface las necesidades de ambos clientes con
xito (los que pagan el dinero) y los usuarios. Con la Gestin del Proyecto se logra una mejora en el
manejo de una entrega exitoso de software. En resumen su propsito consiste en proveer pautas para:
Administrar proyectos de software intensivos.
Planear, dirigir personal, ejecutar acciones y supervisar proyectos.
Administrar el riesgo.
Sin embargo, esta disciplina no intenta cubrir todos los aspectos de direccin del proyecto. Por
ejemplo, no cubre problemas como:
Administracin de personal: contratando, entrenando, enseando.
Administracin del presupuesto: definiendo, asignando.
Administracin de los contratos con proveedores y clientes.
8. Entorno Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que
engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo de las pautas
que apoyan un proyecto. Su propsito es proveer a la organizacin que desarrollar el software, un
ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software.
9. Organizacin y elementos en RUP: Ya conociendo varias partes del RUP nos concentraremos
ahora en los elementos que lo componen, entre estos se tienen: Flujos de Trabajo, Detalle de los Flujos de
Trabajo, Actores, Actividades y Artefactos. En la figura 10 se muestran ms claramente como se
representan grficamente cada uno de estos elementos y la interrelacin entre ellos. Se puede observar
que el Flujo de Trabajo de Requerimientos conlleva varios pasos, cada uno de estos pasos tiene asociado
uno o varios actores, los cuales a su vez son los encargados de la ejecucin de varias actividades, las
cuales a la vez estn definidas artefactos o guas para su realizacin.

V. Actores o roles
Son los personajes encargados de la realizacin de las actividades definidas dentro de los flujos de trabajo
de cada una de las disciplinas del RUP, estos actores se dividen en varias categoras: Analistas,
Desarrolladores, Probadores, Encargados, Otros actores. A continuacin se presenta una lista de actores
de acorde a las categoras mencionadas con anterioridad:
1. Analistas
a. Analista del Proceso del Negocio.
b. Diseador del Negocio.
c. Revisor del Modelo del Negocio.
d. Revisor de Requerimientos Analista del Sistema.
e. Especificador de Casos de Uso.
f. Diseador de Interfaz del Usuario
2. Desarrolladores Arquitecto Revisor de la Arquitectura Diseador de Cpsulas Revisor del
Cdigo y Revisor del Diseo Diseador de la Base de Datos Diseador Implementador y un Integrador
3. Probadores Profesionales Diseador de Pruebas Probador
4. Encargados Encargado de Control del Cambio Encargado de la Configuracin Encargado del
Despliegue Ingeniero de Procesos Encargado de Proyecto Revisor de Proyecto
5. Otros Cualquier trabajador Artista Grfico Stakeholder Administrador del Sistema Escritor
tcnico Especialista de Herramientas
6. Artefactos Los artefactos son el resultado parcial o final que es producido y usado por los
actores durante el proyecto. Son las entradas y salidas de las actividades, realizadas por los actores, los
cuales utilizan y van produciendo estos artefactos para tener guas. Un artefacto puede ser un documento,
un modelo o un elemento de modelo.
VI. Conjuntos de artefactos Se tiene un conjunto de artefactos definidos en cada una de las disciplinas y
utilizadas dentro de ellas por lo actores para la realizacin de las mismas, a continuacin se definen cada
una de estas categoras o grupos de artefactos dentro de las disciplinas del RUP:
a) Modelado del negocio
Los artefactos del modelado del negocio capturan y presentan el contexto del negocio del sistema. Los
artefactos del modelado del negocio sirven como entrada y como referencia para los requisitos del
sistema.
b) Requerimientos
Los artefactos de requerimientos del sistema capturan y presentan la informacin usada en definir las
capacidades requeridas del sistema.
c) Anlisis y diseo del sistema
Los artefactos para el anlisis y del diseo capturan y presenta la informacin relacionada con la solucin
a los problemas se presentaron en los requisitos fijados.
d) Implementacin
Los artefactos para la implementacin capturan y presentan la realizacin de la solucin presentada en el
anlisis y diseo del sistema.
e)Pruebas
Los artefactos desarrollados como productos de las actividades de prueba y de la evaluacin son
agrupadas por el actor responsable, con el cual se lleva un conjunto de documentos de informacin sobre
las pruebas realizadas y las metodologas de pruebas aplicadas.
f) Despliegue
Los artefactos del despliegue capturan y presentan la informacin relacionada con la transitividad del
sistema, presentada en la implementacin en el ambiente de la produccin.
g) Administracin del proyecto
El conjunto de artefactos de la administracin del proyecto capturan los artefactos asociados con el
proyecto, el planeamiento y a la ejecucin del proceso.
h) Administracin de cambios y configuracin
Los artefactos de la configuracin y administracin del cambio capturan y presentan la informacin
relacionada con la disciplina de configuracin y administracin del cambio.
i) Entorno o ambiente
El conjunto de artefactos del ambiente presentan los artefactos que se utilizan como direccin a travs del
desarrollo del sistema para asegurar la consistencia de todos los artefactos producidos.
VII. Grado de finalizacin de artefactos.- Consiste en cuanto hemos finalizado del artefacto propuesto,
con esto nos referimos por ejemplo, si definimos que vamos a utilizar un artefacto, este nos dice los
lineamientos que necesita para ser completado, por lo tanto con grado de finalizacin nos referimos a
cuntos de esos lineamientos del artefacto hemos completado o llenado, esto en cada una de las
disciplinas, de acorde a la fase en que se encuentre, para entender de mejor manera lo antes dicho se
muestra en la figura, en la cual se puede observar que en la fase de Concepcin, en la disciplina de
Implementacin del Sistema los artefactos tienen una poca finalizacin y van aumentando
progresivamente en cada fase hasta llegar a su culminacin en la fase de Transicin, en la disciplina de
Ingeniera del Negocio los artefactos tienen una media finalizacin y sucede lo mismo que con los
artefactos de la disciplina anterior los cuales finalizan tambin en la fase de Transicin.

Con esto se puede mostrar el aumento progresivo de los artefactos en cada disciplina en la fase dada,
teniendo una idea un poco ms amplia sobre el desenvolvimiento del proyecto hablando en trminos de
sus artefactos.
2.2.2. METODOLOGA GIL ASD (Adaptive Software Development)
1. Introduccin
Metodologa gil desarrollada por jim highsmith, despus de trabajar muchos aos con metodologas
predictivas concluyo que son defectuosas.
Metodologas sin muchas ataduras y reglas a seguir, es la metodologa ms abierta.
Las personas deben colaborar de la mejor manera, para dar respuesta y soluciones creativas.
Esta metodologa se adapta al cambio en lugar de luchar con l. Se basa en la adaptacin continua a
circunstancias cambiantes.
En ella no hay un ciclo de planificacin, diseo, construccin del software, sino un ciclo especular,
colaborar, aprender.
2. Definicin
El mtodo gil ASD desarrollo Adaptable de Software es un modelo de implementacin para desarrollo
de software. Al igual que otras metodologas agiles, su funcionamiento es cclico y reconoce que en cada
iteracin se producirn cambios e incluso errores.
3. Caractersticas
Sus principales caractersticas del ASD son:
Iterativo,
Orientado a los componentes de software,
Tolerante a los cambios,
Guiados por los riesgos,
La revisin de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de
desarrollo.
4. Ciclo de vida
El ciclo de vida del ASD se basa en:
Especulacin.- Es donde se inicia y se planifican las caractersticas del Software.
Colaboracin.- Se desarrollan las caractersticas del Software.
Aprendizaje.- Se revisa la calidad, y si no tiene errores se entrega al cliente.
Hay ausencia de estudios de casos del mtodo adaptativo, aunque las referencias literarias a sus principios
son abundantes. Como ASD no constituye un mtodo de ingeniera de ciclo de vida sino una visin
cultural o una epistemologa, no califica como framework suficiente para articular un proyecto. Ms
visible es la participacin de Highsmith en el respetado Cutter Consortium, del cual es director del Agile
Project Management Advisory Service. Entre las empresas que han requerido consultora adaptativa se
cuentan AS Bank de Nueva Zelanda, CNET, GlaxoSmithKline, Landmark, Nextel, Nike, Phoenix
International Health, Thoughworks y Microsoft.
Ventajas
Sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo,
Utiliza informacin acerca de cambios para mejorar el comportamiento del software,
Promulga colaboracin, la interaccin de personas,
Anticipa cambios y trata automticamente con ellos.
Desventajas
Los errores o cambios que no son detectados en reuniones anteriores a tiempo afecta tanto a la
calidad del producto como a su costo total,
Dado a que es una metodologa gil implica no realizar procesos que son requeridos en las
metodologas tradicionales o por lo menos no realizados en diferentes procesos.
2.2.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD
DSDM es la nica de las metodologas aqu planteadas surgida de un Consorcio, formado originalmente
por 17 miembros fundadores en Enero de 1994. El objetivo del Consorcio era producir una metodologa
de dominio pblico que fuera independiente de las herramientas y que pudiera ser utilizado en proyectos
de tipo RAD (Rapid Application Development). El Consorcio, tomando las best practices que se conocan
en la industria y la experiencia trada por sus fundadores, liber la primera versin de DSDM a principios
de 1995. A partir de ese momento el mtodo fue bien acogido por la industria, que empez a utilizarlo y a
capacitar a su personal en las prcticas y valores de DSDM. Debido a este xito, el Consorcio comision
al Presidente del Comit Tcnico, Jennifer Stapleton, la creacin de un libro que explorara la realidad de
implementar el mtodo.
Dado el enfoque hacia proyectos de caractersticas RAD esta metodologa encuadra perfectamente en el
movimiento de metodologas giles. La estructura del mtodo fue guiada por estos nueve principios:
1. El involucramiento del usuario es imperativo.
2. Los equipos de DSDM deben tener el poder de tomar decisiones.
3. El foco est puesto en la entrega frecuente de productos.
4. La conformidad con los propsitos del negocio es el criterio esencial para la aceptacin de los
entregables.
5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin del
negocio.
6. Todos los cambios durante el desarrollo son reversibles.
7. Los requerimientos estn especificados a un alto nivel.
8. El testing es integrado a travs del ciclo de vida.
9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial.
DSDM define cinco fases en la construccin de un sistema ver (Figura N8). Las mismas son: estudio
de factibilidad, estudio del negocio, iteracin del modelo funcional, iteracin del diseo y construccin,
implantacin. El estudio de factibilidad es una pequea fase que propone DSDM para determinar si la
metodologa se ajusta al proyecto en cuestin. Durante el estudio del negocio se involucra al cliente de
forma temprana, para tratar de entender la operatoria que el sistema deber automatizar. Este estudio
sienta las bases para iniciar el desarrollo, definiendo las Caractersticas de alto nivel que deber contener
el software. Posteriormente, se inician las iteraciones durante las cuales: se bajar a detalle las
caractersticas identificados anteriormente, se realizar el diseo de los mismos, se construirn los
componentes de software, y se implantar el sistema en produccin previa aceptacin del cliente.
Desde mediados de la dcada de 1990 hay abundantes estudios de casos, sobre todo en Gran Bretaa, y la
adecuacin de DSDM para desarrollo rpido est suficientemente probada. El equipo mnimo de DSDM
es de dos personas y puede llegar a seis, pero puede haber varios equipos en un proyecto. El mnimo de
dos personas involucra que un equipo consiste de un programador y un usuario. El mximo de seis es el
valor que se encuentra en la prctica. DSDM se ha aplicado a proyectos grandes y pequeos. La
precondicin para su uso en sistemas grandes es su particin en componentes que pueden ser
desarrollados por equipos normales.
Figura N8. Fases del Proceso de Desarrollo de DSDM
Se ha elaborado en particular la combinacin de DSDM con XP y se ha llamado a esta mixtura
EnterpriseXP, trmino acuado por Mike Griffiths de Quadrus Developments . Se atribuye a Kent Beck
haber afirmado que la comunidad de DSDM ha construido una imagen corporativa mejor que la del
mundo XP y que sera conveniente aprender de esa experiencia. Tambin hay documentos conjuntos de
DSDM y Rational, con participacin de Jennifer Stapleton, que demuestran la compatibilidad del modelo
DSDM con RUP, a despecho de sus fuertes diferencias terminolgicas.
Tambin hay casos de xito (particularmente el de Fujitsu European Repair Centre) en que se emplearon
Visual Basic como lenguaje, SQL Server como base de datos y Windows como plataforma de desarrollo e
implementacin.
Descontando la primera fase que es realizada una nica vez al principio del proyecto para analizar la
factibilidad desde el punto de vista del negocio del desarrollo, las dems fases presentan las
caractersticas del modelo iterativo e incremental ya tratado. Sin embargo, lo que diferencia a DSDM de
dicho modelo son los principios alrededor de los cuales se estructura y que hacen nfasis en los equipos
de desarrollo, en el feedback con el cliente, en las entregas frecuentes de productos.
Para resolver la cuestin de la aplicabilidad de DSDM a un proyecto convendr responder las siguientes
preguntas:
Ser la funcionalidad razonablemente visible en la interface del usuario?
Se pueden identificar todas las clases de usuarios finales?
Es la aplicacin computacionalmente compleja?
Es la aplicacin potencialmente grande? Si lo es, puede ser particionada en componentes funcionales
ms pequeos?
Est el proyecto realmente acotado en el tiempo?
Son los requerimientos flexibles y slo especificados a un alto nivel?
Las mismas refieren a las caractersticas que se deben cumplir en los proyectos para poder utilizar el
enfoque RAD de construccin. Se observa que aquellos proyectos que califiquen afirmativamente de
acuerdo a dichas preguntas tendrn las siguientes caractersticas que refieren a la aplicabilidad de DSDM:
a. Son proyectos interactivos con la funcionalidad visible en la interfase de usuario
b. De baja o media complejidad computacional
c. Particionables en componentes de funcionalidad ms pequeos si la aplicacin es de gran
tamao
d. Acotados en el tiempo
e. Con flexibilidad en los requerimientos
f. Con un grupo de usuarios bien definidos y comprometidos al proyecto
De esta forma observamos que DSDM deja las bases sentadas para el anlisis sobre su aplicabilidad a un
espectro bien definido de proyectos de software. Sin embargo, la metodologa no tiene ninguna
prescripcin respecto a las tcnicas a ser usadas en el proyecto, ni siquiera impone el desarrollo bajo un
paradigma especfico funciona tanto para el modelo de orientacin a objetos como para el modelo
estructurado. Algo que s sugiere el mtodo es la generacin de un conjunto mnimo de modelos
necesarios para la sana progresin de la entrega del software y facilidad en el mantenimiento. Estos
modelos esenciales debern ser definidos antes que comience el desarrollo, y debern ser revisados en las
sucesivas iteraciones para validad su contenido.
El concepto de timebox es algo que est embebido en DSDM y en todas las metodologas giles, en las
cuales tambin se conocen como iteracin, ciclo, intervalo. La consecuencia de utilizarlos es el feedback
(realimentacin) frecuente que brinda visibilidad a los stakeholders(Grupos de presin) para que
verifiquen el progreso y puedan tomar acciones correctivas a tiempo. Tambin permiten controlar la
calidad de los productos intermedios que se van generando, y realizar estimaciones de esfuerzo ms
precisas. Asimismo, cada timebox esta compuesta por actividades definidas en relacin a entregables en
vez de tareas.
Cada entregable generado durante el mismo es testeado/revisado dentro del mismo timebox.
En DSDM, un timebox consta de tres fases que son: Investigacin, Refinamiento y Consolidacin.
Durante la Investigacin se chequean que las actividades que componen el timebox se condicen con la
arquitectura del sistema. Esta es una fase de carcter exploratorio, en la que se fijan los objetivos de la
iteracin, los entregables a ser producidos, efectundose revisiones sobre las iteraciones anteriores a la
actual. La siguiente fase, Refinamiento, consiste en la produccin propiamente dicha de los artefactos
planificados. DSDM destaca la necesidad de colocar componentes de distinta prioridad en un mismo
timebox, de manera de poder posponer a futuras iteraciones aquellos con menor prioridad, en caso que
surjan imprevistos o se materialicen riesgos.
Finalmente, la fase de Consolidacin consiste en completar los entregables, verificando la calidad de los
mismos. En esta fase que posee el hito de finalizacin del timebox se demostrar que se satisficieron los
requerimientos de calidad definidos durante la Investigacin.
DSDM incluye roles claves en relacin al management(direccin) del proyecto. Identifica al visionario
como el encargado de asegurar que se satisfacen las necesidades del negocio; el usuario embajador que
equivaldra al on-site customer(Cliente) de XP, que brinda el conocimiento del negocio y define los
requerimientos del software; el coordinador tcnico que es la persona encargada de mantener la
arquitectura y verificar la consistencia de los componentes construidos respecto a esta y al cumplimiento
de los estndares tcnicos.
Algunas tcnicas sugeridas en DSDM son las sesiones JAD para capturar los requerimientos del software
y la realizacin de prototipos para descifrar aquellas ambigedades que se presentan en el relevamiento y
tambin para derribar las barreras comunicacionales entre analistas y usuarios. El enfoque propuesto
consiste en la utilizacin de un prototipo evolutivo, el cual se va refinando hasta tenerse la aplicacin
deseada. El nfasis queda en manifiesto en los prototipos que se sugieren para cada etapa: negocio,
usabilidad, performance y capacidad, y diseo.
En resumen, encontramos en DSDM una metodologa gil creada en el Reino Unido a partir de un
consorcio con participacin de empresas de primera lnea. El mismo contiene las caractersticas
principales de las metodologas giles y contiene prcticas tendientes al enfoque RAD. Algo que es
importante de DSDM ha sido su aceptacin en la industria y su refinamiento continuo actualmente, se
encuentra en su versin 4.0 lo que indica que las metodologas giles no son solo dominio de pequeos
grupos de desarrollo sino que estn siendo adoptadas por pesos pesados en las industrias
2.2.3 METODOLOGA SCRUM
Scrum define un proceso emprico, iterativo e incremental de desarrollo que intenta obtener ventajas
respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptacin de la
naturaleza catica del desarrollo de software, y la utilizacin de prcticas tendientes a manejar la
impredictibilidad y el riesgo a niveles aceptables. El mismo surge en 1986 , de un artculo d e la Harvard
Business Review titulado The New New Product evelopment Game de Hirotaka Takeuchi e Ikujiro
Nonaka, que introduca las mejores prcticas ms utilizadas en 10 compaas japonesas altamente
innovadoras. A partir de ah y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland
formalizan el proceso conocido como Scrum en el ao 1995.
Scrum es un mtodo iterativo e incremental que enfatiza prcticas y valores de Project management por
sobre las dems disciplinas del desarrollo. Al principio del proyecto se define el Product Backlog, que
contiene todos los requerimientos funcionales y no funcionales que deber satisfacer el sistema a
construir. Los mismos estarn especificados de acuerdo a las convenciones de la organizacin ya sea
mediante: features, casos de uso, diagramas de flujo de datos, incidentes, tareas, etc. El Product Backlog
ser definido durante reuniones de planeamiento con los stakeholders. A partir de ah se definirn las
iteraciones, conocidas como Sprint en la juerga de Scrum, en las que se ir evolucionando la aplicacin
evolutivamente. Cada Sprint tendr su propio Sprint Backlog que ser un subconjunto del Product
Backlog con los requerimientos a ser construidos en el Sprint correspondiente. La duracin recomendada
del Sprint es de un mes.
Dentro de cada Sprint el Scrum Master (equivalente al Lder de Proyecto) llevar a cabo la gestin de la
iteracin, convocando diariamente al Scrum Daily Meeting que representa una reunin de avance diaria
de no ms de 15 minutos con el propsito de tener realimentacin sobre las tareas de los recursos y los
obstculos que se presentan. Al final de cada Sprint, se realizar un Sprint Review para evaluar los
artefactos construidos y comentar el planeamiento del prximo Sprint.
Como se puede observar en la Figura N4 la metodologa resulta sencilla definiendo algunos roles y
artefactos que contribuyen a tener un proceso que maximiza el feedback para mitigar cualquier riesgo que
pueda presentarse.
A. Scrum aplicado al Desarrollo de Software Aunque surgi como modelo para el desarrollo de productos
tecnolgicos, tambin se emplea en entornos que trabajan con requisitos inestables y que requieren
rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.
Jeff Sutherland aplic el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa
que en los macro-juegos de compras y fusiones se integrara en VMARK, luego en Informix y finalmente
en Ascential Software Corporation). En 1996 lo present junto con Ken Schwaber como proceso formal,
tambin para gestin del desarrollo de software en OOPSLA 96. En el desarrollo de software Scrum est
considerado como modelo gil por la Agile Alliance.
La intencin de Scrum es la de maximizar la realimentacin sobre el desarrollo pudiendo corregir
problemas y mitigar riesgos de forma temprana. Su uso se est extendiendo cada vez ms dentro de la
comunidad de Metodologas giles, siendo combinado con otras como XP para completar sus
carencias. Cabe mencionar que Scrum no propone el uso de ninguna prctica de desarrollo en particular;
sin embargo, es habitual emplearlo como un framework gil de administracin de proyectos que puede
ser combinado con cualquiera de las metodologas mencionadas.
Figura N4. Descripcin de Roles, artefactos, reuniones y proceso de desarrollo de Scrum.
B. Ciclo de Vida de Scrum.
El ciclo de vida de Scrum es el siguiente:
1. Pre-Juego: Planeamiento. El propsito es establecer la visin, definir expectativas y asegurarse
la financiacin. Las actividades son la escritura de la visin, el presupuesto, el registro de acumulacin o
retraso (backlog) del producto inicial y los tems estimados, as como la arquitectura de alto nivel, el
diseo exploratorio y los prototipos. El registro de acumulacin es de alto nivel de abstraccin.
2. Pre-Juego: Montaje (Staging). El propsito es identificar ms requerimientos y priorizar las
tareas para la primera iteracin. Las actividades son planificacin, diseo exploratorio y prototipos.
3. Juego o Desarrollo. El propsito es implementar un sistema listo para entrega en una serie de
iteraciones de treinta das llamadas corridas (sprints). Las actividades son un encuentro de
planeamiento de corridas en cada iteracin, la definicin del registro de acumulacin de corridas y los
estimados, y encuentros diarios de Scrum.
4. Pos-Juego: Liberacin. El propsito es el despliegue operacional. Las actividades,
documentacin, entrenamiento, mercadeo y venta.
Usualmente los registros de acumulacin se llevan en planillas de clculo comunes, antes que en una
herramienta sofisticada de gestin de proyectos. Los elementos del registro pueden ser prestaciones del
software, funciones, correccin de bugs, mejoras requeridas y actualizaciones de tecnologa. Hay un
registro total del producto y otro especfico para cada corrida de 30 das. En la jerga de Scrum se llaman
paquetes a los objetos o componentes que necesitan cambiarse en la siguiente iteracin.
Figura N5. Ciclo de Carrera o de Vida (Sprint) de Scrum

La lista de Acumulacin del Producto contiene todos los rasgos, tecnologa, mejoras y lista de bugs que, a
medida que se desenvuelven, constituyen las futuras entregas del producto. Los rasgos ms urgentes
merecern mayor detalle, los que pueden esperar se tratarn de manera ms sumaria. La lista se origina a
partir de una variedad de fuentes. El grupo de mercadeo genera los rasgos y la funcin; la gente de ventas
genera elementos que harn que el producto sea ms competitivo; los de ingeniera aportarn paquetes
que lo harn ms robusto; el cliente ingresar debilidades o problemas que debern resolverse. El
propietario de la administracin y el control del backlog en productos comerciales bien puede ser el
product manager; para desarrollos in-house podra ser el project manager, o alguien designado por l. Se
recomienda que una sola persona defina la prioridad de una tarea; si alguien tiene otra opinin, deber
convencer al responsable. Se estima que priorizar adecuadamente una lista de producto puede resultar
dificultosa al principio del desarrollo, pero deviene ms fcil con el correr del tiempo.
Al fin de cada iteracin de treinta das hay una demostracin a cargo del Scrum Master. Las
presentaciones en PowerPoint estn prohibidas. En los encuentros diarios, las gallinas deben estar fuera
del crculo. Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinar a
obras de caridad. Es permitido usar artefactos de los mtodos a los que Scrum acompae, por ejemplo
Listas de Riesgos si se utiliza UP, Planguage si el mtodo es Evo, o los Planes de Proyecto sugeridos en
la disciplina de Gestin de Proyectos de Microsoft Solutions Framework. No es legal, en cambio, el uso
de instrumentos tales como diagramas PERT, porque stos parten del supuesto de que las tareas de un
proyecto se pueden identificar y ordenar; en Scrum el supuesto dominante es que el desarrollo es semi-
catico, cambiante y tiene demasiado ruido como para que se le aplique un proceso definido.
Algunos textos sobre Scrum establece una arquitectura global en la fase de pre-juego; otros dicen que no
hay una arquitectura global en Scrum, sino que la arquitectura y el diseo emanan de mltiples corridas.
No hay una ingeniera del software prescripta para Scrum; cada quien puede escoger entonces las
prcticas de automatizacin, inspeccin de cdigo, prueba unitaria, anlisis o programacin en pares que
le resulten adecuadas.
Como ya se ha mencionado antes, es muy habitual que Scrum se complemente con XP; en estos casos,
Scrum suministra un marco de management basado en patrones organizacionales, mientras XP constituye
la prctica de programacin, usualmente orientada a objetos y con fuerte uso de patrones de diseo. Uno
de los nombres que se utiliza para esta alianza es XP@Scrum. Tambin son viables los hbridos con otras
metodologas giles.
2.2.4. PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP)
XP es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito
en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el
cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente
adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo
tcnico.
Los principios y prcticas son de sentido comn pero llevadas al extremo, de ah proviene su nombre.
Kent Beck, el padre de XP, describe la filosofa de XP en [2] sin cubrir los detalles tcnicos y de
implantacin de las prcticas. Posteriormente, otras publicaciones de experiencias se han encargado de
dicha tarea. A continuacin presentaremos las caractersticas esenciales de XP organizadas en los tres
apartados siguientes: historias de usuario, roles, proceso y prcticas.
1. Las Historias de Usuario
Son la tcnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las
cuales el cliente describe brevemente las caractersticas que el sistema debe poseer, sean requisitos
funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinmico y flexible. Cada
historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan
implementarla en unas semanas [12].
Beck en su libro [2] presenta un ejemplo de ficha (customer story and task card) en la cual pueden
reconocerse los siguientes contenidos: fecha, tipo de actividad (nueva, correccin, mejora), prueba
funcional, nmero de historia, prioridad tcnica y del cliente, referencia a otra historia previa, riesgo,
estimacin tcnica, descripcin, notas y una lista de seguimiento con la fecha, estado cosas por terminar y
comentarios. A efectos de planificacin, las historias pueden ser de una a tres semanas de tiempo de
programacin (para no superar el tamao de una iteracin). Las historias de usuario son descompuestas en
tareas de programacin (task card) y asignadas a los programadores para ser implementadas durante una
iteracin.
2. Roles XP
Los roles de acuerdo con la propuesta original de Beck son:
Programador. El programador escribe las pruebas unitarias y produce el cdigo del sistema.
a. Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su
implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en
cada iteracin centrndose en aportar mayor valor al negocio.
b. Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las
pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte
para pruebas.
c. Encargado de seguimiento (Tracker). Proporciona realimentacin al equipo. Verifica el grado de
acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones.
Realiza el seguimiento del progreso de cada iteracin.
d. Entrenador (Coach). Es responsable del proceso global. Debe proveer guas al equipo de forma
que se apliquen las prcticas XP y se siga el proceso correctamente.
e. Consultor. Es un miembro externo del equipo con un conocimiento especfico en algn tema
necesario para el proyecto, en el que puedan surgir problemas.
f. Gestor (Big boss). Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje
efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.
3. Proceso XP
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos [12]:
El cliente define el valor de negocio a implementar.
El programador estima el esfuerzo necesario para su implementacin.
El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo.
El programador construye ese valor de negocio.
Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar
al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el software o no se
cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega del
producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteracin.
El ciclo de vida ideal de XP consiste de seis fases [2]: Exploracin, Planificacin de la Entrega (Release),
iteraciones, Produccin, Mantenimiento y Muerte del Proyecto.
4. Prcticas XP
La principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica curva exponencial
del costo del cambio a lo largo del proyecto, lo suficiente para que el diseo evolutivo funcione. Esto se
consigue gracias a las tecnologas disponibles para ayudar en el desarrollo de software y a la aplicacin
disciplinada de las siguientes prcticas.
El juego de la planificacin. Hay una comunicacin frecuente el cliente y los programadores. El equipo
tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y
los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin.
Entregas pequeas . Producir rpidamente versiones del sistema que sean operativas, aunque no cuenten
con toda la funcionalidad del sistema. Esta versin ya constituye un resultado de valor para el negocio.
Una entrega no debera tardar ms 3 meses.
a. Metfora. El sistema es definido mediante una metfora o un conjunto de metforas compartidas
por el cliente y el equipo de desarrollo. Una metfora es una historia compartida que describe cmo
debera funcionar el sistema (conjunto de nombres que acten como vocabulario para hablar sobre el
dominio del problema , ayudando a la nomenclatura de clases y mtodos del sistema).
b. Diseo simple . Se debe disear la solucin ms simple que pueda funcionar y ser implementada
en un momento determinado del proyecto.
c. Pruebas . La produccin de cdigo est dirigida por las pruebas unitarias. stas son son
establecidas por el cliente antes de escribirse el cdigo y son ejecutadas constantemente ante cada
modificacin del sistema.
d. Refactorizacin (Refactoring). Es una actividad constante de reestructuracin del cdigo con el
objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms flexible
para facilitar los posteriores cambios. Se mejora la estructura interna del cdigo sin alterar su
comportamiento externo [8].
e. Programacin en parejas . Toda la produccin de cdigo debe realizarse con trabajo en parejas
de programadores. Esto conlleva ventajas implcitas (menor tasa de errores, mejor diseo, mayor
satisfaccin de los programadores, .).
f. Propiedad colectiva del cdigo. Cualquier programador puede cambiar cualquier parte del
cdigo en cualquier momento.
g. Integracin continua. Cada pieza de cdigo es integrada en el sistema una vez que est lista. As,
el sistema puede llegar a ser integrado y construido varias veces en un mismo da.
h. 40 horas por semana. Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas
extras en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un problema que debe
corregirse. El trabajo extra desmotiva al equipo.
i. Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el equipo.
ste es uno de los principales factores de xito del proyecto XP. El cliente conduce constantemente el
trabajo hacia lo que aportar mayor valor de negocio y los programadores pueden resolver de manera
inmediata cualquier duda asociada. La comunicacin oral es ms efectiva que la escrita.
j. Estndares de programacin. XP enfatiza que la comunicacin de los programadores es a travs
del cdigo, con lo cual es indispensable que se sigan ciertos estndares de programacin para mantener el
cdigo legible.
El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y equilibrada puesto que se
apoyan unas en otras. Esto se ilustra en la Figura 1 (obtenida de [2]), donde una lnea entre dos prcticas
significa que las dos prcticas se refuerzan entre s. La mayora de las prcticas propuestas por XP no son
novedosas sino que en alguna forma ya haban sido propuestas en ingeniera del software e incluso
demostrado su valor en la prctica (ver [1] para un anlisis histrico de ideas y prcticas que sirven como
antecedentes a las utilizadas por las metodologas giles). El mrito de XP es integrarlas de una forma
efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el
trabajo en equipo.

El nfasis que pone en XP en las personas se manifiesta en las diversas prcticas que indican que se deben
dar ms responsabilidades a los programadores para que estimen su trabajo, puedan entender el diseo de
todo el cdigo producido, y mantengan una metfora mediante la cual se nombra las clases y mtodos de
forma consistente. La prctica denominada Semana de 40 horas indica la necesidad de mantener un
horario fijo, sin horas extras ya que esto conlleva al desgaste del equipo y a la posible desercin de sus
miembros. Beck afirma que como mximo se podra llegar a trabajar durante una semana con horas
extras, pero si pasando ese tiempo las cosas no han mejorado entonces se deber hacer un anlisis de las
estimaciones de cada iteracin para que estn acordes a la capacidad de desarrollo del equipo. Si bien XP
es la metodologa gil de ms renombre en la actualidad, se diferencia de las dems metodologas que
forman este grupo en un aspecto en particular: el alto nivel de disciplina de las personas que participan en
el proyecto.

2.2.5. METODOLOGA CRYSTAL CLEAR
Alistair Cockburn es el propulsor detrs de la serie de metodologas Crystal. Las mismas presentan un
enfoque gil, con gran nfasis en la comunicacin, y con cierta tolerancia que la hace ideal en los casos en
que sea inaplicable la disciplina requerida por XP. Crystal Clear es la encarnacin ms gil de la serie y
de la que ms documentacin se dispone. La misma se define con mucho nfasis en la comunicacin y de
forma muy liviana en relacin a los entregables. Crystal maneja iteraciones cortas con feedback frecuente
por parte de los usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios. Otra
de las cuestiones planteadas es la necesidad de disponer de un usuario real aunque sea de forma part time
para realizar validaciones sobre la Interfase del Usuario y para participar en la definicin de los
requerimientos funcionales y no funcionales del software.
Comparar el software con la ingeniera nos conduce a preguntarnos sobre especificaciones y modelos
del software, sobre su completitud, correccin y vigencia. Esas preguntas son inconducentes, porque
cuando pasa cierto tiempo no nos interesa que los modelos sean completos, que coincidan con el mundo
real (sea ello lo que fuere) o que estn al da con la versin actual del lenguaje. Intentar que as sea es
una prdida de tiempo [4]. En contra de esa visin ingenieril a la manera de un Bertrand Meyer,
Cockburn ha alternado diversas visiones despreocupadamente contradictorias que alternativamente lo
condujeron a adoptar XP en el sentido ms radical, a sinergizarse con DSDM o LSD, a concebir el
desarrollo de software como una forma comunitaria de poesa o a elaborar su propia familia de
Metodologas Crystal.
La familia Crystal dispone un cdigo de color para marcar la complejidad de una metodologa: cuanto
ms oscuro un color, ms pesado es el mtodo. Cuanto ms crtico es un sistema, ms rigor se requiere.
El cdigo cromtico se aplica a una forma tabular elaborada por Cockburn que se usa en muchas
metodologas giles para situar el rango de complejidad al cual se aplica una metodologa. En la (Figura
N6) se muestra una evaluacin de las prdidas que puede ocasionar la falla de un sistema y el mtodo
requerido segn este criterio. Los parmetros son Comodidad (C), Dinero Discrecional (D), Dinero
Esencial (E) y Vidas (L). En otras palabras, la cada de un sistema que ocasione incomodidades indica
que su nivel de criticalidad es C, mientras que si causa prdidas de vidas su nivel es L. Los nmeros del
cuadro indican el nmero de personas afectadas a un proyecto.
Figura N6. Familia de Crystal Methods

Los mtodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versin del proceso,
y todas se sitan en torno a un ncleo idntico. Hay cuatro variantes de metodologas: Crystal Clear
(Claro como el cristal) para equipos de 8 o menos integrantes; Amarillo, para 8 a 20; Naranja, para 20 a
50; Rojo, para 50 a 100. Se promete seguir con Marrn, Azul y Violeta. La ms exhaustivamente
documentada es Crystal Clear (CC), la misma que puede ser usada en proyectos pequeos de categora
D6, aunque con alguna extensin se aplica tambin a niveles E8 a D10. El otro mtodo elaborado en
profundidad es el Naranja, apto para proyectos de duracin estimada en 2 aos. Los otros dos an se estn
desarrollando. Como casi todos los otros mtodos, CC consiste en valores, tcnicas y procesos.
5. Los siete valores o propiedades de Crystal Clear son:
Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no solamente en compilar
el cdigo. La frecuencia depender del proyecto, pero puede ser diaria, semanal, mensual o lo que fuere.
La entrega puede hacerse sin despliegue, si es que se consigue algn usuario corts o curioso que
suministre feedback.
1. Comunicacin osmtica. Todos juntos en el mismo cuarto. Una variante especial es disponer en
la sala de un diseador snior; eso se llama Experto al Alcance de la Oreja. Una reunin separada para
que los concurrentes se concentren mejor es descripta como El Cono del Silencio.
2. Mejora reflexiva. Tomarse un pequeo tiempo (unas pocas horas por algunas semanas o una vez
al mes) para pensar bien qu se est haciendo, cotejar notas, reflexionar, discutir.
3. Seguridad personal. Hablar cuando algo molesta: decirle amigablemente al manager que la
agenda no es realista, o a un colega que su cdigo necesita mejorarse, o que sera conveniente que se
baase ms seguido. Esto es importante porque el equipo puede descubrir y reparar sus debilidades. No es
provechoso encubrir los desacuerdos con gentileza y conciliacin. Tcnicamente, estas cuestiones se han
caracterizado como una importante variable de confianza y han sido estudiadas con seriedad en la
literatura.
4. Foco. Saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero
debe venir de la comunicacin sobre direccin y prioridades, tpicamente con el Patrocinador Ejecutivo.
Lo segundo, de un ambiente en que la gente no se vea compelida a hacer otras cosas incompatibles.
5. Fcil acceso a usuarios expertos. Una comunicacin de Keil a la ACM demostr hace tiempo,
sobre una amplia muestra estadstica, la importancia del contacto directo con expertos en el desarrollo de
un proyecto. No hay un dogma de vida o muerte sobre esto, como s lo hayen XP. Un encuentro semanal
o semi-semanal con llamados telefnicos adicionales parece ser una buena pauta. Otra variante es que los
programadores se entrenen para ser usuarios durante un tiempo. El equipo de desarrollo, de todas
maneras, incluye un Experto en Negocios.
6. Ambiente tcnico con prueba automatizada, management de configuracin e integracin
frecuente. Microsoft estableci la idea de los builds cotidianos, y no es una mala prctica. Muchos
equipos giles compilan e integran varias veces al da.
El proceso de Cristal Clear se basa en una exploracin refinada de los inconvenientes de los modelos
clsicos. Dice Cockburn que la mayora de los modelos de proceso propuestos entre 1970 y 2000 se
describan como secuencias de pasos. An cuando se recomendaran iteraciones e incrementos (que no
hacan ms que agregar confusin a la interpretacin) los modelos parecan dictar un proceso en cascada,
por ms que los autores aseguraran que no era as. El problema con estos procesos es que realmente estn
describiendo un workflow requerido, un grafo de dependencia: el equipo no puede entregar un sistema
hasta que est integrado y corre. No puede integrar y verificar hasta que el cdigo no est escrito y
corriendo. Y no puede disear y escribir el cdigo hasta que se le dice cules son los requerimientos. Un
grafo de dependencia se interpreta necesariamente en ese sentido, aunque no haya sido la intencin
original.
Figura N7. Ciclos anidados de Crystal Clear

En lugar de esta interpretacin lineal, Cristal Clear enfatiza el proceso como un conjunto de ciclos
anidados. En la mayora de los proyectos se perciben siete ciclos:
1. el proyecto,
2. el ciclo de entrega de una unidad,
3. la iteracin (ntese que CC requiere mltiples entregas por proyecto pero no muchas iteraciones
por entrega),
4. la semana laboral,
5. el perodo de integracin, de 30 minutos a tres das,
6. el da de trabajo,
7. el episodio de desarrollo de una seccin de cdigo, de pocos minutos a pocas horas.
Los mtodos Crystal no prescriben las prcticas de desarrollo, las herramientas o los productos que
pueden usarse, pudiendo combinarse con otros mtodos como Scrum, XP y Microsoft Solutions
Framework.
2.3 UML:
2.3.1. Introduccin al UML
UML surge como respuesta al problema de contar con un lenguaje estndar para escribir planos de
software. Muchas personas han credo ver UML como solucin para todos los problemas sin saber en
muchos casos de lo que se trataba en realidad. El Lenguaje Unificado de Modelado, UML es una notacin
estndar para el modelado de sistemas software, resultado de una propuesta de estandarizacin promovida
por el consorcio OMG (Object Management Group), del cual forman parte las empresas ms importantes
que se dedican al desarrollo de software, en 1996.
UML representa la unificacin de las notaciones de los mtodos Booch, Objectory (Ivar Jacobson) y
OMT (James Rumbaugh) siendo su sucesor directo y compatible. Igualmente, UML incorpora ideas de
otros metodlogos entre los que se pueden incluir a Peter Coad, Derek Coleman, Ward Cunningham,
David Harel, Richard Helm, Ralph Johnson, Stephen Mellor, Bertrand Meyer, Jim Odell, Kenny Rubin,
Sally Shlaer, John Vlissides, Paul Ward, Rebecca Wirfs- Brock y Ed Yourdon. En Septiembre de 2001 se
ha publicada la especificacin de la versin 1.4. Es importante recalcar que slo se trata de una notacin,
es decir, de una serie de reglas y recomendaciones para representar modelos. UML no es un proceso de
desarrollo, es decir, no describe los pasos sistemticos a seguir para desarrollar software. UML slo
permite documentar y especificar los elementos creados mediante un lenguaje comn describiendo
modelos. En la figura 12 se puede observar el desarrollo de UML y sus versiones en los aos dados,
sufriendo revisiones menores, y ciertos participantes en las diversas versiones.

2.3.2 Descripcin del lenguaje
UML es un lenguaje de propsito general para el modelado orientado a objetos, que combina notaciones
provenientes desde: Modelado Orientado a Objetos, Modelado de Datos, Modelado de Componentes,
Modelado de Flujos de Trabajo (Workflows). En todos los mbitos de la ingeniera se construyen
modelos, en realidad, simplificaciones de la realidad, para comprender mejor el sistema que vamos a
desarrollar: los arquitectos utilizan y construyen planos (modelos) de los edificios, los grandes
diseadores de coches preparan modelos en sistemas existentes con todos los detalles y los ingenieros de
software deberan igualmente construir modelos de los sistemas software. Un enfoque sistemtico permite
construir estos modelos de una forma consistente demostrando su utilidad en sistemas de cierto tamao.
Cuando se trata de un programa de cincuenta, cien lneas, la utilidad del modelado parece discutible pero
cuando involucramos a cientos de desarrolladores trabajando y compartiendo informacin, el uso de
modelos y el proporcionar informacin sobre las decisiones tomadas, es vital no slo durante el desarrollo
del proyecto, sino una vez finalizado ste, cuando se requiere algn cambio en el sistema. En realidad,
incluso en el proyecto ms simple los desarrolladores hacen algo de modelado, si bien informalmente.
Para la construccin de modelos, hay que centrarse en los detalles relevantes mientras se ignoran los
dems, por lo cual con un nico modelo no tenemos bastante.
2.3.3 Inconvenientes en UML Como todo en el desarrollo de software UML presenta ciertos
inconvenientes, entre los cuales se pueden mencionar: Falta integracin con respecto de otras tcnicas
tales como patrones de diseo, interfaces de usuario, documentacin, etc., los ejemplos aislados, el
monopolio de conceptos, tcnicas y mtodos en torno a UML.
2.3.4 Perspectivas de UML
Tambin se prev varias perspectivas de UML ya que por ser un lenguaje de propsito general ser un
lenguaje de modelado orientado a objetos estndar predominante los prximos aos, esto se basa en las
siguientes razones:
- Participacin de metodlogos influyentes
- Participacin de importantes empresas
- Aceptacin del OMG como notacin estndar
Tambin se muestran las siguientes evidencias que apoyan lo antes dicho: Herramientas que proveen la
notacin UML Edicin de libros Congresos, cursos, camisetas, etc.
2.3.5 Descripcin de los diagramas Un modelo captura una vista de un sistema del mundo real. Es una
abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente
aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de
detalle. Un diagrama es una representacin grfica de una coleccin de elementos de modelado, a menudo
dibujada como un grafo con vrtices conectados por arcos Un proceso de desarrollo de software debe
ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de
inters. Es aqu donde se hace evidente la importancia de UML en el contexto de un proceso de desarrollo
de software. El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es
ejecutable). Sin embargo, se requieren otros modelos.
2.3.6 Relaciones de enlaces entre modelos

Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de enlaces
entre los diferentes modelos (figura). Varios modelos aportan diferentes vistas de un sistema los cuales
nos ayudan a comprenderlo desde varios frentes. As, UML recomienda la utilizacin de nueve diagramas
que, para representar las distintas vistas de un sistema. Estos diagramas de UML se presentan en la figura
14 y se describen a continuacin:

2.3.7 Diagramas, partes de un modelo
1. Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupndola en descripciones
de acciones ejecutadas por un sistema para obtener un resultado.
2. Diagrama de Clases: muestra las clases (descripciones de objetos que comparten caractersticas
comunes) que componen el sistema y cmo se relacionan entre s.
3. Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus relaciones.
a. Diagramas de Comportamiento: dentro de estos diagramas se encuentran:
b. Diagrama de Estados: modela el comportamiento del sistema de acuerdo con eventos.
c. Diagrama de Actividades: simplifica el Diagrama de Estados modelando el comportamiento
mediante flujos de actividades. Tambin se pueden utilizar caminos verticales para mostrar los
responsables de cada actividad.
d. Diagramas de Interaccin: Estos diagramas a su vez se dividen en 2 tipos de diagramas, segn la
interaccin que enfatizan:
+ Diagrama de Secuencia: enfatiza la interaccin entre los objetos y los mensajes que intercambian entre
s junto con el orden temporal de los mismos.
+ Diagrama de Colaboracin: igualmente, muestra la interaccin entre los objetos resaltando la
organizacin estructural de los objetos en lugar del orden de los mensajes intercambiados.
4. Diagramas de implementacin
a. Diagrama de Componentes: muestra la organizacin y las dependencias entre un conjunto de
componentes.
b. Diagrama de Despliegue: muestra los dispositivos que se encuentran en un sistema y su
distribucin en el mismo.
2.3.8 Metodologa del RUP para anlisis y diseo
El RUP propone la utilizacin de los modelos para la implementacin completa de todas sus fases
respectivamente con sus disciplinas:
1. Modelo de Casos de Uso del Negocio: Describe la realizacin del Caso de Uso, es realizado en
la disciplina de Modelado del Negocio.
2. Modelo de Objetos del Negocio: Se utiliza para identificar roles dentro de la organizacin, es
realizado en la disciplina de Modelado del Negocio.
3. Modelo de Casos de Uso: Muestra las interrelaciones entre el sistema y su ambiente, adems
sirve como un contrato entre el cliente y los diseadores. Es considerado esencial al iniciar las actividades
de anlisis, diseo y prueba; este modelo es realizado en la disciplina de Requerimientos.
4. Modelo de Anlisis: Contiene los resultados del anlisis del Caso de Uso, y contienen instancias
del artefacto de Anlisis de Clases; es realizado en la disciplina de Anlisis y Diseo.
5. Modelo de Diseo: Es un modelo de objetos que describe la realizacin del Caso de Uso, y sirve
como una abstraccin del modelo de implementacin y su cdigo fuente, es utilizado como entrada en las
actividades de implementacin y prueba; este modelo se realizado en la disciplina de Anlisis y Diseo.
6. Modelo de Despliegue: Muestra la configuracin de los nodos del proceso en tiempo de
ejecucin, muestra los lazos de comunicacin entre estos nodos, as como las de los objetos y
componentes que en el se encuentran; se realizado en la disciplina de Anlisis y Diseo.
7. Modelo de Datos: Es un subconjunto del modelo de implementacin que describe la
representacin lgica y fsica de datos persistentes en el sistema. Tambin incluye cualquier conducta
definida en la base de datos como disparadores, restricciones, etc. Es elaborado en la disciplina de
Anlisis y Diseo.
8. Modelo de Implementacin: Es una coleccin de componentes, y de subsistemas de aplicacin
que contienen estos componentes, entre estos estn los entregables, ejecutables, archivos de cdigo
fuente. Es realizado en la disciplina de Implementacin.
9. Modelo de Pruebas: Es utilizado para la elaboracin de las pruebas, y se realiza en la disciplina
de Pruebas.
Estos modelos representan los diagramas que propone el UML para el desarrollo de modelado de un
proyecto de software, con los cuales se puede representar los propuesto por UML mediante la
metodologa RUP utilizando las herramientas que esta provee para la implementacin fcil, clara y
estructurada de los diagramas utilizados.
2.3.9 Descripcin de estereotipos
Para poder entender la interrelacin que tiene UML con RUP se tiene que saber que el inicio de todo est
con los casos de uso, para poder tener una base sobre lo cual se quiere trabajar, los casos de uso son la
base para esta tcnica; luego se procede a la obtencin de los diagramas expuestos anteriormente,
dependiendo de cules son los necesarios de implementar, luego se procede a la identificacin de los
estereotipos, ya que cada uno de estos representan las funciones que se van a definir dentro de los
diagramas, estos diagramas nos ayudan a entender la lgica del caso de uso expuesto.
Las clases, al igual que los dems elementos notacionales del UML, pueden estar clasificadas de acuerdo
a varios criterios, como por ejemplo su objetivo dentro de un programa. Esta clasificacin adicional se
puede expresar mediante la utilizacin de estereotipos.

Los estereotipos ms comunes utilizados para clasificar las clases son: Entidad (entity), Frontera
(boundary), Control (control). Se proponen varias pautas a seguir a la hora de encontrar las clases de
nuestro sistema durante la fase de anlisis. Dichas pautas se centran en la bsqueda de los estereotipos
entidad, control y frontera:
- Una clase entidad modela la informacin de larga vida y su comportamiento asociado. Este tipo
de clase suele reflejar entidades del mundo real o elementos necesarios para realizar tareas internas al
sistema. Tambin se denominan clase dominio, ya que suelen tratar con abstracciones de entidades del
mundo real.
- Una clase frontera maneja comunicaciones entre el entorno del sistema y el sistema, suelen
proporcionar la interfaz del sistema con un usuario o con otro sistema, en general, por tanto, modelan las
interfaces del sistema. Cuando se trata de clases que definen la interfaz con otro sistema se refinarn
durante la fase de diseo, para tener en cuenta los protocolos de comunicacin elegidos.
- Una clase control modela el comportamiento secuenciado especfico de uno o varios casos de
uso. Se trata de clases que coordinan los eventos necesarios para llevar a cabo el comportamiento que se
especifica en el caso de uso, representan su dinmica.
El Nuevo Enfoque del UML 2.0
En las versiones previas del UML, se haca un fuerte hincapi en que UML no era un lenguaje de
programacin. Un modelo creado mediante UML no poda ejecutarse. En el UML 2.0, esta asuncin
cambi de manera drstica y se modific el lenguaje, de manera tal que permitiera capturar mucho ms
comportamiento (Behavior). De esta forma, se permiti la creacin de herramientas que soporten la
automatizacin y generacin de cdigo ejecutable, a partir de modelos UML.
Estndares que conforman el UML
Superestructura: Es la especificacin que usamos todos los das. Aqu se encuentran todos los
diagramas que la mayora de los desarrolladores conocen.
Infraestructura: Conceptos de bajo nivel. Meta-Modelo da soporte a la superestructura, entre
otras.
OCL: Lenguaje de restriccin. De utilidad para especificar conceptos ambiguos sobre los
distintos elementos del diagrama.
XMI / Intercambio de diagramas: Permite compartir diagramas entre diferentes herramientas de
modelado UML.
Reestructuracin del Lenguaje
Para lograr los objetivos enunciados, varios aspectos del lenguaje fueron reestructurados y/o modificados.
La especificacin se separ en cuatro especificaciones (paquetes) bien definidas, tal como se muestra en
la Figura 1. Es interesante destacar que el UML 2.0 puede definirse a s mismo. Es decir, su estructura y
organizacin es modelable utilizando el propio UML 2.0; de esta manera, se da un ejemplo de utilizacin
del UML en un dominio distinto al del desarrollo de software. En este caso, cada paquete del diagrama
representa cada una de las cuatro especificaciones que componen el lenguaje.

Figura 1: Especificaciones principales del UML 2.0
Veamos a continuacin, un poco ms en detalle cada una de las principales especificaciones que
componen UML 2.0. No nos explayaremos demasiado, debido a que en futuras ediciones habr
oportunidad de profundizar en cada una de ellas.
OCL
OCL son siglas en ingls que significan: Object Constraint Language y que en castellano se traducen
como: Lenguaje de Restricciones de Objetos. El OCL define un lenguaje simple, para escribir
restricciones y expresiones sobre elementos de un modelo. El OCL suele ser til cuando se est
especificando un dominio particular mediante el UML y es necesario restringir los valores permitidos
para los objetos del dominio. El OCL brinda la posibilidad definir en los elementos de un diagrama, entre
otros: invariantes, precondiciones, poscondiciones y restricciones. El OCL fue incorporado al UML en la
versin 1.1. El OCL fue originalmente especificado por IBM y es un ejemplo ms de las muchas
herramientas agregadas al UML.
Especificacin para el Intercambio de Diagramas
La especificacin para el intercambio de diagramas fue escrita para facilitar una manera de compartir
modelos, realizados mediante UML, entre diferentes herramientas de modelado. En versiones anteriores
del UML, se utilizaba un Schema XML para capturar los elementos utilizados en el diagrama; pero este
Schema no deca nada acerca de la manera en que el modelo deba graficarse. Para solucionar este
problema, la nueva especificacin para el intercambio de diagramas fue desarrollada utilizando un nuevo
Schema XML, que permite construir una representacin SVG (Scalable Vector Graphics). Esta
especificacin es denominada con las siglas XMI, que en ingls significa: XML Metadata Interchange; y
en castellano se traduce como: XML de Intercambio de Metadata (datos que representan datos).
Tpicamente esta especificacin es solamente utilizada por quienes desarrollan herramientas de modelado
UML.
Infraestructura
En la Infraestructura del UML se definen los conceptos centrales y de ms bajo nivel. La Infraestructura
es un meta-modelo (un modelo de modelos) y mediante la misma se modela el resto del UML.
Generalmente, la infraestructura no es utilizada por usuarios finales del UML; pero provee la piedra
fundamental sobre la cual la Superestructura es definida. Esta ltima s es la utilizada por el comn de los
usuarios. La Infraestructura brinda tambin varios mecanismos de extensin, que hacen del UML un
lenguaje configurable. Para los usuarios normales del UML basta con saber si la infraestructura existe y
cules son sus objetivos.
Superestructura
La superestructura del UML es la definicin formal de los elementos del UML. Esta definicin sola
contiene ms de 640 pginas. La superestructura es tpicamente utilizada por los desarrolladores de
aplicacin. Es aquella sobre la que hablan los libros y la que la mayora conoce de versiones anteriores
del UML.
La Superestructura del UML
Es en la Superestructura donde encontramos los cambios que ms afectan en el da a da a quienes
trabajan como desarrolladores de aplicaciones de negocios, es decir, profesionales que, en general, deben
interpretar o crear modelos que especifiquen el dominio de tales aplicaciones.
Es aqu dnde se definen los diagramas y los elementos que los componen. La Superestructura se
encuentra dividida en niveles. Estos niveles se conocen como:
Bsico (L1): Contiene los elementos bsicos del UML 2.0, entre ellos: Diagramas de clases,
Diagramas de actividades, Diagramas de Interacciones, y Diagramas de Casos de Uso
Intermedio (L2): Contiene los siguientes diagramas: Diagramas de estado, Perfiles, Diagramas
de Componentes y Diagramas de despliegue.
Completo (L3): Representa la especificacin del UML 2.0 completa, como por ejemplo: las
Acciones, Caractersticas avanzadas y PowerTypes? entre otros.
Es importante destacar que basta con que una herramienta implemente el nivel de conformidad Bsico
(L1), para que se considere UML 2.0 compatible. Por eso, es normal ver una disparidad de caractersticas
(features) bastante amplia entre dos herramientas distintas, aunque stas sean UML 2.0 compatibles.

Organizacin de la superestructura
El bloque de construccin bsico del UML es un diagrama. La estructura de los diagramas UML est
reflejado por el diagrama de la figura 2, de acuerdo con la especificacin del UML 2.0 del Object
Development Group. Los detalles sobre estos diagramas especficos se organizan de acuerdo a esta
estructura taxonmica, que da la perspectiva a los diagramas y a sus interrelaciones. Los diagramas de
interaccin comparten propiedades y atributos similares, como lo hacen los diagramas estructurales y de
comportamiento.

2.3.10 Enlace del RUP con el UML
Conociendo los estereotipos utilizados para la representacin de las clases (Entidad, Control y Frontera),
ahora podemos explicar la interrelacin que existe entre el UML y RUP describiendo los diagramas que
describe UML y como se convierten en diagramas del RUP que utilizan estos estereotipos.
El UML proporciona los diagramas de Caso de Uso, al mismo tiempo que el RUP, la nica diferencia es
la forma de dibujar los estereotipos, ya que en el RUP son una elipse con una diagonal al lado derecho
(pero esto es para casos de uso de negocio, los de sistema no tienen la diagonal), y en UML solamente
una elipse, pero en el RUP significa lo mismo a lo que se refiere en UML. En la figura 16 se muestra lo
descrito anteriormente, aunque no nos importa en este caso el motivo por el cual se hicieron los
diagramas, o la utilizacin que se les dio, ya que nicamente nos interesa conocer la forma de dibujar
ambos diagramas para conocer sus diferencias:

2.3.11 Comparacin entre diagramas de casos de uso (a) RUP (b) UML (a) (b)
Los diagramas de Clases tienen la misma lgica para lo cual fueron creados en ambos lenguajes,
solamente con las diferencias en la forma de dibujar los cuadros que indican las clases, por ejemplo se
pueden observar en las siguientes figuras 17(a) y 17(b), que en el RUP se dibujan los cuadros con una
pestaa inferior derecha doblada, y en UML solamente rectngulos con ngulos rectos; otra caracterstica
que se puede observar es que a la hora de ejemplificar las relaciones uno a uno, uno a muchos etc., se
realizan de diferente manera. Pero en ambos lenguajes se puede observar que los diagramas de clases son
lo ms cercano a la elaboracin de un modelo Entidad Relacin para la puesta en prctica de la
finalizacin del proyecto de software.

Los diagramas de objetos, difieren nicamente en la forma como se dibujan los objetos o instancias de las
clases, ya que en el RUP se dibujan crculos con una diagonal en la parte inferior derecha, y en UML
como rectngulos con las esquinas redondeadas, tambin en RUP no se colocan flechas indicativas, y en
UML s. En las siguientes figuras se presentan las diferencias planteadas anteriormente, es importante
mencionar que la lgica de cada figura no nos importa en este momento, solamente deseamos representar
la forma en que se dibujan los objetos, esto ya que cada una de las figuras 18(a) y 18(b) se refieren a
distintos ejemplos.

Los siguientes dos diagramas (figura 19 (a) y (b)) presentan la forma como se elabora un diagrama de
estados en RUP y UML, se puede observar que de igual manera se elaboran ambos, nicamente que en el
diagrama de UML se muestran unos rectngulos con la esquina superior derecha doblada que indican
notas sobre este estado.

En los diagramas de actividades se utilizan todos los bloques utilizados en la elaboracin de diagramas de
flujo, por lo tanto en ambos lenguajes se utilizan los mismos, a continuacin podemos ver la figura 20 que
muestra ejemplos de ambos lenguajes, aunque el enfoque de cada diagrama presentado es distinto,
solamente se tomaron de ejemplos para ejemplificar los bloques utilizados.

En los diagramas de secuencia se pueden encontrar diferencias leves, como se puede mostrar en la figura
21 los diagramas de secuencia de UML no llevan los smbolos que identifican los estereotipos interfase
(crculo con una raya horizontal del lado izquierdo y junto a esta otra vertical), control (crculo con una
flecha sobre su borde apuntando al lado izquierdo) y entidad (crculo con una raya horizontal en la parte
inferior del mismo), representados por crculos con caractersticas independientes.
Los diagramas de colaboracin se representan similares, con la nica diferencia de los bloques que
representan las clases, ya que en el RUP se representan por medio de los crculos con sus caractersticas
individuales de acorde a la funcin que desempean (interfaz, control, entidad), y en UML solamente
como rectngulos. En ambos se colocan las actividades que conllevan realizar para llegar a una clase
determinada, esto se coloca directamente en la flecha dibujada en la lnea que va hacia la clase. Esto se
puede observar en la figura 22.
Dentro de los diagramas de implementacin se encuentran los de componentes (figura 23), los cuales se
representan de manera similar en ambos lenguajes, como se muestra en la figura siguiente.
La diferencia bsica en los diagramas de despliegue (figura 24) es que en UML se dibujan dentro de las
cajas los componentes utilizados, en cambio en el RUP se diagraman de forma separada como se
muestran en las figuras siguientes.
En los diagramas presentados anteriormente, la similitud entre ambos lenguajes es demasiado grande, ya
que RUP utiliza los del UML y por lo tanto recopila todo lo que este lenguaje necesita para la
implementacin, y agrega mejoras, siendo una herramienta de modelado muy eficiente. Por lo tanto la
funcionalidad completa de UML esta descrita e implementada por el RUP.
2.4 LENGUAJES DE PROGRAMACIN
Un lenguaje de programacin es un lenguaje que puede ser utilizado para controlar el comportamiento de
una mquina, particularmente una computadora. Consiste en un conjunto de reglas sintcticas y
semnticas que definen su estructura y el significado de sus elementos, respectivamente.
2.4.1. JAVA ECLIPSE
Eclipse es un entorno de desarrollo integrado de cdigo abierto multiplataforma para desarrollar lo que el
proyecto llama Aplicaciones de Cliente Enriquecido, opuesto a las aplicaciones Cliente-liviano
basadas en navegadores. Esta plataforma, tpicamente ha sido usada para desarrollar entornos de
desarrollo integrados (del ingls IDE), como el IDE de Java llamado Java Development Toolkit (JDT) y
el compilador (ECJ) que se entrega como parte de Eclipse (y que son usados tambin para desarrollar el
mismo Eclipse). Sin embargo, tambin se puede usar para otros tipos de aplicaciones cliente, como
BitTorrent o Azureus.

Eclipse es tambin una comunidad de usuarios, extendiendo constantemente las reas de aplicacin
cubiertas. Un ejemplo es el recientemente creado Eclipse Modeling Project, cubriendo casi todas las reas
de Model Driven Engineering.
Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para
VisualAge. Eclipse es ahora desarrollado por la Fundacin Eclipse, una organizacin independiente sin
nimo de lucro que fomenta una comunidad de cdigo abierto y un conjunto de productos
complementarios, capacidades y servicios.
Eclipse fue liberado originalmente bajo la Common Public License, pero despus fue re-licenciado bajo la
Eclipse Public License. La Free Software Foundation ha dicho que ambas licencias son licencias de
software libre, pero son incompatibles con Licencia pblica general de GNU (GNU GPL).[3]
1. ARQUITECTURA
La base para Eclipse es la Plataforma de cliente enriquecido (del Ingls Rich Client Platform RCP). Los
siguientes componentes constituyen la plataforma de cliente enriquecido:
Plataforma principal inicio de Eclipse, ejecucin de plugins OSGi una plataforma para bundling
estndar. El Standard Widget Toolkit (SWT) Un widget toolkit portable. JFace manejo de archivos,
manejo de texto, editores de texto El Workbench de Eclipse vistas, editores, perspectivas, asistentes.
Los widgets de Eclipse estn implementados por una herramienta de widget para Java llamada SWT, a
diferencia de la mayora de las aplicaciones Java, que usan las opciones estndar Abstract Window
Toolkit (AWT) o Swing. La interfaz de usuario de Eclipse tambin tiene una capa GUI intermedia
llamada JFace, la cual simplifica la construccin de aplicaciones basadas en SWT.
El entorno de desarrollo integrado (IDE) de Eclipse emplea mdulos (en ingls plug-in) para proporcionar
toda su funcionalidad al frente de la plataforma de cliente enriquecido, a diferencia de otros entornos
monolticos donde las funcionalidades estn todas incluidas, las necesite el usuario o no. Este mecanismo
de mdulos es una plataforma ligera para componentes de software. Adicionalmente a permitirle a
Eclipse extenderse usando otros lenguajes de programacin como son C/C++ y Python, permite a Eclipse
trabajar con lenguajes para procesado de texto como LaTeX, aplicaciones en red como Telnet y Sistema
de gestin de base de datos. La arquitectura plugin permite escribir cualquier extensin deseada en el
ambiente, como sera Gestin de la configuracin. Se provee soporte para Java y CVS en el SDK de
Eclipse. Y no tiene por qu ser usado nicamente para soportar otros lenguajes de programacin.
La definicin que da el proyecto Eclipse acerca de su software es: una especie de herramienta universal
un IDE abierto y extensible para todo y nada en particular.
En cuanto a las aplicaciones clientes, eclipse provee al programador con frameworks muy ricos
para el desarrollo de aplicaciones grficas, definicin y manipulacin de modelos de software,
aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing Framework Framework para la edicin
grfica) es un plugin de Eclipse para el desarrollo de editores visuales que pueden ir desde procesadores
de texto wysiwyg hasta editores de diagramas UML, interfaces grficas para el usuario (GUI), etc. Dado
que los editores realizados con GEF viven dentro de Eclipse, adems de poder ser usados
conjuntamente con otros plugins, hacen uso de su interfaz grfica personalizable y profesional.
El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo un IDE con un compilador
de Java interno y un modelo completo de los archivos fuente de Java. Esto permite tcnicas avanzadas de
refactorizacin y anlisis de cdigo. Mediante diversos plugins estas herramientas estn tambin
disponibles para otros lenguajes como C/C++ (Eclipse CDT) y en la medida de lo posible para lenguajes
de script no tipados como PHP o Javascript. El IDE tambin hace uso de un espacio de trabajo, en este
caso un grupo de metadata en un espacio para archivos plano, permitiendo
2. CARACTERSTICAS
Eclipse dispone de un Editor de texto con resaltado de sintaxis. La compilacin es en tiempo real. Tiene
pruebas unitarias con JUnit, control de versiones con CVS, integracin con Ant, asistentes (wizards) para
creacin de proyectos, clases, tests, etc., y refactorizacin.
Asimismo, a travs de plugins libremente disponibles es posible aadir control de versiones con
Subversion.[4] e integracin con Hibernate.[5]
3. HISTORIA
Eclipse comenz como un proyecto de IBM Canad. Fue desarrollado por OTI (Object Technology
International) como reemplazo de VisualAge tambin desarrollado por OTI. En noviembre del 2001, se
form un consorcio para el desarrollo futuro de Eclipse como cdigo abierto. En 2003, fue creada la
fundacin independiente de IBM. Resumen de las versiones de Eclipse:
4. RADIOGRAFA
Los datos y cifras relacionados con Eclipse, mostrados a continuacin, permitirn profundizar un poco
ms en el producto.

Como puede verse en la tabla siguiente, la versin 3.2.1 posee ms de 2 millones de lneas de cdigo
(para el proyecto Eclipse). Estos datos son de acuerdo a SLOCCount.[6] Utilizando esta cifra y aplicando
el modelo COCOMO, podemos ver que requerira un esfuerzo para producir un software de este tamao
de 604 persona-ao (para ello se ha utilizado la frmula 2.4*(KSLOC ** 1.05)).
Para tener un estimado de los costes se toma en consideracin el salario de 56.286 $/ao, que es el salario
promedio de un programador en los Estados Unidos, y luego se multiplica ese resultado por 2,40, que
incluye cualquier gasto extra diferente de los programadores como pueden ser luz, telfono, papelera,
etc.
Un punto muy importante a notar son los diversos lenguajes de programacin utilizados en el desarrollo
del proyecto. De acuerdo al anlisis realizado usando SLOCCount, el lenguaje ms utilizado es Java,
seguido de ANSI C.
2.4.2. VISUAL BASIC
Introduccin.
Visual Basic es uno de los tantos lenguajes de programacin que podemos encontrar hoy en da. Dicho
lenguaje nace del BASIC (Beginners All-purpose Symbolic Instruction Code) que fue creado en su
versin original en el Dartmouth College, con el propsito de servir a aquellas personas que estaban
interesadas en iniciarse en algn lenguaje de programacin. Luego de sufrir varias modificaciones, en el
ao 1978 se estableci el BASIC estndar. La sencillez del lenguaje gan el desprecio de los
programadores avanzados por considerarlo un lenguaje para principiantes.
Primero fue GW-BASIC, luego se transform en QuickBASIC y actualmente se lo conoce como Visual
Basic y la versin ms reciente es la 6 que se incluye en el paquete Visual Studio 6 de Microsoft. Esta
versin combina la sencillez del BASIC con un poderoso lenguaje de programacin Visual que juntos
permiten desarrollar robustos programas de 32 bits para Windows. Esta fusin de sencillez y la esttica
permiti ampliar mucho ms el monopolio de Microsoft, ya que el lenguaje slo es compatible con
Windows, un sistema operativo de la misma empresa.
Visual Basic ya no es ms un lenguaje para principiantes sino que es una perfecta alternativa para los
programadores de cualquier nivel que deseen desarrollar aplicaciones compatibles con Windows.
En este informe explicaremos algunos trminos y/o caractersticas de mismo con la finalidad de aprender
mas sobre este Programa y manejarlo con facilidad
Es un lenguaje de programacin que se ha diseado para facilitar el desarrollo de aplicaciones en un
entorno grafico (GUI-GRAPHICAL USER INTERFACE) Como Windows 98, Windows NT o superior.
1. Qu es Visual Basic?
Diseador de entorno de datos: Es posible generar, de manera automtica, conectividad entre controles y
datos mediante la accin de arrastrar y colocar sobre formularios o informes.
Los Objetos Actives son una nueva tecnologa de acceso a datos mediante la accin de arrastrar y colocar
sobre formularios o informes.
Asistente para formularios: Sirve para generar de manera automtica formularios que administran
registros de tablas o consultas pertenecientes a una base de datos, hoja de calculo u objeto (ADO-
ACTIVE DATA OBJECT)
Asistente para barras de herramientas es factible incluir barras de herramientas es factible incluir barra de
herramientas personalizada, donde el usuario selecciona los botones que desea visualizar durante la
ejecucin.
En las aplicaciones HTML: Se combinan instrucciones de Visual Basic con cdigo HTML para controlar
los eventos que se realizan con frecuencia en una pagina web.
La Ventana de Vista de datos proporciona acceso a la estructura de una base de datos. Desde esta tambin
acceso al Diseador de Consultas y diseador de Base de datos para administrar y registros.
2. Caractersticas de Visual Basic.
Barra de titulo: muestra el nombre del proyecto y del formulario q se est diseando actualmente
Barra de mens: agrupa los mens despegables que contienes todas las operaciones que pueden llevarse a
cabo con Visual Basic 6.0.
Barra de herramientas estndar: contienen los botones que se utilizan con mayor frecuencia cuando se
trabaja con un proyecto. Simplifica la eleccin de opciones de los mens Archivo, Edicin, Ver y
Ejecutar; adems, en el rea derecha presenta la ubicacin (coordenadas) y el tamao del objeto
seleccionado
Ventana de formulario: es el rea donde se disea la interfaz grfica, es decir, es donde se inserta electo
grficos, como botones, imgenes, casilla de verificacin, cuadros de listas, etc.
Cuadro de herramientas: presenta todos los controles necesarios para disear una aplicacin, como
cuadros de texto, etiquetas, cuadros de listas, botones de comandos, etc.
Ventana de proyecto: muestra los elementos involucrados en el proyecto, como formularios, mdulos,
controles oxc, etc. Cada elemento puede seleccionarse en forma independiente para su edicin.
Ventana de posicin del formulario: muestra la ubicacin que tendr el formulario en la pantalla, cuando
ejecute la aplicacin. Esta ubicacin puede cambiarse si se hace clic con el botn izquierdo del mouse.
La Ventana propiedades muestra todas las propiedades del control actualmente seleccionado, en este caso
muestra las propiedades del Form1, luego podemos ver que abajo dice Form1 Form, lo que est en
negrita es el nombre del objeto, y lo que le sigue es el tipo de objeto, en este caso es un Formulario
(Form)
Mediante este control podremos realizar tanto la entrada como la salida de datos en nuestras aplicaciones.
No hace falta que indiquemos las coordenadas de la situacin del formulario en pantalla, simplemente
tendremos que marcar sobre el control de la caja de herramientas y dibujarlo con el tamao que queramos
en nuestro formulario
Label.
Este control es tambin uno de los ms utilizados, aunque su utilidad queda restringida a la visualizacin
de datos en el mismo, no permitiendo la introduccin de datos por parte del usuario.
CommandButton
Este control es el tpico botn que aparece en todas las aplicaciones y que al hacer click sobre l nos
permite realizar alguna operacin concreta, normalmente Aceptar o Cancelar. Aunque segn el cdigo
que le asociemos podremos realizar las operaciones que queramos.
OptionButton
Este control nos permite elegir una opcin entre varias de las que se nos plantean. Cada opcin ser un
control optionbutton diferente.
Bloquear los Controles
Cuando estn situados los controles en el formulario se pueden bloquear para que no puedan moverse de
forma accidental.
Para esto deberemos pulsar en la barra de herramientas:
Cuando actives este botn y mientras no desbloquees los controles utilizando la misma opcin no se
podrn mover ninguno de los controles del formulario activo.
Sin embargo en si abres otro formulario que no tenga los controles bloqueados si se podrn mover. Si
aades ms controles a un formulario bloqueado estos quedan bloqueados automticamente
Tiene la siguiente forma:
Un control Frame proporciona un agrupamiento identificable para controles. Tambin puede utilizar un
Frame para subdividir un formulario funcionalmente por ejemplo, para separar grupos de controles
OptionButton.
CHECK BUTTON Y OPTION BUTTON (BOTONES DE ELECCION Y OPCION)
Se obtienen directamente de la caja de herramientas.
Dada la similitud de ambos controles, se comentan conjuntamente.
El control CheckBox, o casilla de verificacin, permite elegir una opcin (activada / desactivada,
True/False) que el usuario puede establecer o anular haciendo click. Una X en una casilla de verificacin
indica que est seleccionada, activada, o con valor True. Cada casilla de verificacin es independiente de
las dems que puedan existir en el formulario, pudiendo tomar cada una de ellas el valor True o False, a
voluntad del operador.
Un control OptionButton muestra una opcin que se puede activar o desactivar, pero con dependencia del
estado de otros controles OptionButton que existan en el formulario.
Generalmente, los controles OptionButton se utilizan en un grupo de opciones para mostrar opciones de
las cuales el usuario slo puede seleccionar una. Los controles OptionButton se agrupan dibujndolos
dentro de un contenedor como un control Frame, un control PictureBox o un formulario. Para agrupar
controles OptionButton en un Frame o PictureBox, dibuje en primer lugar el Frame o PictureBox y, a
continuacin, dibuje dentro los controles OptionButton. Todos los controles OptionButton que estn
dentro del mismo contenedor actan como un solo grupo, e independientes de los controles OptionButton
de otros grupos distintos.
Aunque puede parecer que los controles OptionButton y CheckBox funcionan de forma similar, hay una
diferencia importante: Cuando un usuario selecciona un OptionButton, los otros controles del mismo
grupo OptionButton dejan de estas disponibles automticamente. Por contraste, se puede seleccionar
cualquier nmero de controles CheckBox.
LIST BOX Y COMBO BOX
Estos dos controles, debido a su similitud, se estudian conjuntamente.
Se obtienen directamente de la caja de herramientas:
Un control ListBox muestra una lista de elementos en la que el usuario puede seleccionar uno o ms. Si el
nmero de elementos supera el nmero que puede mostrarse, se agregar automticamente una barra de
desplazamiento al control ListBox.
Un control ComboBox combina las caractersticas de un control TextBox y un control ListBox. Los
usuarios pueden introducir informacin en la parte del cuadro de texto y seleccionar un elemento en la
parte de cuadro de lista del control. En resumen, un ComboBox es la combinacin de un ListBox, que se
comporta como si de un ListBox se tratase, y de un TextBox, con comportamiento anlogo a un TextBox
sencillo, con la particularidad aqu de que el texto se le puede introducir por teclado, o elegir uno de los
que figuran en la parte ListBox del Combo.
CONTROLES HScrollBar y VScrollBar
Son dos controles similares, para introducir un dato cuasi-analgico en una aplicacin. Se toman
directamente de la caja de herramientas, y tienen un aspecto parecido al de un control de volumen de un
equipo de msica. El HScrollBar est en posicin horizontal, y el VScrollBar en posicin vertical.
Mediante estos controles se pueden introducir datos variando la posicin del cursor.
TIMER TEMPORIZADOR
Este objeto permite establecer temporizaciones. Presenta una novedad respecto a los controles estudiados
hasta ahora. El control Timer solamente se ve durante el tiempo de diseo. En tiempo de ejecucin, el
control permanece invisible.
La temporizacin producida por el Timer es independiente de la velocidad de trabajo del ordenador. (Casi
independiente. El timer no es un reloj exacto, pero se le parece)
Se toma directamente de la caja de herramientas, y tiene el aspecto siguiente:
SHAPE
Se toma directamente de la caja de herramientas:
Shape es un control grfico que se muestra como un rectngulo, un cuadrado, una elipse, un crculo, un
rectngulo redondeado o un cuadrado redondeado.
Utilice controles Shape en tiempo de diseo en lugar o adems de invocar los mtodos Circle y Line en
tiempo de ejecucin. Puede dibujar un control Shape en un contenedor, pero no puede actuar como
contenedor. (Esto quiere decir que un control Shape nunca le servir, por ejemplo, para albergar varios
OptionButton y pretender que sean independientes de otros controles OptionButton que se encuentren
fuera del control Shape.
Este control no tiene Procedimientos. En realidad, solamente sirve para mostrar un determinado grfico,
envolver grficamente a otros controles, pero no tiene ninguna aplicacin en cuanto a programa. Es un
adorno para sus aplicaciones.LINE
Se toma directamente de la caja de herramientas
Line, al igual que Shape, es un control grfico que solamente sirve para poner una lnea en un formulario.
Del mismo modo, no tiene procedimientos, por lo que no sirve para aportar cdigo al programa. Solo
sirve para aportar una caracterstica grfica, es un adorno.
CONTROL GAUGE
Este control presenta una informacin numrica de forma grfica, bien como un display lineal (tpico por
ejemplo en ecualizadores de audio), o como una aguja. No est normalmente en la caja de herramientas,
por lo que hay que traerla desde los Controles Personalizados (Men desplegable de Herramientas) Se
denomina MicroHelp Gauge Control. El archivo que lo contiene se denomina GAUGE16.OCX, 16 bits
Mediante este control, podemos presentar una magnitud numrica de una forma cuasi-analgica.
Podramos decir que es un control similar al HScrollBar, que en vez de meter informacin a la aplicacin,
la presenta.
Este control puede servir, por ejemplo, para presentar el tanto por ciento de ejecucin de una tarea, como
elemento tranquilizante. Puede presentar el nivel de un depsito de agua, etc.
Presenta las dos formas siguientes:
En la figura puede verse un Gauge de aguja, uno de barra horizontal y otro de barra vertical. Para mejorar
la presentacin, el Gauge permite poner un grfico como fondo, cambiar el color de la barra, color de
fondo, etc.
El control Gauge crea medidores definidos por el usuario, que puede elegir entre los estilos lineales
(relleno) o de aguja.
Nota para la distribucin Cuando cree y distribuya aplicaciones con controles Gauge, tendr que instalar
el archivo apropiado en el subdirectorio SYSTEM de Windows del cliente. El Kit para instalacin que
incluye Visual Basic, le proporciona herramientas para escribir los programas que instalan las
aplicaciones correctamente.
El CommonDialog es un control del que se libran muy pocas aplicaciones. Dada la importancia de este
control, se le dedica un capitulo nico en esta Gua del Estudiante.
CUADRO DE DIALOGO CommonDialog
Normalmente se encuentra en la caja de herramientas
Este control no se presenta en tiempo de diseo mas que con un simple icono:
El cuadro de dilogo, CommonDialog se utiliza para varias funciones:
Abrir Ficheros
Guardar Ficheros
Elegir colores
Seleccionar Impresora
Seleccionar Fuentes
Mostrar el fichero de Ayuda
En realidad el cuadro de dilogo permite conocer datos con los cuales, y mediante el cdigo adecuado,
abriremos o guardaremos ficheros, elegiremos colores o seleccionaremos fuentes. Es decir, el
CommonDialog NO realiza mas funciones que mostrar ficheros existentes, fuentes disponibles, colores,
para que, mediante cdigo, abramos esos ficheros o usemos una determinada fuente.
Dependiendo de la aplicacin para la que vaya a usarse se deber activar de distintas formas. Si el cuadro
de dilogo se va a usar para seleccionar la impresora y para otras aplicaciones, es recomendable usar uno
exclusivamente para seleccionar la impresora.
Esta ltima recomendacin se debe a que, para el control de la impresora, el CommonDialog SI realiza las
funciones de seleccin de impresora predeterminada. Esta diferencia operativa hace que si usamos el
mismo CommonDialog para seleccionar impresora y abrir ficheros, por ejemplo, se cuelgue el
CommonDialog.
Eventos: es una accin como hacer clic, doble clic, presionar una tecla, mover el puntero del mouse, etc.
Que el usuario debe realizar para que un objeto ejecute una accin determinada cada control responde a
diferentes eventos, algunos de ellos tienen caractersticas comunes. Los eventos pueden Visualizarse en la
ventana de cdigo.
Mtodos: Son procedimientos definidos en Visual Basic para realizar operaciones especificas sobre los
objetos (Controles o Formularios)
Controles: Son los objetos que conforman la interfaz grafica de un programa;
a travs de ellos, un usuario interacta con la aplicacin. Sus caractersticas
pueden cambiarse por medio de la ventana propiedades
Proyecto:
Propiedades: Son los datos que hacen referencia a un objeto o formulario.
Ejemplo : Color de fondo del formulario, Fuente de texto de un TextBox.
Objetos: Un objeto es una entidad que tiene asociado un conjunto de mtodos, eventos y propiedades.
Hay muchas clases de objetos, y por tanto, puede llegar a haber tantos mtodos, eventos y propiedades
distintas como objetos diferentes.
Ejemplo : Una caja de texto (TextBox) en la cual podemos escribir cualquier lnea es un objeto.
Clases: Una clase no es nada mas que un Objeto, este objeto, tiene propiedades, funciones y mtodos.
Para empezar ahora la creacin de propiedades si se utiliza Property Let y Property Get; la diferencia es
casi nada, inclusive podra decir que una clase en visual basic, es casi lo mismo que un control, pero
ahora nace una nueva pregunta, cuando utilizar un control y cuando utilizar una clase, bueno la opinin
que voy a dar es desde mi perspectiva.
Mdulo: Un proyecto Visual Basic no slo est compuesto de Formularios, sino tambin de lo que se
denominan mdulos.
Un mdulo es un fichero Visual Basic donde escribimos parte del cdigo de nuestro programa, y digo
parte, porque puede haber cdigo en el formulario tambin.
Variable: Dim: Al declarar una variable con esta palabra estamos diciendo que la variable sea local al
mbito en que se declara. Puede ser dentro de un procedimiento o dentro de un formulario, de esta forma
no sera accesible desde los dems procedimientos o formularios.
Public: Las variables declaradas sern publicas y podrn estar accesibles desde todos los formularios de la
aplicacin. Para conseguirlo tendremos que declararlas en un mdulo de cdigo, no en la seccin
declarations de cualquier formulario de los que conste la aplicacin. Para crear un mdulo de cdigo en el
men principal de Visual Basic marcamos en INSERT/MODULE y aparecer junto a los dems
formularios de la ventana de proyecto aunque con un icono distinto indicando que se trata de un mdulo
de cdigo.
Static: Con esta forma de declarar variables conseguiremos que las variables locales no se creen y se
destruyan al entrar y salir de los procedimientos donde fueron declaradas sino que se mantenga su valor
durante todo el periodo de ejecucin de la aplicacin. De esta forma a entrar en algn procedimiento las
variables recuerdan el valor que tenan cuando se sali de l.
TIPOS DE VARIABLES
TIPO COMENTARIO
BOOLEAN Slo admite 2 valores TRUE o FALSE
BYTE admite valores entre 0 y 255
INTEGER admite valores entre -32768 y 32767
LONG admite valores entre -2.147.483.648 y 2.147.483.647
SINGLE admite valores decimales con precisin simple
DOUBLE admite valores decimales de doble precisin
CURRENCY vlido para valores de tipo moneda
STRING cadenas de caracteres
DATE fechas, permite operar con ellas
Constante: Declaracin de constantes que pueden ser usadas en cualquier punto en lugar de su valor,
permitiendo cambiarlo cuando sea necesario, sin tener que cambiarlo en todos los sitios en que se utiliza.
La expresin no puede utilizar llamadas a funciones, pues la constante se calcula en tiempo de
compilacin, no en tiempo de ejecucin.
2.4.3. C#
Caractersticas de C#.- Con la idea de que los programadores ms experimentados puedan obtener una
visin general del lenguaje, a continuacin se recoge de manera resumida las principales caractersticas de
C# Alguna de las caractersticas aqu sealadas no son exactamente propias del lenguaje sino de la
plataforma .NET en general. Sin embargo, tambin se comentan aqu tambin en tanto que tienen
repercusin directa en el lenguaje, aunque se indicar explcitamente cules son este tipo de
caractersticas cada vez que se toquen:
Sencillez: C# elimina muchos elementos que otros lenguajes incluyen y que son innecesarios en
.NET. Por ejemplo:
o El cdigo escrito en C# es autocontenido, lo que significa que no necesita de ficheros
adicionales al propio fuente tales como ficheros de cabecera o ficheros IDL
o El tamao de los tipos de datos bsicos es fijo e independiente del compilador, sistema operativo
o mquina para quienes se compile (no como en C++), lo que facilita la portabilidad del cdigo.
o No se incluyen elementos poco tiles de lenguajes como C++ tales como macros, herencia
mltiple o la necesidad de un operador diferente del punto (.) acceder a miembros de espacios de nombres
(::)
Modernidad: C# incorpora en el propio lenguaje elementos que a lo largo de los aos ha ido
demostrndose son muy tiles para el desarrollo de aplicaciones y que en otros lenguajes como Java o
C++ hay que simular, como un tipo bsico decimal que permita realizar operaciones de alta precisin con
reales de 128 bits (muy til en el mundo financiero), la inclusin de una instruccin foreach que permita
recorrer colecciones con facilidad y es ampliable a tipos definidos por el usuario, la inclusin de un tipo
bsico string para representar cadenas o la distincin de un tipo bool especfico para representar valores
lgicos.
Orientacin a objetos: Como todo lenguaje de programacin de propsito general actual, C# es
un lenguaje orientado a objetos, aunque eso es ms bien una caracterstica del CTS que de C#. Una
diferencia de este enfoque orientado a objetos respecto al de otros lenguajes como C++ es que el de C# es
ms puro en tanto que no admiten ni funciones ni variables globales sino que todo el cdigo y datos han
de definirse dentro de definiciones de tipos de datos, lo que reduce problemas por conflictos de nombres y
facilita la legibilidad del cdigo.
C# soporta todas las caractersticas propias del paradigma de programacin orientada a objetos:
encapsulacin, herencia y polimorfismo.
En lo referente a la encapsulacin es importante sealar que aparte de los
tpicos modificadores public, private y protected, C# aade un cuarto modificador llamado internal,
que puede combinarse con protected e indica que al elemento a cuya definicin precede slo puede
accederse desde su mismo ensamblado.
Respecto a la herencia -a diferencia de C++ y al igual que Java- C# slo admite herencia simple
de clases ya que la mltiple provoca ms quebraderos de cabeza que facilidades y en la mayora de los
casos su utilidad puede ser simulada con facilidad mediante herencia mltiple de interfaces. De todos
modos, esto vuelve a ser ms bien una caracterstica propia del CTS que de C#.
Por otro lado y a diferencia de Java, en C# se ha optado por hacer que todos los mtodos sean por
defecto sellados y que los redefinibles hayan de marcarse con el modificador virtual (como en
C++), lo que permite evitar errores derivados de redefiniciones accidentales. Adems, un efecto
secundario de esto es que las llamadas a los mtodos sern ms eficientes por defecto al no tenerse
que buscar en la tabla de funciones virtuales la implementacin de los mismos a la que se ha de llamar.
Otro efecto secundario es que permite que las llamadas a los mtodos virtuales se puedan hacer ms
eficientemente al contribuir a que el tamao de dicha tabla se reduzca.
Orientacin a componentes: La propia sintaxis de C# incluye elementos propios del diseo de
componentes que otros lenguajes tienen que simular mediante construcciones ms o menos complejas. Es
decir, la sintaxis de C# permite definir cmodamente propiedades (similares a campos de acceso
controlado), eventos (asociacin controlada de funciones de respuesta a notificaciones) o atributos
(informacin sobre un tipo o sus miembros)
Gestin automtica de memoria: Como ya se coment, todo lenguaje de .NET tiene a su
disposicin el recolector de basura del CLR. Esto tiene el efecto en el lenguaje de que no es necesario
incluir instrucciones de destruccin de objetos. Sin embargo, dado que la destruccin de los objetos a
travs del recolector de basura es indeterminista y slo se realiza cuando ste se active ya sea por falta
de memoria, finalizacin de la aplicacin o solicitud explcita en el fuente-, C# tambin proporciona un
mecanismo de liberacin de recursos determinista a travs de la instruccin using.
Seguridad de tipos: C# incluye mecanismos que permiten asegurar que los accesos a tipos de
datos siempre se realicen correctamente, lo que permite evita que se produzcan errores difciles de
detectar por acceso a memoria no perteneciente a ningn objeto y es especialmente necesario en un
entorno gestionado por un recolector de basura. Para ello se toman medidas del tipo:
o Slo se admiten conversiones entre tipos compatibles. Esto es, entre un tipo y antecesores suyos,
entre tipos para los que explcitamente se haya definido un operador de conversin, y entre un tipo y un
tipo hijo suyo del que un objeto del primero almacenase una referencia del segundo (downcasting)
Obviamente, lo ltimo slo puede comprobarlo en tiempo de ejecucin el CLR y no el compilador, por lo
que en realidad el CLR y el compilador colaboran para asegurar la correccin de las conversiones.
o No se pueden usar variables no inicializadas. El compilador da a los campos un valor por
defecto consistente en ponerlos a cero y controla mediante anlisis del flujo de control del fuente que no
se lea ninguna variable local sin que se le haya asignado previamente algn valor.
o Se comprueba que todo acceso a los elementos de una tabla se realice con ndices que se
encuentren dentro del rango de la misma.
o Se puede controlar la produccin de desbordamientos en operaciones aritmticas, informndose
de ello con una excepcin cuando ocurra. Sin embargo, para conseguirse un mayor rendimiento en la
aritmtica estas comprobaciones no se hacen por defecto al operar con variables sino slo con constantes
(se pueden detectar en tiempo de compilacin)
o A diferencia de Java, C# incluye delegados, que son similares a los punteros a funciones de C++
pero siguen un enfoque orientado a objetos, pueden almacenar referencias a varios mtodos
simultneamente, y se comprueba que los mtodos a los que apunten tengan parmetros y valor de retorno
del tipo indicado al definirlos.
o Pueden definirse mtodos que admitan un nmero indefinido de parmetros de un cierto tipo, y a
diferencia lenguajes como C/C++, en C# siempre se comprueba que los valores que se les pasen en cada
llamada sean de los tipos apropiados.
Instrucciones seguras: Para evitar errores muy comunes, en C# se han impuesto una serie de
restricciones en el uso de las instrucciones de control ms comunes. Por ejemplo, la guarda de toda
condicin ha de ser una expresin condicional y no aritmtica, con lo que se evitan errores por confusin
del operador de igualdad (==) con el de asignacin (=); y todo caso de un switch ha de terminar en un
break o goto que indique cul es la siguiente accin a realizar, lo que evita la ejecucin accidental de
casos y facilita su reordenacin.
Sistema de tipos unificado: A diferencia de C++, en C# todos los tipos de datos que se definan
siempre derivarn, aunque sea de manera implcita, de una clase base comn llamada System.Object, por
lo que dispondrn de todos los miembros definidos en sta clase (es decir, sern objetos)
A diferencia de Java, en C# esto tambin es aplicable a los tipos de datos bsicos Adems, para
conseguir que ello no tenga una repercusin negativa en su nivel de rendimiento, se ha incluido un
mecanismo transparente de boxing y unboxing con el que se consigue que slo sean tratados como
objetos cuando la situacin lo requiera, y mientras tanto puede aplicrseles optimizaciones especficas.
El hecho de que todos los tipos del lenguaje deriven de una clase comn facilita enormemente el
diseo de colecciones genricas que puedan almacenar objetos de cualquier tipo.
Extensibilidad de tipos bsicos: C# permite definir, a travs de estructuras, tipos de datos para
los que se apliquen las mismas optimizaciones que para los tipos de datos bsicos. Es decir, que se
puedan almacenar directamente en pila (luego su creacin, destruccin y acceso sern ms rpidos) y se
asignen por valor y no por referencia. Para conseguir que lo ltimo no tenga efectos negativos al pasar
estructuras como parmetros de mtodos, se da la posibilidad de pasar referencias a pila a travs del
modificador de parmetro ref.
Extensibilidad de operadores: Para facilitar la legibilidad del cdigo y conseguir que los nuevos
tipos de datos bsicos que se definan a travs de las estructuras estn al mismo nivel que los bsicos
predefinidos en el lenguaje, al igual que C++ y a diferencia de Java, C# permite redefinir el significado de
la mayora de los operadores -incluidos los de conversin, tanto para conversiones implcitas como
explcitas- cuando se apliquen a diferentes tipos de objetos.
Las redefiniciones de operadores se hacen de manera inteligente, de modo que a partir de una
nica definicin de los operadores ++ y el compilador puede deducir automticamente como
ejecutarlos de manera prefijas y postifja; y definiendo operadores simples (como +), el compilador
deduce cmo aplicar su versin de asignacin compuesta (+=) Adems, para asegurar la consistencia, el
compilador vigila que los operadores con opuesto siempre se redefinan por parejas (por ejemplo, si se
redefine ==, tambin hay que redefinir !=)
Tambin se da la posibilidad, a travs del concepto de indizador, de redefinir el significado del
operador [] para los tipos de dato definidos por el usuario, con lo que se consigue que se pueda acceder al
mismo como si fuese una tabla. Esto es muy til para trabajar con tipos que acten como colecciones de
objetos.
Extensibilidad de modificadores: C# ofrece, a travs del concepto de atributos, la posibilidad de
aadir a los metadatos del mdulo resultante de la compilacin de cualquier fuente informacin adicional
a la generada por el compilador que luego podr ser consultada en tiempo ejecucin a travs de la
librera de reflexin de .NET . Esto, que ms bien es una caracterstica propia de la plataforma .NET y no
de C#, puede usarse como un mecanismo para definir nuevos modificadores.
Versionable: C# incluye una poltica de versionado que permite crear nuevas versiones de tipos
sin temor a que la introduccin de nuevos miembros provoquen errores difciles de detectar en tipos hijos
previamente desarrollados y ya extendidos con miembros de igual nombre a los recin introducidos.
Si una clase introduce un nuevo mtodo cuyas redefiniciones deban seguir la regla de llamar a la
versin de su padre en algn punto de su cdigo, difcilmente seguiran esta regla miembros de su misma
signatura definidos en clases hijas previamente a la definicin del mismo en la clase padre; o si introduce
un nuevo campo con el mismo nombre que algn mtodo de una clase hija, la clase hija dejar de
funcionar. Para evitar que esto ocurra, en C# se toman dos medidas:
o Se obliga a que toda redefinicin deba incluir el modificador override, con lo que la versin de
la clase hija nunca sera considerada como una redefinicin de la versin de miembro en la clase padre ya
que no incluira override. Para evitar que por accidente un programador incluya este modificador, slo se
permite incluirlo en miembros que tengan la misma signatura que miembros marcados como redefinibles
mediante el modificador virtual. As adems se evita el error tan frecuente en Java de creerse haber
redefinido un miembro, pues si el miembro con override no existe en la clase padre se producir un error
de compilacin.
o Si no se considera redefinicin, entonces se considera que lo que se desea es ocultar el mtodo
de la clase padre, de modo que para la clase hija sea como si nunca hubiese existido. El compilador
avisar de esta decisin a travs de un mensaje de aviso que puede suprimirse incluyendo el modificador
new en la definicin del miembro en la clase hija para as indicarle explcitamente la intencin de
ocultacin.
Eficiente: En principio, en C# todo el cdigo incluye numerosas restricciones para asegurar su
seguridad y no permite el uso de punteros. Sin embargo, y a diferencia de Java, en C# es posible saltarse
dichas restricciones manipulando objetos a travs de punteros. Para ello basta marcar regiones de cdigo
como inseguras (modificador unsafe) y podrn usarse en ellas punteros de forma similar a cmo se hace
en C++, lo que puede resultar vital para situaciones donde se necesite una eficiencia y velocidad
procesamiento muy grandes.
Compatible: Para facilitar la migracin de programadores, C# no slo mantiene una sintaxis muy
similar a C, C++ o Java que permite incluir directamente en cdigo escrito en C# fragmentos de cdigo
escrito en estos lenguajes, sino que el CLR tambin ofrece, a travs de los llamados Platform Invocation
Services (PInvoke), la posibilidad de acceder a cdigo nativo escrito como funciones sueltas no
orientadas a objetos tales como las DLLs de la API Win32. Ntese que la capacidad de usar punteros en
cdigo inseguro permite que se pueda acceder con facilidad a este tipo de funciones, ya que stas muchas
veces esperan recibir o devuelven punteros.
Tambin es posible acceder desde cdigo escrito en C# a objetos COM. Para facilitar esto, el
.NET Framework SDK incluye una herramientas llamadas tlbimp y regasm mediante las que es posible
generar automticamente clases proxy que permitan, respectivamente, usar objetos COM desde .NET
como si de objetos .NET se tratase y registrar objetos .NET para su uso desde COM.
Finalmente, tambin se da la posibilidad de usar controles ActiveX desde cdigo .NET y viceversa. Para
lo primero se utiliza la utilidad aximp, mientras que para lo segundo se usa la ya mencionada regasm.
2.5 SISTEMAS GESTORES DE BASE DE DATOS:
Los sistemas gestores de base de datos son un tipo de software especifico, dedicado a servir de interfaz
entre la base de datos y el usuario, las aplicaciones que la utilizan. Se compone de un lenguaje de
definicin de datos de un lenguaje de manipulacin de datos y de un lenguaje de consulta.
2.5.1. MYSQL
1. Qu es MySQL?
Es un sistema de gestin de bases de datos relacional, fue creada por la empresa sueca MySQL AB, la
cual tiene el copyright del cdigo fuente del servidor SQL, as como tambin de la marca.
MySQL es un software de cdigo abierto, licenciado bajo la GPL de la GNU, aunque MySQL AB
distribuye una versin comercial, en lo nico que se diferencia de la versin libre, es en el soporte tcnico
que se ofrece, y la posibilidad de integrar este gestor en un software propietario, ya que de otra manera, se
vulnerara la licencia GPL.
El lenguaje de programacin que utiliza MySQL es Structured Query Language (SQL) que fue
desarrollado por IBM en 1981 y desde entonces es utilizado de forma generalizada en las bases de datos
relacionales.
MySQL es un sistema de gestin de bases de datos relacional, multihilo y multiusuario con ms de seis
millones de instalaciones.[1] MySQL AB desde enero de 2008 una subsidiaria de Sun Microsystems y
sta a su vez de Oracle Corporation desde abril de 2009 desarrolla MySQL como software libre en un
esquema de licenciamiento dual.
MySQL es muy utilizado en aplicaciones web, como Drupal o phpBB, en plataformas (Linux/Windows-
Apache-MySQL-PHP/Perl/Python), y por herramientas de seguimiento de errores como Bugzilla. Su
popularidad como aplicacin web est muy ligada a PHP, que a menudo aparece en combinacin con
MySQL. MySQL es una base de datos muy rpida en la lectura cuando utiliza el motor no transaccional
MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la
modificacin. En aplicaciones web hay baja concurrencia en la modificacin de datos y en cambio el
entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones. Sea
cual sea el entorno en el que va a utilizar MySQL, es importante monitorizar de antemano el rendimiento
para detectar y corregir errores tanto de SQL como de programacin. Por un lado se ofrece bajo la GNU
GPL para cualquier uso compatible con esta licencia, pero para aquellas empresas que quieran
incorporarlo en productos privativos deben comprar a la empresa una licencia especfica que les permita
este uso. Est desarrollado en su mayor parte en ANSI C. Al contrario de proyectos como Apache, donde
el software es desarrollado por una comunidad pblica y los derechos de autor del cdigo estn en poder
del autor individual, MySQL es patrocinado por una empresa privada, que posee el copyright de la mayor
parte del cdigo. Esto es lo que posibilita el esquema de licenciamiento anteriormente mencionado.
Adems de la venta de licencias privativas, la compaa ofrece soporte y servicios
2. Historia de MySQL
MySQL surgi alrededor de la dcada del 90, Michael Windenis comenz a usar mSQL para conectar
tablas usando sus propias rutinas de bajo nivel (ISAM). Tras unas primeras pruebas, lleg a la conclusin
de que mSQL no era lo bastante flexible ni rpido para lo que necesitaba, por lo que tuvo que desarrollar
nuevas funciones. Esto resulto en una interfaz SQL a su base de datos, totalmente compatible a mSQL.
El origen del nombre MySQL no se sabe con certeza de donde proviene, por una lado se dice que en sus
libreras han llevado el prefijo my durante los diez ltimos aos, por otra parte, la hija de uno de los
desarrolladores se llama My. As que no est claramente definido cual de estas dos causas han dado lugar
al nombre de este conocido gestor de bases de datos.
Para sus operaciones contratan trabajadores alrededor del mundo que colaboran va Internet. MySQL AB
fue fundado por David Axmark, Allan Larsson y Michael Widenius.
Al contrario de proyectos como el Apache, donde el software es desarrollado por una comunidad pblica,
y el copyright del cdigo est en poder del autor individual, MySQL est poseIdo y patrocinado por una
empresa privada, que posee el copyright de la mayor parte del cdigo. MySQL AB fue fundado por David
Axmark, Allan Larsson, y Michael Widenius.
3. Caractersticas principales
Inicialmente, MySQL careca de algunos elementos esenciales en las bases de datos relacionales, tales
como integridad referencial y transacciones. A pesar de esto, atrajo a los desarrolladores de pginas web
con contenido dinmico, debido a su simplicidad, de tal manera que los elementos faltantes fueron
complementados por la va de las aplicaciones que la utilizan. Poco a poco estos elementos faltantes,
estn siendo incorporados tanto por desarrolladores internos, como por desarrolladores de software libre.
En las ltimas versiones se pueden destacar las siguientes caractersticas principales:
El principal objetivo de MySQL es velocidad y robustez.
Soporta gran cantidad de tipos de datos para las columnas.
Gran portabilidad entre sistemas, puede trabajar en distintas plataformas y sistemas operativos.
Cada base de datos cuenta con 3 archivos: Uno de estructura, uno de datos y uno de ndice y
soporta hasta 32 ndices por tabla.
Aprovecha la potencia de sistemas multiproceso, gracias a su implementacin multihilo.
Flexible sistema de contraseas (passwords) y gestin de usuarios, con un muy buen nivel de
seguridad en los datos.
El servidor soporta mensajes de error en distintas lenguas
4. VENTAJAS
Velocidad al realizar las operaciones, lo que le hace uno de los gestores con mejor rendimiento.
Bajo costo en requerimientos para la elaboracin de bases de datos, ya que debido a su bajo
consumo puede ser ejecutado en una mquina con escasos recursos sin ningn problema.
Facilidad de configuracin e instalacin.
Soporta gran variedad de Sistemas Operativos
Baja probabilidad de corromper datos, incluso si los errores no se producen en el propio gestor,
sino en el sistema en el que est.
Conectividad y seguridad
5. DESVENTAJAS
Un gran porcentaje de las utilidades de MySQL no estn documentadas.
No es intuitivo, como otros programas (ACCESS).
6. PANORMICA DE PROGRAMAS MYSQL
MySQL AB proporciona varios tipos de programas:
El servidor MYSQL y los scripts de inicio del servidor:
o mysqld es el servidor MySQL
o mysqld_safe, mysql.server, y mysqld_multi son scripts de inicio del servidor
o mysql_install_db inicializa el directorio data y las bases de datos que MySQL instala por
defecto. .
Programas cliente que acceden al servidor:
o mysql es un programa cliente que porporciona una interfaz de linea de comandos para ejecutar
sentencias SQL en modo interactivo o por lotes.
o mysqladmin es un cliente para administracin.
o mysqlcheck ejecuta operaciones de mantenimiento de tablas.
o mysqldump y mysqlhotcopy son utilidades para copia de respaldo.
o mysqlimport realiza importacin de ficheros de datos.
o mysqlshow muestra informacin relativa a tablas y bases de datos. .
Programas que operan independientemente del servidor:
o myisamchk ejecuta operaciones de mantenimiento de tablas.
o myisampack genera tablas comprimidas, de slo lectura.
o mysqlbinlog es una herramienta para procesar archivos de registro binario (binary logs).
o perror informa el significado de un cdigo de error.
La mayora de las distribuciones de MySQL incluyen todos los programas mencionados, con excepcin
de los que son especficos de cada plataforma. (Por ejemplo, los scripts de inicio de servidor no son
necesarios en Windows). Otra excepcin es que las distribuciones RPM son ms especializadas. Existe
una RPM para el servidor, otra para los programas cliente, etc.
2.5.2 SQL SERVER
1. Introduccin a SQL SERVER
El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por el
motor de base de datos de Microsoft Jet. SQL se utiliza para crear objetos QueryDef, como el argumento
de origen del mtodo OpenRecordSet y como la propiedad RecordSource del control de datos. Tambin
se puede utilizar con el mtodo Execute para crear y manipular directamente las bases de datos Jet y crear
consultas SQL de paso a travs para manipular bases de datos remotas cliente servidor.
1.1. Componentes del SQL
El lenguaje SQL est compuesto por comandos, clusulas, operadores y funciones de agregado. Estos
elementos se combinan en las instrucciones para crear, actualizar y manipular las bases de datos.
1.2 Comandos
Existen dos tipos de comandos SQL:
los DLL que permiten crear y definir nuevas bases de datos, campos e ndices.
los DML que permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos.
Comandos DLL
Comando Descripcin
CREATE Utilizado para crear nuevas tablas, campos e ndices
DROP Empleado para eliminar tablas e ndices
ALTER Utilizado para modificar las tablas agregando campos o cambiando la definicin de los campos.
Comandos DML
Comando Descripcin
SELECT Utilizado para consultar registros de la base de datos que satisfagan un criterio determinado
INSERT Utilizado para cargar lotes de datos en la base de datos en una nica operacin.
UPDATE Utilizado para modificar los valores de los campos y registros especificados
DELETE Utilizado para eliminar registros de una tabla de una base de datos
1.3 Clusulas
Las clusulas son condiciones de modificacin utilizadas para definir los datos que desea seleccionar o
manipular.
Clusula Descripcin
FROM Utilizada para especificar la tabla de la cual se van a seleccionar los registros
WHERE Utilizada para especificar las condiciones que deben reunir los registros que se van a seleccionar
GROUP BY Utilizada para separar los registros seleccionados en grupos especficos
HAVING Utilizada para expresar la condicin que debe satisfacer cada grupo
ORDER BY Utilizada para ordenar los registros seleccionados de acuerdo con un orden especfico
1.4 Operadores Lgicos
Operador Uso
AND Es el y lgico. Evalua dos condiciones y devuelve un valor de verdad slo si ambas son
ciertas.
OR Es el o lgico. Evala dos condiciones y devuelve un valor de verdar si alguna de las dos es
cierta.
NOT Negacin lgica. Devuelve el valor contrario de la expresin.
1.5 Operadores de Comparacin
Operador Uso
Mayor que
Distinto de
= Mayor Igual que
= Igual que
BETWEEN Utilizado para especificar un intervalo de valores.
LIKE Utilizado en la comparacin de un modelo
In Utilizado para especificar registros de una base de datos
1.6 Funciones de Agregado
Las funciones de agregado se usan dentro de una clusula SELECT en grupos de registros para devolver
un nico valor que se aplica a un grupo de registros.
Funcin Descripcin
AVG Utilizada para calcular el promedio de los valores de un campo determinado
COUNT Utilizada para devolver el nmero de registros de la seleccin
SUM Utilizada para devolver la suma de todos los valores de un campo determinado
MAX Utilizada para devolver el valor ms alto de un campo especificado
MIN Utilizada para devolver el valor ms bajo de un campo especificado
Consultas de Seleccin
Las consultas de seleccin se utilizan para indicar al motor de datos que devuelva informacin de las
bases de datos, esta informacin es devuelta en forma de conjunto de registros que se pueden almacenar
en un objeto recordset. Este conjunto de registros es modificable.
2.1 Consultas bsicas
La sintaxis bsica de una consulta de seleccin es la siguiente:
SELECT Campos FROM Tabla;
En donde campos es la lista de campos que se deseen recuperar y tabla es el origen de los mismos, por
ejemplo:
SELECT Nombre, Telefono FROM Clientes;
Esta consulta devuelve un recordset con el campo nombre y telfono de la tabla clientes.
2.2 Ordenar los registros
Adicionalmente se puede especificar el orden en que se desean recuperar los registros de las tablas
mediante la clasula ORDER BY Lista de Campos. En donde Lista de campos representa los campos
aordenar. Ejemplo:
SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY Nombre;
Esta consulta devuelve los campos CodigoPostal, Nombre, Telefono de la tabla Clientes ordenados por el
campo Nombre.
Se pueden ordenar los registros por mas de un campo, como por ejemplo:
SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY
CodigoPostal, Nombre;
Incluso se puede especificar el orden de los registros: ascendente mediante la clasula (ASC -se toma este
valor por defecto) descendente (DESC)
SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY
CodigoPostal DESC , Nombre ASC;
2.3 Consultas con Predicado
El predicado se incluye entre la clasula y el primer nombre del campo a recuperar, los posibles
predicados son:
Predicado Descripcin
ALL Devuelve todos los campos de la tabla
TOP Devuelve un determinado nmero de registros de la tabla
DISTINCT Omite los registros cuyos campos seleccionados coincidan totalmente
DISTINCTROW Omite los registros duplicados basandose en la totalidad del registro y no slo en los
campos seleccionados.
ALL
Si no se incluye ninguno de los predicados se asume ALL. El Motor de base de datos selecciona todos
los registros que cumplen las condiciones de la instruccin SQL. No se conveniente abusar de este
predicado ya que obligamos al motor de la base de datos a analizar la estructura de la tabla para averiguar
los campos que contiene, es mucho ms rpido indicar el listado de campos deseados.
SELECT ALL FROM Empleados;
SELECT * FROM Empleados;
TOP
Devuelve un cierto nmero de registros que entran entre al principio o al final de un rango especificado
por una clusula ORDER BY. Supongamos que queremos recuperar los nombres de los 25 primeros
estudiantes del curso 1994:
SELECT TOP 25 Nombre, Apellido FROM Estudiantes
ORDER BY Nota DESC;
Si no se incluye la clusula ORDER BY, la consulta devolver un conjunto arbitrario de 25 registros de la
tabla Estudiantes .El predicado TOP no elige entre valores iguales. En el ejemplo anterior, si la nota
media nmero 25 y la 26 son iguales, la consulta devolver 26 registros. Se puede utilizar la palabra
reservada PERCENT para devolver un cierto porcentaje de registros que caen al principio o al final de un
rango especificado por la clusula ORDER BY. Supongamos que en lugar de los 25 primeros estudiantes
deseamos el 10 por ciento del curso:
SELECT TOP 10 PERCENT Nombre, Apellido FROM Estudiantes
ORDER BY Nota DESC;
El valor que va a continuacin de TOP debe ser un Integer sin signo.TOP no afecta a la posible
actualizacin de la consulta.
DISTINCT
Omite los registros que contienen datos duplicados en los campos seleccionados. Para que los valores de
cada campo listado en la instruccin SELECT se incluyan en la consulta deben ser nicos.
Por ejemplo, varios empleados listados en la tabla Empleados pueden tener el mismo apellido. Si dos
registros contienen Lpez en el campo Apellido, la siguiente instruccin SQL devuelve un nico registro:
SELECT DISTINCT Apellido FROM Empleados;
Con otras palabras el predicado DISTINCT devuelve aquellos registros cuyos campos indicados en la
clusula SELECT posean un contenido diferente. El resultado de una consulta que utiliza DISTINCT no
es actualizable y no refleja los cambios subsiguientes realizados por otros usuarios.
DISTINCTROW
Devuelve los registros diferentes de una tabla; a diferencia del predicado anterior que slo se fijaba en el
contenido de los campos seleccionados, ste lo hace en el contenido del registro completo
independientemente de los campo indicados en la clusula SELECT.
SELECT DISTINCTROW Apellido FROM Empleados;
Si la tabla empleados contiene dos registros: Antonio Lpez y Marta Lpez el ejemplo del predicado
DISTINCT devuleve un nico registro con el valor Lpez en el campo Apellido ya que busca no
duplicados en dicho campo. Este ltimo ejemplo devuelve dos registros con el valor Lpez en el apellido
ya que se buscan no duplicados en el registro completo.
2.4 Alias
En determinadas circunstancias es necesario asignar un nombre a alguna columna determinada de un
conjunto devuelto, otras veces por simple capricho o por otras circunstancias. Para resolver todas ellas
tenemos la palabra reservada AS que se encarga de asignar el nombre que deseamos a la columna
deseada. Tomado como referencia el ejemplo anterior podemos hacer que la columna devuelta por la
consulta, en lugar de llamarse apellido (igual que el campo devuelto) se llame Empleado. En este caso
procederamos de la siguiente forma:
SELECT DISTINCTROW Apellido AS Empleado FROM Empleados;
2.5 Recuperar Informacin de una base de Datos Externa
Para concluir este captulo se debe hacer referencia a la recuperacin de registros de bases de datos
externa. Es ocasiones es necesario la recuperacin de informacin que se encuentra contenida en una
tabla que no se encuentra en la base de datos que ejecutar la consulta o que en ese momento no se
encuentra abierta, esta situacin la podemos salvar con la palabra reservada IN de la siguiente forma:
SELECT DISTINCTROW Apellido AS Empleado FROM Empleados
IN c:\databases\gestion.mdb;
En donde c:\databases\gestion.mdb es la base de datos que contiene la tabla Empleados.
3. Criterios de Seleccin
Antes de comenzar el desarrollo de este captulo hay que recalcar tres detalles de vital importancia. El
primero de ellos es que cada vez que se desee establecer una condicin referida a un campo de texto la
condicin de bsqueda debe ir encerrada entre comillas simples; la segunda es que no se posible
establecer condiciones de bsqueda en los campos memo y; la tercera y ltima hace referencia a las
fechas. Las fechas se deben escribir siempre en formato mm-dd-aa en donde mm representa el mes, dd el
da y aa el ao, hay que prestar atencin a los separadores -no sirve la separacin habitual de la barra (/),
hay que utilizar el guin (-) y adems la fecha debe ir encerrada entre almohadillas (#). Por ejemplo si
deseamos referirnos al da 3 de Septiembre de 1995 deberemos hacerlo de la siguiente forma; #09-03-95#
#9-3-95#.
3.1 Operadores Lgicos
Los operadores lgicos soportados por SQL son: AND, OR, XOR, Eqv, Imp, Is y Not. A excepcin de los
dos ltimos todos poseen la siguiente sintaxis:
operador
En donde expresin1 y expresin2 son las condiciones a evaluar, el resultado de la operacin vara en
funcin del operador lgico. La tabla adjunta muestra los diferentes posibles resultados:
Operador Resultado
Verdad AND Falso Falso
Verdad AND Verdad Verdad
Falso AND Verdad Falso
Falso AND Falso Falso
Verdad OR Falso Verdad
Verdad OR Verdad Verdad
Falso OR Verdad Verdad
Falso OR Falso Falso
Verdad XOR Verdad Falso
Verdad XOR Falso Verdad
Falso XOR Verdad Verdad
Falso XOR Falso Falso
Verdad Eqv Verdad Verdad
Verdad Eqv Falso Falso
Falso Eqv Verdad Falso
Falso Eqv Falso Verdad
Verdad Imp Verdad Verdad
Verdad Imp Falso Falso
Verdad Imp Null Null
Falso Imp Verdad Verdad
Falso Imp Falso Verdad
Falso Imp Null Verdad
Null Imp Verdad Verdad
Null Imp Falso Null
Null Imp Null Null
Si a cualquiera de las anteriores condiciones le anteponemos el operador NOT el resultado de la
operacin ser el contrario al devuelto sin el operador NOT.
El ltimo operador denominado Is se emplea para comparar dos variables de tipo objeto Is . este operador
devuelve verdad si los dos objetos son iguales
SELECT * FROM Empleados WHERE Edad > 25 AND Edad 25 AND Edad 100 AND
Sueldo 21000;
SELECT Id_Producto, Existencias FROM Productos
WHERE Existencias 100 AND NombreProducto Like BOS*;
4.2 AVG
Calcula la media aritmtica de un conjunto de valores contenidos en un campo especificado de una
consulta. Su sintaxis es la siguiente
Avg(expr)
En donde expr representa el campo que contiene los datos numricos para los que se desea calcular la
media o una expresin que realiza un clculo utilizando los datos de dicho campo. La media calculada por
Avg es la media aritmtica (la suma de los valores dividido por el nmero de valores). La funcin Avg no
incluye ningn campo Null en el clculo.
SELECT Avg(Gastos) AS Promedio FROM Pedidos WHERE Gastos > 100;
4.3 Count
Calcula el nmero de registros devueltos por una consulta. Su sintaxis es la siguiente
Count(expr)
En donde expr contiene el nombre del campo que desea contar. Los operandos de expr pueden incluir el
nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por
el usuario pero no otras de las funciones agregadas de SQL). Puede contar cualquier tipo de datos incluso
texto.
Aunque expr puede realizar un clculo sobre un campo, Count simplemente cuenta el nmero de registros
sin tener en cuenta qu valores se almacenan en los registros. La funcin Count no cuenta los registros
que tienen campos null a menos que expr sea el carcter comodn asterisco (*). Si utiliza un asterisco,
Count calcula el nmero total de registros, incluyendo aquellos que contienen campos null. Count(*) es
considerablemente ms rpida que Count(Campo). No se debe poner el asterisco entre dobles comillas
(*).
SELECT Count(*) AS Total FROM Pedidos;
Si expr identifica a mltiples campos, la funcin Count cuenta un registro slo si al menos uno de los
campos no es Null. Si todos los campos especificados son Null, no se cuenta el registro. Hay que separar
los nombres de los campos con ampersand (&).
SELECT Count(FechaEnvo & Transporte) AS Total FROM Pedidos;
4.4 Max, Min
Devuelven el mnimo o el mximo de un conjunto de valores contenidos en un campo especifico de una
consulta. Su sintaxis es:
Min(expr)
Max(expr)
En donde expr es el campo sobre el que se desea realizar el clculo. Expr pueden incluir el nombre de un
campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el usuario
pero no otras de las funciones agregadas de SQL).
SELECT Min(Gastos) AS ElMin FROM Pedidos WHERE Pais = Espaa;
SELECT Max(Gastos) AS ElMax FROM Pedidos WHERE Pais = Espaa;
4.5 StDev, StDevP
Devuelve estimaciones de la desviacin estndar para la poblacin (el total de los registros de la tabla) o
una muestra de la poblacin representada (muestra aleatoria) . Su sintaxis es:
StDev(expr)
StDevP(expr)
En donde expr representa el nombre del campo que contiene los datos que desean evaluarse o una
expresin que realiza un clculo utilizando los datos de dichos campos. Los operandos de expr pueden
incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o
definida por el usuario pero no otras de las funciones agregadas de SQL)
StDevP evala una poblacin, y StDev evala una muestra de la poblacin. Si la consulta contiene menos
de dos registros (o ningn registro para StDevP), estas funciones devuelven un valor Null (el cual indica
que la desviacin estndar no puede calcularse).
SELECT StDev(Gastos) AS Desviacion FROM Pedidos WHERE Pais = Espaa;
SELECT StDevP(Gastos) AS Desviacion FROM Pedidos WHERE Pais= Espaa;
4.6 Sum
Devuelve la suma del conjunto de valores contenido en un campo especifico de una consulta. Su sintaxis
es:
Sum(expr)
En donde expr respresenta el nombre del campo que contiene los datos que desean sumarse o una
expresin que realiza un clculo utilizando los datos de dichos campos. Los operandos de expr pueden
incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o
definida por el usuario pero no otras de las funciones agregadas de SQL).
SELECT Sum(PrecioUnidad * Cantidad) AS Total FROM DetallePedido;
4.7 Var, VarP
Devuelve una estimacin de la varianza de una poblacin (sobre el total de los registros) o una muestra de
la poblacin (muestra aleatoria de registros) sobre los valores de un campo. Su sintaxis es:
Var(expr)
VarP(expr)
VarP evala una poblacin, y Var evala una muestra de la poblacin. Expr el nombre del campo que
contiene los datos que desean evaluarse o una expresin que realiza un clculo utilizando los datos de
dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante
o una funcin (la cual puede ser intrnseca o definida por el usuario pero no otras de las funciones
agregadas de SQL)
Si la consulta contiene menos de dos registros, Var y VarP devuelven Null (esto indica que la varianza no
puede calcularse). Puede utilizar Var y VarP en una expresin de consulta o en una Instruccin SQL.
SELECT Var(Gastos) AS Varianza FROM Pedidos WHERE Pais = Espaa;
SELECT VarP(Gastos) AS Varianza FROM Pedidos WHERE Pais = Espaa;
5. Consultas de Accin
Las consultas de accin son aquellas que no devuelven ningn registro, son las encargadas de acciones
como aadir y borrar y modificar registros.
5.1 DELETE
Crea una consulta de eliminacin que elimina los registros de una o ms de las tablas listadas en la
clusula FROM que satisfagan la clusula WHERE. Esta consulta elimina los registros completos, no es
posible eliminar el contenido de algn campo en concreto. Su sintaxis es:
DELETE Tabla.* FROM Tabla WHERE criterio
DELETE es especialmente til cuando se desea eliminar varios registros. En una instruccin DELETE
con mltiples tablas, debe incluir el nombre de tabla (Tabla.*). Si especifica ms de una tabla desde la
que eliminar registros, todas deben ser tablas de muchos a uno. Si desea eliminar todos los registros de
una tabla, eliminar la propia tabla es ms eficiente que ejecutar una consulta de borrado.
Se puede utilizar DELETE para eliminar registros de una nica tabla o desde varios lados de una relacin
uno a muchos. Las operaciones de eliminacin en cascada en una consulta nicamente eliminan desde
varios lados de una relacin. Por ejemplo, en la relacin entre las tablas Clientes y Pedidos, la tabla
Pedidos es la parte de muchos por lo que las operaciones en cascada solo afectaran a la tabla Pedidos.
Una consulta de borrado elimina los registros completos, no nicamente los datos en campos especficos.
Si desea eliminar valores en un campo especificado, crear una consulta de actualizacin que cambie los
valores a Null.
Una vez que se han eliminado los registros utilizando una consulta de borrado, no puede deshacer la
operacin. Si desea saber qu registros se eliminarn, primero examine los resultados de una consulta de
seleccin que utilice el mismo criterio y despus ejecute la consulta de borrado. Mantenga copias de
seguridad de sus datos en todo momento. Si elimina los registros equivocados podr recuperarlos desde
las copias de seguridad.
DELETE * FROM Empleados WHERE Cargo = Vendedor;
5.2 INSERT INTO
Agrega un registro en una tabla. Se la conoce como una consulta de datos aadidos. Esta consulta puede
ser de dos tipo: Insertar un nico registro Insertar en una tabla los registros contenidos en otra tabla.
5.2.1 Para insertar un nico Registro:
En este caso la sintaxis es la siguiente:
INSERT INTO Tabla (campo1, campo2, .., campoN)
VALUES (valor1, valor2, , valorN)
Esta consulta graba en el campo1 el valor1, en el campo2 y valor2 y as sucesivamente. Hay que prestar
especial atencin a acotar entre comillas simples () los valores literales (cadenas de caracteres) y las
fechas indicarlas en formato mm-dd-aa y entre caracteres de almohadillas (#).
5.2.2 Para insertar Registros de otra Tabla:
En este caso la sintaxis es:
INSERT INTO Tabla [IN base_externa] (campo1, campo2, , campoN)
SELECT TablaOrigen.campo1, TablaOrigen.campo2, , TablaOrigen.campoN
FROM TablaOrigen
En este caso se seleccionarn los campos 1,2, , n dela tabla origen y se grabarn en los campos 1,2,.., n
de la Tabla. La condicin SELECT puede incluir la clusula WHERE para filtrar los registros a copiar. Si
Tabla y TablaOrigen poseen la misma estrucutra podemos simplificar la sintaxis a:
INSERT INTO Tabla SELECT TablaOrigen.* FROM TablaOrigen
De esta forma los campos de TablaOrigen se grabarn en Tabla, para realizar esta operacin es necesario
que todos los campos de TablaOrigen estn contenidos con igual nombre en Tabla. Con otras palabras
que Tabla posea todos los campos de TablaOrigen (igual nombre e igual tipo).
En este tipo de consulta hay que tener especial atencin con los campos contadores o autonumricos
puesto que al insertar un valor en un campo de este tipo se escribe el valor que contenga su campo
homlogo en la tabla origen, no incrementandose como le corresponde.
Se puede utilizar la instruccin INSERT INTO para agregar un registro nico a una tabla, utilizando la
sintaxis de la consulta de adicin de registro nico tal y como se mostr anteriormente. En este caso, su
cdigo especfica el nombre y el valor de cada campo del registro. Debe especificar cada uno de los
campos del registro al que se le va a asignar un valor as como el valor para dicho campo. Cuando no se
especifica dicho campo, se inserta el valor predeterminado o Null. Los registros se agregan al final de la
tabla.
Tambin se puede utilizar INSERT INTO para agregar un conjunto de registros pertenecientes a otra tabla
o consulta utilizando la clusula SELECT FROM como se mostr anteriormente en la sintaxis de la
consulta de adicin de mltiples registros. En este caso la clusula SELECT especifica los campos que se
van a agregar en la tabla destino especificada.
La tabla destino u origen puede especificar una tabla o una consulta.
Si la tabla destino contiene una clave principal, hay que segurarse que es nica, y con valores no-Null ; si
no es as, no se agregarn los registros. Si se agregan registros a una tabla con un campo Contador , no se
debe incluir el campo Contador en la consulta. Se puede emplear la clusula IN para agregar registros a
una tabla en otra base de datos.
Se pueden averiguar los registros que se agregarn en la consulta ejecutando primero una consulta de
seleccin que utilice el mismo criterio de seleccin y ver el resultado. Una consulta de adicin copia los
registros de una o ms tablas en otra. Las tablas que contienen los registros que se van a agregar no se
vern afectadas por la consulta de adicin. En lugar de agregar registros existentes en otra tabla, se puede
especificar los valores de cada campo en un nuevo registro utilizando la clusula VALUES. Si se omite la
lista de campos, la clusula VALUES debe incluir un valor para cada campo de la tabla, de otra forma
fallar INSERT.
INSERT INTO Clientes SELECT Clientes_Viejos.* FROM Clientes_Nuevos;
INSERT INTO Empleados (Nombre, Apellido, Cargo)
VALUES (Luis, Snchez, Becario);
INSERT INTO Empleados SELECT Vendedores.* FROM Vendedores
WHERE Fecha_Contratacion < Now() 30;
5.3 UPDATE
Crea una consulta de actualizacin que cambia los valores de los campos de una tabla especificada
basndose en un criterio especfico. Su sintaxis es:
UPDATE Tabla SET Campo1=Valor1, Campo2=Valor2, CampoN=ValorN
WHERE Criterio;
UPDATE es especialmente til cuando se desea cambiar un gran nmero de registros o cuando stos se
encuentran en mltiples tablas. Puede cambiar varios campos a la vez. El ejemplo siguiente incrementa
los valores Cantidad pedidos en un 10 por ciento y los valores Transporte en un 3 por ciento para aquellos
que se hayan enviado al Reino Unido.:
UPDATE Pedidos SET Pedido = Pedidos * 1.1, Transporte = Transporte * 1.03
WHERE PaisEnvo = ES;
UPDATE no genera ningn resultado. Para saber qu registros se van a cambiar, hay que examinar
primero el resultado de una consulta de seleccin que utilice el mismo criterio y despus ejecutar la
consulta de actualizacin.
UPDATE Empleados SET Grado = 5 WHERE Grado = 2;
UPDATE Productos SET Precio = Precio * 1.1 WHERE Proveedor = 8 AND Familia = 3;
Si en una consulta de actualizacin suprimimos la clusula WHERE todos los registros de la tabla
sealada sern actualizados.
UPDATE Empleados SET Salario = Salario * 1.1
6. Tipos de Datos
Los tipos de datos SQL se clasifican en 13 tipos de datos primarios y de varios sinnimos vlidos
reconocidos por dichos tipos de datos.
Tipos de datos primarios:
Tipo de Datos Longitud Descripcin
BINARY 1 byte Para consultas sobre tabla adjunta de productos de bases de datos que definen
un tipo de datos Binario.
BIT 1 byte Valores Si/No True/False
BYTE 1 byte Un valor entero entre 0 y 255.
COUNTER 4 bytes Un nmero incrementado automticamente (de tipo Long)
CURRENCY 8 bytes Un entero escalable entre 922.337.203.685.477,5808 y
922.337.203.685.477,5807.
DATETIME 8 bytes Un valor de fecha u hora entre los aos 100 y 9999.
SINGLE 4 bytes Un valor en punto flotante de precisin simple con un rango de -3.402823*1038 a -
1.401298*10-45 para valores negativos, 1.401298*10-45 a 3.402823*1038 para valores positivos, y 0.
DOUBLE 8 bytes Un valor en punto flotante de doble precisin con un rango de -
1.79769313486232*10308 a -4.94065645841247*10-324 para valores negativos, 4.94065645841247*10-
324 a 1.79769313486232*10308 para valores positivos, y 0.
SHORT 2 bytes Un entero corto entre -32,768 y 32,767.
LONG 4 bytes Un entero largo entre -2,147,483,648 y 2,147,483,647.
LONGTEXT 1 byte por carcter De cero a un mximo de 1.2 gigabytes.
LONGBINARY Segn se necesite De cero 1 gigabyte. Utilizado para objetos OLE.
TEXT 1 byte por caracter De cero a 255 caracteres.
La siguiente tabla recoge los sinonimos de los tipos de datos definidos:
Tipo de Dato Sinnimos
BINARY VARBINARY
BIT BOOLEAN
LOGICAL
LOGICAL1
YESNO
BYTE INTEGER1
COUNTER AUTOINCREMENT
CURRENCY MONEY
DATETIME DATE
TIME
TIMESTAMP
SINGLE FLOAT4
IEEESINGLE
REAL
DOUBLE FLOAT
FLOAT8
IEEEDOUBLE
NUMBER
NUMERIC
SHORT INTEGER2
SMALLINT
LONG INT
INTEGER
INTEGER4
LONGBINARY GENERAL
OLEOBJECT
LONGTEXT LONGCHAR
MEMO
NOTE
TEXT ALPHANUMERIC
CHAR
CHARACTER
STRING
VARCHAR
VARIANT (No Admitido) VALUE
2.5.4 ORACLE
1. Que es oracle
Oracle es bsicamente una herramienta cliente/servidor para la gestin de Bases de Datos. Es un producto
vendido a nivel mundial, aunque la gran potencia que tiene y su elevado precio hace que slo se vea en
empresas muy grandes y multinacionales, por norma general. En el desarrollo de pginas web pasa lo
mismo: como es un sistema muy caro no est tan extendido como otras bases de datos, por ejemplo,
Access, MySQL, SQL Server, etc.
Vamos ahora en centrarnos en que es Oracle exactamente y como funciona la programacin sobre ste.
Oracle como antes he mencionado se basa en la tecnologa cliente/servidor, pues bien, para su utilizacin
primero sera necesario la instalacin de la herramienta servidor (Oracle 8i) y posteriormente podramos
atacar a la base de datos desde otros equipos con herramientas de desarrollo como Oracle Designer y
Oracle Developer, que son las herramientas bsicas de programacin sobre oracle.
Para desarrollar en Oracle utilizamos PL/SQL un lenguaje de 5 generacin, bastante potente para tratar y
gestionar la base de datos, tambin por norma general se suele utilizar SQL al crear un formulario.
Es posible lgicamente atacar a la base de datos a travs del SQL plus incorporado en el paquete de
programas Oracle para poder realizar consultas, utilizando el lenguaje SQL.
El Developer es una herramienta que nos permite crear formularios en local, es decir, mediante esta
herramienta nosotros podemos crear formularios, compilarlos y ejecutarlos, pero si queremos que los
otros trabajen sobre este formulario deberemos copiarlo regularmente en una carpeta compartida para
todos, de modo que, cuando quieran realizar un cambio, debern copiarlo de dicha carpeta y luego
volverlo a subir a la carpeta. Este sistema como podemos observar es bastante engorroso y poco fiable
pues es bastante normal que las versiones se pierdan y se machaquen con frecuencia. La principal ventaja
de esta herramienta es que es bastante intuitiva y dispone de un modo que nos permite componer el
formulario, tal y como lo haramos en Visual Basic o en Visual C.
Los problemas anteriores quedan totalmente resueltos con Designer que es una herramienta que se
conecta a la base de datos y por tanto creamos los formularios en ella, de esta manera todo el mundo se
conecta mediante Designer a la aplicacin que contiene todos los formularios y no hay problemas de
diferentes versiones, esto es muy til y perfecto para evitar machacar el trabajo de otros. Pero el principal
y ms notable problema es la falta de un entorno visual para disear el formulario, es decir, nos aparece
una estructura como de rbol en la cual insertamos un formulario, a la vez dentro de ste insertamos
bloques o mdulos que son las estructuras que contendrn los elementos del formularios, que pueden
estar basados en tablas o no.
Por lo tanto si queremos hacer formularios para practicar o para probar qu es esto de Oracle, es
recomendable que se utilic Developer pues es mucho ms fcil e intuitivo al principio.
2. Explorador de servidores para base de datos de oracle
Las bases de datos de Oracle presentan algunas diferencias en el Explorador de servidores. Por ejemplo,
cuando agrega una conexin a una base de datos de Oracle, ver las siguientes carpetas: Diagramas de
base de datos, Tablas, Sinnimos, Vistas, Procedimientos almacenados, Funciones, Especificaciones de
paquete y Cuerpos de paquete. En los siguientes temas se describen brevemente cada uno de los objetos
del Explorador de servidores para bases de datos de Oracle.
3. Diagramas de base de datos
La carpeta Diagramas de base de datos contiene diagramas con nombre que muestran la estructura de la
base de datos de forma grfica.
4. Tablas
La carpeta Tablas contiene las tablas base de la base de datos.
Visual Database Tools le ayuda a realizar modificaciones en la base de datos. Es posible controlar cundo
y cmo se guardarn los cambios realizados a una base de datos creada en un diagrama de base de datos.
Para ello, se deben anotar los objetos que han sido modificados y los que no han sufrido cambios en el
diagrama de base de datos, guardar nicamente los cambios realizados en las tablas seleccionadas y
descartar los cambios no deseados. Tambin puede utilizar secuencias de comandos de cambio SQL para
hacer un seguimiento de los cambios, descartarlos y aplicar cambios no guardados.
5. Sinnimos
La carpeta Sinnimos contiene nombres alternativos para las tablas, vistas, secuencias, procedimientos
almacenados, funciones, paquetes e instantneas. Puede utilizar sinnimos para tener acceso fcilmente a
los objetos de base de datos sin utilizar calificadores.
6. Para crear un nuevo sinnimo
Desde una consulta o secuencia de comandos SQL, ejecute la siguiente instruccin:
create synonym name
for table
Sustituya name por el nombre del sinnimo y table por el nombre de la tabla.
7. Para recuperar datos de un sinnimo
En el Explorador de servidores, haga clic con el botn secundario del mouse (ratn) y elija Recuperar
datos de sinnimo. Una cuadrcula muestra el propietario, nombre de columna, tipo de tabla, precisin,
etc., para las columnas accesibles de todas las tablas, vistas y clsteres.
8. Vistas
La carpeta Vistas contiene bloques con nombre de cdigo SQL que filtran los datos disponibles de las
tablas subyacentes.
9. Funciones
La carpeta Funciones contiene bloques con nombre de cdigo SQL que puede devolver valores a un
programa de llamada. Para obtener informacin adicional sobre cmo trabajar con funciones
10. Especificaciones del paquete
La carpeta Especificaciones del paquete contiene grupos con nombre de procedimientos pblicos,
funciones, excepciones, variables, constantes y cursores. Las especificaciones de paquete resultan tiles
para compartir datos y aumentar la eficiencia.
11. Para crear una nueva especificacin de paquete
En el Explorador de servidores, haga clic con el botn secundario del mouse en el nodo Especificaciones
del paquete y elija Nueva especificacin de paquete en el men contextual. En el editor se muestra una
plantilla con la sintaxis correcta de Oracle para especificaciones de paquete.
CREATE OR REPLACE PACKAGE USER.PACKAGE1 AS
/*
FUNCTION FUNCTION_NAME( PARAMETERS )
RETURN DATATYPE;
PROCEDURE PROCEDURE_NAME( PARAMETERS );
*/
END;
Para editar una especificacin de paquete
En el Explorador de servidores, haga clic con el botn secundario del mouse y elija Editar especificacin
de paquete en el men contextual. En el editor se muestra el cdigo SQL para la especificacin de
paquete.
12. Cuerpos de paquete
La carpeta Cuerpos de paquete contiene cuerpos de paquete con nombre creados a partir de
especificaciones de paquete.
13. Para crear un nuevo cuerpo de paquete
En el Explorador de servidores, haga clic con el botn secundario del mouse en el nodo Cuerpos de
paquete y elija Nuevo cuerpo del paquete en el men contextual. En el editor se muestra una plantilla con
la sintaxis correcta de Oracle para cuerpos de paquete.
CREATE OR REPLACE PACKAGE BODY USER.PACKAGE1 AS
/*
FUNCTION FUNCTION_NAME( PARAMETERS )
RETURN DATATYPE;
IS
RETURN_VARIABLE DATATYPE;
BEGIN
END;
PROCEDURE PROCEDURE_NAME( PARAMETERS );
AS
BEGIN
END;
*/
END;
14. Para editar un cuerpo de paquete
En el Explorador de servidores, haga clic con el botn secundario del mouse y elija Editar cuerpo de
paquete en el men contextual. En el editor se muestra el cdigo SQL para el cuerpo de paquete.
CAPITULO III DESARROLLO
3.1 INTRODUCCIN:
En la actualidad, la utilizacin de metodologas para el desarrollo de aplicaciones es casi imposible
omitirla, debido a la gran necesidad de control de variables que conlleva el mismo desarrollo, y para la
ordenada elaboracin de las aplicaciones, por lo tanto, seguir metodologas y estndares nos llevan a estar
en competitividad en todo momento.
Es de suma importancia conocer el modo como se interrelacionan metodologas con estndares y
herramientas siguiendo un nico propsito, el cual consiste en la elaboracin de aplicaciones de manera
eficiente, ordenada y con el menor nmero de defectos. La metodologa RUP nos proporciona disciplinas
en las cuales se encuentran artefactos con lo cual se podr contar con guas para poder documentar e
implementar de una manera fcil y eficiente, todas las guas para un buen desarrollo, todo esto dentro de
las respectivas fases con las cuales cuenta.
No es posible realizar un desarrollo de software de una manera lenta, ya que las exigencias de los clientes
actuales conllevan a verse en la necesidad de implementar soluciones rpidas y que cumplan con los
requerimientos planteados, por lo que el Desarrollo Rpido de Aplicaciones es una de las caractersticas
que ms impacto tiene en la actualidad, para solventar esto se deben utilizar herramientas basadas en este
nuevo enfoque.
Durante el desarrollo del presente capitulo se define el marco de trabajo y las tareas que se requieren para
desarrollar, construir implementar el sistema de control de pago de pensiones, con el que se pretende
cumplir con los objetivos trazados y dar solucin a la problemtica presentado en la institucin. Para la
construccin del sistema de control de pago de pensiones del CPRGB, se optado por usar la metodologa
RUP ( Proceso Racional Unificado). A continuacin se desarrolla en detalle cada una de las fases del
ciclo de vida o de desarrollo de RUP y los flujos de trabajo sobre los cuales iteran.
3.2 FASE INICIO
1. Propsito alcance y Espacio del proyecto
El propsito del presente proyecto es disear, desarrollar e implementar un sistema de informacin
computarizado para el control de pago de pensiones para la administracin del colegio CPRGB que
manipule y administre toda la informacin concerniente al cobro de pago de pensiones. Con el desarrollo
del sistema de control de pago de pensiones del CPRGB, se busca dar solucin a los problemas
presentados en la institucin de forma eficiente y eficaz, empleando informacin confiable y segura.
2. REQUERIMIENTOS DEL SISTEMA
Dentro los alcances del proyecto, el sistema de control de pago de pensiones del CPRGB permitir
cumplir los requerimientos del sistema de cobro de pensiones. Estos requerimientos se pueden diferenciar
en los siguientes subsistemas o mdulos.
Pago de Mensualidad
Registra de pago de mensualidad.
Realizar informes y reportes sobre los ingresos (pago de pensin).
Genera comprobante de pago (Emitir Factura)
3. REQUERIMIENTO TECNOLOGICO
En el requerimiento de software el lenguaje de programacin Eclipse, como motor de base de datos
MYSQL que es eficiente y segura.
La institucin CPRGB no cuenta con ningn tipo de red por lo cual se optara por un enlace de red local.
4. PLANIFICACIN INICIAL DEL PROYECTO:

Para poder cumplir con los objetivos establecidos en el proyecto y desarrollar todas las fases que
contempla la metodologa RUP, es necesario realizar una planificacin temporal respecto al tiempo de
trabajo que tomara la conclusin del sistema de control de pago de pensiones del CPRGB. La
planificacin del presente proyecto estar en base al tiempo estimado por la institucin CPRGB.
Realizar el modelo de requisitos que incluya: Identificacin de los casos de negocio Descripcin de los
casos de uso Definicin del Modelo Conceptual Diagrama de Estados
5. EL CASO DEL NEGOCIO
El caso del negocio proporciona la informacin necesaria, desde el punto de vista del sistema
a) Descripcin de sistema
El sistema de control de pago de pensiones del CPRGB, esta diseado para realizar el control y
administracin de los ingresos en la institucin por concepto cobro de pago de pensiones, dando una
solucin eficaz y eficiente. Adems el sistema se encargara de automatizar las tareas como: Paga
Mensualidad, Registra en Sistema, Emite Factura.
Paga Mensualidad: Cobro de pensiones . el padre de familia solicita pagar la pensin de su(s)
hijo(s).
Registro de pago de mensualidad. Primero el encargado verifica si tiene deudas, una vez
verificada la deuda se registra el monto recibido.
Realizar informes y reportes sobre los ingresos (pago de pensin).
Genera comprobante de pago (Emitir Factura)
b) Identificacin de Subsistemas
Los subsistemas identificados estn en relacin al alcance del proyecto. Para desarrollar el Sistema de
control de pago de pensiones del CPRGB se identificaron los siguientes subsistemas o mdulos. Es
importante sealar que existe dependencia entre los subsistemas anteriormente indicados, es por eso que
analizando los elementos compartidos entre ellos, o las interfaces entre subsistema, se logra determinar
que uno depende del otro y viceversa.

c) Descripcin de los subsistemas.- La descripcin de cada sistema es como sigue:
- Subsistema de paga mensualidad
Verificacin de Cdigo de estudiante.
Verifica deuda.
- Subsistema Registro de pago de mensualidad: Comprende:
Registro de pago
Actualizacin del registro de pago..
- Generar Informes y reportes: Comprende
Reportes de ingresos.
Actualizacin de reportes.
- Emite Factura: Comprende
Confirmacin de Cdigo de estudiante.
Generacin de recibo o factura
d) Gestin de riesgos.- El riesgo es un problema potencial que puede ocurrir o no, y que puede
afectar a los futuros acontecimientos. Por esta razn es necesario evaluar su probabilidad de aparicin,
estimar su impacto y establecer un plan de contingencia.
6. Identificacin del riesgo.- El mtodo que utilizamos para identificar los riesgos es una lista de
comprobacin de elementos de riesgo:
- Definicin del proceso.
El tamao de la base de datos a crear es grande?
Nmero de usuarios del sistema es grande?
La cantidad de software reutilizable es considerable?
- Entorno de desarrollo.
Se tiene disponible las herramientas de gestin del proyecto de software?
Existen herramientas de anlisis y diseo disponibles?
Proporcionan las herramientas de anlisis y diseo mtodos apropiados para el producto a construir?
Existen expertos disponibles para responder todas las preguntas sobre las herramientas?
- Con el Usuario.
Entiende el usuario el proceso del software?
El Usuario est dispuesto en invertir su tiempo en reuniones y revisiones del producto que requiere?
- Tecnologa a construir.
Es necesaria para la institucin la tecnologa a construir?
Es nueva la tecnologa que se va a construir?
El software interacta con hardware nuevo o no probado?
7. Proyeccin del riesgo.- Los riesgos ms altos identificados en el proyecto son los siguientes:
- Estimacin del tamao de software
- Mayor nmero de usuarios de lo previsto
- Falta de informacin sobre las herramientas
- Falta de capacitacin al usuario
8. Anlisis de costos.- En este punto se presenta una estimacin del costo que implica el desarrollo
del SCPP.
Costos directos: Son aquellos recursos utilizados en el desarrollo del sistema desde el inicio hasta su
finalizacin y entrega al usuario.
Costos indirectos: Estos solo sern de apoyo, no implicaran dentro del proyecto, ya que solo son
materiales extras que son necesarios para el desarrollo del sistema
3.2.4 MODELO DEL NEGOCIO
El modelo de negocio del proyecto est enmarcado dentro de las delimitaciones del contexto del sistema y
describe los procesos exactos relacionados con los actores y casos de uso encontrados.
a) Actores del Negocio

b) Casos de uso del negocio
Paga Mensualidad:
Registro de pago de mensualidad.
Generar reportes.
Emite Factura.
c) Modelo inicial del caso de Uso del Negocio: El siguiente diagrama muestra los casos de uso del
negocio.

3.2.5 DIAGRAMA DE CASOS DE USO:
En los diagrama de casos de uso se utiliza los diagramas de UML:

3.2.6 DETALLE DE CASO DE USO EXPANDIDO
El caso de uso expndido describe de forma detallada la informacin del colegio privado Rosemaria
Galindo de Barrientos, donde el objetivo principal se muestran en los casos de uso querealiza el personal
administrativo, que se encarga del cobro y registro de pensiones. A continuacin se detallara los casos de
uso:



Casos de uso : Paga mensualidad




3.3 . DIAGRAMA DE SECUENCIA:
El diagrama de secuencias se muestran los eventos y se realiza operaciones en el proceso del sistema,
permite que el sistema y el actor interactu.


3.4. DIAGRAMA DE COMUNICACIN:

3.5. DIAGRAMA DE CLASES DEL SISTEMA:

3.6. CONCLUSIN:

En este proyecto se ha dado una visin general de lo que es el RUP, UML, as como de la estructura
bidimensional que sigue, dividiendo el proceso en fases, y estas en flujos de trabajo. Tambin el uso de
herramientas como RATIONAL ROSE.

El anlisis y desarrollo orientado a objetos aplicando RUP que es una metodologa completa y extensa
que intenta abarcar todo el mundo del desarrollo software, tanto para pequeos proyectos, como
proyectos ms ambiciosos de varios aos de duracin.

No es fcil manejar esta metodologa, pero con toda la bibliografa que existe sobre RUP, las
herramientas disponibles para desarrollo de software Y UML esta tarea se hace mas causada.

3.7. BIBLIOGRAFA:

1. http://atenea.ucauca.edu.co/~gramirez/archivos/AnotacionesRUP.pdf Ramrez
2. Gonzlez, Gustavo A., Laboratorio III de Electrnica, Anotaciones RUP, 2001.
3. http://davidfrico.com/rup-slc.pdf Rational Unified Process Software Life Cycle .Una tabla
resumen de los flujos, trabajadores y productos.
4. http://www.public.iastate.edu/~shaf2/cs362 docs/Templates/rup_wd_tmpl.zip .Plantillas de
productos de RUP Rational White Paper, Best Practices for Software Development Teams, 1998
5. http://www.rational.com/products/rup/faq.js p FAQ sobre RUP.
6. http://www.yoopeedoo.com/upedu/, Pagina web de UPEDU (Unified Process for EDUcation).
7. http://www.yoopeedoo.com/upedu/process /artifact/tmpl_cs/ovu_tmplcs.htm Ejemplo1.
8. http://www.public.iastate.edu/~shaf2/cs36 2_main.htm Ejemplo 2.
9. Plataforma de software WebSphere http://www.w3c.org/TR/1999/REC-html401-
19991224/loose.dtd
10. Introduccin al UML http://www.yoprogramo.com/articulo4.php
11. Metodologa de desarrollo de sistemas basados en el ciclo de
vidahttp://comip.mendoza.gov.ar/metodologia%20para%20el%20desarrollo%20de%20sistemas.pdf
12. Aprendiendo UML en 24 horas. Schmuller, Joseph. Editorial Prentice Hall, Mxico, 2000.
13. Rational Rapid Developer, Technical Overview. IBM, Rational Software, 2003
14. Productos y servicios de software
WebSpherehttp://www.ibm.com/pe/products/software/websphere/
15. Tesis consultadas para anlisis estructurado

Share this:
Twitter
Facebook2

Esta entrada fue publicada en septiembre 28, 2011. Aadir a marcadores el enlace permanente.Deja un
comentario
Navegador de artculos
Hello world!
DEJA UN COMENTARIO



ENTRADAS RECIENTES
SISTEMA DE CONTROL DE PENSIONES
Hello world!
ARCHIVOS
septiembre 2011
CATEGORAS
Uncategorized
META
Registrarse
Acceder
RSS de las entradas
RSS de los comentarios
WordPress.com
Blog de WordPress.com. | El tem