martes, 7 de mayo de 2013

ARQUITECTURA DE SOFTWARE


 3.1 Arquitectura de software

En los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software. En el libro "An introducción to Software Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema".

  • La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema.

  • Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco
  • Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.

 

 

3 .2 Patrón de diseño


Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

  •  


Objetivos de los patrones


Los patrones de diseño pretenden:

  • Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
  • Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
  • Formalizar un vocabulario común entre diseñadores.
  • Estandarizar el modo en que se realiza el diseño.
  • Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Asimismo, no pretenden:

  • Imponer ciertas alternativas de diseño frente a otras.
  • Eliminar la creatividad inherente al proceso de diseño.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".

Categorías de patrones


Según la escala o nivel de abstracción:

  • Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software.
  • Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas de software.
  • Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.

Además, también es importante reseñar el concepto de "antipatrón de diseño", que con forma semejante a la de un patrón, intenta prevenir contra errores comunes de diseño en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseños muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejón sin salida por haber cometido los mismos errores.

Además de los patrones ya vistos actualmente existen otros patrones como el siguiente:

  • Interacción: Son patrones que nos permiten el diseño de interfaces web.

 Estructuras o plantillas de patrones


Para describir un patrón se usan plantillas más o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicación uniforme entre diseñadores. Varios autores eminentes en esta área han propuesto plantillas ligeramente distintas, si bien la mayoría definen los mismos conceptos básicos.

La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados:

  • Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).
  • Clasificación del patrón: creacional, estructural o de comportamiento.
  • Intención: ¿Qué problema pretende resolver el patrón?
  • También conocido como: Otros nombres de uso común para el patrón.
  • Motivación: Escenario de ejemplo para la aplicación del patrón.
  • Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.
  • Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.
  • Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.
  • Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.
  • Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.
  • Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.
  • Código de ejemplo: Código fuente ejemplo de implementación del patrón.
  • Usos conocidos: Ejemplos de sistemas reales que usan el patrón.
  • Patrones relacionados: Referencias cruzadas con otros patrones.

 

 

3.3 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-to-peer (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.

 

 

3.4  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.

 

3.5 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.

 

3.6 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.

 

3.7  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.