Arquitectura De Dominio Especifico

  • Uploaded by: Reymundo Roman Zarate
  • 0
  • 0
  • January 2021
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Arquitectura De Dominio Especifico as PDF for free.

More details

  • Words: 1,674
  • Pages: 6
Loading documents preview...
Arquitectura de dominio especifico El reto para el diseño es diseñar el software y hardware para proporcionar características deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos sistemas. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. Aquí se tratan dos tipos genéricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-servidor. En este caso el sistema puede ser visto como un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas.

Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. No hay distinción entre un proveedor de servicios y el usuario de estos servicios.

Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización. La distribución soportada es, por lo tanto, intraorganizacional. También se pueden tomar dos tipos más de arquitecturas distribuidas que son más adecuadas para la distribución interorganizacional: arquitectura de sistemas peer-topeer (p2p) y arquitecturas orientadas a servicios. Los sistemas peer-to-peer han sido usados principalmente para sistemas personales, pero están comenzando a usarse para aplicaciones de empresa.

Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representación de la información y los protocolos de comunicación pueden ser todos diferentes.

Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El término middleware se usa para hacer referencia a ese software; se ubica en medio de los diferentes componentes distribuidos del sistema.

Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar computación distribuida. El middleware es un software de propósito general que normalmente se compra como un componente comercial más que escribirse especialmente por los desarrolladores

de la aplicación. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicación.

Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. Estos sistemas están formados por partes independientes pobremente integradas, cada una de las cuales puede interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos software reflejan estas características; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos.

Existen dos modelos de dominio específico:

1. Modelos genéricos que son abstracciones de varios sistemas reales.

2. Modelos de referencia que son modelos abstractos y describen a una clase mayor de sistemas.

Modelo genérico: flujo de datos de un compilador

Modelo de Referencia: La arquitectura OSI.

6.2.1 Diseño Software Arquitectura Multiprocesador

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razón es porque actualmente la mayoría de las CPU’s sólo pueden ejecutar un proceso cada vez. La única forma de que se ejecuten de forma simultánea varios procesos es tener varias CPU’s (ya sea en una máquina o en varias, en un sistema distribuido.

La ventaja de un sistema multiproceso reside en la operación llamada cambio de contexto. Esta operación consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.

El multiproceso no es algo difícil de entender: más procesadores significa más potencia computacional. Un conjunto de tareas puede ser completado más rápidamente si hay varias unidades de proceso ejecutándolas en paralelo. Esa es la teoría, pero otra historia es la práctica, como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del hardware como del software.

Es necesario conocer ampliamente como están interconectados dichos procesadores, y la forma en que el código que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al máximo sus prestaciones.

6.2.2 Diseño Software Arquitectura Cliente-Servidor

La arquitectura cliente-servidor es una forma de dividir las responsabilidades de un Sistema de Información separando la interfaz de usuario (Nivel de presentación) de la gestión de la información (Nivel de gestión de datos).

Esta arquitectura consiste básicamente en que un programa, el Cliente informático realiza peticiones a otro programa, el servidor, que les da respuesta.

Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema multiusuario distribuido a través de una red de computadoras.

La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.

Ventajas de la arquitectura cliente-servidor

› Centralización del control: los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema.

› Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado.

Se reduce el tráfico de red considerablemente. Idealmente, el cliente se comunica con el servidor utilizando un protocolo de alto nivel de abstracción como por ejemplo SQL. Diseño Software Distribuido

Estos recursos técnicos suelen catalogarse en:

- Infraestructura. -Plataforma. -Comunicaciones. -Datos. - Software: - Aplicaciones. -Interfícies. -Servicios. - Seguridad.

Pero no olvidemos que detrás del sistema operativo hay personas que lo usan y los gestionan. El factor humano será fundamental como nos cuidaremos de recordar a lo largo del todo el diseño.

Diseñar un sistema distribuido es crear aplicaciones de software que, utilizando servicios y ayudándose de la conectividad, participen y se integren en este entorno de forma transparente a

las plataformas de proceso y de almacenamiento de datos, dotándolas de los recursos necesarios para gestionarse de forma integrada con el resto del sistema distribuido. Los servicios permitirán usar todos los recursos técnicos y el sistema distribuido resulto ante no será nada más, ni nada menos, que un conjunto de servicios que interoperan entre ellos colaborando para cumplir los objetivos que se han establecido para el sistema.

Los sistemas distribuidos que se diseñen y construyan deben estar alineados con los objetivos de negocio de la empresa, aumentar la eficacia y eficiencia operacional de la compañía y permitir el mayor rendimiento con el menor coste en las estructuras informáticas que dan soporte.

No olvide nunca estos tres puntos. El objetivo es siempre alinear tecnología y negocio. El sistema resultante debe ser adaptable, ofrecer el rendimiento necesario con el coste más barato que seamos capaces de conseguir.Con este objetivo final, empezamos nuestro viaje para el cual le voy a pedir un esfuerzo. Las tecnologías llegan, se consolidan o desaparecen, y al final mueren. Y siempre con facilidad y rapidez.

Pero las estrategias, las tácticas y las técnicas de diseño tienen un ciclo de vida mucho más lento y robusto. Y están por encima de las tecnologías en que se implementan. Intente poner en su mochila solo las primeras. Este es un viaje por el mundo del diseño de sistemas distribuidos, no sus técnicas de implementación aunque haremos las necesarias salidas a ese mundo cunado sea necesario.

Arquitecturas en un sistema distribuido. La arquitectura de Empresa. La palabra arquitectura es de aquellos términos utilizados ampliamente dentro del mundo informático. Cuando atacamos sistemas distribuidos, la palabra aparece continuamente.

Esta constatación de la realidad no resulta extraña si acudimos a la definición que ANSI/IEEE hace del término: “Arquitectura es la organización fundamental de un sistema, donde se integran sus componentes, se establecen las relaciones e interdependencias entre esos componentes y su entorno y se establecen los principios para su diseño, gestión y evolución”.

Así, en el mundo de los sistemas distribuidos donde conviven tantos factores y tan diferentes, es lógico que el término se utilice profusamente en varios lugares. Veamos la primera aparición. El

objetivo fundamental de cualquier sistema distribuido será aportar valor añadido. Y para empezar eficientemente el camino conviene organizar de alguna forma todos los factores que intervienen. La forma de hacerlo es proponer una Arquitectura deEmpresa, conocida también por EA desde su nombre en inglés, Enterprise Architecture.

La arquitectura de la empresa permite a la compañía conocer como es su estructura y la forma en que trabaja. Es el plano de ruta para el desarrollo de los negocios y de la tecnología que va ha apoyarlos, tanto en lo nuevo como en la evolución.

Es en este último aspecto por el que nos conviene acercarnos a ella. Sus contenidos son prerrequisitos que los sistemas distribuidos deberán cumplir. Es de aquí donde se origina el Plan Estratégico Distribuido de la Compañía, donde se registrarán todos los prerrequisitos de desarrollo y gestión que los sistemas distribuidos de la compañía deberán seguir y cumplir. Veremos que este documento se utilizará en la segunda parte dedicada al diseño, como base de muchas decisiones a tomar durante el desarrollo del sistema distribuido.

Diseño Software Tiempo Real

El software de tiempo real esta muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder al ámbito del problema en un tiempo dictado por el ámbito del problema. Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseño del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las características del sistema operativo, por los requisitos de la aplicación y tanto por los extras del lenguaje de programación como prospectos de diseño.

La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, así como contar el tiempo, optimizar el gasto de gasolina de nuestras últimas generaciones de coches y programar a nuestros aparatos.

Todas estas interacciones con las computadoras sean útiles o intrusivas son ejemplos de computación de tiempo real. La computadora esta controlando algo que interactua con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interacción

Related Documents


More Documents from "Vidal Champi Mamani"