estilos heterogéneos

8/18/2019 Estilos heterogéneos

1/25

Estilos heterogéneosAntes de pasar a la familia más fuertemente referida en los últimostiempos, incluyo eneste grupo formas compuestas o indóciles a la clasicación en lascategorías habituales.

Es por cierto objetable y poco elegante que eistan clases residualesde este tipo en unataonomía, pero ninguna clasicación conocida ha podido resol!ereste dilemaconceptual. En este apartado podrían agregarse formas que aparecenesporádicamente enlos censos de estilos, como los sistemas de control de procesosindustriales, sistemas detransición de estados, arquitecturas especícas de dominios "#$%&' oestilos deri!ados de

otros estilos, como #en(oca, )* o +E$.Sistemas de control de procesos-esde el punto de !ista arquitectónico, mientras casi todos los demásestilos se puedendenir en función de componentes y conectores, los sistemas decontrol de procesos se&caracteri/an no sólo por los tipos de componentes, sino por lasrelaciones que mantienenentre ellos. El objeti!o de un sistema de esta clase es mantenerciertos !alores dentro de

ciertos rangos especicados, llamados puntos jos o !alores decalibración0 el caso másclásico es el de los termostatos. Eisten mecanismos tanto deretroalimentación1feedback 2 como de prealimentación 1feedforward2, y tantoreductores de oscilacióncomo amplicadores0 pero el tipo de retroalimentación negati!a es elmás común. En unode los pocos tratamientos arquitectónicos de esta clase de modeloscibern3ticos, $ha4 y

#arlan recomiendan separar los tres elementos del bucle de control1mecanismos paracambiar los !alores de !ariables y algoritmos de control, elementosde datos0 esquema delbucle2. 5a !entaja se6alada para este estilo radica en su elasticidadante perturbacioneseternas "$#%7'.Arquitecturas Basadas en Atributos

Aunque algunas otras !eces se ha in!entado un nue!o estilo paraagregarlo al in!entariode las !ariedades eistentes, como en este caso, en el de Arch, )* o

+E$, la literatura


2/25

estilística suele ser de carácter reacti!o e historicista antes quecreati!a e inno!adora,como si el número de estilos se quisiera mantener deliberadamentebajo. 5a arquitecturabasada en atributos o A8A$ fue propuesta por 9lein y 9la/man

"99%%'. 5a intención deestos autores es asociar a la denición del estilo arquitectónico unframework dera/onamiento 1ya sea cuantitati!o o cualitati!o2 basado en modelosde atributosespecícos. $u objeti!o se funda en la premisa que dicha asociaciónproporciona lasbases para crear una disciplina de dise6o arquitectónico, tornando eldise6o en un procesopredecible, antes que en una metodología ad hoc. )on ello se lograríaque la arquitecturade soft4are estu!iera más cerca de ser una disciplina de ingeniería,aportando elbenecio esencial de la ingeniería 1predictibilidad2 al dise6oarquitectónico.El modelo de 9lein y 9a/man en realidad no tipica como un estilo enestado puro, sinocomo una asociación entre la idea de estilo con análisis arquitectónicoy atributos decalidad. En este conteto, los estilos arquitectónicos denen lascondiciones en que han

de ser usados. Además de especicar los habituales componentes yconectores, los estilosbasados en atributos incluyen atributos de calidad especícos quedeclaran elcomportamiento de los componentes en interacción. :or ejemplo, enlas arquitecturastubería;ltros, se especica que se considere de qu3 manera ha deser administrada laperformance y se presta atención a los supuestos que rigen elcomportamiento de losltros y al efecto de su re;utili/ación. Agregando condiciones, un estilo

de!iene m3todo.-ado el carácter peculiar de A8A$ no se procederá aquí a su análisis.5lamo la atenciónno obstante sobre su naturale/a dinámica e instrumental. :or logeneral los arquitectos delcampo de los estilos, mayormente estructuralistas, no se ocupan decuestiones procesalestales como disciplinas de desarrollo, renamiento, e!aluación oanálisis de riesgo, quecorresponderían más bien a las incumbencias de los ingenieros. En laestrategia dearquitectura de


3/25

forma de una metodología de !ericación de patrones de soft4are"AEA=>'0 lametodología está epresamente orientada a patrones en el sentido de)hristopher?

Aleander "Ale@@', pero es por completo aplicable a estilosarquitectónicos debido a laproimidad de las nociones de patrón y estilo.Estilos Peer-to-PeerEsta familia, tambi3n llamada de componentes independientes,enfati/a lamodicabilidad por medio de la separación de las di!ersas partes queinter!ienen en lacomputación. )onsiste por lo general en procesos independientes oentidades que secomunican a tra!3s de mensajes. )ada entidad puede en!iarmensajes a otras entidades,pero no controlarlas directamente. 5os mensajes pueden ser en!iadosa componentesnominados o propalados mediante broadcast .


4/25

dise6o, el patrón que corresponde más estrechamente a este estilo esel que se conocecomo Observer, un t3rmino que se hi/o popular en $malltalG a principiosde los ochenta0 en elmundo de Ha!a se le conoce como modelo de delegación de

e!entos"5ar>'.5as arquitecturas basadas en e!entos se !inculan históricamente consistemas basados enactores, daemons y redes de conmutación de paquetes 1publicación;suscripción2. 5osconectores de estos sistemas incluyen procedimientos de llamadatradicionales y !ínculosentre anuncios de e!entos e in!ocación de procedimientos. 5a ideadominante en lain!ocación implícita es que, en lugar de in!ocar un procedimiento enforma directa

1como se haría en un estilo orientado a objetos2 un componentepuede anunciar mediantedifusión uno o más e!entos. In componente de un sistema puedeanunciar su inter3s enun e!ento determinado asociando un procedimiento con lamanifestación de dichoe!ento. In caso clásico en ambientes >* ")hu>*' o el :ublish;$ubscribe A:D de

Nindo4s )E .JE &.*.-esde el punto de !ista arquitectónico, los componentes de un estilode in!ocaciónimplícita son módulos cuyas interfaces proporcionan tanto unacolección deprocedimientos 1igual que en el estilo de tipos de datos abstractos2como un conjunto dee!entos. 5os procedimientos se pueden in!ocar a la manera usual enmodelos orientadosa objeto, o mediante el sistema de suscripción que se ha descripto.5os ejemplos de sistemas que utili/an esta arquitectura sonnumerosos. El estilo se utili/a


5/25

en ambientes de integración de herramientas, en sistemas de gestiónde base de datos paraasegurar las restricciones de consistencia 1bajo la forma dedisparadores, por ejemplo2, eninterfaces de usuario para separar la presentación de los datos de los

procedimientos quegestionan datos, y en editores sintácticamente orientados paraproporcionar !ericaciónsemántica incremental.In estilo perteneciente a esta clase es )* o )hiron;*. Ina aplicaciónde arquitectura )*está constituida por componentes que se comunican a tra!3s debuses0 la comunicaciónestá basada en e!entos. In componente puede en!iar o recibire!entos hacia o desde losbuses a los que está conectado. )omponentes y buses se puedencomponertopológicamente de distintas maneras, siguiendo reglas yrestricciones particulares. )adacomponente posee dos puntos de coneión, llamadosrespecti!amente top y bottom. Elesquema no admite ciclos, de modo que un componente no puederecibir una noticacióngenerada por 3l mismo "-J+%%'.En la estrategia arquitectónica de


6/25

la salida del proceso de negocios no está denida por ningunaimplementación, o esdenida sólo por una implementación de negocios especíca.@Entre las !entajas enumeradas en relación con el modelo se se6alanB

$e optimi/a el mantenimiento haciendo que procesos de negociosque no están relacionadossean independientes.$e alienta el desarrollo en paralelo, lo que puede resultar en mejorasde performance.Es fácil de empaquetar en una transacción atómica.Es agnóstica en lo que respecta a si las implementaciones corrensincrónica o asincrónicamenteporque no se espera una respuesta.$e puede agregar un componente registrándolo para los e!entos delsistema0 se puedenreempla/ar componentes.Entre las des!entajasBEl estilo no permite construir respuestas complejas a funciones denegocios.In componente no puede utili/ar los datos o el estado de otrocomponente para efectuarsu tarea.)uando un componente anuncia un e!ento, no tiene idea sobre qu3otros componentesestán interesados en 3l, ni el orden en que serán in!ocados, ni el

momento en quenali/an lo que tienen que hacer. :ueden surgir problemas deperformance global y demanejo de recursos cuando se comparte un repositorio común paracoordinar lainteracción.En esta estrategia juega un rol importante el $er!icio de E!entos, elcual a su !e/proporciona un buen punto de partida para la implementación delestilo o patrón, segúnse est3 concibiendo la arquitectura o implementándola. $e puede

consultar informacióndetallada sobre Enterprise $er!ice E!ents en el artículo sobre L)F


7/25

$ólo recientemente estas arquitecturas que los conocedores llaman$FA han recibidotratamiento intensi!o en el campo de eploración de los estilos. Almismo tiempo sepercibe una tendencia a promo!erlas de un sub;estilo propio de las

conguracionesdistribuidas que antes eran a un estilo en plenitud. Esta promociónocurre al compás delas predicciones con!ergentes de #iga o de #artner que 1despu3s deun par de a6os detitubeo y consolidación2 las !isuali/an en sus pronósticos ycuadrantes mágicos como latendencia que habrá de ser dominante en la primera d3cada delnue!o milenio. Ahorabien, este predominio no se funda en la idea de ser!icios en general,comunicados decualquier manera, sino que más especícamente !a de la mano de laepansión de losNeb ser!ices basados en Q


8/25

$FA:, típicamente transportados usando T: con una seriali/aciónen Q'.Jo es intención de este estudio describir en detalle las peculiaridades

de este estilo,sucientemente caracteri/ado desde diferentes puntos de !ista en ladocumentaciónprimaria de la estrategia de arquitectura de


9/25

1nati!amente o mediando un wrapper 2 podría llegar a con!ersar o aintegrarse concualquier otra 1ídem2 una !e/ resueltas las ine!itables coordinacionesde ontología. En elcuadro siguiente he referido las características del modelo de

llamado;respuesta propiodel estilo, en contraste con tecnologías clásicas bien conocidas decomunicación entrecomponentes y objetos en ambientes -)F


10/25

F8H+ECDF+ Ha!a.rmi.namingI+D


11/25

mismo. Algunas de estas notaciones son pro!istas por lenguajesdeclarati!os basados enQ>'. Es en ella donde se encuentrala caracteri/ación


12/25

más detallada del estilo denominado +epresentational $tate ransfero +E$. Aunque laliteratura especiali/ada tiende a considerar a +E$ una !ariantemenor de lasarquitecturas basadas en ser!icios, Cielding considera que +E$

resulta de lacomposición de !arios estilos más básicos, incluyendo repositorioreplicado, cache,cliente;ser!idor, sistema en capas, sistema sin estado, máquina!irtual, código a demandae interfa/ uniforme "C>*'. Cielding no solamente epande más alláde lo habitual yqui/á más de lo prudente el catálogo de estilos eistentes, sino quesu tratamientoestilístico se basa en :erry y Nolf ":N%*' antes que en #arlan y $ha4"#$%&', debido aque la literatura sobre estilos que se deri!a de este último teto sóloconsidera elementos,conectores y restricciones, sin tomar en consideración los datos, quepara el caso de+E$ al menos constituyen una dimensión esencial.En síntesis muy apretada, podría decirse que +E$ dene recursosidenticables ym3todos para acceder y manipular el estado de esos recursos. El casode referencia esnada menos que la Norld Nide Neb, donde los I+Ds identican los

recursos y T: esel protocolo de acceso. El argumento central de Cielding es que T:mismo, con suconjunto mínimo de m3todos y su semántica simplísima, essucientemente general paramodelar cualquier dominio de aplicación. -e esta manera, elmodelado tradicionalorientado a objetos de!iene innecesario y es reempla/ado por elmodelado de entidadestales como familias jerárquicas de recursos abstractos con unainterfa/ común y una

semántica denida por el propio T:. +E$ es en parte una rese6ade una arquitecturaeistente y en parte un proyecto para un estilo nue!o. 5acaracteri/ación de +E$constituye una lectura creati!a de la lógica dinámica que rige elfuncionamiento de laNeb 1una especie de ingeniería in!ersa de muy alto ni!el2, al lado deuna propuesta denue!os rasgos y optimi/aciones, o restricciones adicionalesB +E$, porejemplo, nopermite el paso de cookies $ propone la eliminación de


13/25

estructural a la corrupción y a su discrepancia lógica con T:. +E$se construyeepresamente como una articulación compuesta a partir de estilos ysub;estilospreeistentes, con el agregado de restricciones especícas. En la

gura 7, ++corresponde a +epositorio +eplicado, )$ a )liente;$er!idor, 5$ asistema en capas, (<a *'5a especicación +E$ posee algunas peculiaridades emanadas de sulógica orientada arecursos que la hacen diferente de otras implementaciones talescomo Neb-A(,ebQ' " httpBOO444.4s;i.org'. El lema de


14/25

+E$ es, despu3s de todo, LAdiós objetos, adiós +:)M.El Lugar del Estilo en Arquitectura de SoftwareA n de determinar cómo se !inculan los estilos con otros conceptos yel espacio queocupan en el marco conceptual de la arquitectura o en las secuencias

de procesos de lametodología, habría que mapear buena parte, si es que no latotalidad del espacio de laarquitectura de soft4are, a su !e/ complejamente !inculado con otroscampos que nuncafueron demarcados de manera deniti!a.


15/25

situar en 3l la teoría y la práctica de los estilos dista de ser algo quepueda decidirsesiempre con transparencia. 5os estilos son históricamente más tardíosque esos marcos, ysurgieron porque había necesidad de compensar una ausencia tanto

en el canon estáticode las matrices de !istas como en el paradigma dinámico de losprocesos, metodologíasde dise6o o disciplinas de desarrollo de soluciones.El concepto de !istas arquitectónicas 1views2, así como losframeworks arquitectónicosestablecidos en las fases tempranas de la arquitectura de soft4are,suministran diferentesorgani/aciones del espacio de conceptos, m3todos, t3cnicas,herramientas y procesossegún distintos criterios y con !ariados 3nfasis. 5as terminologíasglobali/adoras soninestables y no siempre fáciles de comparar entre sí0 se ha habladode frameworks,modelos de referencia, escenarios, !istas 1views2, metodologías yparadigmas. Algunosejemplares abarcati!os han sido consistentes en el uso de laterminología, otros no tanto.Aún en el caso de que la terminología sea sintácticamente in!ariante1como sucede enepistemología con el c3lebre LparadigmaM de homas 9uhn2 la

semántica que se leimprime no siempre ha sido la misma, ni en los documentos ocialesni en su aplicaciónpor terceras partes.En general, los grandes marcos son agnósticos en lo que se reere ametodologías ynotaciones. :or metodologías me reero a entidades tales como


16/25

modelado como I*'2 suelen omitir toda referencia a este marco.El


17/25

5os cinco puntos de !ista no corresponden a etapas de proceso dedesarrollo orenamiento. -e los cuatro estándares básicos, los dos primeros sereeren a lamoti!ación general del modelo y a sus fundamentos conceptuales y

analíticos, el tercero1D$FODE) >@&7;0 ID; Q.%>2 a la arquitectura, deniendo los puntosde !istasreferidos0 y el cuarto 1D$FODE) >@&7;&0 ID; Q.%>&2 a la formali/aciónde lasemántica arquitectónica. +>>, +icG Tilliardelaboró un preciso informe sobre el impacto de las recomendacionesde DEEE sobre elmarco de F#AC, estimando que ambos son complementarios y

compatibles, pero&?recomendando que F#AC se mue!a hacia el marco categorial deDEEE antes que lain!ersa "Til>>'. al como está epresado el marco de referencia, losestilos se articulancon mayor claridad en la !ista de Arquitectura de Aplicación.En %%? :hilippe 9ruchten propuso su c3lebre modelo L&=M,!inculado al +ationalInied :rocess 1+I:2, que dene cuatro !istas diferentes de laarquitectura de soft4areB

12 5a !ista lógica, que comprende las abstracciones fundamentalesdel sistema a partirdel dominio de problemas. 1*2 5a !ista de procesoB el conjunto deprocesos de ejecuciónindependiente a partir de las abstracciones anteriores. 12 5a !istafísicaB un mapeado delsoft4are sobre el hard4are. 1&2 5a !ista de desarrolloB la organi/aciónestática demódulos en el entorno de desarrollo. El quinto elemento consideratodos los anteriores enel conteto de casos de uso "9ru%?'. Es palmario que los estilosafectan a las dos


18/25

primeras !istas, mientras que los patrones tienen que !er más biencon la última. Encuanto a los estilos, 9ruchten menciona la posible implementación dealgunos de ellos1 pipe&'lter , cliente;ser!idor2 en relación con la !ista de proceso,

mientras querecomienda adoptar un estilo en capas en la !ista de desarrollo"9ru%?B , ?'. )uando selee el artículo de 9ruchten 1un par de a6os posterior al surgimiento delos estilos en eldiscurso arquitectónico2 es ine!itable la sensación de que lo que 3lllama estilo tiene másque !er con la notación gráca que usa para la representación1siempre ligada a ideas deobjeto2 que con la estructura de componentes, conectores yrestricciones que según se haconsensuado denen un estilo. Za en la !ista lógica, por ejemplo, loscomponentes sonclases y los conectores están ligados a conceptos de herencia0 en la!ista de desarrollo susclases de!ienen LmódulosM o LsubsistemasM más o menos neutros,pero todo el mundosabe qu3 entidad resulta cuando se instancia una clase, sobre todocuando lasincumbencias enfati/adas son LportabilidadM y Lre;utili/aciónM "9ru%?B&;?'. El

modelo &= se percibe hoy como un intento se reformular unaarquitectura estructural ydescripti!a en t3rminos de objetos y de I


19/25

12 la organi/ación de un sistema de soft4are0 1*2 la selección deelementos estructuralesy sus interfaces a tra!3s de los cuales se constituye el sistema0 12 sucomportamiento,según resulta de las colaboraciones entre esos elementos0 1&2 la

composición de esoselementos estructurales y de comportamiento en subsistemasprogresi!amente mayores01?2 el estilo arquitectónico que guía esta organi/aciónB los elementosestáticos ydinámicos y sus interfaces, sus colaboraciones y su composición. 5osautores&7proporcionan luego un esquema de cinco !istas posibles de laarquitectura de un sistemaB12 5a !ista de casos de uso, como la perciben los usuarios, analistasy encargados de laspruebas0 1*2 la !ista de dise6o que comprende las clases, interfaces ycolaboraciones queforman el !ocabulario del problema y su solución0 12 la !ista deprocesos que conformanlos hilos y procesos que forman los mecanismos de sincroni/ación yconcurrencia0 1&2 la!ista de implementación que incluye los componentes y archi!ossobre el sistema físico01?2 la !ista de despliegue que comprende los nodos que forma la

topología de hard4aresobre la que se ejecuta el sistema "8+H%%B *7;*@'. Aunque las !istasno están epresadasen los mismos t3rminos estructuralistas que campean en sucaracteri/ación de laarquitectura, y aunque la relación entre !istas y decisionesarquitectónicas es de simpleyutaposición informal de ideas antes que de integración rigurosa, esnatural inferir quelas !istas que más claramente se !inculan con la semántica estilísticason la de dise6o y la

de proceso.En los albores de la moderna práctica de los patrones, 8uschmann yotros presentan listasdiscrepantes de !istas en su teto popularmente conocido como()SA "8


20/25

parte, incluyeB 12 (ista lógicaB el modelo de objetos del dise6o, o unmodelocorrespondiente tal como un diagrama de relación0 1*2 (ista deprocesoB aspectos deconcurrencia y sincroni/ación0 12 (ista físicaB el mapeo del soft4are

en el hard4are ysus aspectos distribuidos0 1&2 (ista de desarrolloB la organi/aciónestática del soft4are ensu entorno de desarrollo. Esta segunda lista coincide con el modelo&= de 9ruchten,pero sin tanto 3nfasis en el quinto elemento.8ass, )lements y 9a/man presentan en %% una taonomía denue!e !istas,decididamente sesgadas hacia el dise6o concreto y laimplementaciónB 12 Estructura demódulo. 5as unidades son asignaciones de tareas. 1*2 Estructuralógica o conceptual. 5asunidades son abstracciones de los requerimientos funcionales delsistema. 12 Estructurade procesos o de coordinación. 5as unidades son procesos o threads.1&2 Estructura física.1?2 Estructura de uso. 5as unidades son procedimientos o módulos,!inculados porrelaciones de presunción;de;presencia;correcta. 172 Estructura dellamados. 5as unidadesson usualmente 1sub2procedimientos, !inculados por in!ocaciones o

llamados. 1@2 Clujode datos. 5as unidades son programas o módulos, la relación es deen!ío de datos. 12Clujo de control0 las unidades son programas, módulos o estados delsistema. 1%2Estructura de clases. 5as unidades son objetos0 las relaciones sonhereda-de o es-unainstancia-de "8)9%'. -e acuerdo con el punto de !ista de la formulación deestilos,la situación de 3stos en este marco puede !ariar sustancialmente.5a recomendación DEEE $td &@;*>>> procura establecer una base

común para ladescripción de arquitecturas de soft4are, e implementa para ello trest3rminos básicos,que son arquitectura, !ista y punto de !ista. 5a ar*uitectura se denecomo la&@organi/ación fundamental de un sistema, encarnada en suscomponentes, las relacionesentre ellos y con su entorno, y los principios que gobiernan su dise6oy e!olución. 5os

elementos que resultan denitorios en la utilidad, costo y riesgo de unsistema son en


21/25

ocasiones físicos y otras !eces lógicos. En otros casos más, sonprincipios permanentes opatrones que generan estructuras organi/acionales duraderas.

3rminos como vista o punto de vista son tambi3n centrales. En la recomendación se los

utili/a en un sentidoligeramente distinto al del uso común. Aunque reVejan el usoestablecido en losestándares y en la in!estigación de ingeniería, el propósito delestándar es introducir ungrado de formali/ación homogenei/ando informalmente lanomenclatura. En dichanomenclatura, un punto de !ista 1viewpoint 2 dene un patrón oplantilla 1template2 pararepresentar un conjunto de incumbencias 1concerns2 relati!o a unaarquitectura, mientrasque una !ista 1view2 es la representación concreta de un sistema enparticular desde unaperspecti!a unitaria. In punto de !ista permite la formali/ación degrupos de modelos.Ina !ista tambi3n se compone de modelos, aunque posee tambi3natributos adicionales.5os modelos proporcionan la descripción especíca, o contenido, deuna arquitectura.:or ejemplo, una !ista estructural consistiría de un conjunto demodelos de la estructura

del sistema. 5os elementos de tales modelos incluirían componentesidenticables y susinterfaces, así como interconeiones entre los componentes. 5aconcordancia entre larecomendación de DEEE y el concepto de estilo se establece conclaridad en t3rminos delllamado Lpunto de !ista estructuralM. Ftros puntos de !istareconocidos en larecomendación son el conductual y el de interconeión física. El puntode !istaestructural ha sido moti!ado 1arman los redactores del estándar2 por

el trabajo enlenguajes de descripción arquitectónica 1A-5s2. El punto de !istaestructural, dicen, seha desarrollado en el campo de la arquitectura de soft4are desde%%& y es hoy de ampliouso. Este punto de !ista es a menudo implícito en la descripciónarquitectónicacontemporánea y de hecho ha decantado en el concepto de estilo,plena y epresamentereconocido por la DEEE. En cuanto a los patrones, la recomendación deDEEE no haespecicado ninguna pro!isión respecto a principios de reutili/aciónque constituyen la


22/25

esencia del concepto de patrones. Ante tal circunstancia, +ich Tilliard,uno de susredactores, propone etender el modelo en esa dirección "Til>'. Enun estudio sobre elparticular, Tilliard ha anali/ado puntos de !ista, estilos y patrones

como tres modelosalternati!os de descripción del conocimiento arquitectónico "Til>b'.5a estrategia de arquitectura de *'"$ha4%7' "


23/25

as2&=1(istas2"8+H%%'1(istas2

:F$A1(istas2


24/25

In escenario tan complejo y una historia tan pródiga en incidentescomo las de laingeniería y la arquitectura de soft4are podrían articularse tambi3nsegún otrasnarrati!as. Tacia %%*, por ejemplo, Hoseph #oguen, del 5aboratorio

de )omputación dela Ini!ersidad de Fford, estimaba que el desarrollo de sistemashasta aquel entonces sehabía desplegado en dos campos, que 3l llamaba el +medo y elSeco "#og%*'. El campo&%+medo está dominado fundamentalmente por la mentalidad delLhacker MB eldesarrollador de sistemas desea crear un sistema lo más rápidoposible y para ello utili/atantos principios heurísticos de dise6o como pueda conseguir paraalcan/ar el objeti!o. Elsistema puede o no quedar documentado en el proceso. $i el sistemafunciona, a la larga,ello es porque no está desarrollado según un proceso al a/ar, sino quese han utili/adopatrones heurísticos de dise6o, basados en eperiencias pre!ias yan3cdotas que fueronpasando de un programador a otro. $al!ando las distancias, ladenición de #oguen de lamentalidad seca parece una descripción anticipada de lo que despu3s

sería el espíritu deal menos algunas de las facciones de la programación ágil, la mismaque ha hecho que


25/25

tempranos de esta con!ergencia entre principios secos y húmedosson los principios dedise6o sentados por in!estigadores como HacGson, $torer y otros más,que desdemediados de la d3cada de %> identicaron una serie de reglas para

construir Ldise6osestructuradosM a partir de las pie/as de construcción 1building blocks2de programas, talescomo secuencias de instrucción, selección e iteración. Estos y otrosprincipios de dise6ohan decantado en la in!estigación que nalmente condujo a laarquitectura de soft4are ya los estilos arquitectónicos tal como se los conoce hoy en día.

estilos heterogéneos

Documents