Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Modelo de Arquitectura 4+1

Introducción y conceptualización general del modelo de arquitectura 4+1
by

Eduardo San Martín

on 10 October 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Modelo de Arquitectura 4+1

Modelo de Arquitectura
4+1

En que consiste este modelo?
Primero vamos a definir que es una vista, según Pilippe (Philipe) Kruchten “Una vista es una presentación de un modelo, la cual es una descripción completa de un sistema desde una particular perspectiva”.
entonces una vista es la descripción de un objeto desde un punto de vista específico
Entonces, para hacer un diseño completo de la Arquitectura de Software debemos documentar nuestro sistema en diferentes Vistas o Ángulos, aquí es donde viene el uso del modelo 4 + 1 de Pilippe Kruchten.
Vista Lógica
Vista de Despliegue o Desarrollo
Vista de Proceso
Vista Física
Vista +1 o de Escenarios
En la Vista Lógica hablamos principalmente de los requerimientos funcionales del sistema y de lo que el sistema debe de hacer, las funciones y servicios que se han definido.
Nos vamos a enfocar a lo que hemos definido como dominio de la aplicación, lo que son las clases y objetos principales que formaran el corazón o "core" de nuestra aplicación.
Esta vista la vamos a complementar con los diagramas UML:
Diagrama de Clases
Diagrama de Paquetes
En la Vista de Despliegue o Vista de Desarrollo se va a mostrar principalmente como está dividido nuestro sistema de software en componentes, y muestra las dependencias entre estos componentes.
También va a mostrar la organización y las dependencias entre el conjunto de componentes, y como se comunican entre ellos.
Esta vista la vamos a complementar con 2 diagramas UML:
Diagrama de Componentes
Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes.
Por ultimo tenemos la Vista +1 o Vista de Escenarios, esta vista va a ser representada por los casos de uso, que nos van a ayudar a unir las otras cuatro vistas, así desde un caso de uso podemos ver cómo se van ligando las otras cuatro vistas, con esto tenemos una trazabilidad de componentes, clases, equipo, paquetes, etc., para realización cada caso de uso.
Esta vista la vamos a complementar con 1 diagramas UML:
Diagrama de Casos de uso
En la Vista de Procesos representamos los flujos de trabajo paso a paso de negocio y operacionales de los componentes que conforman el sistema.
También va a mostrar algunos de los requisitos no funciónales, como son ejecución, disponibilidad, tolerancia a fallas, integridad, seguridad, confiabilidad entre otros.
Esta vista la vamos a complementar con 1 diagramas UML:
Diagrama de Actividad
En la Vista Física representamos como están distribuidos los componentes entre los distintos equipos que conforman la solución incluyendo los servicios.
Los elementos definidos en la vista lógica se mapean a componentes de software o de hardware.
Esta vista la vamos a complementar con 1 diagramas UML:
Diagrama de Depolyment
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.
Si bien el modelo no es una metodología, se "sugiere" un método de trabajo. Parece lógico que la vista de
escenarios
o casos de uso sea la de
i
nicio y que de ahí se pase a la
vista lógica
. Desde la vista lógica afrontaremos la de
desarrollo(Despliegue) y procesos
, una vez que tenemos por ejemplo las clases definiremos maneras de agruparlas y modos de ejecución. Finalmente,

concluir en la
vista física
. Todo ello, obviamente, con sus correspondientes y típicas iteraciones.
Full transcript