SISTEMA DE CONTROL DE PENSIONES

INTEGRANTES:

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

SISTEMA DE CONTROL Y ADMINISTRACIN DE PAGO DE PENSIONES PARA COLEGIO PARTICULAR 1. ANALISIS Y DISE;O ESTRUCTURADO 2. ORIENTADO A OBJETOS

INDICE

1.1INTRODUCCIN

1.2 Antescedentes
1.3 ARBOL DE PROBLEMAS 1.3.1 IDENTIFICACIN DEL PROBLEMA 1.3.2 PLANTEAMIENTO DEL PROBLEMA 1.4 OBJETIVOS 7 1.4.1 OBJETIVO GENERAL 8 1.4.2 OBJETIVO ESPECFICOL 9 1.5 ALCANCE 10 1.6 MTODOS DE INVESTIGACIN 11 1.7 JUSTIFICACIN 12 1.8 PLANIFICACION DE ACTIVIDADES MODELO ESENCIAL 13 a) MODELO AMBIENTAL 14 a1) DECLARACIN DE PROPOSITOS 15 a2) DIAGRAMA DE CONTEXTO 16 a3) LISTA DE ACONTECIMIENTOS 17 b) MODELO DE COMPORTAMIENTO 18 b1) MODELO PRELIMINAR DE COMPORTAMIENTO

INTRODUCCIN
En este tiempo los sistemas basados en computadora son ms necesarios para las actividades de las empresas e instituciones, para administrar grandes volmenes de informacin que cada da va creciendo. El fortalecimiento de los recursos humanos en un pas tiene como una de sus bases la educacin. La constante evolucin de la tecnologa informtica y el consecuente incremento de la necesidad de aplicaciones computacionales en organizaciones e instituciones, hace trascendental la necesidad de construir sistemas de informacin oportunos y confiables, que permitan mantener a las instituciones tecnolgica y cientficamente informadas para una mejora en la toma de decisiones. El Colegio Particular Rosemaria Galindo de Barrientos (CPRGB) no est al margen de la utilizacin de esta nueva tecnologa, puesto que la adecuada administracin de la informacin es fundamental para la toma de decisiones. Respondiendo a sta necesidad de contar con un sistema de informacin, que apoye y agilice al trabajo habitual del colegio para lograr un buen desempeo en las labores administrativas, se planteo el Sistema de Control de pago de pensiones de los alumnos del CPRGB .

1.2 Antescedentes
1.2 Antescedentes Utilizar sistemas de informacin para apoyar las tareas de administracin de control de pago de pensiones del colegio mencionado. Ya se dio con anterioridad en nuestro medio por lo que se toma como referencia

proyectos que proponen un modelo para la incorporacin de un sistema de informacin para apoyar a la administracin de control de pago de pensiones. El colegio se encuentra ubicado en la ciudad de La Paz, Zona Irpavi, que nace en Marzo del 1990 gracias al Sr. Paz que acepta el desafo de crear un lugar de educacin para nios y jvenes de la zona. Actualmente el sistema utilizado en el CPRGB es manual, el problema radica en el tratamiento de la informacin sobre la verificacin de pagos al da para la entrega de notas en kardex, lo cual retrasa la informacin. El Colegio Particular CPRGB como unidad educativa, no escapa a esta situacin, por esto surge la necesidad de un Sistema de Control de pago de pensiones, de tal forma que se pueda tener Informacin Almacenada y gestionada de manera ptima. Actualmente no cuenta con un proceso de almacenamiento digital.

1.3 ARBOL DE PROBLEMAS

1.3 ARBOL DE PROBLEMAS

1.3.1 IDENTIFICACIN DEL PROBLEMA

1.3.1 IDENTIFICACIN DEL PROBLEMA El CPRGB tropieza con dificultades en cuanto al manejo de informacin debido a la aplicacin de mtodos tradicionales que no dan solucin a los problemas que se mencionan a continuacin: Generacin de informacin inadecuada e inoportuna, del movimiento econmico del colegio. Dificultad en la elaboracin de informes en los procesos de pago de pensiones. Carencia de informacin capaz de generar datos confiables y rpidos de los alumnos, ocasionando inseguridad en la toma de decisiones.

1.3.2 PLANTEAMIENTO DEL PROBLEMA

Se observa tambin la vulnerabilidad de la seguridad de documentos esto genera la probabilidad de cometer ms errores en el momento de administrar y registrar dichos pagos. En consideracin a lo mencionado se propone lo siguiente: Desarrollar y aplicar un Sistema de Control de pago de pensiones. Minimizar y descongestionar el accionar operativo en lo que respecta al tiempo y los recursos humanos? Ayudara al manejo de la contabilidad?

1.4 OBJETIVOS 1.4.1 OBJETIVO GENERAL

Disear un Sistema de Control de pago de pensiones que sirva para la administracin del colegio CPRGB , para minimizar y descongestionar el accionar operativo en lo que respecta al tiempo y los recursos humanos en los procesos de control de informacin que permita mejorar y agilizar los procesos de cobro de pensiones.

1.4.2 OBJETIVO ESPECFICO

- Automatizar los procesos de pagos de pensiones del estudiante, generacin de reportes institucionales - Mejorar la manipulacin de informacin y que la misma sea precisa, oportuna, coherente y de alta calidad. - Brindar una herramienta que realice el control de ingresos (dinero) a dicha institucin 1.5 ALCANCE Los lmites del presente proyecto estn enmarcadas dentro de las necesidades encontradas al momento de haber realizado el estudio respectivo y llegando a la conclusin de realizar una base de datos para el proceso de cobro como ser: Modulo de pago y control de pensiones, Control de ingresos, que facilitara el cobro de manera eficiente y eficaz. 1.6 MTODOS DE INVESTIGACIN El tipo de estudio que se utilizara en la parte de anlisis y diseo es una investigacin Deductiva y cuantitativa, mediante visitas al colegio estadsticamente analizaremos los datos extrados ,usando el metodo de la observacin en el entorno , la cual nos ayudara a obtener informacin para solucionar los problemas que existen en la institucin , en el colegio CPRGB , podemos utilizar un mejor estudio y asi encontrar mediante un analisis personal de cada causa una mejor solucin a los problemas detectados. Las herramientas que se usan para diseo se encuentran enmarcadas en el anlisis estructurado de Edward Yourdon que ayudan en la abstraccin en el anlisis y diseo. Entre las herramientas que se utilizan tenemos diagrama de contexto, DFD,diccionario de datos, que ofrecen una visin de como se comporta la informacin. 1.7 JUSTIFICACIN El desarrollo de anlisis y diseo para colegios traer un gran beneficio a las personas involucradas directamente con el CPRGB. El Director Administrativo (dueo) obtendr la informacin del pago de las pensiones de los estudiantes. Tambien facilitara las operaciones que realiza el personal administrativo (secretaria) en el cobro de pensiones. 1.8 PLANIFICACION DE ACTIVIDADES Para la planificacion usamos diagramas de Gantt.

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

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

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

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

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

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

FUNCIONES Registro de pago: (Nombre_Alumno, Nivel, Curso, Monto a Pagar, Nombre_Tutor) - Si el nombre del alumno se repite entonces verificamos el nombre del tutor para realizar la operacin de cancelacin de pago. - Busca el nombre del alumno para hacer el pago de pensin correspondiente - Se registra el monto de pago que realizo Generar Comprobante de pago: (Apellido_Tutor, NIT, MONTO) - Este comprante servir para su administracin del tutor del alumno. - Se genera el comprobante una vez que se haya hecho el registro del pago correspondiente. - Verificando ambas partes, recin se realiza la impresin de este comprobante.

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

b4) DICCIONARIO DE DATOS DICCIONARIO DE DATOS Id _ alumno = *Identificador nico de alumno* Paterno+materno+nombre+fecha_nacimiento Nombre {carcter legal} Paterno {carcter legal} Materno {carcter legal} Fecha_nacimiento = *fecha de nacimiento* ** Carcter legal [A-Z/a-z] Id_pensin = *Identificacin de numero de pensin* (digito-numrico) Id _ curso = *Identificacin de curso* (Digito -alfanumrico) Id_usuario = *identificacin usuario*

(digito-alfanumrico) Num_pago = [id _ pensin] Inf_gral_alumno = *datos de alumno en general* {id_alumno, nombre, paterno, materno.fecha_nacimiento, id_curso, nombre_tutor, paterno_tutor, materno_tutor, ci_tutor, direccin actual} Direccion_actual = *datos acerca de la direccin del alumno* ** Datos usuario = *datos actuales del usuario* {id_usuario+nombre+paterno+materno+direccin} Login = *nombre con el que se registra* ** Pass Word = *contrasea usuario* ** Datos factura = *descripcin de la factura* {id_articulo+precio} Reporte ingreso = *reporte a la administracin sobre ingresos por cobro* {Total monto} Reporte pago = *reporte a la administracin sobre pago de mensualidad* {id_alumno+nombre+paterno+materno+curso+num_pago} Reporte mora = *reporte a la administracin sobre mora de alumnos* {id_alumno+nombre+paterno+materno+curso+num_pago} Respuesta = [*pago anulado* /*no se pudo anular el pago*] Solicitud = [*reporte de ingreso mensual*/ *reporte de pago de pensin por alumno* /*reporte por mora por curso*/] b5) ESPECIFICACIN DE PROCESOS PROCESO 1.1: REGISTRAR PAGO DE PENSION COMIENZA ENCONTRAR alumno en ALUMNO con id_alumno = id_alumno SI no encuentra registro Respuesta = No existe Alumno DESPLEGAR respuesta SALIR FIN_SI ENCONTRAR condicin en CONDICION con id _ condicin= curalumno.id_condicion en cur condicin ENCONTRAR ultimo _ pago en PENSION con id _ alumno = id _ alumno CREAR registro de pensin a partir de id_alumno, ultimo_pago+1, curPension.monto AADIR registro de pensin a PENSION TERMINAR PROCESO 1.2: VERIFICAR PAGO COMIENZA SI id_pension es recibido

ENCONTRAR id_alumno, id_pension en PENSION con id_alumno = id_alumno, id_pension = id_pension SI no encuentra registro Respuesta = *FALSO* DEVOLVER respuesta CASO CONTRARIO respuesta = *VERDADERO* DEVOLVER respuesta FIN_SI FIN_SI TERMINAR CONCLUCIONES: De acuerdo a la lnea de investigaciones que se eligi se llega a las siguientes conclusiones: El colegio requiere de un sistema de control de pensiones para la mejor administracin y control de los ingresos de las pensiones de cada alumno, siendo por excelencia, los instrumentos de contabilidad mensual, sobre todo cuando se puede medir cuantitati-vamente los resultados del buen manejo del sistema. Se incorpora en esta corriente la toma de decisiones como factor clave en el diseo del sistema de control de pensiones teniendo en cuenta variables externas e internas del Colegio. Tambien se puede sealar que una correcta implantacin del Sistema favorece y facilita el correcto control del cobro de pensiones por lo cual aportara resultados positivos a nivel econmico en el mismo. PROPUESTAS. Se ha propuesto un modelo de planificacin estratgica, el cual requiere un anlisis exhaustivo de la situacin interna y externa del Colegio del futuro que se quiera para ella, de su misin y objetivos y del diseo de las polticas apropiadas para cumplir esta misin. Esto requiere un anlisis profundo sobre cuales son y como son las necesidades del Colegio para el cobro de pensiones, teniendo en cuenta la situacin actual y las previsiones del futuro de las mismas. REFERENCIAS BIBLIOGRAFICAS.Bueno nosotras ms fuimos investigando mediante tesis: - SISTEMA DE INFORMACIN PARA EL CONTROL Y SEGUIMIENTO DE ATENCION AL CLIENTE Autor: Rosemary Merlo Quispe - SISTEMA DE INFORMACIN VA WEB PARA EL CONTROL DE ALMACENES FBRICA DE FIDEOS SANTA ROSA Autor: Julia Mamani Mamani. - TESIS DE LA CARRERA DE INFORMATICA:T-1843, T-1550, T-1456

2. ORIENTADO A OBJETOS
************************************************************************* **************************************************

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

SISTEMA DE CONTROL DE PAGO DE PENSIONES PARA COLEGIO PARTICULAR -> ORIENTADO A OBJETOS

INDICE CAPITULO I 1.1INTRODUCCIN

1.2 ANTECEDENTES
1.3.2 PLANTEAMIENTO DEL PROBLEMA 1.3.1 IDENTIFICACIN DEL PROBLEMA 1.3.2 ARBOL DE PROBLEMAS 1.4 OBJETIVOS 1.4.1 OBJETIVO GENERAL 1.4.2 OBJETIVO ESPECFICO 1.4.3 ARBOL DE OBJETIVOS 1.5 ALCANCE 1.7 JUSTIFICACIN CAPITULO II ANTECEDENTES DE LA ORGANIZACIN 2.1 PARADIGMA ORIENTADO A OBJETOS 2.2 MODELOS DE DESARRROLLO 2.2.1 METODOLOGIA RUP 2.2.2 METODOLOGIA DAS 2.2.3 METODOLOGIA XP 2.3 UML VERSION 2.0 2.4 LENGUAJES DE PROGRAMACIN 2.4.1 ECLIPSE 2.4.2 VISUAL BASIC 2.4.3 C# 2.5 SISTEMAS GESTORES DE BASE DE DATOS 2.5.1 MYSQL 2.5.2 SQL 2.5.3 ORACLE CAP III 3.1 INTRODUCCION

3.2 FASE DE INICIO 3.3 FASE DE ELABORACIN CAPITULO I

1.1 INTRODUCCIN
Estamos viviendo en una sociedad de informacin, la tecnologa informtica y el consecuente incremento de la necesidad de aplicaciones computacionales en organizaciones e instituciones dependen cada vez ms de la creacin y distribucin de sistemas de informacin a travs de redes locales, internet, esto con lleva al uso de de las nuevas tecnologas de informacin, por medio de las cuales las organizaciones consiguen grandes beneficios, como mejorar operaciones, mejor servicio, etc. El fortalecimiento de los recursos humanos en un pas tiene como una de sus bases la educacin, lo que hace trascendental el uso de estas nuevas tecnologas lo que proporciona informacin oportuna y confiable, as como mejoras en su imagen y comunicacin. El Colegio Particular Rosemaria Galindo de Barrientos (CPRGB) no est al margen del uso de esta nueva tecnologa, por lo que surge la necesidad de un sistema de control de pago de pensiones, de tal manera que se pueda tener informacin almacenada, ya que es fundamental para la toma de decisiones. Respondiendo a sta necesidad de contar con un sistema de informacin, se pretende mejorar el control de cobro de pensiones del Colegio Privado Rosemaria Galindo de Barrientos, que apoye y agilice al trabajo habitual del colegio para lograr un buen desempeo en las labores administrativas.

1.2.ANTECEDENTES
El colegio CPRGB (Colegio Privado Rosamara Galindo de Barrientos) se encuentra ubicado en la ciudad de La Paz, Zona Irpavi, que nace en Marzo del 1990 gracias al Sr. Paz que acepta el desafo de crear un lugar de educacin para nios y jvenes de la zona. El colegio GPRGB es una institucin de carcter privado. Es una empresa al servicio de la educacin. Afiliada a la asociacin de colegios particulares ANDECOP y registrada en las diferentes instancias jurdicas dependientes del estado cumple con las obligaciones de ley en actual vigencia. El Colegio Particular CPRGB como unidad educativa, no escapa a esta situacin, por esto surge la necesidad de un Sistema de Control de pago de pensiones, de tal forma que se pueda tener Informacin Almacenada y gestionada de manera ptima. Actualmente no cuenta con un proceso de almacenamiento digital, el problema radica en el tratamiento de la informacin sobre la verificacin de pagos al da para la entrega de notas en kardex, lo cual retrasa la informacin.

1.3. PROBLEMTICA EN TRABAJOS SIMILARES

Utilizar sistemas de informacin para apoyar las tareas de administracin de control de pago de pensiones del colegio mencionado, ya se dio con anterioridad en nuestro medio por lo que se toma como referencia proyectos que proponen un modelo para la incorporacin de un sistema de informacin para apoyar a la administracin de control de pago de pensiones: Sistema de Control disciplinario Colegio San Calixto realizado por Morales Juan en el ao Seguimiento acadmico Colegio Santa Mara CENAFI, realizado por Nina Pealoza Marco en el

ao 2002.

Sistema de Control y seguimiento acadmico para colegios Caso de estudio: Colegio La familia, directores, profesores y psiclogos, puedan realizar el

Salle 8 elaborado por Rudy Oliver Saavedra Pereira. El sistema est orientado para que los padres de control y seguimiento acadmico de los estudiantes en distintas reas de aprendizaje. Actualmente como se menciono anteriormente no cuenta con un proceso de almacenamiento digital, en el cobro de pago de pensiones, por lo que los procesos siguen siendo manuales. 1.4. PLANTEAMIENTO DEL PROBLEMA En la unidad educativa CPRGB se han encontrado dificultades en el manejo de informacin, no se puede acceder a la informacin de una manera eficiente, ya que la recoleccin de la misma es manual, lo que dificulta el control. Para evitar lo mencionado se debe implementar un sistema de control que nos brinde informacin confiable de forma rpida y automtica, que ayude al control de ingresos (cobro de pago de pensiones). 1.4.1. IDENTIFICACIN DEL PROBLEMA El CPRGB tropieza con dificultades en cuanto al manejo de informacin debido a la aplicacin de mtodos tradicionales que no dan solucin a los problemas que se mencionan a continuacin: 1.4.2. Generacin de informacin inadecuada e inoportuna, ya que el registro y cobro de pensiones son Dificultad en la elaboracin de informes en los procesos de pago de pensiones. La informacin no es accesible y la falta de informacin no genera datos confiables y rpidos, lo que FORMULACIN DEL PROBLEMA manuales, lo que provoca que el control sea deficiente.

dificulta el control de ingreso de dinero, ocasionando inseguridad en la toma de decisiones. El anlisis y diseo a desarrollar en forma sistemtica en los procesos del colegio: Podr aplicar controles efectivos y seguimiento al pago de pensiones? Para evitar todo lo mencionado se debe implementar un sistema que nos brinde informacin precisa, que ayude al control de ingresos al colegio (pago de pensiones). 1.4.3. ARBOL DE PROBLEMAS

1.5. 1.5.1.

OBJETIVOS: OBJETIVO GENERAL

Desarrollar e implementar un Sistema de Control de pago de pensiones que trabaje en un entorno de red local, que colabore al control y la administracin del colegio privado Rosemaria Galindo de Barrientos ofreciendo informacin confiable; para agilizar los procesos de cobro de pensiones utilizando herramientas de anlisis, diseo y desarrollo de sistemas de informacin. 1.5.2. OBJETIVOS ESPECIFICOS Estudiar modelos de desarrollo para conocer el modo como se interrelacionan metodologas con

estndares y herramientas, que tienen como propsito el diseo y elaboracin de un sistema que realice el control eficiente y eficaz de ingresos. 1.5.3. Realizar un control centralizado de los ingresos de los procesos de pago de pensiones, mediante la Proporcionar herramientas para un mejor manejo de la informacin, que la misma sea precisa, Realizar pruebas para mejorar el diseo y la elaboracin del sistema. ARBOL DE OBJETIVOS interaccin de una intranet. oportuna y as facilitar la generacin de reportes.

1.6. ALCANCES Los alcances estn enmarcados en la obtencin de resultados en los objetivos secundarios planteados anteriormente. El sistema a desarrollar esta orientado a: 1.7. Mejorar el control y seguimiento sobre el cobro de pensiones de manera eficiente y eficaz. Facilitar el manejo de la informacin sobre el cobro de pago de pensiones para emitir reportes. JUSTIFICACIN

El desarrollo de un sistema de control de pago de pensiones dedicado a tareas especificas, producto del anlisis diseo y desarrollo de sistemas de informacin, ayudara a solucionar los problemas encontrados en la institucin, ya que traer un gran beneficio, facilitar las operaciones qu realizan las personas involucradas directamente con el Colegio Particular Rosemaria Galindo de Barrientos. 1.7.1. JUSTIFICACION TECNICA El diseo del sistema de control que tiene la finalidad de mejorar la informacin sobre el cobro de pensiones de manera centralizada, se basar en el uso de la tecnologa actual existente de carcter gratuito, as como las herramientas de diseo y los lenguajes de programacin. 1.7.2. JUSTIFICACION ECONOMICA Reducir de gran manera los gastos en los gastos en los que se incurren por errores durante la operaciones de cobro que se realizan en la institucin adems la funcin del sistema es la de tener un mejor control de ingresos y mejorar las utilidades. 1.7.3. JUSTIFICACION SOCIAL El Diseo y desarrollo del sistema mejorara la calidad del servicio hacia los usuarios de la institucin para que de esta forma se presente una imagen seria, ya que facilitara el registro, almacenamiento y control de la

informacin al personal del rea de cobro de pensiones, as facilitar la comunicacin del usuario con la institucin. 1.7. CRONOGRAMA

CAPITULO II 2.1

MARCO TEORICO

ANTECENDENTES DE LA ORGANIZACION

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

2.1 PARADIGMA ORIENTADO A OBJETOS: Es una tcnica o estilo de programacin que utiliza objetos como bloque fundamental de Construccin. 2.1.1 Elementos bsicos de la POO. a) Bloques: Son un conjunto complejo de datos (atributos) y funciones (mtodos) que poseen una determinada Estructura y forman parte de una organizacin. Los atributos definen el estado del objeto; los mtodos, su comportamiento. b) c) Mtodos: Es un programa procedimental que est asociado a un objeto determinado y cuya ejecucin Mensajes: Es simplemente una peticin de un objeto a otro para que este se comporte de una manera solo Puede desencadenarse a travs del mensaje correspondiente. Determinada, ejecutando uno de sus mtodos. Los mensajes comunican a los objetos con otros y con el mundo exterior. A esta tcnica de enviar Mensajes se la conoce como paso de mensajes. d) e) Clases: Es un tipo definido por el usuario que determina la estructura de datos y las operaciones La Interfaz es el conjunto de mtodos, propiedades, eventos y atributos que se declaran como Asociadas con ese tipo. Todos los objetos estn compuestos de tres cosas Interfaz. pblicos en su alcance y que pueden invocar los programas escritos para usar nuestro objeto Implementacin Al cdigo dentro de los mtodos se le llama Implementacin. Algunas veces tambin se le llama comportamiento, ya que este cdigo es el que efectivamente logra que el objeto haga un trabajo til. Es importante entender que las aplicaciones del cliente pueden utilizar nuestro objeto aunque cambiemos la implementacin, siempre que no cambiemos la interfaz. Siempre que se mantengan sin cambio nuestro nombre de mtodo, su lista de parmetro y el tipo de datos de devolucin, podremos cambiar la

implementacin Estado El estado o los datos de un objeto es lo que lo hace diferente de otros objetos de la misma clase. El estado se describe a travs de las variables del Miembro o de la Instancia. Las variables del miembro son aquellas declaradas, de tal manera que estn disponibles para todo el cdigo dentro de la clase. Por lo general, las variables del miembro son Privadas en su alcance. Algunas veces, se les conoce como variables de la instancia o como atributos. 2.1.2 Caractersticas. a) Abstraccin: Significa extraer las propiedades esenciales de un objeto que lo distinguen de los dems tipos de Objetos y proporciona fronteras conceptuales definidas respecto al punto de vista del observador. Es la capacidad para encapsular y aislar la informacin de diseo y ejecucin. b) Encapsulamiento: Es el proceso de almacenar en un mismo compartimiento (una caja negra) los elementos de una Abstraccin (toda la informacin relacionada con un objeto) que constituyen su estructura y su Comportamiento. Esta informacin permanece oculta tanto para los usuarios como para otros objetos Y puede ser accedida solo mediante la ejecucin de los mtodos adecuados. c) Herencia: Es la propiedad que permite a los objetos construirse a partir de otros objetos. La clase base contiene todas las caractersticas comunes. Las sub-clases contienen las Caractersticas de la clase base ms las caractersticas particulares de la sub-clase. Si la sub-clase hereda caractersticas de una clase base, se trata de herencia simple. Si hereda de dos o ms clases base, herencia mltiple. d) Polimorfismo: Literalmente significa cualidad de tener ms de una forma. En poo, se refiere al hecho que una Misma operacin puede tener diferente comportamiento en diferentes objetos. En otras palabras, Diferentes objetos reaccionan al mismo mensaje de modo diferente. e) Modularidad: Un programa es modular si se compone de mdulos independientes y robustos. Esto permite la Reutilizacin y facilita la verificacin y depuracin de los mismos. En poo, los mdulos estn Directamente relacionados con los objetos. Los objetos son mdulos naturales ya que corresponden A una imagen lgica de la realidad. f) Jerarqua: La mayora de nosotros ve de manera natural nuestro mundo como objetos que se relacionan entre s de una manera jerrquica. Por ejemplo, un perro es un mamfero, y los mamferos son animales, y los animales seres vivos Del mismo modo, las distintas clases de un programa se organizan mediante la jerarqua. La representacin de dicha organizacin da lugar a los denominados rboles de herencia Mediante la herencia una clase hija puede tomar determinadas propiedades de una clase padre. As se simplifican los diseos y se evita la duplicacin de cdigo al no tener que volver a codificar mtodos ya implementacin Al acto de tomar propiedades de una clase padre se denomina heredar. 2.1.3 Herencia y polimorfismo a) Herencia: Herencia es la propiedad de que los ejemplares de una clase hija extiendan el comportamiento y los datos asociados a las clases paternas. La herencia es siempre transitiva, es decir que una sub-clase hereda caractersticas de superclases alejadas muchos niveles. Reusabilidad del software Cuando el comportamiento se hereda de otra clase, no es necesario reescribir el cdigo que lo define. Comparticin de cdigo. Muchos usuarios o proyectos distintos pueden usar las mismas clases. Por otro lado, la herencia reduce el tiempo de escritura y el tamao final del programa. Consistencia de la interfaz. El comportamiento de una clase madre que heredan todas sus clases hijas ser el mismo, de esta manera se asegura que las interfaces para objetos sern similares y no solo un conjunto de objetos que son parecidos pero que actan e interactan de forma diferente.

b)

Polimorfismo Poli (muchas)-morphus (formas): Mismo servicio (interfaz) en distintos tipos de

objetos, donde c/u responde de acuerdo a su propia naturaleza (implementacin. Beneficios: Cdigo m genrico .Permite al programador generar componentes reutilizables de alto nivel que puedan adaptarse a diferentes aplicaciones mediante el cambio de sus partes de bajo nivel. Genrico. Maximiza la calidad de rehus y extensibilidad. 2.1.4 Otras propiedades: El modelo objeto ideal no solo tiene las propiedades anteriormente citadas sino que es conveniente que soporte, adems, estas otras propiedades. a) Concurrencia (multitarea): el lenguaje soporta la creacin de procesos paralelos independientes del sistema operativo. Esta propiedad simplificar la transportabilidad de un sistema de tiempo real de una plataforma a otra. Se dice que dos o ms procesos son concurrentes si estn construidos de manera tal que pueden ejecutarse al mismo tiempo y compartiendo recursos. b) c) Persistencia: los objetos deben poder ser persistentes; es decir, los objetos han de poder permanecer Genericidad: las clases parametrizadas (mediante plantillas o unidades genricas) sirven para despus de la ejecucin del programa. soportar un alto grado de reutilizacin. Estos elementos genricos se disean con parmetros formales, que se instanciaran con parmetros reales, para crear instancias de mdulos que se compilan y enlazan, y ejecutan posteriormente. d) Manejo de Excepciones: se deben poder detectar, informar y manejar condiciones excepcionales utilizando construcciones del lenguaje. 2.2. MODELOS DE DESARROLLO: 1. Introduccin En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino gil, aplicado al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas. Para asegurar el xito durante el desarrollo de software no es suficiente contar con notaciones de modelado y herramientas, hace falta un elemento importante: la metodologa de desarrollo, la cual nos provee de una direccin a seguir para la correcta aplicacin de los dems elementos. Generalmente el proceso de desarrollo llevaba asociado un marcado nfasis en el control del proceso mediante una rigurosa definicin de roles, actividades y artefactos, incluyendo modelado y documentacin detallada. Este esquema tradicional para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamao (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el ms adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologas tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir de las buenas prcticas de la Ingeniera del Software, asumiendo el riesgo que ello conlleva. En este contexto, las metodologas giles emergen como una posible respuesta para llenar ese vaco metodolgico. Por estar

especialmente orientadas para proyectos pequeos, las Metodologas giles constituyen una solucin a medida para ese entorno, aportando una elevada simplificacin que a pesar de ello no renuncia a las prcticas esenciales para asegurar la calidad del producto. 2. Por qu usar Metodologas giles Existen unas costosas fases previas de especificacin de requisitos, anlisis y diseo. La correccin Las metodologas tradicionales presentan los siguientes problemas a la hora de abordar proyectos: durante el desarrollo de errores introducidos en estas fases ser costosa, es decir, se pierde flexibilidad ante los cambios. El proceso de desarrollo est encorsetado por documentos firmados. El desarrollo es ms lento. Es difcil para los desarrolladores entender un sistema complejo en su

globalidad. Las metodologas giles de desarrollo estn especialmente indicadas en proyectos con requisitos poco definidos o cambiantes. Estas metodologas se aplican bien en equipos pequeos que resuelven problemas concretos, lo que no est reido con su aplicacin en el desarrollo de grandes sistemas, ya que una correcta modularizacin de los mismos es fundamental para su exitosa implantacin. Dividir el trabajo en mdulos abordables minimiza los fallos y el coste. Las metodologas giles presentan diversas ventajas, entre las que podemos destacar: 1. 2. 3. 4. 5. 6. 1. Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo Entrega continua y en plazos breves de software funcional Trabajo conjunto entre el cliente y el equipo de desarrollo Importancia de la simplicidad, eliminado el trabajo innecesario Atencin contina a la excelencia tcnica y al buen diseo Mejora continua de los procesos y el equipo de desarrollo Introduccin al RUP

2.2.1 RUP: Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Rational) es un producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos. 2. Dimensiones del RUP El RUP tiene dos dimensiones: El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso. El eje vertical representa las disciplinas, que agrupan actividades definidas lgicamente por la naturaleza. La primera dimensin representa el aspecto dinmico del proceso y se expresa en trminos de fases, de iteraciones, y la finalizacin de las fases. La segunda dimensin representa el aspecto esttico del proceso: cmo se describe en trminos de componentes de proceso, las disciplinas, las actividades, los flujos de trabajo, los artefactos, y los roles. En la figura 1 se puede observar como vara el nfasis de cada disciplina en un cierto plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en iteraciones tempranas, pasamos ms tiempo en requerimientos, y en las ltimas iteraciones pasamos ms tiempo en poner en prctica la realizacin del proyecto en s.

Figura 1. Disciplinas, fases, iteraciones del RUP Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP: a) Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilizacin de los Casos de Uso para el desenvolvimiento y desarrollo de las disciplinas con los artefactos, roles y actividades necesarias. Los Casos de Uso son la base para la implementacin de las fases y disciplinas del RUP. a. Un Caso de Uso es una secuencia de pasos a seguir para la realizacin de un fin o propsito, y se relaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia de pasos que conlleva la realizacin e implementacin de un Requerimiento planteado por el Cliente. b) Proceso Iterativo e Incremental: Es el modelo utilizado por RUP para el desarrollo de un proyecto de software. Este modelo plantea la implementacin del proyecto a realizar en Iteraciones, con lo cual se pueden definir objetivos por cumplir en cada iteracin y as poder ir completando todo el proyecto iteracin por iteracin, con lo cual se tienen varias ventajas, entre ellas se puede mencionar la de tener pequeos avances del proyectos que son entregables al cliente el cual puede probar mientras se est desarrollando otra iteracin del proyecto, con lo cual el proyecto va creciendo hasta completarlo en su totalidad. Este proceso se explica ms adelante a detalle. c) Proceso Centrado en la Arquitectura: Define la Arquitectura de un sistema, y una arquitectura ejecutable construida como un prototipo evolutivo.

Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes. Una arquitectura ejecutable es una implementacin parcial del sistema, construida para demostrar algunas funciones y propiedades. RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo. II. FASES El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales (figura 2). En cada extremo de una fase se realiza una evaluacin (actividad: Revisin del ciclo de vida de la finalizacin de fase) para determinar si los objetivos de la fase se han cumplido. Una evaluacin satisfactoria permite que el proyecto se mueva a la prxima fase.

Fig. 2Fases del RUP Planeando las fases El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del producto, cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteraciones, estas fases son: 1. Concepcin, Inicio o Estudio de oportunidad Define el mbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura bsica Se planifica el proyecto considerando recursos disponibles

2. Elaboracin

3. Construccin

El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de anlisis, Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de manera Gran parte del trabajo es programacin y pruebas. Se documenta tanto el sistema construido como el manejo del mismo. Esta fase proporciona un producto construido junto con la documentacin Se libera el producto y se entrega al usuario para un uso real. Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, Los manuales de usuario se completan y refinan con la informacin anterior Estas tareas se realizan tambin en iteraciones

diseo e implementacin incremental conforme se construye (se permiten cambios en la estructura)

4. Transicin

soporte, mantenimiento, etc.

Todas las fases no son idnticas en trminos de tiempo y esfuerzo. Aunque esto vara considerablemente dependiendo del proyecto, un ciclo de desarrollo inicial tpico para un proyecto de tamao mediano debe anticipar la distribucin siguiente el esfuerzo y horario:

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

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

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

2.

Esfuerzo respecto de las fases

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

3.

Iteraciones

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

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

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

6.

Disciplinas

Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias son las necesarias para la realizacin de un proyecto de software, aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las primarias y especifican otras caractersticas en la realizacin de un proyecto de software; entre estas se tienen: Entorno, Gestin del Proyecto, Gestin de Configuracin y Cambios. A continuacin se describe rpidamente cada una de estas disciplinas. IV. MODELADO DEL NEGOCIO Esta disciplina tiene como objetivos comprender la estructura y la dinmica de la organizacin, comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio. Utiliza el Modelo de CU del Negocio para describir los procesos del negocio y los clientes, el Modelo de Objetos del Negocio para describir cada CU del Negocio con los Trabajadores, adems utilizan los Diagramas de Actividad y de Clases.

1.

Requerimientos Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer

(Especificar Requisitos), definir los lmites del sistema, y una interfaz de usuario, realizar una estimacin del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los CU, Actores y Relaciones, adems utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias. 2. Anlisis y diseo Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementacin, al decir anlisis se refiere a transformar CU en clases, y al decir diseo se refiere a refinar el anlisis para poder implementar los diagramas de clases de anlisis de cada CU, los diagramas de colaboracin de de cada CU, el de clases de diseo de cada CU, el de secuencia de diseo de CU, el de estados de las clases, el modelo de despliegue de la arquitectura. 3. Implementacin Esta disciplina tiene como objetivos implementar las clases de diseo como componentes (ej. fichero fuente), asignar los componentes a los nodos, probar los componentes individualmente, integrar los componentes en un sistema ejecutable (enfoque incremental). Utiliza el Modelo de Implementacin, conjuntamente los Diagramas de Componentes para comprender cmo se organizan los Componentes y dependen unos de otros. 4. Pruebas Esta disciplina tiene como objetivos verificar la integracin de los componentes (prueba de integracin), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribucin. 5. Despliegue Esta disciplina tiene como objetivos asegurar que el producto est preparado para el cliente, proceder a su entrega y recepcin por el cliente. En esta disciplina se realizan las actividades de probar el software en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, as como la tarea de ensear al usuario. 6. Gestin y configuracin de cambios Es esencial para controlar el nmero de artefactos producidos por la cantidad de personal que trabajan en un proyecto conjuntamente. Los controles sobre los cambios son de mucha ayuda ya que evitan confusiones costosas como la compostura de algo que ya se haba arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas: 7. Actualizacin simultnea: Es la actualizacin de algo elaborado con anterioridad, sin saber que Notificacin limitada: Al realizar alguna modificacin, no se deja informacin sobre lo que se hizo, Versiones mltiples: No saber con exactitud, cual es la ltima versin, y al final no se tiene un Gestin del proyecto Su objetivo es equilibrar los objetivos competitivos, administrar el riesgo, y alguien ms lo est actualizando. por lo tanto no se sabe quien, como, y cuando se hizo. orden sobre que modificaciones se han realizado a las diversas versiones. superar restricciones para entregar un producto que satisface las necesidades de ambos clientes con xito (los que pagan el dinero) y los usuarios. Con la Gestin del Proyecto se logra una mejora en el manejo de una entrega exitoso de software. En resumen su propsito consiste en proveer pautas para: Administrar proyectos de software intensivos. Planear, dirigir personal, ejecutar acciones y supervisar proyectos. Administrar el riesgo.

 8.

Sin embargo, esta disciplina no intenta cubrir todos los aspectos de direccin del proyecto. Por Administracin de personal: contratando, entrenando, enseando. Administracin del presupuesto: definiendo, asignando. Administracin de los contratos con proveedores y clientes. Entorno Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que

ejemplo, no cubre problemas como:

engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo de las pautas que apoyan un proyecto. Su propsito es proveer a la organizacin que desarrollar el software, un ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software. 9. Organizacin y elementos en RUP: Ya conociendo varias partes del RUP nos concentraremos ahora en los elementos que lo componen, entre estos se tienen: Flujos de Trabajo, Detalle de los Flujos de Trabajo, Actores, Actividades y Artefactos. En la figura 10 se muestran ms claramente como se representan grficamente cada uno de estos elementos y la interrelacin entre ellos. Se puede observar que el Flujo de Trabajo de Requerimientos conlleva varios pasos, cada uno de estos pasos tiene asociado uno o varios actores, los cuales a su vez son los encargados de la ejecucin de varias actividades, las cuales a la vez estn definidas artefactos o guas para su realizacin.

V. Actores o roles Son los personajes encargados de la realizacin de las actividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, estos actores se dividen en varias categoras: Analistas, Desarrolladores, Probadores, Encargados, Otros actores. A continuacin se presenta una lista de actores de acorde a las categoras mencionadas con anterioridad: 1. a. b. c. d. e. f. 2. 3. 4. 5. 6. Analistas Analista del Proceso del Negocio. Diseador del Negocio. Revisor del Modelo del Negocio. Revisor de Requerimientos Analista del Sistema. Especificador de Casos de Uso. Diseador de Interfaz del Usuario Desarrolladores Arquitecto Revisor de la Arquitectura Diseador de Cpsulas Revisor del Cdigo y Probadores Profesionales Diseador de Pruebas Probador Encargados Encargado de Control del Cambio Encargado de la Configuracin Encargado del Otros Cualquier trabajador Artista Grfico Stakeholder Administrador del Sistema Escritor tcnico Artefactos Los artefactos son el resultado parcial o final que es producido y usado por los actores

Revisor del Diseo Diseador de la Base de Datos Diseador Implementador y un Integrador

Despliegue Ingeniero de Procesos Encargado de Proyecto Revisor de Proyecto Especialista de Herramientas durante el proyecto. Son las entradas y salidas de las actividades, realizadas por los actores, los cuales utilizan y van produciendo estos artefactos para tener guas. Un artefacto puede ser un documento, un modelo o un elemento de modelo. VI. Conjuntos de artefactos Se tiene un conjunto de artefactos definidos en cada una de las disciplinas y utilizadas dentro de ellas por lo actores para la realizacin de las mismas, a continuacin se definen cada una de estas categoras o grupos de artefactos dentro de las disciplinas del RUP: a) Modelado del negocio Los artefactos del modelado del negocio capturan y presentan el contexto del negocio del sistema. Los artefactos del modelado del negocio sirven como entrada y como referencia para los requisitos del sistema. b) Requerimientos Los artefactos de requerimientos del sistema capturan y presentan la informacin usada en definir las capacidades requeridas del sistema. c) Anlisis y diseo del sistema Los artefactos para el anlisis y del diseo capturan y presenta la informacin relacionada con la solucin a los problemas se presentaron en los requisitos fijados. d) Implementacin Los artefactos para la implementacin capturan y presentan la realizacin de la solucin presentada en el anlisis y diseo del sistema. e)Pruebas

Los artefactos desarrollados como productos de las actividades de prueba y de la evaluacin son agrupadas por el actor responsable, con el cual se lleva un conjunto de documentos de informacin sobre las pruebas realizadas y las metodologas de pruebas aplicadas. f) Despliegue Los artefactos del despliegue capturan y presentan la informacin relacionada con la transitividad del sistema, presentada en la implementacin en el ambiente de la produccin. g) Administracin del proyecto El conjunto de artefactos de la administracin del proyecto capturan los artefactos asociados con el proyecto, el planeamiento y a la ejecucin del proceso. h) Administracin de cambios y configuracin Los artefactos de la configuracin y administracin del cambio capturan y presentan la informacin relacionada con la disciplina de configuracin y administracin del cambio. i) Entorno o ambiente El conjunto de artefactos del ambiente presentan los artefactos que se utilizan como direccin a travs del desarrollo del sistema para asegurar la consistencia de todos los artefactos producidos. VII. Grado de finalizacin de artefactos.- Consiste en cuanto hemos finalizado del artefacto propuesto, con esto nos referimos por ejemplo, si definimos que vamos a utilizar un artefacto, este nos dice los lineamientos que necesita para ser completado, por lo tanto con grado de finalizacin nos referimos a cuntos de esos lineamientos del artefacto hemos completado o llenado, esto en cada una de las disciplinas, de acorde a la fase en que se encuentre, para entender de mejor manera lo antes dicho se muestra en la figura, en la cual se puede observar que en la fase de Concepcin, en la disciplina de Implementacin del Sistema los artefactos tienen una poca finalizacin y van aumentando progresivamente en cada fase hasta llegar a su culminacin en la fase de Transicin, en la disciplina de Ingeniera del Negocio los artefactos tienen una media finalizacin y sucede lo mismo que con los artefactos de la disciplina anterior los cuales finalizan tambin en la fase de Transicin.

Con esto se puede mostrar el aumento progresivo de los artefactos en cada disciplina en la fase dada, teniendo una idea un poco ms amplia sobre el desenvolvimiento del proyecto hablando en trminos de sus artefactos. 2.2.2. METODOLOGA GIL ASD (Adaptive Software Development) 1. Introduccin Metodologa gil desarrollada por jim highsmith, despus de trabajar muchos aos con metodologas predictivas concluyo que son defectuosas. Metodologas sin muchas ataduras y reglas a seguir, es la metodologa ms abierta. Las personas deben colaborar de la mejor manera, para dar respuesta y soluciones creativas. Esta metodologa se adapta al cambio en lugar de luchar con l. Se basa en la adaptacin continua a circunstancias cambiantes. En ella no hay un ciclo de planificacin, diseo, construccin del software, sino un ciclo especular, colaborar, aprender. 2. Definicin

El mtodo gil ASD desarrollo Adaptable de Software es un modelo de implementacin para desarrollo de software. Al igual que otras metodologas agiles, su funcionamiento es cclico y reconoce que en cada iteracin se producirn cambios e incluso errores. 3. 4. Caractersticas Iterativo, Orientado a los componentes de software, Tolerante a los cambios, Guiados por los riesgos, La revisin de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de Ciclo de vida Especulacin.- Es donde se inicia y se planifican las caractersticas del Software. Colaboracin.- Se desarrollan las caractersticas del Software. Aprendizaje.- Se revisa la calidad, y si no tiene errores se entrega al cliente. Sus principales caractersticas del ASD son:

desarrollo. El ciclo de vida del ASD se basa en:

Hay ausencia de estudios de casos del mtodo adaptativo, aunque las referencias literarias a sus principios son abundantes. Como ASD no constituye un mtodo de ingeniera de ciclo de vida sino una visin cultural o una epistemologa, no califica como framework suficiente para articular un proyecto. Ms visible es la participacin de Highsmith en el respetado Cutter Consortium, del cual es director del Agile Project Management Advisory Service. Entre las empresas que han requerido consultora adaptativa se cuentan AS Bank de Nueva Zelanda, CNET, GlaxoSmithKline, Landmark, Nextel, Nike, Phoenix International Health, Thoughworks y Microsoft. Ventajas Sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo, Utiliza informacin acerca de cambios para mejorar el comportamiento del software, Promulga colaboracin, la interaccin de personas, Anticipa cambios y trata automticamente con ellos. Los errores o cambios que no son detectados en reuniones anteriores a tiempo afecta tanto a la Dado a que es una metodologa gil implica no realizar procesos que son requeridos en las

Desventajas calidad del producto como a su costo total, metodologas tradicionales o por lo menos no realizados en diferentes procesos. 2.2.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD DSDM es la nica de las metodologas aqu planteadas surgida de un Consorcio, formado originalmente por 17 miembros fundadores en Enero de 1994. El objetivo del Consorcio era producir una metodologa de dominio pblico que fuera independiente de las herramientas y que pudiera ser utilizado en proyectos de tipo RAD (Rapid Application Development). El Consorcio, tomando las best practices que se conocan en la industria y la experiencia trada por sus fundadores, liber la primera versin de DSDM a principios de 1995. A partir de ese momento el mtodo fue bien acogido por la industria, que empez a utilizarlo y a capacitar a su personal en las prcticas y valores de DSDM. Debido a este xito, el Consorcio comision al Presidente del

Comit Tcnico, Jennifer Stapleton, la creacin de un libro que explorara la realidad de implementar el mtodo. Dado el enfoque hacia proyectos de caractersticas RAD esta metodologa encuadra perfectamente en el movimiento de metodologas giles. La estructura del mtodo fue guiada por estos nueve principios: 1. 2. 3. 4. 5. negocio. 6. 7. 8. 9. Todos los cambios durante el desarrollo son reversibles. Los requerimientos estn especificados a un alto nivel. El testing es integrado a travs del ciclo de vida. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial. El involucramiento del usuario es imperativo. Los equipos de DSDM deben tener el poder de tomar decisiones. El foco est puesto en la entrega frecuente de productos. La conformidad con los propsitos del negocio es el criterio esencial para la aceptacin de los El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin del

entregables.

DSDM define cinco fases en la construccin de un sistema ver (Figura N8). Las mismas son: estudio de factibilidad, estudio del negocio, iteracin del modelo funcional, iteracin del diseo y construccin, implantacin. El estudio de factibilidad es una pequea fase que propone DSDM para determinar si la metodologa se ajusta al proyecto en cuestin. Durante el estudio del negocio se involucra al cliente de forma temprana, para tratar de entender la operatoria que el sistema deber automatizar. Este estudio sienta las bases para iniciar el desarrollo, definiendo las Caractersticas de alto nivel que deber contener el software. Posteriormente, se inician las iteraciones durante las cuales: se bajar a detalle las caractersticas identificados anteriormente, se realizar el diseo de los mismos, se construirn los componentes de software, y se implantar el sistema en produccin previa aceptacin del cliente. Desde mediados de la dcada de 1990 hay abundantes estudios de casos, sobre todo en Gran Bretaa, y la adecuacin de DSDM para desarrollo rpido est suficientemente probada. El equipo mnimo de DSDM es de dos personas y puede llegar a seis, pero puede haber varios equipos en un proyecto. El mnimo de dos personas involucra que un equipo consiste de un programador y un usuario. El mximo de seis es el valor que se encuentra en la prctica. DSDM se ha aplicado a proyectos grandes y pequeos. La precondicin para su uso en sistemas grandes es su particin en componentes que pueden ser desarrollados por equipos normales. Figura N8. Fases del Proceso de Desarrollo de DSDM Se ha elaborado en particular la combinacin de DSDM con XP y se ha llamado a esta mixtura EnterpriseXP, trmino acuado por Mike Griffiths de Quadrus Developments . Se atribuye a Kent Beck haber afirmado que la comunidad de DSDM ha construido una imagen corporativa mejor que la del mundo XP y que sera conveniente aprender de esa experiencia. Tambin hay documentos conjuntos de DSDM y Rational, con participacin de Jennifer Stapleton, que demuestran la compatibilidad del modelo DSDM con RUP, a despecho de sus fuertes diferencias terminolgicas. Tambin hay casos de xito (particularmente el de Fujitsu European Repair Centre) en que se emplearon Visual Basic como lenguaje, SQL Server como base de datos y Windows como plataforma de desarrollo e implementacin.

Descontando la primera fase que es realizada una nica vez al principio del proyecto para analizar la factibilidad desde el punto de vista del negocio del desarrollo, las dems fases presentan las caractersticas del modelo iterativo e incremental ya tratado. Sin embargo, lo que diferencia a DSDM de dicho modelo son los principios alrededor de los cuales se estructura y que hacen nfasis en los equipos de desarrollo, en el feedback con el cliente, en las entregas frecuentes de productos. Para resolver la cuestin de la aplicabilidad de DSDM a un proyecto convendr responder las siguientes preguntas: Ser la funcionalidad razonablemente visible en la interface del usuario? Se pueden identificar todas las clases de usuarios finales? Es la aplicacin computacionalmente compleja? Es la aplicacin potencialmente grande? Si lo es, puede ser particionada en componentes funcionales ms pequeos? Est el proyecto realmente acotado en el tiempo? Son los requerimientos flexibles y slo especificados a un alto nivel? Las mismas refieren a las caractersticas que se deben cumplir en los proyectos para poder utilizar el enfoque RAD de construccin. Se observa que aquellos proyectos que califiquen afirmativamente de acuerdo a dichas preguntas tendrn las siguientes caractersticas que refieren a la aplicabilidad de DSDM: a. b. c. d. e. f. Son proyectos interactivos con la funcionalidad visible en la interfase de usuario De baja o media complejidad computacional Particionables en componentes de funcionalidad ms pequeos si la aplicacin es de gran tamao Acotados en el tiempo Con flexibilidad en los requerimientos Con un grupo de usuarios bien definidos y comprometidos al proyecto

De esta forma observamos que DSDM deja las bases sentadas para el anlisis sobre su aplicabilidad a un espectro bien definido de proyectos de software. Sin embargo, la metodologa no tiene ninguna prescripcin respecto a las tcnicas a ser usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma especfico funciona tanto para el modelo de orientacin a objetos como para el modelo estructurado. Algo que s sugiere el mtodo es la generacin de un conjunto mnimo de modelos necesarios para la sana progresin de la entrega del software y facilidad en el mantenimiento. Estos modelos esenciales debern ser definidos antes que comience el desarrollo, y debern ser revisados en las sucesivas iteraciones para validad su contenido. El concepto de timebox es algo que est embebido en DSDM y en todas las metodologas giles, en las cuales tambin se conocen como iteracin, ciclo, intervalo. La consecuencia de utilizarlos es el feedback (realimentacin) frecuente que brinda visibilidad a los stakeholders(Grupos de presin) para que verifiquen el progreso y puedan tomar acciones correctivas a tiempo. Tambin permiten controlar la calidad de los productos intermedios que se van generando, y realizar estimaciones de esfuerzo ms precisas. Asimismo, cada timebox esta compuesta por actividades definidas en relacin a entregables en vez de tareas. Cada entregable generado durante el mismo es testeado/revisado dentro del mismo timebox. En DSDM, un timebox consta de tres fases que son: Investigacin, Refinamiento y Consolidacin. Durante la Investigacin se chequean que las actividades que componen el timebox se condicen con la arquitectura del sistema. Esta es una fase de carcter exploratorio, en la que se fijan los objetivos de la iteracin, los

entregables a ser producidos, efectundose revisiones sobre las iteraciones anteriores a la actual. La siguiente fase, Refinamiento, consiste en la produccin propiamente dicha de los artefactos planificados. DSDM destaca la necesidad de colocar componentes de distinta prioridad en un mismo timebox, de manera de poder posponer a futuras iteraciones aquellos con menor prioridad, en caso que surjan imprevistos o se materialicen riesgos. Finalmente, la fase de Consolidacin consiste en completar los entregables, verificando la calidad de los mismos. En esta fase que posee el hito de finalizacin del timebox se demostrar que se satisficieron los requerimientos de calidad definidos durante la Investigacin. DSDM incluye roles claves en relacin al management(direccin) del proyecto. Identifica al visionario como el encargado de asegurar que se satisfacen las necesidades del negocio; el usuario embajador que equivaldra al on-site customer(Cliente) de XP, que brinda el conocimiento del negocio y define los requerimientos del software; el coordinador tcnico que es la persona encargada de mantener la arquitectura y verificar la consistencia de los componentes construidos respecto a esta y al cumplimiento de los estndares tcnicos. Algunas tcnicas sugeridas en DSDM son las sesiones JAD para capturar los requerimientos del software y la realizacin de prototipos para descifrar aquellas ambigedades que se presentan en el relevamiento y tambin para derribar las barreras comunicacionales entre analistas y usuarios. El enfoque propuesto consiste en la utilizacin de un prototipo evolutivo, el cual se va refinando hasta tenerse la aplicacin deseada. El nfasis queda en manifiesto en los prototipos que se sugieren para cada etapa: negocio, usabilidad, performance y capacidad, y diseo. En resumen, encontramos en DSDM una metodologa gil creada en el Reino Unido a partir de un consorcio con participacin de empresas de primera lnea. El mismo contiene las caractersticas principales de las metodologas giles y contiene prcticas tendientes al enfoque RAD. Algo que es importante de DSDM ha sido su aceptacin en la industria y su refinamiento continuo actualmente, se encuentra en su versin 4.0 lo que indica que las metodologas giles no son solo dominio de pequeos grupos de desarrollo sino que estn siendo adoptadas por pesos pesados en las industrias 2.2.3 METODOLOGA SCRUM Scrum define un proceso emprico, iterativo e incremental de desarrollo que intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptacin de la naturaleza catica del desarrollo de software, y la utilizacin de prcticas tendientes a manejar la impredictibilidad y el riesgo a niveles aceptables. El mismo surge en 1986 , de un artculo d e la Harvard Business Review titulado The New New Product evelopment Game de Hirotaka Takeuchi e Ikujiro Nonaka, que introduca las mejores prcticas ms utilizadas en 10 compaas japonesas altamente innovadoras. A partir de ah y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland formalizan el proceso conocido como Scrum en el ao 1995. Scrum es un mtodo iterativo e incremental que enfatiza prcticas y valores de Project management por sobre las dems disciplinas del desarrollo. Al principio del proyecto se define el Product Backlog, que contiene todos los requerimientos funcionales y no funcionales que deber satisfacer el sistema a construir. Los mismos estarn especificados de acuerdo a las convenciones de la organizacin ya sea mediante: features, casos de uso, diagramas de flujo de datos, incidentes, tareas, etc. El Product Backlog ser definido durante reuniones de planeamiento con los stakeholders. A partir de ah se definirn las iteraciones, conocidas como Sprint en la juerga de Scrum, en las que se ir evolucionando la aplicacin evolutivamente. Cada Sprint tendr

su propio Sprint Backlog que ser un subconjunto del Product Backlog con los requerimientos a ser construidos en el Sprint correspondiente. La duracin recomendada del Sprint es de un mes. Dentro de cada Sprint el Scrum Master (equivalente al Lder de Proyecto) llevar a cabo la gestin de la iteracin, convocando diariamente al Scrum Daily Meeting que representa una reunin de avance diaria de no ms de 15 minutos con el propsito de tener realimentacin sobre las tareas de los recursos y los obstculos que se presentan. Al final de cada Sprint, se realizar un Sprint Review para evaluar los artefactos construidos y comentar el planeamiento del prximo Sprint. Como se puede observar en la Figura N4 la metodologa resulta sencilla definiendo algunos roles y artefactos que contribuyen a tener un proceso que maximiza el feedback para mitigar cualquier riesgo que pueda presentarse. A. Scrum aplicado al Desarrollo de Software Aunque surgi como modelo para el desarrollo de productos tecnolgicos, tambin se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software. Jeff Sutherland aplic el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integrara en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo present junto con Ken Schwaber como proceso formal, tambin para gestin del desarrollo de software en OOPSLA 96. En el desarrollo de software Scrum est considerado como modelo gil por la Agile Alliance. La intencin de Scrum es la de maximizar la realimentacin sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se est extendiendo cada vez ms dentro de la comunidad de Metodologas giles, siendo combinado con otras como XP para completar sus carencias. Cabe mencionar que Scrum no propone el uso de ninguna prctica de desarrollo en particular; sin embargo, es habitual emplearlo como un framework gil de administracin de proyectos que puede ser combinado con cualquiera de las metodologas mencionadas. Figura N4. Descripcin de Roles, artefactos, reuniones y proceso de desarrollo de Scrum. B. Ciclo de Vida de Scrum. El ciclo de vida de Scrum es el siguiente: 1. Pre-Juego: Planeamiento. El propsito es establecer la visin, definir expectativas y asegurarse la financiacin. Las actividades son la escritura de la visin, el presupuesto, el registro de acumulacin o retraso (backlog) del producto inicial y los tems estimados, as como la arquitectura de alto nivel, el diseo exploratorio y los prototipos. El registro de acumulacin es de alto nivel de abstraccin. 2. 3. Pre-Juego: Montaje (Staging). El propsito es identificar ms requerimientos y priorizar las tareas Juego o Desarrollo. El propsito es implementar un sistema listo para entrega en una serie de para la primera iteracin. Las actividades son planificacin, diseo exploratorio y prototipos. iteraciones de treinta das llamadas corridas (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteracin, la definicin del registro de acumulacin de corridas y los estimados, y encuentros diarios de Scrum. 4. Pos-Juego: Liberacin. El propsito es el despliegue operacional. Las actividades, documentacin, entrenamiento, mercadeo y venta. Usualmente los registros de acumulacin se llevan en planillas de clculo comunes, antes que en una herramienta sofisticada de gestin de proyectos. Los elementos del registro pueden ser prestaciones del

software, funciones, correccin de bugs, mejoras requeridas y actualizaciones de tecnologa. Hay un registro total del producto y otro especfico para cada corrida de 30 das. En la jerga de Scrum se llaman paquetes a los objetos o componentes que necesitan cambiarse en la siguiente iteracin. Figura N5. Ciclo de Carrera o de Vida (Sprint) de Scrum

La lista de Acumulacin del Producto contiene todos los rasgos, tecnologa, mejoras y lista de bugs que, a medida que se desenvuelven, constituyen las futuras entregas del producto. Los rasgos ms urgentes merecern mayor detalle, los que pueden esperar se tratarn de manera ms sumaria. La lista se origina a partir de una variedad de fuentes. El grupo de mercadeo genera los rasgos y la funcin; la gente de ventas genera elementos que harn que el producto sea ms competitivo; los de ingeniera aportarn paquetes que lo harn ms robusto; el cliente ingresar debilidades o problemas que debern resolverse. El propietario de la administracin y el control del backlog en productos comerciales bien puede ser el product manager; para desarrollos in-house podra ser el project manager, o alguien designado por l. Se recomienda que una sola persona defina la prioridad de una tarea; si alguien tiene otra opinin, deber convencer al responsable. Se estima que priorizar adecuadamente una lista de producto puede resultar dificultosa al principio del desarrollo, pero deviene ms fcil con el correr del tiempo.

Al fin de cada iteracin de treinta das hay una demostracin a cargo del Scrum Master. Las presentaciones en PowerPoint estn prohibidas. En los encuentros diarios, las gallinas deben estar fuera del crculo. Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinar a obras de caridad. Es permitido usar artefactos de los mtodos a los que Scrum acompae, por ejemplo Listas de Riesgos si se utiliza UP, Planguage si el mtodo es Evo, o los Planes de Proyecto sugeridos en la disciplina de Gestin de Proyectos de Microsoft Solutions Framework. No es legal, en cambio, el uso de instrumentos tales como diagramas PERT, porque stos parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenar; en Scrum el supuesto dominante es que el desarrollo es semi-catico, cambiante y tiene demasiado ruido como para que se le aplique un proceso definido. Algunos textos sobre Scrum establece una arquitectura global en la fase de pre-juego; otros dicen que no hay una arquitectura global en Scrum, sino que la arquitectura y el diseo emanan de mltiples corridas. No hay una ingeniera del software prescripta para Scrum; cada quien puede escoger entonces las prcticas de automatizacin, inspeccin de cdigo, prueba unitaria, anlisis o programacin en pares que le resulten adecuadas. Como ya se ha mencionado antes, es muy habitual que Scrum se complemente con XP; en estos casos, Scrum suministra un marco de management basado en patrones organizacionales, mientras XP constituye la prctica de programacin, usualmente orientada a objetos y con fuerte uso de patrones de diseo. Uno de los nombres que se utiliza para esta alianza es XP@Scrum. Tambin son viables los hbridos con otras metodologas giles. 2.2.4. PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP) XP es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. Los principios y prcticas son de sentido comn pero llevadas al extremo, de ah proviene su nombre. Kent Beck, el padre de XP, describe la filosofa de XP en [2] sin cubrir los detalles tcnicos y de implantacin de las prcticas. Posteriormente, otras publicaciones de experiencias se han encargado de dicha tarea. A continuacin presentaremos las caractersticas esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prcticas. 1. Las Historias de Usuario Son la tcnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinmico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas [12]. Beck en su libro [2] presenta un ejemplo de ficha (customer story and task card) en la cual pueden reconocerse los siguientes contenidos: fecha, tipo de actividad (nueva, correccin, mejora), prueba funcional, nmero de historia, prioridad tcnica y del cliente, referencia a otra historia previa, riesgo, estimacin tcnica, descripcin, notas y una lista de seguimiento con la fecha, estado cosas por terminar y comentarios. A efectos

de planificacin, las historias pueden ser de una a tres semanas de tiempo de programacin (para no superar el tamao de una iteracin). Las historias de usuario son descompuestas en tareas de programacin (task card) y asignadas a los programadores para ser implementadas durante una iteracin. 2. Roles XP Los roles de acuerdo con la propuesta original de Beck son: Programador. El programador escribe las pruebas unitarias y produce el cdigo del sistema. a. Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio. b. pruebas. c. Encargado de seguimiento (Tracker). Proporciona realimentacin al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteracin. d. e. f. 3. Entrenador (Coach). Es responsable del proceso global. Debe proveer guas al equipo de forma que Consultor. Es un miembro externo del equipo con un conocimiento especfico en algn tema Gestor (Big boss). Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje Proceso XP El cliente define el valor de negocio a implementar. El programador estima el esfuerzo necesario para su implementacin. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo. El programador construye ese valor de negocio. Vuelve al paso 1. se apliquen las prcticas XP y se siga el proceso correctamente. necesario para el proyecto, en el que puedan surgir problemas. efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos [12]: 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

En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteracin. El ciclo de vida ideal de XP consiste de seis fases [2]: Exploracin, Planificacin de la Entrega (Release), iteraciones, Produccin, Mantenimiento y Muerte del Proyecto. 4. Prcticas XP La principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseo evolutivo funcione. Esto se consigue gracias a las tecnologas disponibles para ayudar en el desarrollo de software y a la aplicacin disciplinada de las siguientes prcticas.

El juego de la planificacin. Hay una comunicacin frecuente el cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin. Entregas pequeas . Producir rpidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versin ya constituye un resultado de valor para el negocio. Una entrega no debera tardar ms 3 meses. a. Metfora. El sistema es definido mediante una metfora o un conjunto de metforas compartidas por el cliente y el equipo de desarrollo. Una metfora es una historia compartida que describe cmo debera funcionar el sistema (conjunto de nombres que acten como vocabulario para hablar sobre el dominio del problema , ayudando a la nomenclatura de clases y mtodos del sistema). b. c. sistema. d. Refactorizacin (Refactoring). Es una actividad constante de reestructuracin del cdigo con el objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms flexible para facilitar los posteriores cambios. Se mejora la estructura interna del cdigo sin alterar su comportamiento externo [8]. e. Programacin en parejas . Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores. Esto conlleva ventajas implcitas (menor tasa de errores, mejor diseo, mayor satisfaccin de los programadores, .). f. g. h. Propiedad colectiva del cdigo. Cualquier programador puede cambiar cualquier parte del cdigo en Integracin continua. Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el 40 horas por semana. Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas cualquier momento. sistema puede llegar a ser integrado y construido varias veces en un mismo da. extras en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo. i. Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el equipo. ste es uno de los principales factores de xito del proyecto XP. El cliente conduce constantemente el trabajo hacia lo que aportar mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicacin oral es ms efectiva que la escrita. j. legible. El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y equilibrada puesto que se apoyan unas en otras. Esto se ilustra en la Figura 1 (obtenida de [2]), donde una lnea entre dos prcticas significa que las dos prcticas se refuerzan entre s. La mayora de las prcticas propuestas por XP no son novedosas sino que en alguna forma ya haban sido propuestas en ingeniera del software e incluso demostrado su valor en la prctica (ver [1] para un anlisis histrico de ideas y prcticas que sirven como antecedentes a las utilizadas Estndares de programacin. XP enfatiza que la comunicacin de los programadores es a travs del cdigo, con lo cual es indispensable que se sigan ciertos estndares de programacin para mantener el cdigo Diseo simple . Se debe disear la solucin ms simple que pueda funcionar y ser implementada en Pruebas . La produccin de cdigo est dirigida por las pruebas unitarias. stas son son establecidas un momento determinado del proyecto. por el cliente antes de escribirse el cdigo y son ejecutadas constantemente ante cada modificacin del

por las metodologas giles). El mrito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.

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

2.2.5. METODOLOGA CRYSTAL CLEAR Alistair Cockburn es el propulsor detrs de la serie de metodologas Crystal. Las mismas presentan un enfoque gil, con gran nfasis en la comunicacin, y con cierta tolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida por XP. Crystal Clear es la encarnacin ms gil de la serie y de la que ms documentacin se dispone. La misma se define con mucho nfasis en la comunicacin y de forma muy liviana en relacin a los entregables. Crystal maneja iteraciones cortas con feedback frecuente por parte de los usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios. Otra de las cuestiones planteadas es la necesidad de disponer de un usuario real aunque sea de forma part time para realizar validaciones sobre la Interfase del Usuario y para participar en la definicin de los requerimientos funcionales y no funcionales del software. Comparar el software con la ingeniera nos conduce a preguntarnos sobre especificaciones y modelos del software, sobre su completitud, correccin y vigencia. Esas preguntas son inconducentes, porque cuando pasa cierto tiempo no nos interesa que los modelos sean completos, que coincidan con el mundo real (sea ello lo que fuere) o que estn al da con la versin actual del lenguaje. Intentar que as sea es una prdida de tiempo [4]. En contra de esa visin ingenieril a la manera de un Bertrand Meyer, Cockburn ha alternado diversas visiones despreocupadamente contradictorias que alternativamente lo condujeron a adoptar XP en el sentido

ms radical, a sinergizarse con DSDM o LSD, a concebir el desarrollo de software como una forma comunitaria de poesa o a elaborar su propia familia de Metodologas Crystal. La familia Crystal dispone un cdigo de color para marcar la complejidad de una metodologa: cuanto ms oscuro un color, ms pesado es el mtodo. Cuanto ms crtico es un sistema, ms rigor se requiere. El cdigo cromtico se aplica a una forma tabular elaborada por Cockburn que se usa en muchas metodologas giles para situar el rango de complejidad al cual se aplica una metodologa. En la (Figura N6) se muestra una evaluacin de las prdidas que puede ocasionar la falla de un sistema y el mtodo requerido segn este criterio. Los parmetros son Comodidad (C), Dinero Discrecional (D), Dinero Esencial (E) y Vidas (L). En otras palabras, la cada de un sistema que ocasione incomodidades indica que su nivel de criticalidad es C, mientras que si causa prdidas de vidas su nivel es L. Los nmeros del cuadro indican el nmero de personas afectadas a un proyecto. Figura N6. Familia de Crystal Methods

Los mtodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versin del proceso, y todas se sitan en torno a un ncleo idntico. Hay cuatro variantes de metodologas: Crystal Clear (Claro como el cristal) para equipos de 8 o menos integrantes; Amarillo, para 8 a 20; Naranja, para 20 a 50; Rojo, para 50 a 100. Se promete seguir con Marrn, Azul y Violeta. La ms exhaustivamente documentada es

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

En lugar de esta interpretacin lineal, Cristal Clear enfatiza el proceso como un conjunto de ciclos anidados. En la mayora de los proyectos se perciben siete ciclos: 1. 2. 3. entrega), 4. 5. 6. 7. la semana laboral, el perodo de integracin, de 30 minutos a tres das, el da de trabajo, el episodio de desarrollo de una seccin de cdigo, de pocos minutos a pocas horas. el proyecto, el ciclo de entrega de una unidad, la iteracin (ntese que CC requiere mltiples entregas por proyecto pero no muchas iteraciones por

Los mtodos Crystal no prescriben las prcticas de desarrollo, las herramientas o los productos que pueden usarse, pudiendo combinarse con otros mtodos como Scrum, XP y Microsoft Solutions Framework. 2.3 UML: 2.3.1. Introduccin al UML UML surge como respuesta al problema de contar con un lenguaje estndar para escribir planos de software. Muchas personas han credo ver UML como solucin para todos los problemas sin saber en muchos casos de

lo que se trataba en realidad. El Lenguaje Unificado de Modelado, UML es una notacin estndar para el modelado de sistemas software, resultado de una propuesta de estandarizacin promovida por el consorcio OMG (Object Management Group), del cual forman parte las empresas ms importantes que se dedican al desarrollo de software, en 1996. UML representa la unificacin de las notaciones de los mtodos Booch, Objectory (Ivar Jacobson) y OMT (James Rumbaugh) siendo su sucesor directo y compatible. Igualmente, UML incorpora ideas de otros metodlogos entre los que se pueden incluir a Peter Coad, Derek Coleman, Ward Cunningham, David Harel, Richard Helm, Ralph Johnson, Stephen Mellor, Bertrand Meyer, Jim Odell, Kenny Rubin, Sally Shlaer, John Vlissides, Paul Ward, Rebecca Wirfs- Brock y Ed Yourdon. En Septiembre de 2001 se ha publicada la especificacin de la versin 1.4. Es importante recalcar que slo se trata de una notacin, es decir, de una serie de reglas y recomendaciones para representar modelos. UML no es un proceso de desarrollo, es decir, no describe los pasos sistemticos a seguir para desarrollar software. UML slo permite documentar y especificar los elementos creados mediante un lenguaje comn describiendo modelos. En la figura 12 se puede observar el desarrollo de UML y sus versiones en los aos dados, sufriendo revisiones menores, y ciertos participantes en las diversas versiones.

2.3.2 Descripcin del lenguaje

UML es un lenguaje de propsito general para el modelado orientado a objetos, que combina notaciones provenientes desde: Modelado Orientado a Objetos, Modelado de Datos, Modelado de Componentes, Modelado de Flujos de Trabajo (Workflows). En todos los mbitos de la ingeniera se construyen modelos, en realidad, simplificaciones de la realidad, para comprender mejor el sistema que vamos a desarrollar: los arquitectos utilizan y construyen planos (modelos) de los edificios, los grandes diseadores de coches preparan modelos en sistemas existentes con todos los detalles y los ingenieros de software deberan igualmente construir modelos de los sistemas software. Un enfoque sistemtico permite construir estos modelos de una forma consistente demostrando su utilidad en sistemas de cierto tamao. Cuando se trata de un programa de cincuenta, cien lneas, la utilidad del modelado parece discutible pero cuando involucramos a cientos de desarrolladores trabajando y compartiendo informacin, el uso de modelos y el proporcionar informacin sobre las decisiones tomadas, es vital no slo durante el desarrollo del proyecto, sino una vez finalizado ste, cuando se requiere algn cambio en el sistema. En realidad, incluso en el proyecto ms simple los desarrolladores hacen algo de modelado, si bien informalmente. Para la construccin de modelos, hay que centrarse en los detalles relevantes mientras se ignoran los dems, por lo cual con un nico modelo no tenemos bastante. 2.3.3 Inconvenientes en UML Como todo en el desarrollo de software UML presenta ciertos inconvenientes, entre los cuales se pueden mencionar: Falta integracin con respecto de otras tcnicas tales como patrones de diseo, interfaces de usuario, documentacin, etc., los ejemplos aislados, el monopolio de conceptos, tcnicas y mtodos en torno a UML. 2.3.4 Perspectivas de UML Tambin se prev varias perspectivas de UML ya que por ser un lenguaje de propsito general ser un lenguaje de modelado orientado a objetos estndar predominante los prximos aos, esto se basa en las siguientes razones: Participacin de metodlogos influyentes Participacin de importantes empresas Aceptacin del OMG como notacin estndar

Tambin se muestran las siguientes evidencias que apoyan lo antes dicho: Herramientas que proveen la notacin UML Edicin de libros Congresos, cursos, camisetas, etc. 2.3.5 Descripcin de los diagramas Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. Un diagrama es una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de inters. Es aqu donde se hace evidente la importancia de UML en el contexto de un proceso de desarrollo de software. El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable). Sin embargo, se requieren otros modelos. 2.3.6 Relaciones de enlaces entre modelos

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

2.3.7 Diagramas, partes de un modelo 1. 2. 3. a. b. c. Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupndola en descripciones de Diagrama de Clases: muestra las clases (descripciones de objetos que comparten caractersticas Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus relaciones. Diagramas de Comportamiento: dentro de estos diagramas se encuentran: Diagrama de Estados: modela el comportamiento del sistema de acuerdo con eventos. Diagrama de Actividades: simplifica el Diagrama de Estados modelando el comportamiento acciones ejecutadas por un sistema para obtener un resultado. comunes) que componen el sistema y cmo se relacionan entre s.

mediante flujos de actividades. Tambin se pueden utilizar caminos verticales para mostrar los responsables de cada actividad. d. Diagramas de Interaccin: Estos diagramas a su vez se dividen en 2 tipos de diagramas, segn la interaccin que enfatizan: + Diagrama de Secuencia: enfatiza la interaccin entre los objetos y los mensajes que intercambian entre s junto con el orden temporal de los mismos.

+ Diagrama de Colaboracin: igualmente, muestra la interaccin entre los objetos resaltando la organizacin estructural de los objetos en lugar del orden de los mensajes intercambiados. 4. a. b. Diagramas de implementacin Diagrama de Componentes: muestra la organizacin y las dependencias entre un conjunto de Diagrama de Despliegue: muestra los dispositivos que se encuentran en un sistema y su distribucin

componentes. en el mismo. 2.3.8 Metodologa del RUP para anlisis y diseo El RUP propone la utilizacin de los modelos para la implementacin completa de todas sus fases respectivamente con sus disciplinas: 1. 2. 3. Modelo de Casos de Uso del Negocio: Describe la realizacin del Caso de Uso, es realizado en la Modelo de Objetos del Negocio: Se utiliza para identificar roles dentro de la organizacin, es Modelo de Casos de Uso: Muestra las interrelaciones entre el sistema y su ambiente, adems sirve disciplina de Modelado del Negocio. realizado en la disciplina de Modelado del Negocio. como un contrato entre el cliente y los diseadores. Es considerado esencial al iniciar las actividades de anlisis, diseo y prueba; este modelo es realizado en la disciplina de Requerimientos. 4. 5. Modelo de Anlisis: Contiene los resultados del anlisis del Caso de Uso, y contienen instancias del Modelo de Diseo: Es un modelo de objetos que describe la realizacin del Caso de Uso, y sirve artefacto de Anlisis de Clases; es realizado en la disciplina de Anlisis y Diseo. como una abstraccin del modelo de implementacin y su cdigo fuente, es utilizado como entrada en las actividades de implementacin y prueba; este modelo se realizado en la disciplina de Anlisis y Diseo. 6. Modelo de Despliegue: Muestra la configuracin de los nodos del proceso en tiempo de ejecucin, muestra los lazos de comunicacin entre estos nodos, as como las de los objetos y componentes que en el se encuentran; se realizado en la disciplina de Anlisis y Diseo. 7. Modelo de Datos: Es un subconjunto del modelo de implementacin que describe la representacin lgica y fsica de datos persistentes en el sistema. Tambin incluye cualquier conducta definida en la base de datos como disparadores, restricciones, etc. Es elaborado en la disciplina de Anlisis y Diseo. 8. Modelo de Implementacin: Es una coleccin de componentes, y de subsistemas de aplicacin que contienen estos componentes, entre estos estn los entregables, ejecutables, archivos de cdigo fuente. Es realizado en la disciplina de Implementacin. 9. Pruebas. Estos modelos representan los diagramas que propone el UML para el desarrollo de modelado de un proyecto de software, con los cuales se puede representar los propuesto por UML mediante la metodologa RUP utilizando las herramientas que esta provee para la implementacin fcil, clara y estructurada de los diagramas utilizados. 2.3.9 Descripcin de estereotipos Para poder entender la interrelacin que tiene UML con RUP se tiene que saber que el inicio de todo est con los casos de uso, para poder tener una base sobre lo cual se quiere trabajar, los casos de uso son la base para esta tcnica; luego se procede a la obtencin de los diagramas expuestos anteriormente, dependiendo de Modelo de Pruebas: Es utilizado para la elaboracin de las pruebas, y se realiza en la disciplina de

cules son los necesarios de implementar, luego se procede a la identificacin de los estereotipos, ya que cada uno de estos representan las funciones que se van a definir dentro de los diagramas, estos diagramas nos ayudan a entender la lgica del caso de uso expuesto. Las clases, al igual que los dems elementos notacionales del UML, pueden estar clasificadas de acuerdo a varios criterios, como por ejemplo su objetivo dentro de un programa. Esta clasificacin adicional se puede expresar mediante la utilizacin de estereotipos.

Los estereotipos ms comunes utilizados para clasificar las clases son: Entidad (entity), Frontera (boundary), Control (control). Se proponen varias pautas a seguir a la hora de encontrar las clases de nuestro sistema durante la fase de anlisis. Dichas pautas se centran en la bsqueda de los estereotipos entidad, control y frontera: Una clase entidad modela la informacin de larga vida y su comportamiento asociado. Este tipo de clase suele reflejar entidades del mundo real o elementos necesarios para realizar tareas internas al sistema. Tambin se denominan clase dominio, ya que suelen tratar con abstracciones de entidades del mundo real. Una clase frontera maneja comunicaciones entre el entorno del sistema y el sistema, suelen proporcionar la interfaz del sistema con un usuario o con otro sistema, en general, por tanto, modelan las

interfaces del sistema. Cuando se trata de clases que definen la interfaz con otro sistema se refinarn durante la fase de diseo, para tener en cuenta los protocolos de comunicacin elegidos. Una clase control modela el comportamiento secuenciado especfico de uno o varios casos de uso. Se trata de clases que coordinan los eventos necesarios para llevar a cabo el comportamiento que se especifica en el caso de uso, representan su dinmica. El Nuevo Enfoque del UML 2.0 En las versiones previas del UML, se haca un fuerte hincapi en que UML no era un lenguaje de programacin. Un modelo creado mediante UML no poda ejecutarse. En el UML 2.0, esta asuncin cambi de manera drstica y se modific el lenguaje, de manera tal que permitiera capturar mucho ms comportamiento (Behavior). De esta forma, se permiti la creacin de herramientas que soporten la automatizacin y generacin de cdigo ejecutable, a partir de modelos UML. Estndares que conforman el UML Superestructura: Es la especificacin que usamos todos los das. Aqu se encuentran todos los Infraestructura: Conceptos de bajo nivel. Meta-Modelo da soporte a la superestructura, entre otras. OCL: Lenguaje de restriccin. De utilidad para especificar conceptos ambiguos sobre los distintos XMI / Intercambio de diagramas: Permite compartir diagramas entre diferentes herramientas de diagramas que la mayora de los desarrolladores conocen.

elementos del diagrama. modelado UML. Reestructuracin del Lenguaje Para lograr los objetivos enunciados, varios aspectos del lenguaje fueron reestructurados y/o modificados. La especificacin se separ en cuatro especificaciones (paquetes) bien definidas, tal como se muestra en la Figura 1. Es interesante destacar que el UML 2.0 puede definirse a s mismo. Es decir, su estructura y organizacin es modelable utilizando el propio UML 2.0; de esta manera, se da un ejemplo de utilizacin del UML en un dominio distinto al del desarrollo de software. En este caso, cada paquete del diagrama representa cada una de las cuatro especificaciones que componen el lenguaje.

Figura 1: Especificaciones principales del UML 2.0 Veamos a continuacin, un poco ms en detalle cada una de las principales especificaciones que componen UML 2.0. No nos explayaremos demasiado, debido a que en futuras ediciones habr oportunidad de profundizar en cada una de ellas. OCL OCL son siglas en ingls que significan: Object Constraint Language y que en castellano se traducen como: Lenguaje de Restricciones de Objetos. El OCL define un lenguaje simple, para escribir restricciones y expresiones sobre elementos de un modelo. El OCL suele ser til cuando se est especificando un dominio particular mediante el UML y es necesario restringir los valores permitidos para los objetos del dominio. El OCL brinda la posibilidad definir en los elementos de un diagrama, entre otros: invariantes, precondiciones, poscondiciones y restricciones. El OCL fue incorporado al UML en la versin 1.1. El OCL fue originalmente especificado por IBM y es un ejemplo ms de las muchas herramientas agregadas al UML. Especificacin para el Intercambio de Diagramas La especificacin para el intercambio de diagramas fue escrita para facilitar una manera de compartir modelos, realizados mediante UML, entre diferentes herramientas de modelado. En versiones anteriores del UML, se utilizaba un Schema XML para capturar los elementos utilizados en el diagrama; pero este Schema

no deca nada acerca de la manera en que el modelo deba graficarse. Para solucionar este problema, la nueva especificacin para el intercambio de diagramas fue desarrollada utilizando un nuevo Schema XML, que permite construir una representacin SVG (Scalable Vector Graphics). Esta especificacin es denominada con las siglas XMI, que en ingls significa: XML Metadata Interchange; y en castellano se traduce como: XML de Intercambio de Metadata (datos que representan datos). Tpicamente esta especificacin es solamente utilizada por quienes desarrollan herramientas de modelado UML. Infraestructura En la Infraestructura del UML se definen los conceptos centrales y de ms bajo nivel. La Infraestructura es un meta-modelo (un modelo de modelos) y mediante la misma se modela el resto del UML. Generalmente, la infraestructura no es utilizada por usuarios finales del UML; pero provee la piedra fundamental sobre la cual la Superestructura es definida. Esta ltima s es la utilizada por el comn de los usuarios. La Infraestructura brinda tambin varios mecanismos de extensin, que hacen del UML un lenguaje configurable. Para los usuarios normales del UML basta con saber si la infraestructura existe y cules son sus objetivos. Superestructura La superestructura del UML es la definicin formal de los elementos del UML. Esta definicin sola contiene ms de 640 pginas. La superestructura es tpicamente utilizada por los desarrolladores de aplicacin. Es aquella sobre la que hablan los libros y la que la mayora conoce de versiones anteriores del UML. La Superestructura del UML Es en la Superestructura donde encontramos los cambios que ms afectan en el da a da a quienes trabajan como desarrolladores de aplicaciones de negocios, es decir, profesionales que, en general, deben interpretar o crear modelos que especifiquen el dominio de tales aplicaciones. Es aqu dnde se definen los diagramas y los elementos que los componen. La Superestructura se encuentra dividida en niveles. Estos niveles se conocen como: Bsico (L1): Contiene los elementos bsicos del UML 2.0, entre ellos: Diagramas de clases, Intermedio (L2): Contiene los siguientes diagramas: Diagramas de estado, Perfiles, Diagramas de Completo (L3): Representa la especificacin del UML 2.0 completa, como por ejemplo: las Diagramas de actividades, Diagramas de Interacciones, y Diagramas de Casos de Uso Componentes y Diagramas de despliegue. Acciones, Caractersticas avanzadas y PowerTypes? entre otros. Es importante destacar que basta con que una herramienta implemente el nivel de conformidad Bsico (L1), para que se considere UML 2.0 compatible. Por eso, es normal ver una disparidad de caractersticas (features) bastante amplia entre dos herramientas distintas, aunque stas sean UML 2.0 compatibles.

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

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

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

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

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

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

En los diagramas de secuencia se pueden encontrar diferencias leves, como se puede mostrar en la figura 21 los diagramas de secuencia de UML no llevan los smbolos que identifican los estereotipos interfase (crculo con una raya horizontal del lado izquierdo y junto a esta otra vertical), control (crculo con una flecha sobre su borde apuntando al lado izquierdo) y entidad (crculo con una raya horizontal en la parte inferior del mismo), representados por crculos con caractersticas independientes. Los diagramas de colaboracin se representan similares, con la nica diferencia de los bloques que representan las clases, ya que en el RUP se representan por medio de los crculos con sus caractersticas individuales de acorde a la funcin que desempean (interfaz, control, entidad), y en UML solamente como rectngulos. En ambos se colocan las actividades que conllevan realizar para llegar a una clase determinada, esto se coloca directamente en la flecha dibujada en la lnea que va hacia la clase. Esto se puede observar en la figura 22. Dentro de los diagramas de implementacin se encuentran los de componentes (figura 23), los cuales se representan de manera similar en ambos lenguajes, como se muestra en la figura siguiente. La diferencia bsica en los diagramas de despliegue (figura 24) es que en UML se dibujan dentro de las cajas los componentes utilizados, en cambio en el RUP se diagraman de forma separada como se muestran en las figuras siguientes. En los diagramas presentados anteriormente, la similitud entre ambos lenguajes es demasiado grande, ya que RUP utiliza los del UML y por lo tanto recopila todo lo que este lenguaje necesita para la implementacin, y agrega mejoras, siendo una herramienta de modelado muy eficiente. Por lo tanto la funcionalidad completa de UML esta descrita e implementada por el RUP.

2.4 LENGUAJES DE PROGRAMACIN Un lenguaje de programacin es un lenguaje que puede ser utilizado para controlar el comportamiento de una mquina, particularmente una computadora. Consiste en un conjunto de reglas sintcticas y semnticas que definen su estructura y el significado de sus elementos, respectivamente. 2.4.1. JAVA ECLIPSE Eclipse es un entorno de desarrollo integrado de cdigo abierto multiplataforma para desarrollar lo que el proyecto llama Aplicaciones de Cliente Enriquecido, opuesto a las aplicaciones Cliente-liviano basadas en navegadores. Esta plataforma, tpicamente ha sido usada para desarrollar entornos de desarrollo integrados (del ingls IDE), como el IDE de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega como parte de Eclipse (y que son usados tambin para desarrollar el mismo Eclipse). Sin embargo, tambin se puede usar para otros tipos de aplicaciones cliente, como BitTorrent o Azureus.

Eclipse es tambin una comunidad de usuarios, extendiendo constantemente las reas de aplicacin cubiertas. Un ejemplo es el recientemente creado Eclipse Modeling Project, cubriendo casi todas las reas de Model Driven Engineering. Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundacin Eclipse, una organizacin independiente sin nimo

de lucro que fomenta una comunidad de cdigo abierto y un conjunto de productos complementarios, capacidades y servicios. Eclipse fue liberado originalmente bajo la Common Public License, pero despus fue re-licenciado bajo la Eclipse Public License. La Free Software Foundation ha dicho que ambas licencias son licencias de software libre, pero son incompatibles con Licencia pblica general de GNU (GNU GPL).[3] 1. ARQUITECTURA La base para Eclipse es la Plataforma de cliente enriquecido (del Ingls Rich Client Platform RCP). Los siguientes componentes constituyen la plataforma de cliente enriquecido: Plataforma principal inicio de Eclipse, ejecucin de plugins OSGi una plataforma para bundling estndar. El Standard Widget Toolkit (SWT) Un widget toolkit portable. JFace manejo de archivos, manejo de texto, editores de texto El Workbench de Eclipse vistas, editores, perspectivas, asistentes. Los widgets de Eclipse estn implementados por una herramienta de widget para Java llamada SWT, a diferencia de la mayora de las aplicaciones Java, que usan las opciones estndar Abstract Window Toolkit (AWT) o Swing. La interfaz de usuario de Eclipse tambin tiene una capa GUI intermedia llamada JFace, la cual simplifica la construccin de aplicaciones basadas en SWT. El entorno de desarrollo integrado (IDE) de Eclipse emplea mdulos (en ingls plug-in) para proporcionar toda su funcionalidad al frente de la plataforma de cliente enriquecido, a diferencia de otros entornos monolticos donde las funcionalidades estn todas incluidas, las necesite el usuario o no. Este mecanismo de mdulos es una plataforma ligera para componentes de software. Adicionalmente a permitirle a Eclipse extenderse usando otros lenguajes de programacin como son C/C++ y Python, permite a Eclipse trabajar con lenguajes para procesado de texto como LaTeX, aplicaciones en red como Telnet y Sistema de gestin de base de datos. La arquitectura plugin permite escribir cualquier extensin deseada en el ambiente, como sera Gestin de la configuracin. Se provee soporte para Java y CVS en el SDK de Eclipse. Y no tiene por qu ser usado nicamente para soportar otros lenguajes de programacin. La definicin que da el proyecto Eclipse acerca de su software es: una especie de herramienta universal un IDE abierto y extensible para todo y nada en particular. En cuanto a las aplicaciones clientes, eclipse provee al programador con frameworks muy ricos para el desarrollo de aplicaciones grficas, definicin y manipulacin de modelos de software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing Framework Framework para la edicin grfica) es un plugin de Eclipse para el desarrollo de editores visuales que pueden ir desde procesadores de texto wysiwyg hasta editores de diagramas UML, interfaces grficas para el usuario (GUI), etc. Dado que los editores realizados con GEF viven dentro de Eclipse, adems de poder ser usados conjuntamente con otros plugins, hacen uso de su interfaz grfica personalizable y profesional. El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo un IDE con un compilador de Java interno y un modelo completo de los archivos fuente de Java. Esto permite tcnicas avanzadas de refactorizacin y anlisis de cdigo. Mediante diversos plugins estas herramientas estn tambin disponibles para otros lenguajes como C/C++ (Eclipse CDT) y en la medida de lo posible para lenguajes de script no tipados como PHP o Javascript. El IDE tambin hace uso de un espacio de trabajo, en este caso un grupo de metadata en un espacio para archivos plano, permitiendo 2. CARACTERSTICAS

Eclipse dispone de un Editor de texto con resaltado de sintaxis. La compilacin es en tiempo real. Tiene pruebas unitarias con JUnit, control de versiones con CVS, integracin con Ant, asistentes (wizards) para creacin de proyectos, clases, tests, etc., y refactorizacin. Asimismo, a travs de plugins libremente disponibles es posible aadir control de versiones con Subversion.[4] e integracin con Hibernate.[5] 3. HISTORIA Eclipse comenz como un proyecto de IBM Canad. Fue desarrollado por OTI (Object Technology International) como reemplazo de VisualAge tambin desarrollado por OTI. En noviembre del 2001, se form un consorcio para el desarrollo futuro de Eclipse como cdigo abierto. En 2003, fue creada la fundacin independiente de IBM. Resumen de las versiones de Eclipse: 4. RADIOGRAFA Los datos y cifras relacionados con Eclipse, mostrados a continuacin, permitirn profundizar un poco ms en el producto.

Como puede verse en la tabla siguiente, la versin 3.2.1 posee ms de 2 millones de lneas de cdigo (para el proyecto Eclipse). Estos datos son de acuerdo a SLOCCount.[6] Utilizando esta cifra y aplicando el modelo

COCOMO, podemos ver que requerira un esfuerzo para producir un software de este tamao de 604 personaao (para ello se ha utilizado la frmula 2.4*(KSLOC ** 1.05)). Para tener un estimado de los costes se toma en consideracin el salario de 56.286 $/ao, que es el salario promedio de un programador en los Estados Unidos, y luego se multiplica ese resultado por 2,40, que incluye cualquier gasto extra diferente de los programadores como pueden ser luz, telfono, papelera, etc. Un punto muy importante a notar son los diversos lenguajes de programacin utilizados en el desarrollo del proyecto. De acuerdo al anlisis realizado usando SLOCCount, el lenguaje ms utilizado es Java, seguido de ANSI C. 2.4.2. VISUAL BASIC Introduccin. Visual Basic es uno de los tantos lenguajes de programacin que podemos encontrar hoy en da. Dicho lenguaje nace del BASIC (Beginners All-purpose Symbolic Instruction Code) que fue creado en su versin original en el Dartmouth College, con el propsito de servir a aquellas personas que estaban interesadas en iniciarse en algn lenguaje de programacin. Luego de sufrir varias modificaciones, en el ao 1978 se estableci el BASIC estndar. La sencillez del lenguaje gan el desprecio de los programadores avanzados por considerarlo un lenguaje para principiantes. Primero fue GW-BASIC, luego se transform en QuickBASIC y actualmente se lo conoce como Visual Basic y la versin ms reciente es la 6 que se incluye en el paquete Visual Studio 6 de Microsoft. Esta versin combina la sencillez del BASIC con un poderoso lenguaje de programacin Visual que juntos permiten desarrollar robustos programas de 32 bits para Windows. Esta fusin de sencillez y la esttica permiti ampliar mucho ms el monopolio de Microsoft, ya que el lenguaje slo es compatible con Windows, un sistema operativo de la misma empresa. Visual Basic ya no es ms un lenguaje para principiantes sino que es una perfecta alternativa para los programadores de cualquier nivel que deseen desarrollar aplicaciones compatibles con Windows. En este informe explicaremos algunos trminos y/o caractersticas de mismo con la finalidad de aprender mas sobre este Programa y manejarlo con facilidad Es un lenguaje de programacin que se ha diseado para facilitar el desarrollo de aplicaciones en un entorno grafico (GUI-GRAPHICAL USER INTERFACE) Como Windows 98, Windows NT o superior. 1. Qu es Visual Basic? Diseador de entorno de datos: Es posible generar, de manera automtica, conectividad entre controles y datos mediante la accin de arrastrar y colocar sobre formularios o informes. Los Objetos Actives son una nueva tecnologa de acceso a datos mediante la accin de arrastrar y colocar sobre formularios o informes. Asistente para formularios: Sirve para generar de manera automtica formularios que administran registros de tablas o consultas pertenecientes a una base de datos, hoja de calculo u objeto (ADO-ACTIVE DATA OBJECT) Asistente para barras de herramientas es factible incluir barras de herramientas es factible incluir barra de herramientas personalizada, donde el usuario selecciona los botones que desea visualizar durante la ejecucin. En las aplicaciones HTML: Se combinan instrucciones de Visual Basic con cdigo HTML para controlar los eventos que se realizan con frecuencia en una pagina web.

La Ventana de Vista de datos proporciona acceso a la estructura de una base de datos. Desde esta tambin acceso al Diseador de Consultas y diseador de Base de datos para administrar y registros. 2. Caractersticas de Visual Basic. Barra de titulo: muestra el nombre del proyecto y del formulario q se est diseando actualmente Barra de mens: agrupa los mens despegables que contienes todas las operaciones que pueden llevarse a cabo con Visual Basic 6.0. Barra de herramientas estndar: contienen los botones que se utilizan con mayor frecuencia cuando se trabaja con un proyecto. Simplifica la eleccin de opciones de los mens Archivo, Edicin, Ver y Ejecutar; adems, en el rea derecha presenta la ubicacin (coordenadas) y el tamao del objeto seleccionado Ventana de formulario: es el rea donde se disea la interfaz grfica, es decir, es donde se inserta electo grficos, como botones, imgenes, casilla de verificacin, cuadros de listas, etc. Cuadro de herramientas: presenta todos los controles necesarios para disear una aplicacin, como cuadros de texto, etiquetas, cuadros de listas, botones de comandos, etc. Ventana de proyecto: muestra los elementos involucrados en el proyecto, como formularios, mdulos, controles oxc, etc. Cada elemento puede seleccionarse en forma independiente para su edicin. Ventana de posicin del formulario: muestra la ubicacin que tendr el formulario en la pantalla, cuando ejecute la aplicacin. Esta ubicacin puede cambiarse si se hace clic con el botn izquierdo del mouse. La Ventana propiedades muestra todas las propiedades del control actualmente seleccionado, en este caso muestra las propiedades del Form1, luego podemos ver que abajo dice Form1 Form, lo que est en negrita es el nombre del objeto, y lo que le sigue es el tipo de objeto, en este caso es un Formulario (Form) Mediante este control podremos realizar tanto la entrada como la salida de datos en nuestras aplicaciones. No hace falta que indiquemos las coordenadas de la situacin del formulario en pantalla, simplemente tendremos que marcar sobre el control de la caja de herramientas y dibujarlo con el tamao que queramos en nuestro formulario Label. Este control es tambin uno de los ms utilizados, aunque su utilidad queda restringida a la visualizacin de datos en el mismo, no permitiendo la introduccin de datos por parte del usuario. CommandButton Este control es el tpico botn que aparece en todas las aplicaciones y que al hacer click sobre l nos permite realizar alguna operacin concreta, normalmente Aceptar o Cancelar. Aunque segn el cdigo que le asociemos podremos realizar las operaciones que queramos. OptionButton Este control nos permite elegir una opcin entre varias de las que se nos plantean. Cada opcin ser un control optionbutton diferente. Bloquear los Controles Cuando estn situados los controles en el formulario se pueden bloquear para que no puedan moverse de forma accidental. Para esto deberemos pulsar en la barra de herramientas: Cuando actives este botn y mientras no desbloquees los controles utilizando la misma opcin no se podrn mover ninguno de los controles del formulario activo.

Sin embargo en si abres otro formulario que no tenga los controles bloqueados si se podrn mover. Si aades ms controles a un formulario bloqueado estos quedan bloqueados automticamente Tiene la siguiente forma: Un control Frame proporciona un agrupamiento identificable para controles. Tambin puede utilizar un Frame para subdividir un formulario funcionalmente por ejemplo, para separar grupos de controles OptionButton. CHECK BUTTON Y OPTION BUTTON (BOTONES DE ELECCION Y OPCION) Se obtienen directamente de la caja de herramientas. Dada la similitud de ambos controles, se comentan conjuntamente. El control CheckBox, o casilla de verificacin, permite elegir una opcin (activada / desactivada, True/False) que el usuario puede establecer o anular haciendo click. Una X en una casilla de verificacin indica que est seleccionada, activada, o con valor True. Cada casilla de verificacin es independiente de las dems que puedan existir en el formulario, pudiendo tomar cada una de ellas el valor True o False, a voluntad del operador. Un control OptionButton muestra una opcin que se puede activar o desactivar, pero con dependencia del estado de otros controles OptionButton que existan en el formulario. Generalmente, los controles OptionButton se utilizan en un grupo de opciones para mostrar opciones de las cuales el usuario slo puede seleccionar una. Los controles OptionButton se agrupan dibujndolos dentro de un contenedor como un control Frame, un control PictureBox o un formulario. Para agrupar controles OptionButton en un Frame o PictureBox, dibuje en primer lugar el Frame o PictureBox y, a continuacin, dibuje dentro los controles OptionButton. Todos los controles OptionButton que estn dentro del mismo contenedor actan como un solo grupo, e independientes de los controles OptionButton de otros grupos distintos. Aunque puede parecer que los controles OptionButton y CheckBox funcionan de forma similar, hay una diferencia importante: Cuando un usuario selecciona un OptionButton, los otros controles del mismo grupo OptionButton dejan de estas disponibles automticamente. Por contraste, se puede seleccionar cualquier nmero de controles CheckBox. LIST BOX Y COMBO BOX Estos dos controles, debido a su similitud, se estudian conjuntamente. Se obtienen directamente de la caja de herramientas: Un control ListBox muestra una lista de elementos en la que el usuario puede seleccionar uno o ms. Si el nmero de elementos supera el nmero que puede mostrarse, se agregar automticamente una barra de desplazamiento al control ListBox. Un control ComboBox combina las caractersticas de un control TextBox y un control ListBox. Los usuarios pueden introducir informacin en la parte del cuadro de texto y seleccionar un elemento en la parte de cuadro de lista del control. En resumen, un ComboBox es la combinacin de un ListBox, que se comporta como si de un ListBox se tratase, y de un TextBox, con comportamiento anlogo a un TextBox sencillo, con la particularidad aqu de que el texto se le puede introducir por teclado, o elegir uno de los que figuran en la parte ListBox del Combo. CONTROLES HScrollBar y VScrollBar

Son dos controles similares, para introducir un dato cuasi-analgico en una aplicacin. Se toman directamente de la caja de herramientas, y tienen un aspecto parecido al de un control de volumen de un equipo de msica. El HScrollBar est en posicin horizontal, y el VScrollBar en posicin vertical. Mediante estos controles se pueden introducir datos variando la posicin del cursor. TIMER TEMPORIZADOR Este objeto permite establecer temporizaciones. Presenta una novedad respecto a los controles estudiados hasta ahora. El control Timer solamente se ve durante el tiempo de diseo. En tiempo de ejecucin, el control permanece invisible. La temporizacin producida por el Timer es independiente de la velocidad de trabajo del ordenador. (Casi independiente. El timer no es un reloj exacto, pero se le parece) Se toma directamente de la caja de herramientas, y tiene el aspecto siguiente: SHAPE Se toma directamente de la caja de herramientas: Shape es un control grfico que se muestra como un rectngulo, un cuadrado, una elipse, un crculo, un rectngulo redondeado o un cuadrado redondeado. Utilice controles Shape en tiempo de diseo en lugar o adems de invocar los mtodos Circle y Line en tiempo de ejecucin. Puede dibujar un control Shape en un contenedor, pero no puede actuar como contenedor. (Esto quiere decir que un control Shape nunca le servir, por ejemplo, para albergar varios OptionButton y pretender que sean independientes de otros controles OptionButton que se encuentren fuera del control Shape. Este control no tiene Procedimientos. En realidad, solamente sirve para mostrar un determinado grfico, envolver grficamente a otros controles, pero no tiene ninguna aplicacin en cuanto a programa. Es un adorno para sus aplicaciones.LINE Se toma directamente de la caja de herramientas Line, al igual que Shape, es un control grfico que solamente sirve para poner una lnea en un formulario. Del mismo modo, no tiene procedimientos, por lo que no sirve para aportar cdigo al programa. Solo sirve para aportar una caracterstica grfica, es un adorno. CONTROL GAUGE Este control presenta una informacin numrica de forma grfica, bien como un display lineal (tpico por ejemplo en ecualizadores de audio), o como una aguja. No est normalmente en la caja de herramientas, por lo que hay que traerla desde los Controles Personalizados (Men desplegable de Herramientas) Se denomina MicroHelp Gauge Control. El archivo que lo contiene se denomina GAUGE16.OCX, 16 bits Mediante este control, podemos presentar una magnitud numrica de una forma cuasi-analgica. Podramos decir que es un control similar al HScrollBar, que en vez de meter informacin a la aplicacin, la presenta. Este control puede servir, por ejemplo, para presentar el tanto por ciento de ejecucin de una tarea, como elemento tranquilizante. Puede presentar el nivel de un depsito de agua, etc. Presenta las dos formas siguientes: En la figura puede verse un Gauge de aguja, uno de barra horizontal y otro de barra vertical. Para mejorar la presentacin, el Gauge permite poner un grfico como fondo, cambiar el color de la barra, color de fondo, etc. El control Gauge crea medidores definidos por el usuario, que puede elegir entre los estilos lineales (relleno) o de aguja.

Nota para la distribucin Cuando cree y distribuya aplicaciones con controles Gauge, tendr que instalar el archivo apropiado en el subdirectorio SYSTEM de Windows del cliente. El Kit para instalacin que incluye Visual Basic, le proporciona herramientas para escribir los programas que instalan las aplicaciones correctamente. El CommonDialog es un control del que se libran muy pocas aplicaciones. Dada la importancia de este control, se le dedica un capitulo nico en esta Gua del Estudiante. CUADRO DE DIALOGO CommonDialog Normalmente se encuentra en la caja de herramientas Este control no se presenta en tiempo de diseo mas que con un simple icono: El cuadro de dilogo, CommonDialog se utiliza para varias funciones: Abrir Ficheros Guardar Ficheros Elegir colores Seleccionar Impresora Seleccionar Fuentes Mostrar el fichero de Ayuda

En realidad el cuadro de dilogo permite conocer datos con los cuales, y mediante el cdigo adecuado, abriremos o guardaremos ficheros, elegiremos colores o seleccionaremos fuentes. Es decir, el CommonDialog NO realiza mas funciones que mostrar ficheros existentes, fuentes disponibles, colores, para que, mediante cdigo, abramos esos ficheros o usemos una determinada fuente. Dependiendo de la aplicacin para la que vaya a usarse se deber activar de distintas formas. Si el cuadro de dilogo se va a usar para seleccionar la impresora y para otras aplicaciones, es recomendable usar uno exclusivamente para seleccionar la impresora. Esta ltima recomendacin se debe a que, para el control de la impresora, el CommonDialog SI realiza las funciones de seleccin de impresora predeterminada. Esta diferencia operativa hace que si usamos el mismo CommonDialog para seleccionar impresora y abrir ficheros, por ejemplo, se cuelgue el CommonDialog. Eventos: es una accin como hacer clic, doble clic, presionar una tecla, mover el puntero del mouse, etc. Que el usuario debe realizar para que un objeto ejecute una accin determinada cada control responde a diferentes eventos, algunos de ellos tienen caractersticas comunes. Los eventos pueden Visualizarse en la ventana de cdigo. Mtodos: Son procedimientos definidos en Visual Basic para realizar operaciones especificas sobre los objetos (Controles o Formularios) Controles: Son los objetos que conforman la interfaz grafica de un programa; a travs de ellos, un usuario interacta con la aplicacin. Sus caractersticas pueden cambiarse por medio de la ventana propiedades Proyecto: Propiedades: Son los datos que hacen referencia a un objeto o formulario. Ejemplo : Color de fondo del formulario, Fuente de texto de un TextBox. Objetos: Un objeto es una entidad que tiene asociado un conjunto de mtodos, eventos y propiedades. Hay muchas clases de objetos, y por tanto, puede llegar a haber tantos mtodos, eventos y propiedades distintas como objetos diferentes.

Ejemplo : Una caja de texto (TextBox) en la cual podemos escribir cualquier lnea es un objeto. Clases: Una clase no es nada mas que un Objeto, este objeto, tiene propiedades, funciones y mtodos. Para empezar ahora la creacin de propiedades si se utiliza Property Let y Property Get; la diferencia es casi nada, inclusive podra decir que una clase en visual basic, es casi lo mismo que un control, pero ahora nace una nueva pregunta, cuando utilizar un control y cuando utilizar una clase, bueno la opinin que voy a dar es desde mi perspectiva. Mdulo: Un proyecto Visual Basic no slo est compuesto de Formularios, sino tambin de lo que se denominan mdulos. Un mdulo es un fichero Visual Basic donde escribimos parte del cdigo de nuestro programa, y digo parte, porque puede haber cdigo en el formulario tambin. Variable: Dim: Al declarar una variable con esta palabra estamos diciendo que la variable sea local al mbito en que se declara. Puede ser dentro de un procedimiento o dentro de un formulario, de esta forma no sera accesible desde los dems procedimientos o formularios. Public: Las variables declaradas sern publicas y podrn estar accesibles desde todos los formularios de la aplicacin. Para conseguirlo tendremos que declararlas en un mdulo de cdigo, no en la seccin declarations de cualquier formulario de los que conste la aplicacin. Para crear un mdulo de cdigo en el men principal de Visual Basic marcamos en INSERT/MODULE y aparecer junto a los dems formularios de la ventana de proyecto aunque con un icono distinto indicando que se trata de un mdulo de cdigo. Static: Con esta forma de declarar variables conseguiremos que las variables locales no se creen y se destruyan al entrar y salir de los procedimientos donde fueron declaradas sino que se mantenga su valor durante todo el periodo de ejecucin de la aplicacin. De esta forma a entrar en algn procedimiento las variables recuerdan el valor que tenan cuando se sali de l. TIPOS DE VARIABLES TIPO BYTE LONG COMENTARIO Slo admite 2 valores TRUE o FALSE admite valores entre -32768 y 32767 admite valores entre 0 y 255 admite valores entre -2.147.483.648 y 2.147.483.647 admite valores decimales de doble precisin vlido para valores de tipo moneda cadenas de caracteres fechas, permite operar con ellas BOOLEAN INTEGER

SINGLE admite valores decimales con precisin simple DOUBLE CURRENCY STRING DATE

Constante: Declaracin de constantes que pueden ser usadas en cualquier punto en lugar de su valor, permitiendo cambiarlo cuando sea necesario, sin tener que cambiarlo en todos los sitios en que se utiliza. La expresin no puede utilizar llamadas a funciones, pues la constante se calcula en tiempo de compilacin, no en tiempo de ejecucin. 2.4.3. C# Caractersticas de C#.- Con la idea de que los programadores ms experimentados puedan obtener una visin general del lenguaje, a continuacin se recoge de manera resumida las principales caractersticas de C# Alguna de las caractersticas aqu sealadas no son exactamente propias del lenguaje sino de la plataforma

.NET en general. Sin embargo, tambin se comentan aqu tambin en tanto que tienen repercusin directa en el lenguaje, aunque se indicar explcitamente cules son este tipo de caractersticas cada vez que se toquen: o o o Sencillez: C# elimina muchos elementos que otros lenguajes incluyen y que son innecesarios en El cdigo escrito en C# es autocontenido, lo que significa que no necesita de ficheros adicionales al El tamao de los tipos de datos bsicos es fijo e independiente del compilador, sistema operativo o No se incluyen elementos poco tiles de lenguajes como C++ tales como macros, herencia mltiple .NET. Por ejemplo: propio fuente tales como ficheros de cabecera o ficheros IDL mquina para quienes se compile (no como en C++), lo que facilita la portabilidad del cdigo. o la necesidad de un operador diferente del punto (.) acceder a miembros de espacios de nombres (::) Modernidad: C# incorpora en el propio lenguaje elementos que a lo largo de los aos ha ido demostrndose son muy tiles para el desarrollo de aplicaciones y que en otros lenguajes como Java o C++ hay que simular, como un tipo bsico decimal que permita realizar operaciones de alta precisin con reales de 128 bits (muy til en el mundo financiero), la inclusin de una instruccin foreach que permita recorrer colecciones con facilidad y es ampliable a tipos definidos por el usuario, la inclusin de un tipo bsico string para representar cadenas o la distincin de un tipo bool especfico para representar valores lgicos. Orientacin a objetos: Como todo lenguaje de programacin de propsito general actual, C# es un lenguaje orientado a objetos, aunque eso es ms bien una caracterstica del CTS que de C#. Una diferencia de este enfoque orientado a objetos respecto al de otros lenguajes como C++ es que el de C# es ms puro en tanto que no admiten ni funciones ni variables globales sino que todo el cdigo y datos han de definirse dentro de definiciones de tipos de datos, lo que reduce problemas por conflictos de nombres y facilita la legibilidad del cdigo. C# soporta todas las caractersticas propias del paradigma de programacin orientada a objetos: encapsulacin, herencia y polimorfismo. En lo referente a la encapsulacin es importante sealar que aparte de los tpicos modificadores public, private y protected, C# aade un cuarto modificador llamado internal, que puede combinarse con protected e indica que al elemento a cuya definicin precede slo puede accederse desde su mismo ensamblado. Respecto a la herencia -a diferencia de C++ y al igual que Java- C# slo admite herencia simple de clases ya que la mltiple provoca ms quebraderos de cabeza que facilidades y en la mayora de los casos su utilidad puede ser simulada con facilidad mediante herencia mltiple de interfaces. De todos modos, esto vuelve a ser ms bien una caracterstica propia del CTS que de C#. Por otro lado y a diferencia de Java, en C# se ha optado por hacer sellados y que los redefinibles hayan de que todos los mtodos sean por defecto de esto marcarse con el modificador virtual (como en C++), lo que

permite evitar errores derivados de redefiniciones accidentales. Adems, un efecto secundario

es que las llamadas a los mtodos sern ms eficientes por defecto al no tenerse que buscar en la tabla de funciones virtuales la implementacin de los mismos a la que se ha de llamar. Otro efecto secundario es que permite que las llamadas a los mtodos virtuales se puedan hacer ms eficientemente al contribuir a que el tamao de dicha tabla se reduzca. Orientacin a componentes: La propia sintaxis de C# incluye elementos propios del diseo de componentes que otros lenguajes tienen que simular mediante construcciones ms o menos complejas. Es

decir, la sintaxis de C# permite definir cmodamente propiedades (similares a campos de acceso controlado), eventos (asociacin controlada de funciones de respuesta a notificaciones) o atributos (informacin sobre un tipo o sus miembros) Gestin automtica de memoria: Como ya se coment, todo lenguaje de .NET tiene a su disposicin el recolector de basura del CLR. Esto tiene el efecto en el lenguaje de que no es necesario incluir instrucciones de destruccin de objetos. Sin embargo, dado que la destruccin de los objetos a travs del recolector de basura es indeterminista y slo se realiza cuando ste se active ya sea por falta de memoria, finalizacin de la aplicacin o solicitud explcita en el fuente-, C# tambin proporciona un mecanismo de liberacin de recursos determinista a travs de la instruccin using. Seguridad de tipos: C# incluye mecanismos que permiten asegurar que los accesos a tipos de datos siempre se realicen correctamente, lo que permite evita que se produzcan errores difciles de detectar por acceso a memoria no perteneciente a ningn objeto y es especialmente necesario en un entorno gestionado por un recolector de basura. Para ello se toman medidas del tipo: o Slo se admiten conversiones entre tipos compatibles. Esto es, entre un tipo y antecesores suyos, entre tipos para los que explcitamente se haya definido un operador de conversin, y entre un tipo y un tipo hijo suyo del que un objeto del primero almacenase una referencia del segundo (downcasting) Obviamente, lo ltimo slo puede comprobarlo en tiempo de ejecucin el CLR y no el compilador, por lo que en realidad el CLR y el compilador colaboran para asegurar la correccin de las conversiones. o No se pueden usar variables no inicializadas. El compilador da a los campos un valor por defecto consistente en ponerlos a cero y controla mediante anlisis del flujo de control del fuente que no se lea ninguna variable local sin que se le haya asignado previamente algn valor. o o Se comprueba que todo acceso a los elementos de una tabla se realice con ndices que se encuentren Se puede controlar la produccin de desbordamientos en operaciones aritmticas, informndose de dentro del rango de la misma. ello con una excepcin cuando ocurra. Sin embargo, para conseguirse un mayor rendimiento en la aritmtica estas comprobaciones no se hacen por defecto al operar con variables sino slo con constantes (se pueden detectar en tiempo de compilacin) o A diferencia de Java, C# incluye delegados, que son similares a los punteros a funciones de C++ pero siguen un enfoque orientado a objetos, pueden almacenar referencias a varios mtodos simultneamente, y se comprueba que los mtodos a los que apunten tengan parmetros y valor de retorno del tipo indicado al definirlos. o Pueden definirse mtodos que admitan un nmero indefinido de parmetros de un cierto tipo, y a diferencia lenguajes como C/C++, en C# siempre se comprueba que los valores que se les pasen en cada llamada sean de los tipos apropiados. Instrucciones seguras: Para evitar errores muy comunes, en C# se han impuesto una serie de restricciones en el uso de las instrucciones de control ms comunes. Por ejemplo, la guarda de toda condicin ha de ser una expresin condicional y no aritmtica, con lo que se evitan errores por confusin del operador de igualdad (==) con el de asignacin (=); y todo caso de un switch ha de terminar en un break o goto que indique cul es la siguiente accin a realizar, lo que evita la ejecucin accidental de casos y facilita su reordenacin.

Sistema de tipos unificado: A diferencia de C++, en C# todos los tipos de datos que se definan

siempre derivarn, aunque sea de manera implcita, de una clase base comn llamada System.Object, por lo que dispondrn de todos los miembros definidos en sta clase (es decir, sern objetos) A diferencia de Java, en C# esto tambin es aplicable a los tipos de datos bsicos Adems, para conseguir que ello no tenga una repercusin negativa en su nivel de rendimiento, se ha incluido un mecanismo transparente de boxing y unboxing con el que se consigue que slo sean tratados como objetos cuando la situacin lo requiera, y mientras tanto puede aplicrseles optimizaciones especficas. El hecho de que todos los tipos del lenguaje deriven de una clase comn facilita enormemente el diseo de colecciones genricas que puedan almacenar objetos de cualquier tipo. Extensibilidad de tipos bsicos: C# permite definir, a travs de estructuras, tipos de datos para los que se apliquen las mismas optimizaciones que para los tipos de datos bsicos. Es decir, que se puedan almacenar directamente en pila (luego su creacin, destruccin y acceso sern ms rpidos) y se asignen por valor y no por referencia. Para conseguir que lo ltimo no tenga efectos negativos al pasar estructuras como parmetros de mtodos, se da la posibilidad de pasar referencias a pila a travs del modificador de parmetro ref. Extensibilidad de operadores: Para facilitar la legibilidad del cdigo y conseguir que los nuevos tipos de datos bsicos que se definan a travs de las estructuras estn al mismo nivel que los bsicos predefinidos en el lenguaje, al igual que C++ y a diferencia de Java, C# permite redefinir el significado de la mayora de los operadores -incluidos los de conversin, tanto para conversiones implcitas como explcitas- cuando se apliquen a diferentes tipos de objetos. Las redefiniciones de operadores se hacen de manera inteligente, de modo que a partir de una nica definicin de los operadores ++ y el compilador puede deducir automticamente como ejecutarlos de manera prefijas y postifja; y definiendo operadores simples (como +), el compilador deduce cmo aplicar su versin de asignacin compuesta (+=) Adems, para asegurar la consistencia, el compilador vigila que los operadores con opuesto siempre se redefinan por parejas (por ejemplo, si se redefine ==, tambin hay que redefinir !=) Tambin se da la posibilidad, a travs del concepto de indizador, de redefinir el significado del operador [] para los tipos de dato definidos por el usuario, con lo que se consigue que se pueda acceder al mismo como si fuese una tabla. Esto es muy til para trabajar con tipos que acten como colecciones de objetos. Extensibilidad de modificadores: C# ofrece, a travs del concepto de atributos, la posibilidad de aadir a los metadatos del mdulo resultante de la compilacin de cualquier fuente informacin adicional a la generada por el compilador que luego podr ser consultada en tiempo ejecucin a travs de la librera de reflexin de .NET . Esto, que ms bien es una caracterstica propia de la plataforma .NET y no de C#, puede usarse como un mecanismo para definir nuevos modificadores. Versionable: C# incluye una poltica de versionado que permite crear nuevas versiones de tipos sin temor a que la introduccin de nuevos miembros provoquen errores difciles de detectar en tipos hijos previamente desarrollados y ya extendidos con miembros de igual nombre a los recin introducidos. Si una clase introduce un nuevo mtodo cuyas redefiniciones deban seguir la regla de llamar a la versin de su padre en algn punto de su cdigo, difcilmente seguiran esta regla miembros de su misma signatura definidos en clases hijas previamente a la definicin del mismo en la clase padre; o si introduce un

nuevo campo con el mismo nombre que algn mtodo de una clase hija, la clase hija dejar de funcionar. Para evitar que esto ocurra, en C# se toman dos medidas: o Se obliga a que toda redefinicin deba incluir el modificador override, con lo que la versin de la clase hija nunca sera considerada como una redefinicin de la versin de miembro en la clase padre ya que no incluira override. Para evitar que por accidente un programador incluya este modificador, slo se permite incluirlo en miembros que tengan la misma signatura que miembros marcados como redefinibles mediante el modificador virtual. As adems se evita el error tan frecuente en Java de creerse haber redefinido un miembro, pues si el miembro con override no existe en la clase padre se producir un error de compilacin. o Si no se considera redefinicin, entonces se considera que lo que se desea es ocultar el mtodo de la clase padre, de modo que para la clase hija sea como si nunca hubiese existido. El compilador avisar de esta decisin a travs de un mensaje de aviso que puede suprimirse incluyendo el modificador new en la definicin del miembro en la clase hija para as indicarle explcitamente la intencin de ocultacin. Eficiente: En principio, en C# todo el cdigo incluye numerosas restricciones para asegurar su seguridad y no permite el uso de punteros. Sin embargo, y a diferencia de Java, en C# es posible saltarse dichas restricciones manipulando objetos a travs de punteros. Para ello basta marcar regiones de cdigo como inseguras (modificador unsafe) y podrn usarse en ellas punteros de forma similar a cmo se hace en C++, lo que puede resultar vital para situaciones donde se necesite una eficiencia y velocidad procesamiento muy grandes. Compatible: Para facilitar la migracin de programadores, C# no slo mantiene una sintaxis muy similar a C, C++ o Java que permite incluir directamente en cdigo escrito en C# fragmentos de cdigo escrito en estos lenguajes, sino que el CLR tambin ofrece, a travs de los llamados Platform Invocation Services (PInvoke), la posibilidad de acceder a cdigo nativo escrito como funciones sueltas no orientadas a objetos tales como las DLLs de la API Win32. Ntese que la capacidad de usar punteros en cdigo inseguro permite que se pueda acceder con facilidad a este tipo de funciones, ya que stas muchas veces esperan recibir o devuelven punteros. Tambin es posible acceder desde cdigo escrito en C# a objetos COM. Para facilitar esto, el .NET Framework SDK incluye una herramientas llamadas tlbimp y regasm mediante las que es posible generar automticamente clases proxy que permitan, respectivamente, usar objetos COM desde .NET como si de objetos .NET se tratase y registrar objetos .NET para su uso desde COM. Finalmente, tambin se da la posibilidad de usar controles ActiveX desde cdigo .NET y viceversa. Para lo primero se utiliza la utilidad aximp, mientras que para lo segundo se usa la ya mencionada regasm. 2.5 SISTEMAS GESTORES DE BASE DE DATOS: Los sistemas gestores de base de datos son un tipo de software especifico, dedicado a servir de interfaz entre la base de datos y el usuario, las aplicaciones que la utilizan. Se compone de un lenguaje de definicin de datos de un lenguaje de manipulacin de datos y de un lenguaje de consulta. 2.5.1. 1. MYSQL Qu es MySQL?

Es un sistema de gestin de bases de datos relacional, fue creada por la empresa sueca MySQL AB, la cual tiene el copyright del cdigo fuente del servidor SQL, as como tambin de la marca. MySQL es un software de cdigo abierto, licenciado bajo la GPL de la GNU, aunque MySQL AB distribuye una versin comercial, en lo nico que se diferencia de la versin libre, es en el soporte tcnico que se ofrece,

y la posibilidad de integrar este gestor en un software propietario, ya que de otra manera, se vulnerara la licencia GPL. El lenguaje de programacin que utiliza MySQL es Structured Query Language (SQL) que fue desarrollado por IBM en 1981 y desde entonces es utilizado de forma generalizada en las bases de datos relacionales. MySQL es un sistema de gestin de bases de datos relacional, multihilo y multiusuario con ms de seis millones de instalaciones.[1] MySQL AB desde enero de 2008 una subsidiaria de Sun Microsystems y sta a su vez de Oracle Corporation desde abril de 2009 desarrolla MySQL como software libre en un esquema de licenciamiento dual. MySQL es muy utilizado en aplicaciones web, como Drupal o phpBB, en plataformas (Linux/WindowsApache-MySQL-PHP/Perl/Python), y por herramientas de seguimiento de errores como Bugzilla. Su popularidad como aplicacin web est muy ligada a PHP, que a menudo aparece en combinacin con MySQL. MySQL es una base de datos muy rpida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificacin. En aplicaciones web hay baja concurrencia en la modificacin de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones. Sea cual sea el entorno en el que va a utilizar MySQL, es importante monitorizar de antemano el rendimiento para detectar y corregir errores tanto de SQL como de programacin. Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, pero para aquellas empresas que quieran incorporarlo en productos privativos deben comprar a la empresa una licencia especfica que les permita este uso. Est desarrollado en su mayor parte en ANSI C. Al contrario de proyectos como Apache, donde el software es desarrollado por una comunidad pblica y los derechos de autor del cdigo estn en poder del autor individual, MySQL es patrocinado por una empresa privada, que posee el copyright de la mayor parte del cdigo. Esto es lo que posibilita el esquema de licenciamiento anteriormente mencionado. Adems de la venta de licencias privativas, la compaa ofrece soporte y servicios 2. Historia de MySQL MySQL surgi alrededor de la dcada del 90, Michael Windenis comenz a usar mSQL para conectar tablas usando sus propias rutinas de bajo nivel (ISAM). Tras unas primeras pruebas, lleg a la conclusin de que mSQL no era lo bastante flexible ni rpido para lo que necesitaba, por lo que tuvo que desarrollar nuevas funciones. Esto resulto en una interfaz SQL a su base de datos, totalmente compatible a mSQL. El origen del nombre MySQL no se sabe con certeza de donde proviene, por una lado se dice que en sus libreras han llevado el prefijo my durante los diez ltimos aos, por otra parte, la hija de uno de los desarrolladores se llama My. As que no est claramente definido cual de estas dos causas han dado lugar al nombre de este conocido gestor de bases de datos. Para sus operaciones contratan trabajadores alrededor del mundo que colaboran va Internet. MySQL AB fue fundado por David Axmark, Allan Larsson y Michael Widenius. Al contrario de proyectos como el Apache, donde el software es desarrollado por una comunidad pblica, y el copyright del cdigo est en poder del autor individual, MySQL est poseIdo y patrocinado por una empresa privada, que posee el copyright de la mayor parte del cdigo. MySQL AB fue fundado por David Axmark, Allan Larsson, y Michael Widenius. 3. Caractersticas principales

Inicialmente, MySQL careca de algunos elementos esenciales en las bases de datos relacionales, tales como integridad referencial y transacciones. A pesar de esto, atrajo a los desarrolladores de pginas web con contenido dinmico, debido a su simplicidad, de tal manera que los elementos faltantes fueron complementados por la va de las aplicaciones que la utilizan. Poco a poco estos elementos faltantes, estn siendo incorporados tanto por desarrolladores internos, como por desarrolladores de software libre. En las ltimas versiones se pueden destacar las siguientes caractersticas principales: 4. 5. 6. o o o o o o o o o 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 Aprovecha la potencia de sistemas multiproceso, gracias a su implementacin multihilo. Flexible sistema de contraseas (passwords) y gestin de usuarios, con un muy buen nivel de El servidor soporta mensajes de error en distintas lenguas VENTAJAS Velocidad al realizar las operaciones, lo que le hace uno de los gestores con mejor rendimiento. Bajo costo en requerimientos para la elaboracin de bases de datos, ya que debido a su bajo consumo Facilidad de configuracin e instalacin. Soporta gran variedad de Sistemas Operativos Baja probabilidad de corromper datos, incluso si los errores no se producen en el propio gestor, sino Conectividad y seguridad DESVENTAJAS Un gran porcentaje de las utilidades de MySQL no estn documentadas. No es intuitivo, como otros programas (ACCESS). PANORMICA DE PROGRAMAS MYSQL El servidor MYSQL y los scripts de inicio del servidor: mysqld es el servidor MySQL mysqld_safe, mysql.server, y mysqld_multi son scripts de inicio del servidor mysql_install_db inicializa el directorio data y las bases de datos que MySQL instala por defecto. . Programas cliente que acceden al servidor: mysql es un programa cliente que porporciona una interfaz de linea de comandos para ejecutar mysqladmin es un cliente para administracin. mysqlcheck ejecuta operaciones de mantenimiento de tablas. mysqldump y mysqlhotcopy son utilidades para copia de respaldo. mysqlimport realiza importacin de ficheros de datos. mysqlshow muestra informacin relativa a tablas y bases de datos. .

hasta 32 ndices por tabla.

seguridad en los datos.

puede ser ejecutado en una mquina con escasos recursos sin ningn problema.

en el sistema en el que est.

MySQL AB proporciona varios tipos de programas:

sentencias SQL en modo interactivo o por lotes.

 o o o o

Programas que operan independientemente del servidor: myisamchk ejecuta operaciones de mantenimiento de tablas. myisampack genera tablas comprimidas, de slo lectura. mysqlbinlog es una herramienta para procesar archivos de registro binario (binary logs). perror informa el significado de un cdigo de error.

La mayora de las distribuciones de MySQL incluyen todos los programas mencionados, con excepcin de los que son especficos de cada plataforma. (Por ejemplo, los scripts de inicio de servidor no son necesarios en Windows). Otra excepcin es que las distribuciones RPM son ms especializadas. Existe una RPM para el servidor, otra para los programas cliente, etc. 2.5.2 SQL SERVER 1. Introduccin a SQL SERVER El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por el motor de base de datos de Microsoft Jet. SQL se utiliza para crear objetos QueryDef, como el argumento de origen del mtodo OpenRecordSet y como la propiedad RecordSource del control de datos. Tambin se puede utilizar con el mtodo Execute para crear y manipular directamente las bases de datos Jet y crear consultas SQL de paso a travs para manipular bases de datos remotas cliente servidor. 1.1. Componentes del SQL El lenguaje SQL est compuesto por comandos, clusulas, operadores y funciones de agregado. Estos elementos se combinan en las instrucciones para crear, actualizar y manipular las bases de datos. 1.2 Comandos Existen dos tipos de comandos SQL: los DLL que permiten crear y definir nuevas bases de datos, campos e ndices. los DML que permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos. Descripcin Utilizado para crear nuevas tablas, campos e ndices

Comandos DLL Comando CREATE DROP

Empleado para eliminar tablas e ndices

ALTER Utilizado para modificar las tablas agregando campos o cambiando la definicin de los campos. Comandos DML Comando Descripcin SELECT Utilizado para consultar registros de la base de datos que satisfagan un criterio determinado INSERT Utilizado para cargar lotes de datos en la base de datos en una nica operacin. UPDATE 1.3 Clusulas Las clusulas son condiciones de modificacin utilizadas para definir los datos que desea seleccionar o manipular. Clusula Descripcin FROM Utilizada para especificar la tabla de la cual se van a seleccionar los registros WHERE Utilizada para especificar las condiciones que deben reunir los registros que se van a seleccionar GROUP BY Utilizada para separar los registros seleccionados en grupos especficos Utilizado para modificar los valores de los campos y registros especificados DELETE Utilizado para eliminar registros de una tabla de una base de datos

HAVING ORDER BY Operador AND OR NOT Operador

Utilizada para expresar la condicin que debe satisfacer cada grupo Utilizada para ordenar los registros seleccionados de acuerdo con un orden especfico Uso

1.4 Operadores Lgicos Es el y lgico. Evalua dos condiciones y devuelve un valor de verdad slo si ambas son ciertas. Es el o lgico. Evala dos condiciones y devuelve un valor de verdar si alguna de las dos es cierta. Negacin lgica. Devuelve el valor contrario de la expresin. Uso Mayor que Distinto de = = LIKE In Mayor Igual que Igual que Utilizado para especificar un intervalo de valores. Utilizado en la comparacin de un modelo Utilizado para especificar registros de una base de datos

1.5 Operadores de Comparacin

BETWEEN

1.6 Funciones de Agregado Las funciones de agregado se usan dentro de una clusula SELECT en grupos de registros para devolver un nico valor que se aplica a un grupo de registros. Funcin AVG SUM MAX MIN Descripcin Utilizada para calcular el promedio de los valores de un campo determinado Utilizada para devolver la suma de todos los valores de un campo determinado Utilizada para devolver el valor ms alto de un campo especificado Utilizada para devolver el valor ms bajo de un campo especificado

COUNT Utilizada para devolver el nmero de registros de la seleccin

Consultas de Seleccin Las consultas de seleccin se utilizan para indicar al motor de datos que devuelva informacin de las bases de datos, esta informacin es devuelta en forma de conjunto de registros que se pueden almacenar en un objeto recordset. Este conjunto de registros es modificable. 2.1 Consultas bsicas La sintaxis bsica de una consulta de seleccin es la siguiente: SELECT Campos FROM Tabla; En donde campos es la lista de campos que se deseen recuperar y tabla es el origen de los mismos, por ejemplo: SELECT Nombre, Telefono FROM Clientes; Esta consulta devuelve un recordset con el campo nombre y telfono de la tabla clientes. 2.2 Ordenar los registros Adicionalmente se puede especificar el orden en que se desean recuperar los registros de las tablas mediante la clasula ORDER BY Lista de Campos. En donde Lista de campos representa los campos aordenar. Ejemplo: SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY Nombre;

Esta consulta devuelve los campos CodigoPostal, Nombre, Telefono de la tabla Clientes ordenados por el campo Nombre. Se pueden ordenar los registros por mas de un campo, como por ejemplo: SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY CodigoPostal, Nombre; Incluso se puede especificar el orden de los registros: ascendente mediante la clasula (ASC -se toma este valor por defecto) descendente (DESC) SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY CodigoPostal DESC , Nombre ASC; 2.3 Consultas con Predicado El predicado se incluye entre la clasula y el primer nombre del campo a recuperar, los posibles predicados son: Predicado ALL TOP Descripcin Devuelve todos los campos de la tabla Devuelve un determinado nmero de registros de la tabla Omite los registros cuyos campos seleccionados coincidan totalmente

DISTINCT

DISTINCTROW Omite los registros duplicados basandose en la totalidad del registro y no slo en los campos seleccionados. ALL Si no se incluye ninguno de los predicados se asume ALL. El Motor de base de datos selecciona todos los registros que cumplen las condiciones de la instruccin SQL. No se conveniente abusar de este predicado ya que obligamos al motor de la base de datos a analizar la estructura de la tabla para averiguar los campos que contiene, es mucho ms rpido indicar el listado de campos deseados. SELECT ALL FROM Empleados; SELECT * FROM Empleados; TOP Devuelve un cierto nmero de registros que entran entre al principio o al final de un rango especificado por una clusula ORDER BY. Supongamos que queremos recuperar los nombres de los 25 primeros estudiantes del curso 1994: SELECT TOP 25 Nombre, Apellido FROM Estudiantes ORDER BY Nota DESC; Si no se incluye la clusula ORDER BY, la consulta devolver un conjunto arbitrario de 25 registros de la tabla Estudiantes .El predicado TOP no elige entre valores iguales. En el ejemplo anterior, si la nota media nmero 25 y la 26 son iguales, la consulta devolver 26 registros. Se puede utilizar la palabra reservada PERCENT para devolver un cierto porcentaje de registros que caen al principio o al final de un rango especificado por la clusula ORDER BY. Supongamos que en lugar de los 25 primeros estudiantes deseamos el 10 por ciento del curso: SELECT TOP 10 PERCENT Nombre, Apellido FROM Estudiantes ORDER BY Nota DESC; El valor que va a continuacin de TOP debe ser un Integer sin signo.TOP no afecta a la posible actualizacin de la consulta.

DISTINCT Omite los registros que contienen datos duplicados en los campos seleccionados. Para que los valores de cada campo listado en la instruccin SELECT se incluyan en la consulta deben ser nicos. Por ejemplo, varios empleados listados en la tabla Empleados pueden tener el mismo apellido. Si dos registros contienen Lpez en el campo Apellido, la siguiente instruccin SQL devuelve un nico registro: SELECT DISTINCT Apellido FROM Empleados; Con otras palabras el predicado DISTINCT devuelve aquellos registros cuyos campos indicados en la clusula SELECT posean un contenido diferente. El resultado de una consulta que utiliza DISTINCT no es actualizable y no refleja los cambios subsiguientes realizados por otros usuarios. DISTINCTROW Devuelve los registros diferentes de una tabla; a diferencia del predicado anterior que slo se fijaba en el contenido de los campos seleccionados, ste lo hace en el contenido del registro completo independientemente de los campo indicados en la clusula SELECT. SELECT DISTINCTROW Apellido FROM Empleados; Si la tabla empleados contiene dos registros: Antonio Lpez y Marta Lpez el ejemplo del predicado DISTINCT devuleve un nico registro con el valor Lpez en el campo Apellido ya que busca no duplicados en dicho campo. Este ltimo ejemplo devuelve dos registros con el valor Lpez en el apellido ya que se buscan no duplicados en el registro completo. 2.4 Alias En determinadas circunstancias es necesario asignar un nombre a alguna columna determinada de un conjunto devuelto, otras veces por simple capricho o por otras circunstancias. Para resolver todas ellas tenemos la palabra reservada AS que se encarga de asignar el nombre que deseamos a la columna deseada. Tomado como referencia el ejemplo anterior podemos hacer que la columna devuelta por la consulta, en lugar de llamarse apellido (igual que el campo devuelto) se llame Empleado. En este caso procederamos de la siguiente forma: SELECT DISTINCTROW Apellido AS Empleado FROM Empleados; 2.5 Recuperar Informacin de una base de Datos Externa Para concluir este captulo se debe hacer referencia a la recuperacin de registros de bases de datos externa. Es ocasiones es necesario la recuperacin de informacin que se encuentra contenida en una tabla que no se encuentra en la base de datos que ejecutar la consulta o que en ese momento no se encuentra abierta, esta situacin la podemos salvar con la palabra reservada IN de la siguiente forma: SELECT DISTINCTROW Apellido AS Empleado FROM Empleados IN c:\databases\gestion.mdb; En donde c:\databases\gestion.mdb es la base de datos que contiene la tabla Empleados. 3. Criterios de Seleccin Antes de comenzar el desarrollo de este captulo hay que recalcar tres detalles de vital importancia. El primero de ellos es que cada vez que se desee establecer una condicin referida a un campo de texto la condicin de bsqueda debe ir encerrada entre comillas simples; la segunda es que no se posible establecer condiciones de bsqueda en los campos memo y; la tercera y ltima hace referencia a las fechas. Las fechas se deben escribir siempre en formato mm-dd-aa en donde mm representa el mes, dd el da y aa el ao, hay que prestar atencin a los separadores -no sirve la separacin habitual de la barra (/), hay que utilizar el guin (-) y

adems la fecha debe ir encerrada entre almohadillas (#). Por ejemplo si deseamos referirnos al da 3 de Septiembre de 1995 deberemos hacerlo de la siguiente forma; #09-03-95# #9-3-95#. 3.1 Operadores Lgicos Los operadores lgicos soportados por SQL son: AND, OR, XOR, Eqv, Imp, Is y Not. A excepcin de los dos ltimos todos poseen la siguiente sintaxis: operador En donde expresin1 y expresin2 son las condiciones a evaluar, el resultado de la operacin vara en funcin del operador lgico. La tabla adjunta muestra los diferentes posibles resultados: Operador Verdad AND Verdad AND Falso Falso AND AND Falso Falso Verdad Verdad Verdad Falso Falso Falso Falso Verdad Resultado

Verdad OR Verdad OR Falso Falso OR OR

Verdad Verdad Verdad Verdad Falso Falso Falso Falso Falso Falso Null Falso Null Falso Null Falso Verdad Falso Falso Verdad Falso Null Verdad Verdad Null Null Verdad Falso Verdad Verdad Verdad Verdad Verdad Falso Verdad Verdad

Verdad XOR Verdad XOR Falso Falso XOR XOR

Verdad Eqv Verdad Eqv Falso Falso Eqv Eqv

Verdad Imp Verdad Imp Verdad Imp Falso Falso Falso Null Null Null Imp Imp Imp Imp Imp Imp

Verdad Verdad

Verdad Verdad

Si a cualquiera de las anteriores condiciones le anteponemos el operador NOT el resultado de la operacin ser el contrario al devuelto sin el operador NOT. El ltimo operador denominado Is se emplea para comparar dos variables de tipo objeto Is . este operador devuelve verdad si los dos objetos son iguales SELECT * FROM Empleados WHERE Edad > 25 AND Edad 25 AND Edad 100 AND Sueldo 21000; SELECT Id_Producto, Existencias FROM Productos

WHERE Existencias 100 AND NombreProducto Like BOS*; 4.2 AVG Calcula la media aritmtica de un conjunto de valores contenidos en un campo especificado de una consulta. Su sintaxis es la siguiente Avg(expr) En donde expr representa el campo que contiene los datos numricos para los que se desea calcular la media o una expresin que realiza un clculo utilizando los datos de dicho campo. La media calculada por Avg es la media aritmtica (la suma de los valores dividido por el nmero de valores). La funcin Avg no incluye ningn campo Null en el clculo. SELECT Avg(Gastos) AS Promedio FROM Pedidos WHERE Gastos > 100; 4.3 Count Calcula el nmero de registros devueltos por una consulta. Su sintaxis es la siguiente Count(expr) En donde expr contiene el nombre del campo que desea contar. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el usuario pero no otras de las funciones agregadas de SQL). Puede contar cualquier tipo de datos incluso texto. Aunque expr puede realizar un clculo sobre un campo, Count simplemente cuenta el nmero de registros sin tener en cuenta qu valores se almacenan en los registros. La funcin Count no cuenta los registros que tienen campos null a menos que expr sea el carcter comodn asterisco (*). Si utiliza un asterisco, Count calcula el nmero total de registros, incluyendo aquellos que contienen campos null. Count(*) es considerablemente ms rpida que Count(Campo). No se debe poner el asterisco entre dobles comillas (*). SELECT Count(*) AS Total FROM Pedidos; Si expr identifica a mltiples campos, la funcin Count cuenta un registro slo si al menos uno de los campos no es Null. Si todos los campos especificados son Null, no se cuenta el registro. Hay que separar los nombres de los campos con ampersand (&). SELECT Count(FechaEnvo & Transporte) AS Total FROM Pedidos; 4.4 Max, Min Devuelven el mnimo o el mximo de un conjunto de valores contenidos en un campo especifico de una consulta. Su sintaxis es: Min(expr) Max(expr) En donde expr es el campo sobre el que se desea realizar el clculo. Expr pueden incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el usuario pero no otras de las funciones agregadas de SQL). SELECT Min(Gastos) AS ElMin FROM Pedidos WHERE Pais = Espaa; SELECT Max(Gastos) AS ElMax FROM Pedidos WHERE Pais = Espaa; 4.5 StDev, StDevP Devuelve estimaciones de la desviacin estndar para la poblacin (el total de los registros de la tabla) o una muestra de la poblacin representada (muestra aleatoria) . Su sintaxis es: StDev(expr) StDevP(expr)

En donde expr representa el nombre del campo que contiene los datos que desean evaluarse o una expresin que realiza un clculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el usuario pero no otras de las funciones agregadas de SQL) StDevP evala una poblacin, y StDev evala una muestra de la poblacin. Si la consulta contiene menos de dos registros (o ningn registro para StDevP), estas funciones devuelven un valor Null (el cual indica que la desviacin estndar no puede calcularse). SELECT StDev(Gastos) AS Desviacion FROM Pedidos WHERE Pais = Espaa; SELECT StDevP(Gastos) AS Desviacion FROM Pedidos WHERE Pais= Espaa; 4.6 Sum Devuelve la suma del conjunto de valores contenido en un campo especifico de una consulta. Su sintaxis es: Sum(expr) En donde expr respresenta el nombre del campo que contiene los datos que desean sumarse o una expresin que realiza un clculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el usuario pero no otras de las funciones agregadas de SQL). SELECT Sum(PrecioUnidad * Cantidad) AS Total FROM DetallePedido; 4.7 Var, VarP Devuelve una estimacin de la varianza de una poblacin (sobre el total de los registros) o una muestra de la poblacin (muestra aleatoria de registros) sobre los valores de un campo. Su sintaxis es: Var(expr) VarP(expr) VarP evala una poblacin, y Var evala una muestra de la poblacin. Expr el nombre del campo que contiene los datos que desean evaluarse o una expresin que realiza un clculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el usuario pero no otras de las funciones agregadas de SQL) Si la consulta contiene menos de dos registros, Var y VarP devuelven Null (esto indica que la varianza no puede calcularse). Puede utilizar Var y VarP en una expresin de consulta o en una Instruccin SQL. SELECT Var(Gastos) AS Varianza FROM Pedidos WHERE Pais = Espaa; SELECT VarP(Gastos) AS Varianza FROM Pedidos WHERE Pais = Espaa; 5. Consultas de Accin Las consultas de accin son aquellas que no devuelven ningn registro, son las encargadas de acciones como aadir y borrar y modificar registros. 5.1 DELETE Crea una consulta de eliminacin que elimina los registros de una o ms de las tablas listadas en la clusula FROM que satisfagan la clusula WHERE. Esta consulta elimina los registros completos, no es posible eliminar el contenido de algn campo en concreto. Su sintaxis es: DELETE Tabla.* FROM Tabla WHERE criterio DELETE es especialmente til cuando se desea eliminar varios registros. En una instruccin DELETE con mltiples tablas, debe incluir el nombre de tabla (Tabla.*). Si especifica ms de una tabla desde la que

eliminar registros, todas deben ser tablas de muchos a uno. Si desea eliminar todos los registros de una tabla, eliminar la propia tabla es ms eficiente que ejecutar una consulta de borrado. Se puede utilizar DELETE para eliminar registros de una nica tabla o desde varios lados de una relacin uno a muchos. Las operaciones de eliminacin en cascada en una consulta nicamente eliminan desde varios lados de una relacin. Por ejemplo, en la relacin entre las tablas Clientes y Pedidos, la tabla Pedidos es la parte de muchos por lo que las operaciones en cascada solo afectaran a la tabla Pedidos. Una consulta de borrado elimina los registros completos, no nicamente los datos en campos especficos. Si desea eliminar valores en un campo especificado, crear una consulta de actualizacin que cambie los valores a Null. Una vez que se han eliminado los registros utilizando una consulta de borrado, no puede deshacer la operacin. Si desea saber qu registros se eliminarn, primero examine los resultados de una consulta de seleccin que utilice el mismo criterio y despus ejecute la consulta de borrado. Mantenga copias de seguridad de sus datos en todo momento. Si elimina los registros equivocados podr recuperarlos desde las copias de seguridad. DELETE * FROM Empleados WHERE Cargo = Vendedor; 5.2 INSERT INTO Agrega un registro en una tabla. Se la conoce como una consulta de datos aadidos. Esta consulta puede ser de dos tipo: Insertar un nico registro Insertar en una tabla los registros contenidos en otra tabla. 5.2.1 Para insertar un nico Registro: En este caso la sintaxis es la siguiente: INSERT INTO Tabla (campo1, campo2, .., campoN) VALUES (valor1, valor2, , valorN) Esta consulta graba en el campo1 el valor1, en el campo2 y valor2 y as sucesivamente. Hay que prestar especial atencin a acotar entre comillas simples () los valores literales (cadenas de caracteres) y las fechas indicarlas en formato mm-dd-aa y entre caracteres de almohadillas (#). 5.2.2 Para insertar Registros de otra Tabla: En este caso la sintaxis es: INSERT INTO Tabla [IN base_externa] (campo1, campo2, , campoN) SELECT TablaOrigen.campo1, TablaOrigen.campo2, , TablaOrigen.campoN FROM TablaOrigen En este caso se seleccionarn los campos 1,2, , n dela tabla origen y se grabarn en los campos 1,2,.., n de la Tabla. La condicin SELECT puede incluir la clusula WHERE para filtrar los registros a copiar. Si Tabla y TablaOrigen poseen la misma estrucutra podemos simplificar la sintaxis a: INSERT INTO Tabla SELECT TablaOrigen.* FROM TablaOrigen De esta forma los campos de TablaOrigen se grabarn en Tabla, para realizar esta operacin es necesario que todos los campos de TablaOrigen estn contenidos con igual nombre en Tabla. Con otras palabras que Tabla posea todos los campos de TablaOrigen (igual nombre e igual tipo). En este tipo de consulta hay que tener especial atencin con los campos contadores o autonumricos puesto que al insertar un valor en un campo de este tipo se escribe el valor que contenga su campo homlogo en la tabla origen, no incrementandose como le corresponde. Se puede utilizar la instruccin INSERT INTO para agregar un registro nico a una tabla, utilizando la sintaxis de la consulta de adicin de registro nico tal y como se mostr anteriormente. En este caso, su

cdigo especfica el nombre y el valor de cada campo del registro. Debe especificar cada uno de los campos del registro al que se le va a asignar un valor as como el valor para dicho campo. Cuando no se especifica dicho campo, se inserta el valor predeterminado o Null. Los registros se agregan al final de la tabla. Tambin se puede utilizar INSERT INTO para agregar un conjunto de registros pertenecientes a otra tabla o consulta utilizando la clusula SELECT FROM como se mostr anteriormente en la sintaxis de la consulta de adicin de mltiples registros. En este caso la clusula SELECT especifica los campos que se van a agregar en la tabla destino especificada. La tabla destino u origen puede especificar una tabla o una consulta. Si la tabla destino contiene una clave principal, hay que segurarse que es nica, y con valores no-Null ; si no es as, no se agregarn los registros. Si se agregan registros a una tabla con un campo Contador , no se debe incluir el campo Contador en la consulta. Se puede emplear la clusula IN para agregar registros a una tabla en otra base de datos. Se pueden averiguar los registros que se agregarn en la consulta ejecutando primero una consulta de seleccin que utilice el mismo criterio de seleccin y ver el resultado. Una consulta de adicin copia los registros de una o ms tablas en otra. Las tablas que contienen los registros que se van a agregar no se vern afectadas por la consulta de adicin. En lugar de agregar registros existentes en otra tabla, se puede especificar los valores de cada campo en un nuevo registro utilizando la clusula VALUES. Si se omite la lista de campos, la clusula VALUES debe incluir un valor para cada campo de la tabla, de otra forma fallar INSERT. INSERT INTO Clientes SELECT Clientes_Viejos.* FROM Clientes_Nuevos; INSERT INTO Empleados (Nombre, Apellido, Cargo) VALUES (Luis, Snchez, Becario); INSERT INTO Empleados SELECT Vendedores.* FROM Vendedores WHERE Fecha_Contratacion < Now() 30; 5.3 UPDATE Crea una consulta de actualizacin que cambia los valores de los campos de una tabla especificada basndose en un criterio especfico. Su sintaxis es: UPDATE Tabla SET Campo1=Valor1, Campo2=Valor2, CampoN=ValorN WHERE Criterio; UPDATE es especialmente til cuando se desea cambiar un gran nmero de registros o cuando stos se encuentran en mltiples tablas. Puede cambiar varios campos a la vez. El ejemplo siguiente incrementa los valores Cantidad pedidos en un 10 por ciento y los valores Transporte en un 3 por ciento para aquellos que se hayan enviado al Reino Unido.: UPDATE Pedidos SET Pedido = Pedidos * 1.1, Transporte = Transporte * 1.03 WHERE PaisEnvo = ES; UPDATE no genera ningn resultado. Para saber qu registros se van a cambiar, hay que examinar primero el resultado de una consulta de seleccin que utilice el mismo criterio y despus ejecutar la consulta de actualizacin. UPDATE Empleados SET Grado = 5 WHERE Grado = 2; UPDATE Productos SET Precio = Precio * 1.1 WHERE Proveedor = 8 AND Familia = 3;

Si en una consulta de actualizacin suprimimos la clusula WHERE todos los registros de la tabla sealada sern actualizados. UPDATE Empleados SET Salario = Salario * 1.1 6. Tipos de Datos Los tipos de datos SQL se clasifican en 13 tipos de datos primarios y de varios sinnimos vlidos reconocidos por dichos tipos de datos. Tipos de datos primarios: Tipo de Datos BINARY BIT BYTE Longitud Descripcin 1 byte Para consultas sobre tabla adjunta de productos de bases de datos que definen un 1 byte Valores Si/No True/False 1 byte Un valor entero entre 0 y 255. 4 bytes Un nmero incrementado automticamente (de tipo Long) 8 bytes Un entero escalable entre 922.337.203.685.477,5808 y 922.337.203.685.477,5807. 8 bytes Un valor de fecha u hora entre los aos 100 y 9999.

tipo de datos Binario.

COUNTER CURRENCY DATETIME

SINGLE 4 bytes Un valor en punto flotante de precisin simple con un rango de -3.402823*1038 a 1.401298*10-45 para valores negativos, 1.401298*10-45 a 3.402823*1038 para valores positivos, y 0. DOUBLE 8 bytes Un valor en punto flotante de doble precisin con un rango de 1.79769313486232*10308 a -4.94065645841247*10-324 para valores negativos, 4.94065645841247*10-324 a 1.79769313486232*10308 para valores positivos, y 0. SHORT 2 bytes Un entero corto entre -32,768 y 32,767. LONG 4 bytes Un entero largo entre -2,147,483,648 y 2,147,483,647. 1 byte por carcter Segn se necesite De cero a un mximo de 1.2 gigabytes. De cero 1 gigabyte. Utilizado para objetos OLE. LONGTEXT LONGBINARY TEXT

1 byte por caracter Sinnimos VARBINARY BOOLEAN

De cero a 255 caracteres.

La siguiente tabla recoge los sinonimos de los tipos de datos definidos: Tipo de Dato BINARY BIT LOGICAL LOGICAL1 YESNO BYTE INTEGER1 AUTOINCREMENT MONEY DATE COUNTER CURRENCY DATETIME TIME TIMESTAMP SINGLE FLOAT4 IEEESINGLE REAL

DOUBLE FLOAT8 IEEEDOUBLE NUMBER NUMERIC

FLOAT

SHORT INTEGER2 SMALLINT LONG INT INTEGER INTEGER4 LONGBINARY OLEOBJECT LONGTEXT MEMO NOTE TEXT CHAR CHARACTER STRING VARCHAR VARIANT (No Admitido) 2.5.4 ORACLE 1. Que es oracle Oracle es bsicamente una herramienta cliente/servidor para la gestin de Bases de Datos. Es un producto vendido a nivel mundial, aunque la gran potencia que tiene y su elevado precio hace que slo se vea en empresas muy grandes y multinacionales, por norma general. En el desarrollo de pginas web pasa lo mismo: como es un sistema muy caro no est tan extendido como otras bases de datos, por ejemplo, Access, MySQL, SQL Server, etc. Vamos ahora en centrarnos en que es Oracle exactamente y como funciona la programacin sobre ste. Oracle como antes he mencionado se basa en la tecnologa cliente/servidor, pues bien, para su utilizacin primero sera necesario la instalacin de la herramienta servidor (Oracle 8i) y posteriormente podramos atacar a la base de datos desde otros equipos con herramientas de desarrollo como Oracle Designer y Oracle Developer, que son las herramientas bsicas de programacin sobre oracle. Para desarrollar en Oracle utilizamos PL/SQL un lenguaje de 5 generacin, bastante potente para tratar y gestionar la base de datos, tambin por norma general se suele utilizar SQL al crear un formulario. Es posible lgicamente atacar a la base de datos a travs del SQL plus incorporado en el paquete de programas Oracle para poder realizar consultas, utilizando el lenguaje SQL. El Developer es una herramienta que nos permite crear formularios en local, es decir, mediante esta herramienta nosotros podemos crear formularios, compilarlos y ejecutarlos, pero si queremos que los otros trabajen sobre este formulario deberemos copiarlo regularmente en una carpeta compartida para todos, de modo que, cuando quieran realizar un cambio, debern copiarlo de dicha carpeta y luego volverlo a subir a la VALUE ALPHANUMERIC LONGCHAR GENERAL

carpeta. Este sistema como podemos observar es bastante engorroso y poco fiable pues es bastante normal que las versiones se pierdan y se machaquen con frecuencia. La principal ventaja de esta herramienta es que es bastante intuitiva y dispone de un modo que nos permite componer el formulario, tal y como lo haramos en Visual Basic o en Visual C. Los problemas anteriores quedan totalmente resueltos con Designer que es una herramienta que se conecta a la base de datos y por tanto creamos los formularios en ella, de esta manera todo el mundo se conecta mediante Designer a la aplicacin que contiene todos los formularios y no hay problemas de diferentes versiones, esto es muy til y perfecto para evitar machacar el trabajo de otros. Pero el principal y ms notable problema es la falta de un entorno visual para disear el formulario, es decir, nos aparece una estructura como de rbol en la cual insertamos un formulario, a la vez dentro de ste insertamos bloques o mdulos que son las estructuras que contendrn los elementos del formularios, que pueden estar basados en tablas o no. Por lo tanto si queremos hacer formularios para practicar o para probar qu es esto de Oracle, es recomendable que se utilic Developer pues es mucho ms fcil e intuitivo al principio. 2. Explorador de servidores para base de datos de oracle Las bases de datos de Oracle presentan algunas diferencias en el Explorador de servidores. Por ejemplo, cuando agrega una conexin a una base de datos de Oracle, ver las siguientes carpetas: Diagramas de base de datos, Tablas, Sinnimos, Vistas, Procedimientos almacenados, Funciones, Especificaciones de paquete y Cuerpos de paquete. En los siguientes temas se describen brevemente cada uno de los objetos del Explorador de servidores para bases de datos de Oracle. 3. Diagramas de base de datos

La carpeta Diagramas de base de datos contiene diagramas con nombre que muestran la estructura de la base de datos de forma grfica. 4. Tablas

La carpeta Tablas contiene las tablas base de la base de datos. Visual Database Tools le ayuda a realizar modificaciones en la base de datos. Es posible controlar cundo y cmo se guardarn los cambios realizados a una base de datos creada en un diagrama de base de datos. Para ello, se deben anotar los objetos que han sido modificados y los que no han sufrido cambios en el diagrama de base de datos, guardar nicamente los cambios realizados en las tablas seleccionadas y descartar los cambios no deseados. Tambin puede utilizar secuencias de comandos de cambio SQL para hacer un seguimiento de los cambios, descartarlos y aplicar cambios no guardados. 5. Sinnimos La carpeta Sinnimos contiene nombres alternativos para las tablas, vistas, secuencias, procedimientos almacenados, funciones, paquetes e instantneas. Puede utilizar sinnimos para tener acceso fcilmente a los objetos de base de datos sin utilizar calificadores. 6. Para crear un nuevo sinnimo Desde una consulta o secuencia de comandos SQL, ejecute la siguiente instruccin: create synonym name for table Sustituya name por el nombre del sinnimo y table por el nombre de la tabla.

7.

Para recuperar datos de un sinnimo

En el Explorador de servidores, haga clic con el botn secundario del mouse (ratn) y elija Recuperar datos de sinnimo. Una cuadrcula muestra el propietario, nombre de columna, tipo de tabla, precisin, etc., para las columnas accesibles de todas las tablas, vistas y clsteres. 8. Vistas La carpeta Vistas contiene bloques con nombre de cdigo SQL que filtran los datos disponibles de las tablas subyacentes. 9. Funciones La carpeta Funciones contiene bloques con nombre de cdigo SQL que puede devolver valores a un programa de llamada. Para obtener informacin adicional sobre cmo trabajar con funciones 10. Especificaciones del paquete La carpeta Especificaciones del paquete contiene grupos con nombre de procedimientos pblicos, funciones, excepciones, variables, constantes y cursores. Las especificaciones de paquete resultan tiles para compartir datos y aumentar la eficiencia. 11. Para crear una nueva especificacin de paquete En el Explorador de servidores, haga clic con el botn secundario del mouse en el nodo Especificaciones del paquete y elija Nueva especificacin de paquete en el men contextual. En el editor se muestra una plantilla con la sintaxis correcta de Oracle para especificaciones de paquete. CREATE OR REPLACE PACKAGE USER.PACKAGE1 AS /* FUNCTION FUNCTION_NAME( PARAMETERS ) RETURN DATATYPE; PROCEDURE PROCEDURE_NAME( PARAMETERS ); */ END; Para editar una especificacin de paquete En el Explorador de servidores, haga clic con el botn secundario del mouse y elija Editar especificacin de paquete en el men contextual. En el editor se muestra el cdigo SQL para la especificacin de paquete. 12. Cuerpos de paquete La carpeta Cuerpos de paquete contiene cuerpos de paquete con nombre creados a partir de especificaciones de paquete. 13. Para crear un nuevo cuerpo de paquete En el Explorador de servidores, haga clic con el botn secundario del mouse en el nodo Cuerpos de paquete y elija Nuevo cuerpo del paquete en el men contextual. En el editor se muestra una plantilla con la sintaxis correcta de Oracle para cuerpos de paquete. CREATE OR REPLACE PACKAGE BODY USER.PACKAGE1 AS /* FUNCTION FUNCTION_NAME( PARAMETERS ) RETURN DATATYPE; IS RETURN_VARIABLE DATATYPE;

BEGIN END; PROCEDURE PROCEDURE_NAME( PARAMETERS ); AS BEGIN END; */ END; 14. Para editar un cuerpo de paquete En el Explorador de servidores, haga clic con el botn secundario del mouse y elija Editar cuerpo de paquete en el men contextual. En el editor se muestra el cdigo SQL para el cuerpo de paquete. CAPITULO III DESARROLLO 3.1 INTRODUCCIN: En la actualidad, la utilizacin de metodologas para el desarrollo de aplicaciones es casi imposible omitirla, debido a la gran necesidad de control de variables que conlleva el mismo desarrollo, y para la ordenada elaboracin de las aplicaciones, por lo tanto, seguir metodologas y estndares nos llevan a estar en competitividad en todo momento. Es de suma importancia conocer el modo como se interrelacionan metodologas con estndares y herramientas siguiendo un nico propsito, el cual consiste en la elaboracin de aplicaciones de manera eficiente, ordenada y con el menor nmero de defectos. La metodologa RUP nos proporciona disciplinas en las cuales se encuentran artefactos con lo cual se podr contar con guas para poder documentar e implementar de una manera fcil y eficiente, todas las guas para un buen desarrollo, todo esto dentro de las respectivas fases con las cuales cuenta. No es posible realizar un desarrollo de software de una manera lenta, ya que las exigencias de los clientes actuales conllevan a verse en la necesidad de implementar soluciones rpidas y que cumplan con los requerimientos planteados, por lo que el Desarrollo Rpido de Aplicaciones es una de las caractersticas que ms impacto tiene en la actualidad, para solventar esto se deben utilizar herramientas basadas en este nuevo enfoque. Durante el desarrollo del presente capitulo se define el marco de trabajo y las tareas que se requieren para desarrollar, construir implementar el sistema de control de pago de pensiones, con el que se pretende cumplir con los objetivos trazados y dar solucin a la problemtica presentado en la institucin. Para la construccin del sistema de control de pago de pensiones del CPRGB, se optado por usar la metodologa RUP ( Proceso Racional Unificado). A continuacin se desarrolla en detalle cada una de las fases del ciclo de vida o de desarrollo de RUP y los flujos de trabajo sobre los cuales iteran. 3.2 FASE INICIO 1. Propsito alcance y Espacio del proyecto El propsito del presente proyecto es disear, desarrollar e implementar un sistema de informacin computarizado para el control de pago de pensiones para la administracin del colegio CPRGB que manipule y administre toda la informacin concerniente al cobro de pago de pensiones. Con el desarrollo del sistema de control de pago de pensiones del CPRGB, se busca dar solucin a los problemas presentados en la institucin de forma eficiente y eficaz, empleando informacin confiable y segura.

2.

REQUERIMIENTOS DEL SISTEMA

Dentro los alcances del proyecto, el sistema de control de pago de pensiones del CPRGB permitir cumplir los requerimientos del sistema de cobro de pensiones. Estos requerimientos se pueden diferenciar en los siguientes subsistemas o mdulos. 3. Pago de Mensualidad Registra de pago de mensualidad. Realizar informes y reportes sobre los ingresos (pago de pensin). Genera comprobante de pago (Emitir Factura) REQUERIMIENTO TECNOLOGICO

En el requerimiento de software el lenguaje de programacin Eclipse, como motor de base de datos MYSQL que es eficiente y segura. La institucin CPRGB no cuenta con ningn tipo de red por lo cual se optara por un enlace de red local. 4. PLANIFICACIN INICIAL DEL PROYECTO:

Para poder cumplir con los objetivos establecidos en el proyecto y desarrollar todas las fases que contempla la metodologa RUP, es necesario realizar una planificacin temporal respecto al tiempo de trabajo que tomara la conclusin del sistema de control de pago de pensiones del CPRGB. La planificacin del presente proyecto estar en base al tiempo estimado por la institucin CPRGB.

Realizar el modelo de requisitos que incluya: Identificacin de los casos de negocio Descripcin de los casos de uso Definicin del Modelo Conceptual Diagrama de Estados 5. a) EL CASO DEL NEGOCIO Descripcin de sistema El caso del negocio proporciona la informacin necesaria, desde el punto de vista del sistema El sistema de control de pago de pensiones del CPRGB, esta diseado para realizar el control y administracin de los ingresos en la institucin por concepto cobro de pago de pensiones, dando una solucin eficaz y eficiente. Adems el sistema se encargara de automatizar las tareas como: Paga Mensualidad, Registra en Sistema, Emite Factura. hijo(s). b) Registro de pago de mensualidad. Primero el encargado verifica si tiene deudas, una vez verificada la Realizar informes y reportes sobre los ingresos (pago de pensin). Genera comprobante de pago (Emitir Factura) Identificacin de Subsistemas deuda se registra el monto recibido. Paga Mensualidad: Cobro de pensiones . el padre de familia solicita pagar la pensin de su(s)

Los subsistemas identificados estn en relacin al alcance del proyecto. Para desarrollar el Sistema de control de pago de pensiones del CPRGB se identificaron los siguientes subsistemas o mdulos. Es importante sealar que existe dependencia entre los subsistemas anteriormente indicados, es por eso que analizando los elementos compartidos entre ellos, o las interfaces entre subsistema, se logra determinar que uno depende del otro y viceversa.

c) d)

Descripcin de los subsistemas.- La descripcin de cada sistema es como sigue: Verificacin de Cdigo de estudiante. Verifica deuda.

- Subsistema de paga mensualidad

- Subsistema Registro de pago de mensualidad: Comprende: Registro de pago Actualizacin del registro de pago.. Generar Informes y reportes: Comprende Reportes de ingresos. Actualizacin de reportes. Emite Factura: Comprende Confirmacin de Cdigo de estudiante. Generacin de recibo o factura Gestin de riesgos.- El riesgo es un problema potencial que puede ocurrir o no, y que puede afectar a los futuros acontecimientos. Por esta razn es necesario evaluar su probabilidad de aparicin, estimar su impacto y establecer un plan de contingencia.

6. -

Identificacin del riesgo.- El mtodo que utilizamos para identificar los riesgos es una lista de Definicin del proceso.

comprobacin de elementos de riesgo: El tamao de la base de datos a crear es grande? Nmero de usuarios del sistema es grande? La cantidad de software reutilizable es considerable? Entorno de desarrollo. Se tiene disponible las herramientas de gestin del proyecto de software? Existen herramientas de anlisis y diseo disponibles? Proporcionan las herramientas de anlisis y diseo mtodos apropiados para el producto a construir? Existen expertos disponibles para responder todas las preguntas sobre las herramientas? Con el Usuario. Entiende el usuario el proceso del software? El Usuario est dispuesto en invertir su tiempo en reuniones y revisiones del producto que requiere? Tecnologa a construir. Es necesaria para la institucin la tecnologa a construir? Es nueva la tecnologa que se va a construir? El software interacta con hardware nuevo o no probado? 7. 8. SCPP. Costos directos: Son aquellos recursos utilizados en el desarrollo del sistema desde el inicio hasta su finalizacin y entrega al usuario. Costos indirectos: Estos solo sern de apoyo, no implicaran dentro del proyecto, ya que solo son materiales extras que son necesarios para el desarrollo del sistema 3.2.4 MODELO DEL NEGOCIO El modelo de negocio del proyecto est enmarcado dentro de las delimitaciones del contexto del sistema y describe los procesos exactos relacionados con los actores y casos de uso encontrados. a) Actores del Negocio Proyeccin del riesgo.- Los riesgos ms altos identificados en el proyecto son los siguientes: Estimacin del tamao de software Mayor nmero de usuarios de lo previsto Falta de informacin sobre las herramientas Falta de capacitacin al usuario Anlisis de costos.- En este punto se presenta una estimacin del costo que implica el desarrollo del

b) c) negocio.

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

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

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

Casos de uso : Paga mensualidad

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

3.4. DIAGRAMA DE COMUNICACIN:

3.5. DIAGRAMA DE CLASES DEL SISTEMA:

3.6. CONCLUSIN:

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

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

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

3.7. BIBLIOGRAFA:

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

http://atenea.ucauca.edu.co/~gramirez/archivos/AnotacionesRUP.pdf Ramrez Gonzlez, Gustavo A., Laboratorio III de Electrnica, Anotaciones RUP, 2001. http://davidfrico.com/rup-slc.pdf Rational Unified Process Software Life Cycle .Una tabla resumen de los flujos, trabajadores y productos. 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 http://www.rational.com/products/rup/faq.js p FAQ sobre RUP. http://www.yoopeedoo.com/upedu/, Pagina web de UPEDU (Unified Process for EDUcation). http://www.yoopeedoo.com/upedu/process /artifact/tmpl_cs/ovu_tmplcs.htm Ejemplo1. http://www.public.iastate.edu/~shaf2/cs36 2_main.htm Ejemplo 2. Plataforma de software WebSphere http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd Introduccin al UML http://www.yoprogramo.com/articulo4.php Metodologa de desarrollo de sistemas basados en el ciclo de vidahttp://comip.mendoza.gov.ar/metodologia%20para%20el%20desarrollo%20de%20sistemas.pdf

12. Aprendiendo UML en 24 horas. Schmuller, Joseph. Editorial Prentice Hall, Mxico, 2000. 13. Rational Rapid Developer, Technical Overview. IBM, Rational Software, 2003 14. Productos y servicios de software WebSpherehttp://www.ibm.com/pe/products/software/websphere/ 15. Tesis consultadas para anlisis estructurado