domingo, 13 de febrero de 2011

1.4 Problemas comunes en el dearrollo y uso de aplicaciones distribuidas.

El desarrollo de aplicaciones distribuidas requirió de nuevas técnicas de diseño y de generación de modelos. También trajo nuevos problemas. Existen 2 tipos distintos de arquitecturas que se utilizaron antes de .NET para hacer aplicaciones distribuidas: Llamadas a Procedimiento Remoto (RPC) Arquitecturas basadas en mensajes

Se verán los problemas técnicos que este tipo de arquitecturas tiene y finalmente como los Estándares Web son utilizados para hacer la nueva generación de aplicaciones distribuidas

Hay una serie de problemas comunes en el diseño de las aplicaciones distribuidas:

La compatibilidad de los Tipos de Datos: Distintos sistemas operativos tienen diferentes tipos de datos que no son siempre compatibles entre sí.

Fallas del Servidor: Debido a que los componentes pueden ser remotos, una falla de cualquiera de ellos puede hacer que toda la aplicación falle .

Fallas del Cliente: El servidor debe saber como responder a las fallas del cliente.

Reintento de llamadas: Si por ejemplo, se hace una llamada a un método en un servidor para generar una orden de compra muy grande, y el servidor responde pero se pierde la respuesta por fallas de red, no es muy eficiente volver a enviar la orden de compra.

Seguridad: En aplicaciones distribuidas los problemas de seguridad se multiplican. Por ejemplo, se debe considerar como: Autenticar a los usuarios Autorizarlos a acceder a los recursos Encriptar la información que viaja por la red Evitar ataques de denegación de servicio

Sincronización de la hora: Hay operaciones que dependen de la fecha y la hora. Por ejemplo, no es lógico en una aplicación procesar un envío de mercadería antes de haber recibido la orden de compra. Si el cliente y el servidor tienen fechas distintas, se debe generar un mecanismo de sincronización de hora para evitar este problema.

La arquitectura basada en RPC Qué es RPC: RPC son llamadas a procedimientos o funciones en sistemas remotos, es decir en máquinas distintas a la máquina local. Transparencia de localización: El desarrollador utiliza los componentes sin necesidad de saber su ubicación física. Con RPC tanto en el cliente como en la máquina donde reside el componente hay subsistemas que se ocupan de la comunicación y el intercambio de datos.

Llamadas Sincrónicas: En RPC las llamadas a los procedimientos son sincrónicas. Esto quiere decir que cuando una aplicación hace una llamada a un procedimiento RPC debe esperar que el servidor le responda para poder continuar con el procesamiento. Esto presenta problemas en un entorno distribuido, mucho más si pensamos en distribuir los componentes en Internet.

Las llamadas sincrónicas con RPC tienen desventajas: Uso de múltiples componentes: Si su aplicación distribuida depende de muchos componentes que se llaman entre sí, esto hace que la aplicación sea más susceptible a fallas. Balanceo de Carga y Tolerancia a fallos: Es el problema de como las aplicaciones descubren la información necesaria para poder conectarse otros servidores en el caso de que el que esta utilizando falle. O de como balancean el procesamiento entre varios servidores Esto no es posible con RPC.

Priorización: Con RPC es muy difícil detectar que servidores están con mucha carga de trabajo y derivar la llamada RPC a otro servidor menos ocupado.

Picos de carga de Trabajo: RPC no puede manejar los picos de carga de trabajo que puede tener un servidor si tiene llamadas RPC de muchos clientes.

La arquitectura basada en Mensajes Otra arquitectura para desarrollar aplicaciones distribuidas es la basada en mensajes.

Esta tecnología es asincrónica. Lo que significa que el cliente puede seguir con el procesamiento mientras espera la respuesta del servidor. Utiliza mensajes en vez de llamadas a funciones.

Tiene desventajas:
Procesamiento del Mensaje: El programador debe manejar en el código el empaquetamiento y des empaquetamiento de los mensajes. Además debe controlar su validez Interoperabilidad: Los sistemas de mensajería utilizan tecnología propietaria. Se necesita software para permitir el envío de mensajes y la comunicación los distintos sistemas.
Flujo de Carga y secuenciamiento de los mensajes: Se necesita de algún mecanismo para coordinar el flujo y la secuencia de los mensajes. Por ejemplo, no se puede procesar una orden de envío de un producto antes de que se procesa la orden de pedido del producto.

Los estándares Web Tanto RPC como la arquitectura basada en mensajes han sido implementados en forma exitosa por muchas organizaciones. Sin embargo su uso tiene dificultades que se resuelven con la utilización de los protocolos Web estándares.

Problemas con los Protocolos Binarios: Existen varias tecnologías RPC, ninguna estándar, por ejemplo. COM de Microsoft, CORBA y RMI. Todas estas tecnologías utilizan protocolos binarios.
Los protocolos binarios tienen desventajas:
Firewall: Para permitir la comunicación entre un cliente y un servidor que se encuentra detrás de un firewall los administradores deben dejar un rango variable de puertos abiertos. Esto es un riesgo de seguridad muy alto.

Interoperatividad: Las distintas tecnologías RPC implican protocolos binarios de comunicación distintos. Para que interoperen entre sí se deben traducir los paquetes de red lo que puede significar pérdida de información. Para evitar este problema las organizaciones utilizan un solo modelo RPC.

Formato de los Datos: Cada protocolo RPC utiliza un formato de datos distintos. La traducción de un formato a otro presenta dificultades.

La nueva arquitectura: Los protocolos que utiliza Internet resuelven muchos de los problemas anteriormente mencionados. Internet y la Web: Los protocolos TCP e IP fueron desarrollados originalmente para conectar redes distintas y crear una red de redes. Esta red de redes terminó convirtiéndose en el Internet que conocemos hoy. A finales de 1990, Tim Berners-Lee inventó WWW (World Wide Web).

WWW es lo que hoy conocemos como la Web. La Web es una red globalmente interconectada de documentos hipertexto. Utiliza 2 tecnologías principales: El lenguaje HTML y el protocolo HTTP para la comunicación. HTML: Es un lenguaje de marcas (Tags). Las marcas definen como el Explorador de Internet presenta la información. Los documentos que tienen estas marcas son llamados documentos hipertexto.

Ventajas de HTTP:
Es el protocolo utilizado para pedir y recibir documentos. El formato de estos documentos puede ser HTML pero también muchos otros más como por ejemplo XML. Los Servicios Web y los clientes pueden intercambiar documentos XML utilizando el protocolo HTTP. HTTP es un Standard usado universalmente

XML- Un formato de datos universal: A pesar de que HTML permite presentar datos, HTML no permite comunicar la estructura de los datos y su relación. XML nació en 1996 para permitir describir la estructura de los datos en un documento. Firewall: Los servidores Web son los responsables de administrar los documentos, que pueden ser accedidos desde Internet pasando por el firewall de la organización y utilizando el protocolo HTTP.

Problemas con la Web:
Como la Web es una red pública se presentan algunos problemas.

Seguridad: Entre otros problemas se encuentran: el robo de información o la modificación de los datos

Performance: Algunos clientes acceden con conexiones telefónicas lo que puede limitar por su baja velocidad la complejidad de las aplicaciones.

Por lo tanto algunas aplicaciones se deben limitar a la Intranet.

1.3 Escenarios de utilización de las aplicaciones distribuidas.


Algunas de las aplicaciones distribuidas más conocidas son remote login, correo electrónico, navegación Web, streaming, telefonía IP y compartición de ficheros (P2P).

Algunos escenarios que utilizan aplicaciones distribuidas son:

• PHP
Eduacaión a distancia - moddle.
Creación de blogs - Wordpress.
Creador de wikis - MediaWiki.
Administrar BD en web - PHPMyAdmin.

• ASP
E-commerce - eCAM.
E-commerce - ProdMentor.

Hoy en día no parece necesario convencer a nadie de las ventajas que para una empresa de cualquier tamaño supone una informatización bien dimensionada y acorde a las necesidades de la misma. Hasta la aparición del ordenador personal en el año 1982, la informatización de las empresas estaba muy condicionada a su tamaño, ya que el coste de un supercomputador o incluso un miniordenador los hacían prohibitivos. Con la aparición del ya bien conocido Personal Computer, la informática se ha extendido a todos los entornos de nuestra sociedad, incluido el residencial, donde cada día es mayor el número de hogares que posee un ordenador.
La fuerte evolución que se ha producido en las prestaciones de los ordenadores junto con el abaratamiento de los mismos han provocado la aparición de programas con mayores posibilidades, de muy fácil manejo, y adecuados para casi cualquier tipo de aplicación que podamos necesitar. Hoy día es difícil encontrar empresas en las que en un alto porcentaje de su desarrollo no se haya adaptado, configurado o utilizado un producto ya disponible en el mercado, e.g., bases de datos, hojas de cálculo, control de procesos, etc.

En la actualidad existe un fenómeno similar a la evolución descrita de la informática y con un impacto muy importante sobre ésta. Nos referimos a las telecomunicaciones. No hace mucho tiempo, la interconexión de ordenadores y terminales dentro de una empresa mediante redes de área local o mediante diversas soluciones de distintos centros de éstas (centros de procesos de datos, sucursales, etc.) estaba restringida a entidades de un tamaño importante. Este hecho también está evolucionando de forma rápida y la utilización de las telecomunicaciones en forma integrada con programas informáticos está dejando de ser un aspecto restringido a grandes empresas. Hoy se puede observar que existen soluciones de muy bajo coste y unas altas prestaciones. Desde un simple módem hasta las altas prestaciones y calidad que ofrece la red digital de servicios integrados (el RDSI es una red de comunicaciones digitalizada y totalmente desplegada, que proporciona unas prestaciones superiores a las que presenta la red de telefonía básica), son soluciones asequibles tanto para profesionales independientes como para empresas de cualquier tamaño.

Estos acontecimientos han provocado una fuerte evolución en los programas informáticos. La integración de las telecomunicaciones en la informática corporativa hace unos años era escasa, existiendo aplicaciones informáticas dirigidas a la comunicación y otras únicamente orientadas al proceso de datos disponibles localmente. El término telemática era utilizado en ese momento para las técnicas de transferencia de datos que serían utilizados con posterioridad por aplicaciones informáticas.

En la actualidad esto no es así, las telecomunicaciones son algo que, aunque imprescindibles ya que permiten procesar datos ubicados en ordenadores o terminales remotos, resultan trasparentes a las aplicaciones informáticas.

Con una apropiada integración informática-telecomunicaciones en una corporación se persigue que el usuario pueda usar diversas aplicaciones informáticas de forma uniforme en toda la organización y con abstracción total del lugar donde se encuentren o se generen los datos. Hoy día no se puede concebir y diseñar el soporte informático de una empresa de cualquier tamaño sin tener en cuenta las telecomunicaciones que vaya a emplear.
Algunos ejemplos muy extendidos y que siguen este esquema son las bases de datos distribuidas (bases de datos donde los datos se encuentran en cualquier punto de la red) o las aplicaciones cliente-servidor donde el procesamiento de los datos de la aplicación se puede llevar a cabo en cualquiera de los ordenadores conectados a la red con total trasparencia para el usuario, actuando como un verdadero sistema operativo distribuido.
Aunque en este artículo se pretende dar una visión de las ventajas que una apropiada informatización supone para una empresa y en especial para las PYMES, se hará especial hincapié en las nuevas oportunidades que la integración telecomunicaciones-informática ofrece.
Un claro ejemplo es el fenómeno que ha supuesto en todos los sectores tanto empresariales como domésticos la aparición de Internet. Aunque existe una gran cantidad de documentación divulgativa y técnica al respecto o la que el lector se puede dirigir, se analizará aquí el alto valor añadido que para la pequeña y microempresa pueden ofrecer Internet. Este hecho se ve potenciado además por la rápida reducción de costes que se está produciendo en las tecnologías asociadas a este tipo de servicio.

La combinación de informática y telecomunicaciones abre, además, un nuevo espacio virtual para el comercio donde las empresas, sean del tamaño que sean, pueden ofrecer sus servicios y competir en igualdad de condiciones. Esto es posible gracias a los mínimos recursos que se precisan para entrar en este mercado y a la transferencia de costes que se consigue realizar a los clientes y proveedores.

Las consideraciones que deben tenerse en cuenta para una correcta integración de programas de diverso tipo con las telecomunicaciones corporativas independientemente de la tecnología de red utilizada, o mejor dicho algunas de las múltiples ventajas que la correcta informatización de una empresa puede ofrecer a ésta y que se pueden ver muy incrementadas con una apropiada integración con las telecomunicaciones de la corporación y todo ello a un coste muy reducido, lo que lo hace extensivo a las PYMES, son:

• Mejora de prodecimientos internos de trabajo de la empresa.- Este es probablemente el ejemplo que todo el mundo tiene más claro por ser quizás el origen de la informática en la empresa. Con la integración de las telecomunicaciones entre distintos centros de la empresa esta ventaja es extensible a toda la corporación. Este punto tiene además una ventaja adicional: permite reducir sustancialmente los recursos de la empresa dedicados a tareas rutinarias y permite concentrar dichos recursos en la actividad propia de la empresa, favoreciendo la creatividad y la iniciativa de sus trabajadores.

• Mejora en la relación con los clientes y proveedores.- El disponer de toda información de los clientes de una empresa "on line", o lo que es lo mismo, disponible en el momento en que exista cualquier relación con él, permite ofrecer una atención personalizada, lo que conducirá a una mejora sustancial de la imagen de la empresa. Por supuesto, una utilización conjunta de aplicaciones informáticas y comunicaciones permitirán ofrecer esta información "on line" a toda la corporación. Disponer de un sistema informatizado para la relación con los proveedores es tan importante como tener una relación ágil con los clientes. Con la ayuda de las telecomunicaciones podremos conseguir automatizar toda la gestión de pedidos, facturación, pagos, control de plazos de entrega, etc. lo que significará sin duda en un alto beneficio para el negocio. El hecho de poder llevar a cabo las relaciones de una empresa con sus clientes y proveedores de manera informatizada permite además una reducción importante de costes.

• Nuevos canales de distribución.- Las redes de telecomunicaciones pueden ofrecer a las empresas un nuevo canal de distribución de productos. Pensemos en la gran cantidad de empresas que en la actualidad, anuncian y ofrecen sus productos a través de Internet. Términos como Telemárketing y Telemercado serán cada día más comunes para todos.

• Mayor control del negocio mediante los sistemas de información.- La capacidad de obtener información de forma contínua de un proceso productivo que ofrecen los programas informáticos permite a la dirección de la empresa, disponer de una visión actualizada en todo momento de la situación del negocio. Pensemos en los esfuerzos requeridos en el pasado para realizar el balance de la empresa, en contraposición con las empresas modernas con un sistema de información totalmente informatizado donde se puede conocer la situación económica de ésta en cada momento.

Clave en procesos de reingeniería y de calidad.- Es cada vez mayor el número de empresas sometidas a procesos internos de Reingeniería o de Gestión de la Calidad Total. Estos procesos van dirigidos a realizar un análisis permanente de los distintos procesos productivos de una empresa con objeto de conseguir una mejora contínua en los mismos. Estos procesos redundan en beneficios de distinta naturaleza para la empresa: aumento de la calidad, reducción de costes, reducción del tiempo de desarrollo de los productos, etc.

• La empresa sin papel .- Este es un objetivo que prácticamente todas las empresas persiguen hoy en día. Este aspecto sólo puede alcanzarse mediante la utilización de programas informáticos junto con unas telecomunicaciones adecuadas en todas las actividades de la empresa: compras, archivo documental, transferencia de información entre departamentos, relación con sus clientes y proveedores, etc.

En resumen, como se puede observar, son muchos los aspectos favorecidos en la empresa mediante una informatización apoyada y correctamente integrada en unas telecomunicaciones bien sean locales o de un ámbito amplio. Aunque se podrían seguir enumerando ventajas, podríamos resumir éstas en una ventaja competitiva para la empresa con todo lo que ello lleva consigo: aumento de la productividad, reducción de costes, aumento de la calidad, etc.


Trabajo cooperativo:

Las Telerreuniones.- Cada día es mayor el número de programas software orientados a ser utilizados de forma distribuida con objeto de facilitar el trabajo en grupo. Entre estas herramientas debe destacar aquellas que van dirigidas a permitir concretizar sesiones de trabajo de forma interactiva entre dos o más personas simultáneamente conectadas a la red. Es lo que se ha dado en llamar "teletrabajo en grupo" o "trabajo cooperativo" soportado por PCs. Estos programas tratan de proveer a los trabajadores de todas las herramientas necesarias para que puedan realizar reuniones de trabajo a través de un computador desde puntos distantes.

Entre las principales herramientas que ofrecen estos programas cabe destacar los siguientes:


-Videoconferencias.- Ayuda a tener un contacto más directo entre las personas que participan en una sesión de trabajo cooperativo.

-Transferencia de ficheros.- Permite entregar documentos, fotografías, archivos, etc., al resto de participantes a través de la red y de forma instantánea.

-Pizarra compartida.- Es una zona de la pantalla del computador de cada participante que se usa de forma compartida entre todos como una mesa común de trabajo. Todo documento, texto, dibujo, etc., que se realice sobre esta zona por cualquiera de los participantes es visto de igual manera por el resto e, incluso, editable de manera conjunta.


-Compartición de aplicaciones.- Esta herramienta permite que cualquier aplicación o programa software que ejecuta cualquier participante en la teleconferencia, puede ser visto por todos con objeto de poder realizar determinados trabajos de forma conjunta.


-Telepuntero.- En algunas ocasiones se desea indicar a los participantes de una sesión de trabajo en grupo una parte de un documento marcándolo con el mouse de nuestro computador. Esto es lo que permite el telepuntero. Cualquier persona puede ver la posición del mouse de cualquier otro participante, identificándolo del resto mediante distintas formas de colores.


Existen otras herramientas específicas de determinados productos software (mensajería entre los participantes, diálogos mediante textos, etc.,) dirigidas a facilitar la realización de sesiones de trabajo en grupo entre personas situadas en lugares distantes. Por tanto, se pueden establecer verdaderas reuniones "virtuales" entre personas en puntos distantes gracias al desarrollo de la informática y las telecomunicaciones.


http://sisbib.unmsm.edu.pe/bibvirtual/publicaciones/quipukamayoc/1999/segundo/informatica.htm

http://www.tutoriales.itsa.edu.mx/DesarrolloDeAplicaciones/index.php?mod=escenarios&ban=0

1.2.5 De Conexión Entre Capas.


Como tecnología, las arquitecturas de capas proporcionan una gran cantidad de beneficios para las empresas que necesitan soluciones flexibles y fiables para resolver complejos problemas inmersos en cambios constantes.

Todas las aplicaciones basadas en capas permitirán trabajar con clientes ligeros, tal como navegadores de Internet, WebTV, Teléfonos Inteligentes, PDAs (Personal Digital Assistants o Asistentes Personales Digitales) y muchos otros dispositivos preparados para conectarse a Internet.

De este modo, las arquitecturas de capas se están posicionando rápidamente como la piedra angular de los desarrollos de aplicaciones empresariales y las compañías están adoptando esta estrategia a una velocidad de vértigo como mecanismo de posicionamiento en la economía emergente que tiene su base en la red (lo que se ha venido a denominar "Nueva Economía").

Actualmente, la Red (Internet, intranets y extranets) es el ordenador o, como diría Sun Microsystems, el ordenador es la Red. Este paradigma está creando un cambio fundamental en los modelos de computación que, a su vez, proporciona desafíos y oportunidades como nunca antes había se habían producido.

Una tecnología de conexión de capas es:

1.2.4 De Comunicación De Datos.


La construcción de aplicaciones distribuidas ha emergido como la arquitectura predominante para la construcción de aplicaciones multiplataforma en la mayor parte de las empresas.

Este cambio radical en los modelos de computación, desde los sistemas monolíticos basados en mainframe y los tradicionales sistemas cliente-servidor, hacia sistemas distribuidos multiplataforma altamente modularles, representa el desarrollo rápido y avance de la investigación en el mundo del desarrollo de aplicaciones, tal y como se pone de manifiesto en las últimas tendencias de las grandes empresas de tecnología, como Sun con su estrategia Sun One, o Microsoft con DotNET (.Net).

Algunas tecnologías de comunicación de datos son:

• Intranet.
• Internet.


La construcción de aplicaciones distribuidas ha emergido como la arquitectura predominante para la construcción de aplicaciones multiplataforma en la mayor parte de las empresas.

Este cambio radical en los modelos de computación, desde los sistemas monolíticos basados en mainframe y los tradicionales sistemas cliente-servidor, hacia sistemas distribuidos multiplataforma altamente modularles, representa el desarrollo rápido y avance de la investigación en el mundo del desarrollo de aplicaciones, tal y como se pone de manifiesto en las últimas tendencias de las grandes empresas de tecnología, como Sun con su estrategia Sun One, o Microsoft con DotNET (.Net).



Ejemplo de una tecnología de comunicación de datos.

http://www.tutoriales.itsa.edu.mx/DesarrolloDeAplicaciones/index.php?mod=decomunicacion&ban=0

1.2.3 De base de datos.

Es el “otro extremo” visto desde la interface de usuario Involucrado en el almacenamiento y recuperación de datos Las tecnologías aplicables incluyen archivos planos, bases de datos relacionales u orientadas a objetos, etc.


La evolución de las bases de datos distribuidas se debe por una parte a razones organizacionales las cuales han demandado que mayores capacidades sean incorporadas a las bases de datos, tales como la integración de información desde distintos sitios donde se encuentre la empresa distribuida hacia algún sitio por ejemplo, para una consulta. Por otra parte, el desarrollo de las tecnologías de comunicación han permitido enlazar datos con aplicaciones que se encuentran en sitios distintos y remotos, por ejemplo las transacciones bancarias realizadas en máquinas-cajeros automáticos (ATM) que se encuentran ubicados en centros comerciales, empresas y escuelas, no serían posibles si no tuviéramos sistemas de comunicación para enlazarnos a bases de datos localizadas en diferentes sitios financieros.

Algunas tecnologías de base de datos son:
• OLEB
• ADO.
• XML.
• SQL.
• Herramientas para modelado (UML).




Ejemplo de una tecnología de base de datos.

http://www.tutoriales.itsa.edu.mx/DesarrolloDeAplicaciones/index.php?mod=debd&ban=0


1.2.2 De aplicacion.


La adopción de un diseño distribuido de aplicaciones empresariales, aumenta la reusabilidad, reduce la cantidad de recursos, y los costes necesarios de desarrollo y mantenimiento.

Este nuevo enfoque de diseño pone en manos de los desarrolladores no solo la funcionalidad que demandan las aplicaciones, sino también la seguridad, rapidez y flexibilidad.

Algunas tecnologías de aplicación son:



• CORBA.
• DNA.
• EJB.
• XML.


Ejemplo de una Interfaz de aplicacion.

http://www.tutoriales.itsa.edu.mx/DesarrolloDeAplicaciones/index.php?mod=deaplicacion&ban=0

1.2.1.De Interfaz de usuario.

Interfaces de Usuario.


El dispositivo de acceso de los usuarios humanos a un sistema distribuido se llama “front-end” o
interface de usuario. Generalmente es un conjunto de pantalla, teclado y mouse, pero en forma creciente vemos nuevos dispositivos como teléfonos celulares, PDA’s, etc. Genéricamente se denominan “cliente”.


Aquí es donde su aplicación presenta información a los usuarios y acepta entradas o respuestas del usuario para usar por su programa. Idealmente, la IU no desarrolla ningún procesamiento de negocios o reglas de validación de negocios. Por el contrario, la IU debería relegar sobre la capa de negocios para manipular estos asuntos. Esto es importante, especialmente hoy en día, debido a que es muy común para una aplicación tener múltiples IU, o para sus clientes o usuarios, que le solicitan que elimine una IU y la remplace con otra.






Ejemplo de una interfaz de usuario.

Algunas tecnologías de interfaz de usuario son:

• API Win 32.
• HTMAL.
• Dell HTML.
• Lenguajes de scrips.


http://www.tutoriales.itsa.edu.mx/DesarrolloDeAplicaciones/index.php?mod=deinterfaz&ban=0

1.2 Evolucion de las tecnologias para el desarrollo de aplicaciones distribuidas.


Hoy en día las compañías no pueden ignorar el grave problema que implica desarrollar y adaptar software al ritmo que imponen los negocios. Los requisitos varían con mucha frecuencia y las aplicaciones no logran ser desarrolladas y/o adaptadas al ritmo requerido. La globalización y fusión de empresas, el crecimiento de Internet, entre otros factores, han acentuado aún más estos problemas llevando el software desarrollado, que normalmente había sido desarrollado para una plataforma específica, a un ambiente distribuido heterogéneo. Esto involucra, en consecuencia, La necesidad de considerar una amplia gama de aspectos como lo son la integración de datos heterogéneos, la interacción entre diversos sistemas, los distintos sistemas operativos, el middleware, las tecnologías web, cuestiones de escalabilidad y performance, por citar algunos de ellos.

La evolución de las tecnologías cliente/servidor sumada al advenimiento de nuevas tecnologías como XML, web services , la plataforma J2EE, la comunicación asíncrona por medio de mensajes, el uso de application servers , son algunos de los conocimientos que permiten llevar a cabo el desarrollo de aplicaciones modernas.

La evolución de las aplicaciones distribuidas se dio de la siguiente forma:

• Aplicaciones monolíticas.
• Arquitectura cliente/servidor.
• Arquitectura de tres capas.
• Arquitectura de N capas.




http://www.tutoriales.itsa.edu.mx/DesarrolloDeAplicaciones/index.php?mod=evolutec&ban=0

1.1.4 Aplicaciones distribuidas.

Mucho tiempo ha transcurrido ya desde que en la década de los ochenta la tecnología de la información comenzara tímidamente a ocupar el lugar que hoy en día posee. En aquellos días, que tal vez algunos veteranos recuerden con cierta nostalgia, la mayoría de los sistemas informáticos estaban constituidos por enormes sistemas centrales que ejecutaban todos las aplicaciones dentro de sí mismos, y en el mejor de los casos los usuarios interactuaban con esas aplicaciones mediante “terminales tontos”, que no eran sino simples pantallas con teclado que permitían enviar caracteres al sistema central y mostrar las respuestas, también basadas en caracteres, que los monstruos generaban y enviaban a través de un cable.

El advenimiento de los ordenadores personales constituyó la primera revolución. Ahora los usuarios disponían de un procesador y de un sistema de almacenamiento autónomo, capaz de procesar datos e incluso de mostrar gráficos por pantalla además de caracteres. Surgieron multitud de aplicaciones “de escritorio” que independizaron a los usuarios de los grandes sistemas y el coste del hardware se redujo a niveles tan aceptables que empresas que no hubieran podido afrontar la inversión en un sistema informático centralizado comenzaron a introducir en sus procesos de negocio la gestión informática de los datos.

Pero en el fondo los modos de ejecución de aplicaciones no habían cambiado. De la ejecución en un sistema centralizado se pasó a la ejecución en sistemas más pequeños e independientes, pero al fin y al cabo las aplicaciones seguían siendo islas incomunicadas entre si, y los usuarios no podían contar más que con las capacidades del propio ordenador para procesar los datos. Por un lado, la necesidad de compartir datos no quedaba resuelta con sistemas independientes, y la opción de las aplicaciones centralizadas seguía siendo la única viable en entornos multiusuario. Por el otro, cuando los datos eran generados por un ordenador central no había forma de tratarlos localmente y toda la potencia de los ordenadores personales no servía para nada.
El avance en las tecnologías de redes comenzó a dibujar un horizonte en el que las aplicaciones se comunicarían entre sí y en el que los procesos de una aplicación se distribuirían entre diferentes equipos, cada uno con características que les permiteran aumentar la eficacia y la disponibilidad de la aplicación. Se comenzó a separar la lógica de las aplicaciones para situarla en el nivel más conveniente y conceptos como “cliente” y “servidor” fueron cobrando cada vez más sentido. Tras algunos años de indecisión, los protocolos de red se estandarizaron y hacia mediados de los años 90 Internet se convirtió en la primera revolución auténtica del siglo XXI, provocando no sólo un vuelco en las relaciones sociales y económicas sino también, por supuesto, un cambio completo de paradigma en la arquitectura de las aplicaciones informáticas.

Las aplicaciones se convierten, así, en aplicaciones distribuidas. Sin arriesgarnos a proporcionar una definición académica que puede encontrarse muy fácilmente en Internet, diremos informalmente que una aplicación distribuida es aquella cuyo objetivo final se alcanza mediante la ejecución de diversos procesos independientes que por lo general se ejecutan en equipos diferentes y que de una forma u otra se pasan datos entre ellos mediante protocolos de comunicaciones bien establecidos.
En esta primera sección examinaremos las formas arquitectónicas (o de diseño) que adquieren las aplicaciones distribuidas. Cada una de ellas plantea ciertas ventajas e inconvenientes que será necesario tener en cuenta a la hora de crear el código para los diferentes componentes de la aplicación.


Características de las aplicaciones distribuidas.

Independientemente de su arquitectura, todas las aplicaciones distribuidas comparten ciertas características que las diferencian notablemente de las aplicaciones centralizadas y de las aplicaciones de escritorio. Conocer esas características y evaluar su impacto en las aplicaciones es primordial para escoger el diseño más adecuado de las mismas. No es cierto que una aplicación se pueda diseñar de cualquier manera.



Aspectos primordiales que han de evaluarse a la hora de diseñar una aplicación distribuida:

1. Concurrencia: De igual forma que en las aplicaciones centralizadas, las aplicaciones distribuidas serán utilizadas por cierto número de usuarios concurrentemente. Aspectos como las transacciones, los bloqueos de recursos o el uso de la CPU de los equipos a los que acceden muchos usuarios son determinantes a la hora de diseñar una arquitectura con la máxima eficacia.

2. Topología de la red: A pesar de que a día de hoy los anchos de banda cada vez son má s amplios, el tráfico de red puede ser un aspecto importante que condicione el tiempo de respuesta de la aplicación. En muchos casos también será necesario tener en cuenta el tipo de red (LAN o WAN), o si la aplicación será o no accesible a través de Internet. La forma de distribuir los procesos de la aplicación tendrá que tomar en consideración el tipo de red que soportará el tráfico de datos.


3. Ubicación de la lógica: Dado que en una aplicación distribuida intervienen varios procesos, será necesario decidir en cuál de los posibles procesos físicos se sitúa cada componente lógico de la aplicación. Mientras que algunos procesos, como la presentación de datos o la recuperación de los mismos, tienen un sitio natural, otros, como la validación o la navegación, pueden ocupar diversos lugares dentro del diagrama que conforma la estructura de la aplicación. En muchas ocasiones la ubicación de los componentes lógicos impacta sobre el rendimiento, sobre la reutilización del código o sobre la facilidad de programación.


4. Homogeneidad de las plataformas: En una aplicación distribuida los sistemas operativos involucrados o los lenguajes de desarrollo utilizados pueden ser un factor a tener en cuenta a la hora de decidir algunos aspectos importantes, como por ejemplo el modo de pasar datos entre procesos. La utilización de estándares puede ser muy útil a la hora de crear aplicaciones distribuidas que permanezcan abiertas a diversos sistemas heterogéneos, pero si las plataformas son similares es posible alcanzar mejor rendimiento sacrificando interoperabilidad.


5. Seguridad: Una aplicación distribuida mantiene procesos que de una forma u otra están a la escucha en una red, lo que aumenta la vulnerabilidad de la aplicación. Será necesario establecer políticas de seguridad que impidan el acceso no autorizado a los procesos. Pedir al usuario un nombre y una contraseña al iniciar el programa es probable que no sea suficiente.

No existe una solución única para todos los problemas. A pesar de que en la actualidad se priman ciertas arquitecturas sobre otras, la realidad es que la decisión final dependerá de todos los factores anteriormente citados, y de otros que a veces no se tienen mucho en cuenta pero que también poseen su importancia, como el coste total de la aplicación o la complejidad de la solución respecto al problema planteado. Ni es recomendable subestimar las necesidades de una aplicación compleja, ni tampoco conviene sobredimensionar la estructura de una aplicación sencilla que puede resolverse con medios más asequibles.

Con las aplicaciones distribuidas el mero análisis funcional de las características de una aplicación ya no es suficiente y es necesario también considerar la distribución y estructura de los procesos involucrados. La tarea del arquitecto de aplicaciones consistirá precisamente en tomar la decisión de diseño más adecuada para resolver el problema, ajustándose lo mejor posible a los requerimientos y tomando en cuenta todos los factores implicados.



Arquitectura de las aplicaciones distribuidas.


En una aplicación distribuida en n-capas los diferentes elementos que integran la aplicación se agrupan de forma lógica según la funcionalidad que reciben o suministran al o desde el resto de los elementos. Así, algunos elementos se limitarán a recibir peticiones de datos mientras que otros interactuarán con el usuario y su función será principalmente la de solicitar a otros elementos la información que el usuario precisa.
Atendiendo al papel que los distintos elementos juegan dentro de la aplicación, distinguimos con claridad tres grupos lógicos en los que podemos agrupar elementos según su funcionalidad:


•La capa de servidor incluye aquellos elementos que se encargan de recibir las peticiones de datos o de acceso a servicios básicos del sistema y de suministrar a otros elementos la información solicitada.
•La capa de negocios encapsula las reglas de acceso a datos y la gestión de procesos internos de la aplicación.
•La capa de presentación se encarga de la lógica necesaria para interactuar con el usuario de la aplicación.

Una vez agrupada la funcionalidad en capas lógicas es fácil relacionar unas con otras. El usuario interactuará con la capa de presentación, solicitando datos o desencadenando acciones. Las solicitudes serán atendidas por la capa de negocios, que se encargará de su gestión o de la traducción necesaria para que la capa de servidor realice la tarea solicitada. Si la capa de servidor debe proporcionar datos estos se devolverán a la capa de negocios, la cual los gestionará o transmitirá a la capa de presentación. La figura 2.1 ilustra este esquema.






Figura 2.1: Esquema lógico de las capas en una aplicación distribuida
.


Es importante notar que el esquema que mostramos es un esquema lógico, no físico. El modo de distribuir físicamente las capas (en diferentes ejecutables o DLL, o en diferentes equipos) se corresponderá con el esquema lógico en todo o en parte, pero no necesariamente existirá una correspondencia exacta entre la distribución lógica de los elementos y su distribución física. La capa de negocios podría residir en diferentes máquinas, por ejemplo, o las entidades de negocio y la capa de servidor podrían formar parte de la misma DLL. Más adelante hablaremos de la relación física entre las diversas capas lógicas y estudiaremos cómo los diferentes escenarios nos condicionarán la distribución física de las capas lógicas.

Adicionalmente, en las aplicaciones distribuidas existen otras funcionalidades, como la seguridad o el registro de sucesos, que no son exclusivas de un grupo lógico ya que deben aparecer en todos los elementos de la aplicación.

1.1.3 Aplicaciones de 2,3 y n capas.

La construcción de aplicaciones n-tier (n-capas) distribuidas ha emergido como la arquitectura predominante para la construcción de aplicaciones multiplataforma en la mayor parte de las empresas.

Este cambio radical en los modelos de computación, desde los sistemas monolíticos basados en mainframe y los tradicionales sistemas cliente-servidor, hacia sistemas distribuidos multiplataforma altamente modularles, representa el desarrollo rápido y avance de la investigación en el mundo del desarrollo de aplicaciones, tal y como se pone de manifiesto en las últimas tendencias de las grandes empresas de tecnología, como Sun con su estrategia Sun One, o Microsoft con DotNET (.Net).

El modelo presenta algunas ventajas entre ellas:

• Desarrollos paralelos (en cada capa).
• Aplicaciones más robustas debido al encapsulamient .
• Mantenimiento y soporte más sencillo (es más sencillo cambiar un componente que modificar una aplicación monolítica).
• Mayor flexibilidad (se pueden añadir nuevos módulos para dotar al sistema de nueva funcionalidad)

Alta escalabilidad.


La principal ventaja de una aplicación distribuida bien diseñada es su buen escalado, es decir, que puede manejar muchas peticiones con el mismo rendimiento simplemente añadiendo más hardware. El crecimiento es casi lineal y no es necesario añadir más código para conseguir esta escalabilidad.

Como tecnología, las arquitecturas de n-capas proporcionan una gran cantidad de beneficios para las empresas que necesitan soluciones flexibles y fiables para resolver complejos problemas inmersos en cambios constantes.

Todas las aplicaciones basadas en n-capas permitirán trabajar con clientes ligeros, tal como navegadores de Internet, WebTV, Teléfonos Inteligentes, PDAs (Personal Digital Assistants o Asistentes Personales Digitales) y muchos otros dispositivos preparados para conectarse a Internet.

De este modo, las arquitecturas de n-capas se están posicionando rápidamente como la piedra angular de los desarrollos de aplicaciones empresariales y las compañías están adoptando esta estrategia a una velocidad de vértigo como mecanismo de posicionamiento en la economía emergente que tiene su base en la red (lo que se ha venido a denominar "Nueva Economía").

Actualmente, la Red (Internet, intranets y extranets) es el ordenador o, como diría Sun Microsystems, el ordenador es la Red. Este paradigma está creando un cambio fundamental en los modelos de computación que, a su vez, proporciona desafíos y oportunidades como nunca antes había se habían producido.

Realmente, los componentes distribuidos de una arquitectura de n-capas es una tecnología esencial para crear la siguiente generación de aplicaciones e-business, aplicaciones que son altamente escalables, fiables y que proporcionan un alto rendimiento y una integración sin fisuras con los sistemas de back-end heredados.

A diferencia de lo que se pudiera pensar, el desarrollo en n-capas no es un producto o un estándar, es un concepto estratégico que ayuda a la construcción y despliegue lógico de un sistema distribuido. Los sistemas de n-capas subdivididos ayudan a facilitar el desarrollo rápido de aplicaciones y su posterior despliegue, con beneficios incrementales fruto de los esfuerzos del desarrollo en paralelo coordinado y del outsourcing inteligente, resultando un enorme decremento del tiempo de desarrollo y de sus costes. Muchas de las aplicaciones de e-business que se utilizan actualmente simplemente utilizan un navegador de Internet como cliente ligero que implementa una interfaz universal. Una arquitectura basada en clientes ligeros desplaza la capa de presentación de la aplicación en el lado del cliente, mientras que la lógica de negocio y los datos residen en el middleware y los servidores de back-end. El diseño para clientes ligeros minimiza los problemas de despliegue de las aplicaciones, mientras que maximiza la accesibilidad a la misma desde una amplia variedad de plataformas heterogéneas. Los frameworks basados en n-capas se crean para obtener las ventajas de los estándares abiertos de la industria que permiten a las aplicaciones resultantes operar en entornos distribuidos multiplataforma.

Caracteristicas.


Las aplicaciones que se construyen con una arquitectura multicapa tienen entre otras las siguientes características:

• Acceso a bases de datos (BD) o Normalmente con BD relacionales

• Transaccionales o Propiedades ACID (Atomicity-Consistency-Isolation-Durability)


Operaciones atómicas (Atomicity) son operaciones que se completan en su totalidad o no se completan en absoluto. Así, en el ejemplo anterior de la transferencia tanto el crédito como el débito deben haber sido exitosos para que el estado de transformación sea exitoso (para que haga efectos), de otro modo el estado de la transformación falla, y el sistema es regresado a su último estado conocido.

• Transformaciones consistentes (Consistency) preservan la integridad interna de los recursos involucrados. Por ejemplo, el borrar registros de una tabla primaria viola la integridad referencial de la base de datos si hay registros relacionados que concuerden.

Transformaciones aisladas (Isolation) parecen ocurrir serialmente, una detrás de otra, creando la ilusión de que ninguna transformación está siendo ejecutada al mismo tiempo.

• La durabilidad (Durability) se refiere a la habilidad para almacenar los resultados de una transformación de estado, usualmente en un disco, de tal modo que los resultados de una transformación puedan ser recuperados en caso de una falla del sistema.

Escalables.
- Deberían poder soportar más carga de trabajo sin necesidad de modificar el software (sólo añadir más máquinas)

Disponibilidad o Idealmente no deben dejar de prestar servicio

• Seguras.
- No todos los usuarios pueden acceder a la misma funcionalidad

• Integración.
- Es preciso integrar aplicaciones construidas con distintas tecnologías.

• Tipo de interfaz.

- De entorno de ventanas (clientes desktop): normalmente sólo tiene sentido en intranets.
- Web: En Internet y en intranets.

• Separación clara entre la interfaz gráfica y la Capa de componentes.
- Capa de componentes: encapsulan la lógica de negocio.
- Ejemplo => aplicación bancaria

 Capa de componentes: conjunto de clases que nos permiten: crear cuentas, destruirlas, encontrarlas por distintos criterios, hacer transferencias bancarias, etc.
- La capa de componentes debería ser reusable con distintas interfaces gráficas
- En el ejemplo de la aplicación bancaria podría haber dos clientes: uno Web y otro desktop.


Aplicaciones de una Capa.

Las capas dentro de una arquitectura son nada más que un conjunto de servicios especializados que pueden ser accesibles por múltiples clientes y fácilmente reutilizables.

Este tipo de arquitectura se caracteriza por tener en una sola asociación lógica y en ella a la presentación, la lógica de negocios y los datos; que si los ponemos como servicios se convierten en capas, lo veremos más adelante.



Aplicaciones de 1 Capa


Ejemplos de esta arquitectura son desarrollos realizados en Excel, Access, Fox, entre otros.


Aplicaciones de dos capas.



Se caracterizan por tener 2 asociaciones lógicas, que prestan servicios y que a la final son capas.




Arquitectura de 2 capas.

En la primera capa se incluye a la presentación (Interface grafica) y a la lógica de negocios, toda la lógica la escribimos en las formas (en el onClick del botón por ejemplo), y accedemos a un servicio de datos para la gestión de los mismos, por lo general a un servidor de Base de Datos.

Esta arquitectura es comúnmente llamada cliente servidor, puesto que también el programa fuente puede residir en un servidor y muchos cliente pueden acceder a él para ejecutar una copia del programa.


Arquitectura Cliente – Servidor.


Pero se tubiese la siguiente problemática:

¿Qué podría suceder si tuviésemos que hacer cambios en la implementación de la lógica de negocios?

El resultado es la recompilación de toda la aplicación y reinstalación en todos y cada uno de los clientes; y….si los clientes suman como 200 máquinas?

La solución está en separar la lógica de negocios en un servicio aparte, allí es donde aparece la tercera capa.




Aplicaciones de 3 Capas.

Una aplicación de tres capas es una aplicación cuya funcionalidad puede ser segmentada en tres niveles lógicos (capas):

• Los servicios de presentación.
• Los servicios de negocios (Lógica de Negocios) .
• Los servicios de datos.







Arquitectura de Aplicaciones de 3 capas .

La capa de servicios de presentación es responsable de:

• Obtener información del usuario.
• Enviar la información del usuario a los servicios de negocios para su procesamiento.
• Recibir los resultados del procesamiento de los servicios de negocios.
• Presentar estos resultados al usuario.


El nivel de servicios de negocios es responsable de:

Recibir la entrada del nivel de presentación.
• Interactuar con los servicios de datos para ejecutar las operaciones de negocios para los que la aplicación fue diseñada a automatizar (por ejemplo, la preparación de impuestos por ingresos, el procesamiento de ordenes y así sucesivamente).
• Enviar el resultado procesado al nivel de presentación.


El nivel de servicios de datos es responsable de:

• Almacenar los datos.
• Recuperar los datos.
• Mantener los datos.
• La integridad de los datos.




Arquitectura de 3 capas .

Al ser la primera capa un servicio, se puede inferir que las aplicaciones no solo podrían ser de escritorio, si quisiéramos que nuestra aplicación tenga una interface web, pues solamente bastaría con cambiar la capa de presentación y de allí en adelante nada tiene porque cambiar.

Entonces nuestras páginas web estarían alojadas en un Servidor Web las mismas que se conectan a la lógica de negocios y de allí a los servicios de datos.




Arquitectura de 3 capas con interface Web .


Aplicaciones de n Capas.

Podríamos ir separando nuestra aplicación en mas niveles lógicos, por ejemplo, vamos a querer que nuestra aplicación tenga múltiples interfaces, es decir interface gráfica (standalone o desktop) y también interface Web.

Lo aconsejado en esta circunstancia es separar al Servidor Web encargado de alojar las páginas Web en una capa más. En este caso se tendrían 4 capas.


Arquitectura de 4 capas


Mientras más servicios coloquemos a nuestra aplicación y mientras más escalable lo imaginemos, mas capas lógicas van a irse añadiendo a nuestra arquitectura; allí está el inicio del estudio de las siguientes secciones del curso, LOS PATRONES DE DISEÑO.

• La arquitectura en 3 capas es la más usada
• La arquitectura en 4 capas puede ser más escalable

http://faustol.files.wordpress.com/2007/09/construccion-de-aplicaciones-en-capas.doc.

1.1.2 Aplicaciones Cliente/Servidor.

Clientes y servidores.

El paradigma cliente - servidor divide las aplicaciones comunicantes en dos categorías, dependiendo de si la aplicación se queda en espera de conexiones (servidor) o las inicia (cliente).



En general, una aplicación que inicia una comunicación con otra se la califica como cliente. Los usuarios finales invocan aplicaciones cliente cuando utilizan un servicio de red. Cada vez que se ejecuta una aplicación cliente, esta contacta con el servidor, le envía una solicitud de servicio y espera la respuesta o resultados del servicio. El proceso cliente es el encargado de llevar a cabo la interacción con el usuario y de mostrar los resultados de las peticiones de servicio. En la mayoría de las ocasiones los clientes son mas fáciles de diseñar que los servidores, y no suelen precisar privilegios especiales del sistema para poder funcionar.

Un servidor es un programa que espera peticiones de servicio por parte de un cliente. El servidor recibe la petición del cliente, ejecuta el servicio solicitado y retorna los resultados al cliente. No existe una interacción directa entre el usuario y el servidor, de esto ya se encarga la aplicación cliente.
Desde el punto de vista de una aplicación, el TCP/IP, al igual que muchos otros protocolos de comunicación, implementa un mecanismo fiable para la transmisión de datos entre ordenadores. En concreto, el TCP/IP permite que un programador pueda establecer comunicación de datos entre dos programas de aplicación, tanto si ambos se están ejecutando en la misma máquina, como en maquinas distintas unidas por algún camino físico (una red local, conexión telefónica directa entre computadoras, computadoras conectas a Internet,... ).

Hay que tener presente que el protocolo TCP/IP especifica los detalles y mecanismos para la transmisión de datos entre dos aplicaciones comunicantes, pero no dictamina cuando ni porque deben interactuar ambas aplicaciones, ni siquiera especifica cómo debería estar organizada una aplicación que se va a ejecutar en un entorno distribuido. Es tarea del diseñador de la aplicación distribuida el establecer un protocolo de comunicación y sincronización adecuado.

En la práctica el esquema de programación más utilizado para la implementación de aplicaciones distribuidas es el paradigma cliente - servidor. La motivación fundamental para el empleo del paradigma cliente - servidor surge del problema del rendezvous. Para entender dicho problema, imaginemos un técnico de computadoras que inicia la ejecución de dos programas en máquinas distintas y que tiene la intención de que dichos programas puedan comunicar entre sí. Una vez iniciado el primer programa este envía un mensaje a su contertulio. La conexión con la maquina a la cual va dirigido el mensaje se puede establecer en un intervalo de unos pocos milisegundos (recordar que las computadoras funcionan a velocidades muchos ordenes de magnitud por encima de los humanos), por lo que el proceso recién lanzado determina que su contertulio todavía no existe, con lo cual emite un mensaje de error y finaliza su ejecución. Mientras tanto, el técnico inicia la ejecución del segundo proceso. Desafortunadamente, el segundo proceso no puede comunicar con el primero ya que este ha concluido su ejecución. Incluso si los dos procesos intentan establecer la comunicación continuamente, estos pueden ejecutarse tan rápidamente, que la probabilidad de colisiones es muy alta.

El modelo cliente - servidor da solución al problema del rendezvous (reencuentro). Según este modelo, en cualquier par de aplicaciones comunicantes, una de las partes implicadas en la comunicación debe iniciar su ejecución y esperar (indefinidamente) hasta que la otra parte contacte con ella. Esta solución es importante, ya que el TCP/IP no proporciona ningún mecanismo que automáticamente lance procesos para atender mensajes entrantes, debe de existir un proceso en espera que sea capaz de atender dichos mensajes (peticiones de servicio).
Muchos administradores hacen que ciertos programas de comunicaciones se inicien automáticamente cuando el sistema arranca, de este modo se aseguran que la computadora estará preparada para aceptar ciertas solicitudes de servicio. Después de iniciar su ejecución, cada uno de estos programas se queda en espera de la siguiente petición para el servicio que oferta.


El modelo cliente - servidor.

TCP es un protocolo orientado a conexión. No hay relaciones maestro/esclavo. Las aplicaciones, sin embargo, utilizan un modelo cliente/servidor en las comunicaciones.
Un servidor es una aplicación que ofrece un servicio a usuarios de Internet; un cliente es el que pide ese servicio. Una aplicación consta de una parte de servidor y una de cliente, que se pueden ejecutar en el mismo o en diferentes sistemas.
Los usuarios invocan la parte cliente de la aplicación, que construye una solicitud para ese servicio y se la envía al servidor de la aplicación que usa TCP/IP como transporte.
El servidor es un programa que recibe una solicitud, realiza el servicio requerido y devuelve los resultados en forma de una respuesta. Generalmente un servidor puede tratar múltiples peticiones(múltiples clientes) al mismo tiempo.

Figura: El modelo de aplicación cliente/servidor.

Algunos servidores esperan las solicitudes en puertos bien conocidos de modo que sus clientes saben a que zócalo IP deben dirigir sus peticiones. El cliente emplea un puerto arbitrario para comunicarse. Los clientes que se quieren comunicar con un servidor que no usa un puerto bien conocido tienen otro mecanismo para saber a qué puerto dirigirse. Este mecanismo podría usar un servicio de registro como Portmap, que utiliza un puerto bien conocido.

http://neo.lcc.uma.es/evirtual/cdd/tutorial/aplicacion/cliente-servidor.html
http://www.ctv.es/USERS/carles/PROYECTO/cap3/cap3.html

1.1.1 Aplicaciones Monoliticas.

Migración de Aplicaciones al Modelo Cliente Servidor

Muchas de las aplicaciones de oficina utilizadas actualmente poseen buenos modelos de datos e interfaces realmente claras que permitieron en su momento un significativo aumento de la productividad. El problema es que ven afectada su posibilidad de crecimiento por características tecnológicas de base que dificultan el acceso a alta velocidad dentro de la Red Local e impiden el acceso desde fuentes remotas como Internet y otras redes no locales.

Tal es el caso de la mayoría de las aplicaciones desarrolladas en los últimos años en que el acceso a datos se efectuaba a partir de aplicaciones monolíticas que concentran en una sola capa tanto la interfaz visual como lo métodos de acceso a datos, lo que comúnmente se conoce como modelos Cliente - Cliente.

Estas aplicaciones Cliente- Cliente concentran toda la actividad en los equipos de los usuarios, dejando al los servidores la labor de meros reservorios de datos compartidos.

Así ante cada petición de datos, el servidor devuelve archivos completos que luego son procesados por el equipo cliente, para obtener el resultado.

Por ejemplo, suponiendo que una base de cliente tuviera un tamaño medio de 5Mb y se efectúa una búsqueda muy simple de un cliente en particular, el servidor no efectuará la búsqueda por sí sino que devuelve la tabla de 5Mb completa, luego el equipo del usuario procesa la búsqueda en su equipo para seleccionar 1 registro de digamos unos 1Kb y descarta el resto de la información.

Los principales defectos de este modelo son:

• Requieren más y mejor Hardware en las estaciones de trabajo.
• Son infinitamente más lentos en el procesamiento de peticiones sencillas.
• Ocupan mayor ancho de banda, provocando congestionamiento en la Red Local.
• Requieren habilitar el acceso real a la carpeta de datos para todos los usuarios de la aplicación.
• Su actualización es más costosa.
• No permiten el acceso en línea desde fuera de la Red Local.

O’Lach Multi Media ofrece servicios de migración de aplicaciones al modelo Cliente servidor, a partir de grupos de trabajo cooperativos con los desarrolladores originales, el equipo de desarrollo de la empresa contratante o la interacción de nuestro equipo de desarrollo con los usuarios calificados y el personal de sistemas.

De esta forma, se logran mejorar las capacidades de los sistemas existentes mediante su división en capas (Reservorio, Acceso a Datos e Interfaz Visual) aprovechando todas las aptitudes de la aplicación y ampliando sus posibilidades de uso y crecimiento gracias a la implementación del modelo Cliente Servidor.


http://www.mitecnologico.com/Main/EvolucionAplicacionesInformaticas

1.1 EVOLUCION DE LAS APLICACIONES INFORMATICAS.


1.1 Evolucion de las Aplicaciones Informaticas.

Aplicaciones.

En sus orígenes la programación de los ordenadores era hecho sólo, para y por los mismos científicos que las construían para propósitos muy específicos. El cálculo de la trayectoria de los proyectiles usados en la II Guerra Mundial, y posteriormente usos muy parecidos, hasta que mucho después que fue utilizada en el Censo de los Estados Unidos fue reconociéndose su valor en el campo administrativo donde estuvo hasta hace 2 décadas, cuando gracias a la Computadora Personal pasaron al dominio público donde con tantas necesidades fueron surgiendo las aplicaciones diversas para cada oficio.


A diferencia de algunos años atrás, hoy existe una infinidad de aplicaciones para satisfacer desde diversiones o entretenimiento de niños hasta sofisticados programas de investigación científica; más sin embargo, para las necesidades de la mayoría de los mortales que trabajan en Instituciones o Empresas y aún para los particulares existe un número preciso de aplicaciones, que como herramientas no deben faltar en ninguna computadora de uso personal.




La evolución de las aplicaciones informáticas se dio debido a los siguientes factores:

1. Trabajo a distancia.
2. Compartir información.
3. Accesibilidad.
4. Seguridad en la protección de la información (tener la base de datos particionada en dos o más nodos).
5. Independencia lugares.

En la actualidad cualquier aplicación cuenta generalmente con tres partes diferenciadas:


1. Una interfaz de usuario: Elemento con el que interacciona el usuario de la aplicación, ejecutando acciones, introduciendo u obteniendo información.
2. Lógica ó Reglas de negocio: Son las que procesan la información para generar los resultados que persiguen, siendo el elemento fundamental que diferencia unas aplicaciones de otras.
3. Gestión de datos: Se ocupa del almacenamiento y recuperación de la información.

http://html.rincondelvago.com/evolucion-de-la-informatica_4.html
http://www.tutoriales.itsa.edu.mx/DesarrolloDeAplicaciones/index.php?mod=evoluciondeaplicaciones&ban=0

UNIDAD 1 PANORAMA GRAL. DE LAS APLICACIONES DISTRIBUIDAS.




INSTITUTO TECNOLOGICO DE CIUDAD ALTAMIRANO.



MATERIA:
DESARROLLO DE APLICACIONES PARA AMBIENTE DISTRIBUIDO.

PROFESOR:
MC. Ángel Sixtos Solís.

ALUMNA:
Deysi Yuri Hernández Ríos.

Cd. Altamirano, Gro. Febrero 2011.

martes, 15 de diciembre de 2009

LINK PARA DESCARGA DEL SISTEMA DE BASE DE DATOS

http://www.megaupload.com/?d=PURMDSAA

Adiministracion de Proyectos






INSTITUTO TECNOLOGICO DE CIUDAD ALTAMIRANO.


DISEÑO E IMPLEMENTACION DE UNA BASE DE DATOS.

MATERIA:
ADMINISTRACION DE PROYECTOS.

DOCTORA:
LETICIA ROQUE CORREA.

INTEGRANTES:

Deysi Yuri Hernández Ríos
Itandewy Aguilar Navarrete
Juana Yasbet Santibañez Chávez
Emmanuel Mendoza Silva
Gumercindo Velázquez Antúnez

Cd. Altamirano, Gro. Octubre 2009.


TITULO DEL PROYECTO.

Creación de una base de datos aplicable a una empresa comercial.

OBTENCION DE REQUISITOS.


Antes de iniciar con el desarrollo del proyecto (creación de una base de datos) debemos de extraer los requisitos que tendremos que cumplir para proceder con el desarrollo de la base de datos y así poder proporcionar a la empresa una una buena propuesta acorde con los intereses de la misma.


Requisitos a obtener para determinar cómo los siguientes:


Datos de personal:
• Empleado.
• Puesto.
• Horas trabajadas.
• Pago por hora.
• Inasistencias.
• Horas extras.
• Pago por hora extra.
• Descuento.
• Sueldo extra.
• Sueldo total.

Inventario de mercancías.

• Producto.
• Marca.
• Existencia.
• Precio.
• Entradas.
• Salidas.
• Productos vendidos.
• Venta total.
• Nuevas entradas.
• Total de productos en existencia.
• Total de inventario.





OBJETIVOS:


Objetivo general:

Crear una base de datos en Access 2007, aplicable a una empresa comercial para proporcionarle un mejor servicio, y así tenga un mejor control y automatización del registro tanto de personal como de mercancías.


Objetivos específicos:

• Obtención de un gestor de base de datos.
• Contactar a la empresa.
• Obtener y conocer los requerimientos de la empresa..
• Cumplir con los requisitos de la empresa.
• Permitir que ofrezca un mejo un servicio al cliente.
• Ahorrar tiempo y automatizar sus registros, facilitar la obtención de la información.


METAS:


Para el desarrollo de este proyecto fijaremos metas a corto plazo ya que tendremos que terminar el proyecto en un corto periodo de tiempo (3 meses aproximadamente).

• Culminar con el desarrollo del proyecto.
• Satisfacer los requerimientos de la empresa.

Facilitar la información necesaria al usuario de la manera que puedan acceder a ella fácilmente y no tenga dificultades al manejar la base de datos.

Lograr que el usuario quede completamente satisfecho con el servicio que le estamos ofreciendo al resolver sus necesidades.

Planear, implementar y administrar estrategias de fácil manejo.

Desarrollar, mantener y actualizar la base de datos de acuerdo a sus necesidades.

Un rápido registro de altas de mercancías.

Responsable de la navegabilidad y usabilidad de la base de datos ya que debe ser una persona capacitada.

Optimizar el tiempo a las capturas de los registros necesarios .

Administrar las bases de datos de los clientes .

Investigar y proponer nuevas tecnologías.


ALCANCE Y LIMITACIONES

ALCANCE:


Alcances que se pretenden lograr en el presente proyecto:
• Dar a conocer al usuario las facilidades que proporcionan las bases de datos y los objetivos de la misma, el funcionamiento, rendimiento y eficacia de estas.
• Terminar el proyecto a tiempo para proporcionarlo a la empresa.
• Proporcionar un manual a la empresa para que opere el sistema.
• Satisfacer las necesidades de la empresa.
• Lograr los objetivos propuestos.

LIMITACIONES:

• Algunas limitaciones que nos impediría proceder con el desarrollo del proyecto:
• No contar con suficiente tiempo para el desarrollo de dicho proyecto.
• Insuficiencia de conocimientos en el manejo de Access 2007.
• No contar con suficientes recursos económicos.
• Disponibilidad del personal para el desarrollo.
• La que empresa no tenga bien definido sus requerimientos.


JUSTIFICACION:

El motivo por el cual se opto por el desarrollo de este proyecto (creación de una base de datos) es por el hecho ser una herramienta útil para una empresa comercial.
Para el desarrollo de la base de datos se eligió el gestor de base de datos Access 2007 por ser uno de los más sencillos de utilizar y es hasta la fecha uno de los más actuales.

Facilita los registros, visualización y automatización del trabajo.
Con este proyecto se beneficiara la empresa que adquiera la base de datos, ya que esto es una herramienta útil y eficaz en la cual la información podrá ser capturada modificada y consultada de acuerdo a lo que el usuario solicite.
La finalidad de esta base de datos es con el fin de ofrecer buenos servicios tanto al cliente como al mismo usuario. Ayudar a comprender la funcionalidad y utilidad de la misma.



TECNICAS PARA LA OBTENCION DE INFORMACION SOBRE EL PROYECTO.

Las técnicas utilizadas para el desarrollo de este proyecto son: la entrevista y la investigación documental.

Mediante la entrevista se recabo la información de los requerimientos de la empresa y mediante la investigación documental obtener información necesaria para proceder el desarrollo del proyecto


CONTRATO DE DESARROLLO DE UNA BASE DE DATOS.

Conste por el presente documento el Contrato para el Desarrollo de una base de datos que celebran de una parte Gumercindo Velázquez Antúnez, alumno del Instituto Tecnológico de Cd. Altamirano, con domicilio en Av. Cuauhtémoc #27 barrio la calera, Coyuca de Catalán Gro. (Proveedor), y de la otra José Bermúdez Salazar propietario de la empresa Ford ubicada en carretera Cd. Altamirano-Coyuca de Catalán Gro.


LOS TÉRMINOS Y CONDICIONES:

CLAUSULA PRIMERA.- ANTECEDENTES

Que, de conformidad con el decreto supremo N° 065-85-PCM reglamento único de adquisiciones para el suministro de bienes y prestación de servicios no personales para el sector público, ley de presupuesto del sector público para el año 2009 y las normas pertinentes del Código Civil, la ENTIDAD contrata con el PROVEEDOR para los trabajos de planeamiento, y / o análisis y diseño, y / o programación e Instalación, de programas informáticos.

La presente adquisición se afecta conforme a (Licitación Pública/Concurso Público/ Adjudicación Directa/etc.) mediante la cual se adjudicó al proveedor la buena propuesta para el suministro de lo detallado en el Anexo II.

Forma parte de este contrato las bases de esta (Licitación Pública/Concurso Público/ Adjudicación Directa/etc.); así como la propuesta del PROVEEDOR.


CLAUSULA SEGUNDA.- OBJETO

Por el presente contrato el PROVEEDOR se compromete a realizar trabajos de planeamiento, y/o análisis y diseño, e Instalación, de base de datos que requiera la ENTIDAD, las que serán utilizadas en el equipo de procesamiento automático de datos descrito en el Anexo I de este contrato, en los locales que la ENTIDAD indique.


CLAUSULA TERCERA.- COMUNICACION ENTRE LAS PARTES.

La ENTIDAD nombrar como su representante al Sr. José Bermúdez Salazar y el PROVEEDOR al C. Gumercindo Velázquez Antúnez quienes resolverán conjuntamente las situaciones que pudieran presentarse durante la operación del mismo, así como agilizar la toma de decisiones involucradas en el proyecto. En caso que cualquiera de las partes fuera reemplazado se hará saber mediante aviso cursado a la otra parte por escrito con quince (15) días hábiles de anticipación a la Fecha del reemplazo.



CLAUSULA CUARTA.- PRECIO CONVENIDO Y FORMA DE PAGO.

El precio por la prestación de los servicios contratados ser abonado de acuerdo a lo señalado en el Anexo III contra presentación de garantía en el caso del PROVEEDOR.

Si cualquiera de las fases de trabajo concluyera y fuera aprobada Antes del tiempo previsto indicado en el Anexo VI, la ENTIDAD cancelar el valor correspondiente a la fase de trabajo concluida y aprobada inmediatamente después de la recepción y aprobación de los productos.



CLAUSULA QUINTA.- PROPIEDAD DE LOS PROGRAMAS INFORMATICOS.

La base de datos es propiedad del PROVEEDOR hasta su cancelación total por parte de la ENTIDAD. Una vez cancelado el valor total de los Programas Informáticos indicado en el Anexo II y de acuerdo con el Anexo III, la ENTIDAD solicitar la titularidad de los mismos para efectos de su registro en la oficina de derechos de autor de INDECOPI tanto en su versión fuente como objeto.

Si el trabajo se cancela bajo la modalidad de pagos parciales por fases de trabajo, la ENTIDAD ser propietaria absoluta de cada sistema, aplicación, programas, procedimientos o cualquier otro producto incluido dentro de la fase de trabajo concluida, aprobada y cancelada, desde el momento mismo de hacer efectivo el pago correspondiente a esta parte del trabajo.

Si el trabajo se cancela bajo la modalidad de pagos parciales por subsistemas concluidos y aprobados se aplica lo contemplado en el párrafo anterior.


CLAUSULA SEXTA.- DE LAS OBLIGACIONES.

La ENTIDAD está obligada a:

- La operatividad, buen estado y uso de los equipos indicados en el Anexo I, necesarios para operar la base de datos.

- Facilitar con la prioridad requerida, los equipos de procesamiento automático de datos para la compilación y prueba de la base de datos a elaborar.

- Facilitar una rea de trabajo para el personal del PROVEEDOR.

- Suministrar la información relacionada con el desarrollo de la base de datos.

En ningún caso, el incumplimiento parcial o total de la ENTIDAD al compromiso contraído por esta clausula releva al PROVEEDOR de las obligaciones que asume en virtud de ese Contrato.


El PROVEEDOR está obligado a:

-Realizar la base de datos de acuerdo a las especificaciones suministradas por la ENTIDAD y de acuerdo a la propuesta de servicios presentada por el PROVEEDOR, las cuales están contenidas en el Anexo IV de este Contrato. La ENTIDAD entregar por escrito tales especificaciones al PROVEEDOR.

- Organizar regularmente reuniones de información sobre el avance de los trabajos en el lugar donde se encuentre la ENTIDAD, en presencia de los responsables de la ENTIDAD.

- Brindar asistencia sobre los programas Informáticos al personal de la ENTIDAD.

- Entregar toda la documentación del desarrollo y uso de los programas informáticos.


CLAUSULA SEPTIMA.- DE LAS MODIFICACIONES.

Si alguna o todas las especificaciones escritas entregadas por la ENTIDAD al PROVEEDOR, fueran modificadas o creadas antes de finalizar la ejecución del presente contrato, el PROVEEDOR evaluar la magnitud de la modificación y podrá o no ejecutarla sin ningún costo. En todo caso por solicitud escrita de la ENTIDAD y de acuerdo con la tarifa por trabajos adicionales indicada en el Anexo V, el PROVEEDOR hará un estimado del costo y ejecutar los trabajos adicionales dentro de un lapso acordado por ambas partes.


CLAUSULA OCTAVA.- DE LA ENTREGA .

La ejecución del presente contrato debe ser de 3 meses, a partir de la fecha de la firma del mismo y se realizar según lo establecido en el cronograma de actividades descritas en el Anexo VI.

El desarrollo de los Programas Informáticos comprender las siguientes fases:
a) Planeamiento de Sistemas.
b) Análisis del Sistema de Información. Establecimiento de Especificaciones Funcionales.
c) Diseño General.
d) Diseño Detallado.
e) Programación y Pruebas.
f) Elaboración de Procedimientos y manuales.
g) Instalación de los Programas Informáticos.
h) Pruebas de Aceptación.
i) Adiestramiento/Capacitación.
j) Documentación de los Programas Informáticos.
k) Asesoría en aspectos relacionados a los Programas Informáticos.


La base de datos funciona de acuerdo a los manuales a que se hace referencia en el Anexo VII de este Contrato.


CLAUSULA NOVENA.- PERSONAL DE SERVICIO DEL PROVEEDOR.

El PROVEEDOR desarrollar los programas Informáticos con su propio personal o el que contratar‚ específicamente para este trabajo, por cuya virtud la ENTIDAD no asume ningún compromiso frente a ellos. El PROVEEDOR podrá utilizar para los fines de agilizar el presente proyecto, el personal de la ENTIDAD si a juicio de ‚esta se justifica tal solicitud de parte del PROVEEDOR. En ningún caso se podrá utilizar personal de la misma sin la autorización respectiva.


CLAUSULA DECIMA.- RESPONSABILIDAD DE LAS PARTES.

El PROVEEDOR se compromete a asegurar la confiabilidad y seguridad de la base de datos, no siendo responsable de los daños que pudieran resultar del mal uso, por fallas imputables al equipo en el cual se procesa. Así mismo, tampoco es responsable de los problemas que pudieran surgir una vez aceptados la base de datos por la ENTIDAD.

La ENTIDAD tiene el derecho de supervisar, con la periodicidad que estime oportuna, el estado y avance de las fases de los trabajos; pudiendo solicitar información acerca de los mismos y formular las observaciones que considere conveniente. Sin embargo, la supervisión de los avances de los mismos no implica la aprobación total de los trabajos ni de sus resultados parciales.

Se estipula que la base de datos debe ser revisada y aprobada por la ENTIDAD al terminar cada fase detallada en la clausula octava, en un plazo no mayor de siete (07) días útiles, antes de iniciarse la fase siguiente, de lo contrario deber hacer llegar las observaciones al PROVEEDOR en el mismo plazo.

La ENTIDAD se obliga a revisar los procedimientos, formularios y esquemas administrativos existentes en el mismo, y comunicar por escrito al PROVEEDOR las modificaciones u observaciones que estime conveniente para la buena marcha del proyecto.

Ambas partes acuerdan que cualquier requerimiento adicional posterior a la implantación de la base de datos ser realizado con el procedimiento de control de cambios a un costo a pactarse.


CLAUSULA DECIMA PRIMERA.- ANEXOS.

Se considera parte integrante de este Contrato, los Anexos siguientes:


Anexo I: Configuración de equipo de procesamiento automático de datos.
Anexo II: Valor Total de las bases de datos
Anexo III: Modalidad de pago
Anexo IV: Documentación.


Cada una de las cuales debe ser firmada por ambas partes.


CLAUSULA DECIMA SEGUNDA.-PRUEBA DE FUNCIONAMIENTO .

La base de datos debe ser sometida a la aprobación de los responsables del proyecto por parte de la ENTIDAD.

El PROVEEDOR se compromete a corregir cualquier falla en la base de datos, aún no presentada en el período de instalación de los mismos, hasta por un lapso de seis (6) meses después de la entrega y aceptación total del proyecto.



CLAUSULA DECIMA TERCERA.- DE LA RECEPCION.

El procedimiento de recepción, tanto a nivel material como de programas, ser en dos etapas por cada entrega o inicio.


1.- Recepción Provisional
- Puesta a disposición de material;
- Constatación suficiente de los juegos de ensayo de cada aplicación.

2.- Recepción Definitiva
- Verificación, rendimiento y funcionalidad.

Las recepciones definitivas tendrán lugar en el plazo de un mes después de las recepciones provisionales salvo en el caso de contestación a nivel de recepción provisional.

La ENTIDAD podrá rehusar las recepciones cuando los rendimientos esperados y las funcionalidades descritas no correspondan a aquellas definidas en las especificaciones técnicas que forman parte del presente contrato. En el caso de reusamiento motivado, el PROVEEDOR tendrá posibilidades de corrección espaciadas en 1 mes máximo, si al final de las tentativas su rendimiento de las funcionalidades no son alcanzados, el contrato ser resuelto y el PROVEEDOR restituir las sumas depositadas por la ENTIDAD.


CLAUSULA DECIMA CUARTA.- GARANTIA DE EVICCION .

El PROVEEDOR se compromete a no evidenciar a la ENTIDAD de sus derechos de plena utilización de los Programas entregados. El PROVEEDOR garantiza el uso de la base de datos.


CLAUSULA DECIMA QUINTA.- CAPACITACION.

Ambas partes establecen de mutuo acuerdo un plan de adiestramiento para el personal de la ENTIDAD, el cual deber estar detallado en el Anexo VI cronograma de actividades. El número de personas a entrenar depender de las necesidades de la ENTIDAD.


CLAUSULA DECIMA SEXTA.- GASTOS ADICIONALES.

Queda entendido por las partes que en caso que fuese necesario los gastos por labores tales como la transcripción de datos, uso de equipos, tiempo de maquina en el computador, impresión de formas continuas de cualquier tipo y papelería ser por cuenta y cargo de la ENTIDAD, previa aprobación de esta.


CLAUSULA DECIMA SEPTIMA.- CONFIDENCIALIDAD DE LA INFORMACION.

El PROVEEDOR se compromete a no divulgar ni transferir a terceros el desarrollo de los programas realizados; ni la data procesada o sin procesar por la ENTIDAD, ni incorporarla a redes nacionales o internacionales de transmisión de datos, sin la autorización previa y expresa de la misma, y en consecuencia, el PROVEEDOR responder de los daños causados en los términos legales establecidos.


CLAUSULA DECIMA OCTAVA.- CASO FORTUITO O FUERZA MAYOR.

La ENTIDAD podrá conceder una prorroga de 1 meses, si por causa de caso fortuito o fuerza mayor, ajena a la voluntad del PROVEEDOR y debidamente justificada a satisfacción de la ENTIDAD, el proyecto no pudiera concluirse en el plazo especificado en el presente contrato. Si la causa fuere imputable al PROVEEDOR, se indemnizar a la ENTIDAD según una tabla progresiva contenida en el Anexo VIII.

CLAUSULA DECIMA NOVENA.- FIANZA DEL FIEL CUMPLIMIENTO .

El PROVEEDOR de acuerdo con el Art. 5.1.4 del Reglamento Único de Adquisiciones para el Suministro de Bienes y Prestación de Servicios no Personales Para el Sector Público a la suscripción del contrato entregar Carta Fianza irrevocable, incondicional y de realización
automático con un plazo de vencimiento por treinta (30) días después‚ de concluido el contrato a favor de la ENTIDAD.


CLAUSULA VIGESIMA.- GARANTIA TECNICA.

El plazo de esta garantía que otorga el proveedor ser de ciento ochenta (180) días contados a partir de la fecha de la firma del acta de aceptación de los Programas Informáticos.

El proveedor conviene en informar por escrito a la entidad al termino de las actividades de implantación de cada Programa Informático para su conformidad presentación de observaciones por escrito en un plazo no mayor de siete (07) días útiles, vencido el cual y, de no existir respuesta se considera como aceptado. En caso de existir observaciones, el proveedor este obligado a subsanarlas en un plazo de siete (07) días útiles e informar por escrito al termino para su aceptación por la entidad.

El proveedor subsanar sin costo alguno para la entidad, los daños y perjuicios que pudiera ocasionar la operación de la base de datos materia del presente contrato debido a vicios ocultos defectos no determinados durante las pruebas de aceptación de los programas Informáticos.


CLAUSULA VIGESIMA PRIMERA.- VENTA .

Si posteriormente la entidad quiere vender la base de datos podrá hacerlo sin solicitar autorización del proveedor.


CLAUSULA VIGESIMA SEGUNDA.- RESOLUCION DEL CONTRATO.

Ser causal de Resolución de contrato si el proveedor transfiere parcial o totalmente la ejecución del contrato, teniendo responsabilidad total sobre su ejecución y cumplimiento.


CLAUSULA VIGESIMA TERCERA.- PENALIDADES.

El retraso por parte del proveedor en el cumplimiento de lo convenido en el presente contrato dar lugar a ser sancionado con multa equivalente en pesos por cada dia de retraso en la entrega deducible del pago de la respectiva factura, previa comunicación de la sanción conforme al Art 6.1.2 del RUA, aprobado por D.S. N§ 065-85-PCM, independientemente de las responsabilidades civiles y penales que se pudiera generar como consecuencia del incumplimiento del presente contrato.


CLAUSULA VIGESIMA CUARTA.- MODIFICACION

Ninguna clausula del presente contrato podrá ser modificada, suprimida o agregada por una de las partes unilateralmente. Toda proposición de cambio deber ser comunicada y aceptada por escrito un mes antes de la fecha de efectivización.


CLAUSULA VIGESIMA QUINTA.- DE LA VIGENCIA .

El presente contrato entra en vigencia a partir de la fecha de su suscripción, por un plazo de 3 meses y se renovar automáticamente por un plazo igual al indicado, salvo que alguna de las partes comunique por escrito a la otra su decisión en contrario, con una anticipación de quince (15) días o mas respecto a la fecha de vencimiento.

CLAUSULA VIGESIMA SEXTA.- DEL TÉRMINO .

Cualquiera de las partes podrá poner término al presente contrato mediante aviso cursado a la otra parte por escrito con treinta (30) días hábiles de anticipación. Cualquier pago que quedar‚ pendiente ser cancelado en un plazo máximo de cinco (5) días hábiles, contados a partir de la más próxima fecha de pago.

CLAUSULA VIGESIMA SEPTIMA.- .

Las partes se someten al conocimiento y decisión de uno o mas árbitros para la solución de las controversias que en el futuro puedan surgir entre ellas como consecuencia del presente contrato.
De acuerdo a la Ley de Arbitraje los árbitros resolver las controversias que se originen con arreglo al derecho aplicable.

CLAUSULA VIGESIMA OCTAVA.- COMPETENCIA.

Las partes renuncian expresamente al fuero de sus domicilios y se someten a la competencia de los Jueces y Tribunales del estado , a si mismo, declaran expresamente que en todo lo no previsto en el presente contrato se rigen por lo dispuesto en el Código Civil en lo que fuera pertinente.
En señal de conformidad del invocando a la buena fe, las partes firman el presente contrato, en dos ejemplares del mismo tenor y efecto legal, en la ciudad de Altamirano, a los días de la fecha acordad

_____________________ _______________________
ENTIDAD PROVEEDOR
(Sello y firma) (Sello y firma)




NOTAS ADICIONALES.

CLAUSULA OCTAVA.- DE LA ENTREGA.

Las fases para el desarrollo de los programas Informáticos pudieran variar dependiendo de la metodología a emplearse pero deben siempre especificarse tanto la metodología como las fases del desarrollo de los programas contratados, con fines de poder evaluar su cumplimiento.

CLAUSULA NOVENA.- PERSONAL DE SEVICIO DEL PROVEEDOR

Se deber solicitar que en la propuesta técnica el proveedor señale las cantidades y calificaciones del personal que dedicar a este proyecto; siendo necesario que adjunte los curriculum que demuestren el cumplimiento de las calificaciones ofrecidas, que Aseguren los resultados requeridos.



ANEXO I


CONFIGURACION DEL EQUIPO DE PROCESAMIENTO AUTOMATICO DE DATOS



_________________________ _________________________
ENTIDAD PROVEEDOR
(Sello y firma) (Sello y firma)


ANEXO II

VALOR TOTAL DE LA BASE DE DATOS

La realización total del proyecto implica las siguientes labores:


1. Planeamiento.

2. Análisis de la base de datos y Establecimiento de Especificaciones.

3. Diseño General.

4. Diseño Detallado.

5. Pruebas.

6. Elaboración de Procedimientos y Manuales.

7. Instalación de la base de datos.

8. Pruebas de Aceptación.

9. Adiestramiento.



_________________ _________________
ENTIDAD PROVEEDOR
(Sello y firma) (Sello y firma)


ANEXO III

MODALIDAD DE PAGO


El pago se realizar en 2 partes. Cada una por fase de trabajo concluida y aprobada, de la siguiente manera:

FASE 1

1. Planeamiento

FASE 2

2. Análisis de la base de datos y establecimiento de especificaciones.

3. Diseño general.

FASE 3

4. Análisis y Diseño Detallado.


FASE 4

5. Pruebas.

6. Elaboración de Procedimiento y Manuales.

7. Instalación de la base de datos.

8. Pruebas de Aceptación.

9. Adiestramiento.



__________________ __________________
ENTIDAD PROVEEDOR
(Sello y firma) (Sello y firma)

ANEXO IV

DOCUMENTACION
La documentación requerida está conformada por lo siguiente:

1.- Manuales

1.1 Manual de la base de datos
1.2 Manual del diseñador de la base de datos por aplicación
1.3 Manual del operador de la base de datos


2.- Documentos por fase:

2.1 Fase I : Planeamiento de la base de datos.
2.2 Fase II: Análisis de la base de datos.
2.3 Fase III: Diseño de la base de datos .


I. Manuales
1.1 Manual de la base de datos.

El manual de la base de datos debe de incluir los siguientes. Ítems:

1.1.1 Nombre de la base de datos.
1.1.2 Objetivos de la base de datos.
1.1.3 Funciones principales.
1.1.4 Descripción de la base datos.
1.1.5 Alcances y restricciones de la base de datos.
1.1.6 Entradas de la base de datos (documentos fuentes).
1.1.7 Salidas de la base de datos (reportes).
1.1.8 Diseño funcional de la base de datos (carta estructurada).
1.1.9 Especificaciones de pantallas de ingreso/salida.
1.1.10 Diseño de la base de datos (estructura de archivos, longitud de registros,
entre otros).
1.1.11 Estimación del volumen de información procesada por el sistema.

1.1.13 Niveles de seguridad y control de la base de datos.
1.1.14 Especificación de requisitos de copias de respaldo, contingencia y
recuperación de errores.
1.1.15 Configuración mínima del equipo requerido
1.1.16 Identificación de las personas que constituyen el equipo de trabajo que
elaboré el sistema, indicando la responsabilidad de cada uno en el proyecto.


1.2 Manual de aplicación

El manual de aplicación deber de incluir los siguientes Ítems:

1.2.1 Nombre de la base de datos.
1.2.2 Objetivos de la base de datos.
1.2.3 Funciones principales de la base de datos.
1.2.4 Especificación de los archivos:
1.2.4.1 Descripción de los archivos
1.2.4.2 Estructura de los registros

1.2.5 Diseño de los reportes
1.2.6 Comandos de instrucciones de control requerido.
1.2.7 Prueba de la base de datos.

1.3 Manual del Operador de la base de datos.

Manual del operador de la base de datos deber de incluir los siguientes. Ítems:


1.3.1 Nombre de la base de datos.
1.3.2 Aplicaciones
1.3.2.1 Descripción
1.3.2.2 Procedimiento
1.3.2.3 Relación con otras aplicaciones
1.3.2.4 Condiciones de error (descripción correctivo).
1.3.3 Relación de Reportes
1.3.3.1 Descripción
1.3.3.2 Frecuencia
1.3.3.3 Diseño




______________________ _______________________
ENTIDAD PROVEEDOR
(Sello y firma) (Sello y firma)


CRONOGRAMA.

Ordena, jerarquiza y controla actividades o tareas que se deben realizar para lograr un objetivo o meta.








PRESUPUESTO.

¿Cuáles son los gastos del proyecto?

a) Recursos Humanos:


• Para el desarrollo de la base de datos se requerirán de 5 personas, puesto que el tiempo establecido para su desarrollo y entrega es corto.
• Se distribuirán las actividades conforme sea necesario.
• Cada uno tendrá que desarrollar parte de la base de datos de manera que todos colaboren y así poder obtenerla en el periodo de tiempo acordado.


b) Recursos Operacionales


• En una sola computadora se puede desarrollar la base de datos, pero como ya se menciono se dispone de un tiempo corto que ya ha sido establecido.

• Por lo que se requerirá que cada persona disponga de una computadora, en la cual este instalado Access 2007.

• 2 Licencias Originales de Office 2007 Professional (1 Licencia para 3 maquinas) $ 3,500 c/u de 2 $7000.

Para el desarrollo de este proyecto pues no se requerirá de una gran cantidad de recursos económicos, puesto que si no se cuentan con ellos se optara por elaborar la base de datos en una sola computadora y en la cual también todos trabajaran.


MARCO TEORICO.

GESTOR DE BASE DE DATOS.

Los Sistemas de Gestión de Base de Datos o SGBD (en inglés DataBase Management System) son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Se compone de un lenguaje de definición de datos, de un lenguaje de manipulación de datos y de un lenguaje de consulta.


Propósito.

El propósito general de los sistemas de gestión de bases de datos es el de manejar de manera clara, sencilla y ordenada un conjunto de datos que posteriormente se convertirán en información relevante para una organización.


Objetivos.

Existen distintos objetivos que deben cumplir los SGBD:

Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de abstracción.


Independencia. La independencia de los datos consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella.


• Consistencia. En aquellos casos en los que no se ha logrado eliminar la redundancia, será necesario vigilar que aquella información que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea. Por otra parte, la base de datos representa una realidad determinada que tiene determinadas condiciones, por ejemplo que los menores de edad no pueden tener licencia de conducir. El sistema no debería aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programación de este tipo de condiciones.


Seguridad. La información almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta información se encuentra segura de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos.


• Manejo de transacciones. Una Transacción es un programa que se ejecuta como una sola operación. Esto quiere decir que luego de una ejecución en la que se produce una falla es el mismo que se obtendría si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho más simple que si no se dispusiera de ellos.


• Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el SGBD tarda en darnos la información solicitada y en almacenar los cambios realizados.

Ventajas

• Proveen facilidades para la manipulación de grandes volúmenes de datos (ver objetivos),Entre éstas:
o Simplifican la programación de equipos de consistencia.
o Manejando las políticas de respaldo adecuadas, garantizan que los cambios de la base serán siempre consistentes sin importar si hay errores correctamente, etc.
o Organizan los datos con un impacto mínimo en el código de los programas.
o Bajan drásticamente los tiempos de desarrollo y aumentan la calidad del sistema desarrollado si son bien explotados por los desarrolladores.


• Usualmente, proveen interfaces y lenguajes de consulta que simplifican la recuperación de los datos.
Inconvenientes

1. Típicamente, es necesario disponer de una o más personas que administren de la base de datos, en la misma forma en que suele ser necesario en instalaciones de cierto porte disponer de una o más personas que administren de los sistemas operativos. Esto puede llegar a incrementar los costos de operación en una empresa. Sin embargo hay que balancear este aspecto con la calidad y confiabilidad del sistema que se obtiene.


2. Si se tienen muy pocos datos que son usados por un único usuario por vez y no hay que realizar consultas complejas sobre los datos, entonces es posible que sea mejor usar una planilla de cálculo.


3. Complejidad: el software muy complejo y las personas que vayan a usarlo deben tener conocimiento de las funcionalidades del mismo para poder aprovecharlo al máximo.


4. Tamaño: la complejidad y la gran cantidad de funciones que tienen hacen que sea un software de gran tamaño, que requiere de gran cantidad de memoria para poder correr.


5. Coste del hardware adicional: los requisitos de hardware para correr un SGBD por lo general son relativamente altos, por lo que estos equipos pueden llegar a costar gran cantidad de dinero.


MICROSOFT ACCESS.

Micosoft Access es un programa Sistema de gestión de base de datos relacional creado y modificado por Microsoft para uso personal de pequeñas organizaciones. Es un componente de la suite Microsoft Office aunque no se incluye en el paquete "básico". Una posibilidad adicional es la de crear ficheros con bases de datos que pueden ser consultados por otros programas. Dentro de un sistema de información entraría dentro de la categoria de Gestion y no en la de Ofimática como algunos creen.

Generalidades .

Software de gran difusión entre pequeñas empresas (PYMES) Microsoft OpenOffice Access permite crear formularios para insertar y modificar datos fácilmente. También tiene un entorno gráfico para ver las relaciones entre las diferentes tablas de la base de datos.
Tiene un sistema de seguridad de cifrado bastante primitivo y puede ser la respuesta a proyectos de programación de pequeños y medianos tamaños.

Historia .

Open Office Access versión 1.0 fue lanzado en noviembre de 1992, rápidamente en mayo de 1993 se lanzó access 1.1 para mejorar la compatibilidad con otros productos de Microsoft e incluir el lenguaje de programación de Access Basic.
Cómo empezar advierte sobre una serie de circunstancias en las que los controladores de dispositivo obsoletos o configuraciones incorrectas puede causar la pérdida de datos. Con la eliminación gradual de Windows 95, 98 y ME, la mejora de la confiabilidad de la red, y el lanzamiento de Microsoft de 8 Service Pack para el Jet Database Engine, la fiabilidad de las bases de datos de Access se ha mejorado enormemente tanto en tamaño como en número de usuarios.
Con Office 95, Microsoft Access 95 se convirtió en parte de Microsoft Open Office Professional Suite junto con Microsoft Excel, Word y PowerPoint y la transformación de Access Basic a Visual Basic para Aplicaciones (VBA). Desde entonces, ha habido liberaciones de Microsoft Access con cada versión de Office. Esto incluye el Access 97 (versión 8.0), Access 2000 (versión 9.0), Access 2002 (versión 10.0), Access 2003 (versión 11.0) y Access 2007 (versión 12.0). El formato de base de datos nativa de Access (la base de datos Jet MDB) también ha evolucionado a lo largo de los años. Incluyen los formatos de acceso 1.0, 1.1, 2.0, 95, 97, 2000, y 2002-2007. La más significativa fue la transición de Access 97 a Access 2000, formato que no era compatible antes, y Access 2000 requirió el nuevo formato. Desde Access 2000, todas las nuevas versiones de Access soportan este formato. Se añadieron nuevas características a Access 2002, que pudieron ser usadas por Access 2002, 2003 y 2007.


En Access 2007, un nuevo formato de base de datos se introdujo: ACCDB. El ACCDB soporta los tipos de datos más complejos, como archivos adjuntos y campos con múltiples valores. Estos nuevos tipos de campos son esencialmente de registros y permitir el almacenamiento de múltiples valores en un campo.

Antes del lanzamiento de Access, el mercado de base de datos de escritorio estaba dominado por Borland con sus programas Paradox y dBase, y FoxPro. Microsoft Access fue el primer programa en masa de base de datos para Windows. Con la compra de FoxPro y la incorporación de sus rutinas de optimización Rushmore dentro de Access, Microsoft Access se convirtió rápidamente en la principal base de datos para Windows de manera efectiva eliminando la competencia que no daba transición en el mundo MS-DOS.


Su nombre código fue Cirrus, el motor se llamó Ruby. Esto fue antes de Visual Basic, Bill Gates los llamo así y decidió que el lenguaje BÁSIC debía ser co-desarrollado como una aplicación ampliable, un proyecto denominado Thunder. Como los motores eran incompatibles entre si, estos proyectos fueron desarrollados por separado, sin embargo, estos se fusionaron de nuevo después de VBA.
Access también fue el nombre de un programa de comunicaciones de Microsoft, destinado a competir con Procomm y otros programas. Esto resultó ser un fracaso y se abandonó. Años más tarde, Microsoft reutilizó el nombre para su software de bases de datos.

Fechas de creacion
• 1992 Access 1.0
• 1993 Access 1.1
• 1992 Access 2.0
• 1995 Access 95
• 1997 Access 97
• 2000 Access 2000
• 2001 Access XP o 2002
• 2003 Access 2003
• 2007 Access 2007
• 2009 Access 2010 (beta)

Inconvenientes
Para bases de datos de gran tamaño (en cuanto a volumen de datos o de usuarios) es recomendable usar otros sistemas como MySQL o Microsoft SQL Server, y código VBA (Visual Basic para Aplicaciones).
Entre sus mayores inconvenientes figuran que no es multiplataforma, pues sólo está disponible para sistemas operativos de Microsoft, Su uso es inadecuado para grandes proyectos de software que requieren tiempos de respuesta críticos
Extensiones de archivo [editar]
Microsoft Access usa las siguientes extensiones para guardar sus datos:
.mdb -Base de datos de Access (Versión 2003 y anteriores)
.mde -Base de datos de Access protegida, con macros (Versión 2003 y anteriores)
.mdz -Extensión de plantillas en Access
.accdb - Base de datos de Access (Versión 2007)
.accde - Base de datos de Access protegida, con macros (Versión 2007 y anteriores)
.mam - Macro de Access
.maq - Consulta de Access
.mar - Informe de Access
.mat - Tabla de Access
.maf - Formulario de Access
.adp - Proyecto de Access
.adn - Plantilla de proyecto de Access




BASE DE DATOS.


Una base de datos es un “almacén” que nos permite guardar grandes cantidades de información de forma organizada para que luego podamos encontrar y utilizar fácilmente. Es una herramienta para recopilar y organizar información.


El término de bases de datos fue escuchado por primera vez en 1963, en un simposio celebrado en California, USA. 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.


En las bases de datos, se puede almacenar información sobre personas, productos, pedidos, o cualquier otra cosa. Muchas bases de datos empiezan siendo una lista en un programa de procesamiento de texto o en una hoja de cálculo. A medida que crece la lista, empiezan a aparecer repeticiones e inconsistencias en los datos. Cada vez resulta más complicado comprender los datos presentados en la lista y existen pocos métodos para buscar o recuperar subconjuntos de datos para revisarlos. Cuando empiezan a observarse estos problemas, es aconsejable transferir la información a una base de datos creada mediante un sistema de administración de bases de datos (DBMS), como Office Access 2007.


Una base de datos informatizada es un contenedor de objetos. Una base de datos puede contener más de una tabla. Por ejemplo, un sistema de seguimiento de inventario que utiliza tres tablas no es un conjunto de tres bases de datos, sino una sola base de datos que contiene tres tablas. Excepto si se ha diseñado específicamente para utilizar datos o código de otro origen, una base de datos de Access almacena sus tablas en un solo archivo, junto con otros objetos, como formularios, informes, macros y módulos. Las bases de datos creadas con formato de Access 2007 tienen la extensión de nombre de archivo .accdb y las bases de datos creadas con formatos de versiones anteriores de Access tienen la extensión de nombre de archivo .mdb. Access 2007 se puede utilizar para crear archivos con formatos de versiones anteriores (por ejemplo, Access 2000 y Access 2002-2003).
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.
Con Access se puede:
• Agregar más datos a una base de datos, por ejemplo, un elemento nuevo en un inventario.
• Modificar datos existentes en la base de datos, por ejemplo, cambiar la ubicación de un elemento.
• Eliminar información, por ejemplo, si se ha vendido o retirado un artículo.
• Organizar y ver los datos de distintas formas.
• Compartir los datos con otros usuarios mediante informes, mensajes de correo electrónico, una intranet o Internet.

Partes de una base de datos de Access
Componentes de una base de datos de Access típica.

• Tablas
• Formularios
• Informes
• Consultas
• Macros
• Módulos


Tablas


Una tabla de una base de datos es similar en apariencia a una hoja de cálculo, en cuanto a que los datos se almacenan en filas y columnas. Como consecuencia, normalmente es bastante fácil importar una hoja de cálculo en una tabla de una base de datos. La principal diferencia entre almacenar los datos en una hoja de cálculo y hacerlo en una base de datos es la forma de organizarse los datos.
Para lograr la máxima flexibilidad para una base de datos, la información tiene que estar organizada en tablas, para que no haya redundancias. Por ejemplo, si se almacena información sobre empleados, cada empleado se insertará una sola vez en una tabla que se configurará para contener únicamente datos de los empleados. Los datos sobre productos se almacenarán en su propia tabla, y los datos sobre sucursales también tendrán su tabla aparte. Este proceso se conoce como normalización.


Cada fila de una tabla se denomina registro. En los registros es donde se almacena cada información individual. Cada registro consta de campos (al menos uno). Los campos corresponden a las columnas de la tabla. Por ejemplo, puede trabajar con una tabla denominada "Empleados", en la que cada registro (fila) contiene información sobre un empleado distinto y cada campo (columna) contiene un tipo de información diferente, como el nombre, los apellidos, la dirección, o similares. Los campos se deben configurar con un determinado tipo de datos, ya sea texto, fecha, hora, numérico, o cualquier otro tipo.


Otra forma de describir registros y campos es imaginando un catálogo de fichas tradicional de una biblioteca. Cada ficha del armario corresponde a un registro de la base de datos. Cada información contenida en una ficha (autor, título, etc.) corresponde a un campo de la base de datos.
Formularios


Los formularios se conocen a veces como "pantallas de entrada de datos". Son las interfaces que se utilizan para trabajar con los datos y, a menudo, contienen botones de comando que ejecutan diversos comandos. Se puede crear una base de datos sin usar formularios, editando los datos de las hojas de las tablas. No obstante, casi todos los usuarios de bases de datos prefieren usar formularios para ver, escribir y editar datos en las tablas.


Los formularios proporcionan un formato fácil de utilizar para trabajar con los datos. Además, se les puede agregar elementos funcionales, como botones de comando. Puede programar los botones para determinar qué datos aparecen en el formulario, abrir otros formularios o informes, o realizar otras tareas diversas. Por ejemplo, podría crear un formulario denominado "Formulario de cliente" para trabajar con datos de clientes. El formulario de cliente podría tener un botón para abrir un formulario de pedido en el que se pudiese escribir un pedido nuevo del cliente.
Los formularios también permiten controlar la manera en que otros usuarios interactúan con los datos de la base de datos. Por ejemplo, puede crear un formulario que muestre únicamente ciertos campos y que permita la ejecución de determinadas operaciones solamente. Así, se favorece la protección de los datos y se facilita la entrada correcta de datos.


Informes


Los informes sirven para resumir y presentar los datos de las tablas. Normalmente, un informe responde a una pregunta específica, como "¿Cuánto dinero se ha facturado por cliente este año?" o "¿En qué ciudades están nuestros clientes?" Cada informe se puede diseñar para presentar la información de la mejor manera posible.


Un informe se puede ejecutar en cualquier momento y siempre reflejará los datos actualizados de la base de datos. Los informes suelen tener un formato que permita imprimirlos, pero también se pueden consultar en la pantalla, exportar a otro programa o enviar por correo electrónico.


Consultas


Las consultas son las que verdaderamente hacen el trabajo en una base de datos. Pueden realizar numerosas funciones diferentes. Su función más común es recuperar datos específicos de las tablas. Los datos que desea ver suelen estar distribuidos por varias tablas y, gracias a las consultas, puede verlos en una sola hoja de datos. Además, puesto que normalmente no desea ver todos los registros a la vez, las consultas le permiten agregar criterios para "filtrar" los datos hasta obtener solo los registros que desee. Las consultas a menudo sirven de origen de registros para formularios e informes.

Algunas consultas son "actualizables", lo que significa que es posible editar los datos de las tablas base mediante la hoja de datos de la consulta. Si trabaja con una consulta actualizable, recuerde que los cambios se producen también en las tablas, no solo en la hoja de datos de la consulta.
Hay dos tipos básicos de consultas: las de selección y las de acción. Una consulta de selección simplemente recupera los datos y hace que estén disponibles para su uso. Los resultados de la consulta pueden verse en la pantalla, imprimirse o copiarse al portapapeles. O se pueden utilizar como origen de registros para un formulario o un informe.


Una consulta de acción, como su nombre indica, realiza una tarea con los datos. Las consultas de acción pueden servir para crear tablas nuevas, agregar datos a tablas existentes, actualizar datos o eliminar datos.


Macros


Las macros en Access se pueden considerar como un lenguaje de programación simplificado, que se puede utilizar para aumentar la funcionalidad de la base de datos. Por ejemplo, puede adjuntar una macro a un botón de comando en un formulario, de modo que la macro se ejecute cuando se haga clic en el botón. Las macros contienen acciones que realizan tareas, como abrir un informe, ejecutar una consulta o cerrar la base de datos. Casi todas las operaciones de bases de datos que normalmente se realizan manualmente se pueden automatizar mediante macros, ahorrando así mucho tiempo.


Módulos


Los módulos, como las macros, son objetos que sirven para aumentar la funcionalidad de la base de datos. Mientras que las macros en Access se crean seleccionando acciones de una lista, los módulos se escriben en el lenguaje de programación de Visual Basic para Aplicaciones (VBA) (Visual Basic para Aplicaciones (VBA): versión del lenguaje de macros de Microsoft Visual Basic que se utiliza para programar aplicaciones basadas en Microsoft Windows y que se incluye en varios programas de Microsoft.). Un módulo es una colección de declaraciones, instrucciones y procedimientos que se almacenan conjuntamente como una unidad. Un módulo puede ser de clase o estándar. Los módulos de clase se adjuntan a formularios o informes, y normalmente contienen procedimientos específicos del formulario o el informe al que se adjuntan. Los módulos estándar contienen procedimientos generales que no están asociados a ningún otro objeto. Los módulos estándar se enumeran en Módulos en el panel de exploración, pero los módulos de clase no.

Definición de base de datos.


Se define una base de datos como una serie de datos organizados y relacionados entre sí, los cuales son recolectados y explotados por los sistemas de información de una empresa o negocio en particular.

Características.


Entre las principales características de los sistemas de base de datos podemos mencionar:
• Independencia lógica y física de los datos.
• Redundancia mínima.
• Acceso concurrente por parte de múltiples usuarios.
• Integridad de los datos.
• Consultas complejas optimizadas.
• Seguridad de acceso y auditoria.
• Respaldo y recuperación.
• Acceso a través de lenguajes de programación estándar.

Ventajas de las bases de datos.


Control sobre la redundancia de datos:
Los sistemas de ficheros almacenan varias copias de los mismos datos en ficheros distintos. Esto hace que se desperdicie espacio de almacenamiento, además de provocar la falta de consistencia de datos.
En los sistemas de bases de datos todos estos ficheros están integrados, por lo que no se almacenan varias copias de los mismos datos. Sin embargo, en una base de datos no se puede eliminar la redundancia completamente, ya que en ocasiones es necesaria para modelar las relaciones entre los datos.


Consistencia de datos:
Eliminando o controlando las redundancias de datos se reduce en gran medida el riesgo de que haya inconsistencias. Si un dato está almacenado una sola vez, cualquier actualización se debe realizar sólo una vez, y está disponible para todos los usuarios inmediatamente. Si un dato está duplicado y el sistema conoce esta redundancia, el propio sistema puede encargarse de garantizar que todas las copias se mantienen consistentes.


Compartición de datos:
En los sistemas de ficheros, los ficheros pertenecen a las personas o a los departamentos que los utilizan. Pero en los sistemas de bases de datos, la base de datos pertenece a la empresa y puede ser compartida por todos los usuarios que estén autorizados.


Mantenimiento de estándares:
Gracias a la integración es más fácil respetar los estándares necesarios, tanto los establecidos a nivel de la empresa como los nacionales e internacionales. Estos estándares pueden establecerse sobre el formato de los datos para facilitar su intercambio, pueden ser estándares de documentación, procedimientos de actualización y también reglas de acceso.


Mejora en la integridad de datos:
La integridad de la base de datos se refiere a la validez y la consistencia de los datos almacenados. Normalmente, la integridad se expresa mediante restricciones o reglas que no se pueden violar. Estas restricciones se pueden aplicar tanto a los datos, como a sus relaciones, y es el SGBD quien se debe encargar de mantenerlas.


Mejora en la seguridad:
La seguridad de la base de datos es la protección de la base de datos frente a usuarios no autorizados. Sin unas buenas medidas de seguridad, la integración de datos en los sistemas de bases de datos hace que éstos sean más vulnerables que en los sistemas de ficheros.


Mejora en la accesibilidad a los datos:
Muchos SGBD proporcionan lenguajes de consultas o generadores de informes que permiten al usuario hacer cualquier tipo de consulta sobre los datos, sin que sea necesario que un programador escriba una aplicación que realice tal tarea.


Mejora en la productividad:
El SGBD proporciona muchas de las funciones estándar que el programador necesita escribir en un sistema de ficheros. A nivel básico, el SGBD proporciona todas las rutinas de manejo de ficheros típicas de los programas de aplicación.
El hecho de disponer de estas funciones permite al programador centrarse mejor en la función específica requerida por los usuarios, sin tener que preocuparse de los detalles de implementación de bajo nivel.

Mejora en el mantenimiento:
En los sistemas de ficheros, las descripciones de los datos se encuentran inmersas en los programas de aplicación que los manejan.
Esto hace que los programas sean dependientes de los datos, de modo que un cambio en su estructura, o un cambio en el modo en que se almacena en disco, requiere cambios importantes en los programas cuyos datos se ven afectados.
Sin embargo, los SGBD separan las descripciones de los datos de las aplicaciones. Esto es lo que se conoce como independencia de datos, gracias a la cual se simplifica el mantenimiento de las aplicaciones que acceden a la base de datos.


Aumento de la concurrencia:
En algunos sistemas de ficheros, si hay varios usuarios que pueden acceder simultáneamente a un mismo fichero, es posible que el acceso interfiera entre ellos de modo que se pierda información o se pierda la integridad. La mayoría de los SGBD gestionan el acceso concurrente a la base de datos y garantizan que no ocurran problemas de este tipo.


Mejora en los servicios de copias de seguridad:
Muchos sistemas de ficheros dejan que sea el usuario quien proporcione las medidas necesarias para proteger los datos ante fallos en el sistema o en las aplicaciones. Los usuarios tienen que hacer copias de seguridad cada día, y si se produce algún fallo, utilizar estas copias para restaurarlos.
En este caso, todo el trabajo realizado sobre los datos desde que se hizo la última copia de seguridad se pierde y se tiene que volver a realizar. Sin embargo, los SGBD actuales funcionan de modo que se minimiza la cantidad de trabajo perdido cuando se produce un fallo.


Desventajas de las bases de datos.


Complejidad:
Los SGBD son conjuntos de programas que pueden llegar a ser complejos con una gran funcionalidad. Es preciso comprender muy bien esta funcionalidad para poder realizar un buen uso de ellos.

Coste del equipamiento adicional:
Tanto el SGBD, como la propia base de datos, pueden hacer que sea necesario adquirir más espacio de almacenamiento. Además, para alcanzar las prestaciones deseadas, es posible que sea necesario adquirir una máquina más grande o una máquina que se dedique solamente al SGBD. Todo esto hará que la implantación de un sistema de bases de datos sea más cara.


Vulnerable a los fallos:
El hecho de que todo esté centralizado en el SGBD hace que el sistema sea más vulnerable ante los fallos que puedan producirse. Es por ello que deben tenerse copias de seguridad (Backup).


Tipos de Campos.


Cada Sistema de Base de Datos posee tipos de campos que pueden ser similares o diferentes. Entre los más comunes podemos nombrar:


Numérico: entre los diferentes tipos de campos numéricos podemos encontrar enteros “sin decimales” y reales “decimales”.
Booleanos: poseen dos estados: Verdadero “Si” y Falso “No”.
Memos: son campos alfanuméricos de longitud ilimitada. Presentan el inconveniente de no poder ser indexados.
Fechas: almacenan fechas facilitando posteriormente su explotación. Almacenar fechas de esta forma posibilita ordenar los registros por fechas o calcular los días entre una fecha y otra.
Alfanuméricos: contienen cifras y letras. Presentan una longitud limitada (255 caracteres).
Autoincrementables: son campos numéricos enteros que incrementan en una unidad su valor para cada registro incorporado. Su utilidad resulta: Servir de identificador ya que resultan exclusivos de un registro.

Tipos de Base de Datos.

Entre los diferentes tipos de base de datos, podemos encontrar los siguientes:
• MySql: es una base de datos con licencia GPL basada en un servidor. Se caracteriza por su rapidez. No es recomendable usar para grandes volúmenes de datos.

• PostgreSql y Oracle: Son sistemas de base de datos poderosos. Administra muy bien grandes cantidades de datos, y suelen ser utilizadas en intranets y sistemas de gran calibre.
• Access: Es una base de datos desarrollada por Microsoft. Esta base de datos, debe ser creada bajo el programa Access, el cual crea un archivo .mdb con la estructura ya explicada.
• Microsoft SQL Server: es una base de datos más potente que Access desarrollada por Microsoft. Se utiliza para manejar grandes volúmenes de informaciones.
Modelo entidad-relación
Los diagramas o modelos entidad-relación (denominado por su siglas, ERD “Diagram Entity relationship”) son una herramienta para el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de información, sus inter-relaciones y propiedades.

Cardinalidad de las Relaciones.

El diseño de relaciones entre las tablas de una base de datos puede ser la siguiente:
• Relaciones de uno a uno: una instancia de la entidad A se relaciona con una y solamente una de la entidad B.
• Relaciones de uno a muchos: cada instancia de la entidad A se relaciona con varias instancias de la entidad B.
• Relaciones de muchos a muchos: cualquier instancia de la entidad A se relaciona con cualquier instancia de la entidad B.


ANALISIS DE RIESGOS.

Cuando nuestros datos son almacenados en bases de datos, con independencia de que sean bases del Estado o privadas, siempre surgen riesgos:


 Riesgo de que sean utilizados comercialmente para beneficio ajeno y encima seamos molestados con publicidad a nuestro nombre.

 Riesgo de uso delictivo para estafas bancarias, suplantación de identidad, chantaje, secuestro por mafias.

 Riesgo de que sean utilizados en nuestra contra por la policía o servicios de inteligencia que nunca tendrán suficiente control democrático y riesgo de su utilización por un futuro gobierno antidemocrático.

A la hora de ceder nuestros datos tenemos que tener muy claro que nunca tendremos la seguridad total de a donde acabarán yendo a parar, ni para qué acabarán siendo utilizados, por lo que siempre hay un riesgo potencial que nos obliga a valorar suficientemente si con ello obtenemos algún beneficio que nos compense y si podemos recuperar su control. Esto no debe volvernos paranoicos pero si prudentes. Los datos que damos pueden ser robados o vendidos por un funcionario o empleado infiel o ser utilizados con una finalidad diferente. Cuando entregamos nuestros datos nos han de ofrecer suficiente confianza de que serán tratados en nuestro beneficio y almacenados con suficiente seguridad. La tecnología moderna facilita la suplantación electrónica de nuestra identidad, también la difusión de información perjudicial (Registros de morosos).



PLANES DE GESTION DE RIESGOS.


La Gestión de Riesgos debe arrancar desde el inicio del Proyecto, durante el arranque de sus fases principales y siempre que se puedan producir cambios sustanciales que pudieran modificar las planificaciones y/o estimaciones.


La Gestión de Riesgos se compone fundamentalmente de cuatro pasos:
• Identificación del Riesgo
• Análisis del Riesgo
• Planificación y Gestión de las Medidas Preventivas y/o Correctoras
• Revisión Periódica del Estado del Riesgo hasta su desaparición.

Se propone la utilización de una matriz específica que sirva de soporte para la
Gestión de Riesgos. Esta matriz se utilizará en las reuniones de seguimiento y/o cuando se estime necesario (en el caso de situaciones excepcionales), y su contenido será el siguiente:



DOCUMENTACION DEL PROYECTO .


La documentación de los programas es un aspecto sumamente importante, tanto en el desarrollo de la aplicación como en el mantenimiento de la misma. Mucha gente no hace este parte del desarrollo y no se da cuenta de que pierde la posibilidad de la reutilización de parte del programa en otras aplicaciones, sin necesidad de conocerse el código al dedillo.


La documentación de un sistema empieza a la vez que la construcción del mismo y finaliza justo antes de la entrega del programa o aplicación al cliente. Así mismo, la documentación que se entrega al cliente tendrá que coincidir con la versión final de los programas que componen la aplicación.
Una vez concluido el programa, los documentos que se deben entregar son una guía técnica, una guía de uso y de instalación.

Tipos de documentación.

La documentación que se entrega al cliente se divide claramente en dos categorías, interna y externa:
•Interna: Es aquella que se crea en el mismo código, ya puede ser en forma de comentarios o de archivos de información dentro de la aplicación.
•Externa: Es aquella que se escribe en cuadernos o libros, totalmente ajena a la aplicación en si. Dentro de esta categoría también se encuentra la ayuda electrónica.


La guía técnica.

En la guía técnica o manual técnico se reflejan el diseño del proyecto, la codificación de la aplicación y las pruebas realizadas para su correcto funcionamiento. Generalmente este documento está diseñado para personas con conocimientos de informática, generalmente programadores.
El principal objetivo es el de facilitar el desarrollo, corrección y futuro mantenimiento de la aplicación de una forma rápida y fácil.

Esta guía está compuesta por tres apartados claramente diferenciados:
•Cuaderno de carga: Es donde queda reflejada la solución o diseño de la aplicación.
Esta parte de la guía es únicamente destinada a los programadores. Debe estar realizado de tal forma que permita la división del trabajo
•Programa fuente: Es donde se incluye la codificación realizada por los programadores. Este documento puede tener, a su vez, otra documentación para su mejor comprensión y puede ser de gran ayuda para el mantenimiento o desarrollo mejorado de la aplicación. Este documento debe tener una gran claridad en su escritura para su fácil comprensión.
•Pruebas: es el documento donde se especifican el tipo de pruebas realizadas a lo largo de todo el proyecto y los resultados obtenidos.


La guía de uso.

Es lo que comúnmente llamamos el manual del usuario. Contiene la información necesaria para que los usuarios utilicen correctamente la aplicación.
Este documento se hace desde la guía técnica pero se suprimen los tecnicismos y se presenta de forma que sea entendible para el usuario que no sea experto en informática.
Un punto a tener en cuenta en su creación es que no debe hacer referencia a ningún apartado de la guía técnica y en el caso de que se haga uso de algún tecnicismo debe ir acompañado de un glosario al final de la misma para su fácil comprensión.


La guía de instalación .
Es la guía que contiene la información necesaria para implementar dicha aplicación.
Dentro de este documento se encuentran las instrucciones para la puesta en marcha del sistema y las normas de utilización del mismo.
Dentro de las normas de utilización se incluyen también las normas de seguridad, tanto las físicas como las referentes al acceso a la información.



ENTREGA FINAL DEL PROYECTO.

En este punto, el trabajo inicia su producción, es decir que las partes deben asegurarse de que el trabajo cumpla con las expectativas del usuario y garantizar que su "instalación" y uso sean los correctos. En la medida en que es el contratista quien conoce el producto que ha sido terminado, el mismo es el responsable de su instalación.


Como ya se ha dicho, todo proyecto está destinado a finalizarse en un plazo predeterminado, culminando en la entrega de la obra al cliente o la puesta en marcha del sistema desarrollado, comprobando que funciona adecuadamente y responde a las especificaciones en su momento aprobadas. Esta fase es también muy importante no sólo por representar la culminación de la operación sino por las dificultades que suele presentar en la práctica, alargándose excesivamente y provocando retrasos y costes imprevistos.


Una vez entregado el proyecto éste es revisado, y se llevan a cabo las valoraciones pertinentes sobre lo planeado y lo ejecutado, así como sus resultados, en consideración al logro de los objetivos planteados.




BIBLIOGRAFIAS.

http://intimidadviolada.blogspot.com/2007/08/riesgos-de-las-bases-de-datos.html http://www.promainsur.com/sigepweb/docs/SIGEP-WEB_PP_GRI_01_00.pdf
http://www.desarrolloweb.com/articulos/importancia-documentacion.html
http://es.wikipedia.org/wiki/Microsoft_Access
http://www.maestrosdelweb.com/principiantes/%C2%BFque-son-las-bases-de-datos/ http://es.wikipedia.org/wiki/Sistema_de_gestión_de_bases_de_... - 37k
http://office.microsoft.com/es-es/access/HA100644503082.aspx