1.4.- Arquitectura 4 + 1 PDF

Title 1.4.- Arquitectura 4 + 1
Course Analísis Avanzado de Software
Institution Instituto Tecnológico de Tijuana
Pages 4
File Size 282.3 KB
File Type PDF
Total Downloads 29
Total Views 363

Summary

TECNOLÓGICO NACIONAL DE MÉXICOINSTITUTO TECNOLÓGICO DE TIJUANASubdirección AcadémicaDepartamento de Sistemas y ComputaciónSemestre Agosto - Diciembre 2020CARRERAIngeniería en Sistemas ComputacionalesMATERIA Y GRUPOAnálisis Avanzado de Software(ADF-1702 SC8B)ALUMNO Y NO. DE CONTROLAcevedo Cardona Ade...


Description

TECNOLÓGICO NACIONAL DE MÉXICO INSTITUTO TECNOLÓGICO DE TIJUANA Subdirección Académica Departamento de Sistemas y Computación Semestre Agosto - Diciembre 2020

CARRERA Ingeniería en Sistemas Computacionales

MATERIA Y GRUPO Análisis Avanzado de Software (ADF-1702 SC8B)

ALUMNO Y NO. DE CONTROL Acevedo Cardona Adelaid Lesdeymariet (16211957)

CORREO INSTITUCIONAL [email protected] TEMA 1.4 – Modelo de Arquitectura 4+1

DOCENTE José de Jesús Parra Galaviz

FECHA DE ENTREGA 24 de septiembre del 2020

Modelo de Arquitectura 4+1 La Arquitectura de Software constituye un diseño de alto nivel del sistema. Una forma de representarlo es mediante el Modelo de Vistas de Arquitectura 4+1, este encajaba en el antiguo estándar IEEE 1471-2000 (Recommended Practice for Architecture Description of SoftwareIntensive Systems) que fue reemplazado en el 2011 por el ISO/IEC/IEEE 42010:2011 (Systems and software engineering - Architecture description) el cual en la actualidad es una referencia en el ámbito del diseño. El modelo fue ideado en 1995 por Philippe Kruchten, un Ingeniero de Software Canadiense, con la finalidad de “describir la arquitectura de sistemas de software, basados en el uso de múltiples puntos de vista concurrentes”. Se utiliza para organizar el software en un entorno de desarrollo. Lo que propone Kruchten es que un sistema de software se ha de documentar y mostrar (tal y como se proponía en el estándar IEEE 1471-2000) con 4 vistas bien diferenciadas y estas 4 vistas se han de relacionar entre sí con una vista más, que es la denominada vista “+1”. Estas 4 vistas las denominó Kruchten como: vista lógica, vista de procesos, vista de despliegue y vista física, la vista “+1” que tiene la función de relacionar las 4 vistas citadas, la denominó vista de escenario. Cada una de estas vistas ha de mostrar toda la arquitectura del sistema de software que se esté documentando, pero cada una de ellas ha de documentarse de forma diferente y han de mostrar aspectos diferentes del sistema de software. A continuación, se explicará que información ha de haber en la documentación de cada una de estas vistas.

Vistas del Modelo de Arquitectura 4+1

Observando la imagen anterior podemos encontrar las siguientes vistas: ▪

Vista Lógica (Logic View): En esta vista se representa la funcionalidad que el sistema proporcionara a los usuarios finales. Es decir, se ha de representar lo que el sistema debe

hacer y las funciones y servicios que ofrece. Para completar la documentación de esta vista se pueden incluir los diagramas de clases, de comunicación o de secuencia de UML. ▪

Vista de Despliegue/Desarrollo (Development View): En esta vista se muestra el sistema desde la perspectiva de un programador y se ocupa de la gestión del software; o en otras palabras, se va a mostrar como está dividido el sistema de software en componentes y las dependencias que hay entre esos componentes. Para completar la documentación de esta vista se pueden incluir los diagramas de componentes y de paquetes de UML.



Vista de Procesos (Process View): En esta vista se tratan los aspectos dinámicos del sistema, muestra los procesos que hay y la forma en la que se comunican entre ellos. Se enfoca en el comportamiento del sistema en ejecución. La vista considera aspectos de concurrencia, distribución, rendimiento, escalabilidad, etc. Para completar la documentación de esta vista se puede incluir el diagrama de actividad de UML.



Vista Física (Phisical View): En esta vista se muestra desde la perspectiva de un ingeniero de sistemas todos los componentes físicos del sistema, así como las conexiones físicas entre esos componentes que conforman la solución (incluyendo los servicios). Para completar la documentación de esta vista se puede incluir el diagrama de despliegue de UML.



“+1” Vista de Escenarios (Scenarios): Esta vista va a ser representada por los casos de uso del software a desarrollar y va a tener la función de unir y relacionar las otras 4 vistas, esto quiere decir que desde un caso de uso podemos ver cómo se van ligando las otras 4 vistas, con lo que tendremos una trazabilidad de componentes, clases, equipos, paquetes, etc, para realizar cada caso de uso. Para completar la documentación de esta vista se pueden incluir los diagramas de casos de uso de UML. Los escenarios describen secuencias de interacciones entre objetos y entre procesos. Se utilizan para identificar y validar el diseño de arquitectura. También sirven como punto de partida para pruebas de un prototipo de arquitectura.

Nota: Hay que dejar claro que Kruchten no dice de qué manera se ha de documentar cada vista; sino que es lo que hay que documentar en cada vista, es decir que cuando se diga que la vista lógica se puede documentar de forma gráfica con un diagrama de clases de UML, no quiere decir que esa vista se tenga que documentar con ese diagrama, sino que ese diagrama (por sus características) puede documentar esa vista.

Bibliografía Juan Ignacio Recofsky. (2019). Modelo de Arquitectura "4+1". Recuperado el 23 de septiembre del 2020, de Platzi Sitio web: https://platzi.com/tutoriales/1248-pro-arquitectura/4142-modelo-de-arquitectura-41/ Ricardo Moya. (2012). Modelo “4+1” vistas de Kruchten (para Dummies). Recuperado el 24 de septiembre del 2020, de Jarroba Sitio web: https://jarroba.com/modelo-41-vistas-de-kruchten-para-dummies/ Anahi Morales Calderón. (2017). El modelo de vistas 4+1 en un caso de arquitectura de software. Recuperado el 23 de septiembre del 2020, de Calameo Sitio web: https://es.calameo.com/read/004591649d409f82fc767...


Similar Free PDFs