Introduccion a Vistas (sin estilo)

Vistas
Gestionando la complejidad
Agenda
• Vistas.
• Vistas y stakeholders.
• Documentando una arquitectura de software: rules of the
thumb.
• Clasificaciones de vistas.
• Estilos.
• Viewtypes y estilos.
Vistas
• La descripción de un sistema complejo no es
unidimensional.
• Surgen de la agrupación de elementos arquitectónicos
en “tipos”.
• Relevancia: depende del propósito. Por ejemplo:
–
–
–
–
–
enunciar la misión de implementación,
análisis de atributos de calidad,
generación automática de código,
planificación,
etc.
Vistas
• Las vistas exponen atributos de calidad en diferente grado.
Ejemplos:
– Vista modular: portabilidad…
– Vista de deployment: performace, confiabilidad…
• Reflejan decisiones arquitectónicas.
• Enfatizan aspectos e ignoran otros para que el problema sea
abordable.
• Es clave saber cuáles son las vistas relevantes y vincularlas.
• Ninguna vista es “LA” arquitectura.
Vistas y stackeholders
• La metáfora de David Garlan
These views are needed
by the cardiologist…
I do bones,
not hearts.
…but will these views work
for the orthopedist?
Alternando caracteres:
Module View
Alternar mayúsculas con minúsculas a
partir de un stream de caracteres
“sofTWareArchitecture” =>
“SoFtWaReArCiTeCtUrE”
main
main
split
split
lower
lower
upper
upper
merge
merge
Referencias
config
config
input/output
input/output
Modulo
Usos
Modularización en función del a relación de uso
Alternando caracteres:
C&C View
lower
lower
split
split
merge
merge
upper
upper
Referencias
Filter
Componentes y Conectores
(Pipe & Filter)
Pipe
Binding
Documentando una arquitectura
• ¿Qué vista documentar?
• Los intereses/preocupaciones (concerns) de
los diferentes stakeholders.
• Motivación: uso de la documentación.
• Enfatizar algunos aspectos en una vista y no
enfatizar o ignorar otros que no son de
incumbencia para mí (mi labor).
Reglas de Documentación
•
•
•
•
Respetar el punto de vista del lector.
Evitar repetición innecesaria.
Evitar ambigüedad.
Usar esquemas estándar para organizar la
información.
• Registrar “rationale”.
• Mantenerla actualizada (pero no en situaciones
de inestabilidad). Pensar en automatizar la
generación de ciertas vistas.
• Revisar la documentación con usuarios
representativos antes de su lanzamiento.
Ambigüedad: el caso de las
flechas
C1
C1
C2
C2
• C1 invoca a C2: C1 llama a C2, C1 le pasa datos a C2?, C1 obtiene
un resultado de C2?, C1 causa que C2 se “cargue”?, C2 no puede
ejecutar hasta que C1 ejecute?, C1 tiene que esperar que C2
termine?
• Si tengo que mostrar flujo de datos: uso dos flechas?, uso una
flecha con dos cabezas?, y quién empieza la interacción?, y si son
pares?
• Y si la situación es más complicada: protocolo de invocación con
múltiples llamados, timeouts, callbacks?, etc.
ABC de la documentación del
paquete de vistas
• Introducción y guía.
• Información sobre interrelación entre vistas.
• Restricciones y rationale de la arquitectura como
un todo.
• Información sobre cómo mantener el paquete.
ABC de la documentación de
Vistas
• Representación principal de los elementos constitutivos
y sus relaciones (usualmente, gráfica).
• Catálogo de elementos y atributos.
• Especificación de interfaces y comportamiento.
• Variabilidad esperada (mecanismos de tailoring).
• Rationale.
Clasificaciones de vistas
Gestionando la complejidad
David Parnas (´74)
– Estructura de módulos (asignación de
trabajo, es parte de o comparte el mismo
secreto que).
– Estructura de uso (programas, depende de
la corrección de).
– Estructura de procesos (procesos, brinda
trabajo computacional a).
Perry y Wolf (´94)
• Reconocen la necesidad de vistas que
enfatizan ciertos aspectos arquitectónicos
útiles para distintas audiencias o para
diferentes propósitos.
Kruchten (´95)
• Enfoque 4 + 1
Kruchten (´95)
• Vista lógica: requerimientos de comportamiento, mecanismos
comunes de diseño (basada en diagramas de objetos y clases).
• Vista de procesos: distribución, integridad, tolerancia a fallas
(basada en describir una red lógica de programas que se
comunican).
• Vista de desarrollo: reuso, portabilidad, asignación de
requerimientos y trabajo de equipos. Organización del software en
el ambiente de desarrollo.
• Vista física: disponibilidad, confiabilidad, performance,
escalabilidad. Mapea elementos de las otras vistas a nodos de
procesamiento.
Siemens Corporate Research (´95)
• Vista conceptual: principales elementos de
diseño y su interrelación.
• Vista de módulos: estructura funcional y de
capas.
• Vista de ejecución: estructura dinámica.
• Vista de código: organización de código fuente,
binarios y bibliotecas en el ambiente de
desarrollo.
Libro: “Software Systems
Architecture”
• Vista funcional
• Vista de información
• Vista de concurrencia
• Vista de desarrollo
• Vista de deployment
• Vista operacional
SEI (´02): Racionalización de
Vistas
• Categorizan las vistas en “ViewTypes”.
• Viewtypes: definen los tipos de elementos
y lo tipos de relaciones usados para una
descripción desde una perspectiva
particular
SEI (´02): Racionalización de
Vistas
• ViewType Modular: ¿Cómo está el sistema estructurado
como conjunto de unidades de implementación?
• ViewType Componente y Conector: … como conjunto
de elementos que tienen comportamiento e interacción
en tiempo de ejecución.
• ViewType Asignación: ¿Cómo se relaciona el software
con elementos que no son software?
Estilos
• Formas recurrentes de estructurar o documentar un
sistema
– cliente-servidor, capas, datos compartidos, pipe&filter, publishsubscribe
• En sí mismos, tiene propiedades que los hacen
interesantes y útiles por ser soluciones abstractas para
alcanzar ciertos requerimientos de calidad.
• Se pueden pensar como especializaciones de tipos de
elementos y relaciones. Formas en las que un viewtype
se manifiesta
– capas para el viewtype modular, publish-subscribe para el C&C,
etc.
Estilos
Gestionando la complejidad
Estilos
• Hay que explicitar los estilos usados en la
documentación (restricciones y propiedades que
imparte).
• Un estilo puede ser sólo una forma de encarar la
documentación de una vista: despliegue,
descomposición, uso, etc.
• Pero otros se pueden usar si realmente el sistema es
diseñado siguiéndolos: capas, procesos que se
comunican, cliente servidor, etc.
Estilos
• Diferentes partes del sistema pueden
tener diferentes estilos:
– Áreas diferentes.
– Un elemento tiene un estilo interno diferente
al del contexto.
– Hay distintas perspectivas para el mismo
sistema.
Estilos de Viewtypes
• Viewtype Modular:
– Descomposición
– Usos
– Generalización
– En capas
Estilos de Viewtypes
• Viewtype Componente-y-Conector (C&C):
– Pipe-and-filter
– Shared-data
– Publish-subscribe
– Client-server
– Peer-to-peer
– Communicating-processes
Estilos de Viewtypes
• Viewtype Asignación:
– Deployment
– Implementation
– Work assigment
Módulos vs. Componentes
• Módulos: entidad en tiempo de diseño.
Enfatiza en encapsulamiento: “information
hiding” e interfaces.
• Componentes: tienen entidad en tiempo
de ejecución y de despliegue.
Alternando caracteres:
Module View
Alternar mayúsculas con minúsculas a
partir de un stream de caracteres
“sofTWareArchitecture” =>
“SoFtWaReArCiTeCtUrE”
main
main
split
split
lower
lower
upper
upper
merge
merge
Referencias
config
config
input/output
input/output
Modulo
Usos
Modularización en función del a relación de uso
Alternando caracteres:
C&C View
lower
lower
split
split
merge
merge
upper
upper
Referencias
Filter
Componentes y Conectores
(Pipe & Filter)
Pipe
Binding