Introducción a La Arquitectura de Software Por Carlos Billy Reynoso

7/21/2019 Introduccin a La Arquitectura de Software Por Carlos Billy Reynoso

1/53

Introduccin a la Arquitectura de Software

Contenidos:

Introduccin Breve Historia de la Arquitectura de Software Definiciones Conceptos fundamentales

Estilos

Lenguajes de descripcin arquitectnica

Frameworks y VistasProcesos y Metodologas

Abstraccin

Escenarios

Campos de la Arquitectura de Software Modalidades y tendencias Diferencias entre Arquitectura y Diseo Repositorios Problemas abiertos en Arquitectura de Software Relevancia de la Arquitectura de Software Referencias bibliogrficas
http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#7#7http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#7#7http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#7#7


2/53


3/53


4/53

Existe entonces espacio y oportunidad para comenzar a articular esas referencias

pendientes, de una manera que contribuya a situar esa estrategia particular

(MSF+Patrones) en el marco de las tendencias actuales de teora y prctica

arquitectnica. Sin que estos documentos expresen una visin oficial, nos parece

til llenar el vaco, tender un puente, entre la investigacin bsica y los aportes

acadmicos por un lado y las visiones y requerimientos de industria por el otro. Lo

que aqu ha de hacerse es otorgar contenidos, aunque sean provisionales y

contestables, al concepto de Arquitectura de Software, dado que cada vez que

aparece en la documentacin de industria se da por sentado lo que esa expresin

significa.

El presente estudio constituye entonces el captulo introductorio a una visin deconjunto de la AS, articulada conforme a este temario:

1. Arquitectura de Software

1.1. Antecedentes histricos1.2. Definiciones y delimitacin de la disciplina1.3. Conceptos fundamentales1.4. Campos de la Arquitectura de Software1.5. Modalidades y tendencias1.6. Diferencias entre Arquitectura y Diseo

1.7. Repositorios1.8. Problemas pendientes en Arquitectura de Software1.9. Relevancia de la Arquitectura de Software1.10. (Referencias bibliogrficas)

2. Estilos de Arquitectura

2.1. Definiciones de estilo

2.2. Clasificaciones de estilos arquitectnicos

2.3. Inventario y Descripcin de estilos arquitectnicos

2.4. Estilos y patrones de arquitectura y diseo2.5. El lugar de los estilos en los marcos de referencia y en las vistas

arquitectnicas

2.6. Los estilos como valor contable

2.7. (Referencias bibliogrficas)

3. Lenguajes de descripcin arquitectnica (ADLs)

3.1. Introduccin a los ADLs3.2. Criterios de definicin de un ADL

3.3. Lenguajes: Acme / Armani ADLs: Acme /Armani ADML Aesop ArTek C2SADL CHAM Darwin Jacal LILEANNA MetaH / AADL Rapide UML UniCon Wright xArch / xADL


5/53

3.4. Modelos computacionales y paradigmas de modelado3.5. ADLs y Patrones3.6. (Referencias bibliogrficas)4. Modelos de proceso y diseo4.1. Mtodos tradicionales y de peso completo CMM, UPM4.2. Mtodos basados en arquitectura

4.2.1. Mtodos de anlisis y diseo en el ciclo de vida Visin general4.2.2. Arquitectura basada en escenarios (FAAM, ALMA)4.2.3. El diseo arquitectnico en el ciclo de vida: ABD4.2.4. Active Review for Intermediate Design (ARID)4.2.5. Quality Attribute Workshops (QAW) - QASAR4.2.6. Attribute-Driven Design (ADD)4.2.7. Evaluacin: Architecture Tradeoff Analysis Method (ATAM)4.2.8. Mtodos de evaluacin de opciones arquitectnicas (SACAM)4.2.9. Derivacin de tcticas arquitectnicas4.2.10. Economa de la arquitectura: Cost-Benefits Analysis Method (CBAM)4.2.11. Documentacin de la Arquitectura4.3. Mtodos heterodoxos y de peso ligero: Mtodos Agiles, Programacin Extrema

Concepcin cardica de los sistemas complejos4.4. Relacin de los mtodos LW con MSF 3 y con las metodologas basadas enarquitectura.5. Herramientas arquitectnicas5.1. El lugar de UML 1.x y 2.0 en arquitectura de software Alcances y limitaciones5.2. Herramientas de diseo y anlisis asociadas a ADLs5.3. Herramientas de Anlisis, Evaluacin y Visualizacin (SAAMTool, AET yanlogas)5.4. Herramientas de recuperacin y visualizacin de arquitectura5.5. Herramientas auxiliares de integracin (MBI)5.6. Servicios, plantillas y herramientas arquitectnicas en VS .NET Architect6. Prcticas de diseo sobre arquitecturas orientadas a servicios y modelos de

integracinEl presente documento cubre los puntos 1.1 a 1.9 del plan de tratamiento del tema.

Ya se encuentran disponibles documentos que cubren los temas 2 (estilos de

arquitectura) y 3 (lenguajes de descripcin arquitectnica). Los dems elementos

del itinerario estn en proceso de elaboracin y se irn publicando a medida que

estn listos.

El propsito de la totalidad del estudio consiste en establecer las bases para una

discusin terica y los fundamentos para una puesta en prctica de un modelo dediseo y desarrollo basado en arquitectura, ya que a pesar de la buena imagen de

la disciplina, sus aportes sustantivos permanecen desconocidos para una mayora

de los ingenieros y metodlogos de software. Dado que estos documentos se

presentan como punto de partida para la discusin de estos temas para la

comunidad de arquitectos, despus de la presentacin de cada tpico se formula

invitacin para desarrollar los mismos contenidos desde otras perspectivas, aportar

elementos de juicio adicionales, suministrar referencias de casos, corregir lagunas,

agregar vnculos, difundir investigaciones relacionadas, compensar los sesgos,

refinar el debate o enriquecer los materiales que aqu comienzan.


6/53

Arriba

Breve Historia de la Arquitectura de Software

Todava no se ha escrito una historia aceptable de la AS. Desde que Mary Shaw o

David Garlan researan escuetamente la prehistoria de la especialidad a principios

de los 90, los mismos prrafos han sido reutilizados una y otra vez en la literatura,

sin mayor exploracin de las fuentes referidas en la resea primaria y con prisa por

ir al grano, que usualmente no es de carcter histrico. En este estudio se ha

optado, ms bien, por inspeccionar las fuentes ms de cerca, con el objeto de

sealar las supervivencias y las re-semantizaciones que han experimentado las

ideas fundadoras en la AS contempornea, definir con mayor claridad el contexto,entender que muchas contribuciones que pasaron por complementarias han sido en

realidad antagnicas y comprender mejor por qu algunas ideas que surgieron hace

cuatro dcadas demoraron un cuarto de siglo en materializarse.

Esta decisin involucra algo ms que el perfeccionamiento de la lectura que pueda

hacerse de un conjunto de acontecimientos curiosos. Las formas divergentes en

que se han interpretado dichas ideas, despus de todo, permiten distinguir

corrientes de pensamiento diversas, cuyas diferencias distan de ser triviales a lahora de plasmar las ideas en una metodologa. Todo lo que parece ser un simple

elemento de juicio, no pocas veces implica una disyuntiva. Situar las inflexiones de

la breve historia de la AS en un contexto temporal, asimismo, ayudar a

comprender mejor cules son sus contribuciones perdurables y cules sus

manifestaciones contingentes al espritu de los tiempos y a las modas tecnolgicas

que se han ido sucediendo.

Si bien la AS acostumbra remontar sus antecedentes al menos hasta la dcada de

1960, su historia no ha sido tan continua como la del campo ms amplio en el que

se inscribe, la ingeniera de software [Pfl02] [Pre01]. Despus de las tempranas

inspiraciones del legendario Edsger Dijkstra, de David Parnas y de Fred Brooks, la

AS qued en estado de vida latente durante unos cuantos aos, hasta comenzar su

expansin explosiva con los manifiestos de Dewayne Perry de AT&T Bell

Laboratories de New Jersey y Alexander Wolf de la Universidad de Colorado

[PW92]. Puede decirse que Perry y Wolf fundaron la disciplina, y su llamamiento fue

respondido en primera instancia por los miembros de lo que podra llamarse la

escuela estructuralista de Carnegie Mellon: David Garlan, Mary Shaw, Paul
http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#top#tophttp://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#top#tophttp://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#top#top


7/53

Clements, Robert Allen.

Se trata entonces de una prctica joven, de apenas unos doce aos de trabajo

constante, que en estos momentos experimenta una nueva ola creativa en el

desarrollo cabal de sus tcnicas en la obra de Rick Kazman, Mark Klein, Len Bass y

otros metodlogos en el contexto del SEI, en la misma universidad. A comienzos

del siglo XXI comienzan ya a discernirse tendencias, cuyas desavenencias mutuas

todava son leves: al menos una en el sur de California (Irvine y Los ngeles) con

Nenad Medvidovic, David Rosenblum y Richard Taylor, otra en el SRI de Menlo Park

con Mark Moriconi y sus colegas y otra ms vinculada a las recomendaciones

formales de la IEEE y los trabajos de Rich Hilliard. Hoy se percibe tambin un

conjunto de posturas europeas que enfatizan mayormente cuestiones

metodolgicas vinculadas con escenarios y procuran inscribir la arquitectura de

software en el ciclo de vida, comenzando por la elicitacin de los requerimientos.Antes de Perry y Wolf, empero, se formularon ideas que seran fundamentales para

la disciplina ulterior. Comencemos entonces por el principio, aunque siempre cabr

la posibilidad de discutir cul puede haber sido el momento preciso en el que todo

comenz.

Cada vez que se narra la historia de la arquitectura de software (o de la ingeniera

de software, segn el caso), se reconoce que en un principio, hacia 1968, Edsger

Dijkstra, de la Universidad Tecnolgica de Eindhoven en Holanda y Premio Turing1972, propuso que se establezca una estructuracin correcta de los sistemas de

software antes de lanzarse a programar, escribiendo cdigo de cualquier manera

[Dij68a]. Dijkstra, quien sostena que las ciencias de la computacin eran una rama

aplicada de las matemticas y sugera seguir pasos formales para descomponer

problemas mayores, fue uno de los introductores de la nocin de sistemas

operativos organizados en capas que se comunican slo con las capas adyacentes y

que se superponen como capas de cebolla. Invent o ayud a precisar adems

docenas de conceptos: el algoritmo del camino ms corto, los stacks, los vectores,

los semforos, los abrazos mortales. De sus ensayos arranca la tradicin de hacer

referencia a niveles de abstraccin que ha sido tan comn en la arquitectura

subsiguiente. Aunque Dijkstra no utiliza el trmino arquitectura para describir el

diseo conceptual del software, sus conceptos sientan las bases para lo que luego

expresaran Niklaus Wirth [Wir71] como stepwise refinement y DeRemer y Kron

[DK76] como programming-in-the large (o programacin en grande), ideas que

poco a poco iran decantando entre los ingenieros primero y los arquitectos

despus.


8/53

En la conferencia de la NATO de 1969, un ao despus de la sesin en que se

fundara la ingeniera de software, P. I. Sharp formul estas sorprendentes

apreciaciones comentando las ideas de Dijkstra:

Pienso que tenemos algo, aparte de la ingeniera de software: algo de lo que hemoshablado muy poco pero que deberamos poner sobre el tapete y concentrar laatencin en ello. Es la cuestin de la arquitectura de software. La arquitectura esdiferente de la ingeniera. Como ejemplo de lo que quiero decir, echemos unamirada a OS/360. Partes de OS/360 estn extremadamente bien codificadas. Partesde OS, si vamos al detalle, han utilizado tcnicas que hemos acordado constituyenbuena prctica de programacin. La razn de que OS sea un amontonamientoamorfo de programas es que no tuvo arquitecto. Su diseo fue delegado a series degrupos de ingenieros, cada uno de los cuales invent su propia arquitectura. Ycuando esos pedazos se clavaron todos juntos no produjeron una tersa y bellapieza de software [NATO76: 150].

Sharp contina su alegacin afirmando que con el tiempo probablemente llegue a

hablarse de la escuela de arquitectura de software de Dijkstra y se lamenta que

en la industria de su tiempo se preste tan poca o ninguna atencin a la

arquitectura. La frase siguiente tambin es extremadamente visionaria:

Lo que sucede es que las especificaciones de software se consideranespecificaciones funcionales. Slo hablamos sobre lo que queremos que haga elprograma. Es mi creencia que cualquiera que sea responsable de la implementacinde una pieza de software debe especificar ms que esto. Debe especificar el diseo,la forma; y dentro de ese marco de referencia, los programadores e ingenierosdeben crear algo. Ningn ingeniero o programador, ninguna herramienta deprogramacin, nos ayudar, o ayudar al negocio del software, a maquillar undiseo feo. El control, la administracin, la educacin y todas las cosas buenas delas que hablamos son importantes; pero la gente que implementa debe entender loque el arquitecto tiene en mente [dem].

Nadie volvi a hablar del asunto en esa conferencia, sin embargo. Por unos aos,

arquitectura fue una metfora de la que se ech mano cada tanto, pero sin

precisin semntica ni consistencia pragmtica. En 1969 Fred Brooks Jr y Ken

Iverson llamaban arquitectura a la estructura conceptual de un sistema en la

perspectiva del programador. En 1971, C. R. Spooner titul uno de sus ensayos

Una arquitectura de software para los 70s [Spo71], sin que la mayor parte de lahistoriografa de la AS registrara ese antecedente.

En 1975, Brooks, diseador del sistema operativo OS/360 y Premio Turing 2000,

utilizaba el concepto de arquitectura del sistema para designar la especificacin

completa y detallada de la interfaz de usuario y consideraba que el arquitecto es

un agente del usuario, igual que lo es quien disea su casa [Bro75], empleando una

nomenclatura que ya nadie aplica de ese modo. En el mismo texto, identificaba y

razonaba sobre las estructuras de alto nivel y reconoca la importancia de las

decisiones tomadas a ese nivel de diseo. Tambin distingua entre arquitectura e


9/53

implementacin; mientras aquella deca qu hacer, la implementacin se ocupa de

cmo. Aunque el concepto de AS actual y el de Brooks difieren en no escasa

medida, el texto de Brooks The mythical man-month sigue siendo, un cuarto de

siglo ms tarde, el ms ledo en ingeniera de software. Se ha sealado que Dijkstra

y Brooks, el primero partidario de un formalismo matemtico y el segundo de

considerar las variables humanas, constituyen dos personalidades opuestas, que se

sitan en los orgenes de las metodologas fuertes y de las heterodoxias giles,

respectivamente [Tra02]; pero eso ser otra historia.

Una novedad importante en la dcada de 1970 fue el advenimiento del diseo

estructurado y de los primeros modelos explcitos de desarrollo de software. Estos

modelos comenzaron a basarse en una estrategia ms orgnica, evolutiva, cclica,

dejando atrs las metforas del desarrollo en cascada que se inspiraban ms bienen la lnea de montaje de la ingeniera del hardware y la manufactura. Surgieron

entonces las primeras investigaciones acadmicas en materia de diseo de

sistemas complejos o intensivos. Poco a poco el diseo se fue independizando de

la implementacin, y se forjaron herramientas, tcnicas y lenguajes de modelado

especficos.

En la misma poca, otro precursor importante, David Parnas, demostr que los

criterios seleccionados en la descomposicin de un sistema impactan en laestructura de los programas y propuso diversos principios de diseo que deban

seguirse a fin de obtener una estructura adecuada. Parnas desarroll temas tales

como mdulos con ocultamiento de informacin [Par72], estructuras de software

[Par74] y familias de programas [Par76], enfatizando siempre la bsqueda de

calidad del software, medible en trminos de economas en los procesos de

desarrollo y mantenimiento. Aunque Dijkstra, con sus frases lapidarias y

memorables, se ha convertido en la figura legendaria por excelencia de los mitos de

origen de la AS, Parnas ha sido sin duda el introductor de algunas de sus nociones

ms esenciales y permanentes.

En 1972, Parnas public un ensayo en el que discuta la forma en que la

modularidad en el diseo de sistemas poda mejorar la flexibilidad y el control

conceptual del sistema, acortando los tiempos de desarrollo [Par72]. Introdujo

entonces el concepto de ocultamiento de informacin (information hiding), uno de

los principios de diseo fundamentales en diseo de software an en la actualidad.

La herencia de este concepto en la ingeniera y la arquitectura ulterior es inmensa,

y se confunde estrechamente con la idea de abstraccin. En la segunda de las


10/53

descomposiciones que propone Parnas comienza a utilizarse el ocultamiento de

informacin como criterio. Los mdulos ya no se corresponden con las etapas de

procesamiento. ? Cada mdulo en la segunda descomposicin se caracteriza por su

conocimiento de una decisin de diseo oculta para todos los otros mdulos. Su

interfaz o definicin se escoge para que revele tan poco como sea posible sobre su

forma interna de trabajo [Par72]. Cada mdulo deviene entonces una caja negra

para los dems mdulos del sistema, los cuales podrn acceder a aqul a travs de

interfaces bien definidas, en gran medida invariables. Es fcil reconocer en este

principio ideas ya presentadas por Dijkstra en su implementacin del THE-

Multiprogramming System [Dij68a]. Pero la significacin del artculo de 1972 radica

en la idea de Parnas de basar la tcnica de modularizacin en decisiones de diseo,

mientras que los niveles de abstraccin de Dijkstra involucraban ms bien (igual

que su famosa invectiva en contra del Go-to) tcnicas de programacin.

El concepto de ocultamiento se fue mezclando con encapsulamiento y abstraccin,

tras algunos avatares de avance y retroceso. Los arquitectos ms escrupulosos

distinguen entre encapsulamiento y ocultamiento, considerando a aqul como una

capacidad de los lenguajes de programacin y a ste como un principio ms general

de diseo. De hecho, Parnas no hablaba en trminos de programacin orientada a

objeto, sino de mdulos y sub-rutinas, porque el momento de los objetos no haba

llegado todava.El pensamiento de Parnas sobre familias de programas, en particular, anticipa ideas

que luego habran de desarrollarse a propsito de los estilos de arquitectura:

Una familia de programas es un conjunto de programas (no todos los cuales hansido construidos o lo sern alguna vez) a los cuales es provechoso o til considerarcomo grupo. Esto evita el uso de conceptos ambiguos tales como similitudfuncional que surgen a veces cuando se describen dominios. Por ejemplo, losambientes de ingeniera de software y los juegos de video no se consideranusualmente en el mismo dominio, aunque podran considerarse miembros de lamisma familia de programas en una discusin sobre herramientas que ayuden aconstruir interfaces grficas, que casualmente ambos utilizan.

Una familia de programas puede enumerarse en principio mediante la especificacin

del rbol de decisin que se atraviesa para llegar a cada miembro de la familia. Las

hojas del rbol representan sistemas ejecutables. El concepto soporta la nocin de

derivar un miembro de la familia a partir de uno ya existente. El procedimiento

consiste en seguir hacia atrs el rbol hasta que se alcanza un nodo (punto de

decisin) genealgicamente comn a ambos, y luego proceder hacia abajo hasta

llegar al miembro deseado. El concepto tambin soporta la nocin de derivar varios

miembros de la familia de un punto de decisin comn, aclarando la semejanza ylas diferencias entre ellos.


11/53

Las decisiones iniciales son las que ms probablemente permanecern constantes

entre los miembros; las decisiones ms tardas (cerca de las hojas) en un rbol

prudentemente estructurado deberan representar decisiones susceptibles de

cambiarse trivialmente, tales como los valores de tiempo de compilacin o las

constantes de tiempo de carga. La significacin del concepto de familia de

programas para la AS es que ella corresponde a las decisiones cerca del tope del

rbol de decisin de Parnas. Es importante considerar que el rbol de Parnas es

top-down no slo porque se construye y recorre de lo general a lo particular, sino

porque sus races se encuentran hacia arriba (o a la izquierda si el modelo es

horizontal). No menos esencial es tener en cuenta que el rbol se ofreci como

alternativa a mtodos de descomposicin basados en diagramas de flujo, por los

que la AS no ha mostrado nunca demasiada propensin.

Deca Parnas que las decisiones tempranas de desarrollo seran las que

probablemente permaneceran invariantes en el desarrollo ulterior de una solucin.

Esas decisiones tempranas constituyen de hecho lo que hoy se llamaran

decisiones arquitectnicas. Como escriben Clements y Northrop [CN96] en todo el

desenvolvimiento ulterior de la disciplina permanecera en primer plano esta misma

idea: la estructura es primordial (structure matters), y la eleccin de la estructura

correcta ha de ser crtica para el xito del desarrollo de una solucin. Ni duda cabeque la eleccin de la estructura correcta sintetiza, como ninguna otra expresin,

el programa y la razn de ser de la AS.

En la dcada de 1980, los mtodos de desarrollo estructurado demostraron no

escalar suficientemente y fueron dejando el lugar a un nuevo paradigma, el de la

programacin orientada a objetos. En teora, pareca posible modelar el dominio del

problema y el de la solucin en un lenguaje de implementacin. La investigacin

que llev a lo que despus sera el diseo orientado a objetos puede remontarse

incluso a la dcada de 1960 con Simula, un lenguaje de programacin de

simulaciones, el primero que proporcionaba tipos de datos abstractos y clases, y

despus fue refinada con el advenimiento de Smalltalk. Paralelamente, hacia fines

de la dcada de 1980 y comienzos de la siguiente, la expresin arquitectura de

software comienza a aparecer en la literatura para hacer referencia a la

configuracin morfolgica de una aplicacin.

Mientras se considera que la ingeniera de software se fund en 1968, cuando F.L.

Bauer us ese sintagma por primera vez en la conferencia de la OTAN de Garmisch,


12/53

Alemania, la AS, como disciplina bien delimitada, es mucho ms nueva de lo que

generalmente se sospecha. El primer texto que vuelve a reivindicar las

abstracciones de alto nivel, reclamando un espacio para esa reflexin y augurando

que el uso de esas abstracciones en el proceso de desarrollo pueden resultar en un

nivel de arquitectura de software en el diseo es uno de Mary Shaw [Shaw84]

seguido por otro llamado Larger scale systems require higher level abstractions

[Shaw89]. Se hablaba entonces de un nivel de abstraccin en el conjunto; todava

no estaban en su lugar los elementos de juicio que permitieran reclamar la

necesidad de una disciplina y una profesin particulares.

El primer estudio en que aparece la expresin arquitectura de software en el

sentido en que hoy lo conocemos es sin duda el de Perry y Wolf [PW92]; ocurri

tan tarde como en 1992, aunque el trabajo se fue gestando desde 1989. En l, los

autores proponen concebir la AS por analoga con la arquitectura de edificios, unaanaloga de la que luego algunos abusaron [WWI99], otros encontraron til y para

unos pocos ha devenido inaceptable [BR01]. El artculo comienza diciendo

exactamente:

El propsito de este paper es construir el fundamento para la arquitectura desoftware. Primero desarrollaremos una intuicin para la arquitectura de softwarerecurriendo a diversas disciplinas arquitectnicas bien definidas. Sobre la base deesa intuicin, presentamos un modelo para la arquitectura de software que consisteen tres componentes: elementos, forma y razn (rationale). Los elementos sonelementos ya sea de procesamiento, datos o conexin. La forma se define entrminos de las propiedades de, y las relaciones entre, los elementos, es decir,restricciones operadas sobre ellos. La razn proporciona una base subyacente parala arquitectura en trminos de las restricciones del sistema, que lo ms frecuentees que se deriven de los requerimientos del sistema. Discutimos los componentesdel modelo en el contexto tanto de la arquitectura como de los estilosarquitectnicos....

La declaracin, como puede verse, no tiene una palabra de desperdicio: cada idea

cuenta, cada intuicin ha permanecido viva desde entonces. Los autores prosiguen

reseando el progreso de las tcnicas de diseo en la dcada de 1970, en la que los

investigadores pusieron en claro que el diseo es una actividad separada de laimplementacin y que requiere notaciones, tcnicas y herramientas especiales. Los

resultados de esta investigacin comienzan ahora (decan en 1992) a penetrar el

mercado en la forma de herramientas de ingeniera asistida por computadoras,

CASE. Pero uno de los resultados del uso de estas herramientas ha sido que se

produjo la absorcin de las herramientas de diseo por los lenguajes de

implementacin. Esta integracin ha tendido a esfumar, si es que no a confundir, la

diferencia entre diseo e implementacin. En la dcada de 1980 se perfeccionaron

las tcnicas descriptivas y las notaciones formales, permitindonos razonar mejor

sobre los sistemas de software. Para la caracterizacin de lo que suceder en la


13/53

dcada siguiente ellos formulan esta otra frase que ha quedado inscripta en la

historia mayor de la especialidad:

La dcada de 1990, creemos, ser la dcada de la arquitectura de software.Usamos el trmino arquitectura en contraste con diseo, para evocar nociones

de codificacin, de abstraccin, de estndares, de entrenamiento formal (de losarquitectos de software) y de estilo. ? Es tiempo de re-examinar el papel de laarquitectura de software en el contexto ms amplio del proceso de software y de suadministracin, as como sealar las nuevas tcnicas que han sido adoptadas.

Considerada como disciplina por mrito propio, la AS ha de ser, para ellos,

beneficiosa como marco de referencia para satisfacer requerimientos, una base

esencial para la estimacin de costos y administracin del proceso y para el anlisis

de las dependencias y la consistencia del sistema.

Dando cumplimiento a las profecas de Perry y Wolf, la dcada de 1990 fue sinduda la de la consolidacin y diseminacin de la AS en una escala sin precedentes.

Las contribuciones ms importantes surgieron en torno del instituto de ingeniera

de la informacin de la Universidad Carnegie Mellon (CMU SEI), antes que de

cualesquiera organismos de industria. En la misma dcada, demasiado prdiga en

acontecimientos, surge tambin la programacin basada en componentes, que en

su momento de mayor impacto impuls a algunos arquitectos mayores, como Paul

Clements [Cle96b], a afirmar que la AS promova un modelo que deba ser ms de

integracin de componentes pre-programados que de programacin.

Un segundo gran tema de la poca fue el surgimiento de los patrones, cristalizada

en dos textos fundamentales, el de la Banda de los Cuatro en 1995 [Gof95] y la

serie POSA desde 1996 [BMR+96]. El primero de ellos promueve una expansin de

la programacin orientada a objetos, mientras que el segundo desenvuelve un

marco ligeramente ms ligado a la AS. Este movimiento no ha hecho ms que

expandirse desde entonces. El originador de la idea de patrones fue Christopher

Alexander, quien incidentalmente fue arquitecto de edificios; Alexander desarroll

en diversos estudios de la dcada de 1970 temas de anlisis del sentido de los

planos, las formas, la edificacin y la construccin, en procura de un modelo

constructivo y humano de arquitectura, elaborada de forma que tenga en cuenta

las necesidades de los habitantes [Ale77]. El arquitecto (y puede copiarse aqu lo

que deca Fred Brooks) debe ser un agente del usuario.

A lo largo de una cadena de intermediarios y pensadores originales, las ideas

llegaron por fin a la informtica diez aos ms tarde. Si bien la idea de arquitectura

implcita en el trabajo actual con patrones est ms cerca de la implementacin y el


14/53

cdigo, y aunque la reutilizacin de patrones guarda estrecha relacin con la

tradicin del diseo concreto orientado a objetos [Lar03], algunos arquitectos

emanados de la escuela de Carnegie Mellon formalizaron un acercamiento con esa

estrategia [Shaw96] [MKM+96] [MKM+97]. Tanto en los patrones como en la

arquitectura, la idea dominante es la de re-utilizacin. A impulsos de otra idea

mayor de la poca (la crisis del software), la bibliografa sobre el impacto

econmico de la re-utilizacin alcanza hoy magnitudes de cuatro dgitos.

Como quiera que sea, la AS de este perodo realiz su trabajo de homogeneizacin

de la terminologa, desarroll la tipificacin de los estilos arquitectnicos y elabor

lenguajes de descripcin de arquitectura (ADLs), temas que en este estudio se

tratan en documentos separados. Tambin se consolid la concepcin de las vistas

arquitectnicas, reconocidas en todos y cada uno de los frameworksgeneralizadores que se han propuesto (4+1, TOGAF, RM/ODP, IEEE), como luego

se ver.

Uno de los acontecimientos arquitectnicos ms importantes del ao 2000 fue la

hoy clebre tesis de Roy Fielding que present el modelo REST, el cual establece

definitivamente el tema de las tecnologas de Internet y los modelos orientados a

servicios y recursos en el centro de las preocupaciones de la disciplina [Fie00]. En

el mismo ao se publica la versin definitiva de la recomendacin IEEE Std 1471,que procura homogeneizar y ordenar la nomenclatura de descripcin arquitectnica

y homologa los estilos como un modelo fundamental de representacin conceptual.

En el siglo XXI, la AS aparece dominada por estrategias orientadas a lneas de

productos y por establecer modalidades de anlisis, diseo, verificacin,

refinamiento, recuperacin, diseo basado en escenarios, estudios de casos y hasta

justificacin econmica, redefiniendo todas las metodologas ligadas al ciclo de vida

en trminos arquitectnicos. Todo lo que se ha hecho en ingeniera debe formularse

de nuevo, integrando la AS en el conjunto. La produccin de estas nuevas

metodologas ha sido masiva, y una vez ms tiene como epicentro el trabajo del

Software Engineering Institute en Carnegie Mellon. La aparicin de las metodologas

basadas en arquitectura, junto con la popularizacin de los mtodos giles en

general y Extreme Programming en particular, han causado un reordenamiento del

campo de los mtodos, hasta entonces dominados por las estrategias de diseo de

peso pesado. Despus de la AS y de las tcticas radicales, las metodologas nunca

volvern a ser las mismas.


15/53

La semblanza que se ha trazado no es ms que una visin selectiva de las etapas

recorridas por la AS. Los lineamientos de ese proceso podran dibujarse de maneras

distintas, ya sea enfatizando los hallazgos formales, las intuiciones dominantes de

cada perodo o las diferencias que median entre la abstraccin cualitativa de la

arquitectura y las cuantificaciones que han sido la norma en ingeniera de software.

Arriba

Definiciones

No es novedad que ninguna definicin de la AS es respaldada unnimemente por la

totalidad de los arquitectos. El nmero de definiciones circulantes alcanza un ordende tres dgitos, amenazando llegar a cuatro. De hecho, existen grandes

compilaciones de definiciones alternativas o contrapuestas, como la coleccin que

se encuentra en el SEI (http://www.sei.cmu.edu/architecture/definitions.html ), a la

que cada quien puede agregar la suya. En general, las definiciones entremezclan

despreocupadamente (1) el trabajo dinmico de estipulacin de la arquitectura

dentro del proceso de ingeniera o el diseo (su lugar en el ciclo de vida), (2) la

configuracin o topologa esttica de sistemas de software contemplada desde un

elevado nivel de abstraccin y (3) la caracterizacin de la disciplina que se ocupa

de uno de esos dos asuntos, o de ambos.

Una definicin reconocida es la de Clements [Cle96a]: La AS es, a grandes rasgos,

una vista del sistema que incluye los componentes principales del mismo, la

conducta de esos componentes segn se la percibe desde el resto del sistema y las

formas en que los componentes interactan y se coordinan para alcanzar la misin

del sistema. La vista arquitectnica es una vista abstracta, aportando el ms alto

nivel de comprensin y la supresin o diferimiento del detalle inherente a la mayor

parte de las abstracciones.

En una definicin semejante, hay que aclararlo, la idea de componente no es la

de la correspondiente tecnologa de desarrollo (COM, CORBA Component Model,

EJB), sino la de elemento propio de un estilo. Un componente es una cosa, una

entidad, a la que los arquitectos prefieren llamar componente antes que objeto,

por razones que se vern en otros documentos de esta serie pero que ya es obvio

imaginar cules han de ser.

A despecho de la abundancia de definiciones del campo de la AS, existe en general
http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#top#tophttp://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#top#tophttp://www.sei.cmu.edu/architecture/definitions.htmlhttp://www.sei.cmu.edu/architecture/definitions.htmlhttp://www.sei.cmu.edu/architecture/definitions.htmlhttp://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#top#top


16/53

acuerdo de que ella se refiere a la estructura a grandes rasgos del sistema,

estructura consistente en componentes y relaciones entre ellos [BCK98]. Estas

cuestiones estructurales se vinculan con el diseo, pues la AS es despus de todo

una forma de diseo de software que se manifiesta tempranamente en el proceso

de creacin de un sistema; pero este diseo ocurre a un nivel ms abstracto que el

de los algoritmos y las estructuras de datos. En el que muchos consideran un

ensayo seminal de la disciplina, Mary Shaw y David Garlan sugieren que dichas

cuestiones estructurales incluyen organizacin a grandes rasgos y estructura global

de control; protocolos para la comunicacin, la sincronizacin y el acceso a datos;

la asignacin de funcionalidad a elementos del diseo; la distribucin fsica; la

composicin de los elementos de diseo; escalabilidad y rendimiento; y seleccin

entre alternativas de diseo [GS94].

En una definicin tal vez demasiado amplia, David Garlan [Gar00] establece que la

AS constituye un puente entre el requerimiento y el cdigo, ocupando el lugar que

en los grficos antiguos se reservaba para el diseo. La definicin oficial de AS se

ha acordado que sea la que brinda el documento de IEEE Std 1471-2000, adoptada

tambin por Microsoft, que reza as:

La Arquitectura de Software es la organizacin fundamental de un sistemaencarnada en sus componentes, las relaciones entre ellos y el ambiente y losprincipios que orientan su diseo y evolucin.

Aunque las literaturas de ambos campos rara vez convergen, entendemos que es

productivo contrastar esa definicin con la de ingeniera de software, conforme al

estndar IEEE 610.12.1990:

La aplicacin de una estrategia sistemtica, disciplinada y cuantificable aldesarrollo, aplicacin y mantenimiento del software; esto es, la aplicacin de laingeniera al software.

Obsrvese entonces que la nocin clave de la arquitectura es la organizacin (un

concepto cualitativo o estructural), mientras que la ingeniera tiene

fundamentalmente que ver con una sistematicidad susceptible de cuantificarse.

Antes el nmero y variedad de definiciones existentes de AS, Mary Shaw y David

Garlan [SG95] proporcionaron una sistematizacin iluminadora, explicando las

diferencias entre definiciones en funcin de distintas clases de modelos. Destilando

las definiciones y los puntos de vista implcitos o explcitos, los autores clasifican los

modelos de esta forma:

1) Modelos estructurales:Sostienen que la AS est compuesta porcomponentes, conexiones entre ellos y (usualmente) otros aspectos tales comoconfiguracin, estilo, restricciones, semntica, anlisis, propiedades,


17/53

racionalizaciones, requerimientos, necesidades de los participantes. El trabajo enesta rea est caracterizada por el desarrollo de lenguajes de descripcinarquitectnica (ADLs).

2) Modelos de framework:Son similares a la vista estructural, pero su nfasisprimario radica en la (usualmente una sola) estructura coherente del sistema

completo, en vez de concentrarse en su composicin. Los modelos de framework amenudo se refieren a dominios o clases de problemas especficos. El trabajo queejemplifica esta variante incluye arquitecturas de software especficas de dominios,como CORBA, o modelos basados en CORBA, o repositorios de componentesespecficos, como PRISM.3) Modelos dinmicos:Enfatizan la cualidad conductual de los sistemas.Dinmico puede referirse a los cambios en la configuracin del sistema, o a ladinmica involucrada en el progreso de la computacin, tales como valorescambiantes de datos.4) Modelos de proceso:Se concentran en la construccin de la arquitectura, y enlos pasos o procesos involucrados en esa construccin. En esta perspectiva, laarquitectura es el resultado de seguir un argumento (script) de proceso. Esta vista

se ejemplifica con el actual trabajo sobre programacin de procesos para derivararquitecturas.5) Modelos funcionales:Una minora considera la arquitectura como un conjuntode componentes funcionales, organizados en capas que proporcionan servicioshacia arriba. Es tal vez til pensar en esta visin como un framework particular.Ninguna de estas vistas excluye a las otras, ni representa un conflicto fundamentalsobre lo que es o debe ser la AS. Por el contrario, representan un espectro en lacomunidad de investigacin sobre distintos nfasis que pueden aplicarse a laarquitectura: sobre sus partes constituyentes, su totalidad, la forma en que secomporta una vez construida, o el proceso de su construccin. Tomadas en suconjunto, destacan ms bien un consenso.

Independientemente de las discrepancias entre las diversas definiciones, es comnentre todos los autores el concepto de la arquitectura como un punto de vista queconcierne a un alto nivel de abstraccin. Revisamos las diversas definiciones delconcepto de abstraccin en un apartado especfico ms adelante en este estudio.

Es casi seguro que la percepcin de la AS que prevalece entre quienes no hantenido contacto con ella, as como los estereotipos dominantes sobre su naturaleza,o los nombres que se escogeran como sus personalidades ms importantes,difieren sustancialmente de lo que es el caso en el interior de la especialidad. Estesera acaso un ejercicio digno de llevarse a cabo alguna vez.

Arriba

Conceptos fundamentales

Ms all de que hoy existan numerosos conceptos en el plano detallado de las

tcnicas y metodologas, la AS se articula alrededor de unos pocos conceptos y

principios esenciales y unas pocas herramientas caractersticas.

Estilos

En el texto fundacional de la AS, Perry y Wolf establecen el razonamiento sobre
http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#top#tophttp://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#top#tophttp://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp#top#top


18/53

estilos de arquitectura como uno de los aspectos fundamentales de la disciplina. Un

estilo es un concepto descriptivo que define una forma de articulacin u

organizacin arquitectnica. El conjunto de los estilos cataloga las formas bsicas

posibles de estructuras de software, mientras que las formas complejas se articulan

mediante composicin de los estilos fundamentales.

Sucintamente descriptos, los estilos conjugan elementos (o componentes, como

se los llama aqu), conectores, configuraciones y restricciones. Al estipular los

conectores como elemento de juicio de primera clase, el concepto de estilo,

incidentalmente, se sita en un orden de discurso y de mtodo que el modelado

orientado a objetos en general y UML en particular no cubren satisfactoriamente. La

descripcin de un estilo se puede formular en lenguaje natural o en diagramas,

pero lo mejor es hacerlo en un lenguaje de descripcin arquitectnica o enlenguajes formales de especificacin.

A diferencia de los patrones de diseos, que son centenares, los estilos se ordenan

en seis o siete clases fundamentales y unos veinte ejemplares, como mximo. Es

digno de sealarse el empeo por subsumir todas las formas existentes de

aplicaciones en un conjunto de dimensiones tan modestas. Las arquitecturas

complejas o compuestas resultan del agregado o la composicin de estilos ms

bsicos. Algunos estilos tpicos son las arquitecturas basadas en flujo de datos, las

peer-to-peer, las de invocacin implcita, las jerrquicas, las centradas en datos olas de intrprete-mquina virtual.

Hemos tratado el tema de las definiciones, los catlogos de estilos, las propiedades

de cada uno, el lugar de los estilos en la AS y su relacin con los patrones de

diseo y con la estrategia arquitectnica de Microsoft en un documento separado,

en torno del cual se podrn discutir las cuestiones relacionadas con ellos.

Lenguajes de descripcin arquitectnica

Los lenguajes de descripcin de arquitecturas, o ADLs, ocupan una parte

importante del trabajo arquitectnico desde la fundacin de la disciplina. Se trata

de un conjunto de propuestas de variado nivel de rigurosidad, casi todas ellas de

extraccin acadmica, que fueron surgiendo desde comienzos de la dcada de 1990

hasta la actualidad, ms o menos en contemporaneidad con el proyecto de

unificacin de los lenguajes de modelado bajo la forma de UML. Los ADL difiere

sustancialmente de UML, que al menos en su versin 1.x se estima inadecuado en

su capacidad para expresar conectores en particular y en su modelo semntico en

general para las clases de descripcin y anlisis que se requieren. Los ADLspermiten modelar una arquitectura mucho antes que se lleve a cabo la


19/53


20/53

incluyen en el cuadro. Una vista es, para definirla sucintamente, un subconjunto

resultante de practicar una seleccin o abstraccin sobre una realidad, desde un

punto de vista determinado [Hil99].

Zachman(Niveles) TOGAF(Arquitecturas) 4+1(Vistas) [BRJ99](Vistas) POSA(Vistas) Microsoft(Vistas)Scope Negocios Lgica Diseo Lgica LgicaEmpresa Datos Proceso Proceso Proceso ConceptualSistema lgico Aplicacin Fsica Implementacin Fsica FsicaTecnologa Tecnologa Desarrollo Despliegue DesarrolloRepresentacin Casos de

usoCasos de uso

Funcionamiento

Tabla 1 - Vistas en los marcos de referencia

El marco de referencia para la arquitectura empresarial de John Zachman[Zac87] identifica 36 vistas en la arquitectura (celdas) basadas en seis niveles

(scope, empresa, sistema lgico, tecnologa, representacin detallada y

funcionamiento empresarial) y seis aspectos (datos, funcin, red, gente,

tiempo, motivacin). En el uso corriente de AS se ha estimado que este modelo

es excesivamente rgido y sobre-articulado. Parecera existir cierto consenso

sobre su excesiva ambicin y su posible obsolescencia. Los manuales recientes

de ingeniera de software (por ejemplo [Pre02] [Pfl02]) suelen omitir toda

referencia a este marco, que se estima perteneciente a una esfera de

Information Management y estrategia empresarial, antes que inscripto en el

campo de la arquitectura. El framework ha estado tambin bajo nutrido fuego

crtico [Cib98] [Keen91]. No obstante, hay que reconocer que tres de las vistas

propuestas por Zachman tan tempranamente como en 1982 (conceptual, lgica

y fsica) se corresponden con el modelo de vistas de los marcos de referencia

posteriores.

El Modelo de Referencia para Procesamiento Distribuido Abierto (RM-ODP)es un estndar de ISO y de ITU (ex-CCITT) que define un marco para la

especificacin arquitectnica de grandes sistemas distribuidos. Define, entre

otras cosas, cinco puntos de vista (viewpoints) para un sistema y su entorno:

empresa, informacin, computacin, ingeniera y tecnologa. Los cinco puntos

de vista no corresponden a etapas de proceso de desarrollo o refinamiento. De

los cuatro estndares bsicos que componen el modelo, los dos primeros se

refieren a la motivacin general del mismo y a sus fundamentos conceptuales y

analticos; el tercero (ISO/IEC 10746-3; UTI-T X.903) a la arquitectura,

definiendo los puntos de vistas referidos; y el cuarto (ISO/IEC 10746-4; UTI-TX.904) a la formalizacin de la semntica arquitectnica. RM-ODP se supone


21/53

neutral en relacin con la metodologa, las formas de modelado y la tecnologa

a implementarse, pero recomienda el uso de lenguajes formales de

especificacin como LOTOS, ESTELLE, SDL o Z. Se supone que un modelo

pensado con similares propsitos, como CORBA, debera ser 100% conforme

con la referencia, pero en verdad no es as; CORBA, por ejemplo, no

proporciona soporte para el viewpoint empresarial, su modelo computacional

revela desviaciones significativas del ISO/IEC o el UTI-T correspondiente, su

modelo de binding es ms restringido (carece de multicast o plug and play) y

aunque hay RFPs que documentan estas divergencias, hasta donde puede

saberse permanecen an sin resolver; en los viewpoints de ingeniera y

tecnologa las discrepancias son menores, pero son muchsimas, y en ninguno

hay concordancia en la nomenclatura [DIR99]. Los modelos mayores de

industria como COM o J2EE son todava ms divergentes y las verificaciones deconformidad son un trmite extremadamente complejo. RM-ODP, adems, no

especifica nada acerca de conectores entre sistemas, integracin de tecnologas

legacy o soporte de sistemas multi-paradigmas [Bez98]. Hoy en da la

interoperabilidad se garantiza ms a travs de tecnologas comunes de formato

y protocolo ligadas a XML, SOAP, BPEL4WS o WS-I (o mediante MDA, o

programando un wrapper) que por conformidad con esta clase de

recomendaciones en todos los puntos de un proceso distribuido.

C4ISR Architecture Framework es el marco de referencia arquitectnicopromovido por el Departamento de Defensa de Estados Unidos (DoD). Algunos

de los otros marcos listados en esta seccin se inspiran en l, como es el caso

de TOGAF. En la versin 2 de C4I, completada en diciembre de 1997, la

definicin de arquitectura reconocida es exactamente la misma que despus se

promulgara como cannica en IEEE 1471. Las vistas arquitectnicas

homologadas son la Operacional (que identifica relaciones y necesidades de

informacin), la de Sistemas (que vincula capacidades y caractersticas a

requerimientos operacionales) y la Tcnica (que prescribe estndares yconvenciones).

El marco de referencia arquitectnico de The Open Group (TOGAF) reconocecuatro componentes principales, uno de los cuales es un framework de alto

nivel que a su vez define cuatro vistas: Arquitectura de Negocios, Arquitectura

de Datos/Informacin, Arquitectura de Aplicacin y Arquitectura Tecnolgica.

The Open Group propone un modelo de descripcin arquitectnica, Architecture

Description Method (ADM) que se supone independiente de las tcnicas de

modelado, aunque en la versin 7 se propone Metis como herramienta.


22/53

En 1995 Philippe Kruchten propuso su clebre modelo 4+1, vinculado alRational Unified Process (RUP), que define cuatro vistas diferentes de la

arquitectura de software: (1) La vista lgica, que comprende las abstracciones

fundamentales del sistema a partir del dominio de problemas. (2) La vista de

proceso: el conjunto de procesos de ejecucin independiente a partir de las

abstracciones anteriores. (3) La vista fsica: un mapeado del software sobre el

hardware. (4) La vista de desarrollo: la organizacin esttica de mdulos en el

entorno de desarrollo. El quinto elemento considera todos los anteriores en el

contexto de casos de uso [Kru95]. Lo que acadmicamente se define como AS

concierne a las dos primeras vistas. El modelo 4+1 se percibe hoy como un

intento se reformular una arquitectura estructural y descriptiva en trminos de

objeto y de UML. Con todo, las cuatro vistas de Kruchten forman parte del

repertorio estndar de los practicantes de la disciplina.

En su introduccin a UML (1.3), Grady Booch, James Rumbaugh e IvarJacobson han formulado un esquema de cinco vistas interrelacionadas que

conforman la arquitectura de software, caracterizada en trminos parecidos a

los que uno esperara encontrar en el discurso de la vertiente estructuralista. En

esta perpectiva, la arquitectura de software (a la que se dedican muy pocas

pginas) es un conjunto de decisiones significativas sobre (1) la organizacin de

un sistema de software; (2) la seleccin de elementos estructurales y sus

interfaces a travs de los cuales se constituye el sistema; (3) sucomportamiento, segn resulta de las colaboraciones entre esos elementos; (4)

la composicin de esos elementos estructurales y de comportamiento en

subsistemas progresivamente mayores; (5) el estilo arquitectnico que gua

esta organizacin: los elementos estticos y dinmicos y sus interfaces, sus

colaboraciones y su composicin. Los autores proporcionan luego un esquema

de cinco vistas posibles de la arquitectura de un sistema: (1) La vista de casos

de uso, como la perciben los usuarios, analistas y encargados de las pruebas;

(2) la vista de diseo que comprende las clases, interfaces y colaboraciones queforman el vocabulario del problema y su solucin; (3) la vista de procesos que

conforman los hilos y procesos que forman los mecanismos de sincronizacin y

concurrencia; (4) la vista de implementacin que incluye los componentes y

archivos sobre el sistema fsico; (5) la vista de despliegue que comprende los

nodos que forma la topologa de hardware sobre la que se ejecuta el sistema

[BRJ99: 26-27]. Aunque las vistas no estn expresadas en los mismos trminos

estructuralistas que campean en su caracterizacin de la arquitectura, y aunque

la relacin entre vistas y decisiones arquitectnicas es de simple yuxtaposicininformal de ideas antes que de integracin rigurosa, es natural inferir que las


23/53

vistas que ms claramente se vinculan con la semntica arquitectnica son la

de diseo y la de proceso.

En los albores de la moderna prctica de los patrones, Buschmann y otrospresentan listas discrepantes de vistas en su texto popularmente conocido comoPOSA [BMR+96]. En la primera se las llama arquitecturas, y son: (1)

Arquitectura conceptual: componentes, conectores; (2) Arquitectura de

mdulos: subsistemas, mdulos, exportaciones, importaciones; (3) Arquitectura

de cdigo: archivos, directorios, bibliotecas, inclusiones; (4) Arquitectura de

ejecucin: tareas, hilos, procesos. La segunda lista de vistas, por su parte,

incluye: (1) Vista lgica: el modelo de objetos del diseo, o un modelo

correspondiente tal como un diagrama de relacin; (2) Vista de proceso:

aspectos de concurrencia y sincronizacin; (3) Vista fsica: el mapeo del

software en el hardware y sus aspectos distribuidos; (4) Vista de desarrollo: la

organizacin esttica del software en su entorno de desarrollo. Esta segunda

lista coincide con el modelo 4+1 de Kruchten, pero sin tanto nfasis en el quinto

elemento.

Bass, Clements y Kazman presentan en 1998 una taxonoma de nuevevistas, decididamente sesgadas hacia el diseo concreto y la implementacin:

(1) Estructura de mdulo; las unidades son asignaciones de tareas. (2)

Estructura lgica o conceptual. Las unidades son abstracciones de los

requerimientos funcionales del sistema. (3) Estructura de procesos o de

coordinacin. Las unidades son procesos o threads. (4) Estructura fsica. (5)

Estructura de uso. Las unidades son procedimientos o mdulos, vinculados por

relaciones de presuncin-de-presencia-correcta. (6) Estructura de llamados. Las

unidades son usualmente (sub)procedimientos, vinculados por invocaciones o

llamados. (7) Flujo de datos. Las unidades son programas o mdulos, la

relacin es de envo de datos. (8) Flujo de control; las unidades son programas,

mdulos o estados del sistema. (9) Estructura de clases. Las unidades son

objetos [BCK98]. Esta taxonoma de vista no coincide con ninguna otra.

La recomendacin IEEE Std 1471-2000 procura establecer una base comnpara la descripcin de arquitecturas de software, e implementa para ello tres

trminos bsicos, que son arquitectura, vista y punto de vista. La arquitectura

se define como la organizacin fundamental de un sistema, encarnada en sus

componentes, las relaciones entre ellos y con su entorno, y los principios que

gobiernan su diseo y evolucin. Los elementos que resultan definitorios en la

utilidad, costo y riego de un sistema son en ocasiones fsicos y otras veces

lgicos. En otros casos ms, son principios permanentes o patrones que


24/53

generan estructuras organizacionales duraderas. Trminos como vista o punto

de vista son tambin centrales. En la recomendacin se los utiliza en un sentido

ligeramente distinto al del uso comn. Aunque reflejan el uso establecido en los

estndares y en la investigacin de ingeniera, el propsito del estndar es

introducir un grado de formalizacin homogeneizando informalmente la

nomenclatura. En dicha nomenclatura, un punto de vista (viewpoint) define un

patrn o plantilla (template) para representar un conjunto de incumbencias

(concerns) relativo a una arquitectura, mientras que una vista (view) es la

representacin concreta de un sistema en particular desde una perspectiva

unitaria. Un punto de vista permite la formalizacin de grupos de modelos. Una

vista tambin se compone de modelos, aunque posee tambin atributos

adicionales. Los modelos proporcionan la descripcin especfica, o contenido, de

una arquitectura. Por ejemplo, una vista estructural consistira de un conjuntode modelos de la estructura del sistema. Los elementos de tales modelos

incluiran componentes identificables y sus interfaces, as como interconexiones

entre los componentes. La concordancia entre la recomendacin de IEEE y el

concepto de estilo se establece con claridad en trminos del llamado punto de

vista estructural. Otros puntos de vista reconocidos en la recomendacin son el

conductual y el de interconexin fsica. El punto de vista estructural ha sido

motivado (afirman los redactores del estndar) por el trabajo en lenguajes de

descripcin arquitectnica (ADLs). El punto de vista estructural, dicen, se hadesarrollado en el campo de la AS desde 1994 y es hoy de amplio uso.

La estrategia de arquitectura de Microsoft define, en consonancia con lasconceptualizaciones ms generalizadas, cuatro vistas, ocasionalmente llamadas

tambin arquitecturas: Negocios, Aplicacin, Informacin y Tecnologa

[Platt02]. La vista que aqu interesa es la de la aplicacin, que incluye, entre

otras cosas: (1) Descripciones de servicios automatizados que dan soporte a los

procesos de negocios; (2) descripciones de las interacciones e

interdependencias (interfaces) de los sistemas aplicativos de la organizacin, y(3) planes para el desarrollo de nuevas aplicaciones y la revisin de las

antiguas, basados en los objetivos de la empresa y la evolucin de las

plataformas tecnolgicas. Cada arquitectura, a su vez, se articula en vistas

tambin familiares desde los das de OMT que son (1) la Vista Conceptual,

cercana a la semntica de negocios y a la percepcin de los usuarios no

tcnicos; (2) la Vista Lgica, que define los componentes funcionales y su

relacin en el interior de un sistema, en base a la cual los arquitectos

construyen modelos de aplicacin que representan la perspectiva lgica de laarquitectura de una aplicacin; (3) la Vista Fsica, que es la menos abstracta y


25/53

que ilustra los componentes especficos de una implementacin y sus

relaciones.

Ahora que se han examinado cules son las vistas que proponen los diferentes

frameworks, habra que precisar mejor el significado especficamente arquitectnicode las vistas. Como expresa Rich Hilliard [Hil99], a quien seguimos en este

tratamiento, aunque expresiones tales como mltiples vistasson algo as como el

Santo Grial de la ingeniera de software, de requerimientos y de sistemas, su

estatus en la AS es bastante ms oscuro. Las razones para ello son mltiples. En

primer lugar, no existe una fundamentacin coherente para su uso en la disciplina.

En segundo trmino, muchos estudiosos las consideran problemticas, porque la

existencia de mltiples vistas introduce problemas de integracin y consistencia

entre las diferentes vistas. Sin embargo, los arquitectos practicantes las usan de

todas maneras, porque simplifican la visualizacin de sistemas complejos.

La idea de contemplar un sistema complejo desde mltiples puntos de vista no es

nativa de la AS contempornea, ni es una invencin de Kruchten, sino que se

origina por lo menos en la dcada de 1970, en el trabajo de Douglas Ross sobre

anlisis estructurado [Ross77]. La motivacin para introducir mltiples vistas radica

en la separacin de incumbencias (separations of concerns). Las vistas se

introdujeron como una herramienta conceptual para poder manejar la complejidad

de lo que ya por aquel entonces se llamaban artefactos, tales como especificacionesde requerimientos o modelos de diseo. En las contribuciones ms tempranas, las

mltiples vistas de un modelo se basaban en perspectivas fijas, puntos de vistas o

viewpoints; casi siempre los puntos de vista eran dos, el funcional y el de datos,

ninguno de los cuales aparece en arquitectura.

En la dcada de 1980, sin embargo, las vistas comenzaron a multiplicarse, al punto

que se realizaron surveysinterdisciplinarios y se organizaron conferencias

especficas sobre la cuestin, como Viewpoints96. No hay un lmite necesario parael nmero de vistas posibles, ni un procedimiento formal para establecer lo que una

vista debe o no abstraer. El estndar IEEE 1471 no delimita el nmero posible de

vistas, ya que se estima que no puede haber acuerdo en ello, pero seala

lineamientos para su constitucin y considera que un viewpointes a una vista como

una clase es a un objeto.

Hay una lista corta de vistas que se usa en los textos generales de AS y una lista

larga que gira en torno de UML, el cual especifica nueve clases de diagramas

correspondientes a ocho vistas, como se indica en el cuadro. Diferentes textos delos mismos autores, por ejemplo [BRJ99] y [RJB00], utilizan distintas terminologas


26/53

no conciliadas; vistas y puntos de vista no siempre se caracterizan como conceptos

distintos y el uso de la terminologa, an en el interior de cada texto, es informal e

inconsistente. Es difcil creer que esto se encuentra unificado de alguna manera.

Cuando los promotores de UML hablan de arquitectura, a instancias de Kruchten,

cambian su modelo de vistas por uno que se refiere no a puntos de perspectiva o a

incumbencias de los participantes, sino a niveles de abstraccin; pero an as,

como se ha visto, su definicin de arquitectura difiere de la definicin estndar.

rea Vista Diagramas Conceptos principales

Estructural Vista esttica Diagrama declases

Clase, asociacin,generalizacin,dependencia, realizacin,interfaz

Vista de casosde uso

Diagramas decasos de uso

Caso de uso, actor,asociacin, extensin,inclusin, generalizacin decasos de uso

Vista deimplementacin

Diagrama decomponentes

Componente, interfaz,dependencia, realizacin

Vista dedespliegue

Diagrama dedespliegue

Nodo, componente,dependencia, localizacin

Dinmica Vista demquinas deestados

Diagrama deestados

Estado, evento, transicin,accin

Vista deactividad Diagrama deactividad

Estado, actividad,

transicin de terminacin,divisin, unin

Vista deinteraccin

Diagrama desecuencia

Interaccin, objeto,mensaje, activacin

Diagrama decolaboracin

Colaboracin, interaccin,rol de colaboracin,mensaje

Gestindelmodelo

Vista de gestindel modelo

Diagrama declases

Paquete, subsistema,modelo

Tabla 2 - Vistas y diagramas de UML, basado en [RJB00: 22]

Como lo subraya Hilliard, en sus textos iniciales la modalidad clsica de la AS,

encarnada en Garlan y Shaw, no habla de vistas en absoluto; la AS clsica se funda

en una vista singular e implcita, de carcter estructural. Muchos arquitectos de la

corriente principal evitan hablar de vistas, porque cuando las ellas proliferan se

hace necesario o bien elaborar lenguajes formales especficos para tratar cada una

de ellas, o bien multiplicar salvajemente las extensiones del lenguaje unificado. Sin

duda las vistas son una simplificacin conveniente, o ms bien un principio de

orden; pero su abundancia y sus complicadas relaciones recprocas generan

tambin nuevos rdenes de complejidad.


27/53

Podra discutirse el concepto y la articulacin de las diferentes vistas un largo rato,

y de hecho los muchos simposios que han habido sobre el particular fueron de

inters pero inconcluyentes. Se acostumbra poner las vistas que denotan niveles

de abstraccin en cuadros superpuestos, por ejemplo, como si fueran anlogas a

las capas del modelo OSI, pero son ambas representaciones estrictamente

homlogas? Constituye el conjunto de las vistas un sistema? Por qu cada vez

que se enumeran los artefactos caractersticos de cada vista aparece la palabra

etctera o la expresin elementos principales?

Procesos y Metodologas

En los diferentes marcos, las vistas estticas se corresponden con las perspectivas

particulares de los diferentes participantes (stakeholders), mientras que las vistasdinmicas tienen que ver con etapas del proceso, ciclo de vida o metodologa,

caracterizadas como requerimiento, anlisis, diseo (o construccin, o modelado),

implementacin, integracin (prueba de conformidad, testing, evaluacin). La

terminologa, lo mismo que la articulacin temporal del proceso o el ciclo, depende

de cada marco. Llegando al territorio de la metodologa, hay que decir que durante

varios aos la AS discurri sin elaborarlas ms que circunstancialmente, como si se

estimara compatible con las prcticas establecidas en ingeniera de software,

cualesquiera fuesen: RUP, RAD, RDS, ARIS, PERA, CIMOSA, GRAI, GERAM, CMM.

Hoy en da la metodologa dominante en la industria es tal vez el Modelo de

Madurez de la Capacidad (CMM), aunque el SEI no la considera formalmente como

tal.

Desde 1998 y cada vez con mayor intensidad, sin embargo, el SEI y otros

organismos comenzaron a elaborar mtodos especficos de procesos de ingeniera

que sistematizan el rol de la arquitectura en la totalidad del proceso, desde la

elicitacin de requerimientos hasta la terminacin. Algunos de esos mtodos son

Architecture Based Design (ABD), Software Architecture Analysis Method (SAAM),

Quality Attribute Workshops (QAW), Quality Attribute-Oriented Software

Architecture Design Method (QASAR), Attribute-Driven Design (ADD), Architecture

Tradeoff Analysis Method (ATAM), Active Review for Intermediate Design (ARID),

Cost-Benefits Analysis Method (CBAM), Family-Architecture Analysis Method

(FAAM), Architecture Level Modifiability Analysis (ALMA), y Software Architecture

Comparison Analysis Method (SACAM). Al lado de esos mtodos est surgiendo un

nutrido conjunto de tcnicas de documentacin; mtodos, tcnicas y estudios de

casos se analizarn en este estudio en documentos separados. Habiendo al menosuna docena de mtodos complejamente engranados entre s, el lector puede


28/53

perderse con facilidad en un laberinto bibliogrfico donde no siempre se discierne

cules de estos mtodos incluyen a cules otros, cules son sus relaciones con

tcnicas consagradas de ingeniera, cules se encuentran vigentes y cules

obsoletos. Un documento actual que describe a grandes rasgos la mayora de esos

mtodos es [KNK03].

En general, la AS de la corriente principal todava no se ha expedido en relacin con

los llamados mtodos giles. No hay un solo mtodo, sino una multiplicidad de

posturas ms o menos radicales y combativas: Extreme Programming, SCRUM,

Crystal Methods Framework, Feature-Driven Development, DSDM, Lean

Development, Adaptive Software Development, Agile Modeling, Pragmatic

Programming [ASR+02] [CLC03]. De hecho, la comunidad de los metodlogos, que

opera a una cierta distancia de las iniciativas formales de la AS, se encuentra

dividida tras lo que ha sido y sigue siendo el gran debate metodolgico entre los

mtodos pesados (o rigurosos) de tipo SEI/CMM por un lado y los mtodos giles

por el otro [Hig01]. Los tericos de cada bando han sido, entre otros, Tom De

Marco, Ed Yourdon y Tim Lister en la faccin rigurosa y Ken Orr, Jim Highsmith,

Martin Fowler y Michael Jackson del lado gil-extremo, con Philippe Kruchten y RUP

buscando establecerse en ambos terrenos.

Ambos grupos operan en el contexto de la crisis del software, que se da por

sentada, alegando que es la mentalidad del bando opuesto lo que la ha ocasionado.Los pesados, mirados por los giles como formalistas fracasados, enfatizan el

modelado, el control y la documentacin escrupulosa; los giles, acusados por los

pesados de hackers irresponsables que pretenden imponer sus juguetes en la

empresa, no slo desprecian los modelos (formales o informales) sino que incluso

ocasionalmente ponen en tela de juicio hasta a los propios patrones de diseo

[Fow01]. Ese tema tambin ser tratado en un estudio aparte.

En lo que respecta a la estrategia arquitectnica de Microsoft, el marco general de

Microsoft Solutions Framework, versin 3, no se expide sobre metodologas

especficas y da cabida a una gran cantidad de alternativas, desde las densas a las

ligeras. Abundan en MSF 3 referencias a mtodos rpidos y giles, a travs de citas

y conceptos de una de las figuras cardinales de Cutter Consortium, Martin Fowler.

La documentacin de MSF ratifica su adecuacin tanto para el CMM de SEI o UPM

como para los mtodos giles en ambientes que requieren un alto grado de

adaptabilidad [MS03].

AbstraccinEl concepto de abstraccin (que a veces se usa en el sentido del proceso de


29/53

abstraer, otra para designar una entidad) ha sufrido tambin diversas acepciones,

con un ncleo de significados comn. Las diferencias en el uso del concepto de

abstraccin ayudan tambin a identificar las diversas corrientes en el seno de la AS.

La definicin que proporciona Grady Booch, por ejemplo, revela que el autor

identifica la abstraccin arquitectnica con el encapsulamiento propio de la

tecnologa de objetos: Una abstraccin escribe Boochdenota las caractersticas

esenciales de un objeto que lo distinguen de otras clases de objeto y provee de

este modo delimitaciones conceptuales bien definidas, relativas a la perspectiva del

observador [Boo91].

El concepto de abstraccin (que a veces se usa en el sentido del proceso de

abstraer, otra para designar una entidad abstracta) ha sufrido tambin diversas

formulaciones sintcticas, con un ncleo de significados comn. En ltimo anlisis,la abstraccin siempre conlleva una heurstica positiva al lado de una negacin.

Tanto para la IEEE como para Rumbaugh, Shaw y otros autores, la abstraccin

consiste en extraer las propiedades esenciales, o identificar los aspectos

importantes, o examinar selectivamente ciertos aspectos de un problema,

posponiendo o ignorando los detalles menos sustanciales, distractivos o

irrelevantes.

La idea de abstraccin forma parte de lo que acaso sea la pieza conceptual msimportante de la AS, el concepto de estilo; un estilo se identifica a grandes rasgos

o, como se dice habitualmente, en un estilo menos es ms. La misma idea

prevalece en todos los conceptos y procedimientos que se consideran

arquitectnicos. Para Len Bass, Paul Clements y Rick Kazman [BCK98], si una

decisin debe posponerse hasta el momento de tratar las cosas a un bajo nivel, no

se trata de una decisin de arquitectura. Clements y Northrop [CN96] sostienen

que el trabajo de Garlan y Shaw sobre los estilos arquitectnicos nos ensea que

aunque los programas pueden combinarse de maneras prcticamente infinitas, hay

mucho que ganar si nos restringimos a un conjunto relativamente pequeo de

elecciones cuando se trata de cooperacin e interaccin. Las ventajas incluyen

mejor reutilizacin, mejores anlisis, menor tiempo se seleccin y mayor

interoperabilidad. Menos es ms figura, de hecho, en el ttulo y en los contenidos

de numerosos papers de la profesin [MB02] [CN96]. Conceptos como el de estilo,

o marcos como MSF, revelan su naturaleza arquitectnica en su abstraccin y en su

generalidad.

EscenariosEsta es una nocin arquitectnica importante y se encuentra en la base de muchos


30/53

de los mtodos de diseo y desarrollo basados en arquitectura, como ALMA, SAAM

y ATAM. Hay que ser precavidos y advertir desde el comienzo que lo que

habitualmente se traduce como escenario no es estrictamente lo que en lengua

castellana se designa como tal; la traduccin correcta debera ser ms bien guin

o libreto. La traduccin literal del trmino no hace ms que aportar confusin.

Desde Kruchten en adelante, se reconoce que los escenarios se dividen en dos

categoras: casos de uso (secuencias de responsabilidades) y casos de cambio

(modificaciones propuestas al sistema).

Los escenarios han sido bsicamente tcnicas que se implementan en la elicitacin

de los requerimientos, particularmente en relacin a los operadores de sistemas.

Tpicamente, la tcnica comienza instrumentando sesiones de brainstorming.

Tambin se han utilizado escenarios como mtodo para comparar alternativas dediseo. Los escenarios describen una utilizacin anticipada o deseada del sistema, y

tpicamente se expresan en una frase; Kazman, Abowd, Bass y Clements proponen

tambin llamarlos vietas [KAB+96].

Segn algunas definiciones, como la de Clements y Northrop [CN96], los escenarios

son algo as como libretos (en el sentido teatral o cinematogrfico del trmino)

correspondientes a las distintas piezas de funcionalidad de un sistema. Se los

considera tiles para analizar una vista determinada [Cle95a] o para mostrar laforma en que los elementos de mltiples vistas se relacionan entre s [Kru95].

Pueden concebirse tambin como una abstraccin de los requerimientos ms

importantes de un sistema. Los escenarios se describen mediante texto comn en

prosa utilizando lo que se llama un script y a veces se describen mediante dibujos,

como por ejemplo diagramas de interaccin de objeto. Se acostumbra utilizar UML

(en el contexto de 4+1) no tanto como recurso de modelado que despus generar

alguna clase de cdigo, sino como instrumento de dibujo ms o menos informal;

pero los propios manuales de UML y los expertos mundiales en casos de uso (David

Anderson, Martin Fowler, Alistair Cockburn) recomiendan desarrollar los escenarios

de requerimiento en texto, no en diagramas. Algunos autores estiman que se trata

de una herramienta importante para relacionar vistas arquitectnicas, porque

recorriendo un escenario puede mostrar las formas en que fragmentos o escenas de

esas vistas se corresponden entre s. Los mtodos propios de la arquitectura

basada en escenarios se analizan tambin en un documento aparte.


31/53

Campos de la Arquitectura de Software

La AS es hoy en da un conjunto inmenso y heterogneo de reas de investigacinterica y de formulacin prctica, por lo que conviene aunque ms no sea

enumerar algunos de sus campos y sus focos. Una semblanza semejante (de la que

aqu se proporciona slo un rudimento) dudosamente debera ser esttica. La AS

comenz siendo una abstraccin descriptiva puntual que en los primeros aos no

investig de manera sistemtica ni las relaciones que la vinculaban con los

requerimientos previos, ni los pasos metodolgicos a dar luego para comenzar a

componer el diseo. Pero esa sincronicidad estructuralista no pudo sostenerse. Por

el contrario, dara la impresin que, a medida que pasa el tiempo, la AS tiende a

redefinir todos y cada uno de los aspectos de la disciplina madre, la ingeniera de

software, slo que a un mayor nivel de abstraccin y agregando una nueva

dimensin reflexiva en lo que concierne a la fundamentacin formal del proceso.

Hay unas pocas caracterizaciones (y mucha actividad de copiado y pegado) en

torno de las reas que componen el territorio. David Garlan y Dewayne Perry, en su

introduccin al volumen de abril de 1995 de IEEE Transactions on Software

Engineering dedicado a la AS, en el cual se delinean las reas de investigacin ms

promisorias, enumeran las siguientes:

Lenguajes de descripcin de arquitecturas Fundamentos formales de la AS (bases matemticas, caracterizaciones

formales de propiedades extra-funcionales tales como mantenibilidad, teoras

de la interconexin, etctera).

Tcnicas de anlisis arquitectnicas

Mtodos de desarrollo basados en arquitectura Recuperacin y reutilizacin de arquitectura Codificacin y gua arquitectnica Herramientas y ambientes de diseo arquitectnico Estudios de casosFundamental en la concepcin de Clements y Northrop [CN96] es el criterio de

reusabilidad como uno de los aspectos que ms hacen por justificar la disciplina

misma. Segn estos autores, el estudio actual de la AS puede ser visto como unesfuerzo ex post facto para proporcionar un almacn estructurado de este tipo de


32/53

informacin reutilizable de diseo de alto nivel propio de una familia (en el sentido

de Parnas). De tal manera, las decisiones de alto nivel inherentes a cada miembro

de una familia de programas no necesitan ser re-inventadas, re-validadas y re-

descriptas. Un razonamiento arquitectnico es adems un argumento sobre las

cuestiones estructurales de un sistema. Se dira tambin que el concepto de estilo

es la encarnacin principal del principio de reusabilidad en el plano arquitectnico.

Paul Clements [Cle96b] define cinco temas fundamentales en torno de los cuales se

agrupa la disciplina:

Diseo o seleccin de la arquitectura: Cmo crear o seleccionar unaarquitectura en base de requerimientos funcionales, de rendimiento o de

calidad.

Representacin de la arquitectura: Cmo comunicar una arquitectura. Esteproblema se ha manifestado como el problema de la representacin de

arquitecturas utilizando recursos lingsticos, pero el problema tambin incluye

la seleccin del conjunto de informacin a ser comunicada.

Evaluacin y anlisis de la arquitectura: Cmo analizar una arquitectura parapredecir cualidades del sistema en que se manifiesta. Un problema semejante

es cmo comparar y escoger entre diversas arquitecturas en competencia.

Desarrollo y evolucin basados en arquitectura: Cmo construir y mantenerun sistema dada una representacin de la cual se cree que es la arquitectura

que resolver el problema correspondiente.

Recuperacin de la arquitectura: Cmo hacer que un sistema legacyevolucione cuando los cambios afectan su estructura; para los sistemas de los

que se carezca de documentacin confiable, esto involucra primero una

arqueologa arquitectnica que extraiga su arquitectura.

Mary Shaw [Shaw01] considera que en el 2001 los campos ms promisorios de la

AS siguen teniendo que ver con el tratamiento sistemtico de los estilos, eldesarrollo de lenguajes de descripcin arquitectnica, la formulacin de

metodologas y (ahora) el trabajo con patrones de diseo. Se requieren todava

modelos precisos que permitan razonar sobre las propiedades de una arquitectura y

verificar su consistencia y completitud, as como la automatizacin del proceso de

anlisis, diseo y sntesis. Sugiere que debe aprenderse una leccin a partir de la

experiencia de la ingeniera de software, la cual no obstante haberse desenvuelto

durante treinta aos no ha logrado plasmar un conjunto de paradigmas de

investigacin comparable al de otras reas de las ciencias de la computacin.Estima que la AS se encuentra ya en su fase de desarrollo y extensin, pero que


33/53

tanto las ideas como las herramientas distan de estar maduras.

Un campo que no figura en estas listas pero sobre el cual se est trabajando

intensamente es en el de la coordinacin de los ADLs que sobrevivan con UML 2.0

por un lado y con XML por el otro. Ningn lenguaje de descripcin arquitectnica en

el futuro prximo (excepto los que tengan un nicho tcnico muy particular) ser

viable si no satisface esos dos requisitos.

Los ejercicios que pueden hacerse para precisar los campos de la AS son

incontables. Ahora que la AS se ha abismado en el desarrollo de metodologas, hace

falta, por ejemplo, establecer con ms claridad en qu difieren sus elaboraciones en

torno del diseo, del anlisis de requerimientos o de justificacin econmica de las

llevadas a cabo por la ingeniera de software. Asimismo, se est esperando todavauna lista sistemtica y exhaustiva que describa los dominios de incumbencia de la

disciplina, as como un examen del riesgo de duplicacin de esfuerzos entre campos

disciplinarios mal comunicados, una situacin que a primera vista parecera

contradictoria con el principio de reusabilidad.

Modalidades y tendencias

En la dcada de 1990 se establece definitivamente la AS como un dominio todava

hoy separado de manera confusa de ese marco global que es la ingeniera y de esa

prctica puntual que es el diseo. Aunque no hay un discurso explcito y

autoconsciente sobre escuelas de AS, ni se ha publicado un estudio reconocido y

sistemtico que analice las particularidades de cada una, en la actualidad se pueden

distinguir a grandes rasgos unas seis corrientes. Algunas distinciones estn

implcitas por ejemplo en [MT00], pero la bibliografa sobre corrientes y alternativas

prcticamente no existe y la que sigue habr de ser por un tiempo una de las pocas

propuestas contemporneas sobre el particular.

Ahora bien, articular una taxonoma de estrategias no admite una solucin simple y

determinista. En distintos momentos de su trayectoria, algunos practicantes de la

AS se mueven ocasionalmente de una tctica a otra, o evolucionan de un punto de

vista ms genrico a otro ms particular, o realizan diferentes trabajos operando en

marcos distintos. Adems, con la excepcin del gran debate metodolgico entre

mtodos pesados y ligeros [Hig01], las discusiones entre las distintas posturas rara

vez se han manifestado como choques frontales entre ideologas irreconciliables,


34/53

por lo que a menudo hay que leer entre lneas para darse cuenta que una

afirmacin cualquiera es una crtica a otra manera de ver las cosas, o trasunta una

toma definida de posicin. Fuera de la metodologa, el nico factor reconocible de

discordia ha sido, hasta la fecha, la preminencia de UML y el diseo orientado a

objetos. Todo lo dems parece ser ms o menos negociable.

La divisin preliminar de escuelas de AS que proponemos es la siguiente:

1)Arquitectura como etapa de ingeniera y diseo orientada a objetos.Es el

modelo de James Rumbaugh, Ivar Jacobson, Grady Booch, Craig Larman y otros,

ligado estrechamente al mundo de UML y Rational. No cabe duda que se trata de

una corriente especfica: Rumbaugh, Jacobson y Booch han sido llamados Los Tres

Amigos; de lo que s puede dudarse es que se trate de una postura arquitectnic a.

En este postura, la arquitectura se restringe a las fases iniciales y preliminares delproceso y concierne a los niveles ms elevados de abstraccin, pero no est

sistemticamente ligada al requerimiento que viene antes o a la composicin del

diseo que viene despus. Lo que sigue al momento arquitectnico es business as

usual, y a cualquier configuracin, topologa o morfologa de las piezas del sistema

se la llama arquitectura. En esta escuela, si bien se reconoce el valor primordial de

la abstraccin (nadie despus de Dijkstra osara oponerse a ello) y del ocultamiento

de informacin promovido por Parnas, estos conceptos tienen que ver ms con el

encapsulamiento en clases y objetos que con la visin de conjunto arquitectnica.

Para este movimiento, la arquitectura se confunde tambin con el modelado y el

diseo, los cuales constituyen los conceptos dominantes. En esta corriente se

manifiesta predileccin por un modelado denso y una profusin de diagramas,

tendiente al modelo metodolgico CMM o a UPM; no hay, empero, una precripcin

formal. Importa ms la abundancia y el detalle de diagramas y tcnicas disponibles

que la simplicidad de la visin de conjunto. Cuando aqu se habla de estilos, se los

confunde con patrones arquitectnicos o de diseo [Lar03]. Jams se hace

referencia a los lenguajes de descripcin arquitectnica, que representan uno de los

assets reconocidos de la AS; sucede como si la disponibilidad de un lenguaje

unificado de modelado los tornara superfluos. La definicin de arquitectura que se

promueve en esta corriente tiene que ver con aspectos formales a la hora del

desarrollo; esta arquitectura es isomorfa a la estructura de las piezas de cdigo.

Una definicin tpica y demostrativa sera la de Grady Booch; para l, la AS es la

estructura lgica y fsica de un sistema, forjada por todas las decisiones

estratgicas y tcticas que se aplican durante el desarrollo [Boo91]. Otras

definiciones revelan que la AS, en esta perspectiva, concierne a decisiones sobre

organizacin, seleccin de elementos estructurales, comportamiento, composicin y


35/53

estilo arquitectnico susceptibles de ser descriptas a travs de las cinco vistas

clsicas del modelo 4+1 de Kruchten [Kru95] [BRJ99: 26-28].

2) Arquitectura estructural, basada en un modelo esttico de estilos, ADLs

y vistas.Constituye la corriente fundacional y clsica de la disciplina. Losrepresentantes de esta corriente son todos acadmicos, mayormente de la

Universidad Carnegie Mellon en Pittsburgh: Mary Shaw, Paul Clements, David

Garlan, Robert Allen, Gregory Abowd, John Ockerbloom. Se trata tambin de la

visin de la AS dominante en la academia, y aunque es la que ha hecho el esfuerzo

ms importante por el reconocimiento de la AS como disciplina, sus categoras y

herramientas son todava mal conocidas en la prctica industrial. En el interior del

movimiento se pueden observar distintas divisiones. Hay una variante informal de

boxologa y una vertiente ms formalista, representada por el grupo de MarkMoriconi en el SRI de Menlo Park. En principio se pueden reconocer tres

modalidades en cuanto a la formalizacin; los ms informales utilizan descripciones

verbales o diagramas de cajas, los de talante intermedio se sirven de ADLs y los

ms exigentes usan lenguajes formales de especificacin como CHAM y Z. En toda

la corriente, el diseo arquitectnico no slo es el de ms alto nivel de abstraccin,

sino que adems no tiene por qu coincidir con la configuracin explcita de las

aplicaciones; rara vez se encontrarn referencias a lenguajes de programacin o

piezas de cdigo, y en general nadie habla de clases

Introducción a La Arquitectura de Software Por Carlos Billy Reynoso

Documents

Transcript of Introducción a La Arquitectura de Software Por Carlos Billy Reynoso