0 оценок0% нашли этот документ полезным (0 голосов)
75 просмотров4 страницы
Edsger Dijkstra propuso establecer una estructuración correcta de los sistemas de software antes de programar y ayudó a precisar conceptos como niveles de abstracción. En 1969, P.I. Sharp formuló el concepto de arquitectura de software, argumentando que el sistema OS/360 no funcionó bien debido a que no tuvo un arquitecto que diseñara la interfaz de usuario de manera completa y detallada. En los años 70, David Parnas demostró que los criterios de descomposición de un sistema impactan su estructura y des
Исходное описание:
breve resumen sobre como se inicio la Arquitectura de software
Edsger Dijkstra propuso establecer una estructuración correcta de los sistemas de software antes de programar y ayudó a precisar conceptos como niveles de abstracción. En 1969, P.I. Sharp formuló el concepto de arquitectura de software, argumentando que el sistema OS/360 no funcionó bien debido a que no tuvo un arquitecto que diseñara la interfaz de usuario de manera completa y detallada. En los años 70, David Parnas demostró que los criterios de descomposición de un sistema impactan su estructura y des
Edsger Dijkstra propuso establecer una estructuración correcta de los sistemas de software antes de programar y ayudó a precisar conceptos como niveles de abstracción. En 1969, P.I. Sharp formuló el concepto de arquitectura de software, argumentando que el sistema OS/360 no funcionó bien debido a que no tuvo un arquitecto que diseñara la interfaz de usuario de manera completa y detallada. En los años 70, David Parnas demostró que los criterios de descomposición de un sistema impactan su estructura y des
Cada vez que se narra la historia de la AS se reconoce que Edsger Dijikstra
quien propuso el establecimiento de una estructuracin correcta de los sistemas de SW antes de programar, al igual que el mismo sostena que las ciencias de la computacin eran una rama aplicada de las matemticas, l tambin fue uno de los instructores de la nocin de SO organizados por capas. Tambin ayudo a precisar docenas de conceptos como el algoritmo del camino ms corto, stacks, vectores, semforos, entre otros. De l tambin podemos hacer referencia a niveles de abstraccin que es tan comn hoy en da. Durante NATO 1969, un ao despus de que se fundara la Ingeniera de Software P.I. Sharp formulo lo siguiente en base a 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 afirma que con el tiempo probablemente se legue a hablarse de La escuela de arquitectura de Dijkstra. Despus de esto nadie volvi a tocar el tema, aunque por algunos aos arquitectura era tomada como una metfora, pero esta no tena ni precisin semntica ni consistencia pragmtica. En el 69 Fred Brooks Jr y Ken Iverson tomaban como arquitectura a la estructura conceptual de un sistema en la perspectiva del programador. En 1975 Brooks tomo este concepto para designar la especificacin completa y detallada de la interfaz de usuario y considero al arquitecto como un agente del usuario. Algo importante durante los 70s fue el Diseo estructurado y de los primeros modelos explcitos de desarrollo de software, estos modelos se basaron en una estructura ms orgnica, evolutiva y cclica dejado atrs el desarrollo en cascada. Tambin surgieron las primeras investigaciones acadmicas referentes a diseo de sistemas complejos, esto dio pauta a que de poco en poco se independizara de la implementacin y forjara de una manera ms especifica. En esa misma poca David Parnas demostr que los criterios seleccionados en la descomposicin de un sistema impactan en la estructura de los programas, propuso varios diseos que se deban seguir a fin de obtener una estructura adecuada, as tambin desarrollo temas como Mdulos de ocultamiento de informacin, estructuras de software y familias de programas todo enfatizado a
la calidad de software medible en economa y mantenimiento. Despus en
1972 publico un ensayo en que mencionaba la mejora del diseo de estos mediante la flexibilidad y control conceptual del sistema. 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. En este punto Parnas no habla sobre POO sino de mdulos y subrutinas ya que los Objetos aun no existan en la programacin Parnas nos dice lo siguiente acerca de las familias de programas: 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. Este concepto soporta la nocin de derivar un miembro de la familia a partir de uno ya existente, al igual que se pueden derivar varios miembros de la familia de un punto de decisin en comn, aclarando la semejanza y diferencias entre ellos. 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). Durante los 80s los mtodos de desarrollo estructurado demostraron no escalar suficientemente y dejaron el descubrimiento de un nuevo paradigma el de la POO. Lo cual llevo a la investigacin de lo que sera el diseo Orientado a Objetos lo cual se puede remontar a la dcada de 1960 con Simula, un lenguaje de simulacin el cual fue el primero en proporcionar tipos de datos abstractos y clases y despus se refino con la llegada de Smalltalk, ya en 1980 se toma el concepto de AS para hacer referencia a la configuracin morfolgica de una aplicacin. El primer estudio en el que aparece la expresin Arquitectura de software tal y como lo conocemos actualmente fue gracias a Perry y Wolf, el artculo comienza con lo siguiente: 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. Los autores siguen rediseando el progreso de la 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 y herramientas especializadas las cuales dieron como resultado a las herramientas CASE, lo cual dio como resultado la absorcin de las herramientas de diseo por los lenguajes de implementacin. Su integracin se esfumo gracias a la confusin entre diseo e implementacin. Ya en los 80s se perfeccionaron las tcnicas descriptivas permitiendo un mejor razonamiento sobre 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. 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 , quien afirma que la AS promova un modelo que deba ser ms de integracin de componentes pre programados que de programacin. 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. Tanto en los patrones como en la arquitectura la idea dominante es la de reutilizacin. , 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). Hasta el ao 2000 surgi uno de los acontecimientos ms importantes fue la clebre tesis de Roy Fielding la cual presento el modelo REST, el cual establece el tema de las tecnologas de Internet y los modelos orientados a servicios.
Asimismo tambin 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. 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.