MagisterenIngenieraInformtica

ArquitecturadeSoftware
ii.ConceptualizandolaArquitecturadeSoftware
Prof.GuillermoE.BadilloAstudillo
SemestreI,2014

QueslaArquitecturadeSoftware

La Arquitectura de Software puede

ser vista como la estructura del
sistema en funcin de la definicin
de los componentes y sus
interacciones.
La Arquitectura de Software puede
considerarse como un puente entre
los requisitos del sistema y la
implementacin.
La Arquitectura es considerada
como plan de diseo del sistema,
debido a que es usada como gua
para el resto del las tareas de la
etapa de desarrollo

prof. G.Badillo,2014_1

Modeloconceptualdeladescripcindelaarquitectura,ref.IEEE14712000
Architecture is the
fundamental
organization of a
system embodied in
its
components,
their relationships to
each other, and to
the
environment,
and the principles
guiding its design
and evolution.
[IEEE 1471]

prof.G.Badillo,2014_1

Contextodeladescripcindelaarquitectura,
ref:ISO/IEC/IEEE42010

prof.G.Badillo,2014_1

Modeloconceptualdeladescripcindeunaarquitectura, ref:ISO/IEC/IEEE42010

prof.G.Badillo,2014_1

Porquesimportantelaarquitecturadesoftware

Los sistemas deben ser diseados teniendo en cuenta los usuarios, el

sistemas propiamente tal (la infraestructura de TI), y los objetivos del
negocio
Para cada una de estas reas , Ud. debe esbozar los escenarios clave, e
identificar los atributos de calidad importantes ( por ejemplo , la fiabilidad o
la escalabilidad ) y las reas claves de satisfaccin e insatisfaccin.
Siempre que sea posible , desarrollar y considerar las mtricas que miden el
xito en cada una de estas reas.

prof.G.Badillo,2014_1

Paraelsoftware,nosepuededefinirsuarquitectura,en
formaaisladadelcontextomsampliodelsistema

prof.G.Badillo,2014_1

Laarquitecturadentrodelprocesodedesarrollo
desoftware

prof.G.Badillo,2014_1

ElprocesosdeRequisitos(ref.RUPdeIBM)

prof.G.Badillo,2014_1

Elprocesodedefinicindelaarquitectura

prof.G.Badillo,2014_1

10

Comunicandoydocumentandolaarquitecturadesoftware

Un modelo contiene los elementos que componen ese modelo. Por ejemplo, un modelo
de datos contendr entidades y las relaciones entre ellos, un modelo de aplicacin
contendr componentes, interfaces y interacciones de los componentes, y un modelo de
infraestructura contendr ubicaciones, los nodos, las conexiones entre los nodos, y la
colocacin de los componentes en los nodos.

Una vista (que puede representarse mediante varios esquemas) se refiere a todos los
elementos de modelado que necesita a fin de comunicar la arquitectura a un
determinado conjunto de actores que comparten un conjunto comn de
preocupaciones. Por ejemplo, una vista de seguridad puede referirse a elementos en un
modelo de datos, modelo de aplicacin y modelo de infraestructura. Estos puntos de
vista y luego forman una parte importante de cualquier "empaquetada" descripcin de
la arquitectura que a continuacin, se comunica a los diferentes grupos de inters.

prof.G.Badillo,2014_1

11

lasecuencialgicadeloselementosquesevanautilizarparacomunicarla
arquitecturaes:
1.

Identificarlosgruposdeinters(Stakeholders).Comosemencionanteriormente,cuando
ladocumentacindeunaarquitecturadesoftware,laprimeracosaaentenderesel
pblicoobjetivo.Losinteresadossepuedenorganizarengruposquecompartenunaserie
depreocupacionesrelacionadas.Losdosgruposdepartesinteresadasquesemuestranen
lafigurasonlosdesarrolladoresyprobadores.

2.

Seleccionelasvistas(View).Unavezidentificadoslosgruposdeinters,entonces
necesitamosidentificarlospuntosdevistacorrespondientesquepermitirnquesus
preocupacionesseanexpresadas.Cadavistarequierelainformacinenpoderde
determinadosproductosdetrabajo(comomodelos)porloquelaarquitecturapuedeser
comunicadaalosgruposdeintersidentificadosdeformaadecuada

3.

Creelosproductosdetrabajo.Elarquitecto(oequipodearquitectura)rellenalos
productosdetrabajoenconsecuencia.Porejemplo,podemosaadirelementosa
cualquieradelosmodelosquehemosdecididocrear.

4.

Empaqueteladescripcindelaarquitectura.Envezdecomunicarlaarquitectura
utilizandotodoslosproductosdetrabajoquesehancreado,porlogeneralempaquetar
elementosenunaformaqueesmsfcilmenteconsumidosporlosgruposdeinters(por
ejemplo,todaslaspartesinteresadasnopuedenteneraccesoacualquierherramientade
modeladoqueseutilizanparacrearciertaproductosdetrabajo).Eldiagramaanterior
muestraelarquitectocreandounaArquitecturadeSoftwareDescripcinentregable.Esta
entregaestorganizadaporlosdiferentespuntosdevistasobrelaarquitectura.

prof.G.Badillo,2014_1

12

Vistas Diagramas Modelos(View,Diagrams Models)

prof.G.Badillo,2014_1

13

AlgunosFrameworks dedescripcindearquitectura
ArquitecturadeSoftware

Modelo4+1(Krutchen)
Rozanski andWoods[Rozanski]
Siemens
RMODP

IngenieradeSistemas

Desarrollodesistemadirigidopormodelos,(ModelDriven Systems
Development (MDSD)[MDSD].Formerly RUPfor Systems Engineering
(RUPSE))

ArquitecturaEmpresarial

The OpenGroup Architecture Framework(ToGAF)

The Zachman Framework[Zachman]

Dedominiosespecficos

Department ofDefense Architecture Framework(DoDAF)

Ministry ofDefence Architecture Framework(MoDAF)
prof.G.Badillo,2014_1

14

ejemplos

prof.G.Badillo,2014_1

15

GradodeparticipacindelArquitectosegneltamaodel
proyecto
Proyecto pequeos

Proyectosgrandes

Rol

Seleasigna aunasolapersonalos
diferentesrolesdelarquitecto:
ArquitectodeAplicacin,Arquitecto
deInfraestructura,Arquitectode
Datos

Diferentesingenierossonasignados
acadaunadelasfuncionesde
arquitecturadelarquitectoprincipal,
ArquitectodeAplicacin,Arquitecto
deInfraestructura,Arquitectode
Datos.Adems,elequipotambin
incluyeunarquitectodeseguridad.

Tareas

UnaIntroduccinalaarquitecturase Unavisinglobaldelaarquitectura
creacomouncroquisenunapizarra secreacomounproductodetrabajo
formalquesemantiene.
y/o undocumentobsico(nose
mantienealda).

Producto detrabajo

Unaarquitecturaapruebade
conceptosecreasloenpapel(sin
softwareejecutabletienequeser
construido).

Unaarquitecturaapruebade
conceptosecreacomosoftware
ejecutable.

Lospuntosdevista delosrequisitos,
lospuntosdevistadelos requisitos, delasfunciones,de
implementacin,devalidacin,
delasfunciones,de
implementacinyrendimientose
rendimientoyseguridadseutilizan
utilizanparadocumentarla
paradocumentarlaarquitectura.
arquitectura.
.
prof.G.Badillo,2014_1

16

Fuerzasqueinfluyenenlalabordelarquitecto

prof.G.Badillo,2014_1

17

Uncasodeestudio:Your Tour

prof.G.Badillo,2014_1

18

Actividad1:definir
elcontexto

prof.G.Badillo,2014_1

19

Actividad2:
esquematizandolos
requisitos

prof.G.Badillo,2014_1

20

ClasificandolosrequisitosfuncionalesynofuncionalesconFURPS+

Puedeelsoftware(porsi
solo)satisfacertodosestos
requisitos?

ElSoftwarenopuede,porssolo,satisfacertodaslasnecesidadesderequisitos,
especialmentelassiguientescategoras:

Confiabilidad (Reliability) : Es la medida de la habilidad de un sistema a mantenerse operativo a lo largo del

tiempo (Barbacci et al., 1995).

Desempeo, (Performance): Es el grado en el cual un sistema o componente cumple con sus funciones
designadas, dentro de ciertas restricciones dadas, como velocidad, exactitud o uso de memoria. (IEEE 610.12).
Segn Smith (1993), el desempeo de un sistema se refiere a aspectos temporales del comportamiento del
mismo. Se refiere a capacidad de respuesta, ya sea el tiempo requerido para responder a aspectos especficos
o el nmero de eventos procesados en un intervalo de tiempo. Segn Bass et al. (1998), se refiere adems a la
cantidad de comunicacin e interaccin existente entre los componentes del sistema.

Compatibilidad(Supportability):olacapacidaddesoporteserefierealascaractersticasinherentesdediseoe
instalacinquepermitenelmantenimientoyelapoyoeficazyeficientedelsistemaalolargodelciclodevida

Restriccionesfsicas(physical constraints):Esunarestriccinqueespecificaunapropiedad(es)fsica(s)del
dominiodeaplicacinquenopuedeserviolada.

prof.G.Badillo,2014_1

22

Tiposynivelesderequisitos,
ref:SoftwareRequirements Engineering:What,Why,Who,When,andHow By LindaWestfall

prof.G.Badillo,2014_1

23

Actividad3:priorizando
losrequisitos

prof.G.Badillo,2014_1

24

Losarquitectosobtienenlassolucionesdirigidasporlasnecesidadesdelnegocio

prof.G.Badillo,2014_1

25

Actividad4:definalavistageneraldelaarquitectura

prof.G.Badillo,2014_1

26

Actividad5:
Describiendolos
elementosfuncionales

prof.G.Badillo,2014_1

27

Describiendoloselementosfuncionales

prof.G.Badillo,2014_1

28

Describiendoloselementosfuncionales

prof.G.Badillo,2014_1

29

Asignandolosrequerimientosnofuncionalesaloscomponentes

prof.G.Badillo,2014_1

30

Detallandoloselementosfuncionales

prof.G.Badillo,2014_1

31

Detallandoloselementosfuncionales

prof.G.Badillo,2014_1

32

Describiendoloselementosdedespliegue

prof.G.Badillo,2014_1

33

Detallandoloselementosdedespliegue

prof.G.Badillo,2014_1

34

Losarquitectosrefinanlasolucinsegnlastendencias
tecnolgicas

prof.G.Badillo,2014_1

35

ArquitecturadereferenciaJ2EE

prof.G.Badillo,2014_1

36

Tecnologasespecficas

prof.G.Badillo,2014_1

37

Tecnologasespecficas

prof.G.Badillo,2014_1

38

Desdelosrequisitosalasolucin
Mtodo deDiseo
dirigidoporAtributos
(ADD)

DesarrolladoporSEI.
Los atributosdecalidaddirigenlaArquitectura

Mtodo delas4vistasde
Siemens(S4V)

DesarrolladoporSiemensCorporate Research
Unanlisisdelosfactores globalesquedirigenlaarquitectura
Abordademaneraiterativadesafosatravsdecuatropuntosdevista
(conceptual,ejecucin,mdulosylaarquitecturadecdigo)

The Rational Unified

Process (RUP)

Desarrollado porIBMRational
Losrequisitosarquitectnicamenterepresentativosdirigenlaarquitectura
Cadaiteracinconsideraloselementosarquitectnicosprincipalesdela
solucin,antesdedarsecuentadelosrequisitosatravsdeellos

prof.G.Badillo,2014_1

39

TendenciasactualesenDesarrollodeSoftware

prof.G.Badillo,2014_1

40

Development and Operations, participacin efectiva de los

administradores de sistemas en el proceso de desarrollo de aplicaciones,
utilizando las mismas tcnicas giles que usan los desarrolladores.

http://theagileadmin.com/whatisdevops/

prof.G.Badillo,2014_1

41

The Architecture BusinessCycle

ElbarcodeguerrasuecoVasa

prof.G.Badillo,2014_1

42

The Architecture BusinessCycle.(ABC)

LaHistoriadelbarcodeguerraSuecoVasa,nosnarralaexperienciavividaporel
arquitectodeeseentonces,Henrik Hybertsson,quintenaacargolaconstruccindel
Vasa.
Hybertsson tenaqueequilibraratributosdecalidadpropiasdelaconstruccinde
barcos,comoelrendimiento,lafuncionalidad,laseguridad,laconfiabilidad,yelcosto,
versuslosdeseosdelreyencuantoatenerunbarcodeguerrajamsvistoenel
mundo,ydeextenderelarmamentodelVasahastaellmite.
PorotraparteHybertsson tenaunagranreputacincomoconstructordebarcos,y
precedidodeunatremendaexperiencia,eraresponsabledelosgruposdeinters,
comoelrey,latripulacin,etc.Frenteaunatareaimposible,Hybertsson tuvola
fortunademorircercadeunaoantesdequeterminaralanave.
Elproyectofinalizsuconstruccindeacuerdosalosrequerimientosplanteados.Yfue
botadoalaguaun10deagostode1628,queluegodedispararalgunosdesuscaones
sehundiensuprimerdaenelmar.Luego deellounaseriedeconjeturasfueron
hechas,desdequeelVasahabasidobienconstruido,peromalproporcionado,osea
suArquitecturaeradefectuosa.
Hoyenda,sabemos queHybertsson fuedbilatodoslosconflictosdeintersque
sobrelactuaban.Enparticular,hizounmaltrabajodelagestinderiesgosyunmal
trabajodegestindeclientes.lsimplementeasintiantelasexigenciasimposiblesde
losstakeholders.

LahistoriadelVasatienemasde385aos,ynosilustraelciclodenegociodela
arquitectura:losobjetivosdelaorganizacingeneranrequisitos,loscualesgeneran
unaarquitectura,ylacualgeneraunSistema.

Ref:tomadodellibroSoftwareArchitecture inPractice

43

Lapreguntaencuestines:Culeslarelacinentrela
arquitecturadesoftwaredeunsistemayelmedioambienteenel
cualelsistemaserconstruidoyluegoexistir?
Laarquitecturadesoftwarees
elresultadodeinfluencias
sociales,denegocio,ytcnicas
queexistenduranteelciclode
vidadelproyecto.Estoesel
llamadoABC,The
Architecture BusinessCycle.
(ref.SEI,www.sei.cmu.edu)
Laarquitecturabsicamente
estinfluenciadapor:
1.
2.
3.

LosStakeholders delsistema
Factoresorganizacionalesy
tcnicos.
Laexperienciadelarquitecto.

The Architecture BusinessCycle

prof.G.Badillo,2014_1

44

1.

LaarquitecturaestinfluenciadaporLos
stakeholders delsistema

Los stakeholders de un sistema, son todas aquellas personas

u organizaciones que estn interesados en la construccin del
sistema.
Ejemplos son el cliente, los usuarios finales, los
inversionistas, los mantenedores, los desarrolladores, el jefe
del proyecto, incluso aquellos que comercializan el software,
etc.
Cada uno de ellos tiene un inters en particular sobre el
software a construir, y cada uno de ellos podra por ej. definir
su propia funcionalidad, y sus propios atributos de calidad del
software, segn sus necesidades e intereses.
prof.G.Badillo,2014_1

45

LafiguramuestraalArquitectorecibiendoalgunassugerenciasdelos
stakeholders.

Ref:tomadodellibroSoftwareArchitecture inPractice
prof.G.Badillo,2014_1

46

cont.Stakeholders
Tener un sistema aceptable incluye caractersticas como el rendimiento,
la confiabilidad, la disponibilidad, la compatibilidad de la plataforma , el
uso de memoria , uso de la red , la seguridad , la modificabilidad , facilidad
de uso y la interoperabilidad con otros sistemas , as como su
comportamiento. (Propiedades que determinan el diseo global de la
arquitectura).
El problema subyacente , es que cada actor tiene diferentes
preocupaciones y objetivos , algunos de los cuales pueden ser
contradictorios .
El documento que debiera resolver estos conflictos, y ambigedades, es
la especificacin de requisito de software.
Pero se trata de un documento de requisitos, que rara vez hace un buen
trabajo de capturar todos los requisitos de calidad de un sistema, a nivel
de detalles comprobables.
La realidad es que el arquitecto a menudo tiene que llenar los espacios en
blanco y mediar los conflictos .
prof.G.Badillo,2014_1

47

Unaarquitecturarespondealasnecesidadesdelas
partesinteresadas

prof.G.Badillo,2014_1

48

Ej.ClasificacindeStakeholders

prof.G.Badillo,2014_1

49

2.Laarquitecturaestinfluenciadaporel
desarrolloorganizacional
Adems de los objetivos de la organizacin
expresadas a travs de los requisitos, una
arquitectura est influenciada por la estructura o
naturaleza propia de la organizacin.
Por ejemplo si la organizacin cuenta con expertos
en arquitecturas clienteservidor, podra ser este el
enfoque apoyado por la organizacin.
las habilidades y preferencias del personal del rea
de TI, tambin deben ser tomadas en cuenta, como
posibles influencias.
prof.G.Badillo,2014_1

50

 En general hay tres influencias que provienen de la

organizacin:
El negocio inmediato
El negocio a largo plazo
y la estructura organizacional

Una organizacin:
puede tener una inversin inmediata de negocios en
determinados activos.
puede desear hacer una inversin de negocio a largo plazo para
perseguir los objetivos estratgicos, y el sistema que se
propone en uno de los medios de financiacin y la ampliacin
de esa infraestructura.
y la estructura de la organizacin puede dar forma a la
arquitectura de software.

prof.G.Badillo,2014_1

51

3.

Laarquitecturaestinfluenciadaporsu
entorno

Un caso especial de la trayectoria y la experiencia del

arquitecto se refleja en el entorno tcnico.
El ambiente de desarrollo y las arquitecturas
actuales influir en esa arquitectura, cuando est
siendo diseada.
El arquitecto deber incluir prcticas de la industria,
o estndares, o tcnicas de la ingeniera de
software, y que prevalecen en la comunidad
profesional de la ingeniera de software.
prof.G.Badillo,2014_1

52

Laarquitecturaestinfluenciadaporsu
entorno

prof.G.Badillo,2014_1

53

4.

Laarquitecturaestinfluenciadaporla
trayectoriayexperienciadelarquitecto

Si los arquitectos de un sistema han tenido buenos resultados

usando un enfoque de arquitectura en particular, lo ms probable
es que van a usar ese mismo enfoque en un nuevo desarrollo. Por el
contrario, si su experiencia previa con este enfoque fue desastroso,
los arquitectos estarn reacios a probarlo de nuevo.
En cuanto a las habilidades que caracterizan a un buen arquitecto:

Habilidades personales: deben tener la capacidad de negociar los

intereses personales de los stakeholders y promover la cooperacin entre
ellos.
Habilidades tcnicas: debe ser capaz de entender las corrientes
tecnolgicas, la relacin entre sus cualidades y la estructura, y debe
entender que la mayora de los requerimientos para una arquitectura no
estn escritos en el documento de requisitos.
Habilidades de comunicacin: deben comunicar claramente la
arquitectura al equipo de desarrollo, tanto en forma escrita como
verbalmente. Escuchar y entender los mltiples puntos de vista.
prof.G.Badillo,2014_1

54

Resumendelasinfluenciasenlaarquitectura

prof.G.Badillo,2014_1

55

ElprocesodedesarrollodesoftwareyelABC
Actividadesinvolucradasenlacreacindela
arquitecturadesoftware:
1.
2.
3.
4.
5.
6.
7.

Creacindelmodelodenegocioparaelsistema
Lacomprensindelosrequisitos
Lacreacinolaseleccindelaarquitectura
Documentarycomunicarlaarquitectura
Anlisisyevaluacindelaarquitectura
Implementarelsistemabasadoenlaarquitectura
Asegurarsedequelaaplicacinseajustaala
arquitectura

prof.G.Badillo,2014_1

56

Considerelassiguientespreocupacionesdealtonivelcuando
sepiensaacercadelaarquitecturadesoftware:
Cmovanlosusuariosautilizarlaaplicacin?
Cmolaaplicacinsedesplegarenproduccin?
Culessonlosrequisitosdelosatributosdecalidaddelaaplicacin,como
porejemplo:laseguridad,elrendimiento,laconcurrencia,laconfiguracin,
entreotras?
Cmopuedeserlaaplicacindiseadaparaserflexibleyfcildemantener
eneltiempo?
Culessonlastendenciasarquitectnicasquepuedanafectarasu
aplicacinahoraodespusquesehaimplementado?
Mantengaenmentequedebe:

Exponerlaestructuradelsistema,peroocultarlosdetallesdeimplementacin.
Llevaracabolarealizacindetodosloscasosdeusoyescenarios.
Tratarderesponderalasnecesidadesdelosdiversosgruposdeinters (stakeholders).
Manejartantoslosrequisitosdefuncionalescomocalidad.

prof.G.Badillo,2014_1

57

Considerelassiguientestendenciasclave:
Empoderamiento delusuario.Diseoflexible,configurable,ycentradoenla
experienciadelusuario.Diseesusaplicacionesconlosnivelesadecuadosde
personalizacindeusuario.Permitaalusuariodefinirlaformaenque
interactanconsuaplicacin,nosobrecargueconopcionesinnecesariasy
ajustesquepuedenllevaraconfusin.
Lamadurezdelmercado.Tomeventajadelamadurezdelmercadomediante
elaprovechamientodeopcionesdeplataformaytecnologaexistentes.Basarse
enlosentornosdeaplicacionesdemsaltoniveldondetienesentido,demodo
queustedpuedacentrarseenloqueesunvalornicoensuaplicacinenlugar
devolveracrearalgoqueyaexisteysepuedevolverautilizar.Utilicepatrones
queproporcionanunaricafuentedesolucionesprobadasaproblemascomunes.
Diseoflexible.Cadavezms,losdiseosflexiblesaprovechanelacoplamiento
flexibleparapermitirlareutilizacinyparamejorarlamantenibilidad .Tambin
puedetomarventajadelastcnicasdeorientacindeserviciotalescomoSOA
paraproporcionarinteroperabilidadconotrossistemas.
Lastendenciasfuturas.Cuandoconstruyasuarquitectura,entiendaquelas
tendenciasfuturaspuedenafectarsudiseodespusdelaimplementacin.
prof.G.Badillo,2014_1

58

Considerelossiguientesobjetivosdelaarquitectura
La arquitectura de software busca construir un puente entre las
necesidades de negocio y los requerimientos tcnicos mediante la
comprensin de los casos de uso, y luego encontrar la forma de
aplicarlos en el software.
La buena arquitectura reduce los riesgos de negocio asociados a la
construccin de una solucin tcnica.
Un buen diseo es suficientemente flexible, cuando es capaz de
manejar la deriva natural que se producir con el tiempo en el
hardware y software, as como en escenarios y necesidades de los
usuarios.
Un arquitecto debe tener en cuenta el efecto total de las decisiones de
diseo, las inherentes ventajas y desventajas entre los atributos de
calidad (como el rendimiento y la seguridad), y las compensaciones
necesarias para hacer atender las necesidades de los usuarios, el
sistema y los requerimientos del negocio.

prof.G.Badillo,2014_1

59

Todaslasfuerzasqueinfluyeneneldiseola
arquitectura,

60

ref:SEI,www.sei.cmu.edu/library/abstracts/newsatsei/architect20052.cfm

Vistageneraldelmtododediseoindustrializado

prof.G.Badillo,2014_1

61

MagisterenIngenieraInformtica

ArquitecturadeSoftware
ii.ConceptualizandolaArquitecturadeSoftware
Prof.GuillermoE.BadilloAstudillo
SemestreI,2014