Introducción

Actualmente los Sistemas Distribuidos permiten que la información procesada por parte del sistema llegue a varias computadoras sin importar dónde estas se encuentren y así no tener toda la información en una única máquina.

A lo largo de esta unidad se irán conociendo una serie de arquitecturas que le permiten al diseñador de software escoger una dependiendo de las características propias de su sistema. Por otro lado, hay que tener en cuenta que la arquitectura es el marco conceptual, donde se describe de forma clara sus componentes y cómo se comunican entre sí.

Se hará una introducción al desarrollo con el diseño orientado a objetos; es de recordar que se pasó de una programación estructurada a una que implica la consecución de los objetos como la representación del mundo real; la cual le permite al desarrollador pensar en clases, atributos, métodos, relaciones entre clases, tiempos de respuesta y por último cómo desarrollar interfaces que le permitan al usuario final tener una interfaz amigable y consistente.

Propósitos de aprendizaje

Propósito general

Explicar los diferentes tipos de arquitecturas e introducir al Diseño Orientado a Objetos.

Propósitos específicos

  • Identificar las ventajas y desventajas de los sistemas distribuidos.
  • Reconocer los tipos de arquitecturas que puede utilizar un diseñador de software.
  • Utilizar los diagramas de UML para el modelamiento de software.
  • Comprender en qué consisten los sistemas en tiempo real.
  • Desarrollar prototipos para el diseño de interfaces.

Arquitecturas multiprocesador

Se denomina arquitectura a la descripción de alto nivel que se le hace a un sistema, en donde se define: el objetivo del diseño, la descomposición en subsistemas, plataforma de hardware y software que son necesarias, control de acceso, políticas de control y todas las estrategias que se consideraron por el equipo de desarrollo para llevar a cabo el sistema.

Un sistema distribuido es aquel que permite que el procesamiento de su información esté ubicado en diferentes computadoras de tal forma que parezca que está solo en una. Esto le facilita al desarrollador pensar en los recursos de hardware y software que necesitará; al estar en un sistema distribuido estos se podrán compartir.

La arquitectura multiprocesador es el modelo más sencillo de los sistemas distribuidos, es un sistema que ejecuta muchos procesos en procesadores diferentes, tal como se explica en la anterior interactividad.

Las arquitecturas multiprocesador se definen en dos tipos. Esta clasificación se basa en que si cuenta con características específicas o por el contrario no tiene unas características bien definidas que el usuario pueda diferenciar. Cualquiera de las dos que se use, garantizará el proceso y control tanto del sistema operativo como del proceso maestro que es el encargado de dirigir el proceso (Sistemas operativos, 2015): Multiprocesamiento simétrico SMP y Multiprocesamiento asimétrico. Además de la clasificación anterior, se encuentra otra clasificación por tipo de memoria: Compartida y Distribuida (Universities, 1999).

Le invitamos a revisar los dos tipos de clasificación en la siguiente interactividad.

Actividad de aprendizaje

Actividad de Aprendizaje

Con base en lo aprendido, diseña la arquitectura de proceso para un sistema de monitorización ambiental.

Arquitecturas Cliente Servidor

Como se veía en la unidad anterior, este tipo de arquitectura está compuesta por un servidor (que ofrece unos servicios) y unos clientes que acceden a los mismos. El servidor no conoce nada acerca de los clientes que están utilizando sus servicios; solo los clientes necesitan saber qué servidores están disponibles (Bruegge, 2004).

Los tipos de Arquitecturas Cliente Servidor se definen con base al número de capas; existen de 2, 3, 4 y N capas, tal como se explicaron en la interactividad.

Un ejemplo común de este tipo de sistema es el Internet, donde un cliente accede de forma fácil a millones de datos de múltiples servidores que se encuentran en la red.

Actividad de aprendizaje

Actividad de Aprendizaje

Organiza un modelo de cuatro capas para un sistema de información de una biblioteca. Evalúa lo aprendido

Arquitecturas de Sistemas Distribuidos

El objetivo de este tipo de arquitecturas es no etiquetar un cliente o un servidor, sino que el sistema se vea como un conjunto de objetos. Estos tienen como características que una parte de los objetos proporcionan una interfaz a un conjunto de servicios. Existen otros objetos que hacen llamada a los servicios disponibles. Se encuentran distribuidos a través de las computadoras de la red y su comunicación se hace mediante middleware, que no es otro que un intermediario de peticiones. (Pressman, 2009).

Para el desarrollo de aplicaciones que manejen minería de datos, tal como lo presenta el gráfico principal de esta pantalla, se sugiere utilizar la arquitectura de objetos distribuidos.

Como se mencionaba anteriormente, para la comunicación de los objetos es necesario contar con un intermediario; para esto existe CORBA, que será abordado en el siguiente subtema.

Arquitecturas de Sistemas Distribuidos

CORBA

Common Object Request Broker Architecture(CORBA), estándar publicado por el Object Management Group (OMG). Es un middleware que realiza tareas de intermediario en las peticiones que realizan los objetos. Su importancia radica en que los objetos pueden estar, por un lado, implementados en diferentes lenguajes de programación, se ejecutan sobre diferentes plataformas y sus nombres no son conocidos por los otros objetos. Un objeto es la encapsulación de atributos y servicios (Sommerville, 2010).

CORBA se encarga de soportar a nivel de comunicación lógica, proporcionando funcionalidades a los objetos como el intercambio y control de la información. A nivel de componentes, proporciona la base necesaria para el desarrollo de componentes compatibles.

Las interfaces de los objetos se encuentran definidas en el lenguaje (IDL- Interface Definition Language), el cual es independiente del lenguaje de programación que se esté utilizando.

Arquitecturas de Sistemas Distribuidos

Arquitecturas Peer to Peer

También conocidos como P2P, donde cualquier nodo tiene la capacidad de tomar la vocería y el control para ser servidor. No existe una distinción entre quién es el cliente y quién el servidor. Esta arquitectura puede ser descentralizada y semicentralizada (Sommerville, 2010).

P2P se conoce como una tecnología que sirve de medio para lograr un fin; en otras ocasiones, se le conoce como intercambiador de archivos. Sus características más relevantes son: escalabilidad, robustez, descentralización, los costos son distribuidos entre todos los usuarios, se maneja el anonimato de sus usuarios y presenta algo de seguridad.

A continuación se presentan las ventajas y desventajas de P2P.

Arquitecturas de Sistemas Distribuidos

Arquitecturas de Sistemas orientadas a servicios

Conocida como SOA. Es un estilo de arquitectura de tecnologías de información que permite integrar el negocio como un conjunto de servicios interrelacionados (tareas repetitivas de trabajo) (Sommerville, 2010).

Surge del problema que presentaba antes por el acceso solamente a través de internet y acceso a los datos que tenían compartidos las organizaciones. No permitía más de una conexión a la vez. Para dar la solución nació lo que hoy se conoce como web services que permite publicar todos los servicios que considere necesarios la organización; de allí nace SOA.

A continuación se presenta un ejemplo de un sistema orientado a servicios.

SOA busca mejorar la satisfacción del cliente, generar ganancia en la puesta en marcha del negocio, y que en toda la empresa se dé el aumento de competitividad y el mejoramiento en costos de las tecnologías de información.

Actividad de aprendizaje

Actividad de Aprendizaje

Con base en lo aprendido selecciona uno de los tipos de sistemas distribuidos para la aplicación de ventas de boletas.

Arquitecturas de Aplicaciones

Le permiten al usuario adecuar las aplicaciones a sus necesidades y se puede presentar que algunas funciones son muy comunes en todas las aplicaciones como, por ejemplo, facturar, contabilizar documentos, conexión de llamadas, gestión de redes y emisión de facturas (Sommerville, 2010).

En los inicios del desarrollo de software no se contaba con patrones comunes de aplicaciones que le sirvieran al diseñador de guía; como consecuencia de esto se presentaban problemas de cubrimiento de requerimientos. Si se iba a realizar algún cambio en la estructuración del sistema era una tarea tediosa, no se sabían todos los eventos que cubriría el aplicativo.

En las siguientes pantallas revisaremos las cuatro arquitecturas de aplicaciones genéricas que los diseñadores de software pueden utilizar.

Arquitecturas de Aplicaciones

Sistemas de Procesamiento de datos

Este tipo de sistemas toman como base gran cantidad de datos, lo cual significa un trabajo muy complejo y dispendioso. Por esta razón se realiza procesamiento de lotes de datos, los cuales ingresan a un sistema (entrada), el sistema realiza un procesamiento (proceso) y genera unos datos transformados (salidas).

Un claro ejemplo de este tipo de sistemas es la generación de las facturas de celular mensual. La descripción del proceso es la siguiente:

  • La entrada es el gran listado de todas las llamadas realizadas en el mes por cada uno de los usuarios de la telefonía celular (lotes de datos)
  • El componente de proceso se encarga realizar los cálculos del valor a pagar por parte de cada uno de los usuarios; para esto es necesario consultar en la base de datos las tarifas de las llamadas y multiplicar por la duración de las llamadas.
  • El componente de salida genera las facturas para cada uno de los usuarios donde se indica el valor a pagar.

Actividad de aprendizaje

Actividad de Aprendizaje

Ordena los elementos de un sistema de procesamiento de datos de un supermercado.

Arquitecturas de Aplicaciones

Sistemas de procesamiento de transacciones

La diferencia entre arquitectura de datos y la de transacciones radica en que las transacciones fueron diseñadas para procesar la petición de solicitud de información en la base de datos y posteriormente se actualiza la información en la base de datos. Para esto es necesario que el proceso de cálculos o ajustes a los datos se realicen prontamente antes de ser actualizados en la base de datos definitiva (Sommerville, 2010).

Este tipo de aplicaciones hacen parte de los sistemas de negocios interactivos. Toda acción del usuario no se mezcla con la de otro; es decir en ningún momento se ve afectada la integridad de la base de datos. Algunas aplicaciones como estas son: Comercio Electrónico, Sistemas de información y todos los sistemas de reservas de algún tipo de servicio.

Otro ejemplo de transacciones, aparte del presentado en la medio principal de esta pantalla, son los sistemas de información de las bibliotecas, que le permiten al usuario acceder a la misma y descargar documentos que se encuentran en otras bibliotecas remotas. En la siguiente interactividad se ve este sistema organizado por capas.

Actividad de aprendizaje

Actividad de Aprendizaje

Agrupa correctamente cada uno de los conceptos de un sistema de procesamiento de transacciones.

Arquitecturas de Aplicaciones

Sistemas de procesamiento de eventos

La principal función de estos sistemas es responder a eventos que se generen en todo el sistema o por parte de la interfaz del usuario. Estos sistemas deben estar siempre a la escucha de los eventos y en el momento en que sea generado alguno debe ser resuelto en ese preciso momento que ocurran (Sommerville, 2010).

Ejemplos de estos sistemas son: los procesadores de texto, videojuegos, aplicativos para presentaciones, entre otros. La operación consiste en detectar e interpretar el evento y dar respuesta a la acción detectada.

El último sistema de aplicaciones corresponde al sistema de procesamiento de lenguajes; aquí se encuentran todos los compiladores.

Arquitecturas de Aplicaciones

Sistemas de procesamiento de lenguajes

Están conformados por procesadores de lenguaje natural o artificial, mediante los cuales se cuenta con una entrada y a partir de ella se genera una salida representada en el lenguaje escogido (Sommerville, 2010).

Un ejemplo de ellos son los compiladores cuya función radica en traducir a partir de un lenguaje artificial escrito en código máquina o en XML a comandos que sean entendibles escritos en un lenguaje natural.

Se compone de los siguientes objetos:

  • Traductor: realiza las operaciones de comprobación de sintaxis, comprobación de semántica y generación de las instrucciones, que son recibidas por la máquina abstracta.
  • Intérprete: obtiene las instrucciones, las ejecuta y genera como salida los resultados al usuario.

Actividad de aprendizaje

Actividad de Aprendizaje

Relaciona las dos columnas con base en la temática de arquitecturas de aplicaciones y evalúa lo aprendido.

Diseño Orientado a Objetos

Estos sistemas se componen de unos objetos, los cuales interactúan entre sí y desarrollan una serie de operaciones para alcanzar un fin (De Amescua, 2003). Cuando el desarrollador comienza con su proceso de implementación, define: el diseño de clases de objetos, las relaciones entre las clases, las características de cada una de las clases y sus funcionalidades. El sistema debe contar con la capacidad de modificar un objeto o agregar nuevas funcionalidades sin que esto afecte al resto de los objetos. A su vez se compone de estas actividades (Sommerville, 2010):

  • Análisis de objetos: se identifican las entidades (objetos) y operaciones que realizarán (métodos)
  • Diseño de objetos: se toman los objetos, se definen sus relaciones y se representan gráficamente por medio de un Diagrama de Clases.
  • Programación de objetos: selección de un lenguaje orientado a objetos (Java, Python) para realizar la codificación de los objetos.

A continuación, se visualiza un diagrama de clases de un juego el cual se compone de dos clases: ajedrez y parchís, quienes se conectan con la clase padre por medio de una relación de herencia (Sommerville, 2010).

Diseño Orientado a Objetos

Contexto del sistema y modelos de utilización

Con base en el caso de estudio expuesto en el medio principal de esta pantalla, se iniciará el proceso de Diseño orientado a objetos. Para representar el contexto del sistema, se debe organizar el sistema (definición de requerimientos funcionales) visualmente por medio de las capas, utilizando el Diagrama de Paquetes de UML (Sommerville, 2010).

Le invitamos a visualizar el diagrama de paquetes de productos, el modelo estático y el modelo dinámico del caso de estudio.

Una vez estudiado el sistema y los modelos de utilización se dará inicio al siguiente proceso del caso de estudio.

  1. Diseño de la arquitectura
  2. Identificación de objetos
  3. Modelos de diseño

Actividad de aprendizaje

Actividad de Aprendizaje

Lee atentamente cada uno de los puntos de la actividad de diseño orientado a objetos, resuélvelos y pon a prueba lo aprendido.

Diseño de software en tiempo real

Algunos autores definen a estos sistemas como: un sistema de software el cual funciona correctamente de acuerdo a los resultados que produzca y en el tiempo en el que dé respuesta. Son de tipo blando, cuando poco a poco se degrada debido a que los requerimientos no se cumplen con respecto a lo acordado y es de tipo duro si sus resultados no dan respuesta conforme a las especificaciones temporales (Sommerville, 2010).

Se compone de un estímulo: operación de entrada sobre un sistema, el cual debe producir una salida y una respuesta. Los estímulos se clasifican en dos:

  • Sincrónicos: cuenta con intervalos de tiempo predecibles. Se tiene estipulado que en un determinado tiempo se produce un estímulo para obtener una respuesta. Estos se componen de unos sensores quienes proporcionan la información al sistema. Las respuestas son administradas por los actuadores que controlan los equipos.
  • Asincrónicos: son irregulares, lo provocan mecanismos de interrupción de la computadora, así que no se cuenta con la certeza de en qué momento se producirán. Se generan ya sea actuadores o sensores.

Diseño de software en tiempo real

Sistemas operativos en tiempo real

Conocidos como RTOS, su función consiste en gestionar los procesos y asignar recursos del sistema. La gestión involucra lanzar y detener los estímulos para que de esta forma se les dé manejo, asignación de memoria y recursos del procesador (Sommerville, 2010).

Con el fin de garantizar un buen proceso, el gestor tiene establecidos dos niveles de prioridad que van acorde a los tiempos de respuesta. Estos son: interrupción y reloj. Otro caso es el proceso de autocomprobación que se realiza durante el momento en que el procesador esté ocioso. De igual forma, otro elemento importante son los planificadores, cuya función es establecer las políticas de orden para ejecutar los procesos, se clasifican en dos: sin reemplazo y con reemplazo.

Los sistemas de monitorización y control son los encargados de supervisar y dirigir los sensores. En el momento en que se identifica un valor en el sensor, pasan la información al actuador de hardware para que ejecute el proceso correspondiente, tal como se explicó en el gráfico anterior.

Actividad de aprendizaje

Actividad de Aprendizaje

Teniendo en cuenta lo estudiado sobre los sistemas en tiempo real, desarrolla uno para una lavadora automática.

Diseño de interfaces de usuario

La interfaz del usuario se puede denominar, como la cara de un software que le permite al usuario manipular el sistema construido. En ocasiones se suele presentar que esta no es muy agradablemente visualmente. Es compleja de manipular, poco amigable; lo que conlleva a un bajo uso por parte del usuario (Pressman, 2009).

Para garantizar el buen uso de esta, se debe contar con un diseño cuidadoso y un cumplimiento de las habilidades, experiencias y expectativas que el usuario tenga frente a la misma. Es importante definir algunos asuntos del diseño, por ser fundamental para que el software alcance el éxito esperado. Para ello se tendrán en cuenta los siguientes aspectos:

  • Factores de diseño
  • Principios de diseño
  • Estilos de interacción
  • Presentación de la información

El proceso de diseño de interfaz es semejante a los modelos de proceso de desarrollo de software en que es iterativo, donde el usuario interactúa con el prototipo y de esa forma opina acerca de características, organización, apariencia y el correcto funcionamiento del sistema. Este proceso se compone de unas actividades (Sommerville, 2010):

  • Análisis de usuario
  • Prototipo
  • Evaluación

Actividad de aprendizaje

Actividad de Aprendizaje

A continuación deberás construir un prototipo en Balsamiq. Recuerda presentar el resultado final al docente de clase.

Material
de apoyo

Resumen

En la unidad se abordaron los temas de sistemas distribuidos que son aquellos que permiten al usuario compartir recursos, tolerantes a fallos y escalables, tal como se presentan en el gráfico principal de esta pantalla.

Para el caso del diseño orientado a objetos se debe definir los requerimientos del sistema y a partir de ellos pensar en objetos. Algunos de los modelos de UML que son muy útiles son los casos de uso, donde se detallan los requerimientos y quién es el responsable, mediante el diagrama de capas, el cual divide el sistema en pequeñas partes conocidas como subsistemas y de esta forma abordar la complejidad del mismo. El diagrama de clases le permite al desarrollador generar los objetos y las relaciones, entre ellos. Otros modelos como secuencia y estado son una excelente herramienta para comprender el comportamiento del sistema en desempeño normal o cuando se generen errores.

Los sistemas en tiempo real, por su parte, son diseñados para responder de forma inmediata.

La generación de prototipos permite al desarrollador mostrar al usuario cómo se comportará su sistema, visualmente cómo serán sus ventanas, opciones disponibles e interacciones que le permitirá realizar. Son una forma económica de desarrollo de software antes de llegar a una versión final.

Caso de estudio

Actividad de Aprendizaje

De acuerdo con todo lo estudiado en la unidad, lee el siguiente caso de estudio y pon a prueba lo aprendido.

Bibliografía ()

  • Amescua, A. (2003). Análisis y diseño estructurado y orientado a objetos de sistemas informáticos. Madrid: Mc Graw-Hill Interamericana.
  • Bourque, P. & Fairley, R.E. (2014). Guide to the Software Engineering Body of Knowledge. Hoes Lane: A Project of the IEEE Computer Society.
  • Bruegge, B. & Dutoit, A. (2004). Object- Oriented Software Engineering Using UML, Patterns, and Java. (3ra ed.) Estados Unidos: Prentice Hall.
  • Fox, C. (2006). Introduction to Software Engineering Design. Boston: Pearson Addison Wesley.
  • George, J., Batra, D., Valacich, J. & Hoffer, J. (2006). Object-oriented systems analysis and design. New Jersey: Prentice Hall.
  • Lawrence Pfleeger, S. (2002). Ingeniería de software. Teoría y práctica. Buenos Aires: Pearson Education.
  • Naveda, J. F.& Seidman, S. B. (2006). IEEE computer society real world software engineering problems a self study guide for today´s software professional. Hoboken N.Y.: Wiley-IEEE Computer Society Pr
  • Piattini, M. (1996). Análisis y diseño detallado de Aplicaciones Informáticas de Gestión. Madrid: RA-MA editorial.
  • Pressman, R. (2009). Ingeniería del Software. Madrid: MC. Graw Hill.
  • Schach, S. R. (2006). Ingeniería de Software Clásica y Orientada a Objetos. México: Mc Graw-Hill.
  • Sommerville, I. (2010). Ingeniería de Software. Madrid: Pearson Educación SA.

Referencias Web