El modelo 4+1 Kruchten.

MODELO 4+1 DE KRUCHTEN

Este modelo fue creado por el docente Philippe Kruchten y fue uno de los mas cercanos a las norma IEEE 1471 que veremos mas adelante, la cual habla principalmente de las practicas recomendadas en la arquitectura de software.

           La propuesta de Kruchten no se sale de la norma y por lo contrario la complemente, especialmente en el termino de las buenas practicas principales como es la documentación y esta documentación se hace de tal forma que se relacionen las cuatro vistas en la vista +1 llamada escenarios.

            La vista lógica: representa claramente la funcionalidad que si sistema debe proporcionar a los usuarios finales, basado en los requerimientos implementados. Es decir en esta vista se habla y se ve como se debe comportar el sistema y que entradas y salidas tiene en la interfaz del usuario. Esta vista se complementa de los diagramas de clases, de comunicación y de secuencia.

             La vista de desarrollo o de Despliegue: es la vista que se presencia desde la perspectiva del desarrollador y de los administradores del sistema. Principalmente es la descripción mas completa de los componentes del sistema y como están relacionados entre si por medio del código generado.

              La vista de procesos: Es la mas útil para el usuario en los aspectos relacionados con la regla de negocio e interoperabilidad que el sistema debe tener. claramente se determina y se evidencia el flujo del proceso, descrito paso a paso de forma clara y completa y su mejor herramienta es el diagrama de actividades, lo cual permite conocer las partes que intervienen en el proceso y su determinada actividad. 

              La vista Física:   La perspectiva mas completa vista desde el ingeniero de sistemas, encargado de toda la infraestructura y quien determina los componentes físicos del sistema, asi como las conexiones físicas entre estos componentes y los servicios que conforman el sistema y sus soluciones para el cliente. su documentación mas relevante el diagrama de despliegue.

            Por ultimo y muy importante la Vista Escenarios: como su nombre lo indica representa claramente como serán los casos de uso del software y como intervienen las cuatro capas anteriores en cada uno de los procesos de forma cíclica y continua. De esta forma es posible documentar y ver como se comporta cada componente antes durante y después de cada proceso, así mismo el como sera el comportamiento y las entradas y salidas de cada capa para actuar y resolver la actividad o funcionalidad que se esta realizando. Su documentación mas relevante es el mas famoso de los diagramas de uml el Diagrama de Casos de uso. 

El creados de este modelo, no determina la forma en la que se debe documentar pero si da las indicaciones de que es lo que se debe documentar y que es lo mas relevante para el flujo del proceso. así mismo determina lo que puede tener cada vista.

La importancia de la arquitectura de software para las empresas 

Las organizaciones están en continua evolución. Una arquitectura bien diseñada es clave para que las empresas puedan evolucionar con el dinamismo que las economías actuales exigen.  

Si la arquitectura del sistema de una organización no ha sido diseñada con base en prácticas correctas de ingeniería de software, es posible que el sistema se convierta en un obstáculo para la evolución requerida por el negocio. Por ejemplo, porque el sistema no puede escalarse para soportar el volumen de transacciones que le generaría a la empresa su incursión en un nuevo mercado, o porque la arquitectura no permite la adición de nuevos componentes cuando se generen cambios en los requerimientos generados, por ejemplo, por la normatividad de comercio que rige en el país donde la empresa quiere incursionar. 

La arquitectura de un sistema de software puede compararse con la estructura de un edificio. Si esta estructura está mal diseñada, el edificio puede derrumbarse. De igual manera, un sistema de software que carece de diseño arquitectónico de calidad puede funcionar de forma muy deficiente o simplemente no funcionar. Peor aún, podría generar consecuencias catastróficas para la organización o los usuarios que sirve. 

Para las empresas que dependen de los sistemas de información, que actualmente no son pocas, las arquitecturas de software son fundamentales para el logro de sus objetivos organizacionales, lo que incluye el poder evolucionar rápidamente según las condiciones altamente cambiantes de los mercados actuales. 

Porque es importante la arquitectura de software 

1. Sirve para crear una base sólida para los proyectos.
2. Conseguiremos que la plataforma creada sea escalable.
3. Aumenta el rendimiento de la plataforma.
4. Reduce considerablemente los costes y evita duplicaciones del código.
5. La arquitectura de software es una manera de garantizarte una buena IT, puesto que el arquitecto debe conservar durante toda la creación, una visión general del producto, de forma que pueda bajar a pequeñas partes del código y saber enlazarlas con el resto. Debe mantener una línea lógica y en ocasiones incluso, dar la cara para asegurar resultado exitosos.
6. El arquitecto, al tener esta visión global del proceso e incluso del producto final, sabe en qué aspectos se puede ahorrar gastos. De forma que reutiliza procesos y comparte los datos para optimizar al máximo cada proceso evolutivo, buscando a su vez la mayor perfección posible.
7. Ya que el código es propio, es mucho más visible y se tiene pleno conocimiento sobre él, de forma que será mucho más fácil encontrar problemas y por lo tanto soluciones, en definitiva tenemos un mantenimiento mucho más eficaz.
8. Este conocimiento, a la par nos permite la implementación de cambios en los sistemas de manera más rápida.
9. Incrementa la calidad de la plataforma.
10. Ayuda en las tareas más complejas.
11. Nos permite hacer la plataforma de manera más rápida.
12. Permite una mayor adaptabilidad. Por ejemplo a la hora de modificar características técnicas en front end, o implementar motores de reglas. Son tareas más sencillas de adaptar cada una a su debido tiempo, ya que por otro lado el arquitecto de software establece prioridades.
13. Ayuda a la gestión de riesgos reduciendo el porcentaje de fracasos.
14. Reduce los tiempos de creación y de entrega de los proyectos.
15. Da prioridad a los conflictos. Permite comunicación entre las partes y decisiones de diseño previas a su implementación, de forma que sea más fácil un diseño especializado.

NORMA IEEE:1471:2000

IEEE 1471 es un sustituida Norma IEEE para describir la arquitectura de un "sistema de software intensivo", también conocida como arquitectura de software .

  

Información general

IEEE 1471 es el nombre abreviado de un estándar conocido formalmente como ANSI / IEEE 1471-2000, Práctica Recomendada para Arquitectura Descripción del Software Systems-intensivo. Dentro Instituto de Ingenieros Eléctricos y Electrónicos jerga (IEEE), se trata de una "práctica recomendada", lo más mínimo normativa de sus normas. En 2007 esta norma fue adoptada por la norma ISO / IEC JTC 1 / SC7 como ISO / IEC 42010: 2007 ., Sistemas e Ingeniería de Software - Práctica recomendada para la descripción arquitectónica de los sistemas intensivos en software

Durante mucho tiempo se ha reconocido Que "la arquitectura" tiene una fuerte influencia sobre el ciclo de vida de un sistema. Sin embargo, hasta hace relativamente poco, Problemas de hardware han tendido a dominar el pensamiento arquitectónico, y los aspectos de software, cuando se considera en absoluto, eran a menudo los primeros en ser comprometida bajo las presiones del desarrollo. EE 1471 fue creado para proporcionar una base para pensar acerca de la arquitectura de los sistemas intensivos en software. 

  

Las contribuciones de IEEE 1471 pueden resumirse de la siguiente manera (en esta lista, los elementos en cursiva son términos definidos por y utilizados en la norma): 

• Proporciona definiciones y un meta-modelo para la descripción de la arquitectura
• Afirma que una arquitectura debería tratar de un sistema de grupos de interés preocupaciones

• Se afirma que la descripción de la arquitectura s son inherentemente múltiples vistas , sin vistas solo capta adecuadamente todas las preocupaciones de los interesados

• Se especifican las nociones de vista y el punto de vista , donde un punto de vista identifica el conjunto de las preocupaciones y las representaciones / técnicas de modelado, etc. utilizados para describir la arquitectura de abordar estas preocupaciones y una vista es el resultado de aplicar un punto de vista de un sistema en particular.

• Establece requisitos de contenido para las descripciones de la arquitectura y la idea de que una descripción de la arquitectura conformando tiene una correspondencia 1 a 1 entre sus puntos de vista y sus opiniones.

• Proporciona una guía para la captura de la arquitectura lógica y la identificación de inconsistencias / problemas no resueltos entre los puntos de vista dentro de una descripción de la arquitectura 

IEEE 1471 proporciona anexos informativos que se relacionan con sus conceptos de arquitectura conceptos ito en otras normas, incluyendo RM-ODP y IEEE 12207 .