Mapeo entre el modelo de vista arquitectónica 4 + 1 y UML

Estoy un poco confundido acerca de cómo el modelo de vista arquitectónica 4 + 1 se asigna a UML.

Wikipedia ofrece el siguiente mapeo:

• Vista lógica: diagrama de clase, diagrama de comunicación, diagrama de secuencia.
• Vista de desarrollo: diagrama de componentes, diagrama de paquete
• Vista de proceso: diagrama de actividad
• Vista física: diagrama de implementación
• Escenarios: diagrama de caso de uso

El papel en papel de las construcciones de diagramas de secuencia UML en Object Lifecycle Concept ofrece la siguiente asignación:

• Vista lógica (diagrama de clase (CD), diagrama de objeto (OD), diagrama de secuencia (SD), diagrama de colaboración (COD), diagrama de diagrama de estado (SCD), diagrama de actividad (AD))
• Vista de desarrollo (diagrama de paquete, diagrama de componentes),
• Vista de proceso (diagrama de caso de uso, CD, OD, SD, COD, SCD, AD),
• Vista física (diagrama de implementación), y
• Vista de caso de uso (diagrama de caso de uso, OD, SD, COD, SCD, AD) que combina los cuatro mencionados anteriormente.

La página web UML 4 + 1 View Materials presenta la siguiente asignación:

Finalmente, el documento técnico Aplicación de arquitectura de vista 4 + 1 con UML 2 ofrece otra asignación:

• Diagramas de clase de vista lógica , diagramas de objetos, diagramas de estado y estructuras compuestas.
• Vista de proceso diagramas de secuencia, diagramas de comunicación, diagramas de actividad, diagramas de tiempo, diagramas de visión general de interacción
• Vista de desarrollo diagramas de componentes
• Diagrama de despliegue de vista física
• Vista de caso de uso diagrama de caso de uso, diagramas de actividad

Estoy seguro de que una búsqueda más profunda también revelará otras asignaciones.

Si bien varias personas generalmente tienen diferentes perspectivas, no veo por qué este es el caso aquí. Especialmente, cada diagrama UML describe el sistema desde un aspecto particular. Entonces, por ejemplo, ¿por qué un "diagrama de secuencia" se considera que describe la "vista lógica" del sistema por un autor, mientras que otro autor considera que describe la "vista de proceso"?

¿Podrías ayudarme a aclarar la confusión?

Aunque generalmente estoy de acuerdo con la respuesta de Bart van Ingen Schenau , creo que algunos puntos necesitan una elaboración adicional.

La ventaja del modelo de vista 4 + 1 es que asigna a las partes interesadas el tipo de información que necesitan, sin requerir que se utilicen anotaciones de modelado específicas. El énfasis está en asegurar que todos los grupos tengan la información para comprender el sistema y continuar haciendo su trabajo.

El Modelo de Arquitectura de Software 4 + 1 View se describió en el documento Architectural Blueprints de Philippe Kruchten - El Modelo de Arquitectura de Software "4 + 1" View que se publicó originalmente en IEEE Software (noviembre de 1995). Esta publicación no hace referencias específicas a UML. De hecho, el documento utiliza la notación Booch para la vista lógica, extensiones a la notación Booch para la vista de proceso y vista de desarrollo, llama al uso de "varias formas" de desarrollar una vista física y una nueva notación para escenarios.

En lugar de intentar mapear cada una de las vistas a tipos particulares de diagramas, considere quién es el público objetivo de cada vista y qué información necesitan. Sabiendo eso, mire varios tipos de modelos y cuáles proporcionan la información requerida.

La vista lógica está diseñada para abordar las inquietudes del usuario final sobre garantizar que el sistema capture toda su funcionalidad deseada. En un sistema orientado a objetos, esto a menudo es a nivel de clase. En sistemas complejos, es posible que necesite una vista de paquete y descomponer los paquetes en múltiples diagramas de clases. En otros paradigmas, puede estar interesado en representar módulos y las funciones que proporcionan. El resultado final debe ser una asignación de la funcionalidad requerida a los componentes que proporcionan esa funcionalidad.

La vista de proceso está diseñada para personas que diseñan todo el sistema y luego integran los subsistemas o el sistema en un sistema de sistemas. Esta vista muestra las tareas y procesos que tiene el sistema, las interfaces con el mundo exterior y / o entre los componentes dentro del sistema, los mensajes enviados y recibidos, y cómo se están abordando el rendimiento, la disponibilidad, la tolerancia a fallas y la integridad.

La vista de desarrollo es principalmente para desarrolladores que construirán los módulos y los subsistemas. Debe mostrar las dependencias y relaciones entre módulos, cómo se organizan, reutilizan y portabilidad.

La vista física es principalmente para los diseñadores y administradores de sistemas que necesitan comprender las ubicaciones físicas del software, las conexiones físicas entre nodos, la implementación e instalación y la escalabilidad.

Finalmente, los escenarios ayudan a capturar los requisitos para que todos los interesados ​​comprendan cómo se pretende utilizar el sistema.

Una vez que comprenda lo que se supone que debe proporcionar cada vista, puede elegir qué notaciones de modelado usar y con qué nivel de detalle se requiere. El último párrafo de Bart es especialmente cierto: puede mostrar varios niveles de detalles en sus modelos UML centrándose en elementos de diseño particulares o combinando varios tipos de diagramas en un conjunto. Además, es posible que desee considerar ir más allá de UML a otras notaciones de modelado para describir mejor la arquitectura de su sistema: SysML , modelado de relación de entidad o IDEF .

La razón por la que no puede encontrar un mapeo uno a uno entre las vistas del modelo arquitectónico 4 + 1 y los diversos diagramas UML es porque dicho mapeo no existe.

Lo que todos esos autores intentan decir con sus "asignaciones" es que para cada vista, hay un conjunto diferente de diagramas UML que pueden ser útiles para transmitir la información que desea contar en esa vista.

Además, algunos diagramas UML pueden usarse de diferentes maneras, enfatizando diferentes elementos en el diagrama, lo que los hace útiles para múltiples vistas. Pero incluso si se puede usar un tipo de diagrama UML en varias vistas, dibujaría un diagrama diferente (o conjunto de diagramas) para cada vista.

Aunque estoy de acuerdo con el enfoque de respuestas de Thomas Owens para satisfacer las necesidades de sus usuarios finales, una cosa que no se menciona es que la razón por la cual la definición original de "4 + 1 View Model Architecture" de Kruchten no hace ninguna Las referencias específicas a UML se deben a que el artículo fue escrito en 1995 (como dice la respuesta), pero UML no fue realmente adoptado como estándar hasta 1997 .

El uso continuo de la notación Booch en el artículo sugiere que relacionar cada una de las vistas de los modelos con un diagrama UML específico podría ser apropiado, ya que Grady Booch fue una de las personas involucradas en el desarrollo de UML.

Es por esto que tantos autores diferentes consideran que diferentes diagramas UML son aplicables a cada vista, ya que múltiples diagramas UML podrían considerarse en cierta cantidad de "abstracciones" de la notación Booch en la que se basa la definición original del modelo 4 + 1. para representar cada vista.

Espero que esto aclare las cosas un poco más para cualquiera que esté investigando esto.

¿Todavía usa la videograbadora que compró en 1995? 4 + 1 era aplicable en aquel entonces cuando el software estaba en su infancia. Pero incluso entonces, nadie usó más de 2 o 3 "vistas". En los últimos 20 años, la ingeniería de software cambió. Hoy en día, el alcance / contexto y conceptual y lógico y físico y ... están todos diferenciados. Se deben integrar muchas soluciones COTS, etc. Hoy, estamos hablando de mapas de paisajes, realizaciones de servicios y docenas de otras vistas y puntos de vista. La mejor manera de verlo es a través de un marco de taxonomía simple como Zachman: 6 vistas y 6 puntos de vista. Deja que ese sea tu punto de partida. 6 puntos de vista son: conceptual conceptual o lógica de negocios o sistema físico o entrega de tecnología o artefactos que funcionan en la empresa

6 puntos de vista son: datos o qué función o cómo red o dónde las personas o quién tiempo o cuándo motivación o por qué

Veamos un ejemplo. Si solo nos interesan los datos, comenzaremos con la vista de alcance y diremos: "Nuestro alcance es CRM". En la vista conceptual para el punto de vista de datos, presentaremos un modelo semántico para CRM. El modelo será conceptual, conceptos de información comercial en lugar de objetos de datos. A continuación, en la vista lógica, produciremos un modelo de datos lógicos a partir de nuestro modelo conceptual de CRM. Podemos usar la metodología ER para producir un modelo de datos lógico. Luego, en la vista física, produciremos un modelo de datos físicos. Aquí, definiremos tipos de datos concretos para la plataforma db de nuestra elección, índices, etc. Finalmente, en la vista de entrega tendremos nuestro script DDL, mientras que en la vista empresarial en funcionamiento tendremos un archivo binario implementado en algún servidor de base de datos y mapeado en estructuras de datos internos del proveedor de DBMs. Repetimos esto para cada punto de vista o columna. Además, si hay más de una parte interesada, crearemos más de un modelo para cada combinación de punto de vista / vista. Ahora que tiene esta taxonomía en su lugar, puede definir sus propios puntos de vista y vistas y alinearlos en esta taxonomía. Por ejemplo, para las iniciativas a nivel empresarial, los siguientes puntos de vista son importantes: cooperación de actores comportamiento de la aplicación cooperación de la aplicación estructura de la aplicación uso de la aplicación función de negocio proceso de negocio proceso de negocio implementación y despliegue de la cooperación estructura de información uso de la infraestructura uso de la infraestructura panorama del paisaje descripción general del servicio de la organización en capas, etc. Ahora que tiene esta taxonomía en su lugar, puede definir sus propios puntos de vista y vistas y alinearlos en esta taxonomía. Por ejemplo, para las iniciativas a nivel empresarial, los siguientes puntos de vista son importantes: cooperación de actores comportamiento de la aplicación cooperación de la aplicación estructura de la aplicación uso de la aplicación función de negocio proceso de negocio proceso de negocio implementación y despliegue de la cooperación estructura de información uso de la infraestructura uso de la infraestructura panorama del paisaje descripción general del servicio de la organización en capas, etc. Ahora que tiene esta taxonomía en su lugar, puede definir sus propios puntos de vista y vistas y alinearlos en esta taxonomía. Por ejemplo, para las iniciativas a nivel empresarial, los siguientes puntos de vista son importantes: cooperación de actores comportamiento de la aplicación cooperación de la aplicación estructura de la aplicación uso de la aplicación función de negocio proceso de negocio proceso de negocio implementación y despliegue de la cooperación estructura de información uso de la infraestructura uso de la infraestructura panorama del paisaje descripción general del servicio de la organización en capas, etc.

Krutchen's 4 + 1 no podría satisfacer todas estas necesidades