Ingeniera de Software II

Primer Cuatrimestre de 2008

Clase 4: Introduccin a las arquitecturas de software. Estilos arquitectnicos

Buenos Aires, 3 de Abril de 2008

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Analizando dibujitos

2
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Banco

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Google

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Marcapasos

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Mozilla

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Interfaz

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Reconocimiento de Voz

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Algunas analogas

Fuente: Virginia McAlester. A Field Guide to American Houses.

9
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Algunas analogas (cont.)

10
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Algunas analogas (cont.)

11
Ctedra de Ingeniera de Software II FCEN UBA, 2008
De los requerimientos a la implementacin

Requerimientos

Y ahora?
Un milagro ocurre
Cmo construimos un puente entre
los requerimientos y la implementacin?

Implementacin

12
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Arquitecturas de sistemas de software

La arquitectura de un sistema de software:

Define el sistema en trminos de componentes
e interaccin 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 ingeniera de software empiece a
asemejarse a otras disciplinas de la ingeniera.

13
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Analogas con la ingeniera civil (slo edificios)

Estilos arquitectnicos: colonial, victoriano, griego

Paradigmas de organizacin de sistemas de
software: pipes, layers, events

Conocimientos especficos para un estilo en

particular: crceles, fbricas automotrices,
hospitales, hoteles 5 estrellas.
Arquitecturas para un dominio especfico

14
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Por qu este tema es importante?

El mantenimiento de grandes sistemas suele llevar

ms del 60% del esfuerzo total

Un 50% del esfuerzo de los programadores de

mantenimiento se va en analizar y entender el
cdigo y la documentacin existente.

La arquitectura hace una diferencia.

La arquitectura posibilita o inhibe alcanzar los

requerimientos de calidad de un sistema.

15
Ctedra de Ingeniera de Software II FCEN UBA, 2008
La estructura de los sistemas

La arquitectura trata sobre la estructura de los

sistemas
Cmo el sistema se descompone en partes

Cmo esas partes interactan

Pero esto lleva a la pregunta: Qu tipos de

estructuras?
Del cdigo

Run-time

Del entorno de desarrollo

Work breakdown structures

Cada una de estas estructuras puede ser la base

para una vista arquitectnica (architectural view)
Histricamente el foco estuvo en vistas de cdigo

16
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Las definiciones ms aceptadas (Bass, Clements)

Arquitectura
La arquitectura de software de un programa o sistema de
computacin 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 <>
arquitectnico)
Los sistemas pueden tener ms de una estructura

Todo sistema de computacin con software tiene una arquitectura

El comportamiento de cada elemento es parte de la arquitectura

Estilo o patrn arquitectnico

Una descripcin de tipos de relaciones y elementos, junto con
restricciones sobre cmo deben usarse (ej. client server).

Arquitectura de referencia
Una divisin comn de funcionalidad mapeada a elementos que
cooperativamente implementan esa funcionalidad y flujos de datos
entre ellos.

17
Ctedra de Ingeniera 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?

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Arquitectura de software

Metfora

Sistema: una ciudad

Elementos: edificios, plazas, escuelas, iglesias,

edificios pblicos, etc.

Relaciones:sus calles, red cloacal, red de gas, red de

agua, puentes, etc.

Comportamiento: El transito segn el horario; el

consumo de luz, agua, gas, etc.

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Arquitectura de software

En una Arquitectura de Software

Sistema: una aplicacin

Elementos: sus componentes, archivos de

configuracin, etc.

Relaciones: relaciones de uso y dependencia entre

componentes

Comportamiento: Qu elementos entran en accin

en la ejecucin de una determinada funcionalidad?

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Implicancias

Definicin Implicancia

Una arquitectura de software

para un sistema es la La arquitectura define elementos
estructura o estructuras del de software (privado <>
sistema, la cual abarca sus arquitectnico)
elementos, su comportamiento
visible y las relaciones entre
ellos

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Implicancias

Definicin
Implicancia

Una arquitectura de software

para un sistema es la Los sistemas pueden tener ms de
estructura o estructuras del una estructura
sistema, la cual abarca sus
elementos, su comportamiento
visible y las relaciones entre
ellos

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Implicancias

Definicin Implicancia

Una arquitectura de software Todo sistema de computacin con

para un sistema es la software tiene una arquitectura
estructura o estructuras del
sistema, la cual abarca sus
elementos, su
comportamiento visible y las
relaciones entre ellos

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Implicancias

Definicin Implicancia

Una arquitectura de software

para un sistema es la El comportamiento de cada
estructura o estructuras del elemento es parte de la
sistema, la cual abarca sus arquitectura
elementos, su comportamiento
visible y las relaciones entre
ellos

Ctedra de Ingeniera de Software II FCEN UBA, 2008

Por qu es importante una arquitectura?

Comunicacin entre stakeholders

Decisiones tempranas de diseo

Define restricciones de implementacin

Afecta la estructura organizativa

Posibilita o inhibe atributos de calidad de un sistema

Facilita el razonamiento sobre cambios y su

implementacin
Permite estimaciones ms precisas

Abstraccin transferible de un sistema

Los sistemas pueden ser construidos a partir de
elementos externos
Menos es ms: es bueno restringir

Permite el desarrollo basado en templates

25
Ctedra de Ingeniera 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

organizacin de desarrollo

Las arquitecturas son influenciadas por la

experiencia y el background de los arquitectos

Las arquitecturas son influenciadas por el entorno

tcnico

Las arquitecturas afectan los factores que las

influencian

26
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Qu hace que una arquitectura sea buena?

Producto de un nico arquitecto o un pequeo grupo de

arquitectos con un claro lder (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 implementacin incremental

Mdulos bien definidos basados en el ocultamiento de la

informacin

Interfaz claramente definida

No dependiente de un nico producto comercial

Usa un grupo pequeo y claro de patrones de interaccin

27
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Taxonoma de estilos arquitectnicos

Data Flow Independent components

Batch Sequential
Event systems implicit
Pipes & filters invocation
Communicating Processes
Call and return
Main program / subroutines
Data Centered
Information hiding
Repository
ADT, objects Blackboard
Layered

Client Server
State Transition

28
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Propiedades de los estilos arquitectnicos

Un vocabulario para los elementos de diseo

Tipos de componentes y conectores

Por ejemplo: clases, invocaciones, pipes, clientes

Reglas de composicin
Un estilo tiene restricciones topolgicas que
determinan cmo se puede hacer la composicin de los
elementos
Por ejemplo: los elementos de un layer se pueden
comunicar slo con los del layer inferior

Semntica para esos elementos

Idealmente, criterios para la evaluacin de una

arquitectura o formas de analizarla; generacin de cdigo

Importante: un estilo arquitectnico no define la

funcionalidad de un sistema. Desde ese punto de vista es
algo abstracto.
29
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Beneficios de los estilos arquitectnicos

Reuso de diseos
Soluciones maduras aplicadas a problemas nuevos

Reuso de cdigo
Una parte importante del cdigo que implementa la
arquitectura puede pasarse de un sistema a otro

Comunicacin

Portabilidad

30
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Arquitecturas Heterogneas

Resultan de la combinacin 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 heterognea que incluya:
Layered

Repository

Independent components

Information hiding Objects

En sistemas medianos / grandes, es ms probable

que un estilo arquitectnico describa una parte de
un sistema que al sistema completo.

31
Ctedra de Ingeniera 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 travs de los

componentes hasta su destino final.

Los componentes son de run-time

Normalmente un programa controla la ejecucin de los

componentes (lenguaje de control)

Dos tipos
Batch sequential

Pipe and filter

32
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Batch Sequential

Cada paso se ejecuta hasta ser completado, y recin

despus puede comenzar el siguiente paso.

Usado en aplicaciones clsicas de procesamiento de datos

33
Ctedra de Ingeniera 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
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Pipes and filters Ventajas y Desventajas

Pros
Fcil de entender: la funcin del sistema es la
composicin de sus filtros
Facilidad de extensin reuso recambio de filtros

Posibilidad de ejecucin concurrente

Cons
Mentalidad batch, difcil para aplicaciones interactivas

El orden de los filtros puede ser complejo

Overhead de parsing y unparsing

Problemas con tamao de los buffers

Interesante: interfaces con XML, transformadas con XSL y

con uso de herramientas de integracin

Extensiones: Bounded Pipes, Typed Pipes

35
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Call and Return

El estilo dominante en la mayora de los sistemas

Programa principal y subrutinas

Programacin estructurada

Ventaja: concepto simple; desventajas: reuso limitado

a funciones / procedimientos, limitada flexibilidad

36
Ctedra de Ingeniera 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 cdigo llevada al

diseo

Information hiding: las decisiones de diseo que es

probable que cambien son ocultadas en un mdulo o un
conjunto pequeo de mdulos (Parnas, 1972).

37
Ctedra de Ingeniera 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, difcil de encontrar la

abstraccin correcta, puede implicar salteo de niveles

Useful systems

Basic Utilities

Core Level
38
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Client server

Una instancia de un estilo ms genrico: 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
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Componentes independientes

Son arquitecturas de procesos que se comunican a travs

del envo de mensajes

Componentes: procesos independientes

Conectores: envo de mensajes

Sincrnico o asincrnico

Sistemas de eventos - Invocacin implcita

Implcita Explcita

Ev1 Op2
C1 C1

Op1 Op1
C2 Manager C3

C3 C2
Op2

40
Ctedra de Ingeniera 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 invocacin no es determinstico

Ventajas
Se independiza la coordinacin

Facilita integracin y evolucin

Se pueden paralelizar invocaciones (performance)

Desventajas
Dificutad de testear

La indireccin puede afectar la performance

Intercambio de datos

41
Ctedra de Ingeniera 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 comunicacin est dada por esos datos compartidos.

Normalmente presentes en todo sistema de informacin

Dos tipos: blackboard y reposotorio (cada vez ms

ocultos en un esquema tipo layered)

42
Ctedra de Ingeniera 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 generacin

dinmica de nuevos estados y transiciones

Con posibilidad de asignar cdigo a ejecutarse al

ocurrir un evento

Posibilidad de usar una herramienta de Workflow

Necesario en algunos sistemas, como por ejemplo en

robtica

43
Ctedra de Ingeniera 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
proteccin trmica de los transbordadores espaciales de la
NASA.

El brazo mvil debe posicionar un plato con herramientas

(cmara e inyector de impermeabilizante) bajo cada uno
de los 17000 azulejos de proteccin trmica

Principales requerimientos:
Seguridad (safety):

1 El robot no debe daar fsicamente al operador

2 El robot no debe daar la superficie del

transbordador
3 El robot no debe realizar ningn movimiento si
el brazo est en una posicin desconocida o invlida
Funcionalidad:

El sistema debe saber en todo momento la posicin

del brazo
44
Ctedra de Ingeniera de Software II FCEN UBA, 2008
EEPS - Arquitectura

Componentes independientes comunicados por eventos

Orientada a componentes que aslan decisiones de diseo

information hiding

State Machine, que describe la posicin del robot

Arquitectura de referencia:

45
Ctedra de Ingeniera de Software II FCEN UBA, 2008
Caso de Estudio EEPS (cont.)
State Manager: mquina de
estados que conoce el estado
del robot.

Cinco procesos que corren en

forma independiente y se
comunican por mensajes
asincrnicos.

Information hiding para el

manejo de posiciones y del
detalle de las articulaciones

Divisin entre sensors y

actuators

46
Ctedra de Ingeniera de Software II FCEN UBA, 2008