Ingeniería de Software II - Universidad de Buenos Aires

Anuncio
Ingeniería de Software II
Primer Cuatrimestre de 2008
Clase 4: Introducción a las arquitecturas de software. Estilos arquitectónicos
Buenos Aires, 3 de Abril de 2008
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Analizando dibujitos…
2
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Banco
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Google
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Marcapasos
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Mozilla
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Interfaz
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Reconocimiento de Voz
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Algunas analogías
Fuente: Virginia McAlester. A Field Guide to American Houses.
9
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Algunas analogías (cont.)
10
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Algunas analogías (cont.)
11
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
De los requerimientos a la implementación
Requerimientos
Y ahora?
Un milagro ocurre
Cómo construimos un puente entre
los requerimientos y la implementación?
Implementación
12
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Arquitecturas de sistemas de software
La arquitectura de un sistema de software:
 Define el sistema en términos de componentes
e interacción entre ellos
 Muestra correspondencia entre requerimientos
y elementos del sistema construido
 Resuelve atributos de calidad en el nivel del
sistema, como escalabilidad, compatibilidad,
confiabilidad y performance.
Muchos piensan (pensamos) que los avances en
el tema de arquitecturas de software son un paso
clave para poder lograr el reuso a gran escala y
ayudar a que la ingeniería de software empiece a
asemejarse a otras disciplinas de la ingeniería.
13
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Analogías con la ingeniería civil (sólo edificios)
Estilos arquitectónicos: colonial, victoriano, griego
 Paradigmas de organización de sistemas de
software: pipes, layers, events
Conocimientos específicos para un estilo en
particular: cárceles, fábricas automotrices,
hospitales, hoteles 5 estrellas.
 Arquitecturas para un dominio específico
14
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
¿Por qué este tema es importante?
El mantenimiento de grandes sistemas suele llevar
más del 60% del esfuerzo total
Un 50% del esfuerzo de los programadores de
mantenimiento se va en analizar y entender el
código y la documentación existente.
La arquitectura hace una diferencia.
La arquitectura posibilita o inhibe alcanzar los
requerimientos de calidad de un sistema.
15
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
La estructura de los sistemas
La arquitectura trata sobre la estructura de los
sistemas
 Cómo el sistema se descompone en partes
 Cómo esas partes interactúan
Pero esto lleva a la pregunta: ¿Qué tipos de
estructuras?
 Del código
 Run-time
 Del entorno de desarrollo
 Work breakdown structures
Cada una de estas estructuras puede ser la base
para una vista arquitectónica (architectural view)
 Históricamente el foco estuvo en vistas de código
16
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Las definiciones más aceptadas (Bass, Clements)
 Arquitectura
 La arquitectura de software de un programa o sistema de
computación es la estructura o estructuras del sistema, que abarcan
elementos de software, las propiedades externamente visibles de
estos elementos y las relaciones entre ellos. Implicancias:
 La arquitectura define elementos de software (privado <>
arquitectónico)
 Los sistemas pueden tener más de una estructura
 Todo sistema de computación con software tiene una arquitectura
 El comportamiento de cada elemento es parte de la arquitectura
 Estilo o patrón arquitectónico
 Una descripción de tipos de relaciones y elementos, junto con
restricciones sobre cómo deben usarse (ej. “client server”).
 Arquitectura de referencia
 Una división común de funcionalidad mapeada a elementos que
cooperativamente implementan esa funcionalidad y flujos de datos
entre ellos.
17
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Arquitectura de software
 ¿Qué es un elemento?
 ¿Qué es el comportamiento?
 ¿Qué son la relaciones?
 ¿Qué es un sistema?
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Arquitectura de software
 Metáfora
 Sistema:
una ciudad
 Elementos:
edificios, plazas, escuelas, iglesias,
edificios públicos, etc.
 Relaciones:
sus calles, red cloacal, red de gas, red de
agua, puentes, etc.
 Comportamiento:
El transito según el horario; el
consumo de luz, agua, gas, etc.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Arquitectura de software
En una Arquitectura de Software
 Sistema:
una aplicación
 Elementos:
sus componentes, archivos de
configuración, etc.
 Relaciones:
componentes
relaciones de uso y dependencia entre
 Comportamiento:
¿Qué elementos entran en acción
en la ejecución de una determinada funcionalidad?
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Implicancias
Definición
“Una arquitectura de software
para un sistema es la
estructura o estructuras del
sistema, la cual abarca sus
elementos, su comportamiento
visible y las relaciones entre
ellos”
Implicancia
La arquitectura define elementos
de software (privado <>
arquitectónico)
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Implicancias
Definición
“Una arquitectura de software
para un sistema es la
estructura o estructuras del
sistema, la cual abarca sus
elementos, su comportamiento
visible y las relaciones entre
ellos”
Implicancia
Los sistemas pueden tener más de
una estructura
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Implicancias
Definición
“Una arquitectura de software
para un sistema es la
estructura o estructuras del
sistema, la cual abarca sus
elementos, su
comportamiento visible y las
relaciones entre ellos”
Implicancia
Todo sistema de computación con
software tiene una arquitectura
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Implicancias
Definición
“Una arquitectura de software
para un sistema es la
estructura o estructuras del
sistema, la cual abarca sus
elementos, su comportamiento
visible y las relaciones entre
ellos”
Implicancia
El comportamiento de cada
elemento es parte de la
arquitectura
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
¿Por qué es importante una arquitectura?
 Comunicación entre “stakeholders”
 Decisiones tempranas de diseño
 Define restricciones de implementación
 Afecta la estructura organizativa
 Posibilita o inhibe atributos de calidad de un sistema
 Facilita el razonamiento sobre cambios y su
implementación
 Permite estimaciones más precisas
 Abstracción transferible de un sistema
 Los sistemas pueden ser construidos a partir de
elementos externos
 Menos es más: es bueno restringir
 Permite el “desarrollo basado en templates”
25
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Algunas realidades sobre las arquitecturas
Las arquitecturas son influenciadas por los
“stakeholders” del sistema
Las arquitecturas son influenciadas por la
organización de desarrollo
Las arquitecturas son influenciadas por la
experiencia y el “background” de los arquitectos
Las arquitecturas son influenciadas por el entorno
técnico
Las arquitecturas afectan los factores que las
influencian
26
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
¿Qué hace que una arquitectura sea “buena”?
 Producto de un único arquitecto o un pequeño grupo de
arquitectos con un claro líder (Brooks, Mills y otros)
 El equipo de arquitectura debe contar con requerimientos
funcionales y atributos de calidad requeridos que sean claros
 La arquitectura debe estar documentada
 La arquitectura debe ser revisada por los “stakeholders”
 Debe ser evaluada cuantitativamente antes de que sea tarde
 Debe permitir una implementación incremental
 Módulos bien definidos basados en el ocultamiento de la
información
 Interfaz claramente definida
 No dependiente de un único producto comercial
 Usa un grupo pequeño y claro de patrones de interacción
27
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Taxonomía de estilos arquitectónicos
 Data Flow
 Batch Sequential
 Pipes & filters
Independent components


 Call and return
 Main program / subroutines
 Information hiding
 ADT, objects
 Layered
 Client Server

Event systems – implicit
invocation
Communicating Processes
Data – Centered
Repository
Blackboard
State Transition
28
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Propiedades de los estilos arquitectónicos
 Un vocabulario para los elementos de diseño
 Tipos de componentes y conectores
 Por ejemplo: clases, invocaciones, “pipes”, clientes
 Reglas de composición
 Un estilo tiene restricciones topológicas que
determinan cómo se puede hacer la composición de los
elementos
 Por ejemplo: los elementos de un “layer” se pueden
comunicar sólo con los del “layer” inferior
 Semántica para esos elementos
 Idealmente, criterios para la evaluación de una
arquitectura o formas de analizarla; generación de código
 Importante: un estilo arquitectónico no define la
funcionalidad de un sistema. Desde ese punto de vista es
algo “abstracto”.
29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Beneficios de los estilos arquitectónicos
 Reuso de diseños
 Soluciones maduras aplicadas a problemas nuevos
 Reuso de código
 Una parte importante del código que implementa la
arquitectura puede pasarse de un sistema a otro
 Comunicación
 Portabilidad
30
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Arquitecturas Heterogéneas
 Resultan de la combinación de distintos estilos
 Por ejemplo:
 Los componentes de un sistema “layered” pueden
tener una estructura interna que use otro estilo
 Una arquitectura hecha con J2EE probablemente
resulte en una arquitectura heterogénea que incluya:
 Layered
 Repository
 Independent components
 Information hiding  Objects
En sistemas medianos / grandes, es más probable
que un estilo arquitectónico describa una parte de
un sistema que al sistema completo.
31
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Arquitecturas tipo “Data – Flow”
 La estructura del sistema está basada en transformaciones
sucesivas a datos de input.
 Los datos entran al sistema y fluyen a través de los
componentes hasta su destino final.
 Los componentes son de run-time
 Normalmente un programa controla la ejecución de los
componentes (lenguaje de control)
 Dos tipos
 Batch sequential
 Pipe and filter
32
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Batch Sequential
 Cada paso se ejecuta hasta ser completado, y recién
después puede comenzar el siguiente paso.
 Usado en aplicaciones clásicas de procesamiento de datos
33
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Pipes and Filters
 Cada componente tiene inputs y outputs. Los
componentes leen “streams” de datos de su input y
producen streams de datos en sus outputs de forma
continua.
 Filters: componentes que ejecutan las transformaciones
 Pipes: son los conectores que pasan los streams de datos
de un filtro a otro
34
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Pipes and filters – Ventajas y Desventajas
 Pros
 Fácil de entender: la función del sistema es la
composición de sus filtros
 Facilidad de extensión – reuso – recambio de filtros
 Posibilidad de ejecución concurrente
 Cons
 “Mentalidad batch”, difícil para aplicaciones interactivas
 El orden de los filtros puede ser complejo
 Overhead de parsing y unparsing
 Problemas con tamaño de los buffers
 Interesante: interfaces con XML, transformadas con XSL y
con uso de herramientas de integración
 Extensiones: Bounded Pipes, Typed Pipes
35
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
“Call and Return”
 El estilo dominante en la mayoría de los sistemas
 Programa principal y subrutinas
 Programación estructurada
 Ventaja: concepto simple; desventajas: reuso limitado
a funciones / procedimientos, limitada flexibilidad
36
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Call and Return (cont.)
 Arquitecturas orientadas a objetos
 Information hiding
 Encapsulamiento
 Herencia, polimorfismo
 Ventajas: reuso a gran escala, todas las ventajas del
encapsulamiento (bien usado) y el information hiding,
correspondencia en los objetos del dominio con objetos
del mundo real.
 Desventaja principal: complejidad del código llevada al
diseño
 Information hiding: las decisiones de diseño que es
probable que cambien son ocultadas en un módulo o un
conjunto pequeño de módulos (Parnas, 1972).
37
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Layered
 Cada nivel provee servicios
 Oculta en nivel siguiente
 Provee servicios al nivel anterior
 En muchos casos el “bajar” de nivel implica acercarse al
hardware o software de base
 Los niveles superiores son “virtual machines”
 Ventajas: portabilidad, facilidad de cambios, reuso
 Desventajas: performance, difícil de encontrar la
abstracción correcta, puede implicar salteo de niveles
Useful systems
Basic Utilities
Core Level
38
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Client server
 Una instancia de un estilo más genérico: sistemas
distribuidos
 Los componentes son clientes (acceden a servicios) y
servidores (proveen servicios)
 Los servers no conocen la cantidad o identidad de los
clientes
 Los clientes saben la identidad de los servidores
 Los conectores son protocoles basados en RPC
 Distintos “flavors”
39
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Componentes independientes
 Son arquitecturas de procesos que se comunican a través
del envío de mensajes
 Componentes: procesos independientes
 Conectores: envío de mensajes
 Sincrónico o asincrónico
 Sistemas de eventos - Invocación implícita
Implícita
Ev1
C1
C2
C3
Explícita
Op2
C1
Op1
Op1
Manager
C3
C2
Op2
40
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Sistemas de eventos
 Modelo
 Componentes: procesos u objetos
 Las interfaces definen eventos que se pueden recibir
 Las interfaces definen eventos que se pueden anunciar
 Conexiones: “binding” de procedimientos a objetos
 Los componentes anuncian eventos
 Cuando se recibe un evento se ejecutan los procedimientos
 El orden de invocación no es determinístico
 Ventajas
 Se independiza la coordinación
 Facilita integración y evolución
 Se pueden paralelizar invocaciones (performance)
 Desventajas
 Dificutad de testear
 La indirección puede afectar la performance
 Intercambio de datos
41
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Arquitecturas centradas en datos
 Estructura de datos central (normalmente una base de
datos) y componentes que acceden a ella. Gran parte de
la comunicación está dada por esos datos compartidos.
 Normalmente presentes en todo sistema de información
 Dos tipos: blackboard y reposotorio (cada vez más
“ocultos” en un esquema tipo “layered”)
42
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
State transition
Generalmente un componente maneja la “maquina
de estados” del sistema completo o de una parte de
él.
Generalmente con posibilidad de generación
“dinámica” de nuevos estados y transiciones
Con posibilidad de asignar código a ejecutarse al
ocurrir un evento
Posibilidad de usar una herramienta de Workflow
Necesario en algunos sistemas, como por ejemplo en
robótica
43
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Caso de Estudio: EEPS – End Effector Positioning Sofware
 Uno de los subsistemas de software del “Tessellator”,
robot experimental para realizar mantenimiento en la
protección térmica de los transbordadores espaciales de la
NASA.
 El brazo móvil debe posicionar un plato con herramientas
(cámara e inyector de impermeabilizante) bajo cada uno
de los 17000 “azulejos” de protección térmica
 Principales requerimientos:
 Seguridad (“safety”):
 1 – El robot no debe dañar físicamente al operador
 2 – El robot no debe dañar la superficie del
transbordador
 3 – El robot no debe realizar ningún movimiento si
el brazo está en una posición desconocida o inválida
 Funcionalidad:
 El sistema debe saber en todo momento la posición
del brazo
44
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
EEPS - Arquitectura
 Componentes independientes comunicados por eventos
 Orientada a componentes que aíslan decisiones de diseño
“information hiding”
 “State Machine”, que describe la posición del robot
 Arquitectura de referencia:
45
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Caso de Estudio – EEPS (cont.)
State Manager: máquina de
estados que conoce el estado
del robot.
Cinco procesos que corren en
forma independiente y se
comunican por mensajes
asincrónicos.
“Information hiding” para el
manejo de posiciones y del
detalle de las articulaciones
División entre “sensors” y
“actuators”
46
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Descargar