Introduccin a la Ingeniera de

Software
Arquitectura de Software
2
Bibliografa
Software Engineering 7ed
Addison Wesley
Ian Sommerville
ocumenting Software Arc!itectures " #iews and Beyond
Addison$Wesley
%aul &lements et al'
Software Systems Arc!itecture " Wor(ing wit! sta(e!olders using
view)oints and )ers)ectives
Addison$Wesley
*ic( +o,ans(i y Eoin Woods
3
Arquitectura de Software
Es)ecificacin de +equerimientos del sistema -S+S.
Sistema instalado y funcionando
En este camino !ay muc!o )or
!acer'
/&omen,amos a )rogramar
)ara terminar lo antes )osible0
$ /&u1les seran los riesgos0
4
Arquitectura de Software
Es)ecificacin de +equerimientos del sistema -S+S.
Sistema instalado y funcionando
-
Arquitectura de Software
-
ise2o detallado
-
Im)lementacin
-
#erificacin
No es un
proceso en
cascada. No se
est definiendo
un proceso.
5
Arquitectura de Software
3os sistemas com)le4os est1n com)uestos de
subsistemas que interact5an ba4o el control de un
dise2o de sistema
Arquitectura de Software

3os subsistemas que com)onen el sistema6

las interfaces y

las reglas de interaccin entre ellos'

6
efinicin
A software arc!itecture for a system is t!e structure or
structures of t!e system6 w!ic! consist of elements6 t!eir
e7ternally visible )ro)erties6 and t!e relations!i)s among
t!em'
Documenting software architectures, views and beyond
7
Im)ortancia
#enta4as de dise2ar y documentar e7)lcitamente
una arquitectura de software8

&omunicacin entre sta(e!olders

ecisiones tem)ranas de dise2o

+euso a gran escala

Bass, et al, Software Architecture in
Practice 2ed.
Addison-Wesley.
8
/9u: Afecta y qu: la etermina0

3a arquitectura de software afecta la

%erformance

Seguridad -security y safety.

is)onibilidad

;antenibilidad

<

Entonces6 el estilo y estructura )articular elegido

)ara una a)licacin de)enden fuertemente de
los requerimientos no funcionales'
9
&onflictos entre Soluciones

El sistema debe ser =muy> )erformante y =muy>

mantenible

/&u1l es el conflicto al momento de elegir el

estilo arquitectnico0

/&mo se )uede solucionar0

Solucin de com)romiso

iferentes estilos )ara distintas )artes del sistema

10
/9u: tan ?1cil es ;odificarla0
Sears
EE@@
AB7 metros
%etronas
;alasia
CAB metros
Dai)ei EFE
&!ina
AFG metros
11
/9u: tan ?1cil es ;odificarla0
;e gustara que el
ascensor quedara del
otro lado
Estara brbaro que el
)uente estuviera BH
)isos m1s arriba6 la
vista sera me4or
12
/9u: tan ?1cil es ;odificarla0
Bur4 ubai6 otros metros m1s arriba6 Emiratos Irabes
13
A5n m1s &om)licado
14
%atrones de Software

%ro)sito

&om)artir una solucin )robada6

am)liamente a)licable

a un )roblema )articular de dise2o'

El )atrn se )resenta en una forma est1ndar que

)ermite que sea f1cilmente reutili,ado'

&inco )ie,as im)ortantes de un )atrn

*ombre

&onte7to

%roblema

Solucin

&onsecuencias -)ositivas y negativas.

15
Estilos6 %atrones e Idioms

3os )atrones de dise2o se agru)an en tres ti)os

Estilos arquitectnicos: Soluciones de organi,acin

a nivel del sistema

Patrones de diseo: Soluciones a )roblemas

detallados de dise2o de software

Idioms: Soluciones 5tiles )ara )roblemas es)ecficos

en alg5n lengua4e de )rogramacin
16
Estilos Arquitectnicos

@n estilo arquitectnico

e7)resa un esquema de organi,acin estructural )ara

sistemas de software'

%rovee un con4unto de ti)os de elementos

)redefinidos6

es)ecifica sus res)onsabilidades e

incluye reglas y guas )ara organi,ar las relaciones

entre ellos
Capa n
Capa n - 1
Capa
Capa 1
!
!
!
17
%atrones de ise2o

@n patrn de diseo

)rovee un esquema )ara refinar los elementos de un

sistema de software o las relaciones entre ellos'

escribe una estructura recurrente de elementos de

dise2o interconectados que soluciona un )roblema
general de dise2o dentro de un conte7to )articular

;encionen alg5n )atrn de dise2o que

cono,can
18
Idioms

@n idiom

es un )atrn de ba4o nivel6 es)ecfico )ara un

lengua4e de )rogramacin'

escribe como im)lementar as)ectos )articulares de

elementos o de las relaciones entre ellos usando las
caractersticas de un lengua4e )articular'
Arquitectura de Software
Estilos Arquitectnicos
20
Beneficios de @sar Estilos

%ermite seleccionar una solucin entendible y

)robada a ciertos )roblemas6 definiendo los
)rinci)ios organi,ativos del sistema

Al basar la arquitectura en estilos que son

conocidos las )ersonas entienden m1s
f1cilmente las caractersticas im)ortantes de la
misma
21
?ormas de @so de los Estilos

Solucin )ara el dise2o del sistema

Alg5n estilo sirve'

Se ado)ta y se usa como una de las estructuras

centrales de la arquitectura'

Base )ara una ada)tacin

Alg5n estilo soluciona )arcialmente los )roblemas'

Se )uede buscar ada)tar el estilo )ara las

restricciones )articulares que se tienen'
22
?ormas de @so de los Estilos -B.

Ins)iracin )ara una solucin relacionada

*ing5n estilo sirve'

Sin embargo6 entender )roblemas que solucionan

ciertos estilos )uede llevar a entender me4or el
)roblema actual'

Entonces6 se )uede encontrar una solucin que de

alguna forma est1 relacionada con estilos e7istentes

;otivacin )ara un nuevo estilo

El )roblema no es atacado )or ning5n estilo

encontrado

Es una buena o)ortunidad )ara encontrar una

solucin general al )roblema y crear un nuevo estilo
23
Algunos Estilos

S!ared ata -atos &om)artidos.

%i,arrn -Blac(board.

&liente$Servidor

&a)as Jer1rquicas

escom)osicin Krientada a Kb4etos

Dubos y ?iltros

&ontrol &entrali,ado

&ontrol Basado en Eventos

Arquitecturas de Sistemas istribuidos

&liente$Servidor

Kb4etos istribuidos

%eer$Do$%eer

Service Kriented Arc!itecture -SKA.

24
S!ared$ata

Leneralidades

May un almacenamiento central de datos y un

con4unto de com)onentes que o)eran sobre :ste'

Interaccin $ intercambio de datos )ersistentes

;5lti)les accesos a los datos

Al menos un almacenamiento com)artido

Si se avisa al consumidor de nuevos datos de inter:s

es un %i,arrn -Blac(board.

Si es el consumidor quien busca los datos es un

+e)ositorio
25
#enta4as y esventa4as

?orma eficiente de com)artir grandes cantidades de

datos'

*o se transmiten datos de un com)onente a otro'

Sin embargo6 los subsistemas deben estar de acuerdo

en el modelo de datos del re)ositorio'

3as com)onentes que )roducen datos no necesitan

conocer como van a ser usados esos datos'

Actividades como res)aldos6 seguridad6 control de

acceso y recu)eracin est1n centrali,adas'

Sin embargo6 diferentes com)onentes )odra tener

distintas )olticas de recu)eracin6 res)aldo6 etc'
26
%i,arrn -Blac(board.

?uentes de &onocimiento

%rocesos inde)endientes que corres)onden a )articiones del

conocimiento del mundo y del dominio de)endientes de la
a)licacin

+es)onden a cambios en el )i,arrn

Estructura de datos del %i,arrn

Estado com)leto de la solucin del )roblema

5nico medio )or el cual las ?uentes de conocimiento interact5an

)ara llegar a la solucin

&ontrol

Luiado enteramente )or el estado del )i,arrn

3as ?uentes de conocimiento res)onden o)ortunamente cuando

los cambios en el )i,arrn a)lican

%uede im)lementarse en las ?&6 en el )i,arrn6 en un

com)onente se)arado o cualquier combinacin de :stos'
27
%i,arrn -Blac(board.
Pizarrn
FC 1
FC 7
FC 6
FC 2
FC 3
FC 4
FC 5
Clculos
Memoria (Comar!i"a#
28
&liente$Servidor

El sistema se descom)one en servicios y sus

ser"idores asociados y en clientes que acceden y usan
dic!os servicios'

Estilo com)uesto )or8

Servidores que ofrecen servicios'

&lientes que usan servicios ofrecidos )or los servidores'

@na red que )ermite que los clientes accedan a los servidores'
Esto no es estrictamente necesario ya que clientes y servidores
)ueden estar en una misma m1quina'

3os clientes conocen a los servidores )ero no a otros

clientes y los servidores no tienen )orqu: conocer a los
clientes

la asignacin de )rocesos a )rocesadores no tiene

)orqu: ser E8E
29
&liente$Servidor -B.
Network
SC1
SC2
CC1 CC2 CC3
CC5 CC6
CC4
Server
computer
Client
computer
s1, s2
s3, s4
c5, c6, c7
c1 c2
c3, c4
c8, c9 c10, c11, c12
&
i
N clientes
S
i
N servidores
30
&a)as Jer1rquicas

El sistema se organi,a en ca)as'

&ada una )rovee un con4unto de servicios a las

ca)as su)eriores y requiere servicios de las
inferiores'
Capa n
Capa n - 1
Capa
Capa 1
!
!
!
31
&a)as Jer1rquicas -B.

#odelo estricto: una ca)a slo utili,a servicios

de la inmediata inferior'

#odelo rela$ado8 se )ueden =saltar> ca)as'

efinicin de )rotocolos mediante los que

interact5an las ca)as
32
#enta4as y esventa4as

#enta4as

?acilita la com)rensin

?acilita mantenimiento

?acilita reutili,acin

?acilita )ortabilidad

esventa4as

*o siem)re es f1cil estructurar en ca)as ni identificar

los niveles de abstraccin a )artir de los
+equerimientos'

la inter)retacin de comandos en m5lti)les niveles

)uede afectar el desem)e2o'
33
escom)osicin K'K'

Se descom)one el sistema en un con4unto de

ob4etos que se comunican'

+e)resentacin de datos y o)eraciones

asociadas se enca)sulan en un ob4eto'

Merencia6 )olimorfismo6 sobrecarga de

o)eradores6 enlace din1mico'
34
#enta4as y esventa4as

#enta4as

3a im)lementacin de los ob4etos )uede ser

cambiada sin afectar a otros ob4etos'

%romueve la reutili,acin de com)onentes'

;uc!os ob4etos re)resentan entidades de la realidad

)or lo que es f1cil entender la estructura del sistema'

esventa4as

%ara usar servicios se debe conocer el nombre de la

interface de otro ob4eto'

3os cambios en las interfaces afectan a todos los

ob4etos que la usan'
35
Dubos y ?iltros

Se descom)one el sistema en mdulos funcionales

Interaccin $ sucesiva transformacin de flu4os de datos
3os datos llegan a un filtro6 se transforman y son )asados a trav:s
de tubos al siguiente filtro
@n 5nico filtro )uede )asar datos a m5lti)les tubos y recibir datos
de m5lti)les tubos
&ada filtro es inde)endiente del resto y no conoce la identidad de
los otros filtros
3a transformacin del filtro )uede comen,ar antes de terminar de
leer la entrada

+es)etando el grafo6 no im)orta la secuencia -)aralelismo.

Filtro
Tubo
36
#enta4as y esventa4as

#enta4as

Se )ueden reutili,ar los filtros'

Es intuitivo )ensar en secuencias de )rocesamientos

de datos'

Agregar nuevas transformaciones de forma que el

sistema evolucione es sencillo'

esventa4as

Acordar cu1l es el formato de los datos'

Diene que ser =gen:rico> si las com)onentes son

reusadas'

Sistemas interactivos son difciles de construir con

este estilo'

Ineficiente si !ace m1s de lo que debe o si los filtros

re)iten c!equeos
37
;odelos de &ontrol

;odelos de control a nivel de la arquitectura se

)reocu)an del flu4o de control entre subsistemas

&ontrol centrali,ado
@n subsistema controla al resto

&ontrol basado en eventos

&ada subsistema )uede res)onder a eventos e7ternos
" Eventos generados )or otros subsistemas
" Eventos generados )or el ambiente del sistema
38
&ontrol &entrali,ado -E.

El control centrali,ado se )uede dividir en dos

clases

3lamada$+etorno
Princial
$u%r& ' $u%r&( $u%r&C
$u%sis!ema
)lama"o*+e!orno
39
&ontrol &entrali,ado -B.

;odelo Lerente

@na com)onente es el gerente del sistema y controla

a los otros )rocesos del sistema
Con!rola"or "el $is!ema
'
(
F
,
C
-
40
&ontrol Basado en Eventos

En los modelos centrali,ados las decisiones de

control suelen estar determinadas )or valores
de alguna variable de estado del sistema

En cambio6 el control basado en eventos es

guiado )or eventos generados e7ternamente

E4em)los

;odelos emisin -broadcast.' Se emiten los eventos

a todos los subsistemas'

;odelos guiados )or interru)ciones' Se usan en

sistemas de tiem)o real' 3as interru)ciones son
)asadas )or un mane4ador de interru)ciones a otras
com)onentes )ara su )rocesamiento'
41
%ublicar$Suscribir

Sistema de com)onentes inde)endientes que

anuncian y se suscriben a eventos

Interaccin va eventos anunciados

3os com)onentes se suscriben a eventos

Es traba4o del run$time asegurarse que cada

evento )ublicado sea entregado a todos los
suscri)tores de dic!o evento

@na forma es la invocacin im!l"cita

42
Arquitecturas de Sistemas istribuidos

#enta4as

Se com)arten recursos'

A)ertura' *ormalmente estos sistemas est1n

dise2ados con )rotocolos est1ndar'

&oncurrencia'

Escalabilidad

Dolerancia a fallas
El )rocesamiento de la informacin es distribuido entre varias
com)utadoras'
43
Arquitecturas de Sistemas istribuidos -B.

esventa4as

&om)le4idad

Seguridad

ifciles de gestionar

;uy )oco )redecibles

E4em)los

&liente$servidor

Kb4etos distribuidos

%eer$to$)eer

Service oriented arc!itecture -SKA.

44
;iddleware

3as com)onentes )ueden ser

Im)lementadas en diferentes lengua4es

E4ecutarse en distintos ti)os de )rocesadores

@sar diferentes modelos de datos

+e)resentar de forma diferente la informacin

@sar distintos )rotocolos de comunicacin

Entonces6 se necesita software )ara gestionar la

comunicacin y el intercambio de datos entre
com)onentes

ic!o software se denomina middleware

Esta en el medio de las diferentes com)onentes distribuidas
45
;iddleware -B.

*ormalmente son usados middleware que son

com)rados comercialmente ya que son de
)ro)sito general'
46
&liente$Servidor

El dise2o de sistemas cliente$servidor debera

refle4ar la estructura lgica de la a)licacin'

@na forma de mirar a una a)licacin es la

siguiente8
&a)a de %resentacin
&a)a de %rocesamiento
&a)a Lestin de atos
47
&liente$Servidor -B.

&a)a de )resentacin

%resentacin de informacin al usuario e interaccin

con el mismo

&a)a de )rocesamiento

Im)lementacin de la lgica de la a)licacin

&a)a gestin de datos

K)eraciones de bases de datos y arc!ivos

En sistemas distribuidos es im)ortante distinguir

claramente esta se)aracin ya que es )osible
distribuir cada ca)a en com)utadoras diferentes
48
&liente$Servidor en B *iveles

Es la arquitectura m1s sim)le cliente$servidor

#arios clientes y un servidor -o varios servidores

id:nticos.

B formas diferentes8

&liente fino

El )rocesamiento de la informacin y la gestin de los datos

ocurre en el servidor' El cliente slo es res)onsable de
e4ecutar el software de )resentacin'

&liente grueso

El servidor es res)onsable slo de la gestin de los datos' El

cliente e4ecuta el )rocesamiento de la a)licacin -la lgica de
la a)licacin. y la )resentacin'
49
&liente ?ino6 Lrueso y A))let

&liente fino

%rocesamiento )esado del lado del servidor

%rocesamiento )esado en la red

&liente grueso

;e4or distribucin del )rocesamiento

3a administracin del sistema es m1s com)le4a

&uando el software de a)licacin cambia !ay que reinstalar
la a)licacin en cada com)utadora cliente

Java A))lets descargables

Est1n en el medio entre cliente fino y grueso

3uego de descargar el a))let se e4ecuta )arte de la

lgica de la a)licacin en el cliente
50
Algunos %roblemas

En B niveles !ay que distribuir las tres ca)as

-)resentacin6 lgica y datos. en dos sistemas
de com)utadoras

%ueden surgir )roblemas de

escalabilidad y rendimiento con el cliente fino
o de gestin del sistema si se usa cliente grueso

%ara evitar estos )roblemas una alternativa es

usar una arquitectura cliente$servidor en H
niveles
51
&liente$Servidor en H *iveles

3a )resentacin6 la lgica y los datos se se)aran

como )rocesos lgicos diferentes distribuidos en
distintas m1quinas

E4em)lo8 Sistema bancario )or internet

&lient
e
&lient
e
&lient
e
&lient
e
Servidor web
%rovisin de
servicios
de cuenta
Servidor de B
S93
Base atos
&uenta
&liente
MDD%
&onsulta S93
52
&om)aracin

3a arquitectura en H niveles

Es m1s escalable que la de B niveles

+educe el tr1fico en la red en com)aracin con

cliente fino

3a ca)a de )rocesamiento de la a)licacin es

f1cilmente actuali,ada ya que est1 locali,ada
centralmente

&liente servidor en m5lti)les niveles

E4em)lo8 a)licacin que necesita acceder a m5lti)les

fuentes de datos -integracin de datos.
53
E4em)los
Arquitectura A)licaciones
Arquitectura &OS
dos niveles
cliente fino
A)licaciones legadas en las cuales no se )uede se)arar el
)rocesamiento de la gestin de los datos
A)licaciones intensivas en las com)utaciones con )oco o
nada de gestin de datos -e48 com)iladores.
A)licaciones intensivas en mane4o de datos -browsing y
consultas. con )oco o nada de )rocesamiento de a)licacin
Arquitectura &OS
dos niveles
cliente grueso
A)licaciones donde el )rocesamiento de la a)licacin es
)rovisto off$t!e$s!elf en el cliente
A)licaciones donde se !acen intensivos )rocesamientos
com)utacionales de los datos -e48 visuali,acin de datos.
Arquitectura &OS
tres niveles o
m5lti)les niveles
A)licaciones de gran escala con cientos o miles de clientes
A)licaciones en donde tanto los datos como el
)rocesamiento son vol1tiles
A)licaciones con fuentes de datos m5lti)les
54
Kb4etos istribuidos

En la arquitectura cliente$servidor los clientes y los

servidores son distintos

3os clientes reciben servicios de los servidores y no de otros

clientes

3os servidores )ueden actuar como clientes de otros servidores

)ero no requieren servicios de clientes

3os clientes deben conocer los servicios ofrecidos )or

servidores es)ecficos y deben conocer como contactar a estos
servidores

Enfoque m1s general

+emover la distincin entre clientes y servidores

ise2ar la arquitectura como una de ob4etos distribuidos

55
Kb4etos istribuidos -B.

Se com)one de ob4etos que )roveen servicios a

otros ob4etos y usan servicios de otros ob4etos

*o !ay distincin entre clientes y servidores

%ueden ser distribuidos entre distintas com)utadoras

en una red y se comunican a trav:s de middleware
Este ti)o de middleware se conoce como #b$ect %e&uest
Bro'er -K+B.6 )or e4em)lo6 &K+BA'

Es m1s com)le4o de dise2ar que cliente$servidor

Software bus
o1 o2 o3 o4
o5 o6
S (o1) S (o2) S (o3) S (o4)
S (o5)
S (o6)
56
%eer$to$%eer

Sistemas descentrali,ados donde las

com)utaciones )ueden ser reali,adas en
cualquier nodo de la red

En )rinci)io no !ay distincin entre clientes y

servidores

El sistema se dise2a )ara usar el )oder de

almacenamiento y )rocesamiento de m5lti)les
com)utadoras en una red

3os )rotocolos que )ermiten la comunicacin entre

nodos est1n embebidos en la )ro)ia a)licacin
&ada nodo debe correr una co)ia de la a)licacin
57
%eer$to$%eer -B.

E4em)los

Sistemas )ara com)artir arc!ivos

;ensa4era instant1nea

SetiP!ome
Q otros P!ome

Se est1 comen,ando a usar tambi:n en el 1rea de

negocios
Intel y Boeing !an im)lementado sistemas intensivos en las
com)utaciones con arquitecturas )B)

Se )ueden clasificar en sistemas

descentrali,ados o semi$centrali,ados
58
%eer$to$%eer -H.

Algunos )roblemas

Kver!ead

Seguridad

&onfian,a

Entonces6 son m1s usados en sistemas que no

son crticos res)ecto a la informacin
59
Service Kriented Arc!itecture -SKA.

Krgani,aciones que quieren !acer su

informacin accesible a otros )rogramas
)ueden !acerlo definiendo y )ublicando una
interface de servicio web

@n ser"icio web es una re)resentacin

est1ndar )ara alg5n recurso com)utacional o de
informacin que )uede ser usado )or otros
sistemas
60
SKA -B.

El servicio es inde)endiente de las a)licaciones

que lo usan

Se )ueden construir a)licaciones mediante el

uso de distintos servicios

May varios modelos de servicios distintos'

&once)tualmente todos o)eran de acuerdo al
siguiente modelo
61
&om)aracin SKA y Kb4etos istribuidos

%ro)aganda )5blica de la dis)onibilidad del servicio

%otencialmente el enlace con el servicio )uede ser en

tiem)o de e4ecucin

K)ortunidad de crear nuevos servicios a trav:s de

com)osicin de otros servicios

%ago )or uso de servicios6 )or su uso m1s que )or su

)rovisin

Esto sustituye com)onentes caras raramente usadas

A)licaciones m1s c!icas y com)actas

A)licaciones que )ueden ser reactivas y ada)tar su

o)eracin de acuerdo a su medio mediante el cambio de
enlaces a servicios durante la e4ecucin
62
Web Services Est1ndares

3os servicios se basan en est1ndares basados

en R;3

Entonces6 )ueden funcionar en cualquier )lataforma y

ser escritos en cualquier lengua4e

Est1ndares m1s conocidos8

SKA% $ Sim)le Kb4ect Access %rotocol

WS3 $ Web Services escri)tion 3anguage

@I $ @niversal escri)tion6 iscovery and

Integration'
63
E4em)lo

@n sistema de informacin )ara un auto )rovee

al conductor con informacin acerca del clima6
las condiciones del tr1fico6 informacin local6
etc' Esto est1 vinculado con la radio del auto de
forma que la informacin es entregada como
una se2al en un canal es)ecfico de la radio

El auto est1 equi)ado con un recibidor L%S

)ara conocer su )osicin y6 basado en esa
)osicin6 el sistema accede a un rango de
servicios de informacin' 3a informacin debe
ser entregada en el lengua4e es)ecificado )or el
conductor
64
E4em)lo -B.
User i nterface
Locator
Di scover s car
posi ti on
Weather
i nfo
Recei ves r equest
fr om user
Recei ver
Recei ves
i nfor mati on str eam
fr om ser vi ces
Tr ansmi tter
Sends posi ti on and
i nfor mati on r equest
to ser vi ces
Radi o
Tr ansl ates di g i tal
i nfo str eam to
r adi o si gnal
I n-car softar e s!stem
"obi l e I nfo Ser vi ce
Faci l i ti es
i nfo
Tr ansl ator
Road
l ocator
Tr affi c
i nfo
#ol l ates i nfor mati on
Road tr affi c i nfo
command
gps coor d
gps
coor d
gps coor d
gps coor d
Language
i nfo
I nfo
str eam
Ser vi ce di scover !
Fi nds avai l abl e
ser vi ces
65
Evaluacin de Arquitecturas

&ambiar la arquitectura de un )roducto ya construido

requiere muc!o esfuer,o

Entonces6 es im)ortante evaluar la arquitectura antes de

im)lementarla com)letamente

#erificar los requisitos de calidad establecidos

Evaluaciones a )osteriori resultan 5tiles como forma de

a)rendi,a4e y estudio de )osibilidades de me4ora6 )or e4'
)ara una nueva versin del )roducto

Software Engineering Institute -SEI. )ro)one8

Arc!itecture Dradeoff Analysis ;et!od -ADA;.

Software Arc!itecture Analysis ;et!od -SAA;.