Arquitectura distribuida. Arquitectura de sistemas distribuidos. sistemas de archivos distribuidos "transparentes"
AggreGate es una de las pocas plataformas de IoT en el mundo que realmente admite una arquitectura distribuida. Esto proporciona escalabilidad ilimitada para equilibrar y dividir todas las operaciones del servidor AggreGate en varios niveles. Una arquitectura de este tipo puede ser la base tanto para resolver los problemas actuales como para satisfacer las necesidades futuras.
A diferencia de un clúster de conmutación por error, los servidores AggreGate en una arquitectura distribuida son completamente independientes. Cada servidor tiene el suyo propia base datos, cuentas usuarios locales y permisos asociados.
Arquitectura distribuida AggreGate es extremadamente flexible. Técnicamente, se basa en la formación de conexiones peer-to-peer entre servidores y en la conexión de partes de un único modelo de datos de algunos servidores ("proveedores") a otros ("consumidores").
Objetivos de las operaciones distribuidas
Los principales objetivos de una arquitectura distribuida son:
- Escalabilidad. Servidores nivel inferior puede tener una gran carga, recopilar datos y administrar una gran cantidad de dispositivos casi en tiempo real. Sin embargo, en la práctica, la cantidad de dispositivos a los que un servidor puede dar servicio está limitada a varios miles. Al escalar el sistema para gestionar un gran número dispositivos, tiene sentido instalar varios servidores y combinarlos como parte de una instalación distribuida.
- Equilibrio de carga. Cada servidor en una instalación distribuida resuelve su propio problema. Los servidores de gestión de red comprueban la disponibilidad y el rendimiento. infraestructura de red, los servidores de control de acceso procesan las solicitudes de los controladores de puertas y torniquetes. Las operaciones de control, como la generación de informes y el envío por correo, se pueden realizar en un servidor central.
- Protección contra intrusiones. Los servidores de sonda secundarios se pueden instalar en lugares remotos y conectado a un servidor central. Los operadores del sistema se conectan únicamente al servidor central, lo que elimina la necesidad de configurar VPN y reenvío de puertos a estos servidores.
- Centralización. Los servidores secundarios pueden funcionar completamente. modo automático, mientras que su configuración y seguimiento se realiza a través de servidor principal, instalado en la sala de control central.
Distribución de roles del servidor
En este sencillo escenario, dos servidores se combinan en una infraestructura distribuida. Los operadores del sistema están constantemente conectados al servidor de monitoreo mientras realizan sus tareas diarias. La dirección de la empresa se conecta al servidor de informes y análisis cuando necesita obtener una instantánea de los datos. Independientemente del volumen de datos y la carga en el servidor, esta operación no afectará el trabajo de los operadores.
Plataforma IoT en la nube a gran escala
Telecomunicaciones y servicios en la nube ofrecer servicios de IoT utilizando modelos IaaS/PaaS/SaaS. En estos casos hablamos de millones de dispositivos pertenecientes a miles de usuarios. Mantener una infraestructura tan grande requiere cientos de servidores AggreGate, la mayoría de los cuales se pueden agrupar en dos grupos:
- Servidores que almacenan un registro de usuarios y sus dispositivos, redirigen conexiones de operadores y dispositivos a servidores de nivel inferior, y también agregan datos para el posterior análisis de información que involucra servidores de nivel inferior.
- Servidores que monitorean y administran dispositivos, así como también reciben, almacenan y procesan datos.
Los servidores de administración de usuarios y dispositivos también son responsables de interactuar con sistema de nube Management, que implementa nuevos servidores de análisis y almacenamiento de datos y también monitorea su funcionamiento.
Los servidores de almacenamiento y procesamiento de datos utilizan recursos (alarmas, modelos, flujos de trabajo, paneles, etc.) obtenidos de servidores de plantillas, que a su vez almacenan copias maestras de estos recursos.
Infraestructura de IoT de varios niveles
Gracias a la infraestructura distribuida de AggreGate, cualquier solución puede incluir muchos servidores diferentes niveles. Algunos de ellos pueden trabajar en puertas de enlace de IoT, recopilando datos, otros pueden almacenar y procesar información, y el resto puede realizar agregación de alto nivel y computación distribuida.
Los equipos de campo, como sensores y actuadores, se pueden conectar a servidores directamente, a través de agentes, puertas de enlace o una combinación de estos.
Gestión de ciudades inteligentes
Este es un ejemplo basado en AggreGate arquitectura multicapa Para automatización compleja grupo grande edificios:
- Nivel 1: equipo fisico (enrutadores de red, controladores, equipos industriales, etc.)
- Nivel 2: servidores de gestión (servidores de monitorización de redes, servidores de control de acceso, servidores de automatización de edificios y otros)
- Nivel 3: centros de control de servidores del edificio (un servidor por edificio, que recopila información de todos los servidores de segundo nivel)
- Nivel 4: Servidores del área de la ciudad (destino final para escalar alertas sobre nivel bajo, monitoreo en tiempo real, integración con sistemas Service Desk)
- Nivel 5: servidores de la oficina central (supervisión de los servidores del distrito, recopilación y resumen de informes, alertas)
Cualquiera de los servidores anteriores puede ser clúster de conmutación por error, que consta de varios nodos.
Gestión de red multisegmento.
AggreGate Network Manager se basa en la plataforma AggreGate y es un ejemplo típico del uso de arquitectura distribuida. Las redes grandes y segmentadas de corporaciones y operadores de telecomunicaciones no se pueden controlar desde un solo centro debido a restricciones de enrutamiento, políticas de seguridad o restricciones. ancho de banda Canales de comunicación con segmentos de red remotos.
Por lo tanto, un sistema de monitoreo distribuido generalmente consta de los siguientes componentes:
- Primario o central un servidor que recopila información de todos los segmentos de la red
- Secundario servidores o servidores de sonda, dispositivos de sondeo en segmentos aislados
- Especializado Servidores como servidores de análisis de tráfico que procesan miles de millones de eventos NetFlow por día.
Los servidores secundarios y especializados son proveedores de información del servidor primario, proporcionando parte de su modelo de datos al centro de control. Podría ser:
- Todo el contenido del árbol contextual del servidor de sonda, que permite un control completo sobre la configuración con servidor central. En este caso, el servidor de sonda se utiliza simplemente como proxy para superar el problema de segmentación de la red.
- Alertas generadas por el servidor de la sonda. En este caso, el 99% de las estaciones de trabajo pueden ser remotas y el operador del servidor central recibirá inmediatamente notificaciones de los servidores secundarios.
- Conjuntos personalizados datos de servidores de sonda, como información operativa sobre la condición es crítica dispositivos importantes o informes resumidos. Todo el trabajo relacionado se realizará en el servidor secundario, permitiendo distribuir la carga.
Gestión de eventos de alto rendimiento
Algunos casos de uso de la plataforma AggreGate, como la gestión centralizada de incidentes, requieren que se reciba, procese y almacene de manera persistente una cantidad significativa de eventos en un formato estructurado. A veces, las transmisiones pueden alcanzar volúmenes de millones de eventos por segundo y recibirse de diferentes fuentes.
EN casos similares un servidor AggreGate no puede hacer frente a todo el flujo de eventos. Una arquitectura distribuida ayudará a organizar el procesamiento de eventos:
- En los objetos que generan eventos, se instalan varios servidores locales que procesan estos eventos. Se pueden conectar varias fuentes (sondas) a un servidor de procesamiento.
- Un servidor de almacenamiento dedicado o un clúster de almacenamiento de big data de múltiples servidores está asociado a cada servidor de procesamiento local. La cantidad de nodos del clúster puede variar según la velocidad a la que se generan los eventos.
- Todos los servidores de almacenamiento local realizan filtrado previo, deduplicación, correlación (mediante reglas que se aplican a las sondas conectadas localmente), enriquecimiento y almacenamiento de eventos.
- Servidores locales Los almacenamientos están conectados a un servidor de agregación central. El servidor de agregación es responsable de correlacionar eventos importantes en todo el sistema.
- Los operadores del servidor central pueden ver toda la base de datos de eventos, con la tarea de buscar datos actualizados distribuidos entre los servidores de almacenamiento. De esta manera, es posible crear informes y alertas centralizados basados en una base de datos de todos los eventos.
Empresa Digital
AggreGate puede actuar como una plataforma de coordinación para la empresa digital. Cada servidor AggreGate puede realizar varias funciones que van desde el seguimiento y la gestión objetos remotos y terminar con servicios de alto nivel, como análisis de negocio o, por ejemplo, gestión de incidentes.
Todos los servidores de una empresa digital están conectados entre sí a través de una infraestructura distribuida. Los servidores de nivel inferior brindan acceso a parte de los contextos de un único modelo de datos a los servidores. nivel superior, permitiéndole crear un centro de situación para toda la empresa.
Los sistemas de información automatizados distribuidos se han convertido ahora en una realidad cotidiana. Numerosos sistemas de información automatizados corporativos utilizan bases de datos distribuidas. Se han desarrollado métodos para la distribución de datos y la gestión de datos distribuidos. enfoques arquitectónicos, asegurando la escalabilidad de los sistemas, implementando los principios de la arquitectura cliente-servidor de múltiples niveles, así como la arquitectura de capa intermedia.
Empezando a ponerse en práctica arquitecturas móviles. Esto se aplica tanto a los sistemas de bases de datos como a las aplicaciones web.
El enfoque de la construcción está reviviendo sistemas distribuidos, basado en una arquitectura peer-to-peer (Peer-to-Peer), en la que, a diferencia de la arquitectura cliente-servidor dominante en los sistemas distribuidos hoy en día, los roles de las partes que interactúan en la red no son fijos. Se asignan según la situación de la red y la carga en sus nodos.
Debido al desarrollo intensivo tecnologías de la comunicación El AIS móvil se está desarrollando activamente. Desarrollado medios tecnicos y software para crearlos. Gracias a esto, comenzaron a desarrollar sistemas móviles bases de datos. Muchos equipos científicos investigan las características específicas de estos sistemas y crean varios prototipos de ellos. Una herramienta esencial para el desarrollo móvil software se convirtieron en tecnologías Java.
Estándar de protocolo creado acceso inalámbrico aplicaciones en la Web (Protocolo de aplicaciones inalámbricas - WAP), que ya es compatible con algunos modelos teléfonos celulares. Basado en WAP y lenguaje XML El consorcio W3C desarrolló un lenguaje de marcado para comunicaciones inalámbricas WML (lenguaje de marcado inalámbrico).
En los desarrollos de AIS se ha prestado más atención a los metadatos. En este sentido, se están tomando medidas en dos direcciones: estandarizar la presentación de los metadatos y garantizar su soporte en el sistema.
AIS utiliza una variedad de métodos y medios para presentar metadatos (varios tipos de repositorios de metadatos). La falta de unificación en este ámbito complica significativamente la solución de los problemas de movilidad de las aplicaciones, reutilizar e integración de recursos de información y tecnologías de la información, así como reingeniería de AIS.
Para superar estas dificultades, se están desarrollando activamente estándares de metadatos centrados en diversas tecnologías de la información. En este ámbito, ya existen una serie de estándares internacionales, nacionales e industriales que definen la presentación de metadatos y el intercambio de metadatos en AIS. Algunas de ellas ya han adquirido el estatus de normas de facto. Nos limitaremos aquí a mencionar sólo los más significativos.
Probablemente el primer estándar de facto en esta categoría fue el lenguaje de descripción de datos CODASYL para bases de datos. estructura de red. Los estándares más recientes incluyen: el estándar del lenguaje de consulta SQL para bases de datos relacionales, que contiene una definición del llamado esquema de información- un conjunto de representaciones de esquemas de bases de datos relacionales; un componente del estándar de base de datos de objetos ODMG que describe las interfaces del repositorio de esquemas de objetos; estándar internacional IRDS (Sistemas de diccionario de recursos de información), que describe sistemas para crear y mantener directorios de recursos de información organizacionales.
A continuación, cabe mencionar el estándar CWM (Common Warehouse Metamodel) desarrollado por el consorcio OMG para la representación de metadatos de data warehouse, basado en el estándar OIM (Open Information Model) previamente creado para propósitos más amplios por el consorcio MDC (Meta Data Coalition).
La nueva plataforma de tecnología XML para la Web también incluye estándares para representar metadatos. El soporte de metadatos es una de las innovaciones más importantes de la Web y cambia radicalmente la tecnología para gestionarla. recursos de información. Si bien el soporte de metadatos era inherentemente necesario en las tecnologías de bases de datos, Web primero No se admitieron metadatos de generación.
Los estándares de metadatos web incluyen un subconjunto del lenguaje XML utilizado para describir estructura lógica Documentos XML de algún tipo. Esta descripción se llama DTD (Definición de tipo de documento). Además, la plataforma XML incluye el estándar XML Schema, que ofrece más capacidades desarrolladas para describir documentos XML. El estándar RDF (Marco de definición de recursos) define un lenguaje de representación de conocimiento simple para describir el contenido de documentos XML. Finalmente, el estándar OWL (Ontology Web Language) en desarrollo define un lenguaje formal de descripción de ontologías destinado a la Web semántica.
El consorcio OMG desarrolló el estándar de lenguaje UML (Unified Modeling Language), que proporciona una representación de metadatos de herramientas CASE para el análisis y diseño de objetos visuales. Este idioma es compatible con muchos productos de software CASO. El consorcio OMG también creó el estándar XMI (XML Metadata Interchange) para intercambiar metadatos entre herramientas CASE utilizando el lenguaje UML.
También vale la pena mencionar aquí el estándar Dublin Core (DC), un conjunto de elementos de metadatos para describir el contenido de documentos de diversa naturaleza. Esta norma rápidamente ganó popularidad y encontró, en particular, amplia aplicación V entorno web(ver sección 3.3).
Continúa el trabajo para desarrollar estándares existentes y crear nuevos estándares para la presentación de metadatos para AIS. Más detalles Las normas en cuestión se pueden encontrar en la enciclopedia.
Actualmente, todos los sistemas de información desarrollados con fines comerciales tienen una arquitectura distribuida, lo que implica el uso de redes globales y/o locales.
Históricamente, la arquitectura del servidor de archivos fue la primera en generalizarse, ya que su lógica es simple y es más fácil transferir los sistemas de información existentes a dicha arquitectura. Luego se transformó en una arquitectura servidor-cliente, que puede interpretarse como su continuación lógica. Sistemas modernos utilizados en red mundial INTERNET se refiere principalmente a la arquitectura de objetos distribuidos (ver Fig. III‑15 )
El SI se puede representar como compuesto por lo siguiente componentes(Figura III-16)
III.03.2. a Aplicaciones de servidor de archivos.
Esta es históricamente la primera arquitectura distribuida (Figura III-17). Está organizado de forma muy sencilla: sólo los datos están en el servidor y todo lo demás pertenece a la máquina cliente. Dado que las redes locales son bastante económicas y que con dicha arquitectura el software de aplicación es autónomo, hoy en día se utiliza a menudo dicha arquitectura. Podemos decir que esta es una opción. arquitectura cliente-servidor, en el que sólo los archivos de datos se encuentran en el servidor. Diferentes computadoras personales interactúan sólo por medio almacenamiento compartido datos, por lo que los programas escritos para una computadora son más fáciles de adaptar a dicha arquitectura.
Ventajas:
Ventajas de la arquitectura del servidor de archivos:
Facilidad de organización;
no contradice requisitos necesarios a la base de datos para mantener la integridad y confiabilidad.
Congestión de la red;
Imprevisibilidad de respuesta a una solicitud.
Estas deficiencias se explican por el hecho de que cualquier solicitud a la base de datos da como resultado la transferencia de cantidades significativas de información a través de la red. Por ejemplo, para seleccionar una o más filas de las tablas, se descarga la tabla completa a máquina cliente y ya allí el DBMS hace una selección. El tráfico de red significativo resulta especialmente complicado a la hora de organizar acceso remoto a la base de datos.
III.03.2. b Aplicaciones cliente-servidor.
En este caso, existe una distribución de responsabilidades entre el servidor y el cliente. Dependiendo de cómo se divida grueso Y cliente ligero.
En el modelo " cliente ligero“Todo el trabajo de la aplicación y la gestión de datos se realiza en el servidor. La interfaz de usuario en estos sistemas se "reubica" a ordenador personal, y él mismo aplicación de software realiza funciones de servidor, es decir ejecuta todos los procesos de la aplicación y gestiona los datos. El modelo de cliente ligero también se puede implementar donde los clientes son computadoras o estaciones de trabajo. Los dispositivos de red ejecutan un navegador de Internet y una interfaz de usuario implementada dentro del sistema.
Principal defecto modelos de clientes ligeros - muy ocupado servidores y redes. Todos los cálculos se realizan en el servidor y esto puede generar importantes tráfico de red entre cliente y servidor. Las computadoras modernas tienen suficiente potencia de cálculo, pero prácticamente no se utiliza en el modelo bancario/cliente ligero.
Por el contrario, el modelo de cliente pesado utiliza poder de computación Máquinas locales: la aplicación en sí se coloca en la computadora cliente. Un ejemplo de este tipo de arquitectura son los sistemas de cajeros automáticos, en los que el cajero automático es el cliente y el servidor. -computadora central mantenimiento de la base de datos de cuentas por cobrar
III.03.2. c Doble y arquitectura de tres niveles cliente-servidor.
Todas las arquitecturas discutidas anteriormente son de dos niveles. Diferencian entre el nivel de cliente y el nivel de servidor. En sentido estricto, el EI consta de tres niveles lógicos:
· Nivel de usuario;
· Nivel de aplicación:
· Capa de datos.
Por lo tanto, en un modelo de dos niveles, donde sólo intervienen dos capas, surgen problemas de escalabilidad y rendimiento si se elige el modelo de cliente ligero, o problemas asociados con la gestión del sistema si se elige el modelo de cliente pesado. Estos problemas se pueden evitar si se utiliza un modelo que consta de tres niveles, donde dos de ellos son servidores (Fig. III-21).
| Servidor de datos |
De hecho, el servidor de aplicaciones y el servidor de datos pueden estar ubicados en la misma máquina, pero no pueden realizar las funciones del otro. Lo bueno del modelo de tres niveles es que separa lógicamente la ejecución de aplicaciones y la gestión de datos.
Tabla III‑5 Aplicación de diferentes tipos de arquitecturas
| Arquitectura | Solicitud |
| Cliente ligero de dos niveles | 1 Sistemas heredados en los que no es práctico separar la ejecución de aplicaciones y la gestión de datos. 2 Aplicaciones con uso intensivo de computación pero uso intensivo de datos. 3 aplicaciones con |
| grandes volúmenes | datos, pero con un pequeño número de cálculos. |
| Cliente pesado de dos niveles | 1 Grandes aplicaciones con células y miles de clientes 2 Aplicaciones en las que tanto los datos como los métodos para procesarlos cambian a menudo. |
3 Aplicaciones que integran datos de muchas fuentes.
Este modelo es adecuado para muchos tipos de aplicaciones, pero limita a los desarrolladores de SI, quienes deben decidir dónde brindar servicios, brindar soporte para la escalabilidad y desarrollar herramientas para conectar nuevos clientes.
III.03.2. d Arquitectura de objetos distribuidos. Un enfoque más general lo proporciona una arquitectura de objetos distribuidos, cuyos componentes principales son objetos. Proporcionan un conjunto de servicios a través de sus interfaces. Otros objetos envían solicitudes sin distinguir entre cliente y servidor. Los objetos pueden ubicarse en diferentes computadoras de la red e interactuar mediante middleware, similar a autobús del sistema
| … |
| , que le permite conectar varios dispositivos y admitir la comunicación entre dispositivos de hardware. |
| Administrador de controladores ODBC |
| Conductor 1 |
| Conductor k |
| DB 1 |
| DBK |
| … |
Trabajando con SQL
La arquitectura ODBC incluye los siguientes componentes:
1. Aplicación (por ejemplo, IP). Realiza las siguientes tareas: solicita una conexión a una fuente de datos, envía consultas SQL a la fuente de datos, describe el área de almacenamiento y el formato de las consultas SQL, procesa errores y notifica al usuario sobre ellos, confirma o revierte transacciones, solicita una conexión a la fuente de datos.
2. Administrador de dispositivos. Carga controladores según la demanda de la aplicación, ofrece una interfaz única para todas las aplicaciones y la interfaz del administrador ODBC es la misma e independiente del DBMS con el que interactuará la aplicación. El Administrador de controladores proporcionado por Microsoft es una DLL cargada dinámicamente. 3. El controlador depende del DBMS. Controlador ODBC - Este biblioteca dinámica
Una DLL que implementa la funcionalidad ODBC e interactúa con la fuente de datos. Un controlador es un programa que procesa una solicitud para alguna función específicamente para el DBMS (puede modificar las solicitudes de acuerdo con el DBMS) y devuelve el resultado a la aplicación. Cada DBMS que admita la tecnología ODBC debe proporcionar a los desarrolladores de aplicaciones un controlador para ese DBMS. 4. La fuente de datos contiene información de control
Este modelo involucra muchos aspectos, para los cuales se utilizan al menos 5 diagramas en UML, ver párrafos. 2.04.2- 2.04.5.
Veamos el aspecto de gestión. El modelo de gestión complementa los modelos estructurales.
No importa cómo se describa la estructura de un sistema, éste consta de un conjunto de unidades estructurales (funciones u objetos). Para que funcionen como un todo, deben estar controlados y la información de control no está disponible en diagramas estáticos. Los modelos de control diseñan el flujo de control entre sistemas.
Hay dos tipos principales de control en los sistemas de software.
1. Gestión centralizada.
2. Gestión basada en eventos.
La gestión centralizada puede ser:
· Jerárquico- según el principio de "devolución de llamada" (así es como funciona con mayor frecuencia) programas de entrenamiento)
· Modelo despachador, que se utiliza para sistemas paralelos.
EN modelos de despachador Se supone que uno de los componentes del sistema es un despachador. Gestiona tanto el inicio como el apagado de sistemas y la coordinación de otros procesos del sistema. Los procesos pueden ejecutarse en paralelo entre sí. Un proceso es un programa, subsistema o procedimiento que opera sobre en este momento. Este modelo también se puede aplicar a sistemas secuenciales, donde programa de control llama a subsistemas individuales dependiendo de algunos variables de estado(a través del operador caso).
Gestión de eventos asume la ausencia de cualquier subrutina responsable de la gestión. El control se realiza mediante eventos externos: presionar una tecla del mouse, presionar un teclado, cambiar las lecturas del sensor, cambiar las lecturas del temporizador, etc. Cada evento externo se codifica y se coloca en la cola de eventos. Si se proporciona una reacción a un evento en la cola, entonces se llama al procedimiento (subrutina) que reacciona a este evento. Los eventos a los que reacciona el sistema pueden ocurrir en otros subsistemas o en el entorno externo del sistema.
Un ejemplo de dicha gestión es la organización de aplicaciones en Windows.
Todos los modelos estructurales descritos anteriormente se pueden implementar mediante control centralizado o control basado en eventos.
Interfaz de usuario
Al desarrollar un modelo de interfaz, se deben tener en cuenta no solo las tareas del software que se está diseñando, sino también las características del cerebro asociadas con la percepción de la información.
III.03.4. a Características psicofísicas de una persona asociadas a la percepción y procesamiento de la información.
La parte del cerebro que convencionalmente se puede llamar procesador de percepción procesa constantemente, sin la participación de la conciencia, la información entrante, la compara con experiencias pasadas y la almacena.
Cuando imagen visual atrae nuestra atención, entonces la información que nos interesa entra en la memoria a corto plazo. Si nuestra atención no fue atraída, entonces la información en el almacenamiento desaparece y es reemplazada por las siguientes partes.
En cada momento, el foco de atención se puede fijar en un punto, por lo que si es necesario monitorear simultáneamente varias situaciones, el foco se mueve de un objeto rastreado a otro. Al mismo tiempo, la atención se dispersa y es posible que se pasen por alto algunos detalles. También es importante que la percepción se base en gran medida en la motivación.
Al cambiar de fotograma, el cerebro se bloquea durante algún tiempo: domina nueva foto, destacando los detalles más significativos. Esto significa que si es necesario respuesta rápida usuario, entonces no deberías cambiar repentinamente las imágenes.
La memoria a corto plazo es el cuello de botella en el sistema de procesamiento de información humano. Su capacidad es de 7±2 objetos desconectados. La información no reclamada se almacena allí durante no más de 30 segundos. Para no olvidar alguna información que es importante para nosotros, solemos repetirla, actualizando la información en la memoria a corto plazo. Así, a la hora de diseñar interfaces hay que tener en cuenta que a la gran mayoría le resulta difícil, por ejemplo, recordar e introducir números que contengan más de cinco dígitos en otra pantalla.
A pesar de que la capacidad y el tiempo de almacenamiento de la memoria a largo plazo son ilimitados, el acceso a la información es muy difícil. El mecanismo para recuperar información de la memoria a largo plazo es de naturaleza asociativa. Para mejorar la memorización de información, se vincula a los datos que la memoria ya almacena y facilita su recuperación. Debido a que es difícil acceder a la memoria a largo plazo, es apropiado confiar no en que el usuario recuerde la información, sino en que la reconozca.
III.03.4. b Criterios básicos para evaluar interfaces
Numerosas encuestas y estudios realizados por empresas líderes en desarrollo de software han demostrado lo que los usuarios valoran en una interfaz:
1) facilidad de aprendizaje y memorización: evalúe específicamente el tiempo de aprendizaje y la duración del almacenamiento de información y memoria;
2) la velocidad para lograr resultados al utilizar el sistema, que está determinada por la cantidad de comandos y configuraciones ingresados o seleccionados con el mouse;
3) satisfacción subjetiva con el funcionamiento del sistema (facilidad de funcionamiento, fatiga, etc.).
Además, para los usuarios profesionales que trabajan constantemente con el mismo paquete, el segundo y tercer criterio rápidamente ganan, y para los usuarios no profesionales que trabajan periódicamente con el software y realizan tareas relativamente simples: el primero y el tercero.
Desde este punto de vista, hoy en día las mejores características para los usuarios profesionales son las interfaces con navegación libre, y para los usuarios no profesionales, las interfaces de manipulación directa. Durante mucho tiempo se ha observado que al realizar la operación de copiar archivos, en igualdad de condiciones, la mayoría de los profesionales usan shells como Far, y los no profesionales usan "arrastrar y soltar objetos" de Windows.
III.03.4. c Tipos de interfaces de usuario
Distinguir siguientes tipos interfaces de usuario:
Primitivo
Con navegación gratuita
Manipulación directa.
La interfaz es primitiva.
Primitivo Se denomina interfaz que organiza la interacción del usuario y se utiliza en modo consola. La única desviación del proceso secuencial que proporcionan los datos es la organización de un bucle para procesar múltiples conjuntos de datos.
Interfaz de menú.
A diferencia de la interfaz primitiva, permite al usuario seleccionar una operación de una lista especial que le muestra el programa. Estas interfaces implican la implementación de muchos escenarios de trabajo, cuya secuencia de acciones está determinada por los usuarios. La organización en forma de árbol del menú sugiere que buscar un elemento en menús de más de dos niveles resulta una tarea bastante difícil.
A menudo, a la hora de definir un sistema distribuido, la división de sus funciones entre varios ordenadores es de suma importancia. Con este enfoque, cualquier sistema computacional, donde el procesamiento de datos se divide entre dos o más computadoras. Según la definición de E. Tanenbaum, un sistema algo más estrechamente distribuido se puede definir como un conjunto de computadoras independientes conectadas por canales de comunicación, que desde el punto de vista del usuario de algún software parecen un todo único.
Este enfoque para definir un sistema distribuido tiene sus inconvenientes. Por ejemplo, todo lo que se utiliza en un sistema tan distribuido. software podría funcionar en una sola computadora, sin embargo, desde el punto de vista de la definición anterior, dicho sistema ya no se distribuirá. Por lo tanto, el concepto de sistema distribuido probablemente debería basarse en un análisis del software que forma dicho sistema.
Como base para describir la interacción de dos entidades, consideremos el modelo de interacción general. cliente-servidor, en el que una de las partes (cliente) inicia el intercambio de datos enviando una solicitud a la otra parte (servidor). El servidor procesa la solicitud y, si es necesario, envía una respuesta al cliente (Fig. 1.1).
Arroz. 1.1.
La interacción dentro del modelo cliente-servidor puede ser sincrónica, cuando el cliente espera a que el servidor complete el procesamiento de su solicitud, o asincrónica, en la que el cliente envía una solicitud al servidor y continúa su ejecución sin esperar una respuesta del servidor. El modelo de cliente y servidor se puede utilizar como base para describir diversas interacciones. Para este curso, la interacción de los componentes del software que forma un sistema distribuido es importante.
Arroz. 1.2.
Consideremos algunos aplicación típica, que, de acuerdo con los conceptos modernos, se puede dividir en los siguientes niveles lógicos (Fig. 1.2): interfaz de usuario(IP), lógica de aplicación (AL) y acceso a datos (DA), trabajando con una base de datos (DB). El usuario del sistema interactúa con él a través de la interfaz de usuario; la base de datos almacena datos que describen;área temática aplicación, y la capa lógica de la aplicación implementa todos los algoritmos relacionados con.
área temática Porque en la practica diferentes usuarios Los sistemas suelen estar interesados en acceder a los mismos datos, la forma más sencilla de distribuir las funciones de dicho sistema entre varias computadoras sería dividir los niveles lógicos de la aplicación entre una parte del servidor Aplicaciones encargadas de acceder a los datos y ubicadas en varios ordenadores., implementando la interfaz de usuario. La lógica de la aplicación se puede asignar al servidor, a los clientes o dividirse entre ellos (Figura 1.3).
Arroz. 1.3.
La arquitectura de aplicaciones creadas según este principio se denomina cliente-servidor o de dos niveles. En la práctica, estos sistemas a menudo no se clasifican como distribuidos, pero formalmente pueden considerarse los representantes más simples de los sistemas distribuidos.
Un desarrollo de la arquitectura cliente-servidor es una arquitectura de tres niveles, en la que la interfaz de usuario, la lógica de la aplicación y el acceso a los datos se separan en componentes independientes del sistema que pueden operar. computadoras independientes(Figura 1.4).
Arroz. 1.4.
La solicitud del usuario en dichos sistemas se procesa secuencialmente. lado del cliente sistema, servidor de lógica de aplicación y servidor de base de datos. Sin embargo, normalmente se entiende por sistema distribuido un sistema con una arquitectura más compleja que uno de tres niveles.
EN grandes explotaciones Decenas de miles de usuarios trabajan en filiales. Cada organización tiene sus propios procesos de negocio internos: aprobación de documentos, emisión de instrucciones, etc. Al mismo tiempo, algunos procesos traspasan las fronteras de una empresa y afectan a los empleados de otra. Por ejemplo, el jefe de la oficina central emite una orden a una filial, o un empleado de una filial envía un acuerdo para su aprobación con los abogados de la empresa matriz. Esto requiere crear una arquitectura compleja utilizando múltiples sistemas.
Es más, dentro de una empresa Se utilizan muchos sistemas para resolver. diferentes tareas: Sistema ERP para operaciones contables, instalaciones separadas de sistemas ECM para documentación organizativa y administrativa, para documentación de diseño y presupuesto, etc.
El sistema DIRECTUM ayudará a garantizar la interacción de diferentes sistemas tanto dentro del holding como a nivel de una organización.
DIRECTUM proporciona herramientas convenientes construir arquitectura distribuida gestionada organizar y resolver las siguientes tareas:
- organización de procesos comerciales de extremo a extremo y sincronización de datos entre varios sistemas de una empresa y del holding;
- proporcionando acceso a datos de diferentes instalaciones de sistemas ECM. Por ejemplo, busque un documento utilizando varios sistemas especializados: con documentación financiera, con documentación de diseño y presupuesto, etc.
- administrar múltiples sistemas y servicios desde un único punto de control y crear una infraestructura de TI cómoda;
- distribución conveniente del desarrollo a sistemas productivos distribuidos.
Componentes de una arquitectura distribuida gestionada
Mecanismos de interconexión (DCI)
Los mecanismos DCI se utilizan para organizar procesos comerciales de un extremo a otro y sincronizar datos entre diferentes sistemas dentro de una o más organizaciones (holding).
La solución conecta los procesos comerciales locales existentes en las empresas en un único proceso de extremo a extremo. Los empleados y sus jefes trabajan con la interfaz ya familiar de tareas, documentos y libros de referencia. Al mismo tiempo, las acciones de los empleados son transparentes en cada etapa: pueden ver el texto de la correspondencia con una empresa relacionada, ver el estado de aprobación del documento con la organización matriz, etc.
Puedes conectar diferentes instalaciones de DIRECTUM y otras clases de sistemas (ERP, CRM, etc.) a DCI. Como regla general, las instalaciones se dividen por área de negocio, teniendo en cuenta la ubicación territorial o legal de las organizaciones y otros factores.
DCI incluye componentes de desarrollo con descripción detallada y ejemplos de código, gracias a los cuales un desarrollador puede crear un algoritmo para los procesos de negocio de su organización.
Los mecanismos DCI permiten transferir grandes cantidades de datos y pueden soportar cargas pico. Además, proporcionan tolerancia a fallos en caso de fallos de comunicación y protección de los datos transmitidos.
Búsqueda federada
Usando la búsqueda federada puedes encontrar tareas necesarias o documentos en todos a la vez sistemas separados DIRECTO. Por ejemplo, ejecute una búsqueda simultáneamente por sistema de trabajo y según el sistema con documentos de archivo.
La búsqueda federada le permite:
- ver el progreso de la aprobación del documento saliente en la organización subsidiaria a través del cliente web;
- buscar acuerdos celebrados con la contraparte en todas las filiales, por ejemplo, para preparar negociaciones. En este caso, puedes ir a las tareas que contienen contratos;
- verificar el estado de ejecución de una orden enviada desde la organización matriz a la subsidiaria, o los documentos y tareas creados de acuerdo con ella;
- buscar documentos simultáneamente en varios sistemas con diferentes especializaciones, por ejemplo, con documentos y contratos organizativos y administrativos;
- encontrar documentos contables primarios para auditoría o conciliación con una contraparte inmediatamente en el sistema de trabajo y en el sistema con un archivo de documentos;
- intercambiar enlaces para buscar resultados con colegas.
El administrador puede cambiar búsquedas estándar, agregar nuevos y también configurar qué sistemas serán visibles para el usuario.
Centro de Administración de Servicios DIRECTUM
El sistema DIRECTUM resuelve muchos problemas diferentes: interacción de los empleados, almacenamiento de documentos, etc. Esto es posible gracias al funcionamiento confiable de sus servicios. Y las grandes empresas dotan instalaciones completas del sistema DIRECTUM con su propio conjunto de servicios para tarea específica, por ejemplo, para almacenar documentos de archivo. Las instalaciones y servicios se implementan en varios servidores. Esta infraestructura necesita ser administrada.
El Centro de administración de servicios DIRECTUM es el único punto de entrada del administrador para configurar, monitorear y administrar los servicios y sistemas DIRECTUM. El centro es un sitio con herramientas para la gestión del servidor de sesiones, servicio de flujo de trabajo, servicio de procesamiento de eventos, servicio de almacenamiento de archivos, servicios de entrada y transformación. búsqueda federada y ayuda web.
Conveniente personalización visual sistemas remotos y servicios simplifica el trabajo del administrador. No necesita ir a cada servidor y realizar cambios manualmente en los archivos de configuración.
Los servicios se detienen y se inician con un solo clic. El estado de los servicios se muestra instantáneamente en la pantalla.
La lista de configuraciones se puede ampliar y filtrar. De forma predeterminada, el sitio muestra solo configuraciones básicas. Al mismo tiempo, para todas las configuraciones puede ver consejos con recomendaciones de llenado.
El sistema DIRECTUM organiza eficazmente el trabajo de organizaciones distribuidas y proporciona a los usuarios un intercambio transparente de documentos, tareas y registros de directorio.
Cada componente de una arquitectura distribuida administrada se puede utilizar por separado, pero juntos aportarán un mayor valor empresarial a su organización.
