SISTEMA DE CONTROL DE PENSIONES

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

SISTEMA DE CONTROL Y ADMINISTRACIÓN

DE PAGO DE PENSIONES

PARA COLEGIO PARTICULAR

 

1. ANALISIS Y DISE;O ESTRUCTURADO

2. ORIENTADO A OBJETOS

 

 

 

 

 

 

 

 

INDICE

 

 

1.1INTRODUCCIÓN

1.2 Antescedentes

1.3 ARBOL DE PROBLEMAS

1.3.1 IDENTIFICACIÓN DEL PROBLEMA

1.3.2 PLANTEAMIENTO DEL PROBLEMA

1.4 OBJETIVOS
7 1.4.1 OBJETIVO GENERAL
8 1.4.2 OBJETIVO ESPECÍFICOL
9 1.5 ALCANCE
10 1.6 MÉTODOS DE INVESTIGACIÓN
11 1.7 JUSTIFICACIÓN
12 1.8 PLANIFICACION DE ACTIVIDADES MODELO ESENCIAL
13 a) MODELO AMBIENTAL
14 a1) DECLARACIÓN DE PROPOSITOS
15 a2) DIAGRAMA DE CONTEXTO
16 a3) LISTA DE ACONTECIMIENTOS
17 b) MODELO DE COMPORTAMIENTO
18 b1) MODELO PRELIMINAR DE COMPORTAMIENTO

INTRODUCCIÓN

En este tiempo los sistemas basados en computadora son más necesarios para las actividades de las empresas e instituciones, para administrar grandes volúmenes de información que cada día va creciendo.

El fortalecimiento de los recursos humanos en un país tiene como una de sus bases la educación. La constante evolución de la tecnología informática y el consecuente incremento de la necesidad de aplicaciones computacionales en organizaciones e instituciones, hace trascendental la necesidad de construir sistemas de información oportunos y confiables, que permitan mantener a las instituciones tecnológica y científicamente informadas para una mejora en la toma de decisiones. El Colegio Particular Rosemaria Galindo de Barrientos (CPRGB) no está al margen de la utilización de esta nueva tecnología, puesto que la adecuada administración de la información es fundamental para la toma de decisiones.

Respondiendo a ésta necesidad de contar con un sistema de información, que apoye y agilice al trabajo habitual del colegio para lograr un buen desempeño 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 información para apoyar las tareas de administración 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 incorporación de un sistema de información para apoyar a la administración 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 desafío de crear un lugar de educación para niños y jóvenes de la zona. Actualmente el sistema utilizado en el CPRGB es manual, el problema radica en el tratamiento de la información sobre la verificación de pagos al día para la entrega de notas en kardex, lo cual retrasa la información.

El Colegio Particular CPRGB como unidad educativa, no escapa a esta situación, por esto surge la necesidad de un Sistema de Control de pago de pensiones, de tal forma que se pueda tener Información 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 IDENTIFICACIÓN DEL PROBLEMA

1.3.1 IDENTIFICACIÓN DEL PROBLEMA

El CPRGB tropieza con dificultades en cuanto al manejo de información debido a la aplicación de métodos tradicionales que no dan solución a los problemas que se mencionan a continuación:

— Generación de información inadecuada e inoportuna, del movimiento económico del colegio.

— Dificultad en la elaboración de informes en los procesos de pago de pensiones.

— Carencia de información capaz de generar datos confiables y rápidos de los alumnos, ocasionando inseguridad en la toma de decisiones.

1.3.2 PLANTEAMIENTO DEL PROBLEMA

Se observa también la vulnerabilidad de la seguridad de documentos esto genera la probabilidad de cometer más errores en el momento de administrar y registrar dichos pagos. En consideración 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

Diseñar un Sistema de Control de pago de pensiones que sirva para la administración 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 información que permita mejorar y agilizar los procesos de cobro de pensiones.

1.4.2 OBJETIVO ESPECÍFICO

- Automatizar los procesos de pagos de pensiones del estudiante, generación de reportes institucionales

- Mejorar la manipulación de información y que la misma sea precisa, oportuna, coherente y de alta calidad.

- Brindar una herramienta que realice el control de ingresos (dinero) a dicha institución

1.5 ALCANCE

Los límites del presente proyecto están enmarcadas dentro de las necesidades encontradas al momento de haber realizado el estudio respectivo y llegando a la conclusión 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 MÉTODOS DE INVESTIGACIÓN

El tipo de estudio que se utilizara en la parte de análisis y diseño es una investigación Deductiva y cuantitativa, mediante visitas al colegio estadísticamente analizaremos los datos extraídos ,usando el metodo de la observación en el entorno , la cual nos ayudara a obtener información para solucionar los problemas que existen en la institución , en el colegio CPRGB , podemos utilizar un mejor estudio y asi encontrar mediante un analisis personal de cada causa una mejor solución a los problemas detectados.

Las herramientas que se usan para diseño se encuentran enmarcadas en el análisis estructurado de Edward Yourdon que ayudan en la abstracción en el análisis y diseño.

Entre las herramientas que se utilizan tenemos diagrama de contexto, DFD,diccionario de datos, que ofrecen una visión de como se comporta la información.

1.7 JUSTIFICACIÓN

El desarrollo de análisis y diseño para colegios traerá un gran beneficio a las personas involucradas directamente con el CPRGB.

El Director Administrativo (dueño) obtendrá la información 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 análisis y diseño 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 automatización del pago de pensiones y al mismo tiempo contribuye a mejorar la calidad de atención que brinda la Unida Educativa.

a1) DECLARACIÓN DE PROPOSITOS.-

El propósito del sitema de control de pago de pensiones es la de almacenar, recolectar y administrar la información. Dicha información requerida por el director administrativo (el dueño del colegio) para el control de cobro de dinero.

a2) DIAGRAMA DE CONTEXTO.- (NIVEL 0)

a3) LISTA DE ACONTECIMIENTOS.- El Director Administrativo:

- La administración solicita reporte sobre pago de pensiones.

- La administración requiere reportes de los Ingresos mensuales.

- La administración requiere información 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 atención 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 INFORMACIÓN 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 operación de cancelación de pago.

- Busca el nombre del alumno para hacer el pago de pensión correspondiente

- Se registra el monto de pago que realizo

Generar Comprobante de pago: (Apellido_Tutor, NIT, MONTO)

- Este comprante servirá para su administración del tutor del alumno.

- Se genera el comprobante una vez que se haya hecho el registro del pago correspondiente.

- Verificando ambas partes, recién se realiza la impresión 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 pensión, ya que puede ser realizado por terceras personas)

Obtener Datos del Alumno: (Nombre_Tutor, Telf._Tutor, Dirección_Tutor, Nombre_Alumno, Nivel, Curso, Dirección, Certificado_Nac)

- Acá se puede obtener el estado de pensiones del alumno.

- Este podrá ser visto mediante la secretaria.

- También 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 información general de los ingresos que hubo hasta la fecha.

- Podrá obtener la información general de las deudas que existe hasta esa fecha.

- Se podrá saber que alumno son los que deben o están al día con sus pensiones.

Verificación de proceso de pago: (Tipo_Plan, Datos_tutor, Nombre_Alumno)

- Elige la opción de pago. (esto se realiza en el momento de la inscripción)

- 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 número de hijos inscritos en el colegio.

• Puede ser que el padre o tutor hizo el pago anual.

• Es becado.

Cancelar Pensión: (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 cancelación

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 {carácter legal}

Paterno {carácter legal}

Materno {carácter legal}

Fecha_nacimiento = *fecha de nacimiento*

**

Carácter legal [A-Z/a-z]

Id_pensión = *Identificación de numero de pensión*

(digito-numérico)

Id _ curso = *Identificación de curso*

(Digito -alfanumérico)

Id_usuario = *identificación usuario*

(digito-alfanumérico)

Num_pago = [id _ pensión]

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, dirección actual}

Direccion_actual = *datos acerca de la dirección del alumno*

**

Datos usuario = *datos actuales del usuario*

{id_usuario+nombre+paterno+materno+dirección}

Login = *nombre con el que se registra*

**

Pass Word = *contraseña usuario*

**

Datos factura = *descripción de la factura*

{id_articulo+precio}

Reporte ingreso = *reporte a la administración sobre ingresos por cobro*

{Total monto}

Reporte pago = *reporte a la administración sobre pago de mensualidad*

{id_alumno+nombre+paterno+materno+curso+num_pago}

Reporte mora = *reporte a la administración 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 pensión por alumno* /*reporte por mora por curso*/]

b5) ESPECIFICACIÓN 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 condición en CONDICION con id _ condición= curalumno.id_condicion en cur condición

ENCONTRAR ultimo _ pago en PENSION con id _ alumno = id _ alumno

CREAR registro de pensión a partir de id_alumno, ultimo_pago+1, curPension.monto

AÑADIR registro de pensión 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 línea de investigaciones que se eligió se llega a las siguientes conclusiones:

• El colegio requiere de un sistema de control de pensiones para la mejor administración 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 diseño del sistema de control de pensiones teniendo en cuenta variables externas e internas del Colegio.

• Tambien se puede señalar que una correcta implantación del Sistema favorece y facilita el correcto control del cobro de pensiones por lo cual aportara resultados positivos a nivel económico en el mismo.

PROPUESTAS.

• Se ha propuesto un modelo de planificación estratégica, el cual requiere un análisis exhaustivo de la situación interna y externa del Colegio del futuro que se quiera para ella, de su misión y objetivos y del diseño de las políticas apropiadas para cumplir esta misión. Esto requiere un análisis profundo sobre cuales son y como son las necesidades del Colegio para el cobro de pensiones, teniendo en cuenta la situación actual y las previsiones del futuro de las mismas.

REFERENCIAS BIBLIOGRAFICAS.-

Bueno nosotras más fuimos investigando mediante tesis:

- SISTEMA DE INFORMACIÓN PARA EL CONTROL Y SEGUIMIENTO

DE ATENCION AL CLIENTE Autor: Rosemary Merlo Quispe

- “SISTEMA DE INFORMACIÓN VÍA WEB PARA EL CONTROL DE ALMACENES FÁBRICA 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.1INTRODUCCIÓN

1.2 ANTECEDENTES

1.3.2 PLANTEAMIENTO DEL PROBLEMA

1.3.1 IDENTIFICACIÓN DEL PROBLEMA

1.3.2 ARBOL DE PROBLEMAS

1.4 OBJETIVOS

1.4.1 OBJETIVO GENERAL

1.4.2 OBJETIVO ESPECÍFICO

1.4.3 ARBOL DE OBJETIVOS

1.5 ALCANCE

1.7 JUSTIFICACIÓN

CAPITULO II

ANTECEDENTES DE LA ORGANIZACIÓN

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 PROGRAMACIÓN

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 ELABORACIÓN

CAPITULO I

1.1 INTRODUCCIÓN

           Estamos viviendo en una sociedad de información, la tecnología informática y el consecuente incremento de la necesidad de aplicaciones computacionales en organizaciones e instituciones  dependen cada vez más de la creación y distribución de sistemas de información a través de redes locales, internet, esto con lleva al uso de de las nuevas tecnologías de información, por medio de las cuales las organizaciones consiguen grandes beneficios, como mejorar operaciones, mejor servicio, etc.

             El  fortalecimiento de los recursos humanos en un país tiene como una de sus bases la educación, lo que hace trascendental el uso de estas nuevas tecnologías lo que proporciona información oportuna y confiable, así como mejoras en su imagen y comunicación.

              El Colegio Particular Rosemaria Galindo de Barrientos (CPRGB) no está al margen del uso de esta nueva tecnología, por lo que surge la necesidad de un sistema de control de pago de pensiones, de tal manera que se pueda tener información almacenada, ya que es fundamental para la toma de decisiones.

             Respondiendo a ésta necesidad de contar con un sistema de información, 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 desempeño en las labores administrativas.

1.2.ANTECEDENTES

              El colegio CPRGB (Colegio Privado Rosamaría 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 desafío de crear un lugar de educación para niños y jóvenes de la zona.

         El colegio GPRGB es una institución de carácter privado. Es una empresa al servicio de la educación. Afiliada a la asociación de colegios particulares ANDECOP y registrada en las diferentes instancias jurídicas dependientes del estado cumple con las obligaciones de ley en actual vigencia.

              El Colegio Particular CPRGB como unidad educativa, no escapa a esta situación, por esto surge la necesidad de un Sistema de Control de pago de pensiones, de tal forma que se pueda tener Información Almacenada y gestionada de manera óptima.

Actualmente no cuenta con un proceso de almacenamiento digital, el problema radica en el tratamiento de la información sobre la verificación de pagos al día para la entrega de notas en kardex, lo cual retrasa la información.

1.3. PROBLEMÁTICA EN TRABAJOS SIMILARES

Utilizar sistemas de información para apoyar las tareas de administración 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 incorporación de un sistema de información para apoyar a la administración de control de pago de pensiones:

•             Sistema de Control disciplinario Colegio “San Calixto” realizado por Morales Juan en el año

•             Seguimiento académico Colegio Santa María “CENAFI”, realizado por Nina Peñaloza Marco en el año 2002.

•             “Sistema  de  Control  y  seguimiento  académico  para  colegios  Caso  de  estudio: Colegio ‘La Salle 8” elaborado por Rudy Oliver Saavedra Pereira. El sistema está orientado  para  que  los  padres  de         familia, directores,  profesores  y  psicólogos, puedan realizar el control y seguimiento académico 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 información, no se puede acceder a la información de una manera eficiente, ya que la recolección de la misma es manual, lo que dificulta el control.

Para evitar lo mencionado se debe implementar un sistema de control que nos brinde información confiable de forma rápida y automática, que ayude al control de ingresos (cobro de pago de pensiones).

1.4.1.     IDENTIFICACIÓN DEL PROBLEMA

El CPRGB tropieza con dificultades en cuanto al manejo de información debido a la aplicación de métodos tradicionales que no dan solución a los problemas que se mencionan a continuación:

•             Generación de información inadecuada e inoportuna, ya que el registro y cobro de pensiones son manuales, lo que provoca que el control sea deficiente.

•             Dificultad en la elaboración de informes en los procesos de pago de pensiones.

•             La información no es accesible y la falta de información no genera datos confiables y rápidos, lo que dificulta el control de ingreso de dinero, ocasionando inseguridad en la toma de decisiones.

1.4.2.     FORMULACIÓN DEL PROBLEMA

El análisis y diseño a desarrollar en forma sistemática 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 información 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 administración del colegio privado Rosemaria Galindo de Barrientos ofreciendo información confiable; para agilizar los procesos de cobro de pensiones utilizando herramientas de análisis, diseño y desarrollo de sistemas de información.

1.5.2.     OBJETIVOS ESPECIFICOS

•             Estudiar modelos de desarrollo para conocer el modo como se interrelacionan metodologías con estándares y herramientas, que tienen como propósito el diseño y elaboración 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 interacción de una intranet.

•             Proporcionar herramientas para un mejor manejo de la información, que la misma sea precisa, oportuna y  así facilitar la generación de reportes.

•             Realizar pruebas para mejorar el diseño y la elaboración del sistema.

1.5.3.     ARBOL DE OBJETIVOS

1.6. ALCANCES

Los alcances están enmarcados en la obtención 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 información sobre el cobro de pago de pensiones para emitir reportes.

1.7.        JUSTIFICACIÓN

El desarrollo de un sistema de control de pago de pensiones dedicado a tareas especificas, producto del análisis diseño y desarrollo de sistemas de información, ayudara a solucionar los problemas encontrados en la institución, 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 diseño del sistema de control que tiene la finalidad de mejorar la información sobre el cobro de pensiones de manera centralizada, se basará en el uso de la tecnología actual existente de carácter gratuito, así como las herramientas de diseño y los lenguajes de programación.

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 institución además la función del sistema es la de tener un mejor control de ingresos y mejorar las utilidades.

1.7.3.     JUSTIFICACION SOCIAL

El Diseño y desarrollo del sistema mejorara la calidad del servicio hacia los usuarios de la institución para que de esta forma se presente una imagen seria, ya que facilitara el registro, almacenamiento y control de la información al personal del área de cobro de pensiones, así facilitar la comunicación del usuario con la institución.

1.7.        CRONOGRAMA

CAPITULO II       MARCO TEORICO

2.1            ANTECENDENTES DE LA ORGANIZACION

El CPRGB (Colegio Privado Rosamaría Galindo de Barrientos), como unidad de formación académica, requiere tecnologías 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 jerárquica se encuentra el área en el cual se desarrolla el sistema de control de pago de pensiones del Colegio Privado Rosamaría Galindo de Barrientos.

La  estructura  organizativa  del  CPRGB (Colegio Privado Rosamaría Galindo de Barrientos) se  halla configurada de la siguiente manera:

Estructura Orgánica del Colegio Particular Rosemaria Galindo de Barrientos.

2.1 PARADIGMA ORIENTADO A OBJETOS:

Es una técnica o estilo de programación que utiliza objetos como bloque fundamental de Construcción.

2.1.1 Elementos básicos de la POO.

a)            Bloques: Son un conjunto complejo de datos (atributos) y funciones (métodos) que poseen una determinada Estructura y forman parte de una organización. Los atributos definen el estado del objeto; los métodos, su comportamiento.

b)           Métodos: Es un programa procedimental que está asociado a un objeto determinado y cuya ejecución solo Puede desencadenarse a través del mensaje correspondiente.

c)            Mensajes: Es simplemente una petición de un objeto a otro para que este se comporte de una manera Determinada, ejecutando uno de sus métodos. Los mensajes comunican a los objetos con otros y con el mundo exterior. A esta técnica 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 están compuestos de tres cosas Interfaz.

e)           La Interfaz es el conjunto de métodos, propiedades, eventos y atributos que se declaran como públicos en su alcance y que pueden invocar los programas escritos para usar nuestro objeto Implementación Al código dentro de los métodos se le llama Implementación. Algunas veces también se le llama comportamiento, ya que este código 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 implementación, siempre que no cambiemos la interfaz. Siempre que se mantengan sin cambio nuestro nombre de método, su lista de parámetro y el tipo de datos de devolución, podremos cambiar la implementación 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 través de las variables del Miembro o de la Instancia. Las variables del miembro son aquellas declaradas, de tal manera que están disponibles para todo el código 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 Características.

a)            Abstracción: Significa extraer las propiedades esenciales de un objeto que lo distinguen de los demás tipos de Objetos y proporciona fronteras conceptuales definidas respecto al punto de vista del observador. Es la capacidad para encapsular y aislar la información de diseño y ejecución.

b)           Encapsulamiento: Es el proceso de almacenar en un mismo compartimiento (una caja negra) los elementos de una Abstracción (toda la información relacionada con un objeto) que constituyen su estructura y su Comportamiento. Esta información permanece oculta tanto para los usuarios como para otros objetos Y puede ser accedida solo mediante la ejecución de los métodos adecuados.

c)            Herencia: Es la propiedad que permite a los objetos construirse a partir de otros objetos. La clase base contiene todas las características comunes. Las sub-clases contienen las Características de la clase base más las características particulares de la sub-clase. Si la sub-clase hereda características de una clase base, se trata de herencia simple. Si hereda de dos o más clases base, herencia múltiple.

d)           Polimorfismo: Literalmente significa “cualidad de tener más de una forma”. En poo, se refiere al hecho que una Misma operación 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 módulos independientes y robustos. Esto permite la Reutilización y facilita la verificación y depuración de los mismos. En poo, los módulos están Directamente relacionados con los objetos. Los objetos son módulos naturales ya que corresponden A una imagen lógica de la realidad.

f)            Jerarquía: La mayoría de nosotros ve de manera natural nuestro mundo como objetos que se relacionan entre s de una manera jerárquica. Por ejemplo, un perro es un mamífero, y los mamíferos son animales, y los animales seres vivos Del mismo modo, las distintas clases de un programa se organizan mediante la jerarquía. La representación de dicha organización 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 diseños y se evita la duplicación de código al no tener que volver a codificar métodos ya implementación 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 características de superclases alejadas muchos niveles. Reusabilidad del software Cuando el comportamiento se hereda de otra clase, no es necesario reescribir el código que lo define. Compartición de código. Muchos usuarios o proyectos distintos pueden usar las mismas clases. Por otro lado, la herencia reduce el tiempo de escritura y el tamaño 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 serán similares y no solo un conjunto de objetos que son parecidos pero que actúan e interactúan 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 (implementación. Beneficios: Código m genérico .Permite al programador generar componentes reutilizables de alto nivel que puedan adaptarse a diferentes aplicaciones mediante el cambio de sus partes de bajo nivel. Genérico. 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, además, estas otras propiedades.

a)            Concurrencia (multitarea): el lenguaje soporta la creación 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 más procesos son concurrentes si están 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 después de la ejecución del programa.

c)            Genericidad: las clases parametrizadas (mediante plantillas o unidades genéricas) sirven para soportar un alto grado de reutilización. Estos elementos genéricos se diseñan con parámetros formales, que se instanciaran con parámetros reales, para crear instancias de módulos 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.            Introducción

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término ágil, aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.

Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación 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 metodología de desarrollo, la cual nos provee de una dirección a seguir para la correcta aplicación de los demás elementos. Generalmente el proceso de desarrollo llevaba asociado un marcado énfasis en el control del proceso mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este esquema “tradicional” para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño (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 más adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologías tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir de las buenas prácticas de la Ingeniería del Software, asumiendo el riesgo que ello conlleva. En este contexto, las metodologías ágiles emergen como una posible respuesta para llenar ese vacío metodológico. Por estar especialmente orientadas para proyectos pequeños, las Metodologías Ágiles constituyen una solución a medida para ese entorno, aportando una elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto.

2.            Por qué usar Metodologías Ágiles

Las metodologías tradicionales presentan los siguientes problemas a la hora de abordar proyectos:

•             Existen unas costosas fases previas de especificación de requisitos, análisis y diseño. La corrección 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 más lento. Es difícil para los desarrolladores entender un sistema complejo en su globalidad.

Las metodologías ágiles de desarrollo están especialmente indicadas en proyectos con requisitos poco definidos o cambiantes. Estas metodologías se aplican bien en equipos pequeños que resuelven problemas concretos, lo que no está reñido con su aplicación en el desarrollo de grandes sistemas, ya que una correcta modularización de los mismos es fundamental para su exitosa implantación. Dividir el trabajo en módulos abordables minimiza los fallos y el coste. Las metodologías á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.            Atención continúa a la excelencia técnica y al buen diseño

6.            Mejora continua de los procesos y el equipo de desarrollo

2.2.1 RUP:

1.            Introducción al RUP

Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Rational) es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo. Su meta es asegurar la producción 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 lógicamente por la naturaleza. La primera dimensión representa el aspecto dinámico del proceso y se expresa en términos de fases, de iteraciones, y la finalización de las fases. La segunda dimensión representa el aspecto estático del proceso: cómo se describe en términos 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 varía 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 más tiempo en requerimientos, y en las últimas iteraciones pasamos más tiempo en poner en práctica la realización del proyecto en sí.

Figura 1. Disciplinas, fases, iteraciones del RUP

Se puede hacer mención de las tres características esenciales que definen al RUP:

a)            Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilización 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 implementación de las fases y disciplinas del RUP.

a.            Un Caso de Uso es una secuencia de pasos a seguir para la realización de un fin o propósito, y se relaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia de pasos que conlleva la realización e implementación 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 implementación del proyecto a realizar en Iteraciones, con lo cual se pueden definir objetivos por cumplir en cada iteración y así poder ir completando todo el proyecto iteración por iteración, con lo cual se tienen varias ventajas, entre ellas se puede mencionar la de tener pequeños avances del proyectos que son entregables al cliente el cual puede probar mientras se está desarrollando otra iteración del proyecto, con lo cual el proyecto va creciendo hasta completarlo en su totalidad. Este proceso se explica más 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 organización o estructura de sus partes más relevantes. Una arquitectura ejecutable es una implementación 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 evaluación (actividad: Revisión del ciclo de vida de la finalización de fase) para determinar si los objetivos de la fase se han cumplido. Una evaluación satisfactoria permite que el proyecto se mueva a la próxima 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 versión del producto, cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un número de iteraciones, estas fases son:

1. Concepción, Inicio o Estudio de oportunidad

-              Define el ámbito y objetivos del proyecto

-              Se define la funcionalidad y capacidades del producto

2. Elaboración

-              Tanto la funcionalidad como el dominio del problema se estudian en profundidad

-              Se define una arquitectura básica

-              Se planifica el proyecto considerando recursos disponibles

3. Construcción

-              El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación

-              Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura)

-              Gran parte del trabajo es programación y pruebas.

-              Se documenta tanto el sistema construido como el manejo del mismo.

-              Esta fase proporciona un producto construido junto con la documentación

4. Transición

-              Se libera el producto y se entrega al usuario para un uso real.

-              Se incluyen tareas de marketing, empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento, etc.

-              Los manuales de usuario se completan y refinan con la información anterior

-              Estas tareas se realizan también en iteraciones

Todas las fases no son idénticas en términos de tiempo y esfuerzo. Aunque esto varía considerablemente dependiendo del proyecto, un ciclo de desarrollo inicial típico para un proyecto de tamaño mediano debe anticipar la distribución siguiente el esfuerzo y horario:

En un ciclo evolutivo, las fases de concepción y elaboración serían considerablemente más pequeñas.

 Algunas herramientas que pueden automatizar una cierta porción del esfuerzo de la fase de Construcción pueden atenuar esto, haciendo que la fase de construcción sea mucho más pequeña que las fases de concepción y elaboración juntas. Este es precisamente el objetivo del trabajo.

Cada paso con las cuatro fases produce una generación del software. A menos que el producto “muera”, se desarrollará nuevamente repitiendo la misma secuencia las fases de concepción, elaboración, construcción y transición, pero con diversos énfasis cada fase. Estos ciclos subsecuentes se llaman los ciclos de la evolución. Mientras que el producto pasa durante varios ciclos, se producen las nuevas generaciones.

 

III.   Ciclo evolutivo en la elaboración 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 tecnología subyacente, reacción a la competición, etcétera. Los ciclos evolutivos tienen típicamente fases de concepción y elaboración mucho más cortas, puesto que la definición y la arquitectura básicas 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 redefinición arquitectónica.

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 obtención de requerimientos o requisitos en la fase de concepción se empiezan a obtener, en la fase de elaboración tiene su auge y va declinando en la fase de construcción, realizar todo esto requiere aproximadamente un 15% de esfuerzo, y así sucesivamente con las demás disciplinas. En esta sección 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 duración 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 más puntualmente una pequeña parte de la figura se puede observar que para la fase de construcción se tiene que dedicar más esfuerzo y mayor duración, siempre y cuando dependiendo de qué disciplina estemos ejecutando, por ejemplo en la disciplina de implementación se tiene mucho auge en la fase de construcción.

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 realización de un ciclo de vida de un proyecto y se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes. En este ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a menor escala, estableciendo los objetivos de una iteración en función de la evaluación de las iteraciones precedentes y las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteración. En la figura 7 se muestran los pasos a realizar para seguir el ciclo de vida iterativo incremental, hasta la realización de una fase.

Para la realización de cada iteración se tiene que tomar en cuenta la planificación de la iteración, estudiando los riesgos que conlleva su realización, también incluye el análisis de los casos de uso y escenarios, el diseño de opciones arquitectónicas, la codificación y pruebas, la integración gradual durante la construcción del nuevo código con el existente de iteraciones anteriores, la evaluación de la entrega ejecutable (evaluación del prototipo en función de las pruebas y de los criterios definidos) y la preparación de la entrega (documentación e instalación del prototipo). Algunos de estos elementos no se realizan en todas las fases. Para la realización de cada iteración se tiene que tomar en cuenta la planificación de la iteración, estudiando los riesgos que conlleva su realización, también incluye el análisis de los casos de uso y escenarios, el diseño de opciones arquitectónicas, la codificación y pruebas, la integración gradual durante la construcción del nuevo código con el existente de iteraciones anteriores, la evaluación de la entrega ejecutable (evaluación del prototipo en función de las pruebas y de los criterios definidos) y la preparación de la entrega (documentación e instalación del prototipo). Algunos de estos elementos no se realizan.

5.            Comparación 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 iteración se realiza una pequeña parte de cada disciplina en paralelo, aumentando poco a poco hasta concluir con la realización, 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 culminación de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias son las necesarias para la realización de un proyecto de software, aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, Análisis y Diseño, Implementación, Pruebas, Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las primarias y especifican otras características en la realización de un proyecto de software; entre estas se tienen: Entorno, Gestión del Proyecto, Gestión de Configuración y Cambios. A continuación se describe rápidamente cada una de estas disciplinas.

 IV.   MODELADO DEL NEGOCIO

Esta disciplina tiene como objetivos comprender la estructura y la dinámica de la organización, 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, además 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 límites del sistema, y una interfaz de usuario, realizar una estimación del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los CU, Actores y Relaciones, además utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias.

2.            Análisis y diseño Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementación, al decir análisis se refiere a transformar CU en clases, y al decir diseño se refiere a refinar el análisis para poder implementar los diagramas de clases de análisis de cada CU, los diagramas de colaboración de de cada CU, el de clases de diseño de cada CU, el de secuencia de diseño de CU, el de estados de las clases, el modelo de despliegue de la arquitectura.

3.            Implementación

Esta disciplina tiene como objetivos implementar las clases de diseño 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 Implementación, conjuntamente los Diagramas de Componentes para comprender cómo se organizan los Componentes y dependen unos de otros.

4.            Pruebas Esta disciplina tiene como objetivos verificar la integración de los componentes (prueba de integración), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribución.

5.            Despliegue Esta disciplina tiene como objetivos asegurar que el producto está preparado para el cliente, proceder a su entrega y recepción 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 enseñar al usuario.

6.            Gestión y configuración de cambios Es esencial para controlar el número 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 había arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas:

             Actualización simultánea: Es la actualización de algo elaborado con anterioridad, sin saber que alguien más lo está actualizando.

             Notificación limitada: Al realizar alguna modificación, no se deja información sobre lo que se hizo, por lo tanto no se sabe quien, como, y cuando se hizo.

             Versiones múltiples: No saber con exactitud, cual es la última versión, y al final no se tiene un orden sobre que modificaciones se han realizado a las diversas versiones.

7.            Gestión 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 Gestión del Proyecto se logra una mejoría en el manejo de una entrega exitoso de software. En resumen su propósito 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 dirección del proyecto. Por ejemplo, no cubre problemas como:

             Administración de personal: contratando, entrenando, enseñando.

             Administración del presupuesto: definiendo, asignando.

             Administración 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 propósito es proveer a la organización que desarrollará el software, un ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software.

9.            Organización 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 más claramente como se representan gráficamente cada uno de estos elementos y la interrelación 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 ejecución de varias actividades, las cuales a la vez están definidas artefactos o guas para su realización.

V.  Actores o roles

Son los personajes encargados de la realización de las actividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, estos actores se dividen en varias categorías: Analistas, Desarrolladores, Probadores, Encargados, Otros actores. A continuación se presenta una lista de actores de acorde a las categorías mencionadas con anterioridad:

1.            Analistas

a.            Analista del Proceso del Negocio.

b.            Diseñador del Negocio.

c.            Revisor del Modelo del Negocio.

d.            Revisor de Requerimientos Analista del Sistema.

e.            Especificador de Casos de Uso.

f.             Diseñador de Interfaz del Usuario

2.            Desarrolladores Arquitecto Revisor de la Arquitectura Diseñador de Cápsulas Revisor del Código y Revisor del Diseño Diseñador de la Base de Datos Diseñador Implementador y un Integrador

3.            Probadores Profesionales Diseñador de Pruebas Probador

4.            Encargados Encargado de Control del Cambio Encargado de la Configuración Encargado del Despliegue Ingeniero de Procesos Encargado de Proyecto Revisor de Proyecto

5.            Otros Cualquier trabajador Artista Gráfico Stakeholder Administrador del Sistema Escritor técnico 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 guías. 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 realización de las mismas, a continuación se definen cada una de estas categorías 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 información usada en definir las capacidades requeridas del sistema.

c)            Análisis y diseño del sistema

Los artefactos para el análisis y del diseño capturan y presenta la información relacionada con la solución a los problemas se presentaron en los requisitos fijados.

d)           Implementación

Los artefactos para la implementación capturan y presentan la realización de la solución presentada en el análisis y diseño del sistema.

e)Pruebas

 Los artefactos desarrollados como productos de las actividades de prueba y de la evaluación son agrupadas por el actor responsable, con el cual se lleva un conjunto de documentos de información sobre las pruebas realizadas y las metodologías de pruebas aplicadas.

f)            Despliegue

Los artefactos del despliegue capturan y presentan la información relacionada con la transitividad del sistema, presentada en la implementación en el ambiente de la producción.

g)            Administración del proyecto

El conjunto de artefactos de la administración del proyecto capturan los artefactos asociados con el proyecto, el planeamiento y a la ejecución del proceso.

h)           Administración de cambios y configuración

Los artefactos de la configuración y administración del cambio capturan y presentan la información relacionada con la disciplina de configuración y administración del cambio.

i)             Entorno o ambiente

 El conjunto de artefactos del ambiente presentan los artefactos que se utilizan como dirección a través del desarrollo del sistema para asegurar la consistencia de todos los artefactos producidos.

VII.  Grado de finalización 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 finalización nos referimos a cuántos 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 Concepción, en la disciplina de Implementación del Sistema los artefactos tienen una poca finalización y van aumentando progresivamente en cada fase hasta llegar a su culminación en la fase de Transición, en la disciplina de Ingeniería del Negocio los artefactos tienen una media finalización y sucede lo mismo que con los artefactos de la disciplina anterior los cuales finalizan también en la fase de Transición.

Con esto se puede mostrar el aumento progresivo de los artefactos en cada disciplina en la fase dada, teniendo una idea un poco más amplia sobre el desenvolvimiento del proyecto hablando en términos de sus artefactos.

 2.2.2.   METODOLOGÍA ÁGIL  ASD (Adaptive Software Development)

1.            Introducción

Metodología ágil desarrollada por jim highsmith, después de trabajar muchos años con metodologías predictivas concluyo que son defectuosas.

Metodologías sin muchas ataduras y reglas a seguir, es la metodología más abierta.

Las personas deben colaborar de la mejor manera, para dar respuesta y soluciones creativas.

Esta metodología se adapta al cambio en lugar de luchar con él. Se basa en la adaptación continua a circunstancias cambiantes.

En ella no hay un ciclo de planificación, diseño, construcción del software, sino un ciclo especular, colaborar, aprender.

2.            Definición

El método ágil ASD desarrollo Adaptable de Software es un modelo de implementación para desarrollo de software. Al igual que otras metodologías agiles, su funcionamiento es cíclico y reconoce que en cada iteración se producirán cambios e incluso errores.

3.            Características

Sus principales características del ASD son:

•             Iterativo,

•             Orientado a los componentes de software,

•             Tolerante a los cambios,

•             Guiados por los riesgos,

•             La revisión 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:

•             Especulación.-  Es donde se inicia y se planifican las características del Software.

•             Colaboración.- Se desarrollan las características del Software.

•             Aprendizaje.- Se revisa la calidad, y si no tiene errores se entrega al cliente.

Hay ausencia de estudios de casos del método adaptativo, aunque las referencias literarias a sus principios son abundantes. Como ASD no constituye un método de ingeniería de ciclo de vida sino una visión cultural o una epistemología, no califica como framework suficiente para articular un proyecto. Más visible es la participación de Highsmith en el respetado Cutter Consortium, del cual es director del Agile Project Management Advisory Service. Entre las empresas que han requerido consultoría 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 información acerca de cambios para mejorar el comportamiento del software,

•             Promulga colaboración, la interacción de personas,

•             Anticipa cambios y trata automáticamente 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 metodología ágil implica no realizar procesos que son requeridos en las metodologías tradicionales o por lo menos no realizados en diferentes procesos.

2.2.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD

DSDM es la única de las metodologías aquí planteadas surgida de un Consorcio, formado originalmente por 17 miembros fundadores en Enero de 1994. El objetivo del Consorcio era producir una metodología de dominio público 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 conocían en la industria y la experiencia traída por sus fundadores, liberó la primera versión de DSDM a principios de 1995. A partir de ese momento el método fue bien acogido por la industria, que empezó a utilizarlo y a capacitar a su personal en las prácticas y valores de DSDM. Debido a este éxito, el Consorcio comisionó al Presidente del Comité Técnico, Jennifer Stapleton, la creación de un libro que explorara la realidad de implementar el método.

Dado el enfoque hacia proyectos de características RAD esta metodología encuadra perfectamente en el movimiento de metodologías ágiles. La estructura del método 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 propósitos del negocio es el criterio esencial para la aceptación de los entregables.

5.            El desarrollo iterativo e incremental es necesario para converger hacia una correcta solución del negocio.

6.            Todos los cambios durante el desarrollo son reversibles.

7.            Los requerimientos están especificados a un alto nivel.

8.            El testing es integrado a través del ciclo de vida.

9.            Un enfoque colaborativo y cooperativo entre todos los interesados es esencial.

DSDM define cinco fases en la construcción de un sistema – ver (Figura Nº8). Las mismas son: estudio de factibilidad, estudio del negocio, iteración del modelo funcional, iteración del diseño y construcción, implantación. El estudio de factibilidad es una pequeña fase que propone DSDM para determinar si la metodología se ajusta al proyecto en cuestión. 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 Características de alto nivel que deberá contener el software. Posteriormente, se inician las iteraciones durante las cuales: se bajará a detalle las características identificados anteriormente, se realizará el diseño de los mismos, se construirán los componentes de software, y se implantará el sistema en producción previa aceptación del cliente.

Desde mediados de la década de 1990 hay abundantes estudios de casos, sobre todo en Gran Bretaña, y la adecuación de DSDM para desarrollo rápido está suficientemente probada. El equipo mínimo de DSDM es de dos personas y puede llegar a seis, pero puede haber varios equipos en un proyecto. El mínimo de dos personas involucra que un equipo consiste de un programador y un usuario. El máximo de seis es el valor que se encuentra en la práctica. DSDM se ha aplicado a proyectos grandes y pequeños. La precondición para su uso en sistemas grandes es su partición en componentes que pueden ser desarrollados por equipos normales.

Figura Nº8. Fases del Proceso de Desarrollo de DSDM

Se ha elaborado en particular la combinación de DSDM con XP y se ha llamado a esta mixtura EnterpriseXP, término acuñado 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 sería conveniente aprender de esa experiencia. También hay documentos conjuntos de DSDM y Rational, con participación de Jennifer Stapleton, que demuestran la compatibilidad del modelo DSDM con RUP, a despecho de sus fuertes diferencias terminológicas.

También 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 implementación.

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 demás fases presentan las características 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 cuestión 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 aplicación computacionalmente compleja?

¿Es la aplicación potencialmente grande? Si lo es, ¿puede ser particionada en componentes funcionales más pequeños?

¿Está el proyecto realmente acotado en el tiempo?

¿Son los requerimientos flexibles y sólo especificados a un alto nivel?

Las mismas refieren a las características que se deben cumplir en los proyectos para poder utilizar el enfoque RAD de construcción. Se observa que aquellos proyectos que califiquen afirmativamente de acuerdo a dichas preguntas tendrán las siguientes características 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 más pequeños si la aplicación es de gran tamaño

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 análisis sobre su aplicabilidad a un espectro bien definido de proyectos de software. Sin embargo, la metodología no tiene ninguna prescripción respecto a las técnicas a ser usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma específico – funciona tanto para el modelo de orientación a objetos como para el modelo estructurado. Algo que sí sugiere el método es la generación de un conjunto mínimo de modelos necesarios para la sana progresión de la entrega del software y facilidad en el mantenimiento. Estos modelos esenciales deberán ser definidos antes que comience el desarrollo, y deberán 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 metodologías ágiles, en las cuales también se conocen como iteración, ciclo, intervalo. La consecuencia de utilizarlos es el feedback (realimentación) frecuente que brinda visibilidad a los stakeholders(Grupos de presión) para que verifiquen el progreso y puedan tomar acciones correctivas a tiempo. También permiten controlar la calidad de los productos intermedios que se van generando, y realizar estimaciones de esfuerzo más precisas. Asimismo, cada timebox esta compuesta por actividades definidas en relación 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: Investigación, Refinamiento y Consolidación. Durante la Investigación se chequean que las actividades que componen el timebox se condicen con la arquitectura del sistema. Esta es una fase de carácter exploratorio, en la que se fijan los objetivos de la iteración, los entregables a ser producidos, efectuándose revisiones sobre las iteraciones anteriores a la actual. La siguiente fase, Refinamiento, consiste en la producción 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 Consolidación consiste en completar los entregables, verificando la calidad de los mismos. En esta fase que posee el hito de finalización del timebox se demostrará que se satisficieron los requerimientos de calidad definidos durante la Investigación.

DSDM incluye roles claves en relación al management(dirección) del proyecto. Identifica al visionario como el encargado de asegurar que se satisfacen las necesidades del negocio; el usuario embajador que equivaldría al on-site customer(Cliente) de XP, que brinda el conocimiento del negocio y define los requerimientos del software; el coordinador técnico 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 estándares técnicos.

Algunas técnicas sugeridas en DSDM son las sesiones JAD para capturar los requerimientos del software y la realización de prototipos para descifrar aquellas ambigüedades que se presentan en el relevamiento y también para derribar las barreras comunicacionales entre analistas y usuarios. El enfoque propuesto consiste en la utilización de un prototipo evolutivo, el cual se va refinando hasta tenerse la aplicación deseada. El énfasis queda en manifiesto en los prototipos que se sugieren para cada etapa: negocio, usabilidad, performance y capacidad, y diseño.

En resumen, encontramos en DSDM una metodología ágil creada en el Reino Unido a partir de un consorcio con participación de empresas de primera línea. El mismo contiene las características principales de las metodologías ágiles y contiene prácticas tendientes al enfoque RAD. Algo que es importante de DSDM ha sido su aceptación en la industria y su refinamiento continuo – actualmente, se encuentra en su versión 4.0 – lo que indica que las metodologías ágiles no son solo dominio de pequeños grupos de desarrollo sino que están siendo adoptadas por “pesos pesados” en las industrias

2.2.3 METODOLOGÍA SCRUM

Scrum define un proceso empírico, iterativo e incremental de desarrollo que intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptación de la naturaleza caótica del desarrollo de software, y la utilización de prácticas tendientes a manejar la impredictibilidad y el riesgo a niveles aceptables. El mismo surge en 1986 , de un artículo d e la Harvard Business Review titulado “The New New Product  evelopment Game” de Hirotaka Takeuchi e Ikujiro Nonaka, que introducía las mejores prácticas más utilizadas en 10 compañías 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 año 1995.

Scrum es un método iterativo e incremental que enfatiza prácticas y valores de Project management por sobre las demás 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 estarán especificados de acuerdo a las convenciones de la organización 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 definirán las iteraciones, conocidas como Sprint en la juerga de Scrum, en las que se irá evolucionando la aplicación 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 duración recomendada del Sprint es de un mes.

Dentro de cada Sprint el Scrum Master (equivalente al Líder de Proyecto) llevará a cabo la gestión de la iteración, convocando diariamente al Scrum Daily Meeting que representa una reunión de avance diaria de no más de 15 minutos con el propósito de tener realimentación sobre las tareas de los recursos y los obstáculos que se presentan. Al final de cada Sprint, se realizará un Sprint Review para evaluar los artefactos construidos y comentar el planeamiento del próximo Sprint.

Como se puede observar en la Figura Nº4 la metodología 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 tecnológicos, también 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 integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. En el desarrollo de software Scrum está considerado como modelo ágil por la Agile Alliance.

La intención de Scrum es la de maximizar la realimentación sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se está extendiendo cada vez más dentro de la comunidad de Metodologías Ágiles, siendo combinado con otras – como XP – para completar sus carencias. Cabe mencionar que Scrum no propone el uso de ninguna práctica de desarrollo en particular; sin embargo, es habitual emplearlo como un framework ágil de administración de proyectos que puede ser combinado con cualquiera de las metodologías mencionadas.

Figura Nº4. Descripción 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 propósito es establecer la visión, definir expectativas y asegurarse la financiación. Las actividades son la escritura de la visión, el presupuesto, el registro de acumulación o retraso (backlog) del producto inicial y los ítems estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro de acumulación es de alto nivel de abstracción.

2.            Pre-Juego: Montaje (Staging). El propósito es identificar más requerimientos y priorizar las tareas para la primera iteración. Las actividades son planificación, diseño exploratorio y prototipos.

3.            Juego o Desarrollo. El propósito es implementar un sistema listo para entrega en una serie de iteraciones de treinta días llamadas “corridas” (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteración, la definición del registro de acumulación de corridas y los estimados, y encuentros diarios de Scrum.

4.            Pos-Juego: Liberación. El propósito es el despliegue operacional. Las actividades, documentación, entrenamiento, mercadeo y venta.

Usualmente los registros de acumulación se llevan en planillas de cálculo comunes, antes que en una herramienta sofisticada de gestión de proyectos. Los elementos del registro pueden ser prestaciones del software, funciones, corrección de bugs, mejoras requeridas y actualizaciones de tecnología. Hay un registro total del producto y otro específico para cada corrida de 30 días. En la jerga de Scrum se llaman “paquetes” a los objetos o componentes que necesitan cambiarse en la siguiente iteración.

Figura Nº5. Ciclo de Carrera o de Vida (Sprint) de Scrum

La lista de Acumulación del Producto contiene todos los rasgos, tecnología, mejoras y lista de bugs que, a medida que se desenvuelven, constituyen las futuras entregas del producto. Los rasgos más urgentes merecerán mayor detalle, los que pueden esperar se tratarán de manera más sumaria. La lista se origina a partir de una variedad de fuentes. El grupo de mercadeo genera los rasgos y la función; la gente de ventas genera elementos que harán que el producto sea más competitivo; los de ingeniería aportarán paquetes que lo harán más robusto; el cliente ingresará debilidades o problemas que deberán resolverse. El propietario de la administración y el control del backlog en productos comerciales bien puede ser el product manager; para desarrollos in-house podría 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 opinión, deberá convencer al responsable. Se estima que priorizar adecuadamente una lista de producto puede resultar dificultosa al principio del desarrollo, pero deviene más fácil con el correr del tiempo.

Al fin de cada iteración de treinta días hay una demostración a cargo del Scrum Master. Las presentaciones en PowerPoint están prohibidas. En los encuentros diarios, las gallinas deben estar fuera del círculo. 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 métodos a los que Scrum acompañe, por ejemplo Listas de Riesgos si se utiliza UP, Planguage si el método es Evo, o los Planes de Proyecto sugeridos en la disciplina de Gestión 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-caótico, 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 diseño emanan de múltiples corridas. No hay una ingeniería del software prescripta para Scrum; cada quien puede escoger entonces las prácticas de automatización, inspección de código, prueba unitaria, análisis o programación 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 práctica de programación, usualmente orientada a objetos y con fuerte uso de patrones de diseño. Uno de los nombres que se utiliza para esta alianza es XP@Scrum. También son viables los híbridos con otras metodologías ágiles.

2.2.4.   PROGRAMACIÓN EXTREMA (EXTREME PROGRAMMING, XP)

XP  es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación 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 técnico.

Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su nombre. Kent Beck, el padre de XP, describe la filosofía de XP en [2] sin cubrir los detalles técnicos y de implantación de las prácticas. Posteriormente, otras publicaciones de experiencias se han encargado de dicha tarea. A continuación presentaremos las características esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prácticas.

1.            Las Historias de Usuario

Son la técnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinámico 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, corrección, mejora), prueba funcional, número de historia, prioridad técnica y del cliente, referencia a otra historia previa, riesgo, estimación técnica, descripción, notas y una lista de seguimiento con la fecha, estado cosas por terminar y comentarios. A efectos de planificación, las historias pueden ser de una a tres semanas de tiempo de programación (para no superar el tamaño de una iteración). Las historias de usuario son descompuestas en tareas de programación (task card) y asignadas a los programadores para ser implementadas durante una iteración.

2.            Roles XP

Los roles de acuerdo con la propuesta original de Beck son:

Programador. El programador escribe las pruebas unitarias y produce el código del sistema.

a.            Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose 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 realimentación 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 iteración.

d.            Entrenador (Coach). Es responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente.

e.            Consultor. Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas.

f.             Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.

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 implementación.

•             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 más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración.

El ciclo de vida ideal de XP consiste de seis fases [2]: Exploración, Planificación de la Entrega (Release), iteraciones, Producción, Mantenimiento y Muerte del Proyecto.

4.            Prácticas XP

La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño evolutivo funcione. Esto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollo de software y a la aplicación disciplinada de las siguientes prácticas.

El juego de la planificación. Hay una comunicación frecuente el cliente y los programadores. El equipo técnico realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración.

Entregas pequeñas . Producir rápidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versión ya constituye un resultado de valor para el negocio. Una entrega no debería tardar más 3 meses.

a.            Metáfora. El sistema es definido mediante una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. Una metáfora es una historia compartida que describe cómo debería funcionar el sistema (conjunto de nombres que actúen como vocabulario para hablar sobre el dominio del problema , ayudando a la nomenclatura de clases y métodos del sistema).

b.            Diseño simple . Se debe diseñar la solución más simple que pueda funcionar y ser implementada en un momento determinado del proyecto.

c.            Pruebas . La producción de código está dirigida por las pruebas unitarias. Éstas son son establecidas por el cliente antes de escribirse el código y son ejecutadas constantemente ante cada modificación del sistema.

d.            Refactorización (Refactoring). Es una actividad constante de reestructuración del código con el objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible para facilitar los posteriores cambios. Se mejora la estructura interna del código sin alterar su comportamiento externo [8].

e.            Programación en parejas . Toda la producción de código debe realizarse con trabajo en parejas de programadores. Esto conlleva ventajas implícitas (menor tasa de errores, mejor diseño, mayor satisfacción de los programadores, .).

f.             Propiedad colectiva del código. Cualquier programador puede cambiar cualquier parte del código en cualquier momento.

g.            Integración continua. Cada pieza de código 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 día.

h.            40 horas por semana. Se debe trabajar un máximo 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 comunicación oral es más efectiva que la escrita.

j.             Estándares de programación. XP enfatiza que la comunicación de los programadores es a través del código, con lo cual es indispensable que se sigan ciertos estándares de programación para mantener el código legible.

El mayor beneficio de las prácticas se consigue con su aplicación conjunta y equilibrada puesto que se apoyan unas en otras. Esto se ilustra en la Figura 1 (obtenida de [2]), donde una línea entre dos prácticas significa que las dos prácticas se refuerzan entre sí. La mayoría de las prácticas propuestas por XP no son novedosas sino que en alguna forma ya habían sido propuestas en ingeniería del software e incluso demostrado su valor en la práctica (ver [1] para un análisis histórico de ideas y prácticas que sirven como antecedentes a las utilizadas por las metodologías ágiles). El mérito 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 prácticas que indican que se deben dar más responsabilidades a los programadores para que estimen su trabajo, puedan entender el diseño de todo el código producido, y mantengan una metáfora mediante la cual se nombra las clases y métodos de forma consistente. La práctica 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 deserción de sus miembros. Beck afirma que como máximo se podría llegar a trabajar durante una semana con horas extras, pero si pasando ese tiempo las cosas no han mejorado entonces se deberá hacer un análisis de las estimaciones de cada iteración para que estén acordes a la capacidad de desarrollo del equipo. Si bien XP es la metodología ágil de más renombre en la actualidad, se diferencia de las demás metodologías 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. METODOLOGÍA CRYSTAL CLEAR

Alistair Cockburn es el propulsor detrás de la serie de metodologías Crystal. Las mismas presentan un enfoque ágil, con gran énfasis en la comunicación, y con cierta tolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida por XP. Crystal “Clear” es la encarnación más ágil de la serie y de la que más documentación se dispone. La misma se define con mucho énfasis en la comunicación y de forma muy liviana en relación 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 definición de los requerimientos funcionales y no funcionales del software.

Comparar el software con la ingeniería nos conduce a preguntarnos sobre “especificaciones” y “modelos” del software, sobre su completitud, corrección 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 estén al día con la versión actual del lenguaje. Intentar que así sea es una pérdida de tiempo [4]. En contra de esa visión 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 más radical, a sinergizarse con DSDM o LSD, a concebir el desarrollo de software como una forma comunitaria de poesía o a elaborar su propia familia de Metodologías Crystal.

La familia Crystal dispone un código de color para marcar la complejidad de una metodología: cuanto más oscuro un color, más “pesado” es el método. Cuanto más crítico es un sistema, más rigor se requiere. El código cromático se aplica a una forma tabular elaborada por Cockburn que se usa en muchas metodologías ágiles para situar el rango de complejidad al cual se aplica una metodología. En la (Figura Nº6) se muestra una evaluación de las pérdidas que puede ocasionar la falla de un sistema y el método requerido según este criterio. Los parámetros son Comodidad (C), Dinero Discrecional (D), Dinero Esencial (E) y Vidas (L). En otras palabras, la caída de un sistema que ocasione incomodidades indica que su nivel de criticalidad es C, mientras que si causa pérdidas de vidas su nivel es L. Los números del cuadro indican el número de personas afectadas a un proyecto.

Figura Nº6. Familia de Crystal Methods

Los métodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versión del proceso, y todas se sitúan en torno a un núcleo idéntico. Hay cuatro variantes de metodologías: 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 Marrón, Azul y Violeta. La más exhaustivamente documentada es Crystal Clear (CC), la misma que puede ser usada en proyectos pequeños de categoría D6, aunque con alguna extensión se aplica también a niveles E8 a D10. El otro método elaborado en profundidad es el Naranja, apto para proyectos de duración estimada en 2 años. Los otros dos aún se están desarrollando. Como casi todos los otros métodos, CC consiste en valores, técnicas 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 código. 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 algún usuario cortés o curioso que suministre feedback.

1.            Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un diseñador sénior; eso se llama Experto al Alcance de la Oreja. Una reunión separada para que los concurrentes se concentren mejor es descripta como El Cono del Silencio.

2.            Mejora reflexiva. Tomarse un pequeño 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 código necesita mejorarse, o que sería conveniente que se bañase más seguido. Esto es importante porque el equipo puede descubrir y reparar sus debilidades. No es provechoso encubrir los desacuerdos con gentileza y conciliación. Técnicamente, 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 comunicación sobre dirección y prioridades, típicamente con el Patrocinador Ejecutivo. Lo segundo, de un ambiente en que la gente no se vea compelida a hacer otras cosas incompatibles.

5.            Fácil acceso a usuarios expertos. Una comunicación de Keil a la ACM demostró hace tiempo, sobre una amplia muestra estadística, 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 telefónicos 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 técnico con prueba automatizada, management de configuración e integración frecuente. Microsoft estableció la idea de los builds cotidianos, y no es una mala práctica. Muchos equipos ágiles compilan e integran varias veces al día.

El proceso de Cristal Clear se basa en una exploración refinada de los inconvenientes de los modelos clásicos. Dice Cockburn que la mayoría de los modelos de proceso propuestos entre 1970 y 2000 se describían como secuencias de pasos. Aún cuando se recomendaran iteraciones e incrementos (que no hacían más que agregar confusión a la interpretación) los modelos parecían dictar un proceso en cascada, por más que los autores aseguraran que no era así. El problema con estos procesos es que realmente están 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 código no está escrito y corriendo. Y no puede diseñar y escribir el código hasta que se le dice cuáles son los requerimientos. Un grafo de dependencia se interpreta necesariamente en ese sentido, aunque no haya sido la intención original.

Figura Nº7. Ciclos anidados de Crystal Clear

En lugar de esta interpretación lineal, Cristal Clear enfatiza el proceso como un conjunto de ciclos anidados. En la mayoría de los proyectos se perciben siete ciclos:

1.            el proyecto,

2.            el ciclo de entrega de una unidad,

3.            la iteración (nótese que CC requiere múltiples entregas por proyecto pero no muchas iteraciones por entrega),

4.            la semana laboral,

5.            el período de integración, de 30 minutos a tres días,

6.            el día de trabajo,

7.            el episodio de desarrollo de una sección de código, de pocos minutos a pocas horas.

Los métodos Crystal no prescriben las prácticas de desarrollo, las herramientas o los productos que pueden usarse, pudiendo combinarse con otros métodos como Scrum, XP y Microsoft Solutions Framework.

2.3 UML:

2.3.1. Introducción al UML

UML surge como respuesta al problema de contar con un lenguaje estándar para escribir planos de software. Muchas personas han creído ver UML como solución para todos los problemas sin saber en muchos casos de lo que se trataba en realidad. El Lenguaje Unificado de Modelado, UML es una notación estándar para el modelado de sistemas software, resultado de una propuesta de estandarización promovida por el consorcio OMG (Object Management Group), del cual forman parte las empresas más importantes que se dedican al desarrollo de software, en 1996.

UML representa la unificación de las notaciones de los métodos Booch, Objectory (Ivar Jacobson) y OMT (James Rumbaugh) siendo su sucesor directo y compatible. Igualmente, UML incorpora ideas de otros metodólogos 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 especificación de la versión 1.4. Es importante recalcar que sólo se trata de una notación, 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 sistemáticos a seguir para desarrollar software. UML sólo permite documentar y especificar los elementos creados mediante un lenguaje común describiendo modelos. En la figura 12 se puede observar el desarrollo de UML y sus versiones en los años dados, sufriendo revisiones menores, y ciertos participantes en las diversas versiones.

2.3.2  Descripción del lenguaje

UML es un lenguaje de propósito 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 ingeniería 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 diseñadores de coches preparan modelos en sistemas existentes con todos los detalles y los ingenieros de software deberían igualmente construir modelos de los sistemas software. Un enfoque sistemático permite construir estos modelos de una forma consistente demostrando su utilidad en sistemas de cierto tamaño. Cuando se trata de un programa de cincuenta, cien líneas, la utilidad del modelado parece discutible pero cuando involucramos a cientos de desarrolladores trabajando y compartiendo información, el uso de modelos y el proporcionar información sobre las decisiones tomadas, es vital no sólo durante el desarrollo del proyecto, sino una vez finalizado éste, cuando se requiere algún cambio en el sistema. En realidad, incluso en el proyecto más simple los desarrolladores hacen algo de modelado, si bien informalmente. Para la construcción de modelos, hay que centrarse en los detalles relevantes mientras se ignoran los demás, 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 integración con respecto de otras técnicas tales como patrones de diseño, interfaces de usuario, documentación, etc., los ejemplos aislados, el monopolio de conceptos, técnicas y métodos en torno a UML.

2.3.4  Perspectivas de UML

También se prevé varias perspectivas de UML ya que por ser un lenguaje de propósito general será un lenguaje de modelado orientado a objetos estándar predominante los próximos años, esto se basa en las siguientes razones:

-              Participación de metodólogos influyentes

-              Participación de importantes empresas

-              Aceptación del OMG como notación estándar

También se muestran las siguientes evidencias que apoyan lo antes dicho: Herramientas que proveen la notación UML “Edición” de libros Congresos, cursos, “camisetas”, etc.

2.3.5  Descripción de los diagramas Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. Un diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices 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 interés. Es aquí donde se hace evidente la importancia de UML en el contexto de un proceso de desarrollo de software. El código fuente del sistema es el modelo más detallado del sistema (y además 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 utilización 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 continuación:

2.3.7  Diagramas, partes de un modelo

1.            Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupándola en descripciones de acciones ejecutadas por un sistema para obtener un resultado.

2.            Diagrama de Clases: muestra las clases (descripciones de objetos que comparten características comunes) que componen el sistema y cómo 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. También se pueden utilizar caminos verticales para mostrar los responsables de cada actividad.

d.            Diagramas de Interacción: Estos diagramas a su vez se dividen en 2 tipos de diagramas, según la interacción que enfatizan:

+ Diagrama de Secuencia: enfatiza la interacción entre los objetos y los mensajes que intercambian entre sí junto con el orden temporal de los mismos.

+ Diagrama de Colaboración: igualmente, muestra la interacción entre los objetos resaltando la organización estructural de los objetos en lugar del orden de los mensajes intercambiados.

4.            Diagramas de implementación

a.            Diagrama de Componentes: muestra la organización y las dependencias entre un conjunto de componentes.

b.            Diagrama de Despliegue: muestra los dispositivos que se encuentran en un sistema y su distribución en el mismo.

2.3.8  Metodología del RUP para análisis y diseño

El RUP propone la utilización de los modelos para la implementación completa de todas sus fases respectivamente con sus disciplinas:

1.            Modelo de Casos de Uso del Negocio: Describe la realización 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 organización, es realizado en la disciplina de Modelado del Negocio.

3.            Modelo de Casos de Uso: Muestra las interrelaciones entre el sistema y su ambiente, además sirve como un contrato entre el cliente y los diseñadores. Es considerado esencial al iniciar las actividades de análisis, diseño y prueba; este modelo es realizado en la disciplina de Requerimientos.

4.            Modelo de Análisis: Contiene los resultados del análisis del Caso de Uso, y contienen instancias del artefacto de Análisis de Clases; es realizado en la disciplina de Análisis y Diseño.

5.            Modelo de Diseño: Es un modelo de objetos que describe la realización del Caso de Uso, y sirve como una abstracción del modelo de implementación y su código fuente, es utilizado como entrada en las actividades de implementación y prueba; este modelo se realizado en la disciplina de Análisis y Diseño.

6.            Modelo de Despliegue: Muestra la configuración de los nodos del proceso en tiempo de ejecución, muestra los lazos de comunicación entre estos nodos, así como las de los objetos y componentes que en el se encuentran; se realizado en la disciplina de Análisis y Diseño.

7.            Modelo de Datos: Es un subconjunto del modelo de implementación que describe la representación lógica y física de datos persistentes en el sistema. También incluye cualquier conducta definida en la base de datos como disparadores, restricciones, etc. Es elaborado en la disciplina de Análisis y Diseño.

8.            Modelo de Implementación: Es una colección de componentes, y de subsistemas de aplicación que contienen estos componentes, entre estos están los entregables, ejecutables, archivos de código fuente. Es realizado en la disciplina de Implementación.

9.            Modelo de Pruebas: Es utilizado para la elaboración 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 metodología RUP utilizando las herramientas que esta provee para la implementación fácil, clara y estructurada de los diagramas utilizados.

2.3.9  Descripción de estereotipos

Para poder entender la interrelación 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 técnica; luego se procede a la obtención de los diagramas expuestos anteriormente, dependiendo de cuáles son los necesarios de implementar, luego se procede a la identificación 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 lógica del caso de uso expuesto.

Las clases, al igual que los demás elementos notacionales del UML, pueden estar clasificadas de acuerdo a varios criterios, como por ejemplo su objetivo dentro de un programa. Esta clasificación adicional se puede expresar mediante la utilización de estereotipos.

Los estereotipos más 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 análisis. Dichas pautas se centran en la búsqueda de los estereotipos entidad, control y frontera:

-              Una clase entidad modela la información 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. También 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 refinarán durante la fase de diseño, para tener en cuenta los protocolos de comunicación elegidos.

-              Una clase control modela el comportamiento secuenciado específico 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 dinámica.

El Nuevo Enfoque del UML 2.0

En las versiones previas del UML, se hacía un fuerte hincapié en que UML no era un lenguaje de programación. Un modelo creado mediante UML no podía ejecutarse. En el UML 2.0, esta asunción cambió de manera drástica y se modificó el lenguaje, de manera tal que permitiera capturar mucho más comportamiento (Behavior). De esta forma, se permitió la creación de herramientas que soporten la automatización y generación de código ejecutable, a partir de modelos UML.

Estándares que conforman el UML

•             Superestructura: Es la especificación que usamos todos los días. Aquí se encuentran todos los diagramas que la mayoría de los desarrolladores conocen.

•             Infraestructura: Conceptos de bajo nivel. Meta-Modelo da soporte a la superestructura, entre otras.

•             OCL: Lenguaje de restricción. 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.

Reestructuración del Lenguaje

Para lograr los objetivos enunciados, varios aspectos del lenguaje fueron reestructurados y/o modificados. La especificación 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 organización es modelable utilizando el propio UML 2.0; de esta manera, se da un ejemplo de utilización 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 continuación, un poco más 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 inglés 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 versión 1.1. El OCL fue originalmente especificado por IBM y es un ejemplo más de las muchas herramientas agregadas al UML.

Especificación para el Intercambio de Diagramas

La especificación 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 decía nada acerca de la manera en que el modelo debía graficarse. Para solucionar este problema, la nueva especificación para el intercambio de diagramas fue desarrollada utilizando un nuevo Schema XML, que permite construir una representación SVG (Scalable Vector Graphics). Esta especificación es denominada con las siglas XMI, que en inglés significa: XML Metadata Interchange; y en castellano se traduce como: XML de Intercambio de Metadata (datos que representan datos). Típicamente esta especificación es solamente utilizada por quienes desarrollan herramientas de modelado UML.

Infraestructura

En la Infraestructura del UML se definen los conceptos centrales y de más 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 común de los usuarios. La Infraestructura brinda también varios mecanismos de extensión, que hacen del UML un lenguaje configurable. Para los usuarios normales del UML basta con saber si la infraestructura existe y cuáles son sus objetivos.

Superestructura

La superestructura del UML es la definición formal de los elementos del UML. Esta definición sola contiene más de 640 páginas. La superestructura es típicamente utilizada por los desarrolladores de aplicación. Es aquella sobre la que hablan los libros y la que la mayoría conoce de versiones anteriores del UML.

La Superestructura del UML

Es en la Superestructura donde encontramos los cambios que más afectan en el día a día 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í dónde se definen los diagramas y los elementos que los componen. La Superestructura se encuentra dividida en niveles. Estos niveles se conocen como:

•             Básico (L1): Contiene los elementos básicos 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 especificación del UML 2.0 completa, como por ejemplo: las Acciones, Características avanzadas y PowerTypes? entre otros.

Es importante destacar que basta con que una herramienta implemente el nivel de conformidad Básico (L1), para que se considere UML 2.0 compatible. Por eso, es normal ver una disparidad de características (features) bastante amplia entre dos herramientas distintas, aunque éstas sean UML 2.0 compatibles.

Organización de la superestructura

El bloque de construcción básico del UML es un diagrama. La estructura de los diagramas UML está reflejado por el diagrama de la figura 2, de acuerdo con la especificación del UML 2.0 del Object Development Group. Los detalles sobre estos diagramas específicos se organizan de acuerdo a esta estructura taxonómica, que da la perspectiva a los diagramas y a sus interrelaciones. Los diagramas de interacción 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 representación de las clases (Entidad, Control y Frontera), ahora podemos explicar la interrelación 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 utilización que se les dio, ya que únicamente nos interesa conocer la forma de dibujar ambos diagramas para conocer sus diferencias:

2.3.11  Comparación entre diagramas de casos de uso (a) RUP (b) UML (a) (b)

Los diagramas de Clases tienen la misma lógica 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 pestaña inferior derecha doblada, y en UML solamente rectángulos con ángulos rectos; otra característica 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 más cercano a la elaboración de un modelo Entidad Relación para la puesta en práctica de la finalización 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 círculos con una diagonal en la parte inferior derecha, y en UML como rectángulos con las esquinas redondeadas, también 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 lógica 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 rectángulos 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 elaboración de diagramas de flujo, por lo tanto en ambos lenguajes se utilizan los mismos, a continuación 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 símbolos que identifican los estereotipos interfase (círculo con una raya horizontal del lado izquierdo y junto a esta otra vertical), control (círculo con una flecha sobre su borde apuntando al lado izquierdo) y entidad (círculo con una raya horizontal en la parte inferior del mismo), representados por círculos con características independientes.

Los diagramas de colaboración 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 círculos con sus características individuales de acorde a la función que desempeñan (interfaz, control, entidad), y en UML solamente como rectángulos. 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 línea que va hacia la clase. Esto se puede observar en la figura 22.

Dentro de los diagramas de implementación 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 básica 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 implementación, 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 PROGRAMACIÓN

 Un lenguaje de programación es un lenguaje que puede ser utilizado para controlar el comportamiento de una máquina, particularmente una computadora. Consiste en un conjunto de reglas sintácticas y semánticas que definen su estructura y el significado de sus elementos, respectivamente.

2.4.1.     JAVA ECLIPSE

Eclipse es un entorno de desarrollo integrado de código abierto multiplataforma para desarrollar lo que el proyecto llama “Aplicaciones de Cliente Enriquecido”, opuesto a las aplicaciones “Cliente-liviano” basadas en navegadores. Esta plataforma, típicamente ha sido usada para desarrollar entornos de desarrollo integrados (del inglés 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 también para desarrollar el mismo Eclipse). Sin embargo, también se puede usar para otros tipos de aplicaciones cliente, como BitTorrent o Azureus.

Eclipse es también una comunidad de usuarios, extendiendo constantemente las áreas de aplicación 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 Fundación Eclipse, una organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de productos complementarios, capacidades y servicios.

Eclipse fue liberado originalmente bajo la Common Public License, pero después 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 pública general de GNU (GNU GPL).[3]

1.            ARQUITECTURA

La base para Eclipse es la Plataforma de cliente enriquecido (del Inglés Rich Client Platform RCP). Los siguientes componentes constituyen la plataforma de cliente enriquecido:

Plataforma principal – inicio de Eclipse, ejecución de plugins OSGi – una plataforma para bundling estándar. 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 están implementados por una herramienta de widget para Java llamada SWT, a diferencia de la mayoría de las aplicaciones Java, que usan las opciones estándar Abstract Window Toolkit (AWT) o Swing. La interfaz de usuario de Eclipse también tiene una capa GUI intermedia llamada JFace, la cual simplifica la construcción de aplicaciones basadas en SWT.

El entorno de desarrollo integrado (IDE) de Eclipse emplea módulos (en inglés plug-in) para proporcionar toda su funcionalidad al frente de la plataforma de cliente enriquecido, a diferencia de otros entornos monolíticos donde las funcionalidades están todas incluidas, las necesite el usuario o no. Este mecanismo de módulos es una plataforma ligera para componentes de software. Adicionalmente a permitirle a Eclipse extenderse usando otros lenguajes de programación 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 gestión de base de datos. La arquitectura plugin permite escribir cualquier extensión deseada en el ambiente, como sería Gestión de la configuración. 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 programación.

La definición 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 gráficas, definición y manipulación de modelos de software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing Framework – Framework para la edición gráfica) 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 gráficas para el usuario (GUI), etc. Dado que los editores realizados con GEF “viven” dentro de Eclipse, además de poder ser usados conjuntamente con otros plugins, hacen uso de su interfaz gráfica 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 técnicas avanzadas de refactorización y análisis de código. Mediante diversos plugins estas herramientas están también 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 también hace uso de un espacio de trabajo, en este caso un grupo de metadata en un espacio para archivos plano, permitiendo

2.            CARACTERÍSTICAS

Eclipse dispone de un Editor de texto con resaltado de sintaxis. La compilación es en tiempo real. Tiene pruebas unitarias con JUnit, control de versiones con CVS, integración con Ant, asistentes (wizards) para creación de proyectos, clases, tests, etc., y refactorización.

Asimismo, a través de “plugins” libremente disponibles es posible añadir control de versiones con Subversion.[4] e integración con Hibernate.[5]

3.            HISTORIA

Eclipse comenzó como un proyecto de IBM Canadá. Fue desarrollado por OTI (Object Technology International) como reemplazo de VisualAge también desarrollado por OTI. En noviembre del 2001, se formó un consorcio para el desarrollo futuro de Eclipse como código abierto. En 2003, fue creada la fundación independiente de IBM. Resumen de las versiones de Eclipse:

4.            RADIOGRAFÍA

Los datos y cifras relacionados con Eclipse, mostrados a continuación, permitirán profundizar un poco más en el producto.

Como puede verse en la tabla siguiente, la versión 3.2.1 posee más de 2 millones de líneas de código (para el proyecto Eclipse). Estos datos son de acuerdo a SLOCCount.[6] Utilizando esta cifra y aplicando el modelo COCOMO, podemos ver que requeriría un esfuerzo para producir un software de este tamaño de 604 persona-año (para ello se ha utilizado la fórmula 2.4*(KSLOC ** 1.05)).

Para tener un estimado de los costes se toma en consideración el salario de 56.286 $/año, 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, teléfono, papelería, etc.

Un punto muy importante a notar son los diversos lenguajes de programación utilizados en el desarrollo del proyecto. De acuerdo al análisis realizado usando SLOCCount, el lenguaje más utilizado es Java, seguido de ANSI C.

2.4.2.     VISUAL BASIC

Introducción.

Visual Basic es uno de los tantos lenguajes de programación que podemos encontrar hoy en día. Dicho lenguaje nace del BASIC (Beginner´s All-purpose Symbolic Instruction Code) que fue creado en su versión original en el Dartmouth College, con el propósito de servir a aquellas personas que estaban interesadas en iniciarse en algún lenguaje de programación. Luego de sufrir varias modificaciones, en el año 1978 se estableció el BASIC estándar. 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 versión más reciente es la 6 que se incluye en el paquete Visual Studio 6 de Microsoft. Esta versión combina la sencillez del BASIC con un poderoso lenguaje de programación Visual que juntos permiten desarrollar robustos programas de 32 bits para Windows. Esta fusión de sencillez y la estética permitió ampliar mucho más el monopolio de Microsoft, ya que el lenguaje sólo es compatible con Windows, un sistema operativo de la misma empresa.

Visual Basic ya no es más “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 términos y/o características de mismo con la finalidad de aprender mas sobre este Programa y manejarlo con facilidad

Es un lenguaje de programación que se ha diseñado 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?

Diseñador de entorno de datos: Es posible generar, de manera automática, conectividad entre controles y datos mediante la acción de arrastrar y colocar sobre formularios o informes.

Los Objetos Actives son una nueva tecnología de acceso a datos mediante la acción de arrastrar y colocar sobre formularios o informes.

Asistente para formularios: Sirve para generar de manera automática 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 ejecución.

En las aplicaciones HTML: Se combinan instrucciones de Visual Basic con código 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 también acceso al Diseñador de Consultas y diseñador de Base de datos para administrar y registros.

2.            Características de Visual Basic.

 Barra de titulo: muestra el nombre del proyecto y del formulario q se está diseñando actualmente

 Barra de menús: agrupa los menús despegables que contienes todas las operaciones que pueden llevarse a cabo con Visual Basic 6.0.

 Barra de herramientas estándar: contienen los botones que se utilizan con mayor frecuencia cuando se trabaja con un proyecto. Simplifica la elección de opciones de los menús Archivo, Edición, Ver y Ejecutar; además, en el área derecha presenta la ubicación (coordenadas) y el tamaño del objeto seleccionado

 Ventana de formulario: es el área donde se diseña la interfaz gráfica, es decir, es donde se inserta electo gráficos, como botones, imágenes, casilla de verificación, cuadros de listas, etc.

 Cuadro de herramientas: presenta todos los controles necesarios para diseñar una aplicación, como cuadros de texto, etiquetas, cuadros de listas, botones de comandos, etc.

 Ventana de proyecto: muestra los elementos involucrados en el proyecto, como formularios, módulos, controles oxc, etc. Cada elemento puede seleccionarse en forma independiente para su edición.

 Ventana de posición del formulario: muestra la ubicación que tendrá el formulario en la pantalla, cuando ejecute la aplicación. Esta ubicación puede cambiarse si se hace clic con el botón 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 situación del formulario en pantalla, simplemente tendremos que marcar sobre el control de la caja de herramientas y dibujarlo con el tamaño que queramos en nuestro formulario

Label.

Este control es también uno de los más utilizados, aunque su utilidad queda restringida a la visualización de datos en el mismo, no permitiendo la introducción de datos por parte del usuario.

CommandButton

Este control es el típico botón que aparece en todas las aplicaciones y que al hacer click sobre él nos permite realizar alguna operación concreta, normalmente Aceptar o Cancelar. Aunque según el código que le asociemos podremos realizar las operaciones que queramos.

OptionButton

Este control nos permite elegir una opción entre varias de las que se nos plantean. Cada opción será un control optionbutton diferente.

Bloquear los Controles

 Cuando estén 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 botón y mientras no desbloquees los controles utilizando la misma opción no se podrán mover ninguno de los controles del formulario activo.

Sin embargo en si abres otro formulario que no tenga los controles bloqueados si se podrán mover. Si añades más controles a un formulario bloqueado estos quedan bloqueados automáticamente

Tiene la siguiente forma:

Un control Frame proporciona un agrupamiento identificable para controles. También 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 verificación, permite elegir una opción (activada / desactivada, True/False) que el usuario puede establecer o anular haciendo click. Una X en una casilla de verificación indica que está seleccionada, activada, o con valor True. Cada casilla de verificación es independiente de las demás 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 opción 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 sólo puede seleccionar una. Los controles OptionButton se agrupan dibujándolos 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 continuación, dibuje dentro los controles OptionButton. Todos los controles OptionButton que están dentro del mismo contenedor actúan 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 automáticamente. Por contraste, se puede seleccionar cualquier número 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 más. Si el número de elementos supera el número que puede mostrarse, se agregará automáticamente una barra de desplazamiento al control ListBox.

Un control ComboBox combina las características de un control TextBox y un control ListBox. Los usuarios pueden introducir información 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 combinación de un ListBox, que se comporta como si de un ListBox se tratase, y de un TextBox, con comportamiento análogo 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-analógico en una aplicación. Se toman directamente de la caja de herramientas, y tienen un aspecto parecido al de un control de volumen de un equipo de música. El HScrollBar está en posición horizontal, y el VScrollBar en posición vertical.

Mediante estos controles se pueden introducir datos variando la posición 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 diseño. En tiempo de ejecución, el control permanece invisible.

La temporización 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 gráfico que se muestra como un rectángulo, un cuadrado, una elipse, un círculo, un rectángulo redondeado o un cuadrado redondeado.

Utilice controles Shape en tiempo de diseño en lugar o además de invocar los métodos Circle y Line en tiempo de ejecución. 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 gráfico, envolver gráficamente a otros controles, pero no tiene ninguna aplicación 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 gráfico que solamente sirve para poner una línea en un formulario. Del mismo modo, no tiene procedimientos, por lo que no sirve para aportar código al programa. Solo sirve para aportar una característica gráfica, es un adorno.

CONTROL GAUGE

Este control presenta una información numérica de forma gráfica, bien como un display lineal (típico 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 numérica de una forma cuasi-analógica. Podríamos decir que es un control similar al HScrollBar, que en vez de meter información a la aplicación, la presenta.

Este control puede servir, por ejemplo, para presentar el tanto por ciento de ejecución de una tarea, como elemento tranquilizante. Puede presentar el nivel de un depósito 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 presentación, el Gauge permite poner un gráfico 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 distribución 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 instalación 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 Guía del Estudiante.

CUADRO DE DIALOGO CommonDialog

Normalmente se encuentra en la caja de herramientas

 Este control no se presenta en tiempo de diseño mas que con un simple icono:

El cuadro de diálogo, 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 diálogo permite conocer datos con los cuales, y mediante el código 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 código, abramos esos ficheros o usemos una determinada fuente.

Dependiendo de la aplicación para la que vaya a usarse se deberá activar de distintas formas. Si el cuadro de diálogo se va a usar para seleccionar la impresora y para otras aplicaciones, es recomendable usar uno exclusivamente para seleccionar la impresora.

Esta última recomendación se debe a que, para el control de la impresora, el CommonDialog SI realiza las funciones de selección 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 acción 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 acción determinada cada control responde a diferentes eventos, algunos de ellos tienen características comunes. Los eventos pueden Visualizarse en la ventana de código.

 Métodos: 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 través de ellos, un usuario interactúa con la aplicación. Sus características

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 métodos, eventos y propiedades. Hay muchas clases de objetos, y por tanto, puede llegar a haber tantos métodos, eventos y propiedades distintas como objetos diferentes.

Ejemplo : Una caja de texto (TextBox) en la cual podemos escribir cualquier línea es un objeto.

 Clases: Una clase no es nada mas que un Objeto, este objeto, tiene propiedades, funciones y métodos. Para empezar ahora la creación de propiedades si se utiliza Property Let y Property Get; la diferencia es casi nada, inclusive podría 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 opinión que voy a dar es desde mi perspectiva.

Módulo: Un proyecto Visual Basic no sólo está compuesto de Formularios, sino también de lo que se denominan módulos.

Un módulo es un fichero Visual Basic donde escribimos parte del código de nuestro programa, y digo parte, porque puede haber código en el formulario también.

 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 sería accesible desde los demás procedimientos o formularios.

Public: Las variables declaradas serán publicas y podrán estar accesibles desde todos los formularios de la aplicación. Para conseguirlo tendremos que declararlas en un módulo de código, no en la sección declarations de cualquier formulario de los que conste la aplicación. Para crear un módulo de código en el menú principal de Visual Basic marcamos en INSERT/MODULE y aparecerá junto a los demás formularios de la ventana de proyecto aunque con un icono distinto indicando que se trata de un módulo de código.

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 ejecución de la aplicación. De esta forma a entrar en algún procedimiento las variables recuerdan el valor que tenían cuando se salió de él.

TIPOS DE VARIABLES

TIPO      COMENTARIO

BOOLEAN           Sólo 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 precisión simple

DOUBLE               admite valores decimales de doble precisión

CURRENCY         válido para valores de tipo moneda

STRING                cadenas de caracteres

DATE     fechas, permite operar con ellas

  Constante: Declaración 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 expresión no puede utilizar llamadas a funciones, pues la constante se calcula en tiempo de compilación, no en tiempo de ejecución.

2.4.3.     C#

Características de C#.- Con la idea de que los programadores más experimentados puedan obtener una visión general del lenguaje, a continuación se recoge de manera resumida las principales características de C# Alguna de las características aquí señaladas no son exactamente propias del lenguaje sino de la plataforma .NET en general. Sin embargo, también se comentan aquí también en tanto que tienen repercusión directa en el lenguaje, aunque se indicará explícitamente cuáles son este tipo de características cada vez que se toquen:

•             Sencillez: C# elimina muchos elementos que otros lenguajes incluyen y que son innecesarios en .NET. Por ejemplo:

o             El código 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 tamaño de los tipos de datos básicos es fijo e independiente del compilador, sistema operativo o máquina para quienes se compile (no  como en C++), lo que facilita la portabilidad del código.

o             No se incluyen elementos poco útiles de lenguajes como C++ tales como macros, herencia múltiple 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 años ha ido demostrándose son muy útiles para el desarrollo de aplicaciones y que en otros lenguajes como Java o C++ hay que simular, como un tipo básico decimal que permita realizar operaciones de alta precisión con reales de 128 bits (muy útil en el mundo financiero), la inclusión de una instrucción foreach que permita recorrer colecciones con facilidad y es ampliable a tipos definidos por el usuario, la inclusión de un tipo básico string para representar cadenas o la distinción de un tipo bool específico para representar valores lógicos.

•             Orientación a objetos: Como todo lenguaje de programación de propósito  general  actual, C# es un lenguaje orientado a objetos, aunque eso es más bien una característica 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 más puro en tanto que no admiten ni funciones ni variables globales sino que todo el código 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 código.

            C# soporta todas las características propias del paradigma de programación   orientada a objetos: encapsulación, herencia y polimorfismo.

            En lo referente a la encapsulación es importante señalar que aparte de los típicos         modificadores public, private y protected, C# añade un cuarto modificador llamado internal, que puede combinarse con protected e indica que al elemento a cuya definición precede sólo puede accederse desde su mismo ensamblado.

            Respecto a la herencia -a diferencia de C++ y al igual que Java- C# sólo admite herencia simple de clases ya que la múltiple provoca más quebraderos de cabeza que facilidades y en la mayoría de los casos su utilidad puede ser simulada con facilidad mediante herencia múltiple de interfaces. De todos modos, esto vuelve a ser más bien una característica propia del CTS que de C#.

Por otro lado y a diferencia de Java, en C# se ha optado por hacer     que todos los métodos 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. Además, un efecto secundario            de esto es que las llamadas a los métodos serán más eficientes por defecto al no tenerse que buscar en la tabla de funciones virtuales la implementación de los mismos a la que se ha de llamar. Otro efecto secundario es que permite que las llamadas a los métodos virtuales se puedan hacer más eficientemente al contribuir a que el tamaño de dicha tabla se reduzca.

•             Orientación a componentes: La propia sintaxis de C# incluye elementos propios del diseño de componentes que otros lenguajes tienen que simular mediante construcciones más o menos complejas. Es decir, la sintaxis de C# permite definir cómodamente propiedades (similares a campos de acceso controlado), eventos (asociación controlada de funciones de respuesta a notificaciones) o atributos (información sobre un tipo o sus miembros)

•             Gestión automática de memoria: Como ya se comentó, todo lenguaje de .NET tiene a su disposición el recolector de basura del CLR. Esto tiene el efecto en el lenguaje de que no es necesario incluir instrucciones de destrucción de objetos. Sin embargo, dado que la destrucción de los objetos a través del recolector de basura es indeterminista y sólo se realiza cuando éste se active –ya sea por falta de memoria, finalización de la aplicación o solicitud explícita en el fuente-, C# también proporciona un mecanismo de liberación de recursos determinista a través de la instrucción 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 difíciles de detectar por acceso a memoria no perteneciente a ningún objeto y es especialmente necesario en un entorno gestionado por un recolector de basura. Para ello se toman medidas del tipo:

o             Sólo se admiten conversiones entre tipos compatibles. Esto es, entre un tipo y antecesores suyos, entre tipos para los que explícitamente se haya definido un operador de conversión, y entre un tipo y un tipo hijo suyo del que un objeto del primero almacenase una referencia del segundo (downcasting) Obviamente, lo último sólo puede comprobarlo en tiempo de ejecución el CLR y no el compilador, por lo que en realidad el CLR y el compilador colaboran para asegurar la corrección 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 análisis del flujo de control del fuente que no se lea ninguna variable local sin que se le haya asignado previamente algún 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 producción de desbordamientos en operaciones aritméticas, informándose de ello con una excepción cuando ocurra. Sin embargo, para conseguirse un mayor rendimiento en la aritmética estas comprobaciones no se hacen por defecto al operar con variables sino sólo con constantes (se pueden detectar en tiempo de compilación)

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 métodos simultáneamente, y se comprueba que los métodos a los que apunten tengan parámetros y valor de retorno del tipo indicado al definirlos.

o             Pueden definirse métodos que admitan un número indefinido de parámetros 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 más comunes. Por ejemplo, la guarda de toda condición ha de ser una expresión condicional y no aritmética, con lo que se evitan errores por confusión del operador de igualdad (==) con el de asignación (=); y todo caso de un switch ha de terminar en un break o goto que indique cuál es la siguiente acción a realizar, lo que evita la ejecución accidental de casos y facilita su reordenación.

•             Sistema de tipos unificado: A diferencia de C++, en C# todos los tipos de datos que se definan siempre derivarán, aunque sea de manera implícita, de una clase base común llamada System.Object, por lo que dispondrán de todos los miembros definidos en ésta clase (es decir, serán “objetos”)

            A diferencia de Java, en C# esto también es aplicable a los tipos de datos básicos      Además, para conseguir que ello no tenga una repercusión negativa en su nivel de rendimiento, se ha incluido un mecanismo transparente de boxing y unboxing con el que se consigue que sólo sean tratados como objetos cuando la situación lo requiera, y  mientras tanto puede aplicárseles optimizaciones específicas.

            El hecho de que todos los tipos del lenguaje deriven de una clase común facilita enormemente el diseño de colecciones genéricas que puedan almacenar objetos de cualquier tipo.

•             Extensibilidad de tipos básicos: C# permite definir, a través de estructuras, tipos de datos para los que se apliquen las mismas optimizaciones que para los tipos de datos básicos. Es decir, que se puedan almacenar directamente en pila (luego su creación, destrucción y acceso serán más rápidos) y se asignen por valor y no por referencia. Para conseguir que lo último no tenga efectos negativos al pasar estructuras como parámetros de métodos, se da la posibilidad de pasar referencias a pila a través del modificador de parámetro ref.

•             Extensibilidad de operadores: Para facilitar la legibilidad del código y conseguir que los nuevos tipos de datos básicos que se definan a través de las estructuras estén al mismo nivel que los básicos predefinidos en el lenguaje, al igual que C++ y a diferencia de Java, C# permite redefinir el significado de la mayoría de los operadores -incluidos los de conversión, tanto para conversiones implícitas como explícitas- 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 definición de los operadores ++ y — el compilador puede deducir automáticamente como ejecutarlos de manera prefijas y postifja; y definiendo operadores simples (como +), el compilador deduce cómo aplicar su  versión de asignación compuesta (+=) Además, para asegurar la consistencia, el compilador vigila que los operadores con opuesto siempre se redefinan por parejas (por ejemplo, si se redefine ==, también hay que redefinir !=)

            También se da la posibilidad, a través 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 actúen como colecciones de objetos.

•        Extensibilidad de modificadores: C# ofrece, a través del concepto de atributos, la posibilidad de añadir a los metadatos del módulo resultante de la compilación de cualquier fuente información adicional a la generada por el  compilador  que luego podrá ser consultada en tiempo ejecución a través de la librería de reflexión de .NET . Esto, que más bien es una característica propia de la plataforma .NET y no de C#, puede usarse como un mecanismo para definir nuevos modificadores.

•             Versionable: C# incluye una política de versionado que permite crear nuevas versiones de tipos sin temor a que la introducción de nuevos miembros provoquen errores difíciles de detectar en tipos hijos previamente desarrollados y ya extendidos con miembros de igual nombre a los recién introducidos.

            Si una clase introduce un nuevo método cuyas redefiniciones deban seguir la regla de llamar a la versión de su padre en algún punto de su código, difícilmente seguirían esta regla miembros de su misma signatura definidos en clases hijas previamente a la definición del mismo en la clase padre;  o si introduce un nuevo campo con el mismo nombre que algún método 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  redefinición deba incluir el modificador override, con lo que la versión de la clase hija nunca sería considerada como una redefinición de la versión de miembro en la clase padre ya que no incluiría override. Para evitar que por accidente un programador incluya este modificador, sólo se permite incluirlo en miembros que tengan la misma  signatura que miembros marcados como redefinibles mediante el modificador virtual. Así además 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 compilación.

o             Si no se considera redefinición, entonces se considera que lo que se desea es ocultar el método de la clase padre, de modo que para la clase hija sea como si nunca hubiese existido. El compilador avisará de esta decisión a través de un mensaje de aviso que puede suprimirse  incluyendo el modificador new en la definición del miembro en la clase hija para así indicarle explícitamente la intención de ocultación.

•             Eficiente: En principio, en C# todo el código 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 través de punteros. Para ello basta marcar regiones de código como inseguras (modificador unsafe) y podrán usarse en ellas punteros de forma similar a cómo 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 migración de programadores, C# no sólo mantiene una sintaxis muy similar a C, C++  o Java que permite incluir directamente en código escrito en C# fragmentos de código escrito en estos lenguajes, sino que el CLR también ofrece, a través de los llamados Platform Invocation Services (PInvoke), la posibilidad de acceder a código nativo escrito como funciones sueltas no orientadas a  objetos tales como las DLLs de la API Win32. Nótese que la capacidad de usar punteros en código inseguro permite que se  pueda acceder con facilidad a este tipo de funciones, ya que éstas muchas veces esperan recibir o devuelven punteros.

            También es posible acceder desde código 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 automáticamente 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, también se da la posibilidad de usar controles ActiveX desde código .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 definición de datos de un lenguaje de manipulación de datos y de un lenguaje de consulta.

2.5.1.     MYSQL

1.            ¿Qué es MySQL?

Es un sistema de gestión de bases de datos relacional, fue creada por la empresa sueca MySQL AB, la cual tiene el copyright del código fuente del servidor SQL, así como también de la marca.

MySQL es un software de código abierto, licenciado bajo la GPL de la GNU, aunque MySQL AB distribuye una versión comercial, en lo único que se diferencia de la versión libre, es en el soporte técnico que se ofrece, y la posibilidad de integrar este gestor en un software propietario, ya que de otra manera, se vulneraría la licencia GPL.

El lenguaje de programación 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 gestión de bases de datos relacional, multihilo y multiusuario con más 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 aplicación web está muy ligada a PHP, que a menudo aparece en combinación con MySQL. MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificación. En aplicaciones web hay baja concurrencia en la modificación 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 programación. 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 específica 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 pública y los derechos de autor del código están en poder del autor individual, MySQL es patrocinado por una empresa privada, que posee el copyright de la mayor parte del código. Esto es lo que posibilita el esquema de licenciamiento anteriormente mencionado. Además de la venta de licencias privativas, la compañía ofrece soporte y servicios

2.            Historia de MySQL

MySQL surgió alrededor de la década 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 conclusión de que mSQL no era lo bastante flexible ni rápido 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 librerías han llevado el prefijo “my” durante los diez últimos años, 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 vía 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 pñblica, y el copyright del código está en poder del autor individual, MySQL está poseIdo y patrocinado por una empresa privada, que posee el copyright de la mayor parte del código. MySQL AB fue fundado por David Axmark, Allan Larsson, y Michael Widenius.

3.            Características principales

Inicialmente, MySQL carecía 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 páginas web con contenido dinámico, debido a su simplicidad, de tal manera que los elementos faltantes fueron complementados por la vía de las aplicaciones que la utilizan. Poco a poco estos elementos faltantes, están siendo incorporados tanto por desarrolladores internos, como por desarrolladores de software libre. En las últimas versiones se pueden destacar las siguientes características 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 implementación multihilo.

•             Flexible sistema de contraseñas (passwords) y gestión 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 elaboración de bases de datos, ya que debido a su bajo consumo puede ser ejecutado en una máquina con escasos recursos sin ningún problema.

•             Facilidad de configuración e instalación.

•             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 están documentadas.

•             No es intuitivo, como otros programas (ACCESS).

6.            PANORÁMICA 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 administración.

o             mysqlcheck ejecuta operaciones de mantenimiento de tablas.

o             mysqldump y mysqlhotcopy son utilidades para copia de respaldo.

o             mysqlimport realiza importación de ficheros de datos.

o             mysqlshow muestra información 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 sólo lectura.

o             mysqlbinlog es una herramienta para procesar archivos de registro binario (binary logs).

o             perror informa el significado de un código de error.

La mayoría de las distribuciones de MySQL incluyen todos los programas mencionados, con excepción de los que son específicos de cada plataforma. (Por ejemplo, los scripts de inicio de servidor no son necesarios en Windows). Otra excepción es que las distribuciones RPM son más especializadas. Existe una RPM para el servidor, otra para los programas cliente, etc.

2.5.2   SQL SERVER

1. Introducción 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 método OpenRecordSet y como la propiedad RecordSource del control de datos. También se puede utilizar con el método Execute para crear y manipular directamente las bases de datos Jet y crear consultas SQL de paso a través para manipular bases de datos remotas cliente – servidor.

1.1. Componentes del SQL

El lenguaje SQL está compuesto por comandos, cláusulas, 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            Descripción

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 definición de los campos.

Comandos DML

Comando            Descripción

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 operación.

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 Cláusulas

Las cláusulas son condiciones de modificación utilizadas para definir los datos que desea seleccionar o manipular.

Cláusula               Descripción

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 específicos

HAVING              Utilizada para expresar la condición que debe satisfacer cada grupo

ORDER BY           Utilizada para ordenar los registros seleccionados de acuerdo con un orden específico

1.4 Operadores Lógicos

Operador            Uso

AND      Es el “y” lógico. Evalua dos condiciones y devuelve un valor de verdad sólo si ambas son ciertas.

OR          Es el “o” lógico. Evalúa dos condiciones y devuelve un valor de verdar si alguna de las dos es cierta.

NOT       Negación lógica. Devuelve el valor contrario de la expresión.

1.5 Operadores de Comparación

Operador            Uso

                Mayor que

                Distinto de

=             Mayor ó Igual que

=             Igual que

BETWEEN            Utilizado para especificar un intervalo de valores.

LIKE       Utilizado en la comparación 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 cláusula SELECT en grupos de registros para devolver un único valor que se aplica a un grupo de registros.

Función               Descripción

AVG      Utilizada para calcular el promedio de los valores de un campo determinado

COUNT Utilizada para devolver el número de registros de la selección

SUM      Utilizada para devolver la suma de todos los valores de un campo determinado

MAX      Utilizada para devolver el valor más alto de un campo especificado

MIN       Utilizada para devolver el valor más bajo de un campo especificado

Consultas de Selección

Las consultas de selección se utilizan para indicar al motor de datos que devuelva información de las bases de datos, esta información 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 básicas

La sintaxis básica de una consulta de selección 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 teléfono 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 claúsula 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 claúsula (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 claúsula y el primer nombre del campo a recuperar, los posibles predicados son:

Predicado           Descripción

ALL         Devuelve todos los campos de la tabla

TOP       Devuelve un determinado número 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 sólo 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 instrucción 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 más rápido indicar el listado de campos deseados.

    SELECT ALL FROM Empleados;

    SELECT * FROM Empleados;

TOP

Devuelve un cierto número de registros que entran entre al principio o al final de un rango especificado por una cláusula 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 cláusula 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 número 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 cláusula 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 continuación de TOP debe ser un Integer sin signo.TOP no afecta a la posible actualización 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 instrucción 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 López en el campo Apellido, la siguiente instrucción SQL devuelve un único registro:

    SELECT DISTINCT Apellido FROM Empleados;

Con otras palabras el predicado DISTINCT devuelve aquellos registros cuyos campos indicados en la cláusula 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 sólo 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 cláusula SELECT.

      SELECT DISTINCTROW Apellido FROM Empleados;

Si la tabla empleados contiene dos registros: Antonio López y Marta López el ejemplo del predicado DISTINCT devuleve un único registro con el valor López en el campo Apellido ya que busca no duplicados en dicho campo. Este último ejemplo devuelve dos registros con el valor López 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 procederíamos de la siguiente forma:

    SELECT DISTINCTROW Apellido AS Empleado FROM Empleados;

2.5 Recuperar Información de una base de Datos Externa

Para concluir este capítulo se debe hacer referencia a la recuperación de registros de bases de datos externa. Es ocasiones es necesario la recuperación de información 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 situación 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 Selección

Antes de comenzar el desarrollo de este capítulo hay que recalcar tres detalles de vital importancia. El primero de ellos es que cada vez que se desee establecer una condición referida a un campo de texto la condición de búsqueda debe ir encerrada entre comillas simples; la segunda es que no se posible establecer condiciones de búsqueda 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 día y aa el año, hay que prestar atención a los separadores -no sirve la separación habitual de la barra (/), hay que utilizar el guión (-) y además la fecha debe ir encerrada entre almohadillas (#). Por ejemplo si deseamos referirnos al día 3 de Septiembre de 1995 deberemos hacerlo de la siguiente forma; #09-03-95# ó #9-3-95#.

3.1 Operadores Lógicos

Los operadores lógicos soportados por SQL son: AND, OR, XOR, Eqv, Imp, Is y Not. A excepción de los dos últimos todos poseen la siguiente sintaxis:

        operador    

En donde expresión1 y expresión2 son las condiciones a evaluar, el resultado de la operación varía en función del operador lógico. 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 operación 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 aritmética 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 numéricos para los que se desea calcular la media o una expresión que realiza un cálculo utilizando los datos de dicho campo. La media calculada por Avg es la media aritmética (la suma de los valores dividido por el número de valores). La función Avg no incluye ningún campo Null en el cálculo.

    SELECT Avg(Gastos) AS Promedio FROM Pedidos WHERE Gastos > 100;

4.3    Count

Calcula el número 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 función (la cual puede ser intrínseca 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 cálculo sobre un campo, Count simplemente cuenta el número de registros sin tener en cuenta qué valores se almacenan en los registros. La función Count no cuenta los registros que tienen campos null a menos que expr sea el carácter comodín asterisco (*). Si utiliza un asterisco, Count calcula el número total de registros, incluyendo aquellos que contienen campos null. Count(*) es considerablemente más rápida que Count(Campo). No se debe poner el asterisco entre dobles comillas (‘*’).

    SELECT Count(*) AS Total  FROM Pedidos;

Si expr identifica a múltiples campos, la función Count cuenta un registro sólo 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(FechaEnvío & Transporte) AS Total FROM Pedidos;

4.4    Max, Min

Devuelven el mínimo o el máximo 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 cálculo. Expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL).

    SELECT Min(Gastos) AS ElMin FROM Pedidos WHERE Pais = ‘España';

    SELECT Max(Gastos) AS ElMax FROM Pedidos WHERE Pais  = ‘España';

4.5    StDev, StDevP

Devuelve estimaciones de la desviación estándar para la población (el total de los registros de la tabla) o una muestra de la población 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 expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL)

StDevP evalúa una población, y StDev evalúa una muestra de la población. Si la consulta contiene menos de dos registros (o ningún registro para StDevP), estas funciones devuelven un valor Null (el cual indica que la desviación estándar no puede calcularse).

    SELECT StDev(Gastos) AS Desviacion FROM Pedidos WHERE Pais = ‘España';

    SELECT StDevP(Gastos) AS Desviacion FROM Pedidos WHERE Pais= ‘España';

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 expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca 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 estimación de la varianza de una población (sobre el total de los registros) o una muestra de la población (muestra aleatoria de registros) sobre los valores de un campo. Su sintaxis es:

    Var(expr)

    VarP(expr)

VarP evalúa una población, y Var evalúa una muestra de la población. Expr el nombre del campo que contiene los datos que desean evaluarse o una expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca 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 expresión de consulta o en una Instrucción SQL.

    SELECT Var(Gastos) AS Varianza FROM Pedidos WHERE Pais = ‘España';

    SELECT VarP(Gastos) AS Varianza FROM Pedidos WHERE Pais = ‘España';

5. Consultas de Acción

Las consultas de acción son aquellas que no devuelven ningún registro, son las encargadas de acciones como añadir y borrar y modificar registros.

5.1    DELETE

Crea una consulta de eliminación que elimina los registros de una o más de las tablas listadas en la cláusula FROM que satisfagan la cláusula WHERE. Esta consulta elimina los registros completos, no es posible eliminar el contenido de algún campo en concreto. Su sintaxis es:

    DELETE Tabla.* FROM Tabla WHERE criterio

DELETE es especialmente útil cuando se desea eliminar varios registros. En una instrucción DELETE con múltiples tablas, debe incluir el nombre de tabla (Tabla.*). Si especifica más 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 más eficiente que ejecutar una consulta de borrado.

Se puede utilizar DELETE para eliminar registros de una única tabla o desde varios lados de una relación uno a muchos. Las operaciones de eliminación en cascada en una consulta únicamente eliminan desde varios lados de una relación. Por ejemplo, en la relación 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 específicos. Si desea eliminar valores en un campo especificado, crear una consulta de actualización que cambie los valores a Null.

Una vez que se han eliminado los registros utilizando una consulta de borrado, no puede deshacer la operación. Si desea saber qué registros se eliminarán, primero examine los resultados de una consulta de selección que utilice el mismo criterio y después 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 añadidos. 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 atención 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 seleccionarán los campos 1,2, …, n dela tabla origen y se grabarán en los campos 1,2,.., n de la Tabla. La condición SELECT puede incluir la cláusula 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 grabarán en Tabla, para realizar esta operación es necesario que todos los campos de TablaOrigen estén 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 atención con los campos contadores o autonuméricos puesto que al insertar un valor en un campo de este tipo se escribe el valor que contenga su campo homólogo en la tabla origen, no incrementandose como le corresponde.

Se puede utilizar la instrucción INSERT INTO para agregar un registro único a una tabla, utilizando la sintaxis de la consulta de adición de registro único tal y como se mostró anteriormente. En este caso, su código específica 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.

También se puede utilizar INSERT INTO para agregar un conjunto de registros pertenecientes a otra tabla o consulta utilizando la cláusula SELECT … FROM como se mostró anteriormente en la sintaxis de la consulta de adición de múltiples registros. En este caso la cláusula 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 agregarán 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 cláusula IN para agregar registros a una tabla en otra base de datos.

Se pueden averiguar los registros que se agregarán en la consulta ejecutando primero una consulta de selección que utilice el mismo criterio de selección y ver el resultado. Una consulta de adición copia los registros de una o más tablas en otra. Las tablas que contienen los registros que se van a agregar no se verán afectadas por la consulta de adición. En lugar de agregar registros existentes en otra tabla, se puede especificar los valores de cada campo en un nuevo registro utilizando la cláusula VALUES. Si se omite la lista de campos, la cláusula 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’, ‘Sánchez’, ‘Becario’);

    INSERT INTO Empleados SELECT Vendedores.* FROM Vendedores

    WHERE Fecha_Contratacion < Now() – 30;

5.3    UPDATE

Crea una consulta de actualización que cambia los valores de los campos de una tabla especificada basándose en un criterio específico. Su sintaxis es:

    UPDATE Tabla SET Campo1=Valor1, Campo2=Valor2, … CampoN=ValorN

    WHERE Criterio;

UPDATE es especialmente útil cuando se desea cambiar un gran número de registros o cuando éstos se encuentran en múltiples 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 PaisEnvío = ‘ES';

UPDATE no genera ningún resultado. Para saber qué registros se van a cambiar, hay que examinar primero el resultado de una consulta de selección que utilice el mismo criterio y después ejecutar la consulta de actualización.

    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 actualización suprimimos la cláusula WHERE todos los registros de la tabla señalada serán 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 sinónimos válidos reconocidos por dichos tipos de datos.

Tipos de datos primarios:

Tipo de Datos    Longitud              Descripción

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 número incrementado automáticamente (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 años 100 y 9999.

SINGLE 4 bytes Un valor en punto flotante de precisión 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 precisión 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 carácter         De cero a un máximo de 1.2 gigabytes.

LONGBINARY    Según 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      Sinónimos

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 básicamente una herramienta cliente/servidor para la gestión de Bases de Datos. Es un producto vendido a nivel mundial, aunque la gran potencia que tiene y su elevado precio hace que sólo se vea en empresas muy grandes y multinacionales, por norma general. En el desarrollo de páginas 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 programación sobre éste. Oracle como antes he mencionado se basa en la tecnología cliente/servidor, pues bien, para su utilización primero sería necesario la instalación de la herramienta servidor (Oracle 8i) y posteriormente podríamos atacar a la base de datos desde otros equipos con herramientas de desarrollo como Oracle Designer y Oracle Developer, que son las herramientas básicas de programación sobre oracle.

Para desarrollar en Oracle utilizamos PL/SQL un lenguaje de 5ª generación, bastante potente para tratar y gestionar la base de datos, también por norma general se suele utilizar SQL al crear un formulario.

Es posible lógicamente atacar a la base de datos a través 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, deberán 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 haríamos 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 aplicación 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 más notable problema es la falta de un entorno visual para diseñar 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 módulos que son las estructuras que contendrán 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 más fácil 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 conexión a una base de datos de Oracle, verá las siguientes carpetas: Diagramas de base de datos, Tablas, Sinónimos, 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 gráfica.

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 cuándo y cómo se guardarán 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. También puede utilizar secuencias de comandos de cambio SQL para hacer un seguimiento de los cambios, descartarlos y aplicar cambios no guardados.

5.            Sinónimos

La carpeta Sinónimos contiene nombres alternativos para las tablas, vistas, secuencias, procedimientos almacenados, funciones, paquetes e instantáneas. Puede utilizar sinónimos para tener acceso fácilmente a los objetos de base de datos sin utilizar calificadores.

6.            Para crear un nuevo sinónimo

􀂙 Desde una consulta o secuencia de comandos SQL, ejecute la siguiente instrucción:

create synonym name

for table

Sustituya name por el nombre del sinónimo y table por el nombre de la tabla.

7.            Para recuperar datos de un sinónimo

􀂙 En el Explorador de servidores, haga clic con el botón secundario del mouse (ratón) y elija Recuperar datos de sinónimo. Una cuadrícula muestra el propietario, nombre de columna, tipo de tabla, precisión, etc., para las columnas accesibles de todas las tablas, vistas y clústeres.

8.            Vistas

La carpeta Vistas contiene bloques con nombre de código SQL que filtran los datos disponibles de las tablas subyacentes.

9.            Funciones

La carpeta Funciones contiene bloques con nombre de código SQL que puede devolver valores a un programa de llamada. Para obtener información adicional sobre cómo trabajar con funciones

10.          Especificaciones del paquete

La carpeta Especificaciones del paquete contiene grupos con nombre de procedimientos públicos, funciones, excepciones, variables, constantes y cursores. Las especificaciones de paquete resultan útiles para compartir datos y aumentar la eficiencia.

11.          Para crear una nueva especificación de paquete

En el Explorador de servidores, haga clic con el botón secundario del mouse en el nodo Especificaciones del paquete y elija Nueva especificación 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 especificación de paquete

En el Explorador de servidores, haga clic con el botón secundario del mouse y elija Editar especificación de paquete en el menú contextual. En el editor se muestra el código SQL para la especificación 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 botón 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 botón secundario del mouse y elija Editar cuerpo de paquete en el menú contextual. En el editor se muestra el código SQL para el cuerpo de paquete.

CAPITULO III DESARROLLO

3.1 INTRODUCCIÓN:

En la actualidad, la utilización de metodologías 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 elaboración de las aplicaciones, por lo tanto, seguir metodologías y estándares nos llevan a estar en competitividad en todo momento.

Es de suma importancia conocer el modo como se interrelacionan metodologías con estándares y herramientas siguiendo un único propósito, el cual consiste en la elaboración de aplicaciones de manera eficiente, ordenada y con el menor número de defectos. La metodología RUP nos proporciona disciplinas en las cuales se encuentran artefactos con lo cual se podrá contar con guías para poder documentar e implementar de una manera fácil y eficiente, todas las guías 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 rápidas y que cumplan con los requerimientos planteados, por lo que el Desarrollo Rápido de Aplicaciones es una de las características que más 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 solución a la problemática presentado en la institución. Para la construcción del sistema de control de pago de pensiones del CPRGB, se optado por usar la metodología RUP ( Proceso Racional Unificado). A continuación 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.            Propósito alcance y Espacio del proyecto

El propósito del presente proyecto es diseñar, desarrollar e implementar un sistema de información computarizado para el control de pago de pensiones para la administración del colegio CPRGB que manipule y administre toda la información concerniente al cobro de pago de pensiones. Con el desarrollo del sistema de control de pago de pensiones del CPRGB, se busca dar solución a los problemas presentados en la institución de forma eficiente y eficaz, empleando información 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 módulos.

•             Pago de Mensualidad

•             Registra de pago de mensualidad.

•             Realizar informes y reportes sobre los ingresos (pago de pensión).

•             Genera comprobante de pago (Emitir Factura)

3.            REQUERIMIENTO TECNOLOGICO

En el requerimiento de software el lenguaje de programación Eclipse, como motor de base de datos MYSQL que es eficiente y segura.

La institución CPRGB no cuenta con ningún tipo de red por lo cual se optara por un enlace de red local.

4.            PLANIFICACIÓN INICIAL DEL PROYECTO:

Para poder cumplir con los objetivos establecidos en el proyecto y desarrollar todas las fases que contempla la metodología RUP, es necesario realizar una planificación temporal respecto al tiempo de trabajo que tomara la conclusión del sistema de control de pago de pensiones del CPRGB. La planificación del presente proyecto estará en base al tiempo estimado por la institución CPRGB.

Realizar el modelo de requisitos que incluya: Identificación de los casos de negocio Descripción de los casos de uso Definición del Modelo Conceptual Diagrama de Estados

5.            EL CASO DEL NEGOCIO

El caso del negocio proporciona la información necesaria, desde el punto de vista del sistema

a)            Descripción de sistema

 El sistema de control de pago de pensiones del CPRGB, esta diseñado para realizar el control y administración de los ingresos en la institución por concepto cobro de pago de pensiones, dando una solución eficaz y eficiente. Además 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 pensión 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 pensión).

•             Genera comprobante de pago (Emitir Factura)

b)           Identificación de Subsistemas

Los subsistemas identificados están en relación al alcance del proyecto. Para desarrollar el Sistema de control de pago de pensiones del CPRGB se identificaron los siguientes subsistemas o módulos. Es importante señalar 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)            Descripción de los subsistemas.-  La descripción de cada sistema es como sigue:

- Subsistema de paga mensualidad

  • Verificación de Código de estudiante.
  • Verifica deuda.

- Subsistema Registro de pago de mensualidad: Comprende:

  •    Registro de pago
  •  Actualización del registro de pago..

-              Generar Informes y reportes: Comprende

  •              Reportes de ingresos.
  •              Actualización de reportes.

-              Emite Factura: Comprende

  •              Confirmación de Código de estudiante.
  •              Generación de recibo o factura

d)           Gestión de riesgos.-  El riesgo es un problema potencial que puede ocurrir o no, y que puede afectar a los futuros acontecimientos. Por esta razón es necesario evaluar su probabilidad de aparición, estimar su impacto y establecer un plan de contingencia.

6.            Identificación del riesgo.- El método que utilizamos para identificar los riesgos es una lista de comprobación de elementos de riesgo:

-              Definición del proceso.

¿El tamaño de la base de datos a crear es grande?

¿Número de usuarios del sistema es grande?

¿La cantidad de software reutilizable es considerable?

-              Entorno de desarrollo.

¿Se tiene disponible las herramientas de gestión del proyecto de software?

¿Existen herramientas de análisis y diseño disponibles?

¿Proporcionan las herramientas de análisis y diseño métodos 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?

-              Tecnología a construir.

¿Es necesaria para la institución la tecnología a construir?

¿Es nueva la tecnología que se va a construir?

¿El software interactúa con hardware nuevo o no probado?

7.            Proyección del riesgo.-  Los riesgos más altos identificados en el proyecto son los siguientes:

-              Estimación del tamaño de software

-              Mayor número de usuarios de lo previsto

-              Falta de información sobre las herramientas

-              Falta de capacitación al usuario

8.            Análisis de costos.- En este punto se presenta una estimación del costo que implica el desarrollo del SCPP.

Costos directos: Son aquellos recursos utilizados en el desarrollo del sistema desde el inicio hasta su finalización y entrega al usuario.

Costos indirectos: Estos solo serán 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 información 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 continuación 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 COMUNICACIÓN:

3.5. DIAGRAMA DE CLASES DEL SISTEMA:

3.6. CONCLUSIÓN:

 

 En este proyecto se ha dado una visión  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. También el uso de herramientas como RATIONAL ROSE.

 

El análisis y desarrollo orientado a objetos aplicando RUP que  es una metodología completa y  extensa que intenta abarcar todo el mundo del desarrollo software, tanto para pequeños proyectos, como proyectos más ambiciosos de varios años de duración.  

 

No es fácil manejar esta metodología, pero con toda la bibliografía que existe sobre RUP, las herramientas disponibles para desarrollo de software Y UML esta tarea se hace mas causada.

 

3.7.  BIBLIOGRAFÍA:

 

  1. http://atenea.ucauca.edu.co/~gramirez/archivos/AnotacionesRUP.pdf Ramírez
  2. González, Gustavo A.,  Laboratorio III de Electrónica, 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.   Introducción al UML  http://www.yoprogramo.com/articulo4.php
  11.   Metodología 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, México, 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 análisis estructurado

 

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s