Universidad Nacional Experimental de Caracas UNEXCA Programa Nacional de Formación Ingeniería Informática PNFI Unidad curricular Ingeniería del software II - Código ISC339 Trimestre 2 - Tema 4 Contenido: definición, método, producto, pasos para hacer DAS, vista 4+1, Patrón MVC

1. DISEÑO ARQUITECTÓNICO
DE SOFTWARE Docente: Magemyl Egaña
Ingeniería del software II
PNFI-UNEXCA

2. DEFINICIÓN DAS
El diseño arquitectónico del software DAS, define la
arquitectura, componentes, interfaces y otras
características de un sistema o componente de
este.
Es la etapa del proceso de ingeniería de software,
donde se expresa un nivel de abstracción mayor en
comparación al modelado de negocio y la
ingeniería de requisitos y esta directamente
relacionado con el desarrollo del sistema.
"La arquitectura de
software muestra
las estructuras de
un sistema,
compuestas de
elementos con
propiedades
visibles de forma
externa y las
relaciones que
existen entre
ellos”
Leonard Joel (Len) Bass."

3. MÉTODO Y PRODUCTO DAS
En el método "Blue Watch" de
Jonas Montilva (2004), se
denomina "Diseño Arquitectónico"
y es "la fase donde se elaborar un
diseño de la arquitectura de la
aplicación que sea apropiada a los
requisitos especificados y que
establezca los subsistemas de la
aplicación, los componentes de
cada subsistema, las conexiones
entre estos componentes y las
restricciones que regulan la
arquitectura.
01
El producto principal es el DAS o
Diseño de la Arquitectura del
Software, donde se describe la
arquitectura de la aplicación.
02

4. FASE 3:
DAS

5. Definición de las metas de diseño.
Identificación de subsistemas.
Descripción de vistas arquitectónicas.
Evaluación de la arquitectura.
01
02
03
04
PASOS PARA HACER DAS

6. DEFINICIÓN DE METAS DE
ARQUITECTURA
Determinar que
requisitos del ERS -
ECU se relacionan con
la arquitectura del
sistema.
Enumerar las posibles
metas de calidad de la
arquitectura del
sistema.
Seleccionar aquellas
metas de diseño que
sean factibles y
describir.
cada meta de diseño
01 02 03

7. IDENTIFICACIÓN DE
SUBSISTEMAS
Definir los criterios y/o
estilos arquitectónicos más
apropiados para dividir el
sistema
01
Dividir el sistema en
subsistemas usando los
criterios y/o estilos
seleccionados
02

8. DESCRIPCIÓN DE VISTAS
Elaborar la vista arquitectónica
de uso.
01
02
03
04
Elaborar la vista arquitectónica
lógica (estructural).
Elaborar la vista arquitectónica
de proceso (comportamiento).
Elaborar la vista arquitectónica
de desarrollo o implementación
(componentes)
05 Elaborar la vista arquitectónica
de despliegue (física)

9. Evaluación de
la Arquitectura
Seleccionar un método de
evaluación de arquitecturas
01
Aplicar el método para
evaluar la arquitectura
propuesta
02

10. VISTA
4+1
La arquitectura de software es considerada como el diseño de más alto
nivel de un sistema, luego de la realización del modelado del negocio y
la ingeniería de requisitos y una manera muy práctica y conocida de
representarla en a través del “Modelo de Vistas de Arquitectura 4+1”
un estándar creado en 1995 por el ingeniero canadiense Philippe
Kruchten para “describir la arquitectura de sistema de software,
basado en el uso de múltiples puntos de vistas concurrentes”; y que se
usa para estructurar y organizar el software en el entorno de desarrollo
a través de cuatros vista (lógica, proceso, desarrollo y física) y una vista
adicional de escenarios para unir las 4 vistas anteriores. La
arquitectura 4+1 es importante para identificar las soluciones sobre las
preocupaciones de cada uno de los involucrados en el proceso de
ingeniería de software.

11. VISTA
4+1
REF. vista de Kruchten

12. VISTAS ARQUITECTÓNICAS
1)Vista lógica: Representa lo que el sistema debe hacer y las funciones y servicios
que ofrece, proporcionando un modelo estático de las clases principales y sus
relaciones. Esta vista muestra la funcionalidad que el sistema proporcionará a los
usuarios finales a través del diagrama de clase, diagrama de comunicación y
diagrama de secuencia.
2)Vista de proceso: enfocado en el comportamiento del sistema, mostrando los
procesos y las tareas que hay en él y la forma en que se comunican entre ellos. Toma
en cuenta los aspectos dinámicos del sistema y algunos requisitos no funcionales
como rendimiento, concurrencia, distribución, escalabilidad, disponibilidad,
integridad del sistema, tolerancia a fallas. Se representa a través del diagrama de
actividad y el diagrama de estados.
3)Vista de desarrollo o despliegue: Modela la arquitectura desde la perspectiva del
programado y se ocupa de la gestión del software mostrando como está organizado
el código de la aplicación, en lenguaje de componentes, paquetes, librerías y la
dependencia entre ellos. Se representa a través del diagrama de componentes y
paquetes.

13. 4)Vista física o de distribución: muestra todos los
componentes físicos del sistema así como sus conectores
entre componentes que conforman la solución (incluyendo
servicios), es decir los procesadores, dispositivos y enlaces
en el ambiente operativo del sistema, apoyado en el
diagrama de despliegue.
5) Vista de escenarios: esta vista es representada a través de
los casos de uso y explica cómo funcionan todas las vistas
juntan, es decir une y relaciona las 4 vistas (lógica, proceso,
despliegue y física). Los escenarios describen secuencias de
interacciones entre objetos y entre procesos y ayudan a
validar el diseño de la arquitectura
VISTAS ARQUITECTÓNICAS

14. PATRÓN DE DISEÑO
MODELO-VISTA-CONTROLADOR
LMVC es un patrón de arquitectura, un modelo o guía que expresa cómo
organizar y estructurar los componentes de un software, sus
responsabilidades y las relaciones existentes entre cada uno de ellos.
Su nombre, MVC, parte de las iniciales de Modelo-Vista-Controlador (Model-
View Controller, en inglés), que son las capas o grupos de componentes en
los que se organizan las aplicaciones bajo este paradigma de programación.
Es a menudo considerado también un patrón de diseño de la capa de
presentación, pues define la forma en que se organizan los componentes de
presentación en sistemas distribuidos.
La arquitectura MVC propone, independientemente de las tecnologías o
entornos en los que se base el sistema a desarrollar, la separación de los
componentes de una aplicación en tres grupos (o capas) principales: el
modelo, la vista y el controlador, describiendo cómo se relacionarán entre
ellos para mantener una estructura organizada, limpia y con un acoplamiento
mínimo entre las distintas capas. FUENTE: JOSÉ MARÍA AGUILAR
HTTPS://WWW.CAMPUSMVP.ES/RECURSOS/POST/QUE-ES-EL-PATRON-MVC-
EN-PROGRAMACION-Y-POR-QUE-ES-UTIL.ASPX

15. El Controlador, tiene acceso bidireccional al Modelo, es
decir, será capaz tanto de actualizar su estado, invocando
por ejemplo métodos o acciones incluidos en su lógica
de negocio, como de consultar la información que sea
necesaria para completar sus tareas.
El Controlador es el encargado de seleccionar la Vista
más apropiada en función de la acción llevada a cabo por
el usuario, suministrándole toda la información que
necesite para componer la interfaz. Para pasar esta
información, el Controlador puede usar clases del
Modelo o clases específicamente diseñadas para ello,
denominadas View-Models, que contendrán toda la
información que la Vista necesite y mantendrá a ésta
aislada de los cambios en el Modelo. La responsabilidad
de la Vista, por tanto, se reduce a generar la interfaz
partiendo de los datos que le suministre el controlador.
01
02
03
En el diagrama, se muestran las acciones e información
procedentes del usuario que serán recogidas
exclusivamente por los Controladores. Ningún
componente de otra capa debe acceder a los datos
generados desde el cliente, de la misma forma que sólo
los componentes de la Vista estarán autorizados a
generar interfaces de usuario con las que enviar
información de retorno.
PATRÓN MVC

16. PREGUNTAS Y
RESPUESTAS