viernes, 27 de julio de 2012

ARQUITECTURA DE SOFTWARE

David Garlan y Mary Shaw definen que la Arquitectura esta a un nivel "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 de Software es un conjunto de abstracciones y patrones que indican el camnino y estructura necesaria para encaminar la construcción del software.

¿Que es una vista?

Una vista es “una presentación de un modelo, la cual es una descripción completa de un sistema desde una particular perspectiva” (Kruchten, 1995).
En arquitecura de software se define un modelo que es el modelo 4+1.
Este modelo define 4 vistas principales

  • Vista Lógica (Logical View), modelo de objetos, clases, entidad – relación.
  • Vista de Proceso (Process View), modelo de concurrencia y sincronización.
  • Vista de Desarrollo (Development View), organización estática del software en su entorno de desarrollo (librerías, componentes, .ear, .jar, etc.).
  • Vista Física (Physical View), modelo de correspondencia software - hardware (aspectos de distribución en máquinas, por ejemplo)

Imagen1.png

Y una vista más, la "+1", que se muestra y traza en cada una de las anteriores y que está formada por las necesidades funcionales que cubre el sistema, y que en ocasiones identificamos como vista de "casos de uso".
También comentar que el modelo de vistas “4+1” es “genérico”: otras notaciones y herramientas a parte de UML pueden usarse, y cualquier método de diseño, especialmente para las descomposiciones lógicas y de proceso.

. Arquitectura Lógica (Logical Architecture)
Soporta el análisis y la especificación de los requisitos funcionales: lo que el sistema debería proporcionar en términos de servicios a sus usuarios. El sistema se descompone en un conjunto de abstracciones clave tomadas mayormente del dominio del problema, en forma de objetos o clases. En esta vista se usan comúnmente los diagramas de clases, los de interacción y objetos.
Notación: La notación más usada es UML, y dentro de esta diagramas de clases y paquetes.
Estilo: El estilo más usado para la vista lógica es el Orientado a Objetos.

2. Arquitectura de Procesos (Process Architecture)
Se tratan algunos requisitos no funcionales. Ejecución, disponibilidad, tolerancia a fallos, integridad, etc. Esta vista también especifica que hilo de control ejecuta cada operación identificada en cada clase identificada en la vista lógica. La vista se centra por tanto en la concurrencia y distribución de procesos.
Notación: La notación más usada es UML, y dentro de esta diagramas estados, actividad y similares.

3. Arquitectura de Desarrollo (Development Architecture)
La vista de desarrollo o despliegue se enfoca en la organización de los módulos software en el entorno de desarrollo. El software es empaquetado en pequeños trozos (librerías de programa, subsistemas, componentes, etc.), los subsistemas se organizan en capas jerárquicas, y cada capa proporciona una interfaz bien definida a sus capas superiores

4. Arquitectura Física (Physical Architecture)
La vista física se centra en los requisitos no funcionales, tales como la disponibilidad del sistema, la fiabilidad (tolerancia a fallos), ejecución y escalabilidad. Y también presenta cómo los procesos, objetos, etc., corresponden a nodos de proceso:
Componentes: nodos de proceso.
Conectores: LAN, WAN, bus, etc.
Contenedores: subsistemas físico
Varias configuraciones físicas pueden usarse. La correspondencia de el software a los nodos debe ser altamente flexible y tener el mínimo impacto en el código fuente.

. Escenarios
La vista de escenarios corresponde con instancias de casos de uso que unifican todas las vistas. Así, desde casos de uso se debiera poder hacer una trazabilidad a todos los componentes del sistema software, viendo, por ejemplo, que máquinas, o clases, o componentes, o .jar, o procesos, son los responsables de que el sistema cubra una cierta funcionalidad

5. Arquitectura y UML
Se ha ido exponiendo a lo largo de la explicación de cada una de las vistas su translación a un lenguaje de modelado concreto como UML. Hay que tener en cuenta que UML nace casi a la vez que el modelo 4+1, por lo que en un origen no existía una clara relación entre ambos, lo que a menudo produce confusión al diseñador que en la actualidad quiere modelar una arquitectura con ambas herramientas. A modo de resumen la translación se presenta en la siguiente tabla:
tabla.png



ArUML.png
Ver Modelado Arquitectonico


Referencias
Kruchten P. Architectural Blueprints—The “4+1” View Model of Software Architecture. IEEE Software, November 1995, 12 (6), pp.42-50.
Piattini, asdasdasd, ediu.
http://es.wikipedia.org/wiki/Arquitectura_de_software

http://foros.cerolag.com/f-el-ultimo-rincon-110/t-wikipedia-56026.html

Lenguaje Unificado de Modelado


Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por elOMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.
 File:UML Diagrams.jpg
 

Estandarización de UML

Desde el año 1995, UML es un estándar aprobado por la ISO como ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Versión 1.4.2.

Historia

[editar]Antes de UML 1.x

Después de que la Rational Software Corporation contratara a James Rumbaugh de General Electric en 1994, la compañía se convirtió en la fuente de los dos esquemas de modelado orientado a objetos más populares de la época: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para análisis orientado a objetos, y el Método Booch de Grady Booch, que era mejor para el diseño orientado a objetos. Poco después se les unió Ivar Jacobson, el creador del método de ingenieríá de software orientado a objetos. Jacobson se unió a Rational en 1995, después de que su compañía Objectory AB fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabia de sus constantes argumentos sobre las prácticas metodológicas.
En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consultó con representantes de compañías competidoras en el área de la tecnología de objetos durante la OOPSLA '96; eligieron cajas para representar clases en lugar de la notación de Booch que utilizaba símbolos de nubes.
Bajo la dirección técnica de los Tres Amigos fue organizado un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una respuesta al OMG RFP. El borrador de la especificación UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las semánticas de la especificación y para integrarla con otros esfuerzos de estandarización. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.

[editar]UML 1.x

Como notación de modelado, la influencia de la OMT domina UML (por ejemplo el uso de rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de Booch, si se adoptó la capacidad de Booch para especificar detalles de diseño en los niveles inferiores. La notación de Casos de Uso del Objectory y la notación de componentes de Booch fueron integrados al resto de la notación, pero la integración semántica era relativamente débil en UML 1.1, y no se arregló realmente hasta la revisión mayor de UML 2.0.
Conceptos de muchos otros métodos OO fueron integrados superficialmente en UML con el propósito de hacerlo compatible con todos los métodos OO. Además el grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en una variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de un sólo usuario a sistemas concurrentes y distribuidos.