El Modelo de “4+1” Vistas de la Arquitectura del Software

Un tema interesante que encontré, es el modelo denominado "4+1" del profesor Philippe Kruchten, tambien denominado vistas recurrentes. Este uso de múltiples vistas permite abordar los intereses de los distintos “stakeholders” de la arquitectura por separado: usuarios finales, desarrolladores, ingenieros de sistemas, administradores de proyecto, etc., y manejar los requisitos funcionales y no funcionales separadamente. Se describe cada una de las cinco vistas descritas, conjuntamente con la notación para captarla. Las vistas se diseñan mediante un proceso centrado en la arquitectura, motivado por escenarios y desarrollado iterativamente. 

El modelo de 4+1 vistas fue desarrollado para remediar este problema. El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes. Cada vista se refiere a un conjunto de intereses de diferentes stakeholders del sistema. 

La arquitectura del software se trata de abstracciones, de descomposición y composición, de estilos y estética. También tiene relación con el diseño y la implementación de la estructura de alto nivel del software. Los diseñadores construyen la arquitectura usando varios elementos arquitectónicos elegidos apropiadamente. Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y performance del sistema, así como también otros requisitos no funcionales tales como confiabilidad, escalabilidad, portabilidad y disponibilidad del sistema. Bueno pues, en el modelo de Kruchten, propone un sistema de software en 4 vistas bien diferenciadas, cada una de estas vistas ha de mostrar toda la arquitectura del sistema de  software que se este documentando, pero cada una de ellas ha de documentarse de forma diferente y ha de mostrar aspectos diferentes del software.

Para entender mejor este concepto, podemos tomar de ejemplo, si un arquitecto nos enseña el plano de una casa, nos esta enseñando una vista de la casa, pero en el momento en el que nos explica que significado tienen cada símbolo, por ejemplo que determinado símbolo representa una puerta, nos esta dando su punto de vista para entender mejor el plano. si luego nos muestra otro plano en donde se muestren diferentes símbolos con otras representaciones de la casa, nos dara otro punto de vista.

Esto para comprender mejor los puntos de vista, ahora podemos ver mejor cada una de las vistas que propone el modelo:

• La vista lógica describe el modelo de objetos del diseño cuando se usa un método de diseño orientado a objetos. Para diseñar una aplicación muy orientada a los datos, se puede usar un enfoque alternativo para desarrollar algún otro tipo de vista lógica, tal como diagramas de entidad-relación.
• La vista de procesos describe los aspectos de concurrencia y sincronización del diseño. 
• La vista física describe el mapeo del software en el hardware y refleja los aspectos de distribución. 
• La vista de desarrollo describe la organización estática del software en su ambiente de desarrollo.

Como parte final, están los escenarios los cuales constituyen la quinta vista. y es que los diseñadores de software pueden organizar la descripción de sus decisiones de arquitectura en estas cuatro vistas, pero estas son ilustrarlas en un conjunto reducido de casos de uso o escenarios,  La arquitectura evoluciona parcialmente a partir de estos escenarios. 

Los escenarios son de alguna manera una abstracción de los requisitos mas importantes. Su diseño se expresa mediante el uso de diagramas de escenarios y diagramas de interacción de objetos. Esta vista es redundante con las otras (y por lo tanto “+1”), pero sirve a dos propósitos principales:

• Como una guía para descubrir elementos arquitectónicos durante el diseño de arquitectura tal como lo describiremos mas adelante 
• Como un rol de validación e ilustración después de completar el diseño de arquitectura, en el papel y como punto de partido de las pruebas de un prototipo de la arquitectura. 

http://jarroba.com/modelo-41-vistas-de-kruchten-para-dummies/
http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:modelo4_1.pdf

LENGUAJES DE PATRONES DE ARQUITECTURA DE SOFTWARE

Como siempre en cada entrada de este blog, lo que trato es de compartir temas relacionados con la clase y en esta ocasión encontré un articulo de la universidad de Pereira algo interesante, el cual hablan un poco de la arquitectura de software visto como una herramienta de ayuda y su vez resaltando el arte que esta contiene, profundizando hasta el tema de lenguajes de patrones de arquitectura de software. Lo que intentare en esta entrada sera de resaltar las características mas importantes que considero encontrados en este articulo.

Como primera medida me parece importante dar una referencia de la definición de arquitectura de software, que de manera general, se define como un nuevo paradigma o nueva forma de ver un sistema de información desde un punto de vista holístico, donde cada componente afecta los requerimientos fundamentales, ya sean funcionales o no funcionales. Esta disciplina aborda estos requerimientos rigurosamente y garantiza un buen diseño de la aplicación final, lo que redunda en mejor calidad, un mayor retorno de inversión de los proyectos y garantiza una mejor mantenibilidad de los sistemas de información construidos. Otra definición es la de George Fairbanks quien define la Arquitectura de Software como: La ciencia que trata el diseño de un sistema de información y del impacto de sus cualidades como: desempeño, seguridad, modificabilidad entre otras.

De forma histórica y evolutiva, el articulo muestra el cambio que se tuvo de la ingeniería de software a la arquitectura de software.

La Ingeniería de Software tuvo sus inicios en la década de los sesenta y a partir de allí a evolucionado de forma constante a través de las últimas seis décadas. En los años cincuenta se inició con el intentó imitar la ingeniería de hardware y se pensó en ese entonces que la utilización del método científico brindaría un soporte investigativo suficiente para obtener un proceso técnico coherente. Finalizando el siglo XX la ingeniería evolucionó como un área de estudio más estructurada y con fundamentos teóricos fuertes. Desde entonces la voluntad de los ingenieros fue de mejorar la calidad del software construido y de dar herramientas que facilitaran el trabajo a diseñadores e implementadores de sistemas de información en general.

Dominios específicos de aplicación

Los lenguajes de patrones han ocupado un lugar muy importante en los diseños de Arquitectura de Software. Se aplican tanto en proyectos de investigación y como en proyectos comerciales de desarrollo de software.

Una ejemplo de cómo los lenguajes de patrones pueden ser usados en dominios específicos se puede observar en el proyecto realizado por IBM donde se define un lenguaje de patrones para aplicaciones eBusiness. Este lenguaje divide los patrones de arquitectura en cuatro categorías: Patrones de negocios, patrones de integración, patrones de aplicación y patrones de ejecución, los cuales parten la arquitectura completa en tres capas principales como se sigue: Capa de negocios, capa de integración y Middleware o Capa de infraestructura. A continuación se define cada uno de las categorías que conformaron el lenguaje propuesto.

Patrones de negocio: mapea las interacciones entre los actores del negocio y las funcionalidades del sistema en particular. Patrones de Integración: Estos se definen como ortogonales a la capa de negocios, creando soluciones particulares que al integrarse soportan las funcionalidades de un sistema en particular.
Patrones de Aplicación: Estos patrones refinan los patrones de negocio e integración subdividiendo los subsistemas en componentes que proveen interfaces claras de implementación de funcionalidades del sistema a diseñar.
Patrones de Ejecución: Refinan los componentes del patrón de aplicación descomponiéndolos en componentes más pequeños sobre la infraestructura o middleware. Ya en este lenguaje los patrones intervienen directamente en la capa física de la aplicación con infraestructura y tecnología.

Esta subdivisión de patrones permite una variedad de soluciones de diseño reusables por diversas aplicaciones en este dominio en particular.

Los Lenguajes de Patrones citados anteriormente han sido utilizados por la industria, y estos se originaron de proyectos de investigación. Otras universidades e investigadores han desarrollado diversos Lenguajes los cuales hoy en día se han convertido en estándares de facto. A continuación se mencionan algunos estos.



http://200.21.217.140/index.php/revistaciencia/article/view/8595

PLANEANDO UN SISTEMA DE INFORMACION

A través de los años, se han evaluado numerosos intentos de modernizar sistemas de información; se han encontrado grandes problemas como altos costos, largos retrasos en el desarrollo y sistemas que no satisfacen las necesidades del usuario.

En muchos casos, estos defectos en el desarrollo ocurrieron por una inadecuada planeación detallada para identificar necesidades futuras y actuales de los usuarios y una prematura decisión a un específico diseño que no consideró alternativas de solución o que tan bien satisficieran las necesidades de los usuarios. 

Tiendo este preámbulo, podemos ver que gran parte del éxito de un sistema de información, comprende su planeación y es allí que buscando alguna información sobre esto, encontré un artículo en donde plantean una ideas del cómo se puede llegar a realizar esta planeación para que el sistema de información vaya a acorde con los principios de la organización y pueda cumplir con éxito los objetivos por los cuales se está creando. 

La planificación de Sistemas de Información (PSI) tiene como objetivo la obtención de un marco de referencia para el desarrollo de sistemas de información que responda a los objetivos estratégicos de la organización. Este marco de referencia consta de:

• Una descripción de la situación actual, que constituirá el punto de partida del Plan de Sistemas de Información. Dicha descripción incluirá un análisis técnico de puntos fuertes y riesgos, así como el análisis de servicio a los objetivos de la organización.
• Un conjunto de modelos que constituya la arquitectura de información. 
• Una propuesta de proyectos a desarrollar en los próximos años, así como la prioridad de realización de cada proyecto. 
• Una propuesta de calendario para la ejecución de dichos proyectos. 
• La evaluación de los recursos necesarios para los proyectos a desarrollar en el próximo año, con el objetivo de tenerlos en cuenta en los presupuestos. Para el resto de proyectos, bastará con una estimación de alto nivel. 
• Un plan de seguimiento y cumplimiento de todo lo propuesto mediante unos mecanismos de evaluación adecuados. 

La perspectiva del plan debe ser estratégica y operativa, no tecnológica. Es fundamental que la alta dirección de la organización tome parte activa en la decisión del Plan de Sistemas de Información con el fin de posibilitar su éxito. La dirección debe convencer a sus colaboradores más directos de la necesidad de realización del plan; de su apoyo de forma constructiva, mentalizándose de que la ejecución del mismo requerirá la utilización de unos recursos de los cuales son responsables.

La presentación del Plan de Sistemas de Información y la constitución del equipo supone el arranque del proyecto y es fundamental que las más altas instancias de la organización estén implicadas en ambos, dando el apoyo necesario y aportando todo tipo de medios. 

Explicar el plan a las personas de la organización y a las unidades organizativas afectadas sobre las que recaerá el Plan, el apoyo de los altos directivos y la cualificación de los recursos de las distintas unidades implicadas, serán factores críticos de éxito del Plan de Sistemas de Información.

El nivel de detalle con el que se hará el estudio de la situación actual dependerá de la existencia de documentación actual, de si hay personas que conozcan dicha documentación y de la predisposición a una sustitución total o parcial por sistemas de información nuevos. En cualquier caso, como paso previo para detectar aspectos importantes que puedan afectar a la organización, es necesario investigar sus puntos fuertes, áreas de mejora, riesgos y amenazas posibles y hacer un diagnóstico de los mismos.

Para la elaboración del Plan de Sistemas de Información se estudian las necesidades de información de los procesos de la organización afectados por el Plan, con el fin de definir los requisitos generales y obtener modelos conceptuales de información. Por otra parte se evalúan las opciones tecnológicas y se propone un entorno. Tras analizar las prioridades relacionadas con las distintas variables que afectan a los sistemas de información, se elabora un calendario de proyectos con una planificación lo más detallada posible de los más inmediatos. Además, se propone una sistemática para mantener actualizado el Plan de Sistemas de Información para incluir en él todos los cambios necesarios, garantizando el cumplimiento adecuado del mismo.


http://www.bocc.ubi.pt/pag/urrutia-amaia-planificacion.pdf
http://manuel.cillero.es/doc/metrica-3/procesos-principales/psi

DESCRIBIENDO LA ARQUITECTURA DE SOFWARE

La complejidad de los sistemas hechos por el hombre ha llegado a un nivel sin precedentes. Esto ha dado lugar a nuevas oportunidades, pero también a un aumento de desafíos para las organizaciones que crean y utilizan sistemas. Los conceptos, principios y procedimientos de arquitectura que se aplican cada vez más para ayudar a manejar la complejidad que enfrentan los actores de los sistemas.

La nacionalización de la arquitectura de un sistema, tal como se expresa en una descripción de la arquitectura, ayuda a la comprensión de la esencia del sistema y propiedades clave relativas a su comportamiento, composición y evolución, que a su vez afecta a preocupaciones tales como: la viabilidad, utilidad y facilidad de mantenimiento del sistema.

Esta norma se puede utilizar para establecer una práctica coherente para desarrollar descripciones de la arquitectura, los marcos de arquitectura y descripción de las arquitecturas establecidas en el marco de un ciclo de vida y sus procesos (no definido en esta Norma Internacional).

De la norma 1471 a la 42010

                           

La IEEE 42010 limita y organiza los frameworks de arquitectura y lenguajes de descripción de arquitectura (ADL). Esta norma proviene de su predecesora la IEEE 1471, con la IEE 42010, se buscó contribuir en los siguientes aspectos:

• Que la arquitectura de un sistema sea considerada fundamental en el contexto del sistema y su desarrollo.
• Documentación específica, organizada y clara de la arquitectura de un sistema.
• Que la arquitectura de un sistema demuestre como la misma informa de las necesidades del sistema a todas las partes interesadas de una manera clara y coherente.
• Que la arquitectura permita identificar todas las reglas del sistema a partir del analisis de cada punto de vista de la arquitectura.
• Que las necesidades puedan ser capturadas a través de un modelo conceptual o meta modelo, estableciendo los conceptos clave y términos para hablar de arquitectura y descripción de la misma.

Modelo conceptual

En la figura se representan los conceptos clave relativos a los sistemas y sus arquitecturas como un contexto para la comprensión de la práctica de la descripción de la arquitectura.

El sistema de expresión se utiliza en esta Norma Internacional para referirse a las entidades cuyas arquitecturas son de interés. El término pretende incluir, pero no se limita a las entidades dentro de los siguientes dominios:

• Sistemas: Los sistemas que son artificiales y se puede configurar con uno o más de los siguientes: el hardware, el software, los datos, los seres humanos, los procesos, los procedimientos, instalaciones, materiales y entidades presentes en la naturaleza.

• Productos de software y servicios que se describen en [ISO / IEC 12207];

• Sistemas intensivos en software: cualquier sistema en el que el software contribuye con influencias esenciales para el diseño, construcción, implementación y evolución del sistema en su conjunto" para abarcar "las aplicaciones individuales, sistemas en el sentido tradicional, subsistemas, sistemas de sistemas, líneas de productos, familias de productos, empresas integrales y otras agrupaciones de interés.

Vistas de arquitectura

Una descripción de arquitectura  deberá incluir exactamente una vista de arquitectura por cada punto de vista de arquitectura usado.

1. Cada vista de arquitectura deberá adherir las convenciones de los puntos de vista que gobiernan la arquitectura.
2. Cada vista de arquitectura deberá incluir:

• Información principal y complementaria según lo especificado por la organización del proyecto.

• Identificación del punto de vista que gobierna la vista.
• Modelos de arquitectura que se ocupan de todos los problemas enmarcados por el punto de vista que lo gobierna y que cubra todo el sistema desde ese punto de vista.
• El registro de los aspectos conocidos en la vista con respecto al punto de vista que lo gobierna.

Modelos de arquitectura

Una vista de arquitectura deberá  estar compuesto de uno o más modelos de arquitectura. Cada modelo de arquitectura deberá incluir la versión especificada por la organización y/o proyecto. Cada modelo de arquitectura deberá identificar el tipo de modelo que lo gobierna y adherirse a las convenciones de ese tipo de modelo.

Términos y definiciones

Architecting: proceso de concebir, definir, expresar, la documentación, la comunicación, la certificación de una aplicación adecuada de mantenimiento y mejora de una arquitectura a lo largo del ciclo de vida de un sistema

Arquitectura: (Sistema) conceptos o propiedades de un sistema en su entorno plasmada en sus elementos, relaciones, y en los principios de su diseño y evolución fundamentales

Descripción de la arquitectura: producto de trabajo se usa para expresar una arquitectura

Marco de arquitectura: convenciones, principios y prácticas para la descripción de arquitecturas establecido dentro de un dominio específico de aplicación y / o de la comunidad de partes interesadas

Vista de la arquitectura: producto de trabajo que expresa la arquitectura de un sistema desde la perspectiva de las preocupaciones específicas del sistema

Arquitectura mirador: producto de trabajo que se establecen los convenios para la construcción, interpretación y uso de los puntos de vista de arquitectura para enmarcar las preocupaciones específicas del sistema

Preocupación: (Sistema) de participación en un sistema correspondiente a una o más de sus grupos de interés

Ambiente: (Sistema) contexto determinar el entorno y las circunstancias de todas las influencias sobre un sistema

Tipo de Modelo: convenciones para un tipo de modelado.

Stakmeholder: Equipo, organización o clases de la misma, que tenga un interés en un sistema.

http://cabibbo.dia.uniroma3.it/asw/altrui/iso-iec-ieee-42010-2011.pdf
https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:42010:ed-1:v1:en

CONCEPTOS CLAVES

SISTEMA DE INFORMACIÓN

Podemos definir un sistema de información como:

• Combinación de tecnología de la información y actividades humanas que usan esa tecnología para soportar operaciones, administración y toma de decisiones.
• Esta compuesto por datos y procesos.
• Su propósito es tener la información correcta, para las personas correctas, en el momento correcto, en la cantidad correcta, y en un formato correcto. 

AXIOMA

La palabra axioma proviene del sustantivo griego αξιωμα, que significa «lo que parece justo» o, que se le considera evidente, sin necesidad de demostración. El término viene del verbo griego αξιοειν (axioein), que significa «valorar», que a su vez procede de αξιος (axios): «valioso» o «digno». Entre los filósofos griegos antiguos, un axioma era lo que parecía verdadero sin necesidad de prueba alguna.

Los axiomas son importantes en los modelos de información ya que son los elementos de calificación los cuales le dan valor y significado al modelo presentado; y se presentar como verdades irrefutables.

INTRODUCCION

En la vida del hombre desde sus inicios, la información ha hecho parte fundamental en este,y ha evolucionado paralela y conjuntamente hasta convertirse en parte indispensable e indiscutible de nuestra rutina diaria a todos los niveles. 

A medida que crecía gradualmente la importancia de la información, también variaba la manera en que esta se gestionaba, llegando a crear disciplinas estrictamente relacionadas con el estudio de información, y en la actualidad es una materia importante de aprendizaje de los inicios nuestra formación así como en parte indisoluble de la mayoría de las empresas a nivel mundial. 

En este progresar del ser humano, de las sociedades y de las tecnologías es que nacieron los sistemas de información (SI), siendo cada vez mas favorecidos en las empresas y organizaciones, y tomando mayor importancia para este. 

Actualmente los sistemas de información apoyados en herramientas ofimáticas han alcanzado un gran auge, a tal punto de casi desplazar los tradicionales formatos de papel. Algunos de los elementos mas importantes son los datos, la información y el conocimiento; entidades que suponen la materia prima de los sistemas de información en las organizaciones.

.