S9 MD D Metodología XP

S8 MD D Metodología XP

S6 TP D Relaciones y Consultas Multitablas En la Base de Datos

RELACIONES EN LA BASE DE DATOS:

 La relación es una asociación establecida entre campos comunes (columnas) en dos tablas. Los campos que entran en relación pueden llamarse de distinta manera, pero tienen que ser del mismo tipo de datos. La relación permite al motor de Acces, encontrar datos relacionados en ambas tablas. Por ejemplo podemos encontar NOMBRE, APELLIDO (de la tabla EMPLEADO_PERSONAL), SALARIO, y DEPART (de la tabla EMPLEADO_LABORAL) de uno o varios empleados.

Las relaciones pueden ser de tres tipos:

•  De uno a uno.
•  De uno a varios.
•  De varios a varios.        

CONSULTAS MULTITABLAS EN LA BASE DE DATOS:

Las consultas multitabla llamadas así porque están basadas en más de una tabla.

El SQL de Microsoft Jet 4.x soporta dos grupos de consultas multitabla:

• La unión de tablas

Esta operación se utiliza cuando tenemos dos tablas con las mismas columnas y queremos obtener una nueva tabla con las filas de la primera y las filas de la segunda. En este caso la tabla resultante tiene las mismas columnas que la primera tabla (que son las mismas que las de la segunda tabla).Por ejemplo tenemos una tabla de libros nuevos y una tabla de libros antiguos y queremos una lista con todos los libros que tenemos. En este caso las dos tablas tienen las mismas columnas, lo único que varía son las filas, además queremos obtener una lista de libros (las columnas de una de las tablas) con las filas que están tanto en libros nuevos como las que están en libros antiguos, en este caso utilizaremos este tipo de operación.

• La composición de tablas

La composición de tablas consiste en concatenar filas de una tabla con filas de otra. En este caso obtenemos una tabla con las columnas de la primera tabla unidas a las columnas de la segunda tabla, y las filas de la tabla resultante son concatenaciones de filas de la primera tabla con filas de la segunda tabla.

Por ejemplo queremos listar los pedidos con el nombre del representante que ha hecho el pedido, pues los datos del pedido los tenemos en la tabla de pedidos pero el nombre del representante está en la tabla de empleados y además queremos que aparezcan en la misma línea; en este caso necesitamos componer las dos tablas (Nota: en el ejemplo expuesto a continuación, hemos seleccionado las filas que nos interesan).

S7 MD D Ejemplo De Caso De Uso

S6 MD D Metodología y Filosofía RUP

METODOLOGÍA RUP

La metodología RUP , abreviatura de Rational Unified Process (o Proceso Unificado Racional), es un proceso propietario de la ingeniería de software creado por Rational Software , adquirida por IBM , ganando un nuevo nombre Irup que ahora es una abreviatura Rational Unified Process y lo que es una marca en el área de software, proporcionando técnicas que deben seguir los miembros del equipo de desarrollo de software con el fin de aumentar su productividad en el proceso de desarrollo.

FASES DE LA METODOLOGÍA RUP

FASE DE DISEÑO

La fase de diseño o de iniciación contiene los flujos de trabajo necesarios para el acuerdo de las partes interesadas – interesados – con los objetivos, la arquitectura y la planificación del proyecto. Si estos actores tienen un buen conocimiento, no será necesario analizar. De lo contrario, se requiere un análisis más elaborado.

En esta etapa, los requisitos esenciales del sistema se transforman en los casos de uso. El objetivo no es para cerrarlas en absoluto, sino sólo las que sean necesarias para dar forma a la opinión.    

El paso es generalmente corto y se utiliza para definir si es factible para continuar con el proyecto y definir los riesgos y el coste de la última. Un prototipo se puede hacer para que el cliente apruebe. Como cita el RUP, lo ideal es realizar iteraciones , las cuales deben estar bien definida en cuanto a su importe y objetivos.

FASE DE ELABORACIÓN

La preparación será para el diseño del sistema, como complemento de la encuesta y / o documentación de casos de uso, frente a la arquitectura del sistema, revisar el modelo de negocio para el proyecto e iniciar la versión del manual del usuario. Uno debe aceptar:

Descripción del producto (aumento + integración) es estable el plan del proyecto es fiable los costos son elegibles.

FASE DE CONSTRUCCIÓN

En la fase de construcción, el desarrollo físico del software se inicia, códigos de producción, pruebas alfa. Pruebas beta se llevaron a cabo al inicio de la fase de transición.

Se debe aceptar las pruebas, procesos estables y de prueba, y el código del sistema son línea de base.

FASE DE TRANSICIÓN

En esta fase es la entrega ( «despliegue») de software, que se lleva a cabo el plan de despliegue y entrega, el seguimiento y la calidad del software. Productos (lanzamientos, las versiones) se van a entregar, y coloque la satisfacción del cliente. Esta etapa también se lleva a cabo la formación de los usuarios.

                                                PRINCPIO DE DESARROLLO

LA FILOSOFÍA RUP

• ADAPTAR EL PROCESO:

El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto, el tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto.

•   EQUILIBRAR EL PROCESO

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados.

Debe poder encontrarse un equilibrio que satisfaga los deseos de todos .Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.

•   DEMOSTRAR VALOR INTERATIVAMENTE

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.

• COLABORACIÓN ENTRE EQUIPOS

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

•  ENFOCARSE EN LA CALIDAD

El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos dela producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente, también es una estrategia de desarrollo de software.

•   ELEVAR EL NIVEL DE ABTRACCIÓN

Este principio dominante motiva el uso de conceptos reutilizables tales como patrones de diseño del software, lenguajes 4GLo esquemas (frameworks) por nombrar algunos. Estos se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.

S5 TP D Consulta De Base De Datos SQLSERVER

¿QUÉ ES UNA BASE  DE DATOS?

Una base de datos se puede definir como un conjunto de información relacionada que se encuentra agrupada ó estructurada.

Desde el punto de vista informático, la base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulen ese conjunto de datos.

Cada base de datos se compone de una o más tablas que guarda un conjunto de datos. Cada tabla tiene una o más columnas y filas. Las columnas guardan una parte de la información sobre cada elemento que queramos guardar en la tabla, cada fila de la tabla conforma un registro.

CONSULTA DE DATOS

Para realizar consultas sobre las tablas de las bases de datos disponemos de la instrucción SELECT. Con ella podemos consultar una o varias tablas. Es sin duda el comando más versátil del lenguaje SQL.

Existen muchas cláusulas asociadas a la sentencia SELECT (GROUP BY, ORDER, HAVING, UNION).

Hay   consultas simples, basadas en una sola tabla. Veremos cómo obtener filas y columnas de una tabla en el orden en que nos haga falta.

El resultado de una consulta SELECT nos devuelve una tabla lógica. Es decir, los resultados son una relación de datos, que tiene filas/registros, con una serie de campos/columnas. Igual que cualquier tabla de la base de datos. Sin embargo esta tabla está en memoria mientras la utilicemos, y luego se descarta. Cada vez que ejecutamos la consulta se vuelve a calcular el resultado.

La sintaxis básica de una consulta SELECT es la siguiente (los valores opcionales van entre corchetes):

SELECT  [ ALL  /  DISTINC ]  [  *  ]  /  [ListaColumnas_Expresiones] AS [Expresion]

FROM Nombre_Tabla_Vista

WHERE Condiciones

ORDER BY ListaColumnas [ ASC / DESC ]

 CAMPOS DE UNA TABLA (SELECT )

SELECT *

FROM CLIENTES

Con el * indicamos que queremos devolver todos los campos. Si CLIENTES dispone de los

campos idCliente, nombre y descripcion, lo anterior sería equivalente a:

SELECT idCliente, nombre, descripcion

FROM CLIENTES

Obviamente, al querer todos los campos, esto es innecesario y es por tanto más conveniente

emplear el asterisco (*). También sería equivalente emplear la notación completa:

SELECT CLIENTES.idCliente, CLIENTES.nombre, CLIENTES.descripcion

FROM CLIENTES

Al tener únicamente una tabla involucrada, podemos referirnos a los campos sin calificar, dado

que no hay duda de a qué tabla se refiere. Cuando veamos consultas sobre varias tablas

comprenderemos la necesidad de incluir esta notación calificada (TABLA.campo).

Devolver un subconjunto de los campos de una tabla (SELECT DISTINCT)

SELECT cp, ciudad

FROM DIRECCION

Esta consulta devolverá únicamente los campos cp (código postal) y ciudad de la tabla

DIRECCION. Al tener un subconjunto de los campos, éstos no tienen por qué incluir a la clave

de la tabla, por lo que no tienen por qué ser únicos. Así, si tenemos muchos registros referidos

a distintas calles y números de ese mismo código postal y ciudad, nos encontraremos muchos

registros repetidos. Esto puede evitarse haciendo:

SELECT DISTINCT cp, ciudad

FROM CLIENTES

Así se eliminan los registros repetidos, devolviendo únicamente una vez cada par cp, ciudad.

Esta selección de un subconjunto de los datos de la tabla y excluyendo repetidos se denomina

en álgebra relacional proyección.

S5 MD D- Proceso Unificado De Rational (RUP)

PROCESO UNIFICADO DE RATIONAL (RUP)

El Proceso Unificado de Rational o RUP (por sus siglas en inglés de Rational Unified Process) es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM.1 Junto con el Lenguaje Unificado de Modelado (UML), constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.

PROCESO DIRIGIDO POR CASOS DE USOS

Los casos de uso no son sólo una herramienta para especificar los requisitos del sistema, sino que también guían su diseño, implementación y prueba. Los casos de uso constituyen un elemento integrador y una guía del trabajo.

Los casos de uso Inician el proceso de desarrollo y proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo.

Basándose en los casos de uso, se crean los modelos de análisis y diseño, luego la implementación que los lleva a cabo, y se verifica que efectivamente el producto implemente adecuadamente cada caso de uso.

PROCESO CENTRADO EN LA ARQUITECTURA 

La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo.

En el caso de RUP, además de utilizar los casos de uso para guiar el proceso, se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.

Existe una interacción entre los casos de uso y la arquitectura, los casos de uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, actualmente y en el futuro.

La arquitectura dentro de RUP se representa en varias vistas. Todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura. Según Kruchten Philippe (1998) “el cual recibe este nombre porque lo forman las vistas lógica, de implementación, de proceso y de despliegue, más la de casos de uso que es la que da cohesión a todas”.

Al final de la fase de elaboración se obtiene una “baseline” (base de referencia) de la arquitectura donde fueron seleccionados una serie de casos de uso arquitectónicamente relevantes (aquellos que ayudan a mitigar los riesgos más importantes, aquellos que son los más importantes para el usuario y aquellos que cubran las funcionalidades significativas).

                                            

PROCESO ITERATIVO E INCREMENTAL 

El equilibrio correcto entre los casos de uso y la arquitectura es muy parecido al equilibrio de la forma y la función en el desarrollo de un producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Cada mini proyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto.

Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando se termina. Durante la planificación de los detalles de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con la versión actual del producto.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones (que son una cantidad variable) según el proyecto, y en las que se hace un mayor o menor hincapié en los distintas actividades.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una “baseline” (base de referencia) de la arquitectura.

Para cada iteración se escogen algunos casos de uso, se refina su análisis y diseño, y se procede a su implementación y pruebas. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar, en cada fase participan todas las disciplinas, pero, dependiendo de la fase, es el esfuerzo dedicado a una disciplina.