Presentación

• I nst r uct or
– Her nán Ast udillo
– I ngenier o I nf or mát ico & PhD Comput er Science
– Pr of esor UTFSM, Valpar aíso, Chile

Arquitectura de Software • Hor ar io & mat er iales

Her nán Ast udillo
• Calif icación
Depar t ament o de I nf or mát ica
Univer sidad Técnica Feder ico Sant a Mar ía
<her nan at acm.or g>
– 5 sesi ones
– Lu 16/ ene - Vi 2 0 / ene; 17-19 h r s; sala 4.0.F.16
– Lect ur as en r epr ogr af ía: capít ulos de t ex t os & ar t ículos
– A dicional: sit io W eb ad-hoc & l i st a de cor r eo
• ht t p:/ / www.ast udillo.biz/ ar quit ect ur a/ uc3m-2004-ar quit ect ur a/
– Par t icipación
– Ex amen f inal
– (posible pr oyect o)

Sesión 01 [2004-ii-16] Arquitectura de Software - 2

H.Astudillo

Contenido del curso

• I nt r oducción, mot ivación y cont ext o
• Repr esent ación de ar quit ect ur as
– Vist as
– Calidad
• Elabor ación de ar quit ect ur as Motivación
– Pat r ones
– Líneas de pr oduct os
• Pr ocesos y evaluación de ar quit ect ur as
– Pr ocesos (incl. t aller )
• Pr áct icas de ar quit ect ur a
– Or ganizaciones y Mer cados
– Component es

Sesión 01 [2004-ii-16] Arquitectura de Software - 3

H.Astudillo

Arquitectura de Software Ejemplo: i-Banco Casero

• ¿Por qué “ar quit ect ur a” de sof t war e? • Pr oblema (conocido)
– Analogía: ar quit ect os, ingenier os, const r uct or es – oper aciones bancar ias
• Per f iles complement ar ios, par t e de un equipo desde la casa
• Compar ar : det er minar t ipo de const r ucción vs. elabor ar – vía int er net (W eb)
plano eléct r ico vs. alzar mur os
• Diver sidad en not aciones, t écnicas, cr it er ios...
– Ar quit ect ur a de sof t war e no es sobr e “obj et os” ni
“pant allas” ni “f unciones”
• Mayor gr anular idad y mayor abst r acción
• Vocabular i o de component es y pr opi edades
• Foco en pr oduct o (sist ema) y pr oceso

Sesión 01 [2004-ii-16] Arquitectura de Software - 5 Sesión 01 [2004-ii-16] Arquitectura de Software - 6

H.Astudillo H.Astudillo

1

MailClient
Sesión 01 [2004-ii-16]
• Est imaciones
– númer o de clases
– esf uer zo de const r ucci ón
Sesión 01 [2004-ii-16]
• Pr oblema (conocido)
– El sist ema se vuelve popular
– Muchos usuar ios
Sesión 01 [2004-ii-16]
Fase 0 - Solución Fase 0 - Notas
• Not as
– client e: br owser Web
– ser vidor : scr ipt s CGI (pr ogr amas invocados seg ún URL)
– comunicaci ón v ía H T T P
– segur idad: usuar io y cont r aseña, v ía f or mas HTML
– audit able: bit ácor a (“logs ”)
MailSender – dat os: BD det r ás del ser vidor W eb
sendText • Pr oblema t ecnol ógico
– oper aciones t r ansaccionales (at ómicas per o compuest as)
– ...per o HTTP es “st at eless”: cada invocación par t e de cer o
• Solución
– ‘Sesiones’: pasar est ado, o guar dar est ado y pasar clave;
ambos casos pueden usar URL, f or ma, cookie...
Arquitectura de Software - 7 Sesión 01 [2004-ii-16] Arquitectura de Software - 8
H.Astudillo H.Astudillo
Fase 0 – Ejercicio Obs: descripción de arquitecturas
• Not aciones similar es a diseño (p.ej . UML, ‘4+1’)
• T ambién ex ist en not aciones f or males (ADLs)
– Vist as del sist ema a const r uir
• Vist as est át icas (clases, asociaciones, capas...)
• Vist as dinámicas (est ados, secuencia, colabor ación...)
• Vist as f uncionales (casos de uso, int er f aces...)
– Vist as del pr oceso a seguir
• Subsist emas y component es (unidades de t r abaj o)
• Dependencias ent r e unidades (par a planif icar ; Gant t / Per t ...)
• Vist as son def inidas por t ipo de ‘lect or ’
– ¿Q uién lee especif icaciones de ar quit ect ur a?
• Mej or dicho, ¿a quién le impor t a lo que hace el ar quit ect o?
– ‘St akeholder s’: los af ect ados (lect or es y evaluador es!!)
Arquitectura de Software - 9 Sesión 01 [2004-ii-16] Arquitectura de Software - 10
H.Astudillo H.Astudillo
Fase 1: masificación Fase 1 - Solución
Arquitectura de Software - 11 Sesión 01 [2004-ii-16] Arquitectura de Software - 12
H.Astudillo H.Astudillo
2
 Fase 1 - Notas Obs: problemas sistémicos
• Pr oblemas sist émicos • Mayor escala pr ovoca pr oblemas sistémicos
– lent o e inest able – Rendimient o, disponibilidad (est abilidad), conf iabilidad...
• CGI levant a pr ocesos -> memor ia y velocidad – N o puede ident if icar se un lugar específ i co ‘culpable’
– colisiones en bit ácor as y dat os – No son def ect os de pr ogr amaci ón, sino malas decisiones
• pr oblemas de concur r encia sobr e pr ot ocolos, polít icas de r eplicaci ón, concur r encia...
– dif ícil de monit or ear • I mpact o de r equisit os
• Soluciones (complement ar ias) – El ar quit ect o pr ivilegia las pr opiedades sist émicas por
– pr ocesos r esident es en memor ia (por sesión) sobr e la “f uncionalidad” (t ar eas)
– cont r ol de concur r encia (pesimist a, pr obablement e) – En gener al, con sist emas gr andes es más dif ícil sat isf acer
las pr opiedades de ej ecuci ón que ej ecut ar la t ar ea misma
– monit or eo dinámico y global
– r eplicación de ser vidor es (balanceo de car ga) – Er r or es de ar quit ect ur a (o diseño) son car os
• Foco del ar quit ect o
– r equisit os sist émicos (descr ipci ón y solución)

Sesión 01 [2004-ii-16] Arquitectura de Software - 13 Sesión 01 [2004-ii-16] Arquitectura de Software - 14

H.Astudillo H.Astudillo

Fase 2: PyMEs / sucursales Fase 2 - Solución

• Pr oblema (conocido)
– El sist ema se ex pande a usuar ios cor por at ivos
• Se r ecibe depósi t os del empleador a empleados
– El sist ema at r ae usuar ios int er nos
• Usuar ios conect ados v ía int r anet , rápida, segur a, con
plat af or ma unif or me
• Pr oblemas de r esponsabilidad y acceso

Sesión 01 [2004-ii-16] Arquitectura de Software - 15 Sesión 01 [2004-ii-16] Arquitectura de Software - 16

H.Astudillo H.Astudillo

Fase 2 - Notas Fase 2 - Notas (Cont.)

• Not as • Soluci ón (par cial)
– usuar ios: per sonas y or ganizaciones (con r epr esent ant es) – aut or ización
– segur idad: separ ar aut ent icación y aut or ización • model o: r ol es y der echos
• aut ent icación: cer t if icados ( ex t r anet ) y login (int r anet ) • implant ación: dir ect or ios cent r alizados (‘manej o de
• aut or ización: modelo de ‘apoder ado’(s) por empr esa ident idad’)

• Pr oblema
– aspect os especializados del dominio r equier en modelos
más r icos
– est os modelos r equier en administ r ación (como par t e del
sist ema)

Sesión 01 [2004-ii-16] Arquitectura de Software - 17 Sesión 01 [2004-ii-16] Arquitectura de Software - 18

H.Astudillo H.Astudillo

3
 Obs: arquitecturas sistematizadas Fase 3: integración
• Pr oblemas r ecur r ent es, usualment e coexist ent es • Pr oblema (gr ande al f in)
• Pr e-empaquet ar t ecnologías – El banco decide incor por ar pago de cuent as y
t r ansf er encias
– sesiones, cont r ol de concur r encia, monit or eo...
• Por usuar i os i ndi vi duales y/ o cor por at i vos
• ‘Ar quit ect ur as de línea de pr oduct os’ – Tr ansacciones con ef ect os en t er cer os
– f act or ización y r euso i nt r a- or ganización • N o-r epudiables
• ‘Ar quit ect ur as de r ef er encia’ par a aplicaciones • Mal uso puede af ect ar al banco, no sólo a los ususar i os
– ‘Ser vlet s’: obj et os- pr ocesos (esquema MVC) – Conex ión con sist emas legado
– ASP (Act ive Ser ver Pages): • Ant iguos, per o f uncionando (y bien)
• Plat af or mas het er ogéneas
• ‘Ar quit ect ur as de r ef er encia’
– CORBA (obj et os dist r ibuidos het er ogéneos; casi S .O.)
– RM- ODP (Open Dist r ibut ed Pr ocessing- Ref er ence Model)

Sesión 01 [2004-ii-16] Arquitectura de Software - 19 Sesión 01 [2004-ii-16] Arquitectura de Software - 20

H.Astudillo H.Astudillo

Fase 3 - Solución Fase 3 - Notas

• Pr oblemas de ‘int egr ación’
– int egr idad de dat os: t r ansacciones coor dinadas y/ o
dist r ibuidas
– compat ibilidad de f or mat os, plat af or mas, pr ot ocolos...
– disponibilidad: t oler ancia a f allas
– en gener al: sist emas y polít icas het er ogéneos
• Posibles soluciones
– const r ucción ad- hoc (p.ej . ‘hear t beat ’, ‘logs’...)
– ser vicios W eb (XML, SOAP, UDDI ...)
– ‘message br oker s’: mensaj es+f ilas conf iables (ej : I BM
MQ)
– sist ema oper at ivo (o BD) dist r ibuido (p.ej . Or acle)
– combinación de element os y/ o pr oduct os

Sesión 01 [2004-ii-16] Arquitectura de Software - 21 Sesión 01 [2004-ii-16] Arquitectura de Software - 22

H.Astudillo H.Astudillo

Obs1: generando arquitecturas Obs1 (Cont.)

• Gener ación de ar quit ect ur as alt er nat ivas
– ident if icar polít icas (pr opiedades de alt o nivel)
– det er minar combinaciones de mecanismos suf icient es
• Dimensiones y valor es (+/ - or t ogonales)
– int egr idad: vía t r ansacciones
– t oler ancia a f alla: vía r eplicación
– comunicación: vía enlaces (modo, medio, f or mat o, met a...)
• (ver a cont .)
• Dimensiones y valor es (+/ - or t ogonales)
– int egr idad: vía t r ansacciones
• semánt icas: nivel de ser ialización, anidamient o, sagas...
• concur r encia: lock, t imest amp , f ile syst em, BD...
– t oler ancia a f alla: vía r eplicación
• del sist ema: r edundancia act iva, ‘f ailover ’ (mast er )...
• del est ado: pr opagado dinámicament e, per iódicament e,
‘cacheado’, of f -line...
– comunicación: vía enlaces (modo, medio, f or mat o, met a...)
• modo: push, pull...
• medio: punt o -punt o / mult i cast/ br oadcast , síncr ona vs.
asíncr ona, mensaj es vs. ‘st r eams’...

Sesión 01 [2004-ii-16] Arquitectura de Software - 23 Sesión 01 [2004-ii-16] Arquitectura de Software - 24

H.Astudillo H.Astudillo

4
 Obs2: evaluando arquitecturas Reflexión
• I mplant ando ar quit ect ur as • ¿Qué hemos hecho?
– Solución H 0 : pr ogr amar (f lex ible/ ameno vs. cost o/ t iempo) – I nt r oducción paulat ina de f uent es de complej idad
– Tecnologías con capacidades suf icient es (J 2EE, .N ET...) • Madur ez t ecnológica
• Escala (t amaño)
– Pr oduct os: comer cial vs. Open Sour ce (r iesgo vs. cost o) • Complej idad del dominio
• Pr oblema • Het er ogeneidad
– Evaluar ar quit ect ur as & compar ar alt er nat ivas – I nt r oducción paulat ina de t emas de ar quit ect ur a
• Descr i pci ón de ar qui t ect ur as
• ¿Qué signif ica ‘mej or ’? • Pr oblemas sist émicos
– cr it er ios de opt imalidad: ef ect ividad, cost o, simplicidad, • Ar quit ect ur as sist emat izadas
f ut ur a int egr ación o cr ecimient o, mar ket ing... • Evaluación y compar ación
– sólo los ‘st akeholder s’ pueden r ealment e escoger (no son – Enf oque a vuelo de páj ar o
decisiones t écni cas) • Sin not ación det allada
– una buena ar quit ect ur a es una buena descr ipci ón de una • Sin det alles t écnicos (de pr oblemas ni soluciones)
buena solución
• “buena”: r esponde las pr egunt as de los ‘st akeholder s’

Sesión 01 [2004-ii-16] Arquitectura de Software - 25 Sesión 01 [2004-ii-16] Arquitectura de Software - 26

H.Astudillo H.Astudillo

La disciplina
• Or igen hist ór ico de la disciplina
– Per cepción cr ecient e que pr oblemas de diseño ‘en gr ande’
son cualit at ivament e dif er ent es
– Énf asis en diseñar par a logr ar pr opiedades más que par a
“Arquitectura de Software” t ener f unciones
– Shaw&Gar lan (1993): r ef er encia est ándar
• (Aunque hay publicaciones ant er ior es con nombr es similar es)
• I dent if icar on “est ilos de ar quit ect ur a”
• Pr ivilegiar on medir y compar ar por sobr e mer ament e hacer
• T r adición cont inúa en el SEI (CMU)

Sesión 01 [2004-ii-16] Arquitectura de Software - 28

H.Astudillo

¿Pero porqué “arquitectura”? Arquitecto de Software – misión

• ¿Por qué “ar quit ect ur a” de sof t war e?
– Analogía clave: ar quit ect os, ingenier os y const r uct or es
• Diver sos pr of esionales (y per f iles), per o complement ar ios y
par t e de un equipo
• Roles complement ar ios: det er minar t ipo de const r ucción vs.
elabor ar plano eléct r ico vs. alzar mur os
• La ar quit ect ur a de sof t war e no es sobr e “obj et os”
ni “pant allas” ni “f unciones”
– Mayor gr anular idad y mayor abst r acción
– Se habla de component es y pr opiedades
• Pr opósit o y audiencia:
– ...no es sobr e c ómo hacer sof t war e
– ...sino sobr e qué sof t war e hacer (o r eusar o compr ar )
• Tar ea del ar quit ect o
– Con una descr ipción de t ar eas y pr opiedades sist émicas…
– …especif ica una solución en t ér minos de component es
• Responde las pr egunt as de los ‘st akeholder s’
– ...per mit e evaluar a pr ior i el sist ema a ser const r uido
– ...sir ve como ‘guía de acción’ a los const r uct or es
– ...per mit e elabor ar un plan de const r ucción
• Super visa el pr oceso de const r ucción
– (usualment e, per o no se r equier e)
– ‘Guar dián de la visión’
• Pr opósit o:
– Per mit ir r azonar sobr e el sist ema y sobr e el pr oceso

Sesión 01 [2004-ii-16] Arquitectura de Software - 29 Sesión 01 [2004-ii-16] Arquitectura de Software - 30

H.Astudillo H.Astudillo

5
 Otras analogías Arquitectura y programación
• Analogías desde la indust r ia de const r ucción • Nót ese la dif er encia con hacer un pr ogr ama
(especif icar una comput ación)
– El ar quit ect o de sof t war e como ar quit ect o de edif icios
– La descr ipción de la ‘f uncionalidad’ (t ar eas) t iene menos
• Analogías desde la indust r ia cinemat ogr áf ica impor t ancia r elat iva
– El ar quit ect o del pr oyect o es el dir ect or de la película – En gener al, al const r uir gr andes sist emas es más dif ícil
sat isf acer las pr opiedades de la ej ecución que ej ecut ar la
– El j ef e del pr oyect o es el pr oduct or de la película t ar ea misma
• For mas de educación (y socialización) – Er r or es de ar quit ect ur a (o diseño) son pr áct icament e
incur ables
– En est udios: como los abogados y los ar quit ect os
• Apr ender mir ando por encima del hombr o
– En clínicas: como los médicos
• Apr ender en equipo en modo cr isis
– Pasiva: como los ingenier os
• Cur sos t eór icos, pr áct ica post-gr aduaci ón

Sesión 01 [2004-ii-16] Arquitectura de Software - 31 Sesión 01 [2004-ii-16] Arquitectura de Software - 32

H.Astudillo H.Astudillo

Arquitectura y diseño Razones

• Cont r ast e de escala y pr opósit o
– Ar quit ect ur a: det er minar qué sof t war e hay que hacer (o
compr ar o r eusar )
– Diseño: det er minar cómo hacer lo
• Per o oj o
– Est as son t ar eas (r oles), no ex cluyent es
– N o hay un límit e dur o ent r e ambas cosas
• Razones par a pensar en ar quit ect ur a
– Sof t war e es dif ícil de mant ener
• Cambios t ienen muchas r amif icaciones
– Necesidad de int egr ar aplicaciones
• Sist emas compuest os de aplicaciones
• Cambios en est r uct ur a or ganizacional impact an el sist ema
– Cambios en r epr esent ación de inf or mación
– Cambios en t ecnología

Sesión 01 [2004-ii-16] Arquitectura de Software - 33 Sesión 01 [2004-ii-16] Arquitectura de Software - 34

H.Astudillo H.Astudillo

Usos [Garland/Anthony] Usos [Clements]

• Ent r enamient o: par a nuevos miembr os del equipo • Medio de educaci ón: par a ent r enar gent e
• Apoyar cambios: r egist r o de decisiones par a • Comunicación ent r e st akeholder s: incluyendo
est imar impact o de cambios f ut ur os ar quit ect os
• I nt er f az: par a pr obar subsist emas, e int egr ación • Base par a analizar el sist ema: r endimient o,
con ot r os sist emas segur idad, usabilidad, disponibilidad,
• Evaluación: per mit ir est imar at r ibut os como modif icabilidad...
conf iabilidad, disponibilidad, r endimient o...
• Ver if icación: muchas veces se descubr e
inconsist encias u omisiones en los r equisit os
• Administ r ación del pr oyect o: par a est imar
esf uer zo, t iempo, r ecur sos, dependencias
• Explot ación: par a conf igur ación y af inamient o
Sesión 01 [2004-ii-16] Arquitectura de Software - 35 Sesión 01 [2004-ii-16] Arquitectura de Software - 36
H.Astudillo H.Astudillo

6
 ¿De qué hablan los arquitectos? Definiciones más formales [1/2]
• Post ur a # 1: ar quit ect os de gr andes sist emas de • I EEE 1471
SW ‘piensan’ en macr o-component es – ‘Ar chit ect ur e is t he f undament al or ganizat ion of a
– Capas (‘layer s’) syst em, embodied in it s component s, t heir r elat ionships
– Pr ocesos y ‘pipes’ t o each ot her and t o t he envir onment , and t he pr inciples
guiding it s design and evolut ion.’
– Client es y ser vidor es
• I EEE 1471
• Post ur a 2: ‘piensan’ en polít icas y mecanismos – An ar chit ect ur e is t he highest - level concept of a syst em
– Toler ancia a f allas, r endimient o … in it s envir onment
– Replicación - - > ‘f ailover ’, balanceo de car ga … – highest level = essent ial, unif ying concept s and pr inciples
• Tenemos 2 vocabular ios con f ocos – syst em = applicat ion, syst em, plat f or m, syst em- of
complement ar ios: syst ems, ent er pr ise, pr oduct line, ...
– Est r uct ur a: component es y conect or es – envir onment = development , oper at ional, pr ogr ammat ic,
– Pr opiedades: polít icas y mecanismos cont ex t
– I mplicat ion: Ever y Syst em has an Ar chit ect ur e

Sesión 01 [2004-ii-16] Arquitectura de Software - 37 Sesión 01 [2004-ii-16] Arquitectura de Software - 38

H.Astudillo H.Astudillo

Definiciones más formales [2/2]

• Alan Cooper
– ‘Ar chit ect s synt hesize people, t echnology and pur pose,
[ t o] cr eat e a vision of a solut ion.’
• Per r y+Wolf e (via Boehm)
– SW Ar ch. = {Element s, For ms, Rat ionale/ Const r aint s} Arquitectura y proceso
– Sof t war e ar chit ect ur e deals wit h t he design and
implement at ion of t he high - level st r uct ur e of sof t war e,
by assembling ar chit ect ur al element s in well- chosen
f or ms t o sat isf y f unct ional and non- f unct ional
r equir ement s (e.g. per f or mance, r eliabilit y, scalabilit y,
por t abilit y, availabilit y)

Sesión 01 [2004-ii-16] Arquitectura de Software - 39

H.Astudillo

Tipos de requisitos [1] Tipos de requisitos [2]

• Los t ipos son conocidos; cor r esponden a: • Funcionales: t ar eas especif icas per mit idas por el
– f uent es dif er ent es sist ema
– Q ué: “El sist ema debe per mit ir hacer X”
– modos de r elevar dif er ent es
– Q uién: El analist a (casos de uso, modelos de dominio...)
– nat ur aleza dif er ent e
• Pr opiedades (no f uncionales): gar ant ías sist émicas
de oper ación del sist ema
– Q ué: Rendimient o, conf iabilidad, disponibilidad... (“ilit ies”)
– Q uién: I nf or males(!); muchas veces suplidas por el
ar quit ect o
• Rest r icciones al sist ema: limit aciones a posibles
soluciones
– Q ué: Decisiones a pr ior i que r est r ingen las soluciones
válidas
– Q uién: J ef es de pr oyect o más que analist as (!)

Sesión 01 [2004-ii-16] Arquitectura de Software - 41 Sesión 01 [2004-ii-16] Arquitectura de Software - 42

H.Astudillo H.Astudillo

7
 Requisitos - resumen Atributos
• Resumiendo • [ G+A,1.1.2]
– 3 t ipos – dist inguir pr oduct o, pr oceso, especif icación
• Funciones
• Pr opi edades
• Rest r icciones
– Conf ir mar que los 3 t ipos sean document ados
• O al menos ent endi dos

Sesión 01 [2004-ii-16] Arquitectura de Software - 43 Sesión 01 [2004-ii-16] Arquitectura de Software - 44

H.Astudillo H.Astudillo

Audiencia del arquitecto [1] Stakeholders (simple)

• ¿A qui én le impor t a lo que el ar quit ect o hace?
– ‘St akeholder s’ analista s
pe
– I mplicados; ‘los que t ienen algo en j uego’ cs

• los “af ect ados” por la calidad de lo que hace el ar quit ect o
arquitecto
• St akeholder s usuales
– Analist a (r epr esent a al client e)
arq
– I mplant ador (pr ogr amador y/ o diseñador de sub- par t es) uit
etu
ra

implantador

Sesión 01 [2004-ii-16] Arquitectura de Software - 45 Sesión 01 [2004-ii-16] Arquitectura de Software - 46

H.Astudillo H.Astudillo

Audiencia [2] Stakeholders

• St akeholder s usuales
– Analist a (r epr esent a al client e) analista sp
ec
– I mplant ador (pr ogr amador y/ o diseñador de sub- par t es) s

• St akeholder s adicionales arquitecto

– Ar quit ect o r evisor y/ o de ot r os sist emas arquitetura
revisor
– Q A y/ o int egr ador es
arq
ra

uit
tu

– J ef e de pr oyect o
etu
ite

ra
qu
ar

– Administ r ador del sist ema

jefe de
implantador sis
projeto tem
a
QA sis
tem
a
admin

Sesión 01 [2004-ii-16] Arquitectura de Software - 47 Sesión 01 [2004-ii-16] Arquitectura de Software - 48

H.Astudillo H.Astudillo

8
 Calidad según los stakeholders
• (ver [ G+A,1.2] )
• La solución debe...
– Sat isf acer los r equisit os (analist as)
– Ser ‘const r uible’ (pr ogr amador es & diseñador es)
– Ser t est able (Q A)
– Ser administ r able (administ r ador es)
• La descr ipción de la solución debe...
– Ser evaluable (ot r os ar quit ect os)
• El pr oceso de const r ucción debe...
– Ser manej able (j ef e de pr oyect o)
¿“Evaluable”? ¿“Manejable”?
• Solución evaluable...
– Debe per mit ir evaluar compr omisos y opciones
• Por lo t ant o, debe t ener r ast r eabilidad ent r e las par t es de
la solución y del pr oblema
• Pr oceso manej able...
– Debe ser par t icionada e indicar dependencias
• Par t iciones: unidades nat ur ales de asignación de t r abaj o
• Dependencias: la base par a def inir calendar io
• Solución debe sat isf acer r equisit os
– ¿Obvio? Not r eally ; debe convencer al analist a

Sesión 01 [2004-ii-16] Arquitectura de Software - 49 Sesión 01 [2004-ii-16] Arquitectura de Software - 50

H.Astudillo H.Astudillo

Stakeholders – resumen Calidad de una arquitectura

• El ar quit ect o debe...
– Descr ibir un sist ema a ser const r uido
– Per mit ir der ivar un pr oceso par a const r uir lo
• Una ar quit ect ur a debe ser más que una list a de
pr oduct os
– Y más que un mer o modelo de component es (!)
• ¿Cómo se r econoce una buena ar quit ect ur a?
– Buena ar quit ect ur a = buena descr ipción de buena solución
– En gener al, necesar ia y suf icient e par a el obj et ivo
• “‘Buena”...
– Depende de cada st akeholder
– Debe r esponder sus pr egunt as y per mit ir le r azonar
• Compr omisos
– (I MHO) Mej or buena descr ipción de mala solución que
vicever sa
• A l menos per mi t e det ect ar pr oblemas

Sesión 01 [2004-ii-16] Arquitectura de Software - 51 Sesión 01 [2004-ii-16] Arquitectura de Software - 52

H.Astudillo H.Astudillo

Calidad [Bass] (Cont.)

• En cuant o al pr oceso...
– Pr oduct o de un ar quit ect o o un gr upo coher ent e
(“int egr idad int elect ual”)
– Requisit os clar os y pr ior izados
– Ar quit ect ur a bien document ada
– Revisada por los st akeholder s
– Analizada (en aspect os cuant if icables) y f or malment e
r evisada (en aspect os cualit at ivos)
– Pr ot ot ipable y de const r ucción incr ement al
– Polít icas ex plícit as par a lidiar con conf lict os específ icos
(p.ej . uso de ancho de banda o memor ia)
• En cuant o a la est r uct ur a del pr oduct o...
– Or ganizada en módulos clar os y encapsulados
– Minimizar dependencias en implant ación de los módulos
– Aislar pr obables cambios en módulos específ icos
– Dist inguir y document ar est r uct ur a modular (“build t ime”)
y est r uct ur a comput acional (“r un t ime”)
– Mecanismos int er nos coher ent es y consist ent es

Sesión 01 [2004-ii-16] Arquitectura de Software - 53 Sesión 01 [2004-ii-16] Arquitectura de Software - 54

H.Astudillo H.Astudillo

9
 Modelos de arquitectura Modelos – Particionamiento
• Modelos • Par t icionamient o por mat er ia/ especialist a
– En pr incipio, descr iben el sist ema en det alle – Modelo de dominio vs. modelo de sof t war e
• Poco r ealist a L
– I nf r aest r uct ur a vs. aplicaciones
• Deben descr ibir al menos... – Segur idad, t oler ancia a f allas, balanceo de car ga...
– Piezas mayor es – Dinámico/ est át ico
• Subsist emas, camadas, t opologías...
• Dependenci as t ecnológi cas y de pr oduct os • Vist as (‘views’)
– Decisiones clave globales – Descr ipciones concur r ent es par a aspect os alt er nat ivos
• Polít icas (t oler ancia a f allas, balanceo de car ga, invocación • RUP (Kr ucht en)
dinámica...) • RM-O DP, ot r as
– Desde dif er ent es per spect ivas (‘punt os de vist a’)

Sesión 01 [2004-ii-16] Arquitectura de Software - 55 Sesión 01 [2004-ii-16] Arquitectura de Software - 56

H.Astudillo H.Astudillo

Técnicas del arquitecto La gran “ility”: Rastreabilidad

• Pr oblema • Noción f undament al de ar quit ect ur a
– Elabor ación concur r ent e de modelos par a múlt iples – Rast r eabilidad : poder j ust if icar una decisión en el
aspect os cont ex t o del document o
• Técnicas clave – Per mit e est udiar impact o de cambios ( f or war d) y r azones
– Ref inamient o par a acción pr opuest a (backwar d)
• Múlt iples niveles de abst r acción y complet it ud
• Los modelos deben pr oveer inf or mación
– Descr ipción en capas
• Capas son modelos incomplet os, per o compr ensibles – Ref inamient o: ex plicado o apar ent e
– Ref inamient o der ivable – N iveles de abst r acción : mapeables ent r e sí
– “Ref act or ing” (f act or ización) • Una buena ar quit ect ur a “cuent a una hist or ia”
– Ex plicar no sólo el que y como, sino el por qué
– Per mit e decisiones inf or madas a f ut ur o

Sesión 01 [2004-ii-16] Arquitectura de Software - 57 Sesión 01 [2004-ii-16] Arquitectura de Software - 58

H.Astudillo H.Astudillo

Otros sentidos de “arquitectura” Otros sentidos... [2/2]

• Por ámbit o:
– “Ent er pr ise Ar chit ect ur e”: visión y pr incipios
t r ansver sales en la empr esa
• p.ej . segur idad, f lex ibilidad, polít icas de compr a, r euso
– Ar quit ect ur a de Línea de Pr oduct os: def iniciones
comunes a pr oduct os (diseño y/ o implement ación)
– Ar quit ect ur a de Ref er encia: vocabular io (est ilo y
component es) par a dominios de aplicación
• Por t ipo de pr eocupación:
– Ar quit ect ur a de Negocio: est r at egias, or ganización y
met as par a pr ocesos de negocios
– Ar quit ect ur a de Aplicaciones: polít icas par a y soluciones
de sof t war e a pr oblemas específ icos
– Ar quit ect ur a Técnica (o I nf r aest r uct ur a): soluciones
gener ales y/ o est andar izadas (r edes, plat af or mas...)
– Ar quit ect ur a de Dat os (o I nf or mación): almacenamient o y
manej o de inf or mación (pr opiedad, diseño, mét odos...)

Sesión 01 [2004-ii-16] Arquitectura de Software - 59 Sesión 01 [2004-ii-16] Arquitectura de Software - 60

H.Astudillo H.Astudillo

10
 Fábula del ómnibus Fábula de la casita soleada
• ¿Qué lado del ómnibus? • Quier o hacer me una casa
– No me gust a viaj ar al sol – Tengo r ecur sos (o no t endr ía un ar quit ect o) y soy mañoso
– Viaj o f r ecuent ement e a Valpar aíso (nor oest e de St go.) – ¿Q ué me deber ía pr egunt ar el ar quit ect o?
• Voy en la AM • “¿Despier t a t empr ano o t ar de?”
• Regr eso en la PM • “¿T r abaj a en la casa?”
– Ej er cicio: ¿de qué lado viaj o siempr e? • “ ¿Cómo le caen las amigas de su esposa?”
– Pr oblema: viaj é a las 12 y me dio el sol • Mor alej a
• Mor alej a – El ar quit ect o no es un ingenier o
– Los f undament os e hist or ia de una decisión se pier den • Debe pr egunt ar me “por qué”, no “cómo”
• Podr íamos usa la hist or ia par a r econst r uir la decisión • Peligr o
• Peligr o – No bast a conocer los t ipos de pr egunt as par a poder
– Si cambian las cir cunst ancias, no sabr emos que hacer las en f or ma út il
posiblement e hay que cambiar la decisión
Sesión 01 [2004-ii-16] Arquitectura de Software - 61 Sesión 01 [2004-ii-16] Arquitectura de Software - 62
H.Astudillo H.Astudillo

Notas Otro ejemplo: “British Library”

• Coment ar ios • La Bibliot eca Br it ánica t iene un edif icio nuevo
– una met áf or a más adecuada: edif icio, no casa – 2 salas de lect ur a pr incipales:
– j ust if icar pr egunt as: así como el ar quit ect o del edif icio • Par a cient íf icos y par a humanist as
puede j ust if icar sus pr egunt as, debemos poder j ust if icar – Met áf or a basada en “las 2 cult ur as” C.P.Snow
las nuest r as • Cient íf icos: libr os al cent r o, mesas de lect ur a alr ededor
– calidad de los modelos: – Pr ivilegiar cont enido, inf or mación
• casas: maquet as (modelos analógicos), levant amient os, • Humanist as: mesas al cent r o, libr os alr ededor
planos... – Pr ivilegiar int er acción
• sist emas: vist as, diagr amas... • Mor alej a
• apuest a de la disciplina: con el t iempo, nuest r os modelos
– Un ar quit ect o puede (y debe!) usar met áf or as
mej or ar án
– pr ogr ama 1 de mej or amient o: ADLs • Peligr o
– pr ogr ama 2: vist as – ¿Y ot r as f or mas de conocimient o? (p.ej . ar t ist as)
– (“pr ogr ama” de invest igación como en f ilosof ía de la ciencia)

Sesión 01 [2004-ii-16] Arquitectura de Software - 63 Sesión 01 [2004-ii-16] Arquitectura de Software - 64

H.Astudillo H.Astudillo

Otro ejemplo: Cash-Link Referencias [1/2]

• {descr ibir } • Len Bass, Paul Clement s, Rick Kazman
– Sof t war e Ar chit ect ur e in Pr act ice (2nd Ed.), Addison W esley
• Ref er encia (2003)
– [ Ast udillo,2000] • Mar y Shaw, David
– Sof t war e Ar chit ect ur e. Per spect ives on an Emer ging Discipline,
Pr ent ice Hall (1996)
• Luke Hohmann
– Beyond Sof t war e Ar chit ect ur e: Cr eat ing and Sust aining
W inning Solut ions, Addison W esley (2003)
• Kat har ine W hit ehead
– Component- Based Development : Pr inciples and Planning f or
Business Syst ems, Addison W esley (2002)
• Her nán Ast udillo, St uar t Hammer
– Under st anding t he Ar chit ect ’s J ob, Sof t war e Ar chit ect ur e
W or kshop of OOPSLA’98 (1998)

Sesión 01 [2004-ii-16] Arquitectura de Software - 65 Sesión 01 [2004-ii-16] Arquitectura de Software - 66

H.Astudillo H.Astudillo

11
 Referencias [2/2] Recursos
• Clemens Szyper ski • “Sof t war e Ar chit ect ur e”
– Component Sof t war e : Beyond Obj ect-Or i ent ed Pr ogr ammi ng, – Sof t war e Engineer ing I nst it ut e (SEI ), Car negie-Mellon
Addison W esley (1998) Univer sit y
• I var J acobson, Mar t in Gr iss , Pat r ik J onsson – www.sei.cmu.edu/ at a/
– Sof t war e Reuse: Ar chit ect ur e, Pr ocess and Or ganizat ion f or • “Sof t war e Ar chit ect ur e Paper s”
Business Success, Addison W esley (1997) – Sof t war e Engineer ing Resear ch Labor at or y (SERL), Univer sit y
of Color ado
• Philippe Kr ucht en
– www.cs.color ado.edu/ user s/ ser l/ ar ch/ paper s.ht ml
– T he Rat ional Unif ied Pr ocess: An I nt r oduct ion (2nd Ed.),
Addison W esley (2000)
– ht t p:/ / www.r at ional.com/ whit epaper s/

Sesión 01 [2004-ii-16] Arquitectura de Software - 67 Sesión 01 [2004-ii-16] Arquitectura de Software - 68

H.Astudillo H.Astudillo

12