SUBSECRETARIA DE EDUCACION SUPERIOR DIRECCION GENERAL DE EDUCACION SUPERIOR TECNOLOGICA INSTITUTO TECNOLOGICO DE TAPACHULA

Nombre Del Alumno: Martnez Ramos Sheyla Berenice

Nombre De La Carrera: Ingeniera En Sistemas Computacionales

Nombre Del Profesor: Mayra Yazmin Lopez Rosales

Nombre De La Materia: Ingeniera de Software

Tema: Evolucion de las Arquitecturas de Software

INTRODUCCION
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 esta investigacin se ha optado, ms bien, por inspeccionar las fuentes ms de cerca, con el objeto de sealar las supervivencias y las resemantizaciones 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 la hora 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.

ANTECEDENTES
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. 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 Laboratorios de New Jersey y Alexander Wolf de la Universidad de Colorado. 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 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, 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 Turing 1972, propuso que se establezca una estructuracin correcta de los sistemas de software antes de lanzarse a programar, escribiendo cdigo de cualquier manera. 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 como stepwise refinement y DeRemer y Kron como programming-in-the large (o programacin en grande), ideas que poco a poco iran decantando entre los ingenieros primero y los arquitectos despus. 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 hemos hablado muy poco pero que deberamos poner sobre el tapete y concentrar la atencin en ello. Es la cuestin de la arquitectura de software. La arquitectura es diferente de la ingeniera. Como ejemplo de lo que quiero decir, echemos una mirada a OS/360. Partes de OS/360 estn extremadamente bien codificadas.

Partes de OS, si vamos al detalle, han utilizado tcnicas que hemos acordado constituyen buena prctica de programacin. La razn de que OS sea un amontonamiento amorfo de programas es que no tuvo arquitecto. Su diseo fue delegado a series de grupos de ingenieros, cada uno de los cuales invent su propia arquitectura. Y cuando esos pedazos se clavaron todos juntos no produjeron una tersa y bella pieza de software.

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 consideran especificaciones funcionales. Slo hablamos sobre lo que queremos que haga el programa. Es mi creencia que cualquiera que sea responsable de la implementacin de 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 ingenieros deben crear algo. Ningn ingeniero o programador, ninguna herramienta de programacin, nos ayudar, o ayudar al negocio del software, a maquillar un diseo feo. El control, la administracin, la educacin y todas las cosas buenas de las que hablamos son importantes; pero la gente que implementa debe entender lo que el arquitecto tiene en mente. 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, sin que la mayor parte de la historiografa 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, 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 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; 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 bien en 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 la estructura 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, estructuras de software y familias de programas, 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. 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 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. 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. 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 han sido construidos o lo sern alguna vez) a los cuales es provechoso o til considerar como grupo. Esto evita el uso de conceptos ambiguos tales como similitud funcional que surgen a veces cuando se describen dominios. Por ejemplo, los ambientes de ingeniera de software y los juegos de video no se consideran usualmente en el mismo dominio, aunque podran considerarse miembros de la misma familia de programas en una discusin sobre herramientas que ayuden a construir 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 y las diferencias entre ellos. 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 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 cabe que 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, 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 lllamado Larger scale systems require higher level abstractions. 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, una analoga de la que luego algunos abusaron [WWI99], otros encontraron til y para unos pocos ha devenido inaceptable. El artculo comienza diciendo exactamente: El propsito de este paper es construir el fundamento para la arquitectura de software. Primero desarrollaremos una intuicin para la arquitectura de software recurriendo a diversas disciplinas arquitectnicas bien definidas. Sobre la base de esa intuicin, presentamos un modelo para la arquitectura de software que consiste en tres componentes: elementos, forma y razn (rationale). Los

elementos son elementos ya sea de procesamiento, datos o conexin. La forma se define en trminos de las propiedades de, y las relaciones entre, los elementos, es decir, restricciones operadas sobre ellos. La razn proporciona una base subyacente para la arquitectura en trminos de las restricciones del sistema, que lo ms frecuente es que se deriven de los requerimientos del sistema. Discutimos los componentes del modelo en el contexto tanto de la arquitectura como de los estilos arquitectnicos 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 la implementacin 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 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 los arquitectos de software) y de estilo. Es tiempo de re-examinar el papel de la arquitectura de software en el contexto ms amplio del proceso de software y de su administracin, 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 sin duda 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 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. 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 cdigo, y aunque la reutilizacin de patrones guarda estrecha relacin con la tradicin del diseo concreto orientado a objetos, algunos arquitectos emanados de la escuela de Carnegie Mellon formalizaron un acercamiento con esa estrategia. Tanto en los patrones como en la arquitectura, la idea dominante es la de reutilizacin. 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 frameworks generalizadores 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. 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. 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.