SISTEMA DE CONTROL

DE PENSIONES
sep28








I NTEGRANTES:

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



SISTEMA DE CONTROL Y
ADMINISTRACIN
DE PAGO DE PENSIONES
PARA COLEGIO PARTICULAR

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 est
udio: 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 a ordenar. 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 vida
http://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 WebSphere
http://www.ibm.com/pe/products/software/websphere/
15. Tesis consultadas para anlisis estructurado