Embed Size (px)
Citation preview
2.5 DISEÑO ARQUITECTONICO
MODULO II
Ingeniería de Software INF - 163
Resumen preparado por Miguel Cotaña 1
18/10/2012
Los requerimientos no determinan del
todo la arquitectura, más bien es el
resultado de influencias en los
ambientes técnicos, sociales y del
negocio.
Llamaremos a este ciclo de
influencias, del ambiente a la
arquitectura y de la arquitectura al
ambiente como “El Ciclo de la
Arquitectura de Negocios”
Architecture Business Cycle - ABC
2
3
arquitecto
gerente del
proyecto
líder de
mercadeo
usuario
final
soporte
aplicativo
cliente
Bajo costo
Rendimiento
del equipo
Corto tiempo en mercado
Bajo costo; ventajas con
productos similares
Funcionalidad
Rendimiento
Seguridad
usabilidad
modificabilidad
Bajo costo y tiempo
de entrega, que no cambie
muy a menudo
Influencia de los participantes
4
El rol de un arquitecto de edificaciones y
un arquitecto de software parece
enfrentar los mismos retos…
5
Por lo que es claro, que se debe contar,
con un conjunto básico de habilidades y
conocimientos necesarios y suficientes
para ejercer este tipo de roles.
6
8
Cada escenario plantea retos,
condiciones y necesidades
diferentes!!!
10
Sale a relucir la siguiente pregunta:
Qué herramientas, personas,
presupuesto, conocimiento y tiempo
necesitamos para cada escenario???
11
Por supuesto…..
Podemos establecer, que todas las
consideraciones que se nos ocurran con
respecto a definir la ARQUITECTURA DE
EDIFICIOS, deberán ser tenidas en
cuenta también al momento de definir la
ARQUITECTURA DEL SOFTWARE.
12
13
Mansión Winchester
Qué tiene que ver esta historia con la
ARQUITECTURA DE SOFTWARE?
En el contexto del desarrollo de
software, es similar a la historia..
Cuando un desarrollador es asignado a
la tarea de mantener y evolucionar un
sistema heredado, cuya arquitectura
tiene fallas o no está documentado,
elige reconstruir partes o crear sus
propias rutas dentro del código…
14
15
16
17
El arquitecto de software es el encargado de
establecer a que nivel, con que estrategia, y que
herramientas son necesarias para realizar una
implementación que satisfaga requisitos
funcionales y no funcionales.
Un buen arquitecto debe estar en
capacidad de generar una especificación
coherente, para enfrentar un conjunto
de riesgos mucho mas reducido, que en
el caso de un arquitecto aprendiz.
Un arquitecto de edificaciones puede ser
bueno sin tener que haber pegado
jamás un ladrillo. Pero, no podemos
pensar lo mismo de un IS.
18
19
Al igual que ellos, los arquitectos de
software usan modelos que representan
las especificaciones y necesidades
técnicas de los sistemas
La construcción de estos artefactos, en
ambos contextos requiere de
herramientas, habilidades y
conocimientos, y servirá como guía en
el proceso de construcción:
De forma global;
Como visión completa;
Parcialmente;
Específicamente;
Con alto nivel de detalle. 20
21
Cualidades de la Arquitectura
Procesos
Representación
de la arquitectura
Qué? Por qué?
Para qué? Quién?
Características
Del Sistema
Arquitectura Requerimientos
S/W
Atributos de
Calidad del sistema
Satisface
Restringe
Organización
Arquitecto
Habilidades
Stakeholders
Define roles
Produce
Analiza
Defines Tecnología
Elementos relacionados con la arquitectura
Clements define:
“La AS es una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones.”
¿Qué es la arquitectura?
22
La arquitectura no es el software
operativo. Es una representación que
permite que un IS:
1) Analice la efectividad del diseño para
cumplir con los requisitos establecidos;
2) Considere opciones arquitectónicas en
una etapa en que aún resulta
relativamente fácil hacer cambios al
diseño:
3) Reduzca los riegos asociados con la
construcción del software. 23
En el contexto del diseño arquitectónico,
un componente de software es algo tan
simple como un módulo del programa o
una clase orientada a objetos, pero
también se extiende para incluir bases
de datos y middleware que permita
configurar una red de clientes y
servidores.
24
Ser producto de un arquitecto o un pequeño grupo
de arquitectos con un líder definido;
Estar bien documentada, con al menos una vista
dinámica y una estática, utilizando notación que los
stakeholders puedan entender fácilmente;
Ser evaluada y analizada con métricas cualitativas y
cuantitativas;
Presentar como implementación incremental,
mostrando primero la mínima funcionalidad y
después cómo puede ir creciendo;
Ser diseñada por arquitectos que cuentan con los
requerimientos funcionales y no funcionales del
sistema
¿Qué hace buena a una arquitectura?
25
Las representaciones de la
arquitectura del software permiten la
comunicación entre todas las partes
interesadas en el desarrollo de un
sistema de cómputo;
La arquitectura destaca las
decisiones iniciales relacionadas con el
diseño que tendrán un impacto en
todo el trabajo de la IS;
¿Por qué es importante la arquitectura?
26
La arquitectura “constituye un
modelo relativamente pequeño e
intelectualmente comprensible de
cómo está estructurado el sistema y
cómo trabajan juntos sus
componentes”.
El modelo de diseño y los patrones
arquitectónicos que contiene son
transferibles. Es decir, los estilos y
patrones arquitectónicos se aplican al
diseño de otros sistemas 27
…. Los diagramas a través de los cuales
se representa el diseño y distribución
del software, pueden mostrar diferentes
vistas de un mismo sistema y de las
condiciones que existen en el entorno
donde se despliega.
28
29
30
1
: IU-1 :
G
r
o
: 1:
2: 3:
4
()
: :
G
r
o
: 1:
2: 3: 4
()
VISTA DEL MODELO DE CASOS DE USO VISTA DEL MODELO DEL DOMINIO /
VISTA DEL DIAGRAMA DE CLASES
VISTA DEL MODELO DEL ANÁLISIS VISTA DEL MODELO DEL DISEÑO
+ VISTAS DEL MODELO DE IMPLEMENTACIÓN Y PRUEBAS
SON VISTAS DE LOS MODELOS (NO MODELOS COMPLETOS).
SÓLO APARECEN LOS QUE CORRESPONDEN
A CASOS DE USOS CRÍTICOS
Taxonomía de estilos arquitectónicos
31
Estilos de Flujo de Datos
Tubería y filtros
Estilos Centrados en Datos
Arquitecturas de Pizarra o Repositorio
Estilos de Llamada y Retorno
Model-View-Controller (MVC)
Arquitecturas en Capas
Arquitecturas Orientadas a Objetos
Arquitecturas Basadas en Componentes
Estilos Derivados
C2
GenVoca
REST
Estilos de Código Móvil
Arquitectura de Máquinas Virtuales
Estilos heterogéneos
Sistemas de control de procesos
Arquitecturas Basadas en Atributos
Estilos Peer-to-Peer
Arquitecturas Basadas en Eventos
Arquitecturas Orientadas a Servicios (SOA)
Arquitecturas Basadas en Recursos
