martes, 5 de junio de 2012

tipos de arquitectura de software.

Arquitectura cliente servidor:
Una arquitectura es un conjunto de reglas, definiciones, términos y modelos que se emplean para producir un producto.
La arquitectura Cliente/Servidor agrupa conjuntos de elementos que efectúan procesos distribuidos y computo cooperativo. 


Beneficios:

Mejor aprovechamiento de la potencia de cómputo (Reparte el trabajo).
Reduce el tráfico en la Red.
Opera bajo sistemas abiertos.
Permite el uso de interfaces gráficas variadas y versátiles.

¿
Qué es el Cliente?
Conjunto de Software y Hardware que invoca los servicios de uno o varios servidores.
Características:
El Cliente oculta al Servidor y la Red.
Detecta e intercepta peticiones de otras aplicaciones y puede redirigirlas.
Dedicado a la cesión del usuario ( Inicia...Termina ).
El método más común por el que se solicitan los servicios es a través de RPC (Remote Procedure Calls).
Funciones Comunes del Cliente:
Mantener y procesar todo el dialogo con el usuario.
Manejo de pantallas.
Menús e interpretación de comandos.
Entrada de datos y validación.
Procesamiento de ayudas.
Recuperación de errores.

¿
Qué es el Servidor?
Conjunto de Hardware y Software que responde a los requerimientos de un cliente.
Tipos Comunes de Servidores:
Servidor de Archivos.
Servidor de Bases de Datos (SQL, CBASE, ORACLE, INFORMIX).
Servidor de Comunicaciones
Servidor de Impresión.
Servidor de Terminal.
Servidor de Aplicaciones.
Funciones Comunes del Servidor:
Acceso, almacenamiento y organización de datos.
Actualización de datos almacenados.
Administración de recursos compartidos.
Ejecución de toda la lógica para procesar una transacción.
Procesamiento común de elementos del servidor (Datos, capacidad de CPU, almacenamiento en disco, capacidad de impresión, manejo de memoria y comunicación)


Arquitectura multiprocesador:


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.
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.
Para lograrlo, es necesario modificar varias facetas del sistema operativo, la organización del código de las propias aplicaciones, así como los lenguajes de programación.
Se configuran dos computadoras de gran capacidad interconectados electrónicamente entre si. Esta configuración recibe el nombre de multiproceso y se caracteriza porque permite proceso de datos continuo aún en el caso de que surjan problemas de funcionamiento en alguno de las computadoras.
Un ejemplo de este tipo de sistema se muestra en la figura 6.3. Éste es un modelo sencillo de un sistema de control de tráfico aéreo. Un conjunto de sensores distribuidos recolecta la información del flujo de tráfico y la procesa localmente antes de enviarla al cuarto de control. Los operadores toman decisiones utilizando esta información y dan instrucciones a un proceso de control de diversas luces de tráfico. En este ejemplo existen varios procesos lógicos para administrar los sensores, el cuarto de control y las luces de tráfico. Estos procesos lógicos son procesos sencillos a un grupo de procesos. En este ejemplo se ejecutan en procesadores diferentes.
Los sistemas de software compuestos de procesos múltiples no necesariamente son sistemas distribuidos. Si más de un procesador está disponible, entonces se puede implementar la distribución, pero los diseñadores del sistema no siempre consideran lo puntos de distribución durante el proceso de diseño. El enfoque de diseño para este tipo de sistemas es esencialmente el mismo que para los de tiempo real.

Los sistemas multiprocesador  son un tipo de arquitectura con una importancia creciente y ampliamente difundido. La mayoría de los constructores de computadores ofrece máquinas en las que están presentes más de una CPU, configuración que es hoy en día de uso habitual en casi todos los sistemas de tamaño medio y grande, incluso ya en ordenadores personales. Asimismo, los fabricantes de procesadores incorporan a sus arquitecturas, desde hace unos años, los mecanismos necesarios para que éstos se puedan emplear fácilmente, y con un coste reducido.

Arquitectura P2P:



En una red de par a par, los computadores en red actúan como socios en partes iguales, o pares. Como pares, cada computador puede tomar la función de cliente o de servidor. En algún momento, el computador A pedirá un archivo al computador B, el cual responderá entregándole el archivo al computador A. El computador A funciona como cliente, mientras que el B funciona como servidor. Más tarde, los computadores A y B cambiarán de papel. 
es una tecnologia que permite la transmision y difusion de material televisivo a traves de la red publica internet usando para ello una arquitectura P2P en la mayoria de los casos de tipo no estructurada - descentralizada. A diferencia de las arquitecturas de IPTV existentes las arquitecturas P2P-TV no cuentan con un servidor central para la distribucion del contenido, en esta los nodos que componen la red estan conectados entre si de forma aleatoria a traves de enlaces logicos, convirtiendo cada uno de estos en clientes y servidores de video simultaneamente, en la siguiente grafica podemos ver una arquitectura P2P-TV.


 


domingo, 3 de junio de 2012

Aquí veremos un pequeño seminario sobre la arquitectura de software






La investigación sobre Arquitectura del Software y Usabilidad 


El interés por la relación entre Arquitectura del Software y usabilidad no es nuevo, pero recientemente han aparecido algunos trabajos que abren el camino a la práctica del resultado de las investigaciones. Este año, tanto en Viena, en la Conference on Human Factors in Computing Systems (CHI2004), como en Edimburgo, en la International Conference on Software Engineering (ICSE04), un equipo liderado por Len Bass ha impartido un tutorial sobre el tema, cuyo título es bastante ilustrativo: Avoiding “We can’t change THAT!”: Software Architecture & Usability (Cómo evitar “¡Esto no se puede cambiar!”: Arquitectura del Software y Usabilidad).


Patrones arquitecturales Bass continúa con una propuesta de patrón arquitectural para cada escenario (sobre el tema de patrones, consultad el artículo de Luis Villa, Patrones para el diseño de interfaz, publicado en Grancomo). El objetivo es doble:
  • Facilitar a los expertos en usabilidad una checklist con escenarios que muestre aspectos de usabilidad importantes a tener en cuenta en tiempo de requerimientos.
  • Facilitar a los arquitectos patrones que los guíen en el momento de dar soporte a los escenarios.
Otro documento interesante es: Patrones de Usabilidad: Mejora de la Usabilidad del Software desde el momento Arquitectónico (PDF), de Natalia Juristo y Maribel Sánchez-Segura. Una de las aportaciones más interesantes de este documento es que describe el procedimiento de obtención de los patrones de usabilidad que han de servir para construir los patrones arquitectónicos.




 la arquitectura de software también  es la estructura de ese sistema, que incluye componentes de software, las propiedades visibles externas de esos componentes, y las relaciones entre estos. El término también puede incluir la documentación sobre la arquitectura de software del sistema.
Una arquitectura software consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construcción del software para un sistema de información. 





Arquitectura de software


un pequeño resumen sobre análisis y diseño de sistemas-arquitectura de software.




Usabilidad y Arquitectura del Software 


Sin embargo, a menudo hay que ir más lejos y no basta con tener en cuenta la presentación y la funcionalidad. Sobre todo en sistemas complejos, como pueden ser los entornos distribuidos, los transaccionales, los multicanal y aquéllos en los que puede haber miles de usuarios conectados simultáneamente, hay que tener en cuenta la usabilidad desde el inicio del diseño del sistema, es decir, desde lo que se denomina momento de Arquitectura del Software. 

Es bien sabido por los ingenieros del software que cuanto más tarde se detectan los problemas, más cuesta arreglarlos. ¿Cuántas veces nos ha pasado que, al diseñar una interfaz, desearíamos crear interacciones y diálogos que el entorno tecnológico no nos permite? Y siempre acabamos exclamando: ¡Pero si esto mismo lo hice en tal otro sitio! La respuesta de los técnicos no se hace esperar y, utilizando un vocabulario lleno de siglas y conceptos técnicos, nos dicen que en su plataforma esto no es posible. 

Me refiero a cosas como que el usuario pueda visualizar el progreso de sus peticiones, que pueda deshacer acciones (undo), que pueda disponer de un entono multilingüe, que pueda cancelar una operación que lleva mucho tiempo en espera, que pueda reutilizar información que ha introducido anteriormente, y muchas otras cosas. 

Si analizamos estos escenarios de interacción, veremos que la causa de que no se puedan implementar es que no se tuvo en cuenta al usuario al inicio del diseño del sistema, es decir, en la Arquitectura del Software. 

¿Qué es la Arquitectura del Software?

 Existen muchas definiciones de Arquitectura del Software y no parece que ninguna de ellas haya sido totalmente aceptada. En un sentido amplio podríamos estar de acuerdo en que la Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación y tiene la responsabilidad de:

  • Definir los módulos principales
  • Definir las responsabilidades que tendrá cada uno de estos módulos
  • Definir la interacción que existirá entre dichos módulos:
  • Control y flujo de datos
  • Secuenciación de la información
  • Protocolos de interacción y comunicación
  • Ubicación en el hardware
La Arquitectura del Software aporta una visión abstracta de alto nivel, posponiendo el detalle de cada uno de los módulos definidos a pasos posteriores del diseño. 

La definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza así: “La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución”. 


Ejemplos de Arquitectura del Software: J2EE y MVC 


 a continuación se muestran dos diagramas de arquitectura en un entorno J2EE. Ambos diagramas están disponibles en Designing Enterprise Applications with the J2EE Platform, Second Edition. 
El primer diagrama consiste en una vista lógica que muestra los componentes y servicios típicos de un entorno J2EE. 







El segundo diagrama es una vista de proceso que muestra las relaciones entre las capas model, view y controller de la arquitectura MVC bajo J2EE. 
















Arquitectura de software


 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 introduction 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.La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.


El Diseño integral de soluciones informáticas de acuerdo a los nuevos estándares de ingeniería de software es una labor muy relevante y estratégica dentro de su ciclo de vida.




Modelos o vistas.



Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa.
Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:
  • La visión estática: describe qué componentes tiene la arquitectura.
  • La visión funcional: describe qué hace cada componente.
  • La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y como interactúan entre sí.
Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes. El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados únicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptar UML ( lenguaje unificado de modelado) como lenguaje único para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de información (o expresarlas de manera incomprensible).

Arquitecturas comunes 
Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas más universales son:

  • Monolítica
  • . Donde el software se estructura en grupos funcionales muy acoplados.
  • Cliente-servidor
  • . Donde el software reparte su carga de cómputo en dos partes independientes pero sin reparto claro de funciones.
  • Arquitectura de tres niveles
  • . Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia).









sábado, 28 de abril de 2012

Ciclo de vida RUP.



RUP es un marco de desarrollo, te indica una forma de enfocar un proyecto de desarrollo de software y después en función de la naturaleza del mismo haces las adaptaciones oportunas (sin salirte de las fronteras que te marca la metodología porque de lo contrario estaríamos hablando de algo que no sería RUP).
RUP sigue principios de ingeniería del software para la obtención de sistemas de información de calidad y de esta forma proporcionar una alternativa que permita evitar que los productos que se obtengan caigan en los aspectos que caracterizan a la crisis del software (todavía muy presente en nuestros días).
RUP sigue una estrategia de ciclo de vida iterativo e incremental, pero de una forma un tanto peculiar, como vamos a ver a continuación.
El ciclo de vida RUP se divide en 4 fases: Iniciación, Elaboración, Construcción y Transición.
En cada fase se realizan una o más iteraciones (con el objeto de ir perfeccionando los objetivos, mediante el feedback del usuario) y hasta que no finaliza una fase no se comienza con la siguiente. Por regla general, la fase en la que se realizan más iteraciones es la Contrucción.
En cada fase se refinan los objetivos de las fases anteriores en el proceso de conseguir el objetivo o objetivos de la fase, por ejemplo, en la fase de construcción se pueden modificar, añadir o eliminar requisitos, casos de uso, etc… lo que tiene un impacto en lo obtenido en fases anteriores, acercándonos cada vez más a un sistema que satisfaga las necesidades de los usuarios.
En cada fase y en cada iteración se realiza un ciclo de vida en cascada con las siguientes etapas: Análisis, Diseño, Construcción (las tareas de programación que se realizan, sobre todo las fases de Construcción y Transición son perfectamente compatibles con la utilización de técnicas de integración continua y análisis estático de códigos), Pruebas/Integración/Implantación. El alcance del ciclo de vida depende en la fase en la que nos encontremos, es decir, aunque se realice un ciclo de vida en cascada en la fase de Iniciación, lo más probable es que no se llegue a construir nada o se llegue a algún a hacer algún prototipo de muy alto nivel.
Los objetivos que se persiguen en cada fase son los siguientes:
- Iniciación: Obtención de los objetivos, catálogo de requisitos, identificación de casos de uso.
- Elaboración: Refinamiento de los objetivos de la fase anterior, casos de uso, análisis, diseño, definición y establecimiento de la arquitectura base del sistema.
- Construcción: Refinamiento de los objetivos de las fases anteriores y construcción del sistema de información.
- Transición: Refinamiento de los objetivos de las fases anteriores e implementacion de sistemas de información (preparación del producto para su entrega y pasos a producción de versiones no finales (porque hay que hacer ajustes) y de la versión final prevista).
Por tanto, como se comentó anteriormente, en cada etapa y en cada iteración se perfeccionan los productos previos que hayan requerido algún cambio, todo eso mientras se intentan conseguir los objetivos concretos de la fase. De esta forma el ciclo de vida RUP sigue un modelo adaptativo de desarrollo de software.
de esta forma el reparto de esfuerzo entre actividades  varían de una fase a otra.

Una característica importante del RUP es que todo el proceso está guiado por los casos de uso, algo que resulta lógico cuando hablamos de modelos incrementales, ya que están orientados al usuario y como tal es importante tener siempre presente el esquema de interacción usuarios/sistema, los cuales vienen definidos por los casos de uso y sus escenarios.
RUP pretende la obtención de productos de muy alta calidad (extendiéndose esta no solo al cumplimiento de las expectativas del usuario, sino a la obtención de productos con una deuda  técnica  aceptable), si bien sus características: varias fases, múltiples iteraciones por fases, pueden provocar que el proceso de desarrollo sea costoso y que no se adapte a proyectos de pequeña escala, aunque el hecho de que siga un esquema incremental permitiría dar flexibilidad en el caso de que fuera necesario.


Aqui veremos un ejemplo del diagrama de caso de uso.






Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso.
Actores
Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores.
Casos de Uso
Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema
Relaciones entre Casos de Uso
Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. Para el caso de que queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: • Incluye (): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial común a varios casos de uso. En la Figura 16 se muestra cómo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorización.

En este veremos un diagrama de clase UML.

Un diagrama de clases esta compuesto por los siguientes elementos:

  • Clase: atributos, métodos y visibilidad.
  • Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
Elementos


  • Superior
     Contiene el nombre de la Clase
  • Intermedio
     Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).
  • Inferior
     Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).