documento final completisimo

INSTITUTO TECNOLÓGICO DE DURANGO

DESARROLLO DE APLICACIONES PARA AMBIENTES DISTRIBUIDOS

“Unidad 1”

Alumno:

2012

Martínez Carrillo Jorge Alberto

No. De Control:

07040400

Maestro:

José Ramón Valdez Gutiérrez

Durango, Durango a 19 de febrero de 2012

TABLA DE CONTENIDORESUMEN GENERAL DEDESARROLLO DE APLICACIONES PARA AMBIENTES DISTRIBUIDOS..................................................................................3

PANORAMA GENERAL DE LAS APLICACIONES DISTRIBUIDAS.......................4

1.1Evolución de las Aplicaciones Informáticas.........................................................4

Introducción..........................................................................................................4

Palabras Clave......................................................................................................4

1.1Evolución de las Aplicaciones Informáticas (Continuación)................................5

Concepto propio....................................................................................................5

Componentes de una aplicación...........................................................................5

1.2 Aplicaciones Monolíticas....................................................................................6

Conceptos.............................................................................................................6

Concepto Propio...................................................................................................6

1.2 Aplicaciones Monolíticas (Continuación)............................................................7

Conceptos Aplicaciones Cliente - Servidor...........................................................7

Concepto Propio...................................................................................................7

Aplicaciones 2, 3 y N capas..................................................................................7

1.2 Aplicaciones Monolíticas(Continuación).............................................................8

Aplicaciones 2, 3 y N capas (Continuación)..........................................................8

1.2 Aplicaciones Monolíticas(Continuación).............................................................9

Aplicaciones 2, 3 y N capas..................................................................................9

Nivel de Dominio de Aplicación.............................................................................9

MARTÍNEZ CARRILLO JORGE ALBERTO

Aplicaciones 2, 3 y N capas (Continuación)........................................................10

Nivel de Repositorio............................................................................................10

Aplicaciones 2, 3 y N capas................................................................................10

Aplicaciones de dos capas..................................................................................10

Arquitectura de 2 capas......................................................................................10


Arquitectura de Aplicaciones de 3 capas............................................................11



Aplicaciones 2, 3 y N capas................................................................................12

Concepto Propio.................................................................................................12

1.3 Conceptos Aplicaciones Distribuidas...............................................................13

Es una aplicación con distintos componentes que se ejecutan en entornos separados, normalmente en diferentes plataformas conectadas a través de una red. Las típicas aplicaciones distribuidas son de dos niveles (cliente-servidor), tres niveles (cliente-middleware-servidor) y multinivel........................................13

Middleware: Sistema Distribuido organizado con un sistema. (Mi tecnologico)..13

Una aplicación con distintos componentes que se ejecutan en entornos separados, normalmente en diferentes plataformas conectadas a través de una red. Las típicas aplicaciones distribuidas son de dos niveles (cliente-servidor), tres niveles (cliente-middleware-servidor) y multinivel. (Wikipedia)....................13

Concepto propio..................................................................................................13

Ejemplos.............................................................................................................13

1.4 Problemas Comunes en el Desarrollo y uso de aplicaciones...........................14

Introducción........................................................................................................14

1.4 Problemas Comunes en el Desarrollo y uso de aplicaciones (Continuación). .15

Introducción (Continuación)................................................................................15

La arquitectura basada en RPC..........................................................................15


La arquitectura basada en RPC (Continuación)..................................................16

La arquitectura basada en clientes.....................................................................16



La arquitectura basada en clientes (Continuación).............................................17


La arquitectura basada en clientes (Continuación).............................................18

CONCLUSIÓN UNIDAD 1......................................................................................19

REFERENCIAS......................................................................................................20

ARQUITECTURA DE APLICACIONES DISTRIBUIDAS........................................23

II ARQUITECTURA DE APLICACIONES DISTRIBUIDAS.....................................24

2.1 Capa de interfaz de usuario.............................................................................24

2.2 Capa de manejo de datos................................................................................25

2.3 Capa de procesamiento de datos.....................................................................26

2.3 Capa de procesamiento de datos (Continuación)............................................27

2.4 Integración de sistemas heredados..................................................................27

2.4 Integración de sistemas heredados (Continuación).........................................28

2.5 Distribución de elementos de una aplicación...................................................28

2.5 Distribución de elementos de una aplicación (Continuación)...........................29

2.6 Integración de tecnologías heterogéneas y homogéneas................................29

2.7 Servicios de la arquitectura (email, web, base de datos, aplicaciones, transacciones, Sistemas operativos, firewall).........................................................30

CONCLUSION UNIDAD 2......................................................................................31

REFERENCIAS......................................................................................................32

DESARROLLO DE APLICACIONES PARA AMBIENTES DISTRIBUIDOS..........35

3.1 Diseño e implementación de manejo de datos.................................................36

3.1 Diseño e implementación de manejo de datos. (Continuación).......................37

3.1 Diseño e implementación de manejo de datos. (Continuación).......................38

3.2 Diseño de procesamiento de datos..................................................................39

3.2 Diseño de procesamiento de datos. (Continuación).........................................40

3.3 Diseño de interfaz de usuario...........................................................................41

Conceptos Generales.........................................................................................41

3.3 Diseño de interfaz de usuario. (Continuación).................................................42

Principios para el Diseño de Interfaces de Usuario............................................42

Anticipación.........................................................................................................42


Autonomía...........................................................................................................42


Percepción del Color...........................................................................................43

Valores por Defecto............................................................................................43

Consistencia.......................................................................................................43


Eficiencia del Usuario..........................................................................................44


Interfaces Explorables.........................................................................................45


Objetos de Interfaz Humana...............................................................................46

Uso de Metáforas................................................................................................46

Curva de Aprendizaje..........................................................................................46

Reducción de Latencia........................................................................................46

Protección del Trabajo........................................................................................46

Auditoría del Sistema..........................................................................................47

Legibilidad...........................................................................................................47

Interfaces Visibles...............................................................................................47

CONCLUSIÓN UNIDAD 3......................................................................................48

REFERENCIAS BIBLIOGRAFÍCAS.......................................................................49


Implementación de procesamiento de datos..........................................................53

4.1 Construcción de componentes.........................................................................53

Introducción:.......................................................................................................53

Desarrollo:...........................................................................................................53

4.1 Construcción de componentes (Continuación).................................................54

Desarrollo (Continuación)...................................................................................54

4.2 Comunicación con manejo de datos................................................................55

Introduccion:.......................................................................................................55

Desarrollo:...........................................................................................................55

Conclusión Unidad 4..............................................................................................56


REFERENCIAS......................................................................................................57


Implementación de interfaz de usuario...................................................................59

5.1 Lenguajes de marcado.....................................................................................59

Introducción:.......................................................................................................59

Desarrollo............................................................................................................59

Implementación de interfaz de usuario. (Continuación).........................................60

5.1 Lenguajes de marcado. (Continuación)............................................................60

5.2 Tecnologías para implementación de interfaces de usuario............................61

Introducción:.......................................................................................................61

Desarrollo:...........................................................................................................61

Tipos de interfaces:.............................................................................................61

5.2 Tecnologías para implementación de interfaces de usuario. (Continuación)...62

Tipos de interfaces de usuario:...........................................................................62

5.3 Programación...................................................................................................63

5.3.1 Del lado del cliente y 5.3.1 Del lado del servidor...........................................63

Introduccion:.......................................................................................................63

5.3 Programación...................................................................................................64

5.3.1 Del lado del cliente y 5.3.1 Del lado del servidor (Continuación)..................64

5.3 Programación...................................................................................................65


5.3 Programación...................................................................................................66


Lenguajes del lado cliente:..................................................................................66

Lenguajes del lado servidor:...............................................................................66

Conclusión Unidad 5..............................................................................................67

REFERENCIAS......................................................................................................68


6 Integración de aplicaciones distribuidas..............................................................70

6.1 Asignación de las partes de la aplicación.........................................................70

Introduccion:.......................................................................................................70


Desarrollo:...........................................................................................................70

6.2 Distribución de la aplicación.............................................................................71

Desarrollo:...........................................................................................................71

6.3 Instalación de los componentes.......................................................................72

Desarrollo:...........................................................................................................72

6.4 Configuración de los componentes..................................................................73

Desarrollo:...........................................................................................................73

6.5 Configuración de la aplicación..........................................................................73

Desarrollo:...........................................................................................................73

6.6 Evaluar desempeño.........................................................................................74

Desarrollo:...........................................................................................................74

6.7 Optimización del desempeño...........................................................................74

Desarrollo:...........................................................................................................74

Conclusion Unidad 6..............................................................................................75

REFERENCIAS......................................................................................................76



P á g i n a | 3

RESUMEN GENERAL DEDESARROLLO DE APLICACIONES PARA AMBIENTES DISTRIBUIDOS

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 cómo 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.



P á g i n a | 4

PANORAMA GENERAL DE LAS APLICACIONES DISTRIBUIDAS

1.1Evolución de las Aplicaciones Informáticas

Introducción

Una aplicación es un tipo de programa informático diseñado

como herramienta para permitir a un usuario realizar uno o

diversos tipos de trabajo. Suele resultar una solución

informática para la automatización de ciertas tareas

complicadas como pueden ser la contabilidad, la redacción de

documentos, o la gestión de un almacén. (Wikipedia)

Programa informático que permite a un usuario utilizar una

computadora con un fin específico. Las aplicaciones son parte

del software de una computadora, y suelen ejecutarse sobre el

sistema operativo. Una aplicación de software suele tener un

único objetivo: navegar en la web, revisar correo, explorar el

disco duro, editar textos, jugar (un juego es un tipo de

aplicación), etc. Una aplicación que posee múltiples

programas se considera un paquete. Tiene algún tipo de

interfaz con el usuario. (Alegsa)

Palabras Clave

Programa informático

Realizar tarea

Objetivo

Automatizar tareas



P á g i n a | 5

1.1Evolución de las Aplicaciones Informáticas (Continuación)

Concepto propio

Las aplicaciones son programas para computadora, los cuales

son diseñados de una manera específica, es decir que son

hechos a la medida para satisfacer la necesidad de realizar

alguna tarea. Generalmente están hechas para hacer una sola

cosa, pero existen algunos paquetes con varias aplicaciones

para el total desempeño en algún área en general..

Componentes de una aplicación

Es el conjunto de transacciones comerciales y financieras

realizadas por medios electrónicos. Esto es, el procesamiento

y la Una aplicación contiene: compilador, código fuente,

archivo objeto, archivo ensamblador, editor de vínculos,

funciones y bibliotecas, archivo fuente, archivo ejecutable.

Además de la interfaz con el usuario.

El compilador transforma el código fuente en código objeto y lo

guarda en un archivo objeto, es decir que traduce el archivo

fuente a lenguaje máquina (algunos compiladores también

crean un archivo en ensamblador, un lenguaje similar al

lenguaje máquina ya que posee las funciones básicas, pero

puede ser leído por los seres humanos. Luego, el compilador

llama a un editor de vínculos (o ensamblador) que permite

insertar los elementos adicionales (funciones y bibliotecas) a

los que hace referencia el programa dentro del archivo final,

pero que no se almacenan en el archivo fuente.



P á g i n a | 6

1.2 Aplicaciones Monolíticas

Conceptos

Las aplicaciones monolíticas son aquellas donde en una

aplicación todo estaba ligado o mezclado por decirlo de alguna

manera. Es decir, la interfaces de usuario, la lógica de cómo

funcionaba la empresa y el manejo de la información

almacenada y recuperada estaban juntas. (El guille)

Las aplicaciones son las que en un mismo archivo ejecutable

guardaba la presentación, la lógica de negocios y el acceso a

datos, el problema de lo anterior es que el mantenimiento

resultaba demasiado complicado, había que tirarse un clavado

en un mundo de instrucciones (a veces hasta 10,000 líneas)

hasta localizar la falla y peor aún en algunos casos se

arreglaba un problema pero se provocaban otros. (Colotlan)

Concepto Propio

Las aplicaciones monolíticas son el tipo de aplicaciones en las

cuales todos los componentes estaban en una misma capa y

eran diseñadas para un solo núcleo, solo que resulta muy

difícil dar el mantenimiento correspondiente precisamente por

el hecho de que todo estaba junto un programa de miles de

líneas.



P á g i n a | 7

1.2 Aplicaciones Monolíticas (Continuación)

Conceptos Aplicaciones Cliente - Servidor

Las aplicaciones monolíticas son el tipo de aplicaciones en las

cuales todos los componentes estaban en una misma capa y

eran diseñadas para un solo núcleo, solo que resulta muy

difícil dar el mantenimiento correspondiente precisamente por

el hecho de que todo estaba junto un un programa de miles de

líneas. (Wikipedia)

Es la tecnología que proporciona al usuario final el acceso

transparente a las aplicaciones, datos, servicios de cómputo o

cualquier otro recurso del grupo de trabajo y/o, a través de la

organización, en múltiples plataformas. El modelo soporta un

medio ambiente distribuido en el cual los requerimientos de

servicio hechos por estaciones de trabajo inteligentes o

"clientes'', resultan en un trabajo realizado por otros

computadores llamados servidores. (Monografías)

Concepto Propio

Son el tipo de aplicaciones en las cuales cada cliente o

usuario al tener acceso al servidor puede hacer el uso de

algún servicio (realización de alguna tarea ajena a sus

funciones) siendo todo esto transparente para el usuario.

Aplicaciones 2, 3 y N capas

Arquitectura de Dos Capas

La arquitectura de dos capas en la actualidad es muy

utilizada, aunque con muchas fallas, todavía no se ha podido

dejar de usar.



P á g i n a | 8

1.2 Aplicaciones Monolíticas(Continuación)

Aplicaciones 2, 3 y N capas (Continuación)

Estas arquitecturas fueron las primeras en aprovecharse de la

estructura cliente-servidor.

Las capas que esta arquitectura presenta son las siguientes:

Nivel de aplicación;

Nivel de la base de datos.

El nivel de Aplicación

Este nivel es en el que se encuentra toda la interfaz del

sistema y es la que el usuario puede disponer para realizar su

actividad con el sistema.

Nivel de la Base de Datos

Este nivel de la Base de Datos también llamado el Repositorio

de Datos, es la capa en donde se almacena toda la

información ingresada en el sistema y que se deposita en

forma permanente.

Arquitectura de Tres Capas

La arquitectura de dos capas si bien ayudó en unos años

atrás, se vio la necesidad de crear una nueva arquitectura ya

que en dos capas se tenía algunos problemas en la capa de

aplicación ya que la principal desventaja de esta era el peso

que tenia para el cliente, como se mencionó anteriormente.

Continua en la siguiente página



P á g i n a | 9

1.2 Aplicaciones Monolíticas(Continuación)

Arquitectura de Tres Capas (Continuación)

Por estas razones, existe una fuerte y bien avanzada

tendencia a adoptar una arquitectura de tres capas.


Y es así que se creó la arquitectura de tres capas las cuales

son:

Nivel de Aplicación

Nivel de Dominio de la aplicación;

Nivel de Repositorio.

Nivel de Aplicación

La diferencia de este nivel aplicado ahora en una arquitectura

de tres capas es que solo tiene que trabajar con la semántica

propia de aplicación, sin tener que preocuparse de cómo esta

implementado este ni de su estructura física.

Nivel de Dominio de Aplicación

En cambio este nivel se encarga de toda la estructura física y

el dominio de aplicación.

Algo muy importante y que es la mayor ventaja de esta

arquitectura es que ahora únicamente se cambia la regla en el

servidor de aplicación y esta actuará en todos los clientes,

cosa que ni sucedía con la arquitectura en dos capas que si

alguna regla se la cambia, se tenía que ir a cada cliente a

realizar el cambio.





P á g i n a | 10

Nivel de Repositorio

En realidad este nivel no ha cambiado para nada y sigue

siendo la capa en donde se almacenan los datos y toda la

información.


Herramientas para el Desarrollo de Aplicaciones en Tres

Capas

Las herramientas para el desarrollo de tres capas son:

• Visual Basic en lo que se refiere a la capa de Aplicación

• SQL Server en lo que se refiere al repositorio de datos.

• MTS en lo que se refiere al nivel del dominio de

Aplicación.

(Mi Tecnologíco)

Aplicaciones de dos 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. Continua en la siguiente página



P á g i n a | 11


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. Continua en la siguiente página


• 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. Continua en la siguiente página



P á g i n a | 12


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.

Concepto Propio

Son diferentes tipos de arquitecturas para aplicaciones en

donde se fue evolucionando de una capa donde se

concentraban todos los componentes en un mismo lugar,

luego de dos capas donde en una capa se reservaba para el

interfaz para el usuario y en el otro

las operaciones lógicas y la base de datos en un mecanismo

conocido como cliente servidoryasí mismo naciendo la

necesidad de construir una tercer capa para solucionar

problemas de implementación y mantenimiento que con solo

dos capas resultaría muy difícil..



P á g i n a | 13

1.3 Conceptos Aplicaciones Distribuidas

Es una aplicación con distintos componentes que se ejecutan en entornos separados, normalmente en diferentes plataformas conectadas a través de una red. Las típicas aplicaciones distribuidas son de dos niveles (cliente-servidor), tres niveles (cliente-middleware-servidor) y multinivel.

Middleware: Sistema Distribuido organizado con un sistema. (Mi tecnologico)

Una aplicación con distintos componentes que se ejecutan en entornos separados, normalmente en diferentes plataformas conectadas a través de una red. Las típicas aplicaciones distribuidas son de dos niveles (cliente-servidor), tres niveles (cliente-middleware-servidor) y multinivel. (Wikipedia)

Concepto propio

Son las aplicaciones en donde sus componentes se ejecutan en diferentes nodos o diferentes partes y en entornos separados haciendo que el funcionamiento sea como si la aplicación estuviera en cada lugar por completo, utilizando generalmente la arquitectura cliente/servidor.

Ejemplos

Transacción bancaria

Actualización de inventario en una tienda

SIIT.



P á g i n a | 14

1.4 Problemas Comunes en el Desarrollo y uso de aplicaciones

Introducción

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) y 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 cómo 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




P á g i n a | 15

1.4 Problemas Comunes en el Desarrollo y uso de aplicaciones (Continuación)

Introducción (Continuación)

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.




P á g i n a | 16


La arquitectura basada en RPC (Continuación)

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 clientes

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.




P á g i n a | 17


La arquitectura basada en clientes (Continuación)

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.

Interoperabilidad: 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.




P á g i n a | 18


La arquitectura basada en clientes (Continuación)

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.

(Mi tecnologico)



P á g i n a | 19

CONCLUSIÓN UNIDAD 1



P á g i n a | 20

REFERENCIAS

Trabajos citadosAladi. (s.f.). Recuperado el 1 de Febrero de 2012, de www.aladi.org/nsfaladi/estudios.nsf/.../$FILE/16-01Aab.ppt

Alegsa. (s.f.). Recuperado el Febrero de 2012, de http://www.alegsa.com.ar/Dic/aplicacion.php

Bicgalicia. (s.f.). Recuperado el 9 de Febrero de 2012, de http://www.bicgalicia.org/files/memofichas/gl/c02_05c_FormasdeComercioElectronico.pdf

Blog del Profesor López. (s.f.). Recuperado el 6 de Febrero de 2012, de http://blogdelprofesorlopez.blogspot.com/2010/04/empresas-punto-com-historia-y-crisis.html

Ciberconta. (s.f.). Recuperado el 8 de Febrero de 2012, de http://ciberconta.unizar.es/leccion/desatecno/200.HTM

Colotlan. (s.f.). Recuperado el Febrero de 2012, de http://colotlan1.blogspot.com/

Cultura Empresarial. (s.f.). Recuperado el 12 de Febrero de 2012, de http://culturaempresarialparatodos.blogspot.com/2009/02/12-elementos-de-un-plan-de-negocio.html

El guille. (s.f.). Recuperado el Febrero de 2012, de http://www.elguille.info/colabora/NET2005/Sagara_AplicacionesDistribuidas3Capas.htm

Gestiopolis. (s.f.). Recuperado el Marzo de 2012 , de http://www.gestiopolis.com/canales/demarketing/articulos/30/marketingbasesdatos.htm.

Informática Milenium. (s.f.). Recuperado el 10 de Febreri de 2012, de http://www.informaticamilenium.com.mx/paginas/mn/articulo20.htm

Ing. Sistemas. (s.f.). Recuperado el Febrero de 2012, de http://ingsistemas2013.fullblog.com.ar/diseno-de-interfaz-de-usuario.html

Justiano. (s.f.). Recuperado el 1 de Febrero de 2012, de www.justiniano.com/revista_doctrina/ecommerce.ppt



P á g i n a | 21

Manual Ecommerce. (s.f.). Recuperado el 6 de Febrero de 2012, de http://www.manual-ecommerce.info/empresa_punto_com

Mi tecnologico. (s.f.). Recuperado el Febrero de 2012, de http://www.mitecnologico.com/Main/AplicacionesDistribuidas

Mi tecnologico. (s.f.). Recuperado el Febrero de 2012, de http://www.mitecnologico.com/Main/ProblemasComunesEnDesarrolloYUsoAplicacionesDistribuidas

Mi Tecnologíco. (s.f.). Recuperado el Febrero de 2012, de http://www.mitecnologico.com/Main/Aplicaciones23YNcCapas

Monografías. (s.f.). Recuperado el Febrero de 2012, de http://www.monografias.com/trabajos24/arquitectura-cliente-servidor/arquitectura-cliente-servidor.shtml

Monografías.com. (s.f.). Recuperado el 10 de Febrero de 2012, de http://www.monografias.com/trabajos42/comercio-electronico/comercio-electronico2.shtml

MSDN. (MARZO de 2012). Obtenido de http://msdn.microsoft.com/es-es/library/cc466455(v=vs.71).aspx

Noticas el empleo. (s.f.). Recuperado el 6 de Febrero de 2012, de http://noticias.elempleo.com/colombia/investigacion_laboral/un-vistazo-a-las-puntocom/6585382

Nueva Economía. (s.f.). Recuperado el 8 de Febrero de 2012, de http://lasindias.net/indianopedia/Nueva_Econom%C3%ADa

Un negocio. (s.f.). Recuperado el 2 de Febrero de 2012, de http://www.un-negocio.com/negocios-online/negocios-electronicos.html


Wikipedia. (s.f.). Recuperado el Febrero de 2012, de http://es.wikipedia.org/wiki/Aplicaci%C3%B3n_inform%C3%A1tica

Wikipedia. (s.f.). Recuperado el Febrero de 2012, de http://es.wikipedia.org/wiki/Cliente-servidor



P á g i n a | 22

Wikipedia. (s.f.). Recuperado el Febrero de 2012, de http://es.wikipedia.org/wiki/Aplicaci%C3%B3n_distribuida


ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

“Unidad 2”

Alumno:


2012


P á g i n a | 23


No. De Control:

07040400

Maestro:


Durango, Durango a 5 de marzo de 2012



P á g i n a | 24

II ARQUITECTURA DE APLICACIONES DISTRIBUIDAS2.1 Capa de interfaz de usuario

La capa de interfaz de usuario la constituye el software con el que el usuario interactúa para operar con la aplicación. Es probablemente la parte más trabajosa de la misma, ya que es muy frecuente que aplicaciones cuyas reglas de negocio sean relativamente sencillas tengan en cambio un interfaz de usuario complejo y vistoso que le proporcione al usuario una experiencia de manejo fácil y agradable. Además, mientras que en la creación de reglas de negocio normalmente sólo interviene un tipo de programación, preferentemente basada en lenguajes, en la preparación del interfaz de usuario suelen mezclarse varias disciplinas, como el diseño o su uso.

Un error frecuente en la creación de las interfaces de usuario consiste en olvidar que las reglas de negocio no se hallan en el interfaz, sino en los objetos subyacentes que residen en las capas inferiores de la solución. La capa de presentación no es más que un sistema de presentación y manejo de datos que se obtienen y se actualizan con los objetos de negocio comunes para todas las aplicaciones que los usan. Si se olvida este aspecto se puede caer en la tentación de colocar reglas de negocio en el interfaz de usuario, imposibilitando la reutilización de las mismas y complicando la distribución y despliegue de la aplicación. Por lo tanto, una regla de oro a observar en toda aplicación distribuidas que la capa de presentación ha de ser completamente independiente de las reglas de negocio, y su función se limitará a la presentación y manejo de los datos de la aplicación, que obtendrá mediante el uso de los objetos de la capa de negocios comentados en la sección anterior. Esto convierte a la capa de interfaz de usuario en una mera fachada de los procesos que son gestionados por la capa de negocios. Las capas de presentación suelen ser “delgadas”, es decir, contienen pocas líneas de código, yaqué su función principal está cubierta por las características de los elementos “visuales” que las componen. Una tendencia creciente es la separación entre diseño y código, ya existente, por ejemplo, en las aplicaciones web dinámicas.



P á g i n a | 25

2.2 Capa de manejo de datos

La capa de manejo de datos representa el grueso de la lógica de funcionamiento de la aplicación distribuida. En esta capa se sitúan las normas de acceso a datos, la lógica de tratamiento de los mismos, y en general cualquier elemento de la aplicación que pueda reutilizarse. El objetivo de la creación de esta capa “intermedia” es aislar la capa de presentación de la capa de servidor, de forma quelas estructuras de datos subyacentes y la lógica que las utilizan sea independiente de la capa de presentación. De esta forma, también, el mantenimiento de las normas de negocio será más sencillo y, sobre todo, será reutilizable desde cualquier capa de presentación, sea del tipo que sea. A pesar de que se suele utilizar el nombre de capa de manejo de datos para referenciar a todos los elementos que componen esta capa intermedia de software, por lo general la capa de negocios suele dividirse en dos tipos de elementos, atendiendo a la función que desempeñan en la capa.



P á g i n a | 26

2.3 Capa de procesamiento de datos

Diagrama de la capa de manejo de datos.

En la capa de procesamiento de datos encontraremos los procesos de la aplicación que se encargan recibir las peticiones de las capas superiores y, si es necesario, devolver los datos solicitados. Esta función será desempeñada por un servicio. Los servicios son procesos que se ejecutan en los equipos servidores y que se mantienen a la escucha esperando que los procesos cliente les soliciten funcionalidad o datos. Por lo general los servicios residen en equipos dedicados cuya configuración y características físicas están especialmente diseñadas para realizar esta función. Los servicios de base de datos son los más frecuentes en las aplicaciones distribuidas.



P á g i n a | 27

Continua en la siguiente pagina2.3 Capa de procesamiento de datos (Continuación)

Los SGBD como SQL Server u Oracle disponen de toda La infraestructura de servicios necesarios para que los equipos cliente les realicen peticiones y para responder a ellas. Se ejecutan como un servicio de forma totalmente desatendida, se enlazan al protocolo de red para escuchar peticiones de otros equipos, gestionan la concurrencia de las llamadas e incorporan mecanismos de seguridad propios o integrables con el directorio activo. Una de las características más importantes de los SGBD es que nos permiten crear reglas de negocio. Estas reglas pueden invocarse remotamente desde los clientes y se escriben en lenguajes propios del SGBD (Transact-SQL en el caso de SQL Server, por ejemplo). Los SGBD compilan y ejecutan de la forma más óptima posible estas reglas, de modo que su ejecución siempre es de alto rendimiento.

2.4 Integración de sistemas heredados

Uno de los mayores problemas que deben resolver los administradores de Intranets es que muchos de los sistemas empresariales y las bases de datos denominados sistemas heredados fueron creados sin considerar el protocolo TCP/IP. Estos sistemas y bases de datos pueden estar basados en mainframes, minicomputadoras o en redes de computadoras, y se los puede incorporar a una Intranets de diversas maneras. En la actualidad, al pensar en una base de datos Cliente/Servidor es necesario analizar cuáles son las funcionalidades con las que cuenta este sistema para posibilitar la exhibición, negociación e integración de datos en la Web. La mayoría de los lenguajes y de los sistemas que actualmente funcionan en una red local basada en DOS o Windows no cuenta con integración y no puede ser transportada al entorno de Internet; cuando esto sucede es necesario volver a programar y crear una aplicación idéntica a la que se tenía para DOS o Windows para que se ejecute en la Web. Cuando se produce este tipo de situación, toda modificación en el sistema tiene que modificar ambas aplicaciones, la de DOS/Windows y la de la Web, algo que convierte el mantenimiento del sistema en costoso y poco viable.



P á g i n a | 28

Continua en la siguiente pagina

2.4 Integración de sistemas heredados (Continuación)

Oracle es uno de los sistemas que, incorporado a un servidor Web, posibilita la integración con varios lenguajes que pueden tratar datos y exhibirlos en una Intranets a través de una aplicación. Lo interesante es que en este caso no es necesario generar dos aplicaciones, una para el entorno de red de computadoras local (DOS/Windows) y otra para la Web, debido a que actualmente existen recursos que ya se encuentran incorporados en Oracle y que permiten escribir sólo una vez una única aplicación para más de un entorno.

2.5 Distribución de elementos de una aplicación

Por lo que respecta a los elementos que forman una aplicación distribuida, tales como los procesos, hilos de control, objetos y agentes. En este sentido, una aplicación distribuida requiere de dos niveles o capas que le servirán de base para su ejecución. En el nivel más bajo se ubica los protocolos de red que permiten el envío y comunicación de datos. El nivel alto, le corresponde al directorio deservicios junto con protocolos de seguridad. En el momento de ejecutar una aplicación de esta naturaleza, se hace uso deservicios de nivel medio, protocolos de red y sistemas operativos con la capacidad para desempeñar tareas coordinadas a través de la red.Los procesos (Processes). Pueden realizarse para una aplicación en particular o muchas aplicaciones pueden hacer uso de los procesos para el desarrollo de sus tareas. Se trata de una secuencia de pasos en determinado lenguaje de programación en su forma ejecutable ejecutándose en el sistema operativo.Hilos de control (Threads). Cada proceso tiene por lo menos un hilo de control. Si el SO soporta la creación de mas de un hilo de control por proceso, se hace necesaria la sincronización.

Objetos (Objects). Un objeto es un conjunto de datos relacionados, con métodos disponibles para la consulta y modificación de esos datos, o bien, para realizar alguna acción basada en los datos. Los procesos pueden hacer uso de uno o



P á g i n a | 29

mas objetos y los objetos pueden ser acezados por uno o mas hilos de control por proceso. Continua en la siguiente pagina



P á g i n a | 30

2.5 Distribución de elementos de una aplicación (Continuación)

Los objetos pueden estar dispersos a través de múltiples procesos, o bien, de múltiples computadoras.

Agentes (Agents). Es un elemento funcional en una aplicación distribuida. Es un componente de alto nivel con una función particular o utilidad o rol en todo el sistema.

2.6 Integración de tecnologías heterogéneas y homogéneas

Existen diferentes motivos para la heterogeneidad. Una razón obvia son los cambios tecnológicos que siempre se dan en un periodo de tiempo corto. En este contexto, dichos cambios se refieren a mejor calidad, mejor desempeño, costos más económicos, seguridad, entre otras características que se toman en cuenta. Otra razón es que la diversidad en una red de computadoras puede hacerla más resistente que cualquier problema dado en algún tipo de máquina, sistema operativo o aplicación son poco probables que afecten a otros sistemas corriendo en diferentes sistemas operativos y aplicaciones. En este contexto desarrollar aplicaciones distribuidas implica el análisis de protocolos además de un sin número de detalles y el uso de diferentes herramientas y librerías. De esta forma podemos definir la interoperabilidad como la habilidad de un sistema capaz de comunicarse con otro sistema sin esfuerzo alguno. La interoperabilidad está incrementando su importancia en los productos de tecnologías de información. Para poder alcanzar y lograr esto, dos o más sistemas que están por comunicarse deben seguir los estándares de interfaces abiertos que existen; otras de las formas en que podemos lograr la interoperabilidad es a través de un intermedio que pueda transformar la interfaz de comunicación de un sistema en la otra interfaz de comunicación de la otra aplicación en tiempo de ejecución. Algunos ejemplos de interoperabilidad que siguen estándares abiertos son: TCP/IP, HTTP y HTML.



P á g i n a | 31

2.7 Servicios de la arquitectura (email, web, base de datos, aplicaciones, transacciones, Sistemas operativos, firewall)

A medida que crece Internet y las tecnologías relacionadas, y las organizaciones buscan integrar sus sistemas entre límites de departamentos y de organización, ha evolucionado un enfoque de generación de soluciones basado en servicios. Desde el punto de vista del consumidor, los servicios son conceptualmente similares a los componentes tradicionales, salvo que los servicios encapsulan sus propios datos y no forman parte, estrictamente hablando, de la aplicación sino que son utilizados por ésta. Aplicaciones y servicios que necesitan integrarse se pueden generar en distintas plataformas, por distintos equipos, en diferentes programas y se pueden mantener y actualizar de forma independiente. Por tanto, es esencial que implemente la comunicación entre ellos con el mínimo acoplamiento. Se recomienda que implemente la comunicación entre los servicios empleando técnicas basadas en mensajes para proporcionar altos niveles de solidez y escalabilidad. Puede implementar la comunicación de mensajes de forma explícita (por ejemplo, escribiendo código para enviar y recibir mensajes de MessageQueue Server), o bien, puede utilizar componentes de infraestructuras que administran la comunicación de forma implícita (por ejemplo, con un servidor proxy de servicios Web generado por Microsoft Visual Studio® .NET).Los servicios exponen una interfaz de servicios a la que se envían todos los mensajes entrantes. La definición del conjunto de mensajes que se deben intercambiar con un servicio para que éste realice una tarea empresarial específica constituye un contrato. Puede imaginarse una interfaz de servicios como una fachada que expone la lógica empresarial implementada en el servicio para consumidores potenciales.



P á g i n a | 32

CONCLUSION UNIDAD 2

La tecnología ha hecho posible la comunicación de datos entre diferentes

equipos y entre usuarios; esta Conectividad es la que permite el uso de bases de

datos distribuidas, el intercambio electrónico de datos, la implantación de DSS y

DIS, las redes internacionales y los sistemas de punto de venta, entre muchas

otras aplicaciones, proporcionando un escenario de intercambio de información

con posibilidades ilimitadas.

Para soportar el proceso de comunicaciones existen diversos canales de

comunicación como los cables, la fibra óptica, las ondas de radio, microondas,

satélite e infrarrojos; todos estos medios proporcionan comunicación de datos a

distancia



P á g i n a | 33

REFERENCIAS















P á g i n a | 34
















P á g i n a | 35




“Unidad 3”

Alumno:


No. De Control:

07040400


2012


P á g i n a | 36

Maestro:


Durango, Durango a 16 de Marzo de 2012



P á g i n a | 37

3.1 Diseño e implementación de manejo de datos.

La interfaz de usuarios es la pantalla por la cual el usuario interactúa con el sistema, esta debe modificarse de vez en cuando ya que puede tornarse aburrida y monótona, la idea de esta es facilitar al usuario la comprensión y el manejo del sistema.Principales funciones son las siguientes:

* Puesta en marcha y apagado.

* Control de las funciones manipulables del equipo.

* Manipulación de archivos y directorios.

* Herramientas de desarrollo de aplicaciones.

* Comunicación con otros sistemas.

* Información de estado.

* Configuración de la propia interfaz y entorno.

* Intercambio de datos entre aplicaciones.

* Control de acceso.

* Sistema de ayuda interactivo.



http://ingsistemas2013.fullblog.com.ar/

http://adnetwork.fullservices.com.ar/acceso/x08129219815773862974/





P á g i n a | 38

3.1 Diseño e implementación de manejo de datos. (Continuación)

El principal objetivo de una interfaz de usuario es que éste se pueda comunicar a través de ella con algún tipo de dispositivo. Conseguida esta comunicación, el segundo objetivo que se debería perseguir es el de que dicha comunicación se pueda desarrollar de la forma más fácil y cómoda posible para el usuarioLas interfaces de usuario se dividen en los siguientes tipos:Según la forma de interactuar del usuarioInterfaces alfanuméricas (intérpretes de comandos) que solo presentan texto.

Interfaces gráficas de usuario (GUI, graphic user interfaces), las que permiten comunicarse con el ordenador de una forma muy rápida e intuitiva representando gráficamente los elementos de control y medida.Interfaces táctiles, que representan gráficamente un "panel de control" en una pantalla sensible que permite interactuar con el dedo de forma similar a si se accionara un control físico.

Según su construcción

Pueden ser de hardware o de software:Interfaces de hardware: Se trata de un conjunto de controles o dispositivos que permiten que el usuario intercambie datos con la máquina, ya sea introduciéndolos (pulsadores, botones, teclas, reguladores, palancas, manivelas, perillas) o leyéndolos (pantallas, diales, medidores, marcadores, instrumentos).

Interfaces de software: Son programas o parte de ellos, que permiten expresar nuestros deseos al ordenador o visualizar su respuesta. Continua en la siguiente pagina


http://adnetwork.fullservices.com.ar/f%C3%A1cil/o08129219721266173488/


P á g i n a | 39

3.1 Diseño e implementación de manejo de datos. (Continuación)

El dialogo es la comunicación entre el usuario y la computadora un buen dialogo facilita la utilización de la computadora y reduce las complicaciones que algunos usuarios puedan tener.

Los lineamientos para el diseño de un dialogo son:Comunicación significativa: el sistema de ser presentado de forma clara al usuario y evitar el utilizar mucho las abreviaciones y utilizar el titulo apropiado para cada pantalla.

Acción mínima del usuario:

* Codificar los códigos en lugar de las pantallas completas en la pantalla de entrada.

* Introducir únicamente datos que aún no están almacenados en los archivos.

* Proporcionar caracteres de edición.

* Usar valores predeterminados para los campos en las pantallas de entrada. Cualquier combinación de estas puede ayudar al analista a disminuir el número de pulsaciones requeridos por el usuario, por esa razón aumenta la entrada de datos y minimiza los errores.Funcionamiento normal y consistencia: el sistema debe ser consistente en el juego de pantallas en las diferentes aplicaciones, la consistencia hace más fácil al usuario una vez familiarizado con el sistema utilizarlo más cómodamente.

La retroalimentación son un conjunto de respuestas o reacciones que realiza el receptor con respecto a la actuación del emisor. En lo referente a sistemas es la


http://adnetwork.fullservices.com.ar/computadora/z08129219760891883780/


P á g i n a | 40

respuesta que tiene el usuario en relación al funcionamiento del sistema. (Ing. Sistemas)

3.2 Diseño de procesamiento de datos.

Si usa un proceso de diseño de base de datos establecido, puede crear de forma rápida y efectiva una base de datos bien diseñada que le proporciona acceso conveniente a la información que desea. Con un diseño sólido tardará menos tiempo en construir la base de datos y obtendrá resultados más rápidos y precisos.

Nota Los términos "base de datos" y "tabla" no son sinónimos en Visual FoxPro. El término base de datos (archivo .dbc) se refiere a una base de datos relacional que almacena información sobre una o más tablas (archivos .dbf) o vistas.

La clave para obtener un diseño de base de datos eficaz radica en comprender exactamente qué información se desea almacenar y la forma en que un sistema de administración de bases de datos relacionales, como Visual FoxPro, almacena los datos. Para ofrecer información de forma eficiente y precisa, Visual FoxPro debe tener almacenados los datos sobre distintos temas en tablas separadas. Por ejemplo, puede haber una tabla donde sólo se almacenen datos sobre empleados y otra tabla que sólo contenga datos de ventas.

Al organizar los datos de forma apropiada, proporciona flexibilidad a la base de datos y tiene la posibilidad de combinar y presentar información de muchas formas diferentes.

Al diseñar una base de datos, en primer lugar debe dividir la información que desea almacenar como temas distintos y después indicar a Visual FoxPro cómo se relacionan estos temas para que pueda recuperar la información correcta cuando sea necesario. Si mantiene la información en tablas separadas facilitará la organización y el mantenimiento de los datos y conseguirá aplicaciones de alto rendimiento.




P á g i n a | 41



P á g i n a | 42

3.2 Diseño de procesamiento de datos. (Continuación)

A continuación se indican los pasos que hay que seguir en el proceso de diseño de una base de datos. Cada paso se trata con mayor detalle en los temas restantes de esta sección.

1. Determinar el propósito de la base de datos Este paso le ayudará a decidir los datos que desea que Visual FoxPro almacene.

2. Determinar las tablas necesarias Cuando ya conozca claramente el propósito de la base de datos, puede dividir la información en temas distintos, como "Employees" u "Orders". Cada tema será una tabla de la base de datos.

3. Determinar los campos necesarios Tiene que decidir la información que desea incluir en cada tabla. Cada categoría de información de una tabla se denomina campo y se muestra en forma de columna al examinar la tabla. Por ejemplo, un campo de la tabla Employee podría ser Last_name y otro podría ser Hire_date.

4. Determinar las relaciones Observe cada tabla y decida cómo se relacionan sus datos con los de las tablas restantes. Agregue campos a las tablas o cree tablas nuevas para clarificar las relaciones, si es necesario.

5. Perfeccionar el diseño Busque errores en el diseño. Cree las tablas y agregue algunos registros de datos de ejemplo. Vea si puede obtener los resultados que desea de sus tablas. Haga los ajustes necesarios al diseño.

No se preocupe si se equivoca o si olvida algunos aspectos en el diseño inicial. Piense en él como en un borrador que podrá mejorar posteriormente. Pruebe con datos de ejemplo y con prototipos de los formularios e informes. Con Visual FoxPro resulta sencillo modificar el diseño de la base de datos durante su creación. Sin embargo, es mucho más difícil modificar las tablas cuando ya están llenas de datos y se han generado formularios e informes. Por este motivo, debe asegurarse de tener un diseño sólido antes de llegar demasiado lejos en la programación de una aplicación.(MSDN, 2012)



P á g i n a | 43

3.3 Diseño de interfaz de usuario.

Conceptos Generales

La Interfaz de Usuario, en adelante IU, de un programa es un conjunto de elementos hardware y software de una computadora que presentan información al usuario y le permiten interactuar con la información y con el computadora. También se puede considerar parte de la IU la documentación (manuales, ayuda, referencia, tutoriales) que acompaña al hardware y al software.

Si la IU está bien diseñada, el usuario encontrará la respuesta que espera a su acción. Si no es así puede ser frustrante su operación, ya que el usuario habitualmente tiende a culparse a sí mismo por no saber usar el objeto.

Los programas son usados por usuarios con distintos niveles de conocimientos, desde principiantes hasta expertos. Es por ello que no existe una interfaz válida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interacción que más se adecúe a sus objetivos en cada momento. La mayoría de los programas y sistemas operativos ofrecen varias formas de interacción al usuario.

Existen tres puntos de vista distintos en una IU: el del usuario, el del programador y el del diseñador (analogía de la construcción de una casa). Cada uno tiene un modelo mental propio de la interfaz, que contiene los conceptos y expectativas acerca de la misma, desarrollados a través de su experiencia.

El modelo permite explicar o predecir comportamientos del sistema y tomar las decisiones adecuadas para modificar el mismo. Los modelos subyacen en la interacción con las computadoras, de ahí su importancia.

Modelo del usuario: El usuario tiene su visión personal del sistema, y espera que éste se comporte de una cierta forma. Se puede conocer el modelo del usuario estudiándolo, ya sea realizando tests de usabilidad, entrevistas, o a través de una realimentación. Una interfaz debe facilitar el proceso de crear un modelo mental efectivo.

Para ello son de gran utilidad las metáforas, que asocian un dominio nuevo a uno ya conocido por el usuario. Un ejemplo


http://www.monografias.com/trabajos7/doin/doin.shtml

http://www.monografias.com/trabajos12/recoldat/recoldat.shtml#entrev

http://www.monografias.com/trabajos11/fuper/fuper.shtml

http://www.monografias.com/trabajos15/computadoras/computadoras.shtml

http://www.monografias.com/trabajos/adolmodin/adolmodin.shtml

http://www.monografias.com/trabajos/adolmodin/adolmodin.shtml

http://www.monografias.com/trabajos35/materiales-construccion/materiales-construccion.shtml

http://www.monografias.com/trabajos11/teosis/teosis.shtml

http://www.monografias.com/trabajos16/objetivos-educacion/objetivos-educacion.shtml

http://www.monografias.com/trabajos901/interaccion-comunicacion-exploracion-teorica-conceptual/interaccion-comunicacion-exploracion-teorica-conceptual.shtml

http://www.monografias.com/trabajos14/la-libertad/la-libertad.shtml

http://www.monografias.com/Computacion/Programacion/

http://www.monografias.com/trabajos35/categoria-accion/categoria-accion.shtml

http://www.monografias.com/cgi-bin/search.cgi?substring=0&bool=and&query=tutoriales

http://www.monografias.com/trabajos6/maca/maca.shtml

http://www.monografias.com/trabajos7/sisinf/sisinf.shtml

http://www.monografias.com/trabajos15/computadoras/computadoras.shtml

http://www.monografias.com/Computacion/Programacion/


P á g i n a | 44

típico es la metáfora del escritorio, común a la mayoría de las interfaces gráficas actuales.

3.3 Diseño de interfaz de usuario. (Continuación)

Modelo del diseñador: El diseñador mezcla las necesidades, ideas, deseos del usuario y los materiales de que dispone el programador para diseñar un producto de software. Es un intermediario entre ambos.

El modelo del diseñador describe los objetos que utiliza el usuario, su presentación al mismo y las técnicas de interacción para su manipulación. Consta de tres partes: presentación, interacción y relaciones entre los objetos (Figura 1).

La presentación es lo que primero capta la atención del usuario, pero más tarde pasa a un segundo plano, y adquiere más importancia la interacción con el producto para poder satisfacer sus expectativas. La presentación no es lo más relevante y un abuso en la misma (por ejemplo, en el color) puede ser contraproducente, distrayendo al usuario.

La segunda parte del modelo define las técnicas de interacción del usuario, a través de diversos dispositivos.

La tercera es la más importante, y es donde el diseñador determina la metáfora adecuada que encaja con el modelo mental del usuario. El modelo debe comenzar por esta parte e ir hacia arriba. Una vez definida la metáfora y los objetos del interfaz, los aspectos visuales saldrán de una manera lógica y fácil.

Principios para el Diseño de Interfaces de Usuario

Existen principios relevantes para el diseño e implementación de IU, ya sea para las IU gráficas, como para la Web.

Anticipación

Las aplicaciones deberían intentar anticiparse a las necesidades del usuario y no esperar a que el usuario tenga que buscar la información, recopilarla o invocar las herramientas que va a utilizar.

Autonomía

La computadora, la IU y el entorno de trabajo deben estar a disposición del usuario. Se debe dar al usuario el ambiente flexible para que pueda aprender rápidamente a usar la


http://www.monografias.com/trabajos15/medio-ambiente-venezuela/medio-ambiente-venezuela.shtml

http://www.monografias.com/trabajos5/laweb/laweb.shtml

http://www.monografias.com/trabajos15/logica-metodologia/logica-metodologia.shtml

http://www.monografias.com/trabajos5/colarq/colarq.shtml

http://www.monografias.com/trabajos35/el-poder/el-poder.shtml

http://www.monografias.com/trabajos14/deficitsuperavit/deficitsuperavit.shtml

http://www.monografias.com/trabajos6/juti/juti.shtml

http://www.monografias.com/trabajos14/propiedadmateriales/propiedadmateriales.shtml

http://www.monografias.com/trabajos11/estadi/estadi.shtml#METODOS


P á g i n a | 45

aplicación. Sin embargo, está comprobado que el entorno de trabajo debe tener ciertas cotas, es decir, ser explorable pero no azaroso. Continua en la siguiente pagina


Es importante utilizar mecanismos indicadores de estado del sistema que mantengan a los usuarios alertas e informados. No puede existir autonomía en ausencia de control, y el control no puede ser ejercido sin información suficiente. Además, se debe mantener información del estado del sistema en ubicaciones fáciles de visualizar.

Percepción del Color

Aunque se utilicen convenciones de color en la IU, se deberían usar otros mecanismos secundarios para proveer la información a aquellos usuarios con problemas en la visualización de colores

Valores por Defecto

No se debe utilizar la palabra "Defecto" en una aplicación o servicio. Puede ser reemplazada por "Estándar" o "Definida por el Usuario", "Restaurar Valores Iniciales" o algún otro término especifico que describa lo que está sucediendo. Los valores por defecto deberían ser opciones inteligentes y sensatas. Además, los mismos tienen que ser fáciles de modificar.

Consistencia

Para lograr una mayor consistencia en la IU se requiere profundizar en diferentes aspectos que están catalogados en niveles. Se realiza un ordenamiento de mayor a menor consistencia:

1. Interpretación del comportamiento del usuario: la IU debe comprender el significado que le atribuye un usuario a cada requerimiento. Ejemplo: mantener el significado de las los comandos abreviados (shortcut-keys) definidos por el usuario.

2. Estructuras invisibles: se requiere una definición clara de las mismas, ya que sino el usuario nunca podría llegar a descubrir su uso. Ejemplo: la ampliación de ventanas mediante la extensión de sus bordes.


http://www.monografias.com/trabajos16/comportamiento-humano/comportamiento-humano.shtml

http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtml



http://www.monografias.com/trabajos14/verific-servicios/verific-servicios.shtml

http://www.monografias.com/trabajos15/calidad-serv/calidad-serv.shtml#PLANT

http://www.monografias.com/trabajos14/control/control.shtml

http://www.monografias.com/trabajos12/elorigest/elorigest.shtml

http://www.monografias.com/trabajos15/valoracion/valoracion.shtml#TEORICA


P á g i n a | 46

3. Pequeñas estructuras visibles: se puede establecer un conjunto de objetos visibles capaces de ser controlados por el usuario, que permitan ahorrar tiempo en la ejecución de tareas específicas. Ejemplo: ícono y/o botón para impresión. Continua en la siguiente pagina


Consistencia (Continuación)

4. Una sola aplicación o servicio: la IU permite visualizar a la aplicación o servicio utilizado como un componente único. Ejemplo: La IU despliega un único menú, pudiendo además acceder al mismo mediante comandos abreviados.

5. Un conjunto de aplicaciones o servicios: la IU visualiza a la aplicación o servicio utilizado como un conjunto de componentes. Ejemplo: La IU se presenta como un conjunto de barras de comandos desplegadas en diferentes lugares de la pantalla, pudiendo ser desactivadas en forma independiente.

6. Consistencia del ambiente: la IU se mantiene en concordancia con el ambiente de trabajo. Ejemplo: La IU utiliza objetos de control como menúes, botones de comandos de manera análoga a otras IU que se usen en el ambiente de trabajo.

7. Consistencia de la plataforma: La IU es concordante con la plataforma. Ejemplo: La IU tiene un esquema basado en ventanas, el cual es acorde al manejo del sistema operativo Windows.

La inconsistencia en el comportamiento de componentes de la IU debe ser fácil de visualizar. Se debe evitar la uniformidad en los componentes de la IU. Los objetos deben ser consistentes con su comportamiento. Si dos objetos actúan en forma diferente, deben lucir diferentes. La única forma de verificar si la IU satisface las expectativas del usuario es mediante testeo.

Eficiencia del Usuario

Se debe considerar la productividad del usuario antes que la productividad de la máquina. Si el usuario debe esperar la respuesta del sistema por un período prolongado, estas pérdidas de tiempo se pueden convertir en pérdidas


http://www.monografias.com/trabajos6/prod/prod.shtml

http://www.monografias.com/trabajos15/ms-windows/ms-windows.shtml

http://www.monografias.com/trabajos14/verific-servicios/verific-servicios.shtml

http://www.monografias.com/trabajos901/evolucion-historica-concepciones-tiempo/evolucion-historica-concepciones-tiempo.shtml

http://www.monografias.com/trabajos15/todorov/todorov.shtml#INTRO


P á g i n a | 47

económicas para la organización. Los mensajes de ayuda deben ser sencillos y proveer respuestas a los problemas. Los manuales y etiquetas de botones deberían tener las palabras claves del proceso.


http://www.monografias.com/trabajos6/napro/napro.shtml


P á g i n a | 48


Eficiencia del Usuario (Continuación)

Ley de Fitt

El tiempo para alcanzar un objetivo es una función de la distancia y tamaño del objetivo. Es por ello, que es conveniente usar objetos grandes para las funciones importantes.

Interfaces Explorables

Siempre que sea posible se debe permitir que el usuario pueda salir ágilmente de la IU, dejando una marca del estado de avance de su trabajo, para que pueda continuarlo en otra oportunidad.

Para aquellos usuarios que sean noveles en el uso de la aplicación, se deberá proveer de guías para realizar tareas que no sean habituales.

Es conveniente que el usuario pueda incorporar elementos visuales estables que permitan, no solamente un desplazamiento rápido a ciertos puntos del trabajo que esté realizando, sino también un sentido de "casa" o punto de partida.

La IU debe poder realizar la inversa de cualquier acción que pueda llegar a ser de riesgo, de esta forma se apoya al usuario a explorar el sistema sin temores.

Siempre se debe contar con un comando "Deshacer". Este suprimirá la necesidad de tener que contar con diálogos de confirmación para cada acción que realice en sistema.

El usuario debe sentirse seguro de poder salir del sistema cuando lo desee. Es por ello que la IU debe tener un objeto fácil de accionar con el cual poder finalizar la aplicación.



http://www.monografias.com/trabajos5/segu/segu.shtml

http://www.monografias.com/trabajos13/ripa/ripa.shtml

http://www.monografias.com/trabajos16/marca/marca.shtml

http://www.monografias.com/trabajos7/mafu/mafu.shtml

http://www.monografias.com/trabajos7/mafu/mafu.shtml

http://www.monografias.com/trabajos16/objetivos-educacion/objetivos-educacion.shtml


P á g i n a | 49


Objetos de Interfaz Humana

Los objetos de interfaz humana no son necesariamente los objetos que se encuentran en los sistemas orientados a objetos. Estos pueden ser vistos, escuchados, tocados o percibidos de alguna forma. Además, estos objetos deberían ser entendibles, consistentes y estables.

Uso de Metáforas

Las buenas metáforas crean figuras mentales fáciles de recordar. La IU puede contener objetos asociados al modelo conceptual en forma visual, con sonido u otra característica perceptible por el usuario que ayude a simplificar el uso del sistema.

Curva de Aprendizaje

El aprendizaje de un producto y su usabilidad no son mutuamente excluyentes. El ideal es que la curva de aprendizaje sea nula, y que el usuario principiante pueda alcanzar el dominio total de la aplicación sin esfuerzo.

Reducción de Latencia

Siempre que sea posible, el uso de tramas (multi-threading) permite colocar la latencia en segundo plano (background). Las técnicas de trabajo multitarea posibilitan el trabajo ininterrumpido del usuario, realizando las tareas de transmisión y computación de datos en segundo plano.

Protección del Trabajo

Se debe poder asegurar que el usuario nunca pierda su trabajo, ya sea por error de su parte, problemas de transmisión de datos, de energía, o alguna otra razón inevitable.



http://www.monografias.com/trabajos11/basda/basda.shtml

http://www.monografias.com/Computacion/index.shtml

http://www.monografias.com/trabajos5/teap/teap.shtml

http://www.monografias.com/trabajos5/elso/elso.shtml


P á g i n a | 50

Auditoría del Sistema

La mayoría de los navegadores de Internet (browsers), no mantienen información acerca de la situación del usuario en el entorno, pero para cualquier aplicación es conveniente conocer un conjunto de características tales como: hora de acceso al sistema, ubicación del usuario en el sistema y lugares a los que ha accedido, entre otros. Además, el usuario debería poder salir del sistema y al volver a ingresar continuar trabajando en lugar dónde había dejado.

Legibilidad

Para que la IU favorezca la usabilidad del sistema de software, la información que se exhiba en ella debe ser fácil de ubicar y leer. Para lograr obtener este resultado se deben tener en cuenta alguna como: el texto que aparezca en la IU debería tener un alto contraste, se debe utilizar combinaciones de colores como el texto en negro sobre fondo blanco o amarillo suave. El tamaño de las fuentes tiene que ser lo suficientemente grande como para poder ser leído en monitores estándar. Es importante hacer clara la presentación visual (colocación/agrupación de objetos, evitar la presentación de excesiva información.

Interfaces Visibles

El uso de Internet, ha favorecido la implementación de interfaces invisibles. Esto significa que el usuario siempre ve una página específica, pero nunca puede conocer la totalidad del espacio de páginas de Internet. La navegación en las aplicaciones debe ser reducida a la mínima expresión. El usuario debe sentir que se mantiene en un único lugar y que el que va variando es su trabajo. Esto no solamente elimina la necesidad de mantener mapas u otras ayudas de navegación, sino que además brindan al usuario una sensación de autonomía


http://www.monografias.com/trabajos11/cartuno/cartuno.shtml

http://www.monografias.com/trabajos37/monitores/monitores.shtml

http://www.monografias.com/trabajos10/formulac/formulac.shtml#FUNC

http://www.monografias.com/trabajos5/colarq/colarq.shtml

http://www.monografias.com/Computacion/Internet/

http://www.monografias.com/trabajos15/introduccion-informatica/introduccion-informatica.shtml#navegad


P á g i n a | 51

CONCLUSIÓN UNIDAD 3

Las integración de los principios, prototipos y heurísticas de

evaluación durante el proceso de diseño de IU permite la

creación de interfaces que satisfacen las expectativas del

Modelo del Usuario, el cual es el punto de vista mas

importante para garantizar la aceptación de un sistema.

Entre las características que contribuyen a construir una

interfaz sencilla de utilizar, sobresale la utilización de

metáforas como ayuda para simplificar al usuario en la

operación del sistema.

La prototipación es un proceso de uso frecuente durante el

diseño de IU. A través diferentes niveles evolutivos de

prototipos se pueden lograr simulaciones del sistema a

construir con un alto grado de detalle, pudiendo validar los

requisitos de diseño que se hayan propuesto.

Las heurísticas de evaluación de IU permiten identificar

problemas que interfieran en la operación del sistema,

resultando de ellas un diagnóstico que puede ser utilizado

como retroalimentación para una nueva versión optimizada de

la interfaz de usuario.


http://www.monografias.com/trabajos5/teorsist/teorsist.shtml#retrp

http://www.monografias.com/trabajos11/funpro/funpro.shtml


P á g i n a | 52

REFERENCIAS BIBLIOGRAFÍCAS














P á g i n a | 53
















P á g i n a | 54





“Unidad 4”

Implementación de procesamiento de datos

Alumno:



2012


P á g i n a | 55

No. De Control:

07040400

Maestro:




P á g i n a | 56

Implementación de procesamiento de datos4.1 Construcción de componentes

Introducción:

Un método eficiente para la construcción y utilización de componentes reusables es el modelo IPS (Industrialización de la Producción de Software), un modelo que permite disponer de una vía clara y nítida, además de eficaz, para la creación de componentes reusables, independiente del(los)dominio(s) tecnológico(s) de nuestra empresa; asegurando además que serán suficientes unos pocos componentes (en torno a 50 elementos) para alcanzar altas cotas (más del 60%) de reutilización real en la fabricación de nuestros sistemas. Es la denominada Eficacia Controlada del modelo IPS.

Desarrollo:

Esta Eficacia Controlada es un factor importante por muchos motivos. En primer lugar porque con él enviamos un mensaje claro a los clientes: no estamos haciendo ninguna clase de experimento con ustedes. Nos comprometemos a que usted obtenga unos resultados cuantificables y medibles.

En segundo lugar, porque además de este compromiso de resultados, derivado de la Eficacia Controlada, este factor nos permite conocer, de antemano, cuanto esfuerzo requerirá disponer del conjunto de componentes reusables, cual será el plazo necesario para hacerlo y cual debe ser el volumen de recursos involucrados para alcanzar el objetivo.




P á g i n a | 57

4.1 Construcción de componentes (Continuación)

Desarrollo (Continuación)

Pero además, los beneficios del uso de componentes reusables no pueden llegar a mediano plazo, han de llegar en el plazo más corto posible: han de llegar desde el primer sistema que la empresa fabrique con ellos. Para una empresa es la mejor manera de estar segura de que ha hecho lo correcto y lo que es muy importante, recuperar su inversión.



P á g i n a | 58

4.2 Comunicación con manejo de datos

Introduccion:

La explosión de nuevas tecnologías que empezó con la introducción del PC y la llegada del Internet en los noventas, le ha brindado al marketing nuevas opciones y herramientas que son explotadas con gran intensidad en la actualidad. Una de ellas es la utilización de instrumentos de información en la generación de bases de datos.

Desarrollo:

La importancia de tener bases de datos:

Conocer a los clientes y saber sus preferencias es un recurso vital en el desarrollo de productos y estrategias de ventas. Poder conocer con exactitud los datos básicos de segmentación del cliente (sexo, edad, preferencias básicas etc) y tal vez poder ir más allá en el conocimiento (preferencias personales, aficiones, gustos básicos, marcas preferidas) resultan recursos muy valiosos para las empresas.

Los datos recogidos de los clientes, formarán bases de clientes, de usuarios registrados y de posibles compradores, quienes serán susceptibles de recibir información actualizada de productos y servicios ofrecidos.

En este entorno, la recopilación de bases de datos servirá a las empresas para:

Mantener comunicación constante con los clientes (mail, teléfono, correo etc) (Gestiopolis)



P á g i n a | 59

Conclusión Unidad 4

El procesamiento de los datos adecuado a las

características de la Tecnología permite eficiencia y

confiabilidad en el resultado de las muestras a

procesar para obtener un diagnóstico seguro.

Disponer de una herramienta informática para

materializarlos en los laboratorios de Tecnología ha

hecho posible interpretaciones diagnósticas basadas

en procedimientos de cálculo complejos.

Consecuentemente repercute positivamente en la

elevación de la calidad de la red de laboratorios de

Tecnología y por consiguiente en el funcionamiento

de los programas de Salud para el pesquisaje

masivo.



P á g i n a | 60

REFERENCIAS

Trabajos citados

Gestiopolis (s.f.). Recuperado el Marzo de 2012, de

http://www.gestiopolis.com/canales/demarketing/articulos/30/marketingbasesdatos.htm



“Unidad 5”

IMPLEMENTACION DE INTERFAZ DE USUARIO


2012


P á g i n a | 61

Alumno:


No. De Control:

07040400

Maestro:


Implementación de interfaz de usuario.5.1 Lenguajes de marcado.

Introducción:

Un “Lenguaje de marcado” o “lenguaje de marcas” se puede definir como una forma de codificar un documento donde, junto con el texto, se incorporan etiquetas, marcas o anotaciones con información adicional relativa a la estructura del texto, su presentación.

Desarrollo

Anotación (metadatos): información añadida al documento que no forman parte del texto en sí mismo.

Lenguajes de marcado (de anotaciones): conjunto de reglas que describen cómo deben realizarse

Anotaciones, bajo qué condiciones se permiten y su significado.

Los lenguajes de marcado se pueden clasificar en:

• Procedimental:

– Describen operaciones tipográficas

• Estructural:



P á g i n a | 62

– Describen la estructura lógica de un documento, pero no

su tipografía

• Híbrido:

– Combinación de ambos

Otra posible clasificación sería:

• De presentación:


Implementación de interfaz de usuario. (Continuación)5.1 Lenguajes de marcado. (Continuación)

– Indica el formato del texto (información para el

maquetado).

• De procedimientos:

– Orientado también a la presentación pero, en este caso, se

Indican los procedimientos que deberá realizar el SW de representación.

• Descriptivo o semántico:

– Describen las diferentes partes en las que se estructura el documento pero sin especificar cómo deben representarse.

Algunos lenguajes de marcado específicos:

– Documentación electrónica

• RTF

• TeX

• Wikitexto



P á g i n a | 63

• DocBook

– Tecnologías de internet

• HTML, XHTML

• RDF (recurso-propiedad(relación)-valor)

• RSS

– Otros lenguajes especializados

• MathML

• VoiceXML

• SVG

5.2 Tecnologías para implementación de interfaces de usuario.

Introducción:

Interfaz de usuario: Las interfaces básicas de usuario son aquellas que incluyen elementos como menús, ventanas, teclado, ratón, los beeps y algunos otros sonidos que la computadora hace, y en general, todos aquellos canales por los cuales se permite la comunicación entre el ser humano y la computadora. La mejor interacción humano-máquina a través de una adecuada interfaz de Usuario, que le brinde tanto comodidad, como eficiencia.

Desarrollo:

Tipos de interfaces:

Dentro de las Interfaces de Usuario se puede distinguir básicamente tres tipos:

A) Interfaz de hardware, a nivel de los dispositivos utilizados para ingresar, procesar y entregar los datos: teclado, ratón y pantalla visualizadora.



P á g i n a | 64

B) Una interfaz de software, destinada a entregar información acerca de los procesos y herramientas de control, a través de lo que el usuario observa habitualmente en la pantalla.

C) Una interfaz de software-hardware, que establece un puente entre la máquina y las personas, permite a la máquina entender la instrucción y a el hombre entender el código binario traducido a información legible.



P á g i n a | 65

5.2 Tecnologías para implementación de interfaces de usuario. (Continuación)

Tipos de interfaces de usuario:

❖ Según la forma de interactuar del usuario:

Atendiendo a como el usuario puede interactuar con una interfaz, nos encontramos con varios tipos de interfaces de usuario:➢ Interfaces alfanuméricas: (intérpretes de mandatos) que sólo presentan texto.

➢ Interfaces gráficas de usuario: (GUI, graphics user interfaces) las que permiten comunicarse con el ordenador de una forma muy rápida e intuitiva representando gráficamente los elementos de control y medida.

➢ Interfaces táctiles: Que representan gráficamente un "panel de control" en una pantalla sensible que permite interaccionar con el dedo de forma similar a si se accionara un control físico.



P á g i n a | 66

5.3 Programación5.3.1 Del lado del cliente y 5.3.1 Del lado del servidor

Introduccion:

El navegador es una especie de aplicación capaz de interpretar las órdenes recibidas en forma de código HTML fundamentalmente y convertirlas en las páginas que son el resultado de dicha orden.

Cuando nosotros pinchamos sobre un enlace hipertexto, en realidad lo que pasa es que establecemos una petición de un archivo HTML residente en el servidor (un ordenador que se encuentra continuamente conectado a la red) el cual es enviado e interpretado por nuestro navegador (el cliente).

Así pues, podemos hablar de lenguajes de lado servidor que son aquellos lenguajes que son reconocidos, ejecutados e interpretados por el propio servidor y que se envían al cliente en un formato comprensible para él. Por otro lado, los lenguajes de lado cliente (entre los cuales no sólo se encuentra el HTML sino también el Java y el JavaScript los cuales son simplemente incluidos en el código HTML) son aquellos que pueden ser directamente "digeridos" por el navegador y no necesitan un pretratamiento.



P á g i n a | 67

5.3 Programación5.3.1 Del lado del cliente y 5.3.1 Del lado del servidor (Continuación)

Desarrollo:

Imagenes



P á g i n a | 68


Cada uno de estos tipos tiene por supuesto sus ventajas y sus inconvenientes. Así, por ejemplo, un lenguaje de lado cliente es totalmente independiente del servidor, lo cual permite que la página pueda ser albergada en cualquier sitio sin necesidad de pagar más ya que, por regla general, los servidores que aceptan páginas con scripts de lado servidor son en su mayoría de pago o sus prestaciones son muy limitadas. Inversamente, un lenguaje de lado servidor es independiente del cliente por lo que es mucho menos rígido respecto al cambio de un navegador a otro o respecto a las versiones del mismo.


P á g i n a | 69


Lenguajes del lado cliente:

El lenguaje llamado HTML indica al navegador donde colocar cada texto, cada imagen o cada video y la forma que tendrán estos al ser colocados en la página.

El lenguaje consta de etiquetas que tienen esta forma o . Cada etiqueta significa una cosa, por ejemplo significa que se escriba en negrita (bold) o significa un párrafo, <A> es un enlace, etc. Casi todas las etiquetas tienen su correspondiente etiqueta de cierre, que indica que a partir de ese punto no debe de afectar la etiqueta. Por ejemplo se utiliza para indicar que se deje de escribir en negrita. Así que el HTML no es más que una serie de etiquetas que se utilizan para definir la forma o estilo que queremos aplicar a nuestro documento. Esto está en negrita.

Lenguajes del lado servidor:

Es el sistema más antiguo que existe para la programación de las páginas dinámicas de servidor. Actualmente se encuentra un poco desfasado por diversas razones entre las que destaca la dificultad con la que se desarrollan los programas y la pesada carga que supone para el servidor que los ejecuta.

Los CGI se escriben habitualmente en el lenguaje Perl, sin embargo, otros lenguajes como C, C++ o Visual Basic pueden ser también empleados para construirlos.


P á g i n a | 70

Conclusión Unidad 5

Hemos visto en estas entradas dedicadas a los mercados cómo estos son descritos, por una parte, como los enemigos de una guerra metafórica y, por otra, como una entidad sufriente, capaz de experimentar emociones. La metáfora bélica traslada la representación de un enemigo de poder ilimitado y, lo que nos parece más interesante, de una pluralidad monolítica tras la que se esconden los integrantes individuales que componen el bando de los mercados. Este enmascaramiento refleja la complejidad de la realidad económica para cuya explicación se tiende a buscar imágenes esquemáticas. La integración de la multiplicidad de agentes económicos implicados en un ente único parece facilitar la comprensión de la crisis, pero, al mismo tiempo, cabría preguntarse hasta qué punto esta simplificación podría operar en el sentido opuesto, oscureciendo la realidad y escondiendo a los verdaderos responsables tras una denominación en la que solo queda la pista de la pluralidad. Podemos identificar un enemigo, un culpable, pero realmente no sabemos quién es. Estamos inmersos en una guerra, pero no sabemos contra quién. El lenguaje expresa esta circunstancia y, a la vez, parece de largo plazo.



P á g i n a | 71

REFERENCIAS

Trabajos citados

Blog (s.f.). Recuperado el 2012, de

http://ponss.blogs.uv.es/2012/05/17/los-mercados-conclusiones-y-iii/



“Unidad 6”

INTEGRACIÓN DE APLICACIONES DISTRIBUIDAS


2012


P á g i n a | 72

Alumno:


No. De Control:

07040400

Maestro:




P á g i n a | 73

6 Integración de aplicaciones distribuidas.6.1 Asignación de las partes de la aplicación.

Introduccion:

Una aplicación con distintos componentes que se ejecutan en entornos separados, normalmente en diferentes plataformas conectadas a través de una red. Las típicas aplicaciones distribuidas son de dos niveles (cliente-servidor), tres niveles (cliente-middleware-servidor) y multinivel.

Desarrollo:

Dependiendo de la forma de interacción entre las partes, tenemos distintos modelos de aplicaciones:

• Orientado a los mensajes, Para aplicaciones que pueden tolerar cierto nivel de independencia frente al tiempo de las respuestas.

• Redes entre iguales (p2p), computación en malla (Grid): Todos los miembros del sistema son iguales. No hay tareas predefinidas entre ellos. Comparten recursos.

•Cliente/Servidor, Las aplicaciones se dividen en dos partes: una de ellas (cliente) inicia la comunicación con una petición y la otra (servidor) responde a esa petición.



P á g i n a | 74

6.2 Distribución de la aplicación.

Desarrollo:

Una vez puesta a punto y finalizada la aplicación será necesario distribuirla al usuario o usuarios mediante un programa de instalación que realice tareas como:

* Copiar todos los archivos necesarios para ejecutar la aplicación

* Crear la estructura de directorios que contendrán los archivos necesarios para ejecutar la aplicación

* Registrar archivos

* Crear un menú de inicio o grupo

* Crear un icono en el escritorio del usuario

Visual Basic puede hacer esto por nosotros para ello es necesario seguir 2 pasos:

1. Packaging, será necesario empaquetar los archivos que requiere la aplicación en 1 o más archivos .cab (cabinet file) y que puedan ser colocados en la ubicación deseada, también será necesario crear los programas de instalación para ciertos tipos de empaquetamientos. Un archivo con extesión .cab es un archivo comprimido.

2. Deployment, será necesario poner la aplicación empaquetada en un medio de almacenamiento para que los usuario puedan instalarla lo cual significa por ejemplo copiar el paquete a un disco, una ubicación de red o sitio web.



P á g i n a | 75

6.3 Instalación de los componentes.

Desarrollo:

Para instalar o actualizar componentes de Tivoli Enterprise Console desde la línea de comandos, necesita el nombre del archivo de índice de cada componente. Los nombres de archivos de índice para la instalación son diferentes de los utilizados para la actualización. Los archivos de índice son archivos ASCII que contiene instrucciones específicas del componente para cada imagen de instalación. Los archivos de índice especifican el identificador de producto registrado de un componente del producto, sentencias de dependencia y la información necesaria para instalar ese componente en cada uno de los sistemas operativos compatibles.

Identificador de producto registrado. Para desinstalar componentes de Tivoli Enterprise Console desde la línea de comandos, necesita el identificador de producto registrado de cada componente. El identificador de producto registrado es el nombre que se ha asignado al componente que está contenido en una imagen de instalación y, también, es el primer valor de cada línea del archivo de índice del componente.

Componente necesario. Para instalar ciertos componentes de Tivoli Enterprise Console en un nodo gestionado, debe instalar antes este componente específico en dicho nodo gestionado o la instalación fallará.



P á g i n a | 76

6.4 Configuración de los componentes.

Desarrollo:

Un componente. Es una unidad Sw cuya finalidad y dependencia están completamente definida por un conjunto de interfaces públicas. Los componentes pueden cambiarse con otros componentes sin hacer referencia a su implementación y pueden ser desplegados como una unidad ejecutable. La composición de componentes. Es el proceso de enlazar componentes para un sistema. Los tipos de composición incluyen: composición secuencial, composición jerárquica y composición aditiva.

6.5 Configuración de la aplicación.

Desarrollo:

Proporciona a los programadores y administradores control y flexibilidad sobre la manera en que se ejecutaran las aplicaciones, un administrador puede controlar a que recursos protegidos puede tener acceso una aplicación, que versiones de ensamblados utiliza la aplicación y donde se ubicara las aplicaciones.



P á g i n a | 77

6.6 Evaluar desempeño.

Desarrollo:

Es un método de retroalimentación del comportamiento laboral que nos ayuda a tomar decisiones respecto al desarrollo, remuneración, promoción y establecimiento del plan de carrera del trabajador. : 1. Ofrecen información con base en la cual pueden tomarse decisiones de desarrollo, remuneración, promoción y plan de carreras. 2. Ofrecen la oportunidad para que el supervisor y subordinado se reúnan y revisen el comportamiento relacionado con el trabajo. 3. Lo anterior permite que ambos desarrollen un plan para corregir cualquier deficiencia y mejorar el desempeño. 4. La evaluación ofrece la oportunidad de revisar el proceso de desarrollo de gerentes y los planes de carrera del trabajador a la luz de las fuerzas y debilidades demostradas.

6.7 Optimización del desempeño

Desarrollo:

Es posible optimizar el rendimiento del sistema para diferentes clases de usuarios, aunque los usos de canales cruzados observaran alguna degradación. Con la posibilidad de monitorear el tráfico y el desempeño no es posible tomar las decisiones de manejo necesarias de reconfigurar, expandir o modificar.



P á g i n a | 78

Conclusion Unidad 6

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



P á g i n a | 79

REFERENCIAS

Trabajos citados

WIKISPACESs (s.f.). Recuperado de 2012, de http://ginoz.wikispaces.com/UNIDAD+6+AMBIENTES+DISTRIBUIDOS


documento final completisimo

Documents